概要
- プロンプトベースの抽出アクティビティの作成
- LLM 接続の設定
- 効果的な抽出プロンプトの作成
- 出力形式および構造の定義
- 厳格度とバリデーションルールの適用
- 抽出結果のテストと改良
- 請求書からのベンダー情報抽出
- ヘッダーレベルのドキュメントデータ取得
- 半構造化ドキュメントの処理
- レイアウトが可変なドキュメントの処理
前提条件
- ABBYY Vantage Advanced Designer へのアクセス
- 設定済みの LLM 接続(LLM Connections の設定方法 を参照)
- サンプルドキュメントが読み込まれている Document Skill
- JSON 構造に関する 基本的な理解
- 抽出したいデータの field の定義
プロンプトベース抽出を理解する
プロンプトベース抽出とは?
- Role: LLM にどのような役割を持たせるか(例: “data extraction model”)
- Instructions: データをどのように抽出し、どのような形式で出力するか
- Output Structure: 結果を表現する JSON の正確な出力形式
- Rules: あいまいなデータや欠損しているデータをどのように扱うかのガイドライン
利点
- 学習データ不要:プロンプトエンジニアリングだけで動作します
- 柔軟:field の追加や変更が容易です
- バリエーションに対応:LLM はさまざまなドキュメント形式を理解できます
- セットアップが高速:従来の機械学習モデルを学習させる場合より短時間で開始できます
- 自然言語:平易な英語で指示を書けます
制限事項
- コスト: 各抽出処理で LLM API 呼び出しが行われます
- 速度: 単純なドキュメントに対する従来の抽出よりも遅くなる場合があります
- 一貫性: 実行のたびに結果がわずかに異なる可能性があります
- コンテキストの制限: 非常に長いドキュメントは個別の対応が必要になる場合があります
ステップ 1: プロンプトベースアクティビティを追加する
- ABBYY Vantage Advanced Designer で Document Skill を開きます
- 左側のパネルで EXTRACT FROM TEXT (NLP) を探します
- Prompt-based を見つけてクリックします

- アクティビティがワークフローキャンバス上に配置されます
- 入力アクティビティと出力アクティビティの間に接続します
ステップ 2: LLM 接続を構成する
- ワークフロー内のプロンプトベースのアクティビティを選択します
- 右側の Activity Properties パネルで LLM Connection を見つけます
- ドロップダウンメニューをクリックします

-
一覧から設定済みの LLM 接続を選択します
- 例:
Nick-ChatGPT,Microsoft Foundry,Production GPT-4
- 例:
- 選択された接続が正しいことを確認します
Step 3: 出力fieldを定義する
- Activity Properties パネルで Output セクションを探します
- fieldグループとfieldの階層リストが表示されます
- この例では、ベンダー情報を抽出します:
- ベンダー
- Name
- Address
- TaxID
- アカウント番号
- Sort Code
- IBAN(国際銀行口座番号)
- BIC_SWIFT
- Business Unit
- Name
- Address
- 請求日
- 請求書番号
- 合計
- Net Amount(正味合計金額)
- ベンダー

- Activity Editor ボタンをクリックして、プロンプトの設定を開始します
ステップ 4: ロール定義を作成する
- Activity Editor で Prompt Text インターフェースが表示されます
- ROLE セクションから作業を開始します:

- 具体的に書く: 「data extraction model」と指定して LLM に目的を伝える
- スコープを定義する: 「vendor-related fields」で抽出対象を限定する
- 期待を明示する: 「value text verbatim」と指定して再フォーマットを防ぐ
- 欠損データへの対応を指示する: 「明確に存在しない field は省略する」と伝える
- ロールは明確かつ簡潔にする
- 命令形を使う(「Extract」「Do not infer」など)
- してはいけないことを明示する
- 境界ケースの扱い方を定義する
ステップ 5: 出力形式を定義する
- ROLE セクションの下に OUTPUT FORMAT 見出しを追加します
- JSON 構造を定義します:

- FieldName: field 定義と完全に一致させる必要があります(例:
Vendor.Name) - Text: 抽出された値(string)
- Line: 値がドキュメント内に現れる行の 0 ベースの行インデックス
- Output 設定で使用している正確な field 名を使用してください
- 一部が空であっても、すべての field を含めてください
- 構造は有効な JSON でなければなりません
- 行番号は検証およびトラブルシューティングに役立ちます
ステップ 6: Field 固有の抽出ルールを追加する

- 認識パターン: 各 field の代替ラベルを列挙する
- フォーマット仕様: 抽出すべき正確な形式を記述する
- 位置のヒント: データが通常どこにあるかを示す
- 除外条件: 抽出してはいけないものを示す
- 分かりやすくするためにルールに番号を付ける
- 複数のラベルバリエーションを用意する
- データがどちら側のものか(ベンダー側か顧客側か)を明示する
- 括弧内にフォーマット例を含める
- 関連する field について明示する(例: 「IBAN を無視 — IBAN 用の専用 field がある」)
ステップ 7: 厳格ルールを適用する

- ハルシネーションを防ぐ: LLM はもっともらしく見えても誤ったデータを生成する可能性がある
- 一貫性を確保する: 明確なルールにより、実行ごとのばらつきを減らす
- 欠損データを処理する: field が見つからない場合にどうするかを定義する
- データの完全性を維持する: 原文どおりに抽出して元の書式を保持する
- ドキュメントに存在しないデータを決して生成しない
- 推測するのではなく、不確実な抽出結果は省略する
- field が見つからない場合は空の構造体を返す
- field 名は完全一致させる
- 元のテキストの書式を保持する
ステップ 8: 文書形式を選択する
- Activity Editor で Prompt ドロップダウンを見つけます
- 文書を LLM にどのような形式で渡すかのオプションが表示されます

-
PDF: 元の PDF ファイル
- 使用例: レイアウトが重要な文書
- 留意点: ファイルサイズが大きくなり、LLM によっては PDF サポートが限定的な場合があります
-
Plain Text: 書式なしのテキスト抽出
- 使用例: シンプルなテキストのみの文書
- 留意点: すべての書式およびレイアウト情報が失われます
-
Annotated Text ⭐(推奨)
- 使用例: ほとんどの文書タイプ
- 留意点: テキストベースでありながら構造を保持します
- 利点: 構造とパフォーマンスのバランスが最も優れています
-
Formatted Text: 基本的な書式が保持されたテキスト
- 使用例: 一部の書式が重要な文書
- 留意点: Plain Text と Annotated Text の中間的な選択肢です
- 最良の結果を得るために Annotated Text を選択します
ステップ 9: 抽出結果をテストする
アクティビティを実行する
- Activity Editor を閉じます
- All Documents タブに移動します
- テスト用ドキュメントを選択します
- Test Activity または Run ボタンをクリックします

- LLM によるドキュメントの処理が完了するまで待ちます
- 処理時間: 通常はドキュメントの複雑さに応じて 5~30 秒程度かかります
- API レスポンスを待っている間はローディングインジケーターが表示されます
結果を確認する
- インターフェースは Predictive view に切り替わります
- 抽出された field が表示される Output パネルを確認します
- 各 field をクリックして、次を確認します:
- 抽出された値
- 信頼度(提供されている場合)
- ドキュメント画像上でハイライトされた領域

- ✅ 想定されているすべての field が入力されていること
- ✅ 値がドキュメントと完全に一致していること
- ✅ ハルシネーション(AI による虚偽生成)や推測されたデータがないこと
- ✅ 複数行の field が正しく処理されていること
- ✅ 欠落している field が空のままであること(誤ったデータで埋められていないこと)
よくある結果パターン
ステップ 10: プロンプトをブラッシュアップする
よくある問題と解決策
- 解決策: より具体的な位置指定のヒントを追加する
- 例: “ベンダー側のみ。customer/buyer の住所は除外する”
- 解決策: 原文どおりに抽出することを強調する
- 例: “数値の書式を、印字されているとおり正確に抽出する(例: ‘12-34-56’)”
- 解決策: 厳格なルールを強化する
- 例: “値を生成したり推測したりしないこと。存在しない場合は省略すること。”
- 解決策: エスケープシーケンスを指定する
- 例: “複数行の値には、改行に
\nを使用する”
- 解決策: field 名が完全に一致していることを確認する
- 例:
AccountNumberではなくVendor.Account Numberを使用する
反復的な改善プロセス
- 複数のドキュメントでテストする: 単一の例だけに最適化しないようにする
- パターンを記録する: どのルールが機能し、どれが改善を要するかをメモする
- 具体例を追加する: 括弧内にフォーマット例を含める
- 厳格さを調整する: 抽出の過不足のパターンに基づいて調整する
- エッジケースをテストする: field が欠落しているドキュメントや、レイアウトが特殊なドキュメントを試す
改善例
抽出プロセスを理解する
プロンプトベース抽出の仕組み
- 文書変換: 文書が選択した形式(Annotated Text(推奨))に変換されます
- プロンプト組み立て: 役割、出力形式、field ルール、および厳格度ルールが統合されます
- API 呼び出し: プロンプトと文書が、設定した接続経由で LLM に送信されます
- LLM 処理: LLM が文書を読み、指示に従ってデータを抽出します
- JSON 応答: LLM が指定された JSON 形式で構造化データを返します
- Field マッピング: Vantage が JSON 応答を、定義済みの出力 fields にマッピングします
- 検証: 行番号と信頼度スコア(提供されている場合)が、結果の精度を検証するのに役立ちます
トークン使用量とコスト
- ドキュメントの長さ:ドキュメントが長いほど使用されるトークン数が増える
- プロンプトの複雑さ:詳細なプロンプトほどトークン数が増える
- 形式の選択:Annotated Text は一般的に PDF より効率的
- field の数:field が多いほどプロンプトが長くなる
- プロンプトでは簡潔かつ明確な表現を使う
- 指示を重複して記載しない
- 不要な例を削除する
- 関連するデータは field をまとめてグループ化することを検討する
ベストプラクティス
プロンプト作成
- ✅ 明確な命令形の文を使う(“Extract”、“Recognize”、“Omit” など)
- ✅ 各 field に対して複数のラベル候補を用意する
- ✅ 括弧内にフォーマット例を記載する
- ✅ 抽出してはいけないもの(除外条件)を明示する
- ✅ 参照しやすいようにルールに番号を振る
- ✅ プロンプト全体で一貫した用語を使用する
- ❌ あいまいな指示を使う(“get the name” など)
- ❌ LLM がドメイン固有の慣習を知っていると想定する
- ❌ 不必要に長く複雑な文を書く
- ❌ セクションごとに内容が矛盾する書き方をする
- ❌ 厳密さに関するルールを省略する
Field 定義
- 認識パターン(代替ラベル)をまず定義する
- 保持すべき正確な書式を指定する
- 配置の目安(典型的な配置場所)を示す
- データ所有者(ベンダー vs. 顧客)を定義する
- 複数行値の扱い方法を明記する
- 関連する field を参照して混同を防ぐ
テスト戦略
- シンプルなドキュメントから始める: まずは基本的な抽出をテストする
- バリエーションに広げる: 異なるレイアウトや形式を試す
- エッジケースをテストする: field が欠落している場合、通常と異なる位置、複数の一致がある場合など
- 失敗事例を記録する: 抽出が失敗した例を残しておく
- 体系的に反復する: 1 回に 1 つずつ変更する
パフォーマンス最適化
- プロンプトは簡潔に保つ
- Annotated Text 形式を使用する
- 1 アクティビティあたりの field 数を最小限にする
- 複雑なドキュメントは分割することを検討する
- field 用の網羅的なルールを定義する
- フォーマット例を含める
- 厳しめの制約ルールを追加する
- 多様なドキュメントサンプルでテストする
- プロンプトの長さを最適化する
- 効率的なドキュメント形式を使用する
- 適切な場合は結果をキャッシュする
- LLM プロバイダーのダッシュボードでトークン使用量を監視する
トラブルシューティング
抽出に関する問題
- field 名のスペルが完全に一致していることを確認する
- データが選択したドキュメント形式に含まれていることを確認する
- 認識パターンにラベルのバリエーションを追加する
- 一時的に厳格さを下げて、LLM が見つけられるか確認する
- ドキュメント品質が OCR/Text 抽出結果に影響していないか確認する
- ベンダーデータ側の仕様・条件をより厳密にする
- 顧客/購入者データを明示的に除外する
- 位置情報のヒントを与える(例: 「ドキュメントの上部」「発行者セクション」)
- 正しい抽出と誤った抽出の例を含める
- エスケープシーケンスの形式(
\n)を明示的に指定する - 正しい複数行出力の例を提示する
- ドキュメント形式が改行を保持していることを確認する
- 次の指示を追加する: 「元の改行を
\nを使って保持すること」
- 「verbatim」および「exactly as printed」を強調する
- 「正規化や推論を行わないこと」という厳格なルールを追加する
- 書式を保持する具体例を提示する
- 次の否定例を含める: 「『12-34-56』ではなく、『12 34 56』のまま保持する」
パフォーマンスの問題
- PDF を使用している場合は Annotated Text 形式に切り替える
- 重要な指示を失わない範囲でプロンプトを簡素化する
- 画像が非常に大きい場合はドキュメント解像度を下げる
- LLM プロバイダーのステータスとレート制限を確認する
- 単純なドキュメントにはより高速なモデルの使用を検討する
- 厳格なルール設定を強化する
- 指示をより具体的かつ曖昧さのないものにする
- フォーマット例を増やす
- 解釈の余地を生むようなプロンプトの複雑さを下げる
- (接続で利用可能な場合は)より高い temperature 設定でテストする
- プロンプトの長さを最適化する
- PDF の代わりに Annotated Text を使用する
- オフピーク時にドキュメントをバッチ処理する
- 単純なドキュメントにはより小さい/低コストのモデルの使用を検討する
- LLM プロバイダーのダッシュボードで予算アラートを監視・設定する
高度な手法
条件付き抽出
多言語サポート
バリデーションルール
Field 間の関係
制限事項と留意事項
現在の機能
- ✅ ヘッダーレベルの field 抽出
- ✅ 単一行および複数行の値
- ✅ 1 つのドキュメント内の複数の field
- ✅ 条件付き抽出ロジック
- ✅ 多言語ドキュメント
- ✅ レイアウトが可変なドキュメント
- ⚠️ テーブル抽出(実装によって異なる)
- ⚠️ 入れ子構造を含む複雑な構造
- ⚠️ 非常に大きなドキュメント(トークン上限)
- ⚠️ リアルタイム処理(API のレイテンシ)
- ⚠️ 完全に決定論的な結果の保証
プロンプトベース抽出を使用するタイミング
- レイアウトが一定でないドキュメント
- 半構造化されたドキュメント
- 迅速なプロトタイピングとテスト
- 小〜中規模のドキュメント処理量
- 学習用データが入手できない場合
- 多言語のドキュメント処理
- 大量処理が必要な本番環境(従来型の機械学習の方が高速な場合があります)
- 高度に構造化されたフォーム(テンプレートベース抽出)
- コスト重視のアプリケーション(従来手法の方が安価な場合があります)
- レイテンシ要件が厳しいアプリケーション(LLM API にはネットワーク遅延があります)
- オフライン処理要件がある場合(従来手法ではインターネット接続が不要)
Document Skill との統合
抽出データの使用
- Validation Activities: 抽出された値にビジネスルールを適用します
- Script Activities: 抽出されたデータを処理または変換します
- Export Activities: データを外部システムに送信します
- Review Interface: 抽出されたフィールドを手動で確認します
他のアクティビティとの組み合わせ
Field マッピング
"FieldName": "Vendor.Name"→ 出力 fieldVendor.Nameにマッピングされます- field の階層構造は出力構造内で保持されます
- 行番号は検証およびトラブルシューティングに役立ちます
まとめ
- ✅ プロンプトベースの抽出アクティビティを作成しました
- ✅ LLM 接続を構成しました
- ✅ 役割・形式・ルールを含む包括的な抽出プロンプトを作成しました
- ✅ 最適なドキュメント形式(Annotated Text)を選択しました
- ✅ データ品質向上のための厳格なルールを適用しました
- ✅ 抽出をテストし、結果を確認しました
- ✅ プロンプトエンジニアリングのベストプラクティスを学びました
- プロンプトベースの抽出では自然言語による指示を使用します
- Annotated Text 形式が最良の結果をもたらします
- 明確で具体的なプロンプトにより、一貫した抽出結果が得られます
- 厳格なルールにより、ハルシネーションを防ぎデータ品質を維持します
- 反復的なテストと改善により精度が向上します
次のステップ
- 多様なドキュメントでテストする: さまざまなレイアウトやバリエーションで検証します
- プロンプトを洗練させる: 結果に基づいて継続的に改善します
- コストを監視する: LLMプロバイダーのダッシュボードでトークン使用量を追跡します
- パフォーマンスを最適化する: プロンプトをチューニングして速度と精度を高めます
- テーブル抽出を試す: サポートされている場合は明細の抽出を試してみます
- ワークフローと統合する: 他のアクティビティと組み合わせてエンドツーエンドの処理を実現します
追加リソース
- ABBYY Vantage Advanced Designer ドキュメント: https://docs.abbyy.com
- LLM 接続設定ガイド: LLM 接続を構成する方法
- プロンプトエンジニアリングのベストプラクティス: 利用している LLM プロバイダーのドキュメントを参照してください
- サポート: 技術的なサポートが必要な場合は ABBYY サポートにお問い合わせください
