GA4のBigQueryエクスポートで集計1本はどれだけ読むか｜events_*の絞り方

GA4 の BigQuery エクスポートで1本の集計がどれだけ読むかは、何日分の表を読むかと、どの列を読むかでほぼ決まります。日付で絞るときは _TABLE_SUFFIX（ワイルドカードで読んだ表の名前の日付の部分）を、定数で比べる形で書きます。event_date 列で絞ったり、日付をサブクエリで渡したりすると、1月分だけ欲しくても、エクスポートされている全期間の表を読みます。

当社は BigQuery を中心にしたデータ基盤の設計・構築と、ダッシュボードでの可視化を支援している会社です。当社のGA4×BigQuery 連携の記事では、Google の公開サンプルで数え方を試し、処理量は読む列と日数で決まる、というところまで書きました。けれども、その SQL を自社の何か月分ものデータに流す前に量を見積もろうとすると、どの書き方なら日数が減り、どの列がどれだけ重いのかまで分からないと答えが出ません。この記事は、その先を掘ります。同じサンプルに、当社の検証用の Google Cloud プロジェクトから、同じ集計を書き方だけ替えて dry run（実行せずに処理量を見積もる機能）で50本流し、処理量を並べました。見積もりが合っているかは、課金の上限を付けて8本を流して確かめています（1本は上限で実行前に止まり、1本はキャッシュから返りました）。お客様の環境やデータは使っていません。

扱うのは、オンデマンド（読んだデータ量で課金される方式）のクエリの処理量です。リンクの作り方や、ユーザー・セッションの数え方は上の連携の記事に、BigQuery の料金の全体の構造はデータ統合基盤の費用の記事に書いています。

試したサンプルと、処理量の見方

使ったのは、Google の公開データセット bigquery-public-data.ga4_obfuscated_sample_ecommerce です。Google Merchandise Store の GA4 のエクスポートを難読化したもので、2020年11月1日から2021年1月31日までの3か月分が入っています（Google アナリティクスの開発者向け文書「Google アナリティクス 4 e コマースウェブ実装向けの BigQuery サンプル データセット」）。表の一覧を読むと、日ごとの表が 92 個（events_20201101〜events_20210131）、合わせて 4,295,584 行・3,583,657,854 バイト（約 3.58 GB）で、どの表にもパーティションやクラスタはありませんでした。実際の GA4 のエクスポートと同じく、日付ごとに別の表に分かれた形（シャーディング）です。

このデータセットは US マルチリージョンに置かれているので、照会も US で動かしました（「BigQuery の一般公開データセット」）。保存の費用は Google が持ち、クエリの料金だけが、クエリを流したプロジェクトの請求先アカウントにかかります。

dry run で処理量を見る

dry run は、クエリを実行せずに、処理するデータの量を見積もる機能です。スロットを使わないので、dry run 自体は課金されません。コンソールのクエリエディタでは、SQL を書くとチェックマークと一緒に処理量が出ます。bq コマンドなら --dry_run、API ならジョブの設定で dryRun を true にします（「クエリの実行」のドライランの節）。この記事の数字は、API の dry run が返したバイト数です。

処理量と課金量は少し違います。オンデマンドの料金は MB 単位に切り上げ、参照する表ごとに最低 10 MB、クエリごとにも最低 10 MB で数えます。エラーで終わったクエリと、キャッシュから結果を返したクエリは課金されません（BigQuery の料金）。公式の表記は MB ですが、当社の実行で課金された量はどれも 1,048,576 バイト（1 MiB）の倍数で、いちばん少ない課金は 10,485,760 バイト（10 MiB）でした。この記事では、処理量は 1 MB＝100万バイトで、課金量は MiB で書きます。

例に固定した集計：2021年1月のページ別の page_view 数

この記事では、最後まで1つの集計を使います。2021年1月の page_view を、パラメータ page_location（ページの URL）ごとに数えて上位10件を出すものです。ページの URL は event_params という配列の中にあるので、UNNEST で取り出します。

SELECT
  (SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'page_location') AS page_location,
  COUNT(*) AS page_views
FROM `bigquery-public-data.ga4_obfuscated_sample_ecommerce.events_*`
WHERE _TABLE_SUFFIX BETWEEN '20210101' AND '20210131'
  AND event_name = 'page_view'
GROUP BY page_location
ORDER BY page_views DESC
LIMIT 10

dry run の見積もりは 344,660,777 バイト（344.7 MB）でした。課金の上限を 400 MiB にして実行すると、処理量は見積もりと1バイトまで同じで、課金量は MiB 単位に切り上げた 344,981,504 バイト（329 MiB）でした。結果の1位はトップページ（shop.googlemerchandisestore.com/）の 71,599 件です。以下、この集計の WHERE か SELECT だけを替えて、処理量がどう動くかを見ていきます。

何日分を読むか：_TABLE_SUFFIX で表の数が決まる

GA4 のエクスポートは、日ごとに events_YYYYMMDD という別の表になります。events_* と書くと、events_ で始まる表をまとめて読むワイルドカードの照会になり、_TABLE_SUFFIX には * に当たる部分（20210101 など）が入ります。GA4 の開発者向け文書も、期間を限るときは WHERE で _TABLE_SUFFIX を使うよう書いています（「Google アナリティクス 4 のイベントデータのエクスポートに関する基本的なクエリ」）。

処理量は、読む表の数にほぼ沿って増えました。日付の条件を書かないと、92日分で 1,307 MB、1月に絞った 344.7 MB の約3.8倍です。表の名前を events_202101* と書いて1月の表だけを対象にしても、344.7 MB で同じでした。

間違えやすい：event_date 列で絞る

表の中には event_date という日付の列もあります。これで1月に絞ると、結果は同じになるはずの条件でも、処理量は 1,350 MB でした。条件なしの 1,307 MB より多いのは、92日分の表を全部開いたうえで、event_date 列の分（92日分で 43.0 MB）まで読んだからです。

SELECT
  (SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'page_location') AS page_location,
  COUNT(*) AS page_views
FROM `bigquery-public-data.ga4_obfuscated_sample_ecommerce.events_*`
WHERE event_date BETWEEN '20210101' AND '20210131'
  AND event_name = 'page_view'
GROUP BY page_location
ORDER BY page_views DESC
LIMIT 10

GA4 のエクスポートは日ごとに別の表として書き出され、このサンプルの表にもパーティションはありませんでした。ワイルドカードで読むとき、列の値で絞っても、読む表は減りません。表を減らせるのは _TABLE_SUFFIX か、表の名前の接頭辞です。

日付で絞ったつもりでも、全期間を読む書き方

_TABLE_SUFFIX を使っていても、表が減らない書き方があります。公式のドキュメントは、スキャンする表を限るには、_TABLE_SUFFIX を定数の式と比べる条件で書くこと、定数の式でない条件（サブクエリの結果や、列の値を使うもの）や JavaScript のユーザー定義関数を含む条件では表の数が限られないことを書いています（「ワイルドカード テーブルを使用した複数テーブルに対するクエリ」）。同じ1月を、書き方だけ替えて dry run しました。

関数で包んでも、日付の定数と _TABLE_SUFFIX だけでできた条件は31日分で済みました。表が減らなかったのは、日付の一覧をサブクエリで作って IN で渡した書き方で、条件を書かないときと同じ量を読みました。

SELECT
  (SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'page_location') AS page_location,
  COUNT(*) AS page_views
FROM `bigquery-public-data.ga4_obfuscated_sample_ecommerce.events_*`
WHERE _TABLE_SUFFIX IN (SELECT FORMAT_DATE('%Y%m%d', d)
      FROM UNNEST(GENERATE_DATE_ARRAY('2021-01-01', '2021-01-31')) AS d)
  AND event_name = 'page_view'
GROUP BY page_location
ORDER BY page_views DESC
LIMIT 10

サブクエリで作った値は実行してみるまで決まらないので、BigQuery は読む表を前もって絞れません。公式のページには回避策として、先に1本目のクエリで値を取り出し、それを定数として2本目のクエリに書く、という分け方が載っています（同じページ）。

「直近7日」のような相対の日付

CURRENT_DATE() から日付を作る書き方は、dry run で 0 バイトでした。サンプルには2020〜2021年の表しか無く、該当する日の表が1つも無かったためです。表が絞られていなければ条件なしと同じ 1,307 MB 前後になるはずなので、この書き方でも読む表は前もって絞られている、と読めます（31日分のような量を測ったわけではありません）。

WHERE _TABLE_SUFFIX BETWEEN FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE('Asia/Tokyo'), INTERVAL 7 DAY))
      AND FORMAT_DATE('%Y%m%d', CURRENT_DATE('Asia/Tokyo'))

なお、CURRENT_DATE() を使うクエリは、結果のキャッシュの対象から外れます（キャッシュに保存されているクエリ結果を使用する）。events_* で読む集計は、もともとキャッシュされないので（後の節）、この違いは料金に出ません。

REGEXP_CONTAINS：日本語版の公式の記述と、このサンプルの結果が食い違った

日本語版の公式ページの「制限事項」には、REGEXP_CONTAINS で _TABLE_SUFFIX を絞っても、接頭辞で始まる全部の表がスキャンされる、という記述があります。このサンプルでは、dry run は1月分の量でした。1月31日だけに絞る正規表現（r'^20210131$'）を、課金の上限を 50 MiB にして実行しても止まらず、処理量は 7,426,961 バイトで1日分と同じでした（課金は最低の 10 MiB）。日本語版の最終更新日は2026年1月24日、英語版は2026年10月13日で、英語版の制限事項には、この記述が見当たりませんでした。食い違う理由は確かめられていないので、表を確実に絞りたいときは BETWEEN か LIKE で書くのが無難です。

ここで見た _TABLE_SUFFIX の決まりは、パーティションを切った表の日付の列を関数で包むと絞り込みが効かないことがある、という話（クエリの最適化の記事）とは別のものです。

どの列を読むか：SELECT * と、重い列

BigQuery は列ごとにデータを持っていて、オンデマンドの料金は、クエリが使う列の量で決まります（BigQuery の料金）。1月に絞って SELECT * にすると 957.1 MB、例の集計は 344.7 MB で、全列の約36%でした。どの列が重いかを見るために、23ある最上位の列を1列ずつ、92日分で dry run しました。

いちばん重いのは event_params で、全体の 39.4%、次が商品の配列 items の 27.7% でした。device・geo・traffic_source のような、中に細かい項目を持つ列（レコード）も重めです。user_id・user_properties・app_info など、このサンプルでは中身が無い列は 0 バイトでした。自社のエクスポートでは、使っている機能によってこの並びが変わります。

このサンプルでは、LIMIT と列の値の条件で減らなかった

92日分の SELECT * に LIMIT 10 を付けても、見積もりは 3,583,657,854 バイトのままでした。クラスタにしていない表では LIMIT で読む量は減らない、と公式も書いています（費用の見積もりと管理）。中身を眺めたいだけなら、コンソールの表の［プレビュー］は無料です（同じページ）。

例の集計から event_name = 'page_view' を外すと、処理量は 329.1 MB に減りました。条件を書くと event_name 列（1月分で 15.6 MB）を読む分だけ増え、page_view 以外の行を読まずに済んだわけではありません。パーティションもクラスタも無いこのサンプルの表では、列の値の条件は読む量を減らさず、読む列を1つ増やしました。パーティションやクラスタのある表なら、その列の条件で読む量が減ることがあります（BigQuery の料金）。

逆に、件数を数えるだけなら列を読みません。1月の表に SELECT COUNT(*) を流す dry run は 0 バイトでした。

event_params の中は、key と値の型ごとに数えられる

event_params はイベントのパラメータを入れた配列で、1つずつが key（パラメータ名）と value（string_value・int_value・float_value・double_value のどれかに値が入る）の組です（アナリティクス ヘルプ「[GA4] BigQuery Export スキーマ」）。この中も列ごとに読まれます。1月分で、中の項目を1つずつ dry run しました。

例の集計の 344,660,777 バイトは、key（181,662,303）と string_value（147,434,965）と event_name 列（15,563,509）の合計と、1バイトまで同じでした。page_location は文字列なので、int_value などは読んでいません。いちばん重いのは値ではなく key で、パラメータの名前が行ごとに入っているためだと考えられます。

取り出し方を替えても量は変わりませんでした。SELECT の中のサブクエリで取り出す形の代わりに、FROM events_*, UNNEST(event_params) AS ep と結合して ep.key = 'page_location' で絞る形にしても、344,660,777 バイトで同じです。一方、配列を丸ごと選ぶと（SELECT event_name, event_params や ep.*）、使わない int_value なども読んで 390.3 MB になりました。

ページ別にユーザー数とセッション数も数えると 415.3 MB で、例の集計より 70.6 MB 増えました。そのうち 45.6 MB が ga_session_id を入れた int_value の列、残りの約 25.0 MB が user_pseudo_id の列の分で、key の列は増えていません。この集計の dry run から読むと、key の列は event_params から1つでも取り出したときに1回読まれ、取り出すパラメータを足しても増えないと考えられます。増えるのは、まだ読んでいない値の型の列（int_value など）と、新しく使う列です。反対に、ページを分けずに日別の page_view 数だけなら、event_params を読まないので 27.7 MB で、例の集計の約12.5分の1でした。ユーザーやセッションの数え方そのものは、GA4×BigQuery 連携の記事で同じサンプルを使って比べています。

同じ集計を繰り返すとき：ワイルドカードの照会はキャッシュされない

BigQuery は、同じクエリの結果を通常およそ24時間キャッシュに残し、キャッシュから返したクエリは課金しません。ただし、ワイルドカードで複数の表を照会したクエリは、キャッシュの対象外です。［キャッシュされた結果を使用］をオンにしていても、同じワイルドカードのクエリを流すたびに課金されます（ワイルドカード テーブルのページの「制限事項」、キャッシュに保存されているクエリ結果を使用する）。例の集計を1日分（1月31日）にして、2回ずつ流して確かめました。

1つの表を直接読んだクエリは、2回目がキャッシュから返って課金 0 でした。events_* で読んだクエリは、_TABLE_SUFFIX で1つの表に絞っていても、この実行では2回目もキャッシュが使われず、また 10 MiB 課金されました。ダッシュボードや定期実行で同じ集計を何度も流すと、その回数分だけ課金が積み上がります。

金額の目安も書いておきます。このサンプルは US マルチリージョンにあるので、オンデマンドの単価は 1 TiB あたり 6.25 米ドルです（東京リージョン asia-northeast1 は 7.50 米ドル）。毎月最初の 1 TiB は無料です（BigQuery の料金）。例の集計の1回の課金は 329 MiB なので、無料枠の 1 TiB は約3,187回分です。日付の条件を書かない形なら1回 1,247 MiB で、約840回分になります。1回あたりの金額は、無料枠を考えずに US の単価で換算しても約0.002米ドルと小さく、このサンプルが3か月で約 3.6 GB しかないためです。自社のエクスポートで同じ比べ方をするなら、自社の表で dry run した量を使ってください。

同じ集計を繰り返し見るなら、公式のベストプラクティスにある「クエリ結果を段階的に実体化する」（途中の結果を宛先の表に書いておき、小さな表を照会する）形にすれば、毎回 events_* を読み直さずに済みます（費用の見積もりと管理）。当社の今回の検証では、この形は試していません。

読みすぎた1本は、課金の上限で止める

1本のクエリが課金される量の上限が「課金される最大バイト数」です。コンソールではクエリエディタの［展開］→［クエリ設定］→［詳細オプション］、bq コマンドでは --maximum_bytes_billed、API では maximumBytesBilled で指定します。見積もりが上限を超えると、クエリは実行前に失敗し、料金はかかりません（費用の見積もりと管理）。サブクエリで日付を渡した例の集計（92日分を読む書き方）を、上限 400 MiB で実行すると、次のエラーで止まり、課金は 0 でした。

Query exceeded limit for bytes billed: 419430400. 1307574272 or higher required.

エラーにある 1,307,574,272 バイトは、dry run の見積もり 1,307,207,146 バイトを MiB 単位に切り上げた値です。1月分なら 400 MiB に収まるはずの集計が、この数字で止まったことで、書き方の誤りに実行前に気づけます。

自社のエクスポートに当てはめる前に

ここまでの数字は、難読化された3か月分のサンプルでの値です。自社のエクスポートでは、日数・1日のイベント数・送っているパラメータの数で量が変わります。比べ方（どの書き方で表が減り、どの列が重いか）は同じ形で確かめられますが、MB の数字はそのまま使えません。そのうえで、サンプルには無く、当社が試していないことを、公式の記述から書いておきます。

ストリーミングのエクスポートを有効にすると、当日のデータが events_intraday_YYYYMMDD という表に書かれ、その日の events_YYYYMMDD ができると消えます（アナリティクス ヘルプ「BigQuery Export」）。ワイルドカードは接頭辞で始まる表に全部一致するので、events_* を条件なしで読むと、当日の intraday の表も含まれます。_TABLE_SUFFIX BETWEEN '20260901' AND '20260930' のように数字の日付で範囲を書いていれば、intraday_ で始まる値は文字列として範囲の外になるので、含まれません。

日次の表は、その日と、その後2暦日まで更新されます（ヘルプの例では、1月1日の表は1月4日まで）。過去のデータの再処理が要るときは、その期間の後でも更新されることがある、とヘルプは書いています（同じページ）。直近の数日を毎朝集計し直す運用では、同じ日の表を何度も読むことになるので、上の「段階的に実体化する」形で貯めるときも、直近の数日は読み直す前提で組みます。

公式は、日付ごとに表を分ける形（シャーディング）より、パーティション分割した表を勧めています（ワイルドカード テーブルのページ）。パーティションとクラスタの使い方はクエリの最適化の記事に書いています。

自分の表で、同じ集計を dry run してから流す

次にやることは、自社のエクスポートに例の集計を dry run してみることです。データセット名と期間を替えれば、そのまま使えます。コンソールなら、エディタに貼るだけで、チェックマークと一緒に処理量が出ます。

-- データセット名を自社のもの（analytics_ のあとにプロパティ ID）に替える
SELECT
  (SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'page_location') AS page_location,
  COUNT(*) AS page_views
FROM `your-project.analytics_123456789.events_*`
WHERE _TABLE_SUFFIX BETWEEN '20260901' AND '20260930'
  AND event_name = 'page_view'
GROUP BY page_location
ORDER BY page_views DESC
LIMIT 10

bq コマンドなら、1行目のように --dry_run を付けると量だけが返り、2行目のように --maximum_bytes_billed（この例は 1,000,000,000 バイト）を付けて流すと、見積もりが上限を超えたときは実行前に止まります。

bq query --use_legacy_sql=false --dry_run 'SELECT …（上の SQL）'
bq query --use_legacy_sql=false --maximum_bytes_billed=1000000000 'SELECT …（上の SQL）'

出てきた量を、日付の条件を外したとき・SELECT * にしたときの量と比べると、自社の表で何日分・どの列がどれだけ重いかが分かります。そのうえで、毎日流す集計を小さな表に貯めるかどうかを決めていきます。

GA4 のエクスポートを、どの集計を貯めてどの画面から読むかまで含めて設計するところは、当社のBigQuery 導入支援で一緒に進められます。

料金と仕様は、2026年10月14日に Google Cloud の公式ドキュメントと料金ページ、アナリティクス ヘルプ、Google アナリティクスの開発者向け文書で確かめたものです。処理量は、2026年10月14日に当社の検証用プロジェクトから Google の公開サンプルに流した dry run と実行の結果です。料金は変わることがあるので、見積もりの前に公式の料金ページを開いてください。