クラウド請求が突然10倍になった：誰が・何を・なぜ走らせたか

「先月の BigQuery 請求書、桁違うんですけど」── データチームの心臓に悪い瞬間。原因の9割は「悪意なき新人 or 試行錯誤中のエンジニア」。コスト爆発を防ぐには、事故が起きてからの調査ではなく、事故が小さいうちに気付く監視が必要。

起きる仕組み（よくある TOP5）

1. 1`SELECT *`：BigQuery は列指向課金、SELECT * で全列スキャン → 10x のコスト
2. 2フィルタなし JOIN：パーティション/クラスタリングが効かない結合
3. 3dbt full refresh の暴走：本来 incremental のモデルがフル再構築モードで毎晩走ってる
4. 4View の再帰実体化：view を view から呼んで、結果的に毎回フルスキャン
5. 5コミットされてない探索クエリ：Notebook で 100 回 SELECT を試した結果

調査手順

SELECT  user_email,  TIMESTAMP_TRUNC(creation_time, DAY) AS day,  job_id,  total_bytes_processed / POW(10, 12) AS tb,  total_bytes_processed / POW(10, 12) * 6.25 AS estimated_usd,  REGEXP_EXTRACT(query, r'FROM\s+([^\s,]+)') AS first_table,  queryFROM `region-us`.INFORMATION_SCHEMA.JOBS_BY_ORGANIZATIONWHERE creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)  AND statement_type IN ('SELECT', 'MERGE')ORDER BY total_bytes_processed DESCLIMIT 30;

SELECT  user_name, warehouse_name, query_id, query_text,  credits_used_cloud_services + warehouse_size_credits AS total_credits,  TIMESTAMP_TRUNC(start_time, DAY) AS dayFROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY qJOIN SNOWFLAKE.ACCOUNT_USAGE.WAREHOUSE_METERING_HISTORY w USING (warehouse_id)WHERE q.start_time >= DATEADD(day, -30, CURRENT_TIMESTAMP)ORDER BY total_credits DESC LIMIT 30;

短期対処

• 該当ユーザに即連絡：意図のあるクエリか、テスト・誤実行か
• job/query を kill：継続中のものを止める
• 該当 dbt model を一時停止：cron / Airflow から外す
• 経理に状況連絡：突発であれば交渉でクラウド側のクレジット還元あり

中長期対策

• Budget Alert：日額しきい値で Slack 通知（BigQuery / Snowflake / AWS（Amazon Web Services） いずれもネイティブ機能あり）
• Per-user 制限：BigQuery の maximum bytes billed、Snowflake の resource monitor
• SELECT * 禁止 lint：sqlfluff・dbt の lint ルールで CI（Continuous Integration） でブロック
• レビュー必須化：本番クエリ実行は Dataform / dbt 経由のみ、PR レビュー必須
• 継続モニタ：cost dashboard（Looker Studio で誰でも見える）+ 異常検知（前週比 +50%）
• FinOps 文化：チーム別コスト配賦 → コスト意識が定着

ふくふくの進め方

コスト診断は2週間：① 直近30日のクエリログを集計、② TOP20 をダッシュボード化、③ 自動アラート + lint + 予約スロット予算化を提案。「事故が起きる前に気付く」体制を3週間で。請求書のショック対応の常連です。