Microsoft Defender XDRのアラート調査でまず確認すべき答えは、アラート単体ではなく、インシデント・影響資産・検出元・分類状態をセットで見ることです。Microsoft Defenderポータルには、デバイス、ユーザー、メールボックス、クラウドアプリ、DLP、Microsoft Sentinelなど複数の検出元からのアラートが集約されます。さらに2026年6月時点では、AIエージェント関連のブロック・監査イベントもMicrosoft Defenderのアラートとして調査ワークフローに乗る流れが強まっています。(Microsoft Learn)
この記事では、Microsoft Defender XDRの「Investigate alerts in Microsoft Defender XDR」を管理者・SOC担当者・開発者向けに整理し、変更点、影響範囲、確認すべき設定、移行・展開時の注意点を実務目線で解説します。
Microsoft Defender XDRのアラート調査で変わったポイント
Microsoft Defender XDRのアラート調査は、単に「検知されたアラートを1件ずつ確認する作業」ではなくなっています。現在は、複数製品のシグナルをインシデントとして関連付け、影響を受けたデバイス、ユーザー、メールボックス、アプリ、データを横断して調査する運用が前提です。公式ドキュメントでも、アラートはより大きな攻撃ストーリーを構成する個々の証拠であり、Defender XDRがそれらを相関してインシデントを形成すると説明されています。(Microsoft Learn)
特に管理者が押さえるべき変更点は、次の5つです。
| 変更・注目点 | 管理者への影響 | まず確認する場所 |
|---|---|---|
| 統合アラートキューで複数製品のアラートを確認 | Endpoint、Office 365、Identity、Cloud Apps、Sentinel、DLPなどを横断して見る必要がある | Microsoft Defenderポータルの「Incidents & alerts > Alerts」 |
| アラートフィルターの重要性が増加 | 重大度だけでなく、製品名、検出元、エンティティ、ワークスペース、データストリーム、機密ラベルで絞り込む運用が必要 | AlertsキューのFilter |
| Entra ID Protectionアラート設定の見直し | 既定が「高リスク検出のみ」になるプレビュー変更が案内されており、中リスク以下を拾う運用では設定確認が必要 | Settings > Microsoft Defender XDR > Alert service settings |
| 組み込みアラートチューニングルールの確認 | 良性アクティビティ由来のノイズを減らせる一方、表示されないアラートが増える可能性がある | Settings > Microsoft Defender XDR > Rules > Alert tuning |
| AIエージェント関連アラートの追加 | Agent 365やローカルAIエージェントの危険な動作が、今後の調査対象に含まれる | Security for AI agents、Advanced Hunting |
アラート数が減った場合でも、それが「安全になった」ことを意味するとは限りません。アラートサービス設定、アラートチューニング、検出元のプレビュー機能、権限不足のいずれかによって見え方が変わっている可能性があります。(Microsoft Learn)
影響範囲はデバイス・ユーザー・メールボックスにとどまらない
Microsoft Defender XDRのアラート調査は、従来のエンドポイント検知だけを対象にするものではありません。公式情報では、Microsoft Defender for Endpoint、Defender for Office 365、Defender for Identity、Defender for Cloud Apps、Defender for Cloud、Microsoft Sentinel、Microsoft Entra ID Protection、Microsoft Data Loss Preventionなど、複数のMicrosoftセキュリティソリューションのアラートが同じキューに表示されるとされています。(Microsoft Learn)
| 対象領域 | 主な調査対象 | 実務で見るべきポイント |
|---|---|---|
| デバイス | 端末、プロセス、ファイル、スケジュールタスク、WMI、AMSIなど | 侵害端末か、社内ツールの正常動作かを切り分ける |
| ユーザー・ID | サインイン、権限、リスク状態、Entra ID Protection | 中リスク以下の検出を除外していないか確認する |
| メールボックス | フィッシング、悪性添付、転送ルール、ユーザー報告メール | Defender for Office 365のロールとタグ機能の状態を確認する |
| クラウドアプリ | アプリ利用、API操作、異常なデータアクセス | Defender for Cloud AppsやPower Automate連携を確認する |
| DLP・機密情報 | ポリシー一致、ファイル、ユーザー操作 | 機密ラベルやDLPポリシー名で絞り込む |
| OT・IoT | 侵害デバイスとOTデバイスの通信 | Defender for IoTの製品名フィルター、デバイスグループを確認する |
| AIエージェント | ツール呼び出し、プロンプト、データアクセス、ブロックイベント | Agent 365、プレビュー機能、Advanced Huntingのテーブルを確認する |
2026年6月の公式更新では、ローカルAIエージェントの検出やランタイム保護がMicrosoft Defender XDRの新機能として案内されています。ブロックまたは監査されたイベントはMicrosoft Defenderのアラートとして表示され、インシデント相関や調査ワークフローを支援します。AIエージェントを業務端末や開発環境で使っている組織では、これも新しい影響範囲として扱うべきです。(Microsoft Learn)
管理者が最初に確認すべき設定
Microsoft Defender XDRのアラート調査で失敗しやすいのは、調査手順よりも「そもそも見えるべきアラートが見えているか」を確認しないことです。以下の設定を先に確認しておくと、検知漏れや誤った優先順位付けを避けやすくなります。
Alertsキューの既定表示とフィルター
Microsoft DefenderポータルのAlertsキューは、既定では過去7日間の「New」と「In progress」のアラートを表示します。古いアラートや解決済みアラートを確認したい場合は、日付範囲や状態フィルターを変更する必要があります。アラートタイトルまたはアラートIDで検索できるため、チケット、SIEM、メール通知から調査する場合はID検索を使うと早くたどり着けます。(Microsoft Learn)
特に見るべきフィルターは、次の通りです。
| フィルター | 使いどころ |
|---|---|
| Severity | まず重大度で優先順位を付ける |
| Status | New、In progress、Resolvedを切り替える |
| Service/detection sources | Defender for Endpoint、Office 365、Sentinelなど検出元で絞る |
| Product name | Microsoft Defender for IoTなど製品単位で確認する |
| Entities | 影響を受けたユーザー、デバイス、メールボックスを軸に調べる |
| Automated investigation state | AIRの調査状態を確認する |
| Workspace | Sentinel連携や複数ワークスペース運用で使う |
| Sensitivity label | 機密情報やDLP関連の影響を確認する |
Defender for Office 365アラートの権限
Defender for Office 365のアラートにアクセスするには、Microsoft Entraのグローバルロール、Office 365 Security & Complianceのロールグループ、またはカスタムロールが必要です。公式ドキュメントでは、Global Administrator、Security Administrator、Security Operator、Global Reader、Security Readerなどが例示されていますが、Microsoftはより少ない権限のロールを使うことを推奨しています。Global Administratorは緊急時の例外として扱うべきです。(Microsoft Learn)
実務では、SOC一次対応者にはSecurity ReaderまたはSecurity Operator、対応権限を持つ担当者には必要最小限のカスタムロール、全体管理者にはSecurity Administratorを割り当てる形が扱いやすいです。メールアラートが見えない場合は、まずライセンスより前に「その担当者が対象アラートを読む権限を持っているか」を確認してください。
Entra ID Protectionアラートのサービス設定
Microsoft Defender XDRでは、Settings > Microsoft Defender XDR > Alert service settingsからアラートサービス設定を構成できます。公式ドキュメントでは、2025年12月11日からEntra ID Protectionアラートの拡張構成オプションがパブリックプレビューで展開され、新しい既定設定は「High-risk detections only」とされています。必要に応じて「High + Medium」または「All detections」に変更する必要があります。(Microsoft Learn)
ここは特に注意が必要です。たとえば、ID侵害の初期兆候を中リスク検出で拾っていた組織が既定のまま運用すると、従来見ていたアラートがキューに出なくなる可能性があります。認証リスクを広めに監視したい組織では、検知量とSOCの処理能力を見ながら設定を決めてください。
Microsoft Defender XDRでアラートを調査する基本手順
アラート調査は、次の順序で進めると抜け漏れが少なくなります。
| 手順 | 確認する内容 | 判断基準 |
|---|---|---|
| アラートキューで優先順位を付ける | 重大度、検出元、製品名、影響エンティティ | 高重大度、重要資産、複数製品にまたがるものを優先 |
| アラートページを開く | Alert story、Summary details | 単発イベントか、攻撃ストーリーの一部かを判断 |
| 影響資産を確認する | メールボックス、デバイス、ユーザー | 重要ユーザー、管理者端末、機密データへの影響を確認 |
| 詳細ページで文脈を見る | 選択したエンティティの履歴、関連アクション | 正常業務、テスト、攻撃のどれに近いかを切り分ける |
| 類似アラートを確認する | View similar alerts、Recommendations | 同じ原因の大量アラートを一括処理できるか判断 |
| 分類して解決する | True positive、Informational、False positive | 今後の検出品質とSOCレポートに残る分類を選ぶ |
| 必要に応じてチューニングする | 条件、適用範囲、アクション | 誤検知削減と検知漏れリスクのバランスを見る |
アラートページでは、Alert storyが時系列の攻撃ストーリーを示します。選択したエンティティに応じて詳細ページの内容も変わり、対象の履歴情報や実行可能なアクションを確認できます。影響資産には、メールボックス、デバイス、ユーザーなどが表示されるため、まず「何が危険か」ではなく「何に影響があるか」を見てください。(Microsoft Learn)
アラートソースとIDの違いはSIEM連携でも重要
Microsoft Defender XDRのアラートは、検出元によってアラートIDの先頭に文字が付く場合があります。たとえば、Defender for Office 365はfa{GUID}、Defender for Endpointはda{GUID}、Defender for Identityはaa{GUID}、Defender for Cloud Appsはca{GUID}、Microsoft Sentinelはsn{GUID}などです。公式ドキュメントでは、先頭に追加される文字はGUIDそのものを変更するわけではなく、統合アラートキューや統合インシデントなどの体験に固有のものとされています。(Microsoft Learn)
開発者やSIEM運用担当者は、次の点に注意してください。
| 注意点 | 影響 |
|---|---|
| アラートIDの接頭辞を固定的に処理しない | 製品横断の相関や重複排除で誤判定する可能性がある |
| アラートタイトルだけで判定しない | 同じアラートタイプでもタイトルが変わる場合がある |
| 古いAPI値を使わない | AptとSecurityPersonnelは2022年8月に非推奨となり、API経由では利用できない |
| タグ名変更を過去アラートに期待しない | 変更後のタグ名は、更新後に作成されたアラートにのみ適用される |
| AIエージェント関連テーブルの移行を確認する | AIAgentsInfoからAgentsInfoへの移行期限を考慮する |
2026年6月の公式情報では、Advanced HuntingのAgentsInfoテーブルがプレビューで利用可能になり、AIAgentsInfoは2026年7月1日までアクセス可能とされています。Agent 365を利用する組織は、KQLクエリやカスタム検出ルールをAgentsInfoへ更新する計画を立ててください。(Microsoft Learn)
アラートチューニングは「削減」ではなく「統制」として扱う
Microsoft Defender XDRには、良性アクティビティ由来のノイズを減らすための組み込みアラートチューニングルールがあります。公式情報では、これらのルールはAIR調査やメール通知に影響を与えずにアラートを抑制し、AIRが悪意ある活動または疑わしい活動を検出した場合は新しいアラートが再アクティブ化されると説明されています。(Microsoft Learn)
ただし、チューニングを「アラートを減らすための設定」と考えると危険です。実務では、次のように用途を分けて判断します。
| アクション | 使う場面 | 注意点 |
|---|---|---|
| Hide alert | Defender for Endpointで、既知の良性アクティビティをキューから隠したい場合 | インシデント作成を防ぐ。Defender for Endpointアラートのみ対象 |
| Resolve alert | 条件に合うアラートを自動的に解決したい場合 | 関連インシデントも解決状態になるため、条件を狭くする |
| Set as behavior | アラートではなく振る舞いとしてハンティングに残したい場合 | Defender for CloudやDefender for Office 365アラートではサポートされない |
| 何もしない | 初期導入、影響不明、攻撃手法が変化中の場合 | まず分類と手動判断の実績を蓄積する |
アラートチューニングは、既知の社内アプリ、セキュリティテスト、Red Team演習など「発生理由を説明できる活動」に限定するのが安全です。条件を広くしすぎると、本物の攻撃と正常動作の違いまで隠してしまいます。(Microsoft Learn)
また、Microsoft Security Copilot Phishing Triage Agentは、アラートチューニングで抑制されたアラートを分類しません。ユーザー報告のマルウェアまたはフィッシングメールを自動解決する組み込みルールや、このアラートを抑制するカスタムルールを使っている場合は、Copilotによるトリアージ運用と矛盾しないか確認が必要です。(Microsoft Learn)
Dynamic Threat Detection AgentとAI関連アラートの注意点
Microsoft Security Copilot in Microsoft Defenderには、Dynamic Threat Detection Agentが含まれます。これはDefenderとMicrosoft Sentinel環境のシグナルを相関し、従来のルールベース検出で見逃される可能性がある脅威を見つけるためのバックエンドサービスです。検出時には、自然言語の説明、MITRE ATT&CK技術、修復手順を含む動的アラートを生成します。(Microsoft Learn)
ただし、この機能はパブリックプレビューとして説明されており、生成される要約や推奨アクションはAI生成のため、正確性を確認する必要があります。また、一般提供後はSecurity Compute Unitsを消費する予定とされています。導入前に、コスト、承認フロー、AI生成内容のレビュー手順を決めておくべきです。(Microsoft Learn)
AIエージェント保護についても同様です。2026年6月2日更新の公式情報では、AIエージェントの危険な動作をリアルタイムにブロックし、ブロック理由、関係するエージェント、ユーザー、ツールを含む詳細アラートを生成すると説明されています。さらに、Agent 365管理下のエージェントについては、Defenderが近リアルタイムのアラートとして検出し、インシデント相関やAdvanced Huntingで調査できるとされています。(Microsoft Learn)
AIエージェントを展開している組織は、次の設定を確認してください。
| 確認項目 | 理由 |
|---|---|
| Microsoft Defenderポータルでプレビュー機能を有効化しているか | AIエージェント関連の証拠をアラートで取得するため |
| Security for AI agentsが有効か | AIエージェント保護の基本設定になる |
| Agent 365が接続されているか | リアルタイム保護と調査の前提になる |
| Copilot StudioやFoundryの追加連携が必要か | 拡張検出を使う場合に必要 |
| Advanced Huntingのクエリが最新テーブルに対応しているか | Agent 365関連の調査・検出ルール移行に関わる |
| 2026年7月1日以降のAgent 365サブスクリプション要件を確認したか | 保護・可視化機能の継続利用に影響する可能性がある |
Power Automate連携は限定条件から始める
Microsoft Defender XDRの公式ドキュメントでは、Power Automateを使ってアラートをトリアージする例も示されています。例として、ユーザーが不在時メッセージを有効にしており、高リスクとしてタグ付けされていない場合に、正当な旅行としてアラートを解決し、Microsoft Teamsへ通知する流れが紹介されています。(Microsoft Learn)
このような自動化は有効ですが、最初から広範囲に適用するのは避けるべきです。おすすめは、次のような条件に限定して始めることです。
| 自動化に向く条件 | 自動化を避けるべき条件 |
|---|---|
| 誤検知パターンが明確に説明できる | 攻撃と正常動作の差が曖昧 |
| 影響範囲が限定されている | 管理者アカウントや重要端末が関係する |
| 手動対応の判断が毎回同じ | 担当者によって判断が分かれる |
| 監査ログとコメントを残せる | なぜ解決したか後から説明できない |
| まず通知のみで試せる | 初回から自動解決・自動抑制する |
自動化は、SOCの作業時間を減らすためではなく、判断基準を標準化するために使うと失敗しにくくなります。
展開前に確認すべきチェックリスト
Microsoft Defender XDRのアラート調査を社内運用に組み込む前に、以下を確認してください。
| チェック項目 | 確認内容 |
|---|---|
| 権限設計 | Security Reader、Security Operator、Security Administrator、カスタムロールの割り当てが適切か |
| アラートサービス設定 | Entra ID Protectionのリスク検出範囲が自社の監視方針と合っているか |
| アラートチューニング | 組み込みルールとカスタムルールが、重要アラートを隠していないか |
| インシデント相関 | アラート単体ではなく、インシデント、Alert story、影響資産を確認する手順があるか |
| 分類ルール | True positive、Informational、False positiveの使い分けを定義しているか |
| API・SIEM連携 | アラートID、分類値、テーブル名、タイトル変更に耐えられる実装か |
| AI関連機能 | Agent 365、Security for AI agents、プレビュー機能、Advanced Hunting移行を確認したか |
| レビュー体制 | AI生成の要約や推奨アクションを人が検証する手順があるか |
特に重要なのは、分類ルールです。「False positive」と「Informational, expected activity」を混同すると、将来の検出改善やSOCレポートの精度に影響します。セキュリティテストやRed Team演習など、技術的には正しいが想定済みの活動は、単純な誤検知とは分けて扱うべきです。(Microsoft Learn)
よくある失敗と回避策
| 失敗しやすいポイント | 起きる問題 | 回避策 |
|---|---|---|
| 重大度だけで対応順を決める | 重要資産への低重大度アラートを見落とす | 重大度、影響資産、検出元、ユーザー権限を組み合わせて判断する |
| アラートが減った理由を確認しない | チューニングや設定変更による非表示を安全と誤認する | Alert tuningとAlert service settingsを定期レビューする |
| 類似アラートを一括で誤分類する | 本物の攻撃までFalse positiveにしてしまう | 代表サンプルを確認してから一括分類する |
| タグ名変更を過去分析に使う | 変更前アラートに新しいタグ名が反映されず集計がずれる | 更新日を境にタグ集計を分ける |
| APIで古い分類値を使う | 連携処理が失敗する | 非推奨値を使っていないか確認する |
| AI推奨をそのまま実行する | 誤った隔離、ブロック、解決につながる | AI生成内容は必ず人が検証する |
Microsoft Defender XDRは多機能ですが、運用の成否は「どのアラートを見るか」よりも「どのアラートを見えなくしているか」を把握できるかで決まります。チューニング、権限、プレビュー機能、Advanced Huntingのテーブル変更は、月次またはリリース確認時に棚卸しするのがおすすめです。
まず実施すべき対応
Microsoft Defender XDRのアラート調査を見直すなら、最初に次の5つを実施してください。
- Alertsキューで、過去7日以外、Resolved、製品別、エンティティ別のフィルターを試し、見えているアラート範囲を確認する。
- Alert service settingsで、Entra ID Protectionアラートのリスク検出範囲が自社の監視方針と一致しているか確認する。
- Built-in alert tuning rulesとカスタムチューニングルールを棚卸しし、抑制・自動解決される条件を文書化する。
- SOC向けに、True positive、Informational、False positiveの分類基準を決める。
- Agent 365やAIエージェントを使っている場合は、Security for AI agents、Advanced Huntingテーブル、2026年7月1日以降のサブスクリプション要件を確認する。
Microsoft Defender XDRのアラート調査は、検知されたイベントを読む作業ではなく、環境全体の攻撃ストーリーを復元する作業です。まずはアラートキュー、影響資産、検出元、チューニング設定を確認し、自社で「何が見えていて、何が抑制されているのか」を明確にすることから始めてください。
コメント