Microsoft Purview の「Endpoint DLP policy scenarios in Microsoft Purview」は、Endpoint DLP の設定手順そのものを置き換える告知ではなく、監査、アラート、ブロック、例外、ブラウザー制御、OneDrive 自動検疫、ネットワーク条件別制御を“シナリオ別にどう組み合わせるか”を整理した公式ガイダンスです。2026年6月26日に更新された公式情報では、すぐに移行しなければならない期限や既存ポリシーを強制変更する内容ではなく、管理者が既存の Endpoint DLP 設計を見直すための実務的な判断材料として読むべき内容になっています。(Microsoft Learn)
特に重要なのは、Microsoft Purview Endpoint DLP を「とりあえずブロックする機能」としてではなく、まず可視化し、影響を確認し、段階的に制御を強める仕組みとして扱う点です。この記事では、更新された公式シナリオをもとに、影響範囲、設定変更の考え方、移行期限の有無、管理者が確認すべきポイントを実務目線で整理します。
Microsoft Purview の Endpoint DLP policy scenarios とは
「Endpoint DLP policy scenarios in Microsoft Purview」は、Microsoft Purview Data Loss Prevention のうち、PC や Mac などのエンドポイント上で発生する機密データの利用・共有・持ち出しを制御するためのシナリオ集です。
公式ページでは、Endpoint DLP を使って組織デバイス上の機密情報を保護するために、DLP ポリシーの作成・変更を「監査」「アラート」「ブロック」「アクセス制御」などの実務シナリオに分けて説明しています。対象は、デバイス上のユーザー操作だけでなく、ブラウザー、クラウドサービス、プリンター、OneDrive 同期、VPN など、データが外部へ出ていく経路全体です。(Microsoft Learn)
ただし、ここで注意すべき点があります。公式ページ自身も、これらの Endpoint DLP シナリオは DLP ポリシー作成・調整の正式な汎用手順ではないと明記しています。一般的な設計や展開は、Microsoft Purview DLP の基本ドキュメントやポリシー作成手順と併せて確認する必要があります。(Microsoft Learn)
つまり、この更新を読むときの正しい姿勢は「新機能が追加されたからすぐ有効化する」ではありません。自社のデータ持ち出しリスクに対して、どのシナリオを優先してテストすべきかを決めるための実装ガイドとして読むのが適切です。
今回の更新ポイントを一言で整理
今回の更新ポイントは、Endpoint DLP の個別機能を単体で説明するのではなく、実際の管理者が遭遇しやすい業務シーンに沿って、ポリシー設計からテスト、運用確認までの流れを整理した点です。
公式ページでは、以下のようなシナリオが案内されています。(Microsoft Learn)
| シナリオ | 主な目的 | 管理者が見るべきポイント |
|---|---|---|
| テンプレートを使った監査モード | まず影響を可視化する | 本番ブロック前に Activity explorer でイベントを確認する |
| プリンター制御 | 承認済みプリンターだけ許可する | プリンターグループと例外設定の設計 |
| PII 検出とアラート | 個人情報の検出時に管理者へ通知する | アラート頻度と通知先の調整 |
| ブロックと上書き許可 | 高リスク操作を止めつつ業務例外を認める | 正当化理由の取得と監査ログ確認 |
| センシティブサービスドメイン制御 | 特定サイトでのコピー、印刷、保存を制御する | ブラウザー対応とドメイングループ設計 |
| ブラウザーへの貼り付け制御 | Webフォームやクラウドアプリへの貼り付けを制御する | 貼り付け先サイトごとの監査・警告・ブロック |
| OneDrive 同期の自動検疫 | 高機密ファイルの同期を防ぐ | 制限アプリ、検疫先、ユーザー通知 |
| 未承認クラウドサービス制御 | 承認されていないクラウドへのアップロードを抑止する | まず監査し、段階的にブロックへ移行する |
| ネットワーク例外 | VPN や社内ネットワーク条件で制御を変える | VPN 優先順位と例外の上書きに注意 |
これらは単なる設定例ではなく、Endpoint DLP の運用成熟度を上げるための段階的なモデルです。特にグローバル企業では、国・地域ごとに個人情報、機密ラベル、利用クラウドサービス、リモートワーク環境が異なるため、「一律ブロック」よりも「監査から始めて、リスクの高い経路から制御する」進め方が現実的です。
影響範囲：対象は Devices ロケーションの Endpoint DLP
今回のシナリオで中心になるのは、Microsoft Purview DLP ポリシーの Devices ロケーションです。Endpoint DLP は、オンボード済みの Windows 10/11、macOS の直近3つのメジャーバージョン、一定の Windows Server バージョンに対して、機密アイテムの利用状況を可視化し、DLP ポリシーに基づく制御を適用します。(Microsoft Learn)
Endpoint DLP の対象範囲を整理すると、次のようになります。
| 項目 | 影響を受ける範囲 |
|---|---|
| 対象サービス | Microsoft Purview Data Loss Prevention、Endpoint DLP、Activity explorer、DLP alerts |
| 主な対象デバイス | オンボード済み Windows 10/11、macOS、Windows Server 2019 以降の一部構成 |
| 主な対象操作 | コピー、印刷、USB へのコピー、ネットワーク共有、RDP、Bluetooth、ブラウザーへの貼り付け、クラウドアップロードなど |
| 主な対象データ | 機密情報の種類、秘密度ラベル、トレーニング可能分類子、カスタム分類条件に一致するファイル |
| 影響を受ける利用者 | DLP ポリシーのユーザースコープとデバイススコープの両方に含まれるユーザー |
| 管理者が確認する画面 | Microsoft Purview portal、Data loss prevention、Endpoint settings、Activity explorer、DLP アラート |
重要なのは、Endpoint DLP のポリシー適用はユーザーとデバイスの両方のスコープで判断される点です。Microsoft は、エンドポイントに DLP ポリシーを適用するには、ユーザーとデバイスの両方がポリシースコープに含まれている必要があると説明しています。(Microsoft Learn)
このため、グローバル展開では「日本法人のユーザーだけ対象にしたつもりが、海外拠点の共有端末にも影響する」「テストユーザーだけにしたつもりが、対象デバイスの条件で想定外の挙動になる」といったミスが起きやすくなります。ポリシーを作成する前に、対象ユーザー、対象デバイス、除外対象を必ずセットで確認してください。
設定変更の要点：いきなりブロックせず段階的に進める
今回の公式シナリオ全体に共通する考え方は、監査から始め、アラートで検知精度を確認し、必要な経路だけブロックまたはブロック上書き許可へ進めるという流れです。
まずは監査モードで現状を把握する
最初のシナリオでは、U.S. PII Data Enhanced テンプレートを使い、Endpoint DLP デバイス上の機密データ利用を audit-only、つまりシミュレーションに近い形で可視化します。ユーザー操作は制限せず、ポリシーヒントと Activity explorer を使って、どのような操作が検出されるかを確認する構成です。(Microsoft Learn)
実務では、いきなりブロックを有効化すると問い合わせが急増します。特に人事、法務、経理、営業部門では、外部共有、印刷、クラウドアップロードが業務に組み込まれている場合があります。最初の1〜2週間は、以下の観点で監査ログを見るのが現実的です。
| 確認項目 | 見るべき内容 |
|---|---|
| 頻出ユーザー | 特定部門に検出が集中していないか |
| 頻出操作 | 印刷、コピー、クラウドアップロード、ブラウザー貼り付けのどれが多いか |
| 対象ファイル | 本当に保護すべきファイルか、誤検知が多いか |
| 発生時間帯 | 定常業務か、例外的な持ち出し行動か |
| 宛先 | 承認済みサービスか、個人利用系サービスか |
監査モードは「弱い設定」ではありません。本番制御を失敗させないための調査フェーズです。ここを省略すると、正当な業務まで止める DLP ポリシーになりやすくなります。
アラートは“毎回通知”が最適とは限らない
PII 検出とアラートのシナリオでは、既存の監査ポリシーを編集し、ルール一致時に管理者へアラートを送る構成が示されています。例では、アクティビティがルールに一致するたびにアラートを送信する設定が使われています。(Microsoft Learn)
ただし、本番環境で「毎回通知」をそのまま使うと、通知過多になり、重要なイベントが埋もれる可能性があります。特にグローバル環境では、時差によりアラートが24時間発生し続けるため、SOC や情報システム部門の運用体制に合わせた設計が必要です。
判断基準はシンプルです。重大な情報、少数の特権ユーザー、外部共有のような高リスク操作は即時通知に向いています。一方、日常的に発生する低リスク操作は、Activity explorer での定期レビューや集約アラートの方が運用しやすい場合があります。
ブロックは“上書き許可”を組み合わせると定着しやすい
ブロックと上書き許可のシナリオでは、U.S. PII データの外部共有をブロックしつつ、正当な理由がある場合にはユーザーが上書きできる構成が示されています。上書き時にはユーザーの正当化理由を取得し、Activity explorer でブロックや上書きイベントを確認できます。(Microsoft Learn)
これは、グローバル企業で特に有効です。国や部門によって、個人情報の取り扱い手順や顧客対応フローが異なるため、完全ブロックだけでは業務が止まるケースがあります。最初は「Block with override」で理由を記録し、例外理由が妥当かを分析してから、特定経路だけ完全ブロックへ進める方が安全です。
ただし、上書き許可を入れる場合は、ユーザー教育が不可欠です。「理由を書けば何でも通せる」と受け取られると、DLP の抑止力が弱まります。ポリシーヒントには、禁止理由、許可される例外、問い合わせ先を短く明記してください。
シナリオ別に見る管理者の確認ポイント
プリンター制御：承認済みプリンターだけを例外にする
プリンター制御のシナリオでは、法務関連コンテンツを含む文書の印刷を原則ブロックし、承認済みの法務部門プリンターだけ許可する例が示されています。プリンターグループは、フレンドリ名、USB 製品 ID、USB ベンダー ID、IP 範囲、Universal Print、企業プリンター、ローカル印刷などで定義できます。(Microsoft Learn)
この設定で失敗しやすいのは、プリンター名だけで管理しようとすることです。拠点や端末によって表示名が微妙に異なると、想定した例外が効かない場合があります。グローバル展開では、IP 範囲、Universal Print、拠点別プリンター命名規則をあわせて整理してからグループ化するのが安全です。
また、公式シナリオでは、許可されたプリンターへの印刷は監査ログに記録される一方、アラートや通知は生成されないと説明されています。許可した操作も定期的に監査したい場合は、Activity explorer で確認する運用を組み込む必要があります。(Microsoft Learn)
センシティブサービスドメイン：Web 利用時のコピー・印刷・保存を制御する
センシティブサービスドメインのシナリオでは、特定の Web サイトを定義し、そのサイトにアクセスしたユーザーのコピー、印刷、ローカル保存などを監査または制限できます。Microsoft Edge、Chrome、Firefox、Safari などのブラウザー対応が説明されており、Chrome や Firefox では Microsoft Purview 拡張機能の扱いに注意が必要です。(Microsoft Learn)
このシナリオは、SaaS 利用が多い企業に向いています。たとえば、人事システム、契約管理システム、CRM、サポート管理ツールなど、機密情報をブラウザー上で扱うサービスでは、ファイルの外部共有だけでなく、画面上の情報をコピーして別の場所へ貼り付ける行為もリスクになります。
設定時は、ドメインを大きく指定しすぎないことが重要です。*.contoso.com のようなワイルドカードは便利ですが、対象範囲が広くなりすぎると、想定外の社内ポータルや業務アプリまで制御対象になる可能性があります。まずは高リスクなサブドメインに限定し、ログを見ながら範囲を広げる方が安全です。
ブラウザーへの貼り付け制御：生成 AI や外部フォーム対策にも応用しやすい
ブラウザーへの貼り付け制御では、ユーザーが Web フォームやブラウザーアプリに情報を貼り付ける瞬間に内容を評価し、監査、警告、ブロックを行います。この評価は貼り付け元ファイルの分類とは独立して行われると説明されています。(Microsoft Learn)
この機能は、外部チャットサービス、翻訳サービス、生成 AI サービス、個人向けクラウドメモ、問い合わせフォームなどへの機密情報貼り付け対策に向いています。たとえば、顧客リストや契約書の一部を外部サイトへ貼り付ける行為は、ファイルアップロードより見落とされやすい経路です。
ただし、公式情報では、貼り付け時の分類に短い遅延が発生する可能性や、通知を減らすための工夫も説明されています。最新の Antimalware クライアントや Edge の利用、関連する Windows 更新プログラムの適用が推奨されています。(Microsoft Learn)
実務では、全サイトを一律ブロックするより、以下のように分類すると運用しやすくなります。
| サイト分類 | 推奨アクション | 例 |
|---|---|---|
| 承認済み業務サービス | 監査のみ、または許可 | 社内 SaaS、契約済みクラウド |
| 注意が必要な外部サービス | ブロック上書き許可 | 外部フォーム、取引先ポータル |
| 未承認・個人利用系サービス | ブロック | 個人クラウド、無許可 AI サービス |
| 調査中のサービス | 監査のみ | 新規導入候補の SaaS |
OneDrive 同期の自動検疫：同期ループと通知疲れを防ぐ
OneDrive 同期の自動検疫シナリオでは、Highly Confidential ラベルが付いたファイルを OneDrive などのクラウド同期アプリが処理しようとした場合に、ファイルを検疫フォルダーへ移動し、元の場所にプレースホルダーのテキストファイルを残す構成が示されています。これにより、同期クライアントが同じファイルを繰り返し同期しようとして通知が連続する問題を避けやすくなります。(Microsoft Learn)
このシナリオで特に確認すべきなのは、制限アプリグループです。公式例では OneDrive の Windows 実行ファイル onedrive.exe と macOS の OneDrive 実行パスが示され、Box、Dropbox、Google Drive、iCloud などの macOS パス例も掲載されています。(Microsoft Learn)
自社で使っているクラウド同期アプリが複数ある場合、OneDrive だけを制限しても、別の同期アプリ経由で持ち出される可能性があります。利用実態を確認し、承認済みクラウドと未承認クラウドを分けて管理してください。
また、公式手順では新しいポリシーの複製と適用に少なくとも1時間程度を見込む記述があります。テスト直後に効かないと判断せず、ポリシー反映時間を考慮して検証する必要があります。(Microsoft Learn)
未承認クラウドサービス：最初は監査から始める
未承認クラウドアプリ・サービスへの共有防止シナリオでは、制限対象となるクラウドサービスドメインを定義し、機密情報のアップロードや未許可ブラウザーからのアクセスを監査する構成が紹介されています。公式シナリオでは、初期段階では Audit only とし、ユーザー行動を把握してから段階的に厳格化できる設計が示されています。(Microsoft Learn)
このアプローチは、グローバル企業にとって現実的です。地域によって使われているクラウドストレージやファイル共有サービスが異なるため、最初から全面ブロックすると、現場で使われている正当な取引先ポータルまで止める可能性があります。
管理者は、監査期間中に以下を洗い出すとよいでしょう。
- 実際に使われている未承認クラウドサービス
- 部門ごとの利用理由
- 承認済み代替サービスの有無
- 機密情報を含むアップロードの頻度
- ブロックした場合に止まる業務プロセス
そのうえで、単に「禁止」ではなく、代替手段を提示することが重要です。DLP はルールだけで完結しません。ユーザーが安全な業務経路を選べる状態にして初めて、実効性が出ます。
ネットワーク例外：VPN と社内ネットワークで制御を変える
ネットワーク例外のシナリオでは、VPN 接続時と通常時でコピー操作などの制御を変える例が示されています。たとえば、通常時はクリップボードコピーを監査のみにし、特定 VPN 接続時は Block with override にする構成です。VPN 情報の取得には、Windows PowerShell の Get-VpnConnection や Get-NetConnectionProfile が使われます。(Microsoft Learn)
ここで最も重要なのは優先順位です。公式情報では、VPN 接続時のユーザー活動を制御したい場合、ネットワーク例外設定で VPN を選択し、VPN を最優先にする必要があると説明されています。そうしないと、Corporate network の設定が適用される可能性があります。(Microsoft Learn)
また、「Apply to all activities」を使うと、他の活動に設定していたネットワーク例外を上書きする可能性があります。印刷、ネットワーク共有、クリップボードなどで別々の例外を設計している場合は、最後に保存した設定が意図しない上書きをしていないか確認してください。(Microsoft Learn)
移行期限はあるのか
今回の「Endpoint DLP policy scenarios in Microsoft Purview」は、2026年6月26日に更新されたシナリオベースの公式ガイダンスです。少なくとも当該ページの内容からは、特定日までに既存ポリシーを移行しなければならない、あるいは旧設定が廃止されるという告知として読むべき記載は確認できません。(Microsoft Learn)
したがって、管理者が取るべき対応は「移行期限に追われて設定変更する」ことではなく、次の3点です。
| 確認項目 | 対応 |
|---|---|
| 既存ポリシーへの影響 | 自動的に変更される前提ではなく、シナリオを参考に自社ポリシーを棚卸しする |
| 新規設定の必要性 | 監査ログを見て、制御すべき経路を優先順位付けする |
| 展開タイミング | いきなり全社展開せず、テストユーザー、部門、地域単位で段階展開する |
ただし、Microsoft Purview や Microsoft 365 の管理画面、ライセンス、ブラウザー拡張、対応 OS は時期によって変更される可能性があります。実際に本番変更する前には、Microsoft Learn の該当ページ、Microsoft 365 管理センターのメッセージセンター、サービス説明を確認してください。
管理者が最初に確認すべきチェックリスト
Endpoint DLP のシナリオを本番環境に取り込む前に、以下を確認してください。
| チェック項目 | 確認内容 | 失敗しやすいポイント |
|---|---|---|
| ライセンス | Endpoint DLP を利用できる Microsoft 365 / Purview ライセンスか | テストユーザーだけ対象ライセンスが不足する |
| デバイスオンボード | Windows、macOS、VDI、サーバーが Purview に報告しているか | Activity explorer にイベントが出ない |
| ユーザー・デバイススコープ | 対象ユーザーと対象デバイスの両方が含まれているか | ユーザーだけ対象にしてポリシーが効かない |
| Activity explorer | 監査イベントを確認できる権限があるか | ロール不足で調査できない |
| 秘密度ラベル | Confidential、Highly Confidential などが発行済みか | ラベル条件に一致せず検出されない |
| 機密情報の種類 | 組み込み SIT かカスタム SIT か | 日本固有の番号や社内形式を拾えない |
| ブラウザー制御 | Edge、Chrome、Firefox、Safari の対応状況を確認したか | 拡張機能未導入で期待どおり制御できない |
| 例外グループ | プリンター、ドメイン、ネットワーク、アプリの例外が整理されているか | 許可範囲が広すぎる、または狭すぎる |
| 通知文 | ユーザーに何が起きたか伝わるか | 問い合わせ先がなく現場が混乱する |
| 段階展開 | 監査、警告、上書き許可、完全ブロックの順で進めるか | 初回から全社ブロックして業務停止する |
Activity explorer は、ラベル付きコンテンツに対する操作履歴を確認するための画面で、最大30日分のデータをレポートすると説明されています。調査時には、日付、アクティビティタイプ、場所、秘密度ラベル、ユーザー、デバイス名などのフィルターを使えます。(Microsoft Learn)
実務でおすすめの展開順序
Endpoint DLP の展開は、次の順序で進めると失敗しにくくなります。
小さく可視化する
最初は、対象をテストユーザー、特定部門、特定デバイスに絞ります。PII、機密ラベル、法務文書など、検出条件も広げすぎないことが重要です。ここではブロックせず、Activity explorer で実際の業務パターンを確認します。
高リスク経路を特定する
監査ログから、USB、印刷、個人クラウド、ブラウザー貼り付け、OneDrive 同期、ネットワーク共有のどれが主要リスクかを見ます。全機能を一度に有効化するのではなく、実際に発生している経路から制御する方が効果的です。
警告または上書き許可に進める
業務影響がある操作は、完全ブロックの前に Block with override を使います。ユーザーに理由を書かせることで、業務上必要な例外と危険な持ち出しを分けて分析できます。
完全ブロックは限定して使う
完全ブロックは、個人クラウドへの機密情報アップロード、未承認アプリでの高機密ファイル同期、特定部門以外の印刷など、リスクと代替手段が明確な場所に限定するのが現実的です。
運用レビューを定例化する
DLP ポリシーは一度作って終わりではありません。組織変更、新しい SaaS、拠点追加、ブラウザー更新、OS 更新によって、最適な設定は変わります。少なくとも月次で、アラート、上書き理由、誤検知、例外申請をレビューする運用を作るべきです。
グローバル企業で特に注意したいポイント
グローバル環境では、Endpoint DLP の設計が日本国内だけの前提では通用しません。特に注意すべきなのは、地域ごとの法令、業務慣行、利用 SaaS、言語、端末管理方式の違いです。
たとえば、日本ではマイナンバーや顧客情報、米国では SSN や HIPAA 関連情報、EU では GDPR 対象の個人データなど、重点的に保護すべき情報が異なります。公式シナリオでは U.S. PII Data Enhanced が例として使われていますが、日本企業がそのまま使うだけでは十分とは限りません。自社で保護すべき情報に合わせて、機密情報の種類、秘密度ラベル、カスタム分類子を見直す必要があります。
また、国や地域によって利用できるクラウドサービスや業務上必要な外部ポータルが違う場合もあります。未承認クラウドサービスを一律でブロックすると、海外拠点の正当な取引先連携が止まることがあります。地域別の例外グループ、段階的な監査期間、現地 IT とのレビューを組み込むと安全です。
今回の更新を受けて取るべき次のアクション
今回の Microsoft Purview Endpoint DLP シナリオ更新は、緊急の移行対応というより、Endpoint DLP を実務で使いこなすための設計ガイドとして重要です。管理者は、次の順序で対応するとよいでしょう。
- 既存の DLP ポリシーで Devices ロケーションを使っているか確認する
- Activity explorer に対象デバイスのイベントが出ているか確認する
- 監査モードで PII、機密ラベル、主要部門の検出状況を確認する
- 印刷、クラウドアップロード、ブラウザー貼り付け、OneDrive 同期、VPN 条件のどれを優先制御するか決める
- ブロック前に、上書き許可、例外グループ、通知文、問い合わせ先を整備する
- テストユーザーまたは一部部門で検証してから、地域・部門単位で展開する
Endpoint DLP は、強く設定すれば安全になるという単純な機能ではありません。監査で実態を把握し、アラートで運用できる範囲を見極め、業務例外を設計したうえで、リスクの高い経路から制御することが成功の近道です。今回の公式シナリオは、そのための判断材料として活用できます。
コメント