Microsoft Defender XDRのAdvanced hunting（高度なハンティング）は、最大30日分の生データをKQLで調査し、脅威の兆候や侵害の疑いを能動的に探すための機能です。2026年5月中旬の公式情報では、新機能の大幅追加というより、アクセス権限、対象データ、クォータ、Microsoft Sentinel連携時の注意点が整理されています。管理者が最初に確認すべきポイントは、URBACの権限設計、メール系テーブルへのアクセス、カスタム検出ルール、Microsoft Defender for EndpointやMicrosoft Sentinelからの移行影響です。(Microsoft Learn)
Microsoft Defender XDRのAdvanced huntingとは
Microsoft Defender XDRのAdvanced huntingは、Microsoft Defenderポータル上で利用できるクエリベースの脅威ハンティング機能です。Microsoft Learnでは、最大30日分の生データを探索し、ネットワーク内のイベントから脅威インジケーターや関連エンティティを探せる機能として説明されています。(Microsoft Learn)
対象データは単一製品に閉じません。公式情報では、以下のデータセットを横断的に確認できるとされています。(Microsoft Learn)
| 対象サービス | Advanced huntingで確認しやすい内容の例 |
|---|---|
| Microsoft Defender for Endpoint | 端末上のプロセス、ファイル、ネットワーク接続、アラート関連情報 |
| Microsoft Defender for Office 365 | メールイベント、URL、添付ファイル、配信後イベント |
| Microsoft Defender for Cloud Apps | クラウドアプリ利用や関連する検出情報 |
| Microsoft Defender for Identity | ID、認証、ドメインコントローラー関連イベント |
| Microsoft Sentinel | Defenderポータルに接続したワークスペースのデータ、クエリ、関数 |
重要なのは、Advanced huntingが「アラートを待つ機能」ではなく「アラートになる前後の痕跡を探す機能」である点です。たとえば、特定のPowerShell実行、疑わしいメールURL、同一アカウントの異常なログオン、複数端末に広がるファイルハッシュなどを、KQLで横断的に調査できます。
今回の更新で押さえるべき変更点
2026年5月中旬の更新では、Advanced hunting overviewのタイトルやメタデータがMicrosoft Defender XDR向けに整理され、権限まわりの説明がより具体化されました。GitHub上の差分では、旧タイトル「Overview – Advanced hunting」から「Advanced hunting overview in Microsoft Defender XDR」への変更、日付メタデータの更新、URBAC権限の説明変更、EmailPostDeliveryEventsの表記修正などが確認できます。(GitHub)
| 確認項目 | 更新・明確化された内容 | 実務上の意味 |
|---|---|---|
| ドキュメント名称 | Microsoft Defender XDRのAdvanced hunting overviewとして整理 | Defender XDR前提の運用資料として参照しやすくなった |
| 権限説明 | Email & Collaboration tablesとAlerts & behaviors tablesの権限が分けて説明された | メール系データを見られない、アラート系だけ見える、という権限差を切り分けやすい |
| URBACパス | メール系メタデータは「Security operations > Raw data > Email & collaboration metadata (read)」として整理 | 最小権限でSOC担当者にアクセスを付与する際の判断材料になる |
| データ鮮度 | イベントデータとエンティティデータの更新頻度が整理 | クエリ結果に反映されるタイミングの誤解を防げる |
| クォータ | 30日、100,000行、10分、64MB、CPU制限などが明示 | 重いクエリや自動検出ルールの設計見直しが必要 |
| Sentinel連携 | Defenderポータル上でSentinelテーブルも扱えるが、制限がある | Sentinel移行・統合運用時に事前検証が必要 |
今回の内容は、単純な「機能追加のお知らせ」ではありません。むしろ、すでにAdvanced huntingを使っている組織が、権限・クエリ・自動検出・Sentinel連携を見直すための更新と捉えるのが実務的です。
影響範囲はセキュリティ管理者、SOC、開発者に及ぶ
Advanced huntingの更新で影響を受けやすいのは、Microsoft Defenderポータルを管理する担当者だけではありません。KQLクエリを作るSOCアナリスト、カスタム検出ルールを保守する検出エンジニア、API経由でデータを取得する開発者にも確認ポイントがあります。
| 対象者 | 影響を受ける作業 | 確認すべきこと |
|---|---|---|
| セキュリティ管理者 | Defender XDRの有効化、URBAC、ロール設計 | 必要な担当者に適切な読み取り権限があるか |
| SOCアナリスト | 日常の脅威ハンティング、インシデント調査 | メール、ID、端末、Sentinelデータを想定どおり検索できるか |
| 検出エンジニア | カスタム検出ルール、KQL最適化 | ルールが10分以内に完了し、必要列を返しているか |
| 開発者 | Advanced hunting API、通知連携、SIEM連携 | APIの権限、制限、Microsoft Graph security APIへの移行要否 |
| Sentinel運用担当 | Sentinelワークスペース接続、KQL資産移行 | Defenderポータルで利用できるテーブル、関数、制限を把握しているか |
特に注意したいのは、同じ「閲覧者」でも見えるデータが同じとは限らない点です。Advanced huntingでは、Microsoft Entraロール、Exchange Onlineロール、Email & Collaborationロール、Defender for EndpointのRBAC、Microsoft Defender XDRのURBACが関係します。権限不足があると、クエリ自体は正しくても結果が返らない、特定テーブルだけ参照できない、といった現象が起きます。(Microsoft Learn)
管理者が最初に確認すべき権限設定
今回の更新で最も実務影響が大きいのは、Advanced huntingのアクセス権限です。公式情報では、クエリ実行前に権限割り当てが必要であり、URBAC、Email & Collaboration権限、Exchange Online権限、Microsoft Entraロール、Defender for EndpointのRBACが関係すると説明されています。(Microsoft Learn)
Email & Collaborationテーブルの権限を見直す
メール調査で使うEmailEvents、EmailUrlInfo、EmailAttachmentInfo、EmailPostDeliveryEvents、UrlClickEventsなどは、フィッシング調査や誤検知対応で頻繁に使います。今回の更新では、URBACにおけるメール系メタデータの読み取り権限が「Security operations > Raw data > Email & collaboration metadata (read)」として明示されています。(GitHub)
メール調査担当者にこの権限がない場合、次のような問題が起きやすくなります。
- フィッシングメールの受信者一覧を出せない
- URLクリック調査ができない
- 添付ファイルのハッシュを追跡できない
- カスタム検出ルールでメール系テーブルを使えない
- 「クエリは合っているのに結果が出ない」と誤認する
管理者は、SOCの担当範囲ごとに「アラートを見る担当」「メールメタデータまで見る担当」「修復操作まで行う担当」を分けて設計すると安全です。
Alerts & behaviorsテーブルの権限も分けて確認する
更新後の説明では、Alerts & behaviorsスキーマへのアクセスには「Security operations > Security data > Security data basics (read)」が使われると整理されています。ただし、この権限はEmail & Collaborationスキーマへのアクセスを含まない点が重要です。(Microsoft Learn)
つまり、アラートや挙動のデータは見えるが、メールイベントは見えないという状態があり得ます。運用では、次のように切り分けてください。
| 症状 | 確認すべき権限 |
|---|---|
AlertInfoやAlertEvidenceは見えるが、EmailEventsが見えない | Email & collaboration metadata (read) |
| 端末系テーブルだけ見えない | Defender for EndpointのRBAC、デバイスグループ |
| Exchange Online由来のデータが見えない | Exchange Onlineロール、Email & Collaborationロール |
| すべてのAdvanced huntingデータが見えるはずの管理者で結果が足りない | Microsoft EntraロールとURBACの有効化状態 |
Microsoft Defender XDRの有効化と展開上の注意点
Advanced huntingを使うには、Microsoft Defender XDRを有効化しておく必要があります。Microsoft Defender XDRは、Defender for Endpoint、Defender for Office 365、Defender for Cloud Apps、Defender for Identityなどの機能を統合し、Microsoft Defenderポータルでインシデント、アラート、Action center、Advanced huntingなどを利用できるようにします。(Microsoft Learn)
展開時に見落としやすいのは、Advanced huntingの画面が表示されることと、期待した全データが取れることは別だという点です。Microsoft Defender XDRは既存サービスのデータを統合しますが、各サービスの展開状況、ネットワーク接続、プロキシ設定、ライセンス、ロールが不十分だと、ハンティング対象が限定されます。(Microsoft Learn)
展開時は、次の順番で確認すると失敗しにくくなります。
| 手順 | 確認内容 | 失敗しやすいポイント |
|---|---|---|
| 1 | Microsoft Defender XDRが有効化されているか | ポータルに入れるだけで全機能が使えると誤解する |
| 2 | Defender for Endpoint、Office 365、Identityなどが展開済みか | 未展開サービスのテーブルに結果が出ない |
| 3 | Microsoft Defenderポータルへの通信が許可されているか | プロキシやファイアウォールでポータル操作が不安定になる |
| 4 | URBACまたは既存RBACの設計が整っているか | 権限不足をクエリ不備と誤認する |
| 5 | SOC担当者の業務範囲に応じた権限になっているか | 全員をGlobal Administratorにしてしまう |
最小権限を維持するなら、調査担当、検出ルール作成担当、修復操作担当を分けるのが現実的です。特にメール削除、端末隔離、ファイル検疫などの操作権限は、読み取り権限とは別に承認フローを設計してください。
データ保持期間とクォータの確認ポイント
Advanced huntingでは、Defender XDRデータについて原則として過去30日分を検索できます。公式情報では、結果セットは最大100,000行、クエリの実行時間は最大10分、結果サイズは64MB、CPUリソースはテナントサイズに応じて割り当てられるとされています。(Microsoft Learn)
| 制限項目 | 公式情報で示されている値 | 運用上の注意 |
|---|---|---|
| 日付範囲 | Defender XDRデータは最大30日 | 長期調査はSentinel連携やStreaming APIを検討 |
| 結果行数 | 最大100,000行 | 全件抽出ではなく条件を絞る |
| タイムアウト | 最大10分 | 重いjoinやsummarizeは最適化が必要 |
| 結果サイズ | 64MB | 不要な列をprojectで削る |
| CPUリソース | テナントサイズに基づく | 複数の重いクエリやカスタム検出で枯渇しやすい |
よくある失敗は、インシデント対応中に広すぎる期間・多すぎる列・複数テーブルの大規模joinを一度に実行することです。ポータルの手動クエリだけでなく、カスタム検出ルールにもクォータは影響します。定期実行するクエリほど、事前に軽量化しておく必要があります。
重いクエリを避ける基本
公式のベストプラクティスでは、早い段階で時間フィルターや条件を適用する、containsよりhasを使う、全列検索を避ける、必要な列だけprojectする、join前にデータ量を減らす、といった最適化が推奨されています。(Microsoft Learn)
実務では、まず次のような書き方を標準にするとよいでしょう。
EmailEvents
| where Timestamp > ago(1d)
| where ThreatTypes has "Phish"
| project Timestamp, NetworkMessageId, SenderFromAddress, RecipientEmailAddress, Subject, DeliveryAction
| take 100調査の初期段階では、いきなり30日分を広く検索するより、1日、3日、7日のように範囲を広げていく方が安全です。結果が多すぎる場合は、summarize count() byで傾向を見てから詳細調査に進むと、タイムアウトや部分結果を避けやすくなります。
タイムゾーンはUTCで考える
Advanced huntingのクエリでは、すべてのデータにUTCが使われます。一方、結果表示はMicrosoft Defender XDR側で設定されたタイムゾーンに変換されます。(Microsoft Learn)
日本のSOCで特に注意したいのは、JSTとUTCの9時間差です。たとえば、日本時間の2026年5月15日午前9時に発生したイベントは、UTCでは2026年5月15日午前0時です。インシデント報告書、SIEM、メールログ、端末ログを突き合わせる場合、どの時刻がUTCでどの時刻がJSTなのかを明記しないと、調査範囲を誤ります。
おすすめは、調査メモに次の3点を必ず書くことです。
- クエリ条件に使った時刻はUTCかJSTか
- Defenderポータルの表示タイムゾーン
- 他システムのログ時刻との変換ルール
時刻のズレは、侵害範囲の見落としにつながります。特に「メール受信後30分以内のログオン」「端末感染後の横展開」など、時系列が重要な調査では必ず確認してください。
Microsoft Sentinel連携時の移行・運用注意点
Microsoft SentinelをDefenderポータルに接続すると、Advanced huntingからMicrosoft Sentinelのワークスペース、クエリ、関数を扱えるようになります。公式情報では、Defenderポータル上でMicrosoft Defender XDRとMicrosoft Sentinelのデータを同じ画面から検索でき、コンテキスト切り替えを減らせるとされています。(Microsoft Learn)
ただし、Sentinel連携には制限もあります。たとえば、Defender XDRデータとSentinelデータを横断してクエリするには少なくともMicrosoft Sentinel Readerロールが必要です。また、ガイド付きハンティングモードやTake actions機能はDefender XDRデータのみをサポートするとされています。(Microsoft Learn)
| 確認項目 | 注意点 |
|---|---|
| ロール | Sentinelデータを横断検索するにはMicrosoft Sentinel Reader以上が必要 |
| データ保持 | SentinelにストリーミングしたDefender XDRテーブルは、設定した保持期間に応じて30日超の検索が可能 |
| KQL | Sentinelのクエリは概ね利用できるが、スキーマ警告が出る場合がある |
| ガイド付きモード | Defender XDRデータのみをサポート |
| Take actions | SentinelデータではなくDefender XDRデータが中心 |
| 補助ログテーブル | Sentinel data lakeオンボード後は扱いに注意が必要 |
また、MicrosoftはMicrosoft Sentinelについて、2027年3月31日以降はAzure portalでサポートされず、Microsoft Defenderポータルでのみ利用可能になると説明しています。現在Azure portal中心でSentinelを運用している組織は、Defenderポータルへの移行計画を早めに立てるべきです。(Microsoft Learn)
Microsoft Defender for Endpointからの移行で注意すべきクエリ
Microsoft Defender for EndpointのAdvanced huntingからMicrosoft Defender XDRへ移行する場合、既存クエリの多くはそのまま動作します。ただし、DeviceAlertEventsを参照するクエリは見直しが必要です。公式の移行情報では、DeviceAlertEventsはMicrosoft Defender XDRのスキーマではAlertInfoとAlertEvidenceに置き換える形で説明されています。(Microsoft Learn)
移行前の例です。
DeviceAlertEvents
| where Timestamp > ago(7d)
| where AttackTechniques has "PowerShell"
| where FileName == "powershell.exe"Microsoft Defender XDR向けには、次のようにAlertInfoとAlertEvidenceをAlertIdで結合する形を検討します。
AlertInfo
| where Timestamp > ago(7d)
| where AttackTechniques has "PowerShell"
| join kind=inner AlertEvidence on AlertId
| where FileName == "powershell.exe"
| project Timestamp, Title, AlertId, DeviceName, FileName, ProcessCommandLineここでのポイントは、単にテーブル名を置き換えるだけではなく、アラートの概要情報と証拠情報が別テーブルに分かれる点を理解することです。移行後は、必要な列がどちらのテーブルにあるかを確認し、projectで結果を絞り込むと扱いやすくなります。
カスタム検出ルールへの影響
Advanced huntingのクエリは、カスタム検出ルールにも利用できます。Microsoft Learnでは、カスタム検出はAdvanced huntingクエリをもとに定期実行され、条件に一致した場合にアラートや応答アクションを生成できる機能として説明されています。(Microsoft Learn)
今回の更新を踏まえると、カスタム検出ルールでは次の確認が必要です。
| 確認項目 | 理由 |
|---|---|
| クエリが10分以内に終わるか | タイムアウトすると検出が安定しない |
| 返す列がアクションに必要な列を含むか | 端末隔離、メール削除、ファイル検疫などで必須列がある |
| メール系テーブルに必要な権限があるか | EmailEventsなどを使う検出が失敗する可能性がある |
| MDE由来のルールがXDR側へ移った場合の通知経路 | SIEM通知やメール通知の設定が変わる場合がある |
| 抑制ルールの扱い | Defender for Endpoint側の抑制ルールが効かなくなるケースに注意 |
特にMicrosoft Defender for EndpointからXDRへ移行する場合、ルールを編集してIDやメールなどXDR専用テーブルを使うと、ルールがMicrosoft Defender XDR側へ移る可能性があります。公式情報では、その場合、既存のDefender for Endpointポータルで見えなくなる、SIEMやメール通知が止まる、Defender for Endpoint側の抑制ルールが適用されない、といった注意点が示されています。(Microsoft Learn)
Take actionsを使う場合の権限と必須列
Advanced huntingの結果から、端末隔離、調査パッケージ収集、ウイルス対策スキャン、ファイル検疫、メール移動、メール削除、Microsoftへの送信、Automated investigationの開始などを実行できます。ただし、これらは読み取り権限だけでは使えません。(Microsoft Learn)
公式情報では、デバイスに対する操作にはMicrosoft Defender for Endpointの修復操作権限が必要で、URBACでは「Security operations > Security data > Response (manage)」が修復操作の承認または却下に必要と説明されています。また、メールへの操作には「Security operations > Security data > Email & collaboration advanced actions (manage)」が必要です。(Microsoft Learn)
| 操作 | 必要な確認 |
|---|---|
| デバイス隔離 | DeviceIdが結果に含まれているか、操作権限があるか |
| ファイル検疫 | SHA1、SHA256、InitiatingProcessSHA1など識別列があるか |
| メール削除 | メール系権限、対象テーブル、必要列がそろっているか |
| 送信者コピーの削除 | EmailDirectionとSenderFromAddressが含まれているか |
| Microsoftへの送信 | URLや添付ファイルの詳細取得に必要なjoinができているか |
実務では、調査用クエリと操作用クエリを分けるのがおすすめです。調査用クエリは幅広く情報を出し、操作用クエリはアクションに必要な列を確実に返すように設計します。
API利用者が確認すべき点
開発者がAdvanced hunting APIを使っている場合は、ポータルのクォータとは別にAPI側の制限や権限も確認してください。Microsoft Learnでは、従来のAdvanced hunting APIは古いバージョンであり、より包括的なMicrosoft Graph security APIが利用可能と説明されています。(Microsoft Learn)
API利用時の確認ポイントは次の通りです。
| 確認項目 | 内容 |
|---|---|
| API権限 | アプリケーション権限ならAdvancedHunting.Read.All、委任権限ならAdvancedHunting.Read |
| ユーザー権限 | ユーザー資格情報でトークンを取得する場合、対象データへの閲覧権限が必要 |
| 呼び出し制限 | テナントごとの呼び出し数、CPU、タイムアウトを考慮 |
| 結果量 | 100,000行や結果サイズ制限を前提にページング・分割を設計 |
| 移行方針 | 新規開発ではMicrosoft Graph security APIの利用可否を検討 |
自動収集バッチで30日分を毎回広く検索する設計は避けましょう。日次・時間単位で差分を取得し、必要な列だけを返すクエリにする方が安定します。
管理者向けの確認チェックリスト
最後に、今回の更新を受けて管理者が確認すべき項目を整理します。
| 優先度 | 確認項目 | 具体的な作業 |
|---|---|---|
| 高 | URBACのAdvanced hunting権限 | メール系、アラート系、修復操作の権限を分けて確認 |
| 高 | メール系テーブルの可視性 | EmailEvents、EmailUrlInfo、EmailAttachmentInfoが検索できるか |
| 高 | カスタム検出ルール | タイムアウト、必要列、通知経路、抑制ルールを確認 |
| 中 | MDEからXDRへの移行クエリ | DeviceAlertEvents依存をAlertInfo、AlertEvidenceへ見直し |
| 中 | Sentinel連携 | ワークスペース接続、ロール、既存KQL、制限を検証 |
| 中 | API連携 | Microsoft Graph security APIへの移行要否、権限、制限を確認 |
| 中 | 時刻管理 | UTCとJSTの変換ルールをSOC手順に明記 |
| 低 | ドキュメント・手順書 | SOC向けの標準クエリ、権限申請手順、エスカレーション先を更新 |
Advanced huntingは、Microsoft Defender XDRを「見るだけのセキュリティポータル」から「能動的に調査・検出・対応する基盤」に変える重要機能です。今回の公式情報では、特に権限とクォータの理解が運用品質を左右します。まずはメール系テーブル、アラート系テーブル、端末系テーブルを担当者ごとに確認し、既存のカスタム検出ルールとMDE移行クエリを棚卸ししてください。そのうえで、Sentinel連携やAPI連携を使っている環境では、データ保持期間、必須ロール、通知経路まで含めて検証すると、実運用でのトラブルを減らせます。
コメント