Microsoft Sentinelでスケジュールされた分析ルールを作成する場合、2026年4月更新でまず確認すべきポイントは、Defender ポータル前提の運用へ移行すること、KQLクエリでTimeGeneratedを正しく返すこと、初回実行時刻・ルックバック期間・アラートグループ化を意図どおり設計することです。
特に、security admins、identity teams、compliance teamsにとって重要なのは、「ルールを作れるか」ではなく「誤検知を増やさず、調査しやすいインシデントとして残せるか」です。Microsoft公式の「Create scheduled analytics rules in Microsoft Sentinel」は2026年4月22日に更新され、ゼロからスケジュール分析ルールを作成する手順、Defender ポータルとAzure portalでの操作、インシデント化、自動応答までを整理しています。(Microsoft Learn)
Microsoft Sentinelの最新動向：スケジュールされた分析ルールで何が変わったか
Microsoft Sentinelのスケジュールされた分析ルールは、KQLクエリを定期実行し、指定したルックバック期間のログを評価して、条件を満たした場合にアラートを生成する仕組みです。単発の検索ではなく、日々のSOC運用で検知を継続するための中核機能と考えると分かりやすいです。(Microsoft Learn)
2026年4月時点で実務上のインパクトが大きいのは、次の5点です。
| 更新ポイント | 実務への影響 | すぐ確認すべきこと |
|---|---|---|
| Defender ポータル前提の運用が重要に | Azure portal中心の手順や教育資料が古くなりやすい | SOC手順書、画面キャプチャ、権限設計をDefender ポータル基準に見直す |
| Azure portalのサポート終了期限が明確 | 2027年3月31日以降はDefender ポータル利用が前提になる | 移行計画、教育、運用テストの期限を決める |
| 初回実行時刻の指定がプレビューで利用可能 | グローバルSOCや夜間バッチ後の検知開始を調整しやすい | 初回実行を「自動」か「特定時刻」にするか決める |
| インシデント相関はDefender側の影響を受ける | ルール側のグループ化設定どおりに見えない場合がある | アラート単位とインシデント単位の期待値を事前に確認する |
| Alert automation classicから自動化ルール中心へ | 古いプレイブック直接指定に依存すると運用リスクが残る | 自動化ルール経由でプレイブックを呼び出す構成へ移す |
Microsoftは、2027年3月31日以降、Microsoft SentinelはAzure portalでサポートされず、Microsoft Defender ポータルでのみ利用可能になると案内しています。Azure portalでSentinelを運用している組織は、単なる画面変更ではなく、インシデント確認、アラート相関、自動化、権限管理まで含めて移行準備を進める必要があります。(Microsoft Learn)
スケジュールされた分析ルールとは何を検知する仕組みか
スケジュールされた分析ルールは、Microsoft Sentinelに取り込まれたログに対してKQLを定期実行し、結果件数や条件に応じてアラートを生成します。たとえば、次のような検知に向いています。
- 短時間に同一ユーザーのサインイン失敗が急増した
- 特権ロールの割り当てが営業時間外に発生した
- 国外IPから管理者アカウントへのアクセスがあった
- 通常より多いデータ転送やファイルアクセスが発生した
- コンプライアンス上、記録すべき操作が実行された
ここで重要なのは、スケジュールされた分析ルールは「怪しいイベントを拾うだけ」では不十分という点です。調査担当者が次に見るべきユーザー、端末、IPアドレス、アプリ、対象リソースが分かるように、エンティティマッピングやカスタム詳細まで設計する必要があります。
2026年4月更新で押さえるべき実務ポイント
Defender ポータルを前提にルール作成手順を整備する
公式手順では、Defender ポータルの場合は「Microsoft Sentinel > Configuration > Analytics」から、Azure portalの場合は「Configuration > Analytics」から分析ルールを作成します。どちらも「+ Create」から「Scheduled query rule」を選びますが、今後の運用を考えるとDefender ポータル基準で手順をそろえるのが現実的です。(Microsoft Learn)
既存の社内手順書がAzure portalの画面だけを前提にしている場合、次の箇所を更新してください。
| 見直す対象 | 更新内容 |
|---|---|
| SOCオペレーション手順 | Defender ポータルでのAnalytics、Incidents、Alertsの場所を明記する |
| 教育資料 | Azure portalのタブ表示とDefender ポータルのタイムライン表示の違いを補足する |
| 権限設計 | Microsoft Sentinel Contributor相当の権限が必要な担当者を確認する |
| 監査手順 | ルール作成、変更、無効化、削除の承認フローをDefender ポータル前提で整理する |
| 外部委託・MSSP運用 | マルチテナント、複数ワークスペースで同じルールをどう配布するか決める |
KQLではTimeGeneratedを必ず返す
スケジュールされた分析ルールでは、ルックバック期間の参照にTimeGenerated列が使われます。公式ドキュメントでも、クエリがTimeGeneratedを返す必要があると明記されています。summarizeやprojectで列を絞り込むと、意図せずTimeGeneratedが消えることがあるため注意が必要です。(Microsoft Learn)
たとえば、サインイン失敗の増加を検知する場合は、次のように集計後もTimeGeneratedを残します。
SigninLogs
| where ResultType != 0
| summarize
FailedCount = count(),
FirstSeen = min(TimeGenerated),
TimeGenerated = max(TimeGenerated),
IPs = make_set(IPAddress, 10),
Apps = make_set(AppDisplayName, 10)
by UserPrincipalName
| where FailedCount >= 10
| project TimeGenerated, UserPrincipalName, FailedCount, FirstSeen, IPs, Appsこの例では、UserPrincipalNameをアカウントエンティティにマッピングし、FailedCount、IPs、Appsをカスタム詳細として表示すると、調査担当者が「誰が」「どのIPから」「どのアプリで」失敗したのかをすぐ確認できます。
よくある失敗は、次のようなクエリです。
SigninLogs
| where ResultType != 0
| summarize FailedCount = count() by UserPrincipalName
| where FailedCount >= 10このクエリは見た目には正しく集計できていますが、出力にTimeGeneratedがありません。分析ルールで使う場合は、検知時刻の基準となる列を残すように修正してください。
実行間隔とルックバック期間は「重複」と「抜け」を意識する
スケジュール設定では、「Run query every」と「Lookup data from the last」を指定します。公式情報では、どちらも5分から14日までの範囲で設定でき、ルックバック期間はクエリ間隔以上である必要があります。さらに、初回実行を自動にするか、特定時刻にするかを選べる設定もプレビューとして案内されています。(Microsoft Learn)
| 目的 | 推奨される考え方 | 設定例 |
|---|---|---|
| ほぼリアルタイムに近い検知 | 重要度が高く、早期対応が必要なルール | 5分ごとに実行、直近5〜10分を参照 |
| 取りこぼしを避けたい検知 | ログ取り込み遅延や集計処理を考慮する | 15分ごとに実行、直近30分を参照 |
| 1日単位の監査検知 | 営業日や日次レビューに合わせる | 1日1回、直近24時間を参照 |
| グローバルSOC向け | 地域ごとのシフト開始やデータ取り込み完了後に合わせる | 初回実行時刻を指定し、以後は一定間隔で実行 |
注意したいのは、ルックバック期間を短くしすぎると、ログ取り込み遅延でイベントを見逃す可能性がある点です。Microsoft Sentinelのスケジュールされた分析ルールは、取り込み遅延を考慮するため、スケジュール時刻から5分遅れて実行されると説明されています。(Microsoft Learn)
アラートしきい値はKQL側とルール側の二重設計で考える
アラートしきい値は、クエリ結果の件数が条件を満たしたときにアラートを生成する設定です。しきい値を設定しない場合は、数値フィールドに0を入力する形が案内されています。(Microsoft Learn)
ただし実務では、すべてをルール側のしきい値だけで制御すると調整しにくくなります。おすすめは、KQL側で意味のある検知単位に整形し、ルール側では「結果が1件以上あれば通知する」形にすることです。
たとえば、KQL側で「同一ユーザーの失敗回数が10回以上」を抽出し、ルール側のしきい値は0にします。こうすると、アラート1件が「ユーザー単位の検知結果」になり、SOCアナリストが調査しやすくなります。
インシデント作成とアラートグループ化の考え方
Defender ポータルではインシデント相関の見え方に注意する
Microsoft SentinelをDefender ポータルにオンボードしている場合、インシデント作成はMicrosoft Defender XDR側が担います。公式ドキュメントでは、この場合も「Create incidents from alerts triggered by this analytics rule」は有効のままにするよう案内されています。(Microsoft Learn)
さらに、Defender ポータルでは相関エンジンがアラートの関連付けを担当するため、分析ルール側のアラートグループ化設定が初期指示として扱われても、実際のインシデントのまとまり方が想定と異なる場合があります。これは誤動作ではなく、Defender側の相関ロジックが働くためです。(Microsoft Learn)
そのため、ルール作成時は次のように判断します。
| 設定 | 向いているケース | 注意点 |
|---|---|---|
| すべてのイベントを1つのアラートにする | 大量イベントを要約して見たい | 個々のイベント調査には追加のドリルダウンが必要 |
| イベントごとにアラートを作る | 個別イベントを明確に追跡したい | アラート数が増えやすい |
| すべてのエンティティ一致でインシデント化 | 同一ユーザー、同一ホストなどをまとめたい | エンティティマッピングの精度が重要 |
| すべてのアラートを1インシデント化 | ノイズを抑えたい検証用ルール | 異なる攻撃や対象が混ざる可能性がある |
| 選択したエンティティと詳細でグループ化 | IP、ユーザー、重大度などで細かく分けたい | カスタム詳細の設計が雑だと期待どおりにまとまらない |
最大150アラートの制限を前提に設計する
公式ドキュメントでは、最大150個のアラートを1つのインシデントにグループ化でき、150を超える場合は同じインシデント詳細を持つ新しいインシデントが生成されると説明されています。大量に発生するルールでは、KQLで集約してからアラート化する設計が重要です。(Microsoft Learn)
たとえば、ブルートフォース攻撃の検知で「失敗ログ1件ごとにアラート」を出すと、短時間で上限に近づきます。実務では「ユーザー単位」「IP単位」「アプリ単位」に集計し、調査に必要な情報をカスタム詳細に持たせるほうが運用しやすくなります。
自動応答はAutomation rules中心で設計する
分析ルールのAutomated responsesでは、既存の自動化ルールを確認したり、新しい自動化ルールを追加したりできます。公式ドキュメントでは、古い方式であるAlert automation classicについて、2023年6月時点で新規プレイブックを追加できず、2026年3月に非推奨化が有効になる旨が記載されています。(Microsoft Learn)
現在の運用では、次のように考えるのが安全です。
| 対応内容 | 推奨設計 |
|---|---|
| インシデント作成時にTeamsへ通知 | インシデントトリガーの自動化ルールを使う |
| 特定の重大度だけチケット起票 | 自動化ルールの条件で重大度やルール名を絞る |
| アラート作成時にプレイブック実行 | Alert created triggerを使う自動化ルールから呼び出す |
| 誤検知の多いルールを自動クローズ | 条件を厳密にし、閉じる理由とコメントを残す |
| コンプライアンス証跡を残す | 自動応答の実行条件、実行結果、変更履歴をレビュー対象にする |
自動化は便利ですが、検知ルールが未成熟な段階で強いアクションを実行すると、正常なアカウントを止めたり、不要なチケットを大量生成したりします。最初は通知やタグ付けから始め、誤検知率が下がった段階で封じ込めや外部連携を追加するのが現実的です。
対象チーム別の確認ポイント
Security adminsが見るべきポイント
Security adminsは、検知精度とSOC負荷のバランスを見ます。ルールを有効化する前に、Results simulationで現在のデータを使ってテストし、過去50回分の実行相当でどれくらい結果が出るかを確認できます。(Microsoft Learn)
確認すべき項目は次のとおりです。
| 確認項目 | 判断基準 |
|---|---|
| アラート件数 | 1シフトで処理できる件数か |
| 重大度 | HighやMediumが乱発されていないか |
| エンティティ | ユーザー、ホスト、IP、リソースが調査に使える形で出ているか |
| 抑制設定 | 同じアラートが短時間に繰り返されないか |
| 例外条件 | 既知の管理作業、監視ツール、社内IPを適切に除外しているか |
Identity teamsが見るべきポイント
Identity teamsは、Microsoft Entra ID関連のログ、特権アカウント、条件付きアクセス、ゲストユーザー、サービスプリンシパルの挙動に注目します。
たとえば、次のような検知はアイデンティティ運用と相性がよいです。
| 検知シナリオ | 例 |
|---|---|
| 特権ロール変更 | Global Administrator、Privileged Role Administratorの追加 |
| 異常なサインイン | 国外IP、匿名化サービス、失敗回数の急増 |
| サービスプリンシパル操作 | 資格情報の追加、権限昇格、アプリ同意 |
| 退職者・休職者アカウント | 無効化予定アカウントのサインイン試行 |
| MFA関連変更 | MFA無効化、認証方法の削除や追加 |
Identity teamsが関与しないままSOCだけでルールを作ると、「実は定常運用だった」という誤検知が増えます。ルール作成前に、正常な管理作業、定期バッチ、例外ユーザーのリストを共有しておくと調整が速くなります。
Compliance teamsが見るべきポイント
Compliance teamsは、検知そのものよりも「説明可能性」と「証跡」を重視します。なぜこのルールが必要なのか、誰が変更したのか、検知時にどの情報が残るのかを確認してください。
| 確認項目 | 実務での見方 |
|---|---|
| ルール名 | 監査対象や統制目的が分かる名前になっているか |
| 説明 | 検知目的、対象ログ、例外条件が書かれているか |
| MITRE ATT&CK | セキュリティカバレッジ説明に使えるか |
| インシデント化 | 監査対象のイベントが見落とされないか |
| エクスポート | ARMテンプレートやJSONで構成を保存できるか |
| 変更管理 | 本番適用前のレビュー、承認、ロールバック手順があるか |
公式ドキュメントでは、ルールをARMテンプレートとしてエクスポートでき、APIやPowerShellで複数のSentinelインスタンスに同じ設定を展開する場合は、まずルールをJSONにエクスポートする必要があると説明されています。複数リージョンや複数テナントで統制をそろえる場合は、手作業ではなく構成管理の対象にするのが有効です。(Microsoft Learn)
ルール作成の実務手順
事前準備
ルール作成前に、次の4点を確認します。
| 項目 | 確認内容 |
|---|---|
| 権限 | Microsoft Sentinel Contributor、またはLog Analyticsワークスペースとリソースグループへの書き込み権限があるか |
| データソース | 必要なコネクタが有効で、ログが定期的に取り込まれているか |
| テーブル名 | SigninLogs、AuditLogs、SecurityEventなど、対象テーブルを把握しているか |
| 検知目的 | 何を脅威または監査対象として検知するのか明文化しているか |
公式の前提条件でも、Microsoft Sentinel Contributor相当の権限、KQLや分析に関する基本知識、分析ルールウィザードの構成オプション理解が求められています。(Microsoft Learn)
作成フロー
- Defender ポータルで「Microsoft Sentinel > Configuration > Analytics」を開く
- 「+ Create」から「Scheduled query rule」を選択する
- ルール名、説明、重大度、MITRE ATT&CK、状態を設定する
- KQLクエリを貼り付け、即時検証のエラーを直す
- Entity mapping、Custom details、Alert detailsを設定する
- 実行間隔、ルックバック期間、初回実行方法を設定する
- アラートしきい値とイベントグループ化を決める
- 必要に応じて抑制設定を行う
- Results simulationで現在データを使ってテストする
- インシデント作成とアラートグループ化を設定する
- 自動化ルールやプレイブック連携を確認する
- Review and createで検証し、問題がなければ作成する
公開前に確認したいチェックリスト
| チェック | 合格基準 |
|---|---|
TimeGeneratedが出力されている | project後にも残っている |
| 検知単位が明確 | ユーザー単位、IP単位、端末単位などが決まっている |
| エンティティがマッピング済み | 調査画面でユーザー、IP、ホストなどを追える |
| カスタム詳細が有用 | FailedCount、対象リソース、アプリ名などが見える |
| 実行間隔とルックバックが妥当 | ログ遅延による抜けを防げる |
| しきい値が過敏すぎない | Results simulationでノイズ量を確認済み |
| インシデント化の方針が明確 | アラートだけ残すのか、必ずインシデント化するのか決まっている |
| 自動応答が安全 | 通知、タグ付け、チケット起票から段階的に始めている |
| 変更管理できる | ARMテンプレート、JSON、チケットで変更履歴を残せる |
| Defender ポータルで確認済み | Azure portalだけでなく今後の標準画面で動作を確認している |
テンプレートを使うべきか、ゼロから作るべきか
Microsoft SentinelにはContent hubで提供される分析ルールテンプレートがあり、公式ドキュメントでも一般的な用途ではテンプレートを利用し、自組織のシナリオに合わせてカスタマイズすることが推奨されています。ゼロから作るのは、既存テンプレートでは検知意図や業務条件を満たせない場合に向いています。(Microsoft Learn)
| 選択肢 | 向いているケース | 注意点 |
|---|---|---|
| テンプレートを使う | Microsoft製品や一般的な脅威検知を早く有効化したい | 自社環境に合わせたしきい値調整が必要 |
| テンプレートをカスタマイズ | 既存ロジックを活かしつつノイズを減らしたい | 元テンプレートの更新管理を忘れない |
| ゼロから作る | 独自業務、独自ログ、監査要件に合わせたい | KQL、エンティティ、インシデント設計の品質が重要 |
SOC最適化の推奨事項から公式ページへ移動した場合、推奨ルールの一覧を探すにはContent hubへ進む案内も記載されています。つまり、まずテンプレートや推奨ルールを確認し、それでも足りない部分をカスタムルールで補う流れが効率的です。(Microsoft Learn)
まとめ：2026年4月更新後にまずやるべきこと
Microsoft Sentinelのスケジュールされた分析ルールは、KQLを書いて終わりではありません。2026年4月更新を踏まえると、Defender ポータルへの移行、TimeGeneratedを含むKQL設計、初回実行時刻とルックバック期間、Defender XDRによるインシデント相関、自動化ルールへの移行をセットで見直す必要があります。
まずは既存ルールを棚卸しし、次の順で対応してください。
- Azure portal前提の手順書をDefender ポータル基準に更新する
- 既存KQLが
TimeGeneratedを返しているか確認する - 重要ルールの実行間隔、ルックバック期間、しきい値を再評価する
- インシデント化とアラートグループ化がSOCの期待どおりか確認する
- Alert automation classicに依存している構成を自動化ルールへ移行する
- ARMテンプレートやJSONでルール構成を管理し、複数環境へ展開できる状態にする
この順番で進めれば、Microsoft Sentinelの検知ルールを「作成できる状態」から「調査・監査・自動化まで使える状態」へ引き上げられます。
コメント