Microsoft 365 E5 を利用している組織では、Microsoft Security Copilot を「別途契約してから導入するもの」とだけ考えていると、ロールアウト計画や予算見積もりがずれる可能性があります。2026年4月20日更新の Microsoft Learn では、Microsoft 365 E5 に含まれる Security Copilot が対象テナントで自動プロビジョニングされる仕組みが説明されています。つまり、管理者が Azure 側で手動セットアップする前に、既定の容量・ワークスペース・一部設定・ロール割り当てが用意される前提で、準備を進める必要があります。(Microsoft Learn)
結論から言うと、Microsoft 365 admins、security platform owners、licensing decision-makers が今すぐ確認すべきことは、「使えるかどうか」ではなく「いつ有効化され、誰が使え、どのデータにアクセスでき、含まれる SCU でどこまで運用できるか」です。Security Copilot / Microsoft 365 E5 のバンドルと自動オンボーディングは、導入判断を後ろ倒しにする理由を減らす一方で、権限管理・データガバナンス・利用量監視の準備を前倒しにします。
Microsoft Security Copilot / Microsoft 365 E5 の何が変わったのか
Microsoft は、Microsoft 365 E5 顧客向けに Security Copilot を利用しやすくする方針を示しており、対象テナントでは Security Copilot が自動的にプロビジョニングされます。Microsoft の説明では、対象の Microsoft 365 E5 顧客は Security Copilot をサブスクリプションの一部として自動的に受け取り、Azure のセットアップや手動の容量プロビジョニングは不要とされています。(Microsoft Learn)
この変更の重要点は、単に「Security Copilot が E5 に含まれる」というライセンス面だけではありません。運用面では、次のような前提が変わります。
| 観点 | 従来の考え方 | E5 含有・自動プロビジョニング後に見直すべき考え方 |
|---|---|---|
| 導入計画 | 契約・容量作成・初期設定を個別プロジェクト化する | 有効化通知を起点に、設定確認と利用統制を先に整える |
| 予算 | Security Copilot の容量を別途見積もる | 含まれる SCU を基準に、超過・追加容量・関連コストを見積もる |
| 権限管理 | 利用開始前にロールを設計する | 自動付与される Owner / Contributor 相当のアクセスを確認する |
| データ管理 | 利用開始時にデータ連携を検討する | 既定で Microsoft 365 サービスデータへのアクセスが有効な点を確認する |
| 利用定着 | PoC 後に本番展開する | Defender、Purview、Entra、Intune など日常業務内で使われる前提で教育する |
特に注意したいのは、「自動プロビジョニングされる」ことと「組織として準備ができている」ことは別物だという点です。環境が有効化されても、権限設計、データ取り扱い方針、利用ガイド、監査観点が未整備だと、現場利用が進まないか、逆に統制のないまま広がるリスクがあります。
自動プロビジョニングで作成・設定されるもの
Microsoft Learn の 2026年4月20日更新ページでは、Microsoft 365 E5 に含まれる Security Copilot の自動プロビジョニングで、既定の Security Copilot 仮想容量、既定ワークスペース、ワークスペース設定、追加設定、既定ロール割り当てが行われると説明されています。(Microsoft Learn)
主に確認すべき項目は次のとおりです。
| 項目 | 自動設定される内容 | 管理者が確認すべきポイント |
|---|---|---|
| 既定容量 | Default Security Copilot Capacity が作成される | 課金対象の追加容量と混同しない |
| 既定ワークスペース | Security Copilot の既定ワークスペースが作成される | データ保存場所、共有設定、ロールを確認する |
| データ保存場所 | Microsoft Entra geography などを基に事前選択される | データ所在地要件、ADR、Go Local などの社内要件と照合する |
| データ共有設定 | Microsoft による人手レビュー関連の共有設定は既定でオフ | セキュリティ・法務・プライバシー部門と方針を合わせる |
| Microsoft 365 データアクセス | Security Copilot から Microsoft 365 サービスデータにアクセスする設定は既定でオン | Purview などのデータ参照を許可する範囲を確認する |
| 既定ロール | 一部の管理ロールが Security Copilot の Owner / Contributor アクセスを継承 | Global Administrator、Security Administrator などの実利用者を棚卸しする |
この中で、導入初期に最も見落とされやすいのはロール割り当てです。Microsoft Learn では、Global Administrator、Security Administrator、Conditional Access Administrator、Intune Administrator、Purview 関連ロールなどが Security Copilot owner access を継承する対象として示されています。また、Microsoft Defender や Purview の一部ロールは contributor access を継承します。(Microsoft Learn)
そのため、ライセンス担当だけでなく、Entra ID、Defender、Purview、Intune の各管理者が横断的に確認する必要があります。
E5 権利で含まれる SCU は「無料だから無制限」ではない
Microsoft 365 E5 に Security Copilot が含まれると聞くと、「追加コストなしで自由に使える」と受け取られがちです。しかし実務上は、Security Compute Unit、つまり SCU の消費設計が重要です。
Microsoft の説明では、Microsoft 365 E5 顧客には、1,000 paid user license ごとに毎月 400 SCU が付与され、上限は毎月 10,000 SCU です。1,000 ライセンス未満の顧客にもライセンス数に応じて比例配分され、例として 400 ライセンスでは 160 SCU/月、4,000 ライセンスでは 1,600 SCU/月が示されています。(Microsoft Learn)
| Microsoft 365 E5 ライセンス数 | 含まれる SCU の考え方 | 例 |
|---|---|---|
| 400 | 1,000 ライセンス未満でも比例配分 | 160 SCU/月 |
| 1,000 | 400 SCU/月 | 400 SCU/月 |
| 4,000 | 400 SCU × 4 | 1,600 SCU/月 |
| 25,000 以上 | 上限に到達する可能性 | 最大 10,000 SCU/月 |
含まれる SCU は、テナント全体で共有される月次バケットとして扱われ、未使用分は翌月へ繰り越されません。Default Security Copilot Capacity は自動作成され、テナント全体の Security Copilot compute を表しますが、変更できず、時間課金されるものではないと説明されています。(Microsoft Learn)
ここでの予算上のポイントは、E5 含有分を「ゼロコスト」ではなく「上限付きの標準容量」として扱うことです。日常的な調査、アラート要約、プロンプトブック、エージェント利用が増えると、含まれる SCU の消費ペースが想定より早くなる可能性があります。
ロールアウト計画で変えるべきこと
Security Copilot / Microsoft 365 E5 の自動オンボーディングにより、ロールアウト計画は「導入可否の検討」から「有効化前後の統制設計」へ重心が移ります。
30日前通知をプロジェクト開始日として扱う
Microsoft 365 E5 への Security Copilot 含有は段階的に展開され、顧客は有効化前に 30 日前通知を受け取ると説明されています。通知は Microsoft 365 admin center や各製品内バナーなどで確認でき、Global Administrator、Message Center Reader、Security Admin、Purview Compliance Admin、Intune Admin などが関連通知を受け取る対象として示されています。(Microsoft Learn)
この 30 日間を、単なる告知期間として扱うのは危険です。実務では、次の作業をこの期間に完了させるべきです。
| タイミング | 実施すべき作業 | 担当の例 |
|---|---|---|
| 通知受領直後 | 対象テナント、対象ライセンス数、想定 SCU を確認 | M365 管理者、ライセンス担当 |
| 1週目 | Owner / Contributor になり得るロールを棚卸し | Entra 管理者、セキュリティ管理者 |
| 2週目 | データ保存場所、Microsoft 365 データアクセス、共有設定を確認 | セキュリティ、法務、プライバシー |
| 3週目 | 利用対象ユースケースを決め、利用ルールを作成 | SOC、IT 運用、コンプライアンス |
| 4週目 | 利用者向けガイド、問い合わせ窓口、監視方法を準備 | 情シス、教育担当、運用責任者 |
特に大規模テナントでは、管理ロールが長年の運用で肥大化していることがあります。Security Copilot の有効化をきっかけに、Global Administrator や Security Administrator を常時付与しているアカウントを見直すと、セキュリティ統制の改善にもつながります。
先にユースケースを絞る
Security Copilot は便利な機能ですが、最初から全チームに広げると、利用量・期待値・問い合わせが一気に増えます。初期展開では、業務価値が分かりやすく、効果測定しやすいユースケースから始めるのが現実的です。
たとえば、次のような順序が扱いやすいでしょう。
| 優先度 | ユースケース | 向いているチーム | 判断基準 |
|---|---|---|---|
| 高 | Defender のインシデント要約、アラート調査支援 | SOC、セキュリティ運用 | 対応時間の短縮を測りやすい |
| 高 | Purview のデータセキュリティ調査支援 | コンプライアンス、データ保護 | 機密情報や DLP 対応と結びつく |
| 中 | Entra のアクセスリスク確認、条件付きアクセス検討 | ID 管理、ゼロトラスト担当 | 権限とポリシーの理解が必要 |
| 中 | Intune の端末管理・変更影響確認 | IT 運用、エンドポイント管理 | 運用手順との整合が重要 |
| 低〜中 | カスタムエージェントや API 活用 | プラットフォームチーム | ガバナンス設計後に進める |
Microsoft Learn でも、Security Copilot は Defender、Entra、Intune、Purview、スタンドアロンポータルなどで利用できることが示されています。(Microsoft Learn) ただし、Microsoft Security Copilot agents が自動的に有効化されるわけではなく、関連するスタンドアロンまたは組み込みエクスペリエンスで組織がエージェントを設定・展開する必要があります。(Microsoft Learn)
つまり、Security Copilot の基盤は自動で用意されても、業務に組み込む設計は自動化されないということです。
予算前提で見落としやすい3つの論点
含まれる SCU と既存のプロビジョニング容量を分けて考える
既に Security Copilot を利用している企業では、既存のプロビジョニング容量をどう扱うかが論点になります。Microsoft Learn では、既存顧客に対して、Microsoft 365 E5 による含有対象になったからといって、以前にプロビジョニングした Security Copilot capacity を削除しないことが推奨されています。継続利用を確保するためです。(Microsoft Learn)
実務では、次のように整理すると判断しやすくなります。
| 状況 | 予算・運用上の考え方 |
|---|---|
| E5 のみでこれから利用開始 | 含まれる SCU を基準に初期ユースケースを設計する |
| 既に Security Copilot を契約済み | 既存容量と E5 含有容量の関係を確認し、すぐ削除しない |
| SOC などで高頻度利用がある | 含有 SCU だけで足りるか、利用ダッシュボードで確認する |
| 月末に利用集中がある | 月次リセット・繰り越しなしを前提に運用ルールを作る |
「E5 に含まれるから予算不要」とまとめてしまうと、追加容量、関連サービス、運用教育、監査対応の費用を見落とします。特に Microsoft Sentinel、Azure Logic Apps、パートナー製エージェントなどを絡める場合、一部の機能や外部要件は Microsoft 365 E5 含有の範囲外になる可能性があります。Microsoft Learn でも、Sentinel data lake の compute / storage、Azure Logic Apps の使用料、パートナーライセンスなどは別途費用の例として挙げられています。(Microsoft Learn)
UI 上のコスト表示をそのまま請求額と見なさない
Default Security Copilot Capacity では、UI に表示されるコスト値が情報表示にすぎず、課金を示すものではないと説明されています。(Microsoft Learn)
これは管理者にとって重要です。経理や調達部門が画面上の金額表示だけを見て「追加請求が発生している」と誤解する可能性があります。ライセンス説明資料には、次のような注記を入れておくと混乱を避けられます。
Microsoft 365 E5 に含まれる Default Security Copilot Capacity は、月次の含有 SCU バケットとして扱われます。画面上の参考コスト表示は請求額を直接示すものではありません。追加容量や対象外サービスを利用する場合は、別途確認が必要です。
超過時の運用ルールを先に決める
含まれる SCU を使い切った場合、Security Copilot のリクエストが停止する可能性があります。Microsoft Learn では、inclusion capacity が exhausted になると、overage capacity が構成されていない限り Security Copilot requests stop と説明されています。(Microsoft Learn)
そのため、導入前に次のどちらの方針にするか決めておく必要があります。
| 方針 | 向いている組織 | 注意点 |
|---|---|---|
| 含有 SCU 内で運用する | 初期導入、予算統制を優先する組織 | 月末や重大インシデント時に利用制限が起きる可能性 |
| 超過・追加容量を検討する | SOC 利用が多い組織、24/7 運用の組織 | 予算上限、承認フロー、監視体制が必要 |
最初から無制限に広げるより、初期 1〜2 か月は利用状況を見て、どのチーム・どのプラグイン・どのエージェントが SCU を消費しているかを確認するのが現実的です。
Readiness work：有効化前に必ず確認したいチェックリスト
Security Copilot / Microsoft 365 E5 の自動プロビジョニングで最も重要なのは、利用開始前の readiness work です。特に、管理者・セキュリティ責任者・ライセンス担当の間で、次のチェックリストを共有しておくと実装が進めやすくなります。
テナントとライセンスの確認
まず、対象テナントが Microsoft 365 E5 の Security Copilot inclusion 対象かを確認します。Microsoft 365 admin center のメッセージセンター、Defender、Purview、Entra、Intune、Security Copilot ポータル内のバナーなどが確認ポイントです。(Microsoft Learn)
確認項目は次のとおりです。
| 確認項目 | 見るべきポイント |
|---|---|
| Microsoft 365 E5 の有償ライセンス数 | 含まれる SCU の概算に使う |
| 対象テナント | マルチテナント企業では有効化時期が異なる可能性 |
| 通知の受信者 | Global Admin だけでなく Message Center Reader も確認 |
| 既存 Security Copilot 契約 | 既存容量を削除しない前提で整理 |
| Sentinel や Logic Apps の利用有無 | E5 含有外のコストがないか確認 |
権限とロールの確認
Security Copilot はセキュリティ・ID・コンプライアンス領域の情報を扱うため、誰が Owner / Contributor として使えるかを明確にする必要があります。
最低限、次のロールは棚卸ししましょう。
- Global Administrator
- Security Administrator
- Conditional Access Administrator
- Intune Administrator
- Microsoft Entra Compliance Administrator
- Purview Compliance Admin
- Purview Organization Management
- Purview Data Governance Administrator
- Microsoft Defender XDR のカスタムロール
- Microsoft Purview 関連ロール
チェック時のポイントは、単にロール名を見るのではなく、実際にそのロールを持っているユーザー、グループ、サービスアカウントを確認することです。退職者アカウント、共有管理者アカウント、長期間使われていない管理者アカウントが残っている場合、Security Copilot の利用開始前に整理すべきです。
データ所在地・データアクセスの確認
自動プロビジョニングでは、既定ワークスペースの Customer Data storage location が事前選択されます。Microsoft Learn では、通常は Microsoft Entra geography が使われ、Microsoft 365 geo override がある場合は Security Copilot がサポートする geo にマッピングされると説明されています。(Microsoft Learn)
また、プロンプト評価場所については、Customer Data storage location が EU の場合は EU で処理され、それ以外の場合は地域性や GPU 可用性に応じて US、UK、EU、ANZ などで処理されると説明されています。(Microsoft Learn)
データ管理の観点では、次の確認が必要です。
| 項目 | 確認すべき内容 |
|---|---|
| Customer Data storage location | 自社のデータ所在地要件に合うか |
| Prompt evaluation location | プロンプト処理場所を説明できるか |
| Microsoft 365 service data access | 既定オンのままでよいか |
| Customer Data sharing preferences | 既定オフを維持するか、変更するか |
| 社内利用ポリシー | 機密情報、個人情報、顧客情報の入力ルールを明文化する |
ここで大切なのは、「Microsoft の既定設定が安全かどうか」を抽象的に議論することではありません。自社の規程、契約、監査要件に照らして、既定値をそのまま使う理由または変更する理由を記録しておくことです。
利用開始後は使用量ダッシュボードを運用に組み込む
Security Copilot の利用状況は、Security Copilot の usage monitoring dashboard で確認できます。Microsoft Learn では、ダッシュボードで SCU 使用量、利用されたプラグイン、セッションの開始者などを確認でき、最大 90 日分のデータを含むと説明されています。(Microsoft Learn)
利用開始後は、次の観点で定期レビューすると、SCU の使い過ぎや利用の偏りを早期に把握できます。
| レビュー観点 | 見るべき指標 | 取るべきアクション |
|---|---|---|
| 利用者 | Initiated by | 想定外の管理者・チームが使っていないか確認 |
| 利用形態 | Prompt / Promptbook / Agent | 自動実行が増えすぎていないか確認 |
| 製品領域 | Copilot experience / Plugin used | Defender、Purview、Entra、Intune のどこで消費が多いか把握 |
| 消費量 | Units used | 月次 SCU の消費ペースを予測 |
| 自動処理 | Manual Action / Automated Action | 自動エージェントやワークフローの制御を検討 |
特に、Automated Action が増えると、ユーザーが明示的にプロンプトを入力していなくても SCU が消費される可能性があります。エージェントや自動処理を導入する際は、「便利だから有効化する」ではなく、「どの業務をどの頻度で自動化し、どの程度の消費を許容するか」を決めてから展開するべきです。
失敗しやすいポイント
Security Copilot / Microsoft 365 E5 の自動オンボーディングで起きやすい失敗は、技術的な設定ミスよりも、部門間の認識違いです。
| 失敗パターン | 起きる理由 | 回避策 |
|---|---|---|
| 「E5 なので完全無料」と説明してしまう | 含有 SCU と追加コストの区別が曖昧 | 含有範囲、対象外機能、追加容量を資料化する |
| 管理者ロールを見直さない | 自動付与されるアクセスを軽視する | Owner / Contributor 相当の権限を棚卸しする |
| 現場に周知せず有効化される | 自動プロビジョニングを導入完了と誤解する | 30日前通知を起点に利用ルールを配布する |
| データ設定を既定値のまま放置する | データ所在地や M365 データアクセスを確認しない | Owner settings を必ずレビューする |
| SCU を監視しない | 初期は利用量が少ないと考える | 週次で usage monitoring dashboard を確認する |
| エージェントを無計画に展開する | 自動化による消費・影響を見積もらない | 小さなユースケースから段階展開する |
独自の観点として、Security Copilot の導入は「AI ツール導入」ではなく、セキュリティ運用の権限モデル変更として扱うべきです。なぜなら、Copilot は単に文章を生成するのではなく、Defender、Purview、Entra、Intune などの既存データと権限の上で動くからです。権限が広すぎれば回答に触れられる情報も広がり、データ連携を止めれば有用性も下がります。このバランスを事前に設計することが、導入成功の分かれ目です。
管理者・セキュリティ責任者・ライセンス担当が次にやるべきこと
Microsoft Security Copilot / Microsoft 365 E5 の最新動向を踏まえると、今後の導入準備は次の順番で進めるのが実務的です。
まず、Microsoft 365 admin center のメッセージセンターと各製品ポータルで、Security Copilot inclusion の通知やバナーを確認します。次に、E5 ライセンス数から含まれる SCU の概算を出し、想定ユースケースに対して十分かを仮説立てします。そのうえで、Owner / Contributor になり得る管理ロールを棚卸しし、Security Copilot の Owner settings でデータ保存場所、データ共有、Microsoft 365 サービスデータアクセスを確認します。
初期展開では、SOC のインシデント要約、Purview のデータセキュリティ調査、Entra のアクセスリスク確認など、効果を測りやすいユースケースに絞るのがおすすめです。利用開始後は usage monitoring dashboard を週次で確認し、SCU 消費、利用者、プラグイン、手動・自動実行の傾向を見ながら展開範囲を広げます。
Microsoft 365 E5 に Security Copilot が含まれ、自動プロビジョニングされる流れは、導入のハードルを下げます。しかし同時に、管理者が準備を先送りできる余地も小さくなります。今やるべきことは、ライセンスの有無を確認するだけではありません。有効化された瞬間に、安全かつ説明可能な形で使い始められる状態を作ることです。
コメント