データ分析

【2026年最新】GA4とBigQueryを連携する設定方法と基本活用術

2026/07/10

GA4とBigQueryを連携させる設定方法を、初心者でも理解できるよう丁寧に解説します。エクスポート手順・データ構造の読み方・基本SQLクエリ例まで、GA4分析を一段深めたい方に向けて網羅的にご紹介。

GA4の標準レポートを使い続けていると、「データ保持期間が短くて長期トレンドを追えない」「イベント単位で細かく掘り下げたいのに、集計済みの数値しか見られない」と感じる場面が増えてきませんか？そのような限界を一気に解消できるのが、GA4 BigQuery連携です。

この記事では、BigQueryの無料枠だけでプロジェクトを用意し、エクスポート設定を完了するまでの具体的な手順を解説します。あわせて、エクスポートされたGA4データの構造と実務で頻出するフィールドの読み方、コピペですぐ試せるSQLクエリのサンプルも紹介します。記事を読み終えれば、費用をほぼかけずに自社サイトの深掘り分析をその日から始められます。

1 GA4とBigQueryを連携させると何が変わるのか
2 BigQueryとは？マーケターが知っておくべき基本知識
3 連携を始める前に確認したい前提条件と費用の目安
4 GA4とBigQueryを連携する設定手順（ステップ別解説）
5 エクスポートされるGA4データの構造と主要フィールド
6 初心者でもすぐ使えるGA4データの基本SQLクエリ3選
7 BigQuery連携後に広がる実務活用シーン3選
8 あわせて読みたい
9 まとめ

GA4とBigQueryを連携させると何が変わるのか

GA4の標準レポートは手軽に分析を始めるには十分ですが、データ量が増えたり分析の要件が高まったりするにつれて、いくつかの壁にぶつかります。BigQueryと連携することで、その壁を根本から取り除けます。

GA4標準レポートでぶつかりやすい3つの限界

多くの担当者が経験する課題は次の3点です。

データ保持期間の上限GA4がユーザー単位のデータを保持できる期間には上限があります。標準プロパティのデフォルトは2か月、最長でも14か月までしか延長できないため、年度をまたいだトレンド分析や前年同月比の比較を行いたい場面で、過去データが参照できなくなる問題が発生します。
サンプリングの発生サンプリングとは、データ量が多いときに全件ではなく一部だけ抽出して集計する処理です。GA4の探索レポートではデータ量が増えるとサンプリングが発生し、実態と乖離した数値が表示されることがあります。
カスタム集計の制約標準レポートで使えるディメンション（分析の切り口）と指標の組み合わせには限りがあります。「特定ページを閲覧後に購入したユーザーの流入元を絞り込む」といった複合条件の集計は、標準機能では難しい場合がほとんどです。

BigQuery連携で広がる分析の可能性

BigQueryと連携すると、GA4が収集した全行動データをGoogleのクラウド上に保存し続けられます。主な変化は次の3点です。

データの無期限蓄積：エクスポート開始以降のデータがすべて保存されるため、長期のトレンド比較が可能になります。
サンプリングなしの全件集計：RAWイベントデータ（収集した生のデータ）に直接アクセスするため、精度の高い数値を得られます。
SQLによる自由な集計：SQL（データベースへの問い合わせ言語）を使えば、標準レポートでは難しかった複雑な条件での分析や、外部データとの組み合わせ分析も実現できます。

なお、GA4自体の初期設定がまだ完了していない場合は、GA4の初期設定手順を先に確認しておくと、この後の連携作業がスムーズに進みます。

BigQueryとは？マーケターが知っておくべき基本知識

BigQueryの役割をひと言で表すと

BigQueryは、Google Cloudが提供するクラウド上のデータ倉庫です。「データ倉庫（データウェアハウス）」とは、大量のデータをまとめて保管し、必要なときに自由な切り口で集計・分析できる仕組みを指します。

Excelやスプレッドシートは数万〜数十万行のデータ処理が限界になりやすく、GA4の標準レポートも画面上で選べる指標や期間に制限があります。一方BigQueryは、数億行規模のデータでも高速に処理できるため、サイトの全イベントログを丸ごと蓄積し、SQLで自在に集計することが可能です。SQLとは、データベースに対して「この条件でこう集計して」と指示するための問い合わせ言語で、プログラミング未経験でも基本的な読み書きは習得しやすい言語です。マーケターにとっては「大きなデータに対して使えるExcelの関数のようなもの」というイメージが近いでしょう。

GA4との相性が抜群な理由：イベントベース設計との親和性

GA4はページビューやクリックなど、ユーザーのあらゆる行動をイベントという単位で記録します。1回の訪問だけでも数十〜数百件のイベントが発生するため、データ量は膨大になりがちです。BigQueryはこのような大量の細かいイベントデータを効率よく格納・検索するために最適化されたカラム型ストレージ（列単位でデータを管理する構造）を採用しており、GA4のデータ構造と非常に相性が良い設計になっています。

さらに重要なのは、GoogleがGA4とBigQueryの連携機能を公式にサポートしている点です。サードパーティのツールを介さずにGA4管理画面から直接エクスポート設定ができるため、データの信頼性が高く、設定の難易度も比較的低く抑えられています。GA4がどのようなイベントデータを収集しているかについては、GA4のスコープとデータ構造の基本を合わせて確認しておくと、この後のSQL活用がよりスムーズになります。

連携を始める前に確認したい前提条件と費用の目安

設定を進める前に、必要な権限の確認と費用感の把握が重要です。権限が不足していると設定途中でブロックされるため、事前に整理しておきましょう。

必要なGoogleアカウントと権限の種類

GA4とBigQueryの連携には、次の2つの権限が必要です。

GA4プロパティ：「編集者」以上の権限
BigQueryプロジェクト：「オーナー」権限

加えて、BigQueryプロジェクト上でBigQuery APIを有効化しておく必要があります。社内で権限の管理担当が分かれている場合は、Google Cloud管理者と事前に調整を取っておきましょう。GA4プロパティの設定がまだ済んでいない方は、GA4の初期設定を先に完了させてください。

BigQuery Sandboxで無料スタート：無料枠の範囲と主な制限

BigQueryには、クレジットカード登録不要で始められる「Sandbox（サンドボックス）」プランがあります。無料で利用できる範囲は以下のとおりです。

項目	無料の上限
アクティブストレージ	毎月10GB
クエリ処理データ量	毎月1TB
テーブルの有効期限	デフォルト60日（期限後は自動削除）

月間PV数が数万〜数十万規模の中小サイトであれば、クエリ処理量が1TBを超えることはほぼなく、実質無料での運用が可能です。ただし、Sandboxではすべてのテーブルにデフォルトで60日の有効期限が設定されるため、長期データを蓄積したい場合は有効期限を手動で解除する必要があります。

なお、標準GA4プロパティからBigQueryへ1日にエクスポートできるイベント数の上限は100万件です。一般的な中小サイトでこの上限に達するケースはまれですが、イベントを大量に収集している場合は確認しておいてください。

有料プランに切り替わるタイミングと月額費用の目安

無料枠を超えた場合、またはBigQueryプロジェクトに請求先アカウントを紐づけた場合に有料プランへ移行します。料金はストレージ量とクエリ処理データ量に応じて発生しますが、料金体系は変更される可能性があるため、最新の単価はGoogle Cloudの公式料金ページで確認してください。

中小規模サイトの運用であれば、まずはSandboxの無料枠で分析を試すことを強くおすすめします。データ量や活用頻度が増えてきた段階で有料プランへの移行を検討するのが、コストリスクを抑えた現実的なアプローチです。

GA4とBigQueryを連携する設定手順（ステップ別解説）

設定はGA4管理画面とGoogle Cloud Console（GCC）の2か所で行います。手順通りに進めれば、30分程度で完了できます。なお、GA4管理画面のUI・メニュー名称は変更されることがあるため、実際の表示と異なる場合はGoogleの公式ヘルプも併せて確認してください。

ステップ1：Google CloudでBigQueryプロジェクトを作成する

Google Cloud Console（cloud.google.com）にアクセスし、GA4データの受け皿となるGCPプロジェクトを作成します。プロジェクトIDは一度設定すると変更できないため、サイト名や用途が伝わる名前をつけておくと後々の管理が楽です。プロジェクト作成後は、次のステップで使うプロジェクトIDを手元に控えておきましょう。

ステップ2：GA4管理画面でBigQueryリンクを設定する

GA4管理画面の左下「管理」をクリックし、プロパティ列にある「BigQueryのリンク」を選択します。「リンク」ボタンをクリックすると連携設定ウィザードが起動するので、以下の流れで設定を進めます。

BigQueryプロジェクトを選択：ステップ1で作成したGCPプロジェクトを選び「確認」をクリック
データロケーションを選択：データを保存する地域を指定します。ロケーションは設定後に変更できないため、自社の利用目的や法令要件に合わせて慎重に選択してください
エクスポートの頻度を選択：「毎日」または「ストリーミング」を選んで設定を完了

ステップ3：日次エクスポートとストリーミングエクスポートの違いと選び方

エクスポート頻度は「毎日（日次）」と「ストリーミング（リアルタイム）」の2択です。

項目	日次エクスポート	ストリーミングエクスポート
データ反映タイミング	翌日午前9時頃（日本時間）	ほぼリアルタイム
追加費用	なし	ストリーミングインサート料金が発生
初心者への推奨	◎ 推奨	△ コスト管理が必要

初めてBigQueryを使う場合は、日次エクスポートを選ぶのが鉄則です。 毎日深夜に前日分のデータが自動転送され、翌日の午前9時頃に events_YYYYMMDD 形式のテーブルが作成されます。リンク設定完了後、最初のデータがBigQueryに届くまで24時間以内を見込んでおいてください。

ストリーミングエクスポートはリアルタイム分析が必要な場面で効果を発揮しますが、ストリーミングインサートの料金が発生するためコストが高くなります。まず日次で運用を始め、リアルタイム性が必要と感じた段階で切り替えを検討しましょう。

エクスポートされるGA4データの構造と主要フィールド

BigQueryに届いたデータがどこにどう格納されているかを把握することが、SQLを正しく書くための出発点です。

BigQueryに作成されるテーブルの種類と命名規則

GA4のエクスポートデータは、analytics_123456789（末尾がGA4プロパティID）という名前のデータセットに自動生成されます。その中に作成される主なテーブルは以下の3種類です。

events_YYYYMMDD：日次エクスポートで毎日生成されるテーブル。当該日付から最長3日間のイベントが記録されます
events_intraday_YYYYMMDD：ストリーミングエクスポートで生成される当日分のテーブル。ユーザー初回取得時のトラフィックソース情報（traffic_source.name・traffic_source.source・traffic_source.medium）は含まれません。これらの値は日次テーブル（events_YYYYMMDD）でのみ安定して参照できます。なお、intraday テーブルは日次エクスポート完了後に自動削除されます。
pseudonymous_users_YYYYMMDD：user_idを持たないユーザーをuser_pseudo_idで識別して格納するテーブル

日常的な分析ではevents_YYYYMMDDを主に使います。日付部分を*でワイルドカード指定すると、複数日をまとめてクエリできます。

実務で必ず使う主要フィールド一覧（event_name・event_params・user_pseudo_id）

フィールド名	概要
`event_name`	イベントの種類を示す文字列（例：`page_view`、`purchase`）
`event_params`	イベントに紐づくパラメータ群。ARRAY型のネスト構造で格納される
`user_pseudo_id`	デバイス・クライアントIDをもとにGA4が割り当てる匿名ユーザー識別子
`ga_session_id`	セッションIDを示すパラメータ。`event_params`内に格納されている
`traffic_source.source`	流入元ソース（例：`google`、`direct`）
`traffic_source.medium`	流入メディア（例：`organic`、`cpc`）
`geo.country`	ユーザーの国情報

ネストされた繰り返しフィールド（ARRAY型）の読み方

event_paramsはARRAY型のネスト構造になっており、1件のイベントに紐づくパラメータの数だけ後続行に値が繰り返し格納されます。通常のSQLのようにSELECT event_paramsとそのまま指定しても値を取り出せないのはこのためです。

このネスト構造をフラットな行形式に展開するために使うのがUNNEST関数です。たとえばpage_locationパラメータを取得するには、UNNEST(event_params) AS epと記述した上でep.key = 'page_location'で絞り込みます。

パラメータの値はstring_value・int_value・double_value・float_valueの4列に分かれており、文字列パラメータはstring_value、数値パラメータはint_valueまたはdouble_valueを参照します。なお、GA4では float_value は現在のところ実データが格納されることはなく、実質的に使用されていません。浮動小数点の値は double_value に格納されます。

初心者でもすぐ使えるGA4データの基本SQLクエリ3選

以下の3クエリはBigQueryの無料枠（毎月1TBのクエリ処理）の範囲内で実行できます。★マークの箇所だけ自サイトの値に書き換えれば、そのまま動作します。テーブル名はBigQueryコンソール左側の「エクスプローラー」でプロジェクトを展開すると確認できます。

クエリ①：日別ページビュー数を集計する

page_viewイベントを日付でグループ化し、1日あたりのページビュー数を取り出します。_TABLE_SUFFIXは日ごとに分割されたテーブル（日付シャード）を期間で絞り込む書き方で、GA4のBigQueryクエリでほぼ必ず登場します。

sql
SELECT
  event_date,                    -- 日付（YYYYMMDD形式で出力）
  COUNT(*) AS pageviews          -- page_viewイベントの件数
FROM
  -- ★ YOUR_PROJECT と XXXXXXXX（プロパティID）を自サイトの値に変更
  `YOUR_PROJECT.analytics_XXXXXXXX.events_*`
WHERE
  -- ★ 集計したい期間に変更（YYYYMMDD形式）
  _TABLE_SUFFIX BETWEEN '20250101' AND '20250131'
  AND event_name = 'page_view'   -- ページビューイベントに絞り込む
GROUP BY
  event_date
ORDER BY
  event_date

クエリ②：コンバージョン（キーイベント）の発生数を確認する

GA4で設定したキーイベントを日別に集計するクエリです。キーイベント名はGA4管理画面の「イベント」一覧で確認できます。purchaseの部分をgenerate_leadやform_submitなど自サイトで計測しているイベント名に変更してください。

sql
SELECT
  event_date,                    -- 日付（YYYYMMDD形式）
  COUNT(*) AS conversions        -- キーイベントの発生件数
FROM
  -- ★ YOUR_PROJECT と XXXXXXXX（プロパティID）を変更
  `YOUR_PROJECT.analytics_XXXXXXXX.events_*`
WHERE
  -- ★ 集計期間を変更
  _TABLE_SUFFIX BETWEEN '20250101' AND '20250131'
  -- ★ 確認したいキーイベント名に変更
  AND event_name = 'purchase'
GROUP BY
  event_date
ORDER BY
  event_date

クエリ③：流入チャネル別のセッション数を比較する

session_startイベントのARRAY型フィールドからsource（流入元）とmedium（流入メディア）をサブクエリ形式のUNNESTで取り出します。この書き方はFROM句にUNNESTを書く方法と同じ意味を持ちつつ、SELECT句の中に閉じてコードをコンパクトにまとめられます。結果からorganic・cpc・referralといった流入経路ごとの傾向を把握できます。

sql
SELECT
  -- サブクエリ形式のUNNESTでARRAY型から値を取り出す
  (SELECT value.string_value
   FROM UNNEST(event_params) WHERE key = 'source') AS source,   -- 流入元（google など）
  (SELECT value.string_value
   FROM UNNEST(event_params) WHERE key = 'medium') AS medium,   -- 流入メディア（organic など）
  COUNT(*) AS sessions           -- セッション数
FROM
  -- ★ YOUR_PROJECT と XXXXXXXX（プロパティID）を変更
  `YOUR_PROJECT.analytics_XXXXXXXX.events_*`
WHERE
  -- ★ 集計期間を変更
  _TABLE_SUFFIX BETWEEN '20250101' AND '20250131'
  AND event_name = 'session_start'  -- セッション開始イベントに絞り込む
GROUP BY
  source, medium
ORDER BY
  sessions DESC                  -- セッション数が多い順に並べる

3つのクエリに共通して、_TABLE_SUFFIXで期間を短く設定するほど読み込むデータ量が減り、無料枠の消費を抑えられます。まずは直近1か月など短い範囲で試し、クエリが正しく動くことを確認してから集計期間を広げるのがおすすめです。

BigQuery連携後に広がる実務活用シーン3選

設定が完了し、SQLで基本集計ができるようになったら、次は実務での応用ステップです。BigQuery連携によって初めて実現できる活用シーンを3つ紹介します。

活用例①：14か月超のデータを蓄積して長期トレンドを分析する

GA4標準レポートのデータ保持期間には上限があります。一方、BigQueryへエクスポートしたデータはプロジェクト内に残り続けるため、連携を始めた時点から継続的に蓄積されます。1年以上のデータが揃えば、前年同月比の比較や季節変動の傾向把握など、標準レポートでは難しかった長期トレンド分析が可能になります。始めるのが早いほど蓄積量が増え、分析の精度も上がるため、連携設定は早めに済ませておくことをおすすめします。

活用例②：Looker StudioとつなぎGA4カスタムダッシュボードを構築する

Looker StudioはBigQueryを「カスタムデータソース」として直接接続できます。接続後はBigQueryのテーブルをソースに選択し、ディメンションと指標を自由にレポートへ配置するだけで、GA4標準レポートにはないカスタムビューを構築できます。SQLで作成した集計テーブルをLooker Studioに渡せば、役員向けの要約レポートや部門別ダッシュボードを低コストで整備することも可能です。Looker Studioの詳細な接続手順やデザイン設定は、ダッシュボード構築に特化した別記事を合わせてご参照ください。

活用例③：Google広告データと結合してROAS・CPA分析を深掘りする

Google広告のデータは「BigQuery Data Transfer Service（データ転送サービス）」を使ってBigQueryに取り込めます。GA4のイベントデータと広告のコスト・インプレッションデータが同一プロジェクト内に揃えば、SQLのJOINでキャンペーン・デバイス・地域などの粒度ごとにROAS（広告費用対効果）やCPA（獲得単価）を算出できます。GA4とGoogle広告を組み合わせた分析の全体像については、GA4とGoogle広告の連携設定・活用方法も合わせて確認しておくと理解が深まります。

まとめ

GA4とBigQueryの連携は、標準レポートでは解決しにくい「データ保持期間の上限」「サンプリング問題」「柔軟な集計粒度」という3つの課題を一気に解消する手段です。ここまで解説してきた内容を振り返ります。

GA4標準レポートの限界を超えられる：データ保持期間の制約やサンプリングの影響を受けずに、全イベントデータを蓄積・分析できる環境が整う。
無料枠から始められる：BigQuery Sandboxを利用すれば、クレジットカードの登録なしでエクスポートとクエリの基本操作を試せる。本格運用への移行も段階的に検討できる。
設定のハードルは低い：GA4管理画面からBigQueryリンクを作成し、日次エクスポートを有効にするだけで、翌日にはデータが届き始める。
データ構造の理解がSQL活用の鍵：event_name・event_params・user_pseudo_idなど主要フィールドとARRAY型のネスト構造を把握すれば、ページビュー集計・コンバージョン確認・チャネル別セッション比較といった基本分析をすぐに実行できる。
活用の幅は段階的に広げられる：Looker Studioとの接続によるダッシュボード構築、Google広告データとのJOINによるROAS・CPA分析など、スキルに合わせて発展させられる。

まず今日やることは、GA4管理画面の「BigQueryのリンク」設定画面を開き、日次エクスポートを有効にすることです。データが届くまでの間に、この記事で紹介したSQLクエリをBigQueryのクエリエディタに貼り付けて動作を確認しておくと、最初の分析がスムーズに進みます。完璧な準備を整えてから始めるより、まず小さく動かして感覚をつかむことが、BigQuery活用を定着させる最短ルートです。