Amazon Quickと決定論的ルールエンジンを連携、AWSが契約書検証の新パターン「Adjudicated Query」を公開

要点

• AWSは、生成AIと非AIのルールエンジンを組み合わせて大量の文書を厳密に法令チェックする設計パターン「Adjudicated Query」を発表した。

• 自然言語インターフェースにAmazon Quickを活用し、判定処理そのものは決定論的なルールエンジンに完全に分離して実行する。

• 従来のRAGやText-to-SQLが抱えていた母集団の欠落やハルシネーションによる対象範囲の縮小を防ぎ、全件検証の証明と説明責任を両立する。

• 5万件規模のアパート賃貸契約書の法令チェックを例に挙げているほか、制裁対象スクリーニングや保険金請求査定、輸出管理など高リスク領域にも適用できるとしている。

• AWSは本パターンのリファレンスアーキテクチャと、エンドツーエンドで動作確認が可能なサンプルを公開した。

• 米アマゾン・ウェブ・サービス（AWS）は2026年10月2日、機械学習ブログ（AWS ML Blog）において、大規模なコンプライアンス確認作業を自動化する新たな設計パターン「Adjudicated Query（裁定クエリ）」を発表した。

• 本パターンは、「Amazon Quick」の生成AI機能によるチャットインターフェースと、決定論的（非AI）なルールエンジンを組み合わせた構成をとる。法規制の変更に伴う膨大な文書の確認作業において、監査や訴訟にも耐えうる正確性と網羅性を実現するという。

大規模文書チェックにおける「完全性」と「説明責任」の課題

複数州にまたがり5万件の物件リース契約を管理する不動産事業者を例にとると、各州の賃貸法規（遅延損害金の上限、通知期間、敷金上限など）は議会のスケジュールで随時改定される。規制が変更された際、コンプライアンス担当チームはどの契約が違反状態になったかを特定する必要がある。

契約数が少ない段階であれば専門スタッフが目視で確認し、人間の判断として信頼性を担保できる。しかし、件数が一定規模を超えてソフトウェアによる自動処理へ移行すると、「画面上に表示された数値を第三者が独自に検証できない」という問題が発生する。

この課題を解決するためには、次の2つの特性が不可欠だとAWSは指摘している。

• 証明可能な完全性（Provable completeness）: 「対象となる2万2,910件の契約をすべて確認した」という主張が実証可能であること。未評価のデータは無言で除外されるのではなく、未評価として明示されなければならない。
• 防御性（Defensibility）: 数カ月後に訴訟や監査、規制当局の調査で指摘を受けた際、いつ・誰が・どの条項テキストに対し・どのルールのどのバージョンを・どのような手法で適用したかを正確に説明できること。

既存のAI手法（RAG・Text-to-SQL）における限界

AWSは、こうした要件が通常のエンタープライズ検索と根本的に異なる点であると説明している。

外部知識を検索して回答を生成するRAG（検索拡張生成）はアクセス性の向上には寄与するものの、類似度検索に基づくため「全件を漏れなく網羅した」と言える閾値が存在せず、除外されたデータを把握できない。

また、自然言語からデータベースクエリを生成するText-to-SQLも、AIが誤った条件式（述語）を生成するハルシネーションのリスクを抱える。母集団が勝手に絞り込まれてしまっても、出力される数値自体は一見正確に見えてしまうため、スコープの誤りに気づきにくいという構造的な問題がある。

「Adjudicated Query」パターンの構造と動作

Adjudicated Queryパターンでは、決定論的なルールエンジンの上に、境界を厳密に制限した対話レイヤーを配置するアーキテクチャを採用している。

生成AIモデルの役割を2点に限定

この構成において、生成AIモデルが担う処理は以下の2つのみに制限される。

1. ユーザーからの自然言語による質問を、事前定義された「型付き操作（typed operations）」の呼び出しへと変換する。
2. ルールエンジンから返された結果を自然な文章として説明する。

モデル自身がデータベースクエリを直接記述したり、対象となる母集団を勝手に決定したり、適合・不適合の判定を下したりすることは一切ない。

データとして管理されるルールエンジン

対話レイヤーの背後に置かれるルールエンジンは、プログラムコードではなくバージョン管理されたデータとしてルールを保持する。

エンジン自体は gte（以上）、lte（以下）、equals（一致）、exists（存在）といった汎用的な比較演算子のみを解釈し、特定の管轄区域やトピックを名指しする条件分岐コードを含まない。そのため、法律が改正された場合でもアプリケーションコードの再デプロイは不要で、ルールブックのデータ行を編集するだけで即座に対応できる。

完全性を担保する「レシート」と適用可能領域

本パターンによるコンプライアンス検証では、スキャンごとに「完全性のレシート（completeness receipt）」が生成される。

これは、カウント処理から計算される不変条件であり、「適合（compliant）＋ 違反（in-breach）＋ 曖昧（ambiguous）＋ 読み取り不能（unreadable）＝ スキャン総数」という等式が必ず成立することを永続化処理の前に検証する。母集団の全数が完全に一致しない実行は処理が完了しない設計となっており、特定のレコードが暗黙のうちにスキップされる経路を排除している。

AWSは、今回具体例として示した賃貸契約書の確認にとどまらず、制裁対象者のスクリーニング、保険金請求の査定、輸出管理など、厳格な正確性と監査証跡が求められる各種コンプライアンス領域に本パターンを広く応用できるとしている。あわせて、これらを実装したAWSリファレンスアーキテクチャとエンドツーエンドの実行サンプルを提供している。