「GA4のデータをBigQueryに入れたい」。この相談を受けるとき、背景はだいたい同じです。GA4の標準UIでは知りたい数字にたどり着けない、広告費や受注データと突き合わせたい、あるいは経営会議で使うレポートが作りづらい。
GA4のBigQueryエクスポートは、無料でオンにできて、以後は毎日自動でデータが流れます。設定自体は10分もかかりません。ただし、料金の考え方、events_* テーブルの読み方、そして「有効化した日以降のデータしか残らない」といった落とし穴を知っておかないと、いざ使う段になって困ります。
そこで、GA4だけでは何が足りないか、エクスポートの仕組みと設定手順、料金の実感、実務でよく使うSQL、Looker Studioや広告データとの組み合わせ、注意点までを、2026年8月時点の情報で通しで整理します。
BigQueryを持ち出す前に、そもそもGA4の標準UIで済むならそれが一番早い、という前提を確認しておきます。実際、月次の概況を見るだけ、探索レポートで思いつく切り口を試すだけなら、GA4のUIで完結します。
BigQueryが必要になるのは、次のような問いが業務で出てきた瞬間です。
このうち1つでも「うちに当てはまる」となったら、BigQueryエクスポートを有効化しておく価値があります。逆に、当てはまるものがゼロなら、まだ設定する必要はありません。
GA4のBigQueryエクスポートは、GA4が受け取ったイベントデータを、そのままBigQuery上のテーブルとしてコピーしてくれる公式機能です。仕組みは単純で、GA4管理画面から自分のGoogle CloudプロジェクトIDを紐づけると、以後は毎日、前日ぶんのイベントが events_YYYYMMDD というテーブルに追加されていきます。
3つの構成要素を覚えれば全体像がつかめます。
analytics_XXXXXXXXX という名前で自動作成される保存先。中に日付ごとのテーブル events_YYYYMMDD が並ぶエクスポート先はGoogle Cloud上のプロジェクトなので、事前にGoogle Cloudアカウントとプロジェクトを1つ用意しておく必要があります。BigQueryの基本については、別記事のBigQuery導入ガイドにまとめています。
有料版のGA4 360を使っている場合は、日次に加えて「ストリーミングエクスポート」（数分〜数十分でBigQueryに反映）と「フレッシュデイリー」（当日ぶんの追加取り込み）が選べます。ただし、多くの会社では無料版の日次エクスポートで十分です。
作業は5ステップで、実作業時間はおよそ10分です。
firebase-measurement@system.gserviceaccount.com）にBigQuery管理者権限を付与しておきます。既存プロジェクトを流用してもかまいませんが、費用の見通しを立てやすくするために「解析データ専用のプロジェクト」を1つ切ることを推奨しますanalytics_<プロパティID> データセットにテーブルが日次で追加されていきます有効化してから最初のテーブルが揃うまで、通常は24〜48時間かかります。そこから先は特に何もしなくても、毎朝、前日ぶんが増えていきます。
注意点が1つ：エクスポートは「有効化した日以降のデータ」しか対象になりません。過去分はさかのぼれないので、いま「使うかもしれない」の温度感でも、先に有効化だけしておく判断がほぼ正解です。GA4は最長14か月しかデータを保持しないため、放置している間、後で欲しくなる数字が毎日消えていきます。
費用は「GA4→BigQueryの転送」と「BigQuery側」の2箇所で発生しますが、実質的にはBigQuery側だけ考えれば足ります。
規模別のざっくりした感覚を表にすると、次のような形になります（2026年8月時点、標準的な使い方を想定）。
| サイト規模 | GA4イベント量/月 | ストレージ | 月間クエリ量 | 無料枠内で収まるか |
|---|---|---|---|---|
| 小規模コーポレート・LP | 〜数十万 | 数GiB | 数百MiB | ほぼ収まる |
| メディア・ECの中規模 | 数百万〜1000万 | 数十GiB | 数百GiB | 月数百円〜数千円 |
| 大規模EC・アプリ | 数千万〜億 | 数百GiB〜 | 数TiB | 月1〜10万円レンジ |
料金が跳ねるパターンはほぼ1つで、「1回のクエリで巨大なテーブルをフルスキャンする」ケースです。BigQuery側でパーティション（日付単位）を絞る、必要な列だけ選ぶ、SELECT * を書かない、この3つを習慣化するだけで請求は落ち着きます。詳細はBigQueryのコスト最適化にまとめています。
エクスポートが動き始めると、BigQuery側に events_YYYYMMDD（および当日ぶんの events_intraday_YYYYMMDD）というテーブルが1日1つずつ増えていきます。1行が1イベントで、主な列は以下です。
page_view / session_start / purchase など）key と value.string_value / value.int_value などの構造purchase などで使う）読みづらいポイントは1つだけで、event_params と items がネストされた配列になっている点です。SQLで扱うときは UNNEST() で展開してから絞り込む、という書き方が基本になります。
-- 例: 特定のCVイベント数を日別で集計する
SELECT
event_date,
COUNT(*) AS cv_count
FROM `myproject.analytics_123456789.events_*`
WHERE _TABLE_SUFFIX BETWEEN '20260701' AND '20260731'
AND event_name = 'purchase'
GROUP BY event_date
ORDER BY event_date;_TABLE_SUFFIX によるパーティション絞り込みは必須です。これを忘れると全期間のテーブルをフルスキャンし、費用と実行時間が跳ねます。
「入れた後、何を書けば実務で役に立つか」の代表例を4つに絞って挙げます。いずれも _TABLE_SUFFIX で対象期間を先に絞る前提です。
1. ページ別のPV・ユニークユーザー数
SELECT
(SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'page_location') AS page_url,
COUNT(*) AS pv,
COUNT(DISTINCT user_pseudo_id) AS uu
FROM `myproject.analytics_123456789.events_*`
WHERE _TABLE_SUFFIX BETWEEN '20260701' AND '20260731'
AND event_name = 'page_view'
GROUP BY page_url
ORDER BY pv DESC
LIMIT 100;2. 流入元別のCV数とCVR
WITH sessions AS (
SELECT
user_pseudo_id,
(SELECT value.int_value FROM UNNEST(event_params) WHERE key = 'ga_session_id') AS session_id,
traffic_source.source AS source,
traffic_source.medium AS medium,
event_name
FROM `myproject.analytics_123456789.events_*`
WHERE _TABLE_SUFFIX BETWEEN '20260701' AND '20260731'
)
SELECT
source,
medium,
COUNT(DISTINCT CONCAT(user_pseudo_id, CAST(session_id AS STRING))) AS sessions,
COUNTIF(event_name = 'purchase') AS cv,
SAFE_DIVIDE(COUNTIF(event_name = 'purchase'), COUNT(DISTINCT CONCAT(user_pseudo_id, CAST(session_id AS STRING)))) AS cvr
FROM sessions
GROUP BY source, medium
ORDER BY cv DESC;3. ファネル分析（ページA → ページB → 購入）
WITH events AS (
SELECT
user_pseudo_id,
event_timestamp,
event_name,
(SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'page_location') AS page
FROM `myproject.analytics_123456789.events_*`
WHERE _TABLE_SUFFIX BETWEEN '20260701' AND '20260731'
)
SELECT
COUNTIF(page LIKE '%/product/%') AS step1_product_view,
COUNTIF(page LIKE '%/cart%') AS step2_cart,
COUNTIF(event_name = 'purchase') AS step3_purchase
FROM events;4. 商品別の売上ランキング
SELECT
item.item_name,
SUM(item.quantity) AS qty,
SUM(item.item_revenue) AS revenue
FROM `myproject.analytics_123456789.events_*`, UNNEST(items) AS item
WHERE _TABLE_SUFFIX BETWEEN '20260701' AND '20260731'
AND event_name = 'purchase'
GROUP BY item.item_name
ORDER BY revenue DESC
LIMIT 30;この4本を叩けるだけで、GA4のUIでは追いにくかった細かい問いにほぼ答えられるようになります。実務ではこれらを dbt などでビュー化しておき、毎日回すのが定石です。
SQLで出した数字をチームで共有するには、Looker Studio（旧データポータル）が最短です。BigQueryとLooker Studioは同じGoogleエコシステム内なので、認証情報の設定さえ済ませればコネクタ経由でそのままつながります。
つなぎ方は2通りで、使い分けは次のとおりです。
「1枚目のダッシュボードは急ぎで作りたい、でも長く使う」場合は、最初はコネクタで直接つなぎ、使う指標が固まってきた段階でビューに切り出す、という順が現実的です。可視化ツールとしてTableauやPower BIも当然使えますが、GA4のBigQueryエクスポートに関してはLooker Studioが最も摩擦の少ない選択肢になります。構築を外部に依頼する場合の費用感と進め方は、Looker Studio構築代行の費用と進め方｜依頼できる範囲と会社選びにまとめています。
BigQueryにGA4のCVデータが乗っていると、次に効くのが「広告データを同じBigQueryに集めて突き合わせる」ステップです。Google広告、Meta広告、Yahoo!広告、TikTok広告のいずれもBigQueryに集約する手段があり、集約さえできれば 広告費 / GA4のCV数 で媒体横断のROASを1枚に載せられます。
自前で組んでもよいですが、媒体ごとのAPI仕様変更に追随し続けるのは思ったより手間で、SaaSに寄せてしまうほうが現実的です。当社が提供しているアドヨミAIは、Google・Meta・Yahoo!・TikTok・LINE・Amazonなどの主要媒体データをBigQueryに集約し、GA4データと掛け合わせたレポートまで自動化するサービスです。「まずレポートが欲しい、基盤の議論はその後」という順で始めたい会社に向きます。
エクスポートを有効化した後、実務で必ずと言ってよいほど出会う「詰まりポイント」を4つ挙げておきます。
1. GA4のUIとBigQueryの数字が合わない
一致しません。GA4のUIはサンプリング・しきい値・独自のセッション定義が入るためです。合わせようとすると疲弊するので、意思決定に使う数字は「BigQuery側の定義」を正として、そちらでダッシュボードを作り直すのが実務的です。UIは概況の速報用と割り切ります。
2. パーティションを絞らずに走らせて料金が跳ねる
WHERE _TABLE_SUFFIX BETWEEN ... を書き忘れると、events_* は全期間のテーブルをスキャンします。1本のクエリで数千円〜の請求が発生するケースも珍しくありません。BigQuery側の予算アラートとクエリごとのスキャン量上限（--maximum_bytes_billed）を先に設定しておくのが安全です。
3. event_params の UNNEST を書きすぎて遅くなる
同じイベント行から複数のパラメータを取るとき、UNNEST を何度も書くと処理が重くなります。サブクエリで一度に取り出す、または STRUCT として先に整形しておく形にすると読みやすく・速くなります。ここはdbtなどで整形レイヤーを1枚挟むと後がずっと楽です。
4. PIIが混入している
URLのクエリパラメータやフォーム入力値の取り違えで、メールアドレスや電話番号がイベントに入り込むケースがあります。BigQueryに移った時点で「消せない・見られる」状態になるので、エクスポート開始前に event_params をサンプル抽出してPIIが流れていないかを確認するのが安全です。混入していた場合はGA4側の計測を修正するのが正攻法で、BigQuery側でマスクするのは応急処置にとどめます。
「エクスポートは有効化した。ただし、そこから先の設計と最初のダッシュボード作りに手が回らない」というケースでは、部分的に外部に頼むのが早いです。頼む範囲別のざっくりした費用感を表にしておきます。
| 依頼範囲 | 費用相場 | 期間目安 |
|---|---|---|
| BigQueryエクスポート有効化＋Looker Studioの初期ダッシュボード1枚 | 20〜50万円 | 2〜3週間 |
| ↑＋主要SQLビュー整備（PV・CVR・ファネル・商品売上） | 50〜120万円 | 4〜6週間 |
| ↑＋広告データ集約（Google/Meta/Yahoo!）＋ROASダッシュボード | 150〜300万円 | 2〜3か月 |
| ↑＋dbt導入・独自指標定義・運用保守込みのフル構築 | 300万円〜 | 3〜6か月 |
数字はあくまで目安で、既存の広告アカウント数・データ量・要件の複雑さで動きます。基盤全体の費用感については、別記事のデータ基盤構築の費用相場にもう少し詳しく整理してあります。
当社では、GA4のBigQueryエクスポート有効化から、広告データ集約、ダッシュボード整備、dbtによる指標定義、運用保守までを一気通貫で支援するデータ基盤構築サービスを提供しています。「まず1枚のダッシュボードから始めて、そこから広告・受注データを段階的に足していく」という進め方で、初期の投資を最小に抑えつつ、後から拡張しやすい形で組み上げます。
GA4のBigQueryエクスポートは、無料で有効化できて、GA4単体では届かないところ（長期保存・サンプリング回避・広告や受注との突き合わせ・独自指標）に一気に手が届く、コストパフォーマンスの高い一歩です。
要点を5つに絞ります。
_TABLE_SUFFIX で期間を絞る習慣が請求を安定させる「エクスポートは動いた、次はどこから手をつけるか」で止まっているなら、データ基盤構築サービスや、GA4×広告データの一気通貫を短期で立ち上げるアドヨミAIをお気軽にご相談ください。1時間の壁打ちで、いま最初にやるべき1手をご一緒に決めます。
データ基盤Amazon RedshiftからBigQueryへの移行判断・費用・工程を、稟議とベンダー選定にそのまま使える形で整理します。BigQuery Data Transfer ServiceでのRedshift移行、SUPER型やDISTKEY/SORTKEYの扱い、AWS→GCPのエグレス費用、10TB規模で初期1,000万〜2,000万円・3〜4ヶ月という目安まで解説します。
データ基盤freee会計・マネーフォワード クラウド会計のデータをBigQueryに載せる方法を、trocco・Fivetran・Airbyte・Cloud Run内製・特化型SaaSの5パターンで費用比較。月額0円〜月30万円まで、freeeプラン別のAPI制限差、非同期ジョブや締め後修正の実装落とし穴、Shopifyや広告費との突合ユースケースを稟議に使える形で整理した2026年版です。
データ基盤Shopifyの注文・顧客・在庫データをBigQueryで分析する方法を、Fivetran・trocco・Airbyte・Cloud Run内製・Stitch/Hevoの5パターンで費用比較。月0円〜月20万円まで、月商1,000万〜10億円規模のD2Cケースを想定した費用相場と、GraphQL calculated cost・Bulk Operations API・多店舗・多通貨・返品遅延・メタフィールドの実装落とし穴を整理した2026年版です。