Microsoft Defender XDR のインシデント相関と統合は、アラートを単体で追うのではなく、攻撃全体の流れとして把握するための重要な仕組みです。2026年6月29日に更新された Microsoft Learn の「Alert correlation and incident merging in the Microsoft Defender portal」では、アラートがどのようにインシデントへまとめられるのか、どの条件でインシデントが自動統合されるのか、手動統合時に何を確認すべきかが整理されています。対象は Microsoft Defender XDR と、Microsoft Defender ポータルに統合された Microsoft Sentinel です。(Microsoft Learn)
結論から言うと、管理者が確認すべきポイントは「相関ルールそのものを細かく編集する」ことではなく、SOC運用で誤った担当割り当て・分類・Sentinel ワークスペース設計・分析ルール設定が、インシデント統合の妨げになっていないかを確認することです。自動相関は Defender 側の内部ロジックで動作するため、管理者は統合されない理由を理解し、必要に応じて手動統合やアラート移動、分析ルールの相関設定を見直す必要があります。
Microsoft Defender のアラート相関とインシデント統合とは
Microsoft Defender のアラート相関とは、複数の検出ソースから届いたアラートを分析し、関連性が高いものを1つのインシデントとしてまとめる仕組みです。Defender は、Microsoft Defender for Endpoint、Defender for Office 365、Defender for Identity、Defender for Cloud Apps、Microsoft Sentinel などから得られるシグナルをもとに、攻撃の流れを「インシデント」として構成します。(Microsoft Learn)
単純なアラート一覧だけでは、SOC担当者は「どのアラートが同じ攻撃に属するのか」を手作業で判断しなければなりません。たとえば、以下のようなイベントが別々に発生すると、個別アラートとしては関連が見えにくくなります。
- フィッシングメールの検出
- ユーザーによる悪性リンクのクリック
- 認証情報の不審な使用
- 端末上での不審なプロセス実行
- 横展開を疑わせるアクセス
Defender の相関エンジンは、これらを同一の攻撃ストーリーとして扱える場合、1つのインシデントにまとめます。これにより、分析担当者は「個々の通知」ではなく「攻撃全体の文脈」を見ながら調査できます。
2026年6月29日更新で押さえるべき変更点
今回の公式情報で重要なのは、インシデント作成後も Defender が継続して関連性を評価し、必要に応じて別々のインシデントを統合する点が明確化されていることです。Defender は、アラートが生成された時点で新規インシデントにするか既存インシデントに追加するかを判断し、その後もインシデント間の共通点を監視します。(Microsoft Learn)
特に実務で確認したいポイントは次の通りです。
| 確認ポイント | 管理者・SOCへの影響 |
|---|---|
| アラート相関は Defender の内部ロジックで実行される | 相関条件を細かく手動定義する運用ではなく、結果を確認して補正する運用が中心 |
| Microsoft Sentinel ワークスペースごとに扱いが異なる | プライマリワークスペースとセカンダリワークスペースで相関範囲が変わる |
| 関連インシデント表示と実際の統合は別物 | 「All associated incidents」に表示されても、統合済みとは限らない |
| 統合されない条件がある | 担当者、分類、ステータス、デバイスグループなどが統合を妨げる可能性がある |
| 手動統合はプレビュー扱い | 本番運用では権限、監査、変更手順を整備して使う必要がある |
この更新は「すぐに設定を変更しなければならない」タイプの告知ではありません。むしろ、既存のインシデント管理プロセスが Defender の自動相関・統合ロジックと矛盾していないかを見直すための運用上のアップデートと捉えるべきです。
アラートはどのようにインシデントへ関連付けられるのか
Defender は、各検出メカニズムからアラートが生成されると、そのアラートを新規インシデントに入れるか、既存インシデントへ追加するかを判断します。公式情報では、一定の時間枠内で十分に一意なアラートであれば新規インシデントを作成し、他のアラートと十分に関連していれば既存インシデントへ追加すると説明されています。相関条件は Defender ポータルの独自の内部ロジックで管理され、インシデント名の付与にも使われます。(Microsoft Learn)
実務上は、次のように理解すると分かりやすくなります。
| アラートの状態 | Defender の動作 | 例 |
|---|---|---|
| 他のアラートと関連性が低い | 新しいインシデントを作成 | 単独端末で検出された不審ファイル |
| 同じ攻撃の一部と判断できる | 既存インシデントへ追加 | フィッシングメール検出後、同じユーザーで不審なサインインが発生 |
| 既存インシデントと後から関連が見つかる | インシデント統合の候補になる | 別々に発生した端末感染と認証情報悪用が同じ攻撃と判断される |
ここで注意したいのは、Defender の相関は「単に同じユーザーだからまとめる」「同じ端末だからまとめる」といった単純な条件だけではない点です。時間軸、エンティティ、証拠、攻撃シーケンスなどをもとに、攻撃ストーリーとして関連があるかを判断します。
Microsoft Sentinel 連携環境での影響範囲
Microsoft Sentinel を Microsoft Defender ポータルに統合している環境では、ワークスペース設計が相関範囲に影響します。複数の Microsoft Sentinel ワークスペースがある場合、Defender ポータルでは1つのワークスペースをプライマリワークスペースとして構成できます。プライマリワークスペースからのアラートは Microsoft Defender のアラートと相関され、同じインシデントに含められる場合があります。(Microsoft Learn)
一方、セカンダリワークスペースのアラートは、Defender や他の Defender ポータルのデータソース、他の Sentinel ワークスペースのアラートとは相関されません。つまり、グローバル企業で地域別・事業部別・MSSP別に Sentinel ワークスペースを分けている場合、どのワークスペースをプライマリにするかが、インシデントの見え方に大きく影響します。(Microsoft Learn)
グローバル運用での判断基準
複数ワークスペース環境では、単に「本社のワークスペースをプライマリにする」と決めるのではなく、次の観点で判断するのが現実的です。
| 判断軸 | 推奨される考え方 |
|---|---|
| SOCの主担当組織 | 24時間監視の中心となるSOCが使うワークスペースを優先 |
| インシデントの集約単位 | グローバル横断で攻撃ストーリーを見たいなら、主要な検出データが集まるワークスペースを選ぶ |
| 法規制・データ所在地 | 国や地域ごとのデータ分離要件がある場合、無理に統合しない |
| MSSPとの分担 | 外部委託先が管理するワークスペースと社内SOCの役割分担を明確にする |
| ノイズの多い分析ルール | 相関対象に含めるべきルールと除外すべきルールを整理する |
特に注意すべきなのは、「セカンダリワークスペースのアラートも当然 Defender のインシデントに混ざる」と誤解することです。相関される範囲を把握していないと、SOCが「なぜこのアラートは同じ攻撃としてまとまらないのか」と混乱しやすくなります。
インシデント統合はどの条件で発生するのか
Defender は、別々のインシデントに含まれるアラート間で共通点や関連性を検出した場合、複数のインシデントを1つに統合します。統合の判断には、ユーザー、デバイス、メールボックスなどのエンティティ、ファイルやプロセス、メール送信者などのアーティファクト、時間枠、複数段階の攻撃を示すイベントの並びが使われます。(Microsoft Learn)
たとえば、次のようなケースでは統合される可能性があります。
- Defender for Office 365 がフィッシングメールを検出
- 同じユーザーが悪性リンクをクリック
- Defender for Endpoint が端末上で不審なプロセスを検出
- Microsoft Entra ID 関連のサインイン異常が発生
- その後、別端末へのアクセス試行が見つかる
このような流れは、個別にはメール、ID、エンドポイントのアラートですが、攻撃者の一連の行動としてつながっている可能性があります。Defender はその関連を見つけると、調査しやすいようにインシデントを統合します。
「関連インシデントの表示」と「統合」は別物
今回の内容で誤解しやすいのが、インシデント画面で表示できる「All associated incidents」と、実際のインシデント統合の違いです。
インシデント体験では、関連インシデントの表示を「This incident only」から「All associated incidents」に切り替えることで、調査グラフ上に関連するインシデントやアラートを広げて表示できます。ただし、この表示切り替えはインシデントのグルーピング、相関ルール、統合ロジックを変更しません。表示されたインシデントは、実際に統合されるまで、それぞれ独自の所有者、ステータス、ライフサイクルを持ち続けます。(Microsoft Learn)
運用上は、次のように使い分けるとよいでしょう。
| 機能 | 目的 | 注意点 |
|---|---|---|
| This incident only | 現在のインシデントだけを調査する | 関連攻撃の全体像を見落とす可能性がある |
| All associated incidents | 関連するインシデントまで広げて文脈を見る | 表示されても統合されたわけではない |
| インシデント統合 | 複数インシデントを1つの管理単位にまとめる | 所有者、分類、監査ログへの影響を確認する |
SOCの初動では「All associated incidents」で広く確認し、実際に同一攻撃として扱うべきと判断した場合に統合を検討する流れが現実的です。
インシデント統合時に何が移動・変更されるのか
インシデントが統合されると、新しいインシデントが作成されるわけではありません。ソースインシデントの内容がターゲットインシデントへ移行され、ソースインシデントは自動的にクローズされます。ソースインシデントは Defender ポータル上では表示・利用できなくなり、参照はターゲットインシデントへリダイレクトされます。一方、Microsoft Sentinel の Azure ポータル側では、クローズ済みのソースインシデントにアクセスできます。(Microsoft Learn)
統合方向、つまりどちらがソースでどちらがターゲットになるかは Microsoft Defender が内部ロジックで決定します。手動統合の場合でも、ユーザーが統合方向を指定することはできません。(Microsoft Learn)
| 項目 | 統合時の扱い |
|---|---|
| アラート | ソースインシデントから削除され、ターゲットインシデントへ追加される |
| タグ | ソースから削除され、ターゲットへ追加される |
| ソースインシデント | Redirected タグが追加され、自動クローズされる |
| エンティティ | 関連付くアラートに従って移動する |
| 分析ルール情報 | ソース作成に関与した分析ルールがターゲット側へ追加される |
| コメント・アクティビティログ | 移行はプレビュー扱い。プレビューにアクセスできない場合は Sentinel の Azure ポータル側で確認する |
実務で特に注意したいのは、監査やレビューのためにインシデントIDを外部チケットシステムへ連携している場合です。統合後は参照先が変わるため、ServiceNow、Jira、Azure DevOps、社内SOC台帳などと連携している組織では、統合後のターゲットインシデントIDを記録できるようにしておく必要があります。
インシデントが統合されない主な条件
Defender の相関ロジック上は関連があると判断されても、特定の条件に該当するとインシデントは統合されません。公式情報では、クローズ済みインシデント、異なる担当者、異なる分類や判定、エンティティ数の上限超過、組織が定義した異なるデバイスグループに属するデバイスを含む場合などが挙げられています。デバイスグループ条件は既定では有効ではなく、有効化が必要です。(Microsoft Learn)
| 統合されない条件 | 現場で起きやすい例 | 対応の考え方 |
|---|---|---|
| 片方が Closed | 先に誤検知として閉じたが、後続アラートで関連が判明 | 本当にクローズしてよいか、初動時の基準を見直す |
| 担当者が異なる | 地域SOCと本社SOCで別々にアサイン | 統合前に担当者をそろえる、または片方を未割り当てにする |
| 分類・判定が異なる | 一方は True positive、もう一方は False positive | 分類ルールをチームで統一する |
| エンティティ数の上限を超える | 大量端末に広がる攻撃やメールキャンペーン | 大規模インシデントでは統合前に範囲を慎重に確認 |
| 異なるデバイスグループ | 部門別・地域別のデバイス分離をしている | デバイスグループ設計と統合ポリシーを合わせる |
この中で最もよく運用トラブルにつながるのは、担当者と分類です。担当者が違うだけで統合されない場合、SOCは「Defender の相関が効いていない」と誤解しがちです。実際には、運用上の管理項目が統合を止めている可能性があります。
手動統合はいつ使うべきか
自動統合されなかったインシデントでも、根本原因を解消すれば手動統合できます。公式情報では、手動統合はプレビュー機能として説明されており、現在は最大5件のインシデントを同時に手動統合できます。(Microsoft Learn)
手動統合を使うべき代表的なケースは、次のような場面です。
- 同じ攻撃だと分析担当者が判断したが、自動統合されていない
- 担当者や分類の違いが理由で統合されていない
- メール、ID、端末のアラートが別インシデントに分かれている
- 外部チケットでは1件のセキュリティインシデントとして管理したい
- 監査ログや調査履歴をできるだけ1つのインシデントに集約したい
手動統合は、アラートを別インシデントへ移動するよりも、インシデント情報を保持しやすい方法として説明されています。手動統合の前提として、対象インシデントを閲覧する権限と読み書き権限が必要であり、統合候補の Assigned to、Classification、Determination は同じ値、または少なくとも片方が空である必要があります。(Microsoft Learn)
手動統合前のチェックリスト
| チェック項目 | 確認内容 |
|---|---|
| 同一攻撃として扱えるか | 時間軸、対象ユーザー、端末、メール、プロセス、IPアドレスを確認する |
| 担当者が矛盾していないか | Assigned to が異なる場合は統合前に調整する |
| 分類・判定が矛盾していないか | True positive と False positive が混在していないか確認する |
| 監査ログを残す必要があるか | 統合理由をコメントに明確に書く |
| 外部チケットと連携しているか | 統合後のターゲットインシデントIDを記録する |
| 関係者に通知が必要か | 地域SOC、MSSP、CSIRT、法務などへの影響を確認する |
手動統合は便利ですが、誤って無関係なインシデントを統合すると、調査の優先順位や影響範囲の判断が崩れます。特にランサムウェア、BEC、内部不正、クラウド侵害のように関係者が多いケースでは、統合前に短い判断メモを残す運用を推奨します。
アラート移動とインシデント統合の使い分け
Defender では、アラートをあるインシデントから別のインシデントへ移動することもできます。すべてのアラートは必ずいずれかのインシデントに属するため、移動する場合は既存インシデントへリンクするか、その場で新しいインシデントを作成します。(Microsoft Learn)
ただし、インシデント全体が同一攻撃を表しているなら、アラート単位で移動するよりもインシデント統合を優先した方が自然です。
| やりたいこと | 適した操作 |
|---|---|
| 1つのアラートだけ誤ったインシデントに入っている | アラート移動 |
| 複数のインシデントが同じ攻撃を表している | インシデント統合 |
| 調査履歴や活動ログをできるだけ残したい | インシデント統合 |
| 既存インシデントから一部だけ切り離したい | アラート移動 |
| SOCの管理単位を1件に集約したい | インシデント統合 |
判断基準は「アラートの入れ間違いを直すのか、攻撃ストーリー全体を1つにまとめるのか」です。前者ならアラート移動、後者ならインシデント統合を検討します。
分析ルールの相関設定を見直すべきケース
Microsoft Sentinel の分析ルールを Defender ポータルで扱う場合、分析ルールごとに相関対象へ含めるか除外するかを制御できます。公式情報では、テナント全体の既定設定に加え、個別ルールを UI、説明文タグ、API で制御できることが説明されています。(Microsoft Learn)
既定設定は、Microsoft Defender ポータルの System > Settings > Microsoft Defender XDR > Rules > Incident correlation で切り替えます。この既定設定はオフが既定で、オフの場合は明示的に #INC_CORR# タグを付けた分析ルールだけが相関対象になります。オンの場合は、#DONT_CORR# タグを付けたルールを除き、分析ルールが相関対象になります。(Microsoft Learn)
相関対象に含めるべきルール
次のようなルールは、Defender の相関に含める価値があります。
- 攻撃チェーンの一部になりやすい認証異常
- エンドポイント感染と関係しやすい不審プロセス
- フィッシング後のアカウント悪用
- 横展開や権限昇格の兆候
- クラウドリソースへの不審なアクセス
これらは単独で見るよりも、他の Defender アラートと組み合わせた方が攻撃全体を把握しやすくなります。
相関から除外を検討すべきルール
一方で、次のようなルールは除外を検討する余地があります。
- 毎日大量に発生する情報通知に近いルール
- 業務上の既知イベントを検出するルール
- 監査目的で作成した低重要度のルール
- 既存の Sentinel 側グルーピングを維持したいルール
- 相関されるとインシデントが過度に大きくなるルール
ただし、除外しすぎると Defender XDR の強みである横断的な攻撃ストーリーが見えにくくなります。最初から広範囲に除外するのではなく、ノイズが多いルールから順番に見直すのが安全です。
設定変更・移行期限の有無
2026年6月29日更新の「Alert correlation and incident merging in the Microsoft Defender portal」自体は、管理者に即時の強制設定変更を求める内容ではありません。また、当該ページの記載範囲では、この機能に関する明示的な移行期限や廃止期限は示されていません。ページの最終更新日は 2026年6月29日です。(Microsoft Learn)
ただし、関連機能にはプレビュー扱いのものがあります。特に、手動でのインシデント統合、コメントやアクティビティログの移行などはプレビューとして扱われているため、本番運用に組み込む際は次のような前提で考えるべきです。
| 項目 | 現時点での扱い | 管理者の対応 |
|---|---|---|
| 自動アラート相関 | Defender の標準動作 | 相関結果を前提にSOC手順を整える |
| インシデント自動統合 | Defender の標準動作 | 統合されない条件を理解する |
| 手動インシデント統合 | プレビュー | 利用範囲、権限、監査手順を決めてから使う |
| コメント・活動ログ移行 | プレビュー | 必要に応じて Sentinel の Azure ポータル側も確認する |
| 分析ルール相関設定 | テナント設定・ルール設定で制御可能 | ノイズの多いルールから見直す |
グローバル展開している組織では、プレビュー機能を全SOCで一斉に使うのではなく、まず1つの運用チームや地域で手順を固めてから展開する方が安全です。
管理者が今すぐ確認すべきポイント
今回の更新を受けて、Microsoft Defender 管理者やSOCリーダーは、次の順序で確認すると実務に落とし込みやすくなります。
インシデント管理ルールを確認する
まず、インシデントの Assigned to、Status、Classification、Determination の運用ルールを確認します。これらの値がチームごとにバラバラだと、関連するインシデントが統合されない原因になります。
たとえば、一次対応チームが暫定的に False positive を付け、二次対応チームが True positive と判断する運用では、統合に失敗する可能性があります。分類は調査完了後に確定する、暫定判断にはコメントを残す、といったルールを決めておくと混乱を減らせます。
Sentinel ワークスペース構成を確認する
複数の Microsoft Sentinel ワークスペースを Defender ポータルにオンボードしている場合、どのワークスペースがプライマリかを確認します。セカンダリワークスペースのアラートは Defender アラートと相関されないため、グローバルSOCで一元的に攻撃を追う場合は設計上の前提を明確にしておく必要があります。(Microsoft Learn)
手動統合の権限を確認する
手動統合を行うユーザーには、対象インシデントの閲覧権限と読み書き権限が必要です。インシデントはソースによって RBAC ロールが異なる場合があるため、Defender XDR と Sentinel の権限設計をあわせて確認します。(Microsoft Learn)
分析ルールの相関設定を棚卸しする
Sentinel の分析ルールを多数運用している場合、どのルールを Defender の相関対象に含めるべきかを棚卸しします。特に、監査目的の低重要度ルールや大量発生する通知系ルールは、相関対象に含めることでインシデントが肥大化する可能性があります。
一方で、認証侵害、横展開、メール起点の攻撃、クラウド侵害に関わるルールは、相関に含めた方が攻撃ストーリーを把握しやすくなります。
外部チケット連携を確認する
インシデント統合後、ソースインシデントは Defender ポータルでターゲットインシデントへリダイレクトされます。外部チケットやレポートに旧インシデントIDだけを記録していると、後から追跡しづらくなる可能性があります。(Microsoft Learn)
ServiceNow、Jira、Teams通知、メール通知、SIEM/SOAR連携などを使っている場合は、統合イベントをどう扱うかを確認しておきましょう。
失敗しやすい運用パターン
Microsoft Defender の相関と統合は強力ですが、運用設計が追いついていないと、かえって混乱を招きます。特に次のパターンには注意が必要です。
| 失敗パターン | 起きる問題 | 改善策 |
|---|---|---|
| すぐに Closed にしてしまう | 後続インシデントと統合されない | 初動ではステータス変更を慎重に行う |
| 担当者を細かく分けすぎる | 統合条件に引っかかる | チーム単位の所有者やエスカレーションルールを設計する |
| 分類ルールが曖昧 | True positive / False positive の差で統合されない | 分類の確定タイミングを標準化する |
| Sentinel ワークスペース構成を理解していない | 想定した相関が発生しない | プライマリ・セカンダリの違いをSOC手順に明記する |
| ノイズの多い分析ルールを相関対象にする | インシデントが肥大化する | ルール単位で相関設定を見直す |
| 手動統合理由を残さない | 監査や引き継ぎで判断根拠が分からない | 統合時のコメントを必須化する |
独自の観点として、インシデント相関は「検出精度」だけでなく「組織の判断ルール」にも左右されます。Defender の自動化を最大限に活かすには、SOCの分類基準、権限設計、チケット管理、Sentinel ワークスペース設計をセットで整える必要があります。
実務で使える確認手順
Microsoft Defender 管理者が今回の内容を運用に反映するなら、次の手順で確認すると効率的です。
| 手順 | 作業内容 | 目的 |
|---|---|---|
| 1 | 直近30日間のインシデント統合履歴を確認 | どのようなケースで統合されているか把握する |
| 2 | 統合されなかった関連インシデントを数件レビュー | 担当者、分類、ステータスの問題を見つける |
| 3 | Microsoft Sentinel のプライマリワークスペースを確認 | 相関範囲の誤解をなくす |
| 4 | ノイズの多い分析ルールを抽出 | 相関除外候補を洗い出す |
| 5 | 手動統合の利用権限を確認 | 誰が統合作業をできるか明確にする |
| 6 | SOC手順書に統合判断基準を追記 | 属人的な判断を減らす |
| 7 | 外部チケット連携の挙動をテスト | 統合後の追跡性を確保する |
この確認は、単発の設定作業ではなく、インシデント対応品質を上げるための運用改善として進めるのが効果的です。
Microsoft Defender 管理者向けの推奨アクション
今回の更新を踏まえ、管理者は次の3点を優先して対応するとよいでしょう。
第一に、インシデント統合を妨げる運用項目を標準化することです。Assigned to、Classification、Determination、Status の扱いがチームごとに違うと、自動統合の効果が弱まります。
第二に、Microsoft Sentinel 連携環境の相関範囲を確認することです。特に複数ワークスペースを使うグローバル環境では、プライマリワークスペースだけが Defender アラートと相関される点をSOC手順に明記しておくべきです。
第三に、手動統合と分析ルール相関設定を、限定的かつ監査可能な形で運用することです。手動統合は便利ですが、誤用すると調査範囲や責任分界が曖昧になります。統合理由のコメント、承認ルール、外部チケット更新をセットにして運用しましょう。
Microsoft Defender の「Alert correlation and incident merging」は、設定画面を1つ変更すれば終わる機能ではありません。アラートを攻撃ストーリーとして扱うための土台です。まずは既存のインシデント管理ルール、Sentinel ワークスペース設計、分析ルールの相関設定を棚卸しし、Defender の自動相関が正しく活きるSOC運用に整えることが、今回の更新を実務に活かす最短ルートです。
コメント