Microsoft Defender XDR を導入・見直しする管理者が最初に押さえるべき結論は、Defender XDR は単体製品として完結するのではなく、Microsoft Defender for Endpoint、Defender for Office 365、Defender for Identity、Defender for Cloud Apps などの導入状況によって、検出・相関分析・修復の範囲が大きく変わるという点です。
今回確認する「Deploy services supported by Microsoft Defender XDR」は、新しいスイッチを1つ有効化する手順というより、Microsoft Defender XDR を最大限活用するために、どのサービスを展開し、どのライセンス・権限・初期設定を確認すべきかを整理した公式ガイドです。限定的な導入でも Microsoft Defender XDR の機能が完全に停止するわけではありませんが、エンドポイント、メール、ID、クラウドアプリを横断した可視化と自動修復の精度は下がります。(Microsoft Learn)
なお、指定テーマは2026年6月24日の確認対象として扱いますが、参照した Microsoft Learn の対象ページ上では最終更新日が2025年4月25日と表示されています。そのため、本記事では「公式ドキュメントに明記された強制移行」ではなく、現行公式情報をもとに、影響範囲、設定変更の有無、移行期限、管理者が確認すべき実務ポイントを整理します。(Microsoft Learn)
Microsoft Defender XDR で確認すべき更新ポイント
Microsoft Defender XDR は、複数の Microsoft セキュリティサービスから得られるシグナルを統合し、高度な攻撃に対する検出、防止、調査を一元化する仕組みです。公式ドキュメントでは、対象サービス、ライセンス要件、複数サービスを導入した場合の利点、限定導入時の制限、個別サービスの展開手順へのリンクが整理されています。(Microsoft Learn)
今回の実務上のポイントは、次の4つです。
| 確認項目 | 管理者が見るべきポイント |
|---|---|
| 影響範囲 | Defender XDR を使う全テナント、特に Endpoint、Office 365、Identity、Cloud Apps の導入状況に差がある組織 |
| 設定変更 | 対象ページ単体では、既存設定を強制変更する内容ではなく、各サービスのプロビジョニングと初期構成の確認が中心 |
| 移行期限 | 対象ドキュメント内に、特定日までの移行期限は明記されていない |
| 管理者の対応 | ライセンス、権限、ネットワーク許可、各サービスの導入状態、Defender ポータルでの機能表示を確認する |
特に重要なのは、「Microsoft Defender XDR を有効にしている」ことと、「XDR に渡すべきシグナル源が十分に展開されている」ことは別問題だという点です。ポータルにアクセスできても、Defender for Endpoint が未展開であれば端末の詳細な検出やデバイス修復は限定されます。Defender for Identity が未展開であれば、オンプレミス Active Directory の認証イベントや ID 関連の行動検出を十分に取り込めません。
対象となる Microsoft Defender サービス
公式ドキュメントで中心的に扱われているサポート対象サービスは、Microsoft Defender for Endpoint、Microsoft Defender for Office 365、Microsoft Defender for Identity、Microsoft Defender for Cloud Apps の4つです。Microsoft 365 E5、E5 Security、A5、A5 Security、または有効なライセンスの組み合わせにより、これらのサービスと Microsoft Defender XDR を利用できると説明されています。(Microsoft Learn)
| サービス | 主な役割 | 管理者が確認すべきこと |
|---|---|---|
| Microsoft Defender for Endpoint | 端末の保護、EDR、攻撃面の削減、端末イベントの収集 | 対象デバイスがオンボード済みか、EDR/AV/ASR のポリシーが適用されているか |
| Microsoft Defender for Office 365 | メール、添付ファイル、URL、コラボレーション領域の保護 | Safe Links、Safe Attachments、フィッシング対策、保護ポリシーが有効か |
| Microsoft Defender for Identity | Active Directory シグナルを使った ID 脅威検出 | センサー配置、ドメインコントローラー接続、アラートの発生状況を確認する |
| Microsoft Defender for Cloud Apps | SaaS、クラウドアプリ、シャドー IT、OAuth アプリの可視化 | Cloud Discovery、アプリ制御、セッション制御、リスクアプリの検出状況を確認する |
ここでの判断基準は、「導入済みかどうか」だけでは不十分です。各サービスが Defender XDR に有効なシグナルを渡せる状態か、検出後の修復アクションが実行可能か、SOC がインシデントとして追跡できるかまで確認する必要があります。
フル展開と限定展開の違い
Microsoft Defender XDR は、展開するサポートサービスが増えるほど、可視性、相関分析、修復能力が高まります。公式ドキュメントでは、すべてのサポートサービスを展開することで、複数センサーからのアラートやイベントをもとにインシデントを関連付け、自動調査と修復、より包括的な高度なハンティングを利用できると説明されています。(Microsoft Learn)
一方で、限定的な展開でも Microsoft Defender XDR 自体が無効になるわけではありません。ただし、包括的な可視化は制限され、修復機能も導入済みサービスが管理するエンティティに限定されます。(Microsoft Learn)
| 導入状態 | 起きやすい問題 | 実務上の影響 |
|---|---|---|
| Endpoint のみ導入 | メール起点の攻撃経路が見えにくい | 端末感染後の調査はできても、フィッシングメールの波及確認が弱い |
| Office 365 のみ導入 | 端末上の実行後イベントが見えにくい | メール検知後に端末で何が起きたか追いにくい |
| Identity 未導入 | AD 認証、横展開、特権 ID の悪用が見えにくい | ランサムウェアや侵害 ID の調査で攻撃経路が途切れやすい |
| Cloud Apps 未導入 | SaaS 利用、シャドー IT、OAuth アプリのリスクが見えにくい | Microsoft 以外のクラウドアプリを経由した情報流出に気付きにくい |
たとえば、フィッシングメールから認証情報が盗まれ、侵害されたユーザーがクラウドアプリにアクセスし、その後エンドポイントへ横展開する攻撃を考えると、メール、ID、クラウドアプリ、端末のシグナルがそろって初めて攻撃全体を把握しやすくなります。どれか1つが抜けると、SOC は個別アラートをつなぎ合わせる作業に時間を取られます。
ライセンス確認で見落としやすいポイント
Microsoft Defender XDR の前提条件ページでは、Microsoft 365 E5/A5、Microsoft 365 E3 に Defender Suite アドオンや EMS E5 アドオンを組み合わせた構成、Office 365 E5/A5、Microsoft Defender for Endpoint、Defender for Identity、Defender for Cloud Apps、Defender for Office 365 Plan 2、Microsoft 365 Business Premium、Microsoft Defender for Business などが、Defender ポータルから XDR 機能へアクセスできるライセンスとして列挙されています。(Microsoft Learn)
ただし、ライセンスがあることと、すべての XDR シグナルがそろうことは同じではありません。公式情報でも、Defender XDR が相関するシグナルは、保有ライセンスとプロビジョニングされたアクセスに依存すると説明されています。(Microsoft Learn)
| 確認項目 | 確認場所・観点 | 失敗しやすい例 |
|---|---|---|
| ライセンス割り当て | Microsoft 365 管理センターの課金、ライセンス | E5 契約はあるが、対象ユーザーに必要なライセンスが割り当たっていない |
| 機能別の要件 | Defender XDR 前提条件、各 Defender 製品の要件 | 自動攻撃の中断や脅威分析を使いたいが、Defender for Endpoint Plan 2 の要件を確認していない |
| 管理者権限 | Microsoft Entra ID のロール | グローバル管理者で作業し続け、最小権限の運用に移行していない |
| サービスごとの展開状態 | Defender ポータル、各製品の設定画面 | ライセンスはあるが、Defender for Identity センサーや Endpoint オンボードが未完了 |
Microsoft は、可能な限り少ない権限のロールを使用することを推奨しており、グローバル管理者は高権限ロールとして緊急時などに限定すべきと説明しています。日常運用では、セキュリティ管理者、セキュリティオペレーター、セキュリティ閲覧者など、職務に応じたロール設計を行うことが重要です。(Microsoft Learn)
Microsoft Defender XDR の設定変更で確認すべきこと
対象ドキュメントの内容は、既存環境へ一律の設定変更を強制するものではありません。中心となるのは、各サービスをテナントにプロビジョニングし、初期構成を行い、その後 Microsoft Defender XDR を有効化または確認する流れです。(Microsoft Learn)
公式ドキュメントでは、Defender for Endpoint は展開ガイドに沿ったプロビジョニング、Defender for Office 365 は Office 365 側でプロビジョニング済みだが保護ポリシー設定が必要、Defender for Identity はインスタンス作成、Defender for Cloud Apps はクイックスタートによる初期設定が案内されています。(Microsoft Learn)
| 順序 | 作業 | 確認ポイント |
|---|---|---|
| 1 | ライセンスと管理者ロールを確認する | 対象ユーザー、管理者、SOC 担当者に必要なライセンスと権限があるか |
| 2 | Defender for Endpoint を展開する | Windows、macOS、Linux、モバイルなど対象端末のオンボード漏れがないか |
| 3 | Defender for Office 365 の保護ポリシーを確認する | フィッシング、リンク、添付ファイル、なりすまし対策が既定値任せになっていないか |
| 4 | Defender for Identity を構成する | ドメインコントローラーのセンサー、ヘルス、アラート発生状況を確認する |
| 5 | Defender for Cloud Apps を開始する | Cloud Discovery、アプリ制御、OAuth アプリ監視、条件付きアクセス連携を確認する |
| 6 | Microsoft Defender XDR を有効化・確認する | Defender ポータルでインシデント、アラート、アクションセンター、高度なハンティングが使えるか |
| 7 | 運用ルールを整備する | インシデント担当、エスカレーション、除外、誤検知対応、定期レビューを決める |
Microsoft Defender XDR は、必要な権限を持つ対象顧客が Microsoft Defender ポータルにアクセスすると自動的にオンになると説明されています。また、オンボード後はインシデント管理、アラートキュー、アクションセンター、高度なハンティング、脅威分析などの機能が追加されます。(Microsoft Learn)
ネットワークとデータセンターの確認も必要
Microsoft Defender XDR の導入では、ポータルやクラウドサービスへ接続できることも前提です。公式ドキュメントでは、Microsoft Defender ポータルをスムーズに利用するため、ネットワークファイアウォールを構成し、Azure Monitor で使用される送信 IP アドレスを許可リストに追加することが案内されています。(Microsoft Learn)
プロキシや閉域網の制約が強い組織では、ここが障害になりやすいポイントです。端末はオンボード済みに見えても、センサーがクラウドへ正常送信できない、管理者はポータルに入れるが一部機能が読み込めない、Identity センサーの通信が不安定といった問題が起きることがあります。
また、Microsoft Defender XDR のデータは、Microsoft Defender for Endpoint で使用される場所と同じ場所に保存・処理されます。Defender for Endpoint がない場合は、アクティブな Microsoft 365 セキュリティサービスの場所に基づいて新しいデータセンターの場所が自動選択されます。グローバル展開では、地域要件、データ所在地、既存の MDE プロビジョニング場所を事前に確認しておくべきです。(Microsoft Learn)
グローバル組織での影響範囲
グローバル企業では、国やリージョンごとに Microsoft 365 テナント、ライセンス、データ所在地、ネットワーク制御、セキュリティ運用体制が異なることがあります。この場合、単に「本社テナントで Defender XDR を有効にした」だけでは不十分です。
特に確認したいのは、次の観点です。
- 各リージョンのユーザーに必要なライセンスが割り当たっているか
- 拠点ごとの端末が Defender for Endpoint にオンボードされているか
- オンプレミス AD を持つ地域で Defender for Identity センサーが導入されているか
- 各国で利用されている SaaS が Defender for Cloud Apps の可視化対象になっているか
- SOC が複数タイムゾーンのインシデントをどの順序で処理するか決まっているか
- データ所在地や政府クラウドなど、地域固有の制約を確認しているか
Microsoft Learn の前提条件ページでは、米国政府機関向けの可用性は別情報を参照するよう案内されています。また、Office 365 統合の Microsoft Defender XDR 機能が一部の Office 365 データセンター場所では利用できない旨も記載されています。グローバル向けに展開する場合は、地域差を前提に導入計画を作る必要があります。(Microsoft Learn)
移行期限はあるのか
「Deploy services supported by Microsoft Defender XDR」の対象ページ自体には、特定日までに移行しなければならない期限や、既存構成が自動的に廃止される期限は明記されていません。したがって、このドキュメントに関しては、期限対応よりも、現在の導入状態を棚卸しして XDR の効果を最大化することが優先です。(Microsoft Learn)
ただし、Microsoft Defender XDR 全体では、機能追加やスキーマ変更、プレビューから一般提供への移行が継続的に行われています。Microsoft Learn の「What’s new in Microsoft Defender XDR」では、製品更新や重要通知を Microsoft 365 管理センターのメッセージセンターでも受け取れると案内されています。管理者は対象ページだけでなく、メッセージセンターと Defender XDR の新機能情報を定期的に確認するべきです。(Microsoft Learn)
たとえば、2026年6月の Microsoft Defender XDR 新機能では、高度なハンティングのスキーマテーブル追加や、AI エージェント関連テーブルの移行情報が案内されています。こうした変更は、既存の KQL クエリ、カスタム検出、SOC の調査手順に影響する可能性があります。(Microsoft Learn)
高度なハンティングを使う組織の注意点
Microsoft Defender XDR の価値を引き出すには、インシデント画面だけでなく、高度なハンティングの設計も重要です。高度なハンティングは、最大30日分の生データをクエリベースで調査でき、Defender for Endpoint、Defender for Office 365、Defender for Cloud Apps、Defender for Identity、Microsoft Sentinel などのデータを対象にできます。(Microsoft Learn)
ただし、導入していないサービスのテーブルやシグナルは当然ながら十分に取得できません。たとえば、メール系のテーブルを前提にした検出ルールを作っても、Defender for Office 365 の対象範囲や権限が不足していれば期待通りの調査はできません。逆に、Endpoint 側のテーブルだけを使っていると、メールや ID を起点にした攻撃の前段を見逃す可能性があります。
高度なハンティングには、日付範囲、結果件数、タイムアウト、結果サイズなどの制限もあります。公式ドキュメントでは、Defender データの検索範囲は通常最大30日、クエリ結果は最大100,000行、タイムアウトは10分、結果サイズには64MBの制限があると説明されています。運用では、長大なクエリを1本で回すより、目的別に絞り込んだクエリを用意する方が安定します。(Microsoft Learn)
管理者がすぐ確認すべきチェックリスト
Microsoft Defender XDR の展開状況を見直す場合は、次の順に確認すると抜け漏れを減らせます。
| 優先度 | 確認内容 | 判断基準 |
|---|---|---|
| 高 | 対象サービスの導入状況 | Endpoint、Office 365、Identity、Cloud Apps のどれが未導入かを一覧化する |
| 高 | ライセンスとユーザー割り当て | 契約だけでなく、対象ユーザー・管理者へ割り当て済みか確認する |
| 高 | Defender ポータルの表示 | インシデント、アラート、アクションセンター、高度なハンティングが表示されるか |
| 高 | 端末オンボード率 | 対象デバイスの未オンボード、センサー異常、古い OS を確認する |
| 中 | メール保護ポリシー | 既定ポリシー任せにせず、組織のリスクに合わせて調整する |
| 中 | Identity センサー | ドメインコントローラーへのセンサー配置とヘルスを確認する |
| 中 | Cloud Apps 可視化 | 利用 SaaS、シャドー IT、OAuth アプリの検出状況を確認する |
| 中 | ネットワーク許可 | プロキシ、ファイアウォール、送信 IP、ポータルアクセスを確認する |
| 中 | SOC 運用 | インシデント担当、重大度、エスカレーション、除外申請の手順を定義する |
| 低 | レポート・改善サイクル | 月次で検出件数、対応時間、未対応アクションをレビューする |
最初にやるべきことは、Microsoft Defender ポータルを開いて機能が表示されるか確認することではありません。先に、各サービスが「シグナルを出せる状態か」「修復対象として管理できる状態か」を棚卸しすることです。ここを飛ばすと、ポータル上は XDR らしく見えても、実際のインシデント対応では情報が欠けます。
よくある失敗と回避策
ライセンスがあるだけで導入済みだと考えてしまう
Microsoft 365 E5 などの契約があっても、各サービスの初期構成、端末オンボード、センサー配置、保護ポリシー設定が終わっていなければ、XDR の相関分析は十分に機能しません。ライセンス確認と展開確認は別のタスクとして扱いましょう。
限定導入のまま「全社 XDR」として運用してしまう
Defender for Endpoint だけ、または Defender for Office 365 だけでも価値はあります。しかし、それを全社的な XDR 運用と呼ぶと、攻撃経路の一部しか見えていない可能性があります。未導入領域をリスクとして明示し、段階導入のロードマップを作ることが重要です。
グローバル管理者で日常運用してしまう
初期構築ではグローバル管理者が必要になる場面がありますが、日常運用まで高権限アカウントで行うのは避けるべきです。Microsoft も最小権限の使用を推奨しているため、SOC、メール管理、端末管理、ID 管理の担当に合わせてロールを分離します。(Microsoft Learn)
ネットワーク制御でセンサー通信を止めてしまう
プロキシやファイアウォールで通信が制限されている環境では、ポータル表示、センサー送信、クラウド連携が不安定になることがあります。展開前に、Microsoft Defender ポータル、Defender for Endpoint、Defender for Identity、Defender for Cloud Apps それぞれの接続要件を確認しましょう。(Microsoft Learn)
高度なハンティングのクエリを導入状況に合わせていない
複数サービスのデータを前提にした KQL クエリを使う場合、未導入サービスや権限不足があると、結果が空になったり、調査対象が偏ったりします。カスタム検出や定期調査クエリは、利用可能なテーブルとデータ保持期間を確認してから運用に入れるべきです。(Microsoft Learn)
まず取るべき実務アクション
Microsoft Defender XDR の「Deploy services supported by Microsoft Defender XDR」を確認した管理者が次に行うべきことは、次の3つです。
まず、現在の Defender サービス導入状況を一覧化します。Endpoint、Office 365、Identity、Cloud Apps について、ライセンス、プロビジョニング、初期構成、データ受信、修復アクションの可否を表にまとめます。
次に、限定導入による見えない領域を明確にします。端末、メール、ID、クラウドアプリのどこに検出ギャップがあるかを整理し、攻撃シナリオごとに「今の構成で検出できるか」「自動修復できるか」を確認します。
最後に、Microsoft Defender ポータルでインシデント、アラート、アクションセンター、高度なハンティング、脅威分析を確認し、SOC の運用手順へ落とし込みます。Microsoft Defender XDR は、導入して終わりではなく、複数サービスからのシグナルを継続的に改善してこそ効果が出ます。
今回の対象ドキュメントに明確な移行期限はありませんが、放置してよいという意味ではありません。今すぐ行うべきことは、期限対応ではなく、Microsoft Defender XDR が本当に横断的な検出・調査・修復を行える構成になっているかを確認することです。
コメント