Microsoft Purview の「Learn about data loss prevention」は、DLP（Data Loss Prevention：データ損失防止）をこれから設計する管理者だけでなく、既存の DLP ポリシーを見直す担当者にとっても重要な公式ドキュメントです。2026年6月26日に更新された内容で最初に押さえるべき点は、Microsoft Purview DLP の説明が「Microsoft 365 内の情報漏えい対策」だけでなく、エンドポイント、オンプレミス、クラウドアプリ、Copilot、AI アプリ、インライン Web トラフィックまで含めた保護ライフサイクルとして整理されていることです。(Microsoft Learn)
今回の更新は、既存ポリシーを直ちに移行させるような期限付きの廃止告知ではありません。ただし、DLP の影響範囲が広がっているため、管理者は「どの場所を監視しているか」「どの操作をブロックするか」「アラートを誰がどこで確認するか」を改めて棚卸しする必要があります。
Microsoft Purview DLPとは何か
Microsoft Purview DLP は、機密情報が不適切に共有・送信・コピー・アップロードされるリスクを減らすためのポリシーベースの保護機能です。たとえば、クレジットカード番号、医療情報、社会保障番号、財務データ、社外秘文書などを含むアイテムに対して、警告表示、共有ブロック、上書き理由の取得、監査ログ記録などを実行できます。(Microsoft Learn)
重要なのは、DLP が単純な文字列検索だけで動く仕組みではない点です。Microsoft Learn では、キーワード、正規表現、内部検証、近接する補助情報、機械学習などを組み合わせてコンテンツを分析すると説明されています。つまり、単に「マイナンバー」「Confidential」という文字を探すだけではなく、機密情報らしさや文脈も含めて判定する設計になっています。(Microsoft Learn)
実務では、DLP を「禁止ルール」としてだけ見ると失敗しやすくなります。最初から厳しくブロックすると、正当な業務フローまで止めてしまうためです。まずは機密情報の流れを可視化し、例外が必要な業務を確認し、段階的に制御を強める運用が現実的です。
2026年6月26日更新版で確認すべき主なポイント
今回の「Learn about data loss prevention」更新で特に確認したいのは、DLP の対象が大きく「Enterprise applications and devices」と「Inline web traffic」に分けて説明されている点です。従来の Exchange、SharePoint、OneDrive、Teams、Office アプリ、Windows/macOS デバイスだけでなく、非 Microsoft クラウドアプリ、オンプレミスファイル共有、Microsoft Fabric、Power BI、Microsoft 365 Copilot、Copilot Chat まで含めて整理されています。(Microsoft Learn)
| 確認項目 | 更新版での見方 | 管理者が取るべき行動 |
|---|---|---|
| 保護対象の範囲 | Microsoft 365、デバイス、オンプレミス、Fabric、Power BI、Copilot などを含めて整理 | 既存 DLP ポリシーが保護すべき場所を漏れなく対象にしているか確認する |
| Web/AI アプリ対策 | Inline web traffic として、ブラウザーやネットワーク経由の共有対策が説明されている | ChatGPT、Gemini、DeepSeek、Copilot などへの入力・アップロード対策を検討する |
| 導入手順 | Plan、Prepare、Deploy の DLP ライフサイクルで説明 | いきなりブロックせず、シミュレーションとチューニングを前提に進める |
| 監視・調査 | Audit log、Activity Explorer、DLP Alerts、Microsoft Defender ポータルとの連携を説明 | アラート確認場所、保存期間、担当者の運用手順を決める |
| 移行期限 | 対象ページでは期限付き移行の告知ではなく、DLP 全体像の説明として更新 | 既存ポリシーの即時移行ではなく、影響範囲と設定の棚卸しを優先する |
影響範囲：Microsoft 365内だけでなくAI・クラウドアプリまで見る
Microsoft Purview DLP の影響範囲は、Exchange Online のメールや SharePoint のファイル共有にとどまりません。公式ドキュメントでは、Exchange、SharePoint、OneDrive、Teams、Office アプリ、Windows 10/Windows 11、直近3バージョンの macOS、非 Microsoft クラウドアプリ、オンプレミスファイル共有、オンプレミス SharePoint、Microsoft Fabric、Power BI、Microsoft 365 Copilot と Copilot Chat が対象として挙げられています。(Microsoft Learn)
特に影響が大きいのは、生成 AI や非管理クラウドアプリへのデータ持ち出し対策です。公式ページでは Inline web traffic の対象例として、OpenAI ChatGPT、Google Gemini、DeepSeek、Microsoft Copilot、Microsoft Defender for Cloud Apps のクラウドアプリカタログに含まれる多数のクラウドアプリが示されています。(Microsoft Learn)
たとえば、次のような業務は DLP 見直しの対象になります。
| 業務シーン | 想定されるリスク | DLPで検討する制御 |
|---|---|---|
| 営業担当が顧客リストを外部メールに添付する | 個人情報や契約情報の社外送信 | 外部宛てメールで機密情報を検出し、警告またはブロックする |
| 開発者がログやソースコードを生成 AI に貼り付ける | API キー、顧客情報、未公開コードの漏えい | AI アプリへのテキスト送信やファイルアップロードを監視・制御する |
| 経理部門がクラウドストレージへファイルをアップロードする | 財務情報の非承認サービスへの持ち出し | 非管理クラウドアプリへのアップロードを監査またはブロックする |
| 社外共有済みの SharePoint ファイルに機密ラベルが付与される | 共有後に機密度が上がったファイルの露出 | ラベルや機密情報タイプを条件に外部アクセスを制限する |
ここでのポイントは、「保存場所」だけでなく「ユーザー操作」まで見ることです。ファイルが OneDrive に保存されているだけなら問題がなくても、そのファイルを USB にコピーする、外部メールに添付する、AI アプリにアップロードする、といった操作でリスクが発生します。
Inline web trafficが重要になる理由
2026年時点の DLP 設計では、Inline web traffic の扱いが重要です。Microsoft Purview Network Data Security では、SASE やセキュアブラウザーとの統合により、生成 AI、クラウドストレージ、クラウドメール、フォーム、SNS などへの通信を分類・保護する考え方が説明されています。(Microsoft Learn)
従来の DLP は、Microsoft 365 内のメールやファイル共有を中心に考えられがちでした。しかし実際の業務では、ユーザーがブラウザー、アプリ、API、アドインを通じて外部サービスに情報を送るケースが増えています。Microsoft Purview の What’s new でも、Microsoft Entra Global Secure Access と連携してテキストや AI インタラクションをネットワーク層で検査し、DLP ポリシーに基づいて制限できるプレビュー機能が紹介されています。(Microsoft Learn)
管理者が注意すべき点は、Inline web traffic 対策が「すべてのテナントで何もしなくても自動的に有効になる」ものではないことです。Network Data Security を使う場合、Microsoft Entra Global Secure Access、SASE、セキュアブラウザー、Security Store、collection policy、DLP policy、ライセンス、課金モデルなどの確認が必要になります。(Microsoft Learn)
設定変更で確認すべきポイント
今回の更新を受けて、管理者が既存テナントで確認すべき設定は大きく4つあります。
DLPポリシーの対象場所を確認する
まず、既存の DLP ポリシーがどの場所を対象にしているかを確認します。Exchange だけ、SharePoint だけ、OneDrive だけを対象にした古い設計のままだと、Teams、Endpoint、Microsoft 365 Copilot、Fabric、Power BI、非 Microsoft クラウドアプリなどが保護対象から漏れる可能性があります。
Microsoft Learn では、DLP ポリシー作成時に「何を監視するか」「管理スコープ」「どこを監視するか」「条件」「一致時のアクション」を選ぶ流れが説明されています。(Microsoft Learn)
実務では、次の順番で棚卸しすると効率的です。
| 確認順 | 見るべき項目 | 判断基準 |
|---|---|---|
| 1 | 機密情報タイプ | 個人情報、決済情報、財務情報、医療情報、契約情報など、自社で守るべき情報が定義されているか |
| 2 | 対象場所 | Exchange、SharePoint、OneDrive、Teams、Endpoint、Copilot、Power BI など必要な場所が含まれているか |
| 3 | 対象ユーザー | 全社対象か、部門別か、管理単位でスコープを分けるべきか |
| 4 | アクション | 監査のみ、警告、上書き許可、完全ブロックのどれが業務に合うか |
| 5 | 例外設定 | 役員、法務、経理、外部委託先連携など、正当な例外が整理されているか |
シミュレーションモードで影響を確認する
DLP ポリシーをいきなり本番でブロックにすると、正当な業務まで止まる可能性があります。Microsoft のデプロイ手順では、ポリシーの状態、アクション、スコープを組み合わせ、最小限の影響から段階的に展開することが推奨されています。(Microsoft Learn)
特に初回導入や対象範囲を拡大する場合は、次のように進めると失敗しにくくなります。
| フェーズ | 設定例 | 目的 |
|---|---|---|
| 検証 | ポリシーをオフまたはシミュレーション | 条件や対象場所が正しいか確認する |
| 可視化 | シミュレーションで監査のみ | どの業務で機密情報が動いているか把握する |
| 教育 | シミュレーション＋ポリシーヒント | ユーザーにリスクを知らせ、行動変容を促す |
| 段階適用 | パイロット部門でブロック | 誤検知や業務影響を確認する |
| 本番展開 | 全対象に適用 | 継続監視しながらルールを調整する |
注意点として、DLP のシミュレーションモードでは、ポリシーに定義したアクションは実際には適用されません。また、公式ドキュメントでは「Stop processing more rules」はシミュレーションモードでは有効にしていても動作しないと説明されています。検証時に「本番と完全に同じ挙動」と思い込まないことが重要です。(Microsoft Learn)
アラートと調査画面の使い分けを決める
Microsoft Purview DLP では、監視されたアクティビティが Microsoft 365 Audit log に記録され、Activity Explorer にもルーティングされます。DLP アラートは DLP Alerts dashboard で確認でき、Microsoft Defender ポータルにもルーティングされます。(Microsoft Learn)
運用上、特に見落としやすいのは保存期間です。公式ドキュメントでは、DLP アラートは Microsoft Defender ポータルでは6か月、Microsoft Purview の DLP alerts dashboard では30日間利用できると説明されています。(Microsoft Learn)
この違いを知らないと、月次レビューや四半期監査のタイミングで「Purview 側にアラートが残っていない」と混乱する可能性があります。監査やインシデント対応で長めに追跡する組織は、Microsoft Defender ポータル、Audit log、レポート出力、チケットシステム連携などを含めて運用設計しておくべきです。
権限と管理単位を見直す
DLP ポリシーの作成・展開には、適切な Microsoft Purview のロールが必要です。公式の作成・展開手順では、Compliance administrator、Compliance data administrator、Information Protection、Information Protection Admin、Security administrator などのロールグループが示されています。(Microsoft Learn)
大規模組織では、全社管理者がすべての DLP を管理するより、地域、部門、子会社、管理単位ごとに権限を分けたほうが安全です。ただし、管理単位で制限された管理者は、自分の管理単位に属する DLP アラートだけを確認する動きになるため、SOC やグローバル監査チームとの役割分担を明確にする必要があります。(Microsoft Learn)
移行期限はあるのか
2026年6月26日更新の「Learn about data loss prevention」は、DLP の全体像とライフサイクルを整理する公式説明であり、対象ページ内では既存 DLP ポリシーの強制移行期限や廃止日を告知する内容ではありません。したがって、管理者が最初にやるべきことは、急いで設定を変更することではなく、既存ポリシーと新しい保護範囲の差分を確認することです。(Microsoft Learn)
ただし、移行期限がないからといって放置してよいわけではありません。生成 AI、非管理クラウドアプリ、エンドポイント持ち出し、Copilot 連携など、情報の流れは変化しています。既存の DLP がメールと SharePoint だけを対象にしている場合、現代的な情報漏えいリスクを十分にカバーできていない可能性があります。
管理者が今すぐ確認すべきチェックリスト
以下のチェックリストは、グローバルテナントや複数拠点を管理する組織で特に有効です。
| チェック項目 | 確認内容 | 優先度 |
|---|---|---|
| DLP ポリシーの対象場所 | Exchange、SharePoint、OneDrive、Teams、Endpoint、Copilot、Power BI、Fabric、オンプレミスが必要に応じて含まれているか | 高 |
| AI アプリ利用状況 | ChatGPT、Gemini、Copilot、その他生成 AI への入力・アップロードを把握しているか | 高 |
| 非管理クラウドアプリ | 個人利用のクラウドストレージ、外部メール、フォーム、SNS などへの送信を把握しているか | 高 |
| ポリシー状態 | 監査のみ、シミュレーション、警告、ブロックの段階が適切か | 高 |
| アラート運用 | Purview と Defender のどちらで誰が確認するか決まっているか | 高 |
| 保存期間 | DLP alerts dashboard 30日、Defender ポータル6か月という違いを踏まえているか | 中 |
| ライセンス | Endpoint DLP、Copilot、Network Data Security など利用機能に必要なライセンスを確認しているか | 高 |
| 例外処理 | 正当な業務例外、上書き理由、承認フローが定義されているか | 中 |
| ユーザー教育 | ポリシーヒントや通知文が業務部門に伝わる表現になっているか | 中 |
| 監査証跡 | Audit log、Activity Explorer、PowerShell レポート、チケット管理の保存方針があるか | 中 |
Network Data Securityを使う場合の注意点
Inline web traffic や非管理 AI アプリ対策を強化する場合、Microsoft Purview Network Data Security の利用を検討することになります。公式ドキュメントでは、Microsoft Entra Global Secure Access、非 Microsoft SASE、セキュアブラウザーとの統合により、ネットワーク層での分類・保護を実現する考え方が説明されています。(Microsoft Learn)
ただし、ここにはいくつかの実務上の注意点があります。
| 注意点 | 内容 |
|---|---|
| ライセンス | Entra Global Secure Access を使う場合と、非 Microsoft SASE/セキュアブラウザーを使う場合で必要なライセンスや課金モデルが異なる |
| 課金 | Network Data Security ではリクエスト単位の従量課金モデルが説明されているため、検証段階で利用量を見積もる必要がある |
| 反映時間 | 統合後、ポリシー配布や初回データ表示に時間がかかる場合がある |
| B2B ゲスト | 公式ドキュメントでは、Purview network data security policies は B2B guest users には適用されないと説明されている |
| パートナー連携 | 非 Microsoft パートナーと統合する場合、ポリシー設定やユーザー識別子がパートナー側で扱われる可能性がある |
特にグローバル企業では、EU、米国、日本、APAC など地域ごとにデータ保護要件や外部サービス利用ルールが異なります。Network Data Security を導入する場合は、セキュリティ部門だけでなく、法務、プライバシー、労務、各国 IT 管理者を含めて設計するべきです。
失敗しやすいポイントと回避策
Microsoft Purview DLP の導入・見直しでは、機能そのものよりも運用設計で失敗することが多くあります。
| 失敗しやすいポイント | 起きる問題 | 回避策 |
|---|---|---|
| 最初から強いブロックを全社適用する | 正常な業務が止まり、ユーザーが回避策を探し始める | シミュレーション、パイロット、ポリシーヒントの順に展開する |
| 機密情報タイプを広くしすぎる | 誤検知が増え、アラートが確認されなくなる | 件数条件、近接条件、ラベル条件、部門スコープで絞る |
| アラート担当が決まっていない | 検知しても誰も対応しない | Purview、Defender、SOC、部門管理者の責任分界を決める |
| 例外申請を設計しない | 業務上必要な共有まで止まる | 上書き理由、承認フロー、例外グループを事前に定義する |
| AI アプリ利用を把握しない | ユーザーが機密情報を外部 AI に入力する | AI アプリ利用状況を可視化し、必要に応じて Inline web traffic 対策を検討する |
| ライセンスを後回しにする | 設計したポリシーが本番で使えない | 利用予定機能ごとに Microsoft 365、Purview、Entra、従量課金要件を確認する |
DLP は「禁止の仕組み」ではなく、「リスクの高い行動を見える化し、必要な場所で止める仕組み」として設計するほうが成功しやすくなります。特にポリシーヒントは、ユーザー教育にも使えるため、いきなりブロックする前に活用する価値があります。
グローバル管理者向けの実践的な進め方
グローバル向けに Microsoft Purview DLP を見直す場合は、国や拠点ごとに個別最適化しすぎる前に、まず全社共通の基準を作ることが重要です。
最初に守る情報を決める
最初からすべての機密情報を完璧に保護しようとすると、ポリシーが複雑になりすぎます。まずは、次のようにリスクが高い情報から優先順位を付けます。
| 優先度 | 情報の例 | 理由 |
|---|---|---|
| 高 | 個人情報、決済情報、認証情報、財務情報 | 漏えい時の法的・金銭的・信用リスクが大きい |
| 中 | 契約書、見積書、顧客提案資料、設計資料 | 業務上の共有が多く、誤共有が起きやすい |
| 中 | ソースコード、ログ、API キー | AI アプリや外部ツールに貼り付けられやすい |
| 低〜中 | 社内資料、会議メモ、一般的な業務文書 | ラベルや共有範囲に応じて段階的に制御する |
部門別にリスクを分ける
同じ DLP ポリシーでも、経理、法務、人事、開発、営業ではリスクが異なります。たとえば、人事部門では個人情報や給与情報、開発部門ではソースコードやシークレット、営業部門では顧客リストや契約条件が重要になります。
Microsoft Purview DLP では、ユーザー、グループ、サイト、管理単位などでスコープを設計できます。大規模環境では、全社一律のブロックよりも、リスクの高い部門から段階的に強めるほうが現実的です。(Microsoft Learn)
監査から始めてチューニングする
最初の1〜2か月は、ブロックよりも可視化を重視します。Activity Explorer や DLP アラートで、どのユーザーが、どの場所で、どの機密情報に対して、どの操作をしているかを確認します。Microsoft Learn では、DLP の結果確認として Overview page、DLP Alerts、Activity Explorer、レポート用 PowerShell コマンドレットが説明されています。(Microsoft Learn)
確認すべき観点は次の通りです。
| 観点 | 見るべき内容 |
|---|---|
| 頻出する機密情報タイプ | 誤検知が多い情報タイプはないか |
| 頻出ユーザー・部門 | 特定部門に業務上の共有ニーズが集中していないか |
| 頻出アクション | 外部共有、USB コピー、クリップボードコピー、AI アップロードなど何が多いか |
| 上書き理由 | 正当な理由か、ルールを回避するための形式的な理由か |
| ルール解除イベント | コンテンツ変更やポリシー変更で DLP ルールが適用されなくなったケースがないか |
DLP Rule Undo event は、以前一致していた DLP ルールが、コンテンツ変更やポリシー変更による再評価で適用されなくなった場合に発生します。ルールが「解除された」イベントも、誤検知削減やポリシー調整の判断材料になります。(Microsoft Learn)
関連する2026年のDLP更新も確認する
「Learn about data loss prevention」だけでなく、Microsoft Purview の What’s new では、2026年6月の Data Loss Prevention 関連更新として、Endpoint DLP デバイス属性データを Advanced Hunting で確認できる機能、デバイススコープを使った DLP ポリシー作成、Microsoft 365 Copilot と Copilot Chat 向けの外部メール条件、Exchange DLP イベントの条件一致情報強化などが紹介されています。(Microsoft Learn)
これらは、DLP を単なる「ファイル共有のブロック」から、より細かい調査・分析・条件設計へ進めるための更新です。特に Endpoint DLP を使っている組織では、Advanced Hunting による大規模なデバイス属性確認が運用効率に影響します。
2026年7月には、Microsoft Entra Global Secure Access と連携してテキストや AI インタラクションをネットワーク層で検査し、DLP ポリシーに基づく制御を行うプレビュー機能も What’s new に掲載されています。AI 利用を許可しながら機密情報を守る方針の組織は、DLP、Insider Risk Management、DSPM for AI、Network Data Security を個別機能ではなく一体のデータセキュリティ基盤として見直す必要があります。(Microsoft Learn)
まとめ：まずはDLPの対象範囲と運用を棚卸しする
2026年6月26日に更新された Microsoft Purview の「Learn about data loss prevention」は、DLP の基本説明に見えますが、管理者にとっては現在の情報漏えい対策を見直すためのチェックポイント集として読むべき内容です。特に、Enterprise applications and devices と Inline web traffic の2軸で DLP を捉え直すことが重要です。(Microsoft Learn)
すぐに確認すべきことは、既存ポリシーの対象場所、AI・クラウドアプリへのデータ送信、Endpoint DLP の適用範囲、アラートの確認場所、シミュレーションから本番適用までの手順です。移行期限に追われる更新ではありませんが、生成 AI や非管理クラウドアプリの利用が進んでいる組織では、従来の DLP 設計では守り切れない領域が出てきます。
次のアクションとしては、まず既存 DLP ポリシーを一覧化し、対象場所・条件・アクション・アラート担当者を表にまとめてください。そのうえで、AI アプリ、外部クラウド、Endpoint、Copilot を含む業務フローを確認し、シミュレーションモードで影響を測定するところから始めるのが安全です。
コメント