Google Workspace DLPでCRMデータを守る方法｜顧客情報・契約情報・AI入力への適用ルール
Google Workspace DLPをCRMデータの保護に使うときに、ルールを増やしすぎると業務が止まり、絞りすぎると事故が起きます。先に「対象データ分類」「検出パターン」「アクション」「対象範囲」の4要素で骨格を作り、Gmail・Drive・Sheets・Gemini・Chatに横断適用するのが、運用負荷を抑える近道です。
2026年6月に Google Workspace Updates で、Google Calendar DLP の一般提供、非Workspaceファイル添付のDLP条件、proximity matching、managed third-party apps 向けの強化データ保護に加え、Workspace Policy API の DLP mutate endpoints も案内されました。これにより、本文や共有リンクだけでなく、予定本文、添付ファイルの種類・ファイル名・MIME type・文脈付きの機密検知・iOS 上の持ち出し経路、さらに DLP ルールの作成・更新・停止まで含めて設計できるようになっています。
結論として、DLPルールは個人情報・契約金額の2カテゴリから始め、Gmail・Drive・Sheets・Gemini・Chatに適用し、添付ファイル条件と proximity matching を誤送信・誤共有の多い経路に足します。運用規模が大きい会社は、Workspace Policy API で DLP ルールの作成・更新・停止を自動化すると、監査と例外対応を回しやすくなります。CRMやAI CRMでの取り扱いは Google Workspace CRM や AI CRM と組み合わせ、責任分担を明確にします。
本記事のポイント
- DLPルールは「対象データ分類→検出パターン→アクション→対象範囲（OU/グループ）」の4要素で設計し、まずは個人情報・契約金額の2カテゴリから始めます。
- Gmail送信・Drive共有・Sheets編集・Gemini入出力・Chat投稿に加え、Calendar の自由記述欄と iOS 上の managed third-party apps 保護まで横断して設計します。
- proximity matching は、単独パターンでは誤検知しやすい金融情報や顧客情報を文脈付きで検知し、Policy API での自動反映と監査ログの継続改善につなげやすくします。
この記事で扱うテーマ
関連キーワード
- Google Workspace DLP CRMデータ
- Workspace DLP 設定
- Workspace DLP Gemini
- Google Calendar DLP
- managed third-party apps
- Workspace DLP 添付ファイル
- Workspace Policy API DLP
- Google Workspace DLP API
- proximity matching DLP
- Google DLP 顧客情報
- Workspace DLP 営業
このページで答える質問
- Workspace DLPでCRMデータを保護するときの設計の進め方は？
- DLPルールはGemini入力・出力にも本当に効くのか？
- 添付ファイル条件とproximity matchingは何に使うべきか？
- CRM・AI CRMとDLPはどう役割分担すべきか？
DLPルールの4要素設計
| 要素 | 役割 | 例 |
|---|---|---|
| 対象データ分類 | 守るべき情報の種類を定義 | 個人情報、契約金額、機密キーワード |
| 検出パターン | 正規表現／辞書／既製テンプレート | クレジットカード番号、マイナンバー、特定文言 |
| アクション | 送信抑止／警告／監査ログのみ | 外部メール送信時はブロック、社内は警告 |
| 対象範囲 | OU/グループ単位での適用 | 営業部 → 全員、人事部 → さらに厳格 |
2カテゴリから始める｜個人情報と契約金額
DLPは最初から全カテゴリで設定すると、現場の業務が止まりがちです。次の2カテゴリから始め、運用が回ってからカテゴリを拡張します。
- 個人情報：氏名・メール・電話番号・住所のパターン検知、外部送信時に警告
- 契約金額・条件：「\\d+,000円」などの金額パターン、社外公開判定の文脈で警告
運用が安定したら「クレジットカード番号」「マイナンバー」「特定の機密文言」を順次追加します。
5チャネルすべてに適用する
| チャネル | 適用例 |
|---|---|
| Gmail（送信） | 外部メールの本文・添付に対する送信抑止／警告 |
| Drive（共有） | 機密ファイルの外部共有抑止／リンク発行制限 |
| Sheets（編集） | 機密データを含む列／セルの保護、コピー時の警告 |
| Gemini（入出力） | プロンプト送信時の機密検知、出力結果のフィルタリング |
| Chat（メッセージ） | 機密キーワードを含むスペース投稿やファイル共有の抑止 |
| Calendar（予定本文） | タイトル、説明、場所に書いた機密情報の audit / warn / block |
Calendar DLP と iOS 持ち出し経路をどう足すか
CRMデータ保護を Workspace 全体で考えるなら、Gmail、Drive、Chat だけでは不十分です。商談調整、採用面談、訪問予定の運用では、顧客名、電話番号、面談メモ、契約条件が Calendar のタイトルや説明へ入りやすく、営業や採用現場では iPhone からそのまま確認・更新されます。このため、2026年6月3日に一般提供となった Google Calendar DLP と、同日案内された managed third-party apps 向け保護 を DLP 設計へ追加しておくと、漏れやすい経路を埋めやすくなります。
役割分担は明確です。Calendar DLP は予定本文の自由記述欄を検知し、managed third-party apps 保護は iOS 上で業務データを個人アプリや未管理アプリへ渡しにくくする経路制御です。DLP の本体ルールとモバイル経路の統制を分けて考えると、営業、採用、CS の現場で何を block し、何を別システムへ逃がすかを説明しやすくなります。
| 追加論点 | 主対象 | CRMデータ保護での使いどころ |
|---|---|---|
| Calendar DLP | 予定タイトル、説明、場所 | 商談予定、採用面談、訪問メモに個人情報や契約条件を書きすぎるのを止める |
| managed third-party apps 保護 | iOS 上の管理対象アプリ間データ共有 | 業務データを個人アプリ、私用アカウント、未管理アプリへ渡しにくくする |
| Endpoint Management | 端末設定、バックアップ、共有制御 | コピー、AirDrop、保存先、iCloud 同期まで含めた持ち出し経路を絞る |
添付ファイル条件と proximity matching をどう足すか
2026年6月の一般提供で重要なのは、DLPの対象を「本文に含まれる文字列」だけで考えないことです。Google の案内では、Gmail、Drive、Chat の添付ファイルをスキャンし、ファイル名、拡張子、MIME type、ファイル内に含まれる文字列などを条件にできます。顧客リスト、見積書、契約書、請求データは、本文ではなく添付ファイルとして外に出ることが多いため、CRMデータ保護ではこの拡張を優先して確認します。
proximity matching は、ある検出条件の近くに別の検出条件があるときだけ反応させる設計です。たとえば、銀行口座番号の近くに routing number がある、顧客名簿の近くに契約金額がある、社内コード名の近くに価格条件がある、といった「組み合わせで危険度が上がる」データを拾いやすくなります。単独キーワードだけでブロックすると誤検知が増えるため、文脈がそろったときに警告・ブロックする設計が現実的です。
| 追加条件 | 見る対象 | CRMデータでの使いどころ |
|---|---|---|
| ファイル名 | 添付ファイルや共有ファイルの名称 | 「見積」「契約」「顧客一覧」などを含むファイルの外部送信を警告する |
| ファイル拡張子 | csv、xlsx、pdf など | 顧客リストや価格表がCSV/Excelで外に出る経路を絞る |
| MIME type | ファイル種別 | 拡張子変更で回避されるリスクを抑える |
| proximity matching | 複数条件の近接関係 | 顧客識別情報と金額・口座・契約条件が近くにある場合だけ強く止める |
設定の順番は、まず「外部送信・外部共有されると困る添付ファイル」を決め、次にファイル条件を警告で観察し、誤検知が少ないものからブロックへ上げます。proximity matching は、いきなり全社ブロックに使うより、金融情報、契約条件、独自の顧客コードなど、組み合わせで危険度が上がる対象に絞る方が運用しやすくなります。
Workspace Policy API で DLP 運用を自動化できるようになった
2026年6月8日に Google Workspace Updates で案内された Workspace Policy API の DLP mutate endpoints により、これまで Admin console 中心だった DLP ルール運用を API で扱えるようになりました。既存の参照系 API に加えて、作成、更新、削除が可能になったため、ルールの棚卸し、例外ルールの一時反映、OU ごとの差分適用、テスト環境から本番環境への反映をコードベースで管理しやすくなります。
ここで重要なのは、「DLP の検知範囲が広がった」ことと「DLP の運用を自動化できる」ことは別論点だという点です。前者は添付ファイル条件、Calendar DLP、proximity matching のような検知設計で、後者は Policy API を使った統制運用です。複数の管理者がいる環境や、営業・人事・法務でルールの厳しさを分けたい環境では、設定画面の手作業だけで追うより、差分を API 管理に寄せた方が説明責任を持ちやすくなります。
| 観点 | Admin console 中心 | Policy API を使う場合 |
|---|---|---|
| 変更の反映 | 管理画面で都度手動変更 | ルール定義をコードや管理スクリプトから反映 |
| 監査 | 設定画面の現時点確認が中心 | 変更履歴、差分、反映時刻を残しやすい |
| 一時例外 | 戻し忘れが起きやすい | 有効化と停止を手順化しやすい |
| OU別の配布 | 手作業で差分調整 | 営業、人事、法務などへ段階適用しやすい |
| 向いている組織 | 小規模、単純なルール設計 | 複数部門、監査要件あり、改善サイクルが速い組織 |
API 化したからといって、いきなり全 DLP ルールを自動反映に寄せる必要はありません。まずは、個人情報、契約金額、特定の外部共有制御のように、運用頻度が高く、差分管理の価値が大きいルールから移すのが現実的です。Google もこの更新を「Admin console で既に扱える機能を API から操作できるようにした拡張」と位置づけており、手作業をゼロにするというより、監査しやすい運用へ寄せるための土台として見る方が実務に合います。
アクション設計｜業務を止めずに守る
- 外部メール／外部共有：原則ブロック、必要に応じて承認フロー
- 社内コラボレーション：警告のみ、業務担当が判断できる猶予を残す
- Gemini入力：機密キーワード検知時はプロンプト送信を抑止、警告のみは推奨しない
- Sheetsの大量コピー：閾値超過で警告、上長承認後に解除
監査ログ・アラート・棚卸しの3点セット
- 監査ログ：DLPの抑止・警告イベントを月次でレビュー
- アラートセンター：閾値超過・繰り返し違反・外部共有変更を即時検知
- 四半期棚卸し：誤検知率・抑止率・運用負荷を見直し、ルールを継続改善
- モバイル経路レビュー：iOSでどのアプリにデータが渡るか、managed app の範囲が妥当かを確認
CRM/AI CRMとの責任分担
| 領域 | Workspace DLP | CRM/AI CRM |
|---|---|---|
| 顧客連絡先 | 外部送信抑止 | 原本保管・アクセス権限 |
| 契約金額 | 外部共有・誤送信抑止 | 取引マスタの監査ログ |
| 商談履歴 | 機密キーワード検知 | 履歴の構造化と利用範囲 |
| AI出力 | 出力フィルタリング | AI支援結果のレビューと承認 |
| 第三者共有 | OAuth・退出設計の確認 | 連携アドオンの選定 |
よくある失敗と対策
- ルールを増やしすぎ：誤検知が増え、現場がバイパスを試みる→2カテゴリから始め、月次で追加判断
- OU/グループの分け方が荒い：適切なロールが警告を浴びる→「営業」「マーケ」「人事」「経理」を最低分割
- 監査ログのレビューが止まる：違反検知後の対応が形骸化→月次・四半期で定例化
- AI出力のフィルタを忘れる：機密データが要約に混入→Gemini入出力にも必ず適用
- 退職・異動時の見直し：権限残存事故→Workspace AIガバナンス（チェックリスト）に組み込み
実装の落とし穴と継続改善
Google Workspace 中心で CRM を組むときの最大の落とし穴は、データ原本の所在が複数になることです。Gmail のスレッド、Drive のフォルダ、スプレッドシート、Calendar の予定に同じ顧客情報が分散すると、「最新版がどこにあるか」を担当者が判断できなくなり、結果として CRM 全体が信用されなくなります。原本は1か所に集約し、メール・予定・資料は「補助情報」として参照する設計にするのが、Workspace 中心の CRM が長く使われる前提条件です。次の落とし穴は、専用 CRM への移行ラインを見誤ることです。100社・3名・1年運用を超えた段階で、入力時間と権限事故が一気に増えます。「無料で続けるべきか」「移行すべきか」を機能差ではなく、追客漏れ件数・入力時間・レポート負荷で判断するのが現実的です。
継続改善のサイクルは、週次の停滞検知と月次のレポートレビューで作ります。停滞検知は QUERY 関数で14日未更新の案件を自動抽出し、週次の営業会議で「次に動かす責任者」を1名指名します。月次のレポートレビューは、ステージ別の滞留日数・失注理由分布・受注金額のトレンドを Looker Studio で可視化し、改善ポイントを1つだけ決めて翌月に反映します。Gemini や AI 関数を併用する場合は、四半期で「下処理に効いている領域」と「判断に流れていないか」を確認するのが、属人化を防ぐ運用です。AI CRM への移行を視野に入れる組織は、Gmail・Calendar・Drive の文脈を CRM の正本と接続できる設計を、早めに小規模で試すと判断材料が揃います。
よくある質問
DLPはどのプランで使えますか？
主にBusiness Plus / Enterprise系のプランで提供されます。最新の対応プランは管理コンソール／販売代理店で確認します。
DLPはGeminiにも本当に効きますか？
Workspace DLPはGeminiの入力・出力に適用可能です。機密キーワード検知やパターンマッチで送信抑止・出力フィルタリングが行えます。
既製テンプレート（Detector）と独自パターンはどちらを使うべきですか？
初期は既製テンプレートで運用を立ち上げ、誤検知や業界特有の機密語をカバーする独自パターンを段階的に追加するのが現実的です。
添付ファイル条件はどのチャネルで使えますか？
2026年6月の一般提供では、Gmail、Drive、Chat の添付ファイルを対象に、ファイル名、拡張子、MIME type、ファイル内の文字列などを条件にできます。CRMデータでは、CSV、Excel、PDFで外部送信される顧客リストや見積書から始めると効果が見えやすくなります。
proximity matching は何のために使いますか？
単独のキーワードや正規表現では誤検知が多い情報を、近くにある別の条件と組み合わせて検知するために使います。たとえば顧客名と契約金額、口座番号と関連語、社内コード名と価格条件のように、組み合わせで機密性が高まる情報に向いています。
アクションは「警告」と「ブロック」のどちらが安全ですか？
外部送信・外部共有はブロック、社内は警告が運用バランスのよい選択です。事故時の影響度で判断します。
DLPの誤検知が多すぎて業務が滞ったらどうすれば良いですか？
誤検知率を週次で記録し、月次で例外ルール（特定OU・特定文脈）を追加します。「外部メール限定」「特定ドメインへの送信時のみ適用」などで絞り込みます。
CRMやAI CRMと併用するときの責任分担は？
DLPは「動的な抑止」、CRMは「保管とアクセス権限」、AI CRMは「文脈の継続支援」と役割を分けます。横断的な運用は AIガバナンスチェックリスト を参照してください。
関連ページと関連記事
- Gemini for Workspace管理者設定：管理コンソールでの設定確認を確認できます。
- Workspace Geminiのプライバシーとトレーニング：データ取り扱いを確認できます。
- Drive顧客フォルダ設計テンプレート：共有ドライブ運用を確認できます。
- Drive顧客データのGemini活用：Gemini活用前の6項目を確認できます。
- Workspace AIガバナンス・チェックリスト：横断的な運用方針を確認できます。
- AI CRMとは？：AI支援を継続運用する設計の全体像を確認できます。
DLPでCRMデータを安全に運用したい方へ
4要素設計と4チャネル適用、監査ログと棚卸し運用を、自社の業種・規模・既存ルールに合わせて整理します。Workspace DLPからAI CRM併用までを、ファネルAi編集部・監修チームが個別に確認します。
