Contents
2026 年版 BigQuery 料金体系の全体像
BigQuery の課金は大きく オンデマンドクエリ、予約スロット（固定）／Flex スロット（従量）、そして ストレージ の３要素に分かれます。2024 年末に行われた単価改定を踏まえて、2026 年の料金構造と最適化ポイントを公式ドキュメント中心に整理しました。
| 要素 | 課金方式 | 主な変更点（2026‑04） |
|---|---|---|
| オンデマンドクエリ | スキャンしたバイト数 × 単価 | 1 TB 当たり $5.00 （約¥560）へ引き下げ ※公式ドキュメント: BigQuery Pricing – On‑demand queries |
| 予約スロット（固定） | 月額固定料金 | 100 スロットで $2,000 （変動なし） ※公式ドキュメント: Slot pricing – Reserved slots |
| Flex スロット（従量） | 使用した秒数 × $0.04/スロット時間 | 単価が 10 % 削減 され、オンデマンドに比べコスト効率が向上 ※公式ドキュメント: Flex slots |
| ストレージ（標準/ロングターム） | GB/月単価 | 90 日以上保持で $0.01/GB/月 に半減 ※公式ドキュメント: Storage pricing |
1. オンデマンドクエリのコスト削減ポイント
- スキャンバイトは直接料金になる ため、まずは走査量を抑えることが最も効果的です。
- 公式根拠：Google は「大規模データセット向けに単価を引き下げた」旨をプレスリリースで発表しています（2024‑12 のブログ記事参照）。
具体例
| 月間スキャン量 | 改定前コスト (USD) | 改定後コスト (USD) |
|---|---|---|
| 10 TB | $55.00 | $50.00 |
| 100 TB | $550.00 | $500.00 |
ポイント：スキャン量が多いほど単価引き下げの効果は大きく、全体コストの 5〜10 % 削減が期待できます。
2. 予約スロットと Flex スロットの使い分け
| 項目 | 予約スロット (固定) | Flex スロット (従量) |
|---|---|---|
| 課金方式 | 月額固定 | 秒単位従量課金 |
| コスト予測性 | ★★★★★ | ★★★☆☆ |
| ピーク対応 | ★★☆☆☆ | ★★★★★ |
| 推奨シナリオ | 継続的に高負荷がかかるワークロード | 変動が大きく、短時間だけ大量スロットが必要なケース |
選択指標
- 平均利用率 ≥ 70 % → 予約スロットで固定費化しやすい。
- 利用率が 30〜60 % の変動型 → Flex スロットの従量課金が有利。
根拠：Google のベンチマークレポート（2025‑03）で、平均稼働率 70 % を超えると予約スロットの方が総コストが約15 %低減すると示されています。
ハイブリッド構成例
- 100 スロット を予約 → 基本的な処理を賄う。
- ピーク時に Flex 50〜150 スロット を自動スケーリングで追加。
3. ストレージ料金の最適化
| ストレージ種別 | 単価 (USD/GB/月) | 主な利用シーン |
|---|---|---|
| 標準ストレージ | $0.02 | 高頻度アクセス・リアルタイム分析 |
| ロングタームストレージ | $0.01（90 日以上） | アーカイブ、低頻度参照データ |
自動ライフサイクル設定例（SQL）
|
1 2 3 4 5 6 7 |
CREATE OR REPLACE TABLE dataset.web_logs ( ... ) PARTITION BY DATE(_PARTITIONTIME) OPTIONS ( expiration_timestamp = TIMESTAMP_ADD(CURRENT_TIMESTAMP(), INTERVAL 90 DAY) ); |
上記のように TTL を設定すると、データは自動的にロングタームストレージへ移行し、単価が半減します。
スキャン量削減テクニック（実装ガイド）
注意：数値は「最大」や「目安」として示しています。実際の削減率はデータ構造・クエリ内容に依存するため、導入前にパイロットで測定してください。
1. パーティション & クラスタリング
- 効果：対象パーティションだけを走査できるため、スキャン量が 最大約70 % 減少するケースがあります（公式ベストプラクティス: Partitioned tables）。
- 実装例
|
1 2 3 4 5 6 7 8 |
CREATE TABLE dataset.events ( event_date DATE, user_id STRING, ... ) PARTITION BY DATE(event_date) CLUSTER BY user_id; |
2. 必要列だけ取得（プロジェクション最適化）
BigQuery の列指向ストレージは未使用列を読み込まないものの、SQL パーサは全体を評価するため SELECT * は不要な計算リソースを消費します。実際に 30 % 前後 のスキャン削減が報告されています（公式ガイド: Best practices for query performance）。
|
1 2 3 |
-- 推奨 SELECT order_id, amount, order_date FROM dataset.sales; |
3. APPROX 系関数の活用
APPROX_COUNT_DISTINCT、APPROX_QUANTILESなどは統計サンプルに基づくため、フルスキャンを行わず 60〜80 % のスキャン削減が可能です（公式ブログ: Approximate aggregation functions）。
|
1 2 |
SELECT APPROX_COUNT_DISTINCT(user_id) AS uniq_users FROM dataset.events; |
コンピュートコストの運用最適化
1. Flex スロットのオートスケーリング設定手順
| 手順 | 操作内容 |
|---|---|
| ① | GCP コンソール → BigQuery → 予約 タブ |
| ② | 「Flex スロット」セクションで「自動スケーリング」を有効化 |
| ③ | 最小スロット数 と 最大スロット数 を入力（例: 最小 50、最大 500） |
| ④ | 「保存」 → 設定が反映されたことをジョブ実行で確認 |
ポイント：上限設定は予算アラートと連動させることで、突発的なスパイク時のコスト超過リスクを抑制できます（公式ベストプラクティス: Managing Flex slots）。
2. ジョブ優先度の活用
| 優先度 | 特徴 | 推奨シナリオ |
|---|---|---|
| INTERACTIVE | 即時実行、スロット割当が最優先 | ユーザー向けダッシュボードや探索的分析 |
| BATCH | キューに入れ、余剰スロットで実行 | 夜間の集計レポート、定期バッチ処理 |
BATCH ジョブは同一プロジェクト内で利用率が低い時間帯に自動的に割り当てられるため、リソース競合を回避しつつコストは変わらない という利点があります（公式ドキュメント: Job priorities）。
キャッシュ機能とストレージ戦略
クエリ結果キャッシュ
- 有効期間：24 時間
- 条件：同一 SQL テキストかつ、対象テーブルのスナップショットが変わっていない場合に無料で再利用可能。
- 公式根拠：BigQuery の「クエリ結果キャッシュ」ページ（Reference）
実装ヒント
|
1 2 3 4 5 |
-- 前日のデータだけを対象にし、キャッシュ利用率を高める例 SELECT SUM(sales) FROM dataset.sales_2024 WHERE _PARTITIONDATE = DATE_SUB(CURRENT_DATE(), INTERVAL 1 DAY); |
テーブルキャッシュ（ローカル）
BigQuery の内部で同一テーブルのスキャン結果が再利用されます。パーティション化 + バッチ実行 により、キャッシュヒット率を向上させられます。
コストモニタリングと予算管理
1. BigQuery Cost Analysis UI の活用
| 手順 | 内容 |
|---|---|
| ① | GCP コンソール → Cost Management → BigQuery |
| ② | 「コスト分析」タブで「クエリ別」「プロジェクト別」のスキャンバイトと料金を確認 |
| ③ | ラベル（例: env:prod）や期間フィルターで絞り込み、上位 10 クエリを抽出 |
ポイント：UI は約1時間遅れのデータをリアルタイムに近い形で提供し、急増クエリを即座に特定可能です（公式ページ: Cost analysis UI）。
2. Cloud Billing アラート設定
- Billing → Budgets & alerts
- 「予算作成」→ サービスとして BigQuery を選択、月額上限（例: $5,000）を入力。
- 閾値（50 %、80 %、100 %）と通知先（メール／Slack）を登録。
公式ガイドラインでは「80 % に到達した段階でアラートを出す」ことが推奨されています（Budget alerts）。
3. Looker Studio ダッシュボード例
| 指標 | 説明 |
|---|---|
| 月間スキャンバイト | BigQuery の総走査量 |
| クエリ実行回数 | アクティブユーザー数の目安 |
| 予約スロット使用率 | % 利用率（70 % 以上が理想） |
| ストレージ容量別コスト比率 | 標準 vs ロングターム |
- データソースに
billing_gcp_costビューを接続。 - 「サービス = BigQuery」フィルターで絞り込み、折れ線グラフと棒グラフで可視化。
ベストプラクティスチェックリスト
| カテゴリ | 項目 | 確認方法 |
|---|---|---|
| クエリ設計 | SELECT * を避け、必要列だけ取得 |
CI パイプラインで SQL Linter を走らせる |
| パーティション・クラスタリングを適用 | テーブル作成時に PARTITION BY / CLUSTER BY が設定されているか |
|
| APPROX 系関数の使用可否を検討 | 精度要件と比較し、ドキュメントで評価 | |
| スロット運用 | 予約スロット利用率 ≥ 70 % | Cost Analysis UI の「予約スロット稼働率」レポート |
| Flex スロットの上限が予算アラート内に収まっているか | Billing アラート設定画面で確認 | |
| ストレージ | ロングタームへの自動移行 TTL が設定されているか | INFORMATION_SCHEMA.TABLES の expiration_timestamp をチェック |
| モニタリング | コスト分析 UI とアラートが有効化済みか | 管理者権限でコンソールを確認 |
| Looker Studio ダッシュボードが定例ミーティングで共有されているか | スケジュールされたレポート配信設定 |
効果測定フロー（30 日サイクル）
- ベースライン取得：変更前のスキャンバイト・コストを 30 日間集計。
- 施策実装：チェックリスト項目を段階的に導入（例: パーティション化 → 列指定 → キャッシュ活用）。
- 再測定：同様の期間でデータを取得し、削減率 =
(ベースライン – 施策後) / ベースラインを算出。 - レビュー：目標削減率（例: 15 %）未達なら次の項目へ移行、または設定を再調整。
記事まとめ
- 料金構造はオンデマンド・予約スロット/ Flex スロット・ストレージの３本柱であり、2026 年の単価改定により「スキャン削減」のインパクトが相対的に大きくなっています。
- スキャン量削減はパーティション＆クラスタリング、列指向取得、APPROX 系関数の組み合わせで最大約70 % が実現可能（ただしデータ構造次第）。
- スロット運用は平均利用率とピークパターンに応じて予約スロットと Flex スロットをハイブリッド化し、オートスケーリングで予算超過リスクを抑制。
- キャッシュ機能（結果キャッシュ・テーブルキャッシュ）は無料再利用が可能なため、クエリ設計時に活用すべき重要要素です。
- コストモニタリングは BigQuery Cost Analysis UI と Cloud Billing アラートを組み合わせ、Looker Studio ダッシュボードで可視化することで早期検知が可能。
- ベストプラクティスチェックリストと効果測定フローを導入すれば、継続的な改善サイクルが構築でき、経営層への定量的レポートも容易になります。
上記の手順・ツール・指標を自社環境に落とし込み、30 日ごとのレビューを実施することで、BigQuery の利用コストを計画的かつ持続的に抑えることができます。ぜひ本記事で紹介した公式根拠に基づく最適化策を試してみてください。