Microsoft PurviewのTeams機密データ修復とは?Triage Agentの変更点と設定手順

Microsoft PurviewでDLPアラートを検知できても、対象者への連絡やファイル修正の確認が管理者の手作業になっているケースは少なくありません。

2026年6月10日に公開されたロードマップ項目「Microsoft Purview: Data Security Triage Agent – Sensitive Data Remediation through Microsoft Teams」では、この修復作業をMicrosoft Teamsまでつなげる機能が追加されます。SharePointまたはOneDriveのDLPアラートをエージェントが評価し、対応優先度が高い「Needs attention」と判断したファイルの最終更新者へ、Teamsで修復依頼を送信します。管理者はData Security Posture Management(DSPM)から対応状況を追跡できます。(Microsoft)

重要なのは、機密情報をエージェントが自動削除する機能ではない点です。通知、利用者による修正、修正状況の確認までを一連のワークフローとして自動化し、管理者の督促作業を減らす機能と考えると分かりやすいでしょう。

目次

Microsoft Purviewで何が変わるのか

これまでのDLP運用では、アラートを確認した管理者が対象ファイルを調査し、所有者や関係者を特定して、メールやTeamsで修正を依頼する必要がありました。修正後の再確認や未対応者への督促も、別途管理しなければなりません。

今回の変更後は、次の流れをData Security Triage Agentが支援します。

  1. SharePointまたはOneDriveのファイルがDLPポリシーに一致する
  2. Data Security Triage Agentがアラートを分析する
  3. 優先度が高いアラートを「Needs attention」に分類する
  4. ファイルの最終更新者へTeamsで修復メッセージを送る
  5. 利用者がファイルから対象の機密情報を削除する
  6. 修復されたファイルを翌日以降のリマインダー対象から外す
  7. 管理者がDSPMで修復状況を確認する

Teamsの通知には、対象ファイル名と注意が必要な機密情報の説明が含まれます。未修復の場合は1日1回通知され、同じ利用者に複数の対象ファイルがある場合は最大10ファイルまでまとめられます。(Microsoft Learn)

項目従来の運用変更後
アラートの優先順位付け管理者が個別に判断エージェントが「Needs attention」などに分類
修復依頼管理者がメールやTeamsで連絡最終更新者へTeamsメッセージを自動送信
未対応者への督促管理者が手作業で管理設定した期間、1日1回リマインド
修復確認対象ファイルを再確認修復後はリマインダー対象から除外
進捗管理表計算やチケットで別途管理DSPMのダッシュボードで確認

影響を受けるユーザーと管理者

Microsoft Purview・DLP管理者

Data Security Triage Agentの展開、対象DLPポリシー、アラート期間、リマインダー期間を設定します。

すべてのDLPポリシーを最初から対象にするのではなく、通知対象にするポリシーを選択できます。修復対象のポリシーは、エージェントによるトリアージ対象ポリシーの一部として設定する必要があります。(Microsoft Learn)

Microsoft Teams管理者

Teams管理センターで、Data Security Triage Agentアプリを利用できる状態にする必要があります。

Purview管理者がTeams管理者権限を持っていない場合は、部門をまたいだ作業が必要です。設定漏れがあると、Purview側でリマインダーを有効にしてもTeamsメッセージは届きません。(Microsoft Learn)

SharePoint・OneDriveの利用者

対象ファイルの所有者ではなく、最後にファイルを更新したユーザーが通知先になります。全ユーザーに一律で画面変更が発生するわけではありません。

最終更新者が単に書式を変更した担当者だった場合など、実際のデータ管理責任者とは異なるユーザーへ通知される可能性があります。利用者が問い合わせできる窓口や、担当外だった場合のエスカレーション方法も決めておく必要があります。

提供時期と対象環境

ロードマップID 564615の公開情報は次のとおりです。

確認項目公開情報
ロードマップID564615
公開・更新日2026年6月10日
状態In development
パブリックプレビュー2026年6月予定
一般提供2026年12月予定
対象クラウドWorldwide(Standard Multi-Tenant)
プラットフォームWeb
対象サービスMicrosoft Purview

2026年6月時点では開発中であり、プレビューおよび一般提供の日程は予定です。Microsoft 365 Roadmapの提供日は見込みであり、延期や内容変更が発生する可能性があります。(Microsoft)

導入期限や強制的な切り替え日は発表されていません。一般提供予定の2026年12月は、移行期限ではなくリリース予定時期です。

利用前に確認すべきライセンスと料金

ロードマップ項目には、この機能専用の追加料金や専用SKUは記載されていません。ただし、Data Security Triage Agentの利用には、次の環境が必要です。

  • Microsoft Purview Data Loss Preventionを利用できるライセンス
  • Microsoft Security Copilotを利用できる環境
  • Security Compute Unit(SCU)の容量
  • Teamsを利用できる対象ユーザー環境

エージェントはアラートの処理時にSCUを消費します。消費量は、処理するアラート数や内容によって変わるため、固定費だけで判断できません。(Microsoft Learn)

Microsoft 365 E5またはE7では、契約ユーザー数に応じたSecurity CopilotのSCUが含まれる場合があります。対象外のライセンスでは、Security CopilotのオンボードとSCUのプロビジョニングが必要です。(Microsoft Learn)

また、Security Copilotではパブリックプレビュー機能もSCU消費の対象です。「プレビューだから無償」とは限らないため、次の場所を確認してください。(Microsoft Learn)

  • Security Copilotの「Usage monitoring」
  • Microsoft 365管理センターの契約ライセンス
  • Azure側のSecurity Copilot容量と請求設定
  • Purviewの「Agents」から確認できる使用状況

本番展開前に、1週間あたりの対象アラート数とSCU消費量をパイロット環境で計測すると、予算を見積もりやすくなります。

Data Security Triage Agentの設定手順

Security Copilotの前提条件を確認する

Data Security Triage AgentはMicrosoft Security Copilot上で動作します。次の設定を確認します。

  • Security Copilotへのオンボードが完了している
  • Microsoft 365データ共有が有効になっている
  • Security CopilotでMicrosoft Purviewソースが有効になっている
  • DLP管理とエージェント管理に必要な権限が割り当てられている
  • SCUを利用できる状態になっている

エージェントはテナント内に1つだけ展開できます。PurviewまたはMicrosoft Defender XDRのどちらから展開しても、設定の編集や無効化はMicrosoft Purviewポータルで行います。(Microsoft Learn)

Purviewでエージェントを展開する

Microsoft Purviewポータルで、次の順に操作します。

  1. 「Agents」を開く
  2. 「Explore agents」を選択する
  3. DLPのTriage Agentを開く
  4. 「Setup」を選択する
  5. 自動実行または手動実行を選ぶ
  6. トリアージするアラートの期間を設定する
  7. 「Remediation reminders in Microsoft Teams」を有効にする
  8. リマインダーを継続する日数を設定する
  9. 対象DLPポリシーを選択する
  10. エージェントを開始する

アラート期間は、新規アラートのみ、過去24時間、48時間、72時間、7日、14日、21日、30日から選択できます。セットアップ完了後、通常は30~60分程度でエージェントがアラートの処理を開始します。(Microsoft Learn)

Teams管理センターでアプリを許可する

Teams管理センターでは、2つの設定が必要です。

組織全体のMicrosoftアプリを有効にする

  1. Teams管理センターを開く
  2. 「Teams apps」から「Manage apps」を開く
  3. 「Actions」から「Org-wide app settings」を選択する
  4. Microsoft appsをオンにする
  5. 設定を保存する

Data Security Triage Agentを利用可能にする

  1. 「Teams apps」から「Manage apps」を開く
  2. 「Data Security Triage Agent」を検索する
  3. 「Users and groups」を開く
  4. Availabilityが利用可能になっていることを確認する

Data Security Triage Agentアプリを、事前に各ユーザーへインストールする必要はありません。修復メッセージが初めて送信される際に、Microsoft Purviewが対象ユーザーへアプリを自動的にインストールします。(Microsoft Learn)

安全に導入するためのパイロット手順

最初から全社のDLPポリシーを対象にすると、想定以上の通知や問い合わせが発生する可能性があります。次の順序で小さく始めるのが安全です。

段階実施内容確認する指標
対象選定機密情報の種類とSharePointサイトを限定想定対象ファイル数
ポリシー設定限定したDLPポリシーをエージェント対象にするアラート発生数
Teams制御検証ユーザーまたはグループだけにアプリを許可メッセージ到達率
利用者テスト承認済みのテストデータで通知を確認通知内容、分かりやすさ
修復テストファイルを修正して翌日の通知を確認リマインダー停止の有無
コスト確認Security Copilotの利用状況を確認SCU消費量
対象拡大部門やポリシーを段階的に追加修復率、問い合わせ件数

検証では、実在する個人情報や本物のパスワードを使用しないでください。社内で承認されたテストデータと、アクセスを限定した検証用サイトを利用します。

なお、Data Security Triage AgentはシミュレーションモードのDLPポリシーから発生したアラートを処理しません。パイロットでは、対象ユーザーと保存場所を十分に絞ったうえで、アクティブモードのポリシーを使用する必要があります。(Microsoft Learn)

更新や移行は必要か

この機能のために、SharePointやOneDriveのファイルを別の場所へ移行する必要はありません。Teamsクライアントへのアプリの一括インストールも不要です。

既存環境で主に必要になるのは、次の設定変更です。

  • Data Security Triage Agentの展開
  • Security CopilotとSCUの確認
  • 修復リマインダーの有効化
  • 対象DLPポリシーの選択
  • Teamsアプリの利用許可
  • 利用者向け案内と問い合わせ窓口の整備

エージェントを管理者本人のユーザーIDで設定している場合、Microsoftは専用のAgent Identityへの移行を推奨しています。担当者の異動やアカウント無効化による停止を避けるためにも、既存設定を確認しておきましょう。(Microsoft Learn)

また、エージェントの対象ポリシーを後から追加しても、すでに生成済みのアラートには遡って適用されません。対象範囲の変更後に発生するアラートが処理対象になります。(Microsoft Learn)

Teams通知が届かない場合の確認ポイント

症状主な原因確認事項
誰にも通知されない組織全体のMicrosoftアプリが無効Org-wide app settingsを確認
誰にも通知されないTriage AgentアプリがブロックされているManage appsでAvailabilityを確認
一部のユーザーだけ届かないユーザーやグループ単位でアプリがブロックされているUsers and groupsを確認
古いアラートに通知されないポリシー範囲の変更前に生成された新しいアラートで再検証
対象ポリシーが表示されない対応していない条件や保存場所を使用しているポリシーのEligibilityを確認
アラートが分類されないシミュレーションモードや未対応条件アクティブモードと検出条件を確認
一部ファイルが処理されないエージェントの処理上限を超えているファイルサイズや対応条件を確認

Teams側では、組織全体のMicrosoftアプリを有効にしていても、Data Security Triage Agentアプリ自体が個別にブロックされていると通知されません。両方の設定を確認する必要があります。(Microsoft Learn)

また、Triage Agentがトリアージできるファイルサイズは最大2MBです。対応していない条件だけで構成されたアラートや、正常に分類できなかったアラートは、管理者が手動で確認する必要があります。(Microsoft Learn)

導入時に注意したい運用上のポイント

最終更新者が責任者とは限らない

通知先は、ファイル所有者やサイト管理者ではなく最終更新者です。共同編集しているファイルでは、機密情報を入力していないユーザーに通知されることも考えられます。

通知を受けたユーザーが担当外だった場合に、ファイル所有者や情報管理部門へ引き継げる手順を用意しておきましょう。

Teamsメッセージをフィッシングと誤解される可能性がある

突然「機密情報を削除してください」というTeamsメッセージが届くため、利用者が不審なメッセージと判断する可能性があります。

運用開始前に、アプリ名、通知内容、正しい確認方法を周知してください。通知から資格情報の入力やパスワードの送信を求めることはないと明示しておくと、安全に対応しやすくなります。

自動化後も管理者の確認は必要

AIによる優先順位付けは、すべてのアラートを完全に判断するものではありません。「Not categorized」に分類されたアラートや、対応していない条件のアラートは手動調査が必要です。

修復率だけでなく、誤検知率、通知先の適切さ、平均修復時間、SCU消費量も定期的に確認してください。

管理者が今確認すべきこと

今回の変更は、DLPアラートの検知だけで終わっていた運用を、Teamsによる利用者への修復依頼までつなげるものです。特に多数のSharePointサイトやOneDriveを運用している組織では、管理者の連絡と督促の負担を減らせる可能性があります。

まずは次の順に確認してください。

  1. Microsoft PurviewでDLPのTriage Agentを利用できるか確認する
  2. Microsoft Security CopilotとSCUの状態を確認する
  3. Teams管理者とアプリ許可設定を調整する
  4. 対象を絞ったアクティブモードのDLPポリシーを用意する
  5. 検証ユーザーで通知、修復、リマインダー停止を確認する
  6. SCU消費量と利用者からの問い合わせを評価する
  7. 問題がなければ段階的に対象を広げる

一般提供予定の2026年12月まで待つのではなく、プレビュー期間中に小規模な検証を行い、通知先のずれやTeams設定、利用者向け案内を整備しておくことが、スムーズな本番導入につながります。

この記事を書いた人

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows/Office(Teams・Excel)からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

コメント

コメントする

目次