Azure 環境で Microsoft Sentinel と Microsoft Defender for Cloud を併用している管理者にとって、「Ingest Microsoft Defender for Cloud incidents with Microsoft Defender XDR integration」は、インシデントの流れを見直すべき重要な更新です。結論から言うと、Microsoft Defender XDR 経由で Defender for Cloud のインシデントを Microsoft Sentinel に取り込む場合は、Microsoft Defender XDR コネクタだけで完結させず、Tenant-based Microsoft Defender for Cloud コネクタも確認する必要があります。設定が不十分だと、Sentinel 側にインシデントは見えても、関連アラートやエンティティが空に見える可能性があります。Microsoft 公式情報では、Defender for Cloud と Defender XDR の統合により、Defender XDR が Defender for Cloud のアラートを収集し、Defender XDR インシデントを作成できると説明されています。(Microsoft Learn)
この記事では、2026年6月下旬時点で確認できる Microsoft Learn の公式情報をもとに、「Ingest Microsoft Defender for Cloud incidents with Microsoft Defender XDR integration」の意味、影響範囲、設定変更、移行期限、管理者が確認すべきポイントを実務目線で整理します。
「Ingest Microsoft Defender for Cloud incidents with Microsoft Defender XDR integration」とは
「Ingest Microsoft Defender for Cloud incidents with Microsoft Defender XDR integration」は、Microsoft Defender for Cloud のインシデントを Microsoft Defender XDR 統合経由で Microsoft Sentinel に取り込むための構成を説明する Microsoft Learn の記事です。
これまで Defender for Cloud のアラートを Sentinel に取り込む場合、サブスクリプション単位の Defender for Cloud コネクタを使って、SecurityAlert テーブルにアラートを取り込む運用が一般的でした。今回のポイントは、Defender for Cloud の検知情報が Defender XDR 側でインシデント化され、そのインシデントを Microsoft Sentinel のインシデントキューに同期できる点です。Microsoft Sentinel で Defender XDR incident integration を有効化している場合、Defender for Cloud のインシデントも Defender XDR 経由で取り込み、同期できます。(Microsoft Learn)
ただし、ここで注意すべきなのは、Microsoft Defender XDR コネクタだけを有効にしても、Defender for Cloud インシデントの中身が完全に表示されるとは限らないことです。Microsoft 公式ドキュメントでは、Defender XDR コネクタ経由で届く Defender for Cloud インシデントに関連アラートやエンティティを表示するには、Defender for Cloud のデータコネクタを構成する必要があると説明されています。(Microsoft Learn)
つまり、この更新は「新しい検知機能が追加された」というより、Sentinel、Defender XDR、Defender for Cloud の間でインシデントとアラートをどう流すかを整理するための運用変更と捉えるべきです。
更新ポイントの要点
今回の公式情報で管理者が押さえるべき要点は、次の4つです。
| 確認項目 | 要点 | 実務上の意味 |
|---|---|---|
| 対象 | Microsoft Defender for Cloud、Microsoft Defender XDR、Microsoft Sentinel | SOC やクラウドセキュリティ運用に影響 |
| 推奨構成 | Tenant-based Microsoft Defender for Cloud コネクタの利用 | テナント全体の Defender for Cloud アラートを扱いやすくなる |
| 注意点 | 旧来の Subscription-based コネクタだけでは、インシデント内の関連情報が欠ける可能性 | 「インシデントはあるが詳細が見えない」状態を防ぐ必要がある |
| 移行期限 | 該当機能単体の強制移行期限は公式情報上では明示されていない | ただし Sentinel の Defender ポータル移行計画とは合わせて確認すべき |
Microsoft は、Tenant-based Microsoft Defender for Cloud コネクタを新しい選択肢として示し、Microsoft Defender XDR と Defender for Cloud の統合がテナントレベルで実装されているため、この新しいコネクタの利用を推奨しています。一方で、Subscription-based Microsoft Defender for Cloud コネクタは Legacy と表示され、接続されていないサブスクリプションがある場合、そのサブスクリプション由来のインシデントで関連アラートやエンティティが表示されない可能性があります。(Microsoft Learn)
何が変わるのか：アラート中心からインシデント中心の運用へ
今回の変更を理解するうえで重要なのは、Microsoft のセキュリティ運用が「個別アラートを集める」方向から、「相関済みインシデントを扱う」方向へ寄っていることです。
Defender for Cloud は、Azure、ハイブリッド、マルチクラウドのワークロードで発生する脅威を検出します。Defender XDR との統合により、クラウドリソース、デバイス、ID、Microsoft 365 などをまたいだ調査コンテキストを Microsoft Defender ポータルで扱えるようになります。公式ドキュメントでは、Defender for Cloud のアラートとインシデントが Microsoft Defender XDR に統合され、クラウドリソース、デバイス、ID をまたぐ調査でより豊富なコンテキストを提供すると説明されています。(Microsoft Learn)
従来のように Sentinel 側で Defender for Cloud のアラートを受け取り、Scheduled analytics rule や Microsoft Security analytics rule でインシデント化していた環境では、運用の重複が起きやすくなります。Defender XDR 側ですでにインシデントが作られ、それが Sentinel に同期されるなら、Sentinel 側で同じアラートから別のインシデントを作る必要は薄くなります。
実務では、次のような変化が起こります。
| 従来の考え方 | 今後意識すべき考え方 |
|---|---|
| Defender for Cloud のアラートを Sentinel に取り込む | Defender XDR で相関されたインシデントを Sentinel でも扱う |
| サブスクリプションごとにコネクタ接続を管理する | テナント単位で Defender for Cloud アラートを同期する |
| Sentinel の分析ルールでインシデントを作る | Defender XDR 側で作られたインシデントを活用する |
| アラート単位でノイズを調整する | Defender ポータルのチューニングや Sentinel の自動化ルールで制御する |
特に大規模な Azure 環境では、サブスクリプションが増えるたびに Sentinel との接続状況を確認する運用は負担になります。Tenant-based コネクタを使うと、テナント全体の Defender for Cloud アラートを扱えるため、サブスクリプション追加時の見落としを減らしやすくなります。公式のデータコネクタ一覧でも、Tenant-based Microsoft Defender for Cloud コネクタは、接続後にすべての Defender for Cloud サブスクリプションのアラートを対象の Sentinel ワークスペースへ送信すると説明されています。(Microsoft Learn)
影響範囲：対象になる管理者と環境
この更新の影響を受けやすいのは、次のような環境です。
| 環境 | 影響度 | 確認すべきこと |
|---|---|---|
| Microsoft Sentinel で Defender XDR インシデントを取り込んでいる | 高 | Tenant-based Defender for Cloud コネクタを有効化しているか |
| Subscription-based Defender for Cloud コネクタを使い続けている | 高 | 未接続サブスクリプションがないか、重複取り込みがないか |
| Sentinel の分析ルールで Defender for Cloud アラートからインシデントを作っている | 高 | Defender XDR 由来のインシデントと二重化しないか |
| Microsoft Defender ポータルへ Sentinel をオンボードしている | 中〜高 | Primary workspace に Defender for Cloud インシデントが流れる設計になっているか |
| Defender for Cloud アラートだけを使い、Defender XDR インシデント統合は使っていない | 中 | 現行コネクタで目的を満たしているか、将来の運用変更に備えるか |
Microsoft Defender XDR と Microsoft Sentinel の統合では、Defender XDR のインシデントが Sentinel のインシデントキューに表示され、ステータス、所有者、終了理由などが同期されます。公式ドキュメントでは、Defender XDR のインシデントには関連アラート、エンティティ、調査に必要な情報が含まれ、Microsoft Sentinel に入った後も Defender XDR と双方向同期されると説明されています。(Microsoft Learn)
そのため、SOC チームが Sentinel を中心に運用している場合でも、Defender XDR 側の相関結果を前提にした運用設計へ寄せる必要があります。
設定変更で確認すべきポイント
管理者が最初に確認すべきなのは、「どの経路で Defender for Cloud の情報を Sentinel に入れているか」です。単にコネクタが有効かどうかではなく、インシデント、アラート、エンティティが期待通りに同期されているかを確認します。
Microsoft Defender XDR コネクタのインシデント統合を確認する
Microsoft Sentinel で Defender XDR インシデントを取り込むには、Microsoft Defender XDR コネクタのインシデント統合が有効になっている必要があります。公式ドキュメントでは、Azure ポータル側で Defender XDR データを Sentinel に同期する場合、Microsoft Defender XDR コネクタを有効にし、インシデントとアラート情報を Sentinel に送信して同期すると説明されています。(Microsoft Learn)
確認すべき項目は次の通りです。
| 確認項目 | 見るべき状態 |
|---|---|
| Microsoft Defender XDR コネクタ | 有効化されている |
| インシデント取り込み | Defender XDR incidents の同期が有効 |
| Sentinel 側のインシデント | ProductName や関連リンクから Defender XDR 由来と分かる |
| 同期状態 | ステータスや所有者の変更が期待通り反映される |
実務上は、設定画面だけで判断せず、実際に Defender XDR 側で発生したテストまたは既存のインシデントが Sentinel 側にどう表示されるかを確認してください。
Tenant-based Microsoft Defender for Cloud コネクタを確認する
今回もっとも重要なのが、Tenant-based Microsoft Defender for Cloud コネクタです。Microsoft 公式情報では、Defender XDR インシデント統合を有効にした後、Content Hub の Microsoft Defender for Cloud solution バージョン 3.0.0 から利用できる Tenant-based Microsoft Defender for Cloud コネクタを有効にする流れが示されています。(Microsoft Learn)
このコネクタを使う理由は、Defender for Cloud と Defender XDR の統合がテナントレベルで行われるためです。サブスクリプション単位の Legacy コネクタだけに頼ると、接続漏れのあるサブスクリプションから来たインシデントで、アラートやエンティティが欠ける可能性があります。
確認時は、次の観点で見てください。
| 確認項目 | 判断基準 |
|---|---|
| Content Hub のソリューション | Microsoft Defender for Cloud solution が導入または更新されている |
| コネクタ種別 | Tenant-based Microsoft Defender for Cloud が利用可能 |
| 接続先 | 目的の Microsoft Sentinel ワークスペースに接続されている |
| 取り込み対象 | テナント配下の Defender for Cloud サブスクリプションが対象になる |
| テスト | Sentinel の SecurityAlert とインシデント詳細で関連情報が確認できる |
特に複数サブスクリプションを運用している企業では、Subscription-based コネクタで接続していた時代の名残として、一部のサブスクリプションだけが Sentinel に接続されていることがあります。この状態で Defender XDR 経由のインシデント取り込みに移ると、「重要なインシデントは見えるのに、調査に必要なエンティティが足りない」という運用上の穴が生まれます。
Legacy コネクタの扱いを決める
Subscription-based Microsoft Defender for Cloud コネクタは、公式ドキュメント上で Legacy と表記されています。Microsoft は、以前から Legacy の Subscription-based Defender for Cloud コネクタを有効にしていた場合、ログ内のアラート重複を防ぐために無効化することを推奨しています。(Microsoft Learn)
ただし、すべての環境で即時に Legacy コネクタを停止すればよいわけではありません。次のように判断すると安全です。
| 状況 | 推奨される判断 |
|---|---|
| Defender XDR インシデント統合を使い、Tenant-based コネクタも有効化する | Legacy コネクタの無効化を検討 |
| サブスクリプション単位でアラート取り込みを継続したい | Legacy コネクタを維持する理由を明文化 |
| 一部ワークスペースで独自の分析ルールを使っている | 重複インシデントの有無を検証してから切り替える |
| 監査要件で既存クエリやレポートを変更できない | 移行期間を設け、テーブルやフィールドの差分を確認 |
大切なのは、「Legacy と書かれているからすぐ止める」ではなく、どの検知・レポート・自動化がそのコネクタに依存しているかを棚卸しすることです。
Sentinel の分析ルールと自動化ルールへの影響
見落としやすいのが、Microsoft Sentinel の分析ルールです。Defender for Cloud のアラートから Sentinel 側でインシデントを作成する Scheduled analytics rule や Microsoft Security analytics rule を使っている場合、Defender XDR 由来のインシデントと重複する可能性があります。
Microsoft 公式情報では、Defender for Cloud アラートからインシデントを作成する Scheduled または Microsoft Security analytics rule がある場合、Microsoft 365 Defender によって作成・同期される既成のインシデントを受け取ることになるため、それらのルールを無効化することが推奨されています。(Microsoft Learn)
特に次のようなルールは確認が必要です。
| ルール例 | リスク | 見直し方 |
|---|---|---|
SecurityAlert を対象に Defender for Cloud アラートを拾う Scheduled rule | 同じ検知から二重にインシデント化される | Defender XDR 由来のインシデントで代替できるか確認 |
| AlertName や ProductName で Defender for Cloud を抽出するルール | コネクタ変更で条件が合わなくなる | 実データでフィールド値を確認 |
| インシデント名を条件にした automation rule | Defender XDR 側の命名に変わり条件が外れる | タグ、Severity、Provider、ProductName などに条件を変更 |
| 特定の Defender for Cloud アラートを自動クローズするルール | 新しい経路で想定外に動作する可能性 | テスト用ワークスペースまたは低影響条件で検証 |
Defender XDR 統合を有効にすると、インシデント作成や相関の主導権が Defender XDR 側に移ります。Microsoft Defender XDR と Sentinel の統合ドキュメントでも、Defender XDR との接続時には、同じアラートから重複インシデントを作らないよう、Microsoft incident creation rules の扱いが変わることが説明されています。(Microsoft Learn)
移行期限はあるのか
「Ingest Microsoft Defender for Cloud incidents with Microsoft Defender XDR integration」自体について、公式情報上、特定日までに Tenant-based コネクタへ移行しなければならないという強制期限は明示されていません。ここは不確かな情報を補って断定すべきではありません。
ただし、Microsoft Sentinel 全体では別の重要な期限があります。Microsoft のデータコネクタ関連ドキュメントでは、2027年3月31日以降、Microsoft Sentinel は Azure ポータルではサポートされず、Microsoft Defender ポータルでのみ利用可能になると説明されています。また、2025年7月以降、多くの新規顧客は Defender ポータルへ自動的にオンボードされるとも記載されています。(Microsoft Learn)
そのため、実務上は次のように整理するとよいでしょう。
| 項目 | 期限・状態 | 管理者の対応 |
|---|---|---|
| Defender for Cloud と Defender XDR の統合 | GA として提供 | 利用方針を決め、Sentinel 連携を確認 |
| Tenant-based Microsoft Defender for Cloud コネクタ | Preview として案内 | 本番適用前に法務・運用上の Preview 扱いを確認 |
| Subscription-based Microsoft Defender for Cloud コネクタ | Legacy として案内 | 継続理由がなければ移行計画を作る |
| Microsoft Sentinel の Azure ポータル利用 | 2027年3月31日以降は Defender ポータルのみ | Defender ポータル前提の運用へ段階移行 |
つまり、今回の更新は「明日までに切り替える」タイプではありません。しかし、Sentinel の Defender ポータル移行、Defender XDR 統合、Defender for Cloud のテナント単位連携は同じ方向を向いた変更です。個別に後追い対応するより、SOC 運用全体の見直しとして進めた方が失敗しにくくなります。
管理者向けの確認手順
ここでは、既存環境で安全に確認するための手順を整理します。
| 手順 | 作業内容 | 確認ポイント |
| -: | ————————————————— | ———————————————————- |
| 1 | 現在の Sentinel ワークスペースを棚卸しする | Primary workspace、接続済みコネクタ、対象サブスクリプションを確認 |
| 2 | Microsoft Defender XDR コネクタの設定を確認する | インシデントとアラートの同期が有効か |
| 3 | Tenant-based Microsoft Defender for Cloud コネクタを確認する | Content Hub の Microsoft Defender for Cloud solution が更新済みか |
| 4 | Legacy コネクタの利用状況を確認する | Subscription-based コネクタに依存するクエリやルールがあるか |
| 5 | Defender for Cloud 由来のインシデントを実データで確認する | Sentinel 側で関連アラート、エンティティ、クラウドリソースが見えるか |
| 6 | 分析ルールと自動化ルールを見直す | 二重インシデント化、想定外クローズ、通知重複がないか |
| 7 | SOC 手順書を更新する | 調査開始点、担当者、クローズ基準を Defender XDR 統合後の状態に合わせる |
この手順で重要なのは、設定変更そのものよりも、SOC が実際に使う画面とクエリで確認することです。コネクタが有効でも、分析ルールやダッシュボードが旧フィールド前提のままだと、運用現場では「見えているのに使えない」状態になります。
よくある失敗と回避策
インシデントは表示されるが、関連アラートやエンティティが空になる
もっとも起こりやすい失敗です。Microsoft Defender XDR コネクタが Defender for Cloud のインシデントを Sentinel に持ってきても、Defender for Cloud 側のデータコネクタが適切に構成されていないと、関連アラートやエンティティが表示されない可能性があります。Microsoft Defender XDR と Sentinel の統合ドキュメントでも、Defender for Cloud インシデントのアラートやエンティティを同期するには、Sentinel 側で Defender for Cloud コネクタを有効にする必要があり、そうしないとインシデントが空に見えると説明されています。(Microsoft Learn)
回避策は、Tenant-based Microsoft Defender for Cloud コネクタを有効化し、Legacy コネクタだけに依存しない構成へ移すことです。
旧コネクタと新コネクタでアラートが重複する
Legacy の Subscription-based コネクタを残したまま Tenant-based コネクタを有効化すると、ログやインシデント運用で重複が起きる可能性があります。Microsoft 公式情報でも、以前から Legacy コネクタを有効化している場合は、ログ内のアラート重複を防ぐために無効化することが推奨されています。(Microsoft Learn)
ただし、停止前には必ず依存関係を確認してください。特に、SecurityAlert を使ったカスタムブック、KQL クエリ、Logic Apps 連携、チケット起票フローがある場合は、どのデータがどの経路で入っているかを確認してから切り替えます。
Sentinel の分析ルールが二重にインシデントを作る
Defender XDR 側で相関済みインシデントが作成される一方、Sentinel 側の Scheduled analytics rule でも同じアラートからインシデントを作ると、SOC のキューが増えます。結果として、担当者が同じ事象を別々に調査し、対応履歴が分散します。
回避策は、Defender for Cloud アラートからインシデントを作る分析ルールを棚卸しし、Defender XDR 由来のインシデントで置き換えられるものを無効化することです。必要なフィルタリングは、Defender ポータルのチューニング機能や Sentinel の自動化ルールで補います。
「アラートだけ欲しい」環境でインシデントまで入ってくる
一部の環境では、Defender for Cloud のアラートを監査や独自分析に使いたいだけで、Defender XDR 由来のインシデントまでは不要というケースがあります。公式情報では、Defender XDR 統合を有効化しているが Defender for Cloud のアラートだけを受け取りたい場合、自動化ルールで Defender for Cloud インシデントを到着後すぐに閉じる方法が示されています。また、それで不十分な場合は、Defender XDR ポータルで Defender for Cloud 統合を完全にオプトアウトし、Legacy の Subscription-based コネクタを使ってアラートを受け取る選択肢も説明されています。(Microsoft Learn)
この判断は、SOC の調査プロセス次第です。Microsoft 推奨の統合運用に寄せるなら Tenant-based コネクタを使い、サブスクリプション単位の既存運用を維持する明確な理由があるなら Legacy 構成を残す、という切り分けが現実的です。
グローバル環境での実務的な判断基準
グローバル企業や複数リージョンを持つ組織では、単に「新しいコネクタを有効にする」だけでは不十分です。テナント、ワークスペース、SOC の担当範囲を合わせて設計する必要があります。
判断基準は次の通りです。
| 判断軸 | Tenant-based コネクタが向くケース | Subscription-based Legacy を残す理由があり得るケース |
|---|---|---|
| 管理単位 | テナント全体で統一監視したい | 国・事業部・環境ごとに明確に分離したい |
| サブスクリプション数 | 多い、増減が頻繁 | 少数で固定されている |
| SOC 運用 | Defender XDR と Sentinel を統合運用したい | Sentinel の既存クエリやレポートを優先したい |
| 調査方法 | インシデント中心で相関情報を活用したい | アラート単位で独自分析したい |
| 移行余力 | コネクタ、ルール、手順書を見直せる | 短期的に既存運用を変えにくい |
多くの組織では、中長期的には Tenant-based コネクタを中心に設計した方が管理負荷を下げやすくなります。一方で、監査要件やデータ分離要件が強い環境では、移行前にワークスペース設計と RBAC を確認する必要があります。
Defender for Cloud と Defender XDR の統合では、Defender for Cloud のアラートや相関情報を表示する権限はテナント全体に関わります。公式情報では、特定サブスクリプションの表示はサブスクリプション ID フィルターで行うこと、統合の利用には Defender for Cloud 向けの Microsoft Defender XDR Unified RBAC ロール、または Global Administrator / Security Administrator が必要であることが説明されています。(Microsoft Learn)
今すぐ実施すべきチェックリスト
最後に、管理者が次に取るべき行動をチェックリストとして整理します。
| 優先度 | チェック項目 | 完了の目安 |
|---|---|---|
| 高 | Microsoft Defender XDR コネクタでインシデント同期が有効か確認する | Defender XDR 由来のインシデントが Sentinel に表示される |
| 高 | Tenant-based Microsoft Defender for Cloud コネクタを確認する | テナント全体の Defender for Cloud アラートが対象になる |
| 高 | Legacy の Subscription-based コネクタの有無を確認する | 重複取り込みリスクを把握できている |
| 高 | Defender for Cloud アラートからインシデントを作る分析ルールを棚卸しする | 二重インシデント化を防げる |
| 中 | 自動化ルール、通知、チケット起票の条件を見直す | インシデント名依存などの脆い条件を避ける |
| 中 | SOC の一次調査手順を更新する | Defender XDR 側の攻撃ストーリーやエンティティを活用できる |
| 中 | Sentinel の Defender ポータル移行計画と合わせて見直す | 2027年3月31日以降の運用に備えられる |
今回の「Ingest Microsoft Defender for Cloud incidents with Microsoft Defender XDR integration」は、単なるコネクタ追加ではありません。Defender for Cloud のクラウド検知を、Defender XDR の相関インシデントとして扱い、Microsoft Sentinel で一貫して調査するための設計変更です。
まずは、現在の Sentinel ワークスペースで Defender XDR コネクタ、Tenant-based Defender for Cloud コネクタ、Legacy コネクタ、分析ルールの4点を確認してください。そのうえで、インシデントが表示されるだけでなく、関連アラート、エンティティ、クラウドリソース、ステータス同期まで期待通りに動くかを検証することが、実務で失敗しない移行の第一歩です。
コメント