Google Calendar DLP ルール設計：推奨ルールの採否判断と確認ポイント

2026年6月に Google Workspace の DLP（Data Loss Prevention、データ損失防止）機能がカレンダーで正式リリース（GA）となり、管理コンソールでは既存のデータ保護インサイトレポート（Drive・Gmail が対象）をもとにしたルール候補が参照できます。この記事では、Drive・Gmail 向けに生成された提案ルールをそのままカレンダーに適用してよいかどうかの判断フレームワークを整理します。

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

• Google Workspace の DLP ポリシーを管理する情シス担当者
• Calendar DLP のルール設計を検討中だが、提案ルールをそのまま有効化してよいか判断できずにいる方
• 会議タイトルや説明欄への顧客名・案件金額の混入に課題感がある方
• Gemini の会議メモ機能と DLP の関係を整理したい方

フィールドごとの特性差：同じルールで誤検知率が変わる

Google Workspace 管理コンソールのヘルプで確認した通り、Calendar DLP が検出対象とするのは次の3フィールドです。

• タイトル（Title）：20〜50字程度が多く、パターンが限定される短い自由入力欄
• 説明（Description）：長文・箇条書き・Gemini 生成コンテンツが混在しうる広い領域
• 場所（Location）：住所・URL・会議室コードが入る自由入力欄

添付ファイルは Calendar DLP の対象外です。添付ファイルへの DLP は Drive DLP が別途担当します。

ここで注意が必要なのは、「Drive・Gmail 向けに作成済みの検出器をそのまま流用すると、フィールドの長さや入力パターンの違いから誤検知率が大きく変わる」という点です。

タイトルは文字数が少ないため、数値パターンや正規表現が「部分一致」でヒットしやすい構造になります。電話番号の正規表現が会議番号・日付・内線番号と誤ってマッチするのは、タイトルフィールドで頻発するパターンです。説明欄は逆に文字数が多くなりがちで、正規表現が複数箇所にヒットする確率が上がります。

場所（Location）フィールドにも注意が必要です。Google Meet の参加 URL やダイヤルイン番号（+81-3-XXXX-XXXX 形式）が自動入力される設定を採用している組織では、汎用的な電話番号パターンをそのまま適用すると Location フィールドが常時ヒットする状態になります。「全フィールドに同じルールを適用する」のではなく、フィールドごとに誤検知リスクを見積もって採否を分けることが先決です。

外部ゲスト招待という Calendar 固有の漏洩経路

Drive や Gmail の DLP は「組織外へのファイル共有・メール送信」をトリガとして設計されています。Calendar はこれと異なる仕様を持ちます。

外部ゲストを招待すると、招待メール自体に会議タイトルと説明欄の一部が含まれて送信されます。カレンダー共有設定の「予定の有無のみ（詳細は非表示）」を組織全体に設定していても、招待を送った相手の受信トレイには件名や本文が届きます。

これは「カレンダーイベントを保存した時点での DLP 検出」だけでは対応しきれないケースを含みます。機密情報が会議タイトルに記載された状態でゲスト招待を送ると、DLP の警告が出る前に招待メールが送信される可能性があります（DLP の検出タイミングはイベント保存時ですが、招待送信との前後関係は公式ヘルプに明記がなく、要確認です）。

カレンダーの組織外共有設定と DLP は別のレイヤで動作する点も整理しておく必要があります。共有設定の「外部への詳細表示を制限する」は、イベントをカレンダービューから参照する際の表示可否を制御するものです。招待時に送信される招待メールの本文に入るタイトル・説明の内容を制御するには DLP ルールが必要です。この2つを補完的に設計することが、情シスとして取りうる現実的なアプローチです。

アクション設定と業務影響のバランス

DLP アクションが「ブロック（Block）」に設定されている場合、外部ゲストを含む会議の作成が拒否されます。これは情シスが意図した動作でも、現場からは「なぜ外部とのミーティングが作れないのか」という問い合わせとして届きます。

外部招待を頻繁に行う部門（営業・渉外・パートナー担当など）については、Block アクションを適用する前に対象 OU（Organizational Unit、組織単位）を整理しておく必要があります。DLP ルールは OU 単位で適用範囲を絞り込めるため、「機密情報を扱う部門」と「外部商談が多い部門」を OU 設計の段階から分けて管理することが現実的な対処です。

提案ルールの採否判断：フィールド別・アクション別の基準

管理コンソールで表示されるルール候補は、組織内の Drive・Gmail データスキャン結果（データ保護インサイトレポート）をもとに生成されています。このレポートは現時点で Gmail と Drive のみを対象としており、Calendar 固有のフィールド特性は反映されていません。提案されたルールをカレンダーに展開する際には、以下の基準で採否を判断します。

以下の表は、主なルール類型の Calendar への適用可否を整理したものです。

ルール類型	採用推奨度	推奨アクション	判断根拠
マイナンバー・パスポート番号等の個人識別情報	◎ 採用可	Audit → Warn	業務上カレンダーに入る頻度が低く、誤検知リスクが限定的
クレジットカード番号	◎ 採用可	Warn / Block	会議タイトル・説明欄に入る業務的理由がほぼない
社外秘・機密ラベルのキーワード	◎ 採用可	Warn	機密ラベル語を明示的に書く場合のみ検出されるため精度が高い
顧客名・企業名のキーワードリスト	△ 要カスタマイズ	Audit のみ	会議タイトルに顧客名を入れるのは日常的。Block 適用で業務停止リスクあり
財務数字・金額パターン（正規表現）	△ Audit のみ	Audit のみ	見積もり金額・予算数字が説明欄に入るケースが多く誤検知率が高い
電話番号パターン（正規表現）	✕ 採用非推奨	適用見送り	会議ダイヤルインの参加番号が誤マッチする。Exclude パターン設計が必要

採用判断の基本ステップ

ルール候補を評価する際には、以下の順序で確認します。

1. そのデータ型がカレンダーの各フィールドに入る業務シナリオが実際に存在するか確認する
2. 適用フィールドを「全フィールド」ではなく「説明欄のみ」「タイトルのみ」に絞り込む
3. アクションは Audit から始め、2〜4 週間の誤検知数を観察してから Warn / Block に昇格する
4. 外部ゲスト招待を頻繁に行う OU については Block を外す対象候補として別管理する

Audit モードの試運転で何を見るか

Audit モードは実際の業務データを用いたドライランです。管理コンソールの DLP レポートで、ルールがどのイベントにヒットしたかを確認できます。試運転期間（2〜4 週間を推奨）で確認すべき指標は次の3点です。

• ヒット件数の水準：1日あたりのヒット件数が想定より多い場合、誤検知の可能性が高い。初期設定時は1日5件以内を目安（環境・業務量により異なる）にアクションを昇格させる判断をする組織も多い
• ヒットしたフィールドの分布：タイトルと説明欄でヒット割合が大きく異なる場合、フィールドを絞った適用を検討する。タイトルにばかり集中する場合はパターンが広すぎる可能性がある
• ヒットしたユーザー・OU の偏り：特定の OU に集中している場合は、そのチームの業務パターンを確認してからアクションを昇格させる

誤検知が起きやすいルール類型と具体例

Drive・Gmail 向けに実績のある検出器がカレンダーでなぜ問題を引き起こすのか、具体例を挙げます。

電話番号パターン

会議の説明欄には「参加ダイヤルイン: +81-3-XXXX-XXXX」などの文字列が頻繁に入ります。汎用的な電話番号正規表現をそのまま適用すると、会議参加情報を記入するたびに警告が出ます。Google Meet の会議 URL と並んで記載されるダイヤルイン番号は、Calendar 特有の入力パターンです。

回避策として、Exclude 条件に「meet.google.com を含む説明欄に限り電話番号パターンを除外する」という設計を検討できます。ただし DLP ルールの Exclude 機能の挙動はアプリごとに差がある場合があり、設定前に公式ヘルプで Calendar に対する Exclude の動作を確認することを推奨します。

金額・数値パターン

「見積もり上限: ¥500,000」のような記述が説明欄に入る商談・予算確認の会議は日常的に存在します。財務数字パターンをそのまま Block に設定すると、営業・購買部門から「会議が作れない」という問い合わせが急増します。カレンダーの金額パターンは Drive（スプレッドシート等）と比べて文脈判断が難しいため、Block ではなく Warn または Audit 止まりが現実的な対処です。

顧客名・企業名のキーワードリスト

「株式会社◯◯ 様 商談」のようなタイトルは、CRM との連携やカレンダー共有を通じて外部に見える場合があります。Block アクションでは外部商談の記録自体を作れなくなる点に注意が必要です。カレンダーの共有設定側（外部への詳細情報表示を制限）との組み合わせで対処するほうが、業務への影響は限定的です。

Gemini 会議メモと Calendar DLP の関係を整理する

Google Workspace の「Google AI note-taking（管理者向けヘルプでの名称；ユーザー向け UI では「Take notes for me」と表示）」機能を有効にしている場合、Gemini が生成した会議サマリは Google Drive 上のドキュメントとして保存され、カレンダーイベントにはそのドキュメントへのリンクが添付されます（Google Workspace 管理コンソールのヘルプより）。

この動作から、次の2点が確認できます。

Gemini 生成の議事録ドキュメントは Drive DLP のスコープ

会議サマリの本体は Drive 上にあるため、そこに記載された顧客名・金額・プロジェクトコードは Calendar DLP ではなく Drive DLP が検出します。Calendar DLP と Drive DLP の両方でルールを整合させておかないと、Calendar 側はブロックできても Drive 側はスルーという状況が生まれます。

特に「個人情報（マイナンバー・パスポート番号）を含む議事録を Drive に保存されると困る」という要件がある場合、Calendar DLP を設定するだけでは不十分です。Drive DLP のルールにも同等の検出器を追加し、会議メモが保存される先のドキュメントでも検出されるよう設計する必要があります。

Calendar event の Description には Gemini が直接書き込まない

Gemini が生成したコンテンツがカレンダーイベントの説明欄に直接書き込まれるわけではないため、「Gemini が書いた内容が Calendar DLP に引っかかる」というシナリオは通常発生しません。ただし、ユーザーが会議サマリの一部をコピーして説明欄に貼り付けた場合は Calendar DLP の検出対象になります。

Gemini 会議メモを活用している組織は、Calendar DLP 単独ではなく Drive DLP のルールも同時に見直すことが必要です。

まとめと次のアクション

Calendar DLP のルール設計において「提案されたルールを全部 ON にする」は誤検知を量産するリスクがあります。Drive・Gmail で実績のある検出器であっても、カレンダーのフィールド特性（タイトルの短さ・説明欄に入る業務データの種類）を踏まえた採否判断が必要です。

判断の軸を3つに絞ると整理しやすくなります。

第一の軸：そのデータ型はカレンダーに入るか

個人識別情報（マイナンバー・クレジットカード番号）は会議タイトルや説明欄に入る業務的理由がほぼなく、採用の優先度が高いです。顧客名・金額・電話番号は日常業務で当たり前に入るため、Block ではなく Audit → Warn の段階設計を取ります。

第二の軸：外部ゲスト招待がある OU をどう扱うか

Block アクションを適用する前に外部招待の多い OU を洗い出し、そのチームへの適用ルールを別管理する設計が現実的です。まずは組織全体で Audit をかけて業務パターンを把握してからアクションを昇格させることを優先します。

第三の軸：Gemini 会議メモが動いているか

Google AI note-taking が有効な場合は Drive DLP との整合が必要です。Calendar DLP だけを設定して終わりにすると、議事録ドキュメントが Drive 側で無検査になるリスクがあります。

「どのルールを採用すべきか」は組織の業務パターンと OU 構成に依存します。Drive や Gmail の DLP で誤検知が出た経験があるほど、Calendar への横展開は丁寧な設計が求められます。DLP ルール設計の相談は、既存ポリシーの状況をヒアリングした上で進める必要があります。

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

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