【2026年】GA4とBigQuery連携｜無料枠でできる分析

「GA4で2年前の同じ月と比べたいのに、数字が出てこない」「探索の画面で、組みたい集計がどうしても組めない」——アクセスの数字を扱う担当者からくり返し聞く声です。この壁は、操作に慣れれば越えられるものではありません。標準の設定では、1件ごとの細かい記録が最長14か月で消える仕様だからです。この記事では、外部のデータ基盤へ書き出す判断と、費用が決まる仕組みを整理します。

なぜ今つなぐのか

理由は2つあります。1つはデータの保持期間です。GA4の標準プロパティでは、イベント単位のデータは最長14か月で削除されます。探索レポートで細かく見られるのはこの範囲だけで、それより前は集計済みの数字しか残りません。

もう1つは分析の天井です。探索レポートには行数や指標の組み合わせに制限があり、期間やデータ量によってはサンプリングが入ります。BigQueryに出したデータはイベント1件ずつが行として並ぶため、UIの制約を受けずに集計できます。

そして最も大きい違いが、他のデータと結合できることです。受注データや商談データと同じ場所に置けば、「どの流入経路から来た問い合わせが受注になったか」を1つのクエリで出せます。GA4の中だけでは分からない、売上との接続がここで可能になる点が本質的な価値です。

設定した日からしか出ない

最初に押さえるべき制約がこれです。BigQueryエクスポートは、連携を設定した日以降に発生したデータから出力されます。過去のデータを遡って出力する機能はありません。

この性質から、実務的な結論は1つです。今すぐ使う予定がなくても、設定だけ先に済ませておく。データが溜まり始めるのは設定した瞬間からなので、1年後に分析したくなったときに1年分あるかどうかは、今日の判断で決まります。

設定作業自体は、GCPのプロジェクト作成を含めても1時間程度です。分析を始めるかどうかは後で決められます。使うか決める前に、溜め始めるだけ済ませておくのが合理的な進め方です。

同じ理由で、計測の設定変更とエクスポートの開始は順序を意識します。カスタムイベントやパラメータを整えてから連携すると、出力されるデータの形が揃います。後から追加したパラメータは、追加した日以降の行にしか入りません。過去の行には空欄が並ぶため、集計時に期間の区切りが必要になります。

探索レポートで足りるかどうかの判断

BigQueryは必要な会社と、まだ必要でない会社があります。判断の基準を先に置いておきます。

探索レポートで足りるのは、見たい集計がGA4の指標とディメンションの組み合わせで表現できる場合です。流入経路別のコンバージョン数、ページ別の滞在、期間比較。これらはUIのほうが速く、SQLを書く理由がありません。

足りなくなるのは3つの場面です。14か月を超える期間を比較したいとき。GA4の外にあるデータと突き合わせたいとき。そして、自社の定義で指標を作り直したいときです。この3つのどれかに当たってから使い始めれば十分で、それ以前は設定だけしてデータを溜めておく状態で構いません。

なお、探索レポートには行数の上限やサンプリングの制約もあります。データ量が多いサイトでは、期間を広げた時点で数字がぼやけ始めます。この症状が出ているなら、BigQueryを使う段階に来ています。

1日100万イベントの上限

標準プロパティで日次（バッチ）エクスポートを使う場合、1日あたり100万イベントという上限があります。これを常態的に超えると、日次エクスポートは停止されます。

問題は復旧の扱いです。停止された期間のデータは、後から再処理されません。つまり上限超過に気づかないまま数か月経つと、その期間だけデータが欠けた状態が残ります。

100万イベントは、規模の目安としては月間数十万PV程度から意識が必要になる水準です。ただしイベント数はページビュー数ではなく、スクロールやクリックの計測を増やすほど膨らみます。カスタムイベントを大量に追加した直後に上限へ近づくケースがあります。

超える見込みがある場合は、ストリーミングエクスポートを併用します。こちらは件数の上限がありませんが、その分の費用が発生します。上限に近い規模なら、まず現状のイベント数を確認してから方式を決める順序になります。

費用はどう決まるのか

費用の考え方は2つに分かれます。データを置いておく費用（ストレージ）と、集計するときの費用（クエリ）です。どちらにも毎月の無料枠があります。

項目	無料枠	超過時の目安	実務での注意
ストレージ	毎月10GBまで無料	1GBあたり月数円程度	GA4のイベントデータは1日分で数十MB〜が目安
クエリ	毎月1TBの処理まで無料	東京リージョンで1TBあたり約6ドル	SELECT * で全期間を読むと一気に消費する
ストリーミング挿入	無料枠なし	取り込み量に応じて課金	上限超過対策で使う場合は事前に見積もる
サンドボックス	課金設定なしで試用可	—	テーブルの保持期間などの制限がある

小規模から中規模のサイトであれば、ストレージもクエリも無料枠の中で収まることが多いのが実情です。月に数万から数十万イベント程度の規模なら、年間のストレージ費用が数十円という水準にもなります。

費用が跳ねるのは、クエリの書き方が原因のときです。全期間・全カラムを読む書き方を繰り返すと、無料枠の1TBを短期間で使い切ります。防ぎ方は後述しますが、最初に知っておくべきは「置くこと」より「読むこと」で費用が動くという構造です。

連携の手順

設定は管理画面から進められます。技術的な知識はほとんど要りませんが、GCP側の準備が必要です。

この手順で見落とされやすいのが3番目のロケーションです。後から変更できないため、社内の他のデータと同じリージョンに揃えておくと、将来の結合で手間が減ります。

データの形を理解する

BigQueryに出たデータは、GA4のレポート画面とは形が違います。1日ごとに1つのテーブルができ、その中の1行が1イベントです。ページビューもクリックも、すべて同じ形で並びます。

最初につまずくのが、イベントのパラメータがネストされた構造で入っている点です。ページのURLやセッションIDは、event_paramsという入れ子の中にあります。普通のSQLの感覚でカラム名を指定しても取り出せないため、UNNESTという書き方を覚える必要があります。

ここが、GA4のBigQueryデータが「難しい」と言われる主な理由です。ただし、実務で使うパターンは限られています。よく使う10行程度のクエリをテンプレートとして保存すれば、以後は日付を変えるだけで済む作業になります。

もう1つ知っておきたいのが、当日分のテーブルです。日次エクスポートとは別に、当日のデータが一時的なテーブルとして作られる仕組みがあります。確定値と当日値が別のテーブルに入るため、集計対象を間違えると数字が合いません。

押さえておく項目は6つだけ

テーブルの中身は列数が多く、初見では圧倒されます。ただし実務で使う項目は限られています。最初に覚えるのは次の6つで足ります。

項目	意味	使いどころ
event_date / event_timestamp	発生日と発生時刻	期間の絞り込み。時刻は細かい単位で入る
event_name	イベントの名前	page_view や成果イベントの抽出
user_pseudo_id	端末単位の識別子	ユーザー数の概算。人単位ではない点に注意
event_params	イベントの詳細（入れ子）	URLやセッションIDの取り出し。UNNESTが必要
traffic_source / session_traffic_source	流入元の情報	経路別の集計
device / geo	端末と地域	セグメント分け

この6つが分かれば、日別の集計と成果イベントの抽出はできます。残りの列は、必要になったときに調べれば足ります。最初から全体を理解しようとすると挫折するため、使う順に覚えるのが早道です。

特に注意が必要なのが3番目です。user_pseudo_idは端末ごとの識別子で、同じ人がPCとスマートフォンから来れば別の値になります。ユーザー数という言葉が指す対象が、GA4のUIと一致しない原因のひとつがここにあります。

セッションの数え方でつまずく

BigQueryのデータでよく起きるのが、セッション数がGA4の画面と合わない問題です。原因は、セッションという概念が生の行データには存在しないことです。

イベントごとにセッションのIDがパラメータとして入っているため、それを取り出して数える形になります。ただしGA4のUI側では、セッションの数え方に独自の処理が入っているため、単純な集計では一致しません。時間帯の区切り方や、流入元が変わったときの扱いが影響します。

実務での結論はシンプルです。数字を揃えようとせず、用途を分けます。社内報告の公式値はGA4のUI、深掘りの分析はBigQueryと決めておけば、差の説明に時間を使わずに済みます。

どうしても揃えたい場合は、指標の定義を自社で決め直すほうが早いです。「30分以上間隔が空いたら別セッション」といった定義を自分で書けば、少なくとも社内では一貫した数字になります。外部の定義に合わせるより、自社の定義を1つ決めて使い続けるほうが議論が進みます。

最初に書く3つのクエリ

いきなり複雑な分析に入る必要はありません。次の3つが動けば、GA4のUIでは出せない集計に手が届きます。

• 日別のイベント数とユーザー数（データが正しく出ているかの確認用）
• 特定のイベントに絞った一覧（問い合わせ完了など、成果イベントの発生をイベント単位で見る）
• ランディングページ別のセッション数と成果数（UIでは組みにくい組み合わせ）

1つ目は検証用です。GA4の画面で見たイベント数とおおよそ一致していれば、連携は正しく動いています。完全一致は期待しないでください。集計のタイミングや定義の違いで数%のずれは通常起こります。

3つ目が、実務での最初の成果になります。ランディングページごとの成果数は、GA4の探索でも組めますが、条件を足すと行数の上限や表示の制約に当たります。SQLなら制約なく組めます。

費用を増やさない書き方

クエリの費用は、読み込んだデータ量で決まります。この性質を知っていれば、費用は簡単に抑えられます。

• SELECT * を使わず、必要なカラムだけを指定する（読み込み量が数分の1になる）
• テーブルの指定で日付の範囲を絞る（ワイルドカードで全期間を読まない）
• コンソールに表示される処理予定量を実行前に確認する
• 同じ集計を繰り返すなら、結果を別テーブルに保存して以後はそれを読む
• プロジェクトにクエリ使用量の上限を設定しておく（想定外の課金を防ぐ）
• 自動更新のダッシュボードを繋ぐ場合は、更新頻度を必要最小限にする

最後の項目が、実際の請求で効いてきます。ダッシュボードを15分ごとに自動更新する設定にすると、同じクエリが1日に96回走ります。日次で足りるなら日次に落とすだけで、消費量は大きく下がります。

BtoBで最も効く使い方

BigQueryに出す価値が最も大きく出るのは、GA4以外のデータと結合するときです。BtoBでは、Webの行動と受注の間に商談という長い期間が入るため、GA4の中だけでは成果が追えません。

具体的には、CRMやSFAから商談・受注のデータを同じプロジェクトに入れ、共通のIDで結合します。フォーム送信時に発行したIDを両方に持たせておけば、流入経路ごとの受注金額まで1つの表で出せます。

この構成が組めると、報告の内容が変わります。「セッションが増えました」ではなく「この流入経路からの受注が四半期で何件・いくら」という単位で話せます。経路別の受注金額が出せると、予算配分の議論が数字で進むようになります。

結合の準備で必要なのは、送信時のID設計です。後から紐づけようとしても、両方に共通の値がなければ結合できません。フォームやMAの設定を触るタイミングで、この一手間を入れておいてください。

個人情報の扱いにも先に線を引きます。BigQueryへ氏名やメールアドレスをそのまま入れる必要はありません。紐づけ用のIDだけを持たせ、個人情報は既存のCRM側に置いたままにする設計が基本です。分析に必要なのは属性と結果であって、誰であるかの情報ではない場面が多くあります。

誰が触るかを先に決める

運用を始める前に、権限とコストの管理を決めておきます。ここを曖昧にすると、後で止まる要因になります。

権限は少なくとも3つに分けます。設定を変更できる管理者、クエリを実行できる分析担当、結果だけを見る閲覧者。全員に実行権限を渡すと、大きなクエリが無自覚に走って費用が跳ねます。

コストの管理者も1人決めます。月次で消費量を確認し、上限設定を管理する役割です。消費量を誰も見ていない状態が、想定外の請求につながる最大の原因になります。月に5分の確認で足ります。

加えて、担当者が変わるときの引き継ぎ項目を残します。プロジェクトの所在、課金の紐づけ先、よく使うクエリの保存場所の3つが書かれていれば、後任は続けられます。個人アカウントでプロジェクトを作らないことも、あわせて決めておきます。

よくある失敗

実際に起きているつまずきを挙げます。多くは事前に知っていれば避けられるものです。

• 必要になってから設定する（過去分は遡れないため、その時点で使えるデータがない）
• 1日100万イベントの上限を把握しないまま計測イベントを増やす（停止され、欠損が残る）
• SELECT * で全期間を何度も読む（無料枠を短期間で使い切る）
• ロケーションを既存の社内データと別に設定する（後から変更できず、結合の手間が増える）
• 当日分の一時テーブルと確定分のテーブルを混ぜて集計する（数字が合わなくなる）
• GA4の画面の数字と完全一致させようとする（定義が違うため一致しない。用途で使い分ける）
• 課金上限を設定しないまま自動更新のダッシュボードを繋ぐ（想定外の請求につながる）

最後から2番目は、社内報告で混乱を招く箇所です。GA4のUIとBigQueryは集計の定義が異なるため、数%の差は正常です。どちらを公式の数字として使うかを先に決めておくと、差の説明に時間を取られません。

最初の3か月の進め方

設定した後、何から手を付けるかを決めておくと形になります。3か月を目安にした進め方を示します。

1か月目は、データが正しく溜まっているかの確認だけです。日次のイベント数を毎週見て、欠けている日がないかを確認します。この段階で分析に踏み込む必要はありません。上限超過による停止に気づける状態を作ることが目的です。

2か月目に、GA4のUIでは組めなかった集計を1つだけ作ります。ランディングページ別の成果数など、実務で使う予定のあるものに絞ります。ここで消費量の実感も得られます。

3か月目に、他のデータとの結合を試します。受注データを1回だけ手動で取り込み、流入経路別の受注が出せるかを確認する。自動化は後回しで構いません。1回でも出せた実績があれば、社内で価値を説明できます。最初から自動連携を目指すと、設計に時間を取られて成果が出ないまま止まります。

よくある質問

エンジニアがいなくても運用できますか

設定はマーケティング担当者でも可能です。クエリの作成は学習が必要ですが、よく使う数本をテンプレート化すれば運用は回ります。生成AIにテーブル構造を伝えてSQLを書かせる方法も実務で使われていますが、実行前に処理量を確認する習慣は必須です。

無料枠だけで続けられますか

小〜中規模のサイトで、集計の頻度を日次程度に抑えるなら十分に可能です。逆に、大量のイベントを持つサイトや、複数人が頻繁に大きなクエリを走らせる環境では超過します。まずは1か月運用して、消費量を実測してから判断するのが確実です。

すでに数年運用していますが、過去データは取り出せますか

イベント単位のデータは取り出せません。GA4のUIで見られる集計済みの数字は、レポートのエクスポートやAPIで取得できます。ただし粒度は落ちます。過去を諦めて、今日から溜め始めるのが唯一の選択です。

Looker Studioに直接つなげばよいのでは

GA4とLooker Studioの直接接続でも多くの可視化はできます。BigQueryを挟む価値は、保持期間を超えたデータを持てること、他のデータと結合できること、重い集計を事前に済ませて軽く表示できることです。目的が定期レポートだけなら、直接接続で足ります。

まとめ

GA4のBigQueryエクスポートは、保持期間の制約と分析の天井を同時に外す手段です。最大の注意点は、設定した日以降のデータしか出ないことです。使う予定が決まっていなくても、設定だけ先に済ませておく価値があります。標準プロパティでは1日100万イベントの上限があり、超過すると停止して再処理されないため、計測イベントを増やす際は現状の件数を確認してください。費用はストレージ10GB・クエリ1TBの無料枠内に収まる規模も多く、跳ねる原因は読み込み方です。必要なカラムと日付範囲を絞る習慣を最初から付けておけば、無料枠の中で実務に足る分析ができます。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。