Microsoft PurviewのDLP運用で、Data Security Triage Agentの優先順位付けをもっと現場に合わせたい、監査ログ上の実行主体を整理したい、これまで未対応だったDLPアラートもトリアージしたい――そんな管理者に関係する更新です。
2026年5月15日（日本時間）に更新が確認されたMicrosoft 365 Roadmap ID 557552では、Microsoft Purview Data Loss Prevention向けのData Security Triage Agentに、メタデータ対応のカスタム指示、設定画面の統合、非コンテンツ条件アラートのサポート、Microsoft Entraで生成されるAgent Identityの利用が追加されています。公式ロードマップ上のステータスは「Launched」、対象はMicrosoft Purview、プラットフォームはWeb、クラウドはWorldwide（Standard Multi-Tenant）です。なお、Microsoft 365 Roadmapの情報は変更される可能性があるため、展開前には自社テナントのメッセージセンターやPurviewポータルでの表示も確認してください。(Microsoft)
結論として、すでにDLPトリアージエージェントを使っている組織は、まず「カスタム指示」「DLPポリシー範囲」「Microsoft Entra上のAgent Identity」「監査ログの見え方」「SCU消費量」を確認するのが優先です。特に、DLPアラートをSIEMやチケット管理ツールへ連携している場合は、エージェントの実行主体やトリアージ対象アラートの増加によって、既存のフィルターやレポート条件がずれる可能性があります。
Microsoft PurviewのData Security Triage Agentとは
Data Security Triage Agentは、Microsoft Purviewのデータセキュリティ領域でDLPアラートの調査を支援するエージェントです。リスクが高いアクティビティを識別し、優先順位付けされたアラートキューを提供します。組織が選択したパラメーターやリスク許容度に基づき、関連コンテンツや潜在的な意図を分析し、分類理由の説明も提示します。(Microsoft Learn)
DLPアラートの調査・管理はMicrosoft Defender XDRダッシュボードとMicrosoft Purviewポータルの両方で扱えますが、Microsoft LearnではDLPアラートの調査と管理にはMicrosoft Defender XDR、DLPポリシーの作成・編集にはMicrosoft Purviewポータルが推奨されています。運用設計では、この役割分担を前提にしておくと混乱を避けやすくなります。(Microsoft Learn)
今回の更新で変わる主なポイント
今回の「Microsoft Purview: Data Loss Prevention – Enhancements to Data Security Triage Agent」は、単なるUI改善ではありません。DLPアラートの優先順位付け、設定管理、監査、外部連携に影響する更新です。
| 変更点 | これまで | 今回の変更 | 管理者が見るべきポイント |
|---|---|---|---|
| メタデータ対応のカスタム指示 | 主にコンテンツ内容に関する指示を使っていた | ユーザーや期間など、メタデータに基づく指示にも対応 | 指示文が過度に狭い、または広すぎないか確認する |
| Agent設定の統合 | 展開構成とトリガーが別管理だった | 単一ビューで設定を変更しやすくなる | 変更権限、承認フロー、運用手順書を見直す |
| 非コンテンツ条件アラートのサポート | RecipientDomainIsなど、コンテンツ以外の条件で発生した一部アラートは未対応扱いだった | DLPの非コンテンツ条件アラートもトリアージ・分類対象になる | 対象アラート数、優先度分布、SCU消費量を再確認する |
| Agent Identity | 設定したユーザーのIDで実行される前提があった | Microsoft Entraで生成されるエージェント自身のIDで展開できる | 監査ログ、Entra上のID管理、SIEMの抽出条件を見直す |
メタデータ対応のカスタム指示で何ができるようになるか
今回の更新で最も実務上の効果が大きいのは、DLP向けカスタム指示がコンテンツ内容だけでなく、メタデータにも対応する点です。
従来の指示は、たとえば「財務情報に関するアラートを重視する」のように、主にファイルやメッセージの内容を起点にしたものでした。今回の更新では、公式ロードマップの例にあるように「過去20日間に特定ユーザーに関連する財務情報アラートを重視する」といった、ユーザーや期間などの条件を含む指示が可能になります。(Microsoft)
Microsoft Learnでも、DLPのTriage Agentではカスタム指示を自然言語で与え、それを構造化された分類ロジックに変換してアラートの優先度を上下させると説明されています。また、現在のドキュメントでは、直近期間、特定ユーザー、ファイル拡張子などを含む指示例も示されています。(Microsoft Learn)
カスタム指示の実用例
| 目的 | 指示の考え方 | 注意点 |
|---|---|---|
| 直近の緊急リスクを優先する | 「過去7日間の税務・財務・法務情報に関するアラートを重視する」 | 古いアラートを完全に無視する運用にしない |
| 特定部門・特定ユーザーの調査を補助する | 調査対象のユーザーや期間を明示して優先度を上げる | 個人名を恒久的に入れると、異動・退職後に運用が歪む |
| ノイズになりやすい条件を下げる | 特定の拡張子や低リスク条件を優先度低めに扱う | 実際にリスクが低いと確認してから使う |
| 分類ルールの意味を補足する | 社内用語や業務上の定義を説明する | 1つの指示に複雑な条件を詰め込みすぎない |
実務では、最初から凝った指示を作るよりも、現在のアラートキューで「毎週人手で後回しにしている条件」と「見逃したくない条件」を洗い出す方が有効です。カスタム指示は、AIに判断を丸投げするためではなく、組織のリスク判断をエージェントに伝えるための運用ルールと考えるべきです。
統合されたAgent設定で運用手順を見直す
今回の更新では、展開構成とトリガーが単一ビューに統合されます。設定を変更しやすくなる一方で、「誰が、いつ、どの設定を変えたのか」を追跡しやすい運用にしておかないと、後から原因調査が難しくなります。
特に注意したいのは、Purview管理者、セキュリティアナリスト、コンプライアンス担当者の権限分担です。Microsoft Purviewポータルでは、Roles and scopesの領域でPurview内の作業権限を管理できます。必要な作業だけを明示的に許可する設計が重要です。(Microsoft Learn)
設定統合後に見直すべき項目は次の通りです。
| 確認項目 | 見直す理由 | 推奨対応 |
|---|---|---|
| エージェント設定の変更権限 | 単一ビュー化により変更しやすくなる | 編集可能なロールを最小限にする |
| 変更承認フロー | カスタム指示や対象ポリシーの変更がアラート優先度に直結する | 変更前後のスクリーンショットや設定値を記録する |
| 運用手順書 | 旧UI前提の手順が使えなくなる可能性がある | Purviewポータル上の新しい導線に更新する |
| アナリスト教育 | 優先度の意味や分類理由の読み方が変わる | トリアージ結果を鵜呑みにしない判断基準を共有する |
非コンテンツ条件アラートもトリアージ対象になる
DLPポリシーでは、機密情報タイプの検出だけでなく、送信先ドメイン、受信者、送信者、ファイル属性など、コンテンツそのもの以外の条件を使うことがあります。今回の更新では、これまで未対応扱いだった「Non content contains condition」に基づくDLPアラートも、Data Security Triage Agentのトリアージおよび分類対象になります。公式ロードマップでは、RecipientDomainIsに一致して発生したアラートの例が挙げられています。(Microsoft)
これは、外部ドメインへの送信、特定宛先への共有、特定条件に合致する送信パターンなどをDLPで監視している組織にとって重要です。今まで「エージェントで処理されないアラート」として別運用していたものが、トリアージキューに入る可能性があります。
ただし、対象が広がることは必ずしも「すぐに楽になる」ことを意味しません。アラート件数が増えれば、分類結果の確認、SCU消費、ダッシュボード上の優先度分布にも影響します。展開直後は、少なくとも以下を比較してください。
| 比較する指標 | 展開前 | 展開後に見ること |
|---|---|---|
| 1日あたりのDLPアラート数 | 現在の総数と未対応扱いの数 | トリアージ対象に入った件数 |
| Needs attentionなど高優先度の件数 | アナリストが処理できる量か | 高優先度が増えすぎていないか |
| 誤検知・低リスクの割合 | 手動で後回しにしていた条件 | カスタム指示で下げられるか |
| 処理時間 | 初動確認までの時間 | エージェント利用で短縮しているか |
Agent Identityにより監査ログの見え方が変わる
今回の更新では、Triage AgentをMicrosoft Entraで生成されるエージェント自身のIDで展開できるようになります。これにより、エージェントが設定者のユーザーIDで動作する必要がなくなり、監査上の実行主体を整理しやすくなります。(Microsoft)
Microsoft Learnでは、Agent Identityを使用する場合にDLPのTriage Agentへ割り当てられるロールとして、Information Protection Analyst、Purview content Analyst、Data classification content viewer、Data classification content downloader、Purview Copilot Workspace Contributorが示されています。(Microsoft Learn)
この点は、Entra管理者やSOC運用担当者にも共有が必要です。新しいIDが監査ログやアラート連携上で見えるようになったときに、不審なアプリや不要なIDと誤認してブロック・削除しないようにするためです。
Agent Identity導入時の確認ポイント
| 項目 | 確認内容 |
|---|---|
| Microsoft Entra上の表示 | どの名前・形式でエージェントIDが作成されるか |
| 監査ログ | 操作主体がユーザーからエージェントIDに変わる箇所があるか |
| 条件付きアクセス | エージェントの動作を意図せず妨げるポリシーがないか |
| SIEM連携 | ユーザーIDだけで抽出しているクエリがないか |
| 所有者・管理責任 | 誰がエージェントIDの状態を定期確認するか |
展開前に確認すべき設定と前提条件
Data Security Triage Agentは、使えばすぐ全アラートを正しく処理してくれる魔法の機能ではありません。ライセンス、SCU、DLPポリシーの状態、Teams修復メッセージの設定など、複数の前提条件があります。
特に、Microsoft LearnではDLPのTriage Agentにシートごとの標準ライセンスモデルと従量課金制課金モデルの両方が必要であり、エージェントの動作にはSecurity Compute Units（SCU）のプロビジョニングが必要とされています。SCU消費量は処理されるアラートの数や種類によって変わるため、今回のように対象アラートが増える更新では利用状況の監視が重要です。(Microsoft Learn)
| 確認項目 | 理由 | OKの目安 |
|---|---|---|
| ライセンスとSCU | エージェントが動作しない、または処理量に制限が出る可能性がある | SCUがプロビジョニング済みで、使用状況を監視できる |
| DLPポリシーの状態 | DLPのTriage Agentはシミュレーションモードのポリシーからのアラートをトリアージしない | 対象ポリシーがActive modeである |
| 対象ワークロード | Exchange、Devices、SharePoint、OneDrive、Teamsなど対象範囲を理解する必要がある | 自社の主要なDLP発生元と一致している |
| デバイス証拠収集 | Devicesのアラートを扱うには追加設定が必要な場合がある | Endpoint DLPの証拠収集設定を確認済み |
| カスタム指示 | 優先度判断に直接影響する | 変更履歴と意図が文書化されている |
| Agent Identity | 監査・権限・連携に影響する | Entra管理者とSOCがIDの存在を把握している |
| Teams修復メッセージ | ユーザー通知に影響する | Teams管理センター側の許可設定を確認済み |
また、Triage Agent in DLPは、有効化前30日までに生成されたアラートを確認できる場合がありますが、十分なSCUがあることが前提です。さらに、アラートに10個以上のファイルが含まれる場合は、リスクが高いと判断された上位ファイルを使って要約する挙動が説明されています。重要アラートでは、エージェントの要約だけでなく、必要に応じて手動分析も行うべきです。(Microsoft Learn)
Teams修復メッセージを使う場合の注意点
DLPのData Security Triage Agentは、機密情報を含むファイルを最後に変更したユーザーへ、Microsoft Teams経由で修復メッセージを送信できます。ただし、この修復リマインダーはプレビュー機能として説明されており、一般提供前に変更される可能性があります。(Microsoft Learn)
Teams修復メッセージを使う場合は、Purview側だけでなくTeams管理センター側の設定も必要です。Microsoft Learnでは、組織全体のMicrosoftアプリを有効にすること、Data Security Triage Agentアプリを対象ユーザーに対してブロックしないことが必要とされています。ユーザーにアプリを事前インストールする必要はなく、修復メッセージ送信時にMicrosoft Purviewが対象ユーザーへ自動的にインストールします。(Microsoft Learn)
現場で失敗しやすいのは、Purview管理者がTeams管理センターの権限を持っていないケースです。DLP側では修復メッセージを有効にしたつもりでも、Teams側でMicrosoftアプリやData Security Triage Agentアプリがブロックされていれば、ユーザーに通知が届きません。展開計画にはTeams管理者を必ず含めてください。
管理者向けの安全な展開手順
今回の更新は、全社一括で有効化・変更するよりも、現在のDLP運用を計測したうえで段階的に反映する方が安全です。
現状のDLPアラートを棚卸しする
まず、直近2〜4週間のDLPアラートを確認します。見るべき項目は、アラート件数、未対応扱いになっていたアラート、手動で後回しにしている条件、処理に時間がかかるアラート、誤検知が多いポリシーです。
この棚卸しをせずにカスタム指示を作ると、実際のノイズではなく思い込みに基づいて優先度を変更してしまいます。
対象ポリシーを限定して試す
最初は、重要度が高く、かつアラート量が管理できるDLPポリシーから試します。たとえば、役員・財務・法務・個人情報を扱う部門のポリシーなどです。ただし、いきなり大量のアラートが出るポリシーを対象にすると、トリアージ結果の検証が追いつかなくなります。
カスタム指示を短く具体的に書く
カスタム指示は、長ければ良いわけではありません。1つの指示に複数の例外、部門名、期間、ファイル種別、業務定義を詰め込みすぎると、分類意図が曖昧になります。
おすすめは、次のように目的ごとに分けることです。
| 悪い例 | 改善例 |
|---|---|
| 「重要なものを優先し、誤検知は下げ、財務や法務や外部送信や特定ユーザー関連は適切に処理する」 | 「過去7日間の財務・税務・法務情報に関するアラートを優先する」 |
| 「PDFはだいたい問題ないので下げる」 | 「業務上承認済みの共有先に送信されたPDF添付アラートは低優先度にする」 |
| 「特定ユーザーのアラートを常に最優先する」 | 「調査期間中のみ、対象ユーザーに関連するアラートを優先する」 |
展開後の差分を確認する
展開後は、少なくとも1〜2週間は毎日確認する期間を設けます。特に見るべきなのは、高優先度アラートの増減、非コンテンツ条件アラートの扱い、SCU消費量、アナリストの処理時間、誤検知の割合です。
DLP運用では、「アラート数が減った」だけでは成功とは言えません。見逃してはいけないリスクが優先表示され、低リスクのノイズが適切に下がり、監査証跡として説明できる状態になっていることが重要です。
開発者・SIEM連携担当者が確認すべきポイント
今回のRoadmap ID 557552自体は、新しいAPIの提供を明記している更新ではありません。そのため、開発者が見るべきなのはAPI追加ではなく、既存の連携が前提としている「アラートの種類」「分類結果」「実行主体」「監査ログ」の変化です。
特に、以下のような実装は見直し対象です。
| 既存実装の例 | 起きうる問題 | 見直し方 |
|---|---|---|
| 「unsupported」扱いのDLPアラートを別集計している | 非コンテンツ条件アラートがトリアージ対象に入ると件数が変わる | サポート状態だけでなく、ポリシー名・条件・分類結果で再整理する |
| ユーザーIDを実行主体として固定している | Agent Identityにより監査上の主体が変わる可能性がある | エージェントIDを許可リストや識別条件に追加する |
| 高優先度アラートだけを自動起票している | カスタム指示変更で起票件数が増減する | 展開後にチケット量と重複起票を確認する |
| アラート分類の文言を完全一致で判定している | 表示や分類の変更に弱い | 可能なら安定したフィールドや複数条件で判定する |
| Teams通知の成功を修復完了とみなしている | 通知送信と実際の修復は別 | 修復ステータスやユーザー対応状況も確認する |
開発者やSOCエンジニアは、Purview管理者だけでなく、Entra管理者、Teams管理者、コンプライアンス担当者と一緒に変更前後のログを確認してください。特に監査ログの主体が変わる部分は、インシデント調査時の説明責任に直結します。
失敗しやすいポイントと回避策
カスタム指示を細かくしすぎる
メタデータ対応により、ユーザー名、期間、ファイル種別などを含めやすくなります。しかし、細かすぎる指示は運用負荷を上げます。特定ユーザー名を恒久的に入れる場合は、調査終了後に削除する期限を決めてください。
非コンテンツ条件アラートの増加を見込まない
これまで未対応だったアラートがトリアージ対象になると、ダッシュボード上の見え方が変わります。高優先度アラートが増えたように見えても、実際には対象範囲が広がっただけの場合があります。展開前のベースラインを残しておくことが重要です。
SCU消費量を確認しない
Data Security Triage AgentはSCUを使用します。今回の更新で処理対象アラートが増えた場合、利用量が変わる可能性があります。エージェントの効果を測るときは、処理時間や検知精度だけでなく、SCU消費量もあわせて見てください。(Microsoft Learn)
エージェントの判断を最終判断にしてしまう
Data Security Triage Agentは、アナリストの調査を支援する機能です。分類理由が示されるとはいえ、法務判断、懲戒判断、重大インシデント対応を自動分類だけで決めるべきではありません。重要アラートでは、ファイル内容、送信経路、ユーザーの業務文脈、過去の活動履歴を人が確認する手順を残してください。
Agent Identityをセキュリティ例外として放置する
Agent Identityは監査を明確にするメリットがありますが、作成後に誰も管理しない状態は避けるべきです。Entra上のID、割り当てロール、監査ログ、条件付きアクセスとの関係を定期確認の対象に入れてください。
まず取るべきアクション
Microsoft Purview Data Loss PreventionのData Security Triage Agent更新に対応するには、機能を理解するだけでなく、自社のDLP運用にどこまで影響するかを確認する必要があります。
最初に行うべきことは、現在のDLPアラート量、未対応アラート、カスタム指示、対象ポリシー、SCU消費量、監査ログの実行主体を棚卸しすることです。そのうえで、メタデータ対応のカスタム指示を小さく試し、非コンテンツ条件アラートがどの程度トリアージ対象に入るかを確認します。
すでにSIEM、SOAR、チケット管理ツール、Teams修復通知を組み合わせている組織では、Purview管理者だけで完結させず、Entra管理者、Teams管理者、SOC、コンプライアンス担当者を含めて変更を確認してください。今回の更新は、アラートを「見る」機能の強化であると同時に、監査・権限・運用フローを整える機会でもあります。
コメント