Microsoft Security Copilot の概要更新で押さえるべき結論は、製品名や基本機能そのものが突然別物になったというより、Microsoft がそれを「誰が」「どこで」「どう導入する製品として説明しているか」 が変わったことです。現行の overview では依然として「防御担当者向けの生成 AI セキュリティ ソリューション」という軸が見えますが、2026年4月前後の公式資料では、Security Copilot は Defender、Entra、Intune、Purview などに埋め込まれ、セキュリティと IT の日常運用を支えるエージェント型基盤 として前面に出ています。(Microsoft Learn)
つまり、エンタープライズ防御者が今見るべきなのは「何を質問できるか」だけではありません。自社が Microsoft 365 E5 同梱の対象か、どの管理画面で使うか、SCU を月次でどう見るか、どのエージェントを誰が有効化するかまで含めて判断する段階に入っています。ここを見落とすと、Security Copilot を単なる SOC 向け補助機能として過小評価しやすくなります。(Microsoft Learn)
Microsoft Security Copilot の位置付けはどう変わったか
4月時点の中核ドキュメントをまとめて読むと、今回の変化は次の4点に整理できます。(Microsoft Learn)
- 対象ユーザーが広がったこと。 FAQ では Security Copilot を「security and IT のための生成 AI アシスタント」と明示し、想定ユーザーとして SOC アナリスト、コンプライアンス担当、IT 管理者、データ セキュリティ管理者、ID 管理者、CISO などを挙げています。(Microsoft Learn)
- 使う場所が広がったこと。 standalone experience は残りつつ、実際の主戦場として Defender XDR、Entra、Intune、Purview、Sentinel などの embedded experience が強く打ち出されています。(Microsoft Learn)
- 活用単位が広がったこと。 以前の「プロンプトで質問して答えを得る」印象に加えて、Microsoft 製エージェント、パートナー製エージェント、カスタム エージェント、プラグイン、コネクタ、Promptbook まで含む運用前提が明確になっています。(Microsoft Learn)
- 導入モデルが広がったこと。 非 E5 テナントは引き続き SCU の手動プロビジョニングが必要ですが、Microsoft 365 E5 テナントでは included capacity と auto-provisioning を軸にした説明へ寄っています。(Microsoft Learn)
概要ページだけを見ると見誤る理由
ここで注意したいのは、現行の「What is Microsoft Security Copilot?」ページ自体の最終更新日は 2026年2月19日 で、説明の中心も「defenders の効率向上」「incident response、threat hunting、intelligence gathering、posture management」といった、比較的オーソドックスな表現だという点です。(Microsoft Learn)
一方、位置付けの変化がはっきり見えるのは、2026年4月9日更新の E5 inclusion / auto-provisioning、4月7日更新の onboarding、4月4日更新の capacity です。これらの文書では、Security Copilot が daily workflow に built-in されること、E5 テナントで自動プロビジョニングされること、tenant-wide の月次バケットとして扱うこと、エージェント活用を前提にすることが、まとめて示されています。要するに、今回の変化は単一の overview ページよりも、周辺の中核資料が同じ方向へそろったこと にあります。(Microsoft Learn)
エンタープライズ防御者にとっての実務的な変化
SOC だけの製品として見ると狭すぎる
役割別ユースケースでは、インシデント対応支援だけでなく、KQL やスクリプト作成、リスクや posture の把握、IT トラブルシュート、ポリシー管理、ライフサイクル ワークフロー、レポート作成まで対象に入っています。PoC を SOC 単独で回すと、Entra、Intune、Purview 側の価値を拾いきれず、導入効果を小さく見積もりやすい構図です。(Microsoft Learn)
入口は「新しい専用ポータル」より既存の管理画面
Security Copilot には standalone experience がありますが、現在の公式説明では embedded experience の存在感が大きく、Defender XDR、Entra、Intune、Purview、Sentinel などの画面内で使う形が強調されています。現場定着を狙うなら、「新しいツールを覚えてもらう」発想より、「今の管理画面のどの作業を短縮できるか」で導入設計した方が成功しやすいです。なお、standalone access 自体がなくなるわけではありません。変わったのは、standalone だけ が主役ではなくなったことです。(Microsoft Learn)
E5 同梱で「触り始めるまでの距離」が短くなった
Microsoft 365 E5 の対象テナントでは、現行資料上、Security Copilot は zero-click activation で自動プロビジョニングされ、既定の workspace と capacity が用意されます。Azure 側の準備や手動の SCU プロビジョニングなしで開始できるため、従来より「まず触ってみる」までのハードルが下がりました。特に、複数部門で小さく試す入口を作りやすくなったのは大きな違いです。(Microsoft Learn)
ただし「自動で全部使える」わけではない
E5 同梱になっても、エージェントは自動で有効化されません。 組織側で relevant experience にセットアップと展開が必要です。また、自動プロビジョニング時の既定値として、Microsoft 365 サービス データへのアクセスはオン、データ共有設定はオフ、特定ロールの owner/contributor 継承は有効になっています。展開前に、権限、データアクセス、説明責任の設計まで確認しておく必要があります。(Microsoft Learn)
既存製品を置き換える製品ではない
Security Copilot は、Defender や Entra、Intune、Purview そのものを置き換える製品ではありません。Microsoft の採用資料でも、既存のセキュリティ製品から信号を取り込み、自然言語での要約や判断支援を行い、日々のセキュリティと IT ワークフローを速くする位置付けが明確です。判断軸は「何を廃止できるか」より、「今ある運用のどこを短縮できるか」に置くべきです。(Microsoft Adoption)
導入判断で確認すべき5つのポイント
- 自社が E5 included か、非 E5 かを最初に切り分ける。 Microsoft の onboarding 文書は、顧客をこの2カテゴリに分けています。E5 なら自動プロビジョニング済みかを確認し、非 E5 なら manual onboarding と SCU 調達を前提に見積もる。この順番を逆にすると、初期工数と費用感を誤ります。(Microsoft Learn)
- 最初に使うコンソールを決める。 Defender XDR のアラート/インシデント対応なのか、Entra の ID 運用なのか、Intune の端末管理なのか、Purview のデータ保護なのか。最も件数が多く、反復性が高い画面から始めると、Security Copilot の価値が測りやすくなります。(Microsoft Learn)
- SCU を「時間単位」ではなく「月次バケット」で見る。 Security Compute Units は standalone、embedded experience、Microsoft 製/パートナー製エージェントなどで共通に消費されます。現行資料では、E5 included capacity は 1,000 有償ユーザー ライセンスごとに月 400 SCU、最大 10,000 SCU/月で、unused 分の繰り越しはありません。枯渇時は overage を設定していない限りリクエストが止まるため、PoC の段階から月次の消費を追うべきです。(Microsoft Learn)
- 自動プロビジョニングの既定値を必ず確認する。 データ共有設定はオフ、Microsoft 365 サービス データアクセスはオン、owner/contributor の一部ロールは自動付与されます。設定そのものは便利ですが、情報管理や権限設計に影響するため、owner settings の見直しを前提にした方が安全です。(Microsoft Learn)
- included の外に出る費用と作業を先に把握する。 E5 同梱で全コストが消えるわけではありません。現行資料では、Microsoft Sentinel の data lake compute/storage、Azure Logic Apps、パートナー製エージェントのライセンス、一部の前提製品などが included の外にあります。ここを見落とすと、「同梱のはずなのに追加確認が多い」と後で混乱しやすくなります。(Microsoft Learn)
失敗しやすいポイント
- E5 同梱なら、そのまま全機能が自然に回り始めると思い込むこと。 実際にはエージェントの展開は組織側の作業で、既定ロールやデータ設定の確認も必要です。(Microsoft Learn)
- included capacity が来たから既存の手動 Capacity を削除してしまうこと。 Microsoft は既存顧客に対し、以前にプロビジョニングした capacity を削除しないよう案内しています。(Microsoft Learn)
- Security Copilot を既存製品の置き換えと見なすこと。 実際の位置付けは、既存の Microsoft セキュリティ/IT 製品に埋め込まれた運用加速レイヤーです。(Microsoft Adoption)
- SCU を見ずに複数部門へ一気に広げること。 included capacity は tenant-wide に共有されるため、誰がどのワークフローで消費するかを見える化しないと、必要なタイミングで上限に当たりやすくなります。(Microsoft Learn)
まず取るべきアクション
- 自社テナントの立ち位置を確認する。 Microsoft 365 E5 の対象か、管理センター通知や製品内バナーが出ているか、Default Security Copilot Capacity が見えているかを確認します。非 E5 なら最初から manual onboarding 前提で進めます。(Microsoft Learn)
- 1チーム1ワークフローで始める。 いきなり全社展開せず、Defender のフィッシング トリアージ、Entra の Conditional Access やアクセス レビュー、Intune の端末トラブル対応、Purview のデータ保護アラート対応など、反復回数が多い業務を一つ選ぶと効果が見えやすくなります。実際、公式の “What’s new” や E5 inclusion 文書でも、こうした agentic な具体例が前面に出ています。(Microsoft Learn)
- owner settings と権限を点検する。 データ共有、Microsoft 365 データアクセス、ロール自動付与、workspace 設定を確認し、自社ポリシーに合わせて整えます。ここを後回しにすると、便利さより先に運用ルールの議論で止まりやすくなります。(Microsoft Learn)
- 1か月単位で SCU 使用量を見て、overage の要否を決める。 E5 included capacity は hourly 課金ではなく monthly bucket なので、従来の Azure 的な感覚とは違います。最初は対象業務を絞って観測し、実消費を見てから overage や追加設計を判断した方が安全です。(Microsoft Learn)
- 効果が出たらエージェント活用へ広げる。 単発のプロンプトで価値が見えたら、Microsoft 製エージェント、パートナー製エージェント、必要に応じてカスタム エージェントやプラグインへ進めると、Security Copilot を「質問ツール」で終わらせずに済みます。(Microsoft Learn)
今回の Microsoft Security Copilot の概要更新で本当に重要なのは、これを SOC 向けの単体支援ツール とだけ捉えると判断を誤ることです。今の Microsoft は、Security Copilot を Defender、Entra、Intune、Purview などに埋め込み、E5 同梱や自動プロビジョニングも含めて、セキュリティと IT の日常運用を支える基盤として説明しています。まずは自社のライセンス区分、使うコンソール、SCU、最初に有効化するエージェントの4点を確認し、PoC も SOC 単独ではなく複数チームで設計するのが現実的です。(Microsoft Learn)
コメント