Microsoft Defender XDR integration with Microsoft Sentinel の要点は、Microsoft Defender XDR のインシデント、アラート、高度なハンティングイベントを Microsoft Sentinel と連携し、SIEM と XDR を同じ運用画面で扱えるようにすることです。特に重要なのは、単なるデータ連携ではなく、インシデント管理、アラート相関、自動化ルール、コネクタ構成、コスト、そして Microsoft Defender ポータルへの移行計画に影響する点です。
2026年6月30日時点で管理者が最初に確認すべき結論は明確です。Microsoft Sentinel を Azure ポータル中心で運用している組織は、Microsoft Defender ポータルへの移行を前提に、既存のコネクタ、分析ルール、プレイブック、チケット連携を棚卸しする必要があります。Microsoft は、2027年3月31日以降、Microsoft Sentinel は Azure ポータルではサポートされず、Microsoft Defender ポータルでのみ利用可能になると案内しています。(Microsoft Learn)
Microsoft Defender XDR integration with Microsoft Sentinel とは
Microsoft Defender XDR integration with Microsoft Sentinel は、Microsoft Defender XDR と Microsoft Sentinel を連携させ、Microsoft 365、ID、エンドポイント、クラウドアプリ、メール、クラウドセキュリティなどの検出結果を、Microsoft Sentinel のインシデント管理や調査に取り込むための統合機能です。
公式ドキュメントでは、統合方法は大きく2つに整理されています。1つは Microsoft Sentinel を Microsoft Defender ポータルにオンボードし、Defender ポータル上で SIEM と XDR を統合運用する方法です。もう1つは、Azure ポータル側の Microsoft Sentinel で Microsoft Defender XDR コネクタを有効化し、Defender XDR のインシデントやアラートを Sentinel に同期する方法です。(Microsoft Learn)
この統合により、Defender XDR のインシデントは Microsoft Sentinel のインシデントキューにも表示されます。インシデントには関連アラート、エンティティ、調査に必要な情報が含まれ、Defender XDR 側のインシデントとも双方向に同期されます。SOC チームは、Microsoft Sentinel の SIEM データと Defender XDR の XDR データを突き合わせながら調査できるようになります。(Microsoft Learn)
何が便利になるのか
従来、Microsoft Sentinel と Microsoft Defender XDR を別々に見ていた環境では、同じ攻撃に関連するアラートが複数の画面に分散しがちでした。統合後は、Defender XDR のアラートグルーピングや相関分析を活用しながら、Sentinel 側のクラウド、オンプレミス、サードパーティデータも含めて調査できます。
たとえば、次のような流れが現実的になります。
| シーン | 統合前に起きやすい課題 | 統合後に期待できること |
|---|---|---|
| フィッシングメールから端末侵害までを追う | Defender for Office 365、Defender for Endpoint、Sentinel のログを別々に確認する | 1つのインシデントからメール、端末、ユーザー、関連エンティティを追いやすくなる |
| ID 侵害の調査 | Entra ID、Defender for Identity、Sentinel の相関に時間がかかる | ユーザーやデバイスの文脈を含めて調査しやすくなる |
| SOC の一次対応 | 類似アラートが多く、キューが肥大化する | Defender XDR の相関・グルーピングにより、攻撃ストーリー単位で扱いやすくなる |
| チケット連携 | Sentinel と Defender XDR のどちらを正とするか迷う | 統合後のインシデント情報を基準に運用ルールを再設計できる |
ポイントは、「ログを増やす機能」ではなく「インシデント運用を統合する機能」として見ることです。ログ取り込みだけを目的に有効化すると、コストや自動化ルールの影響を見落としやすくなります。
2026年時点で押さえるべき更新ポイント
Microsoft Defender XDR integration with Microsoft Sentinel で確認すべき更新ポイントは、主に次の5つです。
| 確認項目 | 管理者が見るべきポイント |
|---|---|
| ポータル移行 | Azure ポータル中心の Sentinel 運用を、Defender ポータル前提に見直す |
| コネクタ構成 | Defender XDR コネクタ有効化により、個別 Defender コネクタの扱いが変わる |
| インシデント生成 | Microsoft incident creation rules やアラート名依存の自動化に影響する |
| データ取り込み | インシデント・アラートは無償同期だが、高度なハンティングイベントや保持延長は課金対象になり得る |
| 移行期限 | 2027年3月31日以降、Sentinel は Defender ポータルでのみ利用する前提になる |
Microsoft Sentinel は Microsoft Defender ポータルでも一般提供されており、Defender XDR や E5 ライセンスがない顧客でも Defender ポータル上で Sentinel を利用できます。ただし、Defender XDR のデータと統合する場合は、Defender XDR 側のライセンスやアクセス権、同一 Microsoft Entra テナントなどの前提条件を確認する必要があります。(Microsoft Learn) (Microsoft Learn)
影響範囲：どの管理者・チームが対応すべきか
この更新は、Microsoft Sentinel の画面を使っている担当者だけの話ではありません。影響は SOC、セキュリティアーキテクト、検出ルール担当、Logic Apps プレイブック担当、ID 管理者、FinOps 担当、監査・コンプライアンス担当まで広がります。
SOC・インシデント対応チームへの影響
SOC チームにとって最も大きな変化は、インシデントキューの考え方です。Microsoft Defender ポータルでは、Sentinel と Defender XDR のインシデントを統合的に扱えるため、調査の入口が Azure ポータルの Sentinel から Defender ポータルの unified incident queue に移っていきます。
一方で、既存の運用手順書が Azure ポータル前提になっている場合、画面遷移、検索場所、インシデントの見え方、担当者アサイン、クローズ理由の扱いを更新する必要があります。Microsoft Defender ポータルでは、インシデント調査、Advanced Hunting、エンティティページなどの場所も Azure ポータルとは異なります。(Microsoft Learn)
Sentinel 管理者への影響
Sentinel 管理者は、ワークスペースのオンボード状態、プライマリワークスペース、データコネクタ、Content hub のソリューション、分析ルール、ワークブック、ウォッチリストを確認する必要があります。
特に複数ワークスペースを使っている環境では、どのワークスペースを Defender ポータルのプライマリワークスペースとして扱うかが重要です。プライマリワークスペースを切り替えると、Defender XDR コネクタは新しいプライマリに接続され、以前のプライマリからは自動的に切断されます。(Microsoft Learn)
自動化・チケット連携担当への影響
自動化ルール、Logic Apps プレイブック、ServiceNow などの外部チケット連携を使っている場合は、特に注意が必要です。Defender XDR 統合後は、インシデント名、プロバイダー名、説明フィールド、クローズ理由、タグなどの扱いが変わる可能性があります。
たとえば、インシデント名に特定の文字列が含まれることを条件にプレイブックを起動している場合、Defender XDR の相関エンジンが自動生成するタイトルに変わることで条件に一致しなくなることがあります。公式情報でも、インシデント名ではなくタグなど別の条件を使うことが推奨されています。(Microsoft Learn)
設定変更で確認すべきポイント
Microsoft Defender XDR integration with Microsoft Sentinel の設定は、Defender ポータルを主軸にするか、Azure ポータルで Defender XDR コネクタを使い続けるかで変わります。
Defender ポータルで統合する場合
Microsoft Sentinel を Microsoft Defender ポータルにオンボードし、Defender XDR ライセンスがある場合、Microsoft Sentinel は Defender XDR に自動接続されます。この場合、Defender XDR データコネクタも自動的に設定されます。さらに、Defender XDR コネクタに含まれる個別の Defender 製品コネクタは切断されます。(Microsoft Learn)
対象になる主なコネクタは次のとおりです。
| 自動的に扱いが変わる主なコネクタ | 確認ポイント |
|---|---|
| Microsoft Defender for Endpoint | 既存の検出ルールが旧スキーマや個別コネクタ前提になっていないか |
| Microsoft Defender for Identity | UEBA、IdentityInfo、オンプレミス AD 連携の要件を確認する |
| Microsoft Defender for Office 365 | フィッシング・メール関連の分析ルールやプレイブックを確認する |
| Microsoft Defender for Cloud Apps | アラートの重複や旧コネクタ依存を確認する |
| Microsoft Entra ID Protection | ID リスク関連のインシデント生成条件を確認する |
管理者がやるべきことは、単に「接続されたか」を見るだけではありません。既存の個別コネクタからのデータ流入、分析ルールの参照テーブル、アラートスキーマ、重複インシデントの有無を確認する必要があります。
Azure ポータルで Defender XDR コネクタを有効化する場合
Azure ポータル側の Microsoft Sentinel で Defender XDR データを同期したい場合は、Microsoft Sentinel の Content hub から Microsoft Defender XDR solution をインストールし、Microsoft Defender XDR データコネクタを有効化します。コネクタでは、インシデントとアラート、エンティティ、イベントの接続設定を確認します。(Microsoft Learn)
基本的な確認手順は次のとおりです。
| 手順 | 作業内容 | 確認ポイント |
|---|---|---|
| 1 | Microsoft Sentinel の Content hub で Microsoft Defender XDR solution を確認 | 未インストールなら導入する |
| 2 | Data connectors から Microsoft Defender XDR を開く | 既存の個別 Defender コネクタとの重複を確認する |
| 3 | Connect incidents & alerts を有効化 | Microsoft incident creation rules の扱いを理解する |
| 4 | 必要に応じて entities / events を接続 | Defender for Identity や高度なハンティングイベントの要件を確認する |
| 5 | KQL で取り込みを確認 | SecurityIncident テーブルで ProviderName を確認する |
| 6 | 自動化ルールとプレイブックをテスト | インシデント名、プロバイダー名、タグ、重大度条件を確認する |
取り込み確認には、公式ドキュメントで示されているように次の KQL を使えます。(Microsoft Learn)
SecurityIncident
| where ProviderName == "Microsoft XDR"通常運用では、Defender XDR で生成されたインシデントは数分程度で Sentinel の UI や API に表示されます。ただし、securityIncident テーブルへの取り込みにはさらに数分かかる場合があります。自動化ルールや外部チケット連携の動作確認では、この遅延も考慮してください。(Microsoft Learn)
移行期限：Azure ポータル前提の運用は見直しが必要
最も重要な期限は、2027年3月31日です。Microsoft は、2027年3月31日以降、Microsoft Sentinel は Azure ポータルでサポートされず、Microsoft Defender ポータルでのみ利用可能になると案内しています。Azure ポータルで Sentinel を利用している顧客は Defender ポータルへリダイレクトされる予定です。(Microsoft Learn)
これは、「いつか移行すればよい」という話ではありません。SOC の実運用では、移行前に次の確認が必要です。
| 期限までに確認すべき項目 | 理由 |
|---|---|
| Sentinel ワークスペース一覧 | どのワークスペースを Defender ポータルにオンボードするか決めるため |
| プライマリワークスペース | Defender XDR データとの相関対象を整理するため |
| 分析ルール | インシデント生成、アラート名、スキーマ依存を確認するため |
| 自動化ルール・プレイブック | 旧フィールドや旧ポータル URL への依存をなくすため |
| 外部チケット連携 | インシデント URL、説明、プロバイダー名の変化に備えるため |
| 権限設計 | Azure RBAC と Defender の Unified RBAC の差分を確認するため |
| 監査・データ所在地 | Defender ポータル利用時のデータ処理・保持ポリシーを確認するため |
移行そのものに追加費用は発生しないと案内されていますが、Microsoft Sentinel の利用量に応じた課金は従来どおり続きます。また、Defender XDR の高度なハンティングデータを Sentinel 側に取り込む、保持期間を延長する、Data Lake tier を利用する、といった構成では別途コスト確認が必要です。(Microsoft Learn) (Microsoft Learn)
データ取り込みとコストの注意点
Microsoft Defender XDR integration with Microsoft Sentinel では、すべてのデータが同じ条件で取り込まれるわけではありません。
公式情報では、Defender XDR のアラートとインシデント、つまり SecurityAlert や SecurityIncident に入るデータは、Microsoft Sentinel へ無償で取り込まれ同期されます。一方で、DeviceInfo、DeviceFileEvents、EmailEvents など、個別 Defender コンポーネントの Advanced Hunting テーブルを取り込む場合は課金対象になります。(Microsoft Learn)
取り込み対象を決める判断基準
| データ種別 | 取り込むべきケース | 注意点 |
|---|---|---|
| インシデント・アラート | SOC のインシデントキューを統合したい | 重複インシデントを避けるため、incident creation rules の確認が必要 |
| Advanced Hunting イベント | Sentinel の KQL、ワークブック、長期保持、他ログとの相関に使いたい | 取り込み課金や保持コストを確認する |
| TVM 関連テーブル | 脆弱性管理データを Sentinel で分析したい | 一部 TVM テーブルは Sentinel に取り込まれず、Defender XDR Advanced Hunting 側で確認する必要がある |
| Defender for Cloud インシデント | クラウドアラートも XDR 経由で統合したい | Defender for Cloud コネクタを有効にしないと、インシデントのアラートやエンティティが空に見える場合がある |
特に見落としやすいのが TVM、つまり Defender Vulnerability Management 関連テーブルです。DeviceTvmSoftwareInventory や DeviceTvmSoftwareVulnerabilities などは Sentinel のスキーマ上に見える場合がありますが、TVM データは Sentinel ワークスペースに取り込まれないため、Sentinel 側のクエリでは結果が返らないことがあります。(Microsoft Learn)
インシデント生成ルールと自動化への影響
Defender XDR コネクタを有効化すると、重複インシデントを避けるため、Defender XDR 統合対象製品の Microsoft incident creation rules は無効化されます。Defender ポータルでは独自のインシデント生成エンジンが使われるため、従来 Sentinel 側で細かく制御していたインシデント名や生成条件に依存している運用は見直しが必要です。(Microsoft Learn)
壊れやすい自動化の例
| 既存の条件 | 起きやすい問題 | 推奨される見直し |
|---|---|---|
| インシデント名に「Defender for Endpoint」を含む場合にプレイブックを実行 | Defender XDR の相関エンジンが別のタイトルを付ける可能性がある | タグ、重大度、製品名、カスタム詳細など別条件に変更 |
| ProviderName が旧値であることを前提に分岐 | 統合後に Microsoft XDR へ寄る | ProviderName の実データを確認して条件を更新 |
| Description フィールドをチケット説明に転記 | 移行後のテーブルや連携で説明が期待どおり取得できない場合がある | title、comments、custom details、providerIncidentUrl など代替項目を検討 |
| アラート単位で即時プレイブックを実行 | Defender ポータルから Sentinel への同期遅延で起動が遅れる場合がある | 最大数分の遅延を前提に SLA と通知設計を見直す |
| インシデントを手動作成して Defender 側にも同期する想定 | Sentinel API や手動作成インシデントは Defender ポータルに同期されないケースがある | 手動インシデントの扱いを運用ルールで明確化 |
移行時は「ルールが有効か」だけでなく、「条件に使っているフィールドが移行後も同じ意味で使えるか」を確認してください。特に外部チケット連携は、テスト環境で実インシデントに近いデータを使って検証するのが安全です。
Defender for Cloud 連携で失敗しやすいポイント
Microsoft Defender XDR コネクタは Microsoft Defender for Cloud のインシデントも扱いますが、Defender for Cloud のアラートやエンティティを正しく同期するには、Microsoft Sentinel 側で Defender for Cloud コネクタの構成も確認する必要があります。
公式情報では、Defender for Cloud のインシデントを同期する場合、Defender for Cloud コネクタを有効にしないと、Defender for Cloud のインシデントが空に見えることがあると説明されています。(Microsoft Learn)
グローバル環境では、Azure サブスクリプションが複数国・複数事業部に分散していることもあります。その場合は、テナントベースで Defender for Cloud アラートを扱うのか、サブスクリプションベースのレガシーコネクタを維持するのかを設計として決める必要があります。(Microsoft Learn)
高度なハンティングと検出ルールの考え方
Microsoft Defender XDR integration with Microsoft Sentinel では、Advanced Hunting イベントを Sentinel にストリーミングし、Sentinel のワークスペース内の専用テーブルで分析できます。これにより、Defender for Endpoint、Defender for Office 365、Defender for Identity、Defender for Cloud Apps などのクエリを Sentinel の KQL 運用に組み込みやすくなります。(Microsoft Learn)
ただし、2026年時点では、検出ルールの作成方針も見直す価値があります。公式情報では、Microsoft Defender の custom detections が、Microsoft Sentinel SIEM と Microsoft Defender XDR をまたぐ新しい検出ルール作成の推奨手段として説明されています。特に Defender XDR データを長期保持する必要がない検出では、Sentinel に大量取り込みする前に custom detections で足りるかを検討すると、コストと運用負荷を下げられる可能性があります。(Microsoft Learn)
判断基準は次のとおりです。
| やりたいこと | 適した選択肢 |
|---|---|
| Defender XDR データだけで高速に検出したい | Microsoft Defender custom detections |
| Sentinel のサードパーティログと Defender データを相関したい | Sentinel analytics rules または Defender ポータル上の統合ハンティング |
| 長期保持した Defender データで調査したい | Sentinel への取り込み、保持期間、Data Lake tier を検討 |
| 既存の Sentinel KQL 資産を活かしたい | Defender ポータルの Advanced Hunting で再利用可否を確認 |
| コストを抑えたい | 取り込み前に、30日既定保持の Defender Advanced Hunting で足りるか確認 |
グローバル企業での確認ポイント
海外拠点や複数リージョンを持つ企業では、機能の有効化だけでなく、データ所在地、プライバシー、権限委任、テナント構成を確認する必要があります。
Microsoft Learn では、Azure ポータル利用時は Microsoft Sentinel のデータ保存・処理・保持・共有ポリシーが適用され、Defender ポータル利用時は Microsoft Defender XDR のポリシーが適用されると説明されています。グローバル環境では、国や業界ごとの規制、監査要件、データレジデンシー方針に沿って、移行前に法務・セキュリティ・クラウド基盤チームで確認しておくべきです。(Microsoft Learn)
グローバル向けチェックリスト
| 項目 | 確認内容 |
|---|---|
| テナント構成 | 国・事業部ごとにテナントが分かれていないか |
| ワークスペース構成 | プライマリワークスペースとセカンダリワークスペースの役割 |
| データ所在地 | Sentinel と Defender XDR のデータ保存・処理ポリシー |
| 権限管理 | Azure RBAC、Microsoft Entra ID ロール、Defender Unified RBAC の整理 |
| MSSP 運用 | マルチテナント管理や委任管理の扱い |
| 監査証跡 | インシデント更新、コメント、クローズ理由の同期範囲 |
| チケット連携 | 拠点別の ITSM ツール、通知先、エスカレーション条件 |
| コスト配賦 | Defender XDR データ取り込み、保持、Data Lake 利用の費用負担部門 |
特に、複数ワークスペースで Microsoft Defender XDR データを取り込んでいた環境では、Defender ポータル移行後にどのワークスペースへデータを集約するかを明確にする必要があります。移行後は、XDR データがプライマリワークスペースに集約される設計になるため、既存の自動化ルールや分析ルールを適切なワークスペースへ移す作業が必要になる場合があります。(Microsoft Learn)
管理者が今すぐ確認すべき実務手順
Microsoft Defender XDR integration with Microsoft Sentinel の対応は、次の順序で進めると抜け漏れを減らせます。
現状を棚卸しする
まず、現在の Microsoft Sentinel 環境を一覧化します。最低限、次の情報をまとめてください。
| 棚卸し対象 | 確認する内容 |
|---|---|
| Sentinel ワークスペース | リージョン、用途、接続済みコネクタ、保持期間 |
| Defender 製品 | Endpoint、Identity、Office 365、Cloud Apps、Defender for Cloud の利用状況 |
| データコネクタ | 個別 Defender コネクタと Defender XDR コネクタの状態 |
| 分析ルール | 参照テーブル、インシデント生成設定、アラート名 |
| 自動化ルール | 条件に使うフィールド、タグ、重大度、プロバイダー名 |
| プレイブック | Logic Apps のトリガー、実行権限、外部連携先 |
| ワークブック | 参照テーブル、KQL、URL、ポータル依存 |
| チケット連携 | インシデント URL、説明、担当者、クローズ理由のマッピング |
移行方針を決める
次に、運用方針を決めます。
| 方針 | 向いている環境 | 注意点 |
|---|---|---|
| Defender ポータルへ移行を進める | 2027年3月31日以降を見据え、統合 SOC 運用へ移りたい | 画面、権限、自動化、手順書の更新が必要 |
| 当面 Azure ポータルで XDR コネクタを使う | 既存 Sentinel 運用を短期的に維持したい | 期限までに Defender ポータル移行計画が必要 |
| 段階移行する | 複数ワークスペースや海外拠点がある | プライマリワークスペース、チケット連携、教育を段階的に整理する |
長期的には Defender ポータル前提で設計するのが自然です。Azure ポータルでの作業を継続する場合でも、あくまで移行期間中の暫定運用として捉えたほうが安全です。
テストすべき項目
本番環境で切り替える前に、少なくとも次のテストを行ってください。
| テスト項目 | 合格基準 |
|---|---|
| Defender XDR インシデントの同期 | Sentinel 側で ProviderName == "Microsoft XDR" のインシデントを確認できる |
| インシデント更新の双方向同期 | ステータス、重大度、タグ、コメントなどの想定項目が同期される |
| 自動化ルール | 期待する条件で実行され、不要なインシデントでは動かない |
| プレイブック | Logic Apps が失敗せず、外部チケットや通知に必要な項目を渡せる |
| Defender for Cloud | アラートやエンティティが空にならず、調査に必要な情報が見える |
| コスト | Advanced Hunting イベント取り込みや保持延長の増分を見積もれる |
| SOC 手順 | アナリストが Defender ポータルで調査、担当者変更、クローズまで完了できる |
よくある疑問
Microsoft Sentinel は Defender XDR がないと使えないのか
使えます。Microsoft Sentinel は Microsoft Defender ポータル上でも一般提供されており、Microsoft Defender XDR や E5 ライセンスがない顧客でも利用可能です。ただし、Defender XDR のインシデントやアラートと統合する場合は、Defender XDR 側のライセンスやアクセス権が必要です。(Microsoft Learn) (Microsoft Learn)
Azure ポータルの Sentinel はすぐ使えなくなるのか
すぐに停止するわけではありませんが、2027年3月31日以降は Azure ポータルでサポートされず、Microsoft Defender ポータルでのみ利用する前提になります。既存の SOC 運用、手順書、自動化、教育を考えると、早めに移行計画を作るべきです。(Microsoft Learn)
Defender XDR コネクタを有効化するとコストは増えるのか
インシデントとアラートの同期自体は無償です。ただし、Advanced Hunting イベントの取り込み、保持期間の延長、Data Lake tier の利用などは費用に影響します。特に大量のエンドポイントイベントやメールイベントを Sentinel に取り込む場合は、テーブル単位で見積もる必要があります。(Microsoft Learn) (Microsoft Learn)
既存の分析ルールはそのまま使えるのか
使えるものもありますが、無条件にそのまま使えるとは考えないほうが安全です。Defender XDR コネクタにより、アラートスキーマやインシデント生成の流れが変わる場合があります。特に、インシデント名、プロバイダー名、説明、旧コネクタ由来のフィールドに依存するルールは確認が必要です。(Microsoft Learn)
どのタイミングで移行すべきか
複数ワークスペース、自動化、外部チケット連携がある組織ほど早めに着手すべきです。まずは棚卸しと検証環境でのオンボードを行い、次に SOC 手順書、自動化、権限、コスト見積もりを更新し、最後に本番ワークスペースを段階的に移行するのが現実的です。
まとめ：まずはコネクタではなく運用影響を確認する
Microsoft Defender XDR integration with Microsoft Sentinel は、Defender XDR のインシデントやアラートを Sentinel に取り込むだけの機能ではありません。SIEM と XDR の運用を Microsoft Defender ポータルへ集約し、インシデント管理、相関分析、調査、自動化を再設計するための重要な統合です。
管理者が次に取るべき行動は、次の3つです。
まず、現在の Sentinel ワークスペース、Defender コネクタ、分析ルール、自動化ルール、プレイブックを棚卸しします。次に、Defender ポータル移行を前提に、プライマリワークスペース、権限、データ保持、コスト、チケット連携を設計します。最後に、検証環境で Defender XDR コネクタとインシデント同期を確認し、2027年3月31日の Azure ポータルサポート終了に備えて本番移行計画を固めます。
特に注意すべきなのは、インシデント名や旧コネクタのスキーマに依存した自動化です。ここを見落とすと、統合後に通知が飛ばない、チケットが起票されない、不要なインシデントが増えるといった問題が起きます。Microsoft Defender XDR integration with Microsoft Sentinel を導入する際は、「接続できたか」ではなく「SOC が明日から迷わず運用できるか」を基準に確認してください。
コメント