AI文書抽出でクリーンで正確な出力を得る方法
AI文書抽出の精度を最大化する

カラム名は指示書です

AI抽出ツールにカラム名を入力するとき、それは単なるスプレッドシートのラベルではありません。モデルに対して「何を探し、どう識別し、どのように整形するか」を伝える指示です。モデルはカラム名を指示として読み取り、バッチ内のすべてのドキュメントに適用します。

つまり、曖昧なカラム名は曖昧な出力を生みます。請求書に5種類の日付がある場合に「日付」と指定すると、モデルが最初に見つけた日付が返ってきます。具体的なカラム名は具体的な出力を生みます。「発行日 (YYYY-MM-DD)」と指定すれば、どの日付を探し、どのように整形するかが明確になります。

以下の8つのヒントは、フォーマット指定から曖昧さの解消、バッチ処理でのエラーを防ぐ構造化テクニックまで、カラム名をより効果的に活用する方法を網羅しています。

より良い抽出結果を得るための8つのヒント

1. フォーマット指定をカラム名に埋め込む

「日付」ではなく「日付 (YYYY-MM-DD)」と書き、「金額」ではなく「金額 (数字のみ、通貨記号なし)」と書きましょう。モデルはカラム名をフィールド識別子とフォーマット指示の両方として読み取ります。

これは重要です。なぜなら、異なるソース文書では同じ値でも「2024年3月15日」「15/03/2024」「2024-03-15」のように形式が異なるからです。列名を「日付（YYYY-MM-DD）」とすれば、バッチ内の全文書で出力形式が統一され、後処理は不要です。金額も同様で、「合計金額（数字のみ、小数点以下2桁）」と指定すれば、通貨記号や桁区切りが除去され、数値演算にすぐ使える列になります。

2. 同じフィールド種別が文書内に複数存在する場合は明確に区別する

注文書には、注文日、納品日、支払期日があります。「日付」とだけ指定すると、モデルが見つけた最初の日付が抽出されます。「注文日」「納品日」「支払期日」を3つの別々の列として指定すれば、それぞれ正しい値が抽出されます。

これは金額（請求書合計 vs. 支払済み預かり金 vs. 残高）、名前（販売元 vs. 受取人 vs. 連絡先担当者）、参照番号（注文番号 vs. 請求書番号 vs. 追跡番号）にも同様に当てはまります。文書内に複数回出現しうるフィールド種別には、区別できる名前が必要です。

3. 推論または分類されるフィールドには自然言語を使用する

文書内のフィールド名を知っている必要はありません。必要な内容を説明すればよいのです。「取引種別（借方または貸方）」という列名は、銀行によって「引き出し/入金」「DR/CR」、あるいは正負の金額で表現される場合でも機能します。モデルは、ソース文書のキーワード一致ではなく、意味理解に基づいて各取引を分類します。

条件フィールドでも同様に機能します。「ステータス（支払印または確認テキストに基づき、支払済みか未払い）」は有効な指示です。モデルが文書を評価し、分類ロジックを適用します。つまり、ラベルがそのまま存在するフィールドに限定されません。

4. 曖昧な列にサンプル値を追加する

フィールド名だけでは複数の解釈が可能な場合、括弧内にサンプル値を追加することで曖昧さを解消します。モデルはこのサンプルをキャリブレーション信号として扱います。これは言語モデルプロンプトにおけるFew-shotプロンプティングと同じメカニズムです。

以下の3つのケースで特に効果的です。

• 特定の分類体系を持つ分類フィールド：「経費カテゴリ（例：家賃、光熱費、給与、旅費）」— サンプル値が使用すべきカテゴリを明確に定義し、モデルが独自にカテゴリを生成するのを防ぎます。サンプルがないと、異なるタイミングで処理されたバッチ間でカテゴリ名に不整合が生じる可能性があります。
• 異なる情報源間での形式統一：「電話番号（例：+1-415-555-0123）」— 国やシステムによって異なる書式規則が使われる場合、サンプルが明示的な書式ルールなしに出力形式を固定します。
• 類似した識別子の区別：「注文番号（例：PO-2024-0892、請求書番号ではありません）」— 複数の参照番号を含む文書において、サンプルが誤った番号を明示的に除外します。

サンプルは実際のデータである必要はなく、妥当な値で十分です。これはフィルターではなく、パターンを示す役割を果たします。

5. 列インデックスがサイレントエラーを防ぐ仕組みを理解する

信頼性の高いAI抽出における構造上の特性：抽出された各値は、カンマ区切り文字列内の位置だけでなく、その列インデックス番号とペアになっている必要があります。これは一見した以上に重要です。

明示的な列インデックスがない場合、フィールドが欠落すると、列が静かにずれてしまいます。行に5つの列があるが、特定の文書にフィールド3が存在しないためにモデルがそれを省略した場合、その行ではフィールド4と5が間違った列に配置されます。50件の文書バッチでは、このような位置ずれは発見が困難です。合計が仕入先名の列に入ったり、日付が金額の列に入ったりします。後続処理で数字が一致しなくなるまで気づきません。

インデックス付き出力（例：「1. 2024-03-15」「2. 1590.00」「3. ACME Supplies」）では、各値が明示的に列の識別情報を持ちます。フィールドが欠落すると、後続の値を静かに左にずらすのではなく、正しいインデックスに空のプレースホルダーが生成されます。ソース文書に実際に存在するフィールド数に関係なく、すべての行が同じ構造を維持し、空のセルは隣接する列を破損させることなく、データ欠落を正しく示します。

これは、ある種の幻覚エラーも抑制します。インデックス制約がないと、モデルは欠落フィールドを空白のままにする代わりに、もっともらしい隣接値を埋めてしまう可能性があります。明示的なインデックス付けにより、「ここには何も見つかりません」が有効で認識された出力状態になります。

6. 未知の文書タイプを扱う場合は、まず自動検出を使用する

これまで抽出したことのない文書タイプに遭遇した場合は、列を指定せずにアップロードしてください。モデルが文書の視覚的構造を分析し、見つかった内容に基づいて初期フィールドリストを生成します。

その出力を使って、どのフィールドが一貫して存在し、ソース文書がそれらをどのようにラベル付けしているかを把握し、以降のバッチ実行で使う列名を洗練させてください。これは、列名を推測したり、空白セルを繰り返し確認して文書の実際の内容を探るよりも効率的です。特に、新しい病院システムの検査報告書、ワークフローに追加したばかりの銀行の明細書、新しい仕入先の請求書フォーマットなど、馴染みのないレイアウトで役立ちます。

7. 文書ごとに1行か、明細ごとに1行かを明示する

8つの明細がある請求書は、1行（明細を連結または集計）または8行（明細ごとに1行）のいずれかで出力できます。指定する列名によって、どちらの動作になるかが決まります。

「仕入先名」「請求日」「合計金額」などの文書レベルの列を指定すると、文書ごとに1行が出力されます。「品目説明」「数量」「単価」「明細合計」などの明細レベルの列を指定すると、バッチ内の全文書の明細ごとに1行が出力されます。両方のタイプを1つの列セットに混在させることも有効です。その場合、モデルは各明細行に文書レベルの値を繰り返し、Excelでフィルタリングやピボットが容易な非正規化テーブルを生成します。

8. 同じ種類の文書をまとめてバッチ処理する

バッチ内のすべての文書が同じ列スキーマを共有する場合、各文書は1つのクリーンな結合テーブルの行セットになります。根本的に異なる文書タイプを、区別する列なしで混在させると、あいまいさが生じます。請求書の「金額」と銀行明細書の「金額」は意味が異なり、結合された出力では区別できなくなります。

異なる文書タイプを統合する必要がある場合は、「文書タイプ」または「ソース」列を追加してください。モデルは各文書から直接読み取り、自動的に入力できます。ファイルごとに手動でラベルを付ける必要はありません。

改善前と改善後：曖昧な列名と正確な列名

よくある質問