2026年5月6日に更新されたMicrosoft公式情報では、Microsoft 365 Copilotのセキュリティを「新しいAI専用の別管理」ではなく、Microsoft 365の既存のID、アクセス権、コンプライアンス、プライバシー保護を継承する仕組みとして整理しています。Microsoft 365 Copilot data protection architectureで最初に押さえるべき結論は、Copilotが勝手に全社データを読めるようになるわけではない一方、SharePointやOneDriveで過共有されている情報は、ユーザーの権限内でCopilotに参照されやすくなるという点です。(Microsoft Learn)
そのため、管理者が今すぐ確認すべきなのは「Copilotを止めるかどうか」ではありません。感度ラベル、SharePointの共有設定、Purview監査、DLP、保持ポリシーを点検し、Copilotが参照してよいデータと参照させたくないデータを明確に分けることです。
Microsoft 365 Copilot data protection architectureで何が変わるのか
今回の公式情報で重要なのは、Microsoft 365 Copilotのデータ保護が、抽象的な「AIの安全性」ではなく、実際の管理項目に落とし込まれて説明されている点です。
特に次の3点が、管理者・セキュリティ担当者・開発者にとって実務上の確認ポイントになります。
| 観点 | 公式情報で整理された内容 | 実務上の意味 |
|---|---|---|
| Microsoft Purviewとの連携 | 秘密度ラベル、暗号化、DLP、eDiscovery、保持ポリシーなどがCopilot利用時にも関係する | ラベル設計や保持ポリシーが不十分だと、AI導入後に監査・証跡・情報保護の穴が見えやすくなる |
| SharePointとOneDriveの過共有対策 | Copilotは既存の権限を尊重するが、広く共有されたコンテンツはユーザーの回答に現れやすい | 「Everyone」「組織全体リンク」「匿名リンク」「所有者不明サイト」の棚卸しが必要になる |
| 監査とコンプライアンス | Copilotのプロンプト、応答、参照されたコンテンツはPurviewの監査・eDiscovery・保持の対象になり得る | Copilotの利用ログを、通常のMicrosoft 365監査運用に組み込む必要がある |
ポイントは、Copilotが権限を無視するのではなく、既存の権限設定の良し悪しを可視化しやすくすることです。従来なら検索されにくかった古いファイル、共有リンク、所有者不明サイトが、Copilotの回答を通じて業務ユーザーの目に触れる可能性があります。
Copilotはどのデータを参照できるのか
Microsoft 365 Copilotは、ユーザーのプロンプトを受け取ると、Microsoft Graphなどを通じて、そのユーザーがアクセスできるメール、チャット、ドキュメント、会議、予定表などの文脈を使って回答を生成します。公式情報では、Copilotのデータアクセスはサインインしているユーザーの権限に限定され、テナント全体のデータを無条件に見られるわけではないと説明されています。(Microsoft Learn)
ただし、ここで誤解しやすいのは「権限を守るなら安全」と言い切れないことです。たとえば、給与改定案が保存されたSharePointサイトに「組織内のすべてのユーザー」リンクが残っていれば、そのファイルは多くの社員にとって「権限上は読めるデータ」になります。Copilotはその権限境界の内側で動くため、過共有はそのままCopilotのリスクになります。
影響を受ける主なサービス
Microsoft 365 Copilot data protection architectureの影響範囲は、Copilotアプリ単体に閉じません。次の領域をまとめて確認する必要があります。
| 領域 | 確認すべき内容 |
|---|---|
| SharePoint | サイト権限、共有リンク、Everyone except external users、所有者不明サイト、アクセスレビュー |
| OneDrive | 個人領域に保存された業務ファイル、外部共有リンク、退職者・異動者のファイル管理 |
| Microsoft Purview | 秘密度ラベル、DLP、監査、eDiscovery、保持ポリシー、DSPM |
| Microsoft Entra ID | 条件付きアクセス、MFA、グループ設計、ゲスト・外部ユーザー管理 |
| Copilot拡張機能 | Graph connectors、エージェント、統合アプリの権限、プライバシー条件、データ処理範囲 |
秘密度ラベルと暗号化で確認すべきこと
Microsoft Purviewの秘密度ラベルは、Copilot利用時のデータ保護で中心的な役割を持ちます。公式情報では、Copilotが暗号化されたコンテンツを扱うには、ユーザーにVIEW権限だけでなくEXTRACT権限が必要になるケースがあると説明されています。また、Copilotがラベル付きデータから新しいコンテンツを生成する場合、サポートされる範囲で優先度の高い秘密度ラベルが継承されます。(Microsoft Learn)
管理者が見落としやすいのは、ラベルを「貼っているか」だけでは不十分な点です。次のように、ラベルの設定内容まで確認する必要があります。
| 確認項目 | 失敗しやすいポイント | 対応の考え方 |
|---|---|---|
| ラベルの分類 | 「社外秘」「機密」などの名称だけあり、保護動作が曖昧 | 共有制限、暗号化、透かし、外部共有可否を具体化する |
| EXTRACT権限 | ユーザーはファイルを開けるが、Copilotが要約できない | ラベルごとの利用権限を確認し、業務上必要な範囲を設計する |
| SharePoint/OneDrive対応 | ラベルはあるが、SharePointとOneDriveでの処理が有効化されていない | Officeファイルのラベル運用をSharePoint/OneDriveまで広げる |
| ユーザー定義権限 | 個別設定された権限により、Copilotエージェントが読めない | エージェント利用部門には、ラベルと権限の組み合わせを事前説明する |
特に開発者や業務部門がCopilotエージェントを作る場合、「ユーザーは読めるのにエージェントが回答できない」という問い合わせが起きやすくなります。これは不具合ではなく、ラベルや暗号化の権限設計による制約である可能性があります。
SharePointの過共有対策はCopilot展開前に必ず行う
Microsoft 365 Copilotの導入で最も現実的なリスクは、AIそのものよりもSharePointとOneDriveの過共有です。Microsoftの展開ガイダンスでも、過共有の修復、ガードレールの設定、規制対応の3本柱でCopilotの安全な基盤を作ることが示されています。(Microsoft Learn)
過共有対策では、次の順番で確認すると実務に落とし込みやすくなります。
| 順番 | 作業 | 判断基準 |
|---|---|---|
| 1 | 利用頻度の高いSharePointサイトを洗い出す | 上位100サイト、部門横断サイト、経営・人事・財務関連サイトを優先 |
| 2 | 広すぎる共有を確認する | Anyoneリンク、組織全体リンク、EEEU、外部共有、壊れた権限継承を確認 |
| 3 | 高リスクサイトを一時的に制限する | Restricted Content DiscoveryやDLPでCopilotからの発見・処理を抑制 |
| 4 | 権限を修復する | 不要なユーザー、古いリンク、所有者不明状態、過剰なグループ権限を整理 |
| 5 | 再発防止を設定する | サイト作成時の既定設定、秘密度ラベル、アクセスレビューを標準化 |
SharePoint Advanced Managementでは、Content Management Assessment、データアクセスガバナンスレポート、Restricted Access Control、Restricted Content Discoveryなどを使って、過共有や高リスクサイトを特定・制御できます。Restricted Content Discoveryは、サイトの権限自体を変えずにCopilotや組織検索での偶発的な発見を抑える用途で使えます。(Microsoft Learn)
過共有と判断しやすい具体例
たとえば、次のような状態はCopilot展開前に優先して見直すべきです。
| 状態 | なぜ危険か |
|---|---|
| 人事評価ファイルが「組織内のすべてのユーザー」リンクで共有されている | 権限上は多くの社員が読めるため、Copilotの回答に含まれる可能性がある |
| 古いプロジェクトサイトに所有者がいない | 誰も権限を見直さず、外部共有や不要なメンバーが残りやすい |
| 部門サイト配下で権限継承が複雑に壊れている | 管理者も実際のアクセス範囲を把握しにくい |
| 機密ファイルに秘密度ラベルが付いていない | DLPや自動保護の対象外になりやすい |
| 退職者・異動者のOneDriveに業務資料が残っている | 所有者や管理責任が曖昧になり、検索・保持・削除の判断が難しくなる |
Copilot導入前の点検では、すべてのサイトを完璧に直そうとするより、利用頻度が高く、機密情報を含み、広く共有されているサイトから優先するのが現実的です。
Purview DLPでCopilotの処理を制御する
Microsoft Purview Data Loss Preventionは、Copilotのプロンプトや参照コンテンツに対して追加の制御をかける手段になります。公式情報では、プロンプトに機密情報タイプが含まれる場合にCopilotの処理や外部Web検索を制限する方法、秘密度ラベル付きのファイルやメールをCopilotの要約処理から除外する方法が説明されています。(Microsoft Learn)
ただし、DLPには注意点があります。機密情報タイプと秘密度ラベルの条件は同じルール内では併用できません。また、ユーザーがプロンプトに直接アップロードしたファイルの中身はDLPでスキャンされず、DLP Copilotは入力されたプロンプト本文を確認します。ポリシー反映にも時間がかかる場合があるため、設定直後に「効いていない」と判断しないことが重要です。(Microsoft Learn)
実務では、次のように使い分けるとよいでしょう。
| 目的 | 設定例 |
|---|---|
| 個人情報をプロンプトに入れさせたくない | 機密情報タイプを条件に、Copilotの処理を制限する |
| 特定ラベルのファイルを要約させたくない | 秘密度ラベルを条件に、該当ファイルやメールを処理対象から除外する |
| Web検索に機密情報を送らせたくない | プロンプト内の機密情報タイプを検出し、外部Web検索での利用をブロックする |
| 部門ごとに例外を作りたい | まずはポリシーを分け、対象ユーザー・対象データ・通知文を明確にする |
監査、eDiscovery、保持ポリシーで確認すべきこと
Microsoft 365 Copilotの利用データは、Microsoft 365サービス内に保存され、Microsoft Purviewの監査、eDiscovery、保持ポリシーで管理対象になり得ます。公式情報では、Copilotのプロンプト、応答、参照コンテンツの監査レコード、eDiscovery用の相互作用データ、クラウド添付ファイルの保持、Copilot ChatでアップロードされたOneDrive内ファイル、Copilot PagesのSharePoint Embeddedコンテナーなどが整理されています。(Microsoft Learn)
保持ポリシーでは、CopilotとAIアプリのやり取りに関する情報が、ユーザーのExchangeメールボックス内の隠しフォルダーに保存され、eDiscoveryツールで検索できる仕組みが説明されています。また、Microsoft 365 CopilotとMicrosoft 365 Copilot Chatの保持ポリシーは、以前のTeamsチャットとCopilot interactionsの扱いから分かれ、新規作成ポリシーではMicrosoft Copilot experiencesなどの場所を扱う形になっています。(Microsoft Learn)
管理者は、次の3点を必ず確認してください。
| 確認項目 | 実務上の注意点 |
|---|---|
| 監査ログ | Copilotのプロンプト、応答、参照コンテンツを調査できる体制にする |
| eDiscovery | 法務・監査部門がCopilot関連データを検索・保全できるか確認する |
| 保持・削除 | 表示上チャットが消えていても、保持や法的保全の対象になっている場合がある |
特に「ユーザー画面から見えない＝削除済み」と判断するのは危険です。保持ポリシー、訴訟ホールド、eDiscoveryホールドが適用されている場合、バックエンドでは保持される可能性があります。
管理者が展開前に確認すべきチェックリスト
Copilotの展開では、ライセンスを割り当てる前にデータ保護の土台を整える必要があります。Microsoftのセットアップ情報でも、テスト環境、パイロット、条件付きアクセス、SharePoint Advanced Management、監査ログ、MFA、機密情報の制限などが準備項目として示されています。(Microsoft Learn)
| 分類 | チェック項目 |
|---|---|
| IDとアクセス | MFAが有効か、条件付きアクセスがCopilot利用を想定しているか |
| SharePoint | 高リスクサイト、外部共有、Anyoneリンク、EEEU、所有者不明サイトを把握しているか |
| Purview | 秘密度ラベル、DLP、監査、eDiscovery、保持ポリシーがCopilotを含めて設計されているか |
| ライセンス | Copilot、Purview、SharePoint Advanced Managementなど、必要な機能のライセンスを確認したか |
| 運用 | 監査ログを誰が見るか、アラートを誰が対応するか、権限修復を誰が承認するか |
| ユーザー教育 | Copilotに入力してよい情報、貼り付けてはいけない情報、回答の確認方法を周知したか |
展開は「全社一斉」よりも、パイロット、部門展開、運用定着の順に進める方が安全です。特に、機密情報を多く扱う人事、法務、経理、経営企画、研究開発部門では、権限とラベルの確認を先に行うべきです。
開発者・エージェント作成者が注意すべき点
CopilotエージェントやGraph connectorsを利用する場合、開発者は「アプリが動くか」だけでなく、「どのデータに、誰の権限で、どの条件でアクセスするか」を設計する必要があります。Microsoft 365 Copilotは、エージェントが必要と判断された場合に、ユーザーのプロンプトやCopilot activity history、ユーザーがアクセスできるMicrosoft 365データをもとに、エージェントへ検索クエリを送る場合があります。管理者は統合アプリの権限、データアクセス、利用規約、プライバシー条件を確認できます。(Microsoft Learn)
開発者が特に確認すべきポイントは次の通りです。
| 項目 | 確認内容 |
|---|---|
| 権限 | 最小権限になっているか。管理者同意が必要な権限を過剰に要求していないか |
| 外部データ | Graph connectorsで取り込む外部データにも適切な権限・分類・所有者があるか |
| ラベル | 秘密度ラベルや暗号化されたファイルをエージェントが処理できる前提で設計していないか |
| ログ | エージェント利用時の監査、DLP、eDiscoveryの対象範囲を確認しているか |
| ユーザー説明 | エージェントが参照するデータ範囲、禁止入力、回答の限界を明示しているか |
開発側の失敗例として多いのは、検証用データでは問題なく動いたエージェントが、本番では秘密度ラベルや権限不足で期待通りに回答できないケースです。逆に、外部システム側の権限が広すぎると、Copilot経由で想定以上の情報が見つかりやすくなります。
まず取るべき行動
Microsoft 365 Copilot data protection architectureを実務に落とし込むなら、最初の一歩は「Copilotの機能調査」ではなく「データの見直し」です。
まず、SharePointとOneDriveで利用頻度が高く、機密情報を含む可能性があるサイトを抽出します。次に、秘密度ラベル、共有リンク、外部共有、所有者、保持ポリシーを確認します。そのうえで、Purview DLPやRestricted Content Discoveryを使って一時的な保護をかけ、権限修復後にCopilotの利用範囲を広げる流れが安全です。
Copilotは、既存のMicrosoft 365ガバナンスを置き換えるものではありません。むしろ、既存のガバナンスが整っている組織ほど安全に価値を引き出せます。管理者と開発者は、ライセンス展開の前に「誰が何を読めるのか」「どのデータをAIに使わせるのか」「利用後にどう監査するのか」を明文化してから展開を進めるべきです。
コメント