カスタム列抽出の使い方：
ページ全体ではなく、必要なデータだけを取得する

「すべて抽出」が間違った出発点である理由

従来のOCRは「このページに何が書いてあるか」という問いに答えるものです。文書の画像を機械可読な文字の流れに変換します。つまり、すべての単語、すべての数字、透かしやページ番号まで含めてです。1ページの請求書であれば、50〜80個のテキスト文字列が構造もラベルもないままスプレッドシートに出力されます。その後、あなたの仕事は、出力を読み、どの文字列が請求書番号で、どれが日付で、どれが合計かを特定し、実際に使っているスプレッドシートにコピーすることになります。

これが、ビジネス文書処理において「OCRで全テキストを抽出」がほとんど正解にならない理由です。文書内のすべてのテキストが必要になることはほぼありません。必要なのは5〜10個の特定のフィールドだけです。残りはノイズであり、そのノイズを除去する時間は、自動化によって節約しようとしていた時間と同じものです。

カスタム列抽出は逆の方向から始まります。すべてを抽出して後からフィルタリングする代わりに、事前に列を定義します。AIはターゲットフィールドをレンズとして文書を読み取ります。PO番号、仕入先名、合計を検索し、それ以外は無視します。出力は、あなたが名付けた列を持つ、まさに欲しかったスプレッドシートになります。

列名は指示である：命名戦略

入力する列名は、あなたとAIの間の主要なコミュニケーションチャネルです。適切に書かれた列名は正確な指示であり、AIにどのような値を探し、どのようにフォーマットするかを正確に伝えます。曖昧な列名（「金額」）はAIへのガイダンスが少なすぎます。適切な列名（「注文合計金額」や「請求書合計」）は検索を絞り込み、最初の試行で正しい数値を取得できる可能性を高めます。

最も正確な抽出結果を生み出す命名原則は次のとおりです。

厳密な命名規則に従う必要はありません。AIは自然言語を理解します。「Due Date」と「Payment Due Date」のどちらでも機能します。ただし、より具体的に指定するほど、AIが解決すべき曖昧さが減り、抽出精度が向上します。

実際の抽出シナリオ3選

同じカスタム列抽出の仕組みは、非常に異なる文書タイプやワークフローに適応します。ここでは、それぞれ異なる列設定戦略を必要とする3つの一般的なシナリオをご紹介します。

シナリオ1: 請求書処理

必要なもの: 請求書番号、請求日、支払期日、ベンダー名、小計、税額、合計金額、通貨。これら8つのフィールドは、形式やレイアウトに関係なく、ほぼすべての請求書に記載されています。

列の設定: 上記のフィールド名をそのまま入力します。明細項目を含む複数ページの請求書の場合は、「品目説明」「数量」「単価」「明細合計」の列を追加します。各明細項目は出力の1行になり、請求書のヘッダーフィールド（番号、日付、ベンダー）は、その請求書のすべての行で繰り返されます。これにより、ベンダーごとのフィルタリングや集計が容易になります。

バッチ処理のヒント: 複数のベンダーからの請求書を一度に処理する場合（例：月末の買掛金処理）、すべての請求書を1つのバッチでアップロードできます。AIは各請求書から独立して抽出し、結果を1つのスプレッドシートに統合します。すべての行で列が一貫しています。

シナリオ2：発注書処理

必要な項目：PO番号、発行日、仕入先名、品目コード、品目説明、注文数量、単価、行合計、希望納品日。これらのフィールドは、POヘッダーと明細項目の詳細の両方を1回の処理でカバーします。

列設定の戦略：POは請求書よりもテーブル中心です。必要な明細項目の列（品目コード、説明、数量、単価、行合計）をすべて、ヘッダーフィールドと同じ列リストに含めてください。AIは、ヘッダーフィールド（PO番号、仕入先名）が文書全体に適用されることを理解し、各明細行にそれらを繰り返し適用します。一方、明細項目のフィールドはテーブル内の行ごとに異なります。

複数ページの処理：各ページに繰り返しの列ヘッダーがある複数ページにわたるPOの場合、AIは繰り返されるヘッダーを認識し、出力から除外します。200の明細項目がある10ページのPOは、手動で結合が必要な10個の別々のテーブルではなく、200のデータ行を生成します。

シナリオ3：ベンダー見積もり比較

必要な項目：仕入先名、品目説明、数量、単価、行合計、リードタイム（日数）、支払い条件、通貨。5つの異なる仕入先からの見積もりを1つのバッチでアップロードすると、AIは各仕入先のフォーマットがどれほど異なっていても、同じ列定義を使用してそれぞれを抽出します。

主な利点：異なる仕入先が同じ情報に異なる名前を使用する場合があります。ある仕入先は「SKU」、別の仕入先は「Part Number」、3つ目は「Item Code」と呼ぶかもしれません。AIの意味理解により、同義語や仕入先ごとのマッピングを設定しなくても、これらすべてが「品目コード」列にマッピングされます。

テンプレートとして保存：一度設定すれば、ずっと使える

特定の文書タイプに適した列セットを定義したら — 例えば、標準の請求書抽出列 — それをテンプレートとして保存できます。次回請求書を処理する際は、8つの列名をすべて再入力する代わりに、ワンクリックでテンプレートを読み込めます。

ここで、一度きりの設定コストが継続的に報われます。請求書の列設定は初回2分で完了します。その後の請求書バッチは — 5件でも50件でも — その列が事前に読み込まれた状態から始まります。ファイルをアップロードすると、AIが保存済みテンプレートに基づいて処理し、毎回一貫した構造のスプレッドシートが得られます。

テンプレートはチームの一貫性にも役立ちます。チームの複数メンバーが文書を処理する場合、同じテンプレートを共有することで、全員の出力に同一の列が同一の順序で含まれることが保証されます — フィールド名のばらつきも、列の欠落も、時間経過による形式のずれもありません。

よくある質問

列はいくつ定義すべきですか？上限はありますか？

厳格な上限はありませんが、実用的な目安があります。約15〜20列までは、抽出は一貫して信頼できます。それを超えると、すべての文書に存在しない可能性のあるエッジケースのフィールドをカバーし始めることになります。5〜12個の適切に命名されたフィールドに絞った列セットは、30列の網羅的なリストよりもほぼ常に良い結果を生みます。AIが各フィールドにより集中的に注意を払えるからです。多くのフィールドが必要な場合は、2回のパスに分割することを検討してください：1回目で主要フィールド、2回目で補足フィールドです。

特定の文書にフィールドが存在しない場合はどうなりますか？

そのセルは空白のままになります。例えば、列セットに「税額」が含まれているが、文書の1つに税がない場合（州間B2B請求書や輸出文書でよくある）、出力のその行の税額セルは単に空になります。スプレッドシートは構造的に一貫性を保ちます — すべての行に同じ列があります — ただし、値はAIが文書内で見つけた場所にのみ入力されます。

1つのバッチに異なる種類の書類を混在させることはできますか？

はい、ただしバッチ内のすべての書類タイプに対して列セットが意味を成す場合に限ります。請求書、発注書、領収書を「請求書番号 / 発注書番号 / 領収書番号」のような列と一緒にアップロードすると、AIは各書類内で各フィールドを見つけようとします。特定のフィールドを含まない書類では、その列は空白セルになります。最良の結果を得るには、同じ種類の書類をまとめてバッチ処理してください。つまり、すべての請求書を1つのバッチに、すべての発注書を別のバッチに入れます。これにより、列定義の焦点が保たれ、出力がクリーンになります。

手動でデータを入力する場合と比べて、精度はどのくらいですか？

印刷された整った形式の書類の場合、フィールドレベルの精度は90%を超えます。つまり、10個の値のうち9個が最初のパスで正しく抽出されるということです。これは、データ品質調査によるとキーストロークごとに1〜3%の固有のエラー率がある手動データ入力と比較して好ましい結果です。違いは、AIのエラーは予測可能な傾向があり（類似したフィールド名の混同、低解像度テキストの誤読）、人間のエラーはランダムである（タイプミス、転置、行のスキップ）ことです。AI出力を簡単に確認すればほとんどの問題を発見できますが、自分で入力したエラーを発見するには、元の書類と照らし合わせて行ごとに検証する必要があり、これは最初の入力と同じくらいの時間がかかります。

AIはチェックボックス、印鑑、署名を処理できますか？

はい — これらの列を定義できます。「承認チェックボックス（チェック済み/未チェック）」、「会社印の有無（あり/なし）」、「権限者の署名の有無（あり/なし）」のような説明的な名前を使用してください。AIはこれらの視覚的要素を識別し、適切なステータスを返します。署名の場合、出力は通常「あり」または「なし」です — 存在を確認するものであり、本人確認をするものではありません。