Microsoft Defender環境で「Microsoft Sentinel automated responses」を確認する目的は、単にプレイブックを作ることではありません。結論から言うと、Microsoft Sentinelの自動応答は、Automation rulesで実行条件と順序を管理し、Azure Logic AppsベースのPlaybooksで通知・調査・封じ込めを実行する設計として整理する必要があります。
特に、Microsoft SentinelをMicrosoft Defenderポータルで利用する流れが強まっているため、既存のAzureポータル運用、Analytics rules、Playbooks、外部チケット連携、Microsoft Entra ID条件をそのまま移すと、自動化が想定どおり動かない可能性があります。本記事では、2026年6月3日時点で確認すべき公式情報を前提に、変更点、影響範囲、管理者・開発者が見るべき設定を実務目線で整理します。
Microsoft Sentinel automated responsesとは何か
「Microsoft Sentinel automated responses」は、Azure Architecture Centerで公開されているMicrosoft Sentinelの自動応答アーキテクチャ案です。Microsoft SentinelはSIEMとSOARの機能を持ち、脅威検出、ハンティング、自動インシデント対応を支援します。脅威対応はPlaybooksで管理され、アラートやインシデントをきっかけに、Azure Logic Appsで定義した一連の処理を実行します。(Microsoft Learn)
公式アーキテクチャでは、Microsoft Entra ID Protectionが不審なサインインを検出し、Microsoft Sentinelにアラートを送信し、インシデント化された後にPlaybookが実行され、侵害が疑われるMicrosoft Entraユーザーをブロックする例が示されています。(Microsoft Learn)
これは「新しい単体機能」というより、企業のSOCやSecOpsがMicrosoft Defender、Microsoft Sentinel、Microsoft Entra ID、Azure Logic Appsを組み合わせて、検知から初動対応までを自動化するための設計パターンと捉えるのが正確です。
何が変わるのか
今回押さえるべきポイントは、Microsoft Sentinelの自動応答が「Playbookを個別に起動する運用」から、Automation rulesを中心に統制する運用へ寄っていることです。
Microsoft公式ドキュメントでは、Automation rulesはインシデントやアラートの処理自動化を一元管理する仕組みと説明されています。Automation rulesでは、インシデントのタグ付け、担当者割り当て、ステータス変更、タスク作成、Playbook呼び出し、複数Analytics rulesへの一括適用、実行順序の制御が可能です。(Microsoft Learn)
| 観点 | 従来ありがちな運用 | 今後見直すべき運用 |
|---|---|---|
| Playbookの起動 | Analytics ruleごとに個別設定 | Automation rulesから条件付きで実行 |
| 自動化の単位 | アラート単位に寄りがち | 原則はインシデント単位で設計 |
| 条件設定 | ルール名や件名に依存 | Analytics rule名、タグ、エンティティを組み合わせる |
| 実行順序 | Playbook内に処理を詰め込みがち | Automation rules側で順序を管理 |
| 移行管理 | 手動変更が中心 | ARMテンプレートやCI/CDで管理 |
重要なのは、Microsoft Defenderポータルへの統合により、インシデントの作成、相関、表示、API応答、Automation rulesの条件評価に差分が出る点です。Microsoft SentinelはDefenderポータルで利用でき、AzureポータルからDefenderポータルへの移行が推奨されています。公式ドキュメントでは、2027年3月31日以降、Microsoft SentinelはAzureポータルでサポートされず、Defenderポータルのみで利用されると案内されています。(Microsoft Learn)
影響を受ける対象者
この変更・整理の影響は、SOC担当者だけに限られません。以下の担当者は、既存設定の棚卸しが必要です。
| 対象者 | 確認すべきこと |
|---|---|
| セキュリティ管理者 | Sentinelワークスペース、Defenderポータル移行状況、データコネクタ、RBAC |
| SOCアナリスト | インシデントキュー、タグ、担当者割り当て、通知ルール、手動Playbook実行手順 |
| Azure管理者 | Log Analyticsワークスペース、Azure Logic Apps、診断ログ、コスト |
| 開発者・自動化担当 | Logic Appsワークフロー、API接続、外部チケット連携、KQL条件 |
| MSSP・マルチテナント運用者 | Azure Lighthouse、テナント間権限、Playbook配置場所 |
| ID管理者 | Microsoft Entra ID Protection、ユーザーリスク、アカウント無効化条件 |
特に注意が必要なのは、Logic Apps Playbookでユーザーの無効化、端末隔離、外部通知、チケット作成などを行っている環境です。自動応答は便利ですが、条件が粗いままだと、正当なユーザーをブロックしたり、不要なインシデントを大量にクローズしたりするリスクがあります。
Microsoft Defenderポータル統合で確認すべき主な変更点
Microsoft SentinelをDefenderポータルで利用する場合、自動化の考え方は同じでも、細かな挙動が変わります。公式ドキュメントでは、Defenderポータル移行後のAutomation rulesとPlaybooksについて、いくつかの制限や差分が示されています。(Microsoft Learn)
| 変更点 | 影響 | 確認ポイント |
|---|---|---|
| Alert triggerのAutomation rules | DefenderポータルではMicrosoft Sentinelアラートのみに作用 | Defender XDR由来アラートに期待どおり反応するか |
| Incident provider条件の扱い | すべてのインシデントでProviderNameがMicrosoft XDRになる | Incident provider条件に依存していないか |
| SecurityIncidentテーブルのDescription | Defenderポータル移行後はDescriptionフィールドが含まれない | ServiceNowなど外部チケット連携で説明文を使っていないか |
| インシデント名の変更 | Defenderの相関エンジンにより既存インシデント名が変わる可能性 | インシデントタイトルを条件にしていないか |
| Updated byの値 | サポートされる値が変わる | 「Microsoft 365 Defender」条件がOther扱いにならないか |
| Playbook起動遅延 | DefenderインシデントがSentinelへ反映されるまで遅延する場合がある | 数分単位の遅延を前提に運用設計する |
| 手動Playbook実行 | アラートやエンティティへの手動実行は一部未対応 | 手動封じ込め手順を別途用意する |
| 複数ワークスペース | Defender XDRデータはプライマリワークスペース中心 | Automation rulesを適切なワークスペースに移す |
実務では、移行後に「Playbookは成功しているのにチケットの説明が空になる」「特定条件のAutomation ruleが急に広く発火する」「インシデント名条件が一致しなくなる」といった問題が起こりやすくなります。条件にはインシデントタイトルではなく、Analytics rule名、タグ、エンティティ属性を使うほうが安全です。
自動応答はIncident triggerを基本に設計する
Microsoft Sentinelの自動化では、アラート単位ではなくインシデント単位を基本に考えるのが推奨されます。公式ドキュメントでは、インシデントはアラート、エンティティ、コメント、タグ、ブックマークなどを含む調査の「ケースファイル」と説明されており、多くの用途ではIncident triggerの自動化が適しています。(Microsoft Learn)
| トリガー | 向いている用途 | 注意点 |
|---|---|---|
| When incident is created | 新規インシデントの初期トリアージ、通知、担当者割り当て、チケット作成 | Defender相関により複数アラートが統合される可能性を考慮 |
| When incident is updated | 重大度変更、タグ追加、所有者変更、再オープン時の通知 | 短時間の複数変更がまとめられる場合がある |
| When alert is created | インシデントを作成しないScheduled/NRT Analytics ruleへの対応 | Defender XDRアラートへの適用可否に注意 |
判断基準はシンプルです。調査・対応プロセスに乗せたいものはIncident trigger、外部システム側でインシデント化を判断したいものや、インシデントを作らない検知だけはAlert triggerを検討します。
PlaybooksとAutomation rulesの使い分け
Automation rulesとPlaybooksは役割が違います。Automation rulesは「いつ、どの条件で、どの順序で処理するか」を決める制御レイヤーです。Playbooksは「実際に何をするか」を定義する実行レイヤーです。
| やりたいこと | 推奨 |
|---|---|
| インシデントにタグを付ける | Automation rules |
| 担当者を割り当てる | Automation rules |
| 誤検知を自動クローズする | Automation rules |
| Teamsに通知する | Playbook |
| ServiceNowやJiraにチケットを作る | Playbook |
| Microsoft Entraユーザーをブロックする | Playbook |
| Microsoft Defender for Endpointで端末を隔離する | Playbook |
| 複数の処理を順序制御する | Automation rules + Playbooks |
公式アーキテクチャでも、PlaybookはAzure Logic Appsで作成され、Microsoft Entra ID、Microsoft Sentinel、Microsoft 365 Outlookなどへの接続認証が必要になります。ユーザー更新権限やメール送信権限が不足していると、Playbookの作成や実行が失敗します。(Microsoft Learn)
既存環境で最初に棚卸しすべき設定
Microsoft Defender環境でMicrosoft Sentinel automated responsesを運用する前に、既存設定を次の順番で確認してください。
| 確認項目 | 見る場所 | 判断ポイント |
|---|---|---|
| Sentinelワークスペース | Microsoft Sentinel / Log Analytics | Defenderポータルへオンボード済みか |
| Data connectors | Data connectors | Microsoft Defender XDR、Microsoft Entra ID Protection、Defender for Cloudの重複がないか |
| Analytics rules | Configuration > Analytics | インシデント作成の有無、Alert automation classicの利用有無 |
| Automation rules | Automation | トリガー、条件、実行順序、有効期限 |
| Active playbooks | Automation > Active playbooks | 権限、サブスクリプションフィルター、接続状態 |
| Logic Apps | Azure Logic Apps | API接続、マネージドID、診断ログ、失敗履歴 |
| 外部連携 | ServiceNow、Teams、Slack、メールなど | 必須フィールド欠落時の挙動 |
| API連携 | Microsoft Graph / SecurityInsights API | providerNameやincidentUrlの差分 |
Microsoft Defenderポータルに移行しても、基本的なデータ収集アーキテクチャやLog Analyticsの取り込みパイプラインは維持されます。一方で、Defender関連のアラートはMicrosoft Defender XDR connectorからストリーミングされるため、コネクタ設定や重複取り込みの確認が重要です。(Microsoft Learn)
Alert automation classicを使っている場合は移行が必要
古い環境では、Analytics ruleの「Alert automation classic」からPlaybookを直接起動している場合があります。Microsoft公式ドキュメントでは、既存のAlert trigger PlaybooksはAutomation rulesから呼び出す形へ移行することが推奨されています。Analytics rulesから直接Playbookを呼び出す方式は非推奨になり、2023年6月以降は新規追加できず、2026年3月に非推奨となると説明されています。(Microsoft Learn)
移行時は、Playbook本体を書き換えるのではなく、呼び出し元をAnalytics ruleからAutomation ruleへ変更するのが基本です。
| 既存構成 | 移行方法 |
|---|---|
| 1つのAnalytics ruleだけで使うPlaybook | Analytics ruleのAutomated responseタブからAutomation ruleを作成 |
| 複数のAnalytics rulesで使うPlaybook | AutomationページからAutomation ruleを作成し、対象Analytics rulesを条件に指定 |
| 複数Playbooksを順番に実行 | Automation ruleのActionsで順序を設定 |
| 一時的な例外対応 | Automation ruleに有効期限を設定 |
移行後は、Alert automation classic側からPlaybookを削除し、二重実行を防ぎます。移行作業は本番で直接行うのではなく、非本番ワークスペースや限定されたAnalytics ruleで動作確認してから展開するのが安全です。
AccountName条件を使う自動化は2026年7月1日までに確認
Microsoft Sentinelでは、Analytics ruleアラートでAccount NameにフルUPNがマッピングされた場合の扱いが変更されます。公式のWhat’s newでは、Account Nameは常にUPNプレフィックス、つまり[email protected]のuser部分になると説明されています。追加で、UserPrincipalName、UPNSuffix、UPNプレフィックス関連のフィールドがSecurityAlertテーブルに追加されます。(Microsoft Learn)
影響を受けやすいのは、Logic AppsやAutomation rulesで次のような条件を書いている環境です。
AccountName Equals [email protected]この条件は、変更後に一致しなくなる可能性があります。代わりに、次のように分解して判定します。
AccountName Starts with user
UPNSuffix Equals contoso.comまたは、KQLやLogic Apps側でUserPrincipalNameを使える場合は、フルUPNを直接参照する設計に見直します。公式ドキュメントでは、互換性を保つために厳密な等価比較ではなく、ContainsやStarts withの利用が推奨されています。(Microsoft Learn)
管理者が確認すべき権限とロール
Playbookが動かない原因の多くは、ロジックの不備ではなく権限不足です。Microsoft SentinelでPlaybookを作成・実行するには、Microsoft Sentinel関連ロールとAzure Logic Apps関連ロールの両方を確認する必要があります。
| 用途 | 必要な代表的ロール |
|---|---|
| Playbookへのアクセス権付与 | Owner |
| Analytics ruleやAutomation ruleにPlaybookを接続 | Microsoft Sentinel Contributor |
| インシデントから手動Playbookを実行 | Microsoft Sentinel Playbook Operator |
| Automation ruleからPlaybookを実行 | Microsoft Sentinel Automation Contributor |
| Consumption Logic Appsの編集 | Logic App Contributor |
| Standard Logic Appsの編集 | Logic Apps Standard Developer / Contributor |
Microsoft SentinelがAutomation ruleからPlaybookを実行する際は、専用のサービスアカウントが使われます。このサービスアカウントには、Playbookが存在するリソースグループに対してMicrosoft Sentinel Automation Contributorロールを明示的に付与する必要があります。(Microsoft Learn)
MSSPやマルチテナント環境では、権限を付与するテナントを間違えやすい点にも注意してください。Automation ruleがあるテナントではなく、Playbookが配置されているテナントやリソースグループ側で権限を確認する必要があります。
導入・移行時の実務手順
Microsoft Sentinel automated responsesをMicrosoft Defender環境で安全に展開するなら、以下の順序で進めると失敗を減らせます。
既存自動化を一覧化する
まず、Automation rules、Analytics rules、Playbooks、Logic Apps、外部連携先を一覧化します。特に「ユーザー無効化」「端末隔離」「チケット作成」「インシデント自動クローズ」は影響が大きいため、処理内容と発火条件を必ず確認します。
トリガーをIncident中心に見直す
アラート単位の反応が本当に必要かを確認します。多くの運用では、インシデント作成時にタグ付け、通知、担当者割り当て、チケット作成を行い、深刻度やエンティティに応じてPlaybookを分岐させるほうが管理しやすくなります。
条件にタイトルや説明文を使わない
Defenderポータル移行後は、相関エンジンによってインシデント名が変わる場合があります。また、SecurityIncidentテーブルのDescriptionフィールドに依存したAutomation ruleは移行後に動作しない可能性があります。条件にはAnalytics rule名、タグ、エンティティ、重大度、戦術、カスタムプロパティなどを使う設計に寄せましょう。(Microsoft Learn)
Playbookの接続と診断ログを確認する
Logic AppsのAPI接続は、作成時点では動いていても、権限変更、認証期限、アカウント削除、条件付きアクセスの変更で失敗することがあります。Playbookテンプレートを使う場合も、接続先、リージョン、リソースグループ、診断ログの有効化を確認してください。
小さくテストして段階展開する
いきなり本番の全Analytics rulesに適用せず、低リスクの通知系Playbookから試します。次にチケット作成、最後にユーザーブロックや端末隔離のような強い封じ込めを展開します。
自動封じ込めの判断基準
PlaybookでMicrosoft EntraユーザーのブロックやMicrosoft Defender for Endpointの端末隔離を実行する場合、完全自動化してよいケースと承認を挟むべきケースを分けることが重要です。
| 対応内容 | 自動化レベル | 判断基準 |
|---|---|---|
| Teams通知 | 完全自動化しやすい | 誤通知の影響が小さい |
| インシデントタグ付け | 完全自動化しやすい | 条件が明確で後から修正できる |
| チケット作成 | 条件付きで自動化 | 重複チケットや説明不足に注意 |
| ユーザーリスク確認 | 完全自動化しやすい | 読み取り中心の処理 |
| ユーザーブロック | 承認付きが安全 | VIP、管理者、サービスアカウントを除外 |
| 端末隔離 | 承認付きまたは高確度時のみ | 業務停止の影響を評価 |
| インシデント自動クローズ | 期限付き条件で実施 | 誤検知ルールに限定し、コメントを残す |
実務では、まず「通知・情報付与・チケット作成」から自動化し、封じ込め処理は段階的に導入するのが安全です。たとえば、初期段階ではTeamsのAdaptive CardでSOC担当者に承認を求め、承認後にユーザーをブロックする構成にします。
Microsoft Entra ID Protection連携での注意点
公式アーキテクチャの例では、Microsoft Entra ID Protectionが匿名IPアドレスからのサインインなどを検出し、Microsoft Sentinelにアラートを送信します。その後、Microsoft Sentinelでインシデントを作成し、Playbookがユーザーをブロックする流れです。(Microsoft Learn)
検証時は、次の点に注意してください。
| 注意点 | 理由 |
|---|---|
| 本番ユーザーでテストしない | 誤って業務アカウントをブロックする恐れがある |
| 専用のテストユーザーを使う | 後で削除・無効化しやすい |
| Torブラウザー検証は隔離環境で行う | セキュリティ上のリスクを本番端末に持ち込まない |
| 監査ログをLog Analyticsへ送る | ブロック前後の挙動を追跡しやすい |
| 除外条件を用意する | 緊急用管理者、Break glassアカウント、サービスアカウントを保護する |
自動化の目的は、攻撃対応を速くすることです。ただし、ID系の自動封じ込めは業務影響が大きいため、「高リスクユーザー」「特定の検知元」「対象グループ」「管理者除外」など複数条件を組み合わせてください。
外部チケット連携・API連携の確認ポイント
ServiceNow、Jira、Teams、Slack、メール、独自SOAR基盤などと連携している場合は、Defenderポータル移行後のフィールド差分を確認します。公式ドキュメントでは、統合インシデントやアラートを扱う場合、Microsoft Graph REST APIの利用が推奨され、Microsoft Sentinel SecurityInsights APIでインシデントを扱っている場合は、レスポンス本文の変更により条件やトリガーの見直しが必要になる可能性があります。(Microsoft Learn)
特に以下は影響が出やすい項目です。
| 項目 | 確認内容 |
|---|---|
| incidentUrl | Defenderポータル用URLを使うか、Sentinelポータル用URLを使うか |
| providerName | Azure Sentinel前提の条件がMicrosoft XDRに変わっていないか |
| productName | Defender for Endpoint、Defender for Cloud Appsなど製品名の扱い |
| serviceSource | 検知元サービスによる分岐処理 |
| description | チケット本文生成に使っていないか |
| alertProductNames | 取得時にalerts展開が必要か |
外部連携では、フィールドが空でもチケットを作るのか、処理を失敗させるのか、代替文を入れるのかを決めておくと運用が安定します。
失敗しやすいポイントと回避策
| 失敗パターン | 起きる問題 | 回避策 |
|---|---|---|
| インシデント名を条件に使う | 相関後に名前が変わりAutomation ruleが動かない | Analytics rule名やタグを使う |
| Descriptionに依存する | Defender移行後に外部チケット本文が空になる | 必要情報を別フィールドから組み立てる |
| Playbook権限を人のアカウント頼みにする | 退職・権限変更で自動化が止まる | マネージドIDやサービスアカウントを整理 |
| AccountNameをフルUPNで比較する | 2026年7月以降に条件不一致が起きる | UPN prefixとUPNSuffixで判定 |
| 封じ込めをいきなり完全自動化する | 正常ユーザーや端末を止める | 承認ステップと除外条件を入れる |
| 診断ログを取らない | 失敗原因を追えない | Logic Apps診断ログと実行履歴を保存 |
| Alert automation classicを残す | 二重実行や将来の非互換リスク | Automation rulesへ移行する |
| マルチテナント権限を誤る | Playbookが実行できない | Playbook配置テナント側の権限を確認 |
自動応答は「速さ」だけでなく「再現性」と「説明責任」が重要です。誰が見ても、どの条件で、どの処理が、どの順序で実行されたかを追跡できる状態にしておきましょう。
管理者向けチェックリスト
公開前、移行前、本番展開前に以下を確認してください。
| チェック | 内容 |
|---|---|
| □ | Microsoft SentinelワークスペースがDefenderポータルにオンボードされているか |
| □ | Microsoft Defender XDR connectorが有効で、重複取り込みがないか |
| □ | Microsoft Entra ID ProtectionアラートをSentinelで収集できているか |
| □ | Analytics rulesのインシデント作成設定を確認したか |
| □ | Alert automation classicにPlaybookが残っていないか |
| □ | Automation rulesのトリガー、条件、実行順序、有効期限を確認したか |
| □ | インシデント名、Description、Incident provider条件に依存していないか |
| □ | AccountNameのフルUPN比較を使っていないか |
| □ | Logic AppsのAPI接続、認証、ロール、診断ログを確認したか |
| □ | Teams、メール、ServiceNowなど外部連携の必須項目を確認したか |
| □ | ユーザーブロックや端末隔離に承認・除外条件を入れたか |
| □ | 非本番または限定ルールでテストしたか |
| □ | SOCアナリスト向けに新しい手順を共有したか |
まず取るべきアクション
Microsoft Defender環境でMicrosoft Sentinel automated responsesを活用するなら、最初にやるべきことは新しいPlaybookを作ることではありません。既存のAutomation rules、Analytics rules、Playbooks、Logic Apps、外部連携を棚卸しし、Defenderポータル統合後も安全に動く条件へ見直すことです。
特に優先度が高いのは、Alert automation classicの移行、AccountName条件の見直し、Incident providerやDescription依存の排除、Playbook実行権限の確認です。これらを整理したうえで、通知、チケット作成、エンリッチメント、封じ込めの順に自動化を広げると、誤作動を抑えながらSOCの対応速度を上げられます。
Microsoft Sentinelの自動応答は、単なる省力化ではなく、企業の初動対応を標準化する仕組みです。Automation rulesで統制し、Playbooksで実行し、Microsoft Defenderポータルで統合的に運用する。この前提で設計を見直すことが、今後のSentinel運用で最も重要な確認ポイントです。
コメント