Microsoft DefenderのAI/Copilot更新で注目すべき点は、Microsoft SentinelのプレイブックをDefenderポータル内で自然言語から生成できるようになることです。管理者は「便利な自動化機能が増えた」と捉えるだけでなく、Security Copilotの有効化、Microsoft SentinelワークスペースのDefenderポータル連携、権限、統合プロファイル、既存の自動化ルールへの影響を事前に確認する必要があります。特に本番環境では、生成されたPythonコードをそのまま有効化せず、実アラートでのテスト、手動レビュー、トリガー条件の絞り込みを行ってから段階的に展開するのが安全です。Microsoft Learnでは、Microsoft Sentinelのプレイブック作成・管理やDefenderポータル移行に関する情報が2026年5月14日に更新されており、AI生成プレイブックのプレビュー情報と合わせて確認すべき内容になっています。(Microsoft Learn)
Microsoft DefenderのAI/Copilot更新で何が変わるのか
今回のポイントは、Microsoft SentinelのSOARプレイブック作成に「自然言語で説明して、AIと共同で生成する」という選択肢が加わることです。
従来、Microsoft Sentinelのプレイブックは主にAzure Logic Appsベースで作成し、トリガー、条件分岐、コネクタ、アクションを管理者や開発者が組み立てていました。AIを使ったプレイブック生成では、Defenderポータル内に埋め込まれたVS Code環境で、AIコーディングエージェントのClineと会話しながら、Pythonベースの自動化ワークフロー、ドキュメント、視覚的なフロー図を作成できます。生成されたプレイブックはアラートデータを入力として利用し、必要な外部API呼び出しは統合プロファイルの設定に基づいて生成されます。(Microsoft Learn)
ただし、これは「SOCの自動化を完全にAIへ任せる機能」ではありません。AIは設計と実装を支援しますが、実行権限、API認証情報、トリガー条件、生成コードの安全性、本番展開の判断は引き続き管理者側の責任です。
| 観点 | 従来のSentinelプレイブック | AI生成プレイブック |
|---|---|---|
| 主な作成方法 | Logic Appsデザイナー、テンプレート、手動構成 | Defenderポータル内の自然言語チャットと埋め込みVS Code |
| 実装の中心 | Logic Appsワークフロー | Pythonベースのコード生成 |
| 入力 | インシデント、アラート、エンティティなど構成により異なる | 現時点ではアラート入力が中心 |
| ドキュメント化 | 作成者が別途整備しがち | ドキュメントとフロー図を自動生成 |
| 向いている用途 | 定型的なコネクタ連携、既存資産の継続運用 | API連携を含む新規自動化、条件分岐の多いSOAR設計 |
| 注意点 | Logic Appsの接続・権限・課金管理が必要 | Copilot、権限、統合プロファイル、生成コードレビューが必要 |
影響範囲はSOC担当者だけでなく管理者・開発者にも及ぶ
AI生成プレイブックの影響は、セキュリティアナリストだけに限られません。むしろ、本番利用で問題が起きやすいのは、権限、API認証、既存自動化ルール、監査、運用手順の部分です。
SOC担当者にとっては、フィッシング対応、URL評価、ユーザー無効化、チケット起票、通知といった作業を自然言語で設計しやすくなります。たとえば「高重大度のフィッシングアラートを受けたら、送信者、URL、対象ユーザーを抽出し、外部脅威インテリジェンスでURLを評価し、結果をインシデントコメントに追加する」といった指示から、処理フローを組み立てられます。
管理者にとっては、Security Copilotの有効化状態、Microsoft SentinelワークスペースのDefenderポータルへのオンボード、Microsoft Entra IDのロール、アプリ登録、クライアントシークレット、統合プロファイルの管理が重要になります。開発者やセキュリティエンジニアにとっては、生成されたPythonコードの安全性、例外処理、外部APIの失敗時動作、ログ出力、レート制限、シークレット管理をレビューする作業が増えます。
利用前に確認すべき前提条件
AIでMicrosoft Sentinelプレイブックを生成するには、いくつかの前提条件があります。特に見落としやすいのは、Security Copilotの要件とMicrosoft Entra IDのロールです。
Microsoftの公式情報では、テナントでSecurity Copilotが有効化され、利用可能なSCUがあることが技術要件として示されています。プレイブック生成ではSCUに課金されないとされていますが、SCUの可用性自体は必要です。また、Microsoft SentinelワークスペースがMicrosoft Defenderポータルにオンボードされている必要があります。(Microsoft Learn)
| 確認項目 | 確認する場所 | 不備がある場合に起きること | 対応 |
|---|---|---|---|
| Security Copilotの有効化 | Security Copilot管理画面 | プレイブック生成を開始できない | テナントでSecurity Copilotを有効化し、必要な容量設定を確認する |
| SentinelワークスペースのDefenderポータル連携 | Microsoft Defenderポータル | SentinelのAutomation機能が想定通り使えない | 対象ワークスペースをDefenderポータルにオンボードする |
| Microsoft Sentinel Contributor | Azureのサブスクリプション、リソースグループ、ワークスペース | 自動化ルールの作成・編集ができない | 対象スコープにロールを割り当てる |
| Detection tuningロール | Microsoft Entra ID | プレイブックジェネレーターを使用できない | Microsoft Entra ID側で必要ロールを付与する |
| 統合プロファイル | DefenderポータルのAutomation | 外部APIやGraph APIを利用する処理を生成・実行できない | 必要なAPIごとに統合プロファイルを作成する |
| 権限反映待ち | ロール割り当て後 | 付与直後に機能が使えない | 最大2時間程度の反映待ちを考慮する |
権限は「とりあえず広く付与する」よりも、パイロット用の少人数グループに限定して検証するのが現実的です。特に、アカウント無効化、IPブロック、クラウドリソース操作などの破壊的または影響の大きいアクションを含む場合は、最小権限と承認フローを先に設計してください。
統合プロファイルはAI生成プレイブックの成否を左右する
AI生成プレイブックでは、外部サービスやAPIを呼び出すために「統合プロファイル」を使います。統合プロファイルには、Base URL、認証方式、必要な資格情報を設定します。Microsoft Graph、チケット管理システム、脅威インテリジェンスサービス、クラウド基盤のAPIなどを使う場合、事前にプロファイルを整備しておく必要があります。
代表的なGraph API連携では、Microsoft Entra IDでアプリ登録を作成し、Application ID、Directory ID、クライアントシークレットを取得します。その後、DefenderポータルのMicrosoft Sentinel > Configuration > AutomationからIntegration Profilesを作成し、Base API URLにhttps://graph.microsoft.com、認証方式にOAuth2、Token endpointにテナントIDを含むURL、Scopesにhttps://graph.microsoft.com/.defaultを設定します。公式手順では、Microsoft GraphのApplication権限としてSecurityAlert.Read.Allが許可済みであることも確認対象になっています。(Microsoft Learn)
注意すべき点は、統合プロファイルのAPI URLと認証方式は作成後に変更できないことです。URLや認証方式を変えたい場合は、新しい統合プロファイルを作成し、古いものを削除する運用になります。これは本番展開後の設計変更に影響するため、開発用、検証用、本番用でプロファイルを分けると管理しやすくなります。
プレイブック生成から展開までの基本手順
AI生成プレイブックの流れは、単にチャットで依頼して終わりではありません。Plan modeで設計を確認し、Act modeでコード生成し、実アラートでテストし、保存後に明示的に有効化します。
| フェーズ | 作業内容 | 管理者が確認すべき点 |
|---|---|---|
| 事前準備 | Security Copilot、Sentinelワークスペース、権限、統合プロファイルを確認 | 権限不足、API認証情報、データ共有設定 |
| 作成開始 | PlaybooksタブからCreate > Playbook Generatorを選択 | 命名規則、対象ワークスペース、作成者権限 |
| Plan mode | 自然言語で処理内容を説明し、計画とフロー図を確認 | 条件、対象アラート、例外処理、影響範囲 |
| Act mode | Pythonコード、ドキュメント、フロー図を生成 | コードレビュー、承認、外部API呼び出し |
| テスト | Alert IDを指定して実アラートでテスト | 誤検知時の動作、ログ、通知、失敗時処理 |
| 保存 | 生成されたプレイブックを保存 | 保存後は無効状態で作成される点に注意 |
| 有効化 | Active PlaybooksでActivateに切り替える | 本番化の承認、ロールバック手順 |
| 自動実行 | Automation RulesでEnhanced Alert Triggerを作成 | 条件の絞り込み、対象ワークスペース、実行アクション |
公式手順では、作成時に埋め込みVS Code環境が開き、Plan modeで要件を説明し、必要に応じてAIが確認質問や不足している統合プロファイルの指摘を行います。Act modeではPythonコード、ドキュメント、フロー図が生成され、テスト実行前には環境に加えられる変更内容を提示して承認を求める流れです。保存後のプレイブックは無効状態で作成されるため、Active Playbooksタブで明示的に有効化する必要があります。(Microsoft Learn)
自然言語プロンプトは「誰に、何を、どの条件で、どこまで」を書く
AI生成の品質は、プロンプトの具体性に大きく左右されます。抽象的に「フィッシング対応を自動化して」と書くより、入力、条件、アクション、失敗時処理、期待する出力を明確にした方が、レビューしやすいプレイブックになります。
良くない依頼例
「フィッシングアラートに対応するプレイブックを作って」
この書き方では、どのアラートを対象にするのか、何を抽出するのか、ユーザーを無効化するのか、通知だけなのか、外部APIを使うのかが分かりません。AIが確認質問を返すか、意図と異なる設計になる可能性があります。
実務で使いやすい依頼例
「Microsoft Defender for Office 365由来の高重大度フィッシングアラートを対象にする。アラートから送信者メールアドレス、受信者、URLエンティティを抽出する。URLはVirusTotalの統合プロファイルで評価し、悪性判定がある場合のみMicrosoft Sentinelのインシデントにコメントを追加する。ユーザー無効化やメール削除は行わず、SOCチームにTeams通知する。API呼び出しに失敗した場合は、失敗理由をコメントに残して処理を終了する」
このように書くと、AIが作るべき処理範囲が明確になります。初回の本番導入では、アカウント無効化やブロックなどの強いアクションよりも、エンリッチメント、コメント追加、通知、チケット起票のような低リスクの自動化から始めるのがおすすめです。
Enhanced Alert Triggerを使う場合の設計ポイント
生成したプレイブックを自動実行するには、プレイブックの有効化に加えて、Enhanced Alert Triggerを使ったAutomation Ruleの作成が必要です。条件には、アラートタイトル、重大度、プロバイダー、対象ワークスペースなどを指定できます。アクションではRun Playbookを選び、有効化済みのプレイブックを指定します。(Microsoft Learn)
Enhanced Alert Triggerはテナントレベルで動作し、複数ワークスペースやMicrosoft Sentinel、Microsoft Defender、XDRプラットフォーム由来のアラートにまたがる自動化を設計できます。一方で、条件を広くしすぎると、想定外のアラートに対して自動処理が走る危険があります。
本番運用では、最初から「すべての高重大度アラート」を対象にするのではなく、以下のように段階的に絞り込むと安全です。
| 段階 | 条件設計 | 目的 |
|---|---|---|
| 検証 | 特定のテスト用アラートタイトル、検証用ワークスペース | 生成コードとAPI連携の確認 |
| パイロット | 特定プロバイダー、特定重大度、限定ワークスペース | 実運用に近い条件で副作用を確認 |
| 本番初期 | 高重大度かつ特定の分析ルール名、通知・コメント中心 | 誤動作時の影響を抑える |
| 本番拡張 | 条件を追加し、必要に応じて封じ込めアクションを追加 | 運用実績を見ながら自動化範囲を広げる |
既存のSentinelプレイブックからの移行で注意すべきこと
既存のMicrosoft Sentinel環境をDefenderポータルへ移行している組織では、AI生成プレイブックそのものよりも、ポータル統合による自動化ルールやインシデント処理の違いに注意が必要です。
Microsoftは、2027年3月31日以降、Microsoft SentinelはAzureポータルでサポートされず、Microsoft Defenderポータルでのみ利用可能になると案内しています。既存のAzureポータル中心の運用を続けている場合は、AI生成プレイブックの検証と並行して、Defenderポータルへの移行計画を立てる必要があります。(Microsoft Learn)
Defenderポータル移行では、既存の自動化ルールやプレイブックに次のような影響が出る可能性があります。
| 影響箇所 | 注意点 | 推奨対応 |
|---|---|---|
| アラートトリガーの自動化ルール | DefenderポータルではMicrosoft Sentinelアラートに対して動作する制約がある | 対象アラートとトリガー条件を棚卸しする |
| インシデントプロバイダー | DefenderポータルではインシデントプロバイダーがMicrosoft XDRとして扱われる | ProviderNameに依存した条件を見直す |
| インシデント名 | 相関処理により既存インシデント名が変わる場合がある | インシデントタイトルを条件に使わず、分析ルール名やタグを使う |
| Descriptionフィールド | Defenderポータル移行後にSecurityIncidentテーブルのDescriptionが利用できないケースがある | 外部チケット連携や条件式を確認する |
| 実行遅延 | インシデント同期や自動化ルール実行に数分の遅延が起きる場合がある | 即時対応が必要な処理は別設計を検討する |
| 手動実行 | Defenderポータルではアラートやエンティティに対する手動実行が未対応の手順がある | 手動実行が必要な運用手順を再確認する |
| API連携 | 統合インシデントやアラートではMicrosoft Graph REST APIの利用が推奨される | SecurityInsights API前提の処理を見直す |
特に、インシデントタイトルやプロバイダー名に依存した条件は、移行後に想定通り動かなくなる可能性があります。Microsoftの移行ガイダンスでも、自動化ルールを安定して実行するために、インシデントタイトルではなく分析ルール名やタグを条件に使うことが推奨されています。(Microsoft Learn)
AI生成プレイブックの制限を把握してから設計する
AI生成プレイブックは便利ですが、現時点ではプレビュー機能であり、明確な制限があります。制限を知らずに設計すると、要件定義の途中で実現できないことが分かったり、本番運用後にスケール上の問題が出たりします。
| 制限項目 | 内容 | 設計上の判断基準 |
|---|---|---|
| 言語 | Pythonのみサポート | PowerShellやNode.js前提の実装は別方式を検討 |
| 入力 | アラートのみ対応 | インシデント起点、エンティティ起点の処理は既存プレイブックを活用 |
| 外部ライブラリ | 現時点では未対応 | 標準機能とAPI呼び出しで実装できるか確認 |
| プレイブック数 | テナントあたり最大100個 | 用途別に乱立させず、命名規則と整理方針を決める |
| サイズ | 1プレイブック最大5,000行 | 複雑な処理は分割や別サービス連携を検討 |
| 実行時間 | 1回の実行は最大10分 | 長時間処理や大量処理には向かない |
| 統合数 | テナントあたり最大500統合 | 環境別・用途別のプロファイル管理を設計 |
| AI利用量 | テナントあたり1日最大8Mトークン | 大量生成や頻繁な試行錯誤は検証計画を立てる |
| 自動化ルール | Enhanced Alert Triggerは優先順位や有効期限をサポートしない | ルールの競合や停止日管理は別途運用で補う |
| アクション数 | 1ルールにつき1アクション | 複数処理はプレイブック内にまとめるかルールを分ける |
公式情報では、生成時にコードやドキュメント、フロー図が提供される一方で、制限事項として自動コード検証は提供されないとされています。そのため、AIが生成したコードであっても、手動レビュー、テスト、実行ログ確認は省略できません。(Microsoft Learn)
管理者が本番前に見るべきチェックリスト
AI生成プレイブックを本番環境に入れる前に、最低限次の項目を確認してください。特に、アカウント停止、権限変更、ネットワークブロック、クラウドリソース操作などを含む自動化では、承認者を明確にしておく必要があります。
| チェック項目 | 確認内容 |
|---|---|
| 対象範囲 | どのワークスペース、どのプロバイダー、どのアラート重大度に適用するか |
| 実行条件 | アラートタイトル、分析ルール名、タグ、重大度などで十分に絞れているか |
| 権限 | プレイブック実行に必要な権限が過剰でないか |
| 統合プロファイル | 本番用API URL、認証方式、シークレット期限、権限スコープが適切か |
| 生成コード | 例外処理、ログ、API失敗時の動作、データ取り扱いをレビューしたか |
| テスト | 実アラートまたは検証用アラートで想定通りに動作したか |
| ロールバック | プレイブック無効化、Automation Rule停止、シークレット無効化の手順があるか |
| 監視 | 実行結果をIncidentのActivitiesで確認できるか |
| 監査 | 誰が作成・変更・有効化したかを追跡できるか |
| 運用手順 | SOC担当者が失敗時に何を確認すべきか文書化しているか |
生成プレイブックの実行状況は、関連するインシデントページのActivitiesタブで確認できます。一方、Automation Ruleの実行結果はMicrosoft Sentinel Health Tableには書き込まれないとされているため、従来の監視手順だけに依存しないよう注意が必要です。(Microsoft Learn)
開発者・セキュリティエンジニア向けのレビュー観点
AI生成プレイブックは「コードとして読める」点が利点です。Logic AppsのGUIだけでは把握しにくかった条件分岐やAPI呼び出しも、Pythonコードとしてレビューできます。ただし、レビューしやすいからこそ、開発者視点の確認を本番前に入れるべきです。
確認すべきポイントは次の通りです。
| 観点 | 具体的な確認ポイント |
|---|---|
| 入力検証 | アラートに期待するエンティティが存在しない場合に失敗しないか |
| 例外処理 | API失敗、認証失敗、タイムアウト時に安全に終了するか |
| 冪等性 | 同じアラートで複数回実行されても二重処理にならないか |
| ログ | 成功、失敗、スキップの理由が追跡できるか |
| 秘密情報 | シークレットやトークンをログ、コメント、プロンプトに出していないか |
| API制限 | 外部サービスのレート制限や再試行設計を考慮しているか |
| 影響範囲 | ユーザー無効化、ブロック、削除などの処理に条件が十分あるか |
| 保守性 | 生成ドキュメントだけでなく、社内の変更管理にも登録しているか |
実務では、最初のプロンプトに「破壊的な操作は行わない」「失敗時はコメントに理由を残す」「対象ユーザーが役員グループに属する場合は実行しない」「本番ではなく検証用ワークスペースを対象にする」といった制約を入れると、安全側に寄せやすくなります。
まず試すなら「エンリッチメント」と「通知」から始める
初回の導入では、封じ込めや削除の自動化よりも、エンリッチメントと通知から始めるのが現実的です。たとえば次のような用途は、比較的リスクを抑えて効果を確認できます。
| ユースケース | 内容 | リスク |
|---|---|---|
| URL評価 | アラート内のURLを外部サービスで評価し、結果をコメントに追加 | 低 |
| ユーザー情報の補足 | Graph APIで部署、役職、アカウント状態を取得してコメント化 | 低 |
| SOC通知 | 条件に合うアラートをTeamsやメールで通知 | 低 |
| チケット起票 | ServiceNowなどに調査チケットを作成 | 中 |
| ユーザー無効化 | 条件を満たすアカウントを一時停止 | 高 |
| クラウド権限変更 | IAMユーザーやロールを変更 | 高 |
| ネットワークブロック | IPやドメインをセキュリティ機器に登録 | 高 |
Microsoftの例でも、URLエンティティをVirusTotalでエンリッチしてインシデントにコメントする、AWS IAMユーザーをブロックして担当者を割り当てる、といったプロンプト例が示されています。これらは有用ですが、ブロックや無効化を含む処理は誤検知時の影響が大きいため、最初は通知やコメントにとどめ、運用実績を見てから強いアクションを追加するのが安全です。(Microsoft Learn)
データ共有とリージョン設定も事前に確認する
AI生成プレイブックはSecurity Copilotの要件と関係するため、データ共有、評価リージョン、プライバシー設定も無視できません。公式手順では、AI生成プレイブック向けに専用のSecurity Copilotワークスペースを用意し、米国または欧州のgeo、またはクロスリージョン評価を許可する構成が推奨されています。また、製品性能の検証やAIモデルの構築・検証に関するデータ取得設定についても言及されています。(Microsoft Learn)
日本企業では、セキュリティログ、インシデント情報、ユーザー情報、外部APIへの送信データが社内規程や顧客契約に関わることがあります。管理者だけで判断せず、必要に応じて情報セキュリティ部門、法務、プライバシー担当、クラウドガバナンス担当と確認してください。
特に次の情報は、プロンプトやコメントに不用意に含めない方が安全です。
| 避けたい情報 | 理由 |
|---|---|
| クライアントシークレット、APIキー | 漏えい時に外部APIやGraph APIへ不正アクセスされる |
| 個人情報を含む詳細ログ | データ共有・保管ポリシーの対象になる可能性がある |
| 顧客名、案件名、内部プロジェクト名 | 外部サービス連携や監査時の取り扱いが複雑になる |
| 未公開のインシデント詳細 | 社外共有や生成AI利用ポリシーに抵触する可能性がある |
失敗しやすいポイントと対策
AI生成プレイブックの導入で失敗しやすいのは、機能そのものよりも運用設計です。以下のようなケースは特に注意してください。
| 失敗パターン | 起きる問題 | 対策 |
|---|---|---|
| 権限付与直後に使えない | ロール反映待ちを障害と誤認する | 最大2時間程度の反映待ちを見込む |
| 統合プロファイルを後から直せると思っている | API URLや認証方式を変更できず作り直しになる | 環境別に設計してから作成する |
| プロンプトが曖昧 | 想定外の条件やアクションを含むプレイブックが生成される | 入力、条件、出力、禁止事項を明記する |
| 保存しただけで動くと思う | プレイブックが無効状態のままで実行されない | Active PlaybooksでActivateする |
| 条件を広くしすぎる | 多数のアラートで自動処理が走る | 重大度、分析ルール名、プロバイダー、ワークスペースで絞る |
| 既存ルールの移行を軽視する | Defenderポータル移行後に自動化が動かない | 既存Automation RuleとAPI連携を棚卸しする |
| Health Tableだけを見ている | 実行結果を見逃す | インシデントのActivitiesタブで確認する |
| 強いアクションから始める | 誤検知時に業務影響が出る | コメント、通知、チケット起票から始める |
管理者が次に取るべき行動
Microsoft DefenderのAI/Copilot更新として提供されるMicrosoft SentinelのAI生成プレイブックは、SOC自動化の初期設計と実装を大きく短縮できる機能です。一方で、既存のLogic Appsベースのプレイブックを一夜で置き換えるものではなく、Defenderポータルへの移行、Security Copilot要件、統合プロファイル、権限、Enhanced Alert Trigger、生成コードレビューを含めて設計する必要があります。
まずは、既存プレイブックとAutomation Ruleを棚卸しし、Defenderポータル移行で影響を受ける条件やAPI連携を確認してください。そのうえで、検証用ワークスペースまたは限定されたアラート条件を使い、URL評価、コメント追加、SOC通知のような低リスクのAI生成プレイブックから試すのが安全です。
本番展開前には、生成コードをレビューし、実アラートでテストし、トリガー条件を絞り、無効化・ロールバック手順を用意します。AIで作成速度は上がりますが、最終的な品質を決めるのは、権限設計、テスト、監視、変更管理です。ここを押さえれば、Microsoft Defenderポータル内でのSentinel自動化を、より速く、より管理しやすい形で展開できます。
コメント