本文へ移動
cotomu FDE

RAGのアクセス制御設計|検索結果から権限外の情報を漏らさない

RAGのアクセス制御は、認証済みの主体情報で検索を毎回絞り、権限変更の反映完了まで旧権限を使わせない設計が要点です。部署異動・共有解除・複数文書回答の権限テスト表で実行条件を整理します。

執筆cotomu FDE 編集部
監修岩崎 裕馬

RAGのアクセス制御の要点は、認証済みの利用者情報に基づく絞り込みを検索のたびに適用し、許可された文書だけを生成AIへ渡すことです。ただし、それだけでは部署異動や共有解除の直後に残る古い権限を防げません。権限の同期完了前をどう扱うかまで決めて、初めて運用可能な境界になります。

実装可否は、部署異動・共有解除・閲覧可否が混在する複数文書回答を一つの権限テスト表で判定できます。難所は、検索結果が正しいかだけでなく、回答文と根拠表示の全体が現在の許可範囲に閉じていることをどう確かめるかです。

RAGのアクセス制御は「検索前の認証」と「検索時の絞り込み」を分ける

RAGでは、検索結果に含まれた情報が回答の材料になります。したがって、回答生成後に画面上の表示を隠すのでは遅く、検索段階で権限外の文書を候補から外す必要があります。

ここで混同しやすいのが、利用者の認証と文書の絞り込みです。2026年9月21日時点のAmazon Bedrockの文書レベルアクセス制御に関する公式仕様によると、ACL対応フィルタリングは取得結果を絞る機能で、エンドユーザーを認証せず、単独ではセキュリティ境界になりません。アプリケーションが利用者を認証し、検証済みのIDコンテキストを渡す必要があります。

同じく2026年9月21日時点のAzure AI Searchのセキュリティフィルタ方式は、ユーザーまたはグループIDを文書に保持し、検索要求ごとにフィルタを適用して、一致しない文書を除外するものです。一方で、ID文字列そのものが認証・認可を行うわけではありません。

公式仕様から共通して確認できる設計原則は、次の境界です。

  • アプリケーションで利用者を認証し、信頼できる主体情報を確定する
  • 主体情報を、文書に付与したユーザーまたはグループの権限条件へ対応させる
  • その条件を検索前または検索時に毎回適用する
  • 絞り込み後の文書だけを回答生成へ渡す

ログインと検索用ACLフィルタは、どちらか一方で済む関係ではありません。認証済みの主体情報から文書単位の閲覧条件を作り、検索へ必ず渡す。この接続処理を迂回できない経路に置くことが実装の前提です。

人事異動で問われるのは権限の「正しさ」より「新しさ」

部署異動のデータが正しく登録されても、検索インデックス側に旧部署のACLが残っていれば、RAGは古い許可範囲で文書を取得し得ます。では、異動情報の更新APIが成功した時点を境界にすればよいのでしょうか。そうは断定できません。元データ、ID・グループ管理、取り込み処理、検索インデックスが別々に更新されるからです。

製品固有の仕様にも、この時間差が現れます。2026年9月21日時点で、Amazon Bedrock Managed Knowledge BaseのACL有効なカスタムデータソースは、与えられたACLメタデータを検索前フィルタリングに利用しますが、リアルタイムのACL検証には対応しません。また、2026年8月6日更新・同年9月21日確認のAzure AI Searchのセキュリティベストプラクティスでは、文書レベルアクセス制御について、権限メタデータをインデックス作成時に取り込み、検索時に利用者IDに基づいて適用すると説明されています。

さらに同ページのSharePoint ACL対応は、2026年9月21日時点でプレビューです。権限を初回インデックス作成時に取得するため、元データの権限変更後に古い権限を残さないには、対象文書の再インデックスが必要とされています。

これらは各製品の公式仕様であり、すべてのRAG基盤が同じ更新方式だという意味ではありません。実務上は、自社が採用するコネクタについて、権限変更の取得契機、同期または再インデックスの完了条件、失敗時の扱いを確認します。確認できない間は「反映済み」とみなさない。この判断が、部署異動と共有解除の境界を守ります。

部署異動・共有解除・複数文書回答の権限テスト表

以下は特定製品の公式テスト手順ではありません。公式仕様で確認した検索時フィルタと権限反映条件から導く、実務上の提案です。合否判定の対象は、利用者に見える検索結果・回答・根拠が許可範囲内かどうかです。「状態を変えた」「同期処理を動かした」という操作記録だけでは合格にしません。

検証行事前条件変更操作実行のタイミング観察対象合格条件不合格時に疑う境界
部署異動前利用者が旧部署に所属し、旧部署文書を閲覧でき、新部署文書は閲覧できないなし異動処理前検索文書、回答本文、根拠表示旧部署の許可文書だけが材料になり、新部署の権限外情報が含まれない主体情報の生成、検索フィルタの付与
部署異動後所属先を旧部署から新部署へ変更するID・グループと文書ACLを更新する採用した同期・再インデックスの完了後同じ質問に対する検索文書、回答本文、根拠表示旧部署文書がすべて除外され、新部署で許可された文書だけが材料になる古いセッション、ACL同期、インデックス更新
異動反映の途中元データの所属は新部署だが、検索側の反映完了を確認できない異動処理を開始する完了確認前検索要求の可否と利用した主体情報旧権限で検索させず、完了前に安全側へ倒す規則どおりに動く完了判定、失敗時制御、キャッシュ
共有解除前対象文書が利用者または所属グループへ共有されているなし解除前対象文書の取得と回答への利用現在の共有条件どおりに取得される共有情報と検索ACLの対応
共有解除後対象文書の共有を解除するACLを更新する採用した同期・再インデックスの完了後直接的な質問と関連語による質問の両方の検索結果、回答、根拠表示対象文書も、その断片も、回答の根拠にも現れない削除・更新対象の特定、断片単位のメタデータ
複数文書回答同じ質問に、閲覧可文書と閲覧不可文書の双方が関連するなし権限反映完了後取得された全断片、統合回答、根拠表示閲覧可文書だけで回答され、不可文書由来の内容が混ざらない検索の全経路、再検索、回答生成への入力

この表では、部署異動後の正常系に加えて、権限の反映途中を独立した検証行にします。すると、「同期完了まで利用を止める」「未反映の対象を検索から除外する」といった運用判断を先送りできません。どちらを採るにせよ、旧権限のまま検索を継続させないことが合格条件です。

共有解除後は、対象文書名を指定した質問だけでは検証が足りません。関連語から取得される断片にも同じ権限メタデータが付き、除外されるかを見ます。文書を分割して検索インデックスへ入れる構成では、元文書の共有解除と各断片の除外を同じ境界として扱う必要があります。

複数文書回答では、回答の自然さを評価する前に、材料となった文書の集合を検査します。閲覧可文書から得た内容だけで回答できたとしても、取得段階で閲覧不可文書が混ざっていれば不合格です。最終回答に偶然現れなかっただけで、境界が守られたとは言えません。

自社で実行する条件を先に固定する

テスト開始前に、各行へ自社固有の実行条件を追記します。製品名と機能名に加え、どの状態をもって現在権限と認めるかまで定義します。

  • 主体情報の発行元と、部署・グループを確定する処理
  • 検索要求へ権限条件を必ず付与する箇所
  • 文書ACLを検索インデックスへ取り込む契機
  • 同期・再インデックスの完了を判定する状態
  • 完了前、失敗時、状態不明時の検索可否
  • 検索文書、回答本文、根拠表示を照合できる記録

この条件が埋まらない行は設計未確定です。テスト日程を置く前に、境界の責任者と判断方法を決める必要があります。とくに「同期は定期実行される」という説明だけでは、異動直後に旧部署文書を検索できる時間をどう扱うかが決まりません。反映完了を観測できることと、その前の利用を制御できることを一組で確認します。

また、質問の入口が複数ある場合は、すべてが同じ認証・絞り込み経路を通るかを確認します。通常検索だけにフィルタがあり、候補の再検索や別の検索機能が迂回路になれば、表の合格条件は満たせません。テスト結果は、画面の回答に取得文書と根拠を照合できる記録を加えて判定します。

AI導入全体の責任分界や運用項目を先に整理したい場合は、AI導入の進め方ガイドも参照してください。検証環境で決めた境界を本番へ持ち込む際は、AI PoCから本番運用へ進むための設計と合わせると、権限テストを移行条件に組み込みやすくなります。

権限反映の完了前を決めてからRAGを公開する

RAGのアクセス制御の実行条件は、認証済みの主体情報で検索を毎回絞り、取得文書・回答・根拠を現在の許可範囲だけに閉じることです。人事異動に連動する境界では、旧部署から新部署への権限反映が完了する前に、旧権限で検索を続けさせないことを公開条件に置きます。

部署異動前後、共有解除前後、閲覧可否が混在する複数文書回答を同じ表で通せば、認証、ACL同期、検索フィルタ、生成入力のどこに未確定な境界があるかを切り分けられます。条件を自社だけで確定しにくい場合は、FDE型支援の無料相談・AI活用診断で、課題定義から実装、定着までの検討事項を整理できます。

FDE・AI実装ガイドへ戻る