BigQuery Editions vs On-demand｜料金モデルの選び方と損益分岐点【2026年版】

「請求書が読めないので、Editionsに切り替えたほうがいいか判断してほしい」。BigQueryを1年以上使っているお客様から、このご相談が増えています。

オンデマンドで運用してきた基盤に定期実行や社内ダッシュボードが積み上がり、月次コストが2〜3倍にじわじわ伸びる。そこで料金モデルの見直しが議題に上がるのですが、Editionsはスロット単位の課金、オンデマンドはスキャン量課金と、そもそも比較する単位が違います。稟議に上げようとすると「切り替えたら本当に下がるのか」を数字で示せず、判断が止まる。

そこで本記事では、東京リージョンの実額でオンデマンドとEditions(Standard / Enterprise / Enterprise Plus)を並べ、月次スキャン量からみた損益分岐点、INFORMATION_SCHEMAでの使用量把握、Autoscaler設計の勘どころまで、稟議と設計会議でそのまま使える形で整理しました。BigQueryそのもののコスト削減施策(SELECT * の潰し方やパーティション設計)はBigQueryの料金体系とコスト削減7手｜課金トラップと最大30%減の実践策で扱っているので、こちらは料金モデルの選択判断に軸足を置いています。

オンデマンドとEditions、そもそも何が違うのか

BigQueryのコンピュート料金は、現在「オンデマンド」と「Editions(Capacity)」の2本立てです。ストレージ料金は共通で、違いはクエリ実行にかかるコンピュート部分だけです。

オンデマンドは、クエリが読み込んだデータ量(スキャン量)に対して1TBあたり課金する方式です。プロジェクトを作った直後はこれが既定で、初期設定なしで使えます。「クエリを投げた分だけ払う」ため、利用量が少ない・読めない段階と相性が良いモデルです。

Editionsは、処理能力を「スロット」という単位で時間貸しする方式です。スロットは並列処理の粒度で、100スロットを1時間確保すれば「100スロット時間」ぶんの料金がかかります。クエリを何本走らせても、スロットの確保量と時間で請求が決まるので、大量クエリを回すほど単価が安くなります。Editionsにはさらに Standard / Enterprise / Enterprise Plus の3グレードがあり、使える機能と単価が段階的に上がります。

ややこしいのは、どちらのモデルも「読み書きしたストレージ」「Streaming Insert」「Storage API」などの周辺料金は別で発生することです。以下では、議論の中心になるコンピュート料金と、切り替え判断に直結する Autoscaler の挙動に絞って掘り下げます。

東京リージョンの実額で並べる

料金は US マルチリージョンと東京(asia-northeast1)で異なります。稟議に載せるのは東京の実額のほうなので、こちらに揃えて並べます(2026年9月時点の Google Cloud 公表値を基準にしています。最新値は必ず公式ページで確認してください)。

オンデマンドの料金

東京は US のおおむね1.2倍と覚えておけば、稟議上の粗い試算には十分です。

Editionsの料金(1スロット時間あたり)

Standard はコミット割引の対象外で、常に PAYG(Pay As You Go)単価です。Enterprise と Enterprise Plus はコミットで単価が下がり、3年コミットの Enterprise は東京で $0.0459/スロット時間 まで落ちます。

覚えておきたい単純換算

• オンデマンド 1TB スキャン ≒ Enterprise で 100スロット × 約1.6時間 相当
• 100スロットを24時間 × 30日 常時確保 = 72,000スロット時間 = 東京 Enterprise で 月 $5,508
• 同じ 100スロットを 1日8時間 × 20営業日だけ確保 = 16,000スロット時間 = 東京 Enterprise で 月 $1,224

「常時確保」と「使う時だけ確保」で 4〜5 倍の差が出るのが、Editions を扱ううえでの第一の勘どころです。

損益分岐点はどこか

「うちはオンデマンドと Editions のどちらが安いか」に一発で答える式はありませんが、月次スキャン量と実行タイミングの2軸で見ると判断できます。

月次スキャン量ベースの目安

東京リージョンで単純比較すると、次の水準が一つの目安になります。

実行タイミングも重要

同じ 20TB/月でも、次の2ケースはコスト構造が違います。

• A社(バッチ集約型): 毎朝2時間、100スロット分の重いバッチが集中して走る → Editions + Autoscaler(baseline=0, max=200) で 月 $306 程度
• B社(常時稼働型): BIツールから終日クエリが飛び続け、50〜100スロットを常に消費 → Editions + 年次コミット(50スロット常時確保) で 月 $2,754

同じスキャン量でも、実行が集中するほど Editions のメリットが出やすくなります。逆に散発的で予測困難な使い方だけなら、オンデマンドのほうが安いケースがあります。

図のように、月次スキャン量とワークロードの形状の2段階で判断すると迷いが減ります。

自分のワークロードをINFORMATION_SCHEMAで見える化する

判断の元になるのは、体感ではなく実測です。オンデマンドで運用している環境なら、次の2本のクエリで「今の使い方だと Editions に切り替えて得か損か」の一次判断ができます。

スキャン量と月額オンデマンド換算を出す

-- 過去30日、プロジェクト全体の月額オンデマンド換算(東京)
SELECT
  DATE_TRUNC(DATE(creation_time, 'Asia/Tokyo'), MONTH) AS month,
  SUM(total_bytes_billed) / POW(1024, 4)              AS tb_scanned,
  ROUND(SUM(total_bytes_billed) / POW(1024, 4) * 7.5, 2) AS usd_on_demand
FROM `region-asia-northeast1`.INFORMATION_SCHEMA.JOBS
WHERE creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
  AND job_type = 'QUERY'
  AND statement_type != 'SCRIPT'
GROUP BY month;

このクエリで 月次スキャン量(TB) と オンデマンド換算の月額 が出ます。ここが5TBを超えていれば、Editions の検討が視野に入ります。

スロット消費の時系列を出す(Editions換算の下地)

-- 過去7日、1分単位のスロット消費(Editions換算の下地)
SELECT
  TIMESTAMP_TRUNC(period_start, MINUTE) AS minute,
  SUM(period_slot_ms) / 1000 / 60       AS slots_used
FROM `region-asia-northeast1`.INFORMATION_SCHEMA.JOBS_TIMELINE_BY_PROJECT
WHERE period_start >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY)
GROUP BY minute
ORDER BY minute;

これを Looker Studio や BigQuery Studio の可視化に流せば、時間帯ごとのスロット消費山谷 が見えます。ピークが日中1〜2時間だけに集中していれば Autoscaler と相性が良く、フラットに広がっていれば baseline を高めに置くコミット構成が向きます。

Evast の現場で見る典型パターン

支援先の環境を最初に覗くと、次の3パターンに大別できます。

• 朝バッチ + 昼のBIピーク型: バッチ集約なので Editions + Autoscaler が最も効きます
• 終日フラット消費型: 常時確保のコミットを主軸にし、Autoscaler は余剰に少しだけ振る構成が向きます
• アドホック分析中心型: 散発的すぎて Editions では逆に高くつくため、オンデマンド継続が正解の場合もあります

「Editions のほうが常に安い」は誤解です。実測を先に取ってください。

Editionsの3グレードの選び方

Editions を選ぶと決めたあと、Standard / Enterprise / Enterprise Plus のどれを取るかで機能と料金が変わります。単価順に並べると差は約1.5倍・2.5倍ですが、選定の主要因は機能要件のほうです。

Standard Edition ── 開発環境と小規模用途

料金が最安(東京 $0.051/スロット時間)ですが、以下の制約があります。

• 1年・3年コミット割引の対象外(常に PAYG 単価)
• ベースラインスロットは 0 固定(常時確保はできない)
• BI Engine、列レベルのセキュリティ、CMEK、VPC Service Controls が 使えない

現実的には、開発/検証プロジェクト か、社内数人が触る小規模データマート の本番用にとどめておくのが安全です。本番の分析基盤で Standard を選ぶと、後述の Enterprise 機能が必要になった時に切り替えコストが発生します。

Enterprise Edition ── 本番の標準

多くの本番ワークロードはここが選択肢になります。東京 $0.0765/スロット時間で、Standard の1.5倍ですが、次の機能が使えるようになります。

• BI Engine(高速インメモリ集計、Looker Studio や BI ツールの応答改善)
• 列レベル・行レベルのセキュリティ(部門ごとの見え方制御)
• VPC Service Controls(社内ネットワークからのみアクセス許可)
• クロスユーザーのクエリキャッシュ共有
• 1年 / 3年のコミット割引(3年で最大 40% 減)

BI ツールを本格運用するかセキュリティ要件があるなら、Standard で始めても早晩 Enterprise への移行を迫られます。最初から Enterprise で組んだほうが手戻りが減ります。

Enterprise Plus Edition ── 規制業界向け

東京 $0.1275/スロット時間で Enterprise の1.67倍。ここまで払う理由は、CMEK(顧客管理暗号鍵) が使えることに尽きます。

• CMEK による顧客側での暗号鍵管理
• 規制業界(金融・医療・行政)の暗号鍵運用要件を満たす
• Enterprise の全機能に加え、最高水準の可用性・災害復旧オプション

FISC 対応が求められる金融データ基盤、HIPAA を意識する医療系、政府調達の分析基盤などが対象です。裏を返せば、これらの要件が 明示的にない プロジェクトでは Enterprise Plus は過剰です。金融業界のデータ基盤設計については保険業界のデータ基盤とは？BigQuery・Databricks活用の費用と作り方【2026年版】で、業界特有の規制対応と組み合わせて整理しています。

オンデマンドからEditionsに切り替える前に確認する4点

「損益分岐は超えている、機能もEnterpriseで良さそう」となっても、切り替え直後に想定外の請求が来て慌てる現場は少なくありません。事前に潰しておきたい落とし穴が4つあります。

1. baselineスロットを甘く設定しない

Editions は「確保している時間ぶん」に課金されます。baseline=100 スロット を24時間確保してしまうと、実際にクエリが1本も走っていない時間帯にも料金が発生します。

夜間バッチだけの環境なら baseline=0 で問題ありません。日中のBIレスポンスが1〜2秒遅れるのが許容できないケースだけ、必要最小限のbaselineを置く判断にしてください。

2. max_slots(上限)を無制限にしない

Autoscaler の上限を「無制限」または非現実的に高くすると、暴走クエリや誤った JOIN で数千スロットが一気に湧いて、日次請求が数十万円振れる事故が起きます。

平常時のピーク消費の1.5〜2倍 を上限の初期値にし、CloudMonitoring でスロット消費のアラートを併設するのが基本です。

3. コミット期間を先に決めすぎない

「安くなるなら3年コミットを最初から」と稟議に上げがちですが、切り替え直後は実消費が読めないため、3ヶ月ほどPAYG(コミットなし)の Enterprise で運用し、実消費が固まってからコミット割引に移すほうが安全です。3年コミットは途中解約が難しい商用契約と同じ性質を持ちます。

4. オンデマンド専用のクエリチューニングは一度見直す

オンデマンド時代に「SELECT * を潰す」「パーティションを刻む」といったスキャン量削減の最適化を積んでいた場合、Editions に切り替えるとその努力がコスト削減にはつながらなくなります(スキャン量ではなくスロット時間の課金になるため)。

代わりにEditionsでは、同時に走るクエリ数と1クエリあたりの実行時間 が支配的です。夜間バッチが直列でつながって全体が長引いている場合、並列化して短時間に押し込むだけで確保時間が減り、コストが下がります。切り替えのタイミングで、チューニング指標を「スキャン量」から「スロット時間」に読み替えることを設計チーム内で明示的に共有してください。

BigQuery そのもののコスト最適化パターンはBigQueryの料金体系とコスト削減7手｜課金トラップと最大30%減の実践策、データ基盤全体のランニングコスト削減の考え方はデータ基盤のランニングコストを下げる5つのコストダウン施策と落とし穴にまとめています。

まとめ ── 「まずオンデマンド、伸びたらEditions」で十分

BigQuery の料金モデル選択について、Evast が現場で採っている基本方針はシンプルです。

• 導入初期(月次1〜5TB): オンデマンドで十分。無料枠に収まることも多い
• 成長期(月次5〜15TB): INFORMATION_SCHEMA で実測を取り、集中実行なら Editions を検討
• 本格運用期(月次15TB〜): Editions Enterprise が基準。実消費が固まったら年次コミットで最大40%減
• 規制業界: 要件があるプロジェクトのみ Enterprise Plus

料金モデルは一度決めたら固定するものではなく、四半期に1回は INFORMATION_SCHEMA でスキャン量とスロット消費を見直し、モデルの妥当性を再点検する運用が現実的です。

Evast では、既存 BigQuery 環境の料金モデル診断と Editions 移行後の Autoscaler チューニングまでを一気通貫で支援しています。請求書が読めない・Editions に切り替えるべきか判断がつかない段階でも、まずは お問い合わせ から現状を共有いただければ、月次スキャン量と実消費ベースの一次診断をお返しします。

BigQuery 全体の導入設計から入りたい場合は、BigQuery導入ガイド｜手順・料金・無料枠・費用相場【2026年版】、他クラウドDWHとの費用比較はクラウドデータウェアハウスの費用比較から読み進めるとスムーズです。