Microsoft Defender XDR を SOC に組み込む前に、最初に確認すべきなのは「機能を有効化できるか」ではなく、「SOC が統合運用できる状態か」です。2026年6月24日に更新された Microsoft Learn の「Step 2. Perform a SOC integration readiness assessment using the Zero Trust Framework」は、Microsoft Defender XDR 導入前に、ID、端末、データ、アプリ、インフラ、ネットワークの不足点を洗い出し、SOC 運用に入る前の是正計画を作るためのガイドです。対象は Microsoft Defender XDR で、Microsoft はこの評価を Zero Trust アプローチに基づいて実施することを推奨しています。(Microsoft Learn)
結論から言えば、今回の更新は「管理者がすぐに設定を変更しなければならない新機能」ではありません。移行期限や強制的な設定変更が示されたものでもありません。重要なのは、Microsoft Defender XDR を SOC のインシデント対応、ハンティング、アラート運用、ユースケース開発に組み込む前に、既存環境の弱点を可視化し、運用側の準備不足を先に解消することです。
Microsoft Defender XDR の SOC 統合準備評価とは
Microsoft Defender XDR の SOC 統合準備評価とは、Defender XDR をセキュリティ運用に組み込む前に、組織の環境が統合運用に耐えられる状態かを確認する作業です。
Microsoft の SOC 統合ガイドでは、Defender XDR を SOC に組み込む流れを複数のステップで整理しており、Step 2 は「Zero Trust Framework を使った SOC 統合準備評価」に位置付けられています。前段では運用準備を計画し、次の Step 3 では SOC のサービスカタログと Defender XDR の機能を対応付ける流れです。(Microsoft Learn)
ここでのポイントは、Defender XDR の導入を単なる製品展開として扱わないことです。SOC では、アラートを誰が見るのか、どの条件でインシデント化するのか、どのチームにエスカレーションするのか、どの証跡をもとに判断するのかまで決める必要があります。環境側に不足があるまま Defender XDR を有効化すると、アラートの精度や対応速度以前に、運用フローそのものが詰まりやすくなります。
2026年6月24日更新で押さえるべき変更点
今回確認すべき更新ポイントは、次の3つです。
| 確認項目 | 内容 | 管理者への影響 |
|---|---|---|
| 対象サービス | Microsoft Defender XDR | Defender for Endpoint、Defender for Identity、Defender for Office 365、Defender for Cloud Apps などを横断する SOC 運用の準備確認が必要 |
| 更新内容の性質 | Zero Trust Framework に基づく SOC 統合準備評価の整理 | すぐに設定を変える話ではなく、導入前評価と是正計画の作成が中心 |
| 移行期限 | 該当ページでは特定の移行期限は示されていない | 「いつまでに移行」よりも、「何が未整備か」を洗い出すことが優先 |
Microsoft Learn の当該ページは 2026年6月24日に更新され、Defender XDR 採用に備えて Zero Trust アプローチで準備状況を評価すること、さらに基礎要件を満たしていない領域を特定して是正することが説明されています。(Microsoft Learn)
実務上は、「新しい画面が増えたか」よりも、「自社の SOC が Defender XDR の統合アラートやインシデントを活用できる状態か」を確認するための更新と見るべきです。
Zero Trust Framework を使う理由
Zero Trust は、「侵害されている可能性を前提にする」「暗黙に信頼しない」「常に検証する」という考え方に基づくセキュリティモデルです。Microsoft の Zero Trust Guidance Center では、ID、デバイス、アプリケーション、データ、インフラ、ネットワークなどの柱を保護対象として整理しています。(Microsoft Learn)
Defender XDR は複数の Defender 製品や Microsoft 365 のセキュリティ信号を横断してインシデントを相関します。そのため、ID だけが整っていても、端末インベントリが不完全なら調査が止まります。端末が整っていても、特権アカウントの棚卸しがなければ、攻撃経路の評価が曖昧になります。
つまり SOC 統合準備評価では、個別機能の有効・無効ではなく、攻撃を検知、調査、封じ込め、復旧するための土台がそろっているかを確認します。
影響範囲：誰が確認すべきか
今回の内容は、Microsoft Defender 管理者だけの作業ではありません。SOC に Defender XDR を統合する場合、次の担当者が関係します。
| 関係者 | 確認すべきこと |
|---|---|
| SOC / SecOps チーム | アラート対応、インシデント分類、ハンティング、エスカレーション基準 |
| Microsoft 365 管理者 | Defender ポータルへのアクセス、ライセンス、ロール、サービス有効化状況 |
| ID 管理者 | Microsoft Entra ID、オンプレミス AD DS、MFA、特権アカウント管理 |
| エンドポイント管理者 | 端末インベントリ、OS バージョン、Defender for Endpoint の展開状況 |
| ネットワーク管理者 | 通信許可、帯域、プロキシ、分離されたネットワークの可視性 |
| アプリ / クラウド管理者 | SaaS 利用状況、未承認アプリ、カスタムアプリの連携可否 |
| CISO / セキュリティ責任者 | 是正優先度、リスク許容度、SOC サービス範囲、投資判断 |
特にグローバル企業では、地域ごとに AD DS、端末管理、SaaS 利用、ネットワーク設計が異なることがあります。日本、米国、欧州、アジア拠点で前提が違う場合、1つのテナントに Defender XDR を展開しても、SOC の運用成熟度は拠点ごとにばらつきます。
SOC 統合準備評価で見るべき5つの領域
Microsoft Learn では、是正が必要な例として、ID、エンドポイント、データとアプリ、インフラ、ネットワークが挙げられています。たとえば、古いオンプレミス AD DS ドメイン、MFA 計画の不足、特権アカウントの棚卸し不足、レガシー OS、端末インベントリ不足、データガバナンス標準の欠如、未承認 SaaS、コンテナセキュリティ不足、低帯域やフラットネットワークなどです。(Microsoft Learn)
実務では、次のように評価すると整理しやすくなります。
| 領域 | よくある不足 | 確認すべき質問 | 初期対応の例 |
|---|---|---|---|
| ID | MFA 未整備、特権アカウント不明、古い AD DS 構成 | 管理者アカウント、サービスアカウント、休眠アカウントを把握しているか | 特権アカウント一覧を作成し、MFA と条件付きアクセスの適用範囲を確認する |
| エンドポイント | レガシー OS、未管理端末、端末台帳の不一致 | Defender for Endpoint の対象外端末はどれか | OS、所有部門、管理方式、オンボード状況を一覧化する |
| データとアプリ | データ分類なし、カスタムアプリ未把握 | 重要データがどのアプリで扱われているか | 重要データ、業務アプリ、外部共有の棚卸しを行う |
| インフラ | 未承認 SaaS、コンテナ保護不足、クラウド資産の可視性不足 | SOC が監視対象に含めるクラウド資産はどれか | SaaS 利用状況、クラウド環境、ワークロードの責任者を整理する |
| ネットワーク | 低帯域、フラットネットワーク、無線 LAN の弱点 | 侵害時に横展開を抑止できる構成か | 拠点別の帯域、セグメント、プロキシ、通信許可を確認する |
ここで大切なのは、「全部を一度に完璧にする」ことではありません。SOC 統合に直接影響する不足から優先順位を付けることです。たとえば、端末インベントリが不完全なまま高度なハンティングを始めても、調査対象の抜け漏れが残ります。まずは検知と調査の前提になる資産情報を固めるべきです。
設定変更は必要か
今回の Step 2 自体は、Defender ポータルで特定のスイッチをオンにする手順ではありません。ただし、準備評価の結果として、既存設定の見直しが必要になる場合があります。
Microsoft Defender XDR は、Defender for Endpoint、Defender for Office 365、Defender for Cloud Apps、Defender for Identity などの主要機能を統合し、Microsoft Defender ポータルでインシデント対応を一元化する位置付けです。Defender XDR は、対象となる顧客が必要な権限で Defender ポータルにアクセスした際に自動的に有効化される場合があり、利用にはロール、ネットワーク、対応サービスの構成確認が関係します。(Microsoft Learn)
設定面では、次の項目を確認しておくと安全です。
| 確認項目 | 見るべきポイント | 放置した場合のリスク |
|---|---|---|
| ライセンス | Defender XDR と関連 Defender サービスを利用できる契約か | 一部機能だけ有効になり、SOC が期待する相関分析ができない |
| 管理者ロール | Security Administrator、Security Operator、Security Reader などの役割設計 | 調査や対応に必要な画面を担当者が開けない |
| Defender ポータル接続 | security.microsoft.com への通信、プロキシ、許可リスト | SOC 端末や拠点からポータルに安定してアクセスできない |
| 関連サービス | Endpoint、Identity、Office 365、Cloud Apps の展開状況 | インシデント相関に必要な信号が不足する |
| データ保管場所 | Defender for Endpoint など既存サービスのデータ所在地 | グローバル運用やコンプライアンス確認で手戻りが発生する |
ライセンスについては、Microsoft 365 セキュリティ製品のライセンスにより Defender XDR を追加費用なしで利用できる場合がある一方、Microsoft は Microsoft 365 E5、E5 Security、A5、A5 Security、または対応サービスを利用できる有効な組み合わせを推奨しています。契約条件は変更される可能性があるため、実際の利用可否は管理センターや契約情報で確認してください。(Microsoft Learn)
移行期限はあるのか
今回の公式ページでは、特定の日付までに移行しなければならないという期限は示されていません。したがって、管理者が慌てて設定を変える必要はありません。
ただし、移行期限がないことと、対応を後回しにしてよいことは別です。Defender XDR を SOC の中核に据える予定があるなら、準備評価は早めに始めるべきです。理由は、評価で見つかる課題の多くが、セキュリティチームだけでは解決できないからです。
たとえば、古い OS の更改、AD DS の整理、ネットワーク分離、SaaS 利用の統制、データ分類ルールの整備は、数日で終わる作業ではありません。SOC 統合プロジェクトの後半で発覚すると、ユースケース作成や運用開始が遅れます。
管理者が確認すべき実務手順
Microsoft Defender XDR の SOC 統合準備評価は、次の順番で進めると実務に落とし込みやすくなります。
現在の SOC 運用を棚卸しする
最初に、現在の SOC が何を担当しているかを整理します。アラート監視だけなのか、インシデント対応まで含むのか、脆弱性管理、フォレンジック、CSIRT、内部不正監視、DLP、フィッシング対応まで見るのかを明確にします。
Microsoft の Step 3 では、SOC のサービス領域として、侵入・マルウェア分析、脅威インテリジェンス、ハンティング、フォレンジック、インシデント対応、CSIRT、DLP、XDR/SOAR、フィッシングなどが例示されています。Defender XDR の機能をどこに割り当てるかを決めるには、先に自社の SOC サービスカタログが必要です。(Microsoft Learn)
Zero Trust の柱ごとに不足を記録する
次に、ID、エンドポイント、データとアプリ、インフラ、ネットワークの各領域で、未整備の項目を記録します。
このとき、「できている」「できていない」だけで判断すると曖昧になります。次のように状態を分けると、改善計画に変換しやすくなります。
| 評価 | 状態 | 例 |
|---|---|---|
| 対応済み | SOC 運用に必要な情報と設定が整っている | 特権アカウント一覧があり、MFA 適用状況も確認済み |
| 一部対応 | 主要範囲は整っているが例外が残っている | 本社端末は管理済みだが、海外拠点端末に未管理がある |
| 未対応 | 調査や対応に必要な情報が不足している | SaaS 利用状況が把握されていない |
| 要確認 | 担当部門や設定根拠が不明 | 過去の例外設定が残っているが理由が分からない |
是正項目に優先順位を付ける
不足点が見つかったら、すべてを同じ重みで扱わないことが重要です。優先順位は、SOC 運用への影響で決めます。
優先度が高いのは、次のような項目です。
- インシデント調査で必ず使う資産情報が不足している
- 特権アカウントや高リスクユーザーの管理が不十分
- Defender XDR の信号収集に必要なサービスが未展開
- 拠点や部門によってログ取得状況が大きく異なる
- ネットワークやプロキシ設定により Defender ポータルや関連サービスへの接続が不安定
逆に、運用開始後でも段階的に改善できる項目は、フェーズを分けて管理します。最初から全領域を完全統制しようとすると、SOC 統合そのものが進まなくなります。
SOC のユースケースに結び付ける
準備評価の目的は、評価表を作ることではありません。最終的には、Defender XDR を使った SOC ユースケースに結び付ける必要があります。
たとえば、次のように考えます。
| ユースケース | 必要な前提 | 準備不足の例 |
|---|---|---|
| フィッシング起点の侵害調査 | メール、ID、端末の相関 | Defender for Office 365 は有効だが端末側の可視性が不足 |
| ランサムウェア初動対応 | 端末隔離、横展開把握、特権 ID 確認 | レガシー OS が多く、端末管理が不完全 |
| 不審な SaaS 利用検知 | Cloud Apps の可視化、SaaS 棚卸し | 未承認 SaaS が多く、業務上の正当利用と区別できない |
| 管理者アカウント侵害対応 | 特権アカウント台帳、MFA、サインインログ | 特権ロールの棚卸しが古い |
Microsoft は、SOC 運用でユースケースを定義し、優先順位を付け、チームの役割やスキルと結び付けることを推奨しています。特に、セキュリティツールは相互に関連するため、1つの機能変更が別の運用に影響する可能性があります。(Microsoft Learn)
失敗しやすいポイント
SOC 統合準備評価でよくある失敗は、評価を「チェックリスト消化」で終わらせることです。以下のような進め方は避けるべきです。
Defender XDR を有効化すれば SOC が高度化すると考える
Defender XDR は強力な統合基盤ですが、SOC の判断基準や担当範囲が曖昧なままでは効果を発揮しにくくなります。アラートが統合されても、誰がどの条件で対応するのかが決まっていなければ、運用は改善しません。
ID と端末の棚卸しを後回しにする
攻撃調査では、ユーザー、端末、アプリ、データの関係を追います。ID と端末の管理が不完全だと、Defender XDR でインシデントが表示されても、実際の業務影響や対応範囲を判断しにくくなります。
グローバル拠点の差を無視する
本社では準備が整っていても、海外拠点や買収した子会社では端末管理、AD DS、ネットワーク、SaaS 利用ルールが異なることがあります。グローバル SOC で運用する場合は、拠点ごとの差を前提に、最低限そろえる基準を決める必要があります。
ライセンスとロールを最後に確認する
PoC や初期展開では管理者が広い権限を持っているため問題が見えにくくなります。本番運用では、SOC アナリスト、セキュリティ管理者、閲覧者、インシデント対応者など、役割ごとに権限を分ける必要があります。ロール設計を後回しにすると、運用開始後に「見える人」と「対応できる人」がずれる原因になります。
グローバル企業で追加確認すべき観点
グローバル向けに Microsoft Defender XDR を統合する場合、日本国内だけの導入よりも確認項目が増えます。
まず、データ所在地と規制対応を確認します。Defender XDR のデータ処理や保管場所は、既存の Defender for Endpoint などの構成に影響を受ける場合があります。Microsoft Learn では、Defender XDR のデータは Defender for Endpoint と同じ場所で保存・処理され、Defender for Endpoint がない場合はアクティブな Microsoft 365 セキュリティサービスの場所に基づいて選択されると説明されています。(Microsoft Learn)
次に、SOC の対応時間と言語を決めます。24時間365日の監視なのか、地域ごとの営業時間対応なのかで、アラートの優先度、通知先、エスカレーション先が変わります。日本語、英語、現地語のどれでインシデント記録を残すかも、後から揉めやすいポイントです。
さらに、例外管理も重要です。特定地域だけ古い OS が残っている、工場ネットワークだけ分離されている、買収企業だけ別テナントを使っている、といった状況は珍しくありません。例外は「放置」ではなく、「リスクを承認し、期限を決めて是正する対象」として管理する必要があります。
今回の更新を受けて管理者が今すぐ行うべきこと
今回の更新を受けて、管理者は次の3つから着手するとよいでしょう。
まず、Microsoft Defender XDR の SOC 統合を予定している範囲を明確にします。対象テナント、対象拠点、対象サービス、SOC が担当する業務範囲を決めます。
次に、Zero Trust の柱ごとに準備状況を棚卸しします。ID、端末、データ、アプリ、インフラ、ネットワークを分けて、未整備項目、担当部門、是正期限を記録します。
最後に、SOC のユースケースに変換します。単に「MFA を有効化する」「端末を登録する」ではなく、「管理者アカウント侵害時に誰が何分以内に確認し、どの証跡で判断するか」まで落とし込むと、Defender XDR の価値を運用に反映しやすくなります。
Microsoft Defender XDR の Step 2 は、派手な新機能ではありません。しかし、SOC 統合の成否を左右する重要な準備工程です。設定画面を触る前に、ID、端末、データ、アプリ、インフラ、ネットワークの不足を洗い出し、SOC のサービスカタログとユースケースに結び付けることが、管理者にとって最も現実的な次の一手です。
コメント