概要
- プロンプトベースの抽出アクティビティを作成する。
- LLM 接続を設定する。
- 効果的な抽出プロンプトを作成する。
- 出力形式と構造を定義する。
- 厳格度とバリデーションルールを適用する。
- 抽出結果をテストして改善する。
- 請求書からのベンダー情報の抽出
- ヘッダーレベルの文書データ抽出
- 半構造化文書の処理
- レイアウトが可変の文書
前提条件
- ABBYY Vantage Advanced Designer にアクセスできること。
- LLM 接続が設定されていること。詳しくは LLM 接続の Configure を参照してください。
- サンプルドキュメントがロードされた Document Skill。
- JSON 構造に関する基本的な理解。
- 抽出したいデータのフィールド定義。
このガイドでは、ヘッダーレベルの抽出に重点を置いています。テーブル抽出のサポート内容は異なる場合があります。
プロンプトベースの抽出について
プロンプトベースの抽出とは?
- Role: LLM にどのような役割を担わせるか (例: 「データ抽出モデル」) 。
- Instructions: データをどのように抽出し、整形するか。
- Output Structure: 結果の正確な JSON 形式。
- Rules: あいまいなデータや欠落データの扱いに関するガイドライン。
Step 1: プロンプトベースのアクティビティを追加する
- ABBYY Vantage Advanced Designer で Document Skill を開きます。
- 左側のパネルで、EXTRACT FROM TEXT (NLP) を探します。
- Prompt-based を見つけてクリックします。

- ワークフローキャンバスにアクティビティが表示されます。
- 入力アクティビティと出力アクティビティの間に接続します。
プロンプトベースのアクティビティは Activities パネルの「EXTRACT FROM TEXT (NLP)」にあり、固有表現 (NER) や Deep Learning など、ほかの抽出方法と並んでいます。
ステップ 2: LLM 接続を設定する
- ワークフロー内でプロンプトベースのアクティビティを選択します。
- 右側の Activity Properties パネルで、LLM 接続 を探します。
- ドロップダウンメニューをクリックします。

- 一覧から設定済みの LLM 接続を選択します。
- 例:
Nick-ChatGPT,Microsoft Foundry,Production GPT-4
- 例:
- 接続が選択されていることを確認します。
一覧に接続が表示されない場合は、まず Configuration → Connections から LLM 接続を設定する必要があります。
Skill を公開すると、ここで選択した接続が Vantage Web Portal でその Skill の デフォルト になります。Skill Catalog → [your skill] → Parameters では、その接続があらかじめ設定された状態で表示されます。テナント管理者は、Skill を再公開しなくても別の接続に切り替えられます (たとえば、環境ごとに本番用の Skill が別の LLM エンドポイントを参照するようにする場合) 。詳しくは、Document skill パラメーター を参照してください。
Step 3: Output field を定義する
- Activity Properties パネルで、Output セクションを探します。
- field グループとfieldの階層リストが表示されます。
- この例では、ベンダー情報を抽出します。
- ベンダー
- 名前
- 住所
- TaxID
- アカウント番号
- Sort Code
- IBAN (国際銀行口座番号)
- BIC_SWIFT
- ビジネス ユニット
- 名前
- 住所
- 請求日
- 請求書番号
- Totals
- Net Amount
- ベンダー

- Activity Editor ボタンをクリックして、プロンプトの設定を開始します。
プロンプトを記述する前に、すべてのfieldを定義してください。field名はプロンプトの構造内で参照されます。
ステップ 4: ロール定義を記述する
- Activity Editor に Prompt Text インターフェイスが表示されます
- ROLE セクションから始めます:

- 具体的にする: “data extraction model” とすることで、LLM にその目的を明確に伝えられます。
- 範囲を定義する: “vendor-related fields” とすることで、何を抽出するかを限定できます。
- 期待する動作を示す: “value text verbatim” とすることで、再整形を防げます。
- データ欠落時の扱いを決める: “Omit any field that is not clearly present”。
- 役割は明確かつ簡潔にします。
- 命令形の文を使います (“Extract”、“Do not infer”) 。
- してはいけないことも明示します。
- 境界ケースの扱い方を定義します。
Step 5: 出力形式を定義する
- ROLE セクションの下に、OUTPUT FORMAT 見出しを追加します。
- JSON構造を定義します。

- FieldName: field 定義と完全に一致している必要があります (例:
Vendor.Name) 。 - Text: 文字列として抽出された値。
- Line: ドキュメント内で値が現れる 0 ベースの行 index。
- Output の設定で使用している field 名を正確に指定してください。
- 一部が空の場合でも、すべての field を含めてください。
- 構造は有効な JSON である必要があります。
- 行番号は Verification や Troubleshooting に役立ちます。
Step 6: field ごとの抽出ルールを追加する

- 認識パターン: 各fieldについて、代替ラベルを列挙します。
- 形式仕様: 抽出対象の正確な形式を記述します。
- 位置のヒント: データが通常どこに記載されているかを示します。
- 除外: 抽出しないものを示します。
- 分かりやすくするため、ルールには番号を付けます。
- ラベルのバリエーションを複数記載します。
- データの帰属先 (ベンダー側か顧客側か) を明記します。
- 括弧内に形式の例を含めます。
- 関連するfieldは明確に示します (例: “IBAN は無視する — 専用のfieldがあります”) 。
ステップ 7: 厳格度ルールを適用する

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

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

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

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