ドキュメントを大量に扱う米国の専門家500人を対象に私たちが実施した調査では、88%が分析やAIシステムに入力されるデータの正確性に自信を持っていると回答しました。その一方で、同じ88%が、ドキュメント由来のデータにエラーを見つけることが少なくとも時々あると報告しています。この2つの数字は同時に真実であり、この矛盾こそがAIエージェントのための構造化データの必要性を物語っています。
これは単なる丸め誤差の話ではありません。現在の多くのチームの現状、つまり「自信を持っているが、問題になるほどの頻度で間違っている」という状況を表しています。あなたのAIエージェントはそのデータの下流に直接配置されていますが、「ちょっと待って、この合計金額はおかしい」と気づいてくれるエージェントは存在しません。
そのため、処理が停止したり、間違ったベンダーに支払いをしたり、間違った証券番号に対して請求を行ったりすると、直感的にモデルのせいにして、より優れたモデルを探し求めてしまいます。しかし、大抵の場合モデルは正常です。欠けていたのは、その前段階、つまり届いたドキュメントを「誰かが実際に確認した名前付きフィールド」に変換するステップなのです。
開発者は不要です。それでは、その6つの段階をご紹介します。
重要なポイント
- AIエージェントのための構造化データとは、予測可能なデータ型を持つ名前付きフィールドのことであり、実行時にエージェントが解釈しなければならないドキュメントそのものではありません。
- エージェントがドキュメント処理に失敗する原因は、スキャン画像に対するOCRレイヤーの欠如、送信者ごとのレイアウトのズレ、必須フィールドの警告なき欠落、そして照合するための信頼度シグナルの欠如の4点です。
- Gartnerは、2027年末までにエージェンティックAIプロジェクトの40%以上が中止されると予測しています。また別の予測では、AI対応データによってサポートされていないAIプロジェクトの60%が2026年までに放棄されるとしています。どちらの失敗も、モデルの上流から始まっています。
- パイプラインは、キャプチャ、分類、スキーマ、抽出、検証、配信の6つの段階で構成されます。検証をスキップすると、デモがインシデントに変わってしまいます。
- 信頼度に基づくゲート機能（ゲーティング）は、単に監視するだけのエージェントと、信頼できるエージェントの違いを生み出します。不確実な少数のみを手動でレビューしているチームは、最大5倍の速度で処理しながら99.9%の精度を達成しています。
- これらに開発者は一切不要です。n8n、Make、Zapierがオーケストレーションを実行し、抽出レイヤーが最も困難な部分を担います。
AIエージェントのための構造化データが実際に意味するもの
AIエージェントのための構造化データとは、予測可能なデータ型と既知の単位を持つ名前付きフィールドに変換されたドキュメントコンテンツを指します。これにより、エージェントは解釈が必要なPDFではなく、invoice_number、due_date、total、line_itemsを受け取ります。エージェントは値を読み取ります。ドキュメントを読むわけではありません。
実際には、以下のように非常にコンパクトです：
{
"invoice_number": "INV-4821",
"supplier": "Northwind Supplies",
"due_date": "2026-08-14",
"currency": "USD",
"total": 1340.0,
"source_document": "https://files.example.com/inv-4821.pdf"
}
3ページのPDFと「合計金額を見つけて」というプロンプトに対して、ワークフローで分岐できる6行のデータです。すべてのフィールドには、名前、型、そして抽出元のページに戻る方法が備わっています。
些細な技術論に聞こえるかもしれません。しかしこれは、デモで動いたエージェントと、11月になっても動き続けるエージェントの違いなのです。同じ請求書を2回渡されたモデルは、2回ともわずかに異なる答えを返すことがあります。チャット画面での単発のやり取りなら愛嬌で済みますが、午前3時に実行されるループ処理では大惨事になります。検証済みのJSONオブジェクトを渡されたモデルは、毎回同じように動作します。解釈の余地が残されていないからです。
これが人々を悩ませ続ける理由は、元のデータが機械向けに作られていないからです。企業データの80〜90%は非構造化データ（メール、PDF、スキャン、添付ファイル、フォームなど）であり、すべて人間が見るために作られています。ほとんどのチームはそのギャップを埋められていません。請求書処理に関するある調査では、34%の企業が依然としてデータを手動で処理しており、すべてを自動的にキャプチャしているのはわずか17%にすぎません。
人間向けの形式の生データ。機械向けの形式を期待するエージェント。組織図の誰もその変換に責任を持っていません。このギャップに関する詳細な議論についてはエージェンティックAIの欠落したレイヤーを、一般的なケースについては非構造化データを構造化データに変換するをご覧ください。この記事では、エージェント向けの内容に絞って解説します。
AIエージェントがドキュメント処理に失敗する理由
ドキュメントに関するAIエージェントのハルシネーションのほとんどは、4つの原因のいずれかに起因します。4つの原因と、4つの異なる解決策があります。
スキャン画像に対するOCRレイヤーの欠如。 スキャンデータは言葉の写真であり、言葉のデータそのものではありません。テキストレイヤーのない画像を与えられたモデルは、きれいに読める部分は読み取り、残りは自信満々に推測で補います。しかも、どの部分が推測だったかは決して教えてくれません。
送信者ごとのレイアウトのズレ。 40社のサプライヤー、40種類の請求書デザインがあり、3月にテストした3社に合わせて構築されたパイプラインがあるとします。12社目のサプライヤーが合計金額を別の枠に移動しても、エラーは発生しません。抽出処理は静かに間違ったセルの値を返し始めます。
必須フィールドの警告なき欠落。 ドキュメントに発注書（PO）番号がないため、フィールドが空になって返され、エージェントはそのまま処理を進めます。何も壊れているようには見えません。問題が表面化するのは2週間後、誰もやりたがらない照合の時です。
信頼度シグナルの欠如。 出力結果の中に「この合計金額には60%の自信がある」と示すものが何もないため、でっち上げられた値も含めて、すべての値が同じように信頼されてしまいます。
これを間違えることの代償は理論上の話ではありません。調査回答者の7割近くがエラーを時々、または頻繁に、あるいは非常に頻繁に見つけると報告しており、ドキュメントデータの不良はインシデントではなく通常の運用状態になっていることを示しています。買掛金部門に限定すると、支払いエラー率はサプライヤーへの総支払額の0.1%〜0.4%に上ります。小さな割合ですが、分母が巨大です。2,000万ドルのサプライヤー支出をこの範囲で実行すると、年間2万〜8万ドルが意図しない場所に流れることになります。
Gartnerも別の角度から同じ結論に達しています。組織の63%がAIに適したデータ管理手法を導入していない、または導入しているか不明であると回答しています。これは、ほとんどのエージェントプロジェクトが、誰も点検していない土台の上に立っていると丁寧に言っているようなものです。OCRの部分で苦労している場合は、AI OCRが失敗する理由で詳しく掘り下げています。
PDFをモデルに直接送信してもうまくいかなくなる理由
生のファイルをGPT、Claude、Geminiに直接送信するアプローチは、ある日突然機能しなくなるまで問題なく動いているように見えます。この「機能している状態」と「破綻する状態」の境界線は、人間が出力結果をレビューしているかどうかにあります。
精度の数値がその理由を説明しています。きれいなテキストPDFの場合、フィールド抽出は96〜98%前後に落ち着きます。スキャンされたドキュメントでは、同じモデルでもおよそ90〜94%に低下します。そのギャップ自体は問題ではありません。問題は、どちらの場合でも応答がまったく同じに見えることです。フラグも、警告も、このドキュメントが難しいタイプのものであったというヒントもありません。
チャットウィンドウであれば、請求書に$13.40と書いてあるのに合計が$1,340と読み取られれば気づくため、致命傷にはなりません。しかし、無人のループ処理では誰も気づく人がおらず、間違った数字がそのまま次の工程に進んでしまいます。
その根底には設計上のポイントが隠されており、これは単一モデルによるドキュメント処理が死んだ理由で詳しく論じました。1回のモデル呼び出しはパイプラインではありません。パイプラインには複数の段階があり、各段階で確認を行うことができます。単一のモデル呼び出しは、あなたが信じると決めた単なるコイントスに過ぎないのです。
ドキュメントからエージェントへのパイプライン、6つの段階
AIエージェントのためのドキュメント解析は1つのステップではなく、6つのステップです。私たちがこれまでに見てきた信頼性の高いセットアップはすべて、ホワイトボード上でそのように設計されたものであれ、散々な月日を過ごした後にそこに辿り着いたものであれ、この6つのステップすべてを実行しています。
1. ドキュメントをキャプチャし、原本を保管する
共有の受信トレイ、DriveやSharePointのフォルダ、フォームのアップロード、SFTPへのドロップ、ヘルプデスクチケットの添付ファイルなど、ドキュメントが実際に届く場所を監視します。元のファイルは、手を加える前に安定した場所に保存してください。
原本を保管するのは単なる整理整頓ではありません。半年後に「この数字はどこから来たのか」という質問に答えるためであり、監査人が最初に求めるものでもあるからです。
2. 抽出する前に分類する
どのフィールドを抽出するかを決める前に、ドキュメントの種類（請求書、発注書、契約書、納品書、銀行取引明細書、履歴書、または不明）を特定します。
これは見た目以上に重要です。請求書と発注書はフィールド名が共通していますが、意味は異なるからです。これらを統合してしまうと、すべての検証チェックを通過しながらも、密かに間違っているレコードが作成されてしまいます。また、リスクが集中する部分でもあります。調査の回答者は、請求書（21%）、発注書（18%）、顧客向けドキュメント（17%）を、最もエラーが発生しやすい種類として挙げています。
「不明」に分類されたものは、推測に任せるのではなく、人間による確認に回します。
3. ドキュメントの種類ごとに1つのスキーマを定義する
スキーマは、ドキュメントとエージェントの間の契約です。各フィールドに名前を付け、型を与え、どれが必須であるかをマークします。
位置ではなく意味でフィールドを定義します。そうすれば、ページ上のどこにあっても、total_amountは請求書の合計金額になります。最新のAI抽出は、テンプレートを設定することなく、これまで遭遇したことのないレイアウトを読み取るため、1つのスキーマで40社のサプライヤーをカバーできます。送信者ごとにスキーマを構築したくなる衝動を抑えてください。その道に終わりはありません。
下流のシステムが機能するために不可欠なフィールドをマークします。これらが第5段階でのハードストップ（処理の強制停止）の基準となります。
4. 単なるモデル呼び出しではなく、専用のレイヤーで抽出する
ここで精度が決まります。適切に行われた場合、AIエージェントのデータ抽出はプロンプトではなくサービスとなります。その違いは数値に表れます。OCRのみのシステムは85〜95%の精度で、一貫性のないレイアウトに苦戦しますが、AIと機械学習による抽出は約99%に達し、テンプレートを再構築することなく新しいレイアウトに適応します。
単純なモデル呼び出しでは得られず、専用レイヤーが提供するもの：スキャンのためのOCR、表や明細の抽出、スキーマに対する正規化と検証、抽出元のソースへのページ参照、再試行の処理、オプションの人間によるレビュー手順、そして過去のレコードを壊すことなく変更できるバージョン管理されたスキーマ。一部のレイヤーでは、フィールドごとの信頼度スコアを追加しています。これはあると便利ですが、ゲート全体をこれに依存して構築すべきではありません。
2026年の本番パイプラインのほとんどは、1つの手法を選ぶのではなく、アプローチを組み合わせています。可能なドキュメントには安価な決定論的抽出を使用し、そうでないドキュメントにはモデルベースの抽出を使用します。このトピックのより深い内容については、エージェンティックなドキュメント抽出をご覧ください。
5. エージェントに到達する前に検証し、ゲートを設ける
抽出されたレコードをスキーマと照合します。必須フィールドが存在するか、型が正しいか、合計が合っているか、日付が解析可能か、値がもっともらしい範囲内に収まっているかを確認します。その後、信頼度のルールを適用します。
合格したレコードはエージェントへ、不合格のレコードは人間へ送られます。この2つ目の経路を行き止まりではなく迂回路として構築することで、誰かが承認すれば、レビューされたレコードが同じワークフローに再合流し、1つの厄介なドキュメントが後続のキューを滞らせることがなくなります。
この単一の分岐が安全メカニズムのすべてであり、以下のセクションで個別に解説します。ここはチームが最もよくスキップし、最もよく後悔する部分だからです。
6. クリーンなレコードをエージェントに配信する
検証済みのオブジェクトを、エージェントが作業を引き受ける場所（自動化プラットフォームへのWebhook、データベースの行、CRMやERPのレコードなど）にプッシュします。エージェントは完成したオブジェクトを受け取るだけで、ドキュメントそのものを見ることはありません。
データが実際にエージェントに到達する仕組み
以下の4つのメカニズムで、あなたが構築するAIエージェント連携のほぼすべてをカバーできます。これらは競合するものではありません。それぞれが、タイミングと所有権に関する異なる課題を解決します。
| メカニズム | 仕組み | 利用シーン | 注意点 |
|---|---|---|---|
| Webhook | 抽出ツールは、レコードの準備ができた瞬間にプッシュします | ドキュメントが継続的に届き、エージェントに迅速に対応させたい場合 | 再試行処理と、配信に失敗した場合の保存先が必要です |
| REST APIのプル | ワークフローがスケジュールに従ってレコードを要求します | バッチ処理、または受信側システムがインバウンド呼び出しを受け入れられない場合 | 遅延が追加され、ポーリングのロジックを管理する必要があります |
| 共有データベース | レコードがテーブルに保存され、エージェントがそこから読み取ります | 複数のエージェントやシステムが同じデータを必要とし、履歴を残したい場合 | 誰かがスキーマの変更とクリーンアップを管理する必要があります |
| ツール呼び出し | エージェントが実行時に（多くの場合MCP経由で）ドキュメントデータを要求します | タスクの実行中に、エージェントがどのドキュメントを必要とするかを決定する場合 | デバッグが最も困難であり、実際のドキュメントワークフローで必要になることは稀です |
Model Context Protocol（MCP）は非常に大きな注目を集めているため、最後の行には注釈を添えるべきでしょう。MCPは、データソースを呼び出し可能なツールとしてエージェントに公開するための、実用的で有用な方法です。ただし、ドキュメントの処理には必ずしも適していません。ドキュメントは独自のスケジュールで届き、必要なフィールドはあらかじめわかっているからです。構造化データをワークフローにプッシュするWebhookの方が、構築もデバッグも簡単で、同じ役割を果たします。
この4つの行すべてに隠されている真実があります。それは、AIエージェントのための特別なAPIは存在しないということです。あるのは、エージェントがアクションを実行できるフィールドを配信する、シンプルなAPIだけです。Parseurは、最初の3つのいずれかを通じて抽出されたデータを送信します。送信先の完全なリストは、エクスポートと連携のページに記載されています。
誰も見ていない間にエージェントが間違った数字で行動しないことを確認する方法
それは、エージェントが処理してよい条件を事前に決定し、それ以外のものはすべて人間の確認に回すように（ゲートを）設定したからです。
これが正直な答えです。どんなに抽出精度が高くても、時には間違いがあり、その間違いは均等に分散しているわけではないため、精度の数字だけでこの不安は消えません。不安を取り除くのは、あなたが意図的に設計したゲートです。
ゲートとは、レコードがエージェントに到達する前にチェックされる、いくつかの小さなルールの集合です：
- いずれかのフィールドで信頼度がしきい値を下回った場合、レビューに回す。これは抽出レイヤーがフィールドごとの信頼度を公開しているかどうかに依存しますが、公開していないツールも多いため、このリストの残りの項目が重要になります。
- 必須フィールドが欠落している場合、レコードを不合格にする。空の文字列を値であるかのように前に進めてはいけません。
- 値が承認限度額を超えている場合、信頼度に関係なく人間の承認を必須とする。完璧に抽出された8万ドルの請求書でも、人が確認すべきです。
- ベンダー、送信者、またはドキュメントの種類が新規の場合、パターンが確立されるまで最初のいくつかをレビューする。
- 分類が「不明」を返した場合、スキーマを推測するのではなく、トリアージ（振り分け）に回す。
- 合計金額が明細と一致しない場合、不合格にする。計算チェックは、最も安価な嘘発見器です。
しきい値自体についてですが、普遍的な数字は存在しません。普遍的な数字を提示する人がいたら、その人はあなたのドキュメントを見ていません。自社の本番ファイルのサンプルを使って調整し、通過してしまうエラーが下流のシステムで吸収できるレベルに設定してください。支払い処理に送られる請求書と、ダッシュボードに送られる納品書が同じ基準であるべきではありません。
その効果は測定可能です。このパターンを実行し、確実な大部分をAIで処理し、不確実な残りを人間がレビューするチームは、最大5倍の速度で処理しながら99.9%の精度を達成しています。保険金の自動請求を行っている北欧のある保険会社では、ドキュメントの約70%を完全に自動処理し、人間は複雑なケースに集中しています。また、買掛金部門では、優秀な企業と平均的な企業との差がまさにここに表れています。トップクラスの企業は例外率が9%であるのに対し、それ以外の企業は22%に上ります。
これらの数字が何を示しているかに注目してください。決して難しいドキュメントに遭遇しないエージェントではなく、どのドキュメントが難しいかを知っているエージェントのことです。このレビュー手順を設計する実践的な方法については、Human-in-the-loop AI、HITLのベストプラクティス、およびデータ検証のガイドをご覧ください。
コードを書かずにAIエージェントのワークフローを構築する
これらに開発者は一切不要です。「パイプライン」と聞いて、エンジニアの工数を4分の1ほど費やすことを想像する人にとっては驚きでしょう。
役割分担はシンプルです。抽出レイヤーが、ドキュメントの読み取り、スキーマの適用、フィールドの正規化と検証といった最も困難な部分を担います。自動化プラットフォームが、新しいドキュメントのトリガー、抽出ツールの呼び出し、結果の受信、ルールのチェック、例外のルーティング、そして完成したオブジェクトのエージェントへの引き渡しといったオーケストレーションを行います。この分業こそが、本番環境を生き残ったAIエージェントのワークフローの姿です。
n8nの場合、全体は4つのノードで構成されます。抽出されたレコードを受信するWebhookトリガー、ルールをチェックするIFノード、エージェントへの分岐、人間への分岐です。前述のゲートに関するすべてはこのIFノードの中に収まります。そして、最も多くをキャッチするルールは、必須フィールドの欠落や明細と一致しない合計金額といった単純なものです。
n8nは、分岐ロジック、エラー処理、セルフホスティングを求めるチームに適しており、現在最も多くエージェント構築が行われている場所です。Makeは、コードに似たものに一切触れずに視覚的なマルチステップフローを構築するのに最も適しています。Zapierは、フローがほぼ直線的であれば、その日の午後には稼働させることができます。このトレードオフについては、n8n vs Zapier vs Makeの比較で詳しく解説しています。
これらのプラットフォームが単独でうまくこなせないのは、スキャンしたPDFの読み取りです。組み込みのファイルノードは、クリーンなテキストベースのドキュメントを処理してそこで止まってしまいます。それこそが抽出レイヤーが埋めるギャップであり、だからこそ、これら2つの要素は競合するのではなく、組み合わせて使うべきものなのです。
抽出レイヤー、RAG、それともLLM単体：どれが必要か？
これら3つは、それぞれ異なる問題を解決するものですが、しばしば代替案として議論されます。
| アプローチ | 得意なこと | 利用シーン | 弱点 |
|---|---|---|---|
| 抽出レイヤー | 特定の種類のすべてのドキュメントから、同じ名前のフィールドを抽出すること | 必要なフィールドがわかっており、エージェントやシステムがそれに基づいて行動する場合 | ドキュメントの意味に関する自由回答形式の質問には向いていない |
| RAG | テキスト全体に対する自由回答形式の質問に答えること | 「基本契約書には契約解除について何と書かれていますか？」のような場合 | 検証が難しく、検索の品質がすべてを左右する |
| LLM呼び出し単体 | プロトタイプ、単発の処理、本当に珍しい種類のドキュメント | 探索段階であり、人間がすべての出力を読む場合 | 信頼度シグナルがなく、監査証跡もなく、ゲートを設ける方法がない |
最もよくある間違いは、スキーマで目的を果たせたはずなのにRAGに手を伸ばすことです。事前にフィールドを書き出せるのであれば、抽出の方が速く、安く、そして正確性を証明するのがはるかに簡単です。RAGは、列挙できない質問のために取っておいてください。
ここは、**AIデータの準備状況（AI data readiness）**が単なるスライド上の言葉からチェックリストへと変わるポイントでもあります。このテーマに関する多くの文章は、データウェアハウスのテーブルやガバナンスポリシーについて語っています。しかし、ドキュメントワークフローにおいては、名前を持つフィールド、型を持つフィールド、移動する前にスキーマに照らして検証されたすべての値、そして値の抽出元ページへのリンク、という4つの具体的な要素を意味します。これが属するより広いカテゴリーについては、インテリジェント・ドキュメント・プロセッシング（IDP）をご覧ください。
Parseurでこれを構築する方法
Parseurは、上記のパイプラインにおける抽出レイヤーです。コンピューターがすでに読めるものを人間が打ち直すのを見るのにうんざりした2人のエンジニアによって開発されました。
セットアップは4つのステップで行います。
- メールボックスを作成し、ドキュメントをそこに向けます。サプライヤーのメールを転送するか、ファイルをドロップするか、ファイルがすでに保存されているフォルダを接続します。
- ParseurのAIが自動的にフィールドを抽出します。 Text AIエンジンはメールやテキストドキュメントを処理し、Vision AIエンジンはPDF、スキャン、画像を処理します。構築すべきテンプレートはなく、サプライヤーが請求書のデザインを変更した日にメンテナンスする作業もありません。
- 検証し、選択したものをレビューします。 すべてのフィールドは正規化され、メールボックスのスキーマに対して検証されるため、日付、数字、選択肢は下流のツールが期待する形で届きます。オプションの手動レビューステップをオンにすると、エクスポートされる前に人間がレコードをチェックします。Parseurはフィールドの信頼度をスコアリングしないため、しきい値に判断を委ねるのではなく、どのドキュメントを人間の目で確認するかをあなた自身が決定します。
- 構造化された結果をエクスポートします。 エージェント、自動化プラットフォーム、データベース、CRM、またはAPIに直接送信します。
Parseurは、PDF、メール、スキャン、スプレッドシート、添付ファイルを読み取り、2016年からこのサービスを提供し続けています。これまでに1億件以上のドキュメントを処理し、外部からの投資は一切受けていません。これは、稼働させたままにしたいパイプラインの基盤として求めるべき、退屈なまでの安定性です。
これらがERPに触れる前に、大抵同じ週にIT部門と財務部門から2つの質問が飛んできます。データはどこに行くのか：ドキュメントはモデルのトレーニングには決して使用されず、処理はGDPRに準拠しており、その他の詳細はセキュリティページに記載されています。費用はいくらか：無料プランがあります。したがって、これらを評価する唯一の賢明な方法は、自社で最も厄介なドキュメントを5つ実行し、返ってくるフィールドを確認することです。
導入を検討する根拠は計算すれば明らかです。米国企業における手動のデータ入力コストは、従業員1人あたり年間約28,500ドルに上ります。あなたのエージェントプロジェクトが本当に競合している予算枠はそこです。そして、チームがパイプラインを信頼できないと判断し、すべてのレコードを手作業でチェックし始めた週に、密かに戻ってくるのもこのコストなのです。
モデルが改善されると、このレイヤーは消滅するか？
抽出精度は毎年向上しています。しかし、ドキュメントとお金を支払うシステムとの間にある、チェック済みの境界線の必要性はなくなりません。
変わることのない計算式があります。フィールドの精度が99%の場合、100件に1件のドキュメントには間違った値が含まれています。月に1万件のドキュメントを処理すると、100個の間違った値が含まれることになり、そのすべてが正しい値とまったく同じように見えます。精度を99.5%に上げても、まだ50個あります。改善はされていますが、ゼロではありません。そして「エージェントが無人で稼働できる」という状態は、このエラー率がゼロであることを暗黙の前提としています。
本当に変わるのはその割合です。人間の確認が必要なドキュメントが減り、確認が必要なドキュメントにより正確なフラグが立てられ、レビューの待ち行列が1つの部門の仕事から、午後だけの仕事へと縮小されます。それは大きな改善であり、実現する価値があります。しかし、それはレイヤーが消滅することと同じではありません。
2028年にエージェントを順調に稼働させているチームは、検証をスキップできるほど優れたモデルを見つけたチームではないでしょう。早い段階でゲートを構築し、それがエラーをキャッチするのを観察し、少しずつそのゲートを広げる権利を獲得したチームなのです。
最終更新日
