公開：2026年10月3日, 最終更新：2026年10月3日
30秒サマリー
- AWSが数万件の賃貸契約を法令遵守審査するAIアーキテクチャ「Adjudicated Queryパターン」の実装方法を公式ブログで詳説
- 生成AIは自然言語の翻訳と結果の読み上げのみを担い、合否判定は決定論的なルールエンジンが行う設計で監査対応・証拠保全を実現
- RAGやText-to-SQLでは達成できない「全件審査の証明可能性」と「後日の訴訟・監査への防御可能性」を両立させる点が核心
何が起きたか
AWSは公式の機械学習ブログで、大量の賃貸契約書を州法の変更に合わせてコンプライアンス審査するためのリファレンスアーキテクチャ「Adjudicated Queryパターン」の実装方法を解説した。記事は同パターンを、制裁スクリーニング・保険金査定・輸出規制など他のハイステークスなコンプライアンス領域にも適用可能としており、賃貸契約審査は具体例として用いられている。なお、原文ではチャットインターフェースのサービス名を一貫して「Amazon Quick」と表記しており、本記事もその表記に従う。
同パターンの核心は役割の厳格な分離にある。Amazon Quickのチャットエージェントは、ユーザーの自然言語による質問を受け取り、あらかじめ定義された6種類の固定オペレーション（sweep_compliance・simulate_rule_change・explore_clausesなど）への呼び出しに変換し、返ってきた結果を読み上げる役割のみを担う。合否の判定そのものは、AWS Lambda上に構築された決定論的なルールエンジンが担当し、生成モデルはこのプロセスに関与しない設計となっている。Amazon Bedrockは、条項の意味的類似検索という「探索的」な用途にのみ使用される。
監査対応の観点から重要なのが「コンプライアンス・レシート」の仕組みだ。審査実行のたびに「適合＋違反＋曖昧＋読取不能＝スキャン総数」という不変条件をSQL集計で検証し、全件が一意のバケットに分類されることを確認してからデータが確定される。この計算が成立しない場合、審査は完了扱いにならない。これにより「全件を審査した」という主張を数値で証明できる。ルールは法改正のたびにコードではなくデータとして更新され、判定結果は追記のみで上書き・削除は設計上行えない構造になっている。
インフラ構成は、Amazon Quick（チャット・Amazon QuickSightダッシュボード）、Amazon Cognito（OAuth認証）、Amazon API Gateway、AWS Lambda（MCPサーバー＋ルールエンジン）、Amazon Aurora Serverless v2（PostgreSQL＋pgvector）、Amazon Bedrockで構成される。生成モデルはAmazon Titan Text Embeddings V2とAnthropic Claude Sonnet 5が使用される。完全なリファレンス実装はGitHubで公開されており、合成データや受け入れテストが含まれている。
原典ハイライト
原文が最も強調するのは「モデルを意思決定経路から除外しつつ、チャットという配信経路に戻すことで生じるリスク」への対処だ。ブログはモデルが注意書きの接頭辞を除去して架空の法令を提示した事例、サンプル20行から全件の傾向を推測した事例を実際の観察として挙げ、ペイロード内の注意表示を複数の構造レベルで繰り返し埋め込む手法を推奨している。「ペイロード内の安全策は、言い換えを生き延びられる強さしか持たない」という原則を提示している点が核心。
出典: AWS Machine Learning Blog（公式ブログ）
So What?（なぜ重要か）
編集部の見方として、このパターンが示す重要性は「AIを使いながらAIに責任を持たせない設計の実用化」にある。RAGやText-to-SQLでは、検索漏れや述語のハルシネーションによって対象母集団が暗黙的に絞り込まれるリスクがあり、その結果は一見正確に見えるため発見が困難だ。一方、Adjudicated Queryパターンはモデルの役割を「翻訳」と「読み上げ」に限定することで、このリスクを設計レベルで排除する。コンプライアンス領域でAIを活用する際の「証明可能性」と「防御可能性」という二つの要件を同時に満たすアーキテクチャの雛形として参照価値が高い。
日本企業への示唆
日本企業への示唆として、まず法務・コンプライアンス部門がAI導入を検討する際の設計原則として活用できる。同パターンは「AIは問いを翻訳し、結論は人間が設計したルールエンジンが出す」という役割分担を徹底しており、個人情報保護法対応や契約管理、社内規程の大量チェックなど、日本国内の法令遵守業務にも転用可能な考え方だ。次に、監査や訴訟を想定した「証跡の設計」という観点が重要で、ルールをコードではなくデータとして管理し、判定結果を追記専用にすることは、日本の内部統制や金融機関の検査対応にも直接応用できる。経営者・CIOは「AIが正しい答えを出す」ではなく「AIが間違えても組織が守られる設計か」を問い直す契機としたい。
背景・経緯
原文によれば、数万件規模の賃貸契約を複数の州法に照らして一斉審査することは、法改正のたびに対象件数が変わり、しかも「全件審査した」ことを証明する必要があるため、従来の人的審査では限界があったとされる。RAGは全件性を構造的に保証できず、Text-to-SQLはハルシネーションによる母集団の縮小リスクがある。この課題背景から、決定論的ルールエンジンとチャットUIを組み合わせた本パターンが提案されたと説明されている。
