クラウドDWHの課金は「ストレージ」と「コンピュート」に分かれます。dbt運用で跳ねるのはほぼコンピュート、つまり仮想ウェアハウスの稼働時間（Snowflakeならクレジット、BigQueryならスキャン量、DatabricksならDBU）。「容量を増やす」のは安いが、「動かし続ける」のは高い、と覚えておくのが第一歩です。

跳ねる典型原因は6つ。materialization選定ミス（大きなテーブルがtable）、ウェアハウスサイズ過剰、full-refreshの乱用、auto_suspendが長い、ジョブの並行衝突、使われていないGoldマートが毎晩構築。順に潰します。

いちばん効くのが各モデルのmaterialization見直しです。view（実体なし）、table（毎回作り直し）、incremental（差分追記）、snapshot（履歴管理）の4つを使い分けます。「大きなテーブルがtableのまま」は典型のコスト無駄遣い。incrementalに切り替えるだけで変換時間が桁違いに下がります。

判断軸はシンプル：軽い変換と参照少ならview、中規模で複雑な更新があるならtable、大規模で追加中心ならincremental、履歴管理が要るならsnapshot。先回りで全モデルincrementalにすると運用が複雑化するので、「重くなってから切り替える」が現実的です。

1つのウェアハウスで全てをさばくと、用途の違う処理が干渉してコストが膨らみます。dbt変換用（WH_DBT_TRANSFORM）、BI参照用（WH_BI）、アドホック分析用（WH_ADHOC）と最低3つに分け、サイズと auto_suspend を用途で変えます。

dbt用はauto_suspend 60秒・サイズ小〜中、BI用はキャッシュを残すためauto_suspend 300秒・マルチクラスタで同時実行に対応。「Lで30分」と「Sで60分」はクレジット消費が同じケースもあるので、計測してから上げます。

「念のため」作ったマートが、誰にも使われていないのに毎晩構築されている、というのは現場で頻発します。SnowflakeのACCESS_HISTORYやQUERY_HISTORYから過去30日参照されていないテーブルを洗い出し、enabled: falseで止めるか削除します。

dbtのexposuresを書いていれば「BIから参照されているか」も追跡できます。「query_tag」でモデル別クレジット消費を可視化し、「重いトップ10」に最適化の工数を集中させる、というアプローチが最も投資効率が高いです。

個別の最適化が一巡したら、次は「コストが見える状態を維持する」運用に移ります。月次のクレジット消費レポート、重いクエリ上位ランキング、新規モデル追加時のコスト試算（PRレビュー時にチェック）、四半期での未使用モデル棚卸し。これらを定例化すると、再度コストが跳ねるのを未然に防げます。

カタログ（DataHub・Atlan等）と連携すると「このモデルは何のために、いくらかけて、誰のために動いているか」が見えるようになり、Data Productとしての責任分担も明確になります。コストはガバナンスの一部、と捉えるのが成熟した運用です。