RAGで権限管理を行うときの原則は、「回答を作る前の検索の段階で、質問した人が見てよい文書だけを対象にする」ことです。生成AIに渡した文書の内容は、指示でいくら「この部分は答えないで」と伝えても、回答の文章に混ざるおそれがあります。回答を作った後で特定の内容を隠そうとする方法や、生成AIへの指示だけで制御しようとする方法では、見てはいけない人に情報を見せてしまうリスクを防ぎきれません。検索の対象を、質問者の権限で確実に絞ることが、情報漏えいを防ぐ設計の土台です。
全社員向けの規程だけを扱っているうちは、権限の問題は表面化しません。しかし、人事の内部資料、役員会の議事録、部署限定の手順書、顧客との契約書などを取り込み始めると、「誰が何を見てよいか」をシステムで正しく扱う必要が出てきます。後から権限の仕組みを追加しようとすると、文書の取り込みからやり直すことになりやすいため、最初の設計の段階で考えておくべき項目です。
この記事は、社内文書を検索して答えるAIを構築・運用している開発担当者、情報システム部門、情報セキュリティの担当者に向けて書いています。権限管理が難しい理由、権限の設計の考え方、文書への権限情報の持たせ方、検索での絞り込みの方法、元の文書の権限との同期、漏えいを防ぐ確認の手順、よくある失敗までを順に説明します。
RAGの権限管理が難しい理由
通常の文書管理システムでは、利用者が文書を開こうとしたときに権限を確認すれば済みます。RAGでは事情が異なり、次のような理由で権限管理が難しくなります。
一つ目は、文書が細かく分割されていることです。RAGでは文書をチャンクという断片に分けて保存するため、元の文書に設定されていた権限を、すべてのチャンクに正しく引き継ぐ必要があります。
二つ目は、複数の文書の内容が一つの回答に混ざることです。検索で取れた複数のチャンクをもとに回答を作るため、見てよい文書と見てはいけない文書が一緒に渡されると、回答の中で区別できなくなります。
三つ目は、回答の文章からは出典が分かりにくいことです。回答が要約や言い換えになっているため、見てはいけない情報が混ざっていても、利用者も運用者も気づきにくい状態になります。
四つ目は、元の文書の権限が変わることです。人事異動や組織変更、文書の公開範囲の変更があったとき、RAGの側の権限も追随しなければ、古い権限のまま検索が行われます。
五つ目は、利用者の質問の仕方によっては、断片的な情報からでも機密の内容が推測できてしまうことです。例えば、「来期に統合される部署はどこか」という質問に、直接の答えは返さなくても、関連する断片から推測できる回答を返してしまうことがあります。権限のない文書を検索の対象から確実に外すことが、この問題への唯一の確かな対策です。
権限の設計の考え方
権限の設計は、「誰が」「どの文書を」見てよいかを、システムで判定できる形で定義することから始めます。
利用者の属性を決める
利用者の権限を判定するために使う属性を決めます。よく使われるのは、所属部署、役職、雇用形態、拠点、プロジェクトへの参加の有無などです。これらの属性は、利用者自身に入力させるのではなく、社内の認証基盤や人事のデータから取得し、利用者がログインしたときにシステムが把握できるようにします。社内のアカウントでまとめてログインできる仕組み（SSO）を使えば、認証基盤が持っている所属や役職の情報を受け取りやすくなります。
文書の公開範囲を決める
文書ごとに、どの属性を持つ利用者が見てよいかを決めます。多くの組織では、役割ごとに見てよい範囲を決めるRBAC（ロールベースアクセス制御）の考え方が分かりやすく、管理もしやすい方法です。例えば、「全社員」「管理職」「人事部」「役員」のような役割を定義し、文書ごとにどの役割に公開するかを設定します。
役割だけでは表しにくい場合（特定のプロジェクトの参加者だけ、特定の拠点だけ、など）は、属性の組み合わせで判定する方法も使います。ただし、条件が複雑になるほど設定の誤りが起きやすくなるため、できるだけ単純な規則で表せるように、公開範囲の区分を整理することが大切です。
| 公開範囲の区分 | 例 | 判定に使う属性 |
|---|---|---|
| 全社員 | 就業規則、福利厚生の案内 | ログインしていること |
| 雇用形態別 | 正社員向けの制度の詳細 | 雇用形態 |
| 部署限定 | 経理の処理手順、営業の提案書の型 | 所属部署 |
| 役職限定 | 管理職向けの評価手順、労務管理の手引き | 役職 |
| プロジェクト限定 | 特定の顧客との契約書、案件の資料 | プロジェクトへの参加 |
| 個人限定 | 本人の評価や給与に関する文書 | 利用者本人であること |
個人限定の文書は、そもそもRAGの検索対象に含めるべきかを慎重に検討します。本人の給与や評価の情報を案内したい場合は、RAGで文書を検索させるのではなく、人事システムの画面を案内するか、本人確認をしたうえでシステムから直接データを取得する方が安全です。
権限の区分の決め方は、業務システムの管理画面の権限設計と共通する部分が多くあります。管理画面の権限設計：ロールと操作範囲を決める実務的な手順も参考になります。
区分を誰が決め、誰が承認するか
公開範囲の区分と、文書ごとの設定は、システムの担当者だけで決めるべきではありません。文書の中身と、誰が見てよいかを判断できるのは、その文書を所管する部署です。区分の定義は情報セキュリティの担当者と各部署の責任者で合意し、文書ごとの公開範囲は所管部署が設定または承認する、という役割分担にしておきます。新しい文書を取り込むときも、所管部署の承認を経る手順を決めておくと、誤った公開範囲で取り込まれることを防げます。また、迷ったときに誰に確認すればよいかが明確になっていることは、運用を続けるうえで大きな助けになります。
文書とチャンクに権限情報を持たせる
権限を検索で使うために、すべてのチャンクに公開範囲の情報をメタデータとして持たせます。
- 文書を取り込むときに、元の保管場所（ファイルサーバー、クラウドストレージ、社内Wikiなど）に設定されている権限を読み取る
- 読み取った権限を、システムで定義した公開範囲の区分に変換する
- 文書を分割したすべてのチャンクに、元の文書の公開範囲を付ける
- 文書の一部だけ公開範囲が異なる場合（文書の中に役員限定の別紙が含まれる、など）は、その部分を別の文書として扱うか、チャンク単位で公開範囲を設定する
- 公開範囲が読み取れない、または区分に当てはまらない文書は、取り込まないか、最も狭い公開範囲を付ける
5の「分からないものは最も狭く扱う」という方針は重要です。権限の情報が欠けた文書を全社員向けとして扱ってしまうと、それだけで漏えいの原因になります。
検索の段階で絞り込む
質問を受けたら、質問者の属性から見てよい公開範囲を求め、その範囲のチャンクだけを検索の対象にします。
検索の前に絞り込む
ベクトル検索の多くの仕組みは、メタデータの条件で対象を絞り込んだうえで検索する機能を持っています。この機能を使い、「質問者が見てよい公開範囲に含まれるチャンク」だけを対象に検索します。検索で上位の候補を取ってから権限で除外する方法もありますが、この方法では、権限のあるチャンクが候補から押し出され、答えられる質問に答えられなくなることがあります。可能な限り、検索の前、あるいは検索と同時に絞り込みます。
部署や利用者ごとにデータを分ける
扱う情報の機密性が特に高い場合は、メタデータでの絞り込みに加えて、保存先そのものを分ける方法もあります。例えば、役員会の資料は別のデータベースに保存し、役員の利用者からの検索のときだけ対象に加える、という形です。設定の誤りがあっても、別の保存先の情報が混ざることはないため、より安全です。その代わり、管理の手間は増えます。
回答とログでも権限を守る
検索で絞り込んでいても、回答以外の場所から情報が漏れることがあります。回答に添える出典のリンク、検索結果の一覧の表示、会話の履歴、運用者が見る質問と回答のログなどです。出典のリンクは、元の保管場所でも利用者に閲覧権限があるものだけを示します。ログには機密の情報が含まれるため、閲覧できる運用者を限定し、保存期間を決めます。誰がいつ何を質問し、どの文書が使われたかの記録は、監査ログとして残しておくと、問題が起きたときの調査に役立ちます。
回答の使い回しと会話の履歴に注意する
応答を速くし費用を抑えるために、よく聞かれる質問の回答を保存して使い回す仕組みを入れることがあります。このとき、利用者の権限を区別せずに使い回すと、管理職の質問に対して作られた回答が、一般社員に返されるといった漏えいが起きます。使い回す場合は、同じ公開範囲を持つ利用者の間に限るか、全社員向けの文書だけから作られた回答に限ります。同様に、会話の履歴を別の利用者の会話に引き継がない、共有の端末やアカウントで使わせない、といった点も確認しておきます。
元の文書の権限と同期する
権限管理で見落とされやすいのが、権限の変更への追随です。次のような変化が起きたとき、RAGの側の権限も更新されなければなりません。
- 人事異動、昇格、退職で、利用者の属性が変わった
- 組織変更で、部署の名前や構成が変わった
- 文書の公開範囲が変更された（限定公開から全社公開へ、あるいはその逆）
- 文書が削除された、または保管場所が移動した
利用者の属性は、ログインのたびに認証基盤から最新の情報を受け取るようにすれば、異動や退職にも追随できます。文書の側の変更は、定期的に元の保管場所の権限を読み取り直してチャンクのメタデータを更新するか、元の保管場所で変更があったときに通知を受けて更新する仕組みを作ります。特に、公開範囲を狭める変更と文書の削除は、反映が遅れるほどリスクが大きいため、優先して速やかに反映される仕組みにします。定期的な読み取り直しだけに頼る場合は、その間隔の中で古い権限のまま検索される時間が生じることを前提に、機密性の高い文書ほど間隔を短くするか、変更時に手動で即時反映できる手段を用意しておきます。
情報漏えいを防ぐ確認の手順
権限の仕組みが正しく動いているかは、公開前と運用中の両方で確認します。
- 確認用の利用者を、公開範囲の区分ごとに用意する：全社員、管理職、各部署、役員など
- 公開範囲が限定された文書について、その文書にしか書かれていない内容を問う質問を用意する
- 各確認用の利用者でその質問をし、権限のない利用者には答えが返らないことを確かめる
- 回答だけでなく、出典の表示、検索結果の一覧、会話の履歴に、権限のない文書の情報が出ていないかを確かめる
- 権限のある利用者には正しく答えが返ることも確かめる
- 文書の公開範囲を変更し、変更が検索に反映されるまでの時間を確かめる
- 確認用の利用者の属性を変更し（異動を想定）、見られる範囲が変わることを確かめる
- 公開後も、文書の追加や仕組みの変更のたびに、同じ確認を繰り返す
2の「その文書にしか書かれていない内容」を使うのがポイントです。一般的な内容を質問すると、全社員向けの文書から答えが返ってしまい、限定文書が混ざったかどうかを判別できません。確認用に、限定文書にだけ含まれる固有の語句や数値を使った質問を用意します。あわせて、言い換えや遠回しな聞き方でも試し、検索の絞り込みが質問の表現に左右されないことを確かめます。
架空の例として、ある会社で、全社員向けの規程と、管理職向けの労務管理の手引きを同じRAGに取り込んだとします。手引きには、残業の多い部下への面談の進め方が書かれていました。一般社員の確認用アカウントで「残業が多い社員への面談の手順は」と質問したところ、手引きの内容に基づいた回答が返ってきました。調べると、手引きの一部がファイルサーバーの共有フォルダに置かれていて、取り込みの際に共有フォルダの権限（全社員が閲覧可）が付けられていたことが原因でした。この例のように、権限の問題は元の保管場所の設定の誤りから生じることも多く、確認の手順は欠かせません。
運用中の監視
公開後は、定期的な確認に加えて、運用中の異常に気づける仕組みを用意します。例えば、限定文書が使われた回答の件数を公開範囲ごとに集計し、想定外の利用者の区分で限定文書が使われていないかを確認します。また、利用者から「見えるはずのない情報が出た」という報告を受け付ける窓口と、報告を受けたときに該当の文書を検索対象から一時的に外す手順を決めておくと、問題が起きたときの影響を小さくできます。
権限設計チェックリスト
- 利用者の属性を認証基盤から取得し、ログインのたびに最新にしている
- 公開範囲の区分が定義され、文書ごとに設定されている
- すべてのチャンクに公開範囲のメタデータが付いている
- 公開範囲が不明な文書を全社員向けとして扱っていない
- 検索の前、または検索と同時に権限で絞り込んでいる
- 出典のリンクや検索結果の一覧でも権限を守っている
- 質問と回答のログの閲覧者と保存期間が決まっている
- 文書の公開範囲の変更や削除が速やかに反映される
- 区分ごとの確認用の利用者で漏えいの確認を行っている
- 個人に関する機密情報を検索対象に含めるかを検討した
よくある失敗と避け方
生成AIへの指示で権限を守ろうとする
「この利用者は管理職ではないので、管理職向けの内容は答えないこと」と指示しても、渡された文書の内容が回答に混ざることを確実には防げません。権限は検索の段階で、仕組みとして守ります。
全社員向けの文書だけで始め、権限を後回しにする
最初は全社員向けの文書だけを扱う場合でも、将来、限定文書を扱う可能性があるなら、チャンクに公開範囲を持たせる設計にしておきます。後から追加すると、全文書の取り込み直しが必要になります。
元の保管場所の権限を無条件に信用する
共有フォルダの設定の誤りや、本来限定すべき文書が公開の場所に置かれていることは珍しくありません。取り込みの前に、対象の保管場所の権限を文書の管理者と確認します。
確認を一度で終える
文書の追加、組織変更、仕組みの改修のたびに、権限の問題が新たに生まれる可能性があります。確認の手順を文書化し、変更のたびに繰り返します。
退職者や異動者の扱いを確認しない
利用者の属性を一度だけ登録し、その後更新しない仕組みでは、異動前の部署の文書が見え続けたり、退職者のアカウントが使え続けたりします。認証基盤と連携して属性を自動で更新し、退職時にはアカウントが確実に無効になることを確認します。
よくある質問
Q. 権限の区分が多く複雑な場合、どう整理すればよいですか？
まず、RAGで扱う文書に必要な区分だけに絞ります。元の保管場所の権限が細かく分かれていても、RAGで扱う文書の範囲では数種類の区分にまとめられることが多いです。複雑な条件が必要な文書は、最初の対象から外すことも選択肢です。
Q. 社外の顧客向けのRAGでも同じ考え方が使えますか？
使えます。顧客向けの場合は、顧客ごと、契約プランごとに見られる情報が異なることが多く、顧客の企業や契約を属性として検索を絞り込みます。ある顧客の情報が別の顧客の回答に混ざることは重大な問題になるため、顧客ごとに保存先を分けることも検討します。
Q. 権限管理の設計はどの段階で行うべきですか？
構築の最初の段階、対象文書と利用者を決めるときに行います。構築の全体の流れはRAGシステムの構築手順で解説しています。
Otsumuに相談できること
扱う文書が全社員向けのものに限られ、将来も限定文書を扱う予定がない場合や、利用している社内向けAIのサービスが元の保管場所の権限をそのまま引き継ぐ機能を持ち、区分も単純な場合は、自社で設定と確認を進めることができます。この記事の確認の手順を使って、公開前に区分ごとのテストを行ってください。
部署や役職、プロジェクトによって見られる文書が細かく分かれている、人事や役員会など機密性の高い資料を扱う、元の保管場所が複数あり権限の同期が必要、顧客ごとに情報を分ける必要がある、といった場合は、権限の設計と検索の仕組み、確認の体制を合わせて設計する必要があります。社内問い合わせへの活用の全体像は、社内ヘルプデスクをAIチャットボット化するもあわせてご覧ください。
Otsumuでは、公開範囲の区分の整理から、認証基盤との連携、チャンクへの権限情報の付与、検索での絞り込み、権限の同期、漏えいの確認手順の整備までを一貫して支援しています。目的から逆算して必要な権限の区分に絞り、AIを活用した少人数の開発で、扱う文書の範囲を段階的に広げる進め方を取ります。詳しくはRAG開発のページをご覧ください。
自社の文書と権限の状況でどう設計するとよいか、一緒に整理することもできます。30分の無料相談からお気軽にご連絡ください。
この記事について
Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。
執筆：Otsumu株式会社 ／ 編集日 2026.10.01