Amazon Contract Intelligence Platform、RAGのポートフォリオ分析における死角に挑む

Amazonは、8つの抽出フィールドを中心に構築した契約インテリジェンスのアーキテクチャを公開した。これは、RAGだけのチャットでは扱いにくい質問に対応するAmazon contract intelligence platformを実現するものだ。

このリファレンス設計は、根強いエンタープライズ課題を対象としている。チャットボットは1件の契約書から1つの支払い条項を取得できる場合が多い。しかし、数百件の契約にまたがって金額を合計し、日付を比較し、未署名文書を数えるよう求められると、信頼性が低下する。

Amazonの答えは、より大きなプロンプトや長いコンテキストウィンドウではない。文書理解とポートフォリオ分析を分離する。AIエージェントがフィールドを抽出・検証し、データベースが計算を担い、Amazon Quickが両方のワークフローに向けた単一のインターフェースを提供する。

この違いにより、検索のみの契約支援ツールにはプレッシャーがかかる。このシステムは、検索拡張生成（RAG）をあらゆる質問のデータベースではなく、1つの構成要素として位置付ける。その結果は、エンタープライズエージェントが担うべき領域と、従来型データシステムが依然として不可欠な領域を示す有用な試金石となる。

Amazonが実際に構築したもの

この設計では、アップロードされたすべての契約書が、検索可能な文書であると同時に、構造化されたデータベースレコードにもなる。

AWSは2026年9月29日に、このcontract intelligence architectureを公開した。これはリファレンス実装であり、自律型の法務サービスや顧客導入の発表ではない。

Reactアプリケーションがユーザーインターフェースを提供する。契約PDFはAmazon Simple Storage Serviceバケットに入れられ、そこから自動処理パイプラインが起動する。

最初のエージェントは各PDFを読み、8つのフィールドを抽出する。AWSによれば、この実装はAnthropicのClaude Sonnet 4.6を使用し、各フィールドの信頼度スコアを含む構造化JSONを返す。

2つ目のエージェントは、同じ文書を独立して読み取る。この検証エージェントはAWSによればClaude Haiku 4.5を使用し、その結果を抽出器の出力と比較する。

2つのエージェントは、Amazon Bedrock AgentCore上のオープンソースStrands Agents SDKを通じて動作する。AgentCoreは、エージェントコードが実行・スケールするマネージドランタイムを提供する。

不一致が生じても、検証エージェントが自動的に優先されるわけではない。署名ステータスについては、システムがAmazon Textractを視覚的なタイブレーカーとして呼び出す。検証済みレコードはその後、Amazon Aurora PostgreSQLに格納される。

元のPDFは別の経路をたどる。支払い条件や個別条項についての質問を含む、文書固有の検索のためにナレッジベースから引き続き利用できる。

Amazon Quickは両方のソースを横断する。そのQuick Sight機能はデータベースレコードに基づくダッシュボードを表示する。対話型インターフェースは、構造化分析または文書検索へ質問を振り分けられる。

両者の違いは重要だ。条項の検索には関連テキストが必要になる。ポートフォリオ全体の合計には、該当するすべてのレコードと信頼できる計算が必要だ。

この設計では、パイプラインのステータスもWebSocket接続を介してブラウザへストリーミングする。ユーザーは、ファイルが抽出、検証、チェック、保存のどの段階にあるかを確認できる。

この可視性は、単なるインターフェース上の磨き込みではない。どの処理段階で遅延や不一致が発生したかをユーザーが確認できれば、エンタープライズワークフローは検査しやすくなる。

AWSによれば、一般的な条件下では契約書は数秒でパイプラインを通過できる。ただしこれは設計上の主張にとどまり、実際の性能は文書の長さ、同時実行数、モデルの可用性、リージョン設定に左右される。

この公開は、2026年1月のAWSによる先行する契約管理設計に続くものだ。そのバージョンでは、法務、リスク、コンプライアンス、ワークフローのタスクに向けた複数の専門エージェントを重視していた。

新しいアーキテクチャは、より狭い範囲を対象とする一方で、より多くを明らかにする。対話型デモでは見えにくい弱点を露呈させる、抽出精度とポートフォリオ分析に焦点を当てている。

RAGが契約ポートフォリオを合計できない理由

RAGは関連するパッセージを選択する一方、ポートフォリオ分析には完全なレコードと統制された計算が必要となる。

元祖となるRAG researchは、言語モデルと取得した外部知識を組み合わせた。このパターンは、ソースコレクション全体をプロンプトに収めずに、モデルが質問へ回答するのに役立つ。

一般的なシステムは文書をチャンクに分割し、そのベクトル表現を作成する。ユーザーが質問を送信すると、セマンティック検索が密接に関連する限られた数のチャンクを取得する。

この仕組みは、求める答えが少数のパッセージに存在する場合には有効だ。解約条項に関する質問であれば、すべてのページを再読せずに該当条項を取得できる。

しかし、質問がコレクション全体に及ぶと、この仕組みは弱点となる。たとえば、調達責任者がすべての有効な契約にまたがるコミット済み価値の合計を求める場合を考えてみよう。

検索器は依然として、最も関連性が高そうなチャンクを選択する。すべての有効な契約が、完全かつ正規化された正しい値を1つずつ計算に寄与することは保証しない。

取得チャンク数を増やしても、この問題を完全には解決できない。契約書には、繰り返されるラベル、修正契約、表、脚注、矛盾する日付が含まれる。関連するパッセージの数が、モデルが実用的に扱えるコンテキストを超える場合もある。

欠けている能力は、対話の流暢さではない。網羅性だ。

AWSはこの問題を、250件の契約からなる仮想ポートフォリオで説明している。各契約が10～20ページだとすれば、そのポートフォリオは最大5,000ページに及ぶ可能性がある。

人間なら最終的にすべての文書を確認し、スプレッドシートを維持できる。しかし、新しい契約や修正契約が追加されるたびに、スプレッドシートは古くなる可能性がある。

RAGアシスタントならより迅速に回答できるが、それでも検索ウィンドウ外のレコードを除外することがある。計算が一部のサブセットしか対象にしていなくても、回答は完全に聞こえるかもしれない。

これがAmazon contract intelligence platformの背後にある主な競争軸だ。RAGのみのチャットと、抽出後にデータベースクエリを実行する方式との対比である。

抽出アプローチでは、すべての契約が同じスキーマを通過する。金額、日付、取引相手、署名状態、その他の選択されたフィールドが行と列になる。

その後、データベースは有効なレコードをフィルタリングし、ベンダー別にグループ化し、合計を計算できる。さらなる検証に向け、結果の根拠となったレコードも返せる。

このアーキテクチャはRAGを不要にするものではない。RAGの強みに見合った、より限定的な役割を与える。

正規化に適さない質問に対して、文書検索は引き続き価値を持つ。支払い文言、責任条項、例外、特殊な義務では、多くの場合に周辺テキストが必要になる。

構造化分析は別の層を担う。たとえば、失効した契約の件数、未署名契約のうち最大の価値を持つもの、特定の日付に近づく更新の内容といった質問を支援する。

2つの経路は相互補完できる。構造化クエリが注意を要する契約を特定し、検索がその裏付けとなる条項を取得する。

この分担により、失敗モデルもより明確になる。検索エラーは文書に関する回答へ影響する。抽出エラーは、ダッシュボードと保存済みフィールドから構築されるすべての集計に影響する可能性がある。

そのため、チャットインターフェースよりも取り込みパイプラインのほうが重要になる。対話層の信頼性は、その背後にあるレコードと検索ソースの信頼性に依存する。

Amazon Contract Intelligence Platformがデータ経路を変える仕組み

このアーキテクチャは、最も難しい作業を質問時から取り込み時へ移す。

RAGのみのアシスタントは、誰かが質問するまで解釈を先送りにする。Amazon contract intelligence platformは、各文書がシステムに入る際に、選択された契約フィールドを解釈する。

この変更により、再利用可能な分析層が生まれる。更新日が抽出、検証、保存されると、複数のダッシュボードと質問が同じ正規化済みの値を利用できる。

最初のステップはAmazon S3を介した文書取り込みだ。アップロードにより、アナリストが手作業でファイルを開かなくても処理フローが開始される。

AWSによれば、抽出エージェントはその後PDFをネイティブに読み取る。8つの期待フィールドを生成し、下流のコンポーネントが確認できる信頼度スコアを付与する。

信頼度スコアはシグナルであり、保証ではない。レビュー作業の優先順位付けには役立つが、抽出値が条項の法的な意味と一致することを立証するものではない。

独立した検証エージェントにより、2回目の読み取りが導入される。異なるモデルファミリーのメンバーを使う目的は、同じ抽出プロセスを繰り返すことで生じる相関エラーを減らすことにある。

この考え方は2人によるレビューに似ているが、この類推には限界がある。同じプロバイダーの2つのモデルでも、学習パターン、盲点、文書処理上の弱点を共有する可能性がある。

AWSは、20件の契約を用いて抽出器と検証器の組み合わせを評価した。チームは各契約の8フィールドに手作業でラベルを付け、160件のグラウンドトゥルース値を作成した。

この評価は、検証器よりも抽出器のほうが重要であることを示唆した。著者らによれば、より高性能な抽出モデルは、軽量な検証器と組み合わせても結果を維持した。

AWSはまた、このデータセットでは、より強力なモデルが常に有意な改善をもたらしたわけではないとしている。同社は、利用可能なモデルを各組織の契約書と受け入れ基準に照らしてテストするよう推奨している。

この留保は重要だ。20件の契約は方向性を示すテストではあっても、選択した組み合わせが業界、言語、起案スタイルを横断して一般化できる証拠ではない。

検証後、データベースが集計質問のためのシステムとなる。Amazon QuickはAurora PostgreSQLに接続し、別途エクスポートを待たずにライブデータをクエリできる。

Amazon Quickは、ソース文書を含むナレッジベースにも接続する。そのため、同じインターフェース内で、構造化された質問と個別文書の検索の両方をチャットエージェントが支援できる。

このルーティングこそが、Amazon contract intelligenceの仕組みを支えるアーキテクチャ上の機構だ。モデルは、会話のたびに契約文を読んであらゆる計算を実行するわけではない。

集計リクエストでは、構造化ソースがフィルタリング済みのレコードと計算結果を提供する。文書固有のリクエストでは、ナレッジベースが関連する契約テキストを取得する。

AWSは、20件の契約からなるサンプルポートフォリオに基づく出力例を提示している。例には、ポートフォリオ価値、失効契約の合計、署名済み・未署名契約の件数が含まれる。

これらの数値はインターフェースを説明するものだ。公開された顧客ポートフォリオの運用結果ではなく、性能の証拠として読むべきではない。

埋め込みダッシュボードは、同じデータを検査する別の方法を提供する。ユーザーはアプリケーションを離れることなく、ポートフォリオの合計、署名状態、抽出結果、信頼度の比較を確認できる。

この共有基盤は、ダッシュボードとチャットの出力間の不一致を減らせる。分析的な質問では、両インターフェースが同じ検証済みデータベースレコードを参照できる。

この設計は、ソース資料へのアクセスも維持する。契約上の判断に条項の読解が必要な場合、アナリストはデータベースの値を最終判断として扱う必要はない。

このハイブリッドパターンは、契約にとどまらない。保険請求、コンプライアンス申告、リース契約、オンボーディング記録はすべて、反復可能なフィールドと文書固有の文言を組み合わせられる。

これは、より広範なknowledge blendingの原則にも合致する。構造化された事実とソースコンテキストは異なる目的を果たすため、有用なシステムには両者を統制してつなぐ橋渡しが必要となる。

検証は追加のモデル呼び出しより重要

この設計で最も示唆に富む点は、あらゆる判断を言語モデルに委ねることを拒んでいる点だ。

テスト中、AWSは検証器が空の署名欄を署名済みと判定する場合があることを発見した。一部の偽陽性ケースでは、報告された信頼度が95〜100％に達した。

モデルは署名に関連する単語やレイアウトを認識し、署名フィールドが存在すること自体を、誰かが署名した証拠として扱った。

この失敗は、生成AIに繰り返し見られる問題を浮き彫りにする。信頼度スコアはモデル内部の確信度を示すことはあっても、基となる結論が正しいことを証明するものではない。

AWSは、2つのモデルで署名ステータスの判断が食い違った場合にのみTextractを追加することで対応した。Textractは視覚的特徴を分析し、手書きまたはデジタルの署名を検出する。

この選択により、3段階の統制が生まれる。1つのモデルが抽出を行い、別のモデルがそれを確認し、専門のコンピュータビジョンサービスが定義済みの不一致を解決する。

これは、3つ目の言語モデルに投票させるより適している。3つ目のモデルも、署名欄と実際の署名を意味的に混同する同じ問題を再現しかねない。

このパターンでは、専門的な検査も争点となったケースに限定される。主要ワークフローを維持しつつ、モデルが不確実性を示した箇所に異なる技術的手法を適用できる。

ただし、Textractは署名の有無を決めるタイブレーカーであり、すべてのフィールドを裁定するものではない。契約金額、更新ルール、日付、当事者の身元には、それぞれ異なる曖昧さが生じうる。

修正契約が以前の値を置き換える場合がある。自動更新条項では、文脈に基づく解釈が必要になることがある。署名が存在していても、別の理由で合意が未完成である可能性がある。

こうしたケースには、明示的なエスカレーションルールが必要だ。AWSの投稿では、決定論的なサービスで解決できない不一致は人間のレビュアーに回すべきだとしている。

この人間による経路は、責任ある導入の中心となる。自動化が定型業務を減らすのか、それとも不確実な記録をデータベース内に隠すだけなのかを左右するからだ。

システムは、抽出された各値、その出典位置、両モデルの出力、最終的な解決内容を保存すべきである。そうでなければ、レビュアーはダッシュボードに特定の数値が含まれる理由を再構成できない。

組織には、フィールドごとのしきい値も必要だ。誤った連絡先名と誤った契約終了日では、業務上のリスクが同じではない。

NIST AI frameworkは、AIシステムにおけるテスト、評価、検証、妥当性確認を重視している。契約ワークフローでは、こうした実務をデータフィールドのレベルで実施する必要がある。

チームは、フィールドごとに適合率、再現率、完全一致の性能を測定すべきである。また、不一致率、レビュアーによる上書き、承認後に発見されたエラーも追跡する必要がある。

精度は文書タイプ別に分類すべきだ。ネイティブPDF、スキャンしたページ、表、修正契約、手書き注記、多言語の契約書では、挙動が異なる可能性がある。

AWSによる20件の契約評価は、方法論の出発点となる。ただし、別の組織の契約ポートフォリオで本番信頼性を確立するには、十分な多様性を提供していない。

有用なパイロットでは、最大のリスクを生む文書をサンプリングすべきである。標準フォームの整った契約書だけでなく、一般的でないテンプレートや低品質なファイルも含める必要がある。

この設計におけるデュアルモデル検証は、不一致を可視化するため、依然として価値がある。決定論的な検査または人間によるレビューを起動できる、測定可能なイベントを生み出すからだ。

しかし、モデル間の一致をグラウンドトゥルースとして扱うことはできない。特に原文が曖昧な場合、2つのエージェントが同じ誤った値を出す可能性がある。

本質的な統制はトレーサビリティである。構造化されたすべての値は、それを生んだページ、条項、抽出判断までレビュアーを導けなければならない。

精度、アクセス、経済性はなお未証明

このリファレンスアーキテクチャは信頼できる仕組みを定義しているが、あらゆる契約ポートフォリオに対する本番運用の準備完了を証明するものではない。

最初の不確実性は評価規模である。AWSはモデルの組み合わせを比較する際、20件の契約書と160のラベル付き値を使用した。

このサンプルは構成間の明白な違いを示すことはできる。しかし、企業契約に見られる書式、起案、スキャン、言語、修正パターンの全範囲を代表することはできない。

2つ目の不確実性はスキーマのカバレッジである。8つのフィールドでも有用なダッシュボードを支えられるが、契約運用では、より複雑な義務や条件付きの日付に依存することが多い。

更新日は通知期間に依存する場合がある。金額には、確約済み料金、従量課金、クレジット、指数連動型の増額が組み合わさることがある。

こうした条件を1つのレコードへ平坦化すると、確実性の錯覚を生む可能性がある。フィールドを単純な数値または日付として表せない場合、スキーマは限定条件を保持しなければならない。

3つ目の不確実性はモデル変更に関するものだ。AWSはモデルの提供状況が変化すると指摘し、新しい選択肢に依存する前にシステムを再テストするよう開発者に助言している。

周辺アプリケーションが変わらなくても、代替モデルによって抽出の挙動が変わる可能性がある。したがって本番チームには、固定された評価セットとリリースゲートが必要になる。

4つ目の不確実性は認可である。契約には、機密性の高い価格情報、従業員情報、セキュリティ義務、戦略的なベンダー条件が含まれる可能性がある。

AWSによれば、AgentCoreはセッション分離をサポートし、ポリシー制御はエージェントコードの外部に配置できる。AgentCore documentationでは、ユーザーセッションごとに分離された実行環境について説明している。

しかし、インフラストラクチャの分離が正しい業務上の権限を自動的に生み出すわけではない。AWSのドキュメントでは、クライアントバックエンドがユーザーとセッション識別子の関係を維持する必要があるとしている。

開発者は、文書、データベース、ダッシュボード、エージェントツールの各レイヤーでもアクセスを強制しなければならない。チャットインターフェースは、同じユーザーが他の場所で開けないレコードを表示すべきではない。

5つ目の不確実性は運用経済性である。AWSの投稿はサンプルのコストモデルを示しているが、商用条件は変化し、ポートフォリオのワークロードも異なる。

処理コストは、ページ数、モデル呼び出し、再試行、ストレージ、データベース容量、同時実行数、ユーザークエリの頻度に左右される。人間によるレビューが最大の変動要因になる場合もある。

信頼できるビジネスケースでは、モデル呼び出しあたりのコストではなく、受理されたレコードあたりのコストを測定すべきである。大規模なレビュー作業を生む安価な抽出は、経済的に安価とは言えない。

競合環境には、複数の実装ルートも存在する。Microsoftのcontract extraction modelは、Document Intelligenceを通じて契約書から構造化フィールドを返す。

GoogleのDocument AIも同様に、非構造化文書を後続処理用の構造化データへ変換する。

これらの製品は、スキーマ、カスタマイズ、オーケストレーション、分析、クラウド統合の点で異なる。購入者は、単一の抽出ベンチマークではなく、完全な制御ループを比較すべきである。

この設計におけるAmazonの差別化要因は、エージェント、検証、リレーショナルデータベース、埋め込み分析、文書Q&Aの接続にある。

この統合は、すでにAWSで運用している組織にとって魅力的になりうる。一方で、ストレージ、モデル、データベース、分析、ID制御にまたがるアーキテクチャ上のコミットメントを増やす可能性もある。

チームは本番導入前にポータビリティをテストすべきだ。抽出されたレコードとプロベナンスデータには、単一の会話型インターフェースの外部からもアクセスできる、文書化されたスキーマを使用する必要がある。

また、障害に対する責任の所在も定義すべきである。調達、法務オペレーション、データエンジニアリング、セキュリティの各チームは、別のグループが出力を検証すると考えるかもしれない。

ワークフローには、スキーマ変更、評価しきい値、例外キュー、アクセスレビューを担う、説明責任を持つ所有者が1人必要である。その所有者がいなければ、システムは不整合を自動化しかねない。

より大きな教訓は、契約インテリジェンスがAI取り込みレイヤーを備えたデータガバナンスプロジェクトだということだ。これをチャットボット導入として扱うのは、必要な作業を過小評価している。

購入者が次に注視すべきこと

このアーキテクチャが契約データの信頼できる運用基盤になるのか、それとも説得力のあるリファレンスデモにとどまるのかは、3つのシグナルで判断できる。

最初のシグナルは、より大規模かつ多様な契約セットから得られる評価エビデンスである。購入者には、スキャン、修正契約、表、言語、一般的でない起案パターンにまたがるフィールドレベルの結果が必要だ。

公開された精度だけでは不十分である。有用なエビデンスでは、データセットの構成、エラー分類、レビューポリシー、両モデルが誤った値で一致した頻度を開示すべきだ。

より良いエビデンスは、独立した検証が信頼性を高めるというAmazonの中心的な主張を強化する。相関したエラーが継続するなら、デュアルモデル設計の根拠は弱まる。

2つ目のシグナルは、本番グレードの例外処理である。プラットフォームには、設定可能なレビューキュー、出典引用、承認履歴、未解決の不一致に対する明確な経路が必要だ。

Amazon Quickにはヒューマン・イン・ザ・ループ機能が含まれているが、組織はその統制が日々の契約業務にどう組み込まれるかを示す必要がある。レビュアーに必要なのは、説明のない別の信頼度スコアではなく、文脈である。

成熟したワークフローでは、誰かがフィールドを修正し、その理由を記録し、元の出力を失うことなく下流の分析を更新できるべきだ。

成功する導入では、低リスクの自動化と高リスクの意思決定も分離される。ポートフォリオの件数集計には、契約終了通知や財務上のコミットメントとは異なる統制を適用できる。

3つ目のシグナルは、デモ用ワークロードを超えた導入である。抽出品質を測定可能な業務成果に結び付けた、公開済みの顧客導入事例に注目したい。

関連する指標には、レビュー時間、修正率、古いレコードの発生頻度、エスカレーションなしで処理された契約の割合が含まれる。これらの指標は、チャットボットの応答速度より重要だ。

競争も導入を左右する。MicrosoftとGoogleはすでに構造化文書抽出を支援しており、契約ライフサイクルプラットフォームは領域特化型のワークフローを提供している。

Amazonは、QuickとAgentCoreがスキーマの柔軟性やガバナンスを制限せずに統合作業を減らすことを示さなければならない。競合他社は、文書から検証済みのポートフォリオ分析へ至る同等に一貫した道筋を示す必要がある。

Amazonの契約インテリジェンスプラットフォームが最も強く主張できる点は、モデルの新規性ではなくアーキテクチャにある。検索、抽出、検証、計算がそれぞれ別の仕事であることを認識している。

この認識は、エンタープライズチームに実践的な判断基準を与える。RAGは原文箇所の発見と説明に使う。構造化レコードは、件数集計、並べ替え、比較、合計に使う。

そして、誤った回答が法的または財務上の判断を変えてしまう箇所にレビュー統制を置く。モデルの信頼度スコアが、その判断を自動的に迂回してはならない。

契約AIを評価するチームにとって、次のステップは代表性のあるパイロットだ。難しい文書を選び、必要なフィールドにラベルを付け、受け入れしきい値を定義し、レビュアーの負荷を測定する。

すべての回答を出典まで追跡できるかを問う。ユーザー、契約、ダッシュボード、チャットセッションをまたいで権限をテストする。修正や修正契約の後に集計値を再計算する。

最も重要なのは、ハイブリッドアーキテクチャを置き換える対象のプロセスと比較することだ。隠れたエラーを減らし、防御可能な監査証跡を備えた、より最新のポートフォリオデータを生み出せるだろうか。

それこそが重要な検証である。Amazonの契約インテリジェンスプラットフォームは、1件の契約書から説得力のある回答を出すだけでなく、ポートフォリオ全体を信頼性高く照会可能にしたときに成功する。