Microsoft Sentinel の「Detection and automation, reimagined」で管理者がまず押さえるべき結論は、既存の分析ルールやプレイブックを慌てて作り直す話ではなく、検出・自動化・ハンティングの主戦場を Microsoft Defender ポータル中心に見直す必要があるという点です。特に確認すべきなのは、Analytics rules と Custom detections の使い分け、インシデント相関、自動化ルールの条件、権限、監査ログ、SOCメンバーへの周知です。
この発表は Microsoft Sentinel Blog の Notice として扱われる更新であり、機能追加のニュースとして読むだけでは不十分です。管理者は「今のルールが動くか」だけでなく、「Defender ポータル上で、誰が、どのデータを見て、どの自動化が、どのインシデントに対して動くか」まで確認する必要があります。Microsoft Sentinel は Defender ポータルで一般提供されており、2027年3月31日以降は Azure ポータルでの Microsoft Sentinel サポートが終了し、Defender ポータルのみで利用する方針が示されています。(TECHCOMMUNITY.MICROSOFT.COM)
Detection and automation, reimagined の管理者向けチェックリスト
まずは次の表を使って、自社環境で確認が必要な項目を洗い出してください。重要なのは、全機能を一括移行することではなく、検出・自動化・調査・権限の依存関係を崩さないことです。
| 確認項目 | 管理者が見るべきポイント | 優先度 |
|---|---|---|
| 既存の Analytics rules | Defender ポータル上で表示、編集、発火、インシデント化が想定通りか | 高 |
| Custom detections | 新規の横断検出ルールを Custom detections で作るべきか | 高 |
| インシデント相関 | Defender XDR の相関エンジンで、従来と異なる単位にまとまらないか | 高 |
| Automation rules | Incident provider 条件、分析ルール名条件、説明フィールド依存がないか | 高 |
| Playbooks | Logic Apps の実行権限、トリガー、外部チケット連携が維持されるか | 高 |
| Workbooks | Defender ポータルで表示できるか、リンクやクエリが古い導線に依存していないか | 中 |
| Hunting queries | Advanced Hunting と Sentinel Hunting のどちらで使うべきか整理する | 中 |
| RBAC / URBAC | Azure RBAC、Defender unified RBAC、スコープ設定の重複や不足を確認する | 高 |
| 監査ログ | SentinelAudit、SentinelHealth、Purview 監査ログで変更追跡できるか | 高 |
| SOCへの周知 | 画面遷移、対応手順、エスカレーション条件を更新する | 高 |
発表の位置づけは「廃止」ではなく運用モデルの再設計
Detection and automation, reimagined は、Microsoft Sentinel の検出と自動化を Defender ポータルの統合運用に合わせて再整理する内容です。ポイントは、従来の Sentinel 単体の運用から、SIEM と XDR を同じポータル上で扱う運用へ寄せることです。
Microsoft Learn では、Defender ポータル上でも Microsoft Sentinel の主要な SIEM 機能、つまりデータ取り込み、分析ルール、インシデント、Workbooks、Hunting が統合された形で利用できると説明されています。また、Workbooks は Defender ポータルでも引き続きデータ可視化の主要な手段として機能します。(Microsoft Learn)
ただし、「画面が変わるだけ」と考えるのは危険です。インシデントの相関、アラートの見え方、自動化ルールの実行条件、Advanced Hunting での制約など、SOC運用に影響する差分があります。特に本番環境では、重大度の高い検出ルールと外部チケット連携から優先的に確認してください。
影響範囲：Analytics rules と Custom detections の使い分け
既存の Microsoft Sentinel Analytics rules は Defender ポータルでも検出、構成、管理が可能です。Microsoft Learn では、Analytics rules の作成、更新、管理、リポジトリ、API による管理機能は Defender ポータルでも利用できると説明されています。(Microsoft Learn)
一方で、新しく検出ルールを作る場合は、Custom detections を優先候補として検討する場面が増えます。Microsoft は、Microsoft Sentinel SIEM と Microsoft Defender XDR をまたぐ新規ルール作成では Custom detections が現在の推奨体験であると説明しています。Custom detections は Advanced Hunting クエリをもとに、定期実行、アラート生成、応答アクションを設定できます。(Microsoft Learn)
| 項目 | Analytics rules が向くケース | Custom detections が向くケース |
|---|---|---|
| 既存運用 | すでに Sentinel で安定稼働している検出 | 新規設計または見直し時 |
| データ範囲 | Sentinel ワークスペース内のログ中心 | Defender XDR と Sentinel データを横断したい |
| 運用目的 | 従来の SIEM ルール管理を維持したい | XDR の応答アクションやエンティティを活用したい |
| 移行リスク | 低い。既存ルールを維持しやすい | 仕様差分の検証が必要 |
| 注意点 | Defender の相関でインシデント単位が変わる可能性 | Sentinel データを含む場合、NRT 周波数などに制限あり |
Custom detections に寄せればすべて解決するわけではありません。Advanced Hunting で Microsoft Sentinel データを扱う場合、Sentinel データを含む Custom detections では Near real-time の検出頻度が使えないこと、Sentinel 側で作成・保存したカスタム関数がサポートされないことが明記されています。高頻度検出や既存 KQL 関数への依存がある場合は、移行前に必ずテストしてください。(Microsoft Learn)
インシデント相関は既存運用との差分を必ず確認する
Defender ポータルでは、Microsoft Defender XDR の相関エンジンが複数のアラートをまとめ、攻撃ストーリーとしてインシデントを構成します。これは分析効率を上げる一方、従来の Sentinel で「ルール単位」「アラート単位」に見ていた運用とは異なる結果になることがあります。(Microsoft Learn)
たとえば、従来は別々の Analytics rules から別々のインシデントが作られていたケースでも、Defender 側の相関ロジックによって1つのインシデントに統合される可能性があります。重大インシデントの通知、チケット起票、担当者割り当てをインシデント数で管理している組織では、件数やSLAの見え方が変わる場合があります。
Microsoft は、移行時の予測可能性を保つため、Analytics rules を Defender XDR の相関エンジンに含めるか除外するかを管理できる機能を用意しています。初回オンボード時は、既定で全 Analytics rules がテナントレベルで相関から除外されると説明されています。必要に応じて、特定ルールだけ相関に含める、または除外する設計を行います。(Microsoft Learn)
実務では、次の判断が重要です。
| ルールの種類 | 推奨判断 |
|---|---|
| 重大インシデントを必ず単独で扱いたいルール | 相関除外を検討する |
| 横展開や複数製品のアラートと合わせて見たいルール | 相関対象に含めることを検討する |
| チケットシステム連携の起点になっているルール | 相関後のインシデント件数とフィールドを検証する |
| SOCの一次対応でノイズが多いルール | 相関とチューニングの効果を検証する |
Automation rules と Playbooks で見落としやすい変更点
Detection and automation, reimagined の確認で最も事故につながりやすいのが、自動化です。特に、インシデント作成後に Logic Apps を呼び出す Playbook、ServiceNow などの外部チケット連携、Teams 通知、メール通知、証拠保全処理は、本番移行前にテストが必要です。
Microsoft Learn では、Defender ポータルで Microsoft Sentinel の Automation rules と Playbooks を扱う際の制限が説明されています。たとえば、アラートトリガーの Automation rules は Microsoft Sentinel アラートにのみ作用します。また、インシデントトリガーでは Incident provider 条件が削除され、すべてのインシデントの ProviderName が Microsoft XDR になります。さらに、オンボード後は SecurityIncident テーブルに Description フィールドが含まれなくなるため、このフィールドを条件や外部連携で使っている場合は修正が必要です。(Microsoft Learn)
| 確認対象 | 失敗しやすい例 | 対応 |
|---|---|---|
| Incident provider 条件 | Sentinel のみを対象にしたつもりが Defender XDR インシデントにも動く | 分析ルール名や別条件で絞り込む |
| Description フィールド | チケット本文や条件分岐が空になる | 代替フィールドへ変更する |
| Playbook 実行権限 | Logic Apps は存在するが実行・編集できない | Logic Apps Contributor / Playbook Operator 相当を確認 |
| 実行タイミング | インシデント生成後すぐに自動化されない | 遅延を前提にSLAを見直す |
| 外部連携URL | Azure ポータルの incidentUrl に依存している | providerIncidentUrl など Defender 側の項目を確認する |
自動化は「動いたかどうか」だけでなく、「どの対象に動いたか」を確認してください。特に隔離、アカウント無効化、チケット自動クローズのような強いアクションは、テスト用インシデントで対象範囲を確認してから本番化するのが安全です。
Workbooks と Hunting は「残るが使いどころが変わる」
Workbooks は Defender ポータルでも引き続き利用できます。Microsoft Learn では、Azure Workbooks が Defender ポータルでもデータ可視化と対話の主要ツールとして機能すると説明されています。導線としては、Defender ポータル内の Microsoft Sentinel > Threat management > Workbooks から利用する形になります。(Microsoft Learn)
ただし、Workbooks 内のリンク、説明文、運用手順が Azure ポータル前提になっている場合は修正が必要です。たとえば「Azure ポータルの Sentinel > Incidents を開く」といった手順が残っていると、SOCメンバーが新旧ポータルを行き来して混乱します。
Hunting については、Advanced Hunting で Microsoft Defender for Endpoint、Defender for Office 365、Defender for Cloud Apps、Defender for Identity、Microsoft Sentinel の広いデータセットを検索できます。これは横断調査に有効ですが、Bookmarks は Advanced Hunting ではサポートされず、Defender ポータルの Microsoft Sentinel > Threat management > Hunting 側で扱う必要があります。(Microsoft Learn)
権限確認：Azure RBAC、Defender unified RBAC、スコープを整理する
Microsoft Sentinel を Defender ポータルへ接続した後も、既存の Azure RBAC 権限は Defender ポータル上の Sentinel 機能に反映されます。Microsoft は、Microsoft Sentinel ユーザーのロールと権限は引き続き Azure ポータルで管理でき、Azure RBAC の変更は Defender ポータルにも反映されると説明しています。(Microsoft Learn)
一方で、Defender unified RBAC を有効化すると、複数のセキュリティ製品にまたがる権限管理を1か所で行いやすくなります。Microsoft Sentinel についても、Defender ポータルにオンボードされたワークスペースを対象に unified RBAC がサポートされています。ただし、サービスプリンシパルや GDAP ユーザーグループへの Sentinel 権限付与は unified RBAC ではサポートされないため、必要な場合は Azure RBAC を使い続ける判断が必要です。(Microsoft Learn)
特に MSSP や複数テナント運用では注意が必要です。Microsoft Sentinel データを Defender ポータルで扱う場合、GDAP と Azure Lighthouse の組み合わせはサポートされず、Microsoft Entra B2B 認証を使うよう案内されています。委託先SOCやグループ会社を含む運用では、移行前にアクセス方式を確認してください。(Microsoft Learn)
権限設計では、次のように分けて考えると整理しやすくなります。
| 役割 | 最小限確認したい権限 |
|---|---|
| SOC一次対応 | インシデント閲覧、アラート調査、コメント、割り当て |
| SOC二次対応 | 高度な調査、KQL実行、必要な応答アクション |
| 検出エンジニア | Analytics rules、Custom detections、Hunting queries の作成・編集 |
| 自動化担当 | Automation rules、Logic Apps、接続情報、実行履歴の確認 |
| 管理者 | RBAC、オンボード、相関設定、監査、ワークスペース設定 |
また、Microsoft Sentinel scoping、つまり行レベルRBACを使う場合は、検出ルールや Custom detections の KQL で SentinelScope_CF を project する必要があります。これを忘れると、スコープ付きユーザーにアラートが見えないなど、権限不備に見える問題が発生します。(Microsoft Learn)
監査確認：変更履歴と正常性を追える状態にする
管理者は、移行や設定変更の前に監査と正常性確認の仕組みを有効にしておくべきです。Microsoft Sentinel では、Analytics rules の実行結果や失敗理由を SentinelHealth に、ルール変更の詳細を SentinelAudit に記録できます。監査ログには、変更されたルール名、変更プロパティ、変更前後の状態、変更者、ソースIP、変更日時などが含まれます。(Microsoft Learn)
まず、Microsoft Sentinel の health and audit monitoring を有効化し、次のようなクエリでデータが出るか確認します。Microsoft Learn でも、_SentinelHealth() と _SentinelAudit() を使った確認例が示されています。(Microsoft Learn)
_SentinelHealth()
| take 20_SentinelAudit()
| take 20Custom detections については、Microsoft Defender XDR の監査ログも確認対象です。Microsoft Defender XDR の監査は Microsoft Purview auditing solution を利用し、Defender ポータルまたは Purview compliance portal から検索できます。Custom detection rule の作成、編集、削除、状態変更、手動実行などは監査アクティビティとして記録されます。(Microsoft Learn)
監査で最低限残したい観点は次の4つです。
| 監査対象 | 確認する理由 |
|---|---|
| Analytics rules の変更 | 検出漏れや過検知の原因調査に必要 |
| Automation rules の実行 | 意図しない Playbook 実行を追跡するため |
| Custom detections の変更 | 新しい検出ルールの責任者と変更理由を残すため |
| RBAC の変更 | 誰がデータや応答アクションにアクセスできるかを証明するため |
移行前に確認すべき実務手順
移行作業は、画面を切り替えるだけでなく、運用手順を再検証する作業として進めます。おすすめは、重要度の高い検出から小さく検証し、問題がなければ対象を広げる方法です。
既存資産を棚卸しする
最初に、Analytics rules、Automation rules、Playbooks、Workbooks、Hunting queries、外部チケット連携、通知先を一覧化します。棚卸しでは、単に数を数えるのではなく、次の情報を付けておくと移行判断がしやすくなります。
| 棚卸し項目 | 記録する内容 |
|---|---|
| ルール名 | Analytics rule / Custom detection の名前 |
| 重要度 | High / Medium / Low |
| 利用データ | Sentinel ログのみか、Defender XDR データも必要か |
| 自動化 | Playbook、Teams通知、チケット作成の有無 |
| 担当者 | 検出ルールのオーナー、SOC担当、承認者 |
| 最終発火日 | 最近使われているか、ノイズ化していないか |
| 移行方針 | 維持、修正、Custom detection 化、廃止 |
パイロット対象を決める
最初から全ワークスペースを切り替えるのではなく、代表的なワークスペース、重大度の高い検出、外部連携を含む自動化を選んで検証します。Defender ポータルではプライマリワークスペースの考え方があり、複数ワークスペースでは相関の扱いにも差があります。プライマリワークスペースのアラートは Defender アラートと相関できますが、セカンダリワークスペースのアラートは Defender や他のデータソースと相関されません。(Microsoft Learn)
インシデント相関をテストする
検証用のアラートを発生させ、従来と同じ単位でインシデントが作られるか、または Defender 側で統合されるかを確認します。チケットシステムと連携している場合は、チケット件数、重大度、担当者、URL、説明文、クローズ条件まで確認してください。
自動化の条件を更新する
Automation rules では、Incident provider や Description フィールドへの依存が特に危険です。条件が古いままだと、自動化が動かない、または想定外のインシデントに動く可能性があります。検証時は「発火しない場合」と「発火してはいけない場合」の両方をテストしてください。
ドキュメントとSOC手順を更新する
運用手順書には、Defender ポータルでの導線を明記します。たとえば、Incidents は Investigation & response > Incidents & alerts > Incidents、Workbooks は Microsoft Sentinel > Threat management > Workbooks、Analytics は Microsoft Sentinel > Configuration > Analytics、Custom detection rules は Investigation and response > Hunting > Custom detection rules というように、旧Azureポータルの手順から更新します。(Microsoft Learn)
周知すべき相手と伝える内容
Detection and automation, reimagined は、Sentinel 管理者だけで完結しません。SOC、インフラ、ID管理、ヘルプデスク、外部委託先まで関係します。関係者ごとに伝える内容を変えると、混乱を抑えられます。
| 対象 | 周知内容 |
|---|---|
| SOCアナリスト | インシデントの見方、相関後の判断、旧ポータルとの差分 |
| 検出エンジニア | Analytics rules と Custom detections の使い分け、KQL制約 |
| 自動化担当 | Automation rules、Playbooks、外部チケット連携の変更点 |
| 権限管理者 | Azure RBAC、Defender unified RBAC、B2B、スコープ設計 |
| 経営・管理部門 | Azure ポータルから Defender ポータルへの移行方針と期限 |
| MSSP / 委託先 | アクセス方式、テナント運用、対応範囲、連絡フロー |
周知では「Microsoft Sentinel がなくなる」と誤解されないようにしてください。正しくは、Microsoft Sentinel の運用体験が Defender ポータルへ統合され、検出、自動化、調査の設計を Defender XDR と組み合わせて見直す流れです。
失敗しやすいポイント
既存ルールをすべて Custom detections に置き換えようとする
Custom detections は新規の横断検出に有効ですが、既存の Analytics rules を無理にすべて置き換える必要はありません。安定しているルールは維持し、Defender XDR データとの横断、応答アクション、エンティティ活用が必要なものから検討するのが現実的です。
インシデント件数だけで移行後の正常性を判断する
Defender の相関により、複数のアラートが1つのインシデントにまとまることがあります。移行前後で件数だけを比較すると、検出漏れと誤解する可能性があります。アラート、エンティティ、相関理由、チケット起票結果まで確認してください。
Playbook の実行権限を見落とす
Sentinel の画面で見えていた Playbook が、実行・編集・接続情報の更新までできるとは限りません。Logic Apps 側の権限、マネージドID、接続先APIの権限を含めて確認してください。
スコープ付きユーザーにアラートが見えない
Microsoft Sentinel scoping を使っている場合、KQLで SentinelScope_CF を project しないと、スコープ付きユーザーにアラートが表示されないことがあります。これはUIの不具合ではなく、スコープ継承の設計漏れとして確認すべきです。(Microsoft Learn)
旧ポータル前提の手順書を残す
Azure ポータルの導線を前提にした手順書、教育資料、チケット本文、リンク集が残っていると、SOC対応が遅れます。移行リハーサルの時点で、スクリーンショットと手順を Defender ポータル版へ更新してください。
管理者が次に取るべき行動
Detection and automation, reimagined を受けて、Microsoft Sentinel 管理者が最初にやるべきことは3つです。
まず、既存の Analytics rules、Automation rules、Playbooks、Workbooks、Hunting queries を棚卸しし、重大度と自動化依存の有無で優先順位を付けます。次に、Defender ポータル上で代表的なインシデントを再現し、相関、自動化、チケット連携、監査ログを確認します。最後に、SOC向けの手順書と権限設計を更新し、2027年3月31日以降の Defender ポータル前提の運用へ段階的に移行します。(Microsoft Learn)
この更新は、単なる画面変更ではありません。Microsoft Sentinel の検出、SOAR、自動化、ハンティングを、Defender XDR と同じ運用面で扱うための設計変更です。管理者は「移行できるか」ではなく、「移行後も同じ品質で検出し、必要な人だけが見て、正しい自動化が動くか」を基準に確認を進めてください。
コメント