Microsoft Sentinel プレイブックを運用している組織が2026年4月更新でまず確認すべき点は、Defender ポータル前提の運用設計、Consumption と Standard の使い分け、マネージド ID を中心にした認証、インシデント ID がない実行パターンへの備えです。Microsoft公式ドキュメント「Create and manage Microsoft Sentinel playbooks」は2026年4月22日に更新され、プレイブックの作成・管理手順だけでなく、Azure portal から Microsoft Defender ポータルへの移行を見据えた注意点も明示されています。(Microsoft Learn)
この記事では、security admins、identity teams、compliance teams が実務で何を見直すべきかを、設定手順・判断基準・失敗しやすいポイントに分けて整理します。
Microsoft Sentinel プレイブックの2026年4月更新で押さえるべき結論
Microsoft Sentinel プレイブックは、インシデント、アラート、エンティティに対する対応手順を Azure Logic Apps のワークフローとして自動化する仕組みです。自動化ルールに紐付けて実行することも、インシデントやエンティティから手動実行することもできます。(Microsoft Learn)
2026年4月時点で特に重要なのは、次の4点です。
| 確認ポイント | 実務上の意味 | 主な担当 |
|---|---|---|
| Defender ポータルへの移行前提 | Azure portal 中心の手順や教育資料を見直す必要がある | security admins |
| Logic Apps の Consumption / Standard 選択 | コスト、ネットワーク、テンプレート利用可否が変わる | security admins、platform teams |
| 認証方式の見直し | 可能な限りマネージド ID を使い、資格情報管理を減らす | identity teams |
| 動的コンテンツの null 対策 | ハンティング起点やエンティティ起点の実行で失敗を防ぐ | SOC、automation owners |
Microsoftは、2027年3月31日以降 Microsoft Sentinel は Azure portal でサポートされず、Microsoft Defender ポータルでのみ利用可能になると案内しています。Azure portal で運用しているチームは、2026年のうちに操作手順、権限設計、監査証跡の確認方法を Defender ポータル前提に切り替えるべきです。(Microsoft Learn)
Microsoft Sentinel プレイブックとは何か
Microsoft Sentinel プレイブックは、セキュリティ対応を自動化するための手順書をワークフロー化したものです。たとえば、不審なサインインを検知したときに、次のような処理を自動化できます。
- インシデントへ調査コメントを追加する
- ユーザー情報や端末情報を取得してインシデントに付与する
- Teams やメールへ通知する
- チケット管理システムへ起票する
- 条件に応じてユーザー無効化や端末隔離などの対応につなげる
プレイブックは Azure Logic Apps を基盤としているため、Microsoft Sentinel だけでなく、Microsoft Entra ID、Defender XDR、ServiceNow、Jira、Teams、メール、HTTP API など外部システムとの連携にも使えます。ただし Logic Apps のリソースとして動作するため、利用内容によって追加コストが発生する点は設計段階で確認が必要です。(Microsoft Learn)
プレイブックが向いている処理
プレイブックは「人が毎回同じ判断で行う処理」に向いています。たとえば、重大度が High のインシデントが作成されたら SOC チャンネルへ通知する、特定の分析ルールから発生したインシデントに資産情報を追記する、といった処理です。
一方で、証拠確認が不十分なままユーザーを無効化する、端末を隔離する、外部システムのデータを削除するような処理は、完全自動化の前に承認ステップや条件分岐を入れるべきです。誤検知が業務停止につながるためです。
2026年4月更新ポイント：Defender ポータル前提で運用を見直す
今回の公式ドキュメントで最も見落とせないのは、Microsoft Sentinel の操作場所が Defender ポータルへ寄っている点です。プレイブック作成手順でも、Defender ポータルまたは Azure portal から Microsoft Sentinel ワークスペースの Automation に移動する流れが示されています。(Microsoft Learn)
ただし、2027年3月31日以降は Azure portal での Sentinel 利用がサポートされなくなるため、Azure portal の手順だけに依存した運用はリスクになります。
いま見直すべき運用資料
| 見直し対象 | 確認内容 |
|---|---|
| SOC向け手順書 | Defender ポータルでインシデント、オートメーション、プレイブックを確認できるか |
| 管理者向け手順書 | Azure portal 前提の画面キャプチャだけになっていないか |
| 監査対応資料 | 誰が、どのプレイブックを、いつ実行・変更したか確認する手順があるか |
| 教育コンテンツ | 新任メンバーが Defender ポータルで同じ操作を再現できるか |
| 障害対応手順 | プレイブック失敗時に Logic Apps 側の実行履歴まで確認する流れがあるか |
特にグローバル組織では、日本拠点だけ Azure portal の旧手順を使い続け、海外SOCは Defender ポータルへ移行済みという状態が起こりがちです。インシデント対応時に画面や用語が揃っていないと、一次対応の遅延につながります。
Consumption と Standard の違いを理解して選ぶ
Microsoft Sentinel プレイブックでは、Azure Logic Apps の Consumption と Standard の両方がサポートされています。Consumption は従来型のマルチテナント実行、Standard はシングルテナント実行で、性能、価格体系、ネットワーク、CI/CD、複数ワークフロー管理などに違いがあります。(Microsoft Learn)
公式ドキュメントでは、Consumption プレイブックはトリガー種別を選んで作成でき、Standard プレイブックは Blank playbook から Logic App を作成し、その後にワークフローと Sentinel トリガーを追加する流れが示されています。(Microsoft Learn)
どちらを選ぶべきか
| 観点 | Consumption が向くケース | Standard が向くケース |
|---|---|---|
| 初期導入 | 小さく始めたい、テンプレートを活用したい | 既にLogic Apps標準化が進んでいる |
| ネットワーク | 外部SaaS連携や一般的な通知が中心 | VNet内、プライベートエンドポイント、閉域接続が必要 |
| 運用規模 | 少数のプレイブックをイベントベースで実行 | 多数のワークフローをまとめて管理したい |
| コスト管理 | 実行回数ベースで様子を見たい | 実行量が多く、固定的なリソース設計をしたい |
| 開発運用 | ポータル中心で作成したい | CI/CDや環境分離を重視したい |
Standard は高機能ですが、Microsoft Sentinel のプレイブックとして使う場合に注意があります。公式情報では、Standard ワークフローではプレイブックテンプレートが直接サポートされないこと、プライベートエンドポイント利用時にアクセス制限ポリシーが必要になること、Sentinel プレイブックとして stateless workflow はサポートされないことが示されています。(Microsoft Learn)
Standard を選ぶときの失敗例
Standard を選ぶときに多い失敗は、「ネットワーク要件があるから Standard にする」とだけ決めて、プレイブックの作成手順や権限付与を Consumption と同じ感覚で進めてしまうことです。
Standard では、Logic App リソースを作っただけでは終わりません。ワークフローを作成し、State type を Stateful にし、Microsoft Sentinel の incident、alert、entity いずれかのトリガーを追加する必要があります。公式ドキュメントでも、Standard では Logic App 作成後にワークフローを作る手順が明記されています。(Microsoft Learn)
トリガーは incident、alert、entity の使い分けが重要
Microsoft Sentinel プレイブックのトリガーは、主に次の3種類です。
| トリガー | 入力 | 使いどころ |
|---|---|---|
| Incident trigger | インシデント、関連アラート、エンティティ | インシデント単位で通知、起票、優先度判定をしたい場合 |
| Alert trigger | 個別アラート | アラート生成直後に軽量な処理をしたい場合 |
| Entity trigger | ユーザー、ホスト、IPなどのエンティティ | 調査中に特定ユーザーや端末へ手動処理を実行したい場合 |
実務では、インシデント対応の標準化には Incident trigger、調査中の補助操作には Entity trigger が使いやすいです。Alert trigger は個別アラート単位で細かく動かせますが、Microsoft Sentinel の運用はインシデント中心に整理されることが多いため、設計時には「その処理は本当にアラート単位で必要か」を確認しましょう。
自動化ルールとの組み合わせを前提にする
インシデントやアラートに自動対応する場合、プレイブック単体ではなく自動化ルールと組み合わせます。公式ドキュメントでは、インシデント作成時、インシデント更新時、アラート生成時などをトリガーにして自動化ルールを作成し、Run playbook アクションでプレイブックを呼び出す流れが説明されています。(Microsoft Learn)
ここで重要なのは、自動化ルールのトリガーとプレイブックのトリガー種別を合わせることです。たとえば、インシデント作成時に動く自動化ルールから呼び出すなら、原則として incident trigger のプレイブックを用意します。
認証はマネージド ID を第一候補にする
2026年時点のプレイブック運用では、認証設計が非常に重要です。プレイブックは Logic Apps として動作し、Microsoft Sentinel や他サービスへ接続するため、それぞれのリソースに対して認証が必要になります。(Microsoft Learn)
Microsoft Sentinel コネクタでは、主に次の認証方式が使われます。
| 認証方式 | 特徴 | 注意点 |
|---|---|---|
| マネージド ID | Logic App 自体にIDを持たせる。資格情報の管理を減らせる | 対象リソースへのロール割り当てが必要 |
| サービスプリンシパル | アプリ登録を使う。権限や資格情報を明確に管理しやすい | シークレットや証明書の期限管理が必要 |
| Microsoft Entra ユーザー | ユーザーとしてサインインする | 個人アカウント依存になりやすく、本番自動化では避けたい |
公式ドキュメントでも、可能な場合はマネージド ID を認証に使うことが推奨されています。資格情報を直接扱わずに済むため、退職者アカウント、期限切れシークレット、過剰権限の放置といった運用リスクを減らせます。(Microsoft Learn)
Identity teams が確認すべきこと
identity teams は、プレイブックごとに「どのIDが、どのワークスペースへ、何をできるか」を棚卸しする必要があります。
特に注意すべきなのは、読み取りだけでよいプレイブックに更新権限を与えてしまうことです。Microsoft Sentinel コネクタでは、読み取り用途と書き込み用途で必要なロールが異なります。公式ドキュメントでは、Microsoft Sentinel Reader はトリガーや読み取りアクションに対応し、Responder / Contributor は書き込みアクションにも対応する整理が示されています。(Microsoft Learn)
たとえば、インシデント情報を取得して Teams に通知するだけなら、原則として過剰な書き込み権限は不要です。一方、インシデントのステータス更新、コメント追加、ウォッチリスト更新などを行う場合は、書き込み可能なロールが必要になります。
動的コンテンツの null 対策を入れる
今回の公式ドキュメントで実務的に重要なのが、インシデント ID がないエンティティプレイブックへの注意です。
Entity trigger で作成したプレイブックは、インシデントに紐づくエンティティから実行されるとは限りません。脅威ハンティングなど、インシデントに接続されていない場面で実行されると、Incident ARM ID が null になり、後続の「インシデントを更新する」処理で失敗する可能性があります。公式ドキュメントでは、Incident ARM ID の値を条件で確認してから後続処理へ進むことが推奨されています。(Microsoft Learn)
null 対策の設計例
| 条件 | 実行する処理 |
|---|---|
| Incident ARM ID が null ではない | インシデントへコメント追加、タグ付け、ステータス更新 |
| Incident ARM ID が null | エンティティ情報の取得、Teams通知、調査メモ出力のみ実行 |
| エンティティ種別が想定外 | 処理を中断し、実行ログに理由を残す |
この条件分岐を入れないと、ハンティング中に便利なはずのプレイブックが途中失敗し、SOCメンバーが「何が成功して何が失敗したか」を手作業で確認することになります。
カスタム詳細は JSON 配列として扱う
Microsoft Sentinel の incident trigger では、アラートのカスタム詳細を動的コンテンツとして扱えます。ただし公式ドキュメントでは、Alert custom details は JSON オブジェクトの配列として説明されています。つまり、単一の文字列としてそのまま使うのではなく、Parse JSON などでスキーマを生成して扱う必要があります。(Microsoft Learn)
よくある失敗
カスタム詳細でよくある失敗は、分析ルール側で追加したキーと、プレイブック側で参照しているキーが一致していないことです。
たとえば、分析ルールでは UserPrincipalName をカスタム詳細に設定しているのに、プレイブック側では UPN として参照していると、期待した値が入りません。さらに、カスタム詳細の値は配列として扱われるため、後続アクションで文字列を期待している場合は、最初の要素を取り出す、結合する、ループで処理するなどの設計が必要です。
運用で使いやすい命名ルール
カスタム詳細は、SOC、ID管理、監査担当が読んでも意味が分かる名前にしましょう。
| 悪い例 | 良い例 | 理由 |
|---|---|---|
field1 | UserPrincipalName | 何の値か分かる |
ip | SourceIPAddress | 送信元か宛先か区別できる |
risk | SignInRiskLevel | どのリスク指標か分かる |
id | IncidentRelatedAccountObjectId | IDの種類を誤解しにくい |
監査やインシデントレビューでは、「なぜそのプレイブックがその判断をしたのか」を説明できることが重要です。カスタム詳細の命名は、後からの説明責任にも関わります。
プレイブック作成手順の実務版チェックリスト
公式ドキュメントの流れを実務向けに整理すると、プレイブック作成は次の順序で進めると失敗しにくくなります。
| 手順 | 作業 | 確認ポイント |
|---|---|---|
| 1 | 自動化したい対応を決める | 通知、情報付与、起票、封じ込めのどれか |
| 2 | トリガーを選ぶ | incident、alert、entity のどれで起動するか |
| 3 | Logic Apps の種類を選ぶ | Consumption か Standard か |
| 4 | 認証方式を決める | 可能ならマネージド ID |
| 5 | 必要なロールを割り当てる | 読み取りだけか、書き込みも必要か |
| 6 | 条件分岐を入れる | 重大度、分析ルール名、Incident ARM ID null など |
| 7 | アクションを追加する | 通知、コメント、チケット作成、API連携など |
| 8 | テスト実行する | 成功時だけでなく失敗時も確認 |
| 9 | 実行ログを確認する | Logic Apps の実行履歴で入力・出力を確認 |
| 10 | 自動化ルールへ紐付ける | 本番適用前に対象条件を絞る |
プレイブックは作った時点では完成ではありません。どの分析ルールから呼び出すか、どの条件で実行するか、誰が失敗時に確認するかまで決めて、初めて運用品質になります。
管理画面で確認すべき項目
公式ドキュメントでは、Automation の Active playbooks タブからアクセス可能なプレイブックを確認できると説明されています。ここでは、状態、Logic Apps のプラン、トリガーの種類などを確認できます。Standard のプレイブックでは LogicApp/Workflow という命名規則が使われます。(Microsoft Learn)
管理時に見るべき項目は次の通りです。
| 項目 | 確認理由 |
|---|---|
| Status | 無効化されたプレイブックが自動化ルールに残っていないか |
| Plan | Consumption / Standard のどちらで動いているか |
| Trigger kind | Sentinel トリガーか、Sentinel アクションのみか |
| Resource group | Sentinel に実行権限を付与しているか |
| Run history | 失敗が継続していないか |
| Connections | ユーザー認証や期限切れの接続が残っていないか |
特に「Using Microsoft Sentinel Action」や「Other」と表示されるプレイブックは、Microsoft Sentinel トリガーで始まっていない可能性があります。自動化ルールから期待通りに呼び出せるかを確認しましょう。
security admins が取るべき対応
security admins は、プレイブックの数を増やす前に、運用ルールを整えるべきです。自動化は便利ですが、設計が曖昧なまま増えると、どの処理がいつ実行されるのか分からなくなります。
優先してやること
- Azure portal 前提の手順を Defender ポータル前提に更新する
- 既存プレイブックを incident / alert / entity 別に棚卸しする
- 自動化ルールとプレイブックの対応表を作る
- 失敗時の確認手順を Logic Apps 実行履歴まで含めて整備する
- 本番影響があるアクションには承認や条件分岐を入れる
たとえば、重大度 High のインシデントで Teams 通知するプレイブックは比較的安全に自動化できます。一方、ユーザー無効化や端末隔離は、対象ユーザー、端末種別、業務時間、例外アカウントなどを条件に含めるべきです。
identity teams が取るべき対応
identity teams は、プレイブックの認証方式とロール割り当てを重点的に確認します。特に、個人ユーザーの接続で動いているプレイブックは、本番運用ではリスクが高くなります。
確認すべき観点
| 観点 | 確認内容 |
|---|---|
| 接続ID | 個人アカウントではなく、マネージド ID または管理されたアプリか |
| 権限 | Reader で足りる処理に Contributor を付けていないか |
| シークレット | サービスプリンシパル利用時に期限管理されているか |
| 退職・異動 | 人に依存する接続が残っていないか |
| 条件付きアクセス | 自動化用IDのサインインが想定通り制御されているか |
特にグローバル企業では、複数テナントや Azure Lighthouse を使う運用もあります。Microsoft Sentinel でインシデントに対してプレイブックを実行する場合、ユーザー自身の権限だけでなく、Sentinel 側のサービスアカウントに対するリソースグループ権限も必要になるケースがあります。(Microsoft Learn)
compliance teams が取るべき対応
compliance teams は、「自動化された対応が監査可能か」を確認します。プレイブックはセキュリティ対応を高速化しますが、誰が承認したのか、どの条件で実行されたのか、実行結果は成功したのかを説明できなければ、監査や事後レビューで問題になります。
監査観点のチェックリスト
| チェック項目 | 具体例 |
|---|---|
| 実行条件が明文化されている | 「重大度 High かつ特定分析ルールのみ」など |
| 変更履歴を追える | Logic Apps、Automation rule、権限変更の履歴を確認できる |
| 失敗時の対応が決まっている | 失敗ログ確認、再実行、手動対応の判断基準がある |
| 過剰な自動対応を防いでいる | ユーザー無効化などに条件や承認を入れている |
| データ連携先が妥当 | チケット、チャット、外部APIへ送る情報が最小限か |
特に個人情報、認証情報、端末情報を外部ツールへ送るプレイブックは、データ分類と保持期間を確認してください。通知先の Teams チャンネルやチケットプロジェクトに、不要なメンバーが参加していないかも重要です。
既存プレイブックの棚卸し観点
2026年4月更新をきっかけに、既存プレイブックは次の観点で棚卸ししましょう。
| 棚卸し項目 | 見直しポイント |
|---|---|
| ポータル依存 | Azure portal 手順だけで管理されていないか |
| トリガー種別 | incident / alert / entity の用途が明確か |
| Logic Apps 種類 | Consumption / Standard の選択理由があるか |
| 認証 | ユーザー接続や期限切れシークレットがないか |
| 権限 | 最小権限になっているか |
| 条件分岐 | null、重大度、分析ルール名、例外アカウントに対応しているか |
| ログ | 実行履歴と失敗理由を追えるか |
| コスト | 不要な高頻度実行や重い処理がないか |
| 所有者 | 問い合わせ先、変更責任者が明確か |
プレイブックは「作った人しか分からない自動化」になりやすい領域です。所有者、目的、発火条件、影響範囲を一覧化しておくと、インシデント対応だけでなく監査や引き継ぎにも役立ちます。
本番導入前のテストで見るべきポイント
プレイブックのテストでは、正常系だけでなく異常系を確認します。
| テスト観点 | 確認内容 |
|---|---|
| 正常実行 | 想定したトリガーで起動し、全アクションが成功するか |
| 権限不足 | 権限不足時にどのエラーが出るか |
| null 入力 | Incident ARM ID やカスタム詳細がない場合に失敗しないか |
| 複数アラート | インシデント内に複数アラートがある場合にループ処理できるか |
| 外部API障害 | チケット作成や通知が失敗したときに再試行・通知できるか |
| 誤検知 | 条件に合わないインシデントで実行されないか |
特に自動化ルールに紐付ける前に、対象となる分析ルール名や重大度で条件を絞ることをおすすめします。最初から全インシデントに対して動かすと、想定外の通知増加や外部システムのチケット乱立につながります。
2026年4月更新を受けた実務アクション
今回の更新内容を踏まえると、次に取るべき行動は明確です。
まず、既存の Microsoft Sentinel プレイブックを一覧化し、Defender ポータルでの確認・実行・編集手順を検証します。次に、Consumption と Standard の選択理由を整理し、ネットワーク要件があるプレイブックでは Standard の Stateful workflow、アクセス制限、プライベート接続まわりを確認します。
そのうえで、認証方式を棚卸しし、個人ユーザー接続をマネージド ID または適切に管理されたサービスプリンシパルへ移行します。最後に、Incident ARM ID の null 対策、カスタム詳細の JSON 処理、実行ログ確認手順を追加すれば、2026年時点の公式ガイドに沿った堅実な運用に近づきます。
Microsoft Sentinel プレイブックは、単なる自動通知ツールではありません。SOC、ID管理、コンプライアンスの3者が同じ設計思想で管理すれば、インシデント対応の速度と再現性を大きく高められます。2027年の Defender ポータル移行期限を待たず、2026年のうちにプレイブック運用を標準化しておきましょう。
コメント