お問い合わせ
AI NOTE — 176

Drive異常検知をBigQuery×AIで設計する

PUBLISHED2026.06.20
READ10 分
CATEGORYAI

2026年3月、Google Workspace のランサムウェア検出・ファイル復元機能が一般提供（GA）になりました。同機能は学習済みの既知脅威パターンに特化しており、未知の異常操作を検出する Google Drive 異常検知フレームワークには、BigQuery Export と AI の組み合わせが別途必要です。

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

  • DriveのランサムウェアGA機能を有効化しているが、既知脅威以外の異常操作への対応に限界を感じている情シス担当者
  • 深夜の大量ダウンロードや退職予定者の権限変更バーストといった「統計的な外れ値」を検出したい方
  • BigQuery ExportでDrive監査ログを蓄積しているが、異常検知への活用設計が定まっていない方
  • 予測型の検知フレームワークを社内提案したいが、実装コストと効果のバランスで判断に迷っている方

DriveランサムウェアGA機能の限界：予測型検知が必要な理由

2026年3月にGA（一般提供）となったDriveのランサムウェア検出機能は、Googleが蓄積してきたランサムウェアの挙動パターンを学習した機械学習モデルで検出を行います。Google Workspace Updatesブログによれば、最新AIモデルの採用で感染検出精度が大幅に向上し、Drive for Desktopのファイル同期が自動停止し、感染を検出したことがユーザーのデバイスへ通知されます。管理者にはAdmin ConsoleのセキュリティセンターおよびAlert Center経由で別途通知が届きます。

この機能が対処できないのは、「Googleが学習済みのランサムウェアパターンに合致しない操作」です。具体的には次のようなグレーゾーンの操作が当てはまります。

  • 退職届を提出した翌日に発生する、数百ファイルの一括ダウンロード
  • 深夜0時〜4時に特定ユーザーが共有ドライブ全域のファイルを外部共有へ変更する操作
  • 普段ほとんどDriveにアクセスしないアカウントが突然大量のファイルを別フォルダへ移動させる操作

いずれも「悪意があるかどうかは判断できないが、統計的に異常」なパターンです。予測型検知を設計するとは、このカテゴリの操作を「事前に兆候として拾う」仕組みを持つことを指します。

Drive監査ログのBigQuery Export：何が取得できるか

Google WorkspaceはBigQuery Export（管理コンソールのレポート設定から有効化）の仕組みを持っており、Driveの活動ログをリアルタイムに近い形でBigQueryに蓄積できます。

Drive監査ログで追跡されるイベントタイプには、ファイルの表示・名前変更・作成・編集・印刷・削除・アップロード・ダウンロード、そして公開設定や共有範囲の変更が含まれます。各イベントに付随する主なフィールドは次の通りです。

  • アクター（操作者）: 操作を行ったユーザーのアカウント情報
  • イベント名: ダウンロード・共有変更など操作の種別
  • ドキュメントタイプ: ファイルの形式（Docs / Sheets / Slides / PDF など）
  • タイムスタンプ: 操作が発生した日時
  • IPアドレス: 操作元のネットワーク情報
  • 公開設定（可視性）: その時点のファイル共有範囲
  • オーナー: ファイルの所有者アカウント
  • 受信者: 共有先として追加されたアカウント

また、2024年3月以降はDriveラベルのメタデータも監査ログに含まれます（Enterprise Essentials Plus・Enterprise Standard・Enterprise Plus・Education S/P 対象。Business Standard/Plus は非対応）。対象プランでは、機密ラベルが付いたファイルへのアクセスだけを絞り込む分析が可能になりました。

異常検知の設計上の出発点は、これらのログを「どう集計するか」の判断です。ログの量は組織規模によって変わりますが、100名規模でも1日あたり数千〜数万件規模（操作頻度により変動）のイベントが発生します。生のログをそのまま監視するのではなく、集計値を分析対象にする設計が前提です。

BigQueryでの集計は、イベント種別・ユーザー・時間帯の3軸で行うのが基本です。下記は1時間単位でユーザーごとの操作件数を集計する設計参考例です（実際のフィールド名はBigQuery Exportのスキーマドキュメントで確認が必要です）。

-- 設計参考例：1時間単位でユーザーごとの操作件数を集計する
-- 実際のフィールド名はBigQuery Exportスキーマドキュメントで確認すること
SELECT
  email                                    AS actor_email,
  TIMESTAMP_TRUNC(
    TIMESTAMP_MICROS(time_usec), HOUR
  )                                        AS event_hour,
  event_name,
  COUNT(*)                                 AS event_count
FROM workspace_audit_logs.drive_activities
WHERE DATE(TIMESTAMP_MICROS(time_usec)) >= DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY)
  AND event_name IN ('download', 'change_document_visibility', 'move')
GROUP BY 1, 2, 3
HAVING event_count >= 10
ORDER BY event_count DESC

このクエリの結果を30日移動平均と比較することで、「今日のこのユーザーのダウンロード件数は平常の何倍か」という偏差倍率を算出できます。後続のスコアリングには生の件数ではなく偏差倍率を使う設計を推奨します。個人差をならした指標にすることで、ヘビーユーザーと軽量ユーザーに同じ閾値を適用する誤りを防げます。

正常ベースラインの定義：3軸で平常を設計する

異常を検出するには、「何が正常か」を先に定義する必要があります。Drive監査ログからベースラインを構築するとき、3つの軸を組み合わせる設計が実用的です。

ユーザー軸

過去30〜60日間のユーザー自身の操作パターンを基準にします。毎朝10件ダウンロードするユーザーと、月に1回しかダウンロードしないユーザーでは「異常な件数」の水準が大きく異なります。個人ごとのベースラインを持たない設計では、アクティブなユーザーほど誤報が増えます。

時間帯軸

組織の通常稼働時間（平日9時〜20時など）を「正常稼働帯」として定義し、深夜・早朝・土日祝日の操作に対して異常スコアを加点します。国内拠点のみの企業であれば、深夜帯の大量ダウンロードは文脈的にほぼ例外扱いにできます。

組織状態軸

HR情報（退職予定・休職中・プロジェクト離任フラグ）と突き合わせます。退職2週間前のユーザーによるダウンロードバーストは、離職トリガー検出として高スコアを付ける設計にします。純粋なログ分析だけでは捕捉できず、HRシステムとのデータ連携が前提となります。

HRシステムとのデータ連携が実現していない場合でも、組織状態軸は運用できます。退職・異動のタイミングをGoogleスプレッドシートで管理し、Apps Scriptで定期的にBigQueryへインポートする方式が現実的な代替手段です。HR担当者が週次で退職予定者リストを更新するだけでも「退職フラグON」（HRデータ上の退職予定登録状態）の判定精度は変わります。手動更新のタイムラグを考慮して「退職予定日の2週間前から監視強度を上げる」設計にすると、運用の抜け漏れを減らせます。

3軸を組み合わせた「複合スコア」で評価することで、単一指標での過検知を抑制できます。「深夜ダウンロード」だけでアラートを上げると、海外出張中のユーザーで大量の誤報が発生します。「深夜 × 高件数 × 退職フラグON」のような複合条件に絞ることで精度が上がります。

AIによる異常スコアリングフロー：設計の考え方

BigQueryでの集計だけで異常を判定しようとすると、閾値の設定が属人的になりがちです。「100件が正常か異常か」の判断が担当者によって分かれる場合、ルールベースだけでは限界があります。複合パターンの解釈をAIに委ねる設計が、この問題への現実的なアプローチです。

設計フローの骨格は4ステップで整理できます。

  1. BigQueryで時系列集計: 1時間単位・1日単位でユーザーごとのダウンロード件数・外部共有変更件数・操作ファイルサイズ合計を集計する
  2. ベースラインとの差分計算: 過去N日間の移動平均・標準偏差を基準に偏差倍率を算出する
  3. AIへの文脈入力: 集計結果に加え、組織状態（退職フラグ・操作時間帯）をまとめたサマリーをAIに渡し、「異常度の分類」と「推奨対応」を出力させる
  4. スコアと通知閾値の設定: AI出力を数値スコアに変換し、閾値を超えたら情シス担当者へ通知する

AIに渡す文脈サマリーは、次のような構造化テキストが実用的です。

【異常スコアリング依頼】
評価対象: user@example.com
評価期間: 2026-06-19 23:00〜2026-06-20 03:00
---
- ダウンロード件数: 312件（本人30日移動平均: 8件／偏差倍率: 39倍）
- 外部共有変更件数: 21件（本人30日合計実績: 0件）
- 操作時間帯: 深夜帯（組織稼働時間 09:00〜20:00 の範囲外）
- HR状態: 退職届提出済み、退職予定日 2026-07-15
- アクセス元: 組織管理外ネットワーク（VPN接続なし）
---
上記の組み合わせを評価し、異常度（高/中/低）と推奨する初期対応を示してください。

ポイントは「生件数」ではなく「偏差倍率」と「文脈情報」をセットで渡す点です。AIが文脈を読めるようにすることで、「312件という数値」ではなく「普段の39倍が深夜に起きた」という意味レベルで判断できます。また、異常度の根拠を自然言語で出力させる設計にしておくと、情シス担当者が確認フローで判断を下す際の説明資料として使えます。

AIに期待する役割は「ルールベースでは拾いにくい複合パターンの文脈解釈」です。たとえば「退職フラグON + 深夜 + 外部共有先が個人ドメイン」の組み合わせを、個別の閾値ではなく文脈として高スコアと評価させます。

ただし、AI判定を即座に自動遮断へ直結させるのは設計上のリスクがあります。誤検知で現役の従業員をロックアウトするコストは高く、最初のフェーズでは「AI判定 → 情シス担当者への通知 → 手動確認 → 遮断」という半自動フローを推奨します。自動化の範囲は、誤検知パターンを十分に蓄積した後に段階的に広げます。

Alert CenterとのAPI連動：役割と設計上の注意点

Google WorkspaceにはAlert Center（アラートセンター）という機能があり、Alert Center API（v1beta1）を使うと、Googleが自動検出したセキュリティアラートの読み取りと、そのアラートへのフィードバック追加をプログラムで行えます。

ただし、情シスが独自に検出した異常をAlert Centerに書き込む機能は提供されていません。Alert Center API公式リファレンスを確認すると、write系のエンドポイントは存在せず、外部システムからカスタムアラートを投入する仕組みは持っていない点に注意が必要です。

独自の異常スコアリングフローと組み合わせるときの、現実的な役割分担は次の通りです。

  • Alert Center: GoogleのGA機能が検出したランサムウェアアラートを読み取り、独自異常検知の補完情報として照合する
  • 通知チャネル: 独自スコアリング結果はSlack・メール・ITSM（チケット管理システム）へ直接送る
  • 遮断フロー: ユーザーアクセスを制限する場合は、Admin SDKなど別の管理APIを介した設計が必要

通知先の選定は、組織の既存ツールに合わせて決めます。Slack Webhookは導入コストが最小で、高スコアのアラートをリアルタイムに担当者へ届けるのに向いています。ITSMを導入済みの組織であれば、スコア閾値を超えたタイミングで自動的にインシデントチケットを起票する設計が後処理の追跡を容易にします。メール通知は確実に届く反面、開封遅延が生じやすく、緊急度の高いアラートには向きません。初期フェーズでは「高スコア → Slack即時通知」「中スコア → 日次メールダイジェスト」の2段階を組み合わせると、認知負荷を抑えながら重要アラートを見逃しにくい運用になります。

「Alert Centerですべて完結させる」という設計は現時点では成立しません。Alert Centerはあくまで「Googleが検知した結果を読む窓口」として位置づけ、独自検知フローは別のスタックで構築します。

実装コストを判断する3段階のフレームワーク

どのレイヤーまで実装するかで、難度と運用コストが大きく変わります。以下の3段階を判断の参照基準として使います。

段階1：BigQuery Export のみ（難度：低）

Driveログを蓄積し、SQLで週次・月次のレポートを作るだけでも「明らかに異常な件数」の可視化は可能です。Looker Studio（GoogleのBIツール）をBigQueryに接続すれば視覚化も容易になります。コストはBigQueryの利用料（ログ量に応じた課金）と初期設定工数が主で、AIは不要です。情シス1〜2名の体制であれば、BigQuery Exportの有効化と基本クエリの整備を合わせて2〜3週間が目安の工数です。

段階2：BigQuery + AI分析（難度：中）

BigQueryの集計結果を生成AIに渡し、異常判定レポートを自動生成します。週次バッチ処理で運用すれば、リアルタイム性は高くないものの、情シス担当者の手動確認工数を大幅に削減できます。Cloud Functions（GCPのサーバーレス実行環境）でスケジュール実行するアーキテクチャが代表的な設計です。設計・実装・テストを含めて1〜2ヶ月を見積もるのが現実的で、段階1で「どのくらいの頻度で異常件数が発生するか」の感覚をつかんでから設計を固めると、閾値調整の手戻りを減らせます。

段階3：フルオートメーション（難度：高）

異常スコアが閾値を超えたら通知→人間確認→遮断を自動フローで走らせる設計です。速度面では優れますが、誤検知対応の仕組みと運用フロー整備が先行して必要になります。段階1・2で「どのパターンが誤検知になるか」の知見を蓄積してから段階3へ進む順番が現実的です。誤検知パターンの蓄積期間を含めると、6ヶ月以上を見込むと安全です。

100名規模・情シス1〜2名の体制であれば、まず段階1で可視化から始め、3〜6ヶ月かけてベースラインの感覚をつかんでから段階2へ移行するのが無理のない進め方です。一度にすべてを構築しようとすると、設計の精度より実装コストが先行して頓挫するリスクがあります。

まとめ：「既知脅威の検出」から「兆候の事前把握」へ

DriveのランサムウェアGA機能は既知の脅威に対して強力に機能します。未知の異常操作を検出するには、BigQuery ExportによるDrive監査ログの蓄積と、正常ベースラインの設計という別の基盤が必要です。

設計を始める上での次のアクションを示します。

  • BigQuery Exportを有効化し、Drive監査ログの蓄積から着手する（設計の前提として必要）
  • 自社の「正常な操作パターン」を3軸（ユーザー・時間帯・組織状態）で定義する
  • 段階1（可視化のみ）から始め、誤検知パターンを蓄積してから段階2以降へ進む
  • Alert Center APIは「Googleが検出したアラートの読み取り」に限定し、独自検知フローは別チャネルで設計する

「検出されてから復元する」防御を維持しつつ、その手前で「統計的に異常になりかけているポイントを先に察知する」体制を整えることが、この設計転換のゴールです。一度にすべてを実装しようとせず、段階的に精度を高める進め方が、情シス担当者にとって現実的な選択です。

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

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

CONTACT

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

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

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