1件もクエリを流していない夜間に、Snowflakeのクレジットが延々と溶け続けていた。Evastでお客様の環境を引き継いだとき、この場面に本当によく出くわします。
管理画面のクレジット消費グラフが、朝方まで一直線に伸びているのを見て、担当者の顔がこわばる。あの瞬間、見覚えがある方は少なくないと思います。
正直に言うと、原因はクエリの書き方ではなく、ほとんどが「ウェアハウスの止め忘れ」と「サイズの選び方」です。Snowflakeが読み込んだデータ量ではなく、計算リソースが動いている時間で課金する仕組みだからこそ、静かにクレジットが溶けます。逆に、この2点さえ押さえれば、月額を半分以下にできるケースは珍しくありません。
料金体系の基本、BigQueryとの課金モデルの違い、現場でよく見る課金トラップ、そして削減の設計原則までを、実務目線で見ていきます。
なお、記載する単価はすべて2026年時点・AWS米国リージョンの目安で、実額はリージョン・クラウド・契約・エディションで変わります。
Snowflakeの料金は、大きく3つの層に分かれます。
多くの現場では、費用の7〜8割をコンピューティング（ウェアハウス）が占めます。つまりコスト最適化の主戦場は、ここになります。
コンピューティングの課金単位が「クレジット」です。基準はシンプルで、X-Smallウェアハウスを1時間動かすと1クレジットを消費します。
やっかいなのは、ウェアハウスのサイズが1段階上がるごとに、クレジット消費が倍になることです。
| サイズ | クレジット/時 |
|---|---|
| X-Small | 1 |
| Small | 2 |
| Medium | 4 |
| Large | 8 |
| X-Large | 16 |
| 2X-Large | 32 |
| … | … |
| 6X-Large | 512 |
Largeを選べば、同じ1時間でもX-Smallの8倍のクレジットを消費します。処理が8倍速く終わるとは限らないため、サイズ選びはそのまま費用に跳ね返ります。
ウェアハウスの課金は秒単位ですが、起動・再開・サイズ変更のたびに最低60秒分が発生します。5秒で終わるクエリのためにウェアハウスを起動しても、実際には1分以上課金される、と覚えておくと安全です。
ストレージは、Snowflakeが自動圧縮した後のサイズに課金されます（データにもよりますが、数分の1に圧縮されることが多いです）。目安はAWS米国リージョンのオンデマンドで月あたり1TBにつき$23前後ですが、東京リージョンは割高になる傾向があり、前払いのキャパシティ契約なら単価が下がります（2026年時点の目安）。
クラウドサービス層には「10%ルール」があります。1日のクラウドサービス消費が、その日のウェアハウス消費の10%以内なら無料で、超えた分だけ課金される仕組みです。通常の使い方では、ここが大きな費用になることはあまりありません。
同じ1クレジットでも、エディションによって単価が変わります。目安はAWS米国リージョンのオンデマンドで、Standardが約$2、Enterpriseが約$3、Business Criticalが約$4です（2026年時点の目安）。
米国外のリージョンは1〜6割ほど上乗せされる傾向があり、東京リージョンも割高です。見積もり時は、どのリージョン・どのエディションの単価かを押さえておくと、想定とのズレを防げます。
同じクラウドDWHでも、SnowflakeとBigQueryでは課金の考え方が根本的に違います。ここを理解すると、最適化の勘所が正反対になることが分かります。
たとえるなら、BigQueryは「タクシー」です。走った距離（スキャン量）で料金が決まるので、無駄な遠回り（不要なカラムの全件スキャン）を減らすことが節約になります。BigQueryの課金トラップと対策はBigQueryの料金体系とコスト削減｜課金トラップと対策で詳しく解説しています。
一方のSnowflakeは「レンタカー」です。借りている時間（稼働時間）で料金が決まるので、用が済んだらすぐ返す（ウェアハウスを止める）こと、そして目的に合った車格を選ぶ（適正サイズにする）ことが節約になります。
つまり、BigQueryでは「読むデータを減らす」、Snowflakeでは「稼働時間を減らし、サイズを適正化する」ことが、コスト最適化の中心になります。両者の料金・性能を7つの軸で比較した選び方は、SnowflakeとBigQuery比較：コスト・性能・機能の違いと選び方で整理しています。
稼働時間課金という仕組みを踏まえると、コストが膨らむパターンには共通点があります。現場で繰り返し見かける6つを紹介します。
稼働中のウェアハウスは、1件もクエリが来なくてもクレジットを消費し続けます。仮にMediumを止め忘れると、Standardのクレジット単価（約$2）で計算して1時間あたり約$8（4クレジット分）、24時間放置すれば約$192相当になります（2026年時点のクレジット単価での計算例）。
「電気をつけっぱなしの会議室」を思い浮かべると分かりやすいでしょう。誰もいなくても、照明（ウェアハウス）が点いていれば電気代（クレジット）は流れ続けます。
小さなクエリに大きなウェアハウスを割り当てるパターンです。サイズは1段階ごとにクレジットが倍になりますが、並列度の低い小さなクエリでは、サイズを上げても処理はほとんど速くなりません。荷物1個の配送に大型トラックを呼ぶようなもので、速く着くわけでもないのに料金だけが倍々でかさみます。
auto-suspend（一定時間クエリが来なければ自動停止する設定）が未設定だと、ウェアハウスは動きっぱなしになります。逆に長すぎても、待機している間のアイドル課金が増えます。目安は5〜10分で、短すぎる設定は起動コストが増えて逆効果です。
マルチクラスタウェアハウス（同時実行が増えたときにクラスタを増やす仕組み）には、需要に応じて増減させるAuto-scaleモードと、指定台数を常時起動するMaximizedモードがあります。Maximizedのまま運用すると、負荷に関係なく全クラスタが動き続けて課金されます。基本はAuto-scaleモードで最小クラスタを1にしておくのが安全です。
自動クラスタリングやマテリアライズドビューなどのServerless機能は、ウェアハウスとは別にクレジットを消費し、機能ごとに乗率（倍率）が設定されています。
| 機能 | クレジット乗率 |
|---|---|
| 自動クラスタリング | 2 |
| マテリアライズドビュー保守 | 2 |
| Search Optimization | 2 |
| Snowpipe（データ取り込み） | 1.25 |
※乗率は2026年時点の目安です。Serverless系は改定されることがあり、Snowpipeはとくに料金モデルの見直しが進んでいます。
自動クラスタリングは裏でデータを継続的に並べ替えるため、更新頻度の高いテーブルにかけるとクレジットを食います。マテビューも元テーブルが更新されるたびに保守コストが発生します。
Time Travel（過去の状態を遡れる機能）は、変更・削除前のデータを保持します。既定は1日（永続テーブルの場合。トランジェント・一時テーブルは最大1日）ですが、Enterprise以上では最大90日まで延ばせます。その後ろには、変更できない7日間のFail-safeが続きます。保持期間を延ばすほど、変更・削除したデータのコピーがストレージに積み上がります。
Evastの現場では：コスト調査でまず見るのは、派手なクエリよりも「動きっぱなしのウェアハウス」と「サイズが用途に合っていないウェアハウス」です。ACCOUNT_USAGEでウェアハウス別のクレジット消費を並べると、アイドル時間の課金が全体の3割前後を占めていた、という例は珍しくありません。派手な改修の前に、まず止め方とサイズを見直すのが近道です。
トラップの裏返しが、そのまま削減策になります。優先度の高い順に整理します。
特にリソースモニターは、後から「請求を見て驚く」を防ぐ最初の一手です。構築の初期段階で、部門やウェアハウス単位に上限を決めておくことをおすすめします。
削減は「どこにいくらかかっているか」を把握してから始めます。Snowflakeでは、SNOWFLAKE.ACCOUNT_USAGE スキーマの各ビューで、消費の内訳を棚卸しできます。BigQueryでいう INFORMATION_SCHEMA.JOBS に相当する入口です。
まずはウェアハウス別のクレジット消費を上位から並べ、アイドル時間の割合と、サイズが用途に合っているかを確認します。これを月に一度行うだけで、無駄なコストの多くは見つかります。
Snowflakeそのものの仕組みや導入メリットの基礎は、Snowflakeとは？クラウドDWHの特徴と導入メリットを解説で整理しています。
Snowflakeのコスト最適化の要点を、あらためて整理します。
Snowflakeは使い始めのハードルが低い分、設定を見直さないままだとコストがじわじわ膨らみます。逆に言えば、止め方・サイズ・上限という設計を最初に決めておけば、費用は十分にコントロールできます。
Snowflakeに限らず、DWH・ETL・BIを含めたデータ基盤全体のランニングコストの下げ方はデータ基盤のランニングコスト削減｜4要素別の見直し方で、構築費用まで含めた費用相場はデータ基盤構築の費用相場は？見積もりの内訳と判断基準を解説でまとめています。BigQuery・Redshiftも含めた3社の費用比較はクラウドDWH費用比較｜BigQuery・Snowflake・Redshiftで整理しています。
株式会社Evastでは、Snowflakeを活用したデータ基盤の設計・構築から、コスト最適化までを支援しています。ウェアハウスの適正化やリソースモニター設計、使用状況の可視化など、設計段階に踏み込んだ相談に対応します。
現状診断から改善提案まで、お気軽にご相談ください。
クラウドDWHのBigQuery・Snowflake・Redshiftを費用で比較します。スキャン量課金・稼働時間課金・ノード/RPU課金という3社の料金モデルの違い、ほぼ横並びのストレージ単価、そして「どれが安いか」がワークロードで2〜3倍ぶれて逆転する理由を、スパイキー型・定常高負荷型・同時実行型のパターン別に整理。自社の使い方に合うDWHを費用で見極めたい発注検討者向けです。
データ連携（ETL/ELT）ツールの料金相場と、費用を抑える方法を解説します。従量課金・定額・OSSという3つの課金モデルの違いと損益分岐、主要ツールの月額の目安、Fivetranの請求が跳ねる仕組み、同期頻度や増分同期などのコストダウン6手、そして「OSSは無料ではない」というTCOの考え方まで。予算組みや稟議で費用を見積もる担当者向けです。
データ基盤は作って終わりではなく、毎月のランニングコストが運用とともに膨らみます。コストダウンの前提となる費用の可視化（FinOps）、DWHのクエリ・ストレージ、ETL・データ連携ツール、BIライセンス、運用人件費という4要素ごとの削減策、コストが急に増える原因、削減を続ける仕組みまでを整理します。クラウド利用料が想定より高いと感じるマネージャー向けの実務記事です。
データ基盤構築の費用相場を、初期構築費・クラウド利用料・運用保守費の3層に分けて整理します。規模別レンジ、工程ごとの内訳と人月単価、内製と外注の違い、見積もりが会社ごとに2〜3倍ずれる理由、安すぎる見積もりの危険サイン、3〜5年のTCOで考える判断基準まで解説。発注を検討中のマネージャーが予算と業者選定を判断するための実務記事です。
