Microsoft PurviewでDLPポリシーを作成・展開する際に最も重要なのは、「いきなりブロックする」のではなく、状態・アクション・スコープを段階的に切り替えて、業務影響を確認しながら本番適用することです。2026年6月26日に更新されたMicrosoft Learnの「Create and deploy data loss prevention policies」では、DLPポリシーの一般的な作成シナリオと、安全に展開するための管理項目が整理されています。特に管理者は、シミュレーションモード、ポリシーヒント、パイロット展開、フル適用の順で進める設計に見直すべきです。(Microsoft Learn)
この記事では、Microsoft Purview Data Loss Prevention、いわゆるDLPポリシーの更新ポイントを、影響範囲、設定変更、移行期限の有無、管理者が確認すべき項目に分けて解説します。既存ポリシーを運用している組織、新規に情報漏えい対策を始める組織、海外拠点を含むグローバルテナントでDLPを展開する管理者が、次に何を確認すべきか分かる内容にまとめます。
Microsoft Purview DLPポリシー更新ポイントの要点
2026年6月26日更新の公式情報で押さえるべきポイントは、単なる「ポリシー作成手順」ではありません。Microsoft Purview DLPポリシーを、業務を止めずに本番展開するための考え方が、より明確に示されています。
公式ドキュメントでは、DLPポリシーには多くの構成オプションがあり、それぞれがポリシーの動作に影響すると説明されています。さらに、ポリシー設計と同じくらい「展開方法」が重要であり、ポリシーの状態、アクション、スコープを使って展開を制御する必要があるとされています。(Microsoft Learn)
| 確認項目 | 管理者が見るべきポイント |
|---|---|
| 影響範囲 | Exchange、SharePoint、OneDrive、Teams、デバイス、Power BI、Edge for Business経由のWebトラフィックなど |
| 設定変更の中心 | ポリシー状態、アクション、スコープを組み合わせた段階展開 |
| 推奨される展開方法 | Keep it offから開始し、シミュレーション、ポリシーヒント付きシミュレーション、フル適用へ進める |
| 移行期限 | 公式ページ上では、特定の日付までに移行が必要という期限は示されていない |
| 注意点 | いきなりBlockを有効化すると、業務プロセスを止める可能性がある |
今回の内容は「新しいボタンが追加された」というより、DLP運用の失敗を避けるための実務ガイドとして読むべきです。特に、情報漏えい対策を強化したい一方で、メール送信、外部共有、ファイル保存、クラウドアプリ利用などの日常業務を止めたくない組織に影響します。
影響範囲：DLPポリシーはMicrosoft 365全体とデバイス、Webトラフィックに関わる
Microsoft Purview DLPポリシーは、単にメールだけを監視する仕組みではありません。公式ドキュメントでは、Enterprise applications & devices向けのシナリオとして、クレジットカード番号のメール共有防止、SharePointとOneDriveでの外部共有防止、Endpoint DLPでスキャンできないファイルの保護、Power BIレポートの保護などが挙げられています。(Microsoft Learn)
さらに、Inline web traffic向けのシナリオとして、Microsoft Edge for Businessを利用した管理対象デバイスからの非管理AIアプリへの共有防止、クラウドアプリへの機密情報共有防止、Network Data Securityを使った非管理AIアプリへの共有防止が示されています。(Microsoft Learn)
| 領域 | 主な対象 | 実務上の影響 |
|---|---|---|
| Exchange Online | メール本文、添付ファイル | クレジットカード番号や個人情報を含むメール送信の監査・警告・ブロック |
| SharePoint / OneDrive | サイト、ドキュメント、共有リンク | 外部ユーザーへの共有制御、監査、例外設定 |
| Teams | チャット、チャネルメッセージ | 機密情報の投稿や共有に対する検知 |
| Devices | Windows、macOSなどのエンドポイント | コピー、印刷、USB、アプリ経由の持ち出し制御 |
| Power BI | レポート、データセット | 機密データを含むレポート共有の制御 |
| Edge for Business / Webトラフィック | クラウドアプリ、非管理AIアプリ | 生成AIやSaaSへの貼り付け・アップロード対策 |
グローバル企業では、地域ごとに業務プロセスや規制要件が異なります。たとえば、日本本社では個人情報、欧州拠点ではGDPR対応、米国拠点では医療・金融関連データの保護が優先される場合があります。DLPポリシーを一律に全社展開すると、ある地域では適切でも、別の地域では過剰な制御になることがあります。
そのため、Microsoft Purview DLPでは、対象場所を選ぶだけでなく、サイト、グループ、アカウント、配布グループ、メールボックス、デバイスなどを含める・除外する設定で、適用範囲を細かく調整することが重要です。(Microsoft Learn)
管理者が理解すべき3つの展開制御
公式ドキュメントでは、DLPポリシーの展開管理を「scope」「state」「actions」の3軸で考えることが推奨されています。ポイントは、影響が小さい状態から始め、段階的にフル適用へ進めることです。(Microsoft Learn)
ポリシー状態：本番適用前に必ずシミュレーションを使う
DLPポリシーの状態は、展開時の最も重要な制御項目です。作成直後のポリシーは、まずKeep it offの状態にして、関係者レビューと設定確認を行うのが安全です。公式ドキュメントでは、ポリシー状態として、Keep it off、Run the policy in simulation mode、Run the policy in simulation mode and show policy tips、Turn it on right awayが説明されています。(Microsoft Learn)
| 状態 | 使う場面 | ユーザー影響 |
|---|---|---|
| Keep it off | 作成直後、レビュー中、設定調整中 | なし |
| Run the policy in simulation mode | 影響範囲をデータで確認する段階 | アクションは実行されず、監査・分析が中心 |
| Run the policy in simulation mode and show policy tips | パイロットユーザーに注意喚起する段階 | ブロックはされないが、ポリシーヒントや通知で気づきを与える |
| Turn it on right away | 十分に検証した後の本番適用 | 設定したアクションが実際に適用される |
特に重要なのは、シミュレーションモードでは実際の強制アクションを実行せず、ポリシーが適用された場合の影響を確認できる点です。Microsoft Learnでは、シミュレーションモードは従来のTestおよびTest with policy tipsのポリシー状態を置き換えるものと説明されています。(Microsoft Learn)
アクション：最初からBlockにしない
DLPポリシーのアクションは、機密情報に対するユーザー操作が発生したときに何を行うかを決める設定です。公式ドキュメントでは、Allow、Audit only、Block with override、Blockが整理されています。Allowはデバイスを対象とするポリシーでのみ利用できる点にも注意が必要です。(Microsoft Learn)
| アクション | 内容 | 向いている場面 |
|---|---|---|
| Allow | 操作は許可し、監査データを取得する | デバイスを対象に、まず実態を把握したい場合 |
| Audit only | 操作は許可し、監査・通知・アラートを利用できる | 本番前の影響確認、ユーザー教育 |
| Block with override | 原則ブロックするが、ユーザーが理由を入力して上書き可能 | 誤検知を拾いながら制御を強めたい場合 |
| Block | 操作を完全にブロックする | 規制・契約・リスク上、例外を許容しにくい場合 |
実務では、最初からBlockを選ぶのは危険です。たとえば、経理部門が監査法人へクレジットカード関連データを送る正当な業務がある場合、外部送信を全面ブロックすると業務が止まります。このようなケースでは、まずAudit onlyで実態を把握し、必要に応じて特定ユーザーや特定ドメインを例外にする設計が現実的です。
Block with overrideは、現場からのフィードバックを得るうえで有効です。ユーザーが「なぜ上書きしたのか」を入力する運用にすれば、誤検知、例外業務、ルールの過不足を見つけやすくなります。
スコープ：広く検知し、狭く教育し、最後に広げる
スコープは、DLPポリシーをどの場所や対象に適用するかを決める設定です。公式ドキュメントでは、Exchange、SharePoint、Teams、Devicesなどの場所に対して、既定では選択した場所の全インスタンスが対象になり、必要に応じて含める・除外する設定で絞り込めると説明されています。(Microsoft Learn)
安全な考え方は、次の3段階です。
| 段階 | スコープの考え方 | 目的 |
|---|---|---|
| シミュレーション | 広めに設定して影響を把握する | どこでどの機密情報が検知されるかを見る |
| ポリシーヒント付きシミュレーション | パイロットグループに絞る | ユーザー教育と現場フィードバックを得る |
| 本番適用 | 設計時に意図した全対象へ広げる | 監査済みの制御を全体に適用する |
グローバル展開では、最初のパイロット対象を「全社のIT部門」だけにするより、実際に機密データを扱う業務部門を含める方が有効です。たとえば、法務、経理、人事、営業管理、カスタマーサポートなどです。これにより、机上の設定では見えない正当業務を早期に発見できます。
推奨されるDLPポリシー展開手順
Microsoft Learnでは、安全にDLPポリシーを展開する手順として、作成後のレビュー、シミュレーション、チューニング、ポリシーヒント付きシミュレーション、ユーザーフィードバックの収集、最後に本番適用という流れが示されています。(Microsoft Learn)
| 手順 | 実施内容 | 管理者の確認ポイント |
|---|---|---|
| 1 | ポリシーを作成し、Keep it offにする | 条件、対象場所、例外、通知文をレビューする |
| 2 | シミュレーションモードに変更する | どの場所で、どの種類の機密情報が検知されるか確認する |
| 3 | 検知結果をもとにチューニングする | 誤検知、過剰検知、対象外にすべき業務を洗い出す |
| 4 | ポリシーヒント付きシミュレーションにする | パイロットユーザーへ通知し、現場の反応を見る |
| 5 | フィードバックとアラートを確認する | 例外設定、通知文、教育コンテンツを調整する |
| 6 | Turn it on right awayに変更する | 本番適用後もアラートとDLP Activity explorerを監視する |
この手順で重要なのは、「シミュレーションで検知されたから、すぐにブロックする」という判断をしないことです。DLPで検知される行為には、危険な操作だけでなく、正当な業務も含まれます。
たとえば、次のような操作は、ルール上はリスクに見えても業務上は必要な場合があります。
- 監査法人への資料送付
- 海外子会社との契約書共有
- 委託先への個人情報を含むCSV送付
- カスタマーサポート部門による顧客情報の確認
- 経営会議用のPower BIレポート共有
DLPポリシーは、セキュリティ部門だけで完成させるものではありません。法務、コンプライアンス、業務部門、IT、場合によっては海外拠点の管理者も含めて、どこまでを許容し、どこからを止めるのかを決める必要があります。
シミュレーションモードで必ず確認したいポイント
シミュレーションモードは、DLPポリシーの品質を上げるための重要な機能です。公式ドキュメントでは、シミュレーション結果が本番ポリシーの結果とは別のダッシュボードで確認でき、影響を分離して評価できると説明されています。(Microsoft Learn)
また、シミュレーションは最大15日間実行され、結果データは30日間保持されます。SharePoint OnlineとOneDrive for Businessでは既存アイテムと新規・変更アイテムが評価されますが、Exchange、Teams、Devicesではシミュレーション開始後の新規アイテムが評価対象になります。(Microsoft Learn)
| 確認項目 | 見るべき理由 |
|---|---|
| 検知件数 | 想定より多すぎる場合、条件が広すぎる可能性がある |
| 検知場所 | SharePoint、OneDrive、メール、Teams、デバイスのどこで多いかを把握する |
| 機密情報の種類 | クレジットカード番号、個人情報、医療情報など、優先順位を決める |
| 誤検知 | 数字列や社内コードを機密情報として誤検知していないか確認する |
| 正当業務 | ブロックすると業務停止につながる操作がないか確認する |
| アラート量 | 運用チームが処理できる件数か確認する |
| 通知文 | ユーザーが次に何をすべきか分かる内容か確認する |
特に見落とされやすいのが、アラート量です。ポリシーを有効化した後に大量のアラートが発生しても、確認する担当者がいなければ運用は破綻します。DLPは「作って終わり」ではなく、アラート確認、例外判断、ユーザー教育、ルール改善まで含めて運用設計する必要があります。
プレビュー機能：DLPポリシー名とルール名の変更に注意
公式ドキュメントでは、プレビューとしてDLPポリシーとルールの表示名を変更できる旨が記載されています。名前を変更した場合、既存のActivity explorerイベント、アラート、監査レコードには以前の名前が残り、新しいレコードには変更後の名前が反映されます。既存レコード側の名前は、各アイテムがシステム上で保持期間を迎えるまで残ると説明されています。(Microsoft Learn)
この変更は便利ですが、運用上は注意が必要です。
| 注意点 | 実務上の対応 |
|---|---|
| 過去レコードの名前は自動的に新名称へ統一されない | 変更前後の名称対応表を残す |
| アラート検索で旧名と新名が混在する | 一定期間は両方の名前で検索する |
| 監査対応時に混乱しやすい | 変更日、変更者、変更理由を記録する |
| グローバル運用で名称ルールがばらつく | 国・部門・対象データを含む命名規則を定義する |
たとえば、「Credit Card DLP」という名前を「Global-Finance-CardData-DLP」に変更する場合、変更前のアラートは旧名で残る可能性があります。監査やインシデント調査で混乱しないよう、変更履歴をチケットや運用台帳に残しておくと安全です。
移行期限はあるのか
今回確認した公式ページでは、特定の日付までに既存DLPポリシーを移行しなければならないという期限は示されていません。したがって、管理者が直ちに全ポリシーを作り直す必要がある内容として読むべきではありません。(Microsoft Learn)
ただし、シミュレーションモードが従来のTestおよびTest with policy tipsのポリシー状態を置き換えると説明されている点は、既存運用を見直す材料になります。新規ポリシーや大きな変更を行う既存ポリシーでは、シミュレーションモードを前提にした展開プロセスへ揃えるのが現実的です。(Microsoft Learn)
| 既存環境の状態 | 対応方針 |
|---|---|
| 既存DLPポリシーが安定稼働している | すぐに作り直さず、名称・スコープ・アラート量を棚卸しする |
| 誤検知やアラート過多が多い | ポリシーを複製し、シミュレーションで調整版を検証する |
| 新しい対象場所を追加したい | いきなり本番適用せず、対象場所ごとにシミュレーションする |
| AIアプリや外部クラウド利用が増えている | Edge for BusinessやWebトラフィック関連のDLPシナリオを確認する |
| グローバル拠点へ展開したい | 地域別の業務プロセス、規制、言語、通知文を確認する |
管理者が確認すべき設定チェックリスト
DLPポリシーの作成・展開前に、管理者は少なくとも次の項目を確認しておくべきです。
| 確認項目 | 確認内容 |
|---|---|
| 権限 | ポリシー作成者が必要なロールグループに所属しているか |
| 管理単位 | Administrative Unitで制限された管理者か、全体管理者か |
| 対象データ | 保護すべき個人情報、金融情報、医療情報、知的財産を明確にしたか |
| 対象場所 | Exchange、SharePoint、OneDrive、Teams、Devicesなどを正しく選んだか |
| スコープ | 全社対象か、部門・サイト・ユーザー・デバイス単位で絞るか |
| 例外 | 監査法人、委託先、特定部門など正当な共有先を考慮したか |
| アクション | Audit only、Block with override、Blockの順で強める設計になっているか |
| 通知 | ユーザーが理由と対応方法を理解できるポリシーヒントになっているか |
| アラート運用 | 誰が、どの頻度で、どの基準でアラートを確認するか |
| 記録 | ポリシー名、変更履歴、承認者、展開日を残しているか |
公式ドキュメントでは、DLPポリシーを作成・展開するアカウントは、Compliance administrator、Compliance data administrator、Information Protection、Information Protection Admin、Security administratorなどのロールグループに所属している必要があると説明されています。また、細かなアクセス制御にはInformation Protection系のロールやロールグループを使えることも示されています。(Microsoft Learn)
権限まわりで特に注意したいのは、Administrative Unitで制限された管理者です。グローバル管理者と同じ感覚で操作すると、想定した全社スコープにポリシーを適用できない、または見える範囲が限定される可能性があります。公式ドキュメントでも、作業前に制限なし管理者とAdministrative Unit制限付き管理者の違いを理解するよう注意されています。(Microsoft Learn)
実務で失敗しやすいポイント
Microsoft Purview DLPポリシーの失敗は、検知ロジックそのものよりも、展開設計の甘さから起こることが多いです。
いきなり全社Blockにする
最も避けるべきなのは、全社スコープでいきなりBlockを有効化することです。外部共有やメール送信が正当業務として存在する組織では、業務停止、問い合わせ急増、例外申請の混乱につながります。
最初はAudit onlyで実態を把握し、ブロック対象を絞り込んでからBlock with overrideまたはBlockへ進めるべきです。
機密情報の定義が広すぎる
クレジットカード番号、マイナンバー、パスポート番号、銀行口座番号などは保護対象として分かりやすい一方、数字列や社内管理番号と誤検知することがあります。
誤検知が多い場合は、検出条件、信頼度、件数しきい値、対象場所、例外条件を見直します。業務で使うテンプレートやファイル名、保存場所のパターンを確認すると、チューニングしやすくなります。
通知文がユーザー目線になっていない
ポリシーヒントに「DLPポリシーに違反しています」とだけ表示しても、ユーザーは何をすればよいか分かりません。
良い通知文には、次の要素を入れます。
- 何が問題として検知されたのか
- なぜ制御されているのか
- 正当な業務の場合はどう申請・上書きするのか
- 問い合わせ先はどこか
- 社内ルールの参照先はどこか
ユーザー教育を目的にする段階では、ブロックよりも理解しやすい通知文の方が効果的です。
アラート運用を決めずに有効化する
DLPアラートは、発生させるだけでは意味がありません。誰が確認し、どの基準で重大度を判断し、どのケースをインシデント化するのかを決めておく必要があります。
たとえば、次のような基準を事前に定義します。
| 判断基準 | 例 |
|---|---|
| 高リスク | 大量の個人情報を外部ドメインへ送信しようとした |
| 中リスク | 機密情報を含むファイルを社外共有しようとしたが上書き理由がある |
| 低リスク | 社内ユーザーがテストデータを含む資料をOneDriveに保存した |
| 要チューニング | 同じテンプレートで誤検知が繰り返されている |
この基準がないまま本番適用すると、運用チームは大量のアラートに追われ、重要な漏えい兆候を見落としやすくなります。
グローバル展開での判断基準
グローバル向けにMicrosoft Purview DLPポリシーを展開する場合、全世界で同じポリシーを使うか、地域・事業部ごとに分けるかを決める必要があります。
| 判断軸 | 全社共通ポリシーが向く場合 | 地域・部門別ポリシーが向く場合 |
|---|---|---|
| 保護対象 | クレジットカード番号など全社共通で保護したい情報 | 国ごとの個人番号、医療情報、業界固有データ |
| 業務プロセス | 共有ルールが全社で統一されている | 海外拠点ごとに委託先や共有先が異なる |
| 通知文 | 英語で全社運用できる | 日本語、英語、現地語で通知を分けたい |
| 例外設定 | 例外が少ない | 部門・地域ごとに正当な例外が多い |
| 管理体制 | 中央ITが全社運用する | 地域ITやコンプライアンス担当が管理する |
おすすめは、最初から細かく分けすぎないことです。まずは全社共通で守るべき情報を定義し、そのうえで地域固有の要件だけを別ポリシーに分けると、管理負荷を抑えられます。
たとえば、クレジットカード番号やパスポート番号は全社共通、各国の納税者番号や医療関連情報は地域別、研究開発資料や設計図は事業部別、という分け方です。
既存ポリシーを見直す際の優先順位
すでにMicrosoft Purview DLPを使っている組織では、すべてのポリシーを一度に見直す必要はありません。優先順位を付けて確認する方が現実的です。
| 優先度 | 見直すべきポリシー |
|---|---|
| 高 | Blockを使っているポリシー、外部共有を制御しているポリシー、アラートが多いポリシー |
| 中 | Audit onlyのまま長期間放置されているポリシー、対象範囲が広すぎるポリシー |
| 低 | 検知件数が少なく、業務影響も小さい監査目的のポリシー |
最初に確認すべきなのは、ユーザー影響の大きいポリシーです。特に、Exchange、SharePoint、OneDrive、Teams、Devicesを横断しているポリシーは、設定変更の影響が大きくなります。
次に、アラートが多いポリシーを見直します。アラートが多いから危険とは限りません。誤検知が多いだけの場合もあります。シミュレーションや複製ポリシーを使って、条件を調整してから本番側へ反映するのが安全です。
管理者が次に取るべき行動
Microsoft Purviewの「Create and deploy data loss prevention policies」更新ポイントは、DLPポリシーを安全に作成し、段階的に展開するための実務指針です。新規導入でも既存運用でも、重要なのは、ポリシー状態、アクション、スコープを分けて考えることです。
まず行うべきことは、既存DLPポリシーの棚卸しです。ポリシー名、対象場所、スコープ、アクション、通知、アラート量、例外設定を一覧化します。次に、BlockやBlock with overrideを使っているポリシーから優先的に確認し、必要に応じてシミュレーションモードで調整版を検証します。
新規にDLPポリシーを作成する場合は、Keep it offでレビューし、シミュレーションで影響を確認し、ポリシーヒント付きシミュレーションでユーザー教育を行い、最後に本番適用する流れを標準手順にしてください。
DLPは、強く設定すれば安全になる仕組みではありません。正当な業務を理解したうえで、止めるべき操作だけを止め、ユーザーに理由を伝え、運用データを見ながら改善することで効果を発揮します。今回の更新をきっかけに、Microsoft Purview DLPポリシーを「作成する設定」ではなく、「継続的に育てる情報保護の運用」として見直すことが重要です。
コメント