セキュリティトリミングとは？RAGで閲覧権限を持つ文書だけを検索する仕組み

セキュリティトリミングとは？RAGで閲覧権限を持つ文書だけを検索する仕組み

社内AIを複数部署で使うと、検索システムが扱う資料の範囲は、一人の社員が読める範囲より広くなります。まず、この二つを分けて考えましょう。以下では、権限データの持たせ方から検索処理、運用時に見落としやすい経路までを整理します。

セキュリティトリミングがRAGに必要な理由

RAGは、質問に関係する資料を検索し、その内容を生成AIへ渡して回答を作る仕組みです。セキュリティトリミングはRAG専用の新機能ではなく、従来の文書検索にも使われるアクセス制御の考え方です。検索結果をそのまま回答材料にするRAGでは、検索時の権限の扱いが回答の安全性に直結します。

たとえば、資料を集めるためのサービス用アカウントには、人事、営業、経理のフォルダーを読む権限があるとします。そのアカウントで取得できた資料を全社員向けの検索に登録し、質問との関連度だけで選ぶと、一般社員の質問に人事限定の評価資料がヒットする可能性があります。検索サービスが取得できることと、質問者が閲覧できることは別です。

「機密を答えない」というプロンプトだけでは、誰がどの文書を読めるかを確実に判断できません。機密の定義が曖昧だったり、資料の要約に内容が混ざったりする可能性もあります。出力の検査は補助になりますが、元の文書に設定された閲覧権限を照合する処理の代わりにはなりません。

設計の基準は、権限外の本文や抜粋を回答生成モデルの入力へ渡さないことです。鍵のかかった書庫で、貸し出し可能な本だけを利用者へ渡す場面を考えると分かりやすいでしょう。検索基盤には広い範囲の資料を扱わせながら、質問者へ戻す情報には、その人の閲覧範囲を適用します。

文書とチャンクに閲覧権限を引き継ぐ

最初に必要なのは、各文書について「誰が閲覧できるか」を検索側で判断できるデータです。ACLはアクセス制御リストの略で、誰にどの操作を許可・拒否するかを表します。RAGで回答材料を選ぶ際は、主に閲覧の可否を扱います。編集できるか、削除できるかとは区別して考えます。

単純な許可リスト方式なら、文書のメタデータに、閲覧できる利用者IDやグループIDを保存します。たとえば人事向け文書に「人事グループのID」を持たせ、検索時に質問者の所属と照合します。表示名は変更や重複があり得るため、照合には元システムで管理される識別子を使うのが基本です。

長い文書を小さな単位に分けたものをチャンクと呼びます。検索がチャンク単位なら、各チャンクにも原文書IDと閲覧権限を引き継ぐか、原文書の権限を確実に参照できるようにします。本文の先頭だけに権限を付けても、後半のチャンクが独立して検索されれば制御できません。添付ファイルや別途作成した要約も、検索対象なら同じ確認が必要です。

原文書IDは、後で全チャンクの権限を更新したり、文書の削除に合わせてまとめて取り除いたりするためにも使います。文書全体の権限だけでなくページや項目ごとに制限がある場合は、制限の異なる内容を一つのチャンクに混ぜない設計も必要です。

権限情報が空であることを「全員に公開」と解釈してはいけません。全社員公開を示す値と、取り込み失敗などで権限が不明な状態は分けます。公開の範囲も、社内全体なのか、インターネット上の誰でもよいのかを明確にします。

権限は文書本文からAIに推測させず、信頼できる文書管理システムから取得します。明示的な拒否、親フォルダーからの継承、例外設定がある場合は、単純な許可IDの一覧への変換で意味を失わないようにします。複数の顧客企業で使うシステムでは、契約組織の区切りであるテナントIDも保持し、別組織の権限情報と混同しないようにします。

認証済み利用者から必須フィルタを組み立てる

検索時には、文書側の権限情報と、信頼できる利用者情報を結び付けます。利用者が質問文に「私は人事担当です」と書いても権限は増えません。ブラウザーから送られたグループIDも、そのまま認可の根拠にせず、サーバー側で確認します。基本の流れは次のとおりです。

1. 利用者を確認する。サーバーで認証情報の有効性を確認し、利用者ID、所属テナント、グループを確定します。署名などを検証した認証情報や、信頼できる所属管理システムを用います。
2. 閲覧条件を作る。単純な許可リストなら、利用者IDまたは所属グループIDが文書の許可IDに含まれることを条件にします。全社員公開の条件も明示し、テナントの制約はこれらと併せて満たすようにします。
3. 条件付きで検索する。サーバーが必須条件を検索要求へ組み込みます。利用者が選ぶ日付や資料種別の絞り込みを変更しても、権限条件は外れないようにします。
4. 許可済みの結果を取り出す。返された本文、抜粋、出典情報が、適用した権限範囲に収まることを保証します。必要に応じて現在の権限を再確認します。
5. 回答を生成する。許可済みの資料だけをモデルへ渡し、根拠に対応する引用を付けます。資料が不足する場合の応答も、この範囲内で決めます。

質問を言い換えて再検索する処理、キーワード検索とベクトル検索を組み合わせる処理、検索失敗時の代替経路にも同じ権限条件を適用します。最初の検索だけを制限しても、後続の検索で条件が抜ければ境界が崩れます。利用者や権限を確認できないときは、全件検索へ切り替えず、取得を止めるなど、許可しない側へ倒します。

検索エンジンが内部でどの段階にフィルタを適用するかと、モデルへ何を渡してよいかは分けて確認します。候補取得後に権限外を除外する方式では、上位10件のうち9件が除外され、必要な資料が別に存在しても1件しか残らないことがあります。結果不足への対応でも、権限条件を緩めてはいけません。

検索結果を別のモデルで並べ替える再ランキングにも注意が必要です。権限外の内容を回答生成の直前で除外しても、その前の外部サービスへ送っていれば別の経路が残ります。どの処理を信頼された検索基盤の内部で行い、どの境界から許可済みの情報だけを渡すのかを決めます。

同じ質問でも部署ごとに検索結果が変わる

架空の会社で、全社員向け就業規則、人事限定の評価資料、営業限定の顧客資料を検索するとします。ここでは人事・営業の担当者も全社員グループに属し、部署間の兼務や個別の追加許可はないものとします。閲覧範囲は次のようになります。

全員が「評価の基準は？」と質問しても、人事限定資料を回答材料にできるのは人事担当者だけです。一般社員には、閲覧可能な就業規則に評価制度の説明があれば、その範囲で回答します。営業担当者は顧客資料を読めますが、それが評価の質問に無関係なら、回答材料に選ぶ必要はありません。

つまり、閲覧できるかという認可と、質問に役立つかという関連度は別々の判断です。検索精度を高めてもアクセス制御は完成せず、権限を正しく適用しても必要な説明が必ず見つかるわけではありません。権限で候補が減ること自体は、検索の不具合とは限りません。

閲覧可能な根拠が足りなければ、「確認できる資料では判断できません」と伝えます。「人事限定の未公開評価表に答えがあります」と返すと、非公開文書の存在や題名を漏らす可能性があります。除外した資料を応答で列挙することも避けます。

この考え方は社内規程の検索だけでなく、顧客ごとに契約書を分けるサポートAIや、参加メンバーだけが設計資料を読める共同プロジェクトにも使えます。部署名を固定で埋め込むより、元の利用者・グループ管理と対応させる方が、兼務や参加者の変更を扱いやすくなります。

関連概念とAzureの実装方式の違い

本人確認、権限の判断、検索への反映は、関連していても役割が異なります。実装の担当範囲を決める際は、次の違いを押さえておくと整理しやすくなります。

メタデータフィルタは、この絞り込みを実装する手段の一つです。ただし、画面上で利用者が自由に解除できる「部署」フィルタは、それだけではアクセス制御になりません。権限を決める条件をサーバー側で必須にし、検索APIへ直接アクセスしても制約を回避できないようにする必要があります。

プロンプトインジェクション対策とも役割が異なります。これは、質問や検索資料に含まれる不正な指示によってAIの動作が変えられることへの対策です。閲覧を許可された文書にも不正な指示は入り得るため、検索権限を守ることと、取得内容を命令として信用しないことの両方を設計します。

Azure AI Searchを例にすると、security filtersは、権限を表すIDを検索インデックスのフィールドに持たせ、アプリケーションが利用者に応じた条件を付ける方式です。文字列のIDをフィルタで照合するだけで、検索サービスが質問者の本人確認や所属の正しさまで自動で保証するわけではありません。IDの取得、条件の組み立て、条件を省略できない経路の管理はアプリ側の責任になります。

これとは別に、対応するデータソースのACLなどを取り込み、文書単位のアクセス制御へ結び付ける連携方式があります。元システムの権限を使いやすくする仕組みですが、どの権限を引き継げるか、利用者情報をどう渡すか、変更をいつ反映するかは方式によって確認が必要です。「ACLを取り込める」ことだけで、回答やキャッシュまで含めた制御が完成するわけではありません。

2026年10月4日時点の本稿では、個別の連携の最新の対応元・制約や、正式提供／プレビューの区分は未確認です。方式を選ぶ際は、Microsoftの文書レベルのアクセス制御の概要とsecurity filtersの説明で、利用する機能の提供状態を確認してください。

権限変更・削除と引用・キャッシュの注意点

運用で重要なのは、今の権限が検索にも反映されることです。異動によるグループ変更、退職による利用停止、共有解除、文書削除は、それぞれ更新対象が異なります。ログインを止めるだけ、原文書を削除するだけでは、検索用のコピーや過去の回答が残る場合があります。

所属グループが変わったら、認証情報や所属情報のキャッシュが古いまま使われないか確認します。文書の共有を解除したら、その文書に由来する全チャンクの権限を更新します。文書を削除したら、チャンクや検索用要約も対象にします。どこまで反映したかを追跡できるよう、原文書IDと更新情報を管理します。

変更の同期には遅延が生じ得ます。夜間更新の仕組みなら、昼に解除した権限が夜まで残る可能性があります。失効をすぐ反映すべき資料では、更新完了まで対象文書を検索から遮断する、取得時に元の権限を再確認するなどの方針が必要です。通常の更新間隔に加え、同期失敗時や緊急の共有解除時の扱いも決めます。

回答本文のほかに、引用の抜粋、出典の題名、ファイル名、検索候補にも情報が含まれます。出典リンクには、そのリンクを開く時点の権限確認が必要です。アプリがファイルを代理取得する場合も、強い権限を持つサービス用アカウントで無条件に渡さず、利用者の閲覧可否を確認します。

キャッシュにも注意しましょう。人事担当者へ返した回答を質問文だけのキーで保存すると、後で同じ質問をした一般社員へ再利用してしまう可能性があります。回答や検索結果のキャッシュは、テナント・利用者・権限範囲を踏まえて分離し、権限変更時には失効させます。利用者IDだけで分けても、同じ人の異動後に古い回答が表示される問題は残ります。

会話履歴に残る過去回答の再表示や共有にも方針が必要です。また、検索結果やプロンプトを記録したログには、本文のコピーが残り得ます。ログ閲覧者を制限し、保存内容や期間を決めます。検索時に除外した文書の題名を、デバッグ画面や利用者向けエラーへ出していないかも確認します。

導入時には、次のような場面を実際の権限構成で確かめます。

• 同じ質問を、閲覧できる利用者とできない利用者がした場合。
• 複数グループへの所属や個別の拒否設定がある場合。
• 権限情報が欠けた文書や、利用者情報を確認できない要求が来た場合。
• 共有解除の直後に再検索し、過去回答やキャッシュを開いた場合。
• 原文書を削除した後に、残ったチャンクが検索されないか。

セキュリティトリミングは、質問者の閲覧範囲を検索結果へ反映するための仕組みです。これだけであらゆる漏えいを防げるわけではありません。信頼できる権限情報、外せない検索条件、変更の同期、回答以外の経路までつなげて設計することで、社内RAGの参照範囲を維持できます。

更新履歴