Automation in Microsoft Sentinel更新ポイント解説｜Defenderポータル移行で確認すべき設定と影響

Automation in Microsoft Sentinel は、Microsoft Sentinel のアラートやインシデント対応を自動化する SOAR 機能です。2026年6月28日に更新された公式情報でまず押さえるべき結論は、単に「自動化ルールとプレイブックを使う」ことではありません。Azure ポータル中心で運用している既存環境では、Microsoft Defender ポータルへの移行に伴い、トリガー条件、インシデントの扱い、フィールド、プレイブック実行タイミングが変わるため、2027年3月31日までに自動化設計を棚卸しする必要があります。(Microsoft Learn)

特に注意したいのは、Incident provider 条件、SecurityIncident テーブルの Description フィールド、インシデント名を条件にしたルール、複数ワークスペース構成、ServiceNow など外部チケット連携です。これらを放置すると、想定外のインシデントに自動化が走る、逆に必要なプレイブックが動かない、チケット情報が欠落するといった運用事故につながります。(Microsoft Learn)

Azure の新機能・変更点：「Automation in Microsoft Sentinel」で確認すべきポイント

Automation in Microsoft Sentinel の更新ポイントは、「自動化機能の追加」というより、Microsoft Sentinel を Microsoft Defender ポータルで運用する前提に合わせて、SOAR の実装方法を見直すべき段階に入ったことです。Microsoft Learn の公式ページでは、Microsoft Sentinel は SIEM であると同時に、Security Orchestration, Automation, and Response、つまり SOAR の基盤として、SOC や SecOps が行う繰り返し作業を自動化する位置づけと説明されています。(Microsoft Learn)

確認項目	更新・変更の要点	管理者が取るべき対応
ポータル移行	2027年3月31日以降、Microsoft Sentinel は Azure ポータルでサポートされず、Microsoft Defender ポータルのみで利用する形になります。	Azure ポータル前提の運用手順、教育資料、権限、監視フローを Defender ポータル前提に更新します。
自動化ルール	インシデント作成・更新、アラート作成を起点に、条件とアクションを組み合わせて実行します。	既存ルールをトリガー別に分類し、条件が移行後も成立するか確認します。
プレイブック	Azure Logic Apps ベースのワークフローとして、通知、調査補助、外部連携、封じ込めを実行します。	Logic Apps の権限、課金、接続先 API、実行アカウントを点検します。
Defender ポータル差分	Incident provider、Description、Updated by、インシデント名、手動実行などに差分があります。	条件に使っているフィールドとチケット連携項目を優先的に見直します。
グローバル・複数ワークスペース	Microsoft Defender XDR 連携データはプライマリワークスペース中心の扱いになります。	地域、テナント、MSSP、データ保持、データ所在地の設計を再確認します。

Automation in Microsoft Sentinelとは

Automation in Microsoft Sentinel は、Microsoft Sentinel の検知結果に対して、人手で繰り返している判断や作業を自動化する仕組みです。主な構成要素は、自動化ルールとプレイブックです。自動化ルールは「どの条件で、何をするか」を管理し、プレイブックは Azure Logic Apps を使って、外部システム連携や複雑な処理を実行します。(Microsoft Learn)

たとえば、フィッシングの疑いがあるアラートを検知したときに、該当ユーザーのサインイン履歴を確認し、危険度が高ければ Microsoft Teams に通知し、ServiceNow にチケットを作成し、必要に応じてアカウントを一時的に無効化する、といった対応を自動化できます。公式ドキュメントでも、侵害されたアカウントや端末に対して、SOC チームに通知する前に端末の隔離やアカウントのブロックを自動化する例が示されています。(Microsoft Learn)

自動化ルールでできること

自動化ルールは、Microsoft Sentinel のインシデント対応を一元管理するための仕組みです。プレイブックを使わずに、インシデントの所有者割り当て、タグ付け、ステータス変更、クローズ、タスク追加などを実行できます。また、複数の分析ルールにまたがって同じ対応を適用したり、アクションの実行順序を制御したりできます。(Microsoft Learn)

自動化ルールは、主に次の3つで構成されます。

構成要素	役割	実務での例
トリガー	いつ実行するかを決める	インシデント作成時、インシデント更新時、アラート作成時
条件	どの対象に実行するかを絞る	重大度が High、特定の分析ルール名を含む、特定タグが付いている
アクション	何を実行するかを決める	所有者割り当て、タグ追加、ステータス変更、プレイブック実行

実務では、「重大度 High の ID 関連インシデントは IAM チームに割り当てる」「計画済みの侵入テスト期間中だけ特定タグ付きのノイズを自動クローズする」「ランサムウェア疑いのインシデントには初動確認タスクを自動追加する」といった使い方が現実的です。公式情報では、自動化ルールに有効期限を設定できるため、ペネトレーションテストのような期間限定のノイズ対応にも使えるとされています。(Microsoft Learn)

プレイブックでできること

プレイブックは、Microsoft Sentinel から実行できる自動応答ワークフローです。Azure Logic Apps を基盤にしており、社内外のシステムと連携しながら、通知、調査情報の付与、チケット作成、封じ込め、復旧作業の一部を自動化できます。(Microsoft Learn)

代表的な活用シーンは、次の4つです。

用途	内容	具体例
エンリッチメント	判断材料をインシデントに追加する	IP アドレスの評判情報、URL 分析結果、ユーザー属性をコメントとして追加
双方向同期	外部チケットシステムと同期する	Sentinel の新規インシデントを ServiceNow チケットとして作成
オーケストレーション	SOC の作業フローをつなぐ	Teams や Slack に通知し、担当者の初動を促す
レスポンス	封じ込めや一次対応を実行する	端末隔離、アカウント無効化、危険なメールの処理

注意点として、プレイブックは Azure Logic Apps を使用するため、Logic Apps の実行やコネクタ利用に応じて追加コストが発生する可能性があります。自動化を増やすほどコストと権限管理の重要度も上がるため、全アラートに安易にプレイブックを紐づけるのではなく、重大度、頻度、誤検知率、手作業の負荷を基準に優先順位を付けるべきです。(Microsoft Learn)

Defender ポータル移行で変わる自動化の挙動

Microsoft Sentinel を Defender ポータルで使う場合、従来の Azure ポータル運用と同じ感覚で自動化ルールを扱うと、想定外の動作になる可能性があります。公式ドキュメントでは、既存顧客が Defender ポータルへ移行すると、自動化の動作に差分が出る場合があると説明されています。(Microsoft Learn)

アラートトリガーは Microsoft Sentinel アラート中心に動く

Defender ポータルでは、アラートトリガーを使う自動化ルールは Microsoft Sentinel のアラートに対して動作します。Microsoft Defender XDR のアラートも含めて自動応答したい場合は、Enhanced Alert Trigger の利用を検討する必要があります。(Microsoft Learn)

これは、運用設計上かなり重要です。たとえば「すべての高重大度アラートを Teams に通知する」というつもりで標準のアラートトリガーを設定しても、Defender XDR 側のアラートまで期待通りに含まれない可能性があります。Microsoft Sentinel、Microsoft Defender for Endpoint、Microsoft Defender for Office 365 などを横断して扱う設計では、対象アラートの発生元を明確に分けてテストしてください。

Incident provider 条件はスコープ制御に使いにくくなる

Defender ポータル移行後は、すべてのインシデントで Incident provider が Microsoft XDR として扱われます。そのため、Incident provider 条件を Microsoft Sentinel や Microsoft 365 Defender に限定していた既存の自動化ルールは、移行後に Microsoft Sentinel と Microsoft Defender XDR の両方のインシデントで実行される可能性があります。(Microsoft Learn)

スコープを絞りたい場合は、Incident provider ではなく、分析ルール名、タグ、重大度、エンティティ属性などを組み合わせる方が安全です。公式情報でも、Microsoft Sentinel のみに存在する分析ルール名を条件に使うことで、Microsoft Sentinel 側のインシデントに限定する考え方が示されています。(Microsoft Learn)

SecurityIncident.Description に依存するルールは見直しが必要

Defender ポータルへオンボードした後、SecurityIncident テーブルには Description フィールドが含まれなくなります。このフィールドをインシデント作成トリガーの条件に使っている自動化ルールは、移行後に動作しません。また、ServiceNow のような外部チケットシステムと連携している場合、インシデント説明が欠落する可能性があります。(Microsoft Learn)

実務では、Description に頼って「件名にマルウェアを含む」「説明文に特定ホスト名を含む」といった分岐を作っているケースがあります。このようなルールは、分析ルール名、アラートタイトル、重大度、タグ、エンティティ情報、カスタムコメントなど、移行後も利用できる項目に置き換える設計を検討してください。

インシデント名を条件にした自動化は避ける

Defender ポータルでは、独自の相関エンジンがインシデントとアラートを関連付けます。オンボード時に相関が適用されると、既存インシデント名が変わる場合があります。公式ドキュメントでは、自動化ルールの条件にインシデントタイトルを使うことを避け、代わりに分析ルール名やタグを使うことが推奨されています。(Microsoft Learn)

たとえば、条件を「インシデントタイトルに Suspicious sign-in を含む」とするより、「該当の分析ルール名に一致する」「タグに identity-risk がある」とした方が、相関や名称変更の影響を受けにくくなります。

更新トリガーは遅延とバッチ処理を考慮する

Defender ポータルで作成または更新されたインシデントが Microsoft Sentinel に渡され、自動化ルールが実行されるまでには、最大10分程度の遅延が発生する可能性があります。また、同じインシデントに対して5〜10分の間に複数の変更が行われた場合、Microsoft Sentinel には最新の変更だけが送られ、中間の更新は失われる可能性があります。(Microsoft Learn)

そのため、「ステータスが New から Active に変わったら通知し、その後 High に変わったら別の処理をする」といった、逐次的な状態変化に強く依存する自動化は要注意です。状態遷移のすべてを追うのではなく、最終的な重大度、タグ、所有者、アラート構成を見て判断する設計に寄せると、移行後の安定性が上がります。

影響範囲：どの環境が優先的に確認すべきか

影響が大きいのは、Microsoft Sentinel を Azure ポータルで長く運用しており、既存の自動化ルールや Logic Apps プレイブックが多い環境です。特に、SOC 運用を外部チケットシステム、複数ワークスペース、複数テナント、MSSP 管理に接続している場合は、単純な画面移行では済みません。(Microsoft Learn)

影響を受けやすい環境	起きやすい問題	優先対応
Azure ポータルで自動化ルールを大量に作成している	条件フィールドや実行順序の前提が変わる	ルールをトリガー別・条件別に棚卸しする
ServiceNow などと連携している	Description 欠落によりチケット情報が不足する	チケット作成時のマッピング項目を見直す
インシデント名で分岐している	相関エンジンにより名称が変わり、条件に一致しない	分析ルール名、タグ、重大度に置き換える
複数ワークスペースで XDR データを扱っている	Defender XDR データがプライマリワークスペース中心になる	ルールとプレイブックを適切なワークスペースへ移す
MSSP・マルチテナント運用	プレイブック実行権限の付与先を誤る	プレイブックが存在するテナント側で権限を確認する
状態変化を細かく追う自動化	更新のバッチ処理で中間状態が失われる	最終状態ベースの条件設計に変更する

管理者が確認すべき設定変更

自動化ルールのトリガーを分類する

最初にやるべきことは、自動化ルールを「インシデント作成」「インシデント更新」「アラート作成」の3種類に分けることです。公式ドキュメントでは、多くのユースケースではアラート単体よりも、証拠やコメント、タグ、エンティティを含むインシデントを中心に自動化を組む方が適していると説明されています。(Microsoft Learn)

判断基準は次の通りです。

判断したいこと	推奨される設計
SOC の標準初動を自動化したい	インシデント作成トリガー
担当者変更や重大度変更に反応したい	インシデント更新トリガー
インシデント化しないアラートにも対応したい	アラート作成トリガー
Defender XDR を含めて広くアラート対応したい	Enhanced Alert Trigger の検討
外部チケットシステムへ送信したい	インシデント中心。ただし Description 依存は避ける

アラート作成トリガーは便利ですが、Defender ポータルでは対象範囲に注意が必要です。標準のアラートトリガーは Microsoft Sentinel のスケジュール分析ルールや NRT 分析ルールなどで作成されたアラートが中心であり、Defender XDR まで横断したい場合は Enhanced Alert Trigger が選択肢になります。(Microsoft Learn)

実行順序を明示的に管理する

自動化ルールは順番に実行され、後続のルールは前のルールが変更した後の状態を見て条件評価します。たとえば、最初のルールが重大度を Medium から Low に変えると、次のルールが Medium 以上だけを対象にしている場合、そのインシデントには実行されません。(Microsoft Learn)

よくある失敗は、「タグ追加」「重大度変更」「担当者割り当て」「プレイブック実行」を複数ルールに分けたまま、順序番号を整理していないケースです。同じ順序番号のルールが複数あると、実行順序を厳密に期待できません。移行前に、同じトリガー種別のルールを一覧化し、上から実行されるべき順に並べ直してください。(Microsoft Learn)

プレイブック実行権限を確認する

自動化ルールがプレイブックを実行する場合、Microsoft Sentinel は専用のサービスアカウントを使います。このアカウントには、プレイブックが存在するリソースグループに対して Microsoft Sentinel Automation Contributor ロールが必要です。権限が不足しているプレイブックは、選択画面で利用できない状態として表示されます。(Microsoft Learn)

最低限、次の権限を確認してください。

操作	必要な代表的ロール
プレイブックを分析ルールや自動化ルールに接続する	Microsoft Sentinel Contributor
インシデントから手動でプレイブックを実行する	Microsoft Sentinel Playbook Operator
自動化ルールからプレイブックを実行する	Microsoft Sentinel Automation Contributor
Logic Apps を編集・管理する	Logic App Contributor または Standard Logic Apps 関連ロール
プレイブック実行権限を付与する	Owner または User Access Administrator

権限設計では、「人が実行できるか」と「自動化ルールが実行できるか」を分けて考える必要があります。ユーザーが Logic Apps を編集できても、Microsoft Sentinel のサービスアカウントに実行権限がなければ、自動実行は失敗します。(Microsoft Learn)

移行期限：2027年3月31日までにやるべきこと

Microsoft の公式情報では、2027年3月31日以降、Microsoft Sentinel は Azure ポータルでサポートされず、Microsoft Defender ポータルのみで利用可能になるとされています。Azure ポータルで Microsoft Sentinel を使っている顧客は Defender ポータルへリダイレクトされ、以後は Defender ポータル上の Microsoft Sentinel を使う形になります。(Microsoft Learn)

移行計画では、画面の操作手順だけでなく、自動化と運用フローを優先して確認してください。特に、夜間や休日に自動実行されるプレイブック、外部チケット作成、重大度変更、自動クローズ、隔離・無効化などの封じ込め処理は、影響が大きいため先に検証すべきです。

推奨される移行ステップ

ステップ	作業内容	確認ポイント
棚卸し	自動化ルール、プレイブック、Logic Apps、外部接続を一覧化する	所有者、用途、実行頻度、失敗時の影響
条件確認	Incident provider、Description、タイトル、Updated by 依存を探す	移行後に同じ条件で動くか
権限確認	Sentinel、Logic Apps、リソースグループの RBAC を確認する	自動実行用サービスアカウントの権限
テスト	Defender ポータル上で代表的なインシデントを使って検証する	実行遅延、チケット内容、通知内容
修正	条件、タグ、分析ルール名、チケット項目を更新する	過剰実行と実行漏れの両方を防ぐ
教育	SOC 手順書とエスカレーションルールを更新する	画面、用語、担当範囲の変更
本番移行	重要ルールから段階的に切り替える	失敗時のロールバック手順

グローバル運用で追加確認すべきポイント

グローバル企業や MSSP では、Automation in Microsoft Sentinel の見直しを、単一ワークスペースの自動化設定だけで終わらせないことが重要です。Defender ポータルでは、Microsoft Sentinel と Microsoft Defender XDR の統合により、インシデントキュー、データコネクタ、相関、権限、データポリシーの前提が変わります。(Microsoft Learn)

データ所在地・プライバシー・CMKを確認する

Azure ポータル利用時は Microsoft Sentinel のデータ保存、処理、保持、共有ポリシーが適用されますが、Defender ポータル利用時は Microsoft Defender XDR のポリシーが適用されます。また、CMK を有効にしている場合、Log Analytics ワークスペース内のログデータは引き続き CMK で暗号化されますが、オンボード後のアラートとインシデントは CMK 暗号化の対象外になると説明されています。(Microsoft Learn)

規制要件がある業界では、移行前にリージョン、データ保持、監査証跡、チケット転送先、外部 API 連携先を再確認してください。特に、EU、米国、日本、APAC などでログ保管方針が異なる組織では、ポータル統合が「データの見え方」だけでなく「データポリシーの説明責任」にも影響します。

複数ワークスペースではプライマリの扱いに注意する

Microsoft Sentinel と Microsoft Defender が統合されると、Microsoft security product のアラートは単独の製品別コネクタではなく Microsoft Defender XDR コネクタ経由に変わります。複数ワークスペース環境では、Microsoft Defender XDR コネクタはプライマリワークスペースのみに接続され、Microsoft Defender for Endpoint、Defender for Office 365、Defender for Identity などの単独コネクタは、重複防止のためセカンダリワークスペースで自動的に切断される場合があります。(Microsoft Learn)

この変更は、自動化ルールの配置に直結します。セカンダリワークスペースにある自動化ルールが、Defender XDR のアラートを前提にしている場合、期待通りに動かない可能性があります。対象データがどのワークスペースに入るのかを確認し、必要に応じてルールやプレイブックをプライマリワークスペース側へ移してください。

API 連携は Microsoft Graph 前提に見直す

Defender ポータルの統合体験では、アラートやインシデントに関する自動化で Microsoft Graph REST API v1.0 の利用が推奨されています。一方、Microsoft Sentinel API は、分析ルールや自動化ルールなど Microsoft Sentinel リソースへの操作を引き続きサポートします。既存の SecurityInsights API でインシデントを扱っている場合は、レスポンスボディの変更により、自動化条件やトリガー条件の更新が必要になる可能性があります。(Microsoft Learn)

ServiceNow、Jira、Teams、Slack、SOAR 製品、独自ポータルと連携している環境では、API の URL、認証、参照フィールド、インシデント URL、プロバイダー名、アラート製品名を確認してください。特に、Defender ポータルでは providerName が Microsoft XDR になる点は、条件分岐やレポート集計に影響しやすいポイントです。(Microsoft Learn)

失敗しやすいポイントと回避策

Automation in Microsoft Sentinel の運用で失敗しやすいのは、「Azure ポータル時代に動いていたから大丈夫」と考えてしまうことです。Defender ポータル移行後は、同じ名前の機能でも、対象範囲や実行タイミングが変わる場合があります。

失敗パターン	何が起きるか	回避策
Incident provider で Microsoft Sentinel だけに絞る	移行後に Microsoft XDR 扱いとなり、想定より広く実行される可能性がある	分析ルール名やタグで絞る
Description を条件にする	移行後にルールが動かない	条件を別フィールドへ置き換える
インシデントタイトルで分岐する	相関によりタイトルが変わり、条件不一致になる	タグ、分析ルール名、重大度を使う
更新イベントの順序に依存する	バッチ処理で中間更新が失われる	最終状態ベースの条件にする
手動プレイブック実行を前提にする	Defender ポータルでは一部の手動実行が未対応	インシデント起点の実行に寄せる
複数ワークスペースを旧設計のまま使う	XDR データが期待したワークスペースに入らない	プライマリワークスペースとルール配置を見直す
権限をユーザーだけに付与する	自動化ルールからプレイブックを実行できない	Sentinel サービスアカウントの権限を付与する

Defender ポータルでは、アラートやインシデントの相関により、複数の検知ソースの情報が1つのインシデントにまとめられることがあります。これは攻撃全体を把握しやすくするメリットがありますが、自動化ルールが想定していないデータ構造を受け取る可能性もあります。自動封じ込めやアカウント停止のような強いアクションは、移行後に必ずテストデータで検証してください。(Microsoft Learn)

実務で使いやすい自動化設計の例

例：重大度 High のインシデントを確実に初動対応へ回す

重大度 High のインシデントが作成されたら、タグ priority-high を付与し、担当チームへ割り当て、Teams に通知し、初動確認タスクを追加します。自動化ルールでは、インシデント作成トリガー、重大度 High、対象分析ルール名またはタグを条件にします。プレイブックでは、Teams 通知とチケット作成を担当させます。

この設計では、Incident provider や Description に依存しないため、Defender ポータル移行後の影響を抑えやすくなります。また、タグを付けておけば、後続の自動化ルールやレポートでも同じ基準を利用できます。

例：期間限定のノイズを自動クローズする

侵入テストや脆弱性診断など、あらかじめ予定されたイベントで大量の低リスクアラートが出る場合は、自動化ルールに有効期限を設定し、対象タグや分析ルール名に一致するインシデントを自動クローズします。自動化ルールには有効期限を設定できるため、期間終了後にルールを無効化し忘れるリスクを減らせます。(Microsoft Learn)

ただし、本番環境では「特定IPからの診断」「特定タグ付き」「重大度 Low または Informational」など複数条件を組み合わせてください。単にタイトルや説明文だけで閉じると、本物の攻撃を見逃す危険があります。

例：ServiceNow 連携を移行後も安定させる

ServiceNow へチケットを作成するプレイブックでは、Description の欠落を前提に、チケット本文を別の情報から組み立てる設計に変更します。具体的には、インシデントタイトル、重大度、分析ルール名、関連エンティティ、タグ、アラート URL、ポータル上のインシデント URL、コメントなどを組み合わせます。Description 依存のままにすると、Defender ポータル移行後にチケット内容が不十分になる可能性があります。(Microsoft Learn)

まず実施すべきチェックリスト

最後に、管理者がすぐ確認すべき項目を整理します。すべてを一度に変更するのではなく、影響が大きい自動化から順に確認するのが現実的です。

優先度	確認項目	完了条件
高	Azure ポータルで使っている Sentinel 自動化ルールを一覧化したか	ルール名、トリガー、条件、アクション、所有者が分かる
高	Incident provider 条件を使っていないか	使っている場合、分析ルール名やタグに置き換える方針がある
高	Description を条件やチケット本文に使っていないか	移行後も利用できる代替項目に変更済み
高	インシデントタイトル依存の条件がないか	タグ、分析ルール名、重大度へ変更済み
高	自動封じ込め系プレイブックをテストしたか	誤実行防止条件と手動承認の要否を確認済み
中	複数ワークスペースのプライマリを確認したか	XDR データと自動化ルールの配置が一致している
中	Logic Apps の権限を確認したか	Sentinel サービスアカウントが実行権限を持つ
中	SOC 手順書を Defender ポータル前提に更新したか	担当者が新しい画面で初動対応できる
中	API 連携の参照フィールドを確認したか	Microsoft Graph と Sentinel API の使い分けが明確
低	期間限定ルールに有効期限を設定したか	テストや診断後に自動で無効化される

Automation in Microsoft Sentinel は、SOC の負荷を下げる強力な機能ですが、移行期には「動けばよい」ではなく「どの条件で、どの範囲に、どの権限で動くか」を明確にすることが重要です。まずは既存の自動化ルールとプレイブックを棚卸しし、Incident provider、Description、インシデントタイトル、複数ワークスペース、プレイブック権限の5点から優先的に見直してください。2027年3月31日の Azure ポータル非サポート期限を待つのではなく、代表的なインシデントで Defender ポータル上の実行結果を早めに検証することが、移行後の運用トラブルを避ける最短ルートです。(Microsoft Learn)