Azure Logic Apps for Microsoft Sentinel playbooksは、Microsoft Sentinelのインシデント対応をAzure Logic Appsのワークフローで自動化する仕組みです。2026年5月14日に更新された公式情報では、Microsoft DefenderポータルでのSentinel運用を前提に、対応するLogic Appsの種類、トリガー、認証、Standardワークフロー利用時の制約が整理されています。管理者がまず確認すべき結論は、既存プレイブックのトリガー方式、認証方式、Logic Appsの種類、Defenderポータル移行後の制約です。
特に注意すべきなのは、Microsoft SentinelがMicrosoft Defenderポータルで一般提供されており、2027年3月31日以降はAzureポータルでのSentinelがサポートされなくなる点です。Azureポータル前提で作成した自動化ルールやプレイブックは、そのまま動くものもありますが、実行タイミング、手動実行の可否、インシデント条件、API連携に差分が出る可能性があります。(Microsoft Learn)
Azure Logic Apps for Microsoft Sentinel playbooksとは
Azure Logic Apps for Microsoft Sentinel playbooksは、Microsoft Sentinelのアラート、エンティティ、インシデントをきっかけに、調査・通知・隔離・チケット起票などの処理を自動化するための仕組みです。
Microsoft SentinelのプレイブックはAzure Logic Apps上のワークフローとして作成されます。Logic Appsは複数のシステムやサービスをつなぎ、処理をスケジュール・自動化・オーケストレーションするクラウドサービスです。Microsoft Sentinelと連携する場合は、Logic AppsのMicrosoft Sentinelコネクタを使います。(Microsoft Learn)
実務では、次のような用途で使われます。
- 重大度の高いインシデントをTeamsやメールに通知する
- 不審なIPアドレスやユーザー情報を外部サービスで照合する
- ServiceNowなどのチケット管理システムにインシデントを登録する
- 条件に応じてインシデントにタグやコメントを追加する
- アナリストが実行すべきタスクを自動で追加する
- 一定条件を満たすアラートを自動クローズまたはエスカレーションする
重要なのは、プレイブックを「便利な自動処理」として作るだけでなく、SOCの運用フローに合わせて、どのタイミングで、どの権限で、どの対象に実行するかを設計することです。
2026年5月14日更新情報で押さえるべき変更点
今回の公式情報で実務上押さえるべきポイントは、プレイブックの基本概念そのものが大きく変わったというより、Microsoft DefenderポータルでのSentinel運用を前提に確認すべき制約が明確になった点です。
| 確認項目 | 内容 | 管理者・開発者への影響 |
|---|---|---|
| 対象ポータル | Microsoft Sentinel in the Microsoft Defender portalとAzure portalの両方に適用 | 今後の運用はDefenderポータル前提で確認する必要がある |
| Logic Appsの種類 | ConsumptionとStandardの両方をサポート | Standard利用時はテンプレート、プライベートエンドポイント、ステートレスワークフローに注意 |
| トリガー | Alert、Entity、Incidentの3種類 | 自動化の起点をアラート単位にするか、インシデント単位にするかを再設計する必要がある |
| 認証 | Microsoft Sentinelを含む各リソースに個別接続・個別認証が必要 | マネージドID、サービスプリンシパル、ユーザー認証のどれを使うか見直す必要がある |
| コスト | Logic Appsは別リソースとして作成され、追加料金が発生する可能性がある | 大量実行やStandard利用時は課金・監視設計が必要 |
Microsoft Sentinelコネクタでは、プレイブックを開始する「トリガー」、実行後の処理である「アクション」、前段の出力を後続処理で使う「動的フィールド」を組み合わせてワークフローを作ります。トリガーはアラート、エンティティ、インシデントに対応しています。(Microsoft Learn)
対象者：誰が確認すべきか
Azure Logic Apps for Microsoft Sentinel playbooksの更新内容は、単にSOC担当者だけが読むものではありません。影響を受けやすいのは、次のような担当者です。
Microsoft Defender・Sentinel管理者
Microsoft DefenderポータルでSentinelを運用する管理者は、既存のAutomation rulesとPlaybooksの動作条件を確認する必要があります。
特に、Azureポータルで作成した自動化ルールが、Defenderポータル移行後も意図した対象にだけ実行されるかが重要です。DefenderポータルではインシデントプロバイダーがMicrosoft XDRとして扱われるため、インシデントプロバイダー条件に依存したルールは見直しが必要です。(Microsoft Learn)
SOC運用担当者
SOC担当者は、手動実行できるプレイブックとできないプレイブックを整理する必要があります。
Defenderポータルでは、アラートに対する手動プレイブック実行と、エンティティに対する手動プレイブック実行が現在サポートされていません。一方で、インシデントを中心にした自動化は引き続き重要です。(Microsoft Learn)
Logic Apps開発者
Logic Apps開発者は、ConsumptionとStandardの違い、認証、動的コンテンツ、JSON解析、エラー時の分岐を確認する必要があります。
特にStandardワークフローを使う場合、Microsoft Sentinelではステートレスワークフローがプレイブックとしてサポートされません。また、Standardのプレイブックテンプレートは現時点でサポートされていないため、Azure Logic Apps側で手動作成する必要があります。(Microsoft Learn)
セキュリティアーキテクト
セキュリティアーキテクトは、Microsoft Defenderポータルへの移行計画、権限設計、データ保持・プライバシー、API連携、チケットシステム連携を確認する必要があります。
Defenderポータル移行後は、インシデントやアラートの扱い、相関付け、APIレスポンス項目に差分が出ます。ServiceNowなど外部システムと連携している場合は、インシデントURLやプロバイダー名、説明フィールドの扱いを検証しておくべきです。(Microsoft Learn)
Logic AppsのConsumptionとStandardの違い
Microsoft Sentinelのプレイブックでは、ConsumptionとStandardのLogic Appsがサポートされています。ただし、Microsoft Sentinelで使う場合は機能差に注意が必要です。
| 種類 | 特徴 | 向いているケース | 注意点 |
|---|---|---|---|
| Consumption | マルチテナント版Logic Appsで動作する従来型の実行モデル | 小規模な自動化、既存テンプレートを活用したい場合 | 実行回数が増える場合は課金と監視を確認する |
| Standard | シングルテナント版Logic Appsで動作し、複数ワークフロー、固定料金、ネットワーク機能、CI/CDに強い | VNet連携、プライベートエンドポイント、複数ワークフロー管理、CI/CD重視の運用 | Sentinelではステートレスワークフロー非対応。テンプレートから直接作成できない制約がある |
Standardは高性能で運用設計もしやすい一方、Microsoft Sentinelプレイブックとして使う場合は次の制約があります。
- プレイブックテンプレートはStandardワークフローでは現在サポートされない
- Standardを使う場合はAzure Logic Apps側で手動作成する
- プライベートエンドポイント利用時はLogic Apps側でアクセス制限ポリシーの定義が必要
- Microsoft SentinelはStandardのステートレスワークフローをプレイブックとしてサポートしない
Standardを選ぶべきか迷う場合は、「閉域ネットワーク接続が必要か」「複数ワークフローを1つのLogic Appにまとめたいか」「CI/CDで管理したいか」を判断基準にするとよいでしょう。単純な通知やタグ付け程度であれば、Consumptionのほうが管理しやすいケースもあります。(Microsoft Learn)
トリガーはAlert・Entity・Incidentのどれを選ぶべきか
Microsoft Sentinelプレイブックの設計で最も重要なのは、どのトリガーを使うかです。
| トリガー | 受け取る入力 | 主な用途 | 注意点 |
|---|---|---|---|
| Alert trigger | アラート | アラート単位の通知、外部照合、インシデント化前の処理 | DefenderポータルではMicrosoft Defender XDR由来のアラート自動化に制約がある |
| Entity trigger | ユーザー、ホスト、IPなどのエンティティ | 特定エンティティの調査、ブロック、照合 | インシデントに紐づかない実行ではIncident ARM IDがnullになる可能性がある |
| Incident trigger | インシデント、含まれるアラート・エンティティ | SOC運用の中心となるトリアージ、通知、チケット起票 | インシデント名や相関ルールの変化を前提に条件を設計する |
多くのケースでは、インシデントトリガーを中心に設計するのが安全です。Microsoftの公式情報でも、インシデントは調査の「ケースファイル」として、アラート、エンティティ、コメント、共同作業情報などを含むため、ほとんどのユースケースではインシデントベースの自動化が望ましいと説明されています。(Microsoft Learn)
一方で、アラート生成時点で外部システムに通知したい、インシデントを作るかどうかを外部ロジックで判断したい、といったケースではAlert triggerも有効です。ただし、Defenderポータル移行後はアラートとインシデントの生成・相関がMicrosoft Defender側のロジックに影響されるため、Azureポータル時代と同じ条件で動くとは限りません。(Microsoft Learn)
Defenderポータル移行で注意すべき影響範囲
Microsoft SentinelはMicrosoft Defenderポータルで一般提供されています。2027年3月31日以降、AzureポータルのMicrosoft Sentinelはサポートされず、Defenderポータルのみで利用される予定です。(Microsoft Learn)
この移行は、画面の場所が変わるだけではありません。プレイブックと自動化ルールには、次のような実務上の影響があります。
手動実行できないプレイブックがある
Defenderポータルでは、現時点で「アラートに対する手動プレイブック実行」と「エンティティに対する手動プレイブック実行」がサポートされていません。
そのため、Azureポータルで「アナリストが対象エンティティを開いて手動実行する」運用をしている場合は、インシデント起点の自動化、または別の実行経路に置き換える必要があります。(Microsoft Learn)
実行遅延を前提にする
Defenderポータルでは、Microsoft DefenderのインシデントがMicrosoft Sentinelに反映されるまで最大5分かかる場合があります。この遅延がある場合、プレイブックのトリガーも遅れます。また、Defenderポータルでアラートが発生してインシデントが作成・更新されてから、自動化ルールが実行されるまで最大10分かかる場合があります。(Microsoft Learn)
リアルタイム遮断が必要な処理と、通知・チケット起票のように数分の遅延を許容できる処理は分けて設計しましょう。
インシデント名を条件にしない
Defenderポータルでは、独自の相関エンジンによりインシデントやアラートが統合されます。オンボード後、既存インシデント名が変わる可能性があります。
そのため、自動化ルールの条件にインシデントタイトルを使うのは避けるべきです。代わりに、アラートを作成した分析ルール名やタグを使うほうが安定します。(Microsoft Learn)
Descriptionフィールドに依存しない
Defenderポータルへオンボードした後、SecurityIncidentテーブルにはDescriptionフィールドが含まれなくなります。インシデント作成トリガーの条件としてDescriptionを使っている自動化ルールは動作しなくなる可能性があります。外部チケットシステムとの連携でも、インシデント説明が欠落する可能性があります。(Microsoft Learn)
実務では、チケット本文をDescriptionだけに依存させず、タイトル、重大度、プロバイダー、エンティティ、カスタム詳細、関連アラート情報を組み合わせて生成する設計が安全です。
認証方式はマネージドIDを基本に見直す
Azure Logic Appsは、Microsoft Sentinelを含む各リソースに対して個別に接続し、個別に認証します。Microsoft Sentinelコネクタは、マネージドID、サービスプリンシパル、Microsoft Entraユーザーをサポートしています。(Microsoft Learn)
| 認証方式 | 特徴 | 推奨される使い方 |
|---|---|---|
| マネージドID | Logic Appsリソース自体にIDを持たせる。資格情報管理を減らせる | 可能な限り第一候補。運用アカウントに依存しない構成に向く |
| サービスプリンシパル | Microsoft Entraアプリとして認証する | CI/CDや複数環境管理で資格情報を統制したい場合 |
| Microsoft Entraユーザー | ユーザーとして接続する | 検証用途には使いやすいが、本番運用では退職・権限変更・MFA影響に注意 |
本番環境では、個人ユーザー接続に依存したプレイブックを避けるべきです。担当者の異動や退職、MFAポリシー変更、条件付きアクセスの変更で接続が切れるリスクがあります。
Microsoft Sentinelコネクタを使うには、認証されたIDに適切な権限が必要です。読み取りだけならMicrosoft Sentinel Reader、インシデント更新やコメント追加などの書き込み処理をするならMicrosoft Sentinel ResponderまたはContributorが必要です。(Microsoft Learn)
既存プレイブックの確認手順
既存環境がある場合は、次の順番で棚卸しすると効率的です。
| 手順 | 確認する内容 | 判断基準 |
|---|---|---|
| 1 | Active playbooksの一覧を確認 | 有効・無効、Consumption/Standard、トリガー種別を把握する |
| 2 | 各プレイブックの実行履歴を確認 | 失敗が多いもの、長時間実行されるものを優先的に見直す |
| 3 | 認証方式を確認 | ユーザー接続はマネージドIDまたはサービスプリンシパル化を検討する |
| 4 | 自動化ルールの条件を確認 | インシデント名、Description、Incident providerに依存していないか確認する |
| 5 | 手動実行の運用を確認 | アラート・エンティティ手動実行に依存している運用を洗い出す |
| 6 | 外部連携を確認 | ServiceNow、Teams、メール、Webhook、Graph APIなどの接続先を確認する |
| 7 | Defenderポータルでテスト | 実際のインシデントでトリガー、権限、遅延、出力を検証する |
Active playbooksタブでは、プレイブックの状態、Logic Appsのプラン、トリガー種別などを確認できます。Defenderポータルへオンボード後は、既定でオンボード済みワークスペースのサブスクリプションにフィルターが設定されます。別サブスクリプションのプレイブックを使う場合は、権限と表示範囲を確認してください。(Microsoft Learn)
アラートトリガーの古い呼び出し方式は移行を確認する
既存のアラートトリガープレイブックを、分析ルールから直接呼び出している場合は注意が必要です。Microsoftの公式情報では、分析ルールからプレイブックを呼び出す方式は2026年3月に非推奨となり、プレイブックは自動化ルールから呼び出す方式へ移行することが推奨されています。(Microsoft Learn)
移行の考え方は次のとおりです。
- 1つの分析ルールだけで使うプレイブックは、その分析ルールから自動化ルールを作成する
- 複数の分析ルールで共通利用するプレイブックは、Automationページから新しい自動化ルールを作る
- アクションの順序が重要な場合は、自動化ルール内で実行順を明示する
- 移行後は、旧来のAlert automation classic側からプレイブック呼び出しを外す
自動化ルールに移すことで、複数の分析ルールにまたがる自動化を一元管理でき、実行順序や有効期限も管理しやすくなります。(Microsoft Learn)
開発者が実装時に注意すべきポイント
Entity triggerではIncident ARM IDのnullを想定する
エンティティトリガーのプレイブックでは、インシデント更新のためにIncident ARM IDを使うことがあります。しかし、脅威ハンティングなどインシデントに紐づかない場面で実行されると、Incident ARM IDがnullになり、ワークフローが失敗する可能性があります。(Microsoft Learn)
対策として、Incident ARM IDを参照する最初のアクションの前に条件分岐を置きます。
Incident ARM ID is not equal to nulltrueの場合はインシデント更新へ進み、falseの場合は通知のみ、ログ記録のみ、または別ルートの処理に切り替えると安定します。
Custom detailsはParse JSONで扱う
Microsoft SentinelのIncident triggerでは、Alert custom detailsがJSONオブジェクトの配列として渡されます。カスタム詳細を後続アクションで使う場合は、Parse JSONアクションでスキーマを生成し、動的フィールドとして扱えるようにします。(Microsoft Learn)
実務では、分析ルールごとにCustom detailsのキーが異なることがあります。共通プレイブックを作る場合は、すべての分析ルールで同じキー名にそろえるか、キーが存在しない場合の分岐を作ると失敗を減らせます。
外部チケット連携ではURLとプロバイダー名を確認する
Defenderポータル移行後、インシデントやアラートのAPIレスポンス項目に差分があります。Microsoftは、統合インシデントやアラートとのやり取りにはMicrosoft Graph REST APIの利用を推奨しています。一方で、分析ルールや自動化ルールなどMicrosoft Sentinelリソースへの操作にはMicrosoft Sentinel APIが引き続き使われます。(Microsoft Learn)
外部システム連携では、次の項目を確認してください。
- インシデントURLとしてどのフィールドを使うか
- providerNameがAzure Sentinel前提になっていないか
- Microsoft XDRとして扱われることを想定しているか
- Descriptionが欠落してもチケット本文を生成できるか
- アラート情報取得時に必要な展開パラメーターを指定しているか
管理者が今すぐ確認すべきチェックリスト
既存のMicrosoft Sentinel環境を運用している場合は、次のチェックを優先してください。
- Microsoft SentinelをDefenderポータルで利用する前提の移行計画があるか
- 既存プレイブックのLogic AppsプランがConsumptionかStandardか把握しているか
- Standardワークフローでステートレスを使っていないか
- Standardのプライベートエンドポイント利用時にアクセス制限ポリシーを設定しているか
- 個人ユーザー認証のAPI接続が残っていないか
- プレイブックに必要なMicrosoft Sentinel Reader、Responder、Contributor権限が適切か
- アラートまたはエンティティの手動実行に依存した運用がないか
- 自動化ルールの条件にインシデント名やDescriptionを使っていないか
- 分析ルールから直接呼び出す古いプレイブックが残っていないか
- ServiceNowなど外部チケット連携で、Defenderポータル移行後の項目差分を検証したか
- 実行履歴、失敗履歴、課金、診断ログを監視しているか
このチェックで問題が見つかった場合は、まず「インシデントトリガー中心の自動化」「マネージドID中心の認証」「自動化ルールからの呼び出し」に寄せるのが現実的です。
失敗しやすい設計パターン
Azure Logic Apps for Microsoft Sentinel playbooksでよくある失敗は、機能不足ではなく、運用前提の見落としです。
個人アカウントで接続している
検証時に自分のMicrosoft Entraユーザーで接続し、そのまま本番化するケースは避けるべきです。ユーザーの権限変更や退職、条件付きアクセスの変更でプレイブックが停止する可能性があります。
本番では、マネージドIDまたはサービスプリンシパルを基本にし、必要最小限の権限を付与しましょう。
すべてをアラート単位で自動化している
アラート単位の自動化は便利ですが、SOCの調査単位は多くの場合インシデントです。アラートごとに通知やチケット作成をすると、重複チケットやノイズが増えることがあります。
インシデントが作成・更新されたタイミングで、関連アラートとエンティティをまとめて扱う設計のほうが、実務では管理しやすくなります。
条件がポータル移行に弱い
インシデントタイトル、Description、Incident providerなど、Defenderポータル移行で変化しやすい項目に依存すると、自動化ルールが意図せず動かなくなる可能性があります。
条件には、分析ルール名、タグ、重大度、エンティティ種別など、運用側で制御しやすい項目を使うのが安全です。
エラー分岐がない
Logic Appsは外部サービス連携が多いため、失敗は必ず起きます。API制限、認証切れ、チケットシステムのメンテナンス、JSON形式の違いなどを想定しないと、重要インシデント時に自動化が止まります。
少なくとも、本番プレイブックでは次を入れておきましょう。
- 失敗時の通知
- 実行履歴の確認手順
- リトライ方針
- 重要アクション前の条件分岐
- null値や空配列への対応
- 外部APIのタイムアウト対策
展開・移行時のおすすめ手順
Microsoft Defenderポータル前提でプレイブックを展開・移行する場合は、次の順序が安全です。
| フェーズ | 作業内容 | 完了条件 |
|---|---|---|
| 棚卸し | 既存プレイブック、自動化ルール、分析ルール、API接続を一覧化 | どのルールがどのプレイブックを呼ぶか分かる |
| 分類 | Incident、Alert、Entityのどのトリガーか分類 | インシデント中心に移せるものを判定できる |
| 権限見直し | 個人接続を洗い出し、マネージドID化を検討 | 本番実行に必要な最小権限が定義されている |
| 移行 | 分析ルール直接呼び出しを自動化ルール呼び出しへ変更 | Automation rulesから実行される |
| 検証 | Defenderポータルでテストインシデントを使って実行 | 遅延、条件、外部連携、失敗通知を確認できる |
| 監視 | 実行履歴、失敗、課金、診断ログを確認 | 定期的にレビューできる状態になっている |
一度にすべてを移行するのではなく、通知系、チケット起票系、インシデント更新系、外部アクション系に分けて段階的に確認すると、障害時の切り戻しがしやすくなります。
まとめ：次にやるべきこと
Azure Logic Apps for Microsoft Sentinel playbooksは、Microsoft Defenderポータル時代のSentinel運用で重要なSOAR基盤です。2026年5月14日に更新された公式情報では、Logic Appsの種類、Microsoft Sentinelコネクタ、認証、Standardワークフローの制約が整理されており、既存環境では移行・設定確認が必要です。
まず行うべきことは、既存プレイブックの棚卸しです。次に、古いアラートトリガー呼び出しを自動化ルールへ移行し、認証をマネージドID中心に見直します。そのうえで、Defenderポータル上でインシデントトリガーを中心にテストし、遅延、条件、外部連携、失敗時の動作を確認してください。
Azureポータル時代の設定をそのまま信じるのではなく、Microsoft Defenderポータルで実際に動く形へ調整することが、今後のMicrosoft Sentinelプレイブック運用で最も重要です。
コメント