デリッシュキッチンのBigQuery導入事例

ツール導入前の課題

Google Analytics for Firebaseで収集したアプリのユーザー行動データを、ファーストパーティデータと組み合わせてより柔軟かつ詳細に分析したいというニーズがありました。Firebase単体の分析機能では対応しきれない、カスタムクエリによる深掘り分析やデータの長期保存が求められていました。

どのような状態を目指していたか

BigQuery導入にあたり、以下のような状態を実現することをゴールとして設定していました。

• ファーストパーティデータとの統合分析が自由にできる状態: Firebase単体の分析機能に閉じず、自社の会員データや行動データとユーザー行動ログを掛け合わせ、SQLベースで自由に深掘り分析ができる環境
• データ連携に運用工数がかからない状態: ログデータの収集・蓄積において追加のETLパイプラインの構築・保守を必要とせず、データエンジニアが分析基盤の改善やコスト最適化に注力できる体制
• メインデータ基盤との役割分担が明確な状態: Databricks（AWS）とBigQuery（Google Cloud）の用途・データの所在が整理され、チーム内で迷いなくデータにアクセスできるルールが確立されている状態
• コストが予測・コントロール可能な状態: データ量の増加に対してストレージ・クエリコストの可視化と最適化の仕組みがあり、スケーラブルに運用できる状態

BigQueryの導入に関しては、Google Analytics for Firebaseとのネイティブ連携が決め手でした。FirebaseのデータエクスポートはBigQueryと直接統合されており、追加のETLパイプラインを構築する必要がありません。Firebase連携というユースケースにおいてはBigQueryが唯一のネイティブ連携先であり、他のDWHサービスと比較するまでもなく、最適なサービスとしてBigQueryを選定しました。

• Firebaseとのシームレスな連携: 設定のみでデータエクスポートが完了し、運用負荷が極めて低い
• サーバーレスアーキテクチャ: インフラ管理が不要で、データエンジニアが分析基盤の構築・最適化に集中できる
• SQLベースの分析: 標準SQLで柔軟なクエリが記述でき、チーム内での知見共有がしやすい
• Google Cloudエコシステムとの親和性: Looker Studioなどの可視化ツールとの連携が容易

改善したかった課題はどれくらい解決されたか

BigQuery導入により、Firebase経由のユーザー行動データをSQLで自由に分析できる環境が整いました。

どのような成果が得られたか

特に大きな成果として、ストレージコストの最適化が挙げられます。データ量の増加に伴いストレージコストが課題となっていましたが、INFORMATION_SCHEMA.TABLE_STORAGE_BY_PROJECTを活用した詳細な分析を行い、論理バイトストレージから物理バイトストレージ課金への切り替えを実施しました。BigQueryの圧縮率が高いため、物理バイト課金の単価増を圧縮率が上回り、結果として大幅なコスト削減を達成しています。

このように、導入後も継続的にコスト最適化に取り組むことで、データ量が増加してもコストを適切にコントロールできる体制を構築しています。

メインのデータ基盤（Databricks/AWS）とBigQuery（Google Cloud）を併用する構成のため、データの所在や用途のすみ分けを明確にする必要がありました。

また、BigQueryのストレージコストについては、データ量が増えるにつれて課題として顕在化しました。課金モデル（論理バイト vs 物理バイト）の違いを正しく理解し、自社データの圧縮率を実測したうえで最適な選択をするためには、INFORMATION_SCHEMAを活用した詳細な調査が必要でした。