お問い合わせ
AUTOMATION NOTE — 139

Gmail DLP 誤検知削減：双方向設計と月次改善サイクル

PUBLISHED2026.06.10
READ9 分
CATEGORYAUTOMATION

Google Workspace の DLP（Data Loss Prevention）は Gmail の送受信で機密情報を検出できる機能で、送信方向にはブロック・隔離・警告が設定可能です。Enterprise Standard / Plus、Frontline Standard・Plus、Education 各エディション向けに提供されています。この記事では、誤検知が発生する構造的な原因の整理から、送受信双方向のフィルタリング設計・BigQuery による月次誤検知率モニタリング・GAS（Google Apps Script）を使った除外リスト半自動更新まで、運用改善サイクル全体を設計します。

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

  • Gmail の DLP ルールを本番運用しており、誤検知によるユーザー苦情が増えている情シス担当者
  • DLP ルールの中身は大きく触りたくないが、運用負担を下げる方法を探している方
  • BigQuery に Workspace 監査ログをエクスポートしている、またはこれから設定しようとしている方
  • 月次で DLP の有効性を数値で測る仕組みを作りたい方

なぜ Gmail DLP 誤検知削減が難しいのか

Gmail DLP の公式ヘルプによると、ルールはメール本文・件名・添付ファイル（20 種類以上のファイル形式）をスキャンします。誤検知が増える原因は主に次の 3 点に集約されます。

  • コンテンツ検出器の粒度が粗い: Google が用意するプリセット検出器（クレジットカード番号・マイナンバー等）は汎用パターンで設計されている。クレジットカード番号の検出器は「16 桁の数字列 + Luhn チェックサム」を条件にするため、社内製品コードや注文番号、会員番号など類似フォーマットの数値でも誤発火する
  • ルールが累積して優先度設計が崩れる: 複数ルールが同一メールに適用された場合、最も厳しいアクション（ブロック ＞ 隔離 ＞ 警告 ＞ 監査のみ）が自動的に適用される。「CC 番号検出」ルールと「CC 番号 + 個人情報の組み合わせ検出」ルールが共存すると、後者が意図せず先に発動することがある
  • 除外リスト（アローリスト）を更新していない: 初回設定時に登録した信頼済みドメインは、取引先が増えても更新されないまま放置されやすい。50 名規模の組織でも 1 年で取引先ドメインが 10〜20 件変化する可能性があり、除外リストが実態に追いつかなくなる

多くの現場ではルールの精度改善に時間を使いがちですが、実際には「除外リストの整備」と「定期的な誤検知率モニタリング」を先に整えるほうが改善効率は高くなります。ルール設計は一度作ると触りにくいからこそ、運用で補う仕組みが重要です。

送信・受信の双方向フィルタリング設計

Gmail DLP には設定できる対象方向（送信 / 受信 / 内部）があります。公式ヘルプによると、ブロック・隔離・警告といった能動的なアクションは送信方向のみ適用可能で、受信方向に対しては「監査のみ（Audit only）」と分類ラベルの付与に限定されています。

情シス実務でよく見落とされるのが、「受信 DLP は検出ログ取得に使い、受信ブロックには別の仕組みを組み合わせる」という役割分担です。以下が双方向の設計方針をまとめた一覧です。

方向 DLP ルールで設定可能なアクション 補足
送信（外部・内部） ブロック / 隔離 / 警告 / 監査のみ 機密情報の外部流出を直接抑制できる
受信 監査のみ / 分類ラベル ブロックには別機能を組み合わせる

受信メールのフィルタリングを強化する場合は、管理コンソールの Gmail コンプライアンス設定にあるコンテンツコンプライアンスルールを活用します。こちらは受信メールに対してもルーティング変更や拒否が設定できます。「DLP ルールで受信の監査ログを取る、コンテンツコンプライアンスルールで受信ブロックを実施する」という組み合わせが、双方向フィルタリング設計の基本構成です。

内部方向（組織内メール）のカバレッジについても触れておきます。DLP ルールは「組織内送信」を対象にすることも可能です。内部向けのルールを設定する際は、外部宛てと同じ検出器を使いながらアクションを「監査のみ」に抑えるケースが多く見られます。最初から「内部はブロック」に設定すると正当業務が止まるリスクが高いため、最低 2〜3 か月の監査ログ収集期間を置いてから強度を上げるのが現実的な選択です。

除外リストの設計：誤検知を構造的に減らす

誤検知削減の第一手はルール本体の精度改善ではなく、「信頼済みのやり取りを除外する仕組みを先に整備する」ことです。

除外対象の典型パターンは以下の通りです。

  • 取引先ドメイン: 長期取引のある会計事務所・法律事務所・外注先。「財務情報が含まれていても問題ない相手」を明示的に許可する
  • 内部システムの通知メール: 社内ツールから送られる定型フォーマットのメール（受注番号・請求番号が本文に含まれるもの）。送信者アドレスが固定であれば、ドメイン全体ではなくアドレス単位で除外するほうが影響範囲を絞りやすい
  • 特定の組織部門（OU）の送信: 経理・法務など、業務上必然的に財務情報や個人情報を扱う部署。OU 単位でルールの適用対象から外す設定が可能

「ドメイン単位で除外するか、送信者アドレス単位で除外するか」は影響範囲の広さで判断します。取引先の全アドレスを許可してよいならドメイン単位、特定の担当者だけなら送信者アドレス単位にすることで、不要なリスクを最小化できます。

除外対象はスプレッドシート 1 枚で一元管理するのが現実的です。以下の列構成を推奨します。

列 記載内容
ドメイン / 送信者アドレス 除外対象の識別子
対象ルール名 どの DLP ルールで除外するか
除外理由 信頼できる根拠（例: 3 年以上の継続取引先）
承認者 情シスリーダーまたは上長の名前
承認日 YYYY-MM-DD 形式
次回レビュー日 承認日から 6 か月後を基準に設定

「誰が承認した除外なのか」が追跡できる状態にしておくと、半年後の棚卸しでも迷いません。

BigQuery で月次誤検知レポートを作る

Workspace 監査ログを BigQuery にエクスポートすると、DLP の発動履歴を SQL で分析できます。エクスポートの設定は管理コンソールの「レポート」>「データ統合」から行います。有効化すると、Gmail 関連のイベントが BigQuery のテーブルに自動で書き込まれます。テーブル名は組織のプロジェクト設定によりますが、gmail_activity_YYYYMMDD のような日付サフィックス付きパーティションテーブルとして作成されることが一般的です。

エクスポートを有効化した後は、BigQuery のスキーマ画面でテーブル名とフィールド名を確認します。特に DLP 関連のイベント名（event_name）と、ルール名が格納されているパラメータのキー名（event_parameters 内）は組織ごとに異なる場合があります。クエリを実行する前に、実際のテーブルを 1 件サンプリングして構造を把握しておくのが確実です。

以下のクエリは「月別・ルール別の DLP 発動件数」と「管理者が隔離を解放した件数（誤検知として扱われた件数）」を集計するサンプルです。テーブル名・フィールド名・イベント名は組織の BigQuery エクスポート設定によって異なるため、実際のスキーマと照合した上で調整してください。

-- Gmail DLP 月次誤検知率レポート
-- ★ テーブル名・フィールド名・イベント名は実際のエクスポートスキーマに合わせて変更すること
WITH dlp_events AS (
  SELECT
    FORMAT_DATE('%Y-%m', DATE(time))  AS month,
    actor_email,
    event_name,
    -- DLP ルール名が格納されているパラメータ名は環境により異なる
    (SELECT value FROM UNNEST(event_parameters) WHERE name = 'RULE_NAME') AS rule_name
  FROM
    `your_project.workspace_audit.gmail_activity_*`  -- 実際のテーブル名に変更
  WHERE
    event_name IN ('DLP_RULE_VIOLATION', 'MESSAGE_QUARANTINED')
),
released AS (
  SELECT
    FORMAT_DATE('%Y-%m', DATE(time)) AS month,
    (SELECT value FROM UNNEST(event_parameters) WHERE name = 'RULE_NAME') AS rule_name,
    COUNT(*) AS released_count
  FROM
    `your_project.workspace_audit.gmail_activity_*`
  WHERE
    event_name = 'QUARANTINE_RELEASED'  -- 管理者が「解放」したイベント名を確認して設定
  GROUP BY 1, 2
)
SELECT
  d.month,
  d.rule_name,
  COUNT(*)                                                   AS triggered_count,
  COALESCE(r.released_count, 0)                             AS false_positive_count,
  ROUND(COALESCE(r.released_count, 0) / COUNT(*) * 100, 1) AS false_positive_rate_pct
FROM
  dlp_events d
LEFT JOIN released r
  ON d.month = r.month AND d.rule_name = r.rule_name
GROUP BY 1, 2, r.released_count
ORDER BY d.month DESC, false_positive_rate_pct DESC;

結果を読む際の目安は次の通りです。

  • 誤検知率 10% 未満: 許容範囲。月次確認を継続
  • 誤検知率 10〜30%: 除外リスト追加を優先検討。対象ルールの除外候補を洗い出す
  • 誤検知率 30% 超: ルール設計の見直しが必要。カスタム正規表現の精度向上や近接語の追加を検討する

誤検知率 30% 超のルールが 3 本以上ある場合は、個別対応より「ルール全体の設計を見直す段階」と判断するのが現実的です。

GAS（Google Apps Script）で除外候補を半自動集計する

管理者が「解放（リリース）」した隔離メールのログをスプレッドシートに蓄積し、同一送信者ドメインが一定回数以上出現したら「除外候補」タブに自動追記する仕組みです。最終的な承認は人間が行うため、「提案 → 承認 → 反映」のサイクルを維持できます。

スプレッドシートのシート構成は次の通りです。

  • DLPログ シート: 列は timestamp / sender_domain / rule_name / action。DLP 発動ログを BigQuery から定期エクスポートして貼り付ける
  • 除外候補 シート: 列は ドメイン / ルール名 / 件数 / 提案日。スクリプトが自動追記する

以下のスクリプトは上記 2 シートを持つスプレッドシートを前提とします。

/**
 * DLP 解放済みメールのログを集計し、除外候補をシートに書き出す
 * トリガー: 毎週月曜 AM 9:00 で設定推奨
 */
function proposeFalsePositiveExclusions() {
  const SS = SpreadsheetApp.getActiveSpreadsheet();
  const logSheet       = SS.getSheetByName('DLPログ');
  const candidateSheet = SS.getSheetByName('除外候補');

  if (!logSheet || !candidateSheet) {
    Logger.log('「DLPログ」または「除外候補」シートが見つかりません');
    return;
  }

  // 直近 30 日分のログを取得（1 行目はヘッダーのためスライス）
  const cutoff = new Date();
  cutoff.setDate(cutoff.getDate() - 30);
  const data = logSheet.getDataRange().getValues().slice(1);

  // sender_domain × rule_name の解放件数を集計
  const countMap = {};
  data.forEach(row => {
    if (new Date(row[0]) < cutoff) return;
    if (row[3] !== 'RELEASED') return;  // 管理者が解放したもののみ
    const key = `${row[1]}|||${row[2]}`;
    countMap[key] = (countMap[key] || 0) + 1;
  });

  // 既登録のキーを取得（重複追記を防ぐ）
  const existing = candidateSheet.getDataRange().getValues()
    .map(r => `${r[0]}|||${r[1]}`);

  // 閾値（月 3 回以上）を超えた未登録エントリを追記
  const THRESHOLD = 3;
  const today     = Utilities.formatDate(new Date(), 'Asia/Tokyo', 'yyyy-MM-dd');
  const newRows   = [];

  Object.entries(countMap).forEach(([key, count]) => {
    if (count >= THRESHOLD && !existing.includes(key)) {
      const [domain, rule] = key.split('|||');
      newRows.push([domain, rule, count, today]);
    }
  });

  if (newRows.length > 0) {
    candidateSheet.getRange(
      candidateSheet.getLastRow() + 1, 1, newRows.length, 4
    ).setValues(newRows);
    Logger.log(`${newRows.length} 件の除外候補を追記しました`);
  } else {
    Logger.log('新規の除外候補はありません');
  }
}

THRESHOLD の 3 という値は組織のメール量に合わせて調整してください。50 名以下の組織では 2 回、500 名超の組織では 5 回程度が現実的な閾値です。

スクリプトの設定は、スプレッドシートを開いて Apps Script エディタにコードを貼り付け、トリガー設定から「時間主導型 → 週タイマー → 月曜 午前 9 時〜10 時」を指定します。DLP ルール本体への反映は、除外候補シートで承認を確認した後に管理コンソールのルール設定から手動で行います。自動で除外リストを更新する実装は、承認フローを省略するリスクが高いため、このサイクルでは意図的に外しています。

月次改善サイクルの進め方：30 分で回す

BigQuery レポートと除外候補シートを組み合わせると、月 1 回の DLP チューニングを短時間で完結できます。次の順序で進めるのが効率的です。

  1. BigQuery クエリを実行する（5 分）: 誤検知率上位 5 ルールを抽出し、前月比の変化を確認する。急増しているルールがあれば優先度を上げる
  2. 除外候補シートを確認する（10 分）: 閾値超えのドメインが正当な取引先かを確認する。承認 / 否認を記録列に入力し、承認したものだけを管理コンソールへの反映対象とする
  3. 管理コンソールで反映する（10 分）: 承認したドメインを対象ルールの除外リストに追加する。変更後は「最終更新日・更新者」をスプレッドシートに記録する
  4. 高誤検知率ルールの調整を検討する（5 分）: 誤検知率が 30% を超えているルールはカスタム正規表現の精度向上や近接語の追加も検討する。大規模な変更が必要な場合はこの場で決めず、別途時間を取る
  5. 次月比較のベースを記録する（2 分）: 今月の誤検知率をスプレッドシートに転記し、翌月の比較に使う

このサイクルを 3 か月継続すると、誤検知率が高かったルールの多くは除外リストの整備だけで改善されます。4〜6 か月目以降に残っているルールが、コンテンツ検出器そのものの設計課題です。そこで初めてカスタム正規表現の精度改善やルール削除を検討するという流れが、運用負担と精度のバランスを保ちやすくします。

セキュリティ上のリスクが高い除外申請（未知ドメインや社外フリーアドレスからの大量受信ドメイン）は、月次サイクルの中で即決せず、セキュリティ担当者や上長に確認を取ってから反映するフローを組み込むことを推奨します。承認者が情シスの 1 名だけだと、判断ミスが直接リスクに繋がります。

まとめ：設定より運用サイクルが DLP の効果を決める

Gmail DLP の誤検知問題は、ルールの設定内容よりも「誰がいつ何を見直すか」というサイクル設計で解決できることが多いです。ここで押さえておきたい点を整理します。

  • 送信方向の DLP ルールと受信方向のコンテンツコンプライアンスルールは役割が異なる。目的に合わせて使い分ける
  • 誤検知削減の第一手は除外リストの整備。ルール本体の精度改善はその後
  • BigQuery レポートで「ルール別誤検知率」を数値化すると、手を入れるべき箇所が明確になる
  • GAS による半自動化も、最終判断は人間が担う設計にしておくことが継続運用の鍵
  • 高リスクな除外申請は複数人による承認フローを組み込んでおく

DLP は導入した瞬間よりも、導入後の改善サイクルに価値があります。BigQuery とスプレッドシートという手元にある道具を組み合わせれば、追加ツールなしで月次チューニングの仕組みは作れます。まずは BigQuery エクスポートの有効化と誤検知率クエリの実行から着手するのが、最初の現実的な一歩です。

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

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

CONTACT

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

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

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