Microsoft DefenderとMicrosoft Sentinelを併用している環境では、アラートが複数のインシデントに分散し、「どこまでを同じ攻撃として扱うべきか」の判断が難しくなります。2026年5月14日に更新された公式情報「Relate alerts to incidents in Microsoft Sentinel in the Azure portal」の要点は、Azure portal上のMicrosoft Sentinelで、調査中のインシデントに関連アラートを追加・削除し、インシデントの範囲を調整できる点にあります。(Microsoft Learn)
ただし、最初に確認すべき結論はシンプルです。Microsoft SentinelワークスペースをDefender portalへオンボード済みかどうかで、管理できる場所と制約が変わります。 Azure portalで従来どおり調査している環境では、エンティティタイムライン、調査グラフ、プレイブック、APIを使ってアラートとインシデントの関連付けを調整できます。一方、Defender portalへ移行済みの環境では、Microsoft Sentinelアラートの追加・削除はDefender portal側での操作が前提になります。(Microsoft Learn)
まず押さえるべき変更点
今回の公式情報は、単に「アラートをインシデントに追加する手順」を説明しているだけではありません。SOC運用、プレイブック、自動化、API連携、Defender portalへの移行計画に影響する実務上のポイントが含まれています。
特に重要なのは、次の4点です。
| 確認項目 | 要点 | 実務上の影響 |
|---|---|---|
| 操作場所 | Azure portal版Microsoft Sentinelでアラートをインシデントに関連付けられる | 調査中にインシデントの範囲を後から広げたり狭めたりできる |
| プレビュー扱い | Incident expansionはプレビュー機能 | 本番運用では仕様変更の可能性を前提に手順化する |
| Defender portalオンボード後 | 追加・削除の扱いがDefender portal中心になる | 既存のAzure portal前提のSOC手順を見直す必要がある |
| 上限 | 1つのインシデントに含められるアラートは最大150件 | 大規模インシデントでは分割・優先順位付けが必要 |
公式ドキュメントでは、この機能を「調査が進むにつれてインシデントのスコープを調整するための機能」と位置付けています。つまり、初期検知時点で完璧なインシデント構成を期待するのではなく、調査中に関連アラートを見つけ、必要に応じてインシデントへ追加する運用を想定しています。(Microsoft Learn)
Microsoft Defender環境で何が便利になるのか
Microsoft Defender XDR、Microsoft Defender for Cloud、サードパーティ製品などを組み合わせている環境では、同じ攻撃キャンペーンに関係するアラートが別々のデータソースから発生します。
たとえば、次のようなケースです。
| 状況 | 従来起こりやすい問題 | アラート関連付けでできること |
|---|---|---|
| Defender XDRでユーザー侵害を検知 | Sentinel側のクラウド設定変更アラートと分断される | 同じインシデントに追加して攻撃の流れを把握する |
| Defender for Cloudで不審なVM操作を検知 | エンドポイント側のアラートと別管理になる | 影響ホスト・ユーザー・IPを軸に関連付ける |
| サードパーティSIEM/EDR由来のアラートがある | Sentinelインシデントとの関係が見えにくい | 調査グラフやエンティティタイムラインから追加する |
| 手動作成したインシデントで調査している | 後から見つけたアラートを紐づけにくい | プレイブックやAPIで関連アラートを追加できる |
この機能の価値は、「アラートをまとめること」そのものではありません。インシデントの範囲を適切に調整し、アナリストが同じ攻撃の文脈で判断できるようにすることです。
アラートをむやみに1つのインシデントへ集約すると、逆に調査が複雑になります。実務では、共通するエンティティ、発生時刻、攻撃手法、影響範囲を見て、同じインシデントに含めるべきか判断する必要があります。
対象となる管理者・開発者
この更新内容を確認すべきなのは、Microsoft Sentinelの画面を使うSOCアナリストだけではありません。Defender portalへの移行、Logic Appsによる自動化、REST API連携に関わる担当者も影響を受けます。
| 対象者 | 確認すべきポイント |
|---|---|
| SOCアナリスト | エンティティタイムラインや調査グラフから、関連アラートを正しく追加・削除できるか |
| Sentinel管理者 | ワークスペースがDefender portalへオンボード済みか、Azure portal運用のままか |
| セキュリティアーキテクト | Defender portal移行後のインシデント相関、データコネクタ、権限設計 |
| 自動化担当者 | プレイブックでアラート追加・削除を使っているか |
| 開発者・連携担当者 | Microsoft Sentinel APIまたはMicrosoft Graph APIを使った連携の見直し |
| MSSP・複数テナント管理者 | ワークスペース単位、テナント単位で操作場所や相関の挙動が変わらないか |
Defender portalへ移行すると、Microsoft SentinelとMicrosoft Defender XDRの統合体験が強化されます。一方で、インシデント名、プロバイダー名、相関エンジン、プレイブック実行タイミングなど、既存運用に影響する点があります。Microsoftは、移行時にSOCプロセスやアナリスト教育を見直すことを推奨しています。(Microsoft Learn)
Azure portalでアラートをインシデントに追加する主な方法
Azure portal版Microsoft Sentinelで、アラートをインシデントに関連付ける方法は大きく4つあります。
エンティティタイムラインから追加する
エンティティタイムラインでは、インシデントに含まれるユーザー、ホスト、IPアドレスなどのエンティティを起点に、関連するアラートを確認できます。外部アラートは、開いているインシデントにまだ含まれていないアラートとして表示されます。
実務では、次のような判断に向いています。
| 使う場面 | 具体例 |
|---|---|
| 特定ユーザーを軸に調査する | 同じユーザーで発生したサインイン異常、メール脅威、端末アラートを確認する |
| 端末侵害を追う | 1台のホストに紐づくEDR、クラウド、ID関連アラートを確認する |
| 攻撃の時系列を補完する | 初期侵入前後に発生した別アラートを同じインシデントに追加する |
公式手順では、Microsoft Sentinelの「Incidents」から対象インシデントを開き、「Entities」タブでエンティティを選択し、タイムライン上の外部アラートを追加します。追加されたアラートはインシデントの一部となり、そのアラートに含まれるエンティティもインシデントに加わります。(Microsoft Learn)
調査グラフから追加する
調査グラフは、エンティティやアラートの関係を視覚的に追うための機能です。アラート同士の関係や、エンティティを介したつながりを確認しながら、関連アラートをインシデントへ追加できます。
エンティティタイムラインが「時系列で見る」機能だとすれば、調査グラフは「関係性で見る」機能です。
たとえば、次のような調査に向いています。
| 調査観点 | 見るべき関係 |
|---|---|
| 横展開の疑い | 同じアカウントが複数ホストにアクセスしていないか |
| 権限昇格の疑い | 管理者アカウント、特権操作、関連端末がつながっていないか |
| クラウド侵害 | IPアドレス、ユーザー、アプリ、ストレージ操作が同じ流れにあるか |
調査グラフでは、関連アラートが点線で表示され、インシデントに追加すると関係線やタイムライン上の表示が変わります。視覚的に「このアラートは調査対象に含まれた」と分かるため、複数人でインシデント対応するSOCでは認識合わせに役立ちます。(Microsoft Learn)
プレイブックで自動的に追加・削除する
Microsoft Sentinelのプレイブックは、Azure Logic Appsをベースにした自動化機能です。公式情報では、Microsoft SentinelコネクタのLogic Appsアクションとして、インシデントへのアラート追加・削除が利用できると説明されています。必要なパラメーターは、インシデントのARM IDとシステムアラートIDです。(Microsoft Learn)
プレイブックを使うと、たとえば次のような自動化が考えられます。
| 自動化例 | 目的 |
|---|---|
| 同じユーザーで一定時間内に発生した高重大度アラートを追加 | アカウント侵害の調査範囲を自動で広げる |
| 同じホストに紐づくEDRアラートを追加 | 端末侵害の全体像を見やすくする |
| 手動作成インシデントに関連アラートを追加 | ハンティング起点の調査をインシデント化する |
| 条件を満たさないアラートを削除 | 誤検知や無関係なアラートを調査対象から外す |
ただし、プレイブックで自動追加する場合は、条件を広げすぎないことが重要です。「同じIPアドレス」「同じユーザー」だけで機械的にまとめると、NAT環境、共有端末、サービスアカウントなどで無関係なアラートを巻き込む可能性があります。
実務では、少なくとも次の条件を組み合わせるのが安全です。
| 条件 | 判断基準の例 |
|---|---|
| 時間範囲 | 同一インシデントに追加するのは前後数時間などに限定する |
| 重大度 | Medium以上、High以上など優先度を決める |
| エンティティ | ユーザー、ホスト、IP、クラウドリソースの一致を見る |
| アラート種別 | 同じ攻撃段階や関連する検知ルールに限定する |
| 除外条件 | 既知のスキャナー、監視アカウント、定常処理を除外する |
APIで関連付けを作成・削除する
ポータル操作だけでなく、Microsoft Sentinel APIでもアラートとインシデントの関係を操作できます。公式情報では、Incident relationsの操作グループを使い、関係の作成、更新、削除、一覧取得が可能とされています。(Microsoft Learn)
開発者やSIEM連携担当者が特に注意すべきなのは、単にAPIエンドポイントを呼び出せばよいわけではない点です。次のようなエラー条件が明示されています。
| エラーになりやすい条件 | 実務での対策 |
|---|---|
| 同じアラートが既にインシデントに存在する | 追加前に関連付け一覧を取得する |
| 関連リソースとインシデントが別ワークスペースにある | workspaceNameとresourceGroupNameを確認する |
| 存在しないsystemAlertIdを指定している | アラートIDの取得元と形式を確認する |
| Microsoft Defender XDRアラートをDefender XDRインシデントへ追加・削除しようとする | Defender portal側の相関・管理ルールを前提にする |
| relationNameが重複している | 一意なrelationNameを生成する |
API連携を本番展開する場合は、追加処理だけでなく、重複チェック、失敗時の再試行、監査ログ、運用者への通知まで設計しておくべきです。
アラートを削除するときの注意点
アラートの削除は、インシデント対応で意外にトラブルになりやすい操作です。理由は、アラートを外すことで調査範囲が狭まり、後から「なぜこのアラートを除外したのか」が問われるためです。
Azure portal版Microsoft Sentinelでは、手動または自動で追加されたアラートをインシデントから削除できます。公式手順では、インシデントのOverviewタブにあるIncident timelineから対象アラートのメニューを開き、Remove alertを選択します。(Microsoft Learn)
削除前には、次の観点を確認してください。
| 確認項目 | 理由 |
|---|---|
| 本当に無関係なアラートか | 同じ攻撃の別段階を示している可能性がある |
| 削除理由を記録したか | 後続担当者や監査対応で説明できるようにする |
| 自動化で再追加されないか | プレイブック条件が残っていると再び追加される可能性がある |
| 他のインシデントとの関係はどうか | アラートは複数インシデントに関連付けられる場合がある |
| Defender portal側の制約に該当しないか | オンボード済み環境では操作場所が変わる |
削除は「なかったことにする」操作ではなく、「このインシデントの調査範囲から外す」操作です。チーム運用では、コメントやチケットに判断理由を残すことを推奨します。
Defender portalへオンボード済みの場合の影響
最も注意すべきポイントは、Microsoft SentinelをDefender portalへオンボードした後の挙動です。
公式情報では、Microsoft SentinelをDefender portalへオンボードした後、Microsoft Sentinelアラートをインシデントに追加・削除する操作はDefender portalでのみサポートされると説明されています。また、Defender portalでアラートをインシデントから外すには、そのアラートを別のインシデントへ追加する必要があります。(Microsoft Learn)
つまり、Azure portalを前提にした既存手順がそのまま使えない可能性があります。
| 項目 | Azure portal中心の運用 | Defender portalオンボード後の注意 |
|---|---|---|
| インシデント調査 | SentinelのIncidentsで対応 | Defender portalの統合インシデントキューを前提に見直す |
| アラート追加・削除 | Azure portalから操作できるケースがある | Defender portal側での管理が中心 |
| Defender XDRインシデント | Azure portalから一部確認できる | Defender portalでの管理が前提 |
| 相関・マージ | Sentinel側のルールやFusionを意識 | Defender XDRエンジンの相関ロジックを考慮 |
| 自動化 | Sentinelプレイブック中心 | 実行タイミングやサポート範囲を再確認 |
Microsoftの移行ガイダンスでは、Defender portalへの移行後、Microsoft Sentinelのデータ収集やLog Analyticsの基本的な取り込み構造は維持される一方、インシデントやアラートの扱い、相関、プレイブック、APIには変更点があると説明されています。(Microsoft Learn)
管理者が確認すべき設定
Microsoft DefenderとMicrosoft Sentinelの運用管理者は、まず自社環境がどちらの状態にあるかを確認してください。
ワークスペースのオンボード状態
最初に見るべきなのは、Microsoft SentinelワークスペースがDefender portalへオンボード済みかどうかです。
| 状態 | 対応方針 |
|---|---|
| Azure portalのみで運用 | 公式手順に沿ってAzure portalでの追加・削除手順を整備する |
| Defender portalへオンボード済み | Defender portalでのインシデント運用に手順を寄せる |
| 移行を検討中 | アラート関連付け、プレイブック、API、権限を移行前に棚卸しする |
| 複数ワークスペース運用 | ワークスペースごとのオンボード状態と相関範囲を確認する |
オンボード状態を確認せずに手順書を作ると、アナリストが「画面にボタンがない」「APIでは成功しない」「プレイブックが想定どおり動かない」といった問題に遭遇しやすくなります。
Microsoft Defender XDRコネクタ
Defender製品のアラートをSentinelで扱う場合、Microsoft Defender XDRコネクタの設定も確認が必要です。移行ガイダンスでは、Defender製品関連のアラートはMicrosoft Defender XDRコネクタからストリーミングされるため、ワークスペースでインシデントとアラートが有効になっていることを確認するよう説明されています。(Microsoft Learn)
特に確認したいのは次の点です。
| 確認項目 | チェック内容 |
|---|---|
| コネクタ状態 | Microsoft Defender XDRコネクタが接続済みか |
| インシデント同期 | インシデントとアラートの取り込みが有効か |
| 重複取り込み | Defender for Cloudなどで重複イベントが発生していないか |
| スキーマ差分 | 移行後にアラートスキーマが変わる可能性を考慮しているか |
| オフボード時の影響 | Defender portalから外した場合のコネクタ影響を理解しているか |
権限とRBAC
アラートをインシデントに追加・削除できる操作は、調査範囲やインシデントの状態に直接影響します。誰でも実行できるようにするのではなく、SOCの役割に応じて権限を設計する必要があります。
たとえば、Tier 1アナリストは候補アラートの確認まで、Tier 2アナリストは追加・削除まで、インシデントマネージャーはクローズや他インシデントとの整理まで、という分担が考えられます。
| 役割 | 推奨される運用 |
|---|---|
| Tier 1 | 関連アラート候補の確認、コメント記録 |
| Tier 2 | アラート追加・削除、影響範囲の再評価 |
| インシデント責任者 | 他インシデントとの統合判断、クローズ判断 |
| 自動化担当 | プレイブック条件、API連携、監査ログの管理 |
| 管理者 | 権限、コネクタ、移行方針の管理 |
Defender portal移行時は、Microsoft SentinelとDefender XDRの権限管理が統合運用に近づくため、既存のAzure RBACだけでなく、Defender側のロール設計も確認してください。
開発者が確認すべきAPI・自動化の注意点
開発者や自動化担当者は、画面操作よりも「どのAPIで、どのインシデントを、どの状態として扱うか」に注意が必要です。
Microsoftの移行ガイダンスでは、統合インシデントやアラートを扱う場合、Microsoft Graph REST APIの利用が推奨されています。一方、Microsoft Sentinel APIは、分析ルールや自動化ルールなどSentinelリソースへの操作を引き続きサポートします。(Microsoft Learn)
API連携では、次のような観点で棚卸ししてください。
| 棚卸し項目 | 確認内容 |
|---|---|
| 使用API | Microsoft Sentinel SecurityInsights APIか、Microsoft Graph APIか |
| 対象データ | Sentinelインシデントか、統合されたDefender incidentか |
| URL項目 | incidentUrl、providerIncidentUrlなどをチケット連携に使っていないか |
| プロバイダー名 | providerNameの変化を条件分岐に使っていないか |
| アラート展開 | alertProductNames取得に追加展開が必要か |
| 自動化条件 | インシデント名や説明文に依存していないか |
特に、インシデント名を条件にした自動化は避けたほうが安全です。Defender portalでは相関エンジンによりインシデント名が変わる可能性があるため、分析ルール名、タグ、エンティティ、重大度など、変化しにくい条件を組み合わせるほうが安定します。(Microsoft Learn)
移行前に見直すべきSOC手順
Defender portalへの移行を予定している組織では、アラート関連付けの機能を単体で見るのではなく、SOC全体の作業フローとして見直すことが重要です。
既存手順書の見直し
Azure portal版Microsoft Sentinelを前提にした手順書には、次のような記述が含まれていることがあります。
| 既存手順の例 | 見直しポイント |
|---|---|
| SentinelのIncidents画面でアラートを追加する | Defender portal移行後も同じ操作が可能か |
| Incident providerがAzure Sentinelの場合のみ処理する | 移行後にproviderNameが変わらないか |
| インシデント名で自動化ルールを分岐する | 相関後の名称変更に耐えられるか |
| Descriptionフィールドを外部チケットに同期する | 移行後に必要な項目が取得できるか |
| 手動作成インシデントをDefender側で扱う | 同期対象や表示場所を確認する |
手順書は画面キャプチャだけでなく、「なぜそのアラートを追加するのか」「どの条件なら削除するのか」という判断基準まで書くと、アナリスト間のばらつきを減らせます。
プレイブックの影響確認
Defender portal移行後は、プレイブックや自動化ルールの実行タイミングにも注意が必要です。移行ガイダンスでは、Microsoft DefenderインシデントがMicrosoft Sentinelに表示されるまでに時間がかかる場合があり、それに伴ってプレイブックの起動も遅れる可能性があると説明されています。(Microsoft Learn)
次のようなプレイブックは、移行前に必ずテストしてください。
| プレイブック種別 | テスト観点 |
|---|---|
| インシデント作成時に実行 | Defender incidentでも想定どおり起動するか |
| アラート追加時に実行 | 対象アラートの種類に制限がないか |
| 外部チケット作成 | incidentUrlや説明文が正しく連携されるか |
| 自動クローズ | 誤って関連インシデントまで閉じないか |
| Teams通知 | 追加されたアラート情報が通知本文に含まれるか |
本番切り替え前には、実際のアラートではなくテスト用の検知ルールや手動作成インシデントを使い、追加・削除・通知・チケット連携まで一連の流れを確認するのが安全です。
失敗しやすいポイント
アラート関連付けは便利ですが、使い方を誤るとインシデント対応の品質を下げます。特に次の失敗は避けたいところです。
| 失敗例 | 起こる問題 | 対策 |
|---|---|---|
| 関連しそうなアラートをすべて追加する | インシデントが肥大化し、原因分析が難しくなる | 追加基準を時間・エンティティ・攻撃段階で絞る |
| Defender portal移行後もAzure portal手順を使う | 操作できない、または想定と違う挙動になる | オンボード状態別に手順を分ける |
| APIで重複追加を考慮しない | 400エラーや再試行ループが発生する | 事前に関連付け一覧を取得する |
| 上限150件を考慮しない | 大規模インシデントで追加に失敗する | 優先度順に整理し、必要ならインシデントを分ける |
| 削除理由を残さない | 監査や引き継ぎで判断根拠が分からない | コメントやチケットに理由を記録する |
| 自動化条件が広すぎる | 無関係なアラートが巻き込まれる | 除外条件とレビュー工程を入れる |
特に「同じユーザーだから同じインシデント」と判断するのは危険です。サービスアカウント、共有端末、プロキシ、クラウドアプリの代理操作などでは、同じエンティティでも攻撃の文脈が異なる場合があります。
実務で使える判断基準
アラートを同じインシデントに追加するか迷った場合は、次の基準で判断すると整理しやすくなります。
| 判断基準 | 追加を検討する条件 | 追加しないほうがよい条件 |
|---|---|---|
| 時間 | 同じ攻撃フェーズ内、または連続した行動に見える | 数日以上離れており関連性が薄い |
| エンティティ | 同じユーザー、端末、IP、クラウドリソースが関係する | 共通点が汎用的なIPや共有アカウントだけ |
| 攻撃手法 | 認証突破、権限昇格、横展開など流れがつながる | 検知カテゴリがまったく異なる |
| 影響範囲 | 同じ業務システムや同じ部門に影響する | 別部門・別システムで独立している |
| 対応担当 | 同じ担当チームがまとめて対処すべき | 別チームに切り分けたほうが速い |
| 証跡 | ログ上の前後関係を説明できる | 「似ている」以上の根拠がない |
実務では、100%の確信がない段階でも追加することはあります。ただし、その場合は「暫定的に関連あり」「同一ユーザーのため追加、後続調査で再評価」など、判断の状態をコメントに残すと後から見直しやすくなります。
展開時のチェックリスト
本番環境でこの機能を使う前に、次のチェックリストを確認してください。
| チェック項目 | 完了の目安 |
|---|---|
| ワークスペースの状態確認 | Azure portal運用か、Defender portalオンボード済みか分かっている |
| 操作手順の整理 | エンティティタイムライン、調査グラフ、削除手順を文書化している |
| Defender XDRコネクタ確認 | インシデント・アラートの取り込み設定を確認している |
| 権限確認 | 誰が追加・削除できるか決めている |
| プレイブック確認 | 自動追加・削除の条件と例外をテストしている |
| API確認 | 重複、上限、ワークスペース不一致、エラー処理を実装している |
| 監査対応 | 追加・削除理由をコメントやチケットに残す運用がある |
| 教育 | アナリストがAzure portalとDefender portalの違いを理解している |
| 上限対策 | 150件上限に達した場合の対応方針がある |
| 移行計画 | Defender portal移行時の手順変更を反映している |
まとめ：最初に確認すべきは「どのポータルで管理する環境か」
2026年5月14日に更新された「Relate alerts to incidents in Microsoft Sentinel in the Azure portal」は、Azure portal版Microsoft Sentinelでアラートをインシデントに追加・削除し、調査範囲を調整するための実務的な手順を示しています。
管理者や開発者が最初に確認すべきなのは、機能の使い方そのものよりも、自社のMicrosoft SentinelワークスペースがDefender portalへオンボード済みかどうかです。Azure portalで操作できる範囲、Defender portalで管理すべき範囲、プレイブックやAPIの挙動が変わるためです。
次に取るべき行動は、現在のインシデント対応手順、プレイブック、API連携、権限設定を棚卸しし、アラート追加・削除の判断基準を明文化することです。特にDefender portalへの移行を進めている組織では、ポータル統合による相関ロジックや運用画面の変化を前提に、SOC手順を更新しておく必要があります。
アラート関連付けは、正しく使えば攻撃の全体像をつかむ強力な機能です。一方で、無条件にアラートをまとめると調査ノイズが増えます。実務では、エンティティ、時系列、攻撃手法、影響範囲を見ながら、インシデントの範囲を意図的に設計することが重要です。
コメント