本文へスキップ

Google Calendar DLPとは?予定タイトル・説明・場所の機密情報を検知する設定と運用

Google Calendar DLPとは?予定タイトル・説明・場所の機密情報を検知する設定と運用

Google Calendar を社内予定の共有だけでなく、商談調整、候補日連絡、採用面談、イベント運営に使っている会社では、予定タイトルや説明欄に顧客名、電話番号、契約条件、面談メモがそのまま入ることがあります。Drive や Gmail の保護は考えていても、Calendar の自由記述欄まで機密情報対策が届いていないケースは珍しくありません。

Google Workspace Updates は、2026年6月3日に Google Calendar 向けの DLP が一般提供になったと案内しました。これにより、予定のタイトル、説明、場所に入るテキストを対象に、監査、警告、ブロックを掛けられます。さらに同時期の Workspace DLP 拡張として、添付ファイル条件や proximity matching も一般提供されており、Calendar 単体では足りない論点まで含めて設計できるようになっています。

結論として、Google Calendar DLP は 予定タイトル・説明・場所の自由記述欄に機密情報が入るのを検知し、audit、warn、block で制御する機能 です。2026年6月3日開始の一般提供では、Web だけでなく Android、iOS、Calendar API でブロックされたときも自動メール通知が行われます。一方で、添付ファイル条件や proximity matching は別論点なので、Workspace DLP 全体設計 とつないで考える必要があります。

Google Calendar DLP を、予定入力、DLP判定、通知、隣接する Workspace DLP 機能の関係で整理した図
Calendar DLP は予定本文の自由記述欄を守る機能であり、添付ファイル条件や proximity matching は Gmail、Drive、Chat 側の補完として設計すると整理しやすくなります。

本記事のポイント

  1. Google Calendar DLP は、予定タイトル・説明・場所の自由記述欄を対象に audit、warn、block を掛けられる機能で、2026年6月3日に一般提供となりました。
  2. Calendar DLP だけでは添付ファイルや文脈付き検知までは扱えないため、Gmail、Drive、Chat 側の添付ファイル条件や proximity matching と組み合わせて設計する必要があります。
  3. 管理者実務では、OU 単位の適用、外部共有や対外送信との優先順位、Calendar API やモバイル利用時の通知動作まで確認すると運用で詰まりにくくなります.

この記事で扱うテーマ

関連キーワード

  • Google Calendar DLP
  • Google Workspace Calendar DLP
  • Calendar DLP とは
  • Google Calendar 機密情報 ブロック
  • Google Workspace proximity matching
  • Google Calendar DLP 設定

このページで答える質問

  • Google Calendar DLPとは何ですか?
  • 予定タイトルや説明、場所に機密情報が入ったらどう制御できますか?
  • Calendar API や iPhone、Android でも DLP は効きますか?
  • 添付ファイル条件や proximity matching とどう使い分けるべきですか?

Google Calendar DLPとは何か

Google の 2026年6月3日付の公式案内では、Google Calendar の DLP は、イベントの titledescriptionlocation を対象に、機密情報をスキャンできる機能として説明されています。ここで重要なのは、対象が「予定に書かれた自由記述テキスト」だという点です。つまり、会議 URL の管理や Drive 権限そのものを制御する機能ではなく、カレンダー予定のテキスト欄に何を書いてよいか を制御するための機能です。

具体的には、クレジットカード番号、国民識別番号、社内で定義したキーワードなどに対してルールを作り、保存時に監査だけする、ユーザーへ警告する、保存や更新をブロックする、という3系統のアクションを取れます。Google Workspace 管理者にとっては、Drive や Gmail に比べて見落としやすい予定データの統制が、ようやく正面から扱えるようになったと見るのが自然です。

観点Google Calendar DLP が見る範囲別で設計すべき範囲
対象データ予定タイトル、説明、場所の自由記述欄Drive 添付ファイル、共有権限、会議 URL のアクセス制御
アクションaudit、warn、block例外承認フロー、棚卸し、再教育
適用単位イベント所有者の OU またはグループ部門横断の共有ルール、外部共有ポリシー
通知Web のポップアップ、モバイルや API 利用時の自動メール管理者向けアラート、監査レポート

Calendar にはつい「社名・氏名・携帯番号・集合場所・契約前の確認事項」をまとめて書きがちです。営業や採用、CS では便利ですが、そのままでは AI ガバナンス や情報保護の抜け穴になります。Calendar DLP の価値は、ここを後追い監査ではなく保存時制御に変えられる点です。

audit・warn・block の違いと、どこで使い分けるか

Google の案内では、管理者は 3 種類のアクションを選べます。違いを理解せずに最初から全部 block にすると、現場が予定登録そのものを避けてしまいます。逆に audit だけだと、危険な入力がそのまま残ります。実務では、予定の種類ごとに段階を分ける方が安定します。

アクション向いている場面実務上の注意点
auditまず実態を把握したい初期導入期違反件数だけでなく、どの部署が何を書いているかを見ないと改善につながりません。
warn社内会議や低リスク予定で、利用者に判断余地を残したい場面警告メッセージは具体的にしないと、単なる「閉じる」操作になります。
block対外予定、採用面談、契約条件、個人情報を含みやすい予定代替入力ルールや記録先を用意しないと、口頭運用へ逃げやすくなります。

たとえば、営業の初回商談で「顧客名+候補日時」までなら許容し、「契約予定金額」や「個人携帯番号」は block にする、といった粒度が現実的です。採用なら面接候補者の名前は許容しても、評価メモや個人番号は block に寄せる方が安全です。Calendar は予定のスピードが重要なため、何でも禁止 より 何を別の保管先へ逃がすか を先に決める方が運用しやすくなります。

この判断は、Workspace DLP 全体設計 とそろえて考える必要があります。Calendar だけ厳しく、Gmail や Drive が緩いと、入力経路が横にずれるだけだからです。

Calendar API、iPhone、Android でどう効くのか

今回の一般提供で見落としにくい論点は、ブロック時の通知動作です。Google の案内では、Web ではポップアップで利用者へ理由を示し、Android、iOS、または Calendar API 経由で更新がブロックされた場合は、自動メール通知で違反理由を伝えるとされています。つまり、ブラウザだけ守ればよい ではなく、モバイルや連携アプリも含めて設計する前提です。

ここはとくに、Google Workspace を CRM 的に使っている会社で重要です。営業支援ツール、採用管理、予約調整ツール、ノーコード連携が Calendar API を触る場合、管理者が知らないまま外部システム経由で予定更新が走ることがあります。Calendar DLP が入ると、その更新失敗が自動メールで利用者へ返るため、単に「保存できない」ではなく、「どこで詰まったか」を運用に落とし込みやすくなります。

  • 営業や CS が iPhone から顧客の個人番号入り予定を更新しようとして block される
  • 採用管理ツールが候補者情報を Calendar API 経由で書こうとして失敗する
  • 外部の予約連携が想定より多くの個人情報を description に書き込んで警告される

こうしたケースでは、DLP 設定だけでなく、連携元ツールのフィールド設計を見直す必要があります。Calendar に何を入れ、何を CRM や ATS 側へ残すかを分けることで、DLP は止めるだけの機能ではなく、記録先の正本を整えるきっかけになります。

添付ファイル条件や proximity matching とどうつなぐか

Calendar DLP を調べる読者が次に迷いやすいのは、「添付ファイルの機密情報も止められるのか」「文脈つきの検知はできるのか」という点です。結論から言うと、2026年6月時点で一般提供された添付ファイル条件と proximity matching は、Workspace DLP の隣接機能 として見る方が正確です。Google の 2026年5月27日開始のロールアウト案内では、Gmail、Drive、Chat の添付ファイルに対して、ファイル名、拡張子、MIME type、近接条件による検知ができるようになっています。

つまり、Calendar DLP は予定本文の自由記述欄、添付ファイル条件はファイル自体、proximity matching は「口座番号の近くに routing number がある」のような文脈付き検知を担当します。全部を Calendar DLP で解決しようとすると、設計がずれます。

機能主対象向いている使い方
Calendar DLP予定タイトル、説明、場所商談調整、採用面談、イベント運営のテキスト欄保護
添付ファイル条件Gmail、Drive、Chat の添付ファイル特定拡張子、ファイル名、MIME type の持ち出し抑止
proximity matching機密情報どうしの近接関係単独では誤検知しやすい金融情報や proprietary data の絞り込み

たとえば、営業がカレンダーの予定本文に「契約金額 120万円」と書くのは Calendar DLP の領域です。一方、予定に紐づく資料を Drive で共有するなら、ファイル名や添付ファイルの DLP 条件も必要です。顧客データや金融データのように文脈で見たい場合は、proximity matching を使って誤検知を減らします。これをつないで考えると、監査ログ とあわせて「どのチャネルで漏れやすいか」を説明しやすくなります。

管理者が最初に決めるべき運用ルール

Calendar DLP は設定画面で終わる機能ではありません。最初に運用ルールを決めておくと、現場での反発と例外運用を減らせます。

  1. どの予定が高リスクかを決める:商談、採用、役員会、外部イベントなど、分類を先に切ります。
  2. Calendar に残してよい情報を決める:顧客名、案件コード、候補日など、必要最小限を定義します。
  3. 残してはいけない情報の保管先を決める:評価メモ、契約条件、個人番号は CRM、ATS、Drive の制御済み領域へ逃がします。
  4. OU 単位で段階導入する:営業、採用、CS のようにリスクが高い部門から始めます。
  5. 月次で違反内容を見直す:audit と warn のログから、教育で解決するものと block へ上げるものを分けます。

このとき、2026年6月3日の GA と、2026年5月27日開始の添付ファイル / proximity 条件の GA を別々のニュースとして追うより、Calendar の自由記述欄保護が増え、Workspace DLP 全体の部品がそろってきた と捉える方が実務に使いやすくなります。

よくある質問

Google Calendar DLP は何を検知しますか?

Google の公式案内では、予定のタイトル、説明、場所の自由記述欄を検知対象にできます。予定本文へ書かれた機密情報を audit、warn、block で制御する機能です。

iPhone や Android の Calendar 利用でも効きますか?

効きます。Google の案内では、Android、iOS、または Calendar API 経由で更新がブロックされた場合、自動メールで違反理由が通知されます。Web だけの機能ではありません。

添付ファイルの DLP も Calendar でそのまま扱えますか?

そのままではありません。添付ファイル条件や proximity matching は、Gmail、Drive、Chat 側の DLP 拡張として考える方が正確です。Calendar DLP は予定本文の自由記述欄が主対象です。

最初から block にした方が安全ですか?

高リスクの予定には有効ですが、全社一律で block にすると運用が止まりやすくなります。初期は audit と warn で実態を見てから、部門や予定種別ごとに block を強める方が現実的です。

既存の Workspace DLP 記事とどう使い分ければよいですか?

このページは Calendar に特化した運用記事です。Gmail、Drive、Sheets、Gemini を含めた横断設計は Google Workspace DLPでCRMデータを守る方法 で整理するとつながります。

関連ページと関連記事

Google Workspace の DLP 設計を整理したい方へ

Calendar、Gmail、Drive、Chat、Gemini をまたぐ DLP 設計は、単機能の説明だけでは運用に落ちません。ファネルAiでは、どの情報をどこへ残し、どのチャネルで止め、どこで監査するかを実務フローに沿って整理できます。

Google Workspace の DLP 設計を相談する

メディア一覧へ戻る