GA4とBigQueryをリンクしたのにテーブルが作成されない原因と確認手順｜events_intradayしかない時の切り分けフロー

GA4とBigQueryのリンク設定を終えて、翌日データセットを開いてみたら中身が空——あるいはevents_intraday_YYYYMMDDしか存在しない。この状態で「設定を間違えたのか」「壊れているのか」「もう少し待てばいいのか」の判断がつかず、時間だけが過ぎていくケースは少なくありません。

結論から言うと、GA4とBigQueryのエクスポートは仕様上、リンク直後から最大72時間ほど「正常でも空・不完全」に見える期間があります。一方で、日次エクスポートの設定漏れやサービスアカウントの権限不足、課金設定の問題は、どれだけ待っても直りません。この二つを最初に切り分けないまま個別の原因を順番に潰していくと、無駄に時間を消費してしまいます。

この記事では、Google アナリティクス 4（GA4）とBigQueryのリンク後にテーブルが作成されない状況を「待てば直る仕様」と「直さないと出ない障害」に時間基準で二分し、events_intradayしかない状態を含めて当日中に原因を特定する手順を解説します。

この記事のポイント

• テーブル未作成は初回リンクから最大24時間、日次テーブルは翌日午後〜72時間まで様子見が正常範囲と言える
• events_intradayしかない状態は「日次未有効」「作成遅延」「滞留バグ」の3パターンに分解して判断するのが定石
• 72時間を超えて日次テーブルが出ない場合は仕様待ちを打ち切り、権限・課金・上限の設定確認に進むべき
• GA4画面とBigQueryの集計数値は仕様上一致しないため、数値差だけを復旧未完了の根拠にしない

GA4とBigQueryをリンクしたのにテーブルが作成されないのはなぜ？

GA4とBigQueryをリンクした直後にテーブルが見当たらない場合、まず疑うべきは障害ではなく仕様上の待ち時間です。BigQueryエクスポートは即時反映を保証する仕組みではなく、初回接続後の反映に一定の時間がかかる設計になっています。

原因を焦って探る前に、まず時間軸で自分の状況を測ることが重要です。リンクしてから何時間経過したか、日次テーブルなのかストリーミングなのか、この2点を確認するだけで、対応すべきかどうかの八割は判断できます。

最初に押さえる結論：24〜72時間は「正常でも空」があり得る

リンク完了から24時間以内であれば、テーブルが1つも存在しない状態は仕様の範囲内です。さらに日次テーブル（events_YYYYMMDD）に限れば、初回作成が翌日の午後になることも珍しくなく、混雑状況によっては翌々日にずれ込むこともあります。つまり「リンクした当日の夜に見に行って何もない」のは、故障ではなく想定どおりの挙動です。

原因は「仕様・設定・権限・課金」の4系統に分かれる

テーブルが作成されない要因は、大きく4つの系統に整理できます。

系統	内容	待てば直るか
仕様	遡及なし・初回反映の遅延・日次作成タイミング	待てば直る
設定	日次/ストリーミングのチェック漏れ、データストリームの選択ミス	待っても直らない
権限	サービスアカウントへのBigQuery権限不足	待っても直らない
課金	サンドボックス制約、課金アカウント未設定、上限超過	待っても直らない

この4系統のうち、自分がどこに該当するかを次章以降で順番に確認していきます。

まず確認：故障ではなく「仕様」でテーブルが見えない3パターン

焦らず待つと気づいて肩の力が抜ける瞬間

多くの問い合わせは、実は仕様どおりの挙動を障害と誤認しているケースです。ここで紹介する3パターンに当てはまるなら、対処は不要で、待つことが最善の一手になります。

リンク前の過去データはエクスポートされない（遡及なし）

GA4とBigQueryのリンクとは、リンク完了時点以降に発生したイベントデータをBigQueryへ転送し始める設定のことです。過去に遡ってエクスポートされることはありません。「先月分のデータも見たかったのに入っていない」という相談は非常に多いのですが、これは不具合ではなく仕様です。過去分のデータが必要な場合は、GA4のData APIなど別の取得手段を検討する必要があります。

初回テーブル作成はリンク完了から最大24時間

リンクボタンを押した瞬間にテーブルが生成されるわけではありません。Google公式のガイダンスでも、初回のデータエクスポートには最大24時間程度を要するとされています。リンク作業を終えてから半日程度で「何もない」と焦るのは時期尚早です。

日次テーブル（events_YYYYMMDD）は翌日の午後、遅いと翌々日に作られる

日次エクスポートのテーブルは、対象日のデータが確定してから生成されるため、当日中には作られません。目安としては翌日の午後にはできていることが多いとされますが、システムの混雑状況によっては翌々日にずれ込むこともあります。したがって「リンクした翌朝に見て、まだ日次テーブルがない」段階では、異常と判断するにはまだ早いというのが実務上の目安です。

events_intradayしかない時の切り分けフロー

図1: intradayのみの状態を3パターンに分岐させる判断ツリー

events_intradayテーブルだけが存在し、日次のevents_YYYYMMDDが一向に現れない状態は、この記事で最も相談が多いパターンです。この状態は原因が一つではなく、少なくとも3つの異なるパターンが混在しているため、まず自分がどれに該当するかを切り分ける必要があります。

パターン1：日次エクスポートにチェックが入っていない(設定を確認する場所)

日次エクスポートが有効化されていなければ、events_intradayだけが延々と作られ続け、日次テーブルは永遠に生成されません。GA4の管理画面で「管理」→「プロダクトリンク」→「BigQueryのリンク」に進み、エクスポートの構成で「日次」にチェックが入っているかを確認してください。ストリーミングだけを有効にしていて日次を外している設定ミスは、実務でも起こりやすい典型パターンです。

パターン2：日次テーブルの作成遅延(72時間までの待ち方と判断基準)

設定自体は正しいのに日次テーブルがまだない場合は、単純な遅延の可能性があります。目安として、リンクから72時間以内であれば遅延の範囲内とみなし、様子を見てよいと言えます。72時間を超えても日次テーブルが1件も現れない場合は、この時点で仕様待ちの判断を打ち切り、後述する権限・課金の確認に進むべきタイミングです。

パターン3：intradayが消えずに滞留する事象(報告例と対処)

本来、events_intradayテーブルは日次テーブルが完成すると自動的に削除される一時的なテーブルです。しかし、処理が途中で中断されると、同じ日付のevents_intradayテーブルが複数残ってしまう事象が報告されています。OWOXのブログ記事「GA4 to BigQuery Export 2025: Events Table Schema and Dates」では、こうした処理中断によってintradayテーブルが同日中に複数残存するケースがあり、集計時には複数のintradayテーブルを結合して読む必要があると指摘されています。日本国内でこの現象に遭遇した場合も、まずはデータセット内に同日付のintradayテーブルが複数存在していないかを確認するとよいでしょう。

注意：intradayは参照元・メディアが不完全なまま。日次の代用にしない

events_intradayテーブルは速報性を優先した設計のため、参照元やメディアといったトラフィックソース関連の項目が確定しないまま格納されることがあります。日次のevents確定後にようやく正確な値に揃うという性質上、intradayを広告の参照元集計に使うと数値がずれる恐れがあります。日次テーブルが出ていないからといって、intradayだけを根拠に広告効果を判断するのは避けたほうが無難です。

テーブルが1つも作成されない時の原因切り分け手順

図2: 手順1〜4を上から順に確認するステップ図

events_intradayすら1件も存在しない場合は、仕様待ちではなく設定・権限・課金のいずれかに問題がある可能性が高いというのが実務的な見立てです。以下の手順1〜4を順番に確認してください。

手順1：GA4側のリンク状態とエクスポート種類・データストリームを確認する

GA4管理画面の「BigQueryのリンク」設定で、リンク自体が有効になっているか、対象のデータストリームが正しく選択されているかをまず確認します。複数のデータストリームを持つプロパティで、対象ストリームの選択漏れがあると、そのストリーム分のデータだけがエクスポートされません。

手順2：firebase-measurementサービスアカウントの権限を確認する

GA4のBigQueryエクスポートは、firebase-measurement@system.gserviceaccount.comというサービスアカウントを経由して書き込まれます。Google Cloud（IAM・課金）のIAM画面で、このサービスアカウントに対象データセットへの「BigQueryデータ編集者」相当の権限が付与されているかを確認してください。プロジェクトの権限を後から絞り込んだ際に、このサービスアカウントの権限だけが意図せず外れてしまうケースが実務ではよく見られます。

手順3：課金状態を確認する(サンドボックスの制約・60日でテーブルが消える罠)

課金アカウントが紐づいていないプロジェクトは、BigQueryサンドボックスという無料の制限モードで動作します。サンドボックスにはストリーミングエクスポートが使えないという制約に加え、テーブルが作成から60日で自動的に失効するという大きな落とし穴があります。DumbDataの記事「Linking Google Analytics (GA4) & BigQuery: 9 Things To Do First」では、サンドボックス環境でテーブルが60日で自動失効し、後から課金を有効化してもデータセットや既存テーブルの有効期限設定を手動で見直さない限り消滅が続くと指摘されています。「最近までデータが入っていたのに急に止まった」という相談の多くは、この60日失効が正体であるケースが少なくありません。課金アカウントの紐付け状況とデータセットの有効期限設定は、セットで確認する必要があります。

手順4：1日100万イベント上限・ロケーション/組織ポリシーを確認する

標準プロパティ（無料版のGA4）には、1日あたり100万イベントというBigQueryエクスポートの上限が設けられています。この上限を超過すると、その日のエクスポートが一時的に停止することがあります。また、データセットのロケーション（リージョン）設定や組織ポリシーの制約によってエクスポートがブロックされる場合もあるため、イベント量が多いプロパティでは上限超過の可能性も併せて確認してください。

GA4のBigQueryエクスポートはいつ反映される？時間の目安まとめ

図3: 初回・日次・ストリーミングの反映タイミング早見図

反映タイミングの目安を時間軸で持っておくことが、仕様と障害を切り分ける最短ルートです。以下の早見表は、公式ヘルプや各種ソースで示されている目安を整理したものです。

初回・日次・ストリーミングの反映時間早見表

エクスポート種別	反映の目安	異常と判断してよいライン
初回リンク後の最初のテーブル	最大24時間	24時間超過で未作成
日次テーブル(events_YYYYMMDD)	翌日午後〜翌々日	72時間超過で未作成
ストリーミングエクスポート	数分〜数十分	数時間経っても反映なし
events_intraday	当日中、随時更新	日次確定後も削除されず滞留

この表はあくまで一般的な目安であり、プロパティの規模やイベント量によって前後します。とはいえ、判断に迷ったときの基準としては十分に機能します。

UTC基準のevent_timestampで「欠けて見える」誤診に注意

BigQueryに格納されるevent_timestampは、プロパティのタイムゾーンではなくUTC（協定世界時）基準のマイクロ秒で記録されます。Simmer（teamsimmer.com）のブログ記事「Why Are My Intraday Table Timestamps Set In The Future When I Query Them?」では、この仕様によってintradayテーブルのタイムスタンプが未来時刻に見えたり、日付の境界がずれて見えたりすると解説されています。日本国内の担当者は日本標準時（JST）の感覚でクエリを書きがちなため、UTCとの時差(9時間)を考慮せずに「特定時間帯のデータが欠けている」と誤診してしまう例が起きやすいポイントです。クエリを書く際は、タイムゾーン変換を挟んでから件数を確認する習慣をつけるとよいでしょう。

復旧を確認する方法と再発防止の設定

通知設定を終えて安心する担当者

テーブルが無事に作成され始めたら、次に気になるのは「本当に正常に戻ったのか」という点です。ここを誤診すると、直っているのに直っていないと思い込んで無駄な対応を続けることになります。

復旧確認：GA4画面とBigQueryの数値は一致しなくて正常

GA4管理画面のレポート上の数値と、BigQueryにエクスポートされた生データの集計値は、一致しないのが正常な状態です。Google Analytics Developers Blogの記事「Bridge the gap between the Google Analytics UI and BigQuery export」では、推定処理・モデリング・しきい値処理といった集計仕様の違いにより、両者が一致しないことは公式に明言されています。復旧確認の場面で「画面の数値とBigQueryの数値が違う」ことだけを根拠に「まだ壊れている」と判断するのは誤りです。むしろ確認すべきは、日次テーブルが継続して毎日生成され続けているか、行数が極端にゼロに近い日がないか、といった点になります。なお、GA4のレポート同士で数値が食い違う場合の原因については、GA4のレポート間で数値が合わない原因の切り分けで詳しく扱っています。

エラー通知メールとテーブル有効期限の見直しで再発を防ぐ

一度復旧しても、課金設定やデータセットの有効期限設定を放置すると同じ問題が再発します。Google Cloudのプロジェクト設定でエラー通知メールを有効にしておけば、エクスポート失敗時に早期に気づけます。また、サンドボックスから課金プロジェクトへ移行した場合は、既存データセットのデフォルトテーブル有効期限を「無期限」または十分に長い日数へ手動で変更しておくことが、60日失効の再発防止として欠かせません。

GA4とBigQueryのエクスポートに関するよくある質問

Q：GA4とBigQueryをリンクすると過去のデータもエクスポートされますか？

いいえ、遡及されません。エクスポート対象になるのはリンク完了以降に発生したデータのみで、リンク前の期間のデータをBigQueryへ後から取り込むことはできません。過去分のデータが必要な場合は、GA4のData APIなど別の取得手段を検討する必要があります。

Q：events_intradayテーブルはいつ消えますか？残しておけますか？

events_intradayテーブルは、対応する日次テーブル（events_YYYYMMDD）が完成した時点で自動的に削除される一時テーブルという位置づけです。意図的にデータを残しておきたい場合は、intraday側を保持する設計にするのではなく、日次テーブル側を正として利用する構成にするべきです。

Q：GA4のBigQueryエクスポートは無料で使えますか？費用はいくらかかりますか？

エクスポート自体は、BigQueryの無料枠（BigQueryサンドボックス）内で開始できます。ただし、サンドボックスにはストリーミングエクスポートが使えない制約と、テーブルが60日で自動失効するという制約があります。継続的な運用やストリーミング利用を見込む場合は、早い段階で課金アカウントを紐づけておくことが望ましいと言えます。

Q：1日100万イベントの上限を超えるとどうなりますか？

標準プロパティ(無料版のGA4)には、BigQueryへの日次エクスポートに1日あたり100万イベントという上限が設けられています。この上限を超過すると、その日のエクスポートが一時的に停止し得ます。イベント量が多い場合は、計測イベントの絞り込みを検討するか、GA4 360へのアップグレードとストリーミングエクスポートの併用を検討することになります。

Q：リンクを一度削除して作り直せば直りますか？

原因が権限不足や課金設定にある場合、リンクを削除して再設定しても根本的な問題は解決しません。むしろ、リンクが切れていた期間のデータは欠損したまま戻らないため、先に原因を特定してから対処することが重要です。安易な再リンクは、データの欠損期間を増やすだけに終わる可能性があります。

---

GA4とBigQueryの連携は、導入判断の段階から運用後のトラブルシューティングまで地続きの領域です。真策堂では、こうした仕様と障害の切り分けを含めたアクセス解析基盤の設計・運用相談を受けています。テーブルが正常に出るようになった後は、BigQueryでGA4の生データを触る最初の一歩も参考にしていただくと、次のアクションがスムーズです。連携そのものの目的や導入判断に迷う場合はGA4×BigQuery連携で何ができるか・導入判断の全体像を、そもそもなぜBigQuery連携が必要なのかという動機の部分はGA4のデータ保持期間とBigQuery連携による長期保存をあわせてご覧ください。お困りの際は、お気軽にご相談ください。