Microsoft が 2026年4月10日付で Defender XDR のカスタム検出ルール ガイダンスを更新しました。今回の要点をひとことで言うと、Microsoft Sentinel の scoping を使う環境では、KQL の最終出力に SentinelScope_CF を残さないと、発火したアラートが scoped analyst から見えなくなる、という前提が明文化されたことです。同じ更新では、Custom frequency は Microsoft Sentinel に取り込まれたデータを前提に動くことも改めて整理されています。
Microsoft 365、Defender、Entra、Sentinel を主軸に運用する“Microsoft ショップ”にとって、これは単なる文書修正ではありません。見直すべきなのは個別のルール本文だけでなく、KQL テンプレート、レビュー項目、権限設計、QA 手順です。この記事では、4月10日の更新差分と、検出エンジニアリングで今すぐ反映したい実務ポイントを整理します。
2026年4月10日の更新で押さえるべき結論
Microsoft Learn の公開ページは ms.date 04/10/2026 で更新され、GitHub の公開履歴では Add SentinelScope_CF scoping note and update date という変更として公開されています。差分の中心は SentinelScope_CF に関する scoping note の追加と、Custom frequency の説明の微修正です。派手な新機能追加ではありませんが、運用事故を防ぐための条件を明文化した更新として重要です。
実務では、この種の更新のほうが影響が大きいことがあります。理由は、ルールが保存できるかどうかではなく、正しい担当者に正しいアラートが届くかに直結するからです。特に Sentinel scoping を導入している組織では、SentinelScope_CF を summarize や project の途中で落とすだけで、検出そのものは動いていても、制限付きアナリストからは見えないアラートが生まれます。
いちばん影響が大きいのは Sentinel scoping を使う環境
Microsoft Sentinel の scoping は、Defender ポータルで構成する行レベルのアクセス制御で、現時点では preview として案内されています。scoped users は自分に割り当てられた scoped data と、それに基づく alerts / incidents だけを表示できます。一方で、custom detections や analytics rules で scope を引き継がせたい場合は、KQL にカスタムフィールド SentinelScope_CF を含める必要があります。さらに、historical data には遡及せず、XDR tables は直接サポート対象ではありません。
たとえば、共有ワークスペースを地域別 SOC で運用していて、SigninLogs や SecurityEvent を summarize した後に SentinelScope_CF を落としてしまうケースです。この場合、ルールは保存できても、地域限定のアナリストからはアラートが見えない可能性があります。4月10日の更新は、こうした“動いているのに見えない”系の障害を防ぐための注意点を、カスタム検出ルール側のドキュメントにもはっきり書いたものと捉えるのが実務的です。
見直し時に最低限確認したいのは次の3点です。
summarizeやprojectのあとでも、最終出力にSentinelScope_CFが残っているかを確認する。列が最終結果に出ていなければ、scoped analyst から alert が見えなくなります。- テストは必ず新しく取り込まれたデータで行う。Sentinel scoping は historical data を後追いで scope しません。
- XDR 側のテーブルまで同じ考え方で scope できる前提にしない。scoping 文書では XDR tables は directly supported ではないとされています。
ルール種別と権限設計も見直すべき
Microsoft の整理では、analytics rules は Microsoft Sentinel に取り込まれたデータを対象にし、custom detection rules は Defender XDR のデータ、または Defender XDR と Sentinel の両方のデータを対象にできます。また、両者ともクエリできるのは analytics logs であり、basic logs や auxiliary logs は対象外です。さらに、Defender XDR の標準テーブル名に見えても、そのデータが Sentinel 側に存在しないなら analytics rule は正しく動きません。Defender XDR データや混在クエリが絡むなら、custom detection を選ぶほうが安全です。
権限面も軽視できません。カスタム検出ルールは、使うデータソースごとに適切な管理権限が必要です。たとえば Email* テーブルを扱うには Microsoft 365 Defender の Manage security settings が必要で、IdentityLogonEvents を使う場合は Defender for Cloud Apps と Defender for Identity の双方の管理権限が求められます。さらに Defender for Endpoint の RBAC が有効な環境では、Security Operator だけでなく Manage Security Settings も必要です。Microsoft ショップでは、コンテンツ設計者と権限設計者が別チームであることが多いため、ルール仕様と権限要件をセットでレビューする運用に変えたほうが事故を減らせます。
検出ルール設計で見直すべき4つのポイント
クエリの最終出力
Defender XDR データを使うカスタム検出ルールでは、クエリ結果に Timestamp もしくは TimeGenerated、イベントを一意に識別する列、そして DeviceId や AccountUpn、RecipientEmailAddress のような強いアセット識別子を含める必要があります。Microsoft は、検出頻度に応じた時間フィルターを内部で適用するため、クエリ側で Timestamp を条件に絞り込むのではなく、遅延到着データに備えて ingestion_time() を使うことを推奨しています。加えて、1回の実行で生成できるアラートは最大 150 件です。
ここで失敗しやすいのが、ハンティングでは成立する集計クエリをそのままルール化するケースです。summarize の結果が件数だけになってしまうと、ReportId や DeviceId など必要な列が消えて、ルール化時に詰まりやすくなります。実務では「KQL が動くか」ではなく、最終出力に必須列が戻っているかをレビューの主語にしてください。
実行頻度の決め方
現行ドキュメントでは、ルールの実行頻度として 24時間、12時間、3時間、1時間、Continuous（NRT）、Custom frequency が案内されています。新規ルールは最初に過去 30 日分のデータで実行され、その後は頻度ごとの lookback が適用されます。Custom detection は ingestion_time() を基準に評価されるため、イベントの Timestamp 自体は古くても、取り込みが遅れたデータが検出対象になることがあります。lookback が frequency より広い場合は重複候補が出ますが、同一の impacted assets、custom details、dynamic details を持つアラートは重複排除されます。Custom frequency は Sentinel に取り込まれたデータだけが対象で、5分から14日まで設定できます。
NRT は遅延を極力減らしたい検出に有効ですが、条件は厳しめです。単一テーブルのクエリであること、サポートされた KQL 機能だけを使うこと、join、union、externaldata を使わないこと、そして参照する列が対応するテーブルの GA 列であることが求められます。逆に言えば、単一テーブルの高シグナル検出は NRT 候補、複数テーブルの相関検出は定期実行、Sentinel 専用データで細かい間隔が必要なものだけ Custom frequencyと切り分けると、設計がかなり安定します。
アラート品質を上げる enrich 設計
現行ガイドでは、dynamic alert title / description にクエリ結果の列を埋め込めます。タイトル、説明ともに使えるのは最大 3 列までです。さらに、custom details は 20 個のキー/値ペアまで設定できますが、合計 4KB を超えると詳細全体が alert から落ちます。entity mapping では impacted assets や関連エビデンスを指定でき、これらのエンティティは incident の grouping にも使われます。Sentinel データを使う場合は、entity mapping を手動で選ぶ必要があります。
ここで大事なのは、情報量を増やすことよりも、triage に必要な情報だけを安定して残すことです。タイトルに毎回変わる値を詰め込みすぎるとノイズになり、custom details を盛りすぎると 4KB 制限にぶつかります。まずは DeviceId、AccountObjectId、RecipientEmailAddress のような安定した主語を軸にし、アナリストが初動判断に必要な 3〜5 項目だけを厳選すると、incident grouping も崩れにくくなります。
自動対応を前提にしたクエリ設計
Defender XDR データに対するカスタム検出ルールでは、デバイス、ファイル、ユーザー、メールに対するレスポンスアクションを設定できます。ただし、アクションごとに必要な列が決まっています。たとえばメールのアクションには NetworkMessageId と RecipientEmailAddress が必要で、ユーザーのアクションには AccountSid と AccountObjectId、メールボックスを特定するには RecipientObjectId や SenderFromAddress などが必要です。デバイススコープはデバイスルールにのみ影響します。
実務では、検出ロジックを先に決めてから後で自動対応を足そうとすると、列不足で作り直しになることが少なくありません。「何を自動化したいか」を先に決め、そのために必要な列をクエリの最終出力に残す順番に変えるだけで、再設計の手戻りはかなり減ります。
見落としやすい失敗
- Microsoft Sentinel ワークスペースに保存した custom functions は、workbooks、analytics rules、advanced hunting では使えても、custom detection rules では使えません。ハンティングで使っている関数をそのままルール化しようとして失敗する典型例です。
adx()演算子は advanced hunting で使えるケースがあっても、custom detections ではサポート外です。ハントから検出へ昇格させる前に、演算子の互換性を必ず確認してください。- NRT に移したいからといって
joinやunionを残したままでは通りません。複数テーブル相関の検出は scheduled のまま運用するのが現実的です。 - custom details を盛り込みすぎると、4KB 制限により細部だけでなく details 全体が落ちることがあります。情報量より、残ることを優先してください。
- Sentinel にデータが存在しない Defender XDR テーブルに対して analytics rule を作ると、作成自体はできても正しく実行されません。ルール種別の選択ミスは、静かに失敗するので厄介です。
まずやるべき見直し手順
4月10日の更新差分と現行ガイド全体を踏まえると、優先順位は次の順にすると無駄がありません。
- Sentinel scoping 利用ルールの棚卸し
Sentinel データを使う custom detections / analytics rules を洗い出し、SentinelScope_CFが最終出力に残るかを確認します。特にsummarize後のprojectは要注意です。 - テンプレートと PR チェック項目の更新
必須列、アクション用列、entity mapping、custom details の上限、ingestion_time()利用方針を、個人の暗黙知ではなくテンプレートに落とし込みます。 - 頻度の再分類
単一テーブルの高シグナル検出は NRT 候補、複数テーブル相関は scheduled、Sentinel 専用で細かな間隔が必要なものだけ Custom frequency に寄せます。 - 権限とルール種別の再確認
使うテーブルに対して必要な管理権限が揃っているか、analytics rule と custom detection の選択が正しいかをレビューします。 - 制限付きアナリストで UAT
新規に取り込んだテストデータを使い、scoped analyst からアラートが見えるか、incident grouping が意図どおりか、自動対応が必要列不足で失敗しないかを確認します。
今回の更新は差分だけ見れば小さく見えますが、Microsoft ショップの検出エンジニアリングでは、仕様変更に近い文書更新として扱う価値があります。特に Sentinel scoping を使っているなら、SentinelScope_CF を「覚えている人だけが入れる列」にせず、テンプレートとレビュー手順に組み込むべきです。そこまでできれば、Defender XDR のカスタム検出ルールは「動く KQL」から「正しく届き、正しく対応できる検出」へ一段引き上がります。
コメント