RAGのアクセス制御の設計：部署・役職ごとに見せる資料を分ける3つの型

3つの型の比較表

• 権限の持たせ方、型1：検索前に絞る：チャンクごとに閲覧可能なユーザー/グループIDを持たせ、検索条件に利用者のIDを入れる、型2：検索後に除く：広めに取得し、1件ずつ元システムに閲覧可否を問い合わせて落とす、型3：索引を分ける：権限区分（例：全社、人事、経営）ごとに別の索引・コレクションを作る
• 向いている場面、型1：検索前に絞る：部署・役職・個人など権限の組み合わせが多い、型2：検索後に除く：権限の正本が外部にあり、索引へ写しにくい、型3：索引を分ける：区分が少なく、分離を厳密にしたい
• 主な弱点、型1：検索前に絞る：索引内の権限が古くなる。権限メタデータの付け忘れ、型2：検索後に除く：上位k件が削られて回答材料が足りなくなる。問い合わせで遅くなる。落とす処理を通らない経路が残りやすい、型3：索引を分ける：重複登録と更新漏れ。横断検索の設計が難しい。区分が増えると運用が破綻する
• 古い権限のリスク、型1：検索前に絞る：同期が済むまで旧権限のまま、型2：検索後に除く：問い合わせ時点の権限が使える（最新に近い）、型3：索引を分ける：文書を移すまで旧区分のまま
• 実装の目安、型1：検索前に絞る：検索基盤のフィルタ機能を使う、型2：検索後に除く：アプリ側の処理を自作、型3：索引を分ける：索引数だけ構成を増やす

最後の行の「目安」は編集上の整理で、製品の公式な分類ではありません。

型ごとの弱点を具体的に見る

型1：検索前に絞る

公式資料でも、この型が基本線になっています。MicrosoftのAzure AI Searchのドキュメントレベルのアクセス制御は、権限を絞る方法として、セキュリティフィルター（利用者やグループの識別子の文字列で絞る）と、Microsoft Entraのトークンを使うネイティブのACL対応などを挙げています。確認時点で、セキュリティフィルターは検索基盤のバージョンに依存しない方式として紹介されています。一方、ACL/RBACスコープ、SharePointのACL、Purviewの秘密度ラベルによるネイティブ対応にはプレビュー表記があります。プレビューは本番利用を推奨しないと書かれているため、採用前に最新の状態を確認してください。

弱点は2つあります。

1. 識別子はただの文字列：セキュリティフィルターのパターンでは、フィルターに入れる識別子は認証されない単なる文字列だと説明されています。つまり、アプリ側で本人確認し、グループ一覧を正しく取得して渡す責任が設計側に残ります。また、グループIDを格納するフィールドを検索結果に返さない設定にしても、それは内容の秘匿や項目単位の保護ではないと明記されています。すべての問い合わせにフィルターを必ず付ける作りにしておくことが肝心です。
2. 同期の遅れ：同ドキュメントは、元システムでの権限変更は、権限メタデータが索引に同期されるまで検索結果に反映されないと説明しています。異動や退職、グループ変更の反映時間を、運用で決めておく必要があります。

Google Cloudのデータソースのアクセス制御（Agent Search）にも同種の仕組みがあります。この機能にはプレビュー表記があります。ドキュメントごとに読み手を持たせ、利用者の識別は組織のIDプロバイダー経由で行います。確認できた制約として、1ドキュメントあたりの読み手は3,000まで、ロケーションごとにIDプロバイダーは1つ、アクセス制御はデータストア作成時に選ぶ設定で後から切り替えられません。「あとで権限を足す」前提では始められない製品もあるわけです。

型2：検索後に除く

検索後の除外は、候補をLLMや利用者向けの表示へ渡す前に行います。権限の確認に失敗した候補も渡しません。たとえば上位20件を取得して、閲覧できない15件を落とすと5件しか残りません。これを防ぐには多めに取得して足りなければ再検索する処理が要り、遅くなります。さらに、落とすだけでは足りない漏れがあります。

• 「該当資料が見つかりませんでした」と「権限がありません」で応答が違うと、資料の存在が推測できます。
• 全体のヒット件数や絞り込み項目の件数を画面に出すと、見えない資料の分まで数えてしまう構成があります。
• 落とす前の候補をログやキャッシュに残すと、そこが穴になります。

Microsoftの資料は、ネイティブのフィルタを使う利点として、アプリ側で検索後に絞る処理を書かずに済み、大量アクセス時にも有利だと説明しています。型2は、その自作コストを引き受ける型だと理解してください。

型3：索引を分ける

分離の考え方が明快で、点検もしやすいのが利点です。ただし、索引を分けるだけでは権限制御は完成しません。利用者が検索できる索引をサーバー側で認可し、指定された別部署の索引へアクセスできないようにします。弱点は運用にあります。全社向け資料を各部署の索引へ重複登録すると、更新漏れで古い版が残ります。役職×部署の組み合わせごとに索引を作ると数が増えすぎます。区分が3〜5つ程度に収まるか、を目安に検討すると判断しやすくなります（編集上の目安です）。

権限メタデータを先に決める

型1でも型2でも、チャンク側に何を持たせるかが設計の中心です。以下は説明用の例です。

{
  "chunk_id": "hr-rule-001-03",
  "text": "（就業規則の該当箇所）",
  "source_doc": "hr-rule-001",
  "allowed_groups": ["grp-hr", "grp-exec"],
  "acl_synced_at": "2026-10-28T09:00:00+09:00"
}

ポイントは3つです。

• 部署名や役職名の文字列ではなく、IDプロバイダーのグループIDで持たせる（表記ゆれ対策）
• 親文書の権限を、分割した全チャンクへ必ず継承させる
• 権限を最後に同期した時刻を持ち、古いチャンクを監視できるようにする

Azure AI Searchの公式資料でも、チャンク分割時は権限フィールドを索引プロジェクションへ移し、各チャンクへ引き継ぐ構成が説明されています。親文書にだけ権限があり、検索対象のチャンクにない状態では、想定した制御が働かないおそれがあります。

公式の例では、検索時に次の形でフィルターを付けます（Microsoftのドキュメントに載るパターンの引用で、私の環境では実行していません）。

"filter": "group_ids/any(g:search.in(g, 'group_id1, group_id2'))"

group_id1, group_id2 の部分に、問い合わせた本人が属するグループを入れます。

漏えいリスクの点検観点（ログ・キャッシュ含む）

検索結果の絞り込みが正しくても、次の場所から漏れます。以下は編集上の点検リストです。

• 質問・回答ログ、起きること：回答に含まれた機密が、閲覧権限の広い運用ログに残る、確認すること：ログの閲覧者は元資料の閲覧者と同等か。保存期間は。回答本文を残さない設定にできるか
• 取得チャンクのログ、起きること：デバッグ用に出した候補チャンクが全文残る、確認すること：本番では文書IDだけを記録しているか
• 回答キャッシュ、起きること：Aさんへの回答がBさんにも返る、確認すること：キャッシュキーに組織・利用者・グループなど実際の認可条件を反映しているか。返却時に元資料への現時点の閲覧権限を確認するか、権限変更時に確実に失効できるか。保証できなければ全社共通資料に限定
• 埋め込み・検索結果キャッシュ、起きること：機密の質問や文書に由来するデータ、未認可の検索結果が別の人に渡る、確認すること：埋め込みへのアクセスを制限しているか。検索結果の再利用時にも現在の閲覧権限を確認し、権限変更時に失効できるか
• 引用・参照リンク、起きること：見えない資料のタイトルやURLが回答に出る、確認すること：引用はフィルター後の資料だけか
• 件数・候補表示、起きること：ヒット件数、関連資料の数が見えない資料まで含む、確認すること：件数は絞り込み後の値か
• エラー・空振り、起きること：応答の違いで存在が推測できる、確認すること：「権限なし」と「該当なし」を同じ表現にしてあるか
• 権限の同期、起きること：異動・退職後も旧権限で検索できる、確認すること：反映までの最大遅延を決め、テストしたか
• プロンプト、起きること：「この部署の人にだけ答えて」と指示するだけで制御したつもりになる、確認すること：権限制御は検索層で行い、プロンプトの指示を唯一の防御にしていないか
• 管理者・サービス用アカウント、起きること：検索用の強い権限のまま利用者の質問を処理する、確認すること：利用者本人の権限で絞る経路になっているか

確認用のテスト手順

1. 権限の違うテスト利用者を3人用意します（例：全社のみ、人事、役員）。
2. 各権限に1件ずつ、本物ではないダミー資料を登録します。内容に目印の語（例：「ダミー給与表A」）を入れます。
3. 各利用者で、他の区分の資料を狙った質問を投げ、回答・引用・件数・ログ・キャッシュを確認します。
4. 権限を1人分剥奪し、変更直後から反映まで繰り返し確認します。旧権限で閲覧できる時間が定めた最大遅延内か、反映後は既存の回答・検索結果キャッシュからも返らないかを確認します。
5. 同じ質問を別の利用者で連続して投げ、キャッシュ越しの混入がないか見ます。

テスト質問の下書きをAIに作らせる依頼文の例です。実際の機密資料は貼らず、ダミーの権限表だけを渡してください。

あなたはRAGのアクセス制御テストの設計者です。
次の説明用の権限表をもとに、権限のない利用者が他区分の資料に触れようとする質問を各区分5個ずつ作ってください。
ただし、直接の聞き方だけでなく、言い換え、要約の依頼、「存在するか」だけを聞く質問も含めてください。
各質問に、期待する応答（回答しない／同じ文面で断る）と、確認すべき場所（回答・引用・件数・ログ）を表にしてください。

権限表（説明用の例）：
- 全社：就業ガイド（全員）
- 人事：評価基準（人事グループのみ）
- 役員：役員報酬規程（役員グループのみ）

出てきた質問は人が読み、実在しない資料・過剰な内容がないか確認してから使います。結果の合否は、必ず各ログと画面で人が確認してください。

選び方の判断表

• 権限がグループ単位で整理されていて、検索基盤にフィルター機能がある、まず選ぶ型：型1
• 権限が元システム側で頻繁に変わり、索引へ写すと遅れが許されない、まず選ぶ型：型2（型1と併用し、最終確認だけ元システムに問い合わせる形も検討）
• 人事・経営など、少数の区分を完全に分けたい、まず選ぶ型：型3（残りは型1）
• 全社公開資料だけで試す、まず選ぶ型：権限制御なしでも可。ただし後から機密を足さない運用を決める

型2を最終確認に使うと、型1の同期遅れを補えます。ただし速度は落ちるため、重要資料だけに限る設計が現実的です（編集上の提案）。