Security for Microsoft 365 Copilotで押さえるべき結論は、Microsoft 365 CopilotはMicrosoft 365の既存のセキュリティ、コンプライアンス、プライバシー保護を継承する一方で、過剰共有されたデータまで安全にしてくれるわけではないという点です。管理者が最初に確認すべきなのは、新しいAI機能そのものよりも、SharePoint、OneDrive、Exchange、Teams、Microsoft Purview、エージェント、コネクタの権限とガバナンスです。
この記事では、Microsoft公式情報で示されているSecurity for Microsoft 365 Copilotの要点をもとに、変更点の見方、影響範囲、管理者や開発者が確認すべき設定、展開時に失敗しやすいポイントを実務目線で整理します。Microsoft 365 Copilotを安全に展開したい場合は、「Copilotを有効化する前に、誰がどのデータを見られる状態なのか」を可視化することから始めるのが最も重要です。
Security for Microsoft 365 Copilotとは
Security for Microsoft 365 Copilotは、Microsoft 365 CopilotをMicrosoftがどのように保護し、CopilotがMicrosoft 365のセキュリティ、コンプライアンス、プライバシー保護をどのように継承するかを説明する公式ガイドです。対象はMicrosoft 365 Copilotで、内容は展開手順そのものではなく、セキュリティ設計の考え方を整理したものです。(Microsoft Learn)
重要なのは、Microsoft 365 Copilotが独立したAIサービスとして社内データを自由に読み取るのではなく、Microsoft 365の既存のID、アクセス制御、データ保護、監査、コンプライアンス機能の上で動作するという点です。MicrosoftはCopilotのセキュリティについて、多層防御、IDとアクセス保護、データ保護とコンプライアンス、過剰共有の防止を主要な観点として示しています。(Microsoft Learn)
ただし、これは「Copilotを入れれば情報漏えい対策が自動で完成する」という意味ではありません。Copilotはユーザーがアクセス権を持つデータを参照するため、すでに広く共有されているファイル、古い権限が残ったSharePointサイト、外部共有されたTeamsチャネルなどがある場合、その状態がCopilotの回答にも影響します。Microsoftも、過剰共有または不十分に管理されたコンテンツはCopilotの結果やリスクに影響すると説明しています。(Microsoft Learn)
今回の公式情報で管理者が読み取るべき変更点
Security for Microsoft 365 Copilotのポイントは、単体の新機能追加というより、Microsoft 365 Copilotを安全に使うための責任分界点が明確になったことにあります。Microsoft側はサービス境界、暗号化、コンプライアンス、AI保護を提供します。一方、組織側はID、権限、共有設定、ラベル、DLP、監査、エージェント利用を設計しなければなりません。
| 観点 | 公式情報の要点 | 管理者が取るべき行動 |
|---|---|---|
| 多層防御 | CopilotはMicrosoft 365のエンタープライズ向けセキュリティ、プライバシー、コンプライアンス基準を前提に保護される | Copilot専用対策だけでなく、Microsoft 365全体の防御状態を確認する |
| IDとアクセス | Microsoft 365のIDとアクセス制御、ゼロトラストの考え方に沿う | Entra ID、条件付きアクセス、多要素認証、最小権限を見直す |
| データ保護 | Copilotはユーザーがアクセスを許可されたデータのみを扱う | SharePoint、OneDrive、Teams、Exchangeの権限を棚卸しする |
| コンプライアンス | Microsoft Purviewなどの既存機能で監査、保持、eDiscoveryに対応できる | Copilotのプロンプト、応答、参照データを監査対象として扱う |
| 過剰共有 | 広すぎる共有や管理不備はCopilotのリスクになる | 高リスクサイト、匿名リンク、全社共有、所有者不在サイトを優先的に是正する |
| 展開準備 | Securityページ自体は展開手順やデータ準備を含まない | Secure and governed foundationの手順と併せて確認する |
Microsoftは、展開やデータ準備の手順は別のガイドで扱うと明記しています。そのため、Security for Microsoft 365 Copilotだけを読んで展開判断を終えるのではなく、セキュアでガバナンスされたデータ基盤の構成ガイドとセットで確認する必要があります。(Microsoft Learn)
影響範囲は「Copilotを使うユーザー」だけではない
Microsoft 365 Copilotのセキュリティ影響範囲は、Copilotライセンスを割り当てるユーザーに限定されません。Copilotが参照する可能性のあるデータ、連携するアプリ、監査対象となるログ、外部データを取り込むコネクタまで含めて考える必要があります。
SharePointとOneDriveの共有設定
最も影響が出やすいのは、SharePointとOneDriveです。Copilotは既存の権限を尊重しますが、逆に言えば、権限が広すぎるファイルはユーザーがCopilot経由で見つけやすくなります。Microsoftのデータ保護アーキテクチャでも、SharePointとOneDriveのアクセス制御は、Copilotが発見・参照できるコンテンツに影響すると説明されています。(Microsoft Learn)
特に注意すべきなのは、次のような状態です。
- 「全員」または広すぎるグループに共有された部門別サイト
- 退職者や異動者が所有者のまま残っているサイト
- Anyoneリンク、社内全体リンク、期限切れでない共有リンク
- 権限継承が壊れ、フォルダー単位で意図しない共有が残っているライブラリ
- 古い人事資料、見積書、契約書、経営会議資料が検索可能な状態
Copilot導入前の棚卸しでは、ファイル単位で完璧に点検しようとすると止まりがちです。最初は「機密度が高い部門」「全社共有の影響が大きいサイト」「外部共有が多いサイト」から優先順位を付けると現実的です。
Exchange、Teams、会議データ
Microsoft 365 Copilotは、メール、予定表、チャット、会議、連絡先など、Microsoft Graph上の組織データを文脈として利用できます。公式情報では、ユーザーのドキュメント、メール、カレンダー、チャット、会議、連絡先などに基づいて応答を生成できると説明されています。(Microsoft Learn)
このため、TeamsやExchangeの管理者は、Copilot展開を「OfficeアプリのAI機能追加」とだけ捉えるべきではありません。たとえば、Teamsの共有チャネルや外部コラボレーションを使っている組織では、他テナントとの共有範囲も確認対象になります。
Microsoft Purview
Microsoft Purviewは、Copilotのセキュリティ運用で中心的な役割を持ちます。Microsoftは、Copilotとのやり取りに関するデータをContent searchやMicrosoft Purviewで管理でき、保持ポリシーの設定にもPurviewを使えると説明しています。(Microsoft Learn)
実務では、次の観点を確認します。
| 確認項目 | 目的 | 見落としやすい点 |
|---|---|---|
| 監査ログ | Copilot利用状況や不審な操作を追跡する | 有効化されていても、誰が確認するか決まっていない |
| 保持ポリシー | プロンプトや応答の保持・削除方針を定める | 通常のメール・ファイル保持とは別に検討が必要 |
| eDiscovery | 法務・監査対応でCopilot関連データを検索する | Copilotの回答だけでなく参照元データも論点になる |
| DLP | 機密情報の不適切な利用や流出を抑える | プロンプト内の機密情報にも注意が必要 |
| 秘密度ラベル | コンテンツの保護と利用制限を行う | ラベルが付いていない古いファイルが残りやすい |
エージェントとコネクタ
開発者や業務部門がエージェントやコネクタを使う場合、影響範囲はMicrosoft 365内のデータにとどまりません。Microsoft 365 Copilotは、Graphコネクタやエージェントを通じてサードパーティのツールや外部サービスを参照できる場合があります。管理センターでは、エージェントに必要な権限、データアクセス、利用規約、プライバシー声明を確認でき、管理者が組織で許可するエージェントを制御できます。(Microsoft Learn)
また、Microsoft 365 Copilotコネクタには、外部コンテンツをMicrosoft Graphに取り込んでインデックス化する同期型コネクタと、MCPを使ってリアルタイム取得するフェデレーション型コネクタがあります。同期型コネクタでは、外部アイテムのセキュリティを制限しない限り、展開済みコネクタがテナント全体に影響する点に注意が必要です。(Microsoft Learn)
管理者が最初に確認すべき設定
Security for Microsoft 365 Copilotを読んだ後、管理者がすぐに確認すべき項目は次のとおりです。ポイントは、Copilot専用の設定だけを探すのではなく、Copilotが継承するMicrosoft 365側の設定を整えることです。
IDとアクセス制御
Microsoft 365 CopilotはMicrosoft 365のIDとアクセス制御の上に構築され、強力なID検証、最小権限、継続的評価などのゼロトラスト原則に沿うと説明されています。(Microsoft Learn)
確認すべき設定は次のとおりです。
| 設定 | 確認ポイント |
|---|---|
| Microsoft Entra ID | Copilot利用者が正しいユーザー、グループ、部署に紐づいているか |
| 条件付きアクセス | 管理者、外部アクセス、信頼されていない端末からの利用を制御できているか |
| 多要素認証 | 特権管理者とCopilot利用者に適切に適用されているか |
| 管理者ロール | Global Administratorを常用せず、最小権限の管理ロールを使っているか |
| ゲスト・外部ユーザー | Teams共有チャネルや外部共有の権限が残っていないか |
ここでの失敗例は、「Copilotを使うユーザーだけ」を確認してしまうことです。実際には、Copilotが参照できるデータの権限を持つユーザー全体、共有リンク、グループ、外部ユーザーまで含めて確認する必要があります。
SharePointとOneDriveの過剰共有
Microsoftの展開ガイドでは、過剰共有の是正を最初のステップとして位置づけています。高リスクサイトや機密コンテンツを特定し、一時的なCopilot保護を適用したうえで、アクセス権と権限を修正する流れです。(Microsoft Learn)
実務では、次の順番で進めると混乱しにくくなります。
| 手順 | 作業内容 | 判断基準 |
|---|---|---|
| 1 | 高リスクサイトを洗い出す | 人事、法務、経営、財務、顧客情報を含むサイトを優先 |
| 2 | 共有範囲を確認する | Anyoneリンク、全社共有、外部共有、所有者不在を重点確認 |
| 3 | 一時的に露出を抑える | すぐ直せないサイトはRestricted Content DiscoveryやDLPを検討 |
| 4 | 権限を修正する | 過剰なユーザー、グループ、共有リンクを削除または再スコープ |
| 5 | 所有者を確定する | サイトごとに責任者を明確にし、継続的なレビュー対象にする |
重要なのは、「Copilotに見せたくないから非表示にする」だけで終わらせないことです。一時的な制御は有効ですが、最終的には共有設計そのものを直さなければ、将来の検索、監査、情報保護でも同じ問題が再発します。
Microsoft Purviewの秘密度ラベルとDLP
Microsoft 365 Copilotは、Microsoft Purviewの秘密度ラベルや暗号化と連携し、グラウンディングやコンテンツ生成時にアクセス制御と保護設定を適用します。暗号化されたコンテンツをCopilotが扱うには、ユーザーにEXTRACTやVIEWなどの使用権限が必要になる場合があります。(Microsoft Learn)
確認すべきポイントは次のとおりです。
- 秘密度ラベルが実際の機密度に合っているか
- ラベル未設定の古いファイルが大量に残っていないか
- 自動ラベル付けを使うべき情報種別があるか
- DLPでCopilotが処理すべきでないファイルやメールを制御できているか
- プロンプトに入力される機密情報をDLPで検知・制御できるか
たとえば、営業部門の「全社共有」フォルダーに契約前の見積書や顧客別価格表が残っている場合、Copilot導入後に「A社向けの最新提案条件をまとめて」と聞かれたとき、権限を持つユーザーには関連情報が提示される可能性があります。これはCopilotが権限を破っているのではなく、元の共有設計が広すぎることが原因です。
Web検索の利用可否
Microsoft 365 CopilotとMicrosoft 365 Copilot Chatでは、Web検索を有効にするとBing検索サービスから情報を取得し、回答の品質向上に使う場合があります。Microsoftは、生成される検索クエリには通常、ユーザーの完全なプロンプト、Microsoft 365ファイル全体、Entra IDに基づく識別情報などは含まれないと説明しています。(Microsoft Learn)
一方で、Web検索は組織のポリシーに合わせて制御すべき項目です。管理者はCloud Policy service for Microsoft 365の「Allow web search in Copilot」ポリシーを使って、Microsoft 365 CopilotとMicrosoft 365 Copilot ChatのWeb検索をユーザーまたはグループ単位で制御できます。(Microsoft Learn)
判断基準は次のとおりです。
| 組織の状況 | 推奨される確認 |
|---|---|
| 最新の市場情報や公開情報を使いたい | Web検索を有効化し、利用ルールとログ確認手順を整備する |
| 機密性の高い業務が多い | 対象部門を限定し、Web検索クエリの監査方法を確認する |
| 規制産業・公共系で運用する | Web検索のデータ処理条件、監査、保持、社内承認を事前確認する |
| ユーザー教育が未整備 | いきなり全社有効化せず、パイロット展開で利用例を作る |
接続エクスペリエンスのプライバシー制御
Microsoft 365 Appsの接続エクスペリエンス設定も確認が必要です。公式情報では、コンテンツを分析する接続エクスペリエンスをオフにすると、Word、Excel、OneNote、Outlook、PowerPointなどのCopilot機能が利用できなくなる場合があると説明されています。(Microsoft Learn)
「セキュリティ強化のために接続エクスペリエンスを無効化したら、Copilotが使えない」というトラブルは起こりやすいポイントです。Copilot展開前に、セキュリティ部門、Microsoft 365管理者、現場部門で、どの接続機能を許可するかをすり合わせておきましょう。
開発者が確認すべきポイント
Microsoft 365 Copilotのセキュリティは管理者だけの問題ではありません。エージェント、コネクタ、API連携を作る開発者も、Microsoft 365の権限モデルとデータ保護の影響を受けます。
エージェントは「便利な拡張」ではなく「データアクセス経路」として扱う
エージェントは、検索、カスタムアクション、コネクタ、APIを追加してCopilotの機能を拡張します。管理者はMicrosoft 365管理センターでエージェントの有効化、無効化、割り当て、ブロック、削除などを管理できます。(Microsoft Learn)
開発者が確認すべきなのは、次の4点です。
| 確認項目 | 実務上の注意点 |
|---|---|
| 必要権限 | 便利さを優先して広すぎるGraph権限や外部API権限を要求しない |
| 利用データ | プロンプト、応答、参照データ、外部APIに渡すデータを整理する |
| 管理者承認 | エージェントの目的、アクセス範囲、利用者、監査方法を説明できるようにする |
| 利用規約・プライバシー | 外部エージェントや外部サービスを使う場合、データ処理条件を確認する |
「社内FAQを答えるだけのエージェント」のつもりでも、実装次第では人事情報、顧客情報、チケット情報、契約情報にアクセスできてしまうことがあります。開発段階で、どのデータソースにアクセスし、誰の権限で取得し、どの範囲に回答するのかを明確にしてください。
コネクタはACLとスキーマ設計が重要
Microsoft 365 Copilotコネクタでは、外部データをMicrosoft 365 Copilotから検索・参照できるようにできます。同期型コネクタは外部コンテンツをMicrosoft Graphに取り込み、フェデレーション型コネクタはMCPを使ってリアルタイムに外部サービスから取得します。(Microsoft Learn)
開発者が特に注意すべきなのは、外部データのアクセス制御です。公式情報では、同期型コネクタを作るにはアプリ登録と必要なMicrosoft Graph権限への管理者同意が必要であり、外部アイテムのセキュリティが制限されていない場合、展開済みコネクタはテナント全体に影響すると説明されています。(Microsoft Learn)
コネクタ開発では、次の設計を必ず確認します。
- 外部システムの権限をMicrosoft 365側にどう反映するか
- 誰でも見える外部アイテムを作っていないか
- タイトルや本文に機密情報を過剰に含めていないか
- 検索精度を上げるためのメタデータが適切か
- 削除済み・権限変更済みデータがインデックスに残らないか
- 管理者が無効化・削除・監査できる運用になっているか
「検索に出したい情報」と「AIが要約してよい情報」は同じではありません。外部ナレッジを取り込む場合は、検索対象、要約対象、アクション実行対象を分けて設計すると安全性を高めやすくなります。
移行・展開時の注意点
Microsoft 365 Copilotの展開では、ライセンス付与よりも前にデータ準備を進めることが重要です。公式のセキュアな基盤構成ガイドでは、過剰共有の是正、ガードレールの設定、規制要件への対応という流れが示されています。(Microsoft Learn)
いきなり全社展開しない
最初から全社員にライセンスを配布すると、権限の不備や利用ルールの曖昧さが一気に表面化します。まずは、業務データの構造を把握している部門、セキュリティレビューに協力できる部門、効果測定しやすい部門でパイロットを行うのが現実的です。
パイロットでは、次の観点を確認します。
| 確認観点 | 具体例 |
|---|---|
| 回答に出てくるデータ | 意図しない古い資料、部外秘資料、外部共有ファイルが出ていないか |
| ユーザーの使い方 | 機密情報をそのままプロンプトに入力していないか |
| 業務効果 | 会議要約、メール整理、資料作成などで明確な時間短縮があるか |
| 監査性 | 管理者が利用状況やリスクを追跡できるか |
| サポート負荷 | 問い合わせ内容が教育で解決できるものか、設定変更が必要なものか |
「Copilotが見せた」ではなく「権限がそうなっていた」と考える
Copilot導入後に「見えてはいけない資料が回答に出た」という相談が起きた場合、まず疑うべきはCopilotの不具合ではなく、元データの権限です。Microsoft 365 Copilotは、ユーザーが少なくとも表示権限を持つ組織データのみを提示すると説明されています。(Microsoft Learn)
この考え方を現場に伝えておかないと、「AIだから危険」という議論に流れがちです。実際には、Copilotは既存の情報整理の問題を可視化しやすくします。展開を機に、共有リンク、所有者、機密ラベル、保持期限を見直すことが重要です。
モデル変更はセキュリティ設定変更とは分けて考える
Microsoft 365 Copilotで基盤モデルの更新が行われる場合でも、Microsoftはモデル更新がセキュリティ、プライバシー、コンプライアンス設定を変更するものではないと説明しています。(Microsoft Learn)
ただし、実務上はモデル更新により回答品質や推論の傾向が変わる可能性はあります。セキュリティ設定が変わらないからといって、業務上の検証が不要になるわけではありません。重要業務で使うプロンプト、エージェント、コネクタは、定期的に出力確認を行う運用にしておくと安心です。
よくある失敗と回避策
Microsoft 365 Copilotのセキュリティ対応では、次のような失敗が起きやすくなります。
| 失敗例 | なぜ問題か | 回避策 |
|---|---|---|
| Copilotライセンスだけ先に配布する | 過剰共有が回答に反映される可能性がある | 高リスクサイトの棚卸しを先に行う |
| SharePoint管理者だけで進める | Purview、Entra ID、Teams、法務の論点が抜ける | 横断チームを作り、権限・監査・保持を同時に確認する |
| DLPや秘密度ラベルを後回しにする | 機密データの扱いを後から制御しにくい | 最低限のラベル体系とDLP方針を先に定める |
| エージェントを自由に追加させる | 外部サービスやAPI経由のデータ流出リスクが増える | 管理センターで承認、割り当て、ブロックの運用を決める |
| Web検索を無条件に許可する | 業務データと公開情報を組み合わせる利用が発生する | 部門別に有効化範囲とログ確認手順を決める |
| ユーザー教育を省略する | 機密情報入力、出力の過信、誤引用が起きやすい | 利用ルール、禁止例、確認手順を短く明文化する |
特に重要なのは、ユーザー教育です。Microsoftも、生成AIの応答は100%事実である保証はなく、送信前にユーザーが判断して確認する必要があると説明しています。(Microsoft Learn)
展開前チェックリスト
最後に、管理者がSecurity for Microsoft 365 Copilotを確認した後に実施すべきチェックリストを整理します。
| 優先度 | チェック項目 | 担当候補 |
|---|---|---|
| 高 | Copilot利用対象ユーザーとパイロット部門を決める | Microsoft 365管理者、事業部門 |
| 高 | SharePointとOneDriveの高リスクサイトを洗い出す | SharePoint管理者、情報システム |
| 高 | Anyoneリンク、全社共有、外部共有を確認する | SharePoint管理者 |
| 高 | Entra ID、条件付きアクセス、多要素認証を確認する | ID管理者 |
| 高 | Purviewの監査、保持、eDiscoveryの対象を確認する | セキュリティ、法務 |
| 中 | 秘密度ラベルとDLPの適用方針を決める | セキュリティ、各部門 |
| 中 | Web検索の許可範囲を決める | 情報システム、法務、セキュリティ |
| 中 | エージェントとコネクタの承認フローを決める | 管理者、開発者 |
| 中 | ユーザー向け利用ルールを作る | 情報システム、教育担当 |
| 低 | 定期レビューの頻度と責任者を決める | 管理者、内部監査 |
最初の一歩としては、Copilotの管理画面を見る前に、SharePointとOneDriveの共有状態を確認することをおすすめします。Copilotのリスクの多くは、AIそのものではなく「すでに広く見えているデータ」が原因になるためです。
まとめ：Copilotのセキュリティ対応はデータ基盤の見直しから始める
Security for Microsoft 365 Copilotの要点は、Microsoft 365 CopilotがMicrosoft 365の既存のセキュリティ、コンプライアンス、プライバシー保護を継承することにあります。一方で、過剰共有、古い権限、未分類の機密ファイル、管理されていないエージェントやコネクタは、Copilot導入後にリスクとして表面化しやすくなります。
管理者は、ライセンス付与の前にSharePoint、OneDrive、Teams、Exchange、Microsoft Purview、Entra IDの状態を確認してください。開発者は、エージェントやコネクタを「AI機能の追加」ではなく「新しいデータアクセス経路」として設計する必要があります。
次に取るべき行動は明確です。まず高リスクサイトと過剰共有を洗い出し、次にPurviewのラベル、DLP、監査、保持を整え、最後にパイロット展開で実際の回答とログを確認しましょう。Microsoft 365 Copilotを安全に活用できるかどうかは、導入時点のデータガバナンスで大きく決まります。
コメント