先に結論
契約をAIで探せても、「対象を一件も漏らさず確認した」と説明できるとは限らない。AWSが公開した賃貸契約の適合性確認例を基に、会話型AIに任せる仕事、ルールで確定する仕事、担当者がなお確認すべき仕事を分けて考える。 対象を正確に列挙でき、判定規則を明文化できる場合に採用を検討する。AWSのAdjudicated Queryは、自然言語の質問を限定された操作へつなぎ、適合・違反の判定を決定的なルールエンジンに任せる設計だ。会話のしやすさを加えながら、判定の母集団と証跡を別の仕組みで管理する。
GLOBAL AI BRIEF ・ PROCESS
会話の質問は、どの境界を通って全件確認の証跡と明細へ届くのか
- STEP 01Amazon Quickで質問操作を選択
- STEP 02限定されたMCP操作正式判定と探索を区別
- STEP 03ルールエンジン定義済みの対象を判定
- STEP 04四区分の合計を検査処理件数と照合
- STEP 05チャットで集計を確認ダッシュボードで明細を見る
ただし、全件を処理したという証跡は、最初に定めた対象集合の内側で成立する。そもそも対象契約の抽出条件が争われる案件や、条項の妥当性に人の解釈が要る案件では、この方式だけで結論を確定できない。
AWSの発表は何を示したか
AWSの一次情報は、複数の州にまたがる賃貸契約を題材に、Amazon Quickのチャットと判定エンジンを組み合わせる参照構成を説明している。Amazon Quickは業務利用者が質問し、結果を確認するための画面を提供する。記事は、合成データを使う実行可能なサンプルにも案内している。
想定場面は、州ごとに異なる賃貸関連の規則が変わったとき、保有する契約のうち再確認が必要なものを探す作業だ。AWSは例として、複数州に計50,000件の契約を持つ事業者を挙げる。この数字は説明用の設定であり、日本企業の標準的な契約量や導入効果を示すものではない。
記事が重視する要件は二つある。第一に、母集団の定義を示したうえで対象を漏れなく処理したと証明すること。第二に、後から個別の判断を問われても、適用した規則の版、条項、比較した値、処理方法と日時をたどれることだ。後者は単に結果の一覧を保存するだけでは満たせない。
検索で見つけることと、全件を判定することは違う
RAGによる類似検索は、関連しそうな条項を探す用途に向く。一方、順位付きの検索結果は上位に出なかった契約を数え上げる仕組みではない。AWSの設計上、検索結果の順位では全件を証明できない。見つかった例が妥当でも、見つからなかった対象がゼロとは言えないためだ。
自然言語からSQLを生成する方法なら件数を返せる。しかしAWSは、生成された抽出条件が誤って母集団を狭めても、結果の数字だけは正確に見える危険を挙げる。この指摘は、すべてのtext-to-SQLが不適切という評価ではない。生成された条件を人が検証でき、誤りを許容できる用途かどうかが分かれ目になる。
ルールエンジンとBIを直接使う構成も比較対象だ。AWSによると、全件性と追跡可能性を保つだけなら、この構成でも足りる。Adjudicated Queryが追加するのは、責任ある利用者が自然言語で質問し、確定済みの処理結果へ到達できる窓口である。
| 方法 | 対象範囲の扱い | 判断時の注意 |
|---|---|---|
| RAGによる類似検索 | 順位付きの標本を返す | 代表例の探索には使えても、漏れのない件数判定には使わない |
| 生成SQL | 生成した条件次第で変わる | 抽出条件を検証できる体制が要る |
| ルールエンジンとBI | 定義済みの対象を全件処理する | 会話画面が不要なら候補になる |
| Adjudicated Query | 定義済みの対象を全件処理する | 会話画面の要約と、元の証跡を併せて確認する |
会話型AIに許される操作はどこまでか
この構成では、モデルは質問を型の決まった操作へ振り分け、戻った結果を説明する。対象集合を決めるSQLを書いたり、規則への適合を自身で判定したりしない。AWSのサンプルがMCPサーバーに公開するのは、六つの操作に限定される。
全件の適合性を調べるsweep_complianceは公式の判定として結果を記録する。simulate_rule_changeは規則の値を仮に変えた場合の方向性を調べる操作で、判定結果を記録しない。explore_clausesは意味の近い条項を上位から示す探索であり、総件数を答える操作ではない。
残るget_findingは一件の判定根拠を開き、list_rulesは指定日時に有効な規則と版を参照し、check_connectionは接続状態だけを確認する。利用者の質問がどの操作に流れたかを確認することが、表示された答えの意味を読み違えないための第一歩になる。
判定エンジンは、以上・以下・一致・存在といった比較演算を使い、規則の値は版を持つデータとして管理する。AWSの説明では、法令変更への対応は管轄地域ごとの分岐をコードに増やす方法ではなく、規則表の行を変更する方法を取る。自然言語をそのままSQLへ渡さない境界もここにある。
「全件を見た」は何で確かめるのか
各実行では、適合、違反、曖昧、読取不能という四区分を集計する。四区分の合計が処理件数と一致することを、結果の保存前に検査する。読めない契約を一覧から消さず、読取不能として残す点が重要だ。数字が合わない処理は正常終了させない設計として紹介されている。
ただし、この一致が証明するのは「指定した母集団の各レコードがいずれかの区分に入った」ということに限る。契約台帳に登録されていない契約、誤った州分類、誤った対象期間まで検出する保証ではない。処理前の分母をどう確定したかは、別に説明できなければならない。
AWSの参照構成では、チャットとAmazon Quick Sightのダッシュボードが同じAuroraのデータ保管先を参照する。チャットには件数、全件確認の証跡、結果の一部とダッシュボードへのリンクを返し、大量の明細はダッシュボードで確認する。要約画面にすべての行を表示しないことと、元データを省略することは別だ。
記事中の合成データによる画面例には、違反10,111件、曖昧689件、読取不能20件が示される。これはサンプルの表示結果であり、実際の顧客契約や日本の賃貸市場で観測された件数ではない。件数だけを転載して精度や削減効果を論じることもできない。
判定の根拠と、回答の言い換えを分けて見る
一件の明細には、契約条項、適用した規則の版と出典、抽出した値、求められる値を対応させる。AWSは判定記録を追記型とし、後から判断を説明できるようにする構成を示す。実務では、一覧の件数から個別の根拠へたどれるかを確認したい。
もう一つの論点は、判定が正しくてもチャットが結果を言い換える際に注意書きを落とす可能性だ。AWSは、サンプルを全体傾向と誤認して説明した例や、例示用の出典表示が言い換えで失われた例を挙げる。対策として、注意書きと操作の種別を複数の位置に置き、全件から計算した集計値をモデルへ渡す設計を説明している。
この対策は、言い換えによる誤読を減らすための設計であって、すべての表示が正しくなる保証ではない。利用者が重大な判断に使うときは、チャットの文章だけで完結させず、全件確認の証跡と個別明細を開いて照合する運用が要る。
また、サンプルの機械間認証トークンは、チャットで質問した個人を判定エンジンへ直接伝えない。利用者の特定はAmazon Quickの監査記録との照合に依存する構成だ。判定用データベース自体に実行者を残す必要がある組織なら、利用者IDを操作へ渡して保存する追加設計が必要になるとAWSは説明している。
日本企業が採用を判断する順番
最初に確かめるべきは製品の選択ではなく、対象集合の定義だ。どの契約、期間、拠点、規則を一回の確認に含めるかを、後から第三者が再現できる条件で書けるか。分母を正確に定義できる案件だけ、全件証跡を判断材料にする。条件が曖昧なままでは、処理の合計が一致しても誤った集合について正確な数字を出すだけになる。
次に、規則を比較演算で表せる範囲を切り分ける。数値の上限や通知日数のように明文化できる条件と、条項の公正さのように解釈を要する条件を同列に扱わない。後者には人による法的判断を残す。AWS自身も、主観的な判断を決定的な規則へ押し込むことを不適切な適用例としている。
そのうえで、探索、仮定の試算、正式な全件判定を画面と記録上で区別する。担当者が探索結果を正式な判定件数と取り違えない表示になっているか、曖昧・読取不能の件数が見えるか、規則の承認者と版を追えるかを確認する。ここまでが、この発表から導ける導入前の確認項目だ。
会話による質問が業務上必須でないなら、ルールエンジンとBIだけを比較候補に入れる。逆に、全件性を求めない条項探索ならRAGで足りる場合がある。追加する構成要素に見合うのは、見落としが問題になり、結果を後日説明する責任がある仕事だ。
適用しない条件と未検証範囲
この方式を避けるべき条件は、判断基準が本質的に主観的な場合、全件確認を必要としない場合、対象集合を厳密に列挙できない場合だ。いずれもAWSの記事が挙げる制約である。全件確認の証跡は、規則そのものの法的妥当性を承認する仕組みでもない。
公開されたサンプルは合成契約と例示用の規則・出典を使う。実契約へ移す前に、組織ごとのデータ分類、アクセス権、規則内容の法的確認が必要だとAWSは明記する。本記事はサンプルを実行しておらず、表示例や設計説明を独立に再現した結果として扱わない。
実運用の性能、費用、判定精度、法令への適合性は、この一次情報だけでは確認できない。AWSの受入試験の説明も、他社環境や日本の契約書で同じ結果になる根拠にはならない。導入可否は、自社の契約台帳と承認済み規則を使った別途の検証で決める必要がある。
FAQ
会話画面を使えば、質問した人を判定記録から直接特定できますか
AWSのサンプルでは機械間認証を使うため、判定エンジンは個人の利用者IDを直接受け取らない。実行者との対応はAmazon Quickの監査記録と実行ID・時刻を照合する設計である。判定用データベースにも実行者を保持する要件があるなら、追加の実装を検討する。
条項を意味検索した件数を、違反件数として報告できますか
できない。explore_clausesは類似度順の標本を返す探索操作で、正式な全件判定ではない。件数を報告する用途では、対象集合を確定し、sweep_complianceの結果と全件確認の証跡を確認する。
日本の契約書へ、そのまま適用できますか
一次情報に日本の契約書での検証結果はない。サンプルの規則と出典も例示用である。対象契約の列挙、条項の抽出、規則の承認、法的解釈、アクセス管理を自社の条件で確認してから判断する。
出典・確認範囲
出典はAWS Machine Learning Blog「Sweep thousands of leases for compliance using Amazon Quick and the Adjudicated Query pattern」（2026年10月2日公開）。本記事の確認日は2026年10月5日。AWSの公開一次情報に記載された構成と合成データの例を確認範囲とし、第三者による効果検証、実環境での再現、日本法への適用は未検証とする。公式情報やサンプルの仕様が更新された場合は記述を見直す。