RAGの設計では、検索精度と閲覧権限を別々に確認する
正しい資料が見つかっても、その利用者に見せてよいとは限りません。
公式資料確認資料確認:2026年10月3日。人事FAQ例・評価表・権限設計は編集上の提案です。RAG検索・権限制御の実機検証は未実施です。
社内検索AIの回答が正しくても、読めないはずの資料を使っていれば問題です。この記事では、検索の適切さ、回答の根拠、利用者の権限を分けて確認する評価表を作ります。
公式資料から分かること:検索は回答の材料になる
Google CloudはRAGを、検索などで取得した情報を生成の材料へ組み込む構成として説明しています。RAGを使うだけで、取得情報の正しさやアクセス制御が自動的に保証されるわけではありません。
OWASPは、Webサイトやファイルなどの外部内容を通じてモデルの挙動を変える間接的なプロンプトインジェクションを説明しています。文書内の命令風の文章を、権限変更や外部送信の許可として扱わない設計が必要です。
仕事の具体例:同じ質問でも参照できる資料が違う
架空の人事FAQで、一般社員は公開された社内規程、人事担当者は担当案件の資料も読めるとします。一般社員の質問では、許可のない個別案件を生成モデルへ渡さない構成にします。「秘密は答えないで」と後から指示するだけに頼りません。
- 文書のID・版・更新日・アクセス条件を管理し、分割した文章にも元文書との対応を残す。
- 利用者の現在の権限と照合し、生成へ渡す前に対象資料を限定する。権限のない資料名や引用も漏らさない。
- 質問に合う最新版を検索できたか確認する。権限があることと、答えの根拠として適切なことは別に評価する。
- 根拠が足りなければ回答を保留する。不要な外部操作の権限を検索AIへ与えない。
コピーして使える権限別評価表
質問/期待する回答・保留条件:
テスト利用者/役割/現在の閲覧条件:
参照してよい文書ID・版:
参照してはいけない文書ID:
確認項目 | 期待結果 | 実際の結果
検索資料 | 許可された適切な資料のみ | 未確認
モデルへ渡す内容 | 許可された範囲のみ | 未確認
回答・引用・資料名 | 根拠に沿い、制限情報なし | 未確認
キャッシュ・履歴 | 他の利用者へ漏れない | 未確認
ログ | 必要な範囲と閲覧権限で管理 | 未確認
権限変更・文書削除後 | 旧権限・旧内容を再利用しない | 未確認
環境/実施日/確認者/不足と対応:
結果の確認ポイント
同じ質問を権限の異なるテスト利用者で試す計画を立て、回答だけでなく、取得された資料とモデルへ渡した範囲を確認します。一般社員と人事担当者のキャッシュを共用して、別の人の回答が流用されないかも確認対象です。
権限を外した後、文書を削除した後、旧版しかない場合、根拠がない場合も評価します。検索用の登録情報だけでなく、引用リンク先や履歴のアクセス制御まで対象にします。確認は許可された環境とダミー資料で行い、評価ログに実際の機密情報を集めないでください。
今日試すこと
質問1つと権限の違う2人を想定し、読める文書・読めない文書・根拠不足時の答えを評価表へ書いてください。検索精度が高くても権限の確認が未完了なら、両者を分けて報告します。
参考資料
- Google Cloud|Retrieval-Augmented Generation:検索した情報を生成へ組み込む構成。
- OWASP|LLM01:2025 Prompt Injection:外部文書を通じた挙動の変更リスク。