のコスト管理は、運用が回り始めると後回しになりがち。気付くと月$1万を超えていた、というのはよくある話です。今回は「読む・抑える・予測する」の3階層でコストを把握する実装を共有します。
Layer 1: 読む（INFORMATION_SCHEMA で見える化）
ユーザー別・テーブル別の月次コスト
SQL
-- BigQuery 過去30日のユーザー × テーブル別スキャン量SELECT user_email, REGEXP_EXTRACT(query, r'FROM `([^`]+)`') AS scanned_table, ROUND(SUM(total_bytes_billed) / POW(10, 12), 2) AS scanned_tb, ROUND(SUM(total_bytes_billed) / POW(10, 12) * 5, 2) AS estimated_usdFROM `region-us`.INFORMATION_SCHEMA.JOBS_BY_PROJECTWHERE creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY) AND statement_type = 'SELECT'GROUP BY 1, 2ORDER BY scanned_tb DESCLIMIT 30;Layer 2: 抑える（カスタムクォータ）
ユーザー単位の日次クエリ上限を設定すると、誤って巨大クエリを投げても上限で止まります。新人がジョインした直後の事故防止にも有効。
おすすめ初期値
個人ユーザー: 100GB/日、開発サービスアカウント: 500GB/日、本番ジョブ用アカウント: 制限なし。これだけで「うっかり事故」の9割を防げます。
Layer 3: 予測する（月予算アラート）
claude-code でコスト分析を生成
BigQueryのINFORMATION_SCHEMAから過去90日のジョブログを取得して、以下のレポートを生成してください。
1. 月次コストの推移グラフ
2. ユーザー別の累計コスト TOP10
3. 「無駄に大きい」クエリTOP10（スキャン量に対して結果行数が極端に少ない）
4. 削減提案（パーティション切替・マテリアライズドビュー化など）
出力: notebooks/bq-cost-report.ipynb 想定される実行結果（例示）
## コスト削減提案レポート（90日分析）
### 月次コスト推移
- 4月: $4,200 → 5月: $5,800 → 6月: $7,100（伸び率 +35%）
- 主要因: マーケ部門のアドホック分析が増加
### 無駄クエリ TOP3
1. `SELECT * FROM events_log` - 月12回 / 3.2TB / 結果使用率 5%
2. パーティション無視のJOIN - 月8回 / 1.8TB
3. 同じCTE再計算 - 月23回 / 0.9TB
### 推奨アクション
- 上位3件を materialized view 化 → 月次 $2,800 削減見込み
- マーケ部門に「カスタムクォータ200GB/日」設定
- 古いテーブルを longterm-storage 価格帯へコスト最適化の典型パターン 5 選
- SELECT *を禁止**：列指定で必要なものだけ。10 倍以上スキャン量が変わる
- パーティション：日付列で `WHERE event_date = '2026-05-01'` だけスキャン
- ：頻出フィルタ列でクラスタリング、フルスキャン回避
- マテビュー / 集約テーブル：日次集計を事前計算しておく（ EP.22 と同じ思想）
- ジョブの取り消し閾値：1 時間超のジョブは自動キャンセル（カスタムクォータ）
「無料枠」の罠
には月 1TB の無料枠があるが、本番運用では数日で使い切る。「無料だから安心」は通用しない前提で予算管理を。
ふくふくの進め方
「BigQuery のコストが読めず予算超過」というご相談には、過去 3 ヶ月のジョブログ分析（1 週間）→ コスト削減提案 → 仕組み実装を 1 ヶ月で。月 50%〜70% カットは普通に達成できる範囲です。
次回予告
EP.08 は、エンジニアが介在せずデータが回る「セルフサービス 」の設計。 のセマンティック層と Looker の統合運用パターンを掘り下げます。
この記事の感想を教えてください
あなたの 1 クリックで、本当にこの記事は更新されます。「もっと詳しく」「続編希望」が一定数集まった記事は、 ふくふくが 実際に内容を拡充したり続編記事を公開 します。 送信したリアクションはお使いのブラウザに記録され、再カウントされません。