競合と同じ戦略を抜け出す|BigQueryだけが解く3つの経営課題

この記事は「競合と同じデータの見方をしているうちは、競合と同じ戦略にしか辿り着けない」という構造を抜け出したい経営者のためのものです。

有料ツールで解決できる課題なら、有料ツールを使ったほうが早い。UIも使いやすく、業界の共通語で社内・代理店・取引先と会話できます。既に有料ツールを使っている会社が、わざわざBigQueryに乗り換える理由はほとんどありません。

ただし例外が3つある。有料ツールを重ねていっても構造的に解けない経営課題が存在します。本記事はその3つの経営課題と、BigQueryがどのようにそれを解くかを扱う。機能の話は後半にまとめいます。まず「自社に関係があるか」を見極めてから読み進めてほしい。

経営課題A: 競合と同じ情報源を使っているうちは、競合と同じ戦略にしか辿り着けない

業界共通ツールが出す数字は、競合も同じツールを使えば同じ数字を見ることになります。これは差別化の源泉にはなりません。

有料ツールの本質は「業界の共通語を提供すること」です。Mixpanelのリテンションカーブ、SalesforceのLTV算出式、Ahrefsのキーワードボリューム、GA4のCPAやCVR。

これらはどれも業界共通の指標であり、競合企業も同じツールを使えば同じ数字を見います。同じ指標を同じ形で見ている限り、同じ仮説が生まれ、同じABテストが回り、同じ改善幅が出て、同じ結論に辿り着く。

これは「業界平均で戦う」ことを前提にした道具であり、差別化の源泉にはなりません。ベンチマークとして優秀であることと、競合との差別化に使えることは別の話です。

ベンダーが自社固有の問いを実装しない構造的理由

有料ツールのベンダーは「多くの顧客に使われる機能」しか実装しません。これはビジネスとして合理的な判断だが、結果として「自社固有の切り口」は実装されにくい構造になります。

自社がベンダーに機能追加を依頼しても、「他の顧客にも共通するニーズかどうか」で判断されます。そのため、自社の個別事情に合わせた分析軸は後回しになりやすいです。

BigQueryは同じ原材料から自社だけの料理を作る道具

BigQueryの本当の価値は、この制約を外せる点にある。生データとSQLを使えば、ベンダーが用意した分析メニューに縛られず、自社が思いついた切り口をその場で検証できます。

競合も同じGA4やSearch Consoleの生データを持っているが、そこからどの角度で切り出すかは各社の判断に委ねられます。同じ原材料から自社だけの料理を作る道具、と言い換えてもよい。

これは「機能の優劣」ではなく「競争戦略上の立ち位置」の問題です。業界平均で戦うか、自社だけの勝ち筋を探すか。その経営判断そのものが、BigQueryを使うかどうかの分岐点になります。

経営課題B: 自社にしかない問いに、自社で答えられる意思決定力を組織に持つ

本当に経営を動かす問いは「業界共通ではない自社にしかない問い」です。有料ツールの標準機能には構造的に実装されない領域で、自社で答えを出す組織能力が必要になります。

有料ツールは「業界共通の問い」に「業界共通の答え」を出すために設計されいます。一方、本当に経営を動かす問いは、多くの場合「自社にしかない問い」です。

自社にしかない問いの例

• 商品Aと商品Bを両方見たユーザーの受注率は、片方だけ見たユーザーの何倍違うのか
• 新商品をリリースした日を境に、既存顧客の離脱は加速したのか、新規獲得だけが増えたのか
• 創業ストーリーページを読んだ人と読まなかった人で、その後の購入単価はどう違うのか
• 休眠リードが特定のコラム記事を再訪した瞬間にアプローチすると、商談化率は何倍になるのか
• 先週のメルマガを読んだ人のうち、実際に商品ページまで来た人は、他流入と比べて滞在時間が長いのか短いのか

これらは「業界共通」ではない。だから有料ツールの標準機能には実装されにくい。ベンダーに機能追加を依頼しても、自社以外にも同じニーズがある顧客が一定数いなければ優先度は上がりません。自社固有の問いに答えが出るまでの時間は、長くなりがちです。

自社の問いを自社で解く組織への転換

BigQueryは「自社の頭で立てた問いを、自社のデータで検証できる」という組織能力を提供します。SQLを書ける人が社内に1人いれば、新しい問いが生まれたその日のうちに検証結果を出せる。

ダッシュボードを眺めるだけの組織から、自社の問いを自社で解く組織への転換を、ここで選ぶことになります。

有料ツールを重ねていくと、むしろこの能力は失われやすいです。UIで操作するうちに、「ツールが出してくれる範囲の問い」しか立てなくなるためです。自社の問いを問う習慣そのものが、有料ツール依存によって衰退する構造的なリスクがあります。

経営課題C: 代理店・ベンダー依存から脱却し、提案の妥当性を自分で検証できる経営になる

代理店やベンダーの月次レポートの妥当性を自社で独立検証できないと、間違った提案に気づくまで半年かかります。BigQueryがあれば1週間で気づける。

多くの会社は、広告代理店、SEO業者、ツールベンダーの月次レポートを見て意思決定しいます。この構造には構造的な弱点があります。

代理店が出す数字と改善策の妥当性を、クライアント側が独立して検証できませんことです。

代理店が自分の成績に都合の良い数字を選ぶ構造

たとえば代理店が「このキーワードに広告費を増やしましょう」と提案した時、その妥当性は代理店のレポートだけでは判断できません。代理店側には自分の成績に都合の良い数字を切り出す動機が働く場合があります。

これは悪意ではなく、報告者が自分の評価に影響する数字を選ぶという構造上の問題です。

有料ツールに依存しているうちは、この構造問題から抜けられません。ツールが出す数字の計算式は、ベンダー側の設計に閉じいます。計算式の前提や除外条件を自社で変えることは、基本的にできません。

結果として、ベンダーの設計した視点でしか自社を見られない状態になります。

半年後に気づくか、1週間で気づくか

BigQueryを持っている会社は、代理店レポートと並行して自社で独立した分析ができます。「その広告費追加は、LTVベースで見て本当に利益が出ているのか」「改善策の根拠となっているデータは、正しくセッション単位で追えているのか」を自分で確認できます。

間違った提案に半年間お金を払い続けて気づくのか、1週間で気づくのか。その差が年間のマーケティング投資の成果を決める。

これは「外部ベンダー依存から脱却し、自社の判断力を取り戻す」という経営課題です。有料ツールを使い続けることは、構造的にベンダーの分析視点に依存し続けることを意味します。

3つに共通する本質: 答えを出す道具ではなく、答えを出せる組織能力

3つの経営課題に共通するのは「答えを出す道具」ではなく「答えを出せる組織能力」という視点です。BigQueryはその組織能力を取り戻すための装置と位置付けると正確になります。

経営課題A・B・Cに共通するのは、「答えを出すための道具」ではなく「答えを出せる組織能力」という視点です。

有料ツールは「業界共通の答え」を会社に渡すが、「自社の問いに自社で答える能力」までは渡しません。むしろ依存が深まるほど、その能力は衰退しやすいです。

BigQueryは、この組織能力を取り戻すための装置と位置付けるのが正確です。SQLを書ける人が社内に1人いれば、あらゆる新しい問いに自力で答えられる状態に近づく。

道具そのものではなく、道具を通じて獲得する組織能力が本当の資産になります。

他社が真似できない意思決定を、自社のデータから導ける組織になります。この経営課題だけは、有料ツールでは構造的に解決しにくいです。

コストとスイッチングコストについて

BigQueryのトータルコストは既存有料ツールと大差ありません。判断基準は価格ではなく、業界平均で戦うのか差別化を目指すのかという経営判断です。

BigQueryのクエリ課金自体は安いです。しかし現実には、SQLを書ける人材の確保、継続的なメンテナンス、スクリプトの保守、ダッシュボードとの連携まで含めたトータルコストは、決して無視できる金額ではありません。

既存の有料ツールと比較した場合、トータルコストで明確に安いとは言い切れません。

さらに、既に有料ツールを導入している会社にとってはスイッチングコストもあります。社内の運用フローを変え、代理店との報告形式を変え、従業員のリテラシーを一段上げる必要があります。これらは見えにくいが大きなコストです。

価格ではなく、競争ポジションで判断する

この現実を踏まえた上で、次の問いを自問してほしい。業界平均で戦い続けることを選ぶのか、それとも競合と差をつけるために組織の分析能力そのものを強化することを選ぶのか。

前者で十分なら、有料ツールを使い続ければよいです。後者を目指すなら、スイッチングコストは「差別化のための先行投資」に変わります。

判断基準は価格ではなく、経営としてどの競争ポジションを取るかです。

記事の後半では、技術的な話(GA4管理画面との違い、計測設計、実例SQL、よくある落とし穴)を扱う。ただしそれらは「組織能力を獲得するための手段」であり、目的ではありません。まず上記の経営課題が自社に当てはまるかを見極めた上で読み進めてほしい。

SQLが書ける人材がいない企業はどうするか

2025年以降、Claude CodeやAntigravity等のAIエージェントが日本語の問いをSQLに自動変換します。SQL人材の有無は導入判断の前提条件ではなくなりました。

BigQueryを導入する上での最大のハードルは、長年「SQLを書ける人材が社内にいなければ運用できない」という点でした。毎回の問いが生まれるたびに、SQLを書ける人にその問いを伝え、クエリを作ってもらい、結果を待つ。このリードタイムが長ければ、仮説検証のサイクルは回らず、結局「有料ツールのダッシュボードを眺めていた方が早い」という結論になっていました。

しかし、このハードルは2025年以降、AIエージェントの実用化によって大きく変わりました。Claude Code、Antigravity、ChatGPTのData Analyst等のAIエージェントは、日本語で立てた問いをSQLに自動変換し、BigQuery上で実行し、結果を日本語で返す。「商品Aと商品Bを両方見たユーザーの受注率を調べたい」と自然文で伝えれば、数十秒〜数分でSQLが書かれ、結果が出る。SQLを書ける人を介さずに、マーケティング担当者や経営者が直接BigQueryを操作できる状態になっいます。

AIで運用するBigQueryの具体的な流れ

• 日本語で問いを書く: 「先月と比べて離脱率が上がったページはどれか、ランキングで出して」
• AIエージェントがスキーマを読み取り、SQLを自動生成する
• BigQuery上で実行され、数十秒で結果が返る
• AIが結果を日本語で要約し、次に考えるべき仮説まで提案する
• 追加の問いがあれば、さらに日本語で続ければよい

この流れは、SQLを書ける人材の有無とは無関係に成立します。必要なのは「問いを立てる能力」と「AIとの対話の進め方」だけです。技術的な壁は下がり、代わりに「自社のビジネスに対して、どれだけ鋭い問いを立てられるか」という本来の課題に集中できるようになります。

当社が提供する導入支援

当社はこのAIエージェント方式でのBigQuery運用を、クライアントへの導入支援として提供しいます。具体的には以下の流れで進める。

• GA4 BigQuery Exportの有効化(作業時間は数分)
• Search Console Bulk Data Exportの有効化
• AIエージェント(Claude Code、Antigravity等)とBigQueryの接続設定
• クライアント固有の「よくある問い」のテンプレート整備
• 初回レクチャー: 日本語で問いを立てる練習、結果の読み取り方、次の問いへの繋げ方
• 月次レビューで仮説検証のサイクルを並走

この方式により、社内にエンジニアがいないクライアントでも、マーケティング担当者や経営者が直接BigQueryに問いを投げて、その場で答えを得られる状態を作っいます。実際に、当社が支援している企業の中には、SQLを書ける人材が1人もいない状態からBigQueryの本格活用を始め、週次で自社固有の問いを検証するサイクルを回しているケースがあります。

BigQueryを使うための前提条件は「SQLを書ける人」ではなく「鋭い問いを立てられる人」です。後者は技術者ではなく経営者とマーケティング担当者の領域にある。

「BigQuery=SQL人材が必要」という従来の前提は、AIエージェントの実用化によって崩れました。現在の意思決定軸は「SQL人材を確保できるか」ではなく「自社のビジネスにどれだけ鋭い問いを立てられるか」に移っいます。後者は、技術者ではなく経営者とマーケティング担当者の領域です。ここにこそ、BigQuery×AIエージェント運用の真価があります。

BigQueryに対するよくある誤解

「設定が難しい」「高い」「使いにくい」等の6つの懸念の大半は、2025年以降のAIエージェント実用化と公式無料エクスポートの整備で既に解消されいます。

BigQueryという言葉を聞いた瞬間に、多くの経営者とマーケティング担当者が無意識に抱く懸念があります。これらの懸念は、かつては正しかった部分もあるが、2025年以降のAIエージェントの実用化によって大半が解消されいます。以下6つの代表的な誤解と、その現在の実情を並べる。

よくある誤解	現在の実情
設定が難しい	GA4管理画面で「BigQueryリンク」を1箇所ONにするだけで連携は完了します。作業時間は数分。Search Console Bulk Data Exportも管理画面から数クリックで有効化できる
高い	GA4エクスポートとSearch Consoleエクスポート自体は無料。中規模サイト(月30万PVまで)のクエリ課金は無料枠(月1TB)内に収まる。データ保存料金も中規模なら月数ドル以内
当社には関係ない	BigQueryが関係するのは「競合と同じ情報源で戦うのを止めたい会社」です。逆に業界平均で戦うだけで十分な会社には不要。この判断は売上規模や業種ではなく、競争戦略の選び方で決まる
GA4の管理画面で十分	GA4管理画面はサンプリング、しきい値による非表示、カーディナリティの「(other)」集約、14ヶ月の保持期間制限があります。これらに該当しない小規模サイトならGA4で十分だが、該当する段階で管理画面の数字は実数から乖離していく
大量のトラフィックがないサイトでは必要ない	大量のトラフィックがないサイトほど、1件1件のCVデータが貴重です。少ないサンプルを正確に追えるかどうかで判断の精度が変わります。逆に大量データでは管理画面のサンプリングで近似値になるため、BigQueryの必要性はむしろ中小規模サイトで高い
使いにくい(SQLが書けないと触れない)	2025年以降、Claude CodeやAntigravity等のAIエージェントを使えば、ChatGPTを使う感覚で日本語の問いを書くだけで自動的にSQLが生成・実行されます。SQL人材がいない会社でも使える状態になっている

6つの誤解に共通する構造

6つの誤解のうち、「設定が難しい」「高い」「使いにくい」の3つは技術的な懸念です。これらは数年前までは確かに正しかったが、2025年以降のAIエージェントの実用化と、Google側の無料エクスポート機能の整備によって大半が解消されいます。

残る3つ「当社には関係ない」「GA4で十分」「大量のトラフィックがないサイトでは必要ない」は、BigQueryの本質を「機能」として捉えているために生まれる誤解です。BigQueryは機能ではなく「自社固有の問いに答える組織能力」を獲得する装置である、という視点に立ち直すと、業態や規模の話ではなく、競争戦略としてどこを目指すかの話に変わります。

有料ツールより使いやすい側面もある

一点補足しておくと、AIエージェント経由でBigQueryを使う運用は、有料ツールのダッシュボードよりも使いやすい側面があります。有料ツールはベンダーが用意したUIの範囲内でしか操作できず、ドロップダウンメニューとチェックボックスで表現できる問いしか立てられません。一方、AIエージェント経由のBigQueryは、日本語の自由な文章で問いを立てられます。

たとえば「先週のメルマガを開封した人のうち、3日以内に商品ページを再訪したユーザーの割合を、新規と既存で分けて、さらに滞在時間の中央値も出して」という問いを、有料ツールのUIで操作できるかを想像してほしい。大半のツールでは、この1つの問いのために複数のレポートを切り替え、エクスポートしたCSVを手動で結合する必要があります。AIエージェント経由なら、この文章をそのまま貼るだけで数十秒で答えが返る。

「BigQuery=難しい道具」という旧来のイメージは、実態とかけ離れつつある。現在の正しい捉え方は「BigQuery+AIエージェント=ChatGPTに日本語で質問する感覚で、自社のあらゆるデータに問いを投げられる環境」です。

データの流れとGA4との関係

同じGA4イベントでも、管理画面(サンプリングあり)とBigQueryエクスポート(生データ)で見える中身が違います。この章で分岐点を整理します。

ユーザーがサイト上で行動（クリック、閲覧、購入等）すると、そのデータはGA4の収集サーバーに送られます。ここで分岐が起きる。

GA4の管理画面（UIレポート）は、生データを集計・加工して表示します。このときサンプリングやしきい値による非表示が発生します。一方、BigQueryエクスポートは生データを1行も漏らさず保存します。サンプリングもしきい値もありません。

GA4の管理画面では見えないもの

サンプリング、しきい値、カーディナリティ、14ヶ月の保持期間。GA4管理画面の4つの制約は、BigQueryエクスポートでは全て外れます。

項目	GA4管理画面	BigQuery
サンプリング	データ量が多いと一部だけで計算して全体を推定	全データで正確に計算
しきい値	少人数データは非表示になる	全データが見える
カーディナリティ	ユニーク値が多すぎると「(other)」にまとめられる	全値が個別に記録
期間の精度	固定選択またはカスタム	SQLで日単位・時間単位で正確に指定
データ保持期間	最大14ヶ月（デフォルト2ヶ月）	無制限

Search Consoleの場合

項目	Search Console管理画面	BigQuery連携
データ粒度	クエリxページの組み合わせに上限（上位1,000件）	全クエリx全ページの組み合わせ
GA4との結合	不可	URLをキーにGA4のCVデータと結合可能
保持期間	最大16ヶ月	無制限

集計データと生データの違い

集計データでは「何回見られたか」までしか分かりません。生データがあって初めて「誰が、どの順番で、何を見て、最後にどうしたか」が追える。

集計データで見えるもの（GA4管理画面）

日付	ページ	アクセス数
4月7日	/column/about_aeration	15回
4月7日	/contact-simple	3回

「この日に何回見られたか」は分かるが、それ以上の分析はできません。

生データで見えるもの（BigQuery）

時刻	行動
14:23:05	コラム記事Aを閲覧
14:25:18	コラム記事Bを閲覧
14:27:30	資料ダウンロード一覧ページに遷移
14:28:45	資料請求フォームに遷移
14:30:10	フォーム送信完了

生データがなければ答えられない問いがあります。「フォーム送信した人は、送信前にどのコラムを読んでいたか」「特定のコラムを読んだ人は、その後フォームに到達しやすいか」「同じ人が複数回サイトを訪問して、何回目にフォーム送信したか」「コンバージョンに至るユーザーの行動パターンTOP5は何か」。いずれも集計データでは追跡できません。

BigQueryだからできる分析

行動シーケンス、コホート、ファネル、CVに至る行動パターンTOP5、異常検知。GA4管理画面では不可・または近似値でしか出せない分析が、BigQueryなら全ユーザーを正確に追って出せる。

分析	GA4管理画面	BigQuery
ユーザーの行動シーケンス分析	探索レポートで部分的（サンプリングあり）	全ユーザーを正確に追跡
CVに至るユーザー行動パターンTOP5	不可	生データからパターン化・ランキング
コホート分析（初回訪問月別リピート率）	標準レポートで概算	正確なコホート分析
カスタムファネル定義	探索レポート（サンプリングあり）	SQLで自由にファネル定義
他データソースとの結合	不可	GA4 + Search Console + CRMを結合
異常検知・アラート	不可	定期監視でCV急減を即座に検出

当社の実績では、同一期間でGA4管理画面とBigQueryの数値を突合した結果、総収益に約5%の差異が発生した事例があります。月間売上3,000万円のサイトであれば、年間約210万円の差異になります。経営判断やマーケティング投資の精度に直結する数字です。

CRM連携で「売上」まで追跡する

GA4とBigQueryだけでは「フォーム送信」までしか見えません。CRMを連携すると、サイト訪問から商談・受注・売上までを一本の線で追跡できるようになります。

GA4とBigQueryで追跡できるのは「誰がフォームを送信したか」まで。その先の商談、見積提出、受注、売上といった営業活動のデータはWebでは取得できません。CRMのデータをBigQueryに連携することで、「サイト訪問→ページ閲覧→問い合わせ→商談→受注→売上」の全行程を一本の線で追跡できるようになります。

CRM連携で可能になる分析

分析内容	活用例
流入経路別の売上貢献	「オーガニック検索からの問い合わせは受注率が高い」「広告経由は受注単価が大きい」など、売上に直結する流入経路を特定
CV種別ごとのROI計算	問い合わせ、資料請求、電話のどのCV種別が売上につながりやすいかを比較
コンテンツ別の売上貢献	「どのコラムを読んだユーザーが受注に至りやすいか」を特定し、高CVRコンテンツの横展開に活用
リードタイム分析	初回問い合わせから受注まで平均何日かかるかを把握

対応しているCRM

CRM	BigQuery連携方法
ZOHO CRM	n8n / Airbyte / REST API V8
Salesforce	Connected Sheets / Fivetran / Airbyte
HubSpot	HubSpot BigQuery Connector / Airbyte
kintone	CData / n8n経由

段階的な導入ロードマップ

BigQueryの価値を引き出すには段階設計が必要です。Phase 1の計測基盤が崩れると、後に積み上げた分析は全て「間違ったデータに基づく間違った結論」になります。

フェーズ	内容	期間	何ができるようになるか
Phase 1	計測基盤の検証と整備	1～2ヶ月	全ての分析の土台。ここが崩れると後の全てが台無しになる
Phase 2	CROファネル分析と改善施策の実行	1～2ヶ月	離脱ポイントの特定と改善
Phase 3	Search Console連携 + CTR分析	1～2週間	SEO施策の効果測定
Phase 4	CRM連携	2～4週間	Webの先の「売上」まで追跡

Phase 1が最も重要です。計測基盤の設計にミスがあると、その上に積み上げた全ての分析が「間違ったデータに基づいた間違った結論」になります。GTMのタグが二重発火していれば、CV数が実数の2倍に見える。イベントの定義が曖昧であれば、BigQueryに蓄積されるデータ自体が汚染されます。

Phase 1の成果物

• GTMタグ棚卸し一覧（全タグ、トリガー、変数のステータス）
• CV定義書（全CV地点のイベント名、トリガー条件、パラメータ一覧）
• BigQuery突合レポート（GA4 vs BigQueryの数値比較表）
• 異常検知スケジュールクエリ（日次の自動監視設定）

これらが揃って初めて「このデータは信頼できる」と言える。

実務で遭遇する落とし穴（当社実績）

実プロジェクトで起きた5つの問題と解決方法。いずれも「BigQueryにデータがある」ことと「分析ができる状態」は別物だという教訓に収束します。

以下は実際のプロジェクトで発生した問題と、その解決方法です。Phase 1の工程を省略した場合に起きることの具体例でもあります。

外部フォームサービスのCV計測が動かない

JotForm、Typeform、GoogleFormなどの外部フォームサービスをiframeで埋め込んでいるサイトでは、フォーム送信完了時にdataLayer.pushが発生しません。通常のGTMトリガーではCVを検知できません。postMessageによるCV検知を試みたが失敗し、最終的に「フォーム送信後にサンクスページにリダイレクトする設定」で解決しました。外部フォームを使っているサイトでは、Phase 1で必ずこの検証が必要になります。

Next.js/SPAサイトでGTMが発火しない

Next.jsやReactで構築されたSPA（Single Page Application）では、ページ遷移がブラウザのフルリロードではなくJavaScriptによる画面書き換えで行われます。このため、通常の「ページビュー」トリガーが発火しません。GTMのトリガーを「ページビュー」から「History Change」に変更することで解決しました。

BigQueryに連携できないデータソース

Microsoft ClarityはBigQueryへの詳細データエクスポートが公式サポートされていません。日別サマリー（9行程度）しか取得できず、ヒートマップやセッション録画のデータはClarityの管理画面で直接見るしかありません。BigQueryに全てのデータを集約できるわけではなく、Clarityのヒートマップ分析はClarityの管理画面で、数値分析はBigQueryで、という使い分けが必要になります。

高度な分析が「できる状態か」の事前検証

BigQueryに「データがある」ことと「分析ができる状態」は別物です。たとえば、スクロール深度の段階的分析（25%/50%/75%/90%）はGA4のscroll_depthイベントが有効になっている必要があります。デフォルトでは90%のみが記録されます。当社の実績では、6つの分析のうち1つ（スクロール深度の段階的分析）は追加設定が必要でした。「分析できます」と約束して実際にできなければ信頼を失う。

「1日でも早く設定すべき」の具体的な理由

BigQueryの自動エクスポートは設定した日以降のデータのみ蓄積されます。後から過去に遡ることはできません。当社の実績では、あるクライアントが3月にBigQuery連携を設定しました。もし判断が1ヶ月遅れて4月に設定していた場合、3月のデータは永久に失われていました。3月はちょうど繁忙期であり、繁忙期のユーザー行動データがなければ、翌年の繁忙期に向けた施策設計の根拠が得られませんでした。BigQueryの設定は「やろうと決めた日」にやるべきで、来月に延ばす理由はありません。

BigQuery設定は「やろうと決めた日」にやる以外に正解がありません。設定した日より前のデータは、後から一切取り戻せません。

実録: CV計測設計の再定義プロセス（B2B製造業）

GA4既定のgenerate_leadだけでは何も見えません。3系統のイベント分離とパラメータ追加で、初月から自社固有の事実が数値化されたB2B製造業の再定義プロセスを公開します。

「BigQueryの前に計測設計」の重要性は、実際のプロジェクトで痛感します。以下はB2B製造業のクライアントで実施したCV計測の再定義プロセスです。計測を始めた初日から、GA4既定のgenerate_leadだけでは何も見えないことが判明しました。なお、以下で示す数値はクライアント匿名化のため一部を改変しいます。

旧設計の問題点

当初の設計はGA4既定のgenerate_leadイベントだけでした。これには致命的な問題が3つありました。第一に、サイト上には4種類のフォーム（問い合わせ、相談、見積、資料請求）があるのに、どのフォームから送信されたかが分かりません。第二に、資料ダウンロードが実質的な主要CVなのに、フォーム送信と別イベントとして計測されていません。第三に、電話クリックが計測されていません。つまりB2Bサイトで最も重要な「確度の高いCV」と「確度の低いCV」の区別がつかませんでした。

新設計: 3系統に分離し、パラメータで確度を識別

CVイベントを3系統に分離し、GTMでカスタムパラメータを仕込みました。

イベント名	発火条件	追加パラメータ
form_submission_complete	外部フォームサービスのサンクスページ到達時	form_type（contact/estimate/consulting/download）、page_referrer
resource_download	サンクスページ上の資料DLリンククリック時	link_text（資料名）、download_url
phone_click	tel:リンククリック時	page_url（発生ページ）

form_typeパラメータを入れたことで、確度の高いCV（見積・相談）と確度の低いCV（資料請求）を分離して集計できるようになりました。link_textを入れたことで、どの資料が人気か（製品カタログ、コストダウン事例集、業界別事例集が上位）を個別に追跡できるようになりました。

再定義後に初めて見えた事実

計測開始から10日間のBigQueryデータを分析したところ、以下の3つの事実が明らかになりました。いずれもGA4管理画面のgenerate_leadだけ見ていた時代には一切把握できていませんでした。

事実	数値（匿名化のため改変）
コラム記事閲覧セッションの約96%が1記事だけで離脱	約4,200セッション中、複数記事回遊は約3%
コラムから資料請求フォームへの直接到達率	約0.2%（1000人に2人）
1フォーム送信あたりのDL数	平均約2.4資料、セッション単位では平均約5件、最大約20件

特に「コラム→フォーム到達率約0.2%」という数字は、GA4管理画面では直感的に出せません。BigQueryでuser_pseudo_idとga_session_idを結合してセッション単位で集計して初めて見える数字です。この数字が可視化されたことで、施策の優先順位が「コラムからフォームへの動線設計」に絞られました。

実例: 当社が実際に使っているSQL4選

当社がクライアントプロジェクトで実走しているSQLを4本、ユースケースと実行結果つきで公開します。いずれもGA4 BigQuery Exportが有効なら初月から実行可能なものです。

BigQueryは生データを見られる強力な基盤だが、書くSQLが想像しづらいと導入のハードルになります。以下は当社が実際のクライアントプロジェクトで使用しているSQLです。いずれも前章で紹介したB2B製造業の事例で実走済みです。

SQL1: コラム閲覧セッションから資料請求フォームへの直接到達率

セッション単位でコラム閲覧の有無とフォーム到達の有無を結合します。ga_session_idとuser_pseudo_idを連結した疑似セッションIDで集計するのがBigQueryでのセッション分析の基本パターンです。

WITH sessions AS (
  SELECT
    CONCAT(user_pseudo_id, '-',
      (SELECT value.int_value FROM UNNEST(event_params) WHERE key = 'ga_session_id')
    ) AS session_key,
    (SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'page_location') AS page_url
  FROM `project.analytics_XXX.events_*`
  WHERE _TABLE_SUFFIX BETWEEN 'YYYYMMDD' AND 'YYYYMMDD'
    AND event_name = 'page_view'
),
col_sessions AS (
  SELECT DISTINCT session_key FROM sessions WHERE page_url LIKE '%/column/%'
),
form_sessions AS (
  SELECT DISTINCT session_key FROM sessions WHERE page_url LIKE '%/download/form%'
)
SELECT
  (SELECT COUNT(*) FROM col_sessions) AS column_sessions_total,
  (SELECT COUNT(*) FROM col_sessions c INNER JOIN form_sessions f USING(session_key)) AS column_to_form_sessions;

このクエリの実行結果「約4,200セッション中、フォーム到達は約7セッション（約0.2%）」が、前章で紹介した衝撃の数字です。（数値はクライアント匿名化のため改変）

SQL2: コラム記事閲覧数のセッション分布

「1セッションで何本のコラム記事を読んでいるか」の分布を取る。GA4管理画面では「ページ別ユーザー数」は取れても、「ユーザー単位で何本読んだかの分布」は取れません。

WITH column_views AS (
  SELECT
    CONCAT(user_pseudo_id, '-',
      (SELECT value.int_value FROM UNNEST(event_params) WHERE key = 'ga_session_id')
    ) AS session_key,
    (SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'page_location') AS page_url
  FROM `project.analytics_XXX.events_*`
  WHERE _TABLE_SUFFIX BETWEEN 'YYYYMMDD' AND 'YYYYMMDD'
    AND event_name = 'page_view'
    AND (SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'page_location') LIKE '%/column/%'
),
per_session AS (
  SELECT session_key, COUNT(DISTINCT page_url) AS column_pages_viewed
  FROM column_views
  GROUP BY session_key
)
SELECT column_pages_viewed, COUNT(*) AS session_count
FROM per_session
GROUP BY column_pages_viewed
ORDER BY column_pages_viewed;

実行結果は「1記事: 約4,020セッション（約96%）、2記事: 約130、3記事: 約14、4記事以上: 約6」という極端な分布になった（数値は匿名化のため改変）。これを見て、施策の方向は「コラム回遊率の改善」ではなく「1記事でも確実にCVに結びつける動線設計」に転換しました。数字が戦略を決めた具体例です。

SQL3: 資料DL数のセッション分布（複数資料ニーズの可視化）

1セッションでユーザーが何件の資料をDLしているかの分布を取る。これを見ないと「1フォーム送信あたり平均2.7資料」という平均値に騙されます。分布を見れば、5件・10件・25件を一度にDLするヘビーユーザーが存在することが分かる。

WITH dl_counts AS (
  SELECT
    CONCAT(user_pseudo_id, '-',
      (SELECT value.int_value FROM UNNEST(event_params) WHERE key = 'ga_session_id')
    ) AS session_key,
    COUNT(*) AS dl_count
  FROM `project.analytics_XXX.events_*`
  WHERE _TABLE_SUFFIX BETWEEN 'YYYYMMDD' AND 'YYYYMMDD'
    AND event_name = 'resource_download'
  GROUP BY session_key
)
SELECT dl_count, COUNT(*) AS session_count
FROM dl_counts
GROUP BY dl_count
ORDER BY dl_count;

実行結果の分布は「1件: 3セッション、3件: 3、5件: 2、7件: 1、10件: 1、20件: 1」という形になった（数値は匿名化のため改変）。セッション単位では平均約5件、最大約20件。平均値だけでは見えない「複数資料を一度にまとめて取りたいニーズ」が実在することが明確になりました。この事実がカート型UI施策の根拠になりました。

SQL4: 月次CV推移と着地予測（計測開始直後でも月末を見積もる）

計測を始めた月は、まだ10日間分のデータしかありません。それでも「このペースだと月末で何件になるか」を試算することはできます。テスト送信の除外、GTM計測前日数の補正を含めた実装がこれです。

-- 計測開始から10日分の実測値（テスト送信を除外するため、gtm_debug付きURLと確認用セッションを除外）
WITH actual AS (
  SELECT
    COUNT(*) AS total_events,
    COUNT(DISTINCT CONCAT(user_pseudo_id, '-',
      (SELECT value.int_value FROM UNNEST(event_params) WHERE key = 'ga_session_id')
    )) AS total_sessions
  FROM `project.analytics_XXX.events_*`
  WHERE _TABLE_SUFFIX BETWEEN 'YYYYMMDD' AND 'YYYYMMDD'
    AND event_name = 'form_submission_complete'
    AND (SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'page_location') NOT LIKE '%gtm_debug%'
)
SELECT
  total_events AS actual_cv,
  total_events - 6 AS cv_without_test,  -- テスト送信約6件を除外
  ROUND((total_events - 6) / 10.0, 1) AS daily_avg,
  ROUND((total_events - 6) / 10.0 * 24, 0) AS month_end_forecast  -- 計測可能な月内残り日数(例: 24日分)
FROM actual;

このクエリで「実測約38件からテスト送信約6件を除外して日割り約3.2件/日、計測可能な月内残り24日分で着地予測約77件」が算出される（数値は匿名化のため改変）。GTMを設置した当月から月末の着地予測ができることで、クライアントへの月次報告が「今月は何件だった」の事後報告から「今月は何件で着地する見込み、来月はこう動く」の予測型報告に変わります。

これらのSQLは、全てGA4のBigQueryエクスポートを有効化すれば即座に実行できます。追加のETLやCRM連携は不要です。計測設計を丁寧に行い、form_typeやlink_textのパラメータを仕込んでおけば、初月からこのレベルの分析が可能になります。

よくある質問

導入検討時に繰り返し聞かれる6つの質問への回答。技術的な懸念と費用の話が中心です。

GA4の管理画面でデータを見るだけではだめですか

管理画面ではデータの保持期間（最大14ヶ月）やクロス集計に制限があります。BigQueryでは全期間の生データに対して自由な分析が可能です。

Search ConsoleとGA4をそれぞれ単体で見るだけではだめですか

単体では「どのキーワードで来た人がコンバージョンしたか」が分かりません。BigQueryで結合することで、検索流入からコンバージョンまでの一気通貫の分析ができます。

今まで貯めてきたGA4のデータをBigQueryに流し込めばよいのでは

GA4の管理画面からエクスポートできるのは「集計データ」であり、BigQueryの自動エクスポートで得られる「生データ」とは全く異なります。集計データでは「どのコラムを読んだ人がCVに至ったか」の追跡ができません。生データがなければ、ユーザー行動パターンの分析はできません。BigQueryの自動エクスポートを早期に設定することが重要です。

BigQueryの利用に追加費用はかかりますか

GA4とSearch ConsoleのBigQueryエクスポート自体は無料です。BigQueryの従量課金は東京リージョンで1TBあたり$6.25（Google Cloud公式価格）。

サイト規模	月間PV目安	月間クエリ量目安	月間費用目安
小規模	～5万PV	～100GB	無料（1TB無料枠内）
中規模	5～30万PV	～500GB	無料（1TB無料枠内）
大規模	30～100万PV	1～3TB	$0～$12.50/月
超大規模	100万PV以上	3TB以上	$12.50～/月

データ保存料金は別途（1GBあたり$0.023/月）。中規模サイトの1年分のGA4データ保存で月$1～$5程度です。

Phase 1にそんなに時間がかかるのですか

GTMの発火検証、CV定義の設計、BigQueryの突合検証を丁寧に行うと1～2ヶ月かかります。ここを省略してPhase 2に進むと、間違ったデータに基づいた間違った結論を出すことになります。計測基盤の設計ミスは、後から修正するほどコストが大きくなります。