社内文書を読み込ませたAIを試験導入したら、権限のない社員の質問に、人事評価の一覧や取締役会の資料をもとに答えてしまった。こういう話を、最近よく聞くようになりました。海外でも同じことが起きているようです。Gartnerが2024年6月にIT責任者132人へ行った調査では、社内文書の過剰共有を理由に、4割がMicrosoft 365 Copilotの展開を3か月以上遅らせたと答えたそうです。Microsoft自身も同年12月、過剰共有への対策機能をまとめて発表しています（記事末尾の出典参照）。

先に結論を書きます。共有フォルダに昔からあった穴を、AIが探し当てた。それだけです。したがって対策の中心は、文書側の権限と、AIに何を読ませるかの線引きです。AI側の設定は、そのあとに来ます。この記事では、想定される対策を4つに整理し、それぞれ何を防げて何を防げないかを比べます。

この記事の要点：RAGの流出は、見えていた文書が検索できるようになったことで起きる。対策は、①そもそも読ませない、②権限に応じて検索範囲を変える、③読ませる前に伏せ字にする、④出口で止める、の4つ。順番は権限の棚卸しが先で、AI側の仕組みは後。④だけに頼る構成は選ばない。

RAGとは何か。図書館にたとえると

言葉をそろえておきます。RAG（検索拡張生成）とは、AIが答える前に社内文書を検索し、見つけた文書をもとに回答を組み立てる仕組みです。AI自身は社内文書を覚えていません。質問のたびに探しに行きます。

図書館にたとえると分かりやすい。社内文書は書庫の本、AIは司書です。利用者が質問すると、司書が書庫から関係する本を数冊抜いてきて、その内容を要約して答えてくれる。人が本を探す手間が消えるので、便利なのは間違いありません。

問題は、この司書が驚くほど有能で、書庫の全部の本を一瞬で読めることです。これまでは、閲覧できる状態にあっても、誰も場所を知らないから読まれなかった本がたくさんありました。司書はそれを見つけます。「経営企画部の共有サイトの、3階層下のフォルダに、5年前の役員報酬の表がある」。人なら一生たどり着かない場所でも、司書は一秒で抜いてくる。

なぜ漏れるのか。穴は3か所

流出が起きる経路は、大きく3つあります。

第一に、そもそもの権限が緩い。全社共有のサイトに、部内限りの資料が置かれている。退職者が作ったフォルダの権限が「全員」のまま残っている。こうした過剰共有は、どの会社の共有フォルダにも例外なくあります。Microsoftの公式ドキュメントでは、Copilot導入の設計図の3本柱の1つが「過剰共有の是正」になっています（出典参照）。製品を売る側が、導入前にまず権限を直せと言っている。裏を返せば、それだけ導入現場で問題が起きているということでしょう。

第二に、AIに読ませる時点で権限が消える。RAGを自前で作るとき、社内文書をいったん一つの索引（AIが検索しやすい形に変換したデータ）にまとめます。このとき、元の文書が持っていた、誰が読めるかの情報を一緒に持ち込まないと、索引の中では全部の文書が平等になります。総務の人が経理の索引を検索できてしまう。作った側に悪意はなく、単に権限を持ち込む設計を忘れただけ、というのが典型です。

第三に、出口を人が見張れない。AIは、抜いてきた本の内容を要約して答えます。元の文書名が出るとは限らず、答えの中に数字や人名が溶け込む。読んだ本人は、それがどの文書から来たのか分かりません。だから「見てはいけない情報を見てしまった」と気づくこともなく、社外への転記や口外につながります。

対策の選択肢。4つを比べる

ここから対策です。想定される手を4つに分け、図書館のたとえで言えばそれぞれ何をしているのかを添えます。

① そもそも読ませない（書庫に入れない）

秘密度の高い文書を、最初からAIの検索対象に含めない方法です。取締役会資料、人事評価、未公表の決算、M&Aの検討資料。こうした文書は、AIに読ませて得られる便益より、漏れたときの損害のほうが桁違いに大きい。だから書庫に入れない。

技術的には、文書に秘密度の区分（ラベル）を付け、一定以上の区分は索引の対象外にする、あるいは特定の保管場所は対象外にする、という設定です。Microsoft 365であれば、特定のサイトをCopilotの参照対象から外す設定があり、また秘密度ラベルで暗号化した文書は、その文書の抽出権を持つ利用者でなければCopilotが内容を使えない、と公式ドキュメントに書かれています。自前で作る場合も、索引を作る処理に対象外の条件を書けば済みます。

利点は単純で、確実なことです。読ませていない文書は、どう質問しても出てきません。欠点も明確で、AIが役に立つ範囲がその分狭くなります。そして、どの文書を対象外にするかを決めて、区分を付け続ける運用が要ります。この線引きは技術部門にはできません。文書を所管する部門と経営が決める話です。

② 権限に応じて検索範囲を変える（利用者証を見て出す本を変える）

利用者ごとに、その人が読める文書だけを検索対象にする方法です。司書が利用者証を確認して、この人には閉架の本は出さない、と判断するのに近い。

やり方は2通りあります。一つは、元のシステムの権限をそのまま引き継ぐ方式です。Microsoft 365 Copilotがこの方式で、利用者がSharePointやTeamsで元々読める文書の範囲でしか回答を作らないとされています。もう一つは、文書に部門や区分のタグを付けておき、質問した人の所属や役職に応じて検索範囲を絞る方式です。AWS（Amazon Q BusinessやBedrockのナレッジベース）やGoogle Cloud（Agent Search、旧Vertex AI Search）にも、元の文書の権限を取り込む方式と、タグで絞る方式の両方が用意されていると各社の公式ドキュメントに書かれています（出典参照）。

利点は、AIの便益を最大限に保てることです。役員は役員の範囲で、担当者は担当者の範囲で、それぞれ全部の文書を使える。欠点は、元の権限が正しいことが前提になる、という一点に尽きます。第一の穴、つまり過剰共有がそのままなら、この方式は過剰共有をそのまま高速に届けるだけです。権限を引き継ぐ方式は、権限が正しい会社では最善で、権限が乱れている会社では最悪の結果を出します。

もう一つ、自前で作る場合の注意があります。権限の確認は、検索のたびに行う必要があります。索引を作った時点の権限で固定してしまうと、その後の異動や退職が反映されません。四半期に一度しか索引を作り直さない構成だと、異動した人が3か月間、前の部署の文書を見られる、ということが起きます。

③ 読ませる前に伏せ字にする（本の一部を黒塗りして書庫に入れる）

文書をAIに読ませる前に、個人名や口座番号、金額など特定の情報を機械的に伏せる方法です。文書そのものは対象に含めつつ、危ない部分だけを消す。

議事録の内容は検索させたいが、出席者の発言に含まれる個人名は出したくない、といった場面で使えます。契約書の雛形は共有したいが、取引先名と金額は消しておきたい、という場合も同様です。

欠点は、何を伏せるかの判定が完全にはならないことです。人名や番号のような形の決まった情報は機械で拾えますが、「この一文を読めば買収先が推測できる」といった文脈上の機密は拾えません。①や②の代わりにはならず、補助として組み合わせる手だと考えたほうがよいです。

④ 出口で止める（退館時に持ち物を確認する）

AIの回答が利用者に届く前に、回答の中身を検査し、機密らしき情報が含まれていれば止める、または伏せる方法です。情報漏洩対策の製品（DLP）を、AIの出力に当てるイメージです。

これは最後の網です。①から③をすり抜けたものを拾う役目であって、これだけに頼る構成は選ばないでください。理由は③と同じで、機械が機密と判定できるのは形の決まった情報に限られるからです。人事評価の内容が文章として要約されて出てきたとき、それを機密と判定するのは今の技術ではかなり難しい。加えて、止めるたびに利用者の体験は悪くなり、誤って止める例が増えると現場が使わなくなります。

4つの手を、1枚にまとめます

① 読ませない② 権限で検索範囲を変える③ 伏せ字にする④ 出口で止める
何を防げるか対象外にした文書は確実に出ない権限外の文書が出ない特定の項目（人名・番号等）が出ない形の決まった機密が出ない
防げないもの対象内の文書の過剰共有元の権限の乱れ。索引時点固定なら異動の反映漏れ文脈から推測できる機密文章に溶けた機密。誤検知で使われなくなる
AIの便益その分狭まる最大限保てるほぼ保てるほぼ保てる
運用の重さ区分を決めて付け続ける必要あり権限の棚卸しと維持が必須伏せる項目の定義と精度確認検知ルールの調整が続く
決めるのは誰か文書所管部門と経営情報システム部門（権限の持ち主は各部門）情報システム部門情報システム部門
位置づけ最初に決める線引き中心の仕組み補助最後の網

推奨する順番。権限の棚卸しが先

自分なら、次の順番で進めます。

まず、権限の棚卸しです。AIを入れる前に、共有フォルダの権限が現状どうなっているかを調べる。「全員」に公開されている場所に、部内限りの資料がどれだけあるか。これはAIと無関係に、今すぐできる作業です。ここを飛ばして②を入れると、先に書いたとおり、過剰共有をそのまま高速に届けることになります。

次に、①の線引きです。読ませない文書の区分を決め、所管部門に付けてもらう。全部の文書に付けようとすると終わらないので、「取締役会資料と人事評価と未公表決算だけは対象外」のように、最初は3種類程度に絞ってよいと考えます。

そのうえで、②を中心の仕組みとして入れる。既製品を使うなら権限を引き継ぐ方式のものを選び、自前で作るなら検索のたびに権限を確認する構成にする。

最後に、④を網として置き、あわせて誰が何を質問し、どの文書が使われたかの記録を残す。既製品なら大抵この記録は取れます（Copilotであれば、質問と回答と参照した文書の監査記録が取れると公式ドキュメントにあります）。自前で作るなら、最初から設計に入れておく。この記録があると、万一のときに、誰がいつどの文書を見たかをたどれます。逆に記録がないと、漏れたことにすら気づけません。

順番の話を、会社の話に置き換えるとこうなります。RAGの流出対策は、AIの問題ではなく、権限の土台の問題です。土台が整っている会社はAIの便益を全部取れますし、整っていない会社は、まずそこからです。

経営が決めること。指示は3行で足ります

技術部門に任せきりにすると、②と④だけが入って、①と権限の棚卸しが抜けます。技術部門から見ると、①の線引きは自分たちが決められない話だからです。だから、経営から先に決めて渡す必要があります。指示は次の3行で足ります。

  1. AIに読ませない文書の区分を決める。最初は取締役会資料、人事評価、未公表決算の3種類でよい。所管部門は各文書に区分を付ける。
  2. AI導入の前に、全社共有になっている場所の権限を棚卸しし、部内限りの資料を移す。完了をAI導入の条件にする。
  3. AIは、利用者の既存の権限の範囲でしか文書を参照しない構成にし、誰がどの文書を使ったかの記録を残す。

この3行のうち、いちばん時間がかかるのは2です。そして、いちばん効きます。AIを入れる入れないにかかわらず、いつかやらなければならなかった作業でもあります。AIの導入は、その締め切りを決めてくれた、と考えるとちょうどよいと思います。

出典（一次情報）

この記事の各社製品に関する記述は、以下の公開情報に基づいています（いずれも2026年8月19日時点）。

この記事の各社製品に関する記述は、上記の公開ドキュメントに基づいています（2026年8月19日時点）。仕様は変更されることがあります。導入判断の際は、必ず最新の公式情報をご確認ください。