数百件の取引先契約をPDFで管理していて、更新日や支払条件の棚卸しに毎回時間を取られているなら、この記事が参考になるかもしれません。法務・調達チームの手作業を置き換えるために、AWSが「AgentCore」というエージェント運用基盤を使った契約書処理パイプラインの実装ガイドを公開しました。本記事では、このアーキテクチャを自社基盤に導入するかどうかを、SRE・インフラ目線の判断軸で整理します。
AgentCoreは、Amazon Bedrock（AWSが提供する生成AIの基盤モデルをAPI経由で呼び出すサービス）を使ったエージェント群を調整する実行基盤です。単発の質問に答えるチャットボットとは違い、抽出・検証・集計という3段階のパイプラインを常時運用する仕組みになっています。既存のRAG（文書検索で得た情報を生成AIの回答に反映させる手法）チャットが「1契約書への質問」しか扱えないのに対し、このパイプラインは「全契約書の年間SaaS支出合計は」といったポートフォリオ横断の集計に対応します。
この違いは、運用の重さにそのまま跳ね返ります。チャットボット1台の運用と、並列実行するエージェント群・状態管理・検証ロジックを含むパイプラインの運用では、必要な監視項目もインシデント対応の複雑さも桁違いです。導入前にどこを見るべきか、判断軸ごとに整理します。
どんな場面で判断が必要になるか
想定される場面は大きく2つあります。ひとつは、法務・調達部門から「契約書管理を自動化したい」という要望が来て、インフラチームが実現可能性を見積もる場面です。もうひとつは、既存のRAGチャット型の契約書検索ツールを運用していて、集計系の問い合わせに応えられず拡張を迫られる場面です。
どちらの場面でも、導入するのは単なるAI機能ではなく「エージェントが並列に動く分散システム」だという理解が出発点になります。ここを見誤ると、小さなPoC（概念実証）が終わったあとの本番運用で想定外の運用負荷に直面します。
判断軸1: 状態管理とスケーリング方式
このパイプラインでは、抽出エージェントが契約書ごとに独立したタスクとして動きます。オーケストレーター（全体の実行順序を管理する制御層）はDynamoDBにタスク状態を書き込み、S3の名前空間を分けてエージェント同士の衝突を防ぎます。つまり状態管理の設計がIaC（Infrastructure as Code）でどこまで再現可能かが最初の判断軸です。
具体的には、Lambda関数やECSタスクを増やせば500件の契約書を並列処理できるとされていますが、これはTerraformやPulumiでインフラをコード化していることが前提の話です。DynamoDBのテーブル定義、S3バケットのライフサイクルポリシー、Lambdaの同時実行数上限（Concurrency Limit）をコードで管理できていないと、スケールアウトのたびに手作業設定が発生し、再現性のない環境ができあがります。
既にTerraformでAWSリソースを管理している組織であれば、この部分は既存のモジュール構成に素直に乗せられます。一方、コンソール操作中心でインフラを管理している組織は、導入前にIaC化から着手する必要があり、その工数を見積もりに含めるべきです。
判断軸2: SLOをどこに設定できるか
2つ目の判断軸は、SLO（Service Level Objective、サービスが満たすべき品質目標）を定義できる箇所があるかです。抽出エージェント・検証エージェント・Amazon Quick（自然言語での問い合わせをSQLに変換して実行するクエリ層）という3層構成では、それぞれ性質の異なる指標が必要になります。
抽出エージェントには「1契約書あたりの処理時間」「抽出成功率」が、検証エージェントには「人間へのエスカレーション率」「確信度スコアの分布」が、Quickには「クエリ応答時間」「SQL変換の成功率」が対応します。単一のSLAで「契約書処理は24時間以内」とだけ決めても、どの層がボトルネックかを切り分けられません。
特に見落とされがちなのが、検証エージェントが人間に処理を差し戻す「human-in-the-loop」フローです。ここが詰まると契約書全体のパイプラインが停止したように見えますが、実態はシステム障害ではなく業務プロセス側の滞留です。SLOを層ごとに分けておかないと、オンコール担当者が誤ってシステム側の障害対応に時間を使ってしまいます。
判断軸3: オブザーバビリティの設計コスト
3つ目は、監視すべきテレメトリの種類が通常のWebアプリより多いという点です。抽出エージェントが書き出す確信度スコア、検証エージェントが残す「決定ログ」（S3に保存される監査証跡）、DynamoDBのタスク状態遷移は、いずれもログ・メトリクス・トレースのどれかに分類して可視化する必要があります。
たとえば、ある契約書の金額表記が「$1.2M annually」と「$1,200,000 per year」のように複数のエージェントで食い違った場合、どちらが採用されたかを追跡できないと、法務チームからの問い合わせに答えられません。この決定ログをCloudWatch LogsやS3経由でトレーシング基盤に統合し、契約ID単位で横断検索できる状態にしておくことが、障害対応の仕組み化につながります。
既存の分散トレーシング基盤（AWS X-Rayや、Datadog・New Relicなどのサードパーティ製品）を運用しているなら、エージェントのタスクIDをトレースIDに紐づける設計を追加するだけで済みます。何も導入していない場合は、このオブザーバビリティ層の構築自体が追加プロジェクトになる点を見積もりに含めるべきです。
判断軸4: コストの構造
4つ目はコストがエージェントの呼び出し回数とBedrockのトークン消費に比例するという構造です。500件の契約書を並列処理する場合、抽出・検証の2段階でBedrockの推論が最低でも1000回発生します。契約書が長文であればトークン数も増え、コストはリニアに積み上がります。
ここはLambdaやECSの計算コストより、Bedrockの推論コストが支配的になりやすい部分です。コスト最適化の観点では、確信度スコアが高い契約書は軽量モデルで処理し、曖昧な契約書だけ高精度モデルにエスカレーションするような、モデルの使い分け設計が効いてきます。
選択肢の比較
契約書処理を自動化する手段は、このマルチエージェント構成だけではありません。既存の選択肢と比べて整理します。
| 選択肢 | 向いている規模 | 運用負荷 | 集計クエリへの対応 |
|---|---|---|---|
| 単発RAGチャット | 数十件程度 | 低い | 不可 |
| AgentCore型マルチエージェント | 数百件以上 | 高い(分散システム運用) | 可能 |
| 人手+スプレッドシート | 数十件未満 | 中(属人化しやすい) | 限定的(手作業集計) |
ケース別の推奨
契約書が100件未満で、かつ更新日の確認程度しかニーズがないなら、単発RAGチャットかスプレッドシート管理で十分です。マルチエージェント構成を導入する運用コストの方が上回ります。
契約書が数百件規模で、かつ「ベンダー横断の支出合計」「契約更新のリスク一覧」のような集計系の問い合わせが月次・四半期で発生するなら、マルチエージェント構成の検討価値があります。ただしIaCでの再現性、SLOの層別設計、オブザーバビリティ基盤の3点が社内に揃っているかを先に確認すべきです。
すでにTerraform・CloudWatch・DynamoDBの運用実績があるチームなら、追加で必要なのは検証ロジックとAmazon Quickとの接続部分だけで済み、導入のハードルは比較的低くなります。
あえて見送るべき条件
次のような条件に当てはまる場合は、導入を急がないほうが安全です。
- オンコール体制が1〜2名で、分散システムの障害切り分けに割ける人員がいない
- IaCでのインフラ管理がまだ整備されておらず、手作業デプロイが中心になっている
- 契約書の形式がスキャン画像中心で、OCR精度の検証にまとまった工数を割けない
- 人間へのエスカレーション(human-in-the-loop)フローを受け止める法務側の体制が未整備
特に最後の点は見落とされがちです。検証エージェントが確信度の低い契約書を人間に差し戻しても、受け取る側の体制がなければ、差し戻しキューが積み上がるだけの状態になります。
まとめ
契約書のマルチエージェント処理は、単なるAI機能の追加ではなく、状態管理・SLO・オブザーバビリティ・コストの4点を備えた分散システムの運用そのものです。導入を検討する際は、まず自社のTerraformやCloudWatchの整備状況を棚卸しし、DynamoDBでの状態管理パターンに慣れているかを確認してください。
次の一歩としては、契約書のサンプル10〜20件で小規模なPoCを組み、抽出エージェントの確信度スコアの分布とエスカレーション率を実測することをおすすめします。この数値が、本番導入時のSLO設計とコスト見積もりの土台になります。