みなさんこんにちは！かぎパケです！
社内 RAG の評価では、回答が正しいかに加えて、回答の材料を誰の権限で取得したかを確認します。
利用者が元の文書を開けなくても、検索サービスが広い権限で本文を取得し、生成モデルへ渡していれば、元システムの閲覧制限を引き継げていません。
RAG（Retrieval-Augmented Generation）は、外部から検索した情報を生成モデルの入力へ加え、回答に利用する構成です。
検索で測る関連性と、利用者に情報の参照を許可する認可は、別の判定です。
文書が質問に近いという理由では、その利用者が読めることを証明できません。
ISC2 が 2026 年 9 月 3 日に掲載した Varun Carlay 氏の寄稿は、RAG をデータアクセス層として扱い、実際の利用者を踏まえて検索時に権限を強制する設計を提案しています。
これは Member Voices の記事であり、ISC2 の公式見解を示すものではありません。
以下はこの寄稿と OWASP の資料をもとにした設計レビュー案で、特定製品の検証報告ではありません。
接続アカウントと利用者の権限
たとえば、全社員が使う RAG に、人事部限定の資料と全社公開の手順書を登録する構成を考えます。
これは説明用の例で、実際の組織で確認した事故ではありません。
一般社員の質問に対し、検索サービスの共通アカウントが両方を取得できても、利用者へ両方を返してよいとは限りません。
接続にサービスアカウントを使うこと自体と、利用者の認可を省略することは区別します。
サービスアカウントを使う構成でも、信頼できる利用者情報に基づき、利用者ごとの取得範囲を強制する必要があります。
逆に、画面でログイン済みと表示されるだけでは、検索処理まで利用者の権限が伝わった証拠にはなりません。
レビューでは、認証済みセッションなどから利用者と所属を確定する処理と、検索条件に反映する処理をたどります。
リクエスト本文に書かれた利用者 ID、部門、テナントを無検証で信用すると、利用者自身が検索範囲を指定できてしまいます。
テナントとは、サービス内でデータを分離する組織や顧客の単位です。
権限を適用する位置
設計の基準にするのは、利用者に許可したデータだけを検索サービスから返す構成です。
検索基盤の権限制御や、迂回できないサーバー側の検索処理で範囲を制限します。
画面上のフィルターだけに任せず、検索 API を直接呼ぶ経路でも同じ制限が働くかを確認します。
図では、文書断片が生成モデルへ届く前に、どこで許可範囲を決めるかを見ていきましょう。
これは論理的な制御位置を示す図で、検索エンジン内部の実行順を指定するものではありません。
製品の pre-filter や post-filter という名称だけで判定せず、どの処理が未認可データを扱い、どこから外へ出るのかを確認します。
検索後に信頼されたサーバー側で除外する設計なら、その手前の処理にも機密データを扱える権限と保護が必要です。
権限外の本文をモデルへ渡してから、回答だけをマスクしても、送信済みの本文は取り消せません。
生成に使うモデルだけでなく、検索順位を調整する外部モデルに文書を送る場合も、送信前の認可を確認します。
ここでいう送信は推論時の入力であり、そのデータが学習に使われるかとは別の話です。
保存や学習利用の条件は、利用するサービスの契約と設定で確認する必要があります。
OWASP の LLM08:2025 も、権限を考慮したベクトルストアとデータの分離を対策に挙げています。
部署名を検索条件に加えるだけで、個別共有や明示的な拒否を含む元文書の権限を再現できるとは限りません。
文書の分割と権限変更
取り込み処理で文書を小さな断片（チャンク）に分割する場合、断片と元文書の対応を保ちます。
本文だけを取り込み、元文書の ID や権限情報を失うと、検索時に閲覧可否を判断したり、削除対象を特定したりする根拠がなくなります。
権限情報が欠けたデータは全員公開として扱わず、利用対象から外す設計にします。
運用担当者は、本文の更新だけでなく、共有解除と削除の反映経路を確認します。
たとえば原文で閲覧権限を取り消しても、インデックス側が昨日の権限を使い続けるなら、その間は取り消しが検索に反映されません。
許容する反映時間を定め、遅延時の利用停止や検索時の再確認を含めて設計します。
即時失効が必要な要件を、翌日の再取り込みだけで満たすことはできません。
権限情報を書き換える操作も制限します。
誰でもチャンクの所属や公開範囲を変更できれば、検索側の判定が正しくても、判定に使う情報を信用できません。
キャッシュと会話履歴
検索結果や回答を再利用する処理でも、利用者の権限を確認します。
質問文だけをキーに回答をキャッシュすると、別の利用者へ同じ回答を返す際に、元の検索時の権限が持ち越されるおそれがあります。
権限範囲を区別できるキーに加え、権限変更時の無効化や再確認を設計します。
利用者 ID だけをキーにしても、その人の異動や共有解除には対応できません。
矢印は点検する順序の一例で、製品内部の処理順序や自動反映機能を示してはいません。
同じ権限変更でも、確認する先は三つあります。検索結果だけが更新され、古い回答をそのまま返す経路が残らないかを確かめます。
会話履歴に以前取得した本文や要約を含める構成では、次の質問でそれらをモデルへ再送する経路も点検します。
新しい検索を正しく制限していても、古い会話から同じ資料が再び入力されるなら、取得停止だけでは対策が完結しません。
ただし、既に正当な権限で利用者へ表示した内容を、権限失効によって利用者の手元から回収できるわけではありません。
失効後の再取得と再利用をどう扱うかを定める話です。
非機密の資料で行う確認試験
試験では、本物の人事情報を使う必要はありません。
検証用の資料に固有の非機密文字列を入れ、部門別のテストアカウントで取得範囲を比較します。
次の表は実施案であり、実測結果ではありません。
| 条件 | 操作 | 確認する結果 |
|---|---|---|
| 一般社員と人事担当者 | 同じ資料について質問する | 各利用者の許可集合を超えた文書 ID や本文が、検索サービスの返却値とモデル入力に含まれない |
| 別テナントの利用者 | 同じ語句で検索する | 類似度が高くても、別テナントの資料を返さない |
| 未認可の文書 ID | 検索を経由せず、取得 API を呼ぶ | 直接取得でも認可が働き、タイトルや本文を漏らさない |
| 共有解除後の同じ利用者 | キャッシュがある状態で再質問する | 定めた失効要件に従い、旧回答や旧検索結果から対象内容を再提供しない |
| 権限情報の欠落や照会エラー | 対象資料を検索する | 全件検索へ切り替えず、対象データを返さない |
| 権限失効後の既存会話 | 会話を継続する | 失効した資料の本文や派生要約を、方針に反して再送しない |
回答に固有文字列が出ないだけでは、試験の合格とはしません。
モデルがその文字列を省略して回答した可能性があるため、検索サービスの返却値とモデル入力も検証環境で確認します。
この確認で保証できる範囲は、用意したアカウント、資料、操作に限られます。
本番の監査ログには、利用者の識別子、実行サービス、対象文書 ID、許可または拒否、適用したポリシーの版を残す方法が考えられます。
本文やプロンプトの全文を常時記録することとは分け、識別子も含めたログの閲覧権限と保存期間を管理します。
OWASP の Authorization Cheat Sheet は、既定拒否、リクエストごとの権限検証、サーバー側の制御と試験を推奨しています。
設計レビューには回答の正確さだけでなく、「誰が、どの資料を、どの時点の権限で取得したか」を確認できる証跡を持ち込みます。
認可を検索、直接取得、キャッシュ、会話継続の各経路で点検することで、モデルの回答を見ただけでは分からない制限の抜けを探せます。