BigQueryでGA4生データを触る最初の一歩（現場で何ができる？）

ℹ️ 本記事はアフィリエイトプログラム（一般社団法人ウェブ解析士協会）による収益を含みます。料金・制度は変わることがあるため、申し込み前に必ず公式サイトの最新情報をご確認ください（本記事は2026年7月時点）。

この記事のポイント

• GA4の管理画面では見えない領域（複雑なクロス集計・サンプリング回避・自由なセグメント抽出）を扱いたくなったら、それがBigQueryを検討するタイミング
• BigQueryへのGA4データエクスポートは無料枠内で始められるが、「エクスポートしただけで満足」「クエリは書けても数字の意味を誤読する」現場は非常に多い
• 生データを触る前に必要なのは高度なSQL力より、GA4のイベント・パラメータ構造とKPI設計の理解
• GA4講座（33,000円・税込）はBigQueryそのものは扱わないが、生データの前提になるGA4の見方を体系的に押さえられる
• 「なんとなくSQLが書ける」を「再現性を持って課題を切り分けられる」に変えるには、体系的な学習が近道

こんな場面、心当たりありませんか？

設定はしたが、誰も触れていない道具

「うちはBigQueryにGA4データをエクスポートしてます」という会社、最近本当に増えました。ただ、その先で止まっている現場を、私は広告運用のご相談の中でかなりの頻度で見かけます。

• エンジニアがBigQuery連携だけ設定して、あとは誰も触っていない
• Looker Studioでダッシュボードは作ったけど、GA4の管理画面と数字が微妙に合わず「どっちが正しいの？」と毎回聞かれる
• 「セグメントを自由に切って分析したい」と言われてBigQueryに触ってみたものの、テーブル構造が複雑すぎて心が折れた
• SQLは書けるようになったのに、出てきた数字がGA4のイベント定義とどう対応しているのか分からず、レポートに自信が持てない

これ、共通しているのは「ツールは用意されているのに、データの読み方が体系化されていない」という点です。BigQueryは強力な道具ですが、道具の使い方だけ覚えても、GA4のデータ構造やKPI設計の考え方が抜けていると、結局「なんとなく動くクエリ」で終わってしまいます。

この記事では、広告運用とアクセス解析を仕事にしている立場から、BigQueryでGA4生データを触る前に押さえておきたい考え方と、現場で踏み出せる最初の一歩を整理します。ウェブ解析士とは？資格の全体像・費用・取得ロードマップを保有者が解説もあわせて読むと、GA4・BigQueryを扱う前提となる資格体系がつかめると思います。

そもそもBigQueryとGA4はどう繋がっているのか

GA4には「BigQuery Export」という標準機能があり、GA4プロパティの設定画面からBigQueryプロジェクトをリンクするだけで、イベントデータが毎日（または任意でリアルタイムも）BigQuery側のテーブルに書き出されます。GA4の管理画面上に表示される集計済みの数値ではなく、ユーザーの行動を1イベント1行で記録した「生データ」が手に入るのが最大の特徴です。

無料枠の範囲内で始められるため、費用面のハードルは実はそこまで高くありません。ただし、エクスポートされたテーブルは日別に分かれ、1レコードごとにイベント名・パラメータ・ユーザープロパティがネスト（入れ子）構造で格納されています。ExcelやスプレッドシートのようなフラットなCSVとは違い、そのままではSELECT文一発で綺麗な表にならないのが、最初につまずくポイントです。

なぜGA4の管理画面だけでは限界がくるのか

GA4の標準レポートや探索レポートは非常によくできていますが、次のような場面では構造的な限界にぶつかります。

• 複雑な多段セグメント: 「特定の広告経由で流入し、初回セッションでLP Aを見て、7日以内に再訪してCVした人」のような条件を、画面操作だけで正確に切るのは難しい
• サンプリングの影響: データ量が多いプロパティでは、探索レポートでサンプリングがかかり、細かいセグメントほど数字がブレやすい
• 他データとの結合: 広告費データ、CRMの顧客データ、在庫データなどGA4の外にある情報と突き合わせたい場合、管理画面だけでは完結しない
• 長期の生データ保持: GA4の標準保持期間には制限があるが、BigQueryにエクスポートしておけば自分たちの意思で長期保存できる

これらは「GA4が使いにくい」のではなく、「GA4という計測ツールと、BigQueryという分析基盤は役割が違う」というだけの話です。この切り分けができていないと、「BigQueryを入れたのに管理画面と同じことしかできていない」という状態になりがちです。

現場で踏み出す「最初の一歩」——生データに触る前に押さえること

図1: 生データに触る前の5ステップの流れ

いきなりSQLの書き方から入ると挫折しやすいので、私がおすすめする順番は次の通りです。

1. GA4のイベント設計を先に理解する：どのイベントが自動収集され、どれがカスタムイベントとして送られているかを、GA4の管理画面（イベント一覧）で棚卸しする
2. 主要イベントのパラメータを把握する：page_location、session_source、ga_session_idなど、頻出パラメータの意味を押さえる
3. BigQuery側のテーブル名の規則を知る：events_YYYYMMDD（当日確定分）とevents_intraday_YYYYMMDD（当日未確定・リアルタイム分）の違いなど
4. SELECT * を1回叩いてみる：まずは1日分だけ、全カラムを見て構造に慣れる（データ量が大きい場合はLIMITを必ずつける）
5. 既存のGA4レポートの数字と、自分で書いたクエリの結果を突き合わせる：ここで初めて「集計ロジックの理解」が試される

正直に言うと、この5番目が一番大事で、一番地味です。SQLが書けることと、GA4の数字の作られ方を理解していることは別物で、両方揃って初めて「信頼できる分析」になります。

実際に見るべきテーブル構造とクエリの雰囲気

イメージを掴んでもらうために、ごく簡単なクエリの形を紹介します（実際のプロジェクトIDやデータセット名は各社の環境に合わせてください）。

SELECT
  event_name,
  COUNT(*) AS event_count
FROM
  `プロジェクトID.analytics_XXXXXXXXX.events_20260701`
GROUP BY
  event_name
ORDER BY
  event_count DESC

これだけでも「1日にどのイベントが何回発生しているか」が分かります。ここからevent_paramsをUNNEST（ネストを展開）してパラメータの中身を取り出したり、user_pseudo_id単位でユーザーの行動を追ったりしていくのが次のステップです。

→ → →

GA4標準レポート vs BigQuery分析：どっちを使うべきか

図2: GA4とBigQueryの使い分けを示す2択マトリクス

現場でよく聞かれる「結局どっちを使えばいいの？」という疑問に対しては、こう整理しています。

観点	GA4標準・探索レポート	BigQuery分析
導入のしやすさ	管理画面だけで完結、すぐ使える	エクスポート設定＋SQL学習が必要
定型のKPI確認	得意（セッション数・CVR等）	できるが手間がかかる
複雑な多段セグメント	サンプリングや操作の限界あり	得意（条件を自由に組める）
他データとの結合（広告費・CRM等）	基本的にできない	得意
長期のデータ保持	標準保持期間に制限あり	自分たちの設定次第で長期保存可
必要なスキル	ツール操作の理解	SQL＋GA4データ構造の理解
コスト感	無料	小規模なら無料枠内、大量クエリは課金対象

結論としては「日々のKPI確認はGA4標準レポート、深掘りが必要になったらBigQuery」という役割分担が現実的です。全部をBigQueryに寄せる必要はありません。

実務でどう活きるか——広告運用・LP改善の具体例

私自身、上級ウェブ解析士の講座でGA4・GTMを使った解析環境構築の考え方を学んだことが、実務でBigQueryのエクスポートデータを見るときの土台になっています。SQLの構文自体は書籍やドキュメントでも学べますが、「そのカラムが広告運用上のどの意思決定に繋がるのか」を判断する軸は、体系的にGA4を学んでいないと身につきにくい部分だと感じています。

具体的な活用シーンとしては、たとえば次のようなケースが考えられます。

• 広告とGA4の数字が合わない原因調査: 広告管理画面のコンバージョン数とGA4のコンバージョン数がズレているとき、BigQueryの生データまで降りると、どのセッションでイベントが発火し損ねているか、パラメータレベルで突き合わせられる
• LP改善のためのセグメント抽出: 「広告A経由・スマホ・初回訪問」のようなピンポイントな条件でユーザーの行動フローを追い、離脱ポイントを特定する
• レポーティングの自動化: 毎月手作業で集計していた指標をクエリ化し、Looker Studio等と組み合わせて自動更新の仕組みにする

こうした場面はどれも「SQLが書ける」だけでは足りず、「GA4がそのデータをどういう定義で計測しているか」を理解していることが前提になります。

つまずきやすいポイント・注意点

見えない分岐点でつまずく足元

正直な話として、BigQueryを触り始めた現場でよくあるつまずきも共有しておきます。

• クエリコストの見落とし: 無料枠を超えると課金対象になります。SELECT *で全カラム・全期間を毎回叩くようなクエリは、データ量が増えるとコストが跳ねやすいので注意が必要です
• UNNESTの理解不足: パラメータがネスト構造になっているため、UNNESTを使わないと欲しい値が取り出せません。ここでつまずいて離脱する人は多い印象です
• GA4の指標定義の誤読: 「セッション」や「エンゲージメント」の定義をGA4独自の基準で理解していないと、SQLで正しく集計しても解釈を誤ります
• 属人化: SQLを書ける1人だけが分析を回す状態になり、その人が抜けると誰も触れなくなる、というインハウス化の失敗パターンもよく聞きます

これらはどれも「技術的にできるかどうか」より「データの意味を理解しているかどうか」の問題です。だからこそ、BigQueryの操作を学ぶ前に、GA4そのものの見方を固めておく価値があると私は考えています。

「BigQueryまで手を出すのは意味ない？」への実態ベースの回答

「そこまでやる必要ある？」と聞かれることもよくあります。答えは、会社の規模とデータ活用のフェーズによります。

• 月間のトラフィックが少なく、GA4標準レポートで十分に意思決定できているなら、無理にBigQueryへ進む必要はありません
• 広告費が一定額を超え、複数チャネル・複数LPを運用していて「なぜこの数字なのか」を自分たちで検証したい段階になったら、BigQueryは十分に投資対効果が見合ってきます
• 「エンジニアに毎回頼まないと分析できない」状態を解消したい法人であれば、マーケ担当自身がGA4の構造とSQLの基礎を理解することが、内製化・属人化解消の第一歩になります

ここで大事なのは、BigQueryそのものを教える資格講座は今のところWACAにはない、という点です。ただしGoogleアナリティクス4講座（33,000円・税込・2026年時点）では、GA4の考え方・ユーザー解析・トラフィック解析・コンバージョン解析・探索レポート作成を体系的に学べます。BigQueryやGTM、Looker Studioそのものはカリキュラムに含まれませんが、BigQueryで生データを読み解く前提になる「GA4の見方」を固めるには適した内容です。

さらに一歩進んで、GA4のデータをもとに課題を発見し改善施策や提案書に落とし込む力をつけたいなら、上級ウェブ解析士とは？講座内容・費用・修了レポートを保有者が解説で紹介している上級ウェブ解析士講座（88,000円・税込・2026年時点）が近いです。GA4・GTMを使った解析環境構築の実践や、データからの改善提案の作り方を扱うカリキュラムで、BigQueryで出てきた数字を「で、どう動くか」まで落とし込む思考の土台になります。私自身、この講座で学んだ考え方が実務で今も効いていると感じています。

まだ資格自体に馴染みがない方は、先にウェブ解析士（初級）認定試験を徹底ガイド｜難易度・料金・勉強法で全体像を掴んでから検討するのも良い順番だと思います。

よくある質問

Q. BigQueryを使うのにプログラミング経験は必須ですか？ 必須ではありませんが、SQLの基礎（SELECT・WHERE・GROUP BY・JOINあたり）は避けて通れません。プログラミング未経験でも、SQLは比較的とっつきやすい言語なので、最初のクエリを写経するところから始める人が多い印象です。

---

Q. GA4講座を受ければBigQueryも使えるようになりますか？ いいえ。GA4講座（33,000円・税込・2026年時点）のカリキュラムにBigQuery・GTM・Looker Studインは含まれていません。GA4の考え方やユーザー解析・探索レポート作成が中心です。BigQuery自体の操作は別途SQLの学習が必要になります。誤解のないよう、公式サイトで最新のカリキュラムをご確認ください。

---

Q. 無料枠だけでBigQuery分析は完結できますか？ 小〜中規模のデータ量であれば無料枠内で運用できるケースは多いです。ただしクエリの書き方（SELECT *の多用など）によってはスキャン量が増えてコストが発生するため、規模が大きくなるほどクエリの最適化が必要になります。具体的な料金体系はGoogle Cloud公式で最新情報をご確認ください。

---

Q. マーケ担当がSQLを覚えるのと、エンジニアに任せるの、どちらが良いですか？ 役割分担の問題なので一概には言えませんが、「マーケ担当がGA4のデータ構造とKPI設計を理解した上で、簡単な集計クエリは自分で書ける」状態が、属人化を防ぎつつスピード感も保てるバランスだと感じています。複雑なパイプライン構築まではエンジニアに任せる、という分担が現実的です。

---

Q. ウェブ解析士の資格はBigQueryを扱う実務で役に立ちますか？ BigQueryの操作そのものを直接教える資格ではありませんが、GA4の指標定義やKPI設計、事業分析の考え方を体系的に押さえられるので、BigQueryで出てきた数字を正しく解釈し、施策提案に繋げる土台として役立ちます。とくに上級ウェブ解析士では、GA4データから課題を発見し改善提案に落とし込む実践的な内容を扱っています。

まとめ

BigQueryでGA4の生データを触ること自体は、無料枠の範囲で誰でも始められます。ただ、SQLの書き方だけを覚えても、GA4のイベント定義やKPI設計の理解が抜けていると、「動くけど信頼できない分析」で終わってしまいがちです。まずはGA4のイベント・パラメータ構造を棚卸しし、既存レポートの数字と自分のクエリを突き合わせる、という地道な一歩から始めるのが結局は近道だと感じています。

その土台作りとして、GA4の考え方を体系的に学びたい方はGoogleアナリティクス4講座の公式ページで最新の日程・料金を確認してみてください。もう少し実務寄りに、GA4データから改善提案まで落とし込む力を身につけたい方や、社内のデータリテラシーを底上げしたい法人の担当者の方は、上級ウェブ解析士講座の内容も合わせて検討する価値があると思います。まずは無料のオープンセミナーで雰囲気を確認してから申し込む、という進め方も無理がなくおすすめです（詳細はWACA公式サイトでご確認ください）。

管理画面とクエリの数字が合わないときに確認すること

「最初の一歩」の5番目で既存レポートとクエリの結果を突き合わせると、まず数字は合いません。ずれ自体は珍しくないので、次の順番で原因を切り分けるのが現実的かなと思います。

• 日付の区切り方：event_date はプロパティのタイムゾーンで記録されますが、event_timestamp はUTCのマイクロ秒です。timestampで日付を切ると、日本時間とは9時間ずれた集計になります
• セッションの数え方：生データに「セッション」という行はありません。user_pseudo_id と ga_session_id を組み合わせて数えるのが一般的です。また、GA4の管理画面ではユーザー数やセッション数に近似的な集計が使われていると公式ヘルプで説明されているので、完全一致しないのは前提と考えたほうがいいと思います
• 流入元のフィールド：traffic_source はユーザーを最初に獲得した流入元で、セッションごとの流入元ではありません。ここを取り違えると、広告別の数字が大きく狂います。セッション単位で見たいなら、イベントパラメータの source / medium や、新しく追加されたセッション用のフィールドを確認してください
• 同意モード・しきい値：管理画面側にはモデリングやデータしきい値がかかることがあり、生データとは前提が違います
• 確定のタイミング：日次テーブルは遅れて届くイベントで後から更新されることがあります。直近数日分で突き合わせると合いにくいです

判断の目安は、ずれの「方向と大きさ」が毎日安定しているかどうかです。安定しているなら定義の違い、日によってばらつくなら計測や集計ロジックの問題、と見当をつけやすくなります。

UNNESTとコスト管理を両立させるクエリの型

つまずきポイントで触れたUNNESTとコストは、実は同じクエリの書き方でまとめて対策できます。最初はこの形をひな形にしておくと安全かなと思います。

SELECT
  event_date,
  (SELECT value.string_value FROM UNNEST(event_params)
     WHERE key = 'page_location') AS page_location,
  COUNT(*) AS page_views
FROM
  `プロジェクトID.analytics_XXXXXXXXX.events_*`
WHERE
  _TABLE_SUFFIX BETWEEN '20260701' AND '20260707'
  AND event_name = 'page_view'
GROUP BY
  event_date, page_location
ORDER BY
  page_views DESC

ポイントは3つです。

1. events_* と _TABLE_SUFFIX で期間を絞る：テーブルが日別に分かれているので、ここで絞らないと全期間を読みにいきます
2. SELECT * ではなく必要な列だけを書く：BigQueryは読んだ列の量で課金されます。LIMITを付けても読み込む量は基本的に減らないので、LIMITはコスト対策ではなく「表示を短くするもの」と考えたほうがいいです
3. パラメータの型を確認する：page_location は string_value ですが、ga_session_id は int_value に入っています。型を間違えると、エラーにならずにNULLが返ってくるので気づきにくいです

加えて、BigQueryのコンソールでは実行前に「このクエリで処理されるデータ量」が表示されます。実行ボタンを押す前にここを見る習慣をつけるだけで、想定外の課金はかなり防げると思います。プロジェクト単位で1日あたりのクエリ量に上限を設定できるので、社内で複数人が触るなら最初に設定しておくと安心です。

最初の1か月で整えておくと、属人化しにくくなるもの

クエリが動くようになったら、分析の量を増やす前に次の3つを整えておくと、後から効いてくると思います。

• 指標の定義メモ：「セッション＝user_pseudo_id×ga_session_id」「CV＝このイベント名」など、クエリで使った定義を1枚にまとめておきます。管理画面との差分の理由もここに書いておくと、「どっちが正しいの？」と聞かれたときにすぐ答えられます
• 保存済みクエリの共有：個人のエディタにだけ残すのではなく、プロジェクト内で共有する形で保存しておきます
• 中間テーブル化の判断：同じUNNESTを何度も書くようになったら、よく使う列だけを展開した表をスケジュールクエリで毎日作るタイミングです。Looker Studioからはこの中間テーブルを参照するようにすると、表示のたびに生データを読みにいかずに済むので、コストの面でも有利です

なお、クレジットカードを登録しない「サンドボックス」で始めた場合は、テーブルが一定期間で自動的に削除されるなどの制限があります。長期保存を目的にしているなら、どこかの段階で課金アカウントに切り替えることになるので、最初にGoogle Cloud公式で条件を確認しておくのがいいかなと思います。

クエリを書く前に、エクスポート設定そのものを確認しておく

SQLより手前の「設定と権限」で止まるケースも多いので、最初に次の点を見ておくと手戻りが減ると思います。

• データはリンクした日からしか溜まらない：BigQuery Exportは過去分を遡って書き出してくれません。「去年と比較したい」と思った時点でリンクしても、去年のデータは入っていないので、分析の予定がなくても先にリンクだけ済ませておく価値はあるかなと思います
• 日次とストリーミングのどちらが有効か：GA4の管理画面の「BigQueryのリンク」で確認できます。ストリーミングは別途料金がかかる仕組みなので、当日の数字を急いで見る用途がなければ、日次だけでも十分なことが多いと思います
• 日次エクスポートの上限：標準プロパティには、日次エクスポートできるイベント数に上限があると公式ヘルプに書かれています。イベント数が多いサイトは、不要なイベントをエクスポート対象から除外する設定も検討したほうがいいです
• データのロケーション：リンク時に選んだロケーションは、後から変更しにくい項目です。広告費など他のデータと結合する予定があるなら、同じロケーションに揃えておかないと結合できません
• 権限：データセットは見えるのにクエリが実行できない場合、データの閲覧権限はあっても、ジョブを実行する権限が付いていないことが多いです。エンジニアには「閲覧」と「ジョブ実行」の両方を依頼すると話が早いと思います

広告費は生データに入っていない——突き合わせるときの考え方

見落としやすいのですが、GA4のエクスポートには広告費・表示回数・クリック数が入っていません。CPAやROASを出したい場合は、広告側のデータを別に用意して結合することになります。

• Google広告：BigQuery Data Transfer Serviceで、広告のレポートデータを別のデータセットに取り込めます。GA4側のテーブルとは別物なので、結合キーを自分で決める必要があります
• その他の媒体：媒体のレポートをスプレッドシートやCSV経由でBigQueryに入れる形が現実的です。この場合、GA4側と繋がるのはUTMパラメータだけなので、utm_campaign の命名規則が揃っていないと結合できません。SQLより先に、入稿時の命名ルールを決めるほうが効くと思います

結合の粒度は、最初は「日付×キャンペーン」で止めておくのがおすすめです。広告グループやCR単位まで細かくすると、GA4側でパラメータが欠けている行が増えて、合計が広告管理画面と合わなくなりやすいからです。まずキャンペーン単位で合計の整合を確認して、合うことが分かってから粒度を下げる、という順番が安全かなと思います。