E 会計/ファイナンス・コスト効率 — BigQuery オンデマンド vs flat-rate 損益分岐点 Bad→Good（「コストが青天井で不安」で損益分岐点未計算 × 実測ピークスロット消費(240)から必要スロットを逆算すると300スロット=$5,100/月 × 損益分岐点は340TB/月ではなく1,020TB/月 × SELECT *・パーティションフィルタ欠如15モデルの最適化で147TB/月に削減 × スロット不足によるバッチSLA違反リスク）（MOps 販促システムチーム dbt Core 45モデル/Argo Workflows/BigQuery Bad→Good 7点）

概要

問題

ECサイト MOps チームのシニアエンジニアとして、BigQuery のコスト構造レビューを任された。現在はオンデマンド課金（$5/TB スキャン）で運用しているが、後輩エンジニアが「クエリ数が増え続けてコストが青天井なのが不安なので、今すぐ flat-rate（定額）に切り替えるべき」という Bad コスト比較メモを作成し、来週のインフラ定例でこのまま提案する予定だという。

以下の Bad メモから 試算・設計上の問題（7点）を洗い出し、損益分岐点（スキャン量ベース）の計算・実測に基づくスロット容量計画・クエリ最適化案・オンデマンド維持案とflat-rate案の比較・インフラ定例への推奨文までを一気通貫で回答してください。

制約・前提条件

• 料金前提: オンデマンド $5/TB スキャン / flat-rate $1,700/月・100スロット（100スロット単位で追加可能） / 為替 1USD=150円
• dbt Core モデル（Argo Workflows経由、毎晩2:00〜3:30 JSTのバッチウィンドウ内完走がSLA）: 45モデルを最大8並列で実行
  • うち15モデル（stagingレイヤー、旧パターン）はSELECT *かつパーティションフィルタなしで月間40TBをスキャン。増分データのみ対象にすれば月間5TBまで削減可能
  • 残り30モデルは既に最適化済みで月間80TBをスキャン（削減余地は小さい）
• アドホックBIダッシュボード（Looker Studio、9-21時に15分間隔更新、12ダッシュボード）: mart層（クラスタリング未設定）に対し月間62TBをスキャン
• 月間スキャン量の推移（実測）: 3ヶ月前145TB → 2ヶ月前162TB → 直近182TB（月次成長率 約+12%）。直近の月額オンデマンド請求額 = 182TB×$5 = $910/月
• nightly dbtバッチの実測ピーク同時消費スロット数（95パーセンタイル）: 240スロット
• エンジニア単価: 80万円/月（20営業日=4万円/人日）。クエリ最適化作業見積もり: 15モデル×0.5人日=7.5人日

悪いコスト比較メモ (Before)

📋 コピー件名: BigQuery flat-rate 移行のご提案

現状: オンデマンド課金（$5/TB）
  クエリが増え続けており、今後もコストが青天井になる不安がある
← 問題①②③: 損益分岐点未計算・現状の逆転関係見落とし・
   成長トレンドを使った到達時期試算なし

改善案: flat-rate（$1,700/月・100スロット）へ今すぐ切り替える
  月額固定になるので、クエリ数がいくら増えても$1,700/月で
  使い放題になり、コストの見通しが立つようになる
← 問題④: 根本原因(非効率クエリ)の最適化を検討せず
   課金方式だけで解決しようとしている
← 問題⑤⑥: 100スロットに実測根拠なし、
   スロット不足によるバッチSLA違反リスク未検討

よって flat-rate（100スロット）への切り替えを提案します。
← 問題⑦: 単一案のみで代替案との比較なし

ヒント（段階的開示）

【損益分岐点の骨格】
損益分岐スキャン量(TB/月) = flat-rate月額 ÷ オンデマンド単価
  100スロット想定(誤り):  $1,700 ÷ $5 = 340TB/月
  300スロット実測ベース:  $5,100 ÷ $5 = 1,020TB/月

【到達時期の骨格（複利成長）】
現在の月間スキャン量 × (1+成長率)^n = 損益分岐スキャン量
  n = ln(損益分岐スキャン量 ÷ 現在の月間スキャン量) ÷ ln(1+成長率)

【クエリ最適化後の月間スキャン量】
最適化後 = (現状182TB − レガシー15モデル40TB) + 最適化後レガシー分5TB
         = 142TB + 5TB = 147TB/月

問題点分析（7点）

損益分岐点比較 — 想定100スロット vs 実測ベース300スロット

模範解答

📋 コピー到達時期 n = ln(損益分岐スキャン量 ÷ 現状スキャン量) ÷ ln(1+成長率)

最適化前(182TB基準):
  n = ln(1,020 ÷ 182) ÷ ln(1.12)
    = ln(5.604) ÷ ln(1.12)
    = 1.723 ÷ 0.1133 ≒ 約15.2ヶ月後

最適化後(147TB基準):
  n = ln(1,020 ÷ 147) ÷ ln(1.12)
    = ln(6.939) ÷ ln(1.12)
    = 1.937 ÷ 0.1133 ≒ 約17.1ヶ月後

📋 コピーflat-rate（100スロット、$1,700/月）への即時切替は、実測データに
基づかない試算です。オンデマンドの現行コストは$910/月であり、
切り替えるとむしろ月額が上がります。また、nightly dbtバッチの
実測ピークスロット消費量（240スロット）から必要スロット数を
計算すると、実際には300スロット（$5,100/月）が必要であり、
想定していた100スロットではバッチSLA（3:30終了）を守れない
リスクがあります。

損益分岐点は実測ベースで1,020TB/月であり、現状182TB/月・
成長率+12%/月でも到達には約15ヶ月かかります。まずは
SELECT *とパーティションフィルタ欠如が残る15のレガシー
stagingモデルを最適化し（工数7.5人日）、月間スキャン量を
147TBまで削減することを推奨します。これにより月額コストを
$910から$735に抑えつつ、将来flat-rateへ移行する際の
必要スロット数（延いてはコスト）自体を圧縮できます。

flat-rateへの切替は、実測スロット使用量とスキャン量の成長
トレンドを継続的にモニタリングし、必要性が定量的に裏付け
られた時点で再検討します。

ポイント解説

実務への応用

MOpsチームのようにdbtバッチとBIダッシュボードの両方でBigQueryを使うチームでは、「クエリ数・データ量が増えてきたので定額プランへ」という発想に流れやすい。しかし実務では、コスト増加の内訳（バッチの非効率クエリなのか、BIの高頻度アクセスなのか）を分解し、根本原因に手を打ってから課金方式の見直しを検討する順序が重要になる。INFORMATION_SCHEMAベースでスロット使用量・スキャン量を継続的にモニタリングする仕組みをdbtパイプラインやDataDogダッシュボードに組み込んでおけば、「切り替えるべきタイミング」を勘ではなく数字で判断できるようになる。

今日のまとめ

次のステップ

• 発展問題: クエリ最適化実施から6ヶ月後、月間スキャン量が想定(147TB×1.12^6≒290TB)よりも早いペースで損益分岐点(1,020TB/月)の半分の水準に達し、BIダッシュボードの新規追加（マーケティング部門から月10件のペースで依頼）が主因と判明した。このとき、(1)flat-rateへの切替を前倒しすべきか、(2)BI Engineでダッシュボード側のスキャンをキャッシュ化してオンデマンドを維持すべきかを、それぞれのコスト構造（固定費化 vs キャッシュ容量課金）を比較した上で判断せよ。
• 参考: BigQuery オンデマンド課金 / flat-rate（スロット予約） / INFORMATION_SCHEMA.JOBS_BY_PROJECT / パーティションフィルタ / クラスタリング / BI Engine / 損益分岐点分析

自己評価（あとで記入）