30秒サマリー
- AWSの公式ブログがAmazon Bedrock Knowledge Basesを活用した契約書検索AI「AIDA」のアーキテクチャを詳説
- 「暗黙的フィルタリング」と「明示的フィルタリング」の二段構えでLLMへ渡す候補チャンクを絞り込み、精度を大幅改善
- AI生成の契約解釈は必ず法律専門家がレビューすることを前提とした意思決定支援ツールと明記
何が起きたか
AWSは公式のMachine Learning Blogにおいて、エンターテインメント・メディア業界向けに開発されたAI契約管理ソリューション「AIDA（AI-Driven Annotation）」の実装アーキテクチャを解説した。AIDAはAmazon Bedrock Knowledge Basesを基盤としたRAG（検索拡張生成）アーキテクチャを採用し、大量の契約書リポジトリに対して自然言語で問い合わせできる仕組みを提供している。
システムの核心は、ベクトル検索の前段に「暗黙的フィルタリング（Implicit Filtering）」と「明示的フィルタリング（Explicit Filtering）」を組み合わせる二段階の絞り込みにある。暗黙的フィルタリングは、契約当事者・発効日・終了日・準拠法・管轄地域などの構造化メタデータをドキュメントごとに付与（1件あたり最大10KB）し、セマンティック検索を実行する前に候補文書を自動的に絞り込む。明示的フィルタリングはアプリケーション層で一律に適用され、地域規制への準拠・機密分類レベルの制限・時間的制約（例：過去2年以内の有効契約のみ）といったビジネスポリシーをユーザー入力に依存せず強制する仕組みだ。
セキュリティ面では、通信をHTTPS/TLS 1.2以上で暗号化し、AWS IAMによるロールベースアクセス制御、Amazon Bedrock Guardrailsによるプロンプトインジェクション対策やPII保護、Amazon CloudWatchによる監査ログを実装している。最終的な回答はソース文書への参照情報とともに返却され、ハルシネーションリスクの低減を図っている。なお同ブログは「AIが生成した契約解釈は業務判断に使用する前に必ず資格を持つ法律専門家がレビューすべき」と明記しており、AIDAは法的専門知識を代替するのではなく補完する意思決定支援ツールと位置付けられている。
原典ハイライト
AWSブログは、RAGシステムの根本的課題として「意味的に関連する候補チャンクが数百件に及びうるが、Amazon Bedrockのセマンティック検索が返す候補チャンクの上限は100件であり、そこから漏れた候補チャンクが重要な文脈を含む可能性がある」点を指摘。重要条項の見落としや不正確な回答につながりうるこの問題を解消する手段として、メタデータによる事前絞り込みとセマンティック検索の二段階処理が「標準的なRAG実装と区別される核心的アーキテクチャ」と説明している。
出典: AWS Machine Learning Blog（公式ブログ）
So What?（なぜ重要か）
編集部の見方として、RAGを法務文書に適用する際に単純なベクトル検索だけでは精度が構造的に不十分になる問題をAWSが公式に認め、具体的なアーキテクチャとして解決策を示した点は注目に値する。メタデータ設計とフィルタリング戦略が、LLMそのものの性能よりも先に解決すべきエンジニアリング課題であることが明確になっており、法務DXにおけるAI導入の実装論が一段と具体化したといえる。
日本企業への示唆
日本企業が社内契約管理システムにRAGを導入する際、まず「どのメタデータ項目を契約書に付与するか」の設計が検索精度を左右する。準拠法・管轄・有効期限・契約種別などの属性定義を先行して標準化しなければ、AIDAと同様のフィルタリング効果は得られない。また明示的フィルタリングは、部門別アクセス制限や機密レベル管理といった社内情報管理ポリシーをAIシステムに組み込む有効な手法であり、コンプライアンス担当者とITが連携してフィルタ設計を行う体制整備が先決となる。AI出力の法律専門家によるレビュー義務化については、社内規程への明文化を検討すべき事項といえる。
背景・経緯
大量の契約書管理は、エンターテインメント・メディア産業を中心に長年マニュアル作業に依存してきた。RAGを活用したAIによる契約分析は有望な解決策として注目されているが、法律文書特有の高い文脈依存性（例：同じ更新条項でも準拠法によって解釈が異なる）が、汎用のセマンティック検索では精度を担保しにくいという課題がある。AWSはAmazon Bedrock Knowledge Basesにメタデータフィルタリング機能を提供しており、本ブログはその実践的活用事例として位置付けられる。
