Microsoft Defender の「Microsoft Security Copilot Security Alert Triage Agent in Microsoft Defender」は、SOC のアラート一次判定を AI エージェントで自動化するプレビュー機能です。2026年7月1日更新の公式情報で特に確認したいポイントは、メール関連アラートで使う権限がより限定的な「アラートに関連付けられたメールの読み取り」に変わり、最小特権で運用しやすくなったことです。既存の Phishing Triage Agent 利用者は新しいエージェントを入れ直す必要はなく、前提条件を満たしたうえで対象アラートを追加していく考え方になります。(Microsoft Learn)
ただし、これは「すべての Defender アラートを AI が自動解決してくれる機能」ではありません。対象アラート、ライセンス、統合 RBAC、Security Copilot の SCU、エージェント ID、既存のアラートチューニングルールを確認してから段階的に有効化する必要があります。特にグローバル環境では、プレビュー提供状況、データアクセス権限、監査ログ、SCU 消費量、既存 SOAR 運用との役割分担を事前に整理しておくことが重要です。
Microsoft Defender の Security Alert Triage Agent とは
Security Alert Triage Agent は、Microsoft Defender XDR に組み込まれる Microsoft Security Copilot の自律型エージェントです。対応しているアラートを AI が分析し、悪意のある可能性が高いものを True Positive、誤検知と判断したものを False Positive として分類し、Microsoft Defender のインシデント内に判定理由を記録します。アナリストは、エージェントの結論だけでなく、判断に使われた証拠や意思決定の流れを確認できます。(Microsoft Learn)
重要なのは、このエージェントが従来の Phishing Triage Agent と同じエージェントを拡張した位置づけである点です。メールとコラボレーション領域のフィッシングトリアージは一般提供済みですが、クラウドアラートや ID アラートへの拡張はプレビューとして提供されています。対象範囲は今後増える可能性がありますが、現時点ではサポートされるアラートタイプに限定されます。(Microsoft Learn)
2026年7月1日更新情報で押さえるべき変更点
2026年7月1日に更新された Microsoft Defender XDR の公式「新機能」情報では、Phishing Triage Agent と Security Alert Triage Agent が、従来より広い「すべてのメールを読む」権限ではなく、「アラートに関連付けられたメールのみを読む」権限を使うようになったことが示されています。これはセキュリティ運用上かなり大きな変更です。AI エージェントの利便性を高めながら、メール本文への過剰なアクセスを避けやすくなるためです。(Microsoft Learn)
| 確認項目 | 更新・変更の内容 | 管理者が見るべきポイント |
|---|---|---|
| メール権限 | 「Email & collaboration content: Emails associated with alerts (read)」を使用 | 既存ロールが広すぎる権限を持っていないか確認する |
| 対象エージェント | Phishing Triage Agent と Security Alert Triage Agent | 既存のフィッシングトリアージ運用にも影響する |
| セキュリティ効果 | アラートに関連するメールだけへアクセスを絞る | 最小特権、監査、データ保護の観点で再評価する |
| 既存環境 | 既存設定をそのまま放置しない | カスタムロール、運用手順書、監査説明資料を更新する |
| プレビュー範囲 | クラウド、ID アラートはプレビュー | 本番全面展開ではなく段階導入が現実的 |
この変更は「機能が増えた」というより、「AI エージェントを運用に組み込む際の権限設計が現実的になった」と見るべきです。特に金融、医療、公共、グローバル企業のようにメール本文アクセスの説明責任が重い組織では、導入判断のハードルを下げる材料になります。
影響範囲：誰が何を確認すべきか
Security Alert Triage Agent の影響は、SOC だけに閉じません。Microsoft Defender、Microsoft Security Copilot、Microsoft Entra ID、Defender for Office 365、Defender for Cloud、Defender for Identity、Defender for Cloud Apps など複数の管理領域にまたがります。
| 担当者 | 主な影響 | 具体的な確認ポイント |
|---|---|---|
| SOC アナリスト | アラートの一次判定が自動化される | True Positive / False Positive の妥当性、エージェントの理由説明 |
| セキュリティ管理者 | エージェント設定、停止、削除、ID 管理が必要 | Microsoft Entra ID の Security Administrator 権限 |
| Microsoft 365 管理者 | ユーザー報告メール、Defender for Office 365 の設定が関係 | Outlook の報告メッセージ設定、アラートポリシー |
| クラウド管理者 | Defender for Cloud / Containers のアラートが対象 | コンテナー関連検出の有効化状況 |
| ID 管理者 | Defender for Identity、Cloud Apps、Entra ID P2 が関係 | 統合 RBAC、ID アラートの対象範囲 |
| コンプライアンス担当 | AI エージェントのデータアクセスと監査が論点になる | 最小権限、監査ログ、フィードバック履歴 |
| SIEM / SOAR 担当 | 既存ワークフローとの重複が起きる | 自動クローズ、チケット連携、KQL クエリの見直し |
特に注意したいのは、Security Alert Triage Agent がアラートの分類や状態更新を行う点です。誤検知と判断されたアラートは False Positive として分類され、状況に応じて解決されます。一方、悪意があると判断されたものは True Positive として分類され、インシデントは調査継続の状態で残ります。(Microsoft Learn)
対象アラート：すべてのアラートが対象ではない
Security Alert Triage Agent は、Microsoft Defender XDR の全アラートを対象にするわけではありません。公式情報では、メールとコラボレーション、クラウド、ID の一部アラートが対象として整理されています。(Microsoft Learn)
| 領域 | 提供状況 | 主な対象例 | 実務上の見方 |
|---|---|---|---|
| メールとコラボレーション | 一般提供 | ユーザーがマルウェアまたはフィッシングとして報告したメール | 既存のフィッシング報告対応を効率化しやすい |
| クラウド、コンテナー | プレビュー | コンテナー内の疑わしいコマンド、暗号資産マイニング、Web シェル、Kubernetes 関連検出など | クラウド SOC のノイズ削減に有効だが対象検出を確認する |
| ID | プレビュー | パスワードスプレー、BEC 関連の受信トレイルール、パスワードスプレー後の侵害アカウント | ID セキュリティ運用と連携して評価する |
導入時は、「自社で多いアラート」と「エージェントが対応するアラート」が一致しているかを最初に確認してください。たとえば、エンドポイントのマルウェア検出やカスタム検出ルールのアラートが大量にある環境でも、それらがサポート対象に含まれていなければ、期待した削減効果は出ません。
前提条件：ライセンス、SCU、統合 RBAC を先に確認する
Security Alert Triage Agent を使うには、Security Copilot の SCU 容量、必要なプラグイン、統合 RBAC、対象ワークロードごとのライセンスが必要です。エージェントは Microsoft Defender XDR、Microsoft Threat Intelligence、Security Alert Triage Agent の各プラグインを自動的に有効化しますが、アラート種別に応じた製品・権限の準備は管理者側で必要です。(Microsoft Learn)
| 領域 | 必要なもの | 確認すべき設定 |
|---|---|---|
| 共通 | Security Copilot の SCU、統合 RBAC、対象アラートを解決しないチューニング設計 | SCU の確保、統合 RBAC の有効化、既存チューニングルールの棚卸し |
| メールとコラボレーション | Microsoft Defender for Office 365 Plan 2 | Defender for Office 365 の統合 RBAC 有効化、Outlook の報告メッセージ監視、対応アラートポリシー |
| クラウド | Microsoft Defender for Cloud、Microsoft Defender for Containers | Defender for Cloud 側の保護対象とアラート発生状況 |
| ID | Entra ID P2、Microsoft Defender for Identity、Microsoft Defender for Cloud Apps | Defender for Identity と Defender for Cloud Apps の統合 RBAC 有効化 |
メール領域では、ユーザーが Outlook から報告したメッセージを Defender 側で扱えるようにしておく必要があります。サードパーティのメール報告ツールを使っている場合は、その報告が Microsoft Defender と統合される構成になっているかも確認が必要です。(Microsoft Learn)
設定変更で最初に見るべきポイント
Security Alert Triage Agent のセットアップは、Microsoft Defender ポータルのインシデントキューから「Set up agent」を選ぶ方法と、Security Store から設定する方法があります。プレビュー対象外のテナントでは Security Alert Triage Agent ではなく Phishing Triage Agent として表示される場合がありますが、公式情報では同じエージェントであると説明されています。(Microsoft Learn)
エージェント ID は新規作成が基本
セットアップ時には、エージェントに ID を割り当てます。公式情報では、新しい Microsoft Entra Agent ID の作成が推奨されています。既存ユーザーアカウントを接続することもできますが、その場合はアカウントの認証期限や条件付きアクセス、権限継承を慎重に管理しなければなりません。長期バックグラウンド操作の性質上、PIM や TAP とは互換性がない点も注意が必要です。(Microsoft Learn)
実務では、次のように整理すると安全です。
| 判断項目 | 推奨される考え方 |
|---|---|
| ID の種類 | 可能なら新しい Agent ID を作成する |
| 表示名 | 「Security Alert Triage Agent」など、監査で識別しやすい名前にする |
| 権限 | 対象アラートに必要な最小権限だけを付与する |
| 監視者 | エージェントと同等以上の権限を持つユーザーグループを用意する |
| 条件付きアクセス | Security Copilot の動作を妨げないポリシーにする |
| 既存ユーザー利用 | 認証期限切れ、退職、権限変更で停止しないよう管理する |
権限は対象アラートごとに違う
Security Alert Triage Agent には、対象アラートに応じた権限が必要です。特に今回の更新で注目すべきなのは、メールとコラボレーションアラートに必要なメール本文アクセスが「アラートに関連付けられたメール」に限定される点です。(Microsoft Learn)
| アラート種別 | 必要な主な権限 | データスコープ |
|---|---|---|
| メールとコラボレーション | Security Copilot 読み取り、セキュリティデータ基本情報読み取り、アラート管理、メール/コラボレーションメタデータ読み取り、アラートに関連付けられたメール読み取り | Microsoft Defender for Office 365 |
| クラウド、コンテナー | Security Copilot 読み取り、セキュリティデータ基本情報読み取り、アラート管理 | Microsoft Defender for Cloud |
| ID | Security Copilot 読み取り、セキュリティデータ基本情報読み取り、アラート管理 | Microsoft Defender for Identity、Microsoft Defender for Cloud Apps |
既存のカスタムロールで「すべてのメール読み取り」に相当する広い権限を付けている場合は、今回の更新を機に見直してください。最小権限へ寄せることで、AI エージェント導入時の内部説明や監査対応がしやすくなります。
既存のアラートチューニングルールに注意する
Security Alert Triage Agent は、すでに解決済みのアラートをトリアージしません。そのため、対象アラートを自動解決するチューニングルールがあると、エージェントが分析する前にアラートが処理されてしまう可能性があります。公式情報では、メール領域について「Auto-Resolve – Email reported by user as malware or phish」の組み込みチューニングルールや、同じアラートを解決するカスタムチューニングルールを無効にするよう案内されています。(Microsoft Learn)
導入前には、次の順番で確認すると失敗を避けやすくなります。
| 手順 | 確認内容 | 失敗しやすい例 |
|---|---|---|
| 1 | 対象にしたいアラート名を洗い出す | 「フィッシング全般」と曖昧にして対象外アラートまで期待する |
| 2 | 既存のチューニングルールを確認する | 先に自動解決され、エージェントが動かない |
| 3 | 対応アラートポリシーを有効化する | ユーザー報告メールのアラートが発生しない |
| 4 | エージェント ID の権限を確認する | メール本文、メタデータ、アラート管理権限が不足する |
| 5 | 監視者側の権限を確認する | エージェントの結果を見られず検証できない |
フィードバック機能はメール領域のみと考える
Security Alert Triage Agent には、アナリストが分類結果にフィードバックを与え、将来の類似アラート判定に反映できる仕組みがあります。ただし、公式情報では、このフィードバックによる学習機能は現在、メールとコラボレーションアラートに限定されています。クラウドや ID アラートでも同じように学習できると考えて運用設計すると、期待と実際の機能にズレが出ます。(Microsoft Learn)
また、分類変更時に理由を入力しただけでは、エージェントの判断には反映されません。エージェントに教えるには、フィードバックを使って学習させる操作を明示的に選び、生成されたレッスン内容を確認して保存する必要があります。フィードバックは監査用に残すだけの使い方もできます。(Microsoft Learn)
良いフィードバックと悪いフィードバックの違い
| 目的 | 良いフィードバック | 避けたいフィードバック |
|---|---|---|
| 送信元ドメインを判断材料にする | 「福利厚生に関するメールは @benefits.example.com から送信された場合のみ正当」 | 「この送信者は怪しい」 |
| 本文の特徴を伝える | 「認証確認を求めるメールは対象サービス名とアカウント名が本文に明記されていない場合、フィッシングとして扱う」 | 「アカウント確認メールは危険」 |
| 件名を条件にする | 「請求取引の承認を求める件名で、社内承認番号がないものは不審」 | 「ポジティブな件名なら安全」 |
| 受信者条件を使う | 「契約社員オンボーディング通知は v- で始まるメールアドレス宛のみ正当」 | 「いつもと違う受信者なら危険」 |
AI エージェントへのフィードバックは、社内ルールをそのまま自然文で書けばよいわけではありません。判定に使える具体的な条件として書く必要があります。曖昧な表現や広すぎる一般化は、True Positive の過剰判定や不安定な分類につながります。
監視と運用：有効化後に見るべきメトリック
Security Alert Triage Agent は、有効化して終わりではありません。Microsoft Defender ポータルの Security Copilot > Agents からエージェントの状態、ID、ロール、最近のアクティビティ、パフォーマンスを確認できます。Performance タブでは、日次アクティビティ、平均トリアージ時間、SCU 消費量などを確認できます。(Microsoft Learn)
| メトリック | 見る理由 | 判断例 |
|---|---|---|
| Incidents addressed | エージェントが実際に処理した量を把握する | 想定より少ない場合、対象アラートやチューニングルールを確認 |
| MTTT | トリアージ時間短縮の効果を見る | 人手対応との差分を比較する |
| SCU consumption | Security Copilot の容量計画に使う | 対象アラート拡大前に消費傾向を把握する |
| True Positive / False Positive の傾向 | 分類品質を確認する | 誤判定が多い領域はフィードバックや対象範囲を見直す |
| フィードバック状態 | 学習に使われているか確認する | Conflict や Not in use が多い場合はルールの書き方を改善 |
| Agent タグ付きインシデント | エージェント処理中・処理済み案件を追跡する | SOC のレビューキューを作る |
SCU 消費は見落とされがちです。試験導入では、まず対象アラートを限定して有効化し、SCU 消費量と処理件数を確認してから、クラウドや ID へ段階的に広げるのが現実的です。
移行期限：エージェント本体と高度なハンティングを分けて考える
Security Alert Triage Agent 本体について、公式情報上は「特定日までに Phishing Triage Agent から別エージェントへ移行しなければならない」という形の期限は示されていません。既存の Phishing Triage Agent 利用者は新しいエージェントをインストールし直す必要はなく、既存のフィッシングトリアージ設定とフィードバックは自動的に引き継がれると説明されています。追加のアラートタイプを使う場合は、前提条件を確認したうえで、エージェント設定から対象アラートを有効にします。(Microsoft Learn)
一方で、AI エージェントの棚卸しやガバナンスを高度なハンティングで行っている場合は別です。Microsoft Defender XDR の公式新機能情報では、AIAgentsInfo テーブルが AgentsInfo テーブルへ移行中であり、AIAgentsInfo は 2026年7月1日までアクセス可能とされています。2026年7月1日以降も古いテーブル名を使う KQL クエリ、ダッシュボード、検出ルール、監査レポートが残っている場合は、AgentsInfo への切り替えを優先してください。(Microsoft Learn)
| 対象 | 期限・対応 | 管理者の対応 |
|---|---|---|
| Security Alert Triage Agent 本体 | 明確な移行期限は公式情報上確認されない | 既存 Phishing Triage Agent から設定を拡張する |
| メール権限 | 最小権限へ更新済みの扱い | カスタムロールや監査説明を見直す |
AIAgentsInfo テーブル | 2026年7月1日までアクセス可能 | AgentsInfo へ KQL クエリを更新する |
| クラウド / ID アラート | プレビュー | 本番全面展開ではなく段階導入する |
SOAR との違い：置き換えではなく一次判定の強化
Security Alert Triage Agent は、SOAR の代替ではありません。SOAR は、あらかじめ定義したルールやプレイブックに沿って処理を自動化する仕組みです。一方、Security Alert Triage Agent は、Microsoft Defender 内の証拠をもとに推論し、アラートの分類と理由説明を行うエージェントです。公式 FAQ でも、既存の調査・対応ツールを置き換えるものではないと説明されています。(Microsoft Learn)
実務では、次のように役割を分けると導入効果が出やすくなります。
| 領域 | Security Alert Triage Agent | SOAR / 既存プレイブック |
|---|---|---|
| 一次判定 | 得意。証拠をもとに True Positive / False Positive を分類 | ルールに合う場合のみ対応 |
| 説明性 | 判定理由やワークフローを Defender 内で確認 | プレイブックの実行履歴中心 |
| 封じ込め | 主目的ではない | 端末隔離、アカウント無効化、通知などを実行 |
| 例外処理 | フィードバックで一部改善可能 | 条件分岐や承認フローで制御 |
| 運用設計 | 対象アラート、権限、SCU、監視が重要 | 実行条件、承認、連携先が重要 |
おすすめは、Security Alert Triage Agent で「どのアラートを優先調査すべきか」を絞り込み、True Positive と判断されたインシデントを既存の SOAR やチケットシステムに渡す運用です。AI の判定をそのまま最終対応にせず、封じ込めや復旧は既存の承認フローに乗せる方が安全です。
導入判断：今すぐ有効化すべき環境、様子を見るべき環境
Security Alert Triage Agent は便利な機能ですが、すべての環境で即時有効化すべきとは限りません。次の表を目安に、導入タイミングを判断してください。
| 状況 | 判断 | 理由 |
|---|---|---|
| ユーザー報告フィッシングが多く、SOC の一次判定が逼迫している | 優先的に検証 | メール領域は一般提供済みで効果を確認しやすい |
| Security Copilot の SCU と Defender for Office 365 P2 が整っている | 小規模パイロットに向く | 前提条件を満たしやすい |
| コンテナーや ID アラートのノイズが多い | 限定的に検証 | クラウド / ID はプレビューのため対象アラートを絞る |
| 統合 RBAC が未整備 | 先に権限設計を整える | エージェントと監視者の権限不整合が起きやすい |
| メール本文アクセスに厳しい内部規程がある | セキュリティ・法務と確認後に導入 | 権限は最小化されたが、アラート関連メールへのアクセスは発生する |
| 既存 SOAR が自動クローズを多用している | 競合確認が必要 | エージェントが分析する前にアラートが解決される可能性がある |
| KQL で AI エージェント棚卸しをしている | すぐ確認 | AIAgentsInfo から AgentsInfo への移行確認が必要 |
最初から全領域で有効化するより、メール報告アラートだけで効果、誤判定、SCU 消費、レビュー負荷を測る方が安全です。その後、クラウドや ID の対象アラートを追加し、運用ルールを広げると失敗しにくくなります。
管理者向けチェックリスト
導入前後で確認すべき項目を、実務順に並べると次のようになります。
| タイミング | チェック項目 | 完了の目安 |
|---|---|---|
| 導入前 | Security Copilot の SCU が利用可能か | 容量と課金・割当を確認済み |
| 導入前 | 統合 RBAC が有効か | 対象ワークロードが有効化済み |
| 導入前 | 対象アラートがサポート範囲に含まれるか | メール、クラウド、ID のどれを対象にするか決定済み |
| 導入前 | 必要ライセンスがあるか | Defender for Office 365 P2、Defender for Cloud、Entra ID P2 などを確認済み |
| 導入前 | 自動解決チューニングルールが競合しないか | 対象アラートを先に解決するルールを停止・調整済み |
| 設定時 | エージェント ID をどう作るか | Agent ID または専用アカウントを決定済み |
| 設定時 | 最小権限ロールを割り当てたか | 対象アラートに必要な権限だけを付与済み |
| 設定時 | 監視者の権限が足りているか | エージェント結果を確認できるグループを設定済み |
| 運用開始後 | Agent タグ付きインシデントをレビューしているか | SOC の確認キューを作成済み |
| 運用開始後 | MTTT と SCU 消費を見ているか | パフォーマンス画面またはダッシュボードで定期確認 |
| 運用開始後 | フィードバックの品質を確認しているか | Conflict / Not in use をレビュー |
| 運用開始後 | KQL クエリのテーブル名を確認したか | AgentsInfo へ更新済み |
よくある失敗と回避策
エージェントを有効化したのに処理件数が増えない
対象アラートがサポート範囲に入っていない、または既存のアラートチューニングルールで先に解決されている可能性があります。まずは、対象にしたいアラート名と実際に Defender に発生しているアラート名を照合してください。
監視者がエージェントの結果を見られない
エージェントに権限を付けても、監視するユーザーグループの権限が不足していると、出力を確認できません。公式情報でも、エージェントを監視するユーザーグループにはエージェントと同等以上の権限を持たせる必要があるとされています。(Microsoft Learn)
フィードバックを入れたのに改善されない
分類変更理由を保存しただけでは、必ずしもエージェントの学習には使われません。フィードバックをエージェントに教える操作、評価、保存まで行ったか確認してください。また、フィードバック機能は現在メールとコラボレーション領域に限られるため、クラウドや ID アラートで同じ効果を期待しないことが重要です。(Microsoft Learn)
既存 SOAR と二重処理になる
SOAR 側で自動クローズ、チケット起票、通知をしている場合、Security Alert Triage Agent の分類結果と競合することがあります。導入前に「エージェントが分類する範囲」と「SOAR が対応する範囲」を分け、False Positive の自動解決をどこまで許容するか決めておきましょう。
まず実施すべき次のアクション
Security Alert Triage Agent の更新ポイントは、単なる新機能紹介ではなく、AI エージェントを Microsoft Defender の実運用に入れるための権限・監査・運用設計の見直しです。まずは次の順番で確認してください。
- Microsoft Defender XDR の対象アラートと自社のアラート量を照合する
- Security Copilot の SCU、対象ライセンス、統合 RBAC を確認する
- 既存のアラートチューニングルールと SOAR 処理を棚卸しする
- エージェント ID と最小権限ロールを設計する
- メール領域から小さく検証し、MTTT、SCU 消費、誤判定を測る
- 高度なハンティングで
AIAgentsInfoを使っている場合はAgentsInfoへ更新する
特に今回の最小権限化は、AI エージェント導入に慎重な組織でも検討しやすい材料です。一方で、プレビュー領域を含むため、対象範囲を広げすぎず、まずはメール報告アラートなど効果を測りやすい領域から始めるのが現実的です。
コメント