GA4、Search Console、Google広告、Meta広告、CRMなど、マーケティングで扱うデータは複数の管理画面やスプレッドシートに分散しています。各画面から数値を集め、項目名や形式をそろえ、前月比を計算する。毎月、この集計作業だけに多くの時間を取られている企業も少なくありません。BigQuery（ビッグクエリ）は、こうしたデータを一カ所に集約し、共通の基準で分析するための基盤です。
BigQueryはエンジニアだけの道具ではありません。GA4やSearch Consoleには公式のエクスポート機能があり、集約したデータはGoogleスプレッドシートやLooker Studioへ連携できます。最初から大規模な基盤を作る必要はなく、無料枠を利用して小規模に試すこともできます。
この記事では、BigQueryの役割、スプレッドシートやLooker Studioとの違い、料金の仕組みを、マーケティングでの利用場面に絞って解説します。
AIを活用したBtoBマーケティングの戦略設計から実行までを担当。検索流入を軸にした集客と、AIXの現場知見をもとに記事を監修しています。
合同会社efuでは、広告の運用そのものから、成果を判断するためのレポートと指標の設計までを支援しています。記事の内容に関するご質問や、自社での取り組みについてのご相談は、支援内容のページからご連絡ください。
BigQueryはマーケティングデータをためてつなぐ基盤
BigQueryは、Google Cloudが提供するフルマネージド、サーバーレスのデータプラットフォームです。大量のデータを保存し、SQLという言語で必要な行や列を抽出し、集計できます。サーバーの台数や処理能力を利用者が管理する必要はなく、データの保存と分析に集中できる設計です。
マーケティングにおけるBigQueryの役割は、各サービスから集めたデータを保管・整理する共通基盤と考えると分かりやすくなります。GA4、Search Console、広告媒体、CRMから日次データを取り込み、BigQuery上で指標名や計算方法を統一します。集計結果はGoogleスプレッドシート、Looker Studio、AIエージェントへ連携できます。
BigQuery自体は、完成したグラフを並べるダッシュボードではありません。データの蓄積・整形・集計を担うサービスです。数値を表示する画面はLooker Studioなどで作り、BigQueryはその裏側で、統一した定義に基づく集計結果を返します。
スプレッドシート・データベース・Looker Studioとの違い
BigQueryと混同されやすいツールには、それぞれ異なる役割があります。互いに置き換えるものではなく、目的に応じて組み合わせて使います。
| 道具 | 主な役割 | 向いている場面 |
|---|---|---|
| Googleスプレッドシート | 数値を確認し、手作業で集計・調整する | データ量が小さく、担当者が直接操作しながら集計したい |
| 業務データベース | 顧客情報や受注情報を日々登録・更新する | 業務データを1件ずつ登録・更新するシステムを運用したい |
| BigQuery | 複数のデータを蓄積し、大量のデータを横断的に集計する | 媒体横断の分析、長期保管、定例集計を行いたい |
| Looker Studio | データをグラフや表で可視化する | 決まった指標をダッシュボードで共有したい |
単一媒体の数値を月に一度確認するだけなら、スプレッドシートやLooker Studioで対応できます。BigQueryの価値が高まるのは、データソースが増え、同じ集計を繰り返すようになり、元データの長期保管も必要になった段階です。
BigQueryを使うとマーケティングで何ができるか
GA4のイベント単位のデータを分析する
GA4のBigQuery Exportを設定すると、Webサイトやアプリで発生したイベントのデータが日次テーブルへ出力されます。GA4の標準レポートに用意された切り口に限定されず、ページ閲覧、流入元、コンバージョンなどを任意の条件で再集計できます。
標準のGA4プロパティでも日次エクスポートを利用でき、上限は1日100万イベントです。日次テーブルは events_YYYYMMDD という名前で作られます。設定前の過去データは遡ってエクスポートできないため、将来利用する可能性がある場合は、分析設計が固まる前にエクスポートを有効にしておくと、蓄積期間を確保できます。
Search Consoleの検索データを日次で蓄積する
Search Consoleにも、検索パフォーマンスのデータをBigQueryへ毎日出力する一括データエクスポートがあります。管理画面には重要な行が優先して表示されますが、一括データエクスポートを使うと、より網羅的なクエリデータを自社で分析できます。
URL別、クエリ別、国別、デバイス別の変化を長期で追い、公開日やリライト日と突き合わせる分析に向きます。ただし、出力されたデータが日付やURLごとに必ずしも1行に集約されているとは限らないため、SQLではクリック数や表示回数を SUM して使います。
広告とCRMをつなぎ、問い合わせ後まで見る
広告媒体の管理画面だけでは、クリック後に発生した商談や受注まで一貫して追跡することは困難です。広告費とクリックは広告媒体、問い合わせの発生はフォームやGA4、商談・受注はCRMに記録されます。これらをBigQueryへ集約し、共通の識別子で連携できれば、CPAに加えて有効リード率や商談化率まで一続きで分析できます。
ここで重要なのは、データを集めるだけでなく、指標の定義をそろえることです。媒体によって、コンバージョンの計測方法、日付の基準、タイムゾーンが異なります。BigQuery上に共通のビューを作り、会議で使うCPAの計算方法を固定すると、担当者ごとに数値が変わる状態を防げます。
スプレッドシート・BI・AIへ同じ数値を渡す
BigQueryに集約したデータは、Connected Sheetsを使ってGoogleスプレッドシートから扱えます。ピボットテーブルや関数、グラフを使うときも、元のデータはBigQuery側に置いたままです。Looker StudioはBigQueryのテーブルやビューへ直接接続できます。
AIエージェントにも読み取り権限を与えれば、「先月、CPAが悪化した媒体とキャンペーンを出して」と自然言語で問い合わせられる仕組みを構築できます。スプレッドシート、ダッシュボード、AIが同じビューを参照することで、ツールごとの指標の不一致を防げます。
AIを各サービスへ直接つなぐ方法との違い
AIエージェントをGA4、広告媒体、CRMなどのAPIへ直接接続し、質問のたびにデータを取得・統合する方法もあります。単一サービスの数値を確認する場合や、一時的な分析であれば、BigQueryを使わずに直接接続するほうが簡単です。
| 比較軸 | AIを直接接続 | BigQueryへ集約 |
|---|---|---|
| データ取得 | 質問するたびに各サービスのAPIから取得する | あらかじめ取り込み、同じ場所から参照する |
| 履歴 | 各サービスやAPIが提供する期間・粒度に依存する | 必要な期間と粒度で自社に蓄積できる |
| 指標の定義 | 質問や処理ごとに集計条件を指定する | SQLやビューとして計算方法を固定できる |
| 再現性 | 回答時のAPI結果や指示内容によって結果が変わり得る | 同じデータとSQLから集計結果を再現できる |
| 認証・運用 | 接続先ごとに認証とAPIの管理が必要 | AIの接続先をBigQueryにまとめられる |
BigQueryの利点は、AIがデータへアクセスできること自体ではありません。複数サービスのデータと過去の履歴を一カ所に残し、CPAやコンバージョンなどの計算方法をSQLやビューとして固定できる点にあります。AIが出した数値に疑問がある場合も、どのデータをどの条件で集計したかを確認できます。
AIの直接接続とBigQueryは、どちらか一方を選ぶ関係ではありません。まず直接接続で必要な分析を確かめ、複数媒体の横断分析や定例レポートが必要になった段階でBigQueryへ集約する方法もあります。継続運用では、BigQueryを共通のデータ基盤とし、AIはBigQueryへ接続する構成にすると、利用するAIを変更してもデータと指標の定義を維持できます。
BigQueryの基本構造を4つの要素で理解する
BigQueryを使い始めると、プロジェクト、データセット、テーブル、ビューという言葉が出てきます。マーケティングのデータ基盤では、次の4つの要素に分けて整理すると理解しやすくなります。
- プロジェクト：課金、API、権限を管理する単位
- データセット：用途ごとにテーブルをまとめる箱。たとえば
marketing_rawやmarketing_mart - テーブル：実際のデータを行と列で保存する場所
- ビュー：SQLによる集計方法を保存し、毎回同じ定義で結果を返す仮想的な表
分析するときは、SQLで「どのテーブルから、どの期間の、どの列を、どう集計するか」を指定します。広告の日次テーブルから直近30日分のクリックと費用を集計するなら、考え方は次のようになります。
SELECT
report_date,
SUM(clicks) AS clicks,
SUM(cost) AS cost,
SAFE_DIVIDE(SUM(cost), SUM(conversions)) AS cpa
FROM `project_id.marketing.ad_daily`
WHERE report_date BETWEEN DATE_SUB(CURRENT_DATE('Asia/Tokyo'), INTERVAL 30 DAY)
AND CURRENT_DATE('Asia/Tokyo')
GROUP BY report_date
ORDER BY report_date;同じSQLをビューとして保存すれば、スプレッドシートやLooker Studioはそのビューを参照するだけで済みます。計算式を各レポートへ複製しないことが、数値を統一するうえで重要です。
BigQueryの料金は主に保存量とデータ処理量で決まる
BigQueryの主な料金は、データを保存するストレージ料金と、SQLでデータを処理するコンピューティング料金の二つです。オンデマンド方式では、クエリが読み取ったデータ量に応じて料金が決まります。
Google Cloudの公式料金では、毎月10 GiBまでのストレージと、毎月1 TiBまでのクエリ処理に無料枠があります。公式料金表では、無料枠を超えたオンデマンドクエリの料金は、処理量1 TiBあたり6.25米ドルが目安です。実際の料金はリージョン、通貨、利用する追加機能で変わるため、導入時点のBigQuery公式料金を確認してください。
BigQueryサンドボックスを使えば、クレジットカードや請求先を登録せずに試せます。ただし、サンドボックスではテーブルやビューが60日で期限切れになり、GA4のストリーミングエクスポートも使えません。SQLの試用には向きますが、マーケティング基盤として継続運用する場合は、請求先を設定した通常のプロジェクトを使用します。
費用を抑える基本は、読む範囲を狭くすること
クエリ費用は返ってくる行数ではなく、読み取ったデータ量で決まります。SELECT * で全列を読み、最後に LIMIT 100 を付けても、読み取り量は減りません。必要な列だけを指定し、日付条件を使える場合は対象期間も絞ります。
日々データが追加されるテーブルは、日付でパーティション分割します。検索条件に日付を入れると、BigQueryは該当するパーティションだけを読み、処理時間と費用の両方を抑えられます。請求アラートとクエリ量の上限も設定し、操作ミスがそのまま想定外の請求につながらないように安全策を設けます。
BigQueryを使い始める4つの手順
手順1 何を判断するためのデータかを決める
収集できるデータを先に並べるのではなく、何を判断したいのかを決めます。「媒体横断のCPAを見る」「記事閲覧から有効リードの発生まで追う」「毎週のレポートを自動化する」など、一つの用途から始めます。用途が決まると、必要なデータソース、更新頻度、項目、データの粒度が決まります。
手順2 Google Cloudのプロジェクトと権限を用意する
Google Cloudでプロジェクトを作成し、継続利用する場合は請求先を設定してBigQuery APIを有効にします。データセットを作るときはロケーションも決めます。あとから別リージョンのデータと結合すると設計が複雑になるため、GA4やSearch Consoleの出力先を含め、最初に同じロケーションへそろえます。
人やプログラムに与える権限は、必要な範囲だけに絞ります。レポート生成に使うAIやダッシュボードには、データを書き換える権限を渡さず、読み取り専用を基本にします。サービスアカウントの鍵はコードや共有フォルダに直接置かず、実行環境のシークレットとして管理します。
手順3 元データと集計用のビューを分ける
取り込んだままの元データは、加工せずに残します。その上に、列名、日付、媒体名、指標の定義をそろえたビューを作ります。集計を間違えても元データから作り直せるようにするためです。
自動取り込みは、同じ日付の処理を再実行しても二重計上されない形にします。取得件数が急にゼロになったり、前日から大きく減ったりした場合は、後続処理を止め、更新前の正常なデータを残すほうが安全です。
手順4 見せる場所へ接続して数値を照合する
集計用のビューをConnected SheetsやLooker Studioへ接続し、担当者が使う表やグラフを作ります。完成後は、各指標を元の管理画面や手計算の結果と一つずつ照合します。数値が合わない場合は、期間、タイムゾーン、コンバージョンの定義、重複、通貨の順に確認します。
広告、GA4、Search Consoleを実際にBigQueryへ集約し、毎朝更新するダッシュボードを作る手順は、「AIで自作するマーケティングダッシュボードの作り方、広告・GA4・Search Consoleを連携する4つの手順」で、実装時に起きた失敗とあわせて解説しています。
BigQueryが必要なケースと、まだ使わなくてよいケース
| BigQueryが向く | 既存の道具で足りる |
|---|---|
| GA4、広告、Search Console、CRMを横断したい | 単一媒体の決まった指標だけを見る |
| 日次データを長期で蓄積したい | 月次の合計値を手元に残せればよい |
| 同じ集計を毎週、毎月繰り返す | 分析が単発で、更新の予定がない |
| 複数の担当者やBI・AIで同じ数値を共有したい | 一人で小さな表を確認するだけ |
BigQueryを導入すること自体を目的にすると、使われないテーブルだけが増えます。単一媒体の定型レポートなら、まずLooker Studioの公式コネクタで十分です。スプレッドシートの動作が重い、複数媒体を横断して集計できない、同じ加工を毎月繰り返している、といった課題が明確になった段階で導入しても遅くありません。
BigQuery導入で失敗しやすい点
データを集めるだけで数値がそろうと考える
媒体ごとに指標の定義が違うままでは、同じ場所へ集めても比較できません。クリック、コンバージョン、費用、日付の基準、通貨について、会議で使う定義を先に決めます。データ基盤の品質はテーブル数ではなく、判断に使う指標の定義が一意に決まるかで評価します。
元データを直接加工する
取り込み直後のテーブルを上書きすると、計算ミスが見つかったときに戻せません。元データ、整形データ、表示用の集計を分け、加工はSQLやビューとして残します。誰が見ても計算過程を追える状態にします。
必要以上に広い権限を与える
ダッシュボードやAIとの連携に必要なのは、多くの場合、決められたビューの読み取り権限だけです。プロジェクト全体の編集権限や、元テーブルの削除権限まで渡す必要はありません。個人情報や顧客情報を扱う場合は、列単位・行単位の権限を設定し、AIへ渡してよい項目の範囲も定めます。
BigQueryの構築を外部委託する範囲の決め方
外部委託する範囲は、社内で不足しているのがデータ基盤を構築する技術なのか、数値を基に施策を実行する体制なのかで決めます。
データ基盤とダッシュボードの構築だけを任せる
広告やコンテンツの改善を社内で実行できており、データ連携、BigQueryの設計、定例レポートの自動化でつまずいている場合は、基盤構築のみを外部へ委託する形が向いています。一般社団法人日本AI導入支援協会の広告レポート自動化・ダッシュボード構築支援では、KPI設計からデータ統合、可視化、AIによるレポート要約までを扱っています。
分析後の広告運用まで任せる
ダッシュボードを作る目的が広告成果の改善にあり、施策を実行する人員も足りない場合は、可視化だけを整えても成果にはつながりません。合同会社efuでは、広告運用とあわせて、判断に使う指標やレポートの設計を支援しています。現在の集計方法と改善施策をまとめて見直したい場合は、広告運用代行の支援内容をご覧ください。
まとめ
BigQueryは、複数のマーケティングデータを一カ所にため、同じ定義で集計し、スプレッドシート、Looker Studio、AIへ渡すための基盤です。画面を作るツールではなく、その裏側で統一した定義に基づく集計結果を返す役割を担います。
単一媒体の小規模なレポートには必須ではありません。GA4、広告、Search Console、CRMを横断したい、日次データを長期保管したい、同じ集計を繰り返したいという段階で導入価値が高まります。最初は一つの分析目的と一つのデータソースに絞り、元データを残す、クエリの対象期間を絞る、権限を最小限にするという三点から始めると、運用しやすい基盤になります。
参照
- Google Cloud「BigQueryの概要」
- Google Cloud「BigQueryの料金」
- Google Cloud「BigQueryをサンドボックスで試す」
- Google Cloud「パーティション分割テーブルの概要」
- Google Cloud「クエリ計算の最適化」
- Google Cloud「Connected Sheetsを使用する」
- Google Cloud「Looker StudioをBigQueryへ接続する」
- Google Analyticsヘルプ「BigQuery Exportを設定する」
- Google Analyticsヘルプ「BigQuery Exportスキーマ」
- Search Consoleヘルプ「一括データエクスポートを開始する」
- Search Consoleヘルプ「クエリのガイドラインとサンプル」
