お問い合わせ
AUTOMATION NOTE — 187

GWS 監査ログ異常検知 BigQuery×AI 設計

PUBLISHED2026.06.23
READ12 分
CATEGORYAUTOMATION

Google Workspace の BigQuery Export を有効にすると、Admin・Login・Drive・Meet など複数サービスの監査ログを一元的に BigQuery へ蓄積できます。本記事では、管理コンソールのアラートセンターが対応するルールベース検知では拾えない「統計的に異常なスパイク」を、全ログ横断で自動発見するパイプラインの設計方針を解説します。

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

  • GWS Enterprise Standard/Plus 以上のエディションで BigQuery Export を有効化済み、または有効化を検討中の情シス担当者（Business Starter・Business Standard では BigQuery Export を利用できません）
  • GAS（Google Apps Script）で既知ルールのアラートを組んでいるが、未知の異常パターンへの対応に限界を感じている方
  • BigQuery 上のログ分析をセキュリティ監視に活用する具体的な設計イメージを固めたい方
  • Drive 単体の異常検知は把握済みで、全ログ横断の時系列スパイク検知に発展させたい方

ルールベース検知の限界：スパイク検知が必要な理由

GWS の管理コンソールには Alert Center（アラートセンター）が組み込まれており、「フィッシングメールの大量着信」「ユーザーへの管理者権限付与」「政府系攻撃者からの警告」など、Google が事前に定義した脅威パターンに対応したルールが標準提供されています。一般的な既知の攻撃パターンは網羅されており、多くの組織にとって出発点として有効です。

問題は、このルールの外側にある灰色地帯の操作です。以下のようなケースは既存ルールでは検知されません。

  • 深夜 2 時に特定の管理者アカウントが連続して権限変更を実行する
  • 普段ほぼ操作しないユーザーが 1 時間で数百ファイルをダウンロードする
  • Meet の録音エクスポートが特定の時間帯だけ集中する
  • 1 名のユーザーから外部共有リンクが短時間に大量生成される

いずれも「悪意があるかは文脈次第だが、統計的に見て平常と明らかに異なる」パターンです。退職を間近に控えたユーザーが数百件の Drive ファイルをダウンロードするケースも、業務上の正当な手続きである可能性はあります。しかし「通常の 10 倍のダウンロード件数が特定の時間帯に集中した」という事実は、意図に関わらず確認すべき出来事です。

「統計的ベースラインとの乖離（スパイク）を検出する設計」がこの課題への現実的なアプローチです。事前定義ルールに頼らず未知の異常パターンを浮かび上がらせる手法で、アラートセンターを補完する役割を担います。

Drive 単体の異常検知フレームワークについては Drive 異常検知を BigQuery×AI で設計する で別途解説しています。本記事では Admin・Login・Drive・Meet を横断した「時系列スパイク検知」に特化します。

パイプライン全体構成：4レイヤで考える

GWS 全ログ横断スパイク検知パイプラインは、大きく 4 つのレイヤに分けて設計します。

  1. ログ収集レイヤ: 管理コンソールのレポート設定から BigQuery Export を有効化し、対象サービスの監査ログを BigQuery プロジェクトへ転送します。BigQuery Export は日次で自動転送されるため、設定後は手動操作なしでログが蓄積されます
  2. 集計レイヤ: 転送されたログを BigQuery のスケジュールクエリで 1 時間単位に集計し、サービス別・ユーザー別の操作件数を時系列テーブルとして蓄積します。このテーブルがスパイク判定のインプットになります
  3. スパイク判定レイヤ: 過去 30 日分のデータから算出した平均・標準偏差をベースラインとして、当日集計値との乖離（Z スコア）を計算し、閾値を超えた行を異常候補として抽出します。Z スコアは「平均からどれだけ離れているか」を標準偏差単位で表した指標で、3 を超えると「正規分布上で全体の 0.3% 未満にあたる稀な事象」に相当します
  4. 通知レイヤ: 異常候補を AI に渡してコンテキストを付加し、情シス担当者へのアラートとして Slack や Gmail へ通知します。重複排除の仕組みを組み込み、同一事象の連続通知を防ぎます

各レイヤは独立性が高く、実装を段階的に進めやすい構造です。まず集計レイヤまで動かしてデータ品質を確認してから、スパイク判定→通知と順に拡張するアプローチが現実的です。

実装基盤の選択肢として、スケジュールクエリは BigQuery の標準機能を使うのが最もシンプルです。通知レイヤは GAS から Slack Webhook を叩く構成でも動きますが、GAS の実行時間制限（6 分）が気になる場合は Cloud Run + Cloud Scheduler の組み合わせが安定します。100 名規模の組織であれば、GAS ベースの軽量実装から始めて問題が出たら移行する判断で十分です。

GWS BigQuery Export の分析パイプライン設計

横断対象ログの選び方

BigQuery Export では、管理コンソールのレポート設定から有効化することで Admin・Login・Drive・Meet など複数サービスのログを日次で蓄積できます（Google Workspace 管理者ヘルプ「レポートログと BigQuery について」参照）。スパイク検知の目的に対して優先度が高いサービスは以下のとおりです。

サービス 監視優先度 代表的な検知シナリオ
Login 高 短時間の連続認証失敗、通常と異なる時間帯・IP からのログイン急増
Admin 高 深夜・早朝の権限変更集中、スーパー管理者操作の急増
Drive 中〜高 大量ダウンロード集中、外部共有設定の一括変更
Meet 中 録音エクスポートの異常集中、通常稼働時間外の大量利用

100 名規模の組織であれば、まず Login と Admin の 2 サービスから始め、運用が軌道に乗ってから Drive・Meet を追加するアプローチが実用的です。すべてを同時に対象にすると初期の誤報（false positive）が増え、担当者がアラートを信頼しなくなります。最初の 4 週間は「確実に問題になるもの」だけを対象にして、感度のチューニングに集中します。

BigQuery Export で蓄積されるデータ量は、組織規模・サービス数・保持期間によって変わります。まず実際に Export を有効化して 1 週間ほど溜め、SELECT service_name, COUNT(*) FROM ... で件数を確認してから保持期間設計に入るのが現実的なステップです。

ベースライン計算とスパイク判定の SQL 設計例

以下は設計参考用の SQL です。テーブル名・フィールド名は BigQuery Export のスキーマドキュメントで必ず確認してください。実際の構造は組織のプロジェクト設定によって異なります。

まず、1 時間単位でサービス別・ユーザー別の操作件数を集計するビューの設計例です。

-- 設計参考例：複数サービス横断の時間単位集計ビュー
-- テーブル名・フィールド名は BigQuery Export スキーマドキュメントで確認すること
SELECT
  actor_email,
  service_name,
  TIMESTAMP_TRUNC(event_timestamp, HOUR) AS event_hour,
  event_name,
  COUNT(*)                               AS event_count
FROM
  `your-project.workspace_audit.activity_*`
WHERE
  _TABLE_SUFFIX BETWEEN
    FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY))
    AND FORMAT_DATE('%Y%m%d', CURRENT_DATE())
  AND service_name IN ('drive', 'admin', 'login', 'meet')
GROUP BY 1, 2, 3, 4

次に、このビューを元に Z スコア（ある値が平均から何標準偏差離れているかを示す統計指標）でスパイクを判定する設計例です。Z スコアが 3 を超えた行が「統計的に異常なスパイク候補」として抽出されます。

-- 設計参考例：Zスコアによるスパイク候補の抽出
WITH baseline AS (
  SELECT
    actor_email,
    service_name,
    event_name,
    EXTRACT(HOUR FROM event_hour) AS hour_of_day,
    AVG(event_count)              AS avg_count,
    STDDEV_SAMP(event_count)      AS stddev_count
  FROM hourly_summary             -- 上記集計ビューを 30 日分参照
  WHERE event_date < CURRENT_DATE()
  GROUP BY 1, 2, 3, 4
)
SELECT
  t.actor_email,
  t.service_name,
  t.event_name,
  t.event_count,
  b.avg_count,
  SAFE_DIVIDE(
    t.event_count - b.avg_count,
    NULLIF(b.stddev_count, 0)
  )                               AS z_score
FROM today_summary t
JOIN baseline b
  USING (actor_email, service_name, event_name, hour_of_day)
WHERE SAFE_DIVIDE(
    t.event_count - b.avg_count,
    NULLIF(b.stddev_count, 0)
  ) > 3
ORDER BY z_score DESC

SAFE_DIVIDE は分母がゼロになるケースを安全に処理する BigQuery 組み込み関数です。ベースラインの標準偏差がゼロ（操作が均一すぎて変動なし）の場合は NULL を返すため、NULLIF(b.stddev_count, 0) と組み合わせて使います。

ベースラインを「ユーザー別 × 時間帯別」の 2 軸で計算する点が重要です。同一ユーザーが同一時間帯に同一操作を行う件数を基準にすることで、「業務時間内の Drive ダウンロードは多いのが普通」「管理者は平日午前中に権限変更を行う傾向がある」といった個人・組織の文脈を反映したベースラインが構築されます。ユーザー横断の一律閾値では検知できない個人特有の行動変化を捉えやすくなります。

監査ログ自動アラートの設計：情シスが考えるべき閾値

スパイク判定で重要なのは「Z スコアの閾値をどこに設定するか」ではなく、「どのイベントカテゴリでスパイクが問題になるか」を先に整理することです。カテゴリによってリスクの重みが異なるため、一律の閾値を全サービスに適用するのは避けた方がよいです。

以下は、カテゴリ別のアラート条件設計の考え方をまとめた一覧です。実際の閾値は組織規模・ユーザーの操作傾向に合わせた調整が必要です。

カテゴリ 代表的な検知シナリオ スパイク判定の軸 推奨アラート優先度
管理者操作集中 深夜の権限変更・OU 移動 時間帯 × 操作件数の Z スコア 高
認証異常 短時間での連続ログイン失敗 1時間あたりの失敗件数 Z スコア 高
ファイル大量操作 退職前後の Drive 大量ダウンロード ユーザー別 Z スコア × 時間帯フラグ 中〜高
会議系操作集中 録音エクスポートの異常集中 月次ベースラインとの件数乖離 中

Z スコア > 3 をスタートラインとして、最初の 2〜4 週間は通知を受け取るだけで誤報率を確認します。誤報が多い場合は閾値を引き上げるか、複合条件（例: 「深夜帯 AND Z スコア > 2」）に絞り込む調整を加えます。単一スコアよりも複合条件で絞る方が、海外出張中ユーザーや深夜の定期バッチ処理による誤報を大幅に減らせます。

通知頻度の管理も重要です。1 日に数十件のアラートが発生すると担当者が疲弊し、重要なアラートを見落とす「アラート疲れ」が生じます。運用開始直後は「high 優先度のみ即時通知、medium は翌朝 9 時のダイジェストにまとめる」設計から始め、誤報率が安定してから通知範囲を広げるのが現実的なアプローチです。

Google Workspace 脅威検知を自動化する AI 分析フロー

BigQuery クエリで Z スコアが高い行を抽出するだけでは、「これは本当に対応が必要なのか」を人間がすべて判断することになります。AI を組み込む目的は、抽出された異常候補にコンテキストを付加して優先度を自動分類し、情シス担当者が見るべき件数を絞り込むことです。

AI 分析フローは 4 ステップで設計できます。

  1. 集計結果の整形: BigQuery から抽出した Z スコア上位の行を、ユーザー名・サービス名・操作種別・時間帯・件数・Z スコアをまとめた構造化テキストに変換します。JSON 形式で整形すると後工程の自動処理が安定します
  2. コンテキストの付加: 「そのユーザーが最近退職申請を出しているか」「管理者権限を持つアカウントか」「通常の操作時間帯と一致するか」などの追加情報を連結します。LLM は文脈が多いほど正確な判断を返す傾向があるため、組織固有の情報（標準業務時間・管理者ロールの定義など）をシステムプロンプトに埋め込む設計が有効です
  3. LLM（大規模言語モデル）への問い合わせ: 整形したサマリーを LLM に渡し、「異常度の分類（高/中/低）」と「推奨する次のアクション（即時調査 / 監視継続 / 無視）」を出力させます。出力形式は JSON に固定することでルーティングの自動化が安定します
  4. 重複排除フィルタ: 同一ユーザー・同一イベントが連続して通知されないよう、前回通知からの経過時間でデデュプリケーション（重複排除）を行ってから Slack や Gmail へ通知します

ステップ 3 で LLM を使う場合、BigQuery の生データをそのまま渡すのではなく「1 件の異常候補につき 1 プロンプト」にする設計がトークンコストを抑えます。100 名規模であれば、1 日に Z スコア > 3 を超えるイベントは数件〜十数件に収まるケースが多く、API コストは限定的です。

LLM モデルの選択は、コストと精度のバランスで決めます。一次スクリーニングにはコストが低いモデルを使い、high 判定になったケースだけより高精度のモデルで再分析する 2 段階構成が現実的です。同一イベントに対してスコアが毎回変動しないよう、temperature パラメータは 0 か低い値に設定します。

システムプロンプトの内容は定期的に見直します。「false positive だと判断した事象のパターン」をフィードバックとして蓄積し、3〜6 か月ごとにプロンプトを更新することで検知精度が維持されます。更新したプロンプトはバージョン管理し、変更前後のスコアリング傾向を比較できる状態にしておきます。

設計時の注意点

利用可能なエディションの事前確認

BigQuery Export は Enterprise Standard/Plus・Education Standard/Plus・Frontline Standard/Plus・Enterprise Essentials Plus のみ対応しており、Business Starter・Business Standard では利用できません（Google Workspace 管理者ヘルプ「レポートログと BigQuery について」参照）。設計を始める前に、管理コンソールのアカウント設定でエディションを確認してください。エディションが対応していない場合は、BigQuery Export の有効化自体ができないため、まずエディション要件の充足が前提条件になります。

ベースライン期間の選定

過去 30 日をベースライン期間とするとき、祝日・長期休暇・一斉研修などのイベントが含まれると、通常期の操作件数が低く見積もられてスパイクの誤報が増えます。カレンダー情報と組み合わせて「業務稼働日のみをベースライン期間とする」フィルタを設計に組み込んでおくことを推奨します。具体的には EXTRACT(DAYOFWEEK FROM event_hour) で土日を除外し、別途管理する祝日テーブルとの JOIN で祝日をフィルタする方法が実用的です。

Export 開始直後の観測期間

BigQuery Export を有効化してすぐに Z スコア判定を走らせると、ベースライン期間のサンプルが少なく Z スコアが不安定になります。Export 開始後は少なくとも 4 週間分のデータが溜まるまでアラートを止め、分析のみ行う「観測期間」を設けることが現実的です。この期間を利用して集計クエリのチューニングやフィールド名の確認を行うと、本番稼働時の品質が上がります。

BigQuery Export スキーマの管理

BigQuery Export のスキーマは GWS のアップデートにともなって変更されることがあります。フィールド名を直書きしたクエリは、スキーマ変更で突然動かなくなるリスクがあります。定期的に INFORMATION_SCHEMA.COLUMNS でスキーマを確認する仕組みを組み込むか、フィールド名を定数として集約管理する設計を検討します。

プライバシーと監視のポリシー整備

業務ログの分析はユーザー個人の行動を詳細に追跡する性質を持ちます。情シス内で「どのログを誰が参照できるか」のアクセス権限ポリシーと、「分析結果をどう保管・廃棄するか」のデータ保持ポリシーを事前に整えておくことが重要です。人事部門との連携を含む場合は、社内の法務・コンプライアンス確認が別途必要になります。BigQuery のデータセットに対して最小権限のアクセス制御を設定し、ログを参照できるユーザーを情シス担当者に限定するのが基本的な対処です。

まとめ

GWS の BigQuery Export は、単なるログ保管基盤ではなく「統計的ベースラインとの乖離を自動発見するための分析基盤」として機能します。

設計のポイントを整理します。

  • 対象ログは Login・Admin から始め、Drive・Meet を段階的に追加する
  • ベースラインは「ユーザー別 × 時間帯別」の 2 軸で計算する
  • Z スコア > 3 を出発点に、誤報率を確認しながら閾値または複合条件を調整する
  • AI はスコアリングと優先度分類に使い、担当者が見るべき件数を絞る補助として位置づける
  • プライバシーポリシーと BigQuery アクセス権限は設計段階で整備する

まず取り組むべきステップは 3 つです。最初に BigQuery Export の有効化と COUNT クエリによる件数把握。次に 4 週間の観測期間でデータ品質を確認。その後、Z スコア計算を組み込んで最初のアラートを試験的に発火させます。「既知ルールで検知できなかった未知の異常」を日々自動で浮かび上がらせる仕組みを持つことが、事後対応から予防型監視への移行につながります。

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

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

CONTACT

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

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

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