「取引先を招待した打ち合わせの予定に、社内向けの但し書きがそのまま残っていた」——先方から指摘されて初めて気づく、という形で表面化します。予定のタイトルに案件名を入れ、説明欄に社内の事情を書き、そのまま外部のゲストを追加する。悪意はなく、単にカレンダーが「社内のメモ帳」として使われているだけです。
メールには添付の制限をかけ、ドライブには共有設定の棚卸しをした。それでもカレンダーだけ手つかずになっている会社は珍しくありません。理由ははっきりしていて、これまでカレンダーには止める仕組みがなかったからです。
カレンダーが対策の穴になっていた理由
情報漏洩対策（DLP）は、機密にあたる文字列を検出して、監査・警告・ブロックのいずれかを行う仕組みです。Google Workspace では Gmail とドライブ、そしてチャットに順次入ってきました。
一方カレンダーは長く対象外でした。ところが実際に業務を見ていくと、カレンダーには次のようなものが平然と書かれています。
- 予定のタイトルに、まだ公表していない案件名や社名
- 説明欄に、会議室の入館コードや接続用のパスワード
- 場所の欄に、相手先の住所と担当者名
- 添付として、その会議で使う資料そのもの
そして予定は、ゲストを1人追加した瞬間にその全部が相手へ渡ります。 ドライブの共有と違って、招待は日常動作です。「この人にも出てもらおう」という判断に、共有設定の確認は挟まりません。
さらに厄介なのが、予定の内容がAIアシスタントの参照対象にもなることです。要約や検索の便利さは、そのまま「書いてあるものが引き当てられやすくなる」ことを意味します。カレンダーに書いた但し書きは、書いた本人が忘れた後も残り続けます。
何ができるようになったか
Googleカレンダー向けのデータ損失防止ポリシーは、2026年2月11日にベータとして提供が始まり、その後 GA（一般提供）に入りました（Data loss prevention policies for Google Calendar now available in GA — Google Workspace Updates）。
検査の対象になるのは、予定のタイトル・説明・場所です。クレジットカード番号や各国の個人識別番号といった定義済みの検出項目のほか、自社で定義した正規表現や単語リストも使えます。
管理者が選べる動作は3つです。
| 動作 | 何が起きるか | 向いている使い方 |
|---|---|---|
| 監査（audit） | 利用者には何も起きず、記録だけ残る | 導入初期。どのくらい引っかかるかを測る |
| 警告（warn） | 保存時に利用者へ注意が出る。保存自体は可能 | 運用に乗せる段階。判断は現場に残す |
| ブロック（block） | 予定の作成・更新そのものを止める | 定義が固まった、絶対に出したくない項目だけ |
あわせて2026年6月には、Workspace 以外のファイル形式の添付に対する DLP と、近接条件（proximity） が一般提供に入りました（New data loss prevention capabilities for file attachments and proximity conditions are generally available — Google Workspace Updates）。添付についてはファイル拡張子・ファイル名・ファイル種別を条件にでき、近接条件では2つの一致文字列の距離を最大1,000文字まで指定できます。
近接条件は地味に見えて、誤検知を減らす効き方をします。「数字の並びが12桁ある」だけで止めると社内の伝票番号まで引っかかりますが、「『口座』という語の近くに数字の並びがある」なら精度が上がります。
「うちの管理コンソールには出てこない」場合
設定しようとして項目が見当たらない、という相談がいちばん多く出ます。原因はほぼエディションです。
Workspace の DLP は上位エディション向けの機能で、Business Starter / Standard / Plus では使えません。 カレンダー向けのポリシーもベータの段階から Enterprise Standard 以上が対象とされていました。自社が Business プランであれば、管理コンソールをいくら探しても出てきません。
ここで「では Enterprise に上げるか」と即断する必要はありません。DLP のためだけにエディションを上げると、費用が人数分で効いてきます。Business プランのままで取れる代替の打ち手はGoogle WorkspaceのDLPはBusinessプランでは使えないで整理しているので、まずそちらで現実的な線を引いてください。Gmail 側を含めた DLP 全体の考え方はGmailを含む統合DLPにまとめています。
いきなりブロックから入ると、翌週に外される
エディションの条件を満たしていて設定できる場合でも、最初からブロックを入れるのは勧めません。理由は運用面です。
予定の作成を止められた利用者は、その場で仕事が止まります。 会議の直前に予定を作ろうとしてブロックされ、なぜ止まったのか分からない。この状態が数人に起きると、情報システム担当への問い合わせが集中し、たいてい「いったん外そう」で終わります。
順序としては次のようにするのが安全です。
- 監査だけを有効にして2週間動かす。 この間、利用者には何も起きません
- 記録を見て、実際に何が引っかかったかを数える。 予想と違う項目が上位に来ることが多いはずです
- 誤検知の多い条件を外し、近接条件などで絞る
- 残った条件を警告に上げる。 ここで初めて利用者に見える形になります
- 数か月運用して苦情が出ない条件だけ、ブロックに上げる
2番の「実際に何が引っかかったか」を見るには、DLP のインシデントレポートを使います（DLP インシデント レポート — Google Workspace 管理者 ヘルプ）。ここを見ずに条件を足していくと、誤検知の山を作ってから運用を始めることになります。
なお、カレンダーには DLP とは別に、非公開の予定の中身を代理人に見せないという設定も入りました。代理権限の設計とあわせて見る場合はGoogleカレンダーに「非公開の予定を見せない」設定が入ったを参照してください。DLP は「書かれた内容」を、代理設定は「見える相手」を制御するもので、どちらか一方では塞がりません。
設定より先に、1つだけ数えてほしいこと
管理コンソールを開く前に確認しておくと判断が早くなることがあります。直近1か月で、外部ゲストを含む予定が何件あったかです。
カレンダーの検索で外部ドメインのゲストを含む予定を絞り込めば、おおよその数は出ます。この数が月に数件しかない会社であれば、DLP を組むより「外部を招待する予定はタイトルを案件名にしない」という運用ルール1本のほうが早く効きます。逆に週に何十件もあるなら、人の注意力に任せる設計はいずれ破れます。
打ち手の重さを決めるのは機能の有無ではなく、その会社で外部との予定が日常かどうかです。ここを数えないまま設定を組むと、使われない仕組みが1つ増えます。
カレンダーを含めた情報の出口を一度通しで点検したい、Business プランのままどこまで守れるかを整理したい——そうしたご相談は、グリームハブのIT・Google Workspace 無料相談で承っています。要件によって最適な構成は変わるため、個別にお見積りします。お問い合わせからご相談ください。
Sources
- Data loss prevention policies for Google Calendar now available in GA — Google Workspace Updates
- Data loss prevention policies for Google Calendar now available in beta — Google Workspace Updates（2026年2月11日）
- New data loss prevention capabilities for file attachments and proximity conditions are generally available — Google Workspace Updates（2026年6月）
- GoogleカレンダーにDLPポリシーを設定する方法 — Qiita
- DLP インシデント レポート — Google Workspace 管理者 ヘルプ
