BigQueryの容量ベース料金 vs オンデマンド料金を実データで比較する

「BigQueryの料金プランって、定額のほうが安くなるんですか？」

データ基盤の相談をいただくと、ある程度運用に慣れてきた方からこんな質問を受けることがあります。月々の請求を見ながら、「もしかして定額契約に切り替えたほうがお得なのでは」と気になり始めるタイミングです。

結論を先にお伝えすると、中小ECや個人事業主の規模であれば、ほとんどのケースでオンデマンド（従量課金）のほうが安く済みます。ただし、これは「スキャン量がそれほど多くない」という前提があってのことです。本当にどちらが得かは、自社のスキャン量を測って判断するのが一番確実です。

この記事では、BigQueryの2つの課金モデルの違いと、損益分岐の考え方、そして自社のスキャン量を測る方法を整理します。なお、ここで扱うのは「どちらの課金モデルを選ぶか」という中長期の設計判断です。今日明日の請求をまず下げたいという方は、月1万円以下に抑える7つの実践テクニックのほうが目的に近いはずです。

はじめに：結局どちらが安いのか

最初に全体像を押さえておきます。BigQueryのクエリ課金には、大きく分けて2つのモデルがあります。

モデル	課金の対象	向いている規模
オンデマンド	クエリが読んだデータ量（スキャン量）	利用量が少〜中規模・変動が大きい
容量ベース（Editions）	予約した処理能力（スロット）の時間	利用量が多く・安定して走り続ける

ざっくり言えば、オンデマンドは「使った分だけ」、容量ベースは「処理能力を借りる定額（に近い）」です。携帯電話の従量プランと使い放題プランの関係に少し似ています。たくさん使う人ほど定額が得になり、たまにしか使わない人は従量のほうが安い、という構図です。

中小ECの多くは「たまにしか使わない」側に位置するため、オンデマンドが基本的に有利になります。とはいえ、なぜそうなるのかを理解しておくと、将来データ量が増えたときに判断を間違えずに済みます。

ここで一つ注意したいのは、「定額」という言葉のイメージに引っ張られないことです。定額と聞くと「上限が決まっていて安心」という印象を持ちがちですが、容量ベースは「使わなくても払う」固定費でもあります。利用が少ない月でも料金は変わりません。逆にオンデマンドは、使わない月は請求が下がります。この非対称性が、規模によって有利不利が入れ替わる理由です。

2つの課金モデルの違い

オンデマンド：スキャン量に対する課金

オンデマンド課金は、クエリが読み込んだ（スキャンした）データ量に対して料金が発生します。テーブルの保存量でも、実行回数でもなく、1回のクエリで何バイト読んだかがコストを決めます。

目安として、オンデマンドは1TB（テラバイト）のスキャンあたり約 $6.25 です。さらに、毎月最初の1TBは無料という枠もあります（リージョンや時期で変動します）。

このモデルの良いところは、使わなければ課金されないという点です。月に数回しかクエリを叩かない月があっても、その分だけ請求が下がります。利用量に波がある中小ECとは相性が良いモデルです。

一方で弱点もあります。それは、設計を誤った重いクエリ（全期間スキャンや SELECT * など）を投げると、その1回でスキャン量が跳ね上がり、コストが読みにくくなる点です。オンデマンドは「無駄なスキャンがそのまま請求に乗る」モデルでもあるため、列の絞り込みやパーティション設計でスキャン量を抑える工夫がそのままコスト削減につながります。

容量ベース（Editions）：スロットの予約に対する課金

もう一方の容量ベース課金は、BigQuery Editions という枠組みで提供されています。ここで課金の単位になるのが「スロット」です。スロットとは、クエリを処理するための仮想的な計算リソース（CPUのようなもの）だと考えてください。

容量ベースでは、このスロットを一定数確保し、その確保している時間に対して料金を払います。スキャン量がいくら大きくても、確保したスロットの範囲内で処理する限り、追加のスキャン課金は発生しません。つまり「処理能力を時間貸しで借りる」イメージです。

Editions には Standard / Enterprise / Enterprise Plus といった段階があり、使える機能や単価が変わります。また、スロットの確保には次の3つの方式があります。

オンデマンド的に自動で増減する方式（オートスケール）
1年や3年の長期コミットで単価を下げる方式
必要なときだけ確保する方式

長期コミットを選ぶほど単価は下がりますが、その分「使わなくても払う」固定費の性格が強まります。ここがオンデマンドとの最大の違いです。

容量ベースのメリットは、コストの予測がしやすいことと、スキャン量が大きくても料金が膨らまないことです。毎日決まった重いバッチを走らせる運用では、オンデマンドだと請求が変動しますが、容量ベースなら金額が読めます。逆にデメリットは、利用が少ない時間帯でも確保したスロットぶんの料金が発生する点と、スロット数の設計・調整という運用の手間がかかる点です。少人数で回している中小ECには、この手間が割に合わないことが多いです。

損益分岐の考え方

では、どのくらいスキャンするとオンデマンドより容量ベースが得になるのでしょうか。考え方そのものはシンプルです。

オンデマンドのコストは「月間スキャン量 × 単価」で増えていきます。スキャンすればするほど青天井に上がります。一方、容量ベースのコストは「確保したスロット × 時間」で、おおむね一定です。たくさんクエリを走らせても料金は変わりません。

つまり、横軸にスキャン量、縦軸にコストを取ると、オンデマンドは右肩上がりの直線、容量ベースはほぼ水平な線になります。この2本が交差する点が損益分岐です。スキャン量がこの交点を超えると容量ベースが得になり、下回るならオンデマンドが得、という関係です。

ごく粗い試算で感覚をつかんでみます。仮に容量ベースで最小規模のスロットを常時確保した場合、月の固定費は数万円規模になることが多いです。一方オンデマンドは1TBあたり約 $6.25 なので、月数万円ぶんのスキャンとなると、おおよそ数十TBを毎月読む計算になります。

月間スキャン量	オンデマンドの目安	判断
1TB未満	無料枠内（実質0円）	オンデマンド一択
数TB	数十〜数百円	オンデマンドが圧倒的に安い
数十TB	数千〜1万円台	まだオンデマンド有利なことが多い
数百TB以上・常時稼働	数万円超	容量ベースの検討余地が出てくる

中小ECの受注・会員・GA4ログを設計よく扱えば、月間スキャン量は数GB〜せいぜい数TBに収まります。この表で言えば、損益分岐のはるか手前です。だからこそ「中小ECはオンデマンド寄り」という結論になります。

なお、この数字はあくまで考え方を示すための粗い目安です。実際のスロット単価や最小構成は変わるため、判断材料は次に説明する「自社の実測値」です。

よくある勘違い

損益分岐を考えるときに陥りやすい誤解を、いくつか挙げておきます。

「定額のほうが必ず安い」——使わない時間帯ぶんも払うため、利用量が少ないと割高になります。
「保存料金とクエリ料金を混同する」——ここで比較しているのはクエリ（処理）の料金です。データの保存料金は別建てで、どちらのモデルでも発生します。
「無料枠を忘れる」——オンデマンドには毎月1TBの無料枠があり、小規模なら実質0円に近づきます。容量ベースにはこの枠の概念がありません。

これらを取り違えると、本来オンデマンドで十分なのに容量ベースへ乗り換えて固定費を増やしてしまう、という事故が起きます。

INFORMATION_SCHEMA で自社のスキャン量を測る

損益分岐を自分の数字で考えるには、実際に月間でどれだけスキャンしているかを知る必要があります。BigQuery には INFORMATION_SCHEMA という、クエリの実行履歴を記録したビューがあり、ここから過去のスキャン量を集計できます。

まずは直近30日間の合計スキャン量と、その概算コストを出してみます。

-- 直近30日のスキャン量と概算コスト（リージョンは環境に合わせて変更）
SELECT
  SUM(total_bytes_billed) / POW(1024, 4) AS billed_tb,
  ROUND(SUM(total_bytes_billed) / POW(1024, 4) * 6.25, 2) AS est_usd
FROM
  `region-asia-northeast1`.INFORMATION_SCHEMA.JOBS
WHERE
  creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
  AND job_type = 'QUERY'
  AND state = 'DONE'
  AND statement_type != 'SCRIPT';

total_bytes_billed は実際に課金対象となったバイト数です（無料枠適用前の値なので、目安として見てください）。これをTBに換算し、1TBあたり $6.25 を掛けて概算コストを出しています。region-asia-northeast1 の部分は、テーブルを置いているリージョンに合わせて書き換えてください。

次に、どのクエリやユーザーがスキャン量を押し上げているかを見ます。重いクエリ上位を洗い出すと、削減の余地が見えてきます。

-- スキャン量の多いクエリ上位10件
SELECT
  user_email,
  ROUND(total_bytes_billed / POW(1024, 3), 2) AS billed_gb,
  query
FROM
  `region-asia-northeast1`.INFORMATION_SCHEMA.JOBS
WHERE
  creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
  AND job_type = 'QUERY'
  AND state = 'DONE'
ORDER BY
  total_bytes_billed DESC
LIMIT 10;

この2つを定期的に眺めるだけでも、「うちは月に何TB読んでいるのか」「容量ベースを検討するラインに近いのか」がはっきりします。多くの中小ECでは、ここで出てくる数字が損益分岐のはるか手前であることに気づくはずです。

スキャン量の継続的な監視については、INFORMATION_SCHEMA でコストを監視する記事でより詳しく扱っています。

中小ECはオンデマンド寄りという結論

ここまでを踏まえると、中小ECがオンデマンドを基本にすべき理由は次のように整理できます。

月間スキャン量が損益分岐のはるか手前にあり、容量ベースの固定費を払う合理性がない
利用量に波がある（繁忙期だけ分析が増える等）ため、使った分だけ課金されるほうが無駄がない
毎月1TBの無料枠があり、設計しだいで実質0円に近づけられる
スロット管理やコミット判断といった運用の手間がかからない

逆に、容量ベースを検討する価値が出てくるのは、毎日大量のバッチが常時走り、月間スキャンが数百TB規模に達し、しかもコストが読みやすい安定運用になっている場合です。中小ECでこの状態に至るケースはまれですが、事業が成長してデータ量が跳ね上がったときには、改めて実測値で見直す価値があります。

なお、容量ベースとオンデマンドはプロジェクト単位で切り替えられるため、「分析用は容量ベース、それ以外はオンデマンド」といった使い分けも可能です。ただしこれは規模が大きくなってからの話で、まずはオンデマンドで無駄なスキャンを減らすことが先決です。コスト削減の具体策は月1万円以下に抑えるテクニックの記事にまとめています。

⚠️ 料金について

本記事の金額（1TBあたり約 $6.25、無料枠1TBなど）は2026年時点のおおよその目安です。リージョン・時期・Editions の段階によって変わり、スロットの単価や最小構成も改定されることがあります。実際に契約・プラン変更する前に、必ず公式の最新料金を確認してください。

まとめ

BigQueryの課金モデルは、使った分だけのオンデマンドと、処理能力を借りる容量ベース（Editions）の2種類です。どちらが安いかは月間スキャン量で決まり、損益分岐を超えるほど大量に・安定して使うなら容量ベース、そうでなければオンデマンドが有利になります。

中小ECの規模では、スキャン量は損益分岐のはるか手前にあるのが普通です。まずは INFORMATION_SCHEMA で自社の実測値を出し、その数字を見て判断するのが確実です。多くの場合、答えは「オンデマンドのまま、無駄なスキャンを減らす」に落ち着きます。

料金は変わるものなので、最終的な判断の前には公式の最新情報を確認してください。自社の数字に基づいて、過不足のないプランを選んでいきましょう。

自社のスキャン量を実測して損益分岐を確認する、というここまでの作業を自分でやる時間が取れない、あるいは INFORMATION_SCHEMA の集計結果をどう設計に落とし込めばいいか判断がつかない、ということもあると思います。そうした場合は、実測から料金プランの選定、その後のテーブル設計までを一緒に整理することもできます。詳しくはBigQueryのデータ基盤構築・運用サービスをご覧ください。