Purview DLP → GWS DLP：移行設計の判断軸

Google Workspace DLP は 2025 年 2 月、Gmail への適用を一般提供開始しました（Workspace Updates Blog より）。Purview DLP から Google Workspace への移行設計で判断軸を求める情シス担当者に向け、両製品の設計概念の違い・代表ポリシーのマッピング・移行優先順位の考え方を整理します。

この記事を読んだほうが良い人

• M365 から GWS への移行を進めている情シス担当者
• Purview DLP で設定済みのポリシーを GWS にどう引き継ぐか迷っている方
• GWS DLP の設計概念を Purview との対比で理解したい方
• DLP 移行のスコープ・優先順位の判断軸が欲しい方

Purview DLP と Google Workspace DLP の設計概念はどう違うのか

移行作業に入る前に、両製品の設計思想の違いを把握しておく必要があります。ポリシーをそのまま持ち込もうとすると、ここで必ず詰まります。

Purview DLP：ラベルを起点とする 3 層構造

Microsoft Purview DLP は、MIP（Microsoft Information Protection）の一部として設計されています。MIP はファイル・メール・サイトにラベルを付与し、そのラベルをトリガーにアクセス制御・暗号化・DLP をまとめて制御するフレームワークです。

構成の大まかな流れは次の通りです。

1. 機密ラベル（Sensitivity Labels）の適用: ユーザーが手動で付与するか、自動ラベリングで適用される
2. DLP ポリシー: 機密ラベルや SIT（Sensitive Information Type＝機密情報タイプ）、保持ラベルなどを条件として参照する
3. ルール: ポリシー内に複数定義でき、条件・アクション・例外をまとめて設定する

SIT は、クレジットカード番号・社会保障番号・パスポート番号といった機密情報のパターンを事前定義したものです（Microsoft Learn 公式ドキュメントより）。国・情報種別ごとに多数の組み込み SIT が用意されており、各 SIT には「信頼度（低・中・高）」と「最小出現回数」が設定できます。この閾値設定が、後述する GWS DLP への移行時に参照すべき重要な設計情報になります。

Purview DLP の大きな特徴は「ラベルがコンテンツに付帯する」点です。ファイルが SharePoint から OneDrive に移動したり Teams で共有されたりしても、ラベルが残るためポリシーが追従します。また、シミュレーションモードで本番前に動作を検証できる点も実務で重宝します。移行を検討している段階で一度シミュレーションモードを走らせると、「どのルールが何件ヒットしているか」が可視化されます。ヒット件数が多いルールほど GWS 移行後も誤検知が起きやすい傾向があるため、移行の優先順位と検証計画を立てる際の基礎データになります。

対応サービスも幅広く、Exchange / SharePoint / OneDrive / Teams に加え、Windows・macOS エンドポイント上のファイル操作（USB コピー・印刷など）やオンプレミスファイルサーバーまでカバーできます（Microsoft Learn 公式ドキュメントより）。

GWS DLP：ルールを起点とする 2 層構造

GWS の DLP（正式名称はデータ保護ルール）はルールベースの設計です。構造はシンプルな 2 層です。

1. DLP ルール: スキャン対象サービス・条件・アクションをひとまとめに定義する
2. スコープ: OU（組織単位）またはグループ単位で適用範囲を指定する

ルールの条件として指定できるのは、定義済み情報タイプ（クレジットカード番号・社会保障番号など）、カスタムパターン（正規表現・キーワード）、そして Drive ラベル（分類ラベル）の 3 種類です（Google Workspace ヘルプより）。GWS DLP でも信頼度（低・中・高）と最小出現回数の設定が可能なため、Purview 側で「信頼度: 高 / 出現回数 1 回以上」と設定しているルールは GWS 側でも同等の閾値を設定することを検討してください。過検知が多い初期段階では信頼度「高」から始め、精度を確認しながら閾値を調整していく進め方が安定します。

2025 年 2 月の Gmail DLP 一般提供は、M365 からの移行実務の観点で重要な意味を持ちます。それ以前は、メール受送信に関する DLP 的な制御は「コンテンツコンプライアンスルール」で対応するケースが多かった経緯があります。Gmail DLP の一般提供により、Exchange Online の DLP ルールに近い形でのメール制御が GWS 上でも設定できる環境が整いました。

Drive ラベルを使えば Purview の機密ラベルに近い運用も取れますが、MIP のエコシステムと比較するとラベルの統合度は低い段階にあります。DLP ルールの条件として Drive ラベルを参照できるのは Drive 上のファイルが主体です。MIP のように「ラベルがコンテンツを横断して追従する」状態を GWS で再現するには、Drive ラベルの設計・展開を先行して完了させておく必要があります。

対応サービスは Drive / Gmail / Chat / Calendar / Chrome です。一方で、エンドポイント上のファイル操作・オンプレミスファイルサーバー・Google 以外のクラウドアプリへのアップロードは GWS DLP の対象外です（同ヘルプより）。Chrome については Chrome Enterprise Premium アドオンで一部対応できますが、Purview のエンドポイント DLP と対象範囲は異なります。

設計概念の比較表

両製品の主な設計概念の差分を一覧化します。

観点	Microsoft Purview DLP	GWS DLP
設計の起点	ラベル（MIP）	ルール
ポリシー構造	ポリシー → 複数ルール	ルール単体
分類ラベルの役割	MIP ラベルが全サービスで統合	Drive ラベルは Drive ファイルへの条件参照が主体
対応サービス範囲	M365 全体 + エンドポイント + オンプレミス	Drive / Gmail / Chat / Calendar / Chrome
エンドポイント DLP	あり（Windows / macOS）	Chrome Enterprise Premium アドオンで一部対応
テスト・検証手段	シミュレーションモード	アラートのみモードで代替
スコープ設定単位	管理単位 / グループ	OU / グループ
信頼度・閾値設定	SIT ごとに信頼度・出現回数を設定可	ルールごとに信頼度・出現回数を設定可

代表ポリシーを GWS DLP でどう再現するか

Purview DLP の代表的なルールパターンと、GWS DLP での対応方法を整理します。◎は設定変更なし、○は近似再現、△は設計変更が必要、× は直接再現不可を意味します。

Purview ポリシー例	GWS での再現可否	対応方法
個人情報（マイナンバー・社会保障番号等）の社外共有をブロック	◎ 再現可	定義済み情報タイプを条件に設定し、外部共有をブロック
クレジットカード番号を含むメールの送信をブロック	◎ 再現可	Gmail DLP で定義済み情報タイプを条件に設定
「社外秘」ラベル付きファイルの外部共有制限	△ 設計変更が必要	Drive ラベルを事前に整備した上でラベルを条件に設定。MIP ラベルとの 1:1 対応はしない
Teams チャンネルへの個人情報投稿ブロック	○ 近似再現	Chat DLP で同内容のルールを設定。添付ファイルの扱いはルール設計で補完
エンドポイントでの機密ファイル USB コピー制限	× 直接再現不可	Chrome Enterprise Premium で一部代替。エンドポイント DLP と同等の機能はない
SharePoint へのアップロード監視	◎ 再現可	Drive DLP で共有イベントを条件にスキャン
外部メールへのファイル添付をブロック	◎ 再現可	Gmail DLP で添付ファイルをスキャン + 送信をブロック

◎の大半は定義済み情報タイプを使うルールです。移行の優先候補として扱えます。△ が「設計変更が必要」になる理由は、Drive ラベルを事前に作成・展開した状態でなければ DLP ルールの条件として参照できないためです。× については代替手段を別途設計する必要があり、DLP 移行スコープから切り出して個別検討に回します。

M365 GWS DLP 移行設計：3 フェーズで進める優先順位

すべてのポリシーを同時に移行しようとすると、設定の複雑さと運用テストの負荷が一気に高まります。以下の 3 区分で整理するのが現実的です。

フェーズ 1（移行開始から 1〜2 ヶ月）：定義済み情報タイプ系のルール

個人情報・クレジットカード番号などの定義済み情報タイプを条件にしているルールは、GWS DLP でほぼ同じ条件で再現できます。移行初期にここを固めることで、最低限の情報漏えい対策を維持できます。

対象サービスは Drive → Gmail → Chat の順に広げると、設定ミスが発生したときの影響範囲を絞れます。まずアラートのみモードで稼働させ、誤検知率を確認してからブロックアクションへ切り替えてください。アラートの確認は週次スケジュールに組み込んでおくと、対応漏れを防げます。

フェーズ 2（Drive ラベル整備後）：ラベルベースのポリシー

Purview の機密ラベルに対応するものを GWS で使うには、Drive ラベルを事前に設計・展開する必要があります。MIP ラベルを Drive ラベルに 1:1 マッピングできるとは限らず、「GWS 上でどのラベル体系を運用するか」を決める作業はそれ自体が独立したプロジェクトです。

DLP ルールの設定より先にラベル体系を確定させてください。ラベル設計が固まっていない状態で DLP ルールを作ると、後から設定し直すことになります。このフェーズはフェーズ 1 と並行して計画できますが、完了は DLP ルール設定より先でなければなりません。

フェーズ 3（移行完了後・別途検討）：エンドポイント・オンプレミス対象ポリシー

エンドポイント DLP（USB 制限・印刷制限など）は GWS DLP で直接再現できません。Chrome Enterprise Premium アドオンで Chrome ブラウザ上の操作を一部制御できますが、Purview のエンドポイント DLP とは対象範囲と粒度が異なります。

オンプレミスファイルサーバーへの DLP 適用も GWS の対象外です。これらのポリシーは移行対象から切り出し、SIEM 連携・ファイルサーバー側のアクセス制御強化などを別途検討してください。業種・取り扱いデータの性質によってはエンドポイント DLP が必須要件になる場合もあり、その場合は GWS への全面移行を急がず、Purview を一部残す設計も選択肢に入れます。

よくある設計ミスと回避策

移行プロジェクトで繰り返し見られるミスを 3 点取り上げます。

ミス 1：「Purview で設定しているルールをすべて GWS に移す」という発想で始める

Purview の SIT は GWS の定義済み情報タイプと完全には一致しません。まず GWS が対応する情報タイプの一覧を確認し、「そのまま移せるもの」「設計変更が必要なもの」「移せないもの」の 3 分類に整理してから着手してください。整理なしで全件移行を試みると、後から設定の見直しが発生して二度手間になります。

ミス 2：Drive ラベルを準備せずに DLP ルールを設定しようとする

ラベル系のポリシーは Drive ラベルが存在しなければルールを作れません。フェーズ 2 に入る前に「GWS 上のラベル設計が完了しているか」を必ず確認してください。ラベル名・分類の粒度・適用対象 OU の設計をチームで合意した上で DLP ルール設計に進みます。

ミス 3：並行稼働期間にアラートが爆発して対応しきれなくなる

Purview と GWS DLP を同時稼働させると、同一コンテンツに対して両方からアラートが上がります。初期は GWS 側をアラートのみモードに限定し、対応できる範囲でのみ稼働させてください。Purview 側でシミュレーションモードを事前に走らせておくと、GWS 側で発生するアラート量の規模感をある程度予測できます。

移行前後の確認事項チェックリスト

移行前

移行計画を始める前に確認すべき事項です。

• [ ] Purview DLP で有効化されているポリシー・ルールの全量を確認した
• [ ] 各ポリシーが参照している条件（SIT・信頼度・閾値・ラベル・例外リスト）を洗い出した
• [ ] GWS DLP で再現不可なポリシー（エンドポイント・オンプレミス等）を別管理にした
• [ ] Drive ラベルの体系設計（MIP ラベルとのマッピング方針）が確定している
• [ ] GWS DLP の対応エディション・ライセンス要件を確認した
• [ ] Purview 側でシミュレーションモードを走らせ、各ルールのヒット件数を把握した

最後の項目は見落とされがちですが、GWS 側の検証計画を立てる上で欠かせません。ヒット件数が少ないルールほど初期検証が短期間で完了するため、移行スケジュールに余裕を確保しやすくなります。

移行後

GWS DLP ルールを稼働させた後に確認すべき事項です。

• [ ] GWS DLP ルールをアラートのみで初期稼働させた
• [ ] アラートセンターでポリシーマッチの誤検知率を一定期間モニタリングした
• [ ] 誤検知が多いルールは信頼度・しきい値・キーワードを調整した
• [ ] ブロックアクションに切り替えた後も定期的にアラートを確認している
• [ ] Purview DLP と GWS DLP の並行稼働期間中は双方の設定が競合しないことを確認した
• [ ] M365 テナント廃止前に GWS DLP が全ポリシーをカバーしていることを確認した

GWS DLP でカバーできないギャップへの対処

GWS DLP は Purview DLP の完全な代替ではありません。特に「エンドポイント DLP」と「オンプレミスファイルサーバーの監視」は、GWS への移行後も Purview 側を残すか、別製品で補完する判断が必要になります。

業種によって判断の方向性は変わります。医療・金融など規制業種では端末操作の証跡が監査要件になる場合があり、エンドポイント DLP の廃止が難しいケースがあります。一方、SaaS 中心でオンプレミスファイルサーバーがほぼない企業では、GWS DLP がカバーする範囲（Drive / Gmail / Chat）のリスクが実運用上の大半を占めることが多いです。

筆者の見解としては、100 名規模の企業では後者のケースが大半を占めます。まず GWS DLP で主要サービスの保護を確立し、エンドポイント側は移行後フェーズで別途検討するアプローチが現実的です。ただし、エンドポイント DLP が必須要件になる場合は GWS への全面移行を急がず、Purview を一部残す設計も選択肢に入れてください。

まとめ

Purview DLP から GWS DLP への移行は「設定のコピー」ではなく「設計の再構築」です。ラベルから始まる Purview の設計思想から、ルールから始まる GWS の設計思想へ移るには、各ポリシーの意図を言語化して再設計し直す必要があります。

移行の最初の一歩として、全ポリシーを「定義済み情報タイプ系」「ラベル系」「エンドポイント・オンプレミス系」の 3 区分に分類してください。この分類が完了すると、移行計画は具体的な形になります。DLP の移行は後工程になりがちですが、M365 テナントの廃止タイミングに間に合わせるために、早めにスコープを確定させることを強く勧めます。

コーポレートITのご相談はお気軽に

この記事で書いたような業務改善・自動化の設計から実装まで、DRASENASではコーポレートITの現場に寄り添った支援を行っています。 「まず相談だけ」でも大歓迎です。DRASENAS 公式サイトからお気軽にどうぞ。