これまでのAIセキュリティ記事では、公開した推論エンドポイントの窃取や、外部攻撃者によるプロンプトインジェクションといった「外から仕掛けられる攻撃」を中心に扱ってきました。しかし2026年、Microsoft 365 Copilot・Gemini for Workspace・Claudeを社内データに接続する全社展開が一気に進むなかで、まったく別種の事故が急増しています。それは、侵入も攻撃も一切ないのに、正規の社員が正規のクエリで「見えてはいけない社内情報」を要約させてしまう——という内部の過共有（オーバーシェアリング）です。
SharePointやGoogle Drive上に長年放置された「全社員閲覧可」の給与ファイル、進行中のM&A資料、離職者の個人フォルダ。これらは共有設定の負債として静かに眠っていましたが、AIアシスタントを繋いだ瞬間、「誰でも自然言語で聞き出せるAI回答」へと姿を変えます。ファイルを一つひとつ開いて探さなくても、「うちの部長の年収は？」「今期のM&A候補は？」と聞けば、AIが権限の範囲内で親切に要約してくれるからです。
筆者はネットワークのTAC（テクニカルアシスタンスセンター）とアドバンスドサービスで長年、アクセス制御（ACL）の設計と棚卸しに携わってきました。本記事の核心は、その「最小権限の原則」と「権限の棚卸し」というネットワーク運用の発想が、そのままAIオーバーシェアリング対策に転用できるという点にあります。これは新しい攻撃への防御ではなく、AI以前から存在した共有設定の負債を、AI導入前に清算する「権限衛生（パーミッション・ハイジーン）」の話です。
想定読者は、Copilot・Gemini・Claudeの全社導入を控える情シス・CISO、そして「導入したら何が起きるか」を事前に押さえておきたい経営・管理部門の方々です。
- なぜ「侵入なし・攻撃なし」でも情報が漏れるのか——オーバーシェアリングの構造
- 典型的な事故シナリオ——「聞かれると答えてしまう」情報たち
- 対策の全体像——「導入前の権限衛生」を4層で設計する
- 第1層：アクセス権の棚卸し（可視化）——「何が過共有か」を知る
- 第2層：権限の是正（最小権限化）——広すぎる範囲を絞る
- 第3層：機密ラベル連動——AIの取り扱いを自動で制御する
- 第4層：検索スコープの制限——AIが探せる範囲を絞る
- 導入前パーミッションレビュー——推奨される展開シーケンス
- 標準フレームワークでの位置づけ
- オーバーシェアリング対策チェックリスト
- よくある質問（Q&A）
- まとめ——AIは「共有設定の負債」を可視化する装置である
- 参考リンク
なぜ「侵入なし・攻撃なし」でも情報が漏れるのか——オーバーシェアリングの構造
まず押さえるべき大前提は、Copilot・Gemini・Claudeのいずれも、既存のアクセス権を「バイパス」しないということです。AIは新しい権限を作りませんし、権限のない人にファイルを見せることもありません。ユーザーがもともとアクセスできる範囲でのみ、情報を検索・要約します。
では、なぜ事故が起きるのか。問題はAIではなく、AI以前から積み上がっていた「アクセス権の範囲」そのものが、実態として広すぎる点にあります。マイクロソフトもグーグルも公式に、「AIは権限を回避しないが、すでに過共有されているコンテンツの可視性と集約速度を劇的に高める」と説明しています。
従来は、全社員閲覧可の機密ファイルが存在しても、そのファイルパスを知り、検索し、開くという手間があったため、事実上は「見つからない＝安全」に近い状態でした。いわば「発見困難性によるセキュリティ（security by obscurity）」に守られていたのです。AIアシスタントは、この最後の障壁を取り払います。自然言語で聞くだけで、テナント全体・ドライブ全体から該当情報を探し出し、要約して差し出すからです。
過共有はなぜ溜まるのか——典型的な「負債の発生源」
オーバーシェアリングは、悪意ではなく日々の業務の積み重ねで発生します。ネットワークのACLが運用のなかで肥大化していくのと同じ構図です。
- 「リンクを知っている全員」共有の乱用：とりあえず共有を通すために発行された広域リンクが、期限もなく残り続ける。
- 「全社員」「Everyone except external users」への付与：一時的な全社通知のために付けた広い権限が、機密フォルダにも残置される。
- 継承の破損（broken inheritance）：サイトやフォルダ単位の権限設計が、個別ファイルの例外付与で崩れ、把握不能になる。
- 離職者・異動者の権限残置：退職・異動後もアクセス権が消えず、本来閉じているべき範囲が開いたまま。
- サイト作成の民主化：誰でもチームサイトやドライブを作れるため、ガバナンスの効かない共有領域が増殖する。
これらはAIの問題ではありません。しかしAIを繋いだ瞬間、「潜在的な過共有」が「顕在的な情報漏洩」へと一気に転化するのです。
他のAIセキュリティ論点との違い
本記事のテーマは、これまで扱ってきた論点とは主題がはっきり異なります。
| 論点 | 誰から守るか | 主題 |
|---|---|---|
| マルチテナント分離 | 他の顧客 | 顧客間のデータ混線を防ぐ |
| DLP（データ損失防止） | 外部への流出 | 機密を組織の外に出さない |
| RAGの権限設計 | システム設計上の欠陥 | 検索基盤に権限を正しく実装する |
| オーバーシェアリング（本記事） | 社内の正規ユーザー | 「見えてはいけないものが社内で見える」既存の共有負債を清算する |
つまり本記事が扱うのは、外部への流出でも、システムの欠陥でもなく、「社内の正規ユーザーに、本来見えてはいけないものが見えてしまう」内部過共有です。攻撃対策ではなく、導入前の権限衛生という切り口は、これまでカバーされてこなかった空白地帯です。
典型的な事故シナリオ——「聞かれると答えてしまう」情報たち
抽象論では危機感が伝わりにくいので、実際に報告されている典型的な事故パターンを挙げます。いずれも正規ユーザーが、悪意なく、日常的な言葉で聞いただけで起きます。
| 漏れる情報 | 放置されていた共有設定 | きっかけとなる素朴なクエリ例 |
|---|---|---|
| 役員・社員の給与、人事評価 | 人事フォルダが「全社員閲覧可」のまま | 「管理職の給与レンジを教えて」 |
| 進行中のM&A・資本提携資料 | 経営企画サイトに広域リンクが残置 | 「今検討している買収案件は？」 |
| 未発表の組織改編・リストラ計画 | 役員用ドライブの継承が破損 | 「来期の組織変更の予定を要約して」 |
| 顧客リスト・単価・原価 | 営業共有ドライブが全社公開 | 「主要顧客ごとの粗利率は？」 |
| 採用中の候補者評価・オファー額 | 採用フォルダのアクセス権残置 | 「今オファーを出している人の条件は？」 |
これらに共通するのは、どれ一つとして「攻撃」ではない点です。侵入もマルウェアも異常アクセスもありません。だからこそ、WAFやEDR、ふるまい検知といった既存のセキュリティ対策では一切捕捉できません。ログ上は「正規ユーザーが正規に許可された情報にアクセスした」という、完全に正常な記録が残るだけです。
対策の全体像——「導入前の権限衛生」を4層で設計する
オーバーシェアリング対策は、AI導入と同時に慌てて始めるものではなく、接続する前に済ませておく「衛生管理」です。ネットワークで新しいセグメントを本番投入する前にACLを棚卸しするのと同じで、順序が重要です。以下の4層で整理します。
- 可視化：どこに過共有があるかを棚卸しする
- 是正：広すぎる権限を最小権限に絞る
- ラベル連動：機密ラベルでAIの取り扱いを自動制御する
- スコープ制限：AIの検索対象そのものを絞り込む
第1層：アクセス権の棚卸し（可視化）——「何が過共有か」を知る
対策は「現状を知る」ことから始まります。推測ではなく、実データで過共有の全体像を把握します。ネットワークでいえば、まず現行ACLと通信フローを可視化してから設計に手を入れるのと同じです。
Microsoft 365環境では、Copilotライセンスに付帯するSharePoint Advanced Management（SAM）が、この可視化の中核ツールになります。SAMのデータアクセスガバナンス（DAG）レポートや権限状態レポート（Permission State Report）を使うと、継承の破損、公開リンク、過剰なグループアクセスといった過共有リスクを持つサイトを洗い出せます。マイクロソフトは導入前に「SharePointオーバーシェアリング・アセスメント」を実施し、最もリスクの高い所見から是正することを推奨しています。
Google Workspace環境でも同様に、Drive上の広域共有・組織全体共有・共有ドライブの継承を、拡張後ではなく拡張前にレビューすることが推奨されています。多くの組織が、この棚卸しで初めて「何年分もの過共有・過剰権限・離職者の残存アクセス」の存在に気づきます。
棚卸しで確認すべき観点を整理します。
- 広域共有リンク：「リンクを知っている全員」「組織全体」で共有されている機密コンテンツ
- 広範なグループ付与：「全社員」「Everyone except external users」が機密サイトに残っていないか
- 継承の破損：親フォルダと異なる例外権限が付いた、把握困難なファイル
- 休眠サイト・オーファン権限：所有者不在・離職者権限が残るサイトやドライブ
第2層：権限の是正（最小権限化）——広すぎる範囲を絞る
過共有が見えたら、次は是正です。ここでの原則は、ネットワーク設計と完全に同じ「最小権限の原則（Principle of Least Privilege）」です。「誰もが念のため見られる」状態から、「業務上必要な人だけが見られる」状態へ絞り込みます。
Microsoft 365では、SharePoint Advanced Managementの制限付きアクセス制御（Restricted Access Control）が有効です。これは、特定のサイトへのアクセスを指定したEntraセキュリティグループやMicrosoft 365グループのメンバーに限定する機能で、グループ外のユーザーは、たとえ過去のリンクや個別権限を持っていても、サイトとその中身にアクセスできなくなります。積み上がったリンクの負債を、グループ単位のガードで一括して封じ込められる点が強力です。
是正を進めるうえでの実務的な指針は次のとおりです。
- クラウンジュエルから着手：全ファイルを一度に直そうとせず、給与・M&A・法務・採用といった「漏れたら致命傷」の領域を最優先で絞る。
- 広域リンクの棚卸しと失効：期限のない「組織全体」リンクを期限付き・限定共有に切り替える。
- 継承の再設計：破損した継承を正し、例外権限を原則廃止して、サイト/フォルダ単位のシンプルな権限構造に戻す。
- 離職者・オーファン権限の除去：退職・異動に連動した権限剥奪を定常プロセスにする。
第3層：機密ラベル連動——AIの取り扱いを自動で制御する
権限の是正は「範囲を絞る」対策ですが、それと並行して、コンテンツ自体に機密度をラベル付けし、AIの挙動をラベルに連動させるのが第3層です。ネットワークでいえば、トラフィックにQoSマーキングを打って扱いを変えるのに近い発想です。
Microsoft Purviewの秘密度ラベル（Sensitivity Labels）は、この中核を担います。ラベルがPurview Information Protectionによる暗号化を適用している場合、Copilotとエージェントはユーザーの利用権限（EXTRACT＝コピー権限）をチェックし、その権限がある場合にのみアイテムの内容を回答に使います。つまり、機密ラベルで暗号化されたコンテンツは、権限のないユーザーのAI回答には引用されなくなります。
さらに、Copilot向けのMicrosoft Purview DLPを使うと、特定の秘密度ラベルが付いたコンテンツを、Copilotの処理対象から除外できます。「このラベルが付いた文書はAIの要約・生成の材料にしない」という制御を、ポリシーとして一元的にかけられるわけです。
ラベル連動を機能させるためのポイントは次のとおりです。
- クラウンジュエルへのラベル付与を先行：まず最重要コンテンツに機密ラベルを付け、AIの取り扱いを確定させる。
- 自動ラベル付けの活用：キーワードやパターンに基づく自動分類で、人手の付け漏れを補う。
- 暗号化ラベルとDLPの併用：「AIに引用させない」だけでなく「そもそも処理対象から外す」を二段で設計する。
第4層：検索スコープの制限——AIが探せる範囲を絞る
最後の層は、AIアシスタントが検索・参照できる範囲そのものを絞り込む対策です。権限是正やラベル付けが追いつかない領域に対して、「そもそもAIの目に触れさせない」という即効性のあるガードをかけます。
Microsoft 365では、SharePoint Advanced Managementの制限付きコンテンツ検出（Restricted Content Discovery：RCD）がこれにあたります。RCDは、特定のSharePointサイトをCopilotやエージェントの検索対象から除外する設定で、ワンスイッチで「このサイトの中身はAIに要約させない」状態を作れます。是正の作業中で権限がまだ広いサイトに対する、時間稼ぎと保険を兼ねた措置として有効です。管理者はRCDの権限をサイト所有者に委任し、分散責任モデルで運用することもできます。
Google Workspace側でも、管理コンソールからGeminiアプリのWorkspaceサービスへのアクセス範囲を制御でき、Drive・Docsの共有設定をあわせて絞ることで、AIが参照できる範囲を管理できます。
ただし注意すべきは、スコープ制限はあくまで「暫定的なフタ」であって、根本治療ではないという点です。RCDでサイトを隠しても、過共有そのものは残ります。第1〜第2層の棚卸しと是正を進め、恒久的に権限を正すのが本筋であり、スコープ制限はそこに至るまでの安全マージンと位置づけるのが適切です。
導入前パーミッションレビュー——推奨される展開シーケンス
ここまでの4層を、実際の導入プロジェクトにどう組み込むか。マイクロソフトが示す展開シーケンスは、ネットワークの段階的ロールアウト（PoC→限定本番→全社展開）とよく似た、堅実な順序になっています。
- オーバーシェアリング・アセスメントの完了と是正：SAMのDAGレポートで最もリスクの高い所見を洗い出し、優先的に是正する。
- 情シス・セキュリティチームで先行有効化：まず自部門でCopilotを使い、機密業務ユーザーに届く前に「想定外の情報露出」を検知する。
- クラウンジュエルへの機密ラベル付与：最重要コンテンツにラベルを付け、AIの取り扱いを確定させる。
- パイロットグループでの限定展開：人事・財務・法務など機密性の高い部門で、Purviewの監視を明示的に有効化したうえで試験運用する。
- インシデントなし期間を経て全社展開：30日間の無事故運用を確認したのち、広域展開に移る。
重要なのは、「導入してから問題を探す」のではなく、「導入前に権限を正し、監視下の小さな範囲から広げる」という順序です。オーバーシェアリングは一度全社に開いてしまうと、どの情報が誰に要約されたかを事後に追うのが極めて困難になります。だからこそ、権限衛生は「前工程」に置く必要があります。
標準フレームワークでの位置づけ
オーバーシェアリング対策は「特殊な運用上の懸念」ではなく、AIガバナンスの標準的な枠組みに正面から接続します。社内説明や監査対応の根拠として押さえておくと有効です。
- OWASP LLM Top 10：権限のないユーザーへの機密情報の露出は LLM02:2025 Sensitive Information Disclosure（機密情報の漏洩） に対応します。また、AIアシスタントが広すぎる権限で社内データを横断参照する構造は、過剰な権限・機能を戒める LLM08 Excessive Agency（過剰な権限・エージェンシー） の考え方とも重なります。
- NIST AI RMF：Govern（統治）・Map（把握）・Measure（計測）・Manage（管理）の4機能に沿えば、本記事の「棚卸し（Map）→是正・ラベル・スコープ制限（Manage）→監視（Measure）→展開ルール化（Govern）」はそのままRMFの実装に対応します。
つまり「導入前の権限衛生」は、思いつきの運用テクニックではなく、標準フレームワークが求めるガバナンスを、AIアシスタント導入という具体的な場面に落とし込んだものです。
オーバーシェアリング対策チェックリスト
| 層 | 対策 | 主なツール（M365例） |
|---|---|---|
| 可視化 | アクセス権の棚卸し・過共有アセスメント | SAM データアクセスガバナンス／権限状態レポート |
| 是正 | 最小権限化・広域リンク失効・継承の再設計 | 制限付きアクセス制御（Restricted Access Control） |
| 是正 | 離職者・オーファン権限の除去 | 権限棚卸し＋人事連動プロセス |
| ラベル連動 | 機密ラベルでAIの引用・処理を制御 | Purview 秘密度ラベル／Copilot向けDLP |
| スコープ制限 | AIの検索対象からサイトを除外 | 制限付きコンテンツ検出（RCD） |
| 展開 | 導入前アセスメント→段階的ロールアウト | 展開ブループリント／Purview監視 |
| 運用 | 過共有の継続監視・権限の定期棚卸し | DSPM／データアクセスガバナンス |
よくある質問（Q&A）
Q1. CopilotやGeminiは、権限のないファイルまで見せてしまうのですか？
いいえ。Copilot・Gemini・Claudeのいずれも、既存のアクセス権を回避しません。ユーザーがもともとアクセスできる範囲でのみ検索・要約します。問題はAIではなく、そのユーザーがアクセスできる範囲が、実態として広すぎる（過共有されている）ことです。AIは「発見困難性で守られていた過共有」を、自然言語で即座に引き出せる状態に変えるのです。
Q2. これは新しいサイバー攻撃なのですか？
いいえ。侵入も攻撃もありません。正規ユーザーが正規に許可された情報にアクセスするだけなので、WAFやEDR、ふるまい検知では捕捉できません。本質は「攻撃への防御」ではなく、AI以前から積み上がっていた共有設定の負債を、導入前に清算する権限衛生の問題です。
Q3. 何から手をつければよいですか？
まず可視化（棚卸し）です。Microsoft 365ならCopilotライセンスに付帯するSharePoint Advanced Managementのデータアクセスガバナンス・レポートで、過共有サイトを洗い出せます。推測で対処せず、実データで「どこが過共有か」を把握してから、リスクの高い領域を優先的に是正してください。
Q4. 全部のファイルを直すのは現実的ではありません。
一度に直す必要はありません。「漏れたら致命傷」のクラウンジュエル（給与・M&A・法務・採用など）から着手するのが鉄則です。是正が追いつかない領域には、制限付きコンテンツ検出（RCD）でAIの検索対象から一時的に除外する「フタ」をかけ、時間を稼ぎながら恒久的な権限是正を進めます。
Q5. 機密ラベルを付ければ、それだけで安全になりますか？
ラベルは強力ですが単独では不十分です。Purviewの暗号化付き秘密度ラベルは、権限のないユーザーのAI回答への引用を防ぎ、Copilot向けDLPは処理対象からの除外を可能にします。ただしラベルの付け漏れがあれば効きません。自動ラベル付けで漏れを補いつつ、第1〜第2層の棚卸し・最小権限化と組み合わせて、多層で守るのが前提です。
Q6. 導入後にオーバーシェアリングが発覚したら、どうすればよいですか？
まず該当サイトにRCDや制限付きアクセス制御を適用して露出を止め、次に権限とラベルを是正します。そのうえで、Purviewの監視で「どの情報が要約対象になり得たか」を確認します。ただし、一度全社展開したあとに事後追跡するのは非常に困難です。だからこそ導入前アセスメントと段階的ロールアウトが、事後対応よりはるかに確実です。
まとめ——AIは「共有設定の負債」を可視化する装置である
社内AIアシスタントのオーバーシェアリング事故は、AIそのものの欠陥でも、外部からの攻撃でもありません。AI以前から静かに積み上がっていた「全社員閲覧可」の共有設定の負債が、AIによって一気に顕在化する——これが問題の本質です。要点は3つです。
1. AIは権限を回避しない。範囲が広すぎるだけ。Copilot・Gemini・Claudeは既存のアクセス権の中で動きます。問題は、その範囲が実態として広すぎることであり、AIはそれを「聞けば答える」状態に変える可視化装置です。
2. 攻撃対策では捕捉できない。だから「権限衛生」で臨む。侵入も異常アクセスもないため、既存のセキュリティ製品では止まりません。ネットワークのACL棚卸しと同じ発想で、導入前に権限を清算するのが唯一の実効策です。
3. 導入前に、可視化→是正→ラベル→スコープ制限を済ませる。棚卸しで過共有を把握し、最小権限化で範囲を絞り、機密ラベルでAIの取り扱いを制御し、必要に応じて検索スコープを制限する。この4層を、段階的ロールアウトの「前工程」に置くことが、事後の追跡不能な事故を防ぎます。
「AIを繋がない」という選択肢が現実的でない以上、「繋いだ瞬間、放置された共有設定が誰でも聞き出せるAI回答に変わる」を前提に、導入前の権限衛生を徹底する——これが、社内AIアシスタントを安全に全社展開するための基本姿勢です。
参考リンク
- Microsoft Learn「Secure & Governed Data Foundation for Microsoft 365 Copilot」
- Microsoft Learn「Get ready for Microsoft 365 Copilot with SharePoint Advanced Management」
- Microsoft Learn「Prevent oversharing with data risk assessments from Microsoft Purview DSPM」
- Microsoft Learn「Microsoft Purview DLP for Microsoft 365 Copilot and Copilot Chat」
- Microsoft Learn「Learn about sensitivity labels」
- Google Workspace「What controls Gemini’s access to Workspace data」
- OWASP Top 10 for LLM Applications（2025年版）
- NIST AI Risk Management Framework（AI RMF）
免責事項：本記事は2026年7月時点の公開情報および各社の公式ドキュメントに基づく一般的な情報提供であり、特定の製品・構成・テナントにおける安全性を保証するものではありません。また、法的助言ではありません。実際の権限設計・ガバナンス実装は自社環境・データ分類・関連法令に照らして検討し、必要に応じてセキュリティ専門家や弁護士にご相談ください。各製品の機能・名称・仕様は更新されるため、最新情報は各公式ソースでご確認ください。
コメント