Contents
スポンサードリンク
1. 2026 年版料金体系とリソース選択
| 項目 | 内容 |
|---|---|
| オンデマンド課金 | スキャンしたデータ量（TB）ごとに $5 USD が課金されます。 ※公式: On‑demand pricing 2026 年改定版 |
| 予約スロット（フラットレート） | 1 スロットは $0.04 USD/時間（約 $350 USD/年）で確保できます。 ※公式: Flat‑rate pricing の「Slot price」欄 |
| 適用シーンの目安 | 月間スキャン量が 10 TB 以上 の場合は、予約スロットへの移行がコスト削減に有効です。 |
1‑1. コストシミュレーション（2026 年版）
| シナリオ | 月間スキャン量 | オンデマンド費用 (5 USD/TB) | 予約スロット必要数* | 年額コスト |
|---|---|---|---|---|
| 小規模開発 | 0.3 TB | $1.5 | 0 スロット（オンデマンドで十分） | $18 (年間オンデマンド) |
| 中規模分析 | 30 TB | $150 | 1 スロット（30 TB ÷ 10 TB/スロット が目安） | $350 (フラットレート) + $0 (追加オンデマンド) = $350 |
| 大規模レポート | 300 TB | $1,500 | 10 スロット（300 TB ÷ 30 TB/スロット が目安） | $3,504 (=10×$350) |
*「予約スロット必要数」は、1 スロットで概算 10‑30 TB/月 を処理できるというベンチマーク（Google Cloud公式サンプル）を元にしています。実際の利用状況に合わせてスロット数は調整してください。
ポイント
- 月間スキャンが 10 TB 未満 ならオンデマンドで柔軟性を確保。
- 10‑30 TB の範囲では 1 スロット が最もコスト効率的。
- 30 TB 超えるケースはスロット数を段階的に増やすと、オンデマンド費用との差が大きくなります。
2. クエリ実行コスト削減テクニック
2‑1. 必要カラムだけ取得する（SELECT * 回避）
| 手順 | 内容 |
|---|---|
| 課題 | SELECT * はテーブル全体をスキャンし、不要な列まで課金対象にします。 |
| 対策 | 使用する列名を明示的に指定するだけで、スキャン量が 30‑70 % 程度削減できます（BigQueryベストプラクティス実測例）。 |
| 実装例 | sql -- 悪い例 SELECT * FROM sales_raw WHERE sale_date >= '2024-01-01'; -- 良い例 SELECT sale_id, product_id, amount, sale_date FROM sales_raw WHERE sale_date >= '2024-01-01'; |
測定方法：
INFORMATION_SCHEMA.JOBS_BY_PROJECTのtotal_bytes_processedをクエリ実行前後で比較し、削減率を算出してください。
2‑2. 列指向フォーマット（Parquet／ORC）への変換
| 項目 | 内容 |
|---|---|
| 利点 | 列単位でデータを格納するため、必要な列だけが読み込まれ、スキャン量が 約 70 % 減少します。 |
| 手順 | sql CREATE OR REPLACE TABLE dataset.sales_parquet OPTIONS (format='PARQUET') AS SELECT * FROM dataset.sales_raw; |
| 効果例 | 同一クエリで CSV テーブルが 10 TB スキャンした場合、Parquet では 約 3 TB にまで削減（公式ベンチマーク参照）。 |
2‑3. ビュー／マテリアライズドビューの活用
| 手順 | 内容 |
|---|---|
| 目的 | 複雑な集計ロジックを毎回実行せず、結果をキャッシュ（保存）して再利用する。 |
| 実装例 | sql CREATE MATERIALIZED VIEW dataset.mv_daily_sales AS SELECT DATE(sale_date) AS day, SUM(amount) AS total_amount FROM dataset.sales_parquet GROUP BY day; |
| 注意点 | マテリアライズドビューは 24 時間以内に更新されるデータを対象とし、クエリ実行時のスキャンはほぼ 0 USD に近くなります（キャッシュ利用）。 |
3. テーブル設計：パーティショニング & クラスタリング
| 機能 | 効果 | 設計指針 |
|---|---|---|
| パーティション | データを日付や地域単位で分割し、不要なパーティションのスキャンを防止。 削減率は 90‑95 % が目安（ベストプラクティス測定）。 |
WHERE 句で頻出する列（日付・地域）をパーティションキーに設定。 |
| クラスタリング | 同一キーでソートされたブロック単位でデータが格納され、フィルタや集計時のスキャンが更に削減。 追加削減率は 20‑30 % 程度。 |
パーティション後に、region や product_id など高カーディナリティかつ絞り込み頻度が高い列をクラスタリング対象にする。 |
実装例（日付パーティション＋地域クラスタリング）
|
1 2 3 4 5 6 |
CREATE TABLE dataset.sales_partitioned PARTITION BY DATE(sale_date) CLUSTER BY region, product_id OPTIONS (format='PARQUET') AS SELECT * FROM dataset.sales_raw; |
ベストプラクティス
1. パーティションは 過剰分割を避け、月単位または日単位 が推奨。
2. クラスタリング列は 高カーディナリティかつフィルタで頻繁に使用 するものに限定。
4. ストレージコストとデータロードの最適化
4‑1. Cold Storage 自動移行
| 手順 | コマンド例 |
|---|---|
| ライフサイクルポリシー作成（365 日経過で自動Cold） | bq update --storage_tier=COLD --expiration=365d project_id:dataset |
| テーブル単位で適用 | sql ALTER TABLE dataset.sales_partitioned SET OPTIONS (storage_tier='COLD'); |
- 効果：Cold Storage の単価は $0.007 USD/GB/月（標準ストレージ $0.02 USD/GB/月）で、保存コストが 約 65 % 削減できます（公式料金表参照）。
4‑2. バルクロードへ切り替える
| 項目 | 内容 |
|---|---|
| 問題点 | ストリーミングインサートは1 行あたり $0.005 USD の書き込み単価がかかり、頻繁に実行するとコストが膨らむ。 |
| 代替策 | bq load --source_format=PARQUET で日次・週次バッチロードを実施し、1 回あたりのデータ量は 10 TB 以下 に抑える。 |
| 自動化例（Cloud Scheduler + Cloud Functions） | bash # 毎日 02:00 に起動 gcloud scheduler jobs create pubsub daily-load --schedule="0 2 * * *" --topic=load-topic --message-body='{"dataset":"sales","date":"$(date -d yesterday +%F)"}' |
4‑3. 不要バックアップの定期削除
|
1 2 3 4 |
-- 180 日以上前に作成されたテーブルを一覧化 SELECT table_name FROM `project.dataset.INFORMATION_SCHEMA.TABLES` WHERE creation_time < TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 180 DAY); |
- 削除コマンド：
bq rm -t project_id:dataset.table_name - 効果：不要テーブルが占めるストレージ容量を定期的に回収し、無駄な課金を防止。
5. BI Engine とマテリアライズドビューでダッシュボード高速化
| 機能 | 特徴 | コスト算出 |
|---|---|---|
| BI Engine | メモリ上にデータキャッシュ（GB 単位）を保持し、クエリ応答時間を 数百ミリ秒 に短縮。 | slot_capacity（例：500 GB）× $0.02 USD/GB/月 で課金。（公式料金ページ参照） |
| マテリアライズドビュー | 集計結果を自動更新し、再利用時はストレージ読み取りのみ。 | ビューの保持コストは対象テーブルと同等のストレージ費用だけで、クエリ実行料はほぼ 0 USD に近い。 |
実装例（月次売上サマリー）
|
1 2 3 4 5 6 7 8 |
CREATE MATERIALIZED VIEW dataset.mv_monthly_sales AS SELECT EXTRACT(YEAR FROM sale_date) AS yr, EXTRACT(MONTH FROM sale_date) AS mo, product_id, SUM(amount) AS total_amount FROM dataset.sales_parquet GROUP BY yr, mo, product_id; |
- ダッシュボードでの利用：
SELECT * FROM mv_monthly_sales WHERE yr=2024 AND mo=1;はフルスキャンが不要なため、実行コストは 0 USD に近い。
コスト可視化（Looker Studio + Cloud Monitoring）
- BigQuery メタデータテーブル
INFORMATION_SCHEMA.JOBS_BY_PROJECTを元に、日次のスキャン量・課金額を算出するクエリを作成。 - Looker Studio に接続し、折れ線グラフで「TB スキャン量」「USD 課金額」の推移を表示。
- Cloud Monitoring のメトリクス
bigquery.googleapis.com/query/bytes_processedに対して 日次平均 > 15 TB（予算上限の 150 %）というアラートポリシーを設定し、メール通知で異常検知。
6. 実装チェックリスト & 次のアクション
| 項目 | 確認ポイント |
|---|---|
| 料金シミュレーション | オンデマンド vs 予約スロットの表を最新料金で作成。 |
| SELECT * の排除 | 全クエリでカラム指定に置き換え、total_bytes_processed が減少したか検証。 |
| 列指向フォーマット | テーブルが FORMAT='PARQUET' もしくは ORC になっていることを確認。 |
| パーティション・クラスタリング | パーティションキーとクラスタリング列が適切に設定され、スキャン削減率が 80 % 以上か測定。 |
| Cold Storage ポリシー | ライフサイクルポリシーが有効で、古いパーティションが自動的に Cold に移行しているか。 |
| バルクロード化 | ストリーミングインサートが停止し、bq load ジョブがスケジュール通り実行されているか。 |
| BI Engine & マテリアライズドビュー | ダッシュボードでのクエリ応答時間が 300 ms 未満に改善されたか。 |
| 可視化・アラート | Looker Studio のコストダッシュボードと Cloud Monitoring アラートが稼働中。 |
推奨プロセス
- 第1週：料金シミュレーション表作成＋オンデマンド/予約スロット比較。
- 第2‑3週：クエリ改修（
SELECT *排除、Parquet 変換）とパーティショニング実装。 - 第4週：Cold Storage ポリシー適用・バルクロード化、バックアップテーブル削除。
- 第5週：BI Engine とマテリアライズドビューを対象ダッシュボードに導入し、応答時間測定。
- 第6週以降：コストメトリクスの定期レビューとスロット数・BI Engine 容量の微調整。
最終的な目標は「月間スキャン量 × コスト = 最適化後の費用」が 30 % 以上削減 できる状態です。効果が出たら、さらにスロット予約数や BI Engine のキャパシティを再評価し、継続的な最適化サイクルへ移行してください。
本稿の内容は執筆時点（2026 年 4 月）における公式情報に基づいています。料金改定や機能追加があった場合は、必ず最新ドキュメントをご確認ください。
スポンサードリンク