Microsoft Defender XDRからMicrosoft Sentinelへデータをストリームする設定は、Defender XDRのインシデント、アラート、Advanced Huntingの生イベントをSentinel側で分析・監視したい管理者向けの重要な連携です。結論から言うと、すでにMicrosoft SentinelをMicrosoft Defenderポータルへオンボードしている環境では、Defender XDRコネクタは自動的に有効化されるため、Azure portalでの手動設定は原則不要です。一方、まだAzure portalでMicrosoft Sentinelを運用している環境では、2027年3月31日以降にAzure portalでのSentinelサポートが終了予定であることを踏まえ、コネクタ設定だけでなくDefenderポータルへの移行計画まで含めて確認する必要があります。(Microsoft Learn)
2026年5月14日に更新されたMicrosoft Learnの公式情報では、Microsoft Defender XDRコネクタを使って、インシデントとアラートの同期、オンプレミスActive Directoryユーザーエンティティの連携、Defender各サービスの生イベント収集を行う方法が整理されています。この記事では、変更点として押さえるべき内容、影響範囲、管理者・開発者が確認すべき設定、移行時の注意点を実務目線でまとめます。(Microsoft Learn)
Microsoft Defender XDRとMicrosoft Sentinel連携で何ができるのか
Microsoft Defender XDRコネクタを有効にすると、Microsoft Defender XDRで生成されたインシデント、アラート、関連エンティティをMicrosoft Sentinelに取り込み、両ポータル間でインシデント情報を同期できます。Microsoft Sentinel側では、Defender XDRの検知情報を、他のクラウド、オンプレミス、サードパーティ製品のログと組み合わせて調査できます。(Microsoft Learn)
連携の主な目的は、Defender製品群のアラートを単にSentinelへ送ることではありません。Defender XDR側で相関・集約されたインシデントをSentinelのインシデントキューで扱い、必要に応じてKQL、ワークブック、自動化ルール、プレイブックと組み合わせることにあります。
| 連携対象 | できること | 実務での使いどころ |
|---|---|---|
| インシデントとアラート | Defender XDRのインシデントをSentinelに取り込み、状態や担当者などを同期 | SOCの一次対応、インシデント管理の集約 |
| エンティティ | Microsoft Defender for Identityを通じてオンプレミスADユーザー情報を連携 | ユーザー起点の調査、UEBAとの組み合わせ |
| Advanced Huntingイベント | Endpoint、Office 365、Identity、Cloud Appsなどの生イベントをSentinelのテーブルに収集 | 脅威ハンティング、長期保管、他ログとの相関分析 |
特に重要なのは、Defender XDRのアラートがMicrosoft Defender for Endpoint、Microsoft Defender for Identity、Microsoft Defender for Office 365、Microsoft Defender for Cloud Appsなど複数サービスの情報を含み、Defender XDR側でグルーピングされる点です。アラート単位ではなく、攻撃の流れに近いインシデント単位で扱えるため、重複調査を減らしやすくなります。(Microsoft Learn)
2026年5月14日更新情報で管理者がまず見るべきポイント
今回の公式情報で最も重要なのは、Azure portalでのSentinel運用が恒久的な前提ではない点です。Microsoftは、2027年3月31日以降、Microsoft SentinelはAzure portalでサポートされず、Microsoft Defenderポータルのみで利用可能になると説明しています。現在もAzure portalでSentinelを運用している組織は、コネクタを有効にするだけでなく、Defenderポータルへの移行計画を早めに作る必要があります。(Microsoft Learn)
また、2025年7月1日以降にMicrosoft Sentinelへオンボードした一部の環境では、Defenderポータルへのオンボードが自動で行われる場合があります。既にDefenderポータルにオンボード済みであれば、Azure portalでこの記事の手順を繰り返す必要はありません。まず自社のSentinelワークスペースが、Azure portal運用なのか、Defenderポータル運用なのかを確認してください。(Microsoft Learn)
影響が出やすい環境
次の環境では、設定変更や移行前の検証を省くと、アラートの重複、クエリ不具合、ワークブックの表示崩れが起きやすくなります。
| 環境 | 注意すべき理由 | 確認ポイント |
|---|---|---|
| Defender製品の個別コネクタを既に使っている | XDRコネクタ有効化後、既存のDefender系コネクタはバックグラウンドで切断される | データ流入元、既存ルール、重複検知の有無 |
| インシデント名を条件に自動化している | Defender XDR連携後はインシデント名を事前に決められない | 条件をタグ、重大度、製品名などに変更 |
| KQLクエリやワークブックを作り込んでいる | スタンドアロンコネクタとXDRコネクタでスキーマ差分がある | フィールド名、値、エンティティ構造を検証 |
| Advanced Huntingイベントを大量に取り込む予定がある | インシデント・アラート以外の生イベントは課金対象 | 収集テーブル、保持期間、日次データ量 |
| Defender for Cloudも連携している | Defender for Cloudのアラート同期には追加の考慮が必要 | テナント単位かサブスクリプション単位かを確認 |
Azure portalでMicrosoft Defender XDRコネクタを設定する前提条件
Azure portalでMicrosoft Defender XDRコネクタを設定するには、ライセンス、権限、ワークスペース、ソリューションの準備が必要です。公式情報では、Microsoft Defender XDRの有効なライセンス、対象テナントでのSecurity Administratorロールまたは同等権限、Microsoft Sentinelワークスペースへの読み取り・書き込み権限、同一Microsoft Entraテナントへの所属、Content HubからのMicrosoft Defender XDRソリューションのインストールが前提として挙げられています。(Microsoft Learn)
実務では、設定画面を開けるかどうかだけで判断しないでください。たとえば、Sentinelワークスペースの閲覧権限はあるが、コネクタ設定を変更できないケースがあります。変更作業を行う担当者には、少なくとも「Defender XDR側の管理権限」と「Sentinelワークスペース側の書き込み権限」の両方が必要です。
設定前チェックリスト
| 確認項目 | 確認内容 | 不備がある場合の影響 |
|---|---|---|
| ライセンス | Microsoft Defender XDRを利用できるライセンスがあるか | コネクタ設定やデータ連携が進まない |
| テナント | Defender XDRとSentinelワークスペースが同じMicrosoft Entraテナントか | コネクタ変更ができない |
| ロール | Security Administratorまたは同等権限があるか | Defender側データのストリーム設定ができない |
| Sentinel権限 | ワークスペースへの読み取り・書き込み権限があるか | データコネクタ設定を保存できない |
| Content Hub | Microsoft Defender XDRソリューションがインストール済みか | コネクタや関連コンテンツが利用できない |
| Defenderポータル移行状況 | 既にDefenderポータルへオンボード済みか | 不要なAzure portal設定を行う可能性がある |
コネクタ設定で確認すべき3つの領域
Microsoft Defender XDRコネクタの設定は、大きく「インシデントとアラート」「エンティティ」「イベント」の3つに分かれます。それぞれ目的と影響範囲が異なるため、すべてを一度に有効化するのではなく、優先度を決めて段階的に展開するのが安全です。(Microsoft Learn)
インシデントとアラートの接続
最初に有効化すべきなのは、Microsoft Defender XDRのインシデントとアラートの接続です。これにより、Defender XDRのインシデントがMicrosoft Sentinelのインシデントキューに表示されます。設定時には、重複インシデントを避けるため、Microsoft製品のインシデント作成ルールをオフにするチェック項目が推奨されています。(Microsoft Learn)
接続後は、Log Analyticsで次のようなKQLを実行し、Microsoft Defender XDR由来のインシデントが入っているか確認します。
SecurityIncident
| where ProviderName == "Microsoft XDR"ここでデータが出ない場合は、すぐに障害と判断せず、まず「Defender XDR側で新しいインシデントが発生しているか」「対象ワークスペースを見ているか」「コネクタが正しいテナントで有効化されているか」を確認してください。通常運用下では、Defender XDRで生成されたインシデントはSentinelのUIやAPIに数分程度で表示されると説明されていますが、テーブルへの反映にはさらに時間がかかる場合があります。(Microsoft Learn)
エンティティ連携はDefender for Identity環境で重要
オンプレミスActive Directoryのユーザー情報をSentinelに連携したい場合は、Microsoft Defender for Identityを使ったエンティティ連携を確認します。公式手順では、UEBA構成ページに移動し、UEBAを有効化したうえでActive Directory関連の設定を適用します。オンプレミスAD同期では、Defender for Identityへのオンボードとセンサーの導入が前提です。(Microsoft Learn)
この設定は、端末やメールのアラートだけでなく「誰が関与したのか」を軸に調査したい組織で効果があります。たとえば、あるユーザーの資格情報が侵害された疑いがある場合、エンドポイント、メール、クラウドアプリ、オンプレミスADの行動をつなげて確認しやすくなります。
Advanced Huntingイベントは必要なテーブルから始める
Advanced Huntingイベントの収集では、Microsoft Defender for Endpoint、Microsoft Defender for Office 365、Microsoft Defender for Identity、Microsoft Defender for Cloud Apps、Defenderアラート関連のテーブルを選択できます。代表的なテーブルには、DeviceEvents、DeviceProcessEvents、EmailEvents、UrlClickEvents、IdentityLogonEvents、CloudAppEvents、AlertInfo、AlertEvidenceなどがあります。(Microsoft Learn)
ただし、Advanced Huntingイベントは生ログに近いため、すべて有効にするとデータ量が急増します。インシデントとアラートはSentinelへ無償で取り込まれますが、Advanced Huntingテーブルなど個別のDefenderコンポーネント由来データは取り込み課金の対象です。まずは調査目的に合うテーブルだけを有効化し、1〜2週間のデータ量を見てから拡張するのが現実的です。(Microsoft Learn)
| 目的 | 優先して検討するテーブル例 | 判断基準 |
|---|---|---|
| 端末侵害の調査 | DeviceProcessEvents、DeviceNetworkEvents、DeviceFileEvents | プロセス、通信、ファイル操作を追いたい場合 |
| メール脅威の調査 | EmailEvents、EmailAttachmentInfo、EmailUrlInfo、UrlClickEvents | フィッシング、添付ファイル、URLクリックを追いたい場合 |
| ID侵害の調査 | IdentityLogonEvents、IdentityDirectoryEvents、IdentityQueryEvents | 認証、AD変更、ディレクトリ探索を追いたい場合 |
| クラウドアプリ監視 | CloudAppEvents | SaaS操作やクラウドアプリ上の活動を見たい場合 |
| アラート根拠の確認 | AlertInfo、AlertEvidence | アラートに紐づくファイル、URL、IP、ユーザーなどを確認したい場合 |
既存環境への影響範囲
Microsoft Defender XDRコネクタを有効化すると、以前から接続していたMicrosoft Defender製品別のスタンドアロンコネクタは、バックグラウンドで自動的に切断されます。画面上は接続済みに見え続ける場合があっても、データは流れなくなるため、既存コネクタの状態表示だけで監視正常性を判断しないでください。(Microsoft Learn)
アラートスキーマ差分に注意
スタンドアロンコネクタからXDRコネクタへ移行すると、アラートのフィールドマッピング、派生フィールド、スキーマ構造、取り込み対象が変わる可能性があります。Microsoft Learnでは、既存のクエリ、分析ルール、ワークブックに影響する可能性があるため、移行前に差分確認を行うよう説明されています。(Microsoft Learn)
たとえば、Microsoft Defender for Identityの一部情報は、従来のエンティティ表現からresourceAccessEvents配列内のプロパティへ折り込まれる場合があります。また、Microsoft Defender for Cloudではスタンドアロンコネクタがサブスクリプション単位だったのに対し、XDRコネクタではテナント単位のスコープになります。こうした差分は、KQLのextendやparse_json、ワークブックの可視化ロジックに影響します。(Microsoft Learn)
自動化ルールは「インシデント名依存」を避ける
Defender XDRコネクタを有効化すると、インシデント作成はDefender XDR側の相関エンジンが主導します。そのため、Sentinel側でインシデントタイトルを事前に決める前提の自動化は壊れやすくなります。公式情報でも、インシデント名を条件にした自動化ルールではなく、タグなど別の条件を使うことが推奨されています。(Microsoft Learn)
実務では、次のように条件を見直すと安全です。
| 旧条件 | 問題点 | 置き換え候補 |
|---|---|---|
| インシデント名に「Phishing」を含む | Defender XDR側の命名変更で条件に一致しなくなる | タグ、アラート製品名、戦術、重大度 |
| 特定コネクタ名を前提にする | XDRコネクタ経由で製品名や構造が変わる | ProductName、ProviderName、AlertInfo |
| アラート件数だけで分岐する | XDR側の相関で複数アラートが統合される | 重大度、エンティティ種別、影響範囲 |
| スタンドアロンコネクタのフィールド名を参照 | スキーマ差分で値が空になる | XDRコネクタのスキーマに合わせて再設計 |
Defender portal移行を前提にした展開計画
Azure portalでMicrosoft Defender XDRからMicrosoft Sentinelへデータをストリームする設定は、短期的には有効な選択肢です。ただし、2027年3月31日以降のサポート終了予定を考えると、最終的にはMicrosoft Defenderポータルでの統合セキュリティ運用へ移行する計画が必要です。(Microsoft Learn)
DefenderポータルへSentinelを接続すると、Microsoft SentinelのデータをDefender XDRのインシデント、アラート、脆弱性、その他のセキュリティデータと同じポータルで扱えるようになります。Microsoftは、インシデント管理やAdvanced Huntingを統合し、ツール切り替えを減らす利点を説明しています。(Microsoft Learn)
移行前に棚卸しするもの
移行作業では、単にワークスペースを接続するだけでなく、既存の運用資産を棚卸ししてください。
| 棚卸し対象 | 確認する内容 | 移行時の判断 |
|---|---|---|
| Sentinelワークスペース | プライマリ、セカンダリ、リージョン、保持期間 | Defenderポータルでどのワークスペースを中心にするか |
| データコネクタ | Defender系、Defender for Cloud、サードパーティ | XDRコネクタへ集約するものと残すものを分ける |
| 分析ルール | KQL、スケジュール、インシデント生成条件 | スキーマ差分に合わせて修正 |
| 自動化ルール | 条件、タグ、担当者、プレイブック起動 | インシデント名依存を排除 |
| ワークブック | 参照テーブル、フィールド、グラフ | XDRコネクタ経由データで表示確認 |
| 運用手順書 | 一次対応、エスカレーション、クローズ理由 | Defenderポータル前提に更新 |
| 権限設計 | Azure RBAC、Microsoft Entraロール、SOC担当者 | 最小権限で再確認 |
特に複数ワークスペースを使っている場合は、プライマリワークスペースの扱いに注意が必要です。Defenderポータルでは、1つのプライマリワークスペースと複数のセカンダリワークスペースを扱う構成が説明されており、プライマリワークスペースを変更するとDefender XDRコネクタの接続先も切り替わります。(Microsoft Learn)
管理者と開発者が確認すべき具体的な設定
管理者は、連携そのものの成否だけでなく、重複インシデント、権限、課金、保持期間を確認する必要があります。一方、開発者や運用自動化の担当者は、KQL、API、ワークブック、プレイブックの動作確認が重要です。
管理者向けチェック
| 項目 | 確認内容 | 推奨対応 |
|---|---|---|
| ポータル | Azure portal運用かDefenderポータル運用か | 既にDefenderポータルならAzure portalでの手動設定を避ける |
| 権限 | Security Administrator、Sentinel Contributorなど | 作業者と運用者の権限を分ける |
| 重複防止 | Microsoft製品のインシデント作成ルール | XDR連携時に重複しないよう無効化 |
| 既存コネクタ | Defender製品別コネクタ | XDRコネクタ有効化後のデータ流入を確認 |
| 課金 | Advanced Huntingイベントの取り込み量 | 最初は必要テーブルだけ有効化 |
| 保持期間 | Log Analytics側の保持設定 | 調査要件とコストのバランスを調整 |
| 移行期限 | 2027年3月31日以降のAzure portalサポート終了予定 | 年度計画にDefenderポータル移行を組み込む |
開発者・自動化担当者向けチェック
| 項目 | 確認内容 | よくある失敗 |
|---|---|---|
| KQL | SecurityIncident、SecurityAlert、Advanced Huntingテーブル | 旧フィールド名のまま参照して結果が空になる |
| 分析ルール | XDRコネクタ経由のスキーマに合っているか | スタンドアロンコネクタ前提の条件が残る |
| ワークブック | グラフや集計が正しく表示されるか | ProductNameやProviderNameの値変更を見落とす |
| プレイブック | トリガー条件、入力JSON、エンティティ参照 | インシデント構造の差分で実行エラーになる |
| API連携 | インシデントID、ステータス、コメント同期 | 双方向同期後の状態更新を想定していない |
| タグ運用 | 自動化条件に使うタグ設計 | タグが統一されずルールが複雑化する |
データ取り込み後の確認方法
設定後は、コネクタ画面のグラフだけでなく、KQLで実データを確認してください。インシデントの確認にはSecurityIncident、生イベントの確認には有効化したAdvanced Huntingテーブルを使います。公式情報でも、インシデント、アラート、イベントの線がコネクタページのグラフに表示されることに加え、KQLによる確認が案内されています。(Microsoft Learn)
インシデント件数を日次で確認する例は次のとおりです。
SecurityIncident
| where ProviderName == "Microsoft XDR"
| summarize Count = count() by bin(TimeGenerated, 1d)
| order by TimeGenerated descDeviceEventsを有効化した場合は、次のように日次件数を確認できます。
DeviceEvents
| summarize Count = count() by bin(TimeGenerated, 1d)
| order by TimeGenerated desc確認時は、件数が多いか少ないかだけでなく、次の観点も見てください。
| 観点 | 確認する理由 |
|---|---|
| 想定した製品のデータが入っているか | Endpointだけ、Office 365だけなど偏りを見つけるため |
| 重大度の分布が極端でないか | フィルタリングや取り込み条件の誤りを見つけるため |
| 日次件数が急増していないか | Advanced Huntingイベントの課金増を早期に把握するため |
| インシデントが重複していないか | 旧コネクタやルールとの二重生成を避けるため |
| 自動化ルールが期待通り動くか | クローズ、通知、チケット起票の誤動作を防ぐため |
失敗しやすいポイントと対策
Microsoft Defender XDRとMicrosoft Sentinelの連携で多い失敗は、「接続できた」ことをゴールにしてしまうことです。実際には、接続後のスキーマ差分、既存ルールの影響、コスト、運用手順の変更まで確認しないと、SOCの現場で混乱が起きます。
すべてのイベントを一気に有効化する
Advanced Huntingイベントは便利ですが、最初からすべてのテーブルを有効化すると、ログ量とコストが読みにくくなります。まずは現在の調査シナリオに直結するテーブルだけを選び、データ量を測定してください。たとえば、メール起点の侵害調査が主目的なら、EmailEvents、EmailUrlInfo、UrlClickEventsを優先し、端末の詳細イベントは後から追加するほうが管理しやすくなります。
旧コネクタの表示を信じてしまう
XDRコネクタ有効化後、旧Defender系コネクタが画面上で接続済みに見えても、実際にはデータが流れない場合があります。運用監視では、コネクタの表示ではなく、対象テーブルの直近データ、ProviderName、ProductName、日次件数で確認してください。(Microsoft Learn)
Defender for Cloudの扱いを混同する
Defender XDRコネクタはDefender for Cloudのインシデントも扱いますが、アラートやエンティティを同期するにはDefender for Cloudコネクタ側の設定も関係します。公式情報では、これを有効にしない場合、Defender for Cloudインシデントが空で表示される可能性が説明されています。(Microsoft Learn)
インシデント同期の意味を誤解する
Defender XDRとSentinelでは、ステータス、重大度、タグ、コメントなど一部の情報が同期されます。ただし、両ポータルのスキーマに合わせて値が変換される項目もあります。たとえば、Defenderポータル側のActiveがSentinel側ではNewとして扱われるなど、状態管理の見え方が変わることがあります。(Microsoft Learn)
まず実施すべき対応
現在Azure portalでMicrosoft Sentinelを運用している場合は、次の順序で進めるのが現実的です。
| 優先度 | 実施内容 | 目的 |
|---|---|---|
| 高 | SentinelワークスペースがDefenderポータルにオンボード済みか確認 | 手動設定が必要か判断する |
| 高 | 既存のDefender系スタンドアロンコネクタを棚卸し | XDRコネクタ移行時の影響を把握する |
| 高 | インシデント作成ルールと自動化ルールを確認 | 重複生成や誤動作を防ぐ |
| 中 | 主要KQL、分析ルール、ワークブックをテスト | スキーマ差分による不具合を防ぐ |
| 中 | Advanced Huntingテーブルを段階的に有効化 | コストとデータ量を管理する |
| 中 | Defenderポータル移行のスケジュールを作る | 2027年3月31日以降に備える |
| 低 | 運用手順書とSOC教育資料を更新 | 調査フローの混乱を減らす |
Microsoft Defender XDRからMicrosoft Sentinelへデータをストリームする設定は、セキュリティ運用を統合するうえで有効です。ただし、Azure portalでの個別設定だけを見ていると、Defenderポータルへの移行、旧コネクタの切断、スキーマ差分、Advanced Huntingイベントの課金といった重要な論点を見落とします。
まずは、自社のSentinelがどのポータルで運用されているかを確認してください。そのうえで、インシデントとアラートの連携を優先し、既存ルールの影響を検証しながら、必要なAdvanced Huntingテーブルだけを段階的に有効化するのが安全です。長期的には、2027年3月31日以降のAzure portalサポート終了予定を前提に、Microsoft Defenderポータルでの統合運用へ移行する計画を立てておくべきです。
コメント