「Create and use Microsoft Sentinel automation rules to manage response」で最初に押さえるべき結論は、Microsoft Sentinelの自動化ルールを“作る手順”だけでなく、Microsoft Defenderポータル移行後のインシデント対応ルールとして再点検する必要がある、という点です。特に、AzureポータルでMicrosoft Sentinelを運用している組織は、2027年3月31日以降のDefenderポータル集約を前提に、自動化ルール、プレイブック、API連携、チケット連携の条件を見直すべきです。Microsoft Learnの該当ページは2026年5月14日に更新され、対象は「Microsoft DefenderポータルのMicrosoft Sentinel」と「AzureポータルのMicrosoft Sentinel」の両方です。(Microsoft Learn)
この記事では、Microsoft Defenderに関連する「Create and use Microsoft Sentinel automation rules to manage response」の要点を、管理者・SOC担当者・開発者が確認すべき変更点、影響範囲、設定、移行、展開上の注意点に絞って整理します。自動化ルールを使うと、インシデントの担当者割り当て、重大度変更、タグ付け、ノイズの多いインシデントの抑制、プレイブック実行などを標準化できます。ただし、Defenderポータル移行後はインシデント相関、条件評価、API応答、プレイブック実行タイミングが変わる可能性があるため、既存ルールをそのまま放置するのは避けるべきです。
Create and use Microsoft Sentinel automation rules to manage responseの要点
Microsoft Sentinelの自動化ルールは、インシデントやアラートが作成・更新されたタイミングで、あらかじめ定義した条件に基づき対応アクションを実行する仕組みです。公式ドキュメントでは、SOCの効率と脅威対応の有効性を高めるために、トリガー、条件、アクションを設計して自動化ルールを作成・利用する流れが説明されています。(Microsoft Learn)
自動化ルールでできる代表的な処理は次のとおりです。
| 目的 | 自動化ルールでできること | 実務での使いどころ |
|---|---|---|
| 初動対応の標準化 | 新規インシデントをActiveに変更し、担当者を割り当てる | 夜間・休日の一次対応、Tier 1 SOCの受付処理 |
| ノイズ削減 | 条件に合うインシデントを自動クローズまたはタグ付けする | 既知の誤検知、検証環境からの定常アラート |
| 優先度判断 | 重大度を変更し、特定タグを付与する | 重要サーバー、特権アカウント、特定MITRE戦術を含む検知 |
| 外部連携 | Azure Logic Appsベースのプレイブックを実行する | ServiceNow、Jira、Teams、メール、SOAR連携 |
| 監査・運用改善 | ルールの実行順序や有効期限を管理する | 一時的な抑制、段階的な自動化展開 |
重要なのは、「検知したらすぐ何でも自動実行する」ことではありません。自動化ルールは、SOCが毎回同じ判断をしている処理をルール化し、人が判断すべきインシデントを見つけやすくするために使います。
2026年5月14日更新で管理者が見るべき変更点
今回の公式情報で特に重要なのは、Microsoft SentinelがDefenderポータル中心の運用へ移っていることです。Microsoftは、2027年3月31日以降、Microsoft SentinelはAzureポータルでサポートされず、Microsoft Defenderポータルのみで利用可能になると案内しています。AzureポータルでSentinelを使っている組織は、早めにDefenderポータルへの移行計画を立てる必要があります。(Microsoft Learn)
変更点を実務目線で見ると、次の4つが大きな確認ポイントです。
| 確認ポイント | 何が変わるか | 管理者・開発者が取るべき対応 |
|---|---|---|
| 操作場所 | AutomationはDefenderポータルの「Microsoft Sentinel > Configuration > Automation」から管理する | Azureポータル前提の手順書、運用フロー、教育資料を更新する |
| インシデント相関 | DefenderポータルではDefender XDRの相関エンジンがインシデント統合に関与する | インシデント名や件数を前提にした自動化条件を見直す |
| 条件評価 | Defenderポータル移行後、Incident providerやDescription条件に影響が出る | ルール条件を「分析ルール名」「タグ」「エンティティ」中心に再設計する |
| プレイブック連携 | 実行権限、同期遅延、手動実行できない対象に注意が必要 | Logic Apps権限、実行ログ、外部チケット連携を検証する |
Defenderポータルでは、インシデント、アラート、調査を単一の画面で扱う統合セキュリティ運用が強化されています。Microsoft SentinelはDefender XDRと一体化した体験として提供され、SIEMとXDRをまたいだ検知・調査・対応を進めやすくなります。(Microsoft Learn)
対象者と影響範囲
この更新の影響を受けるのは、Microsoft DefenderやMicrosoft Sentinelを直接操作するSOC担当者だけではありません。自動化ルールはインシデント対応、プレイブック、外部チケット、API連携にまたがるため、複数の担当者で確認する必要があります。
| 対象者 | 主な影響 | 確認すべきこと |
|---|---|---|
| セキュリティ管理者 | 自動化ルールの設計・実行順序・有効期限 | 既存ルールの棚卸し、Defenderポータルでの動作確認 |
| SOCアナリスト | インシデントキュー、タグ、担当者、重大度の扱い | どのアラートが自動処理されるか、手動判断が必要な条件 |
| プレイブック開発者 | Logic Apps、外部サービス、権限 | Run playbookの権限、トリガー種別、失敗時の再実行手順 |
| API・連携担当者 | Graph API、SecurityInsights API、チケット連携 | incidentUrlやproviderNameなど応答フィールドの差分 |
| MSSP・マルチテナント管理者 | 複数ワークスペース、複数テナントの自動化 | プライマリワークスペース、委任権限、プレイブック配置場所 |
Microsoft SentinelをDefenderポータルに統合しても、Log Analyticsの観点では基本的なデータ収集パイプラインやデータスキーマは維持されます。一方で、Defender製品に関連するアラートはMicrosoft Defender XDRコネクタからストリーミングされるため、インシデントとアラートの取り込み設定や、Defender for Cloud連携時の重複イベント対策は確認が必要です。(Microsoft Learn)
自動化ルールの基本構成
Microsoft Sentinelの自動化ルールは、主に「トリガー」「条件」「アクション」で構成されます。この3つを分けて考えると、既存ルールの見直しや新規作成がしやすくなります。
トリガーはインシデント中心で設計する
自動化ルールのトリガーには、主に次の3種類があります。
| トリガー | 実行されるタイミング | 向いている用途 |
|---|---|---|
| When incident is created | 新しいインシデントが作成されたとき | 初動対応、担当者割り当て、重大度変更、タグ付け |
| When incident is updated | ステータス、所有者、重大度、タグ、コメントなどが変更されたとき | エスカレーション、再オープン時の通知、更新後の再評価 |
| When alert is created | Microsoft SentinelのScheduledまたはNRT分析ルールでアラートが作成されたとき | インシデントを作成しないアラートへの個別対応 |
多くのケースでは、アラート単位ではなくインシデント単位で自動化する方が安全です。Microsoftの説明でも、インシデントはアラート、エンティティ、コメント、コラボレーション情報などを含む「調査のケースファイル」として扱われるため、攻撃ストーリーの変化を追いやすいとされています。(Microsoft Learn)
例外は、分析ルール側でインシデント作成を無効にしているアラートです。この場合は、alert triggerを使ってプレイブックを動かし、外部システムでチケットを作る、通知だけ送る、既存インシデントへ追加する、といった使い方が考えられます。ただし、DefenderポータルではMicrosoft Defender XDRが作成したアラートに対するalert-triggered automationは利用できない点に注意してください。(Microsoft Learn)
条件は「タイトル」より「分析ルール名・タグ・エンティティ」を使う
自動化ルールでは、条件によって「どのインシデントやアラートに適用するか」を絞り込みます。たとえば、特定の分析ルール名を含むインシデントだけを対象にしたり、特定のタグ、重大度、ステータス、エンティティ情報を条件にしたりできます。
Defenderポータル移行後に特に避けたいのは、インシデントタイトルへの過度な依存です。Defenderポータルでは独自の相関エンジンにより、既存インシデント名が変更される可能性があります。Microsoftは、自動化ルールが安定して動くように、条件にはインシデントタイトルではなく、アラートを作成した分析ルール名やタグを使うことを推奨しています。(Microsoft Learn)
条件設計の実務的な判断基準は次のとおりです。
| 条件に使う項目 | 推奨度 | 理由 |
|---|---|---|
| Analytic rule name | 高 | 検知ロジックに紐づくため、タイトル変更の影響を受けにくい |
| Tag | 高 | SOC運用上の分類に使いやすく、抑制やエスカレーションに向く |
| Entity property | 中〜高 | 重要ホスト、特権ユーザー、IPなど実害に近い条件を作れる |
| Severity / Status | 中 | 初動分類に便利だが、他ルールによる変更順序に注意 |
| Incident title | 低 | Defenderポータル移行後の相関や名称変更の影響を受けやすい |
| Description | 低 | Defenderポータル移行後にSecurityIncidentテーブルへ含まれないため注意が必要 |
Defenderポータルへオンボード後は、SecurityIncidentテーブルにDescriptionフィールドが含まれなくなるため、インシデント作成トリガーの条件にDescriptionを使っている自動化ルールは動作しなくなる可能性があります。ServiceNowなど外部チケットシステムとの連携でも、インシデント説明が欠落する影響を確認する必要があります。(Microsoft Learn)
アクションはシンプルな処理から段階的に増やす
自動化ルールのアクションには、担当者割り当て、ステータス変更、重大度変更、タグ追加、プレイブック実行などがあります。alert triggerを使う自動化ルールでは、利用できるアクションはRun playbookのみです。(Microsoft Learn)
実務では、最初から複雑なプレイブックを大量に実行するより、まずは次のような軽い自動化から始めるのが安全です。
| 段階 | 自動化例 | 狙い |
|---|---|---|
| 第1段階 | タグ付け、担当者割り当て | SOCが見落とさない状態を作る |
| 第2段階 | 重大度変更、ステータス変更 | 優先度をそろえ、初動を速くする |
| 第3段階 | Teams通知、チケット作成 | 外部ワークフローへ接続する |
| 第4段階 | ブロック、隔離、無効化などの対応 | 誤実行リスクを評価したうえで限定的に展開する |
プレイブックを実行する場合、Microsoft Sentinelには対象プレイブックのリソースグループへアクセスする明示的な権限が必要です。権限を付与する管理者自身には対象リソースグループのOwner権限が必要で、プレイブックを含むリソースグループにはMicrosoft Sentinel Automation Contributorロールが必要です。(Microsoft Learn)
Defenderポータル移行後に壊れやすい設定
自動化ルールは、画面上では有効に見えても、条件や連携先の前提が変わると期待どおりに動きません。特に以下は移行時の失敗パターンになりやすい項目です。
| 失敗しやすい設定 | 起こり得る問題 | 対策 |
|---|---|---|
| Incident provider条件に依存している | DefenderポータルではProviderNameがMicrosoft XDRになり、意図せず広範囲にルールが走る可能性がある | 分析ルール名、タグ、エンティティで対象を絞る |
| インシデントタイトルを条件にしている | 相関エンジンによりインシデント名が変わる可能性がある | タイトル条件を減らし、Analytic rule nameを使う |
| Descriptionを条件や外部チケット本文に使っている | Descriptionが欠落し、ルール不発やチケット情報不足が起きる | カスタム詳細、アラート情報、Graph API側の取得項目を見直す |
| プレイブックの権限をAzureポータル前提で設定している | DefenderポータルでRun playbookが表示されない、実行できない | Manage playbook permissionsで権限を再確認する |
| ルールの実行順序を管理していない | 先に実行されたルールが重大度やタグを変え、後続条件の評価結果が変わる | ルール順序を明示し、テスト用インシデントで検証する |
| 複数ワークスペースにXDRデータを連携している | Defenderポータルではデータがプライマリワークスペースへ取り込まれる | 関連する自動化ルールを適切なワークスペースへ移す |
Defenderポータルでは、アラート発生からインシデント作成・更新を経て自動化ルールが実行されるまで、最大10分程度かかる可能性があります。また、Microsoft DefenderインシデントがMicrosoft Sentinelに表示されるまで最大5分程度かかる場合があり、その場合はプレイブック実行も遅延します。リアルタイム遮断を前提にした自動化では、この遅延を設計に含めるべきです。(Microsoft Learn)
自動化ルール作成時の実務手順
自動化ルールを新しく作る場合は、画面操作から始めるのではなく、先に「何を、どの条件で、どこまで自動処理するか」を決めます。
| 手順 | 作業内容 | 判断基準 |
|---|---|---|
| 1 | 対象を決める | すべてのインシデントか、特定の分析ルール・タグ・エンティティだけか |
| 2 | トリガーを選ぶ | 原則はincident created / updated。例外的にalert createdを使う |
| 3 | 条件を設計する | タイトルではなく、分析ルール名、タグ、重要エンティティを優先する |
| 4 | アクションを決める | タグ付け・担当者割り当てから始め、プレイブックは段階導入する |
| 5 | 実行順序を決める | 抑制、分類、通知、外部連携の順序を明確にする |
| 6 | 有効期限を設定する | 一時的な抑制ルールはIndefiniteにせず期限を入れる |
| 7 | 監査クエリで確認する | Automationによる変更履歴をSecurityIncidentで確認する |
Microsoft Sentinelでは、Automationページから自動化ルールを一元管理できます。ルールの有効化・無効化、実行順序の変更、対象分析ルールの確認ができるため、複数の分析ルールにまたがる自動化や、Defender XDR由来のインシデントを対象にする場合はAutomationページから管理するのが実務的です。(Microsoft Learn)
監査では、次のようなKQLでAutomationによる変更履歴を確認できます。
SecurityIncident
| where ModifiedBy contains "Automation"このクエリは、特定のインシデントに対して自動化ルールがどのような変更を行ったかを追跡する入口になります。ルール作成後は、少なくともテスト用インシデント、実運用初日の対象インシデント、誤検知が多い分析ルールの3パターンで確認しましょう。(Microsoft Learn)
プレイブック移行で確認すべきこと
既存のプレイブックを分析ルールから直接呼び出している環境は、特に注意が必要です。Microsoftは、アラートトリガーのプレイブックを分析ルールから呼び出すのではなく、自動化ルールから呼び出す構成へ移行することを推奨しています。公式ドキュメントでは、この方式により単一画面での自動化管理、複数分析ルールへの適用、実行順序の制御、有効期限の利用ができると説明されています。(Microsoft Learn)
公式情報では、分析ルールからプレイブックを呼び出す機能は2026年3月に非推奨化されるとされ、2023年6月以降は分析ルールから呼び出すプレイブックを新たに追加できないとされています。2026年5月時点で運用を続けている場合は、「まだ動いているか」ではなく、「自動化ルール経由に移行済みか」を基準に棚卸しすべきです。(Microsoft Learn)
移行時の確認項目は次のとおりです。
| 確認項目 | チェック内容 |
|---|---|
| プレイブックのトリガー | incident trigger用か、alert trigger用かを確認する |
| 呼び出し元 | 分析ルール直下ではなく、自動化ルールからRun playbookしているか |
| 権限 | Logic Apps Contributor、Microsoft Sentinel Contributor、Automation Contributor相当の権限を確認する |
| 外部連携 | ServiceNow、Jira、Teamsなどで必要なフィールドが欠落していないか |
| エラー処理 | プレイブック失敗時の通知、再実行、手動代替手順を決めているか |
| 実行遅延 | Defenderポータル同期による遅延をSLAに含めているか |
プレイブックは便利ですが、誤った条件で実行されると、チケット乱立、誤通知、不要な遮断などを引き起こします。最初は通知やチケット作成に限定し、アカウント無効化、端末隔離、IPブロックのような強い対応は、条件を十分に絞ってから展開するのが安全です。
API連携・外部チケット連携の注意点
Defenderポータルの統合体験では、インシデントとアラートに関するAPIの扱いも見直しが必要です。Microsoftは、統合されたインシデントやアラートを扱う場合はMicrosoft Graph REST APIの利用を推奨しています。一方で、分析ルールや自動化ルールなどMicrosoft Sentinelリソースへの操作は、引き続きMicrosoft Sentinel APIでサポートされます。(Microsoft Learn)
外部チケット連携で特に確認すべきフィールドは次のとおりです。
| 項目 | Azureポータル中心の運用での見方 | Defenderポータル移行後の注意 |
|---|---|---|
| インシデントURL | incidentUrlを使うことが多い | providerIncidentUrlを利用した方がDefenderポータルの直接リンクに向く |
| providerName | Azure Sentinelとして扱われる場合がある | DefenderポータルではMicrosoft XDRになる |
| alertProductNames | そのまま参照できる前提になりがち | Graph APIでは?$expand=alertsが必要なケースを確認する |
| serviceSource / detectionSource / productName | 既存処理に存在しない場合がある | Defender側の検知元・製品名として連携ロジックへ反映する |
| Description | チケット本文に使われがち | Defenderポータル移行後の欠落に備え、別フィールドで補完する |
たとえばServiceNow連携で「インシデントタイトル＋Description＋incidentUrl」を固定的に送っている場合、Defenderポータル移行後に説明文が不足したり、リンク先が運用画面と合わなかったりする可能性があります。チケット本文には、分析ルール名、重大度、エンティティ、関連アラート、Defender側URL、担当チーム、推奨初動を明示的に入れる設計に変えると安定します。
展開・移行前のチェックリスト
本番環境で自動化ルールを展開する前に、次の順番で確認すると失敗を減らせます。
| 項目 | 確認する内容 | 優先度 |
|---|---|---|
| Azureポータル依存 | 手順書、スクリーンショット、教育資料がAzureポータル前提になっていないか | 高 |
| 既存ルール棚卸し | 有効・無効、実行順序、有効期限、対象分析ルールを一覧化したか | 高 |
| 条件の安定性 | タイトル、Description、Incident providerへ依存していないか | 高 |
| プレイブック移行 | 分析ルール直下の呼び出しから自動化ルール経由へ移したか | 高 |
| 権限 | Sentinel、Logic Apps、リソースグループ、マルチテナント権限を確認したか | 高 |
| Defender XDRコネクタ | インシデントとアラートの取り込みが有効か、重複がないか | 中〜高 |
| API応答 | Graph APIとSentinel APIの使い分け、フィールド差分を確認したか | 中〜高 |
| 監査 | SecurityIncidentでAutomation実行履歴を確認できるか | 中 |
| CI/CD | ARMテンプレート、JSON、Content as codeで管理できるか | 中 |
| 教育 | SOCアナリストがDefenderポータルの統合インシデントキューに慣れているか | 中 |
自動化ルールはARMテンプレートとしてエクスポート・インポートでき、ワークスペースやテナントをまたいだ展開、バージョン管理、CI/CD管理にも利用できます。複数環境で同じルールを使う場合は、画面で手作業コピーするよりも、JSONを管理して差分を追える形にする方が安全です。(Microsoft Learn)
また、DefenderポータルではMicrosoft SentinelのWorkspace Managerが利用できないため、複数ワークスペースへコンテンツを配布する場合は、リポジトリからのContent as code、マルチテナントポータル、Content hubの利用を検討します。(Microsoft Learn)
実務で使いやすい自動化ルール例
既知の誤検知を一時的に抑制する
検証環境や既知のスキャナーから定期的に出る低リスクのアラートは、自動化ルールでタグ付けし、必要に応じてクローズします。ただし、抑制ルールには有効期限を設定してください。恒久的に無効化すると、環境変更後に本物の攻撃を見落とす可能性があります。
設計例は次のとおりです。
| 項目 | 設定例 |
|---|---|
| トリガー | When incident is created |
| 条件 | Analytic rule name contains 特定ルール名、Entity Host name contains 検証環境名 |
| アクション | Add tag: known-fp、Change status: Closed、コメントに理由を記録 |
| 有効期限 | 30日後 |
| 確認 | 週次で対象件数と誤クローズの有無を確認 |
重要資産に関わるインシデントを自動エスカレーションする
特権アカウント、ドメインコントローラー、決済系サーバーなど、影響が大きい資産に関する検知は、重大度を引き上げて担当チームへ通知します。
| 項目 | 設定例 |
|---|---|
| トリガー | When incident is created |
| 条件 | Entity account contains admin、またはHost nameが重要資産リストに一致 |
| アクション | Change severity: High、Add tag: critical-asset、Run playbook |
| プレイブック | Teams通知、ServiceNowチケット作成 |
| 注意点 | 通知先が多すぎるとアラート疲れを招くため、対象条件を絞る |
インシデント更新時に再オープンを通知する
一度クローズしたインシデントが再オープンされた場合、通常の新規インシデントよりも見落とされやすくなります。incident updatedトリガーを使い、ステータス変更を条件に通知すると、再調査の漏れを減らせます。
| 項目 | 設定例 |
|---|---|
| トリガー | When incident is updated |
| 条件 | Status changed to Active、Severity equals High |
| アクション | Add tag: reopened、Run playbook |
| 注意点 | 短時間に複数更新がある場合、更新情報が集約される可能性を考慮する |
まず実施すべき次のアクション
Microsoft Defender環境で「Create and use Microsoft Sentinel automation rules to manage response」を確認するなら、最初にやるべきことは新規ルール作成ではなく、既存の自動化ルールとプレイブックの棚卸しです。
優先順位は明確です。まず、Azureポータル前提の手順や分析ルール直下のプレイブック呼び出しを洗い出します。次に、タイトル、Description、Incident providerに依存する条件を見直し、Analytic rule name、タグ、エンティティ中心の条件へ寄せます。そのうえで、DefenderポータルのAutomationページで実行順序、権限、有効期限、監査ログを確認します。
自動化ルールは、SOCを楽にするための仕組みである一方、誤った条件で広範囲に適用すると対応品質を下げます。2027年3月31日のDefenderポータル集約を待つのではなく、2026年のうちに小さなルールから検証し、プレイブック、API、チケット連携まで含めて段階的に移行することが、最も安全な進め方です。
コメント