社内RAGの権限管理｜検索前フィルタ・ACL連携・権限変更反映の設計

社内RAGで守るべき境界は、回答の文章だけではありません。検索対象、LLMへ渡すコンテキスト、引用リンク、ログ、キャッシュまで含めて、閲覧権限に沿って扱う必要があります。

本記事での推奨設計は、ユーザーを認証する → 信頼できる認可属性を取得する → 検索リクエストへ認可フィルタを付与する → 取得結果を必要に応じて再検証する → 回答・引用を表示する → 監査するというデータフローです。RAGは、検索でアクセスする外部メモリと生成モデルを組み合わせる枠組みです。したがって、社内文書を対象にする場合は、検索時の認可を取得パイプラインの要件として扱います。RAG原論文

RAGの基本的な仕組みや導入・評価の全体像は、RAG（検索拡張生成）とは？を先に確認してください。本記事では、特に「誰に、どの文書・チャンクを検索させてよいか」の設計へ絞ります。

結論：回答を隠す処理ではなく、検索時の認可を主経路にする

社内RAGでは、認可されていない文書・チャンクを検索要求の時点で対象外にする設計を主経路にします。OWASPは、異なるアクセス制限のデータを同じベクトルDBで扱う場合、ある利用者群の埋め込みが別の利用者群への応答で取得され、機密の業務情報が漏えいし得るシナリオを示しています。対策例として、認可を認識するベクトルDBで許可済みグループだけが情報へアクセスできるようにすることを挙げています。OWASP LLM08:2025

ここでいう「検索前」は、利用する検索基盤が検索実行時にフィルタやトークンベースの認可判定を適用する構成を指します。たとえばAzure AI Searchのセキュリティフィルタのパターンでは、文書へユーザーまたはグループIDを保持し、クエリへフィルタを指定して、一致しない文書を結果から除外します。同資料は、権限フィールドを応答から非表示にする設定だけでは文書レベルの認可にならず、すべてのクエリへセキュリティフィルタを適用する必要があると説明しています。Azure AI Search: Security Filter Pattern

検索後フィルタだけを主制御にするかどうかは、検索基盤、再ランキング、ログ、観測基盤、LLMへ渡すコンテキストの実装に依存します。候補がどの処理へ渡るかを製品・自社実装ごとに確認してください。本記事では、未認可候補を後段で除外する前提ではなく、検索要求そのものに認可条件を含める構成を推奨します。

推奨する全体データフロー

1. 認証：アプリケーションが利用者を認証する。
2. 認可属性の取得：ユーザーID、所属グループ、ロール、テナント、雇用状態、必要に応じて文書分類の閲覧レベルを、IdPまたは認可サーバーから取得する。
3. 検索フィルタの構築：アプリケーションの信頼境界内で、検証済みの属性から検索フィルタまたは検索基盤へ渡す認可トークンを構築する。ブラウザやLLMに認可条件を決めさせない。
4. 権限付き検索：ベクトル検索、キーワード検索、再ランキングの各段階で、設計した認可条件が適用されることを確認する。
5. 取得結果の再検証：必要に応じて返却直前に文書ID、ACL版、失効状態、原本側の認可状態を確認する。これは同期遅延・キャッシュ・例外処理を検出する補助層である。
6. 回答・引用表示：LLMには認可済みかつ必要な検証を終えたチャンクだけを渡す。引用リンクも表示時と遷移先の両方で認可を確認する。
7. 監査：誰が、いつ、どの認可コンテキストで、どの文書ID群を取得し、何件を除外・拒否したかを記録する。

この設計は、ネットワーク内にいることだけを信頼根拠にしないゼロトラストの考え方と整合します。NIST SP 800-207は、物理的・ネットワーク上の位置や資産所有だけで暗黙の信頼を与えず、認証・認可をエンタープライズリソースへのセッション確立前に実施する考え方を示しています。NIST SP 800-207: Zero Trust Architecture

ACL・RBAC・ABACをどう使い分けるか

次の表は、Mojiによる社内RAGの設計提案です。ACL、RBAC、ABACは排他的な選択肢ではありません。元データの権限モデル、入力文書の品質、検索基盤、評価方法、許容できる同期遅延に応じて組み合わせます。

Mojiによる推奨設計：原本システムの権限情報を認可判断の基準とし、RAG側には検索時の照合に必要な認可メタデータと同期状態を保持します。RAG側だけで閲覧可能者リストを手編集する場合は、原本との不整合を検知・是正する運用を別途用意してください。

Azure AI Searchは、カスタムの認可モデルでは文字列ベースのセキュリティフィルタを、Azure Data Lake StorageやSharePointなどではACL・RBAC・ラベルを取り込んでクエリ時に評価する方式を案内しています。どの方式でも、原本側の権限変更が検索結果へ反映されるのは、認可メタデータがインデックスへ同期された後です。Azure AI Search: Document-Level Access Control

文書とチャンクに持たせる権限メタデータ

検索単位がチャンクである場合、検索基盤が各チャンクに対して認可を評価できる必要があります。Azure AI Searchの文書レベルアクセス制御の資料でも、文書をチャンク化する構成では、ACLやラベルをチャンク行へ投影しなければ、チャンクレベルの参照がフィルタされないと説明されています。Azure AI Search: Document-Level Access Control

{
  "chunk_id": "chunk_…",
  "document_id": "doc_…",
  "tenant_id": "tenant_…",
  "source_acl_version": "…",
  "allowed_group_ids": ["…"],
  "allowed_user_ids": ["…"],
  "classification": "internal",
  "source_updated_at": "…",
  "index_updated_at": "…",
  "is_revoked": false
}

上記は架空の例です。以下はMojiによる設計提案として、少なくとも document_id、テナント境界、ACLまたは認可属性、ACL版、原本更新時刻、索引更新時刻、失効状態を追跡可能にします。

• 文書単位で足りる場合：文書全体が同一の共有設定で、すべてのチャンクが同じ認可条件を継承する場合。
• チャンクごとの分割を検討する場合：一つのファイル内に公開範囲の異なる付録、顧客別の節、秘匿すべき表が混在する場合。安全な分割または別文書化を先に検討する。
• 混在を避ける場合：許可対象と不許可対象の情報を同じ検索チャンクへ混ぜない。分割境界と認可境界を評価ケースで検査する。

Azure AI Searchのセキュリティフィルタの例では、ユーザー・グループIDをフィルタ可能なフィールドへ格納し、クエリ時に照合します。なお、Azure AI SearchのネイティブACL・RBAC統合にはプレビューの機能が含まれます。プレビュー機能はSLAの対象外で、本番ワークロードには推奨されない場合があるため、対象API、サポート条件、プレビュー表記を採用時点で確認してください。Azure AI Search: Document-Level Access Control

権限変更をどう反映するか：失効目標時間と同期方式を分ける

異動、退職、グループ脱退、共有解除、文書の機密区分変更では、「いつから検索結果に反映されるか」を実装ごとに定義し、測定する必要があります。権限変更が検索結果へ反映される時間は、IdPの属性キャッシュ、セッショントークン、コネクタ、インデクサー、検索基盤、アプリケーションキャッシュに依存します。一般論として「変更直後に必ず見えなくなる」とは扱えません。

たとえばAmazon BedrockのACL対応検索では、アプリケーションが利用者を認証し、検証済みのユーザーコンテキストを渡すことが前提です。同資料では、第三者IdP資格情報は最大1時間キャッシュされる場合があり、アクセス制御の変更は結果整合で通常数分以内に反映されると説明されています。Amazon Bedrock: ACL-aware retrieval

Mojiによる提案：失効を急ぐデータでは、インデックス更新だけに依存せず、短いセッション寿命、明示的なセッション無効化、対象文書の拒否リスト、または原本・認可サービスへのオンライン再照会を組み合わせます。どの方法が必要かは、許容できる露出時間と業務停止の影響を比較して決めます。

ACL情報の取得に失敗した、ACL版が不一致である、同期状態が不明であるといった場合に検索対象から除外する fail closed も、Mojiによる設計提案です。Amazon BedrockのACL対応検索でも、ACLメタデータが欠ける文書は利用者へ返さず、アクセス不可として扱う動作が示されています。Amazon Bedrock: ACL-aware retrieval

実装手順：小さく始めるための7ステップ

1. 保護対象を棚卸しする：文書、添付ファイル、OCRテキスト、埋め込み、検索クエリ、プロンプト、回答、引用URL、ログ、バックアップを対象に含める。
2. 原本の認可システムを定める：共有設定を持つDMS、IdP、業務システムのうち、どの情報を認可判断の基準にするかを決める。
3. 認可ポリシーを文章で書く：「テナントが一致し、文書ACLの許可ユーザーまたは許可グループに属し、機密区分の閲覧条件も満たす場合だけ取得可能」のように、実装前に判定式を合意する。
4. 取り込み時に認可メタデータを保存する：抽出・分割・埋め込みの各段階で、親文書ID、ACLまたは認可属性、ACL版を検索単位へ引き継ぐ。
5. 検索APIを一本化する：クライアント、管理画面、バッチ、エージェントのどの経路でも、認可を伴わない検索APIを呼べないようにする。
6. 失効イベントを接続する：共有変更、グループ変更、退職処理を受け、認可情報の更新、必要に応じた対象チャンクの一時無効化、再同期を行う。
7. 拒否ケースを含む評価を継続する：正答率だけでなく、認可されていない文書が検索候補・コンテキスト・引用に入らなかったかを確認する。

RAGを回答品質だけで評価すると、権限上の失敗が見えにくくなります。検索・生成を分けた評価データの設計は、RAG評価データセットの作り方も参考にしてください。

管理者・一般利用者で確認するテストケース

次のチェックリストはMojiによる提案です。実際の合否基準は、扱うデータ、認可モデル、IdP、検索基盤、トークン・属性キャッシュ、設定した反映SLOに応じて定めます。

テストは「変更直後」という曖昧な条件ではなく、たとえば「共有解除から15分以内」「IdPイベント受信から5分以内」のように、自社が合意した測定可能なSLOで判定します。製品の仕様上、数分またはそれ以上の結果整合があり得る場合は、その時間を前提に追加制御を設計するか、対象データを当該構成へ載せないかを判断します。

監査ログに残す項目と、残しすぎない項目

監査ログは、漏えい調査、拒否動作の検証、運用改善に必要です。一方、検索クエリや回答自体が機密情報・個人情報を含むことがあります。以下はMojiによる提案です。

• セキュリティ監査ログ：リクエストID、利用者の疑似化ID、テナント、認可ポリシー版、ACL版、許可・拒否件数、取得文書ID、処理時刻、失敗理由。
• 品質評価ログ：必要な場合だけ、アクセス制御された保管先に最小限のクエリ・コンテキスト・回答を保存する。閲覧者、保管期間、削除手順を定める。
• 変更イベントログ：原本のACL変更時刻、イベント受信時刻、インデックス更新時刻、検索除外を確認した時刻を記録し、反映SLOを測定する。

OWASPは、検索活動の詳細かつ改ざんされにくいログを維持し、不審な挙動を検知・対応することを対策として挙げています。ログ、バックアップ、評価用データセットもRAG本体と同じく権限管理の対象です。OWASP LLM08:2025

AIシステム全体の脅威整理、権限、鍵、監査を横断して確認する際は、AIのセキュリティ対策もあわせて参照してください。

導入前チェックリスト

• □ 原本の権限情報を認可判断の基準とするシステムが決まっている
• □ 検索単位となる全チャンクに、文書ID、テナント、ACLまたは認可属性、ACL版を付与している
• □ ベクトル検索、キーワード検索、再ランキングで認可条件がどこで適用されるかを確認している
• □ LLM、ブラウザ、クライアントが認可フィルタを任意に変更できない
• □ 必要に応じた検索後の再検証で、失効・同期不明の文書を除外できる
• □ 退職、異動、グループ脱退、共有解除ごとに反映SLOと測定方法が決まっている
• □ 回答本文だけでなく、引用、検索候補、コンテキスト、キャッシュ、ログ、評価データを検査対象に含めている
• □ 一般利用者・管理者・退職者・権限変更後を含む拒否テストを自動化または定期実施している
• □ ACL取得失敗、インデックス遅延、イベント処理失敗を運用者が検知できる
• □ 「権限なしなら回答しない」だけでなく、「権限なしの文書を検索対象にしない」取得経路を実装している

まとめ

社内RAGの権限管理では、プロンプトの禁止指示や回答表示時のマスキングだけを認可の根拠にしません。認証済みのユーザー属性と、文書・チャンクへ同期したACLまたは認可メタデータを使い、検索要求の段階で候補集合を制限することを主経路にします。

ただし、権限変更の反映時間は、IdP、トークン、コネクタ、インデックス、キャッシュの仕様に依存します。即時反映を前提にせず、失効SLO、同期方式、追加の拒否制御、検索時の再検証、引用を含む表示制御、監査と拒否テストを組み合わせて設計してください。

検索精度と権限制御は別々の後付け工程ではありません。認可された候補集合の中で検索品質を評価・改善する順番で、取得パイプラインを設計します。