Microsoft Security Copilot / Microsoft 365 E5 の最新動向で最初に押さえるべき結論は、Security Copilot が「一部の先進企業が個別に導入するAIツール」から、「Microsoft 365 E5 のセキュリティ運用に組み込まれる標準的なAI基盤」へ移りつつある、という点です。
2026年4月20日更新の Microsoft Learn「Microsoft 365 E5 customers 向け Security Copilot の自動プロビジョニング」では、対象テナントで Security Copilot の既定ワークスペース、既定容量、データ所在地、データ共有、Microsoft 365 サービスデータアクセス、既定ロールが自動設定されることが明記されました。つまり、IT部門が見るべき論点は「使えるかどうか」から「誰に、どのデータ範囲で、どの業務に、どの容量で使わせるか」へ変わっています。(Microsoft Learn)
Product owner、IT decision-maker、technical strategist が今やるべきことは、ライセンス確認だけではありません。Microsoft Security Copilot を Microsoft 365 E5 のロードマップ上の“組み込み型セキュリティAI”として捉え、RBAC、データ境界、SCU使用量、エージェント展開、監査・教育まで含めた運用方針を先に決めることです。
Microsoft documents auto-provisioning of Security Copilot for Microsoft 365 E5 customers が意味すること
今回の更新は、単なるドキュメント追加ではありません。Microsoft Security Copilot / Microsoft 365 E5 の中期的な方向性を読むうえで、かなり重要なシグナルです。
Microsoft の説明では、Security Copilot が Microsoft 365 E5 ライセンスに含まれ、テナントが有効化されると、Microsoft が自動的にプロビジョニングとオンボーディングを行います。これにより、Purview、Entra、Intune、Security Copilot ポータルなどの業務フロー内で利用を開始できる構成になります。(Microsoft Learn)
特に注目すべき点は、以下の3つです。
| 観点 | これまでの見方 | 今回の更新から読むべき方向性 |
|---|---|---|
| 導入 | Azure側で容量や初期設定を設計してから使う | Microsoft 365 E5 テナントでは自動有効化を前提に準備する |
| 利用形態 | スタンドアロンのAIチャットとして検証する | Defender、Purview、Entra、Intune などの業務に組み込む |
| 管理 | 導入プロジェクトで個別に管理する | E5標準機能として、継続的なガバナンス対象にする |
この変化は、Security Copilot を「SOC向けの便利な補助ツール」としてだけ見ている組織ほど見落としやすいポイントです。Microsoft 365 E5 の中に入ってくる以上、利用者はセキュリティアナリストだけに限られません。ID管理、エンドポイント管理、データ保護、コンプライアンス対応、IT運用まで影響範囲が広がります。
Microsoft Security Copilot / Microsoft 365 E5 のロードマップは「組み込み型エージェント」へ向かっている
Microsoft は Ignite 2025 で、Security Copilot エージェントを Microsoft Defender、Microsoft Entra、Microsoft Intune、Microsoft Purview の日常業務フローに直接組み込む方針を示しました。既存の Security Copilot 利用中の Microsoft 365 E5 顧客からロールアウトが始まり、その他の E5 顧客にも段階的に展開され、対象顧客には有効化前に通知されるとされています。(Microsoft Learn)
この流れから見ると、今後のロードマップは次のように整理できます。
Security Copilot は「画面を開いて質問するAI」から「業務の中で動くAI」へ変わる
これまでの生成AI導入では、ユーザーがAI用の画面に移動し、プロンプトを入力し、回答を業務に戻す形が一般的でした。Security Copilot の方向性は逆です。
Microsoft Defender でアラートを調査する、Microsoft Entra でアクセスレビューや条件付きアクセスを見直す、Microsoft Purview でDLPやデータリスクを確認する、Microsoft Intune でデバイス状態を把握する。こうした作業の中に Copilot やエージェントが入ることで、AIは「別ツール」ではなく「作業フローの一部」になります。
これはProduct ownerにとって重要です。導入KPIを「何人がCopilotを起動したか」だけで測ると、本来の価値を見誤ります。見るべき指標は、フィッシング調査時間、アクセスレビューの滞留、DLPアラートの一次判断時間、デバイス修復までの時間など、業務単位の改善です。
E5の価値は「ライセンスの束」から「AI付きセキュリティ運用基盤」へ広がる
Microsoft 365 E5 は、Defender、Entra、Purview、Intune などのセキュリティ・コンプライアンス機能をまとめた上位ライセンスとして扱われてきました。Security Copilot が E5 に含まれる方向になると、E5 の価値は「機能が多いライセンス」から「AIを前提にした統合セキュリティ運用基盤」へ変わります。
IT decision-maker が検討すべき論点も変わります。単に「Security Copilot が追加費用なしで使えるか」ではなく、E5 の既存投資をどれだけAIで活用できるか、E3からE5へのアップグレード判断にどの程度影響するか、既存のSOC・ID・DLP運用コストをどこまで圧縮できるかを見積もる必要があります。
エージェント化により、標準機能と独自ワークフローの境界が薄くなる
Microsoft Learn の「新機能」では、2025年11月時点で Microsoft 365 E5 顧客向けに Security Copilot が含まれ、Microsoft製およびパートナー製の新しいエージェント群が追加されたことが説明されています。また、2026年4月には Security Analyst Agent のパブリックプレビューも掲載されています。(Microsoft Learn)
この流れは、Security Copilot が単なる会話型AIではなく、エージェント基盤として拡張されていくことを示しています。technical strategist は、今後の設計で次のような観点を持つべきです。
| 設計対象 | 検討すべきこと |
|---|---|
| 標準エージェント | Defender、Entra、Intune、Purview のどの業務から使うか |
| カスタムエージェント | 自社のインシデント対応手順、承認フロー、レポート作成に適用できるか |
| パートナーエージェント | 既存のSIEM、SOAR、脆弱性管理、ID管理ツールと競合・補完するか |
| 監査 | エージェントが何を参照し、何を提案し、誰が実行したかを追跡できるか |
Microsoft 365 E5 に含まれる Security Copilot は「無制限利用」ではない
Microsoft 365 E5 顧客向けの Security Copilot で特に誤解しやすいのが容量です。Microsoft の説明では、Microsoft 365 E5 顧客には 1,000有償ユーザーライセンスあたり月400 SCU、最大で月10,000 SCU が含まれます。400ライセンスなら月160 SCU、4,000ライセンスなら月1,600 SCU という例も示されています。(Microsoft Learn)
SCUは Security Compute Unit の略で、Security Copilot のワークロードを実行するためのコンピュート容量です。E5に含まれる容量はテナント全体で共有され、月次で更新され、未使用分は翌月に繰り越されません。既定の Security Copilot Capacity は自動作成され、変更できず、画面上のコスト表示は情報提供用であり時間課金を示すものではないと説明されています。(Microsoft Learn)
| 容量モデル | 向いている組織・用途 | 注意点 |
|---|---|---|
| Microsoft 365 E5 inclusion capacity | E5契約済みで、まず標準ワークフローにSecurity Copilotを組み込みたい組織 | 月次枠であり、未使用分は繰り越されない |
| Provisioned capacity | 安定した利用量があり、一定の性能・容量を確保したい組織 | 時間単位で容量を確保するため、使い切らない時間帯もコスト設計が必要 |
| Overage capacity | 繁忙期やインシデント対応時の急増に備えたい組織 | 利用状況に応じた追加コスト管理が必要 |
実務では、最初から全社展開するよりも、利用シナリオごとにSCU消費を観測するのが安全です。たとえば、フィッシングトリアージ、条件付きアクセス見直し、DLPアラート分析、インシデント要約をそれぞれ小さく試し、どの業務が最も容量対効果を出しやすいかを見極めます。
自動プロビジョニング後に最初に確認すべき設定
自動プロビジョニングは便利ですが、「自動で安全な運用設計まで完了する」という意味ではありません。Microsoft Learn では、既定ワークスペース、既定容量、ワークスペース設定、追加設定、既定ロールが自動で割り当てられると説明されています。(Microsoft Learn)
有効化されたら、管理者はまず次の設定を確認してください。
| 確認項目 | 既定・仕様のポイント | 実務での判断基準 |
|---|---|---|
| Customer Data storage location | 既定ワークスペースのデータ保存場所は Microsoft Entra の地理情報をもとに事前選択される | グローバル企業は、リージョン、データ所在地要件、契約上の制約と合うか確認する |
| Customer Data sharing preferences | 製品性能検証やモデル構築・検証のための人手レビュー設定は既定でOFF | 原則OFFで開始し、法務・セキュリティ・プライバシー部門の承認後に判断する |
| Prompt evaluation location | EUのデータ保存場所ではEU処理、それ以外ではGPU可用性などに応じてグローバル処理が選ばれる | データ所在地だけでなく、プロンプト処理場所も確認する |
| Microsoft 365 services data access | Security Copilot が Microsoft 365 サービスデータへアクセスする設定は既定でON | Copilot活用には重要だが、Purviewや機密データの参照範囲を事前に整理する |
| Default roles | Global Administrator、Security Administrator、Intune Administrator など一部ロールが既定アクセスを継承する | 最小権限の原則で、OwnerとContributorを棚卸しする |
特に重要なのは、Microsoft 365 サービスデータアクセスです。既定でONになっているため、Security Copilot は対応するMicrosoft 365サービスの情報を使って回答できます。一方で、無効化すると Microsoft 365 製品と連携した価値は制限されます。(Microsoft Learn)
この設定は「便利か危険か」の二択で見るべきではありません。正しい判断軸は、ユーザー権限、参照対象データ、業務目的、監査要件がそろっているかです。Security Copilot はユーザーとしてクエリを実行し、ユーザーの権限を超えて昇格するわけではないと説明されていますが、逆に言えば、ユーザーが広い権限を持っていればAIの応答対象も広がります。(Microsoft Learn)
役割別に見る運用方針
Microsoft Security Copilot / Microsoft 365 E5 の運用では、関係者ごとに見るべきポイントが異なります。全員が同じ観点で議論すると、導入は進んでも成果が出にくくなります。
| 役割 | 主な関心事 | 最初に決めるべきこと |
|---|---|---|
| Product owner | 業務価値、利用シナリオ、ユーザー定着 | どのセキュリティ業務をCopilotで短縮・標準化するか |
| IT decision-maker | ライセンス、コスト、リスク、コンプライアンス | E5包含容量、追加容量、利用部門、データ共有方針をどう管理するか |
| Technical strategist | アーキテクチャ、権限、統合、拡張性 | RBAC、ワークスペース、エージェント、監査ログ、既存ツール連携をどう設計するか |
Product owner は「利用率」ではなく「業務成果」を見る
Product owner が最初にやるべきことは、Security Copilot のユースケースを業務単位に分解することです。
たとえば「SOCで使う」では曖昧です。次のように、作業と成果をセットで定義します。
| ユースケース | 測るべき成果 |
|---|---|
| フィッシング報告の一次トリアージ | 判定待ち時間、誤検知率、アナリストの処理件数 |
| インシデント要約 | 初動判断までの時間、引き継ぎメモ作成時間 |
| 条件付きアクセスの見直し | カバー漏れポリシー数、例外設定の削減数 |
| DLPアラート分析 | アラート確認時間、エスカレーション精度 |
| Intuneデバイス調査 | 非準拠デバイスの原因特定時間、修復完了率 |
「Copilotを使ったか」ではなく、「人が何分短縮できたか」「判断のばらつきが減ったか」「重大な見落としが減ったか」を見るべきです。
IT decision-maker は「含まれる容量」と「追加費用の境界」を明確にする
E5に含まれるからといって、無計画に開放してよいわけではありません。Microsoft の説明では、含まれるSCUを超えた場合の扱いや、将来的な超過利用オプションについても記載されています。現時点の契約・地域・提供条件によって扱いが変わる可能性があるため、実際の予算化ではMicrosoft 365管理センター、契約条件、Microsoft担当者または販売パートナーで確認する必要があります。(Microsoft Learn)
IT decision-maker が作るべきポリシーは、次の3つです。
| ポリシー | 決める内容 |
|---|---|
| 利用対象 | どの部門・ロールから開始するか |
| 容量管理 | 月次SCUの使用量を誰が監視し、どの閾値で制御するか |
| 追加費用 | 超過容量や既存のProvisioned capacityをどう扱うか |
既存のSecurity Copilot顧客で、すでに容量をプロビジョニングしている場合は、E5包含が始まったからといってすぐ削除しないほうが安全です。Microsoft のFAQでも、既存容量を保持して利用継続性を確保することが推奨されています。(Microsoft Learn)
Technical strategist は「AIの回答」より「AIが参照できる境界」を設計する
technical strategist にとって最重要なのは、プロンプト設計よりもデータ境界と権限設計です。
Security Copilot は、Microsoft 365やMicrosoft Security製品のデータを参照して価値を出します。そのため、権限が広すぎる管理者、長期間放置された例外ロール、古いグループメンバーシップ、不要なPurview権限があると、AI活用の前にガバナンスリスクが高まります。
最初に確認すべき技術項目は次のとおりです。
| 技術項目 | 確認ポイント |
|---|---|
| Entraロール | Global Administrator の常用を避け、Security Administrator や各製品管理者を適切に分離しているか |
| Security Copilot Owner | Owner権限を持つユーザーが多すぎないか |
| Contributor | Defender、Purviewなどのロール継承で意図せずアクセスが広がっていないか |
| Purviewデータ | DLP、IRM、eDiscovery、Communication Compliance などの機密性に応じた利用ルールがあるか |
| 監査 | エージェント管理、設定変更、利用状況を追跡できるか |
| プラグイン・エージェント | どのエージェントを誰が有効化・展開できるか決まっているか |
自動プロビジョニング後の導入計画
Microsoft 365 E5 テナントで Security Copilot が有効化される前後は、次の順序で進めると失敗しにくくなります。
| フェーズ | やること | 成果物 |
|---|---|---|
| 事前準備 | Microsoft 365 管理センターの通知確認、対象テナント確認、既存ロール棚卸し | 有効化対象テナント一覧、管理者一覧 |
| 初期確認 | Owner settings、データ所在地、データ共有、Microsoft 365データアクセス、既定ロール確認 | 初期設定レビューシート |
| パイロット | Defender、Entra、Purview、Intune のうち1〜2領域で小さく検証 | ユースケース別の効果測定 |
| ガバナンス整備 | 利用ルール、承認フロー、禁止事項、プロンプト取り扱い、監査手順を整備 | Security Copilot利用ポリシー |
| 展開 | 対象部門を広げ、SCU使用量と業務成果を月次レビュー | 月次利用・改善レポート |
大切なのは、最初から「全社AI活用」を掲げないことです。Security Copilot はセキュリティ業務に深く関わるため、失敗すると単なる利用停止では済まず、監査・権限・データ管理の問題に発展します。
まずは、影響範囲が明確で、効果を測りやすい業務から始めるべきです。
おすすめの初期ユースケースは次の4つです。
| 優先度 | ユースケース | 選びやすい理由 |
|---|---|---|
| 高 | フィッシング報告の一次調査 | 件数が多く、定型判断が多いため効果を測りやすい |
| 高 | インシデント要約 | アナリストの引き継ぎ・初動判断に直結する |
| 中 | 条件付きアクセスやアクセスレビュー支援 | ID管理の改善効果が大きいが、承認設計が必要 |
| 中 | DLP・データリスク分析 | 機密データを扱うため、Purview設計とセットで進める必要がある |
失敗しやすいポイント
「E5に含まれるから全員に開放する」は危険
Microsoft 365 E5 に含まれることは、全ユーザーに自由利用させることを意味しません。Security Copilot はセキュリティデータ、ID情報、デバイス情報、コンプライアンス関連データに近い場所で動きます。
まずは、業務上必要な担当者に限定し、OwnerとContributorを分け、利用ログを確認しながら広げるべきです。
「自動プロビジョニングされたので設定確認は不要」と考える
自動プロビジョニングでは、既定ワークスペースや設定が割り当てられます。しかし、組織のデータ所在地ポリシー、プライバシー要件、国・地域ごとの規制、社内のAI利用規程まで自動で判断してくれるわけではありません。
グローバル企業では、特にプロンプト評価場所、データ保存場所、Microsoft 365データアクセス、データ共有設定を確認してください。
「エージェントも自動で全部動く」と誤解する
Microsoft のFAQでは、Security Copilot エージェントが自動的に有効化されるわけではなく、組織側で関連するスタンドアロンまたは組み込みエクスペリエンスに設定・展開する必要があると説明されています。(Microsoft Learn)
これは重要です。自動プロビジョニングは利用開始の土台を作るものであり、各エージェントの業務適用、実行範囲、承認フロー、例外処理は組織が設計する必要があります。
「AIの提案をそのまま実行する」前提にする
Security Copilot の価値は、調査、要約、優先順位付け、推奨アクションの提示にあります。ただし、アクセス権変更、ポリシー変更、データ削除、インシデント封じ込めなどの高影響操作では、人間の承認を残すべきです。
特に本番環境では、次のルールを明文化してください。
| 操作 | 推奨方針 |
|---|---|
| インシデント要約 | AI出力を初動メモとして使い、人間が確認する |
| 条件付きアクセス変更 | 提案は参考にし、変更は承認フローを通す |
| DLP・IRM関連判断 | 機密度に応じてコンプライアンス担当者が確認する |
| エンドポイント修復 | 自動化対象と手動確認対象を分ける |
| レポート作成 | 経営報告に使う前に根拠データを確認する |
今後の運用方針は「小さく始めて、標準化して、拡張する」
Microsoft Security Copilot / Microsoft 365 E5 のロードマップを踏まえると、今後の運用方針は次の3段階で考えるのが現実的です。
まずは既存E5投資の中で効果が出る業務に絞る
最初の対象は、既に Microsoft Defender、Entra、Intune、Purview を使っている業務が適しています。新しい業務プロセスを作るより、既存プロセスの中に Security Copilot を差し込むほうが早く効果を出せます。
例として、Defenderのアラート調査、Entraのアクセスレビュー、PurviewのDLPアラート、Intuneのデバイス状態確認などが候補です。
次に、ポリシーと監査を標準化する
利用が広がる前に、次の文書を整備します。
| 文書 | 内容 |
|---|---|
| 利用ガイドライン | 使ってよい業務、禁止する入力、確認すべき根拠 |
| ロール設計書 | Owner、Contributor、製品別管理者の割り当て |
| データ取り扱いルール | 機密情報、個人情報、顧客情報、調査データの扱い |
| 容量管理ルール | SCU使用量の監視、閾値、追加容量判断 |
| エージェント管理ルール | 有効化、変更、停止、レビューの手順 |
この段階を飛ばすと、Copilot の利用が広がった後に「誰がどのデータを見てよいのか」「どの回答を根拠に判断したのか」が追えなくなります。
最後に、エージェントとカスタムワークフローへ拡張する
標準機能で効果が見えたら、自社固有のワークフローに広げます。たとえば、インシデント対応手順書に沿った調査支援、週次リスクレポートの生成、特権IDレビューの補助、脆弱性対応の優先順位付けなどです。
ここで重要なのは、AIに業務を丸投げするのではなく、既存の標準手順をAIが実行・補助しやすい形に整えることです。手順が曖昧な業務ほど、AI導入後に判断がばらつきます。
Microsoft 365 E5 顧客が今すぐ確認すべきチェックリスト
Microsoft Security Copilot の自動プロビジョニングを前提に、Microsoft 365 E5 顧客は次の項目を確認してください。
| チェック項目 | 確認済み |
|---|---|
| Microsoft 365 管理センターで Security Copilot 関連通知を確認した | |
| E5ライセンス数から月次SCU枠の目安を把握した | |
| 既定の Security Copilot Capacity とワークスペースを確認した | |
| Owner settings でデータ保存場所、データ共有、プロンプト評価場所を確認した | |
| Microsoft 365 サービスデータアクセスをONにする範囲を決めた | |
| Security Copilot Owner / Contributor の割り当てを棚卸しした | |
| 最初のパイロット業務を1〜2個に絞った | |
| SCU使用量を月次で確認する担当者を決めた | |
| AI出力の利用ルールと人間の承認ポイントを決めた | |
| エージェント展開の承認フローを決めた |
このチェックリストを満たしていない状態で利用範囲を広げると、コスト管理、データ管理、権限管理のいずれかでつまずきやすくなります。
まとめ：Security Copilot は「導入するか」ではなく「どう統制して活用するか」の段階へ
2026年4月20日更新の自動プロビジョニング文書は、Microsoft Security Copilot / Microsoft 365 E5 の方向性を読み解くうえで重要です。Microsoft 365 E5 顧客にとって、Security Copilot は個別に試すAIではなく、Defender、Entra、Intune、Purview などの運用に組み込まれる前提の機能になりつつあります。
今後の判断軸は明確です。
| 判断軸 | 取るべき行動 |
|---|---|
| 利用開始 | 自動プロビジョニングと通知を前提に、事前に設定・ロールを確認する |
| コスト | E5包含SCUを月次容量として管理し、超過や既存容量を整理する |
| データ | 保存場所、処理場所、Microsoft 365データアクセス、共有設定を確認する |
| 業務 | フィッシング、インシデント要約、ID管理、DLPなど効果が測れる領域から始める |
| 統制 | Owner、Contributor、エージェント、監査、承認フローを標準化する |
次にやるべきことは、Security Copilot の機能一覧を眺めることではありません。自社テナントで「誰が、どの業務で、どのデータに基づき、どの判断までAIに任せるのか」を決めることです。その設計ができていれば、Microsoft 365 E5 に含まれる Security Copilot は、単なる新機能ではなく、セキュリティ運用を再設計する実用的な基盤になります。
コメント