2026年7月10日にMicrosoft 365 Roadmapへ追加された「Microsoft Purview Insider Risk Management adds Triage Agent summaries to Microsoft Defender alerts」は、Insider Risk ManagementのTriage Agentが生成した要約を、Microsoft Defenderのアラートキューから確認できるようにする更新です。
結論として、新しい検知ルールや自動防御が追加される更新ではありません。Microsoft Purviewへ画面を切り替えなくても、SOC担当者がアラートの重要度やリスクの背景を一次判断しやすくなる、調査ワークフローの改善です。
対応を優先すべきなのは、Insider Risk ManagementのアラートをMicrosoft Defender XDRへ共有し、Triage Agentを利用中、または導入予定の組織です。該当する場合は、2026年8月のプレビュー開始前に、データ共有、閲覧権限、匿名化、Security Copilotの課金、運用手順を確認しておく必要があります。
2026年7月10日に公開されたロードマップの概要
Microsoft 365 Roadmapの項目ID「567472」では、Insider Risk Managementのアラートに対してTriage Agentが作成した要約を、Microsoft Defenderのアラートキューに表示すると説明されています。
| 項目 | 内容 |
|---|---|
| Roadmap ID | 567472 |
| 機能名 | Microsoft Purview: Insider Risk Management – DS Triage Agent for IRM available in Defender |
| ステータス | 開発中 |
| プレビュー予定 | 2026年8月 |
| 一般提供予定 | 2026年12月 |
| 対象クラウド | Worldwide（Standard Multi-Tenant） |
| 対象プラットフォーム | Web |
| 主な変更 | DefenderのIRMアラートにTriage Agentの要約を表示 |
現時点の対象タグにはGCC、GCC High、DoDが含まれていません。政府機関向けクラウドを利用している場合は、今回の予定をそのまま自組織へ適用せず、今後のロードマップ更新を確認してください。また、Microsoft 365 Roadmapの提供時期や内容は変更される可能性があります。(Microsoft)
Microsoft DefenderのIRMアラートで何が変わるのか
Insider Risk Managementのアラートは、データ共有を有効にしている環境では、すでにMicrosoft Defender XDRのアラートキューやインシデントキューへ表示できます。
これまでもSOC担当者は、次の操作をMicrosoft Defenderから実行できました。
- Insider Risk Managementアラートの確認
- DLP、Defender for Identity、Defender for Office 365などのアラートとの関連付け
- ユーザーのインサイダーリスク重大度の確認
- Advanced Huntingによる関連イベントの調査
- Microsoft Graph Security APIによるアラートデータの取得
今回の更新では、そこへTriage Agentの分析結果が追加されます。ロードマップでは、Defenderのアラートキューに次の情報が表示される予定です。
- エージェントによるカテゴリ判定
- 調査内容の要約
- 検出されたリスクパターン
- 関連するユーザー情報
より詳細なアクティビティ、ファイル、リスク要因、ユーザー履歴の調査は、引き続きMicrosoft Purviewポータルで行います。(Microsoft)
更新前後の違い
| 確認項目 | 更新前 | 更新後 |
|---|---|---|
| IRMアラートの存在 | Defenderで確認可能 | 変更なし |
| 他製品のアラートとの関連付け | Defenderのインシデントで確認可能 | 変更なし |
| ユーザーのリスク重大度 | Defenderで確認可能 | 変更なし |
| Triage Agentのカテゴリ判定 | 主にPurviewで確認 | Defenderアラートから確認可能 |
| リスクパターンの要約 | 主にPurviewで確認 | Defenderアラートから一次確認可能 |
| 詳細なアクティビティ調査 | Purviewで実施 | 引き続きPurviewで実施 |
| 新しいブロック処理 | なし | ロードマップ上の追加記載なし |
つまり、Microsoft Defenderだけで調査が完結するのではなく、Defenderで優先順位を判断し、必要なアラートだけをPurviewで深掘りする運用へ移行しやすくなります。
保護対象は既存のInsider Risk Managementポリシーで決まる
今回の機能によって、新しいデータ保存場所やユーザーが自動的に保護対象へ追加されるわけではありません。
実際の対象は、組織が作成しているInsider Risk Managementポリシーと、そこで有効にしているインジケーターによって決まります。Insider Risk Managementは、Microsoft 365やMicrosoft Graphなどのシグナルを関連付け、知的財産の持ち出し、データ漏えい、セキュリティポリシー違反といった、悪意または誤操作による内部リスクを検出します。(Microsoft Learn)
今回のDefender表示の対象になるには、少なくとも次の条件が関係します。
- ユーザーがInsider Risk Managementポリシーの対象になっている
- ポリシーに基づくIRMアラートが生成されている
- Triage Agentが対象ポリシーのアラートを処理している
- Insider Risk ManagementからDefenderへのデータ共有が有効になっている
- 閲覧者がDefenderとPurviewの必要な権限を持っている
Triage Agentは、ユーザーリスク、アクティビティリスクなどを基にアラートを評価し、「Needs attention」または「Less urgent」などに分類します。現在のPurview側の仕様では、対象ユーザーに関連する直近最大30,000件のアクティビティイベントを分析し、アラートを生成したポリシーに含まれるイベントだけでなく、記録されているユーザーアクティビティ全体を評価します。(Microsoft Learn)
このため、Triage Agentの要約には、アラート単体を確認しただけでは分からない行動の連続性や、別ポリシーで検出されたリスクが反映されることがあります。
管理者が確認すべき設定
DefenderにTriage Agentの要約を表示するには、単にロードマップ機能の展開を待つだけでは不十分です。現在の構成を次の順番で確認してください。
| 確認項目 | 必要な状態 | 未設定の場合の影響 |
|---|---|---|
| Microsoft 365監査 | 監査ログが有効 | IRMポリシーが必要なアクティビティを検出できない |
| IRMポリシー | 対象ユーザー、トリガー、インジケーターを設定 | アラート自体が生成されない |
| Defenderへのデータ共有 | IRMのデータ共有設定を有効化 | DefenderにIRMアラートやユーザーリスク情報が表示されない |
| Security Copilot | テナントをオンボード | Triage Agentが動作しない |
| Microsoft 365データ共有 | Security Copilot側で有効化 | エージェントがMicrosoft 365データを利用できない |
| Microsoft Purviewプラグイン | Security Copilotで有効化 | IRMデータをエージェントが参照できない |
| SCU | 利用可能なSecurity Compute Unitを用意 | エージェントが処理を実行できない |
| Triage Agent | 対象ポリシー、期間、実行方法を設定 | アラート要約が生成されない |
| RBAC | DefenderとPurviewの両方で付与 | アラートまたは要約を閲覧できない |
Defenderへのデータ共有を確認する
Microsoft Purviewポータルで、次の設定を確認します。
- Microsoft Purviewポータルを開く
- 「設定」を選択する
- 「Insider Risk Management」を開く
- 「データ共有」を選択する
- 他のMicrosoftセキュリティソリューションとの共有を有効にする
この設定を有効にすると、IRMアラートをDefenderのアラートキューで確認できるほか、他の検知ソースと関連付けたインシデント調査や、Advanced Huntingを利用できるようになります。(Microsoft Learn)
データ共有を有効にすることは、IRMが持つユーザーリスク情報をSOC担当者のワークスペースへ広げることでもあります。技術設定だけでなく、社内のプライバシーポリシーや内部調査規程との整合も確認してください。
Triage Agentのライセンスと課金を確認する
Insider Risk ManagementのTriage Agentには、Insider Risk Managementを利用できるライセンスに加え、標準のユーザー単位ライセンスと従量課金モデルが必要です。
エージェントの処理ではSecurity Compute Unitが消費されます。消費量は処理するアラートの件数や種類によって変わるため、Security Copilotの使用状況監視機能で定期的に確認します。(Microsoft Learn)
プレビュー検証では、最初からすべてのIRMポリシーを対象にするのではなく、退職予定者や高重要度ユーザーなど、優先度の高いポリシーに限定する方が安全です。要約の有用性とSCU消費量を確認してから対象を広げると、予期しないコストを避けやすくなります。
エージェントの対象ポリシーと実行方法を決める
Triage Agentでは、主に次の項目を設定できます。
- 自動実行またはアラート単位の手動実行
- 分析対象とするアラート期間
- 対象とするIRMポリシー
- 組織固有の優先事項を伝えるカスタム指示
自動実行のスケジュールはMicrosoft側で設定され、組織が任意の時刻へ変更する方式ではありません。初回検証では手動実行を使い、1件ずつPurviewの詳細情報と照合すると、要約の精度や判断基準を評価しやすくなります。(Microsoft Learn)
また、同じ種類のエージェントは1テナントにつき1インスタンスです。部門ごとに独立したエージェントを複数展開する前提では運用設計できません。
90日ごとの認証更新を運用に組み込む
Triage Agentは、最後にエージェント設定を保存したユーザーのセキュリティコンテキストで実行されます。この認証は90日で期限切れになり、設定を再保存するまでエージェントが停止します。(Microsoft Learn)
次のような管理方法が必要です。
- 設定保存に使用するアカウントを明確にする
- 担当者の異動や退職に依存しない運用にする
- 90日より短い間隔で更新確認を行う
- エージェント停止を検知する定期点検を設ける
- 認証更新日を運用カレンダーへ登録する
Defenderに要約が表示されなくなった場合、ロールアウト障害だけでなく、この90日認証の期限切れも確認してください。
DefenderとPurviewの権限を両方確認する
Microsoft DefenderでIRMアラートを閲覧するには、Defender側の権限だけでは足りません。
既存の公式ドキュメントでは、少なくとも次の組み合わせが必要です。
- Microsoft Defender XDR側：Security ReaderまたはSecurity Operator
- Microsoft Purview側：Insider Risk Management、Insider Risk Management Analysts、Insider Risk Management Investigatorsのいずれか
Triage Agentの構成や要約閲覧には、Purview Agent関連ロールやSecurity Copilot Contributorなど、追加の権限が必要になる場合があります。プレビュー開始後は、グローバル管理者で確認して終わらせず、実際にSOC担当者へ割り当てる最小権限のテストアカウントで確認してください。(Microsoft Learn)
匿名化とユーザー情報の表示は特に注意が必要
Insider Risk Managementは、ユーザー名を仮名化して表示するプライバシー設定を備えています。
一方、現在の公式ドキュメントでは、匿名化設定を有効にしていても、Triage Agentダッシュボードの優先アラートではユーザー名が匿名化されないと説明されています。今回のロードマップでも、Defenderへ表示する要約に「関連するユーザー情報」が含まれる予定です。(Microsoft Learn)
Defender側で具体的にどのユーザー属性まで表示されるかは、プレビュー環境で次の観点から確認する必要があります。
- ユーザー名やUPNが表示されるか
- 部署、役職、最終勤務日などが表示されるか
- Security ReaderとSecurity Operatorで表示範囲が異なるか
- アラートのエクスポートやチケット連携に個人情報が含まれるか
- Purviewで匿名化したユーザーがDefender側で特定可能にならないか
内部リスク情報は、人事情報や退職予定、行動履歴と結び付く可能性があります。SOC全員へ一律に閲覧権限を付けるのではなく、インサイダーリスク調査を担当するメンバーへ限定することが重要です。
管理単位を使っている組織はDefender側のスコープを検証する
Microsoft Purviewでは、Microsoft Entraの管理単位を使い、地域や部門ごとにIRMポリシー、アラート、ケースの閲覧範囲を制限できます。
ただし、公式ドキュメントでは、Microsoft Defender XDRの管理単位サポートはDLP向けであり、Insider Risk Managementには対応していないとされています。(Microsoft Learn)
そのため、Purviewで「日本部門だけを閲覧できる調査担当者」を設定していても、Defender側でも同じスコープ分離になると決めつけてはいけません。
地域別・子会社別に調査権限を分離している組織では、次をプレビュー前の必須テストにしてください。
- 管理単位付きの制限管理者を用意する
- Purviewで閲覧できるアラートを確認する
- 同じアカウントでDefenderのIRMアラートを確認する
- スコープ外ユーザーの情報が表示されないか確認する
- 想定外の表示がある場合はDefenderでの利用範囲を制限する
監査ログと検知への影響
検知シグナルやリスクスコアの仕組みは基本的に変わらない
Insider Risk Managementは、Microsoft 365監査ログなどのアクティビティをポリシーで評価し、条件を満たした場合にアラートを生成します。
今回のロードマップには、新しい監査イベント、リスクインジケーター、検知ポリシー、自動ブロック処理の追加は記載されていません。したがって、現時点では検知範囲の拡張ではなく、既存アラートの分析結果をDefenderへ表示する変更と考えるのが適切です。(Microsoft)
Triage Agentのカテゴリ判定と、IRMアラートの重大度は別の値です。
- Triage Agentのカテゴリ：Needs attention、Less urgentなど
- IRMアラートの重大度：High、Medium、Low
- Defenderの分類：True positive、Informational、False positiveなど
「Needs attention」と判定されたからといって、直ちにインシデントをTrue positiveとして確定してはいけません。エージェントの要約は調査対象を絞り込む材料であり、最終判断は担当者が証拠を確認して行います。
Defenderでの操作はPurviewへ同期される
IRMアラートのステータス、重大度、分類などは、PurviewとDefenderの間で同期されます。公式ドキュメントでは、アラートの生成または更新から30分以内に反映されると説明されています。(Microsoft Learn)
主な対応関係は次のとおりです。
| Defenderでの操作 | Purview側の扱い |
|---|---|
| New | Needs review |
| In progress | Needs review |
| True positiveとして解決 | Confirmed |
| Informationalとして解決 | Dismissed |
| False positiveとして解決 | Dismissed |
| 分類せずに解決 | Dismissedになる場合がある |
Defenderで要約を確認できるようになると、SOC担当者がそのままアラートを解決する場面が増えると考えられます。既存のSOAR、自動化ルール、ServiceNow連携が、Purview側のステータス変更によって影響を受けないか確認してください。
アラートのメモは同期されない
アラートのステータスなどは同期されますが、Insider Risk Managementで追加したアラートメモはMicrosoft Defenderへ同期されません。(Microsoft Learn)
調査記録をPurviewとDefenderの両方へ分散させると、判断根拠が追えなくなる可能性があります。次のいずれかを運用ルールとして決めておく必要があります。
- 詳細な調査記録はPurviewへ集約する
- SOCの記録はチケット管理システムへ集約する
- Defenderには対応状況だけを残す
- Purviewケースへの参照情報をチケットへ記録する
Triage Agentの管理操作は監査対象になる
Microsoft Security Copilotでは、エージェントやトリガーの作成、変更、削除などの管理操作がMicrosoft Purviewの統合監査ログへ記録されます。ユーザー操作のメタデータも監査対象です。
一方、プロンプトと応答の具体的な内容は、統合監査ログだけでなくDSPM for AI側の構成が関係します。要約本文そのものを監査証跡として保存したい場合は、統合監査ログだけで要件を満たせると判断せず、プレビュー環境で記録内容を確認してください。(Microsoft Learn)
APIやAdvanced Huntingへの要約追加は未確認
既存のIRMアラートやイベントは、Microsoft Graph Security APIやAdvanced HuntingのDataSecurityBehaviors、DataSecurityEventsなどから取得できます。
しかし、2026年7月10日時点のロードマップには、Triage Agentの要約フィールドをAPIやAdvanced Huntingへ追加するとの記載はありません。現段階では、Defenderの画面に表示された要約が、そのままAPIから取得できると想定しない方が安全です。(Microsoft)
要約をチケットへ自動転記する仕組みを検討する場合は、正式なMicrosoft GraphスキーマやAdvanced Huntingスキーマが公開されてから実装してください。
対応要否を環境別に判断する
| 現在の利用状況 | 対応優先度 | 推奨対応 |
|---|---|---|
| Insider Risk Managementを利用していない | 低 | 現時点で変更不要。導入計画がある場合のみロードマップを監視 |
| IRMを利用しているがDefenderへ共有していない | 中 | SOCへ共有する必要性とプライバシー影響を判断 |
| IRMアラートをDefenderへ共有しているがTriage Agentは未使用 | 中～高 | Security Copilot、SCU、ライセンス、導入効果を評価 |
| IRMとTriage Agentを利用し、Defender共有も有効 | 高 | RBAC、匿名化、管理単位、ステータス同期を優先確認 |
| 地域・子会社ごとに管理単位で権限分離している | 最優先 | Defender側でスコープ外情報が見えないか実機検証 |
| 人事・退職・医療など機微情報を扱うポリシーがある | 最優先 | 労務、法務、プライバシー担当を含めて表示範囲を承認 |
| GCC、GCC High、DoDを利用している | 監視 | 現在のロードマップ対象外。追加発表を待つ |
プレビュー前から一般提供までの推奨手順
2026年8月のプレビュー前
- IRMポリシーと対象ユーザーを一覧化する
- Defenderへのデータ共有状態を確認する
- Triage Agentの導入状態と対象ポリシーを確認する
- Security CopilotとSCUの契約・消費量を確認する
- DefenderとPurviewのロール割り当てを棚卸しする
- 匿名化と管理単位の要件を整理する
- 検証対象とするポリシーを1～2個に絞る
プレビュー開始後
- 手動実行で少数のアラートを処理する
- Defenderの要約とPurviewの詳細を比較する
- Needs attentionとLess urgentの判断精度を記録する
- ユーザー情報の表示範囲をロール別に確認する
- Defenderでステータスを変更し、Purviewへの同期を確認する
- アラートメモが同期されない前提で記録手順をテストする
- SCU消費量と調査時間の短縮効果を測定する
- 統合監査ログでエージェント操作を確認する
2026年12月の一般提供前
- 本番対象ポリシーを決定する
- SOC向けの判断基準を文書化する
- エージェントの判定だけで解決しないルールを設ける
- 90日ごとの認証更新担当者を決める
- API・チケット連携の対応状況を再確認する
- プライバシー担当者の承認を得る
- 調査記録を残すシステムを一本化する
なお、Purview側でもTriage Agentと従来のアラート画面を統合した新しいAlertsエクスペリエンスへの移行が進んでおり、公式ドキュメントでは2026年8月31日以降、新しい統合画面のみをサポートする予定です。古い画面のスクリーンショットや「Alert Spotlight」を前提にした手順書は、この機会に更新してください。(Microsoft Learn)
導入時に失敗しやすいポイント
Triage Agentを有効にすれば自動的にDefenderへ表示されると思う
Triage Agentの導入だけでなく、IRMからDefenderへのデータ共有、Security Copilotの設定、SCU、閲覧ロールが必要です。どれか一つが欠けると、要約が生成されても担当者が確認できない可能性があります。
Needs attentionを重大度Highと同じ意味で扱う
エージェントのカテゴリ判定、IRMの重大度、Defenderの分類は別の軸です。自動化ルールを作る場合は、どのフィールドを条件にしているか明確にしてください。
要約だけでアラートを解決する
要約には誤りや情報不足が含まれる可能性があります。ファイル、対象データ、時系列、端末、IPアドレスなどの根拠は、PurviewのActivity explorerや詳細画面で確認します。
匿名化設定がDefenderでも完全に維持されると思う
Triage Agentでは、匿名化設定を有効にしていてもユーザー名が表示される場面があります。Defenderへ要約が広がることで、従来より多くのSOC担当者がユーザー情報へアクセスできる可能性を考慮してください。
Purviewの管理単位がDefenderにも適用されると思う
Defender XDRはIRMの管理単位をサポートしていません。部門や地域で権限を分けている環境では、プレビューでの権限検証を省略できません。
90日認証を忘れる
エージェントが突然アラートを処理しなくなり、Defenderに新しい要約が表示されなくなる原因になります。認証更新を定期作業として管理してください。
要約をAPIから取得できる前提で自動化を進める
現在のロードマップでは、Defenderのアラートキューへの表示のみが明記されています。Graph APIやAdvanced Huntingの正式なフィールドが公開されるまでは、画面表示を前提としたプレビュー検証に留めるのが安全です。
まず確認すべきこと
今回の更新に対して最初に行うべきことは、自社環境が次のどこまで利用しているかを確認することです。
- Insider Risk Managementを利用しているか
- IRMアラートをMicrosoft Defenderへ共有しているか
- Triage Agentを有効にしているか
- Security CopilotとSCUを利用できるか
- DefenderでIRMアラートを見る担当者が誰か
- ユーザー名や人事情報をどこまで表示してよいか
すべて該当する組織では、機能展開を待つのではなく、権限とプライバシーの確認を優先してください。
一方、Insider Risk ManagementやTriage Agentを利用していない組織に、緊急の設定変更は必要ありません。将来的に導入する場合は、Defenderへの情報集約による調査時間の短縮と、ユーザー情報の閲覧範囲拡大をセットで評価することが重要です。
この更新の価値は、アラートを増やすことではなく、既存の内部リスクアラートをSOCが短時間で理解できるようにする点にあります。2026年8月のプレビューでは少数のポリシーから検証し、要約の精度、調査時間、SCU消費、権限分離を確認したうえで、2026年12月の一般提供へ備えるのが現実的です。
コメント