トップ / 基礎知識

料金構造とウェアハウスのリソース消費

コストは何に対して発生するのか。標準ウェアハウスとSnowpark-Optimized Warehouseの違い、書き方で抑えられる部分を整理します。

このページに書かれている料金体系・数値（秒単位課金・60秒最低利用・メモリ量など）は、Snowflakeのエディション・リージョン・契約内容によって異なり、将来変更される可能性があります。実際の請求額の見積もりには、必ずSnowflake公式サイトの最新の料金情報をご確認ください。

まず押さえること：変換を書くだけでは課金されない

Snowparkは遅延評価（詳しくはアーキテクチャの解説）を採用しているため、select・filter・joinのような変換メソッドを何回書いても、それ自体では一切課金されません。課金が発生するのは、collect()・show()・save_as_table()のようなアクションメソッドを呼び、実際にSnowflakeのウェアハウスが処理を実行した瞬間だけです。他のインメモリ処理系（都度実行されるライブラリ）に慣れていると、「変換を書いた時点で何か処理が走っているはず」という直感でコストを見積もってしまいがちですが、Snowparkではその直感は成り立ちません。

コンピュートコストは秒単位

アクションメソッドが実行されるとき、実際に処理を行うのはSnowflakeの仮想ウェアハウス（Virtual Warehouse）です。課金は秒単位で行われ、ウェアハウスが起動してから最初の60秒は最低利用時間として課金されます。一定時間クエリが来なければ自動的に一時停止（オートサスペンド）し、その間の課金は発生しません。

メモリが足りない処理にはSnowpark-Optimized Warehouse

大量のメモリを必要とするPython UDFや機械学習のトレーニングでは、標準のウェアハウスだとメモリ不足（OOM）が起きることがあります。Snowflakeは「Snowpark-Optimized Warehouse」という、標準より多くのメモリを積んだウェアハウスの種類を提供しています。

Snowflake公式ドキュメントによると、Snowpark-Optimized Warehouseの既定構成はノードあたり標準ウェアハウスの16倍のメモリを提供します。具体的なメモリ量はサイズ指定によって変わり、たとえばMEMORY_16Xは256GB（Mサイズ以上）、MEMORY_64Xは最大1TB（Lサイズ以上）です。ただし1TBの構成（MEMORY_64X）は本稿確認時点でプレビュー機能かつAWSのみでの提供であり、標準的に使えるわけではない点に注意してください。

ストレージコストも別に発生する

cache_result()やsave_as_table()を呼ぶと、その時点の結果を一時テーブルまたは永続テーブルとしてSnowflake内に保存します。これらのテーブルは通常のストレージ料金の対象になります。「キャッシュしたから無料」ではなく、キャッシュ自体がストレージコストを生む点は見落としやすい落とし穴です。

書き方でコストを抑える

課金の単位（ウェアハウスの稼働時間）が分かると、コードの書き方でコンピュートコストを減らせる場面が見えてきます。

不要なcollect()を挟まない：collect()は結果をクライアント側に持ってくるアクションで、そこで必ずウェアハウスが動きます。処理の途中経過を確認したいだけなら、最終的なcollect()の前に余計なcollect()を挟まず、変換のチェーンをつなげたままにする方がウェアハウスの稼働時間を抑えられます。
with_columnの連続チェーンを避ける：with_columnを何度も連続で呼ぶと、内部的に生成されるSQLがネストして複雑になり、実行時間が伸びることがあります（詳しくはwith_column / with_columnsのページ）。複数列を追加するときはwith_columnsにまとめて式を渡す方が、生成されるSQLがシンプルになります。
limitは早い段階に置く：一部の行だけ確認したいときにlimitを後段に置くと、絞り込む前の全件に対して手前の変換が評価されてしまう場合があります。動作確認の段階では早めにlimitを挟むと、無駄な計算に対するウェアハウスの稼働時間を減らせます。
cache_result()は「使い回す」ときだけ使う：同じ中間結果を後続の複数の処理で繰り返し参照するなら、cache_result()で一度だけ計算してテーブル化する方が、毎回同じ変換を再計算するより合計のコンピュートコストが下がることがあります。逆に、その場限りでしか使わない結果にcache_result()を呼ぶと、再計算を避けるメリットが無いままストレージコストだけが増えます。

filtered = df.filter(col("amount") > 100)

# 悪い例：同じ filtered から2回 collect() すると、
# filter の変換がそのたびに再計算される（ウェアハウスが2回分動く）
report_a = filtered.group_by("region").agg(F.sum("amount")).collect()
report_b = filtered.group_by("customer_id").agg(F.count("*")).collect()

# 良い例：cache_result() で一度だけ実体化し、以降はそのテーブルを再利用する
cached = filtered.cache_result()
report_a = cached.group_by("region").agg(F.sum("amount")).collect()
report_b = cached.group_by("customer_id").agg(F.count("*")).collect()

cache_result()がTableオブジェクトを返すことはSDKのクラス定義で確認済みです。同じfilteredを複数の集計で使い回すときに効果が出るパターンで、1回しか使わない中間結果に呼んでもストレージコストが増えるだけの逆効果になる点は前述のとおりです。

出典

公式ドキュメントの記載にもとづく解説です（実行検証はしていません）。確認日：2026-08-27