お問い合わせ
SECURITY NOTE — 124

Google Calendar DLP 設定チェックリストと誤検知対策

PUBLISHED2026.06.05
READ9 分
CATEGORYSECURITY

2026年6月3日、Google Workspace の DLP（Data Loss Prevention、データ損失防止）機能がカレンダーに対応し、正式リリース（GA）になりました。カレンダー予定のタイトル・説明・場所の3フィールドが検出対象となり、情シスは既存の DLP ポリシーにこのスコープを追加する実装フェーズに入ります。

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

  • Google Workspace の DLP ポリシーを管理している情シス担当者
  • Calendar DLP の GA を受けて展開計画を立てようとしている方
  • Drive や Gmail 向けの DLP は設定済みで、カレンダーへの拡張を検討している方
  • 誤検知を最小化しながら段階的に展開したい方

対象エディションと事前確認

Calendar DLP は利用できるエディションが限定されています。Google Workspace 管理コンソールのヘルプで確認した対象エディションは以下の通りです。

  • Enterprise Standard / Enterprise Plus
  • Education Fundamentals / Education Standard / Education Plus
  • Enterprise Essentials
  • Frontline Standard / Frontline Plus
  • Cloud Identity Premium

Business プラン（Starter・Standard・Plus）はこのリストに含まれていません。エディションの確認は展開計画の前提になるため、まず管理コンソールで契約プランを確認します。

対象エディションに含まれていない場合、Calendar DLP の設定画面自体が管理コンソールに表示されないか、カレンダーをポリシー適用先として選択できない状態になります。この場合はプランのアップグレードを検討するか、Calendar DLP は対象外として他の手段（共有設定の制限・ユーザー教育など）で対応する判断が必要になります。

展開前に確認しておくべき項目を表にまとめます。

確認項目 内容
エディション確認 自社の契約エディションが対象エディションに含まれるか
既存DLPポリシーの棚卸し Drive・Gmail・Chat 向けに作成済みの検出器を Calendar に流用できるか
OU構成の整理 どの OU（Organizational Unit、組織単位）から先行展開するか優先順位をつける
機能の有効化確認 Calendar DLP はデフォルト OFF。有効化するまで機能は動かない
管理者権限の確認 DLP ポリシーの作成・編集には「DLP ルールの管理（Manage DLP rule）」権限を付与したカスタム管理者ロール、またはスーパー管理者が必要

既存の Drive・Gmail 向け DLP ポリシーがある場合、その中のカスタム検出器（正規表現・キーワードリスト）はカレンダーのポリシーにも流用できます。ただし、Drive や Gmail で問題なく動いていた検出器でも、カレンダーの短いフィールドでは誤検知率が上がることがあります。既存検出器をそのまま適用するのではなく、本記事のチェックリストに沿ってフィールドごとに動作を確認してから本番展開することを推奨します。

Calendar DLP で検出されるフィールドと優先設定の考え方

Calendar DLP が検出対象とするのは、カレンダー予定の3つの自由入力フィールドです（Google Workspace 管理コンソールのヘルプより）。

  • タイトル
  • 説明（Description）
  • 場所（Location）

添付ファイルは Calendar DLP の対象外です。添付ファイルへの DLP は Drive DLP が別途適用されます。公式ヘルプで検出対象として明示されているのは上記3フィールドのみです。

フィールドごとの特性と推奨アクションを整理します。

フィールド 機密情報の混入リスク 誤検知リスク 推奨アクション
タイトル 高（案件コード・顧客名が含まれやすい） 中（短文ゆえに過剰マッチが起きやすい） 監査で実態確認後、警告へ移行
説明 高（詳細な顧客情報・個人情報が記載されることがある） 低（文脈が豊富で精度が上がりやすい） 監査から始めて検出件数を把握
場所 中（顧客拠点名・社外会議室の住所） 高（社内会議室名との干渉リスクがある） 当初は監査のみを推奨

3フィールドすべてに同一の検出器を適用するより、フィールドの特性に合わせてポリシーを分けた方が運用しやすくなります。特に場所フィールドは誤検知リスクが他の2フィールドより高いため、独立したポリシーとして扱うことを推奨します。

また、DLP ポリシーは OU 単位だけでなく、グループ（Google グループ）を対象に設定することもできます。特定の部署（法務・人事・経営企画など）だけを先行対象にしてパイロット展開する際、OU 境界とグループ境界のどちらを使うかも事前に決めておく必要があります。OU は組織の木構造に沿った継承が働くため、上位 OU に設定を置いた場合は配下のすべてのユーザーに影響します。意図しない範囲への適用を防ぐため、最初は葉に近い OU かグループ指定でのパイロット展開が安全です。

Google Calendar DLP の誤検知パターンと対処法

Drive や Gmail では問題なかった検出器でも、カレンダーの短いフィールド（特にタイトルと場所）では誤検知が多くなる場合があります。以下は発生しやすいパターンと対処法の整理です。

誤検知パターン 発生しやすいフィールド 原因 対処法
会議室名がカスタムキーワードと一致 場所 「Project Alpha会議室」「Exec Room」等の命名がカスタム検出器の単語リストと合致 場所フィールドのみ「監査のみ」で運用。誤検知件数が多ければ除外リストに会議室名を追加
社内プロジェクトコード形式が過剰マッチ タイトル 「PRJ-1234」形式の正規表現が社内の全コードに反応 最小文字数の引き上げ、またはコンテキスト条件を追加して精度を向上させる
電話番号形式の内線番号 説明・タイトル 「内線0120」「03-XXXX-XXXX」形式が電話番号検出器に反応 組み込みの電話番号検出器は汎用的なため、カスタム検出器で内線番号パターンを除外したものに切り替える
一般語を含む顧客名・製品名 タイトル・説明 顧客名の一部が一般名詞と一致してしまいマッチする 完全一致または単語境界付きの正規表現に絞る

精度改善に有効な手段の一つが近接マッチ（proximity matching）です。これは Google Workspace DLP の公式機能として提供されており、キーワードの前後に特定の語句が存在する場合のみ検出する条件を加えられます。Drive や Gmail での運用実績がある検出器をカレンダーに流用する際、誤検知が増えた場合はこの条件を追加することで精度が改善するケースがあります。

誤検知の調査には管理コンソールのセキュリティ調査ツールが使えます。DLP ルールのログイベントをフィールド・アクション・ルール名で絞り込むと、どのルールがどのフィールドで何件発火したかを把握できます。監査モード運用中はこのツールを定期的に確認して、本格展開前に誤検知の傾向を掴んでおく必要があります。ルール発火件数が多い場合でも、中身を精査せずにブロックへ移行するのは危険です。まず「正検知か誤検知か」を件数ベースで確認することを優先してください。

また、ユーザー自身が誤検知と判断した場合、警告モードでは「保存して続行」を選べます。一方、ブロックモードでは保存そのものができなくなるため、業務上どうしても機密情報を含む予定情報を扱わざるを得ない部署（例：役員秘書・法務担当）は、例外フローの整備が特に重要です。

OU単位の段階展開チェックリスト

カレンダーは Drive や Gmail と比べて短い文字列を大量に扱う特性があります。全社一斉展開ではなく、OU ごとに段階的に進めることを推奨します。

フェーズ1：監査モード（Audit）でのパイロット展開

監査モードはイベントの作成・更新をブロックせず、検出件数をログに記録するだけです。まずここから始めて実態を把握します。

  • [ ] 対象エディションで Calendar DLP が利用可能なことを確認
  • [ ] 機密情報を扱う頻度が高い OU（経営企画・人事・法務等）を優先対象として選定
  • [ ] 既存の Drive / Gmail 向け検出器を Calendar に適用し、監査モードで展開
  • [ ] 1〜2週間の監査期間を設け、ルールログイベントを確認
  • [ ] 検出件数の内訳を把握し、誤検知と思われる検出をセキュリティ調査ツールで精査
  • [ ] 検出器の修正候補リストを作成し、次のフェーズ移行の判断基準を明確にする

パイロット対象 OU を選ぶ際は、機密情報の取り扱い頻度が高く、かつ IT リテラシーが比較的高い部署を選ぶと後続の展開がスムーズです。フェーズ1からフェーズ2に移るタイミングの目安は、誤検知と判断できる検出が全体の10%程度以下に安定してきた状態です。

フェーズ2：警告モード（Warn）への移行

警告モードはユーザーに通知するだけで操作はブロックしません。誤検知の修正が終わったタイミングで移行します。

  • [ ] フェーズ1で特定した誤検知ルールの条件を修正、または除外リストを追加
  • [ ] 警告メッセージの文面を整備（何が問題で、どう対応するかをユーザーに伝える内容にする）
  • [ ] 対象ユーザーへの事前周知（警告ポップアップが出ても業務停止ではない旨を明示）
  • [ ] 警告モードを追加の OU へ展開
  • [ ] 2週間程度、「警告を無視して保存」する件数をモニタリング
  • [ ] 警告の無視率が高い場合は、ユーザーへの再教育または検出ルールの精度改善を先に行う

誤検知の修正が不十分なまま警告モードに切り替えると、ユーザーが警告そのものを無視するようになります。後のブロックモード移行時に強い反発を受けるリスクがあるため、フェーズ1での誤検知修正を先に完了させることがフェーズ移行を成功させる鍵です。

フェーズ3：ブロックモード（Block）の判断

ブロックモードはイベントの作成・更新そのものを止めます。業務への影響が大きいため、慎重に判断します。

  • [ ] 警告を無視する件数が継続的に多い場合に、ブロックへの移行を検討
  • [ ] ブロックが業務フローに与える影響を事前に評価
  • [ ] 緊急時の例外申請フローを社内で整備（外部共有が避けられないケースへの対応策）
  • [ ] ブロック時のカスタムメッセージに問い合わせ先を明記
  • [ ] モバイル・API 経由でのブロック時はメール通知が届くことをユーザーに周知
  • [ ] 全社向けの変更アナウンスを実施してからブロックを適用

複数のルールが競合する場合は、より厳しいアクションが優先されます（公式ヘルプより）。OU 展開を増やすタイミングで想定外のルール競合が起きる場合があるため、展開ごとにルールの優先順位を確認してください。

ブロックモードへの移行を焦る必要はありません。多くの情シス現場では、監査モードと警告モードの2段階だけで必要なリスク低減が達成できます。ブロックは「最後の手段」として位置づけ、業務インパクトのリスクアセスメントを行った上で経営層の承認を得てから適用することを推奨します。

まとめ：Calendar DLP展開で最初にやること

Calendar DLP は 2026年6月3日の GA 以降、対象エディションのテナントで利用可能になりましたが、デフォルトは OFF です。意図的に有効化するまで機能は動きません。

展開の起点として、最初の優先順位を3つに絞ります。

  1. エディション確認と既存 DLP ポリシーの棚卸し
  2. 機密情報を扱う OU に絞った監査モードでのパイロット展開
  3. 場所フィールドを独立したポリシーとして扱い、誤検知リスクを切り離す

Calendar DLP は監査ログを見ながら検出器を育てていく運用が前提の機能です。特に場所フィールドは誤検知が起きやすいため、他のフィールドより慎重に進めることが実装の安定につながります。

一点、見落としやすい挙動を補足します。Calendar DLP はカレンダー予定の更新時にも判定が走ります。つまり、過去に作成した予定を編集すると、その時点のポリシーで再評価されます。展開後に全社員が一斉に既存の予定を編集するようなタイミング（例：年次のカレンダー整理や会議体の見直し）が重なると、予期しないブロックや警告が大量発生する可能性があります。展開スケジュールを決める際は、大規模なカレンダー編集作業との重複を避けるか、そのタイミングを事前にユーザーに周知しておくことを推奨します。

DLP for Calendar の基本的な設定方法については、DRASENAS ブログの「GoogleカレンダーにDLPポリシーを設定する方法」も参考にしてください。

DLP ポリシー全体の設計・棚卸しが必要な場合は、ぜひ DRASENAS にご相談ください。Calendar DLP 導入時の要件整理から展開支援まで対応します。

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

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

CONTACT

御社の IT 部門、ここにあります。

「ITのことはあまりわからない」── そのような状態からで、まったく問題ございません。まずはお気軽にご相談ください。

無料相談を予約する → サービス詳細を見る
一社ずつ、一から。