Microsoft Defenderの「Incident Response with XDR and Integrated SIEM」で最初に押さえるべき結論は、Microsoft Defender XDRとMicrosoft Sentinelを別々に見る運用から、Defenderポータルを中心にインシデント、アラート、調査、ハンティング、SOARを統合して扱う運用へ移行するという点です。
これは単なる画面変更ではありません。インシデントの相関、コネクタ構成、Microsoft Sentinelのワークスペース、KQLクエリ、Automation rules、Playbook、チケット連携、SOCの一次対応フローまで影響します。特に、Microsoft SentinelをAzureポータルで運用している組織は、Defenderポータルへの移行計画を早めに作る必要があります。Microsoft Learnでは、Microsoft Sentinelは2027年3月31日以降Azureポータルでサポートされず、Defenderポータルでのみ利用可能になると案内されています。(Microsoft Learn)
本記事では、2026年5月31日時点で確認すべきMicrosoft公式情報を基に、Microsoft Defenderに関する「Incident Response with XDR and Integrated SIEM」の変更点、影響範囲、管理者・開発者が確認すべき設定、移行時の注意点を実務目線で整理します。
Microsoft Defenderの「Incident Response with XDR and Integrated SIEM」とは何か
「Incident Response with XDR and Integrated SIEM」は、Microsoft Defender XDRとMicrosoft Sentinelを組み合わせ、ゼロトラストの考え方に沿ってインシデント対応を高速化するための公式ソリューションガイドです。
Microsoft Defender XDRは、Microsoft 365環境のユーザー、ID、デバイス、アプリ、メールなどのシグナルを収集・相関・分析するXDRです。一方、Microsoft Sentinelは、SIEMとSOARの機能を持つクラウドネイティブなセキュリティ運用基盤です。Microsoftの公式ガイドでは、この2つを組み合わせることで、現代的な攻撃に対する検知、調査、対応を包括的に進められると説明されています。(Microsoft Learn)
実務上は、次のように理解すると分かりやすいです。
| 観点 | Microsoft Defender XDR | Microsoft Sentinel |
|---|---|---|
| 主な役割 | Microsoft 365やDefender製品群の脅威検知・相関・自動対応 | マルチクラウド、オンプレミス、サードパーティ製品を含むSIEM/SOAR |
| 強み | 攻撃ストーリー、アラート相関、端末隔離、Live response、自動調査 | 広範なログ収集、KQL分析、Playbook、Automation rules、長期保持 |
| 統合後の価値 | DefenderポータルでSIEMとXDRの情報を同じ文脈で扱える | Microsoft製品以外のログも含め、統合インシデント対応に活用できる |
ポイントは、XDRとSIEMのどちらか一方を選ぶ話ではないことです。XDRは攻撃の流れを素早く理解し、自動対応につなげるのが得意です。SIEMは広範なログを集約し、監査、相関分析、独自ルール、SOARに強みがあります。統合SIEM/XDRは、この2つを連携させて「見つける」「調べる」「止める」「再発防止する」までの流れを短くする考え方です。
何が変わるのか：Defenderポータル中心の統合運用へ進む
今回の実務上の大きな変化は、Microsoft SentinelとMicrosoft Defender XDRをDefenderポータルで統合して扱う流れが明確になっている点です。
Microsoft SentinelとDefender XDRの統合方法は大きく2つあります。1つ目は、Microsoft SentinelワークスペースをDefenderポータルにオンボードし、Defenderのインシデント、アラート、脆弱性、セキュリティデータと並べて表示する方法です。2つ目は、Azureポータル側でMicrosoft Defender XDRコネクタを有効化し、Defender XDRのインシデントや高度なハンティングイベントをMicrosoft Sentinelへ取り込む方法です。(Microsoft Learn)
| 項目 | これまでの運用で起きがちな状態 | 統合後に目指す状態 | 確認ポイント |
|---|---|---|---|
| インシデント管理 | SentinelとDefender XDRを別々に確認 | 統合インシデントキューで横断的に確認 | 担当者、状態、重大度、クローズ理由の同期 |
| アラート相関 | 製品別・ルール別に分散 | Defender XDRの相関エンジンで攻撃ストーリーを集約 | 既存のインシデント名依存の自動化を見直す |
| コネクタ | Defender製品ごとの個別コネクタが残る | Defender XDRコネクタを軸に集約 | 重複取り込みとスキーマ変更を確認 |
| ハンティング | Sentinel LogsとDefender Advanced huntingを別々に利用 | Defenderポータルで横断的に調査 | 既存KQL、関数、テーブル差分を確認 |
| 自動化 | Azureポータル前提のPlaybookやAutomation rules | Defenderポータル前提のインシデント対応へ調整 | トリガー条件、ProviderName、Description依存を見直す |
特に重要なのは、Microsoft SentinelをDefenderポータルにオンボードした場合、Defender XDRコネクタが自動的に構成され、Microsoft Defender for Endpoint、Microsoft Defender for Identity、Microsoft Defender for Office 365、Microsoft Defender for Cloud Apps、Microsoft Entra ID Protectionなどの個別アラートプロバイダー用コネクタが切断される点です。(Microsoft Learn)
これは「データが消える」という意味ではありません。重複したインシデント作成を避けるため、Defender XDRコネクタを中心に相関・同期する構成へ寄せるという意味です。ただし、既存のKQL、Workbook、Automation rules、外部チケット連携が個別コネクタのスキーマを前提にしている場合は、移行後に動作が変わる可能性があります。
影響を受ける対象者
この変更は、Microsoft Defenderの管理者だけでなく、SOC運用、Microsoft Sentinel管理者、SOAR開発者、KQLを使うセキュリティエンジニアにも関係します。
| 対象者 | 主な影響 | すぐ確認すべきこと |
|---|---|---|
| セキュリティ管理者 | Defenderポータルでの統合インシデント運用 | Sentinelワークスペースのオンボード状況、RBAC、ライセンス |
| SOCアナリスト | インシデントの見え方、相関、Attack story、Evidenceの確認方法 | 一次切り分け手順、重大度判断、コメント運用 |
| Microsoft Sentinel管理者 | コネクタ、分析ルール、Automation rules、Playbookの挙動 | Defender XDRコネクタ、重複コネクタ、Fusion、インシデント作成ルール |
| 開発者・自動化担当 | API、KQL、外部チケット連携の変更 | Microsoft Graph Security API、SecurityInsights API、フィールド差分 |
| コンプライアンス担当 | ログ保持、課金、データ保存、CMKの扱い | Advanced huntingイベントの取り込み範囲、保持期間、データポリシー |
Microsoftの移行ガイドでは、Defenderポータルへの移行後もLog Analyticsを使ったデータ保存、検索、相関の基本的なパイプラインは維持される一方で、コネクタ、スキーマ、インシデント相関、Automation rulesには注意が必要だと説明されています。(Microsoft Learn)
管理者が最初に確認すべき設定
Microsoft SentinelワークスペースがDefenderポータルにオンボードされているか
最初に確認するのは、Microsoft SentinelワークスペースがDefenderポータルに接続済みかどうかです。
Defenderポータルでは、System > Settings > Microsoft Sentinel > Workspacesからワークスペース接続を確認できます。単一ワークスペースの場合は分かりやすいですが、複数ワークスペースを持つ組織では、どれをプライマリワークスペースにするかが重要です。
Microsoft公式ドキュメントでは、Defenderポータルは1つのプライマリワークスペースと複数のセカンダリワークスペースを扱えると説明されています。Defender XDRのアラートやインシデントと相関されるのはプライマリワークスペースであり、セカンダリワークスペースはDefender XDRのインシデントやアラートとは同期されません。(Microsoft Learn)
実務では、グローバルSOCや全社SOCで使うワークスペースをプライマリにするのが基本です。部門別、国別、子会社別のワークスペースをセカンダリとして扱う場合は、「そのワークスペースのインシデントはDefender XDRと相関されない」という前提を運用手順に明記しておきましょう。
Defender XDRコネクタと個別コネクタの重複を確認する
AzureポータルでMicrosoft Sentinelを使い続ける場合は、Microsoft Defender XDRコネクタを有効化して、Defender XDRのインシデント、アラート、高度なハンティングイベントをMicrosoft Sentinelへストリーミングします。コネクタの構成には、インシデントとアラート、エンティティ、イベントの3要素があります。(Microsoft Learn)
有効化後は、Microsoft SentinelのLogsで次のようなクエリを実行し、Defender XDR由来のインシデントが入っているか確認します。
SecurityIncident
| where ProviderName == "Microsoft XDR"
| summarize Incidents = count() by bin(TimeGenerated, 1d), Status, Severity
| order by TimeGenerated desc公式手順でも、SecurityIncidentテーブルでProviderName == "Microsoft XDR"を確認する方法が紹介されています。(Microsoft Learn)
注意したいのは、Defender XDRコネクタを有効化すると、以前から接続されていたMicrosoft Defenderコンポーネントの個別コネクタがバックグラウンドで切断されることです。画面上は接続済みに見える場合があっても、データが流れないことがあるため、コネクタ画面だけでなく実際のテーブル取り込み状況で確認してください。(Microsoft Learn)
Microsoft Defender for Cloudの扱いを確認する
Microsoft Defender for Cloudを使っている組織は、Defender XDR統合時に特に注意が必要です。
Microsoftの公式情報では、Defender XDRコネクタはMicrosoft Defender for Cloudのインシデントも取り込みますが、これらのインシデントのアラートやエンティティを同期するには、Microsoft Sentinel側でDefender for Cloudコネクタを有効にする必要があります。有効化していない場合、Defender for Cloudのインシデントが空に見える可能性があります。(Microsoft Learn)
また、テナントベースのDefender for Cloudコネクタとレガシーのサブスクリプションベースコネクタを併用すると、重複や想定外の同期が起こりやすくなります。移行前に「どのサブスクリプションのクラウドアラートをどのワークスペースで扱うか」を棚卸ししておきましょう。
移行・展開時に失敗しやすいポイント
インシデント作成ルールが無効化される前提で見直す
Defender XDRとMicrosoft Sentinelを統合すると、重複インシデントを避けるため、Defender XDR統合製品に対するMicrosoft SentinelのMicrosoft incident creation rulesはオフになります。また、DefenderポータルではMicrosoft incident creation rules自体がサポートされず、Defenderポータル側のインシデント作成エンジンが使われます。(Microsoft Learn)
影響が大きいのは、次のような運用です。
| 既存運用 | 起こり得る問題 | 見直し方 |
|---|---|---|
| インシデント名を条件にAutomation rulesを実行 | Defender XDRの相関エンジンによりインシデント名が変わる | タイトルではなくタグ、重大度、分析ルール名、エンティティを条件にする |
| Sentinel側のincident creation rulesでアラートを絞り込み | ルールが無効化され、想定より多いインシデントが出る | DefenderポータルのAlert tuningやAutomation rulesで抑制する |
| Fusionの相関を前提にSOPを作成 | Defender XDRの相関エンジンに置き換わる | Attack story、Incident graph、Evidenceベースの手順に更新する |
特に「インシデントタイトルがAならServiceNowのBキューへ送る」といった自動化は壊れやすいです。移行後は、タイトルではなくタグや分析ルール名、重大度、MITRE ATT&CK、エンティティ種別など、変更されにくい条件を使いましょう。
Automation rulesとPlaybookのトリガー条件を確認する
Microsoft SentinelのAutomation rulesとPlaybookは移行後も重要ですが、Defenderポータルでは一部の挙動が変わります。
Microsoftの移行ガイドでは、Defenderポータル移行後、すべてのインシデントのProviderNameがMicrosoft XDRになり、SecurityIncidentテーブルからDescriptionフィールドがなくなること、インシデント説明に依存したAutomation rulesや外部チケット連携に影響が出ることが説明されています。(Microsoft Learn)
また、Defenderポータルで作成・更新されたインシデントがMicrosoft Sentinelに同期されてからAutomation rulesが動くため、Automation rulesの実行までに遅延が発生する場合があります。公式情報では、状況によって最大10分程度のタイムラグが説明されています。(Microsoft Learn)
移行前に、少なくとも次の条件を含むAutomation rulesを洗い出してください。
- Incident providerを条件にしている
- インシデントタイトルを条件にしている
- Descriptionフィールドを参照している
- 外部チケットシステムにインシデントURLや説明を渡している
- Microsoft 365 Defender、Azure Sentinelなど旧名称を条件にしている
- Playbookをアラートやエンティティに対して手動実行する運用がある
この棚卸しをしないままオンボードすると、「インシデントは見えているのにチケットが起票されない」「自動クローズが走らない」「想定外のインシデントまでPlaybookが実行される」といった問題が起こりやすくなります。
KQLクエリとスキーマ差分を確認する
Defender XDRコネクタを使うと、個別コネクタ時代とアラートのスキーマが変わる可能性があります。Microsoft公式手順でも、スタンドアロンコネクタからXDRコネクタへ置き換えるとアラートスキーマが変わり、既存クエリへ影響する可能性があると説明されています。(Microsoft Learn)
特に見直すべきなのは、次のようなKQLです。
SecurityAlertやSecurityIncidentの特定フィールドに依存しているクエリ- Defender製品別のコネクタ名やProductNameを条件にしているクエリ
IdentityInfoなど、DefenderポータルとLog Analyticsで扱いが変わる可能性があるテーブル- Workbook、Analytics rules、Hunting queries、Watchlist結合クエリ
- API連携でincidentUrlやproviderNameを参照している処理
Advanced huntingでアラートの発生元を確認する場合は、AlertInfoテーブルのServiceSourceやDetectionSourceを使うと、どのサービスや検知ソースから来たアラートかを把握しやすくなります。AlertInfoは、Microsoft Defender for Endpoint、Microsoft Defender for Office 365、Microsoft Defender for Cloud Apps、Microsoft Defender for Identityなどのアラート情報を含む高度なハンティング用テーブルです。(Microsoft Learn)
AlertInfo
| summarize Alerts = count() by ServiceSource, DetectionSource, Severity
| order by Alerts desc移行前後でこのような集計を比較し、アラート数、重大度、検知元の分布が大きく変わっていないか確認すると、コネクタや相関の問題を早期に見つけやすくなります。
コストとログ保持の確認ポイント
Defender XDRとMicrosoft Sentinelの統合では、取り込み対象を広げすぎるとコストに影響します。
Microsoft公式情報では、Defender XDRのアラートとインシデント、つまりSecurityAlertやSecurityIncidentに入る項目はMicrosoft Sentinelへ無料で取り込まれ、同期されると説明されています。一方で、DeviceInfo、DeviceFileEvents、EmailEventsなど、個別のDefenderコンポーネントからの高度なハンティングテーブルを取り込む場合は課金対象です。(Microsoft Learn)
| データ種別 | 取り込みの考え方 | 注意点 |
|---|---|---|
| Defender XDRのインシデント・アラート | Sentinelへ同期しても追加課金なし | 重複インシデントを避ける構成にする |
| Advanced huntingイベント | 必要なテーブルを選んで取り込む | 取り込み量に応じてコスト増の可能性 |
| 長期保持したいDefenderデータ | SentinelやLog Analytics側で保持設計 | 30日を超える調査要件があるか確認 |
| Workbookや監査用データ | 必要なテーブルだけ保持 | 「念のため全部取り込む」は避ける |
DefenderポータルのAdvanced huntingでは、Defender XDRの生ログを一定期間ハンティングできますが、長期保持やSentinel側のWorkbook、相関分析に使う場合は、どのテーブルをMicrosoft Sentinelへ取り込むかを設計する必要があります。公式ドキュメントでも、Advanced huntingイベントをMicrosoft Sentinelへストリーミングすると、Defender XDR標準の30日を超えた保持をワークスペースやテーブル単位の保持設定で実現できると説明されています。(Microsoft Learn)
コスト最適化のコツは、インシデント対応に直結するテーブルから優先することです。例えば、端末侵害調査が多い組織ならDeviceProcessEventsやDeviceNetworkEvents、メール起点の攻撃が多い組織ならEmailEventsやUrlClickEventsを優先します。すべてのテーブルを最初から取り込むより、過去3か月のインシデントで実際に使ったテーブルを基準に選ぶ方が失敗しにくいです。
ゼロトラスト運用で見るべき実務シナリオ
「Incident Response with XDR and Integrated SIEM」は、ゼロトラストの3原則である「明示的に検証する」「最小権限を使う」「侵害を前提とする」に沿って整理されています。Microsoft公式ガイドでは、Microsoft Sentinelが環境全体からデータを収集・分析し、Defender XDRがユーザー、ID、デバイス、アプリ、メールを横断した検知と対応を担うと説明されています。(Microsoft Learn)
実務では、次のようなシナリオで効果が出やすくなります。
フィッシングから横展開までを1つの攻撃ストーリーとして見る
典型的な攻撃では、メールから侵入し、添付ファイル実行、マルウェア感染、資格情報窃取、Microsoft 365アプリやSharePointへの横展開、機密ファイルの大量ダウンロードへ進みます。Microsoftの関連ガイドでも、このような攻撃ステップに対して、Defender for Office 365、Defender for Endpoint、Microsoft Entra ID Protection、Defender for Cloud Appsがそれぞれ検知・防御を担う例が示されています。(Microsoft Learn)
統合前は、メール、端末、ID、クラウドアプリのアラートが別々に見え、SOCアナリストが手動で関連付ける必要がありました。統合後は、Defender XDRの相関により、複数のアラートを1つのインシデントとして扱いやすくなります。
一次対応の判断を「アラート単位」から「インシデント単位」に変える
統合SIEM/XDR運用では、アラート1件ごとに処理するのではなく、攻撃ストーリー全体を見て優先度を決めます。
例えば、単独の不審なサインインだけなら監視継続でよい場合があります。しかし、同じユーザーに対してメール添付ファイル実行、端末上の不審プロセス、SharePoint大量ダウンロードが続いていれば、アカウント無効化、端末隔離、セッション失効、ファイル共有停止などをまとめて検討すべきです。
Defenderポータルでは、インシデントの範囲、資産タイムライン、保留中の自動修復、Live response、Evidence and Responseなどを確認しながら対応できます。Microsoft公式のインシデント対応ガイドでも、Defenderポータルでトリアージ、調査、解決を行い、Microsoft Sentinelの領域でSOAR Playbookや証跡記録を活用する流れが示されています。(Microsoft Learn)
移行前に実施したいチェックリスト
実際にDefenderポータル中心の運用へ移る前に、次の順番で確認すると安全です。
| フェーズ | 作業 | 確認内容 |
|---|---|---|
| 棚卸し | 現在のSentinel構成を洗い出す | ワークスペース、コネクタ、Analytics rules、Workbook、Automation rules、Playbook、API連携 |
| 設計 | プライマリワークスペースを決める | 全社SOCで見るべきワークスペースか、部門別に分けるか |
| 権限 | RBACとUnified RBACを確認 | 最小権限でオンボード、調査、対応、サポート依頼ができるか |
| コネクタ | Defender XDRコネクタを確認 | 個別Defenderコネクタとの重複、Defender for Cloud連携、データ流入 |
| 自動化 | Automation rulesとPlaybookを検証 | タイトル、Description、ProviderName、Incident provider依存がないか |
| KQL | クエリとテーブルを検証 | スキーマ差分、ProductName、ServiceSource、DetectionSourceの扱い |
| コスト | 取り込みテーブルを選定 | Advanced huntingイベントの取り込み量、保持期間、課金影響 |
| 運用 | SOC手順を更新 | トリアージ基準、クローズ理由、タグ、チケット連携、教育 |
特に、本番移行前にテスト用インシデントを作成し、次の一連の流れを確認してください。
- Defender XDRでインシデントが生成される
- Microsoft Sentinel側に同期される
- 担当者、状態、重大度、コメントが期待どおり反映される
- Automation rulesが想定条件で動く
- Playbookが外部システムへ正しい内容を渡す
- クローズ理由が両ポータルでずれない
- WorkbookやKQLで必要な集計ができる
この検証をせずに全社展開すると、移行後のSOCで「見えるが動かない」「自動化が走らない」「チケットの情報が足りない」という問題が起こりやすくなります。
開発者・自動化担当が確認すべきAPIの注意点
Microsoft SentinelのAPIを使ってインシデントを処理している場合は、Defenderポータル統合後のAPI設計も見直しが必要です。
Microsoftの移行ガイドでは、Microsoft Sentinel APIはAnalytics rulesやAutomation rulesなどSentinelリソースに対する操作を引き続きサポートしますが、統合インシデントやアラートを扱う場合はMicrosoft Graph REST APIの利用が推奨されています。また、DefenderポータルではproviderNameがMicrosoft XDRになるなど、Azureポータル時代とレスポンスボディの前提が変わる可能性があります。(Microsoft Learn)
外部チケットシステム、社内ポータル、SOAR基盤、独自ダッシュボードを連携している場合は、次の項目を重点的に見直してください。
- インシデントURLとして
incidentUrlだけを使っていないか - Defenderポータル側のリンクである
providerIncidentUrlを扱えるか providerName = Azure Sentinelを前提にしていないかalertProductNamesを取得するためにアラート展開が必要かserviceSourceやdetectionSourceを保存・表示できるか- インシデント名変更やマージに耐えられる設計か
開発者視点では、移行後の最大のポイントは「インシデントIDやタイトルが固定的に扱える」という前提を捨てることです。Defender XDRの相関エンジンがアラートをマージし、インシデント名や構成アラートが変わる可能性があります。外部システム側では、インシデントの状態変化、タグ、重大度、関連エンティティ、ソース製品を柔軟に扱える設計にしておきましょう。
まとめ：まずはワークスペース、コネクタ、自動化の3点を確認する
Microsoft Defenderの「Incident Response with XDR and Integrated SIEM」は、Microsoft SentinelとDefender XDRを統合し、ゼロトラストに基づくインシデント対応をより速く、正確に進めるための運用モデルです。
まず着手すべきなのは、次の3点です。
- Microsoft SentinelワークスペースがDefenderポータルにオンボードされているか
- Defender XDRコネクタと個別Defenderコネクタが重複・競合していないか
- Automation rules、Playbook、KQL、API連携が統合後のスキーマやProviderNameに対応しているか
そのうえで、SOCのトリアージ手順を「製品別アラート処理」から「統合インシデント対応」へ更新します。移行作業はポータルを切り替えるだけでは終わりません。インシデント相関、コスト、ログ保持、自動化、チケット連携、分析ルールまで含めて検証することで、Microsoft DefenderとMicrosoft Sentinelの統合メリットを安全に引き出せます。
コメント