社内AI検索の情報漏洩を防ぐには｜AWSがRAGのアクセス権をリアルタイム照合

AWSは2026年10月7日、Amazon QuickとAmazon Bedrock Knowledge Basesで、文書のアクセス権を検索時に確認する仕組みを解説しました。SharePoint、Google Drive、Confluenceなどの社内情報をAIに検索させるRAGでは、回答の正確さと同じくらい権限管理が重要です。

一般的なRAGでは、文書の内容とアクセス制御リスト（ACL）を定期的に検索インデックスへ同期します。しかし、社員の異動や共有設定の変更が起きると、インデックス側の権限が古くなり、すでに閲覧権限を失った文書が検索候補に残るおそれがあります。

【RAGで情報が漏れる経路】RAGは質問に関連する文書を検索し、その抜粋をAIモデルへ渡して回答を生成します。検索時点で権限のない文書が混入すると、モデルがその内容を回答に反映する恐れがあります。回答生成後のフィルタリングだけに頼らず、検索結果を渡す前にアクセス権を確認することが重要です。

【ACLの同期だけでは不十分な理由】検索インデックスへ権限情報を複製する方式では、共有設定の変更とインデックス更新の間に時間差が生じます。異動した社員が以前の部署の文書を参照できる状態が残るなど、更新遅延による問題が考えられます。

【二段階の権限確認】まずインデックスに保存されたACLで検索候補を絞り込み、次に元の文書サービスへ現在の閲覧権限を問い合わせます。この方式では、検索候補の数を抑えながら最新の権限を反映することを目指します。最終的に許可された情報だけをモデルへ渡すことが設計上の要点です。

【認証情報とユーザーの識別】元データ側の権限を正しく評価するには、誰の代理で検索しているかが明確でなければなりません。共有のサービスアカウントが広い閲覧権限を持つ場合、利用者本人の権限と混同しない仕組みが必要です。ユーザーIDやグループ所属の対応関係も検証対象になります。

【速度と障害時の扱い】検索のたびに外部の文書サービスへ問い合わせると、通信遅延やAPI制限が応答時間に影響する可能性があります。権限確認が失敗したときは、未確認の文書をそのまま回答へ渡さない設計が安全です。失敗率や待ち時間も運用指標として監視する必要があります。

【検証すべきテストケース】共有解除直後、グループからの除外直後、異動後、文書の所有者変更後などに、検索結果が適切に変わるかを試します。権限のある文書を誤って除外しないかも確認し、漏洩防止と検索品質の両面を評価することが重要です。

【仕組みと背景】RAGで検索結果をモデルへ渡す前に権限を確認することは、回答後に機密情報を削除しようとする方法より根本的な対策です。

【導入時の課題】インデックスに保存したACLは、社員の異動や共有設定の変更によって古くなる可能性があります。

【検証と今後】元の文書サービスへ検索時に確認する方式でも、サービス側の権限設定が過剰なら問題は残ります。

【今後の注目点】技術の新しさだけでなく、既存の作業へ無理なく組み込めるか、導入費用に見合う効果があるか、利用者が結果を検証できるかが普及を左右します。実際の運用事例と継続的な評価が、今後の判断材料になります。

AWSの方式は2段階です。まず保存済みACLで検索候補を絞り込み、その後、Google Driveなど元のデータソースへ問い合わせて、利用者が現在その文書を閲覧できるか確認します。許可された文章だけをモデルの参照情報として渡します。

この設計は、AIの回答を生成した後に機密情報を消すのではなく、生成前の情報取得段階で制限するものです。組織のデータ管理では、権限の正本をどこに置くかという設計判断が重要になります。

ただし、実際の適用範囲はコネクターや設定に依存します。検索権限の確認だけで、プロンプトインジェクション、誤回答、過剰な権限付与まで解消できるわけではありません。