#42 Copilotが暴く、「見つからなかっただけ」の情報 ～AI時代に備えるMicrosoft 365のアクセス権限管理～

はじめに

Microsoft 365 Copilot（以下、Copilot）の導入を検討する企業が、この1〜2年で一気に増えました。
議事録をまとめる、メールの下書きを作る、提案書のたたき台を用意する。

使い始めると手放せない、という声もよく聞きます。

一方で、Copilotの導入が途中で止まる例も少なくありません。

多くの理由として挙がるのは、「情報漏えいが心配だ」というものです。

ただ、その心配を掘り下げる前に、一つ整理しておきたいことがあります。
Copilotは、どこか新しい場所から情報を持ってくるわけではありません。
そのユーザーがすでにアクセスできる情報を「代わりに」集めて、要約しているだけです。

つまりCopilotの回答の質も、情報漏えいのリスクも、同じ一点にかかっています。
「誰が、どのファイルにアクセスできるか」です。

今回は、はじめにCopilotが何を変えたのかを整理します。

続いて社内でアクセス権限が緩んでいく典型的な経路と、よく取られる対策がなぜ効きにくいのかを説明し、最後に2027年1月に迫った期限について触れます。

Copilotは新しい穴を開けるわけではない

Copilotがアクセスできる範囲は、そのユーザーがアクセスできる範囲と同じです。
SharePoint、OneDrive、Teams、Outlook。権限の仕組み自体は、これまでのMicrosoft 365と何も変わっていません。

変わったのは、探し方です。

閲覧権限が付与されたまま放置されているファイルは、Copilotの登場以前から大量にありました。
しかし、部署の奥のフォルダーに眠るファイルに無関係な社員が偶然たどり着くことは、まずありません。

探す手間が、事実上のセキュリティとして機能していたわけです。

Copilotは、その手間をきれいに取り払いました。

社内のどこかに給与一覧などの人事データや役員会の資料が置かれていれば、瞬時に見つけて要約し、自然な日本語で差し出してきます。

「見えてはいたが、誰も見ていなかった」情報が、「実際に見られる」情報になった。
Copilotが変えたのは、そこだけです。

だとすれば、対策のポイントはCopilotではありません。SharePointやOneDriveの、アクセス権です。

1. アクセス権限はどこで緩んでいくのか

では、なぜ「本来アクセスできないはずの情報」に手が届く状態が生まれるのでしょうか。
現場でよく見かけるのは、次の3つです。 

1.共有リンクの既定設定

ある社員が、機密の事業数値を含むExcelファイルを上司に共有したとします。

「共有」を押してリンクをコピーし、チャットに貼る。

それだけの操作です。

問題は、そのとき自動生成されるリンクの既定値です。
テナントの設定によっては「リンクを知っている全員」がアクセスできるリンクが、何の警告もなく作られます。

本人には、上司ひとりに渡したつもりしかありません。
ですがそのファイルには、全社に開いた入口が付いています。

そしてCopilotは、その入口を見つけます。

2.Teamsで共有したファイルの置き場所

Teamsのチャットにファイルを貼る操作も、感覚としては「Teamsに置いた」でしょう。

しかし、実際には違います。
チャネルに投稿したファイルはSharePointのチームサイトに、個人チャットやグループチャットに貼ったファイルはOneDriveの「Microsoft Teams チャット ファイル」フォルダーに保存されます。

プライベートチャネルなら、専用のSharePointサイトが別途作られます。

この構造を正確に把握している利用者は、ほとんどいないでしょう。
そしてCopilotが見に行くのは、Teamsの画面ではなく、その裏側のSharePointとOneDriveです（図2）

3.積み上がっていく権限の残骸 

異動、退職、プロジェクトの終了、期間限定で招いた取引先のゲストアカウント。
役割が変わっても、いったん付与された権限が自動的に外れることはありません。

棚卸しや設定変更をしない限り、権限は増える一方です。

なお、この話題では「社外のゲストがCopilotで社内情報を引き出す」という点が強調されがちです。
一件あたりの影響は確かに大きいのですが、件数として圧倒的に多いのは、社内に残ったままの共有設定のほうです。

外側の穴を塞ぐ前に、まず内側を数えるほうが現実的だと思います。

基準は「Need to Know」

1.  

2. 「共有を止める」では、なぜ解決しないのか

対策として真っ先に挙がるのは、おそらく「共有機能を絞る」という案でしょう。
外部共有を禁止し、社内共有の既定値も厳しくする。一見、筋は通っています。

ただ、これがうまくいく可能性は低いです。理由は2つあります。

一つは、業務は止まらない、からです。
社内の共有が使いにくくなると、利用者は別の手段を探します。

機密文書が個人メールや他社のクラウドストレージを経由して流れ始め、管理者から見える状況はむしろ悪化します。

もう一つは、設定変更が過去に遡らない、からです。
既定値を変えても効果が及ぶのは変更後に作成・共有されたファイルだけで、これまで積み上がった共有リンクや権限はそのまま残ります。

しかもMicrosoft 365の標準ツールだけでは、テナント内の権限の全体像を把握することも、ポリシーを適用して監視し続けることも困難を極めます。
「何が残っているのか」を数える手段自体が足りていない、というのが出発点です。

1.  

2. 「制限付きSharePoint検索」という時限的暫定装置

3. この問題は、Microsoft自身も認識しています。
   2024年に提供された「制限付きSharePoint検索（Restricted SharePoint Search：RSS）」がそれです。
4. 管理者が指定したサイトだけを全社検索とCopilot検索の対象とし、それ以外を検索から隠す機能でした。
5.  
6. ただ、この機能には最初から弱点がありました。
   粒度がサイト単位しかなく、許可するか丸ごとブロックするかの二択であること。
7. そして検索対象が絞られるため、Copilotを使っていない社員の検索体験まで劣化し、Copilotの回答の網羅性にも影響が出ることです。
8. Copilotを活かすために入れたはずが、Copilotの価値を削ってしまう。解決策とは言いにくいところです。
9.  
10. しかも、期限が決まっています。
    新規の有効化は2026年7月31日をもって停止され、機能そのものは2027年1月31日に廃止されます。（出展：Microsoft 365 メッセージセンター MC1395311）
11.  
12. 本稿を書いている時点で、新しく有効にすることはすでに不可能です。
    そして既存の設定は後継機能へ自動的には引き継がれないため、何もしなければ、これまで検索対象から外れていたコンテンツがある日また見つかるようになります。
13.  
14. 後継として案内されている「制限付きコンテンツ検出（Restricted Content Discovery：RCD）」も、Microsoft自身が「権限を見直すまでの時間を確保するための一時的な統制」と位置づけています。
15. （出典：Microsoft Learn 「SharePointサイトとコンテンツの検出を制限する」）
    検索から隠して先送りする時代は、終わりつつあるということです。
16.  
17. 残された時間は、すでに半年を切っています。
18.  
19.  

20. 法令や制度の側面からも

21. もっとも、これはCopilotが登場したから始まった話ではありません。
22.  
23. 個人情報保護法が求める安全管理措置は、以前からアクセス制御と、アクセス者の識別・認証を含んでいます。金融、医療、電力といった業種別のガイドラインも同様です。
    総務省の「クラウドサービス利用・提供における適切な設定のためのガイドライン」も、設定ミスによる意図しない公開を主要なリスクとして扱っています。
24.  
25. つまり「誰が何にアクセスできるかを説明できること」自体が、以前からの要求事項だったわけです。
26.  
27. そしてこの流れは、これから一段と強まります。
28.  
29. 2026年3月、経済産業省と内閣官房国家サイバー統括室は「サプライチェーン強化に向けたセキュリティ対策評価制度」（SCS評価制度）の制度構築方針を公表しました。
    サプライチェーンを構成する企業のセキュリティ対策状況を★の等級で評価・可視化する仕組みで、★3・★4は2026年度末の運用開始が予定されています。
30.  
31. この★3・★4の要求事項には、ユーザーIDの管理手続やアクセス権の管理ルールが含まれています。
    なかでも、役割が変わった従業員から不要なアクセス権を速やかに取り除くこと、機密区分に応じて情報を管理することは、まさに先ほど挙げた「積み上がっていく権限の残骸」への対応そのものです。
32.  
33. これまで社内ルールの問題で済んでいたアクセス権の管理が、取引先から等級で問われる話になりつつあります。
    Copilotを導入するかどうかに関わらず、遠からず手を付けることになる領域だと考えたほうがよさそうです。
34.  
35.  

36. では、何ができれば良いのでしょうか

37. ここまでを踏まえると、必要な機能は次の4つに整理できます。
38.  
39. 1. 把握する ― サイト、フォルダー、ファイルの各レベルで誰がアクセスできるかを一覧でき、外部ユーザーやゲストの共有も絞り込めること
40.  
41. 2. 基準を決める ― Need to Knowに沿ったあるべき権限の状態を、ポリシーとして定義し適用できること
42.  
43. 3. 直す ― 数千サイト規模でも、まとめて是正できること
44.  
45. 4. 見張り続ける ― 違反を検知して通知し、対応の履歴が残ること
46.  
47. 大事なのは4番目です。権限は放っておけば必ずまた緩みます。
48. 一度きりの棚卸しではなく回り続ける仕組みでなければ、半年後には同じ状態に戻ります。
49.  
50.  

51.  365 Permission Managerという選択肢

52. Hornetsecurityが提供する365 Permission Managerは、この4つを1つの画面で扱うためのサービスです。
    権限の全体像を把握する「Explore」、ベストプラクティスや独自のポリシーを割り当てる「Manage」、違反を検知して通知する「Monitor & Audit」が、先ほどの1〜4にそのまま対応します。
53.  
54. Microsoft 365の純正ツールが画一的なポリシーしか適用できないのに対し、サイト・フォルダー・ファイルの各レベルで異なるポリシーを並行して運用できる点は、実務でよく効きます。
55.  
56. おすすめしたい機能は「To Do」リストです。
    サイトごとに違反が一覧化され、まとめて是正することも、業務上の理由がある場合に例外として承認することも可能です。
    違反は所有者本人にもメールで通知されるので、情報システム部門がすべてを抱え込まずに済みます。
57.  
58. 365 Permission Managerは、Copilotを止めるためのものではありません。
59. 安心して使えるように、足元を整えるためのツールです。
60.  
61.  

62. まとめ

63. 今回は、Copilot導入にあたって見落とされがちなアクセス権の問題を取り上げました。
64.  
65. Copilotは新しい脆弱性を持ち込むわけではなく、これまで放置されてきた権限設定の状態をそのまま映し出します。
    導入の可否を議論する前に、「自社のテナントで、誰が何にアクセスできるのか」に答えられるかどうか。そこが出発点です。
66.  
67. そして「制限付きSharePoint検索」で目隠しをしている環境には、2027年1月という期限があります。
68.  
69. やるべきこと自体は、目新しくありません。Need to Knowの原則に沿って権限を正しい状態に戻し、その状態を保ち続ける。
70. それだけです。
71.  
72. 本稿を機に、自社のMicrosoft 365の共有設定を一度点検されてはいかがでしょうか。