「社内AIを導入したいが、閲覧権限のない文書まで回答に使われないか」と不安を感じていませんか？
この問題は、社内文書を生成AIへ接続する企業で起こり得ます。社内情報を保存しているクラウドストレージなど元のサービスでは閲覧できない文書でも、設定によっては社内AIが回答へ引用してしまう可能性があります。
特に注意が必要なのは、人事異動や退職、プロジェクト終了などで権限が変わった後です。元の文書へのアクセス権限を停止しても、AIがその文書を引用して回答してしまうかもしれません。
この記事は、社内AIの導入を進める情報システム・DX・セキュリティ担当者に向けたものです。
記事を読むことで、次の点を判断できるようになります。
- 社内AIでは、どの段階で権限を確認すべきか
- 製品選定時にベンダーへ何を質問すべきか
- 試験導入で情報漏えいの有無をどう検証するか
- AIエージェントの操作権限をどう分けるか
◇ 社内AIの権限管理が重要になっている理由
◆ 社内AIが参照する情報が増えている
従来の社内チャットボットは、限定されたFAQやマニュアルを参照するものが中心でした。現在は、複数のサービスをまとめて検索する社内AIが増えています。
接続対象には、SharePoint、Google Drive、Box、Confluenceなどがあります。顧客情報を管理するCRMや、社内データベースを接続するケースもあります。
このとき使われる仕組みの一つが「RAG」です。RAGとは、社内文書などを検索し、見つけた情報を参考にして生成AIが回答する仕組みです。
RAGを使えば、社内情報に基づく回答を作りやすくなります。一方で、検索対象を正しく制限しなければ、閲覧権限を制限すべき機密情報まで利用者に開示されてしまうおそれがあります。
◆ AIエージェントには操作権限も必要になる
AIエージェントは、情報を検索して答えるだけではありません。顧客情報の更新やメール送信、申請の登録などを行う場合があります。
そのため、次の3種類の権限を分けて考える必要があります。
- 社内AIへログインする権限
- 文書やデータを閲覧する権限
- 社内システムを更新・操作する権限
社内AIへログインできるからといって、接続されているすべての情報を閲覧してよいとは限りません。文書を読める人が、その文書を更新できるとも限りません。
◆ RAGへ文書を登録しても権限が引き継がれるとは限らない
RAGでは、長い文書を「チャンク」と呼ばれる小さな単位に分けることがあります。たとえば、社内規程を章や段落ごとに分割して検索しやすくするのです。
分割したデータは、「検索インデックス」と呼ばれる検索用のデータベースへ登録されます。このとき、元文書の権限情報が失われる場合があります。
権限情報がなければ、検索時に「この利用者へ表示してよい情報か」を判断できません。
Webサービスなどの安全な運用方法を公開している国際的な団体「OWASP」は、文書だけでなく、分割後のチャンクにも権限情報を持たせることを推奨しています。
また、AIへの指示文（プロンプト）だけで情報の表示を制限する方法は十分ではありません。情報をAIへ渡す前に、システム側で除外する必要があります。
出典：OWASP RAG Security Cheat Sheet
◇ 社内AIが回答するまでに権限を確認する4段階
社内AIの権限管理を厳密に行う場合、次の4段階の流れを実現できるRAG構成にします。
1．質問した利用者を確認する
最初に、誰が質問しているかを特定します。社員番号や社内アカウントを使い、割り当てられている権限範囲を確認します。
2．検索対象を絞り込む
利用者が閲覧権限を持つ文書だけを検索対象にします。権限のない文書は、この段階で候補から除外します。
3．元のサービスで最新の権限を確認する
必要に応じて、SharePointやGoogle Driveに設定されている権限を参照し、利用者が現在も文書を閲覧できるか再確認します。
この処理があれば、検索用データに古い権限が残っていても、情報漏えいを防ぎやすくなります。
4．許可された情報だけで回答する
権限を確認できた情報だけを生成AIへ渡します。生成AIは、その情報をもとに回答を作ります。
Microsoft Azure AI Searchも、利用者のIDに応じて検索結果を制限する方法を案内しています。ただし、利用できる機能や権限の反映方法は構成によって異なります。
製品を選ぶ際は、権限変更後に再登録が必要かどうかも確認してください。
◇ 社内AIの権限管理で確認すべき3つの場所
社内AIの情報漏えい対策では、「どこに問題があるか」を分けて考える必要があります。確認する場所は、元データ、連携・検索、社内AIの3つです。
1．元データの権限
対象：社内データベース、SharePoint、Google Drive、Boxなど
共有範囲が広すぎたり、異動・退職前の権限が残ったりしていると、社内AIもその文書を参照する可能性があります。
次の点を確認します。
- 全社員向けの共有や公開リンクの設定が適切か
- 異動者や退職者の権限が適切に管理されているか
- 社外の利用者へ意図せず共有されていないか
この問題は、社内AIではなく元データ側で修正する必要があります。
2．RAGへの連携と検索権限
対象：文書の取り込み処理と検索用データ
元データの権限が正しくても、同様の権限が社内AI（RAG）へ反映されなければ情報漏えいにつながります。
文書自体には権限が設定されていても、文書を分割した「チャンク」に権限が引き継がれていない場合もあります。
RAGなどの社内AI製品を選定する際、次の点を確認しましょう。
- 権限変更や文書削除が反映されるか
- 分割後のデータ（チャンク）にも権限が設定されるか
- 権限のない情報が回答生成前に除外されるか
3．社内AIの会話履歴と共有範囲
対象：社内AIの会話履歴・共有機能
社内AIに会話履歴の保存や共有機能がある場合は、その閲覧範囲を確認します。利用者が過去の回答を共有すると、回答に含まれる社内情報も共有される可能性があるためです。
次の点を確認してください。
- 会話履歴を閲覧できる利用者
- 会話を共有できる範囲
- 管理者が閲覧できる内容
- 退職者や異動者の履歴の扱い
- 履歴の保存期間と削除方法
過去の回答を再利用する機能が実装されている場合には、権限変更後の無効化方法も確認します。
元データの権限、社内AIへの反映、回答後の扱いは、それぞれ別の確認項目です。3つを分けて点検することで、問題の原因と修正すべき場所が明確になります。
◇ 社内AIの権限管理で押さえる7つの設計ポイント
1．権限管理の基準を決める
まず、どのサービスの権限設定を基準にするか決めましょう。SharePointやGoogle Drive、Box、CRMなどが候補です。
次の項目を一覧表にまとめておくと、権限を適切に管理しやすくなります。
- 情報を保存しているサービス
- 情報を所有する部門
- 閲覧できる利用者
- 権限を変更する担当者
- 変更を社内AIへ反映する期限
2．社内アカウントと連携する
利用者は、メールアドレスだけで識別せず、社内IDなどの情報と組み合わせて識別する方が安全です。可能であれば、社内のID管理システムと連携しましょう。
また、一度の認証で複数のサービスへログインするSSO（シングルサインオン）を使えば、退職者の社内アカウントを停止した際、社内AIも利用停止にしやすくなります。
複数人で使う共有アカウントで社内AIを利用するのは避けましょう。共有アカウントでは、問題が発生した際に誰が何を検索したか追跡できないためです。
3．検索範囲を制限する
検索範囲の分け方には、大きく二つの方法があります。
一つは、部門ごとに検索データを分ける方法です。閲覧権限のない情報が最初から検索データに含まれていなければ、RAGで引用される心配はありません。もう一つは、一つの検索データの中で、文書やチャンクごとに権限を設定する方法です。
部門間で情報を共有する必要がない場合は、検索データを分ける方法が適しています。共通文書と機密文書が混在する場合は、文書ごとの絞り込みが必要です。
どちらの場合も、権限のない情報が生成AIへ渡る前に除外されることを確認してください。
4．権限変更の反映時間を決める
「権限の同期に対応している」という説明だけでは、十分ではありません。
次の時間を具体的に確認します。
- 異動や退職が社内アカウントへ反映されるまで
- 文書の権限変更が検索結果へ反映されるまで
- 保存済みの回答が無効になるまで
- 更新の失敗を管理者が検知するまで
機密性の高い文書では、回答のたびに元のサービスへ最新権限を確認できるかも重要です。
5．閲覧権限とAIエージェントの操作権限を分ける
AIエージェントには、業務に必要な操作だけを許可します。
営業支援であれば、「顧客情報の閲覧」「メールの下書き」「顧客情報の更新」「メール送信」を分けて設定します。
外部送信や削除、契約内容の変更などには、人による承認を挟みましょう。AIが操作を提案することと、実際に操作できることは分けて考えます。
6．保存済みの回答と会話履歴も管理する
検索時の制御だけでは十分ではありません。会話履歴や保存済みの回答から、機密情報が漏えいする可能性があるためです。
次の項目を確認してください。
- 利用者が異なる場合に、回答が共有されないか
- 文書の権限変更後に、古い回答を削除できるか
- 会話履歴をほかの利用者へ共有できるか
- 管理者がどこまで会話を閲覧できるか
- 会話履歴をいつまで保存するか
7．「表示されること」と「表示されないこと」をテストする
通常の回答精度テストだけでは、権限管理を確認できません。
人事、経理、営業、一般社員など、権限の異なるテスト利用者を用意します。それぞれが同じ質問を行い、回答の違いを確認してください。
確認すべき内容は二つあります。
- 閲覧可能な文書が正しく回答に使われること
- 閲覧できない文書の内容が回答に出ないこと
異動や退職、文書削除、共有解除も再現します。その後、いつ権限が反映されたかを確認します。
◇ 社内AIツールを選ぶ際の権限管理チェックリスト
| 確認項目 | ベンダーへ尋ねる内容 | 合格条件の例 |
|---|---|---|
| 利用者の確認 | 社内アカウントとの連携や多要素認証に対応するか | 社内アカウントの権限停止と連動する |
| 文書の権限 | 元データの閲覧権限を引き継げるか | 利用者の権限によって検索結果が変わる |
| 制御の細かさ | フォルダ、文書、チャンクのどこまで制御できるか | 自社の機密区分に合う |
| 操作権限 | 閲覧、更新、送信、削除の権限を分けられるか | 重要な操作に承認を設定できる |
| 操作記録 | 誰が何を検索したか記録できるか | 問題発生時に経路を追跡できる |
| 権限テスト | 閲覧できない情報を使ったテストが可能か | 本番導入前に検証できる |
機能の有無だけで判断しないことが重要です。
「どの情報サービスで使えるか」「標準機能か追加開発か」「正式提供されている機能か」まで確認してください。
◇ 30日で社内AIの権限管理を検証する方法
1〜5日目：対象を限定する
人事規程、営業資料、製品マニュアルなどから、公開範囲の異なる文書を50件程度選びます。
最初から全社の文書を登録する必要はありません。権限の違いを確認しやすい文書を選びましょう。
6〜12日目：権限表を作る
利用者を、人事担当者、営業担当者、一般社員など3〜5種類に分けます。
次に、文書ごとの閲覧可否を表へ記録します。AIエージェントを使う場合は、閲覧、下書き、更新、送信の可否も追加してください。
13〜22日目：権限の境界をテストする
権限の異なる利用者が、同じ質問を行います。回答内容と参照された文書を記録してください。
閲覧可能な情報が表示されることだけでは不十分です。閲覧できない情報が表示されないことも確認します。
23〜30日目：異動・退職・削除を再現する
所属変更、アカウント停止、文書削除、共有解除を試します。
決めた時間内に変更が反映されるか確認してください。過去の回答や会話履歴に情報が残っていないことも調べます。
最後に、管理画面の記録から検索と回答の流れを追跡します。ここまで確認できれば、本番導入を判断する材料がそろいます。
◇ 統合AIサービス「SELFBOT」の権限管理
SELF株式会社の提供する「SELFBOT」は、実効性のある権限管理が可能な社内AIツールです。
◆ 部署・役職などの権限別に検索データを分けられる
SELFBOTは、10体までのBotを追加料金なしでご利用いただけます。
「人事/労務Bot」「情シスBot」など部署や用途に応じて検索データを登録し、専用のBotを作成することで本来開示すべきでない情報の開示を防ぐことが可能です。
また、ユーザーごとにBotへのアクセス権限を付与できるので、「役員向けBot」「一般社員向けBot」といった切り分けも可能です。
◆SSO認証、外部IDとの連携も可能
SELFBOTはGoogleアカウント、Microsoft Entra IDによるSSO（シングルサインオン）に対応しています。SSO認証を利用することで、退職者の社内AIへのアクセス権限を適切に管理しやすくなります。
また、社内IDや外部サービス（kintoneなど）のユーザーIDと連携し、IDを持たないユーザーへの回答を拒否したり、会話履歴の一覧画面に表示することも可能です。
※外部IDとの連携は個別の追加開発が必要です。
◆ カテゴリ設定で検索データの「優先／除外」が可能
SELFBOTは独自機能として「カテゴリ設定」機能を備えています。
これは、検索データとなる文書に種類や属性などのカテゴリ情報を付与し、質問者の入力文や閲覧中のページに応じて、優先的に参照したり、検索から除外することができる機能です。アカウント情報と連携し、カテゴリを設定することも可能です。
文書単位ではなくチャンク単位で設定できるため、分割時にカテゴリ情報が失われてしまうこともありません。
※アカウント情報によるカテゴリ設定は個別の追加開発が必要です。
◆ ユーザーごとに設定できる管理画面の操作権限
SELFBOTの管理画面ではユーザーごとに「管理者／担当者／利用者」の権限区分を設定できます。それぞれにできることは以下の通りです。
- 管理者：学習リソース（検索データ）の登録・編集を始め、各種設定変更など、管理画面での全ての操作が可能です。
- 担当者：割り当てられたBotの学習リソースの登録・編集、各種設定変更が可能です。
- 利用者：割り当てられたBotとのチャットが可能です。学習リソースの登録・編集、各種設定変更はできません。
会話履歴を閲覧できるのは「管理者」「担当者」の権限を持つユーザーのみです。また、「担当者」権限を持っていても権限が割り当てられていないBotの会話履歴は閲覧できません。
この権限管理により、検索データの編集過程や会話履歴からの情報漏えいを防止することができます。
このように、SELFBOTは適切な権限管理を可能とする様々な機能を備えています。
◇ よくある質問
RAGを使えば社内情報の漏えいを防げますか？
RAGだけでは、情報漏えいを防げません。
RAGは、社内文書を検索して回答へ利用する仕組みです。利用者の確認や文書ごとの閲覧制限は、別に設計する必要があります。
保存済みの回答、会話履歴、操作記録も確認対象です。
部門ごとにチャットボットを分ければ十分ですか？
部門間で情報を共有しない場合には有効です。
ただし、兼務者やプロジェクト参加者の権限は、所属部門だけでは判断できません。その場合は、文書や利用者ごとの細かな制御が必要です。
権限管理のテストでは何を優先すべきですか？
閲覧できない情報が回答へ含まれないことを優先します。
通常の質問だけでなく、機密文書に含まれる固有名詞を指定した質問も行います。過去の回答を尋ねる質問や、異動直後の質問も試してください。
◇ 社内AIの権限は回答を作る前に確認する
社内AIの安全性は、ログイン機能の有無だけでは判断できません。
重要なのは、質問した利用者を特定することです。そのうえで、利用者が閲覧できる文書だけを検索します。生成AIへ渡す情報も、許可されたものに限定します。
さらに、異動や退職後の権限更新も必要です。保存済みの回答、会話履歴、AIエージェントの操作権限も管理対象になります。
まずは、1部門・50文書程度で権限表を作りましょう。そのうえで、「表示されるべき情報」と「表示されてはいけない情報」の両方をテストします。
回答の正確さと権限管理を同時に確認することが、安全な全社展開への第一歩です。
◇ 権限管理に適した社内AIを
社内AIを導入する前に、「利用者」「情報源」「許可する操作」を整理しましょう。
SELFでは、社内ナレッジ検索や問い合わせ対応、AIエージェントの活用について相談できます。既存データの保存場所や運用体制を踏まえ、確認すべき項目を整理することが可能です。
文書ごとの公開範囲や、異動時の権限変更に不安がある場合は、SELFBOTの資料やデモをご確認ください。実際の権限設定を想定した小規模な検証から始めると、導入後の問題を見つけやすくなります。
