GA4とBigQueryの連携手順｜出力確認と費用管理の準備

連携の目的と管理担当を先に決める

BigQuery連携は、GA4のイベントデータをGoogle Cloud側で保存・集計するための選択肢です。GA4の標準レポートをコピーするだけの仕組みではなく、両者の集計結果が常に一致するわけでもありません。

必要なのは、対象GA4の編集権限、リンクに必要なCloud権限を持つ担当者、利用プロジェクト、保存場所と費用の管理方針です。権限要件は公式のリンク画面・手順で確認し、最小限を担当者に割り当てます。この記事では実際のCloud設定・課金を実行していません。

1．費用の見積もりに必要な値をそろえる

見積もり式は「対象の課金単価×課金対象量」が基本ですが、無料枠、通貨、リージョン、課金方式で変わります。たとえば1回10GiBの読み取りを月30回なら300GiBという量を先に求め、公式料金表に当てはめます。これは架空の量の例で、料金見積もりではありません。予算通知は通常、課金を自動停止する仕組みではありません。

2．Cloudプロジェクトを準備する

専用または承認済みのGoogle Cloudプロジェクトを選び、BigQuery API、請求先またはsandboxの利用条件、権限を担当者が確認します。sandboxには制約があるため、無料という理由だけで本番の保存要件を満たすと判断しません。

データを置くリージョンは、社内の保存方針と他データとの結合予定を踏まえて決めます。あとで気軽に移せる前提にせず、リンク前に合意します。

3．GA4からリンクを作る

GA4管理のサービス間のリンク設定からBigQueryのリンクを開き、リンクを作成します。対象Cloudプロジェクトを選び、データのロケーション、対象ストリーム、エクスポート設定を確認して送信します。

最初は目的に合う最小構成を選びます。日次とストリーミングを無条件に両方有効化しません。除外イベントや対象ストリームを変更した場合は、その日付を記録します。既存のリンクを削除して作り直す前には影響を確認してください。

4．翌日以降の出力を確認する

リンク状態だけで完了とせず、BigQueryで対象プロジェクトとanalytics_プロパティIDのデータセットを確認します。日次ならevents_YYYYMMDD形式のテーブルを確認します。出力開始まで待ち時間があり、過去のすべてのデータが自動的に遡って出力されるわけではありません。

クエリはまず対象日の1テーブルに限定します。次はSQLの例で、プロジェクト・データセット・日付を実在する値へ置き換えます。実行前に読み取り量を確認してください。

SELECT event_name, COUNT(*) AS event_count
FROM `YOUR_PROJECT.analytics_YOUR_PROPERTY.events_20261001`
GROUP BY event_name
ORDER BY event_count DESC;

このCOUNTは出力イベント行の数です。GA4画面のユーザー数やセッション数とは別です。SQLを実行しただけでGA4全体との一致を証明したことにはなりません。

出力されない・数字が違うとき

上限・利用可能な出力方式はプロパティ種別でも変わるため、最新の公式制限を確認します。SQLの全期間ワイルドカードを繰り返す前に、日付を限定して原因を調べます。

AIを使う前提と完了条件

このSQLの対象テーブル、期間、集計単位、読み取り量の懸念をレビューしてください。
実行は不要です。ユーザー数やセッション数とイベント行数を混同しないでください。
未提供のテーブル構造は仮定として明示してください。

出力テーブル、対象期間、費用管理、アクセス権、確認担当と運用記録がそろえば初回確認は完了です。SQLのローカル例示と実アカウントでの実行確認は区別してください。

公式資料：BigQuery Export設定、出力スキーマ、費用管理。

AI支援で制作。公式資料の確認日：2026年10月5日。次回確認予定：2027年1月5日。実アカウントの操作・課金・公開、実務者監修、第三者再現は未実施です。掲載の記入例・数値例は架空の教材であり、実績ではありません。