Microsoft Security Copilot / Microsoft 365 E5 の自動プロビジョニングで最初に確認すべきことは、「使えるようになるか」ではなく「誰が、どのデータに、どの設定でアクセスできるようになるか」です。
Microsoft は 2026年4月20日更新のドキュメントで、Microsoft 365 E5 ライセンスに Security Copilot が含まれ、対象テナントで有効化される場合、既定の Security Copilot 容量とワークスペース、Owner 設定、既定ロールなどが自動的に構成されることを説明しています。特に重要なのは、データ共有設定は既定で OFF である一方、Microsoft 365 サービスデータへのアクセスは既定で ON になる点です。(Microsoft Learn)
つまり、Microsoft Security Copilot を安全に使い始めるには、導入作業よりも先に、Owner 設定、ロール、データ所在地、監査ログ、利用ポリシーを確認する必要があります。Security teams、compliance leads、platform architects は、単なる新機能の確認ではなく、AI が既存の権限とデータ境界をどのように利用するかという観点で影響評価を進めるべきです。
Microsoft Security Copilot の自動プロビジョニングで何が起きるのか
Microsoft 365 E5 向けの Security Copilot 自動プロビジョニングでは、対象テナントで Security Copilot を使い始めやすくするため、Microsoft 側で既定の構成が作成されます。
公式ドキュメントによると、自動プロビジョニングでは主に次の内容が設定されます。(Microsoft Learn)
| 項目 | 自動プロビジョニングでの扱い | セキュリティ上の確認ポイント |
|---|---|---|
| 既定容量とワークスペース | 既定の Security Copilot 仮想容量とワークスペースが作成される | 誰が Owner として管理できるかを確認する |
| Customer Data storage location | Microsoft Entra の geography、または Microsoft 365 の geo override に基づき事前選択される | データ所在地が社内規程・契約・規制要件と合うか確認する |
| Customer Data sharing preferences | 人によるレビューを伴うデータ共有設定は既定で OFF | 例外的に ON にする場合は法務・コンプライアンス承認が必要 |
| Prompt evaluation location | EU の場合は EU、それ以外は US、UK、EU、ANZ などで処理される可能性がある | プロンプト処理地域が許容範囲か確認する |
| Microsoft 365 サービスデータへのアクセス | 既定で ON | Purview などの Microsoft 365 データを Copilot が参照できる範囲を確認する |
| 既定ロール | 一部の管理者ロールが Owner または Contributor アクセスを継承 | 不要な高権限ユーザーが Copilot を使える状態になっていないか確認する |
この変更は「Security Copilot が勝手に危険な操作をする」という話ではありません。より正確には、既存の Microsoft 365 E5 環境にある権限、データ、監査設計が、Security Copilot という AI インターフェースを通じて使われやすくなるという変化です。
そのため、リスクは Copilot 単体ではなく、既存の RBAC、Purview 設定、Entra ID、Intune、Defender、監査運用の成熟度によって大きく変わります。
安全対策の観点で見るべき重要ポイント
既定で Microsoft 365 サービスデータへのアクセスが ON になる
自動プロビジョニングで最も優先して確認すべきなのは、Security Copilot が Microsoft 365 サービスデータへアクセスできる設定です。
Microsoft の説明では、この設定により Security Copilot は Microsoft Purview などの Microsoft 365 サービスから直接情報を照会できます。自動プロビジョニングでは、この設定が既定で ON になります。管理者は Owner settings から無効化できますが、無効化すると Microsoft 365 製品と連携した Security Copilot の機能は制限されます。(Microsoft Learn)
ここで重要なのは、ON が悪いということではありません。Security Copilot の価値は、Purview、Entra、Intune、Defender などのデータを横断して分析できる点にあります。問題は、その前提となるアクセス権が整理されていない状態で ON になっていることです。
たとえば、Purview のロールグループに長年使われていない管理者アカウントや外部委託先アカウントが残っている場合、Security Copilot の導入によって、これまで手作業では見つけにくかった情報が自然言語で引き出しやすくなる可能性があります。
データ共有設定は OFF だが、データ処理そのものは発生する
自動プロビジョニングでは、Microsoft が Security Copilot のデータを取得し、人によるレビューで製品性能の検証やセキュリティ AI モデルの検証に使う設定は、既定で OFF です。(Microsoft Learn)
ただし、これを「Copilot 利用時にデータ処理が発生しない」と解釈してはいけません。Security Copilot を使うと、ユーザーのプロンプト、応答、応答生成のために取得された情報などは、サービス提供のために処理・保存されます。Microsoft のプライバシー文書では、Customer Data としてプロンプト、応答、取得された情報、ファイルアップロードなどが扱われることが説明されています。(Microsoft Learn)
コンプライアンス部門が確認すべきポイントは、次の3つです。
| 確認項目 | 判断基準 |
|---|---|
| データ共有設定 | 既定 OFF を維持するか、明示的な承認プロセスを経て ON にするか |
| データ所在地 | Customer Data storage location が社内のデータレジデンシー要件と合うか |
| プロンプト処理地域 | GPU による評価場所が、規制・契約・社内規程上許容されるか |
特に金融、医療、公共、グローバル企業では、「データ共有 OFF」だけで安心せず、保存場所と処理場所を分けて確認する必要があります。
既定ロールにより利用可能な管理者が広がる可能性がある
Microsoft の自動プロビジョニング文書では、Global Administrator、Security Administrator、Conditional Access Administrator、Intune Administrator、複数の Purview / Compliance 関連ロールなどが Security Copilot の Owner アクセスを継承することが示されています。また、Defender や Purview の一部ロールは Contributor アクセスを継承します。(Microsoft Learn)
ここでのリスクは、Security Copilot が特権昇格することではありません。Microsoft の説明では、Security Copilot はユーザーとしてクエリを実行するため、そのユーザーが持つ権限を超えてアクセスすることはありません。(Microsoft Learn)
しかし、実務上は別の問題があります。既存の管理者ロールが広すぎる場合、Copilot によって「広すぎる権限の影響」が見えやすく、使いやすくなります。
たとえば、次のような状態は見直し対象です。
| 状態 | リスク |
|---|---|
| Global Administrator が日常運用に使われている | Copilot Owner 相当の管理範囲が広がりやすい |
| 退職者・異動者・委託先の管理者権限が残っている | 不要なユーザーが Copilot 経由で情報を取得できる可能性がある |
| Purview ロールグループが部門横断で過剰付与されている | DLP、IRM、eDiscovery、Communication Compliance 関連情報の露出面が広がる |
| PIM やアクセスレビューが未整備 | 一時的に必要な権限が恒久的に残りやすい |
Security Copilot の安全対策は、Copilot の設定だけで完結しません。Entra ID、Purview、Defender、Intune のロール棚卸しが前提になります。
Microsoft 365 E5 組織が優先すべきリスク低減策
まず Owner settings を確認する
対象テナントで Security Copilot が有効化されたら、最初に確認すべき場所は Security Copilot ポータルの Owner settings です。
Owner settings では、利用とデータプライバシーに関する設定を管理できます。Microsoft のドキュメントでは、容量管理、データ共有、Purview への監査データログ、ファイルアップロード管理などが Owner settings の対象として説明されています。(Microsoft Learn)
確認する順序は次のとおりです。
| 優先度 | 確認内容 | 実務上の判断 |
|---|---|---|
| 高 | Customer Data storage location | 想定した地域になっているかを証跡として残す |
| 高 | Customer Data sharing preferences | 原則 OFF。ON にする場合は承認者・理由・対象期間を記録する |
| 高 | Microsoft 365 service data access | RBAC レビュー完了前は慎重に扱う。無効化時は機能制限も説明する |
| 高 | 既定ロール | Owner / Contributor を必要最小限に絞る |
| 中 | Prompt evaluation location | グローバル処理が許容されるかを確認する |
| 中 | ファイルアップロード | 機密ファイルのアップロードルールを定める |
| 中 | Usage monitoring | 部門別・用途別の利用傾向を確認する |
特に初期段階では、設定画面のスクリーンショットや変更履歴を残し、監査時に「いつ、誰が、どの判断で設定したか」を説明できる状態にしておくと安全です。
Copilot Owner を「職務」で定義する
Security Copilot の Owner は、便利だからといって広く付与すべきではありません。Owner は設定変更やデータ関連の管理に関わるため、単なる利用者ではなく、運用責任を持つロールとして扱う必要があります。
おすすめは、個人名ではなく職務ベースのグループで管理する方法です。
| 役割 | 推奨される関与 |
|---|---|
| Security Operations Lead | 利用ユースケース、インシデント対応、SOC 運用を判断 |
| Compliance Lead | データ共有、保存場所、監査要件を判断 |
| Platform Architect | Entra、Purview、Intune、Defender との統合影響を判断 |
| IAM Administrator | PIM、アクセスレビュー、管理者ロールを管理 |
| Privacy / Legal | 人によるレビュー、外部委託、規制要件を確認 |
Global Administrator を日常的な Owner として使うのは避けるべきです。Microsoft も、Global Administrator は高権限ロールであり、既存ロールでは対応できない緊急時に限定することを推奨しています。(Microsoft Learn)
既存の RBAC を Copilot 前提で棚卸しする
Security Copilot の導入で新しいリスクが生まれるというより、既存の権限設計の粗さが露出しやすくなります。
特に確認すべき領域は次の4つです。
| 領域 | 確認するロール・権限 |
|---|---|
| Microsoft Entra | Global Administrator、Security Administrator、Conditional Access Administrator |
| Microsoft Purview | Compliance Administrator、Organization Management、Information Protection、Insider Risk Management、Communication Compliance 関連ロール |
| Microsoft Defender | Defender XDR の Unified RBAC、Security operations、Security posture、Authorization and settings |
| Microsoft Intune | Intune Administrator、Endpoint Security Manager、デバイス管理関連ロール |
Defender では Unified RBAC によってカスタムロールを作成し、ポータル体験へのアクセスを細かく制御できます。Microsoft のドキュメントでも、Defender Unified RBAC は特定の権限を持つカスタムロールを作成し、ユーザーやグループに割り当てる仕組みとして説明されています。(Microsoft Learn)
棚卸しでは、単に「誰が管理者か」を見るだけでは不十分です。次の観点で確認してください。
| チェック | 見るべきポイント |
|---|---|
| 人の妥当性 | 現在の職務に必要な権限か |
| 期間の妥当性 | 一時的な権限が残っていないか |
| 外部ユーザー | 委託先やゲストに不要な権限がないか |
| グループ継承 | ネストされたグループ経由で意図せず権限が付いていないか |
| 緊急用アカウント | break-glass アカウントが通常利用されていないか |
Copilot 利用前に完璧な RBAC を作る必要はありません。しかし、少なくとも Owner / Contributor に該当する可能性があるユーザーは、先にレビューしておくべきです。
Microsoft 365 サービスデータへのアクセスは「価値」と「露出面」で判断する
Security Copilot の Microsoft 365 サービスデータアクセスを ON にすると、Purview などのデータを使ってセキュリティ分析や調査を支援できます。たとえば、DLP アラート、ラベル付けアクティビティ、eDiscovery のレビューセット、Insider Risk Management のアラート、Communication Compliance のポリシーマッチなどが関連します。(Microsoft Learn)
ただし、これは非常に強力です。DLP や eDiscovery の情報は、企業の機密情報、従業員情報、法務関連情報に近い領域を扱うことがあります。
判断基準は次のように整理できます。
| 状況 | 推奨判断 |
|---|---|
| RBAC と Purview ロールの棚卸しが完了している | ON のまま、利用範囲と監査を明確にする |
| Purview ロールが長年見直されていない | 一時的に制限またはパイロット対象を限定する |
| 規制対象データを多く扱う | Compliance Lead の承認を必須にする |
| SOC の初動調査を効率化したい | DLP、Defender、Entra の優先ユースケースに絞って開始する |
| 法務・人事系データの扱いが未整理 | eDiscovery、IRM、Communication Compliance 周辺は慎重に開始する |
「便利だから全社で使う」ではなく、「どの調査業務に使うか」を先に決めるのが安全です。
初期導入で使える安全な運用手順
有効化前または通知受領後に行うこと
Microsoft 365 E5 向け Security Copilot は、対象顧客に段階的に提供され、Microsoft 365 管理センターなどで 30日前通知を受け取ると説明されています。(Microsoft Learn)
通知を受け取った段階で、次の準備を進めます。
| 作業 | 担当 | 成果物 |
|---|---|---|
| 対象テナントの確認 | Platform Architect | 有効化予定テナント一覧 |
| Owner 候補の定義 | Security Lead / IAM | Owner グループ案 |
| 既定ロールの棚卸し | IAM / 各管理チーム | 高権限ロールのメンバー一覧 |
| データ所在地要件の確認 | Compliance / Legal | 許容される保存・処理地域の整理 |
| Microsoft 365 データアクセス方針 | Security / Compliance | ON / OFF 判断と理由 |
| 監査ログ方針 | Compliance / SOC | ログ確認頻度と担当者 |
| 利用ポリシー作成 | Security Enablement | 利用可・禁止例を含むガイド |
この段階で重要なのは、技術設定だけでなく「判断者」を決めることです。Security Copilot はセキュリティ、コンプライアンス、プラットフォームの境界にあるサービスのため、1チームだけで判断すると抜け漏れが起きやすくなります。
有効化直後の48時間で確認すること
有効化後は、まず既定設定の確認に集中します。いきなり広範な利用を開始するのではなく、設定と権限の証跡を残してください。
| 確認項目 | 実施内容 |
|---|---|
| ワークスペース | 既定ワークスペースが作成されているか確認 |
| Owner / Contributor | 想定外の管理者が含まれていないか確認 |
| データ共有 | 人によるレビュー設定が OFF のままか確認 |
| Microsoft 365 データアクセス | ON / OFF の状態と理由を記録 |
| データ所在地 | Customer Data storage location を記録 |
| プロンプト処理地域 | 組織要件と合っているか確認 |
| 監査ログ | Purview 側でログ確認手順を整備 |
| 利用者 | パイロットユーザーだけに案内 |
この時点では、「Security Copilot を使える人を増やす」よりも、「設定が説明可能な状態になっているか」を優先します。
最初の30日でパイロット運用する
最初の30日は、全社展開ではなく、限定されたユースケースで運用するのが現実的です。
Microsoft は、Security Copilot の利用例として、フィッシングトリアージ、アラートトリアージ、アクセスレビュー、脆弱性修復支援などを挙げています。(Microsoft Learn)
初期ユースケースとしては、次のようなものが扱いやすいです。
| ユースケース | 向いている理由 | 注意点 |
|---|---|---|
| フィッシング報告の要約 | SOC の初動負荷を下げやすい | 自動判定だけで隔離・削除しない |
| Defender インシデントの要約 | 既存アラートの理解を早められる | 重大インシデントは人が根拠を確認する |
| 条件付きアクセスの影響確認 | Identity チームのレビューに役立つ | ポリシー変更は必ず承認フローを通す |
| DLP アラートの説明 | コンプライアンス担当者の調査を補助できる | 個人情報や機密情報の出力範囲に注意 |
| Intune 関連の変更確認 | 端末管理の影響評価に使いやすい | 推奨内容をそのまま本番適用しない |
パイロットの評価指標は、単なる利用回数ではなく、次のように設定すると実務に役立ちます。
| 指標 | 具体例 |
|---|---|
| 時間短縮 | アラート要約にかかる平均時間が短縮したか |
| 品質 | 誤った要約や根拠不明の提案がどの程度あったか |
| 安全性 | 不要なデータ出力や過剰な権限利用がなかったか |
| 監査性 | 誰が、いつ、どの用途で使ったか追跡できるか |
| 教育効果 | 初級アナリストの判断支援に役立ったか |
監査ログと利用状況の確認を運用に組み込む
Security Copilot を安全に運用するには、設定時の確認だけでなく、継続的な監査が必要です。
Microsoft のドキュメントでは、Security Copilot の監査ログについて、Microsoft Purview Unified Audit Log、Microsoft Purview Data Security Posture Management for AI、Office Management API などを通じて、コンプライアンスや規制要件に対応するための可視性を提供すると説明されています。Unified Audit Log では管理者イベントやアクティビティメタデータ、DSPM for AI ではプロンプトと応答のペアに関する洞察を得られるとされています。(Microsoft Learn)
運用では、次の確認を定例化してください。
| 頻度 | 確認内容 |
|---|---|
| 毎日 | 高権限ユーザーの利用、異常な大量利用、重要インシデント関連の利用 |
| 毎週 | ユースケース別の利用傾向、想定外のユーザー利用、プロンプト品質 |
| 毎月 | Owner / Contributor の見直し、設定変更履歴、ポリシー違反の有無 |
| 四半期 | RBAC 棚卸し、監査証跡のレビュー、利用ポリシー更新 |
また、Security Copilot の SCU 使用量も確認対象です。Microsoft は Copilot owners が使用量ダッシュボードで一定期間の SCU 消費を確認できると説明しています。(Microsoft Learn)
Microsoft 365 E5 では、1,000 paid user licenses あたり月 400 SCU、最大月 10,000 SCU が含まれると説明されていますが、容量はテナント全体で共有されます。(Microsoft Learn) そのため、部門ごとの無計画な利用が増えると、重要な調査で必要なときに利用制約が問題になる可能性があります。
利用ポリシーに必ず入れるべき内容
Security Copilot の利用ポリシーは、抽象的な「機密情報に注意」だけでは不十分です。現場が判断できるように、許可される使い方と禁止される使い方を具体化してください。
許可する使い方の例
| 使い方 | 例 |
|---|---|
| インシデントの要約 | Defender のインシデント内容を要約し、確認すべき端末・ユーザー・アラートを整理する |
| 調査観点の整理 | 疑わしいサインインについて、確認すべきログや関連リスクを洗い出す |
| DLP アラートの初期整理 | アラートの内容、関係するラベル、次の確認事項をまとめる |
| 条件付きアクセスのレビュー補助 | 既存ポリシー変更時の影響を確認する |
| 初級アナリストの教育 | 調査手順や用語の理解を補助する |
禁止または承認制にする使い方の例
| 使い方 | 理由 |
|---|---|
| 個人情報を含む内容を不要に貼り付ける | 最小限のデータ利用原則に反する |
| 法務・人事・内部通報関連の情報を無承認で調査する | アクセス権があっても職務上の必要性が限定される |
| Copilot の回答だけでアカウント停止や端末隔離を行う | 誤判定時の業務影響が大きい |
| 機密ファイルを検証なしにアップロードする | ファイル内容が応答生成に使われる可能性がある |
| 外部共有用の調査報告をそのまま生成して送付する | 文脈の誤りや過剰開示のリスクがある |
| カスタムプラグインやエージェントを無承認で追加する | 外部システム連携によるデータ流出面が広がる |
ポリシーには、次の一文を入れておくと現場で使いやすくなります。
「Security Copilot の回答は調査支援情報であり、重要な封じ込め、削除、アクセス停止、懲戒、法務判断は、担当者が根拠ログと社内手続きに基づいて承認する。」
これにより、AI の出力を便利な下書きとして使いつつ、最終判断を人間の統制下に置けます。
失敗しやすいポイントと対策
「E5 に含まれるなら安全に使える」と考える
Microsoft 365 E5 に含まれることは、導入しやすいことを意味します。しかし、安全に使えることを自動的に保証するものではありません。
特に、既存の高権限ロール、Purview ロールグループ、外部委託先アカウント、古い管理者アカウントが残っている環境では、Security Copilot の前に IAM と RBAC を見直す必要があります。
「データ共有 OFF だからデータリスクはない」と考える
データ共有 OFF は重要な安全設定ですが、Security Copilot の利用に伴うデータ処理や保存がなくなるわけではありません。
プロンプト、応答、応答生成のために取得された情報は、サービス提供のために扱われます。データ共有 OFF、データ所在地、プロンプト評価場所、Microsoft 365 サービスデータアクセスは、別々の設定として確認してください。
「Copilot が権限を超えて情報を取る」と誤解する
Security Copilot はユーザーの権限を超えてアクセスするものではありません。ただし、既存の権限が広すぎる場合、その影響が大きくなります。
そのため、対策は「Copilot を疑う」ことではなく、「ユーザーと管理者の権限を最小化する」ことです。
「エージェントも自動で有効になる」と考える
Microsoft の FAQ では、Security Copilot agents は自動的に有効化されるのではなく、組織が関連するスタンドアロンまたは組み込みエクスペリエンスで設定・展開する必要があると説明されています。(Microsoft Learn)
エージェントは業務効率化に有効ですが、トリガー、実行範囲、接続先、承認フローを明確にしてから展開してください。
グローバル組織での実践的な設計例
日本、米国、EU に拠点があり、Microsoft 365 E5 を利用している企業なら、次のような設計が現実的です。
| 領域 | 設計例 |
|---|---|
| 管理体制 | Security Copilot Owner はグローバル共通の管理グループで運用 |
| 地域要件 | EU、US、日本のデータ所在地・処理地域要件を Compliance Lead が確認 |
| 利用開始 | まず SOC と IAM チームに限定してパイロット |
| Purview 連携 | DLP と Information Protection から開始し、IRM や eDiscovery は後段で検討 |
| 監査 | Purview の監査ログと DSPM for AI を定例レビューに組み込む |
| 教育 | 利用可能なプロンプト例、禁止例、エスカレーション基準を配布 |
| 変更管理 | エージェント、カスタムプラグイン、データ共有 ON は CAB または同等の承認制 |
この設計のポイントは、Security Copilot を「全社共通の便利ツール」として展開しないことです。最初は高価値で低リスクなユースケースに絞り、監査と RBAC が追いついた領域から拡大します。
すぐに実行すべきチェックリスト
最後に、Microsoft Security Copilot / Microsoft 365 E5 を使う組織が、すぐに実行すべき項目を整理します。
| 優先度 | アクション |
|---|---|
| 最優先 | Microsoft 365 管理センターや各ポータルで Security Copilot 有効化通知を確認する |
| 最優先 | Security Copilot Owner / Contributor に該当するロールのメンバーを棚卸しする |
| 最優先 | Owner settings でデータ共有、データ所在地、Microsoft 365 サービスデータアクセスを確認する |
| 高 | Purview、Entra、Defender、Intune の高権限ロールを見直す |
| 高 | Compliance Lead とデータ所在地・プロンプト処理地域の許容範囲を確認する |
| 高 | 監査ログの確認方法とレビュー頻度を決める |
| 中 | パイロット対象ユーザーとユースケースを限定する |
| 中 | 利用ポリシーに許可例、禁止例、承認制の操作を明記する |
| 中 | SCU 使用量の監視と部門別利用状況の確認を運用に入れる |
| 中 | エージェントやカスタムプラグインの展開に変更管理プロセスを適用する |
Microsoft Security Copilot の自動プロビジョニングは、導入のハードルを下げる一方で、既存の権限設計とデータガバナンスの品質をそのまま映し出します。
最初に行うべきことは、新しいプロンプトを試すことではありません。Owner settings を確認し、既定ロールを見直し、Microsoft 365 サービスデータへのアクセス方針を決め、監査できる状態を作ることです。
そのうえで、SOC、IAM、コンプライアンス、エンドポイント管理など、効果が大きく責任範囲が明確なユースケースから始めれば、Microsoft 365 E5 に含まれる Security Copilot を安全かつ実務的に活用できます。
コメント