4. ワークフローキャンバスにアクティビティが表示されます。
5. 入力アクティビティと出力アクティビティの間に接続します。
**構造コンポーネント:**
* **FieldName**: field 定義と完全に一致している必要があります (例: `Vendor.Name`) 。
* **Text**: 文字列として抽出された値。
* **Line**: ドキュメント内で値が現れる 0 ベースの行 index。
**重要な注意事項:**
* Output の設定で使用している field 名を正確に指定してください。
* 一部が空の場合でも、すべての field を含めてください。
* 構造は有効な JSON である必要があります。
* 行番号は Verification や Troubleshooting に役立ちます。
***
## Step 6: field ごとの抽出ルールを追加する
各 field の抽出について、詳細な指示を記述します。
OUTPUT FORMAT の下に、各 field タイプに対する具体的なルールを追加します。
```
VENDOR NAME
1) Recognize names like "ABC Corporation", "XYZ Ltd", "Acme Inc.".
2) Extract the complete company name including legal suffixes (Ltd, Inc, GmbH, etc.).
3) Vendor name typically appears near the top of the document.
VENDOR ADDRESS
1) Extract the complete address including street, city, postal code.
2) For multiline addresses, represent each new line using "\n".
3) Vendor-side only; exclude customer/buyer addresses.
ACCOUNT NUMBER
1) Recognize "Account Number", "Account No", "Acct #".
2) Extract the numeric format exactly as printed (e.g., "12-34-56" or "500 105 17").
3) Vendor-owned accounts only (e.g., "Beneficiary" or "Vendor Payment" sections).
4) Ignore IBAN — it has its own field.
SORT CODE
1) Recognize "Sort Code", "Sort No.", "BLZ", "Bankleitzahl".
2) Extract the numeric format exactly as printed (e.g., "12-34-56" or "500 105 17").
3) Vendor-side data only; ignore payer/buyer codes.
IBAN
1) Recognize "IBAN", "International Bank Account Number".
2) Extract the full IBAN exactly as printed (include spaces).
3) Vendor-side only, typically under "Bankverbindung", "Coordonnées bancaires", "Payment Details", or "Beneficiary Bank".
BIC_SWIFT
1) Recognize "BIC", "SWIFT", or "BIC/SWIFT".
2) Extract the complete identifier (usually 8 or 11 uppercase letters/numbers).
3) Vendor-side only, near the IBAN or bank name.
4) Exclude customer/payer data.
```
**ルールの構成:**
* **認識パターン**: 各fieldについて、代替ラベルを列挙します。
* **形式仕様**: 抽出対象の正確な形式を記述します。
* **位置のヒント**: データが通常どこに記載されているかを示します。
* **除外**: 抽出**しない**ものを示します。
**ベストプラクティス:**
* 分かりやすくするため、ルールには番号を付けます。
* ラベルのバリエーションを複数記載します。
* データの帰属先 (ベンダー側か顧客側か) を明記します。
* 括弧内に形式の例を含めます。
* 関連するfieldは明確に示します (例: "IBAN は無視する — 専用のfieldがあります") 。
***
## ステップ 7: 厳格度ルールを適用する
データ品質と一貫性を確保するため、バリデーションルールを追加します。
プロンプトの末尾に、**STRICTNESS** セクションを追加します:
```
STRICTNESS
- Never generate or infer values.
- Omit ambiguous or missing fields.
- If none of the vendor fields are found, return:
{
"Fields": []
}
```
**追加の厳格度ルール (任意) :**
```
GENERAL RULES
- field ごとに正確に1つの値を抽出すること。
- 確実に特定できない field は省略し、出力に含めないこと。
- "FieldName" は上記の名前と完全に一致させること。
- "Text" はドキュメントからそのまま転記すること（正規化や推測は行わない）。
- 複数行にわたる値（住所など）は、改行をエスケープシーケンス "\n"（バックスラッシュと文字 n）で表現すること。
- 出力テキストに などの HTML タグを挿入しないこと。 - "Line" は抽出した値を含む最初の行の 0 始まりのインデックスであり、検証可能な場合にのみ含めること。 ``` **厳格性が重要な理由:** * **ハルシネーションを防ぐ**: LLMはもっともらしく見えても、誤ったデータを生成することがあります。 * **一貫性を確保する**: 明確なルールによって、実行ごとの差異を抑えられます。 * **欠損データに対応する**: fieldが見つからない場合の扱いを定義します。 * **データの整合性を保つ**: 原文どおりに抽出することで、元の書式を維持できます。 **厳格性の基本原則:** * 文書内にないデータは決して生成しない。 * 不確かな抽出結果は推測せず、省略する。 * fieldが1つも見つからない場合は、空の構造を返す。 * field名は完全一致させる。 * 元のテキストの書式を保持する。 ***
## Step 8: 文書形式を選択
LLM に送信する文書表現を選択します。
1. Activity Editor で、**Prompt** ドロップダウンを見つけます。
2. 文書を LLM にどのような形式で渡すかのオプションが表示されます。
**利用可能な形式:**
* **PDF**: 元の PDF ファイル
* 使用対象: レイアウトが重要な文書
* 注意点: ファイルサイズが大きく、一部の LLM では PDF のサポートが限定的です
## ステップ 9: 抽出をテストする
結果を確認するには、サンプル文書に対してアクティビティを実行します。
### アクティビティを実行する
1. Activity Editorを閉じます。
2. **All Documents** タブに移動します。
3. テスト用のドキュメントを選択します。
4. **Test Activity** または **Run** ボタンをクリックします。
5. LLMによるドキュメントの処理が完了するまで待ちます
* 処理時間: 通常、ドキュメントの複雑さに応じて5～30秒です。
* APIレスポンスを待機している間、ロード インジケーターが表示されます。
### 結果を確認する
処理が完了したら:
1. インターフェイスが**Predictive view**に切り替わります。
2. 抽出されたフィールドが表示されている**Output**パネルを確認します。
3. 各fieldをクリックして、次の内容を確認します。
* 抽出された値
* 確信度 (提供されている場合)
* 文書画像上で強調表示された領域
**確認するポイント:**
* ✅ 想定されるすべてのfieldに値が入っている
* ✅ 値が文書と完全に一致している
* ✅ 幻覚や推測によるデータが含まれていない
* ✅ 複数行のfieldが適切に処理されている
* ✅ 欠落しているfieldは省略されている (誤ったデータで埋められていない)
### 一般的な結果のパターン
**抽出が成功した場合:**
```json theme={null}
{
"Fields": [
{ "FieldName": "Vendor.Name", "Text": "ABC Corporation Ltd", "Line": 3 },
{ "FieldName": "Vendor.Address", "Text": "123 Business Street\nLondon SW1A 1AA", "Line": 5 },
{ "FieldName": "Vendor.IBAN", "Text": "GB29 NWBK 6016 1331 9268 19", "Line": 15 }
]
}
```
**部分抽出 (一部のfieldが欠落している場合) :**
```json theme={null}
{
"Fields": [
{ "FieldName": "Vendor.Name", "Text": "ABC Corporation Ltd", "Line": 3 }
]
}
```
**field が見つかりません:**
```json theme={null}
{
"Fields": []
}
```
***
## Step 10: プロンプトを改善する
テスト結果に基づいて、プロンプトを調整します。
### よくある問題と解決策
**問題: LLMが誤ったfieldを抽出する**
* **解決策**: より具体的な位置のヒントを追加します。
* **例**: "ベンダー側のみ。顧客/購入者の住所は除外"
**問題: 書式が変わってしまう**
* **解決策**: 原文どおりに抽出するよう強調します。
* **例**: "印字された数値形式をそのまま正確に抽出すること (例: '12-34-56') "
**問題: LLMがデータを捏造する**
* **解決策**: 厳格度ルールを強化します。
* **例**: "値を生成したり推測したりしないこと。存在しない場合は省略すること。"
**問題: 複数行のfieldが連結される**
* **解決策**: エスケープシーケンスを指定します。
* **例**: "複数行の値では、改行に `\n` を使用する"
**問題: 出力内のfield名が正しくない**
* **解決策**: field名が完全に一致していることを確認します。
* **例**: `AccountNumber` ではなく `Vendor.Account Number` を使用
### 反復的な改善プロセス
1. **複数の文書でテストする**: 単一の例だけに最適化しないでください。
2. **文書のパターンを記録する**: どのルールが有効で、どれに改善が必要かを記録します。
3. **具体例を追加する**: 括弧内に書式の例を含めます。
4. **厳格度を調整する**: 過剰抽出または抽出不足のパターンに基づいて調整します。
5. **エッジケースをテストする**: フィールドが不足している文書や、通常と異なるレイアウトの文書を試します。
### 改善例
**変更前:**
```
VENDOR NAME
1) Extract the vendor name from the document.
```
**変更後：**
```
VENDOR NAME
1) Recognize names like "ABC Corporation", "XYZ Ltd", "Acme Inc.".
2) Extract the complete company name including legal suffixes (Ltd, Inc, GmbH, etc.).
3) Vendor name typically appears near the top of the document.
4) Exclude customer/buyer names - focus on the entity issuing the invoice.
```
***
## 抽出プロセスを理解する
### プロンプトベースの抽出の仕組み
1. **ドキュメント変換**: ドキュメントは、選択した形式に変換されます (推奨形式: Annotated Text) 。
2. **プロンプトの組み立て**: ロール、出力形式、field ルール、厳格度ルールが組み合わされます。
3. **API 呼び出し**: プロンプトとドキュメントが、接続を介して LLM に送信されます。
4. **LLM による処理**: LLM がドキュメントを読み取り、指示に従ってデータを抽出します。
5. **JSON レスポンス**: LLM は、指定された JSON 形式で構造化データを返します。
6. **フィールドマッピング**: Vantage が JSON レスポンスを、定義した出力フィールドにマッピングします。
7. **検証**: 行番号と信頼度スコア (提供されている場合) は、精度の確認に役立ちます。
### トークン使用量とコスト
**コストに影響する要因:**
* **文書の長さ**: 文書が長いほど、使用するトークン数も増えます。
* **プロンプトの複雑さ**: プロンプトが詳細になるほど、トークン数が増えます。
* **形式の選択**: Annotated Text は通常、PDF より効率的です。
* **フィールド数**: フィールドが多いほど、プロンプトも長くなります。
**最適化のヒント:**
* プロンプトには、簡潔かつ明確な表現を使います。
* 指示を重複させないでください。
* 不要な例は削除してください。
* 関連するデータは field グループ化を検討してください。
***
## ベストプラクティス
### プロンプトの書き方
**推奨事項:**
* ✅ 明確な命令形 (「Extract」「Recognize」「Omit」) を使います。
* ✅ 各fieldについて、複数のラベルのバリエーションを示します。
* ✅ 括弧内に形式の例を含めます。
* ✅ 抽出しないもの (除外対象) を明記します。
* ✅ 参照しやすいようにルールに番号を付けます。
* ✅ 全体を通して用語を統一します。
**避けること:**
* ❌ 曖昧な指示 (「名前を取得する」など) は使わないでください。
* ❌ LLMが業務領域固有の慣習を理解していると決めつけないでください。
* ❌ 長すぎたり複雑すぎたりする文は書かないでください。
* ❌ セクションごとに内容が矛盾しないようにしてください。
* ❌ 厳格度ルールを省略しないでください。
### field の定義
**効果的な field の指示:**
* 認識パターン (代替ラベル) をまず指定します。
* 保持すべき正確な形式を指定します。
* 位置のヒント (一般的な配置場所) を示します。
* データの帰属 (ベンダーか顧客か) を定義します。
* 複数行の値の扱いを含めます。
* 混同を避けるため、関連する fields を参照します。
**例:**
```
IBAN
1) Recognize "IBAN", "International Bank Account Number".
2) Extract the full IBAN exactly as printed (include spaces).
3) Vendor-side only, typically under "Bankverbindung", "Payment Details".
4) Do NOT confuse with Account Number — IBAN is longer and alphanumeric.
```
### テスト戦略
1. **シンプルな文書から始める**: まずは基本的な抽出をテストします。
2. **バリエーションを広げる**: 異なるレイアウトや形式を試します。
3. **エッジケースをテストする**: フィールドの欠落、通常と異なる位置、複数一致などを確認します。
4. **失敗例を記録する**: 抽出に失敗したケースの例を残します。
5. **体系的に繰り返す**: 一度に変更するのは1つだけにします。
### パフォーマンスの最適化
**速度を重視する場合:**
* プロンプトは簡潔にします。
* Annotated Text形式を使用します。
* アクティビティごとのフィールド数は最小限に抑えます。
* 複雑な文書は分割することも検討します。
**精度を重視する場合:**
* フィールドルールはできるだけ詳細に設定します。
* 形式の例を含めます。
* 明確な厳格度ルールを追加します。
* 多様な文書サンプルでテストします。
**コストを重視する場合:**
* プロンプトの長さを最適化します。
* 効率的な文書形式を使用します。
* 必要に応じて結果をキャッシュします。
* LLM providerのダッシュボードでトークン使用量を監視します。
***
## トラブルシューティング
### 抽出に関する問題
**問題:** データが存在するのに field が空です。
**解決策:**
* field name のスペルが完全に一致しているか確認します。
* データが選択した文書形式に含まれていることを確認します。
* 認識パターンにラベルのバリエーションをさらに追加します。
* 一時的に 厳格度 を下げて、LLM が見つけられるか確認します。
* 文書品質が OCR/テキスト抽出に影響していないか確認します。
**問題:** LLM がベンダーのデータではなく顧客のデータを抽出します。
**解決策:**
* ベンダー側の指定内容をより明確にします。
* 顧客/購入者データに対する明示的な除外条件を追加します。
* 位置のヒント (例: 「文書の上部」、「発行者欄」) を指定します。
* 正しい抽出例と誤った抽出例の両方を含めます。
**問題:** 複数行の値が連結されたり、形式が崩れたりします。
**解決策:**
* エスケープシーケンスの形式 (`\n`) を明示的に指定します。
* 正しい複数行出力の例を示します。
* 文書形式で改行が保持されることを確認します。
* 「元の改行を `\n` を使って保持する」という指示を追加します。
**問題:** LLM がデータを再整形または正規化します。
**解決策:**
* 「verbatim」と「印字どおり正確に」を強調します。
* 厳格度 rule として「正規化や推測を行わない」を追加します。
* 書式が保持されることを示す具体例を示します。
* 否定例を含めます: 「'12-34-56' ではなく、'12 34 56' のままにする」。
### パフォーマンスの問題
**問題:** 抽出速度が遅すぎます。
**解決策:**
* PDF を使用している場合は、Annotated Text 形式に切り替えます。
* 重要な指示を損なわない範囲で、プロンプトを簡潔にします。
* 画像が非常に大きい場合は、ドキュメントの解像度を下げます。
* LLMプロバイダーのステータスとレート制限を確認します。
* 単純なドキュメントでは、より高速なモデルの使用を検討します。
**問題:** 実行するたびに結果が一致しません。
**解決策:**
* 厳格度ルールを強化します。
* 指示をより具体的で曖昧さのないものにします。
* 書式の例をさらに追加します。
* 解釈の余地を生む可能性があるプロンプトの複雑さを下げます。
* より高い温度設定でテストします (接続で利用可能な場合) 。
**問題:** API コストが高すぎます。
**解決策:**
* プロンプトの長さを最適化します。
* PDF の代わりに Annotated Text を使用します。
* オフピーク時にドキュメントをバッチ処理します。
* 単純なドキュメントでは、より小規模で低コストのモデルの使用を検討します。
* LLMプロバイダーのダッシュボードで予算アラートを設定し、監視します。
***
## 応用テクニック
### 条件付き抽出
条件が満たされた場合にのみ特定のfieldを抽出するよう、LLMに指示できます。
```
ACCOUNT NUMBER (CONDITIONAL)
1) Only extract if the document contains bank payment details.
2) If "Payment Method: Check" or similar appears, omit this field.
3) Recognize "Account Number", "Account No", "Acct #".
```
### 多言語対応
プロンプトベースの抽出は、多言語のドキュメントに対しても効果的です。
```
VENDOR NAME (MULTI-LANGUAGE)
1) Recognize in English: "Vendor Name", "Supplier", "Seller"
2) Recognize in German: "Verkäufer", "Lieferant", "Anbieter"
3) Recognize in French: "Fournisseur", "Vendeur"
4) Extract the complete company name regardless of language.
```
### バリデーションルール
プロンプトにバリデーションロジックを追加します。
```
IBAN (WITH VALIDATION)
1) Extract the full IBAN exactly as printed.
2) Verify it starts with a 2-letter country code.
3) If format doesn't match IBAN pattern, omit the field.
4) Do not invent check digits or country codes.
```
### field間のリレーション
field同士のリレーションを指定します。
```
ACCOUNT NUMBER vs IBAN
- Account Number: Usually shorter, numeric, domestic format.
- IBAN: Alphanumeric, starts with country code (e.g., "GB29 NWBK...").
- If both are present, extract both to separate fields.
- If only one is present, extract to the appropriate field.
- Do not duplicate the same value in both fields.
```
***
## 制限事項と留意点
### 現在の機能
**サポート対象:**
* ✅ ヘッダーレベルのフィールド抽出
* ✅ 単一行および複数行の値
* ✅ 1つの文書内の複数のフィールド
* ✅ 条件付きの抽出ロジック
* ✅ 多言語の文書
* ✅ さまざまな文書レイアウト
**制限あり、または未対応:**
* ⚠️ テーブル抽出 (実装によって異なります)
* ⚠️ 入れ子の複雑な構造
* ⚠️ 非常に大きな文書 (トークン数の制限)
* ⚠️ リアルタイム処理 (APIレイテンシ)
* ⚠️ 結果の決定性保証
### プロンプトベースの抽出を使用する場合
プロンプトベースの抽出が適しているケースと、従来の抽出を選ぶべきケースについては、[LLM を使用する場合](/ja/vantage/documentation/llms/llms#when-to-use-llms)を参照してください。
***
## Document Skills との連携
### 抽出されたデータの使用
抽出が完了すると、フィールドデータを Document Skill 全体で利用できます。
1. **Validation Activities**: 抽出された値に業務ルールを適用します。
2. **Script Activities**: 抽出されたデータを処理または変換します。
3. **Export Activities**: データを外部システムに送信します。
4. **Review Interface**: 抽出されたフィールドを手動で検証します。
### 他のアクティビティとの併用
プロンプトベースの抽出は、他のアクティビティと併用できます。
```
ワークフロー例：
1. Classification（文書タイプの識別）
2. OCR（テキストの抽出）
3. プロンプトベースの抽出（構造化データの抽出）
4. バリデーションルール（データ品質の検証）
5. Script（エクスポート用に整形）
6. Output（結果の出力）
```
### Field Mapping
抽出されたJSONのfieldは、自動的に定義したOutput fieldにマッピングされます。
* `"FieldName": "Vendor.Name"` → Output field `Vendor.Name` にマッピングされます。
* fieldの階層は出力構造内で保持されます。
* 行番号は、Verificationやトラブルシューティングに役立ちます。
***
## まとめ
以下の作業が完了しました。
* ✅ プロンプトベースの抽出アクティビティを作成しました。
* ✅ LLM 接続を設定しました。
* ✅ 役割、形式、ルールを含む包括的な抽出プロンプトを作成しました。
* ✅ 最適な文書形式 (Annotated Text) を選択しました。
* ✅ データ品質を確保するために厳格度ルールを適用しました。
* ✅ 抽出をテストし、結果を確認しました。
* ✅ プロンプトエンジニアリングのベストプラクティスを学びました。
**主なポイント:**
* プロンプトベースの抽出では、自然言語の指示を使用します。
* Annotated Text 形式は最も良い結果をもたらします。
* 明確で具体的なプロンプトほど、一貫した抽出結果が得られます。
* 厳格度ルールはハルシネーションを防ぎ、データ品質を維持します。
* 繰り返しテストと改善を行うことで精度が向上します。
これで、プロンプトベースの抽出アクティビティを文書処理に使用する準備が整いました。
***
## 次のステップ
1. **さまざまな文書でテストする**: 異なるレイアウトやバリエーションで検証します。
2. **プロンプトを改善する**: 結果に基づいて継続的に改善します。
3. **コストを監視する**: LLM プロバイダーのダッシュボードでトークンの使用量を追跡します。
4. **パフォーマンスを最適化する**: 速度と精度を高めるためにプロンプトを調整します。
5. **テーブル抽出を試す**: 明細の抽出を試します (サポートされている場合) 。
6. **ワークフローと統合する**: 他のアクティビティと組み合わせて処理全体を構成します。
***
## 追加リソース
* **ABBYY Vantage Advanced Designer ドキュメント:** [https://docs.abbyy.com](https://docs.abbyy.com)
* **LLM 接続設定ガイド:** [LLM 接続をConfigureする](/ja/vantage/documentation/skills/connections).
* **プロンプトエンジニアリングのベストプラクティス:** ご利用の LLM プロバイダーのドキュメントを参照してください。
* **サポート:** 技術的なサポートが必要な場合は、ABBYY サポートにお問い合わせください。
***
## よくある質問
**Q: プロンプトベースの抽出と従来型の抽出の違いは何ですか？** A: プロンプトベースでは、学習データを使わず、LLM に自然言語で指示を与えます。従来の方法では学習用のサンプルが必要ですが、大規模処理ではより高速でコスト効率に優れています。
**Q: プロンプトベースの activities でテーブルを抽出できますか？** A: ヘッダーレベルの抽出は十分にサポートされています。テーブル抽出の対応状況はケースによって異なり、特定のプロンプト構造が必要になる場合があります。
**Q: PDF ではなく Annotated Text を使うのはなぜですか？** A: Annotated Text は、構造保持と処理効率のバランスに最も優れています。テストでも、最も信頼性が高いことが確認されています。
**Q: API コストを削減するにはどうすればよいですか？** A: プロンプトの長さを最適化し、Annotated Text 形式を使用し、効率よく処理し、LLM provider のダッシュボードでトークン使用量を監視してください。
**Q: LLM 接続が失敗した場合はどうすればよいですか？** A: Configuration → Connections で接続のステータスを確認してください。接続を Test し、認証情報を確認し、API のクォータを超過していないことを確認してください。
**Q: 1 つの Skill で複数の LLM 接続を使用できますか？** A: はい。異なる activities で異なる接続を使用できます。これにより、抽出タスクごとに異なるモデルを使い分けられます。
**Q: 複数の言語の文書はどのように扱えばよいですか？** A: field ルールに多言語のラベルバリエーションを追加してください。LLM は一般に多言語コンテンツを適切に処理できます。
**Q: 文書の最大サイズはどれくらいですか？** A: これは LLM provider のトークン上限によって異なります。非常に長い文書は、分割するか、セクションごとに処理する必要がある場合があります。