Microsoft PurviewのDLPでData Security Triage Agentを使うべきか迷っている場合、最初に確認すべきポイントは「新しいDLPポリシーを作ること」ではなく、既存のDLPアラートをエージェントが正しく優先順位付けできる状態になっているかです。
今回の更新では、Microsoft PurviewのData Security Triage Agent in DLPが世界向けに一般提供され、DLPやIRMのアラートのうち、組織にとってリスクが高いものをエージェント管理のキューで優先順位付けできるようになります。公式ロードマップでは、Endpoint DLPアラート、Custom SITs（カスタム機密情報の種類）を使ったアラート、Entra Agent IDのサポートがGAリリースの要点として示されています。(Microsoft)
管理者がまず行うべきことは、Security Copilotの利用条件、SCU、DLPポリシーの対象範囲、Endpoint DLPの証拠収集、Purview/Defender XDRでの運用権限を確認することです。この記事では、Microsoft Purviewのセキュリティ更新として、変更点、影響範囲、設定確認、移行・展開時の注意点を実務目線で整理します。
Microsoft Purviewのセキュリティ更新で何が変わるのか
Data Security Triage Agent in DLPは、DLPアラートを単に一覧表示する機能ではありません。Microsoftの説明では、エージェント管理のアラートキューを作成し、組織に最も大きなリスクをもたらすDLPおよびIRMアラートを特定・優先順位付けします。また、各アラートがなぜ優先されたのかを要約と説明で示し、アナリストが重要なアラートに集中できるようにする機能です。(Microsoft)
今回のGAで実務上大きいのは、次の3点です。
| 確認項目 | 変更・追加された内容 | 管理者が見るべきポイント |
|---|---|---|
| Endpoint DLPアラート | エンドポイント由来のDLPアラートも対象範囲に含まれる | デバイス上のファイルアクティビティ証拠収集が有効か |
| Custom SITs | カスタム機密情報の種類を使うアラートも対象に含まれる | 誤検知・過検知が多いCustom SITがないか |
| Entra Agent ID | エージェントIDのサポートが追加 | 個人管理者IDで動かしている構成から移行できるか |
この更新は、DLPポリシーの検知ロジックを直接置き換えるものではありません。既存のDLPポリシーによって生成されたアラートを、調査しやすい順に整理するための機能です。そのため、導入効果は「アラートの数を減らす」よりも、「最初に見るべきアラートを明確にする」ことにあります。
Data Security Triage Agentは何をしてくれるのか
DLP運用でよくある課題は、アラートが多すぎて、どれから確認すべきか判断しにくいことです。特にExchange、Teams、SharePoint、OneDrive、Endpoint DLPをまとめて運用している環境では、アラートの量だけでなく、リスクの種類もばらつきます。
Data Security Triage Agentは、このアラート対応を次のように変えます。
- アラートをリスクの高いものから優先する
- 優先した理由を要約として表示する
- アナリストが手作業で読むべきアラートを絞り込む
- PurviewとDefender XDRの両方で出力を確認しやすくする
Microsoft Learnでは、DLPトリアージエージェントが「注意が必要」「緊急性が低い」「分類されていない」などのカテゴリにアラートを整理すること、優先順位付けにはコンテンツリスク、流出リスク、ポリシーリスクなどが使われることが説明されています。(Microsoft Learn)
たとえば、同じ「機密情報を含むファイル共有」のアラートでも、社内ユーザーが限定共有したケースと、外部ドメインへ送信されたケースでは対応優先度が異なります。Data Security Triage Agentは、このような違いをアラートの背景として整理し、アナリストの初動判断を助けます。
影響範囲：対象になるワークロードと対象外になりやすい条件
Data Security Triage Agent in DLPは、すべてのDLPアラートを無条件に処理するわけではありません。公式ドキュメントでは、DLPトリアージエージェントがExchange、Teams、OneDrive、SharePoint、デバイス（Endpoint）の場所を対象とするポリシーからのアラートをトリアージすると説明されています。デバイス由来のアラートを扱うには、デバイス上のファイルアクティビティの証拠収集を有効にする必要があります。(Microsoft Learn)
| 領域 | 対象になるか | 確認ポイント |
|---|---|---|
| Exchange | 対象 | DLPポリシーがアクティブモードで動作しているか |
| Microsoft Teams | 対象 | チャットやチャネルのDLPアラート運用手順があるか |
| SharePoint | 対象 | 外部共有・過剰共有の調査フローがあるか |
| OneDrive | 対象 | 個人領域の機密ファイル共有を誰が調査するか |
| Endpoint DLP | 対象 | ファイルアクティビティの証拠収集が有効か |
| シミュレーションモードのDLPポリシー | 対象外 | 本番アラートとテストアラートを混同しない |
| 件名一致など非SIT条件のみのルール | 対象外になり得る | 手動分析の対象として運用に残す |
特に注意したいのは、アクティブモードのDLPポリシーです。Microsoft Learnでは、DLPのトリアージエージェントはアクティブモードのポリシーからのアラートのみをサポートし、シミュレーションモードのDLPポリシーからのアラートはトリアージしないと説明されています。また、メール件名一致のような非SITまたは非トレーニング可能分類子条件だけのアラートはトリアージされないため、手動分析が必要です。(Microsoft Learn)
つまり、導入前に「DLPポリシーがあるから大丈夫」と判断するのは危険です。どのポリシーがエージェントの対象になり、どのポリシーが制限付きまたは対象外になるかを確認する必要があります。
管理者が最初に確認すべき設定
Data Security Triage Agentは、Microsoft Security Copilot上で動作します。そのため、Microsoft Purviewだけを見ていても導入準備は完了しません。公式ドキュメントでは、Security Copilotへのオンボード、Microsoft 365データ共有、Microsoft Purviewプラグインの有効化が前提条件として示されています。(Microsoft Learn)
| 確認項目 | 確認内容 | 見落とした場合の影響 |
|---|---|---|
| ライセンス | DLP利用権とSecurity Copilot関連の要件を満たすか | エージェントを有効化できない |
| SCU | Security CopilotのSecurity Compute Unitがプロビジョニング済みか | アラート処理が実行できない、または処理量に制限が出る |
| Microsoft 365データ共有 | Security Copilotで有効になっているか | エージェントが必要なデータにアクセスできない |
| Purviewプラグイン | Security Copilot側で有効か | Purviewデータを使った処理ができない |
| DLPポリシーの状態 | アクティブモードか、対象ワークロードを含むか | アラートがトリアージ対象外になる |
| Endpoint DLP証拠収集 | デバイスのファイルアクティビティ証拠収集が有効か | Endpoint DLPアラートを十分に評価できない |
| Entra Agent ID | エージェントIDで構成しているか | 個人管理者ID依存の運用が残る |
| ロールと権限 | 管理者・アナリストに必要な役割があるか | 表示、編集、手動実行、管理ができない |
ライセンスと課金の観点では、DLPトリアージエージェントには標準のシート単位ライセンスモデルと従量課金モデルの両方が必要で、エージェントがタスクを実行する際にSCUを使用します。処理されるアラートの数と種類によってSCU消費量が変わるため、導入前に使用状況監視の確認フローを決めておくべきです。(Microsoft Learn)
Entra Agent IDへの移行は優先度が高い
今回のGAで見逃せないのが、Entra Agent IDのサポートです。Microsoft Learnでは、エージェントは独自のエージェントIDを持つようになり、ユーザーIDで設定されたエージェントについてはエージェントIDへの移行が推奨されています。(Microsoft Learn)
実務では、これは単なるID設定ではありません。個人の管理者アカウントに依存した運用を避け、エージェントの活動を独立したIDに紐づけるための設計変更です。
特に次のような環境では、早めに確認してください。
- 以前のプレビュー段階でユーザーIDを使ってエージェントを構成した
- 管理者の異動や退職でアカウント棚卸しが必要になる
- Purviewの監査ログやアクセス権レビューを厳格に運用している
- 最小権限の原則に基づき、個人IDとサービス的な実行主体を分けたい
エージェントIDで設定した後は、ロールベースのアクセスが反映されるまで30分待ってから手動実行を開始するよう案内されています。また、セットアップ完了後は30〜60分以内に実行が開始され、既定では過去30日以内に生成されたDLPポリシーからのアラートを処理します。(Microsoft Learn)
PurviewとDefender XDRでの展開・管理の違い
Data Security Triage Agentは、Microsoft PurviewポータルとMicrosoft Defender XDRポータルの両方から展開できます。ただし、管理、編集、無効化はMicrosoft Purviewポータルからのみ行えます。展開後の概要や出力は、PurviewとDefender XDRの両方で確認できます。(Microsoft Learn)
この点は、SOC運用で混乱しやすいポイントです。Defender XDRでDLPアラートを見ているアナリストが「ここで展開できるなら、設定変更もDefender XDRでできる」と誤解しやすいためです。
運用ルールとしては、次のように分けると分かりやすくなります。
| 作業 | 主な担当 | 操作場所 |
|---|---|---|
| エージェントの初期展開 | Purview管理者、セキュリティ管理者 | PurviewまたはDefender XDR |
| エージェント設定の編集 | Purview管理者 | Microsoft Purview |
| ポリシースコープ変更 | Purview管理者 | Microsoft Purview |
| アラート確認 | SOCアナリスト | PurviewまたはDefender XDR |
| 無効化・削除 | Purview管理者 | Microsoft Purview |
Defender XDR側から展開した場合でも、設定変更や無効化を行う場所はPurviewです。この切り分けを運用手順書に明記しておくと、アラート対応中の権限不足や設定変更の迷子を防げます。
導入手順：本番展開前にやるべき流れ
Data Security Triage Agentの導入は、いきなり全ポリシーを対象にするよりも、対象範囲を確認しながら段階的に進めるほうが安全です。
事前準備でライセンス・SCU・権限を確認する
まず、Security Copilotの利用条件、SCU、Microsoft 365データ共有、Purviewプラグイン、管理者とアナリストのロールを確認します。
この段階で重要なのは、アナリストに過剰な管理権限を渡さないことです。アラートを見る人、エージェント設定を変更する人、DLPポリシーを変更する人を分けると、運用ミスを減らせます。
対象DLPポリシーを棚卸しする
次に、既存のDLPポリシーを確認します。
見るべき観点は次の4つです。
- アクティブモードか
- Exchange、Teams、SharePoint、OneDrive、Endpointのいずれかを対象にしているか
- Custom SITや既定SIT、トレーニング可能分類子を適切に使っているか
- Endpoint DLPで証拠収集が必要なポリシーがあるか
Custom SITを多用している環境では、誤検知率が高いSITをそのまま使うと、エージェントの優先順位付け結果も現場感とずれる可能性があります。導入前に、過去のDLPアラートから「実際に対応が必要だったもの」と「ノイズだったもの」を確認しておくとよいでしょう。
エージェントを有効化し、ポリシースコープを設定する
Purviewポータルでは、左側ナビゲーションからエージェントを選択し、Data Loss Preventionのトリアージエージェントをセットアップできます。設定では、自動実行、アラート期間、修復リマインダー、ポリシースコープなどを調整できます。(Microsoft Learn)
ワンクリック展開も用意されていますが、既定ではエージェントIDを作成して使用し、スケジュールに基づいて自動実行し、過去30日間のアラートを対象にし、修復リマインダーはオフ、ポリシースコープは対象内のすべてのポリシーになります。(Microsoft Learn)
本番環境では、最初から全ポリシーを対象にするよりも、機密度が高く、過去に対応実績が多いDLPポリシーから始めると評価しやすくなります。
初回実行後に結果を確認する
初期セットアップ後、エージェントがスコープ内アラートのトリアージを完了し、手動実行が有効になるまで最大2時間かかる場合があります。(Microsoft Learn)
初回確認では、単に「動いたか」ではなく、次の点を見ます。
| 確認観点 | 判断基準 |
|---|---|
| 要注意アラート | 実際に優先対応すべき内容が上位に来ているか |
| 緊急性が低いアラート | 現場判断と大きくずれていないか |
| 分類されていないアラート | 対象外条件、証拠収集不足、サポート外条件がないか |
| 要約内容 | アナリストが次の調査アクションを判断できるか |
| SCU消費 | 想定より処理量が多すぎないか |
この確認をせずに全社展開すると、「エージェントを入れたのに、結局アナリストが全部見ている」という状態になりやすくなります。
修復リマインダーは便利だが、プレビュー扱いに注意
Data Security Triage Agentには、Teamsを使ってユーザーへ修復メッセージを送る機能があります。Microsoft Learnでは、機密情報を含むファイルを最後に変更したユーザーにTeams経由で修復メッセージを送信できると説明されていますが、この修復リマインダーはプレビュー段階で、一般公開前に変更される可能性があるとされています。(Microsoft Learn)
この機能を使う場合、Teams管理センターで組織全体のMicrosoftアプリを有効にし、Data Security Triage Agentアプリが対象ユーザーに対してブロックされていないことを確認する必要があります。(Microsoft Learn)
修復リマインダーは、SharePointやOneDrive上の機密ファイルをユーザー自身に修正してもらう運用では有効です。一方で、誤ったメッセージを大量に送ると、ユーザーの不信感や問い合わせ増加につながります。
本番利用前には、次の条件を満たしているポリシーだけで有効化するのが現実的です。
- 誤検知が少ないDLPポリシーである
- ユーザーが自分で修復できる内容である
- ヘルプデスクやセキュリティ窓口の案内が整っている
- Teamsメッセージの受信対象ユーザーを説明できる
- プレビュー機能として変更可能性を社内合意している
開発者・運用担当者が確認すべきポイント
この更新は、アプリケーション開発者がコードを直接変更するタイプの機能ではありません。ただし、DLPポリシー、Custom SIT、SIEM連携、SOC運用フローに関わる担当者には影響があります。
Custom SITの品質を見直す
GAでCustom SITsを使ったアラートも対象に含まれるため、カスタム定義の品質がより重要になります。
たとえば、社内の顧客番号や契約番号をCustom SITで検出している場合、パターンが広すぎると通常の文書まで高リスク扱いされる可能性があります。逆に条件が狭すぎると、本当に重要なデータが優先されません。
見直しでは、次の観点を使うと効果的です。
| 観点 | 具体例 |
|---|---|
| 誤検知 | 一般的な数字列を顧客番号として拾っていないか |
| 検知漏れ | ハイフン有無、全角半角、プレフィックス違いに対応しているか |
| 文脈 | 契約書、請求書、顧客一覧など業務文書の文脈と合っているか |
| 優先度 | すべてのCustom SITを同じ重要度として扱っていないか |
SIEMやチケット運用の優先度設計を合わせる
Data Security Triage Agentによって、アラートの優先順位付けや要約が使いやすくなっても、チケットシステム側で従来通り「発生順」に処理していれば効果は半減します。
SOC運用では、次のように優先度ルールを見直す必要があります。
- 「注意が必要」カテゴリは初動SLAを短くする
- 「分類されていない」カテゴリは対象外理由の確認フローを作る
- エージェント要約をそのまま結論にせず、一次判断材料として扱う
- 重大インシデント化の基準は人間の承認を残す
AIによる優先順位付けは、アナリストの判断を置き換えるものではありません。むしろ、アナリストが根拠を確認しやすくするための補助線として使うべきです。
よくある失敗と回避策
| 失敗しやすいポイント | 起きる問題 | 回避策 |
|---|---|---|
| シミュレーションモードのポリシーを対象と思い込む | アラートがトリアージされない | 本番アクティブモードのポリシーを確認する |
| Endpoint DLPの証拠収集を有効にしていない | エンドポイント由来のアラート評価が不十分になる | デバイス上のファイルアクティビティ証拠収集を確認する |
| Custom SITの誤検知が多い | 要注意アラートの品質が下がる | 過去アラートを使ってCustom SITを調整する |
| Defender XDRで管理できると思い込む | 設定変更や無効化ができず混乱する | 管理はPurview、確認はPurview/Defender XDRと整理する |
| 修復リマインダーを全社で急に有効化する | ユーザー問い合わせが増える | 対象ポリシーを絞り、案内文とサポート窓口を準備する |
| SCU消費を見積もらない | 想定外の利用量になる | 初期展開は対象ポリシーを絞り、使用状況を監視する |
| エージェントID移行を後回しにする | 個人管理者IDに依存した運用が残る | Entra Agent IDへの移行計画を作る |
どの組織から導入すべきか
Data Security Triage Agent in DLPは、すべての組織が同じ優先度で導入すべき機能ではありません。特に効果が出やすいのは、次のような環境です。
- DLPアラートが多く、SOCや情報システム部門の確認が追いついていない
- Endpoint DLP、SharePoint、OneDrive、Teamsを横断してデータ漏えい対策をしている
- Custom SITを使って業界固有・自社固有の機密情報を検出している
- Microsoft PurviewとDefender XDRを併用している
- Security Copilotの利用基盤やSCU管理が整いつつある
一方、DLPポリシーが少数で、アラート件数も少ない組織では、まずDLPポリシーの精度改善やアラート対応フローの整備を優先したほうが効果的です。エージェントを入れる前に、そもそも「何を高リスクとみなすか」を決めておく必要があります。
まとめ：まずはDLPポリシーの対象範囲とEntra Agent IDを確認する
Microsoft PurviewのData Security Triage Agent in DLPは、DLPアラート運用を「発生順に処理する」状態から、「リスク順に判断する」状態へ近づける機能です。GAリリースでは、Endpoint DLPアラート、Custom SITs、Entra Agent IDのサポートが重要な確認ポイントになります。(Microsoft)
管理者が次に取るべき行動は明確です。
まず、Security Copilotのオンボード、SCU、Purviewプラグイン、Microsoft 365データ共有を確認します。次に、DLPポリシーがアクティブモードで、Exchange、Teams、SharePoint、OneDrive、Endpointの対象条件を満たしているかを棚卸しします。そのうえで、Endpoint DLPの証拠収集、Custom SITの精度、Entra Agent IDへの移行、PurviewとDefender XDRの運用分担を整理してください。
最初から全社展開するより、重要度の高いDLPポリシーを数本選び、要注意アラートの精度、分類されていないアラートの理由、SCU消費、アナリストの対応時間を確認するのが安全です。Data Security Triage Agentは、DLP運用を自動化する魔法の機能ではありません。正しく設計されたDLPポリシーと運用ルールがあって初めて、アラート対応の優先順位を実務で使える形にしてくれます。
コメント