GA4のBigQueryエクスポート遅延で日次集計が2ヶ月止まった話

GA4のデータをBigQueryにためて、自前の集計テーブルを毎日作っている人は多いと思います。ダッシュボードは普通に開ける。エラー通知も鳴らない。なのにある日ふと「先月の数字が出ていない」と気づく。

これはある案件で実際に起きたことです。原因はバグでも権限切れでもなく、GA4のBigQueryエクスポート遅延という仕様と、集計クエリの書き方の相性でした。毎朝のジョブは成功している。成功しているのに、テーブルには1行も増えていない。いちばん気づきにくい壊れ方です。

同じ作り方をしている人は、気づかないまま止まっている可能性があります。原因の見つけ方と、二度と起きない直し方を実話ベースでまとめます。

結論：止まったのは「GA4の送信」ではなく「自前の集計」

先に、いちばん誤解しやすい点から押さえます。

BigQueryのデータは2段階でできています。1段目は、GA4がイベントを自動で送り込む生データ（events_YYYYMMDD という日付ごとのテーブル）。2段目は、その生データを自分たちで書いたクエリでレポート用のまとめ表に集計する処理です。今回、1段目のGA4からの送信は正常でした。止まっていたのは2段目の自前の集計のほうです。生データはBigQueryにちゃんと届いていたのに、それをまとめ表に並べる処理が取りこぼしていた、という形になります。

ではなぜ取りこぼすのか。GA4の生データは届く時刻が保証されていません。Googleの仕様では、日次の確定テーブルは翌日午後ごろに作られるのが一般的とされる一方で時刻の保証はなく、翌日にずれ込むこともあります。さらに遅れて届いたイベントは、当日プラス2日ほどかけて後から追加されます。届くまで実質1〜3日ほどを見ておくのが安全です（これがいわゆるGA4のBigQueryエクスポート遅延）。一方で集計クエリは毎朝「昨日のテーブルだけ」を読む設計でした。

直し方の結論も1行で言えます。毎回「直近の数日ぶん」をまとめて入れ直す、自己修復型に変えるだけです。

実話：成功ログが毎日並ぶのに、テーブルが伸びない

きっかけは「先月の流入が集計に出てこない」という違和感でした。

まず疑ったのはジョブの停止です。ところが実行履歴を見ると、毎日決まった時刻に集計が走り、状態はすべて成功（DONE）。エラーも無い。次に集計テーブルの中身を見ると、最新の日付が約2ヶ月前で止まっていました。

ここで「集計の元データ自体が止まったのでは」と考え、GA4側の events_ テーブルを確認します。すると元データは当日近くまで毎日そろっていました。つまり、ソースは生きているのに集計だけが拾えていない。欠けている期間の events_ は56日ぶん存在するのに、集計テーブルの該当期間は0行でした。

ここまで来て、ようやく犯人が「GA4のBigQueryエクスポート遅延」と「昨日だけ読む集計」の組み合わせだと分かりました。ジョブは毎朝きちんと走り、きちんと「まだ無い昨日」を読み、きちんと0行を書いて成功していたわけです。仕事熱心な空振りでした。

なぜ起きるのか：期待と実際のズレ

整理するとこうなります。

ポイントは、これがエラーで落ちないことです。落ちてくれれば気づけます。GA4のBigQueryエクスポート遅延は「異常」ではなく「正常な遅延」なので、クエリは何の文句も言わずに空を集計します。監視が「ジョブの成否」だけだと、永遠に気づけません。

直し方の3ステップ

ステップ1：ソースと集計のズレを確認する

まず事実を押さえます。集計テーブルの最新日付（MAX(date)）と、GA4の events_ テーブルの最新日付を並べて見比べる。元データのほうが新しければ、ソースは生きていて集計が取りこぼしているという確定診断になります。あわせて、欠けている期間の events_ が実在するかも数えておきます。実在するならバックフィルで埋められます。

ステップ2：欠けた期間をバックフィルする

抜けた区間を後追いで埋めます。コツは冪等（べきとう＝何度流しても結果が同じ）にすることです。対象期間をいったん削除してから入れ直す（DELETE してから INSERT する）形にすると、途中で失敗しても安全に再実行できます。元データがそろっている期間なら、これで一気に復旧します。

ステップ3：「直近数日を毎回入れ直す」自己修復型に変える

ここが再発防止の本丸です。「昨日だけ」をやめて、毎回「直近4日ぶん」をまとめて削除して入れ直す形にします。日付は実行日から数えるのではなく、テーブル名の日付サフィックス（_TABLE_SUFFIX＝events_ の末尾の日付部分）から拾います。

こうすると、ある日のデータが2日遅れて届いても、翌日以降の実行が同じ窓をもう一度処理するときに自然に拾われます。1日くらいの遅れや一時的な取りこぼしは、誰も手を動かさなくても勝手に埋まる。これが自己修復です。窓を何日にするかはエクスポートの遅延幅に余裕を持たせて決めます。

アンチパターン3つ

1. 「昨日だけ」を読む増分集計。GA4のBigQueryエクスポート遅延がある以上、単一日ピンポイントは取りこぼし前提になります。窓で処理する。
2. ジョブの成否だけを監視する。成功しても、データが入ったとは限りません。件数や最新日付（鮮度）を監視対象にする。
3. 集計テーブルに鮮度の自己申告が無い。レポート生成側で「この層の最新日付はいつか」を毎回出力し、古ければ警告する。鮮度を数字で持つだけで、空振りが可視化されます。

このうち2番目が一番の教訓です。動いていないシステムは気づかれて直されますが、誤って動いているシステムは気づかれずに被害が積み上がります。

外注・委託している場合の確認項目

データ基盤を自社で持たず、制作会社や開発パートナーに任せている管理職向けに、確認すべき点を挙げます。技術の中身を知らなくても、次の3つを聞けば取りこぼしリスクの大半は見えます。

データ連携まわりは、作って終わりではなく「壊れたと気づける設計か」で品質が決まります。設計思想の近い話として、データ移行で起きる取りこぼしの罠や、BigQueryでGA4のデータ基盤を作るときの実務知識もあわせて参考になります。

まとめ

GA4のBigQueryエクスポート遅延そのものは止められません。止められないものを前提に、集計を「昨日だけ」から「直近数日の窓を毎回入れ直す」へ変えるのが正解です。あわせて、ジョブの成否ではなくデータの鮮度を監視すれば、空振りはその日のうちに見えます。毎朝成功しているのにデータが伸びない、という静かな故障は、設計を少し変えるだけで防げます。

データ基盤の「気づけない故障」でお困りなら

GA4や広告データをBigQueryにためているけれど、数字がいつの間にか古くなっている、誰も壊れたと気づけない、という状態はよくあります。f2tでは、こうしたデータ基盤の設計と「壊れても気づける・自動で追いつく」運用づくりを支援しています。自社の集計が静かに止まっていないか不安な方は、お問い合わせからご相談ください。現状の構成を見て、どこにリスクがあるかを整理するところからお手伝いします。