Microsoft Security Copilot / Microsoft 365 E5のrolloutで現場が最初に押さえるべき点は、「Security Copilotを個別に構築するプロジェクト」から「Microsoft 365 E5の中で使える前提の業務ワークフロー設計」へ変わることです。2026年4月20日に更新されたMicrosoft Learnでは、対象テナントでSecurity CopilotがMicrosoft 365 E5ライセンスに含まれる場合、Microsoftが既定の仮想容量とワークスペースを自動作成し、Defender、Purview、Entra、Intune、Security Copilotポータルなどの業務導線から利用を始められると説明されています。(Microsoft Learn)
つまり、管理者やソリューションオーナーが考えるべきことは「有効化するかどうか」だけではありません。誰が使うのか、どのデータにアクセスさせるのか、SCUをどの業務に優先配分するのか、既存のSOC・ID管理・データ保護・端末管理の手順をどう変えるのかまで決める必要があります。
Microsoft Security Copilot / Microsoft 365 E5の最新動向
Microsoftは、Microsoft 365 E5顧客向けにSecurity Copilotの利用範囲を広げる方針を示しており、既存のMicrosoft 365 E5顧客に対して段階的なrolloutを進めています。Microsoft Learnでは、2025年11月18日から既存のSecurity Copilot利用顧客かつMicrosoft 365 E5顧客向けに展開が始まり、対象顧客には有効化前に30日前通知が届くとされています。(Microsoft Learn)
今回のポイントは、単に「AI機能が増える」という話ではありません。Microsoft 365 E5のセキュリティ運用にSecurity Copilotが組み込まれることで、現場の作業は次のように変わります。
| これまでの作業 | rollout後に変わるポイント |
|---|---|
| 管理者がAzureやSecurity Copilot側で容量や初期設定を個別に準備する | 対象テナントでは既定のSecurity Copilot容量とワークスペースが自動作成される |
| Defender、Purview、Entra、Intuneを個別に見ながら状況を整理する | 各製品の文脈でCopilotに調査、要約、次の対応案の整理を依頼しやすくなる |
| SOC、ID管理、コンプライアンス、端末管理で対応手順が分断される | 共通のCopilot体験を軸に、調査メモ、判断理由、対応履歴をそろえやすくなる |
| AI活用が一部の検証チームに閉じる | Power users、admins、solution ownersが実業務の中で使う前提になる |
特に重要なのは、Security Copilotが「セキュリティ担当者だけの専用ツール」ではなく、Microsoft 365 E5を運用する複数チームの共通レイヤーになりつつある点です。SOC、ID管理、情報保護、エンドポイント管理のどこか一つだけで導入を考えると、効果が限定されます。
自動プロビジョニングで何が準備されるのか
Microsoft Learnの2026年4月20日更新では、Security Copilotの自動プロビジョニング時に、既定のSecurity Copilot仮想容量、既定ワークスペース、データ保存場所、データ共有設定、プロンプト評価場所、Microsoft 365サービスデータへのアクセス設定、既定ロールが設定されると説明されています。(Microsoft Learn)
現場目線では、これを「初期設定が省ける」とだけ捉えると危険です。自動で使える状態になるからこそ、管理者は有効化後すぐに次の確認を行うべきです。
| 確認項目 | 見るべき理由 | 実務上の判断基準 |
|---|---|---|
| Owner settings | データ、容量、ファイルアップロードなどの管理設定に関わる | セキュリティ管理者だけでなく、コンプライアンス責任者もレビューする |
| 既定ロール | 誰がOwnerまたはContributorとして扱われるかに影響する | Global Administratorに依存せず、最小権限で運用できる体制にする |
| Microsoft 365サービスデータへのアクセス | PurviewなどのデータをCopilotが参照できるかに関わる | 使う業務シナリオとデータガバナンス方針を照合する |
| データ保存場所とプロンプト評価場所 | リージョン、データ所在地、社内規程に関わる | グローバル企業では法務・DPO・地域ITと確認する |
| Usage monitoring | SCU消費の把握に関わる | 最初の1〜2か月は週次で確認し、利用部門別に傾向を見る |
Microsoft Learnでは、Microsoft 365 E5顧客向けの既定設定として、Customer Data sharing preferencesは既定でオフ、Microsoft 365サービスデータへのアクセスは既定でオンと説明されています。(Microsoft Learn)
このため、管理者が最初にやるべきことは、Copilotを止めることではなく「どの業務で、どの権限を持つ人に、どの範囲のデータを使わせるか」を明文化することです。
容量管理は「導入時の見積もり」から「利用状況の継続管理」へ変わる
Microsoft 365 E5向けのSecurity Copilotでは、Security Compute Units、つまりSCUの扱いも現場運用に影響します。Microsoft Learnでは、Microsoft 365 E5顧客には1,000有料ユーザーライセンスあたり月400 SCU、最大月10,000 SCUが追加費用なしで含まれると説明されています。(Microsoft Learn)
この仕組みは、従来の「時間単位で容量を確保する」発想とは異なります。Microsoft 365 E5のinclusion capacityはテナント全体で共有され、月次で更新され、未使用分は翌月に繰り越されません。既定のSecurity Copilot Capacityは自動作成され、テナント全体のSecurity Copilotコンピュートとして共有される仕組みです。(Microsoft Learn)
実務では、次のような運用ルールを作ると失敗しにくくなります。
| 利用フェーズ | 重点管理ポイント | 具体的な運用例 |
|---|---|---|
| rollout直後 | 誰がどの機能を試しているか | SOC、Intune、Purviewなど部門別に試行シナリオを限定する |
| 定着期 | SCUを消費している業務 | Usage monitoringでユーザー、プラグイン、体験別に確認する |
| 拡大期 | 自動実行やagent利用の増加 | 自動化前に想定消費量と業務効果をレビューする |
| 月末前 | SCU残量と業務優先度 | インシデント対応など重要業務を優先し、検証用途を抑制する |
Security Copilotのusage monitoring dashboardでは、SCUの使用量、利用されたプラグイン、セッションの開始者、手動実行か自動実行かなどを確認でき、データのエクスポートも可能です。(Microsoft Learn)
Power usersに自由に使わせるだけでは、便利な質問や検証でSCUが消費され、本当に必要なインシデント対応時に利用しづらくなる恐れがあります。rollout後は、単なるライセンス管理ではなく、AI利用の優先順位管理が必要です。
利用シナリオ：SOCのフィッシング調査を短縮する
最も分かりやすい活用先は、SOCやセキュリティ運用チームの一次調査です。MicrosoftはSecurity Copilotの利用例として、SOCチームがフィッシングのトリアージやインシデント対応で、アラート分類、脅威の要約、修復ガイダンスに活用できると説明しています。(Microsoft Learn)
従来のフィッシング調査では、担当者がメールヘッダー、URL、添付ファイル、送信元、影響ユーザー、Defenderのアラートを個別に確認し、チケットに状況をまとめる必要がありました。Security Copilotを組み込むと、次の流れに変えられます。
| 手順 | 従来 | Security Copilot活用後 |
|---|---|---|
| 初期確認 | 複数画面を開いて手作業で情報収集 | Defenderなどの文脈から要約を生成 |
| 影響範囲確認 | 受信者、クリック有無、類似メールを個別検索 | 影響範囲の整理をCopilotに依頼 |
| 判断 | 担当者の経験に依存 | 判断材料、根拠、追加確認点を文章化 |
| 引き継ぎ | チケットの記述品質が人によりばらつく | 一定のフォーマットで調査メモを作成 |
| 再発防止 | 後回しになりやすい | 条件付きアクセス、メール対策、教育観点を整理しやすい |
ここで重要なのは、Copilotに「これは安全か危険か」と丸投げしないことです。現場で使いやすいプロンプトは、判断を依頼する前に、出力形式を指定します。
使いやすいプロンプト例
このフィッシング疑いのアラートについて、影響ユーザー、クリック有無、関連する類似メール、推奨される封じ込め手順、追加確認が必要な点を、SOCチケットに貼り付けられる形式で整理してください。判断根拠が不足している場合は、不足しているログや確認項目も列挙してください。
このように依頼すると、Copilotの出力をそのまま対応記録に近い形で使えます。ポイントは「結論」「根拠」「次のアクション」「不明点」を必ず分けることです。
利用シナリオ：Entraの条件付きアクセス見直しを現実的に進める
Microsoft 365 E5環境では、ID管理チームや管理者がMicrosoft Entraの条件付きアクセス、アクセスレビュー、リスクユーザー対応を担当するケースが多くあります。Microsoftは、Security Copilotのユースケースとして、IDチームが条件付きアクセスの最適化やアクセスレビューの自動化に活用できると説明しています。(Microsoft Learn)
条件付きアクセスの見直しでありがちな失敗は、「強くすれば安全」と考えて業務影響を見落とすことです。特にグローバル企業では、国、拠点、デバイス状態、レガシーアプリ、緊急用アカウントなどの条件が複雑になります。
Security Copilotを使う場合は、次のようなワークフローにすると実務に落とし込みやすくなります。
| フェーズ | Copilotに任せやすい作業 | 人が判断すべき作業 |
|---|---|---|
| 現状把握 | ポリシー一覧、対象ユーザー、例外条件の整理 | 例外が妥当か、業務上必要かの判断 |
| リスク確認 | サインインリスク、失敗傾向、影響範囲の要約 | 実際にブロックしてよい業務の判断 |
| 変更案作成 | 条件、対象、除外、段階適用案の整理 | 本番適用の承認、ロールバック方針 |
| 展開後確認 | 変更前後のサインイン傾向の比較 | 問い合わせ増加や業務影響の評価 |
Power usersやadminsにとっての価値は、設定そのものをAIに任せることではありません。複雑なポリシーを読み解き、「何が変わると誰に影響するか」を短時間で把握できる点にあります。
使いやすいプロンプト例
現在の条件付きアクセス設定を、管理者向けに要約してください。対象ユーザー、対象アプリ、除外条件、MFA要求、ブロック条件、業務影響が大きそうな箇所を表で整理し、変更前に確認すべきリスクを挙げてください。
この依頼なら、設定変更前のレビュー資料として使いやすくなります。変更作業そのものより、レビュー、説明、承認の時間を短縮できるのが現実的な効果です。
利用シナリオ：PurviewのDLPアラートを「読む」から「対応方針を決める」へ
情報保護やコンプライアンス担当者にとって、Microsoft PurviewのDLP、Insider Risk Management、Communication Complianceなどのアラートは、内容確認に時間がかかる領域です。Microsoft Learnでは、Security CopilotがMicrosoft Purviewで処理されたMicrosoft 365サービスデータにアクセスできる設定があり、DLPアラート、ラベル付け活動、eDiscoveryレビューセット、Insider Risk Managementアラートなどが対象例として示されています。(Microsoft Learn)
この領域でのワークフロー変化は、単なる要約ではありません。重要なのは、アラートの優先順位付けです。
| よくある課題 | Security Copilot活用の方向性 |
|---|---|
| DLPアラートが多く、どれから見るべきか分からない | 機密度、外部共有、ユーザー行動、過去傾向で優先度を整理する |
| アラート内容が専門的で、関係部門に説明しにくい | 法務、IT、現場部門向けに説明文を分けて作成する |
| 誤検知か本当に危険かの判断が属人化する | 判断材料と不足情報を明示し、レビュー観点を標準化する |
| 対応履歴がチケットに残りにくい | 初期判断、追加確認、対応方針をテンプレート化する |
使いやすいプロンプト例
このDLPアラートについて、検出されたデータの種類、共有先、ユーザーの操作、過去の類似傾向、誤検知の可能性、緊急度を整理してください。コンプライアンス担当者が一次判断できるように、確認すべき追加情報も含めてください。
ただし、Purview領域ではデータガバナンスへの配慮が欠かせません。Microsoft 365サービスデータへのアクセス設定は既定でオンですが、無条件に広く使わせるのではなく、対象ロール、利用目的、監査ログの確認方法を先に決めるべきです。(Microsoft Learn)
利用シナリオ：Intuneの端末管理で変更影響を見える化する
エンドポイント管理では、Microsoft Intuneのポリシー変更、デバイス準拠状況、脆弱性対応、アプリ配布などが日常業務です。Microsoftは、IT管理者がSecurity Copilotを使って、脆弱性修復や生産性に影響する変更の事前評価に役立てられると説明しています。(Microsoft Learn)
Intune運用でよく起きる問題は、セキュリティ強化の変更がユーザー体験に影響することです。たとえば、デバイス準拠ポリシーを厳しくすると、リモートワーカーや海外拠点のユーザーが突然アクセスできなくなる可能性があります。
Security Copilotを活用するなら、変更前レビューを標準化すると効果が出やすくなります。
| 変更対象 | Copilotに確認させたい観点 |
|---|---|
| 準拠ポリシー | 非準拠になりそうなデバイス群、影響ユーザー、例外対象 |
| アプリ保護ポリシー | 業務アプリへの影響、既存ポリシーとの競合 |
| デバイス構成プロファイル | 対象グループ、除外、既存設定との差分 |
| 脆弱性対応 | 優先度、対象端末、適用順序、業務停止リスク |
使いやすいプロンプト例
このIntuneポリシー変更について、影響を受けるユーザーとデバイス、既存ポリシーとの競合可能性、リモートワーカーへの影響、ロールバック時に確認すべき項目を整理してください。変更承認会議で説明できる形式にしてください。
これにより、Intune管理者の作業は「設定を作る」から「影響を説明し、承認を得る」方向へ移ります。特に大規模テナントでは、変更管理の品質向上が大きな価値になります。
agentは自動で有効になるわけではない
Security Copilotのrolloutで誤解しやすいのが、agentの扱いです。Microsoft Learnでは、Security Copilot agentsは顧客組織側で関連するスタンドアロンまたは埋め込み体験に設定・展開する必要があり、自動で有効化されるわけではないと説明されています。(Microsoft Learn)
また、Microsoft製agentを使う場合でも、Security CopilotのAgents画面からagentを選び、identityや必要な入力パラメーターなどを設定する流れが示されています。partner-built agentでMicrosoft製品データにアクセスする場合は、Global Administratorによる承認が必要になるケースもあります。(Microsoft Learn)
現場では、次の順序で展開するのが安全です。
| ステップ | 実施内容 | 失敗しやすいポイント |
|---|---|---|
| 業務候補を選ぶ | フィッシング対応、DLPトリアージ、アクセスレビューなどを選定 | いきなり全部門に展開する |
| ownerを決める | agentの目的、権限、出力品質の責任者を置く | 管理者だけでなく業務責任者が不在 |
| identityを設計する | agent用IDや既存アカウントの扱いを決める | 高権限アカウントを安易に使う |
| テストする | 小さな対象範囲で出力、SCU消費、監査を確認 | 本番アラートにいきなり自動適用する |
| 運用化する | 手順書、停止条件、レビュー周期を決める | agentの出力を誰もレビューしない |
agentは「便利な自動化」ではなく、「権限を持って業務に関与する仕組み」です。導入時は、ワークフロー、責任者、停止条件をセットで設計してください。
adminsとsolution ownersがrollout直後にやるべきこと
rollout後に最も差が出るのは、初期の運用設計です。Security Copilotが使えるようになってから慌ててルールを作ると、利用部門ごとのばらつき、SCU消費の偏り、データアクセスに関する不安が起きやすくなります。
最初の1週間で確認すること
| 対象 | 実施内容 |
|---|---|
| Microsoft 365管理センター | 通知、対象テナント、有効化時期を確認 |
| Security Copilotポータル | 既定ワークスペースとDefault Security Copilot Capacityの有無を確認 |
| Owner settings | データ共有、Microsoft 365データアクセス、ファイルアップロード設定を確認 |
| ロール | Owner、Contributor相当のユーザーと管理者ロールを確認 |
| 利用候補部門 | SOC、ID管理、Purview、Intuneの代表者を決める |
最初の30日で決めること
| 決めること | 判断基準 |
|---|---|
| 優先ユースケース | アラート量が多い、判断が属人化している、説明資料作成に時間がかかる業務を優先 |
| 利用者範囲 | まずは管理者とPower usersに限定し、成果とリスクを見て広げる |
| プロンプト標準 | チケット貼り付け用、承認資料用、影響調査用などの形式を統一 |
| SCU監視周期 | rollout直後は週次、定着後は月次で確認 |
| 禁止事項 | 個人情報や機密データの扱い、未承認agent、出力の無レビュー利用を明確化 |
Microsoftは、管理者がOwner settingsを確認し、組織の希望する構成に合っているかを確認したうえで、ユーザーにSecurity Copilotの利用可否と組織ポリシー内での使い方を知らせることを推奨しています。(Microsoft Learn)
Power users向け：良いプロンプトは「作業の型」から作る
Power usersがSecurity Copilotを活用する場合、単発の質問よりも、繰り返し使う業務フォーマットを作るほうが効果的です。
たとえば、次のようなテンプレートを用意しておくと、出力品質が安定します。
インシデント初期調査用
対象インシデントについて、概要、検出理由、影響範囲、関連ユーザー、関連デバイス、推奨される封じ込め手順、追加確認項目を表で整理してください。確度が低い内容は「要確認」と明記してください。
管理者レビュー用
この設定変更について、変更内容、期待される効果、影響を受けるユーザー、リスク、ロールバック手順、承認前に確認すべき点を整理してください。
経営・非技術部門向け説明用
このセキュリティアラートを、専門用語を避けて説明してください。事業影響、現在の対応状況、追加判断が必要な事項を3段落でまとめてください。
ポイントは、「何を聞くか」より「何に使う出力か」を明確にすることです。Security Copilotの回答をそのまま業務成果物に近づけると、チケット作成、会議資料、承認依頼、引き継ぎの時間を削減できます。
注意点：AI導入より先に運用ルールを整える
Microsoft Security Copilot / Microsoft 365 E5のrolloutは、現場にとって大きなチャンスです。一方で、AIの利用範囲が広がるほど、管理の甘さも目立ちます。
特に注意すべき点は次の4つです。
| 注意点 | 実務上の対策 |
|---|---|
| 出力を過信する | 重要判断では必ずログ、アラート、設定値を確認する |
| 権限が広がりすぎる | Global Administratorに依存せず、最小権限のロール設計にする |
| SCUを無計画に消費する | 部門別・用途別に利用状況を確認し、優先業務を決める |
| agentを早く広げすぎる | 小規模検証、停止条件、責任者、監査方法を決めてから展開する |
Microsoftも、Global Administratorは高権限ロールであり、低い権限のロールを使うことが組織のセキュリティ向上に役立つと説明しています。(Microsoft Learn)
Microsoft Security Copilot / Microsoft 365 E5 rolloutで現場が取るべき次の行動
Microsoft Security Copilot / Microsoft 365 E5のrolloutは、「AIが追加された」というニュースではなく、セキュリティ運用の入口が変わる出来事です。対象テナントでは自動プロビジョニングにより利用開始のハードルが下がる一方、Owner settings、ロール、Microsoft 365データアクセス、SCU、agent展開を管理しなければ、現場の混乱につながります。
まずは、SOC、Entra、Purview、Intuneの中から、最も作業量が多く、判断が属人化している業務を1つ選びます。次に、その業務で使うプロンプト、出力形式、レビュー担当者、SCU監視方法を決めます。最後に、30日単位で利用状況と成果を見直し、対象業務を広げていくのが現実的です。
Security Copilotの価値は、単に回答を速く出すことではありません。調査、判断、説明、引き継ぎという現場ワークフローを標準化し、管理者とPower usersが同じ根拠で動けるようにすることです。
コメント