Amazon Bedrock AgentCore Document Processing、固定テンプレートを学習ループに置き換え
Amazonは、Amazon Bedrock AgentCoreのドキュメント処理における未知の業務ファイルへの対応方法を変える、8エージェントのリファレンスシステムを発表した。レイアウトごとに新たなテンプレートを必要とする代わりに、このシステムは抽出指示を生成し、自身の出力を検証し、成功した指示を再利用のために保存する。
これにより、文書自動化における競争の軸が変わる。従来のインテリジェント・ドキュメント・プロセッシング（IDP）は、既知の形式に結び付いた事前定義済みのフィールド、テンプレート、ルールに依存している。Amazonのアプローチは、より多くの設定を実行時の学習ループへ移し、エージェントが新しい文書ごとの処理方法を決定する。
この変化によって人間のエンジニアリングが不要になるわけではない。チームは依然として、スキーマ、業務ルール、権限、許容可能なエラーレベルを定義する必要がある。したがって本質的な競争は、自動化と手作業によるデータ入力の対立ではなく、適応的なエージェント・オーケストレーションと予測可能なテンプレート処理の対比である。
Amazon Bedrock AgentCore Document Processingは検証失敗から学習する
Amazonのリファレンスアーキテクチャは、未知の文書を恒久的なテンプレート作成プロジェクトではなく、一時的な学習課題として扱う。
AWSは10月14日、2026年にエージェント型IDPの設計を公開した。対象は請求書、発注書、保険金請求、融資申請書など、送信者ごとにレイアウトが異なる文書だ。
このアーキテクチャは、グラフベースの2つのワークフローにまたがり、8つの専門エージェントを連携させる。オープンソースのソフトウェア開発キットであるStrands Agentsが、AgentCore Runtime内のワークフローグラフを制御する。
最初のワークフローでは、システムに投入された文書を特定する。AnalyzerエージェントはAmazon Textractを使ってテキストを抽出し、文書タイプと送信者を識別する。次にMatcherエージェントが、意味的に類似した文書をAmazon S3 Vectorsで検索する。
ベクトル類似性は、完全一致のファイル名やテンプレートを求めるのではなく、コンテンツの数学的表現を比較する。そのため、わずかなレイアウト差があっても、新しいファイルを既知の文書ファミリーに関連付けられる。
一致に成功した場合、文書は自動化ワークフローへ送られる。Extractorエージェントは保存済みの指示を取得し、新しいファイルに適用する。Validatorエージェントは、生成された構造化データをスキーマと業務ルールに照らして検査する。
一致に失敗した場合は、より長い学習ルートに進む。Instructionsエージェントが未知の形式向けに抽出プロンプトを作成する。Extractorがソースコンテンツを構造化データへ変換し、Validatorがその結果を検証する。
検証に失敗すると、Instructions Fixerエージェントが起動する。このエージェントは不一致を診断し、抽出指示を修正して、ファイルを再試行に回す。成功した指示は、類似した特徴を持つ将来の文書のためにベクトルストアへ登録される。
この設計こそが、Amazonの説明でシステムを「自己改善型」としている理由だ。エラーのたびに基盤モデルを再学習するのではない。モデルの周囲にある、文書固有のプロンプトと変換から成る再利用可能な層を改善する。
この違いは重要だ。モデルの再学習には、キュレーション済みデータセット、評価パイプライン、相当な運用統制が必要になる可能性がある。抽出指示の更新は、より限定的で高速であり、検査もしやすい。
AWSは、既知の形式に関する失敗と、新しい形式に関する失敗も分離している。既知の形式で検証に失敗した場合、Troubleshooterエージェントは保存済みの指示を直ちに書き換えることなく、抽出済みデータを修復する。
この分離により、1つの異常なファイルから共有指示を保護できる。破損したスキャンや単発のコンテンツエラーによって、特定の送信者から届く今後すべての文書に適用されるルールまで変更すべきとは限らない。
このワークフローは、2つのフィードバックループを生み出す。学習ループは検証失敗後に再利用可能な指示を改善する。処理ループは、繰り返し発生する形式の変動を明らかにし得るトラブルシューティングの詳細を記録する。
これは、大規模言語モデルに文書を読み込ませてJSONを返すよう単純に求める方法よりも規律ある設計だ。分類、抽出、検証、修正、永続化が、観測可能な結果を持つ個別の段階となる。
システムは決定論的な制御も維持する。サポート対象の文書タイプごとに、想定されるフィールドとデータ型を定義したJSONスキーマが必要だ。抽出された値が運用要件を満たすかどうかは、引き続き業務バリデーターが判断する。
企業チームにとって、この境界は極めて重要である。モデルは解釈を提案するが、出力を次の工程へ進められるかどうかは検証ルールが決定する。エージェント型の柔軟性は、明示的な品質ゲートの背後に置かれる。
テンプレートベースのIDPチームが直面する圧力
このアーキテクチャは、すべてのサプライヤーのレイアウトを手作業で設定・維持することに経済性を依存するIDPシステムへ圧力をかける。
テンプレート処理は、文書が安定している場合に有効に機能する。チームはフィールドを既知の領域にマッピングし、解析ルールを適用して、想定値と照らして出力をテストする。エンジニアが各変換を制御するため、ワークフローは理解しやすいまま保たれる。
しかし、数百の発行元がそれぞれ異なるレイアウトを使用すると、このモデルはコスト高になる。新しいサプライヤーは新規設定作業を生み、既存サプライヤーも予告なくフォント、列、ラベル、ページ構造を変更し得る。
わずかな改訂でも、発注番号の位置を変えたり、明細表をページ間に分割したりする可能性がある。厳格なテンプレートはこうした変更をコンテンツ欠落と解釈することがあり、さらに悪い場合には、一見もっともらしいが誤った値を返す。
Amazon Bedrock AgentCoreのドキュメント処理は、この保守負担をマッチング層と指示生成層へ移す。最初の成功した処理は、十分に類似していると判断された文書向けの再利用可能な処理資産を生み出す。
AWSは、Two Wheel Storeという架空の小売業者からの合成発注書でこの仕組みを実演している。ベクトル検索で適切な一致が見つからないため、最初の文書は学習ワークフローに入る。
Extractorは小売業者の在庫管理単位を読み取るが、Validatorは1つの値を拒否する。その小売業者はSB-004を使用している一方、架空の購入者の内部スキーマではプレフィックスとより長いパターンが必要となる。
Instructions Fixerは、サプライヤーの値を期待される内部形式へ変換するルールを追加する。2回目の試行では、7つすべての明細項目が検証を通過する。
AWSの例では、この最初の実行に3分49秒かかる。システムはその後、同じ小売業者からの別の文書がプロンプト生成を省略できるよう、洗練された指示を保存する。
後続の発注書は、3.7のしきい値に対して報告された信頼度スコア3.946で保存済み指示に一致する。初回の試行で3つの明細項目を検証し、1分30秒で完了する。
これらの数値は、意図された複利的な効果を示している。最初の未知の形式では追加の推論と検証サイクルを要するが、後続の例では得られた指示を再利用し、必要なワークフローステップが少なくなる。
ただし、この証拠はAWSの合成デモに基づくものであり、独立した本番ベンチマークではない。この例は、リファレンス実装が設計されたループを実行することを示している。しかし、制御されていない企業文書全体での精度を立証するものではない。
それでも、テンプレートベンダーへの圧力は現実的だ。購入者は、検証の規律を手放すことなく、学習済み指示がオンボーディング作業を削減するかどうかを評価できるようになった。これにより、測定可能な保守削減が調達協議の中心に置かれる。
既存のIDPプラットフォームはいくつかの方法で対応できる。生成型抽出を追加し、意味的なレイアウトマッチングを取り入れるか、独自の再利用可能な修正ループを提供できる。多くは、これらの手法を既存の光学文字認識と組み合わせるだろう。
もっとも可能性が高いのは、テンプレートが直ちに消滅することではない。変化するのは、テンプレートの適用範囲だ。安定した形式では決定論的なマッピングを維持できる一方、変動する形式はエージェント支援型の処理へ入る。
このハイブリッドな経路は、規制の厳しいチームにとって魅力的だろう。予測可能な文書については既存の統制を維持しつつ、例外、新規サプライヤー、低リスクの文書クラスで適応型ワークフローを試験できる。
この変化は社内エンジニアリングチームにも影響する。レイアウトごとに1つのパーサーを構築する代わりに、文書ファミリー全体で機能するスキーマ、検証サービス、信頼度ポリシー、エスカレーション経路を設計しなければならない。
この作業は、運用ナレッジシステムの維持に似ている。チームには、技術文書向けの検索可能なナレッジベースのように、検索可能な指示、修正履歴、信頼できる検索機能が必要となる。
AgentCoreのドキュメント処理がAWSサービス間で機能する仕組み
この学習ループは、並外れて高性能な1回のモデル呼び出しではなく、連携されたストレージ、アイデンティティ、検証、可観測性サービスに依存している。
文書はAmazon Simple Email ServiceまたはAmazon S3への直接アップロードを通じて取り込まれる。次にAmazon EventBridgeがAWS Lambda関数を起動し、DynamoDBに追跡ジョブを作成する。
Lambda関数はAgentCore Runtimeを呼び出し、そこでStrandsワークフローが専門エージェントを連携させる。このランタイムでは、Amazon Bedrockを通じて有効化されたAmazon NovaまたはAnthropic Claudeモデルを使用できる。
このモデルの柔軟性により、タスク固有のルーティングを支援できる。チームは単純な作業を1つのモデルに割り当て、曖昧な抽出やトラブルシューティングにはより高性能なモデルを確保できる。
AgentCore Gatewayは、Model Context Protocolを通じてLambda関数をエージェント互換ツールとして公開する。MCPは、モデルが構造化された入力を用いて外部ツールを検出・呼び出しできるようにする標準インターフェースだ。
この設計により、業務ロジックを言語モデルの外部に保てる。発注書バリデーターは、ベンダーと製品のレコードを照会するLambda関数のまま維持できる。エージェントは検証結果を作り出すのではなく、その関数を呼び出す。
Amazon Aurora DSQLは、サンプルバリデーターで使用される合成業務データを保存する。本番デプロイでは、こうしたモックのレコードとルールを実際のエンタープライズシステムへ置き換える必要がある。
請求書実装では、ベンダー識別子を確認し、明細項目の合計を再計算することが考えられる。契約ワークフローでは、必要条項、日付、法人を確認できる。保険金請求ワークフローでは、保険証券と補償情報を検証できる可能性がある。
アイデンティティも処理設計の一部となる。AgentCore IdentityとAmazon Cognitoは、AWSリソースにアクセスするエージェント向けにマシン間認証情報を提供する。IAMポリシーは、これらのエージェントが利用できるサービスとアクションを決定する。
エージェント型ワークフローは複数のシステムにまたがってアクションを実行するため、この制御は重要だ。分類には文書へのアクセスが必要であり、検証には参照データが必要であり、永続化には再利用可能な指示を保存する権限が必要となる。
AgentCore documentationでは、このプラットフォームを単一のフレームワークやモデルに依存せず、エージェントをデプロイ・運用するためのインフラストラクチャとして説明している。IDPサンプルは、このインフラストラクチャを限定された1つの業務プロセスへ適用している。
運用上の可視性は、AgentCore ObservabilityとAmazon CloudWatchを通じて得られる。AWSによれば、このプラットフォームはエージェント実行内のセッション、レイテンシー、所要時間、トークン使用量、エラー、ステップを記録できる。
これらのトレースにより、運用担当者は複数の障害タイプを見分けられるようになります。Textractがソースを誤読した可能性、検索が誤った指示を選択した可能性、抽出でフィールドが欠落した可能性、あるいは検証が正しい内容を拒否した可能性があります。
この分離がなければ、チームが目にするのは失敗した最終結果だけです。トレースがあれば、責任のある段階を特定し、プロンプト、しきい値、スキーマ、バリデーターのどれを見直すべきか判断できます。
AgentCore Gatewayは、ツールアクセスを管理する境界も提供します。チームは、認可、ガードレール、リクエスト制御、可観測性を、エージェント自身のアプリケーションコードの外部に配置できます。
このアーキテクチャには、Amazon Elastic Container Serviceでホストされるダッシュボードが含まれます。運用担当者はジョブと保存済み指示を確認し、検証結果を調査し、ワークフロー障害についてチャットインターフェースに質問できます。
Amazonはこのサンプルを、6つのCloudFormationスタックとして提供しています。コアのストレージとID管理、ゲートウェイツール、Aurora、エージェントランタイム、オーケストレーションエンドポイント、Reactインターフェースをカバーしています。
AWSによれば、前提条件が整った後、デプロイには通常15～20分かかります。前提条件にはDocker、AWS Cloud Development Kit、対応モデル、リージョン内のサービスアクセス、権限が含まれます。
公開されたサンプルリポジトリにより、アーキテクチャを詳細に確認できます。デプロイコード、プロンプト、スキーマ、バリデーター、ワークフローロジック、合成された発注書データが含まれています。
この透明性により、この発表は概念図以上の実用性を持ちます。エンジニアリングチームはサービスの依存関係を確認し、サンプルコンポーネントを独自のスキーマや検証ルールに置き換えられます。
同時に、実装負荷も明らかになります。本番デプロイには依然として、セキュリティレビュー、データ保持管理、監視、例外処理、参照データ連携、代表的な文書全体でのテストが必要です。
したがって、AgentCoreとテンプレート処理の違いは、設定があるかないかの比較ではありません。チームが個々の視覚レイアウトをすべて設定するのか、共有スキーマ、バリデーター、適応的な指示を設定するのかが違いです。
自己改善という主張は検証の境界で止まる
システムは再利用可能な指示を改善できますが、企業にとって何が正しさを意味するかを独力で判断することはできません。
AWSは、各文書タイプにJSONスキーマを作成するようチームに求めています。スキーマはフィールド名、データ型、各値が明示的に記載されるか推論が必要かを定義します。
チームは、自社の運用ルールに合わせたバリデーターも作成する必要があります。サンプルのバリデーターは架空の発注書システムを理解しますが、実在企業の仕入先、契約、許容範囲、承認ポリシーまでは把握できません。
これが、AgentCoreの文書処理がどのように機能するかにおける中心的なトレードオフです。エージェントはレイアウト固有の作業を減らす一方、業務固有の設定は引き続き必要であり、むしろ重要性を増します。
弱いバリデーターは、流暢でも誤った抽出結果を承認する可能性があります。厳格すぎるバリデーターは、正当な例外を拒否する可能性があります。検証結果が後続の修正を導くため、どちらの失敗も学習ループを損なうおそれがあります。
検索には別のリスクもあります。Matcherエージェントは、保存済み指示を見つけるために意味的類似性を利用します。高い類似度スコアは、2つの文書が同一のフィールド意味や変換ルールを共有することを保証しません。
サプライヤーは、請求書とクレジットノートで同じレイアウトを使い回す可能性があります。文書は似ていても、会計上は正反対の影響を持つ場合があります。メタデータ、文書分類、保守的なしきい値によって、安全でない指示の再利用を防ぐ必要があります。
AWSの例では一致しきい値が示されていますが、その値はデモンストレーション用です。本番環境のチームは、自社の文書構成、誤一致のコスト、許容できるレビュー負荷に基づく評価が必要です。
文書には信頼できないテキストが含まれるため、プロンプトインジェクションも懸念事項です。文書内に、モデルへの指示のように見える文言が含まれる可能性があります。ワークフローでは、文書内容を信頼できるシステム指示やツール権限から分離しなければなりません。
AWSは、機密ファイルに対してコンテンツ制御とグラウンディングチェックを推奨しています。OWASPが維持するLLMセキュリティリスクのカタログでも、プロンプトインジェクション、機密データの漏えい、過剰な自律性、安全でない出力処理が指摘されています。
最小権限のアクセス許可は、侵害されたステップによる被害を減らします。抽出エージェントは、1つのソースファイルを読む必要があるからといって、広範な書き込み権限を得るべきではありません。ツール呼び出しでは、入力スキーマと認可を強制する必要があります。
不確実性が高いケースや影響の大きいケースでは、人によるレビューが引き続き適切です。低信頼度の分類、繰り返される検証失敗、異常な合計額、想定外の文書タイプは、管理された例外キューに送るべきです。
アーキテクチャは、無限の修正サイクルも防止すべきです。再試行回数の上限、タイムアウト、トークン予算により、バリデーターを満たせないワークフローを抑制できます。
指示の永続化自体にもガバナンスが必要です。チームには、後続文書に影響を与えるプロンプトについて、バージョン管理、作成者記録、テスト結果、承認状態、ロールバックの仕組みが必要です。
1回の修正成功は、一般的なルールの証明にはなりません。あるサプライヤーの文書を修正した接頭辞変換は、そのサプライヤーが採番システムを変更した後には失敗するかもしれません。
このため、代表性のあるテストが重要です。AWSは、エッジケースやフォーマットの変動を含め、タイプごとに5～10件の文書から始めることを推奨しています。ただし、これはソリューション作成者によるガイダンスであり、普遍的に十分な基準値ではありません。
精度測定も、完全一致のフィールド数だけを対象にすべきではありません。チームは、分類エラー、誤った指示の一致、検証失敗、人による上書き、下流工程での取り消しも追跡すべきです。
レイテンシにも同等の注意が必要です。複数のエージェントが指示を生成、テスト、改訂するため、サンプルの学習ルートは再利用ルートより時間がかかります。再試行が増えれば、処理時間とモデル消費量が増加する可能性があります。
モデル自体も変化し得ます。新しいバージョンは、同じ抽出プロンプトを異なる形で解釈するかもしれません。AWSは、モデル変更時の品質確認にAgentCore Evaluationsを利用するよう開発者に案内しています。
モデル更新を本番環境に投入する前に、評価を実行すべきです。有用なテストセットには、きれいな文書、不鮮明なスキャン、レイアウト変更、欠落フィールド、矛盾する値、敵対的コンテンツが含まれます。
チームは、エージェント型ワークフローを現在のベースラインと比較すべきです。重要なのはデモが動くかどうかではありません。新システムが、精度を加味した労働コスト、レイテンシ、例外率を改善するかどうかです。
したがって、「自己改善」というラベルは正確に解釈する必要があります。このシステムは、検証済みの抽出戦略を記憶し、再利用します。ポリシー判断、独立したテスト、説明責任を伴う人間の所有を不要にするものではありません。
学習ループが持続するかを示す3つのシグナル
次の検証点は、アーキテクチャがより大きな検証・ガバナンス負荷を生むことなく、本番運用の保守作業を削減できるかどうかです。
第1のシグナルは、実際の文書ポートフォリオから得られる独立したパフォーマンスデータです。チームは、フィールドレベルの精度、誤った指示の一致、検証通過率、人によるレビュー率、レイアウト変更をまたいだ結果を確認すべきです。
成功すれば、再利用可能な指示が大規模なテンプレート保守を置き換えられるというAmazonの主張を強化します。例外率が高ければ、エージェントの柔軟性は作業を移し替えただけだと示唆されます。
比較には、初回のフォーマットと繰り返し使われるフォーマットの両方を含める必要があります。このアーキテクチャは不慣れな文書に明示的に多くの作業を費やすため、集計平均では高コストの学習ケースや不十分な検索性能が隠れる可能性があります。
第2のシグナルは、組織が保存済み指示を本番資産として統治できることを示す証拠です。有用な導入では、プロンプトのバージョン、検証履歴、レビュー判断、ロールバック制御を可視化できるべきです。
明確なガバナンスがあれば、チームは後続文書が学習済み変換に従った理由を調査できるため、適応型モデルを支えられます。不透明な指示変更は、特に金融、保険、法務のワークフローで信頼を損ないます。
可観測性は、エージェントのトレースを業務成果に結び付けなければなりません。技術的に成功した実行でも、高コストの下流エラーを生む可能性があります。チームには、ソース文書、抽出レコード、検証、修正、最終システム更新の間を結ぶリンクが必要です。
第3のシグナルは、IDPベンダーとエンタープライズチームが、適応型エージェントと決定論的制御をどのように組み合わせるかです。競合他社は、その前提に応えるためにAmazonの正確な8エージェントグラフをコピーする必要はありません。
既存のワークフロー製品に生成型抽出を組み込み、意味的マッチングを追加し、修正の記憶を導入できます。また、より強力な保証を伴う、より限定的な自動化を強調することもできます。
信頼性の高い本番パターンは、おそらくハイブリッドになるでしょう。決定論的手法は安定した大量フォームを処理し、エージェントはより厳格なレビューしきい値の下で新しいレイアウトや例外を処理します。
この結果でも、Amazonの主張の核心は裏付けられます。文書処理は、見慣れないレイアウトごとに完全なテンプレート開発プロジェクトとして扱う必要がなくなります。
Amazon Bedrock AgentCoreの文書処理を評価する開発者は、対象を限定した文書ファミリーと明示的なベースラインから始めるべきです。現在のセットアップ時間、抽出精度、例外量、人による修正作業を測定してください。
次に、同じ文書を適応型ワークフローでテストします。これまでに見たことのないレイアウト、フィールドが変更された既知のレイアウト、低品質のスキャン、保存済み指示に一致すべきでない文書を含めます。
すべての修正が後続ファイルに影響を与える前に検査してください。バリデーターが、有効なJSON構文や想定フィールド名だけでなく、業務上の意味をテストしていることを確認してください。
最後に、自動化をどこで止めるかを決めます。どの検証失敗にレビューが必要か。どのツール操作に別途承認が必要か。欠陥のある指示を運用担当者はどれだけ迅速に無効化できるか。
Amazonは、すべての文書業務を自律化すべきだという証拠ではなく、具体的なアーキテクチャと動作するコードを提供しました。正確性を外部で定義し続けながら、フォーマット学習を再利用可能にすることに機会があります。
これが、購入者が今後数か月にわたって適用すべき基準です。制御を弱めることなく導入・保守の労力を減らせるなら、適応型IDPには説得力のある本番導入の根拠が生まれます。
検証、レビュー、プロンプトガバナンスが節約した労力を消費するなら、テンプレート処理は重要な優位性を維持します。決定的な問いは、エージェントが文書を読めるかどうかではありません。組織が、エージェントの記憶する内容を信頼できるかどうかです。
