Microsoft Sentinelの「Detection and automation, reimagined」は、今すぐ既存の分析ルールやプレイブックを作り直す話ではありません。重要なのは、検出・自動化・ハンティングの主戦場がMicrosoft Defenderポータルへ寄り、今後の新規検出は「カスタム検出（custom detections）」を中心に考える流れが強まっている点です。既存のAnalytics rules、Playbooks、Workbooksは継続利用できる一方で、SOC運用では「Defenderポータルで正しく動くか」「自動化条件が意図通りか」「誰がどのデータを見られるか」を早めに確認しておく必要があります。Microsoft Sentinel Blogの記事では、検出エンジニアリング、自動化、ハンティング、Workbooks、ケース管理の変化が整理されています。(TECHCOMMUNITY.MICROSOFT.COM)
Detection and automation, reimaginedで押さえるべき結論
2026年6月19日ごろに確認された「Detection and automation, reimagined」は、Microsoft SentinelをMicrosoft Defenderポータルへ統合していく流れの中で、検出と自動化の運用モデルがどう変わるかを説明するNoticeです。
結論から言うと、Microsoft Sentinel利用者が確認すべきポイントは次の3つです。
| 確認ポイント | 実務上の意味 |
|---|---|
| 既存のAnalytics rulesは消えない | 既存ルールを慌てて削除・再作成する必要はない |
| 新規検出はカスタム検出を優先検討 | SentinelデータとDefender XDRデータをまたいだ検出を作りやすくなる |
| SOARはインシデント中心で再点検 | アラート単位の自動化だけでなく、統合インシデントで期待通り動くかを検証する |
Microsoftは、既存の分析ルール、プレイブック、Workbooksがそのまま使える一方で、検出・調査・自動化できる範囲がエンドポイント、ID、メール、クラウドアプリ、Sentinelデータへ広がると説明しています。これは「機能が減る」変更ではなく、SIEM単体の運用からSIEMとXDRを組み合わせた運用へ寄せる変更と捉えるのが実務的です。(LinkedIn)
何が変わったのか
「Detection and automation, reimagined」の中心は、Microsoft Sentinelの検出・自動化機能がDefenderポータル上で再整理されることです。従来のSentinel運用をそのまま続けるだけでなく、Defender XDRのデータ、ネイティブ応答アクション、統合インシデントを使う設計へ移行しやすくなります。
| 領域 | これまでの主な考え方 | 今後意識すべき考え方 |
|---|---|---|
| 検出ルール | SentinelのAnalytics rulesでKQLを定期実行 | 新規検出はカスタム検出を優先候補にする |
| NRT検出 | SentinelのNRTルールで短い間隔の検出 | カスタム検出のContinuous/NRTも含めて設計する |
| 自動化 | Analytics rulesやAutomation rulesからプレイブック実行 | 統合インシデント、Defenderアラート、Sentinelアラートを前提に条件を見直す |
| ハンティング | SentinelのLogsやHuntingで調査 | Advanced HuntingでSentinelとDefenderのデータを横断確認する |
| Workbooks | Sentinel内の可視化として利用 | 継続利用しつつ、リンク・権限・データ参照をDefenderポータル前提で確認する |
| ケース管理 | Sentinelインシデント中心 | Defender側の統合インシデントキューとケース運用へ寄せる |
Microsoft Learnでは、カスタム検出がMicrosoft Sentinel SIEMとMicrosoft Defender XDRをまたぐ新規ルール作成の推奨体験として説明されています。カスタム検出では、Defender XDRデータ、Defenderの関数、修復アクション、エンティティマッピングなどを活用できます。(Microsoft Learn)
既存のAnalytics rulesはどう扱うべきか
既存のAnalytics rulesは、直ちに廃止されるものではありません。まずは「移行」ではなく「棚卸し」から始めるのが安全です。
特に確認したいのは、次のようなルールです。
| 優先度 | 確認対象 | 見るべき観点 |
|---|---|---|
| 高 | 高重大度インシデントを作るルール | Defenderポータルのインシデントで期待通り表示・相関されるか |
| 高 | 自動化を呼び出すルール | Automation rulesやLogic Appsが正しい条件で動くか |
| 中 | NRTルール | カスタム検出のNRTへ寄せるメリットがあるか |
| 中 | Defender製品データと組み合わせたいルール | Advanced Huntingやカスタム検出化を検討する |
| 低 | 長期間発火していないテンプレート由来ルール | 無効化・閾値調整・説明更新を検討する |
判断基準はシンプルです。Sentinelのログだけで完結し、既に安定しているルールは急いで変更する必要はありません。一方で、端末、ID、メール、クラウドアプリの情報を横断して検出したいルールは、カスタム検出化の候補にできます。
Microsoftの比較表では、Sentinel Analytics rulesはDefender XDRデータを扱えない一方、カスタム検出はDefender XDRデータやネイティブのDefender応答アクションをサポートします。ただし、MITRE ATT&CK連携や一部のAutomation rules連携など、カスタム検出側で計画中の項目もあるため、全ルールを機械的に置き換えるのは避けるべきです。(Microsoft Learn)
カスタム検出で確認したいポイント
カスタム検出は便利ですが、既存のAnalytics rulesと完全に同じ前提で扱うと失敗します。特に、クエリ結果の列、スコープ、重複アラート、応答アクションを確認してください。
たとえば、ユーザーの不審なサインインと端末上の不審なプロセス実行を組み合わせたい場合、従来はSentinelに取り込まれたログを中心にKQLを書く運用になりがちでした。DefenderポータルのAdvanced Huntingとカスタム検出を使うと、Defender XDR側のテーブルとSentinelデータを同じ調査体験で扱いやすくなります。
一方で、カスタム検出を作る前には次を確認します。
| 確認項目 | 理由 |
|---|---|
| クエリが必要な列を返しているか | アラートの時刻、デバイス、ユーザー、エンティティ紐付けに影響する |
| scoped analystがアラートを見られるか | スコープ列の不足で、担当者にアラートが見えない可能性がある |
| 通常運用の挙動を除外しているか | カスタム検出は誤検知を増やしやすい |
| 自動応答の対象が正しいか | ユーザー無効化、端末隔離などの応答は影響が大きい |
| ルール実行頻度とlookbackが適切か | 重複アラートや検出漏れにつながる |
Microsoft Defender XDRのカスタム検出ドキュメントでは、Advanced Huntingから検出ルールを作る流れ、必要な権限、クエリ結果に含めるべき列、スコープ設定、重複アラートの扱いが説明されています。(Microsoft Learn)
NRTルールは「速ければよい」ではない
NRT、つまりNear-real-time検出は、侵害の初動を早く見つけたい場面では有効です。Microsoft SentinelのNRTルールは、クエリを1分間隔で実行する高応答の検出として説明されています。(Microsoft Learn)
ただし、実務ではすべての検出をNRTに寄せる必要はありません。NRTに向いているのは、短時間で被害が拡大する操作です。
| NRTに向く例 | 通常のスケジュール検出でよい例 |
|---|---|
| break-glassアカウントの使用 | 週次の構成監査 |
| 特権ロールの急な付与 | 低リスクの棚卸しレポート |
| 大量の認証失敗と成功の連鎖 | 長期傾向を見る異常検知 |
| 既知の侵害端末からの横展開兆候 | 月次のコンプライアンス確認 |
NRT化する前に、誤検知時の対応も決めておくべきです。高頻度で誤検知が出るルールをNRT化すると、検出が速くなる代わりにSOCの作業負荷も速く増えます。
自動化とプレイブックで注意すべき変更
既存のプレイブックをすぐに書き直す必要はありません。ただし、Defenderポータルへオンボードした後は、Automation rulesやプレイブックの挙動に差分が出る可能性があります。
特に注意したいのは、インシデント条件、説明フィールド、手動実行、同期遅延です。Microsoft Learnでは、DefenderポータルでAutomation rulesを実行する場合、アラート発生からインシデント作成・更新を経てAutomation ruleが実行されるまで最大10分程度かかる場合があること、手動でアラートやエンティティに対してプレイブックを実行する操作がDefenderポータルでは未サポートであることなどが整理されています。(Microsoft Learn)
| 確認項目 | 失敗しやすいポイント | 対応 |
|---|---|---|
| Incident provider条件 | Defender統合後に前提が変わる | Analytics rule名やタグで条件を絞る |
| Incident title条件 | タイトル変更で自動化が外れる | ルール名、タグ、重大度など安定した条件を使う |
| Description参照 | SecurityIncidentテーブルのDescription前提が崩れる可能性 | 外部チケット連携の項目マッピングを再確認する |
| 手動プレイブック実行 | アラート・エンティティ単位の手動実行に制限 | インシデント単位の実行手順に寄せる |
| Logic Apps課金 | プレイブック実行回数増加で費用が増える | 高頻度ルールと自動化をセットで見直す |
プレイブックはAzure Logic Appsベースのため、外部システム連携には強い一方、実行回数やコネクタ利用による追加費用が発生する可能性があります。高頻度の検出ルールに重いプレイブックを付けている場合は、移行確認時にコストと実行時間も見直すべきです。(Microsoft Learn)
AIによるプレイブック生成は使う前提条件を確認する
今回の流れで注目されるのが、SOAR playbook generatorです。これは自然言語で自動化要件を説明し、Pythonベースのプレイブック、ドキュメント、フロー図を生成する機能です。Defenderポータル内のVS Code環境とClineを使って、プレイブックを作成・調整する仕組みです。(Microsoft Learn)
ただし、すべての環境ですぐ使えるとは限りません。Security Copilotの有効化、SCUの利用可能状態、Defenderポータルにオンボード済みのSentinelワークスペース、必要なRBAC権限などを確認する必要があります。特に本番対応に使う場合は、生成されたコードを人がレビューし、テスト用アラートで動作確認してから有効化する運用にしてください。(Microsoft Learn)
実務では、最初から「ユーザー無効化」「端末隔離」のような強い応答を自動化するより、次のような低リスク用途から始めると安全です。
| 初期導入に向く用途 | 理由 |
|---|---|
| インシデントへの調査メモ追加 | 誤動作しても影響が小さい |
| VirusTotalなど外部情報の付与 | アナリストの手作業を削減しやすい |
| Teamsやチケットシステムへの通知 | 既存運用に組み込みやすい |
| 担当者やタグの自動付与 | 影響範囲が限定的 |
ハンティングはAdvanced Hunting中心に慣れておく
Defenderポータルでは、Advanced Huntingが重要になります。Microsoftは、Microsoft SentinelをDefenderポータルにオンボードすると、既存のSentinelワークスペースのクエリや関数を含むコンテンツへアクセスでき、Defender XDRなどのデータソースと横断してクエリできると説明しています。(Microsoft Learn)
これにより、調査時の画面切り替えは減ります。たとえば、不審なメールを起点に、同じユーザーのサインイン、端末上のプロセス、クラウドアプリ操作、Sentinelに取り込んだネットワークログを同じ調査導線で追いやすくなります。
一方で、既存のSentinel運用に慣れたチームでは、次の点でつまずきやすくなります。
| つまずきやすい点 | 対応策 |
|---|---|
| SentinelのLogsとAdvanced Huntingのテーブル名・列名の違い | よく使う調査クエリを一覧化し、Defenderポータルで再実行して確認する |
| ブックマーク運用の違い | 重要なブックマーク、保存済みクエリ、調査手順を棚卸しする |
| 権限不足で一部データが見えない | Sentinel Readerだけで足りるか、Defender側の権限も必要か確認する |
| 複数ワークスペースの扱い | 代表ワークスペースで検証してから横展開する |
影響を受ける担当者
今回の変更は、Sentinel管理者だけの話ではありません。SOCの役割ごとに確認すべき点が異なります。
| 対象者 | 影響 | すぐやること |
|---|---|---|
| SOCアナリスト | インシデントキューと調査画面が変わる | Defenderポータルで主要インシデントの調査手順を試す |
| 検出エンジニア | 新規ルール作成の中心がカスタム検出へ寄る | 重要ルールをAnalytics rules継続、カスタム検出候補、廃止候補に分類する |
| SOAR担当 | 自動化条件と実行タイミングに差分が出る | Automation rulesとプレイブックの実行条件を検証する |
| SOCマネージャー | 運用KPI、手順書、教育が変わる | 移行計画、訓練、誤検知レビューの周期を決める |
| MSSP・複数テナント運用担当 | 権限、ワークスペース、顧客別運用の確認が必要 | テナントごとのオンボード状況とRBACを棚卸しする |
特に検出エンジニアは、既存ルールを「そのまま残すか」ではなく、「今後どの検出をどの基盤で育てるか」という観点で整理すると判断しやすくなります。
Defenderポータル移行の期限も合わせて確認する
この話は、Microsoft SentinelのDefenderポータル移行と切り離せません。Microsoft Learnでは、2027年3月31日以降、Microsoft SentinelはAzure portalでサポートされず、Microsoft Defenderポータルでのみ利用可能になると案内されています。(Microsoft Learn)
つまり、Detection and automation, reimaginedは単なる新機能紹介ではなく、2027年3月末までにSentinel運用をDefenderポータル前提へ寄せるための実務的なガイドとして読むべきです。
すでにSentinelをAzure portal中心で使っている組織は、次の順で進めると無理がありません。
| フェーズ | やること |
|---|---|
| まず1週間 | 主要ルール、プレイブック、Workbooks、権限を一覧化する |
| 次の2〜4週間 | Defenderポータルで代表的なインシデント調査と自動化をテストする |
| 次の1〜2か月 | 高重要度ルールからカスタム検出化の候補を選ぶ |
| 本番展開前 | SOC手順書、チケット連携、通知先、権限を更新する |
| 継続運用 | 誤検知、実行遅延、コスト、アナリスト負荷を定期レビューする |
すぐ確認したい実務チェックリスト
最後に、Microsoft Sentinel利用者がすぐ確認すべき項目を整理します。
| チェック | 確認内容 |
|---|---|
| Defenderポータル接続 | 対象ワークスペースがDefenderポータルで利用できるか |
| 重要インシデント | 代表的な重大インシデントが統合インシデントキューで見えるか |
| Analytics rules | 高重要度・高頻度・自動化付きルールを特定したか |
| カスタム検出候補 | Defender XDRデータと組み合わせたい検出を洗い出したか |
| NRT検出 | 本当に即時性が必要なルールだけをNRT候補にしたか |
| Automation rules | タイトルやDescription依存の条件が残っていないか |
| Playbooks | インシデント単位で実行できるか、外部連携が壊れないか |
| Workbooks | データ参照、リンク、権限、表示内容が維持されるか |
| Advanced Hunting | よく使うKQLと関数がDefenderポータルで使えるか |
| 権限 | Sentinel側だけでなくDefender側のロール不足がないか |
| コスト | Logic Apps、データ保持、検出頻度の増加が費用に影響しないか |
| 手順書 | SOCアナリストが新しい画面で同じ判断をできるか |
今回の変更で最も避けたいのは、「既存資産は残る」と聞いて何も確認しないことです。既存のルールやプレイブックは残っても、インシデントの見え方、相関、自動化の条件、担当者の権限が変われば、SOCの実運用では検出漏れや通知漏れにつながります。
まずは、重大度の高い検出と自動化から順にDefenderポータルで再現テストを行いましょう。そのうえで、新規作成する検出はカスタム検出を優先候補にし、既存のAnalytics rulesは安定稼働しているもの、見直すもの、将来置き換えるものに分けて管理するのが現実的です。
コメント