Microsoft Purview DLPのData Security Triage Agentを使っている管理者にとって、今回の更新の要点は「AIエージェントの判断を、信頼度スコアと理由の説明で検証しやすくなる」ことです。これにより、DLPアラートをただ自動分類するだけでなく、SOCやコンプライアンス担当者が「なぜ注意が必要なのか」「どの程度信用してよいのか」を確認しながら対応できます。
ただし、これは手動レビューを完全になくす機能ではありません。管理者がまず確認すべきなのは、DLPトリアージエージェントの展開状況、対象ポリシー、対応ワークロード、Security CopilotのライセンスとSCU、Microsoft Defender XDRやTeams連携を含む運用ルールです。特に、低信頼度のアラートや未分類アラートを自動的に無視する運用は避けるべきです。
Microsoft Purview DLPの今回の更新で何が変わるのか
Microsoft 365 Roadmap ID 560597では、Microsoft PurviewのData Loss Prevention、つまりDLPにおけるData Security Triage Agentへ、Reasoning TraceとConfidence Scoreを追加する機能が示されています。公式のRelease Communications APIでは、対象製品はMicrosoft Purview、プラットフォームはWeb、クラウドインスタンスはWorldwide、ステータスはIn development、プレビューは2026年5月、一般提供予定は2026年7月とされています。更新日時はAPI上で2026年5月14日23:15:59 UTCと表示されており、日本時間では2026年5月15日に相当します。(Microsoft)
Microsoftのロードマップ情報は予定であり、提供時期や内容は変更される可能性があります。実際の展開判断では、Microsoft 365 Roadmap、Microsoft 365管理センターのメッセージセンター、対象テナントでの表示状況をあわせて確認してください。(Microsoft)
今回の変更は、DLPアラートをエージェントが分類した後に、アナリストが判断根拠を追いやすくするためのものです。従来は、エージェントがなぜその判断をしたのか、どの程度の確信度なのかが見えにくい場合、アナリストは結局すべてを手動確認しがちでした。今回の機能では、エージェントの判断にReasoning TraceとConfidence Scoreを並べて表示し、SOCチームが検証可能な出力として扱えるようにすることが目的とされています。(Microsoft)
Reasoning TraceとConfidence Scoreの意味
Reasoning Traceは、エージェントがDLPアラートをどのような根拠で判断したのかを説明するための情報です。たとえば、機密情報の種類、外部共有の有無、ラベルの削除やダウングレード、ポリシーの厳しさなどが、判断にどう関係したのかを確認する材料になります。
Confidence Scoreは、エージェント出力の信頼度を示すシグナルです。重要なのは、Confidence Scoreを「真陽性である確率」と単純に読み替えないことです。実際の表示形式やしきい値は、提供後にテナント側で確認する必要がありますが、運用上は「レビューの深さを決める補助指標」として使うのが現実的です。
| 項目 | 何を確認できるか | 実務での使い方 | 注意点 |
|---|---|---|---|
| Reasoning Trace | エージェントが判断に使った理由の説明 | アラートの根拠を確認し、監査・レビュー時の説明材料にする | AIの内部処理すべてが開示されると考えない |
| Confidence Score | エージェント判断の信頼度シグナル | 高信頼度の重大アラートを優先対応し、低信頼度は人手で検証する | スコアだけで自動クローズや自動放置を判断しない |
| エージェント分類 | Needs attention、Less Urgent、Not categorizedなどの分類 | アラートキューの優先順位付けに使う | 未対応・未分類アラートの確認フローを残す |
影響を受ける範囲
今回の更新は、DLPポリシーそのものを強制的に変更するものではなく、主にDLPアラートのトリアージ、調査、監査説明、運用設計に影響します。特に影響が大きいのは、Microsoft Purview DLPのアラートを日常的に確認しているSOC、コンプライアンス部門、情報保護管理者、Microsoft Defender XDRでDLPインシデントを扱うチームです。
Data Security Triage Agent in DLPは、Exchange、Teams、OneDrive、SharePoint、デバイス、つまりエンドポイントからのDLPアラートを対象にします。デバイス由来のアラートをトリアージするには、デバイス上のファイルアクティビティの証拠収集を有効にする必要があります。(Microsoft Learn)
| 確認対象 | 影響 | 管理者が見るべきポイント |
|---|---|---|
| Microsoft Purview DLPアラート | エージェント判断に理由と信頼度が加わる | 既存のアラート確認手順に、Reasoning TraceとConfidence Scoreの確認を追加する |
| Microsoft Defender XDR | DLPアラートをインシデントとして扱う運用に影響 | Defender側のインシデント管理、タグ、コメント、修復アクションとの整合性を確認する |
| DLP対象ワークロード | Exchange、Teams、OneDrive、SharePoint、デバイスが主な対象 | 対象外の場所や条件だけで構成されたポリシーを期待しすぎない |
| エンドポイントDLP | 証拠収集が無効だとトリアージできない場合がある | ファイルアクティビティの証拠収集、保存先、ポリシー条件を確認する |
| Teams修復メッセージ | ファイルの最終変更者へTeamsで修復依頼できる | Teams管理センターのアプリ許可設定と、修復リマインダーのプレビュー状態を確認する |
| 外部連携・独自ダッシュボード | 新しい表示項目をどう扱うか検討が必要 | APIやエクスポート仕様が確認できるまで、UI表示を前提にした固定実装を避ける |
Data Security Triage Agentの前提条件を確認する
今回のReasoning TraceとConfidence Scoreを活用するには、そもそもData Security Triage Agentが正しく展開・構成されている必要があります。
Microsoft Learnでは、DLPのトリアージエージェントを利用するには、標準のシート単位ライセンスモデルと従量課金モデルの両方が必要であり、Microsoft Purview DLPを利用できるライセンス、Security CopilotのSCUプロビジョニング、SCU消費量の監視が必要と説明されています。(Microsoft Learn)
また、DLPのトリアージエージェントはMicrosoft Security Copilot上で動作します。テナントのSecurity Copilotオンボード、Microsoft 365データ共有、Microsoft Purviewプラグインの有効化など、基盤側の設定も確認対象です。(Microsoft Learn)
最初に確認すべき設定チェックリスト
| 項目 | 確認内容 | 不備がある場合のリスク |
|---|---|---|
| ライセンス | Microsoft Purview DLP、Security Copilot、必要なライセンス体系 | エージェントを展開できない、または利用範囲が限定される |
| SCU | Security CopilotのSCUがプロビジョニングされているか | アラート処理量に応じた利用ができない |
| エージェントID | ユーザーIDではなく、推奨されるエージェントIDで構成しているか | 設定者の退職・権限変更により運用が不安定になる |
| DLPポリシー | 対象ポリシーがアクティブモードか | シミュレーションモードのアラートをトリアージ対象と誤解する |
| 対象ワークロード | Exchange、Teams、OneDrive、SharePoint、デバイスを含むか | 対象外ポリシーのアラートが期待通りに分類されない |
| エンドポイント証拠収集 | デバイス上のファイルアクティビティ証拠収集が有効か | デバイス由来のアラートで判断材料が不足する |
| Teamsアプリ設定 | 修復メッセージを使う場合、MicrosoftアプリとData Security Triage Agentアプリが許可されているか | 修復メッセージがユーザーに届かない |
エージェントのIDについては特に注意が必要です。Microsoft Learnでは、エージェント専用のMicrosoft EntraエージェントIDを作成して利用する方法が推奨されています。設定ユーザーのIDを使っている場合、ユーザーの権限変更や無効化が運用に影響する可能性があるため、エージェントIDへの移行を検討してください。(Microsoft Learn)
アラート分類の見方を運用ルールに落とし込む
Data Security Triage Agentは、選択した期間とポリシーで生成されたアラートをトリアージします。ただし、すべてのアラートを必ず分類するわけではありません。Microsoft Learnでは、トリアージ済みアラートはAll、Needs attention、Less Urgent、Not categorizedに分類され、Not categorizedにはサーバーエラー、レビュー中、その他のエラー、サポート外アクティビティなどが含まれると説明されています。(Microsoft Learn)
今回のConfidence Scoreが加わると、分類と信頼度を組み合わせた運用が重要になります。たとえば、Needs attentionかつ高信頼度のアラートは即時調査の優先候補です。一方で、Needs attentionでも信頼度が低い場合は、誤検知の可能性も含めて証拠を確認する必要があります。
| エージェント分類と信頼度の組み合わせ | 推奨される対応 |
|---|---|
| Needs attention、高信頼度 | 速やかにインシデントとして確認し、ファイル、ユーザー、共有先、ポリシー一致条件を調査する |
| Needs attention、低信頼度 | アラートの根拠を人手で検証し、誤検知か真陽性かを判断する |
| Less Urgent、高信頼度 | すぐに重大対応しない場合でも、サンプルレビューや定期レビューに回す |
| Less Urgent、低信頼度 | ポリシー条件、SIT、分類子、ラベル設定の調整候補として見る |
| Not categorized | 自動化の対象外として扱い、手動トリアージのキューに残す |
DLPの調査フローでは、アラートを真陽性か誤検知か判断し、真正の場合は重大度や組織への影響に基づいて優先順位付けと所有者割り当てを行います。Microsoft DefenderポータルではDLPイベントをインシデントとしてグループ化できるため、Reasoning TraceとConfidence ScoreをDefender側のインシデント対応手順にも反映させると、運用が分断されにくくなります。(Microsoft Learn)
管理者が変更前に行うべき準備
今回の更新は「機能が追加されたら見る」だけでは十分ではありません。信頼度スコアが表示されても、組織側に判断基準がなければ、結局すべてのアラートを同じように手動確認することになります。
DLPポリシーの対象と適格性を確認する
DLPのトリアージエージェントは、アクティブモードのポリシーからのアラートをサポートします。シミュレーションモードのDLPポリシーからのアラートはトリアージされません。また、DLPでは、メール件名一致のような非SITまたはトレーニング不可能な分類子のみの条件によるアラートはトリアージされないとされています。エージェントが評価しないアラートは、手動分析が必要です。(Microsoft Learn)
特に確認したいのは、以下のようなポリシーです。
- 外部共有や外部送信を検知するポリシー
- 秘密度ラベルの削除・ダウングレードを検知するポリシー
- 個人情報、クレジットカード番号、契約情報など高リスク情報を対象にするポリシー
- エンドポイントでのコピー、ダウンロード、リムーバブルメディア利用を監視するポリシー
- 誤検知が多く、アナリストの確認負荷が高いポリシー
まずは全ポリシーに広げるより、影響が大きく、かつ判断基準を定義しやすいDLPポリシーから段階的に確認するのが安全です。
エンドポイントDLPでは証拠収集を確認する
デバイス、つまりエンドポイント由来のDLPアラートをトリアージしたい場合、ファイルアクティビティの証拠収集が重要です。証拠が取得できていないと、エージェントが十分な材料を持てず、部分的なトリアージや未分類につながる可能性があります。
管理者は、次の観点で確認してください。
| 確認項目 | 実務上の判断基準 |
|---|---|
| 証拠収集の有効化 | エンドポイントDLP対象ポリシーでファイルアクティビティ証拠収集が有効か |
| ストレージ | 証拠収集先が要件を満たしているか |
| 対象デバイス | 重要部門の端末がDLP管理対象になっているか |
| プライバシー説明 | 証拠収集の目的、対象、保管期間を社内規程や通知に反映しているか |
| 調査権限 | 証拠ファイルや関連ログを確認できるロールが適切に割り当てられているか |
Teams修復メッセージを使う場合の注意点
Data Security Triage Agentは、機密情報を含むファイルを最後に変更したユーザーへ、Microsoft Teams経由で修復メッセージを送信できます。ただし、この修復リマインダーはプレビュー段階であり、一般提供前に機能や手順が変わる可能性があります。(Microsoft Learn)
Teamsで修復メッセージを使う場合、Microsoft Teams管理センターで組織全体のMicrosoftアプリを有効にし、Data Security Triage Agentアプリがユーザーに対してブロックされていないことを確認する必要があります。Purview管理者がTeams管理センターの権限を持っていない場合は、Teams管理者と事前に連携してください。(Microsoft Learn)
失敗しやすいのは、DLP側のエージェント設定だけを完了して、Teams側のアプリ許可を確認しないケースです。修復メッセージはユーザー行動の改善に役立ちますが、メッセージが届かない状態では、SOC側の「送ったつもり」とユーザー側の「受け取っていない」が発生します。
開発者・運用自動化担当者が確認すべきこと
DLPアラートをSIEM、チケット管理、独自ダッシュボード、レポート基盤に連携している組織では、Reasoning TraceとConfidence Scoreをどう扱うかを早めに設計しておくべきです。
ただし、Roadmap ID 560597の説明では、Reasoning TraceとConfidence ScoreがどのAPI、ログ、エクスポート形式で取得可能になるかまでは明示されていません。公式情報の範囲では、まずMicrosoft PurviewやDefender XDRの画面での表示、テナントでの実装状況、関連ドキュメントの更新を確認する必要があります。(Microsoft)
開発者・自動化担当者は、次の方針で準備すると安全です。
| 項目 | 推奨対応 |
|---|---|
| データモデル | アラートに信頼度、説明、分類理由を格納できる余地を持たせる |
| スキーマ変更 | 新しいフィールドが追加されても壊れないよう、固定列前提の処理を避ける |
| チケット起票 | Confidence Scoreだけで自動クローズせず、分類・重要度・対象データ・共有先と組み合わせる |
| ダッシュボード | Needs attention件数だけでなく、低信頼度・未分類・手動確認待ちも可視化する |
| 監査ログ | Reasoning Traceをそのまま最終証拠にせず、ポリシー一致、アクティビティ、ファイル情報と紐づける |
| 検証環境 | 本番全体に広げる前に、限定ポリシーで表示内容と運用負荷を確認する |
Confidence Scoreを使った実務的な判断基準
Confidence Scoreは、アナリストの作業を減らすための材料ですが、スコアの数字だけで対応を決めると危険です。おすすめは、組織のDLP運用ルールに「スコアを見た後の行動」を定義することです。
たとえば、次のような判断ルールを作れます。
| 条件 | 対応例 |
|---|---|
| 高リスクポリシー、外部共有、Confidence Score高 | すぐに所有者を割り当て、共有停止やラベル適用などの修復候補を確認する |
| 高リスクポリシー、Confidence Score低 | Reasoning Traceと実ログを照合し、誤検知かどうかを判断する |
| 低リスクポリシー、Confidence Score高 | 自動クローズせず、一定期間はサンプルレビューして精度を確認する |
| Not categorizedが多い | ポリシー条件、証拠収集、対象ワークロード、サポート外条件を見直す |
| 低信頼度が特定ポリシーに集中 | SIT、分類子、例外条件、しきい値、ラベル運用を調整する |
重要なのは、Confidence Scoreを「調査しない理由」にしないことです。特に個人情報、認証情報、知的財産、契約情報、財務情報などを扱うポリシーでは、低信頼度であっても影響が大きい場合があります。
カスタム指示を使う場合の注意点
Data Security Triage Agentでは、DLPのトリアージエージェント向けにカスタム指示を使えます。Microsoft Learnでは、自然言語の入力を構造化された分類ロジックへ変換し、アラートに関連付けられたドキュメントコンテンツに対して実行し、条件に一致した場合に優先度を上げると説明されています。(Microsoft Learn)
ただし、カスタム指示でエージェントが分析するのはドキュメントコンテンツです。メタデータや動作属性は分析対象ではないとされています。たとえば「税金や財務に関する内容」「クレジットカード番号や社会保障番号のような名前付きエンティティ」「5件以上のSSNを含む財務ドキュメント」のような内容条件は向いていますが、「深夜にアクセスした」「外部ユーザーに送信した回数が多い」といった行動条件をカスタム指示だけで扱えると考えるのは避けるべきです。(Microsoft Learn)
展開時に失敗しやすいポイント
今回の更新で最も避けたいのは、「説明と信頼度が出るから安全」と考えて、運用設計を省略することです。実務では、次の失敗が起こりやすくなります。
| 失敗例 | 起きる問題 | 回避策 |
|---|---|---|
| Confidence Scoreを真偽判定として扱う | 低信頼度の重大アラートを見落とす | スコアはレビュー深度を決める補助指標として使う |
| Reasoning Traceだけを監査証跡にする | 実ログやファイル情報との整合性が確認できない | ポリシー一致、アクティビティ、共有先、修復履歴とあわせて保存する |
| シミュレーションモードのポリシーで期待する | トリアージ対象にならず、検証結果が出ない | アクティブモードの対象ポリシーでパイロットする |
| エンドポイント証拠収集を未設定にする | デバイス由来アラートの判断材料が不足する | ファイルアクティビティ証拠収集を事前に確認する |
| Teamsアプリをブロックしたままにする | 修復メッセージが届かない | Teams管理者と連携してMicrosoftアプリと対象アプリの可用性を確認する |
| 最初から全DLPポリシーを対象にする | SCU消費や運用負荷を把握しにくい | 高リスク・高頻度・誤検知が多いポリシーから段階展開する |
| ユーザーIDでエージェントを構成し続ける | 権限変更や退職で運用が不安定になる | エージェントIDへの移行を検討する |
推奨される展開ステップ
本番環境で安全に活用するには、いきなり全社展開するより、DLP運用の中で効果を測りやすい領域から始めるのが現実的です。
| フェーズ | 実施内容 | 成功基準 |
|---|---|---|
| 現状確認 | DLPポリシー、アラート量、誤検知率、対象ワークロード、SCU状況を確認 | どのポリシーから試すべきか決まっている |
| パイロット | 高リスクかつアラート件数が多いポリシーを限定して対象化 | Reasoning TraceとConfidence Scoreをアナリストが評価できる |
| 運用ルール化 | Needs attention、Less Urgent、Not categorized、信頼度別の対応を定義 | 誰が、いつ、何を確認するかが明文化されている |
| 連携確認 | Defender XDR、Teams修復、チケット管理、レポート出力を確認 | アラート対応から修復までの流れが途切れない |
| 拡大展開 | 対象ポリシーと部門を段階的に増やす | SCU消費、未分類率、手動レビュー時間を継続的に測定できる |
| 改善 | 誤検知、低信頼度、未分類が多いポリシーを調整 | ポリシー精度とアナリスト負荷が改善している |
今回の更新で管理者が取るべき次の行動
今回のMicrosoft Purview DLPにおけるData Security Triage Agent更新は、DLPアラート対応を「AIに任せる」ためのものではなく、「AIの判断を検証しながら、段階的に自動化へ寄せる」ための更新です。
まずは、Microsoft 365 Roadmap ID 560597の提供状況を確認し、自社テナントでData Security Triage Agentが展開済みか、対象DLPポリシーがアクティブモードか、Security CopilotとSCUの準備が整っているかを確認してください。そのうえで、Reasoning TraceとConfidence Scoreをアラート対応手順に組み込み、低信頼度や未分類アラートをどう扱うかを明文化することが重要です。
特に、DLPアラートの件数が多い組織では、今回の機能によってアナリストが見るべきアラートを絞り込みやすくなる可能性があります。一方で、信頼度スコアを過信すると、重大な情報漏えいの兆候を見落とすリスクもあります。最初の展開では、限定したポリシーで実際の判断理由、信頼度、手動レビュー結果を突き合わせ、組織に合ったしきい値と対応フローを作ることから始めてください。
コメント