GWSの監査ログ3年分をどう残す？BigQuery・GCS・Databricksで比較検討してみた

2026年11月5日 14:53

こんにちは、情報システム部 ITマネジメントグループ ITサービスオペレーションチームの小野です。

企業のセキュリティ対策やコンプライアンス要件において、避けて通れないのが「SaaSの監査ログ保管」です。
とりわけ社内のコラボレーションの中心である Google Workspace (GWS) の監査ログは、何かインシデントや退職時のトラブルがあった際の命綱になります。
しかし、GWSの管理コンソール上でログを参照できる期間は、多くのログ種類で6ヶ月に固定されており、これを超えたログは順次削除されてしまいます。そのため、コンプライアンス等で要求される長期保管には標準機能だけでは対応できません。
そこで今回、社内で「GWSの監査ログを長期 (3年間) 保管したい」「いざという時に検索できるようにしたい」というプロジェクトが立ち上がりました。

そこでまずあがったのがこの2つの問いです。

「毎月どれくらいのデータ量になって、いくら費用がかかるの？」
「社内にあるツール（BigQuery、Google Cloud Storage(GCS)、Databricks、Sentinelなど）の中で、どれを使うのが一番安くて運用しやすい？」

さらに検討を進めると、社内から「Google Driveに置けばタダじゃない？」という声があがったり、「Cloud LoggingとBigQueryで取れるログの種類が全然違う……！」という仕様の罠に気づいたりと、なかなかのドラマがありました。保管期間の点でGoogle Vaultも候補にあがりましたが、個別のライセンスが必要になったり、ユーザー削除に制約が発生する等の事情があり見送っています。

今回は、約3,500アカウント規模の環境を前提に、私たちが検討・試算したログ保管アーキテクチャをシェアします！

1. まずは試算：監査ログは3年で何TBになるのか？

GWSの監査ログ費用を左右するのは「データ量（インジェスト・ストレージ）」と「検索頻度（クエリ）」です。
現在の社内の有効アカウントは2,600件前後ですが、将来的な組織拡大や今後のログ増を見越し、余裕を持たせた「3,500アカウント」として多めに見積もりを行いました。
Google Workspace Enterpriseの管理コンソールから日々のイベント件数を確認しつつ、一般的なオフィスワーク環境をベースに弾き出した規模感がこちらです。

ログ容量の想定目安（3,500アカウント）

1人あたりのログ生成量: 約 1.5 MB / 日
全体の1日あたりの増加量: 約 5.25 GB / 日
月間のログ増加量: 約 175 GB / 月 (余裕を見て)
3年間の総蓄積量: 約 6.3 TB（6,300 GB）

この数字をもとに、王道である「BigQuery」に保存し続けた場合の月額推移を計算してみました。

BigQuery月額費用のシミュレーション推移（概算）

※ 1 USD = 150円、ストリーミング挿入 $0.05/GB、アクティブ保存 $0.02/GB、90日超長期保存 $0.01/GB で試算。（US multi-region単価）

「必要な時にしか検索しない」前提であれば、BigQueryの無料枠（月1TBスキャン無料）に収まるためクエリ代はほぼゼロ。3年経って最大6.3TBまで膨らんでも、月額約1.1万円前後（年間約13万円）で平衡状態になります。
「思っていたより安いな」というのが最初の率直な感想でした。

2. アーキテクチャ比較：BigQuery vs Google Cloud Storage +Databricks vs Sentinel

しかし、今回のプロジェクトは「徹底したコスト最適化」と「社内でのDatabricks利活用推進」という2つの裏テーマがありました。
そこで、社内で利用可能なプラットフォームを並べて比較してみることにしました。

候補サービスの比較まとめ

なぜAWS S3やAzure Blobではなく「Google Cloud Storage(GCS)」なのか？

「AWSのGlacier Deep ArchiveやAzure Blobの方がGB単価がわずかに安いのでは？」とも思いましたが、GWSのログを出力・保管する場合、必ずGoogle Cloud を経由する必要があります。

これを他社クラウドに送ろうとすると、Google Cloud からのデータ搬出費用（エグレス料金: 約$0.08〜0.12/GB）が毎月発生し、ストレージの差額など一瞬で吹き飛んでトータルコストが跳ね上がることが判明しました。同一クラウド内の通信（$0）で完結できるGoogle Cloud内での構成一択です。

3. 「Google Driveに保存できないの？」への回答

検討の途中で、誰もが一度は思いつく悪魔の囁きがありました。
「え、Google Driveの共有ドライブにテキストで溜めていけば、ストレージ代タダじゃない？」
結論から言うと、技術的にも運用上も絶対にやってはいけません。
もし同様の意見が出た場合は、以下の4つの理由から避けるべきです。

そもそも標準機能が存在しない:
GWSの管理機能に「ログをDriveへ自動エクスポートする」機能はありません。やるなら自作スクリプトが必須です。
いざという時に検索できない:
何万件もの巨大JSON/テキストファイルがDriveに転がっていても、SQLで検索できません。インシデント発生時に手動でギガ単位のファイルを開こうとしてPCがフリーズします。
API制限によるログ欠損リスク:
3,500人規模のログをAPI経由でDriveに書き込み続けると、レートリミット（403/429エラー）に引っかかり、重要なログが抜け落ちる事故が起きます。
逆に高くつく（人件費）:
月数千円のクラウド代をケチるために、ログ転送プログラムを開発・保守するエンジニアの人件費をかけるのは本末転倒です。

4.Cloud Logging経由 vs BigQueryエクスポート

「よし、GCSに保管してDatabricksで読もう！」と決めたところで、ひとつ注意が必要なポイントに気づきました。
「GWSのログをどうやって外部に出力（エクスポート）するか？」という問題です。GWSから直接GCSに吐き出すボタンはないため、最初は手軽そうな「Google Cloud Logging を経由させる」ルートを検討しました。GWS管理コンソールでデータ共有をONにし、Google Cloud側のCloud Loggingで集約シンク（Aggregated Sink）を作れば、GCSバケットへログを自動転送できるため一見とてもラクに見えます。ただ、検証を進める中で「取得できるログの種類」に違いがあることが分かりました。

取得できるログの範囲の違い

Cloud Logging経由で取れるログ（セキュリティ・認証系中心）
- 管理者監査ログ（Admin Audit）
- ログイン監査ログ（Login Audit）
- エンタープライズグループ監査（Groups Audit）
- OAuthトークン監査、SAML監査
  ※「誰がログインしたか」「どのような設定変更が行われたか」といった管理・認証系のログが中心です。

BigQueryエクスポートで取れるログ（全アクティビティ網羅）:
- 上記のセキュリティログに加えて、
- Google ドライブの操作ログ（ファイルの閲覧、編集、ダウンロード、外部共有変更）
- Google カレンダー、Google Meet、Gmail/DLPルール違反ログなど

判断ポイント:
「ドライブからのファイル持ち出しや閲覧ログまで追跡したいか？」が判断の分かれ目になります。社内の不正持ち出し調査やファイル操作追跡まで想定する場合、ドライブ監査ログは欠かせません。その場合はCloud Logging経由だけだとカバーしきれないため、BigQueryエクスポートを選択するのが確実です。
※ BigQueryエクスポートは Enterprise Standard / Plus などの上位エディションで利用できる機能です（Business系エディションでは利用できません）。弊社ではEnterprise版を契約しています。

5. まとめ：私たちが選んだベストプラクティス

様々な角度から比較検討した結果、私たちは「外部ストレージへ逃がさず、BigQuery 1本でシンプルに完結させる」という設計方針に着地しました。

最終的に選んだ構成

インジェスト・保管・検索基盤：GWS ➔ BigQueryエクスポート
- ドライブの閲覧・ダウンロードログまで網羅するため、BigQueryへ直接エクスポート

なぜ「GCS＋他社分析基盤」などの連携をやめてBigQuery 1本にしたのか？
試算の段階では「GCSなどに安く二次保存し、必要な時だけ別の分析基盤で検索する」というパイプライン構成にかなり心を惹かれていました。しかし、以下の理由から見送ることになりました。

データパイプラインの構築・保守工数
BigQueryから定期的にログを別ストレージへ搬出・フォーマット変換するような自動化処理を、わざわざ自前で組んで運用し続けるのは手間がかかる。
ストレージ圧縮と長期保存の恩恵
BigQueryの標準的なデータ圧縮機能に加え、90日経過した過去データは自動的に「長期保存料金」が適用されるため、別ストレージへわざわざ移さなくても十分に低コストで運用できる。
運用のシンプルさ
「いざログを調べたい」となった際、複雑な構成を挟まず、BigQuery上で直接SQLを叩いてすぐに調査できる手軽さが情シスチームにとって一番のメリット。

実際のデータ感と運用の手応え
実際に設定を行って1ヶ月運用してみたところ、ログの出力ペースは当初の想定よりやや多めに出ていました。
一瞬「予算的にどうかな……？」と思いましたが、BigQuery側で効率よくデータが圧縮されていることもあり、90日以降の長期保存割引なども加味すると、3年分溜め込んでも予算感には全く問題なく収まる見込みが立ちました。
余計な連携スクリプトやパイプラインを作らずに済んだことで、運用コスト・構築工数ともに最少に抑えることができ、無事に社内でも「このシンプル構成でいこう」と決着しました。

GWSのログ保管設計で悩んでいる情シスのみなさんの参考になれば幸いです！

※本記事の掲載内容は執筆時点の仕様に基づく個人の検証・見解であり、所属組織の公式見解を代表するものではありません。クラウドの料金体系等は変更される可能性があるため、導入時は最新の公式ドキュメントをご確認ください。