Microsoft Defender XDRからMicrosoft Sentinelへデータをストリーミングする2026年4月更新ポイント

Microsoft Defender XDRのインシデント、アラート、Advanced HuntingイベントをMicrosoft Sentinelへ連携している組織は、2026年4月更新を「単なる手順書の更新」と見ないほうがよいです。結論から言うと、今回確認すべきポイントは、Azure portalでの手動コネクタ設定よりも、Microsoft Defender portalへの移行、重複インシデントの防止、既存クエリや分析ルールへの影響確認です。

Microsoft公式ドキュメント「Stream data from Microsoft Defender XDR to Microsoft Sentinel in the Azure portal」は2026年4月22日に更新され、Defender XDR connectorによるMicrosoft Sentinel連携の前提、設定手順、検証方法、注意点が整理されています。特にsecurity admins、identity teams、compliance teamsは、Defender XDR connectorを有効化する前後で「誰が権限を持つか」「どのデータが流れるか」「既存の検知・監査に影響が出ないか」を確認する必要があります。(Microsoft Learn)

Microsoft Defenderの最新動向: Stream data from Microsoft Defender XDR to Microsoft Sentinel in the Azure portalで何が変わったか

今回の更新で最も重要なのは、Microsoft Defender XDRとMicrosoft Sentinelの連携が、Azure portal中心の手動設定から、Microsoft Defender portalを中心とした統合セキュリティ運用へ移りつつある点です。

公式ドキュメントでは、Defender XDR connectorがMicrosoft Defender XDRのインシデント、アラート、Advanced HuntingイベントをMicrosoft Sentinelへストリーミングし、両ポータル間でインシデントを同期できると説明されています。一方で、Microsoft SentinelをDefender portalへオンボードしている場合、Defender XDR connectorは自動的に有効化されるため、Azure portal側での手動設定は不要とされています。(Microsoft Learn)

つまり、今後の実務では次のように考えるべきです。

利用状況	取るべき対応
すでにMicrosoft SentinelをDefender portalへオンボード済み	Azure portalでの手動接続作業より、接続状態・データ流入・権限設計を確認する
Azure portalでMicrosoft Sentinelを運用中	Defender XDR connectorの設定内容を確認しつつ、Defender portal移行計画を立てる
これからSentinel連携を設計する	Azure portal前提ではなく、Defender portalでの統合運用を前提に設計する
既存のDefender個別コネクタを利用中	XDR connectorへの置き換えでスキーマやクエリに影響が出ないか確認する

特に見落としやすいのは、「Azure portalで動いているから問題ない」と判断してしまうことです。Microsoftは、2027年3月31日以降、Microsoft SentinelはAzure portalでサポートされなくなり、Microsoft Defender portalでのみ利用可能になると案内しています。(Microsoft Learn)

2026年4月更新で実務上押さえるべきポイント

2026年4月時点での確認ポイントは、大きく5つあります。

Defender XDR connectorはインシデント、アラート、イベントをまとめて扱う

Defender XDR connectorは、Microsoft Defender XDRのインシデント、アラート、Advanced HuntingイベントをMicrosoft Sentinelへ連携します。単なるログ転送ではなく、Microsoft Defender製品群の情報をSentinelのインシデント管理やハンティングに活用するための入口です。(Microsoft Learn)

実務では、次の3種類を分けて考えると整理しやすくなります。

連携対象	主な用途	注意点
Incidents and alerts	SOCの一次対応、トリアージ、インシデント管理	重複インシデントを避ける設定が重要
Entities	ユーザー、デバイス、ID情報を含む調査	Defender for IdentityやUEBA設定との関係を確認
Events	Advanced Huntingテーブルを使った詳細調査	取り込むテーブルが増えるほどデータ量とコストに注意

特にグローバル企業では、SOC、ID管理チーム、コンプライアンス部門が同じデータを異なる目的で見ることがあります。インシデント対応のために必要なデータと、監査・証跡として必要なデータを分けて設計することが重要です。

Defender portalへオンボード済みなら手動設定は不要

公式ドキュメントでは、Microsoft SentinelをDefender portalへオンボードするとDefender XDR connectorが自動的に有効化されるため、Azure portalで説明されている手動設定は不要とされています。(Microsoft Learn)

これは、運用担当者にとって大きな変更点です。従来のように「Azure portalでデータコネクタを探して接続する」だけでなく、まず自社のSentinelワークスペースがDefender portalへオンボードされているかを確認する必要があります。

確認すべき順序は次のとおりです。

確認項目	確認する理由
SentinelワークスペースがDefender portalへ接続済みか	手動設定が必要かどうかを判断するため
プライマリワークスペースがどれか	Defender XDRデータの集約先を把握するため
既存の個別Defenderコネクタが残っていないか	重複や無効な接続表示を避けるため
SOCが使うポータルが統一されているか	インシデント対応の手順混乱を防ぐため

新規導入の場合は、最初からDefender portal中心の運用に寄せたほうが、後から移行作業を減らせます。

Azure portal利用組織は2027年3月31日を移行期限として見る

Microsoftは、2027年3月31日以降、Microsoft SentinelはAzure portalでサポートされず、Microsoft Defender portalでのみ利用可能になると明記しています。(Microsoft Learn)

このため、2026年4月時点でAzure portal中心にSentinelを運用している組織は、Defender XDR connectorの設定確認だけでは不十分です。2026年度内に、次のような移行準備を進めるべきです。

時期の目安	実施内容
すぐに実施	現在のSentinelワークスペース、接続済みコネクタ、分析ルール、ブック、プレイブックを棚卸しする
移行前	Defender portalでの権限、プライマリワークスペース、SOC手順を確認する
検証期間	既存KQL、分析ルール、ワークブック、インシデント運用に差分が出ないか確認する
本番移行	インシデント対応フロー、監査証跡、通知先、運用手順書を更新する
移行後	データ流入、重複、検知漏れ、権限過多を定期的にレビューする

特にcompliance teamsは、ポータル移行に伴ってデータの保存、処理、保持、共有のポリシーがどう扱われるかを確認しておく必要があります。Microsoftの移行ドキュメントでは、Azure portal利用時とDefender portal利用時で適用されるデータ保存・処理・保持・共有のポリシーが異なる点が説明されています。(Microsoft Learn)

設定前に確認すべき前提条件

Defender XDR connectorを設定する前に、ライセンス、権限、ワークスペース、テナント、関連ソリューションを確認します。公式ドキュメントでは、Microsoft Defender XDRの有効なライセンス、対象テナントでのSecurity Administratorロールまたは同等の権限、Microsoft Sentinelワークスペースへの読み取り・書き込み権限などが前提条件として示されています。(Microsoft Learn)

実務では、次の表を使って事前確認すると抜け漏れを減らせます。

確認項目	主な担当	チェック内容
Microsoft Defender XDRライセンス	security admins	対象テナントでDefender XDRを利用できるか
Security Administrator権限	security admins / identity teams	ログをストリーミングするテナントで必要権限があるか
Sentinelワークスペース権限	security admins	読み取り・書き込み権限があるか
Microsoft Entra tenant	identity teams	設定変更アカウントとSentinelワークスペースが同じテナントに紐づくか
Content HubのMicrosoft Defender XDR solution	security admins	Azure portal側で必要なソリューションがインストール済みか
Defender for Identity環境	identity teams	オンプレミスAD同期に必要なセンサーとオンボードが済んでいるか

権限確認では、単に「管理者アカウントを持っているか」ではなく、どのテナントに対する権限かを確認してください。グローバル企業やMSSP運用では、テナントやワークスペースの境界を誤ると、接続画面に対象が表示されない、データが想定外のワークスペースに流れる、調査担当者がインシデントを開けないといった問題が起こります。

接続設定で見るべき3つの構成

Defender XDR connectorの構成は、公式ドキュメント上で「Connect incidents and alerts」「Connect entities」「Connect events」の3つに分かれています。(Microsoft Learn)

Connect incidents and alerts：重複インシデントを防ぐ

最初に確認すべきなのは、Microsoft Defender XDRのインシデントとアラートをMicrosoft Sentinelへ取り込む設定です。

公式手順では、重複インシデントを避けるために「Turn off all Microsoft incident creation rules for these products. Recommended」というチェックボックスを有効にすることが推奨されています。このチェックボックスは、Microsoft Defender XDR connectorが接続済みになると表示されなくなります。(Microsoft Learn)

ここで失敗しやすいのは、既存のMicrosoft Defender for Endpoint、Defender for Office 365、Defender for Identityなどの個別コネクタによるインシデント生成ルールを残したまま、XDR connectorも有効化してしまうケースです。

結果として、SOCのキューに似た内容のインシデントが複数並び、担当者が「どれを正として処理すべきか」を判断しにくくなります。アラートの重複は、単なる画面上のノイズではありません。対応遅延、誤ったクローズ、監査時の説明負荷につながります。

Connect entities：オンプレミスADのユーザー情報をSentinelへ活用する

Connect entitiesでは、Microsoft Defender for Identityを利用してオンプレミスActive DirectoryのユーザーエンティティをMicrosoft Sentinelへ同期します。公式手順では、UEBA設定ページへ移動し、Entity behavior configurationでUEBAを有効化し、Active Directoryのチェックボックスを選択して適用する流れが示されています。(Microsoft Learn)

identity teamsにとって重要なのは、インシデント調査時に「このユーザーは誰か」「どの端末や認証イベントと関係するか」をすばやく追える状態にすることです。

たとえば、アカウント侵害の疑いがある場合、メール、端末、クラウドアプリ、オンプレミスADの認証イベントが分断されていると、調査担当者は複数画面を行き来することになります。エンティティ連携を適切に構成しておけば、ユーザーを軸に調査を進めやすくなります。

ただし、オンプレミスAD情報を扱う場合は、対象ドメイン、センサー配置、監査ログの取り扱い、プライバシー要件も確認してください。グローバル拠点でデータ所在地や監査要件が異なる場合、compliance teamsとの事前確認が不可欠です。

Connect events：必要なAdvanced Huntingテーブルだけを選ぶ

Connect eventsでは、Defender製品群のAdvanced HuntingテーブルをMicrosoft Sentinelへ取り込めます。対象には、Defender for Endpoint、Defender for Office 365、Defender for Identity、Defender for Cloud Apps、Defender alertsに関連するテーブルが含まれます。(Microsoft Learn)

主なテーブルの例は次のとおりです。

領域	代表的なテーブル	活用例
Endpoint	DeviceProcessEvents、DeviceNetworkEvents、DeviceLogonEvents	不審プロセス、外部通信、端末ログオンの調査
Office 365	EmailEvents、EmailAttachmentInfo、UrlClickEvents	フィッシング、添付ファイル、URLクリックの調査
Identity	IdentityLogonEvents、IdentityDirectoryEvents、IdentityQueryEvents	認証異常、AD変更、ディレクトリ照会の調査
Cloud Apps	CloudAppEvents	SaaS利用状況、不審なクラウドアプリ操作の調査
Alerts	AlertInfo、AlertEvidence	アラートの重要度、関連エンティティの確認

ここでの判断基準は、「全部入れる」ではありません。Advanced Huntingイベントは調査力を高める一方で、データ量、コスト、クエリ設計、保持期間に影響します。

たとえば、SOCが端末侵害の初動対応を重視しているなら、DeviceProcessEventsやDeviceNetworkEventsの優先度は高くなります。一方、フィッシング対応を強化したい組織では、EmailEventsやUrlClickEventsの価値が高くなります。ID侵害を重点監視するなら、IdentityLogonEventsやIdentityDirectoryEventsを優先的に検討すべきです。

既存コネクタからXDR connectorへ切り替える時の注意点

Defender XDR connectorを有効化すると、以前接続されていたMicrosoft Defenderコンポーネントの個別コネクタはバックグラウンドで自動的に切断されます。ただし、画面上は接続済みに見え続ける場合があり、その場合でもデータは流れないと説明されています。(Microsoft Learn)

この仕様は、現場で混乱しやすいポイントです。

「コネクタ画面では接続済みに見えるのに、なぜデータが来ないのか」という問い合わせが発生しやすいため、移行時には以下を運用メモに残しておくとよいでしょう。

よくある誤解	正しい見方
個別コネクタが接続済みに見えるのでデータも流れている	XDR connector有効化後は、個別コネクタ経由ではデータが流れない場合がある
既存のKQLはそのまま使える	XDR connectorではアラートスキーマが変わる可能性がある
重複しても後で整理すればよい	インシデント対応の優先順位や監査証跡に影響する
Defender portalへ移れば設定確認は不要	権限、ワークスペース、データ流入の確認は必要

Microsoftのスキーマ差分ドキュメントでは、スタンドアロンコネクタとXDR connectorではフィールドマッピング、派生フィールド、スキーマ構造、アラート取り込みに違いがあり、既存クエリ、分析ルール、ワークブックに影響する可能性があると説明されています。(Microsoft Learn)

特に、既存のKQLでCompromisedEntity、ExtendedProperties、特定のアラート重要度、製品別のフィールドを参照している場合は注意が必要です。検知ルールがエラーにならなくても、条件に一致しなくなり、結果として検知漏れが起きる可能性があります。

データ流入を確認するKQL

設定後は、画面上の接続状態だけでなく、KQLで実際にデータが入っているかを確認します。

Microsoft公式手順では、Microsoft Defender XDRのインシデントデータ収集を確認するため、Microsoft Sentinel Logsで次のクエリを実行する例が示されています。(Microsoft Learn)

SecurityIncident
| where ProviderName == "Microsoft XDR"

このクエリで結果が返れば、Microsoft XDR由来のインシデントがSentinel側に入っていることを確認できます。

ただし、本番運用では「結果が1件でも返ればOK」では不十分です。次の観点でも確認してください。

確認観点	見るべき内容
件数	想定されるインシデント数と大きく乖離していないか
時系列	有効化後の時間帯から継続的に入っているか
重要度	HighやMediumなど、必要な重大度が入っているか
担当者・状態	双方向同期後に状態や所有者が想定どおり扱われるか
重複	既存ルールや個別コネクタ由来の重複がないか

イベント量を確認する場合は、対象テーブルを指定して日次件数を確認します。たとえばDeviceEventsを確認する場合は、公式例のように特定テーブルの件数を時系列で可視化できます。(Microsoft Learn)

let Now = now();
(range TimeGenerated from ago(14d) to Now-1d step 1d
| extend Count = 0
| union isfuzzy=true (
    DeviceEvents
    | summarize Count = count() by bin_at(TimeGenerated, 1d, Now)
)
| summarize Count=max(Count) by bin_at(TimeGenerated, 1d, Now)
| sort by TimeGenerated
| project Value = iff(isnull(Count), 0, Count), Time = TimeGenerated, Legend = "Events")
| render timechart

このクエリは、DeviceEventsの部分をEmailEvents、IdentityLogonEvents、CloudAppEventsなどに置き換えて使えます。接続直後だけでなく、数日単位でデータ量が安定しているかを見ると、ネットワーク、ライセンス、コネクタ、対象テーブル選択の問題に気づきやすくなります。

security admins、identity teams、compliance teams別の確認ポイント

同じDefender XDR connectorでも、担当チームによって見るべきポイントは異なります。

security adminsが確認すべきこと

security adminsは、インシデント対応と検知運用に直結する項目を優先します。

優先度	確認項目
高	Defender XDR connectorが有効か
高	重複インシデント生成ルールが無効化されているか
高	既存の分析ルールやKQLがXDR connectorのスキーマに対応しているか
中	必要なAdvanced Huntingテーブルが選択されているか
中	SOC手順書がDefender portal前提に更新されているか

特に既存ルールの確認では、クエリが動くかどうかだけでなく、期待した件数が返るかまで確認してください。スキーマ変更による検知漏れは、エラーとして見えないことがあります。

identity teamsが確認すべきこと

identity teamsは、Microsoft Entra ID、オンプレミスActive Directory、Defender for Identity、UEBAの関係を確認します。

優先度	確認項目
高	設定変更アカウントとSentinelワークスペースが同一Microsoft Entra tenantに紐づくか
高	Defender for Identityがオンボード済みか
高	必要なDefender for Identity sensorが配置されているか
中	Active Directoryエンティティ連携が有効か
中	ID関連イベントの保持・利用目的が社内ポリシーと整合しているか

ID情報は調査に不可欠ですが、扱いを誤ると権限過多やプライバシー上の懸念につながります。特に多国籍企業では、地域ごとのデータ保護要件も確認しておくべきです。

compliance teamsが確認すべきこと

compliance teamsは、データの保存、保持、共有、監査証跡を中心に確認します。

優先度	確認項目
高	Azure portalからDefender portalへの移行で適用ポリシーが変わる点を把握しているか
高	監査対象データがどのワークスペースに保存されるか
高	インシデントの状態変更、所有者変更、クローズ理由が監査できるか
中	データ保持期間と社内規程が一致しているか
中	国・地域ごとのデータ所在地要件に抵触しないか

Defender portal移行は、SOCの画面が変わるだけではありません。監査ログの説明、証跡取得手順、データ管理ポリシーにも影響する可能性があります。

グローバル組織での設計ポイント

グローバル読者向けに考える場合、Defender XDR connectorの導入では「単一テナントの設定手順」だけでなく、複数テナント、複数ワークスペース、MSSP運用、地域ごとのコンプライアンスを考慮する必要があります。

MicrosoftのDefender portalオンボード関連ドキュメントでは、Defender portalが単一のMicrosoft Entra tenant、プライマリワークスペース、複数のセカンダリワークスペースをサポートすることが説明されています。(Microsoft Learn)

実務での設計ポイントは次のとおりです。

設計テーマ	判断基準
プライマリワークスペース	どの地域・組織単位のSOCが中心になるか
セカンダリワークスペース	国別、事業部別、MSSP別の分離が必要か
権限設計	グローバルSOC、地域SOC、監査担当の権限をどう分けるか
データ保持	セキュリティ調査に必要な期間と法規制上の保持期間をどう両立するか
運用手順	インシデントの所有者、エスカレーション、クローズ理由をどこで統一するか

グローバル環境では、すべてのログを一箇所に集めることが常に正解とは限りません。調査効率、データ所在地、権限分離、コストのバランスを取る必要があります。

導入・更新時に失敗しやすいポイント

Defender XDR connectorの設定自体は難しく見えません。しかし、運用に入ると次のような失敗が起こりやすくなります。

失敗例	影響	対策
個別コネクタとXDR connectorの関係を理解せず有効化する	データが流れていないのに接続済みと誤認する	有効化後にKQLで実データを確認する
重複インシデント生成を止めない	SOCキューがノイズで膨らむ	接続前にMicrosoft incident creation rulesを確認する
既存KQLのスキーマ差分を確認しない	検知漏れやワークブック不具合が起こる	代表的な分析ルールとワークブックを事前検証する
全イベントテーブルを無計画に取り込む	コスト増、クエリ負荷増	調査シナリオ別に必要テーブルを選ぶ
Defender portal移行を後回しにする	2027年の期限前に移行が集中する	2026年中に検証環境で移行手順を確認する
compliance teamsを後から巻き込む	データ保持・監査要件の手戻りが出る	設計段階から保存場所・保持期間を確認する

特に注意したいのは、接続が成功したことと、運用が成功したことは別という点です。コネクタが有効でも、SOCが使うクエリが壊れていたり、監査チームが必要な証跡を取得できなかったりすれば、実務上は失敗です。

今すぐ実施すべきチェックリスト

2026年4月更新を踏まえると、Microsoft Defender XDRとMicrosoft Sentinelを利用している組織は、次の順に確認するのが現実的です。

チェック	実施内容
現状把握	SentinelをAzure portal中心で使っているか、Defender portalへオンボード済みかを確認する
コネクタ確認	Defender XDR connectorの有効状態、個別Defenderコネクタの扱いを確認する
データ確認	SecurityIncident | where ProviderName == "Microsoft XDR"で流入を確認する
ルール確認	既存のKQL、分析ルール、ワークブックがXDR connectorのスキーマに対応しているか確認する
権限確認	Security Administrator、Sentinel権限、Microsoft Entra tenantの整合性を確認する
コスト確認	Advanced Huntingイベントの取り込み対象テーブルを必要最小限にする
移行計画	2027年3月31日を見据え、Defender portal移行スケジュールを作る
監査確認	データ保持、処理、共有、証跡取得の要件をcompliance teamsと確認する

最初の一歩としては、既存環境で次の3点を確認してください。

SecurityIncident
| where ProviderName == "Microsoft XDR"

このクエリでMicrosoft XDR由来のインシデントが確認できるかを見たうえで、次に既存の分析ルール、ワークブック、プレイブックを棚卸しします。最後に、Defender portalへの移行計画をSOC、ID管理、コンプライアンスの3チームで共有してください。

Microsoft Defender XDRからMicrosoft Sentinelへのデータストリーミングは、単なるログ連携ではなく、SIEMとXDRを統合する運用設計の中核です。2026年4月更新をきっかけに、コネクタ設定だけでなく、スキーマ、権限、監査、移行期限まで含めて見直すことが、今後のMicrosoft Defender運用で重要になります。