AWSは、大量の賃貸借契約を対象にコンプライアンス上の質問を行うためのAmazon Quick参照設計を公開した。注目すべき点は、厳密な引き継ぎの仕組みだ。チャットモデルは固定されたツールを選び、その応答を説明する。一方、別のルールエンジンが対象母集団を定義し、各契約の判定を行う。 10月2日の記事 と サンプルリポジトリ が説明するのは教育用の概念実証であり、検証済みの法務コンプライアンスサービスではない。

エンジニアやコンプライアンス責任者にとっての問いは、この境界が審査対象の判断に適しているかどうかだ。サンプルでは合成した賃貸借契約と、架空の規則や引用を使用している。例示された合計値は意図する出力形式を示すにとどまり、実際の契約や法律に対する正確性については何も証明しない。

大きな変化

  • 何が変わったか： AWSのサンプルは、AIを固定された審査ツールへの制御されたインターフェースとして使う。列挙された賃貸借契約の母集団については、ルールエンジンが判定結果を決める。
  • なぜ重要か： バージョン管理されたルールと証拠を記録した処理レシートにより、レビュー担当者はチャットの外で選択された記録がどのように評価されたかを確認できる。
  • 今後の注目点： 処理レシートが検証できるのは、選択された母集団の処理結果までだ。在庫一覧、情報抽出、法的ルールを正しいと証明するものではない。利用企業はそれらの入力、ユーザーの識別方法、自社データでの性能を確認しなければならない。

プロンプトより先に対象母集団を定める

ユーザーはQuickに、指定日の遅延損害金ルールに違反するテキサス州の賃貸借契約を尋ねられる。Quickはその依頼を sweep_complianceという6つの名称付きMCP操作の一つに振り分ける。この操作は、指定された管轄区域と日付を使って対象母集団と適用するバージョン管理済みルールを選ぶ。モデルがSQLを記述したり、条項が基準を満たすかを判定したりするわけではない。ルールエンジンが固定された比較演算子を適用し、ルール値はパラメーターとして渡される。AWSによると、正式な一括処理ではモデルを参照しない。 AWSはこのページで操作の契約を説明している。実装については リポジトリが説明している。

ほかのツールの用途はさらに限定されている。 simulate_rule_change は、提案された値の探索用集計を行うが、判定結果を記録しない。 explore_clauses は、絞り込んだサンプルを意味的類似度で順位付けするもので、「何件あるか」という質問には答えられない。 get_finding は一つの証拠の連鎖を取得し、 list_rules は指定日に有効なルールを表示し、 check_connection は接続状態を確認する。この違いは重要だ。関連性の高い条項のサンプルは、全件調査ではない。

一括処理では、読み取った全レコードを「準拠」「違反」「曖昧」「判読不能」の4分類のいずれかに割り当てた処理レシートが作成される。記録を確定する前に、エンジンは各分類の合計がスキャンした総数と一致することを検証する。Quickは件数と少数のサンプルを表示でき、Quick Sightダッシュボードは同じAuroraデータストアから全件の判定結果を読み取る。判定結果には条項の文面、抽出値と期待値、ルールのバージョン、引用が含まれる。これらはAWSサンプルの設計上の特徴であり、BIG CHANGEが実行したり独自に検証したりした結果ではない。

処理レシートが対象にするのは選択された母集団だ。元の在庫一覧にすべての契約が含まれているか、抽出で関連条項を漏れなく正しく取得したか、ルールが現行法を反映しているかは示せない。それぞれ別途、データ照合、抽出結果のレビュー、法務承認が必要だ。「テキサス州の全契約」という分母が不確かな場合、件数が正確でも対象集合を取り違えている可能性がある。

構築に必要なもの

この サンプル構成 では、Quickのチャットエージェントの前段に、AWS Lambda上のMCPサーバーを置いている。Amazon Cognitoがサービス用トークンを発行し、API Gatewayがそれを検証する。LambdaはRDS Data API経由でAurora Serverless v2の読み書きを行う。Quick SightはVPC接続を通じて同じデータベースにアクセスする。AWSは探索的な条項検索ツールにBedrockの埋め込みモデルと言語モデルを割り当て、正式な一括処理は決定論的なままにしている。

公開された例は、架空の5万件の契約データ、バージョン管理されたルールブック、デプロイ済み構成に対して28項目を実行するとAWSが説明する受け入れテスト用スクリプトで構成される。リポジトリは、コードが本番利用向けではないこと、法務内容が架空であること、実際の入居者データには追加のセキュリティテストと独立した法的検証が必要なことを明記している。私たちはドキュメントとリポジトリの説明を確認したが、構成をデプロイしたり、テストを実行したり、チャットエージェントのツール振り分けを試したりはしていない。

応用する際は、まず正式な記録の一覧と、対象に含める条件を厳密に定める。そのうえで、どの項目を信頼できる形で抽出できるか、どのルール比較を機械的に処理できるか、誰が各ルールのバージョンを承認するかを決める。レビュー担当者が結果を再構成できるよう、原文、抽出ステータス、ルールのバージョン、担当者、比較値、日付、判定IDを保存する。チャット応答とは別に、処理レシートと正式な契約一覧を照合する。これらはサンプルが示す保証と限界に基づく設計上の確認事項であり、私たちが試験した手順ではない。

AWSによると、Cognitoのクライアント認証フローで発行するトークンはQuickアプリケーションを識別するもので、チャットで質問した人を識別しない。サンプルでは、Quickの監査レイヤーと一括処理IDおよび時刻を照合してユーザーを特定する。コンプライアンス用データストア自体にその識別情報を記録する必要がある場合、AWSはエンドユーザーIDを渡して保存する方法を提案している。判定結果だけで監査記録として成立させたいチームは、導入前にこの設計を決めるべきだ。

アクセス、制限、コスト

AWSの手順は、AWSアカウント、設定済みのAWS CLI v2認証情報、Python、CDK用のNode 24、 us-east-1内のモデルアクセス、さらにMCPコネクターとQuick Sightを備えたAmazon Quick環境を前提としている。記事ではPython 3.12としているが、リンク先のREADMEにはPython 3.9以降とある。ローカル環境を決める際は、リポジトリの最新要件を確認する。サンプルの手順ではCDK CLI 2.261.0を固定しているが、これはサンプルの依存関係であり、AWS全般に必要なバージョンではない。

最新の Quick MCPガイド では、各操作のタイムアウトを60秒に固定し、1つのサーバー接続当たり最大100個のツールを許可し、独自のHTTPヘッダーは送信しないとしている。大規模な一括処理では、このタイムアウトを実際の負荷で検証する必要がある。データベースの長時間処理が正しく実行できても、コネクターの制限を超えれば同期型Quick操作として完了できない。同ガイドによれば、カスタムコネクターのツール一覧は Syncで更新できる。一方、AWSのブログ記事とサンプルREADMEでは、ツールを変更した際に統合を削除して作り直すよう案内している。現在のコネクターについては最新のQuickドキュメントに従い、自分の環境で登録済みツール一覧と振り分けを確認する。

これは複数のサービスを組み合わせる構築であり、公表資料から根拠のある「一括処理当たりの料金」を一つ示すことはできない。AWSの Quickの料金ページ ではサブスクリプションとエージェント稼働時間の条件を分けており、一部機能にはQuick Sightの追加料金も記載されている。 Auroraの料金 は容量、ストレージ、I/Oの構成によって変わる。サンプルは停止時にゼロへ縮小せず、最低0.5 ACUを稼働させる。API Gateway、Lambda、探索用のBedrock呼び出しもワークロードに応じた見積もりが必要だ。リポジトリは継続課金を避けるため、評価後にスタックを削除するよう勧めている。この記事のためにAWSリソースは作成していない。

意思決定のチェックリスト

この方式を採用するのは、自社データと管理方法に基づいて、次の問いに答えられる場合に限る。

  • レビュー済みの安定した条件で対象母集団の全件を列挙し、正式な一覧と照合できるか。
  • ルールは承認済みバージョン、適用日、引用を備えた機械的な比較か。人の確認に回すべき曖昧なケースはどれか。
  • 抽出失敗や判読不能な文書を、黙って除外せず件数に含められるか。
  • 各判定に原文の条項、比較値、ルールのバージョンが保持され、チャットの外で証拠一式を取得できるか。
  • 一括処理をQuickの操作タイムアウト内に完了できるか。また、結果を依頼者本人まで追跡するにはどうすればよいか。
  • 想定する処理量でサブスクリプション、データベース、各サービスの料金を見積もり、使用を許可されたデータで性能と判定品質を検証したか。

このタスクに法的解釈や、範囲の定まらない基準への判断が必要なら、決定論的な合否ラベルによって、人が下すべき判断そのものが見えなくなるおそれがある。代表的な事例を知りたいだけなら、意味検索の方が簡単だ。説明責任を負う利用者に、すでにレビュー済みのルールエンジンとダッシュボードを提供しているなら、会話型の仕組みは必須ではない。こうした代替案は、AWS記事の「誤った選択」についての説明と、合成データを使ったサンプルの限界から導かれる。

出典・参考資料