Microsoft Purview の「Get started with endpoint data loss prevention」は、2026年6月26日に更新された Endpoint DLP の導入ガイドです。今回まず押さえるべき結論は、Endpoint DLP を「端末上のファイル操作を監視し、必要に応じて監査・警告・ブロックなどの保護アクションを適用する仕組み」として、オンボード済みデバイス、プロキシ通信、ポリシーのスコープ、仮想環境の制限を見直すことです。該当ページでは強制的な移行期限や廃止期限は明記されていないため、急な移行作業よりも、既存の DLP ポリシーが意図しないユーザーや端末に適用されていないかを優先して確認するのが現実的です。(Microsoft Learn)
Microsoft Purview Endpoint DLP の更新ポイントを先に整理
Microsoft Purview の Endpoint DLP は、Microsoft 365 上の DLP 機能をエンドポイント端末まで拡張し、機密情報を含むファイルがローカル端末でどのように利用・共有されているかを可視化し、ポリシーに応じて制御する機能です。公式情報では、オンボード済みの Windows 10、Windows 11、macOS デバイスを対象に、機密アイテムの使用や共有を検出できると説明されています。(Microsoft Learn)
| 確認項目 | 今回の見方 | 管理者が取るべき対応 |
|---|---|---|
| 更新日 | 公式ページは 2026年6月26日更新 | 社内手順書や運用チェックリストの前提情報を更新する |
| 影響範囲 | Windows 10/11、macOS、VDI などのオンボード済み端末が中心 | 対象端末、OS、管理方式、仮想環境の有無を棚卸しする |
| 設定変更 | 端末オンボーディング、プロキシ通信、Endpoint settings、DLP ポリシースコープが重要 | 既存設定をそのまま本番ブロックに使わず、監査・シミュレーションから確認する |
| 移行期限 | 該当ページ内に強制移行期限は示されていない | 期限対応ではなく、誤検知・過剰ブロック・対象漏れの点検を優先する |
| 運用上の注意 | ユーザーとデバイスの両方でスコープが決まる | 対象外にしたいユーザーや端末は明示的に除外する |
Endpoint DLP は「USB制御だけ」ではない
Endpoint DLP というと、USB メモリへのコピー制御を思い浮かべる管理者は多いはずです。しかし、Microsoft Purview の Endpoint DLP は USB だけを対象にした機能ではありません。機密情報を含むファイルに対して、クラウドサービスへのアップロード、クリップボードへのコピー、ネットワーク共有へのコピー、印刷、Bluetooth アプリ、RDP、制限付きアプリからのアクセスなど、複数の操作を監査または制御できます。(Microsoft Learn)
たとえば、次のような使い方が現実的です。
| 利用シーン | Endpoint DLP で確認・制御したい操作 | 推奨される初期対応 |
|---|---|---|
| 経理部門の顧客データ持ち出し対策 | クレジットカード番号や口座情報を含むファイルの USB コピー、印刷、ネットワーク共有へのコピー | まず監査モードで実態を把握し、対象部門から段階的にブロックする |
| 生成AI・外部クラウドへのアップロード対策 | 機密情報を含むファイルの未承認クラウドサービスへのアップロード | サービスドメイン制御とブラウザ制御を組み合わせる |
| VDI 環境の情報漏えい対策 | 仮想デスクトップからローカル・ネットワーク側へのコピー | USB がネットワーク共有として扱われるケースを踏まえてルールを作る |
| macOS 利用者の管理 | macOS 端末上のファイル操作、アプリ経由のアクセス | Windows と同じ前提で考えず、対応機能と制限を個別に確認する |
ポイントは、Endpoint DLP を「端末の出口対策」として捉えることです。メールや SharePoint、OneDrive の DLP だけでは、ローカル保存後のコピー、印刷、別アプリ経由の操作まで十分に追えない場合があります。Endpoint DLP は、そうした端末側の行動を Activity explorer やアラートで確認し、必要に応じて保護アクションを適用するための機能です。
影響範囲：対象はオンボード済み端末とポリシースコープで決まる
今回の更新内容を読むうえで最も重要なのは、「Microsoft Purview にオンボードされている端末が対象になる」という点です。Windows 10/11 端末は、Group Policy、Microsoft Endpoint Configuration Manager、Microsoft Intune、ローカルスクリプト、非永続 VDI 用スクリプトなどの方法でオンボーディングできます。(Microsoft Learn)
また、macOS については Intune、Microsoft Defender for Endpoint が展開された Intune 管理端末、JAMF Pro、Microsoft Defender for Endpoint が展開された JAMF Pro 管理端末向けの手順が案内されています。オンボード後は、デバイス一覧に表示され、Activity explorer に監査アクティビティを報告し始めることが期待されます。(Microsoft Learn)
ユーザーとデバイスのスコープを混同しない
Endpoint DLP では、ポリシーの対象をユーザーとデバイスの組み合わせで構成できます。公式ドキュメントでは、サインインしているユーザーが必要条件を満たさないデバイスにポリシーをスコープする場合、ユーザーまたはデバイス、あるいはその両方を明示的に除外しないと、意図しないポリシー適用につながる可能性があると注意されています。(Microsoft Learn)
実務では、ここが最も事故につながりやすい箇所です。たとえば「経理部門だけ USB コピーをブロックする」つもりで設定したのに、共有 PC や VDI、ヘルプデスク用アカウントまで巻き込むと、業務停止に近い影響が出ることがあります。
確認すべき観点は次の通りです。
| 確認対象 | チェック内容 |
|---|---|
| ユーザー | 対象部門、対象グループ、例外ユーザーが正しく整理されているか |
| デバイス | 管理対象端末、共有端末、VDI、サーバーが混在していないか |
| 除外設定 | IT 管理用端末、検証端末、業務上例外が必要な端末を除外しているか |
| 適用状態 | 監査、警告、ブロックのどの段階で本番適用しているか |
仮想環境では USB とクリップボードの扱いに注意
公式ページでは、仮想マシンを Microsoft Purview ポータル上の監視対象デバイスとしてオンボードでき、オンボーディング手順自体に変更はないと説明されています。対象として、Azure Virtual Desktop、Windows 365、Citrix Virtual Apps and Desktops、Amazon WorkSpaces、Hyper-V などの仮想化環境が整理されています。(Microsoft Learn)
ただし、VDI 環境では通常の物理 PC と同じ感覚でポリシーを作ると失敗しやすくなります。特に重要なのは次の2点です。
| 注意点 | 実務上の意味 |
|---|---|
| AVD 環境では、ブラウザ経由の Copy to Clipboard 監視や Endpoint DLP 強制に制限がある | クリップボード制御を前提にしたルールだけでは漏れが出る可能性がある |
| 仮想環境の USB ストレージはネットワーク共有として扱われる | USB コピーを監視したい場合でも、Copy to network share アクティビティを含める必要がある |
つまり、VDI では「USB コピーをブロックしたいから USB のルールだけ設定する」では不十分な場合があります。仮想デスクトップでは、実際のイベント名や Activity explorer 上の見え方が物理端末と異なることを前提に、監査イベントを確認してから制御を強めるべきです。
設定変更で確認すべき Endpoint settings
Endpoint DLP の動作は、個別の DLP ポリシーだけでなく、Microsoft Purview ポータルの Endpoint settings によっても左右されます。公式ドキュメントでは、Endpoint settings からクラウドへの持ち出し制限、アプリごとの制限、Windows/macOS のファイルパス除外、ブラウザとドメインの制限、ポリシーヒントでの業務上の理由、Office・PDF・CSV ファイルの自動監査などを制御できると説明されています。設定場所は「Data loss prevention > Overview > Data loss prevention settings > Endpoint settings」です。(Microsoft Learn)
特に確認すべき項目は次の通りです。
| 設定項目 | 確認する理由 | 失敗しやすい例 |
|---|---|---|
| File path exclusions | 監視・アラート・強制を除外するパスを決める | C:\Users など広すぎる除外で重要ファイルが監視対象外になる |
| Restricted apps / app groups | 特定アプリからの機密ファイルアクセスを制御する | 実行ファイル名や macOS のパス指定を誤り、制御できない |
| Browser and domain restrictions | 外部クラウドや未承認サービスへのアップロードを制御する | Allow と Block の考え方を逆にして、想定外のドメインが許可される |
| Always audit file activity for devices | Office、PDF、CSV などの操作を常時監査するか決める | 「ポリシーに一致したイベントだけ見たい」のに大量の監査イベントが出る |
| Network share coverage | ネットワーク共有やマップドライブ上のファイルを対象にする | VDI やファイルサーバー利用時のコピーイベントを見落とす |
Endpoint settings は全体設定に近い性質を持つため、1つのポリシーだけを見ていても原因が分からないことがあります。アラートが多すぎる、逆にイベントが出ない、ブラウザ制御が効かないといった問題が起きた場合は、ポリシー条件だけでなく Endpoint settings も必ず確認してください。
プロキシと通信要件は導入前に検証する
Windows 10/11 端末をオンボードする場合、端末がクラウド DLP サービスと通信できることを確認する必要があります。Microsoft Endpoint 関連の技術は WinHTTP を使って Microsoft のクラウドサービスと通信し、この WinHTTP 設定は通常のブラウザ用プロキシ設定である WinINet とは独立しています。(Microsoft Learn)
企業ネットワークでは、ここが導入トラブルの典型です。利用者のブラウザではインターネットに接続できていても、LocalSystem コンテキストで動作する Endpoint DLP 側の通信がプロキシや SSL インスペクションで止まっている場合があります。
確認すべきポイントは次の通りです。
| 確認項目 | 実務上のチェック |
|---|---|
| プロキシ方式 | 透過プロキシ、WPAD、静的プロキシのどれを使っているか |
| WinHTTP 設定 | ブラウザではなくシステムコンテキストの通信が通るか |
| 許可 URL | Microsoft Defender for Endpoint サービス URL への通信が遮断されていないか |
| SSL インスペクション | 対象ドメインが HTTPS スキャンで妨げられていないか |
| 接続検証 | MDATP Client Analyzer などで端末側の疎通結果を確認したか |
Endpoint DLP は「ポリシーを作れば動く」機能ではありません。端末がクラウド側の分類・評価サービスと適切に通信できないと、監査イベントの欠落やポリシー適用の遅れにつながります。
ポリシーは最初からブロックせず、監査から始める
DLP ポリシーの導入では、いきなり本番ブロックを有効にしないことが重要です。Microsoft の DLP ポリシー展開ガイドでも、スコープ、状態、アクションを組み合わせて段階的に展開し、影響の小さいシミュレーションモードから始めて本番適用へ進める考え方が示されています。(Microsoft Learn)
おすすめの進め方は次の通りです。
| 段階 | 設定の考え方 | 管理者が見るべきもの |
|---|---|---|
| 監査・シミュレーション | まず業務影響なしでイベントを集める | Activity explorer、アラート件数、対象ユーザー、ファイル種別 |
| パイロット | 一部部門・一部端末でポリシーヒントや警告を出す | 誤検知、業務例外、利用者からの問い合わせ |
| Block with override | 業務上の理由がある場合だけ上書きを許可する | 上書き理由、頻度、例外申請の妥当性 |
| Block | 持ち出しリスクが高い操作を本番ブロックする | 業務停止が起きていないか、例外ルールが過剰でないか |
特に、個人情報、決済情報、医療情報、研究開発データなどを扱う組織では、ブロックの強さだけでなく「なぜその操作を止めるのか」を利用者に説明できる設計が必要です。ポリシーヒント、業務上の理由、問い合わせ窓口を整えておくと、DLP が単なる邪魔な制限ではなく、データ保護のルールとして受け入れられやすくなります。
Activity explorer で確認すべきイベント
Endpoint DLP の効果を判断するには、Activity explorer の確認が欠かせません。Activity explorer はラベル付きコンテンツなどのアクティビティを確認する画面で、最大30日分の履歴ビューを提供し、日付範囲、アクティビティ種別、場所、秘密度ラベル、ユーザー、クライアント IP、デバイス名などのフィルターを使えます。Endpoint DLP を有効にすると、オンボード済みの Windows 10/11 および直近3つのメジャーリリースの macOS に関するデバイスレベルのアクティビティも含まれます。(Microsoft Learn)
管理者は、少なくとも次の観点で確認してください。
| 見るべき項目 | 判断ポイント |
|---|---|
| Activity type | USB、ネットワーク共有、印刷、アップロード、クリップボードなど、どの操作が多いか |
| User | 特定ユーザーや部門にイベントが偏っていないか |
| Device name | 共有端末、VDI、未想定端末が含まれていないか |
| Sensitive information type | 検出された機密情報の種類がポリシー意図と合っているか |
| Policy / Rule | 最も厳しいルールだけを見て誤解していないか |
| Destination | 持ち出し先が業務上必要なものか、未承認サービスか |
DLP は「ブロックできたか」だけで評価すると失敗します。実務では、監査データから通常業務と危険な操作を分け、例外を減らしながら制御を強めていくことが重要です。
管理者が確認すべきチェックリスト
Endpoint DLP の導入・見直しでは、次のチェックリストを使うと抜け漏れを減らせます。
| 分類 | 確認項目 |
|---|---|
| ライセンス・権限 | 対象テナントで必要な Microsoft 365 / Purview 関連ライセンスと管理者ロールを確認したか |
| デバイス | Windows、macOS、VDI、Windows Server などの対象端末を棚卸ししたか |
| オンボーディング | Intune、Group Policy、Configuration Manager、JAMF Pro など、展開方式を明確にしたか |
| 通信 | WinHTTP、プロキシ、SSL インスペクション、Microsoft サービス URL への疎通を確認したか |
| スコープ | ユーザーとデバイスの両方で、対象と除外が意図通りか |
| Endpoint settings | ファイルパス除外、ブラウザ制御、ドメイン制御、制限付きアプリを確認したか |
| ポリシー | 監査、警告、Block with override、Block の段階設計をしているか |
| 監視 | Activity explorer と DLP アラートでイベントを確認できるか |
| 利用者対応 | ポリシーヒント、上書き理由、問い合わせ先、例外申請ルールを用意したか |
| 運用改善 | 月次で誤検知、例外、イベント量、ブロック件数を見直す体制があるか |
よくある失敗と回避策
いきなり全社ブロックを有効にする
Endpoint DLP は強力な制御機能ですが、最初から全社に Block を適用すると、業務で必要な印刷、ネットワーク共有、クラウドアップロードまで止めてしまう可能性があります。最初は Audit only やシミュレーションで実態を把握し、対象部門や対象データを絞って強制に移るべきです。
デバイスだけ、またはユーザーだけで判断する
Endpoint DLP の適用は、ユーザーとデバイスの組み合わせで考える必要があります。共有端末、VDI、管理者用端末、委託先ユーザーがある環境では、グループ設計を曖昧にすると意図しない制御が発生します。対象外にしたいユーザーや端末は、暗黙的に外れると期待せず、明示的に除外してください。
除外パスを広くしすぎる
パフォーマンスや誤検知対策としてファイルパス除外は有効ですが、広く設定しすぎると監視対象から重要ファイルが外れます。たとえば一時フォルダーやアプリのキャッシュだけを除外するつもりが、ユーザープロファイル全体を除外してしまうと、DLP の意味が大きく薄れます。
未保存ファイルの扱いを誤解する
Endpoint DLP は、ローカル端末上で保存・分類されるファイルの扱いに注意が必要です。公式ドキュメントでは、データがローカルデバイス上のファイルとして保存されていない場合、Endpoint DLP はスキャンや分類ができないと説明されています。たとえば、Word で開いた文書を一度もローカル保存せずに USB へ直接保存するようなケースでは、検査やブロックの前提が変わります。(Microsoft Learn)
macOS と Windows を同じ前提で運用する
macOS も Endpoint DLP の対象ですが、すべての機能が Windows と同じように使えるわけではありません。たとえば、オフライン時の既存ポリシー適用に関する機能は Windows エンドポイント向けの説明であり、macOS エンドポイントではサポートされないとされています。(Microsoft Learn)
移行期限はあるのか
今回の「Get started with endpoint data loss prevention」更新ページを見る限り、特定日までに移行しなければならない、旧機能が廃止される、といった移行期限は示されていません。したがって、管理者が急いで行うべきことは「移行プロジェクトの開始」ではなく、Endpoint DLP の導入前提と既存設定の点検です。(Microsoft Learn)
ただし、期限がないから放置してよいという意味ではありません。DLP ポリシーは、組織変更、端末更新、VDI 導入、macOS 利用拡大、生成AIサービス利用などの影響を受けます。特に外部クラウドや未承認アプリへのアップロード対策を強める場合、Endpoint DLP のスコープと Endpoint settings を定期的に見直す必要があります。
また、ポリシー更新の反映にも時間差があります。Microsoft の説明では、Microsoft Purview ポータルでポリシーを更新した場合、サービス全体への同期には一般的に約1時間かかり、Authorized Groups の変更では24時間の同期が必要とされています。検証時は、設定直後に効かないと判断せず、同期時間を考慮して確認してください。(Microsoft Learn)
次に取るべき行動
Microsoft Purview の Endpoint DLP をこれから導入する管理者は、まず対象端末を棚卸しし、Windows、macOS、VDI、サーバーの管理方式を分けて整理してください。すでに導入済みの場合は、2026年6月26日更新の公式情報を前提に、ユーザーとデバイスのスコープ、プロキシ通信、Endpoint settings、Activity explorer のイベントを確認するのが優先です。
最初から完璧なブロックルールを作る必要はありません。監査で実態を把握し、部門単位でパイロット展開し、誤検知と例外を減らしながら Block with override、Block へ進めることが、業務影響を抑えながら情報漏えい対策を強化する近道です。
コメント