Microsoft Defenderの公式ドキュメント更新「Consolidate incident notifications FAQ」は、単なるFAQページの整理ではありません。確認すべきポイントは、Defender Experts for XDRのインシデント通知FAQが、Managed responseのFAQへ統合されたこと、そしてSOC運用で使う通知経路、Microsoft Sentinel連携、Graph Security API、SIEM／SOAR／ITSM連携の確認場所が変わったことです。
特に、security admins、compliance teams、enterprise IT readersにとって重要なのは、「通知が来るか」だけではなく、誰が対応中なのか、顧客側の対応待ちなのか、どのフィールドを自動化のトリガーにするのかを再確認することです。Microsoft Defender XDRやDefender Experts for XDRを運用している組織は、今回の更新をきっかけに、通知設定・Sentinel自動化ルール・チケット連携・監査ログ確認手順を棚卸ししておくべきです。
Microsoft Defenderの「Consolidate incident notifications FAQ」で何が変わったか
2026年4月30日のMicrosoftDocs系GitHub更新では、「Consolidate incident notifications FAQ」というコミットにより、Microsoft Defender Experts for XDRのインシデント通知FAQが、Managed response関連FAQへ統合されました。コミット説明では、従来の faq-incident-notifications-xdr.md を削除し、その内容を faq-managed-response.md に統合したこと、TOCから旧FAQ項目を外したこと、旧パスからManaged response FAQへのリダイレクトを追加したことが示されています。(GitHub)
つまり、今回の変更は「Microsoft Defenderの通知仕様が全面的に変わった」というより、運用担当者が参照すべき公式FAQの場所と構成が整理された更新と見るのが適切です。公式Learnページでも、対象はMicrosoft Defender XDRで、Managed responseに関するSOCチーム向けのFAQとして掲載されています。(Microsoft Learn)
実務上は、次の3点を優先して確認してください。
| 確認項目 | なぜ重要か | 具体的に見る場所 |
|---|---|---|
| 旧FAQ URLの扱い | 社内手順書やブックマークが古い可能性がある | faq-incident-notifications-xdr.md から faq-managed-response へのリダイレクト |
| 通知ステータスの意味 | SOCが「対応中」「顧客対応待ち」を誤認しないため | Assigned to、Status、Classification、Determination |
| 外部連携のトリガー | Sentinel、SIEM、SOAR、ITSMの自動化が止まらないようにするため | Microsoft Sentinel連携、Graph Security API、Logic Apps |
今回の更新は「通知FAQの統合」であり、参照先の整理が中心
GitHub上の差分では、旧インシデント通知FAQファイルが削除され、Managed response FAQに通知関連の内容が追加されています。あわせて、旧パス defender-xdr/faq-incident-notifications-xdr.md から /defender-xdr/faq-managed-response へリダイレクトする設定も追加されています。(GitHub)
この点は、運用チームにとって地味ですが重要です。社内Runbook、ナレッジベース、監査対応資料、教育資料などに旧FAQのURLを貼っている場合、リンク自体はリダイレクトで開ける可能性があります。しかし、監査や変更管理の観点では、「公式FAQの正式な参照先がManaged response FAQに変わった」ことを明記しておくほうが安全です。
特にグローバル企業では、日本語資料、英語Runbook、SOC向け手順書、監査証跡の参照リンクが分散しがちです。今回のようなドキュメント統合では、リンク切れだけでなく、参照している章名や説明文が古くなることにも注意が必要です。
まず確認すべきポイントはManaged responseの通知フロー
更新後の公式FAQでは、Managed responseの基本説明に加えて、「Understanding managed response notifications」というセクションが設けられています。ここでは、Microsoft Defender portal、Graph Security API、Microsoft Sentinel、サードパーティSIEM／SOAR／ITSM、メール、Teams、Slackなどの通知経路が整理されています。(Microsoft Learn)
運用担当者が最初に確認すべきなのは、通知の種類そのものではなく、通知がどの状態変化を表しているかです。
たとえば、Defender Expertsがインシデント調査を必要と判断すると、インシデントの Assigned to が Defender Experts に更新されます。その後、調査開始時には Status が In progress に更新されます。調査が完了して顧客側の対応が必要になると、Assigned to が Customer、Status が Awaiting Customer Action になります。(Microsoft Learn)
この状態遷移を理解していないと、次のような運用ミスが起きやすくなります。
| 起きやすいミス | 原因 | 対策 |
|---|---|---|
| Defender Expertsが対応中なのに、SOCが重複調査を始める | Assigned to: Defender Experts の意味を把握していない | インシデント一覧の担当者フィールドを一次判断に使う |
| 顧客側の対応待ちを見落とす | Awaiting Customer Action を通知だけで見ている | 毎日のSOC確認項目にステータスフィルターを追加する |
| チケットが自動起票されない | SentinelやSIEM側のフィールドマッピングが古い | Owner、Status、Tagのマッピングを再点検する |
| 監査時に対応根拠を説明できない | 調査サマリーや監査ログ確認手順がRunbookにない | Investigation summaryと監査ログの確認手順を明文化する |
Microsoft Defender portalで見るべきフィールド
Microsoft Defender portalでは、Managed responseの通知や対応状況をインシデント画面で確認します。公式FAQでは、Defender Expertsの作業開始、解決、調査結果、推奨対応、顧客側の対応待ちを判断するためのフィールドが説明されています。(Microsoft Learn)
運用上、特に重要なのは次のフィールドです。
| フィールド | 代表的な値 | 運用上の意味 |
|---|---|---|
| Assigned to | Defender Experts | Defender Expertsが関与している |
| Assigned to | Customer | 顧客側SOCまたはIT部門の対応が必要 |
| Status | In progress | 調査または対応が進行中 |
| Status | Awaiting Customer Action | 顧客側のアクション待ち |
| Status | Resolved | インシデントが解決済み |
| Classification / Determination | True Positiveなど | 調査結果や判定理由の確認に使う |
ここで重要なのは、メール通知だけに依存しないことです。メールは見落とし、配信遅延、配布リスト変更、迷惑メール判定などの影響を受けます。重要インシデントでは、Defender portalのインシデントキューを正とし、通知は補助的な導線として扱うほうが堅実です。
「Awaiting Customer Action」は最優先で監視する
今回のFAQ統合で特に見直したいのが、Awaiting Customer Action の扱いです。これは、Defender Expertsが推奨対応を提示し、顧客側のSOCやIT運用チームに対応を求めている状態です。
たとえば、次のようなケースが考えられます。
| シーン | 必要な確認 |
|---|---|
| 高リスクユーザーの無効化が推奨された | ID管理チームの承認フローと連携する |
| 端末隔離が推奨された | 業務影響、対象端末、除外設定を確認する |
| メール削除が推奨された | メールセキュリティ担当と証跡保存方針を確認する |
| 除外済み資産に対応が必要 | なぜ除外しているのか、代替手順があるかを確認する |
対応待ちの状態を放置すると、Defender Expertsが調査していても、最終的な封じ込めや復旧が進まない可能性があります。SOCの日次チェックでは、重大度だけでなく、Assigned to: Customer と Status: Awaiting Customer Action の組み合わせを必ず確認してください。
Microsoft Sentinel連携で確認すべきこと
Microsoft Sentinelを利用している組織では、今回の更新は特に重要です。公式FAQでは、Microsoft Defender XDRとMicrosoft Sentinelのデータコネクタを有効化している場合、Defender Expertsによるインシデント更新がSentinelにも同期されると説明されています。また、Microsoft Defender XDR側の Assigned to、Status、Classification は、Sentinel側の Owner、Status、Reason for closing に対応します。(Microsoft Learn)
つまり、Sentinel側で自動化ルールやプレイブックを組んでいる場合は、Defender portal側の表示名だけでなく、Sentinel側の対応フィールドで正しくトリガーされるかを確認する必要があります。
| Microsoft Defender XDR | Microsoft Sentinel | 確認ポイント |
|---|---|---|
| Assigned to | Owner | Defender ExpertsまたはCustomerへの変更を検知できるか |
| Status | Status | Active、Closedなどの扱いを誤認していないか |
| Classification | Reason for closing | クローズ理由や分類が監査レポートに反映されるか |
| Awaiting Customer Action | Tag | タグ追加を自動化のトリガーにできるか |
Sentinelのプレイブックは「通知」ではなく「業務アクション」まで設計する
公式FAQでは、Defender Expertsの割り当て時にメール、Teams、Slackへ通知したり、推奨対応が公開されたときにSMSや電話通知、Azure DevOps、ServiceNow、Jira、Zendesk、Freshservice、PagerDutyなどにタスクやチケットを作成したりする例が示されています。(Microsoft Learn)
ここでの実務ポイントは、通知先を増やすことではありません。重要なのは、通知を受けた後に誰が、何分以内に、どのシステムで、何を完了するかまで設計することです。
たとえば、次のように設計すると実効性が上がります。
| トリガー | 自動化例 | 担当 |
|---|---|---|
| OwnerがDefender Expertsに変更 | SOCのTeamsチャネルへ通知 | SOC一次対応 |
| OwnerがCustomerに変更 | ServiceNowに高優先度チケット作成 | SOCリード |
| Awaiting Customer Actionタグ追加 | PagerDutyでオンコール通知 | インシデント責任者 |
| StatusがClosedに変更 | 監査用レポートに転記 | コンプライアンス担当 |
通知を「知らせるだけ」で終わらせると、重大インシデントほど対応が属人化します。SentinelプレイブックやLogic Appsを使う場合は、通知先よりもエスカレーション条件を明確にしてください。
Graph Security APIと外部SIEM／SOAR／ITSM連携の確認点
サードパーティのSIEM、SOAR、ITSMを利用している組織では、Graph Security API経由の同期設定を確認する必要があります。公式FAQでは、Microsoft Defender XDRからDefender Expertsの更新を取得する方法としてGraph Security APIが示され、フィールドマッピング、単方向／双方向同期、テスト、定期的な検証が重要とされています。(Microsoft Learn)
外部連携で特に注意したいのは、Managed responseのすべての内容を外部ツールだけで完結できるとは限らないことです。公式FAQでは、Defender ExpertsがManaged response actionsを公開すると、Assigned to が Customer、Status が Awaiting Customer Action に更新され、これらをGraph Security APIで同期して、Microsoft Defender portal上のManaged response actions確認のトリガーとして使えると説明されています。(Microsoft Learn)
つまり、現時点の実務では次のように整理しておくと安全です。
| 連携対象 | できること | 注意点 |
|---|---|---|
| SIEM | インシデント状態の集約、相関分析 | フィールド名や分類の差異に注意 |
| SOAR | 通知、チケット作成、承認フロー起動 | 自動封じ込めは誤作動時の影響を評価する |
| ITSM | 対応履歴、担当者、SLA管理 | Defender portal側の調査サマリー参照導線を残す |
| Graph Security API | Defender XDRの更新取得 | 定期的にマッピングの妥当性を検証する |
特にコンプライアンス部門が関与する環境では、「外部チケットに何が記録されるか」と「Defender portalに何が残るか」を分けて考える必要があります。監査時には、チケット番号、インシデントID、調査サマリー、対応アクション、承認者、完了時刻が追跡できる状態にしておきましょう。
メール、Teams、Slack通知は補助線として設計する
公式FAQでは、推奨対応が公開された場合に指定されたインシデント連絡先へメール通知されること、TeamsでManaged responseの通知や双方向チャットを利用できること、Logic Appsを使ってSlack、Twilio、Azure Communication Servicesなどの通知に拡張できることが説明されています。(Microsoft Learn)
ただし、通知チャネルを増やすほど、かえって責任の所在が曖昧になることがあります。おすすめは、通知チャネルを役割ごとに分ける設計です。
| 通知チャネル | 向いている用途 | 避けたい使い方 |
|---|---|---|
| メール | 正式な通知、証跡、関係者共有 | 緊急対応の唯一の通知手段にする |
| Teams | SOC内の即時共有、質問、初動連携 | 重要判断をチャットだけで完結させる |
| Slack | 開発・SREチームとの連携 | セキュリティ判断の承認場所にする |
| SMS／電話 | 重大インシデントのオンコール呼び出し | 低優先度通知まで流す |
| ITSMチケット | 対応履歴、SLA、承認管理 | Defender portalの詳細確認を省略する |
通知は「多ければ安全」ではありません。SOC、IT運用、コンプライアンス、経営報告のどのレイヤーに何を通知するのかを決めておくことが重要です。
旧FAQを参照している社内資料は更新が必要
今回の更新では、旧FAQページが削除され、Managed response FAQへ統合されています。旧URLはリダイレクトされますが、社内資料のリンクや説明文まで自動で更新されるわけではありません。GitHubの差分では、旧インシデント通知FAQの削除と、旧パスからManaged response FAQへのリダイレクト追加が確認できます。(GitHub)
社内資料では、次のような箇所を点検してください。
| 点検対象 | 見直す内容 |
|---|---|
| SOC Runbook | FAQ参照先をManaged response FAQに変更する |
| インシデント対応手順 | Assigned to、Status、Awaiting Customer Action の意味を明記する |
| Sentinel自動化ルール | Owner、Status、Tagのトリガー条件を確認する |
| ITSM連携仕様書 | フィールドマッピングとチケット起票条件を見直す |
| 監査対応資料 | 調査サマリー、監査ログ、対応履歴の参照手順を更新する |
| 教育資料 | 旧FAQ名を使った説明を修正する |
特に、旧ドキュメント名の「incident notifications」を前提にした章タイトルや手順名は、Managed response全体の文脈に合わせて変更しておくと、今後の運用説明がしやすくなります。
Managed responseの対象範囲もあわせて再確認する
今回のFAQ統合を機に、Managed responseの対象範囲も確認しておくべきです。公式FAQでは、Managed responseはDefender Experts for XDRが必要なインシデントの調査、根本原因の特定、必要な対応アクションの決定、実行を管理するものとして説明されています。対象アクションには、デバイスの隔離、隔離解除、ファイルの停止と隔離、アプリ実行制限、ユーザーの無効化、メールのソフト削除などが含まれます。(Microsoft Learn)
ここで見落としやすいのが、除外対象の扱いです。高価値資産や機密性の高いユーザー・端末を除外リストに入れている場合、Defender Expertsはそれらに直接アクションを実行せず、必要な対応を通知・案内する形になります。(Microsoft Learn)
たとえば、役員端末、特権管理者アカウント、基幹業務サーバー、研究開発端末などを除外している場合、SOCだけで即時判断できないことがあります。この場合は、事前に承認者、代替手順、緊急時の例外対応を決めておく必要があります。
除外リストは「安全策」だが、対応遅延の原因にもなる
除外リストは、業務影響や誤対応を避けるために有効です。一方で、実際にインシデントが発生したときには、顧客側の判断待ちが発生しやすくなります。
次のような観点で、除外リストを定期的に見直してください。
| 見直し観点 | 確認すること |
|---|---|
| 業務重要度 | 本当にManaged responseの直接対応から除外すべきか |
| 承認者 | 夜間・休日でも判断できる責任者がいるか |
| 代替手順 | 手動隔離、アカウント停止、ネットワーク遮断の手順があるか |
| 証跡 | なぜ除外したのか、誰が承認したのか記録されているか |
| 定期レビュー | 組織変更や端末更新後も除外設定が妥当か |
除外設定は「設定して終わり」ではありません。セキュリティと事業継続のバランスを取るための運用設計として扱うべきです。
コンプライアンスチームが見るべき監査・証跡のポイント
コンプライアンスチームにとって、今回の更新で重要なのは、通知そのものよりも誰が、どの判断で、どの対応を実行したかを説明できるかです。公式FAQでは、Defender Expertsがインシデント調査時に実行したアクションは、Microsoft Defender portalのManaged responseフライアウト内のInvestigation summaryで確認できるとされています。また、テナント内でのサインイン時刻やアクションについては、Microsoft Purview portalまたはOffice 365 Management Activity APIを通じて監査ログを検索できると説明されています。(Microsoft Learn)
監査対応を意識するなら、次の情報を紐づけて保存できるようにしておくと実務で役立ちます。
| 証跡 | 用途 |
|---|---|
| Microsoft Defender XDRのIncident ID | インシデントの一意な追跡 |
| Investigation summary | 調査内容と判断根拠の確認 |
| Classification / Determination | 真陽性・誤検知などの判定確認 |
| Managed response actions | 実施または推奨された対応の確認 |
| 監査ログ | 誰がいつテナントにアクセスし、何を行ったかの確認 |
| ITSMチケット番号 | 社内承認・対応履歴との紐づけ |
| Sentinel incident | 相関分析や自動化履歴の確認 |
重要なのは、Defender portal、Sentinel、ITSM、監査ログを別々に見るのではなく、インシデント単位で横断的に追えるようにすることです。
移行準備として実施すべきチェックリスト
今回のMicrosoft Defender公式ドキュメント更新を受けて、すぐに大規模な設定変更が必要とは限りません。しかし、運用資料や自動化ルールが古いままだと、インシデント発生時に判断ミスが起きる可能性があります。
以下のチェックリストで、影響範囲を確認してください。
| 優先度 | チェック項目 | 対応内容 |
|---|---|---|
| 高 | 旧FAQ URLを使っている資料がある | Managed response FAQへの参照に変更する |
| 高 | Awaiting Customer Action を監視していない | SOCの日次確認・アラート条件に追加する |
| 高 | Sentinelプレイブックが旧条件のまま | Owner、Status、Tagのトリガーを再確認する |
| 中 | ITSMチケットにDefender incident IDが入っていない | チケット項目に追加する |
| 中 | メール通知だけで運用している | Defender portalやSentinelでの確認手順を併用する |
| 中 | 除外リストの承認者が不明 | 資産ごとに責任者と代替手順を定義する |
| 低 | 教育資料の画面名・FAQ名が古い | 最新のManaged response FAQに合わせて更新する |
特に、SOCが24時間体制でない組織では、Customer や Awaiting Customer Action の検知をオンコール通知に連携するかどうかを検討してください。重大度だけで通知を制御していると、顧客側対応待ちのインシデントを見落とす可能性があります。
実務でのおすすめ確認手順
運用チームが最短で影響確認するなら、次の順番で進めると効率的です。
| 手順 | 作業 | 目的 |
|---|---|---|
| 1 | 公式Managed response FAQを確認する | 最新の参照先と用語を把握する |
| 2 | 社内資料の旧FAQリンクを検索する | 古いURL・旧名称を洗い出す |
| 3 | Defender portalのインシデント表示項目を確認する | Assigned to、Status、Classificationの見方を統一する |
| 4 | Sentinel自動化ルールを確認する | Owner、Status、Tagの変更を検知できるか確認する |
| 5 | SIEM／SOAR／ITSM連携を確認する | フィールドマッピングとチケット起票条件を確認する |
| 6 | 除外リストと承認フローを確認する | 顧客側対応待ちが放置されないようにする |
| 7 | 監査ログ確認手順をRunbookに追記する | コンプライアンス対応に備える |
この順番で進めると、ドキュメント更新の確認だけで終わらず、実際のインシデント対応品質を改善できます。
今回の更新で誤解しやすいポイント
今回の更新はFAQの統合が中心ですが、いくつか誤解しやすい点があります。
| 誤解 | 正しい見方 |
|---|---|
| 旧FAQが消えたので通知機能が廃止された | FAQがManaged response FAQに統合されたと見るべき |
| リダイレクトされるなら社内資料は更新不要 | 正式な参照先や章名が変わるため更新したほうがよい |
| メール通知が来れば十分 | Defender portal、Sentinel、ITSMで状態確認できる設計が必要 |
| 外部SIEMだけ見れば対応できる | Managed response panelやInvestigation summaryの確認導線を残すべき |
| 自動化ルールは一度作ればよい | フィールドマッピングやタグ条件は定期的に検証する必要がある |
特に、Defender Experts for XDRを導入済みの組織では、Microsoft Defender portal上のManaged response情報を中心に、Sentinelや外部ツールを補助的に使う設計が現実的です。
まとめ：Microsoft Defenderの通知FAQ統合は運用手順を見直すきっかけ
Microsoft Defenderの公式ドキュメント更新「Consolidate incident notifications FAQ」で確認すべき点は、旧インシデント通知FAQがManaged response FAQへ統合されたこと、旧URLがリダイレクトされること、そして通知・Sentinel連携・Graph Security API・外部ツール連携の確認場所が整理されたことです。
実務では、次の対応を優先してください。
- 社内Runbookやナレッジベースの旧FAQリンクを更新する
Assigned to: CustomerとStatus: Awaiting Customer Actionを監視対象にする- Microsoft SentinelのOwner、Status、Tagを使った自動化ルールを再確認する
- SIEM／SOAR／ITSM連携のフィールドマッピングを見直す
- 除外リスト、承認フロー、監査ログ確認手順を整備する
今回の更新は、単なるドキュメント整理として流すよりも、SOC運用の品質を上げる機会として扱うべきです。Microsoft Defender XDRとDefender Experts for XDRを使っている組織は、まず社内資料の参照先を更新し、そのうえで「顧客側の対応待ちを確実に拾えるか」を確認してください。
コメント