Microsoft Defender XDRを有効にする際の結論は、対象ライセンスと必要な権限を満たしているテナントでは、Microsoft Defenderポータルへのアクセスをきっかけに有効化が進むという点です。ただし、管理者が確認すべきことは「オンにできるか」だけではありません。ライセンス、ロール、ファイアウォール、データ保存場所、既存のアラート運用、SIEM/SOAR連携や自動化への影響まで見ておく必要があります。
Microsoft Defender XDRは、Microsoft Defender for Endpoint、Microsoft Defender for Office 365、Microsoft Defender for Cloud Apps、Microsoft Defender for Identityなどの機能を統合し、インシデント調査と対応をMicrosoft Defenderポータルに集約するサービスです。公式情報では、既存の展開、設定、統合済みサービスのデータに影響を与えずに、複数サービスのデータを集約して一元的な対応ワークフローを可能にすると説明されています。(Microsoft Learn)
Microsoft Defender XDRを有効にすると何が変わるのか
Microsoft Defender XDRを有効にすると、個別のDefender製品で発生していたアラートやセキュリティシグナルを、インシデント単位で確認しやすくなります。特にSOCや情報システム部門では、「メールのアラート」「端末の検知」「IDの不審な動き」「クラウドアプリのリスク」を別々に追うのではなく、攻撃の流れとしてまとめて確認できる点が大きな変化です。
公式ドキュメントでは、プロビジョニング後にインシデント管理、アラートキュー、アクションセンター、高度なハンティング、脅威分析などの機能が追加されるとされています。(Microsoft Learn)
| 変更点 | 管理者への影響 | 確認すべきこと |
|---|---|---|
| インシデント対応がMicrosoft Defenderポータル中心になる | 調査・対応の入口が統合される | SOC手順書、エスカレーションルール、通知先を見直す |
| アラートが複数サービス横断で関連付けられる | 単発アラートではなく攻撃全体を追いやすくなる | 既存のチケット起票条件や重複アラート処理を確認する |
| アクションセンターで自動調査・対応を管理する | 承認待ちの修復アクションが発生する | 誰が承認・却下できるかを権限設計に反映する |
| 高度なハンティングを使える範囲が広がる | 端末、メール、IDなどを横断して調査しやすくなる | 既存KQLクエリ、検出ルール、運用レポートを検証する |
| データが一元的に処理・保存される | データ所在地や監査要件に関わる | データセンターの場所、保持期間、社内規程との整合性を確認する |
ここで重要なのは、Microsoft Defender XDRの有効化は「既存のDefender製品を勝手に再構成する作業」ではないということです。既に展開済みのサービスからデータを集約し、相関分析や対応をしやすくするものです。一方で、展開済みサービスが少なければ、見える範囲や修復できる範囲も限定されます。(Microsoft Learn)
影響範囲はどこまで及ぶのか
Microsoft Defender XDRの影響範囲は、導入済みのDefenderサービスによって変わります。すべてのサービスを展開している場合は、エンドポイント、メール、ID、クラウドアプリを横断した相関分析が期待できます。反対に、Defender for Endpointだけを使っている環境では、端末中心の可視化に寄り、メールやIDの文脈は不足します。
| サービス | 主な対象 | XDRで見えるようになる代表的な情報 | 注意点 |
|---|---|---|---|
| Microsoft Defender for Endpoint | PC、サーバー、端末 | EDR検知、デバイス状態、ファイル、プロセス、ネットワーク接続 | 端末がオンボードされていないと十分なシグナルが得られない |
| Microsoft Defender for Office 365 | Exchange Online、メール、Teamsなど | メール、添付ファイル、URL、メールボックス関連の検知 | 保護ポリシーや誤検知対応の運用設計が必要 |
| Microsoft Defender for Identity | Active Directory、ID関連シグナル | 認証イベント、ID関連の不審な動作 | センサー展開やAD環境の前提を確認する |
| Microsoft Defender for Cloud Apps | SaaS、クラウドアプリ | シャドーIT、クラウドアプリ利用、データ公開リスク | Cloud Apps側の初期設定やログイン確認が必要 |
公式情報では、サポートされているサービスをすべて展開すると、利用可能なセンサーやサービス固有の分析に基づくインシデント関連付け、自動調査と修復、より包括的な高度なハンティングが利用しやすくなると説明されています。限定的な展開でもMicrosoft Defender XDR自体は無効になりませんが、可視性と修復範囲は導入済みサービスに依存します。(Microsoft Learn)
有効化前に確認すべきライセンスと権限
Microsoft Defender XDRを有効にする前に、最初に確認すべきなのはライセンスです。Microsoft 365 E5/A5、Microsoft 365 E3にDefenderスイートや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など、複数のライセンス構成でMicrosoft Defender XDR機能にアクセスできます。ライセンスによって利用できるシグナルや機能範囲は変わるため、「XDRを開けるか」だけでなく「必要な検知・対応機能が使えるか」を確認する必要があります。(Microsoft Learn)
特に注意したいのは、自動攻撃の中断と脅威分析です。公式情報では、自動攻撃の中断と脅威分析にはMicrosoft Defender for Endpoint Plan 2が必要とされています。XDRの画面が表示されても、期待していた高度な機能がライセンス不足で使えないことがあるため、導入前の棚卸しは必須です。(Microsoft Learn)
権限については、実務上は「最小権限」を基本に設計します。Microsoft Defender XDRを有効にするロールとして、グローバル管理者、セキュリティ管理者、セキュリティオペレーター、グローバル閲覧者、セキュリティ閲覧者、コンプライアンス管理者、アプリケーション管理者などが案内されています。一方、前提条件のページでは、少なくともMicrosoft Entra IDのセキュリティ管理者が必要とされています。運用では、初期有効化や重要設定はセキュリティ管理者以上、日常監視はセキュリティ閲覧者やカスタムロールに分けるのが安全です。(Microsoft Learn)
| 確認項目 | 推奨する確認方法 | よくある失敗 |
|---|---|---|
| ライセンス | Microsoft 365管理センターの「課金」>「ライセンス」で確認 | E5相当と思い込んでいたが、一部ユーザーだけ対象外 |
| 有効化権限 | Microsoft Entra IDとMicrosoft Defenderポータルの権限を確認 | グローバル管理者で作業し、そのまま日常運用してしまう |
| 閲覧権限 | 監視担当、ヘルプデスク、SOCの役割ごとに分離 | 監視担当に過剰な修復権限を付与してしまう |
| 自動対応の承認者 | アクションセンターの承認権限を事前に決める | 承認待ちアクションが放置され、修復が遅れる |
Microsoftは、可能な限り権限の少ないロールを使うことを推奨しており、グローバル管理者は緊急時など既存ロールで対応できない場合に限定すべきとしています。(Microsoft Learn)
ネットワークとプロキシで確認すべき設定
Microsoft Defender XDRを有効にしても、ネットワーク側で必要な通信が遮断されていると、ポータル表示、調査、ハンティング、各Defenderサービスとの連携に支障が出る可能性があります。公式情報では、Microsoft Defenderポータルを円滑に利用するため、ネットワークファイアウォールの許可リストにAzure Monitorで使用される送信IPアドレスを追加し、Defender for Endpoint、Defender for Office 365、Defender for Identity、Defender for Cloud Apps側の構成も確認するよう案内されています。(Microsoft Learn)
実務では、次の順番で確認すると抜け漏れを減らせます。
| 確認箇所 | 見るべきポイント |
|---|---|
| ファイアウォール | Microsoft Defenderポータルと関連クラウドサービスへの通信が許可されているか |
| プロキシ | SSLインスペクションや認証プロキシでDefender関連通信を妨げていないか |
| Endpoint通信 | Defender for Endpointのセンサーが正常にクラウドへ送信できているか |
| Identity通信 | Defender for Identityセンサーや関連サーバーの通信要件を満たしているか |
| Cloud Apps | ポータルアクセス、ログ連携、初期サインインが完了しているか |
ありがちな失敗は、「管理者PCからポータルにアクセスできたので問題ない」と判断してしまうことです。実際には、SOC端末、踏み台環境、VDI、サーバーセグメント、プロキシ配下の端末などで通信条件が異なる場合があります。導入前に複数の代表的なネットワークからアクセスと機能表示を確認しておくべきです。
データセンターの場所とデータ管理の注意点
Microsoft Defender XDRでは、データセンターの場所も確認が必要です。公式情報では、Microsoft Defender XDRのデータはMicrosoft Defender for Endpointで使用されるのと同じ場所に格納・処理され、Defender for Endpointがない場合は、アクティブなMicrosoft 365セキュリティサービスの場所に基づいて新しいデータセンターの場所が自動選択されるとされています。別のデータセンターでのプロビジョニングが必要な場合は、Microsoft Defenderポータルからサポートへ問い合わせる流れです。(Microsoft Learn)
データ所在地は、あとから簡単に変更できる前提で考えないほうが安全です。特に、金融、医療、公共、グローバル企業、海外子会社を含むテナントでは、次の点を事前に確認してください。
| 確認項目 | 実務上の判断基準 |
|---|---|
| データ所在地 | 社内規程、契約、監査要件に合っているか |
| 既存のDefender for Endpoint構成 | 既に選択済みの地域を把握しているか |
| データ保持 | インシデント調査、監査、フォレンジックに必要な期間と合うか |
| テナント統合・分割 | 海外拠点や子会社のデータ管理方針と矛盾しないか |
| サポート対応 | 希望する場所でのプロビジョニングが必要な場合、事前に問い合わせる体制があるか |
Defender for Endpointの公式情報では、デバイスから収集されるファイル、プロセス、レジストリ、ネットワーク接続、デバイス情報などがサービスに格納され、ポータルではMicrosoft Defender for Endpointのデータが180日間表示されるとされています。高度なハンティング調査エクスペリエンスでは、クエリによるアクセス期間が別途定められています。(Microsoft Learn)
Microsoft Defender XDRを有効にする基本手順
Microsoft Defender XDRのオンボードは、複雑なウィザードを長時間進める作業ではありません。公式情報では、Microsoft Defenderポータルのナビゲーションから「インシデントとアラート」「ハンティング」「アクションセンター」「脅威分析」などを選択すると、オンボードプロセスを開始できるとされています。(Microsoft Learn)
ただし、本番環境で安全に展開するには、次の順序で進めるのがおすすめです。
| 手順 | 作業内容 | 完了の目安 |
|---|---|---|
| 事前確認 | ライセンス、管理者ロール、データ所在地、ネットワーク要件を確認 | 有効化前チェックリストが埋まっている |
| 対象サービスの棚卸し | Endpoint、Office 365、Identity、Cloud Appsの導入状況を確認 | どのサービスからシグナルが入るか説明できる |
| ポータルアクセス確認 | Microsoft Defenderポータルに管理者アカウントでアクセス | 必要なメニューが表示される |
| オンボード開始 | インシデント、ハンティング、アクションセンターなどを開く | XDR機能がプロビジョニングされる |
| 機能確認 | インシデント管理、アラートキュー、高度なハンティング、脅威分析を確認 | SOC担当者が日常業務で使える |
| 運用検証 | 既存アラート、チケット、SIEM/SOAR、通知ルールを確認 | 旧運用と新運用の差分が整理される |
| 本展開 | 管理者、SOC、ヘルプデスクへ手順を展開 | 役割ごとの対応手順が明文化されている |
Defender for Cloud Appsとの統合では、少なくとも一度Microsoft Defender for Cloud Appsにログインする必要があると案内されています。Cloud Appsを使っている環境では、XDR側の画面だけでなく、Cloud Apps側の初期状態も確認してください。(Microsoft Learn)
管理者が見落としやすい展開上の注意点
Microsoft Defender XDRの有効化で失敗しやすいのは、技術的なボタン操作ではなく、周辺運用の準備不足です。特に次の項目は、導入後にトラブルになりやすいポイントです。
既存のアラート運用をそのまま使い続けない
XDRでは、複数のアラートが1つのインシデントに関連付けられることがあります。従来の「アラート1件ごとにチケットを起票する」運用をそのまま続けると、重複チケットが増えたり、インシデント全体の優先度を見誤ったりします。
見直すべき項目は、チケット起票条件、重大度の判断基準、一次対応者、エスカレーション先、クローズ条件です。特に、メール起点の攻撃から端末侵害、ID悪用までつながるケースでは、個別アラートよりインシデント全体の文脈を優先して判断する必要があります。
グローバル管理者で日常運用しない
初期設定のためにグローバル管理者を使う場面はありますが、そのまま日常的な監視や調査に使うのは避けるべきです。Microsoft Defender XDRでは、グローバルMicrosoft Entraロールとカスタムロールでアクセスを管理できます。カスタムロールを使えば、必要なデータ、タスク、機能へのアクセスをより細かく制御できます。(Microsoft Learn)
日常運用では、調査担当、承認担当、設定変更担当を分けると安全です。たとえば、一次監視担当は閲覧中心、SOCアナリストは調査とハンティング、セキュリティ管理者は設定変更と自動対応の承認、という形です。
サポートサービス未展開のまま「XDRが見えない」と判断しない
Microsoft Defender XDRは、導入済みサービスのシグナルを集約します。Defender for Endpointが未展開なら端末シグナルは不足し、Defender for Identityが未展開ならオンプレミスAD由来の検知は限定的になります。公式情報でも、限定的なデプロイでは可視性や修復範囲が影響を受けると説明されています。(Microsoft Learn)
「XDRを有効にしたのに検知が少ない」と感じる場合は、XDR自体の問題ではなく、シグナルを提供する各サービスの展開不足が原因であることがあります。
自動化と開発者向け連携を事前に検証する
開発者や自動化担当者は、既存のSIEM/SOAR連携、チケット連携、通知Bot、PowerShellスクリプト、KQLクエリ、カスタム検出ルールを確認してください。XDRの有効化により、調査の中心がインシデント単位に移ると、既存の「アラートID前提」の処理が運用に合わなくなることがあります。
確認すべき観点は次の通りです。
| 対象 | 確認ポイント |
|---|---|
| KQLクエリ | 使用テーブル、列名、期間、結果件数、権限不足時の挙動 |
| SIEM/SOAR | インシデントとアラートのどちらを主キーにするか |
| チケット連携 | 重複起票、重大度マッピング、クローズ同期 |
| 通知Bot | 通知対象をアラート単位からインシデント単位へ変えるか |
| 自動修復 | アクションセンターの承認フローと衝突しないか |
| 監査ログ | 誰が調査・承認・修復したか追跡できるか |
2026年6月のMicrosoft Defender XDR新機能では、高度なハンティング関連のスキーマ更新や、AIエージェント関連の検出・保護機能のプレビューも案内されています。特にAgentsInfoテーブルへの移行など、クエリやレポートを運用しているチームはスキーマ変更の影響を確認しておくと安全です。(Microsoft Learn)
有効化後に確認すべきチェックリスト
Microsoft Defender XDRを有効にした後は、画面が表示されることだけで完了にしないでください。最低限、次のチェックを行うと運用の抜け漏れを減らせます。
| 確認カテゴリ | チェック内容 |
|---|---|
| ポータル | インシデント、アラートキュー、アクションセンター、高度なハンティング、脅威分析が表示されるか |
| シグナル | Endpoint、Office 365、Identity、Cloud Appsのどこからデータが入っているか |
| 権限 | 閲覧、調査、修復、承認、設定変更の権限が役割に合っているか |
| 通知 | 既存のメール通知、Teams通知、SIEM通知と重複していないか |
| 対応フロー | 重大度ごとの一次対応、エスカレーション、クローズ基準が明確か |
| 自動化 | 既存のKQL、API連携、チケット連携が想定通り動くか |
| 監査 | 誰がどのアクションを実行したか追跡できるか |
| 教育 | SOC、ヘルプデスク、管理者が新しい画面と用語を理解しているか |
最初の運用期間では、インシデントの件数や重大度だけでなく、「本当に調査時間が短くなっているか」「不要な通知が増えていないか」「アクションセンターの承認待ちが滞留していないか」を確認してください。XDRは検知を増やすためだけの仕組みではなく、複数のシグナルを関連付けて、判断と対応を速くするための仕組みです。
導入を急いでよいケース、準備を優先すべきケース
Microsoft Defender XDRは、要件を満たすテナントであれば比較的スムーズに有効化できます。しかし、すべての組織が同じ速度で本番展開すべきとは限りません。
| 判断 | 該当するケース | 推奨アクション |
|---|---|---|
| 早めに有効化してよい | E5相当のライセンスがあり、EndpointやOffice 365保護が展開済み | 有効化後、インシデント運用とハンティングを優先して整備する |
| 準備してから有効化 | 権限設計、プロキシ、データ所在地、SOC手順が未整理 | 事前チェックリストを作り、管理者とSOCでレビューする |
| 段階展開が望ましい | グローバル拠点、複数テナント、SIEM/SOAR連携が複雑 | 代表テナントまたは限定部門で運用検証してから広げる |
| 先に個別サービスを整える | Defender for EndpointやDefender for Identityが未展開 | XDR有効化前後で、シグナル不足を補う展開計画を作る |
小規模な組織では、Microsoft 365 Business PremiumやMicrosoft Defender for Businessを使っている場合でも、まずはポータル上で見えるインシデントとアラートを整理するだけで効果があります。一方、大規模組織では、XDRの有効化をきっかけに、権限、監査、チケット連携、運用手順をまとめて見直すべきです。
まとめ：Microsoft Defender XDRは「有効化」より「運用設計」が重要
Microsoft Defender XDRを有効にする作業自体は、対象ライセンスと権限を満たし、Microsoft Defenderポータルからオンボードを開始できれば難しくありません。重要なのは、有効化後に何が見えるようになり、誰が調査し、誰が対応を承認し、既存のアラート運用や自動化がどう変わるかを事前に決めておくことです。
まずは、ライセンス、ロール、ネットワーク、データセンターの4点を確認してください。そのうえで、導入済みのDefenderサービスを棚卸しし、インシデント管理、アラートキュー、アクションセンター、高度なハンティングの動作を確認します。既存のSIEM/SOARやチケット連携を使っている場合は、アラート単位ではなくインシデント単位で運用を再設計することが、Microsoft Defender XDRを効果的に使う近道です。
コメント