コラム / データ基盤・解析 /
GA4の生ログをBigQueryで長期保持する設計と費用 ─ 14ヶ月の壁を越える実務構成
標準保持14ヶ月で前年同月比が壊れる前に、月3,000円から組める恒久ログ基盤の現実
📖 約12分 / 公開日: 2026/05/26
GA4 を導入して2年が経った会社から、ここ数ヶ月で同じ相談が立て続けに入っています。「去年の同じ月のデータが消えていた」「2024年4月のチャネル別CV比較が出せなくなった」。GA4 の標準データ保持期間は探索レポート用で最長14ヶ月、これを超えると探索ツールでは事実上参照できなくなる仕様です。Universal Analytics 時代の感覚で「設定さえしておけば永遠に残る」と思い込んでいると、ある日突然、過去データが探索画面から消えます。
この仕様変更は2020年の GA4 リリース時点で公式に告知されていましたが、UA からの移行が2023年7月の強制停止で慌ただしかったこともあり、長期保持の設計まで手が回らないまま運用に入ってしまった会社が大半です。直近1年で受けた相談6件のうち、5件は前年同月比が出せなくなって初めて気づいた、というパターンでした。
結論を先に書きます。GA4 の生イベントログを長期保持する手段は、現状 BigQuery エクスポート一択です。GA360（年額1,800万円〜）の有料機能だったエクスポートが GA4 では無償版でも利用できるようになり、日次エクスポートで月100万イベントまで無料、それを超えても安価で済むため、中小規模なら BigQuery 側の費用は月3,000円から5,000円に収まります。Looker Studio や Metabase との接続も容易で、SQL を書ける人材が一人いれば内製運用も現実的です。
ただし、これは適切に設計した場合の話です。雑にエクスポート設定だけ有効化して放置すると、3ヶ月後に BigQuery の請求書が月15万円を超えていた、という事故が発生します。直近で1件、ECサイト運営会社で実際に起きました。原因の8割はパーティション設計の不備とクエリの全件スキャン、残り2割はストレージクラスの選択ミスです。
規模別に推奨構成を示します。月間PV 50万以下の小規模サイトであれば、日次エクスポートだけ有効化し、Looker Studio から直接 BigQuery を参照する最小構成で十分です。BigQuery の物理ストレージ料金は東京リージョンで月額0.020ドル/GB、1年分のイベントログでも数GB程度に収まり、ストレージ費用は月50円程度。クエリ料金はオンデマンドだと1TB処理あたり7.5ドルですが、Looker Studio からの定期参照を1日10回程度に抑えればこちらも月100円台で済みます。トータル月3,000円というのは、ここに最低限の監視やバックアップを足した実勢額です。
月間PV 500万規模の中堅メディアでは、ストリーミングエクスポート（リアルタイム送信）が選択肢に入ります。日次バッチだと前日比較しかできませんが、ストリーミングなら当日のCV経路をその日のうちに確認できる。ただし1GBあたり0.05ドルの追加料金が発生するため、必要性をよく考えてから有効化すべきです。たいていの会社は日次で足ります。中堅規模でよく起きるのが、テーブル参照時のパーティション指定漏れ。events_YYYYMMDD という日付シャーディング構造を意識せず WHERE 句で event_date を指定しないままクエリを投げると、過去365日分を全件スキャンして1回で数千円のクエリ料金が走る。BIツール側に「自動更新を毎時に設定」みたいなものが残っていると、これが時限爆弾になります。
月間PV 5,000万を超える大規模サイトでは、BigQuery のフラットレート（予約枠）を検討する価値が出てきます。100スロット月額2,000ドル（東京リージョン、コミットなし）から始められ、オンデマンド換算で月20万円相当の処理を超えるなら逆転します。ここまで来ると専任の Data Engineer が必要になり、dbt や Dataform でモデル管理、Cloud Composer でスケジューリング、といった本格的なデータ基盤の話になります。月額30万円というのは、GCPの請求額に加えて運用工数の人件費を含めた現実的な総コストです。
設計上の落とし穴を3つ挙げておきます。まず、エクスポート設定はプロパティ作成時から有効にしないと、過去データはエクスポートされません。後から有効化しても、有効化した日以降のデータしか BigQuery に流れない。これは何度言っても引っかかる罠で、2024年の事例だと「3年運用していたGA4をBigQueryに繋いだら過去データが空だった」というケースが3件ありました。事実上、過去データの救済は不可能で、UA時代の集計データを別途インポートして補うしかありません。
2つ目はクラスタリングの欠如です。BigQuery のテーブルはパーティション（日付）だけでなくクラスタリング（任意のカラム）も設計できます。GA4 の生テーブルにクラスタリングを追加すると、user_pseudo_id や event_name でのフィルタクエリが3〜10倍速くなる。料金も同比率で下がります。素のままだとパーティション指定だけが頼りになり、ユーザー軸の分析クエリで毎回フルスキャンが走るため、長期運用ではここがコスト差を生みます。
3つ目は IAM の権限設計。Looker Studio から BigQuery を参照する場合、「BigQuery データ閲覧者」と「BigQuery ジョブユーザー」の両方が必要で、片方だけだとクエリが走らない、あるいは結果が空になる。マーケ部門から「数字が0になっている」という連絡が来て調べると、半数は権限設定の問題です。最小権限の原則を守りつつ、必要な範囲は明示的に付与する設計が必要になります。
対案にも触れておきます。BigQuery を避けたい場合、Snowflake や Databricks へのエクスポートを Fivetran 経由で実現する手もありますが、Fivetran のコネクタ料金が月3万円から、加えて Snowflake のクレジット料金で結局月10万円を超えます。Microsoft Fabric も2024年から GA4 連携が話題に上がりますが、現時点では Power BI ユーザー以外には積極的に勧められる構成ではありません。BigQuery が圧倒的に安く、ドキュメントも揃っている。これは推奨というより、現実的な選択肢が他にないという話です。
運用開始から1年以内にやっておくべきことは2つ。BigQuery 内に「集計済みテーブル」を作って Looker Studio はそちらを参照する、というレイヤー分離。これでクエリ料金が劇的に下がります。もう1つは、コスト上限アラートを GCP の Budget で設定すること。閾値は月額5,000円・15,000円・50,000円の3段で組んでおけば、誤ったクエリが走った段階で気づけます。
14ヶ月の壁は、気づいた時にはもう過去データが消えています。GA4 を運用している会社は、まず BigQuery エクスポートが有効になっているかを今日確認すべきです。設定画面で1分で分かります。エクスポートが無効のままなら、それが最優先課題です。
この仕様変更は2020年の GA4 リリース時点で公式に告知されていましたが、UA からの移行が2023年7月の強制停止で慌ただしかったこともあり、長期保持の設計まで手が回らないまま運用に入ってしまった会社が大半です。直近1年で受けた相談6件のうち、5件は前年同月比が出せなくなって初めて気づいた、というパターンでした。
結論を先に書きます。GA4 の生イベントログを長期保持する手段は、現状 BigQuery エクスポート一択です。GA360（年額1,800万円〜）の有料機能だったエクスポートが GA4 では無償版でも利用できるようになり、日次エクスポートで月100万イベントまで無料、それを超えても安価で済むため、中小規模なら BigQuery 側の費用は月3,000円から5,000円に収まります。Looker Studio や Metabase との接続も容易で、SQL を書ける人材が一人いれば内製運用も現実的です。
ただし、これは適切に設計した場合の話です。雑にエクスポート設定だけ有効化して放置すると、3ヶ月後に BigQuery の請求書が月15万円を超えていた、という事故が発生します。直近で1件、ECサイト運営会社で実際に起きました。原因の8割はパーティション設計の不備とクエリの全件スキャン、残り2割はストレージクラスの選択ミスです。
規模別に推奨構成を示します。月間PV 50万以下の小規模サイトであれば、日次エクスポートだけ有効化し、Looker Studio から直接 BigQuery を参照する最小構成で十分です。BigQuery の物理ストレージ料金は東京リージョンで月額0.020ドル/GB、1年分のイベントログでも数GB程度に収まり、ストレージ費用は月50円程度。クエリ料金はオンデマンドだと1TB処理あたり7.5ドルですが、Looker Studio からの定期参照を1日10回程度に抑えればこちらも月100円台で済みます。トータル月3,000円というのは、ここに最低限の監視やバックアップを足した実勢額です。
月間PV 500万規模の中堅メディアでは、ストリーミングエクスポート（リアルタイム送信）が選択肢に入ります。日次バッチだと前日比較しかできませんが、ストリーミングなら当日のCV経路をその日のうちに確認できる。ただし1GBあたり0.05ドルの追加料金が発生するため、必要性をよく考えてから有効化すべきです。たいていの会社は日次で足ります。中堅規模でよく起きるのが、テーブル参照時のパーティション指定漏れ。events_YYYYMMDD という日付シャーディング構造を意識せず WHERE 句で event_date を指定しないままクエリを投げると、過去365日分を全件スキャンして1回で数千円のクエリ料金が走る。BIツール側に「自動更新を毎時に設定」みたいなものが残っていると、これが時限爆弾になります。
月間PV 5,000万を超える大規模サイトでは、BigQuery のフラットレート（予約枠）を検討する価値が出てきます。100スロット月額2,000ドル（東京リージョン、コミットなし）から始められ、オンデマンド換算で月20万円相当の処理を超えるなら逆転します。ここまで来ると専任の Data Engineer が必要になり、dbt や Dataform でモデル管理、Cloud Composer でスケジューリング、といった本格的なデータ基盤の話になります。月額30万円というのは、GCPの請求額に加えて運用工数の人件費を含めた現実的な総コストです。
設計上の落とし穴を3つ挙げておきます。まず、エクスポート設定はプロパティ作成時から有効にしないと、過去データはエクスポートされません。後から有効化しても、有効化した日以降のデータしか BigQuery に流れない。これは何度言っても引っかかる罠で、2024年の事例だと「3年運用していたGA4をBigQueryに繋いだら過去データが空だった」というケースが3件ありました。事実上、過去データの救済は不可能で、UA時代の集計データを別途インポートして補うしかありません。
2つ目はクラスタリングの欠如です。BigQuery のテーブルはパーティション（日付）だけでなくクラスタリング（任意のカラム）も設計できます。GA4 の生テーブルにクラスタリングを追加すると、user_pseudo_id や event_name でのフィルタクエリが3〜10倍速くなる。料金も同比率で下がります。素のままだとパーティション指定だけが頼りになり、ユーザー軸の分析クエリで毎回フルスキャンが走るため、長期運用ではここがコスト差を生みます。
3つ目は IAM の権限設計。Looker Studio から BigQuery を参照する場合、「BigQuery データ閲覧者」と「BigQuery ジョブユーザー」の両方が必要で、片方だけだとクエリが走らない、あるいは結果が空になる。マーケ部門から「数字が0になっている」という連絡が来て調べると、半数は権限設定の問題です。最小権限の原則を守りつつ、必要な範囲は明示的に付与する設計が必要になります。
対案にも触れておきます。BigQuery を避けたい場合、Snowflake や Databricks へのエクスポートを Fivetran 経由で実現する手もありますが、Fivetran のコネクタ料金が月3万円から、加えて Snowflake のクレジット料金で結局月10万円を超えます。Microsoft Fabric も2024年から GA4 連携が話題に上がりますが、現時点では Power BI ユーザー以外には積極的に勧められる構成ではありません。BigQuery が圧倒的に安く、ドキュメントも揃っている。これは推奨というより、現実的な選択肢が他にないという話です。
運用開始から1年以内にやっておくべきことは2つ。BigQuery 内に「集計済みテーブル」を作って Looker Studio はそちらを参照する、というレイヤー分離。これでクエリ料金が劇的に下がります。もう1つは、コスト上限アラートを GCP の Budget で設定すること。閾値は月額5,000円・15,000円・50,000円の3段で組んでおけば、誤ったクエリが走った段階で気づけます。
14ヶ月の壁は、気づいた時にはもう過去データが消えています。GA4 を運用している会社は、まず BigQuery エクスポートが有効になっているかを今日確認すべきです。設定画面で1分で分かります。エクスポートが無効のままなら、それが最優先課題です。