データ基盤
Snowflakeの料金の仕組みとは?計算・保存・転送とコスト管理
シリーズSnowflake 入門全3回
- 第1回Snowflakeとは?仕組み・料金・使い方をわかりやすく解説
- 第2回Snowflakeのウェアハウスとは?サイズとクレジット・自動停止
- 第3回Snowflakeの料金の仕組みとは?計算・保存・転送とコスト管理
- 料金
- Snowflake
- クレジット
- コスト管理
- リソースモニター
- 予算
- サーバーレス
- クラウドサービス
- ストレージ
- データ転送
- オブジェクトタグ
- オンデマンド
- キャパシティ
- AI Credits
- Time Travel
- Fail-safe
- コスト異常
- METERING_DAILY_HISTORY
- データ基盤
目次
Snowflake は、使った分だけ払う形の料金を取る1。計算に使った量はクレジットという単位で数え、問い合わせを処理するウェアハウス(計算機の集まり)は、動いている間だけクレジットを使う。
使った分だけ払う形では、使う人が増えたり、データを自動で取り込む仕組みを足したりすると、請求も変わる。
Snowflake では、ウェアハウスを使わずに Snowflake が計算資源を用意して動かす機能をサーバーレスの機能という。クレジットの使用に上限を置く主な仕組みが二つあり、ウェアハウスを止められるものをリソースモニター、使用を見張って知らせるものを予算(Budgets)という。
Snowflake の請求が予想を超えないようにするには、どこに上限を置けばよいのか。
ウェアハウスにはリソースモニターで止める上限を置く。サーバーレスの機能を含む計算全体には、予算で知らせる上限を置く。
リソースモニターは、サーバーレスの機能を数えられない。予算の上限は知らせるためのもので、止めるには自分で書いた手順を使う(AI の機能は利用者ごとの上限でも止められる)。保存とデータ転送に上限を置く仕組みは、文書に見当たらない。
月 1,000 クレジットに収める
※ この節の例は、説明のために作った架空のものです。
ある旅行会社のデータチームが、Snowflake の計算に使うクレジットを月 1,000 に収めると決めたとする。ウェアハウスで予約の集計を回し、Snowpipe(ファイルが届くたびに自動で取り込むサーバーレスの機能)で 1 日 100 GB の予約の記録を取り込んでいる。
ウェアハウスに止める上限を置く: 文書には、上限の手前で止めるリソースモニターの SQL が載っている2。
USE ROLE ACCOUNTADMIN;
CREATE OR REPLACE RESOURCE MONITOR limit1 WITH CREDIT_QUOTA=1000
TRIGGERS ON 90 PERCENT DO SUSPEND
ON 100 PERCENT DO SUSPEND_IMMEDIATE;
ALTER WAREHOUSE wh1 SET RESOURCE_MONITOR = limit1;
このモニターは、割り当てたウェアハウスが使ったクレジットに応じて、次のように動く2。
- ウェアハウスリソースモニター1. 使ったクレジットが 900(90%)に達する
- リソースモニター管理者2. 知らせる(知らせを有効にしてある場合)
- リソースモニターウェアハウス3. 実行中の問い合わせが終わってから止める
- ウェアハウスリソースモニター4. 実行中の問い合わせで 1,000(100%)に達した場合
- リソースモニターウェアハウス5. すぐに止める(実行中の問い合わせも取り消す)
90% で止める動きでも、実行中の問い合わせが終わるまではクレジットを使い続ける。文書は、止まるまでに時間がかかるので、上限そのものではなく手前(たとえば 90%)で止めるよう勧めている2。
サーバーレスの機能には予算を置く: Snowpipe は、取り込んだデータ 1 GB あたり 0.0037 クレジットを使う3。1 日 100 GB なら 1 日 0.37 クレジット、30 日で約 11 クレジットである。この分は、リソースモニターでは数えられず、止まらない2。チームは、サーバーレスの機能も数えるアカウント予算を、同じ月 1,000 クレジットで作った4。予算は、月の上限を超えそうだと見込んだ日に知らせる4。
チームが決めたのは、月のクレジットの上限、ウェアハウスを止める割合、サーバーレスの機能を含めて見張る予算である。
請求の三つの柱:計算・保存・データ転送
Snowflake の請求は、計算、保存、データ転送の費用の合計である5。
計算: 使ったクレジットの数に、1 クレジットの値段を掛ける。クレジットを使うものとして、文書は三つを挙げている5。
- ウェアハウス: 動いている間、問い合わせを処理しているかどうかに関わらずクレジットを使う6。
- サーバーレスの機能: 請求書に機能ごとの行として載る。多くは動いた時間を秒単位で数えて機能ごとの倍率を掛けるが、Snowpipe のように取り込んだデータの量で数えるものもある63。
- クラウドサービス: 認証や問い合わせの組み立てをする層で、その日の使用量がウェアハウスの使用量の 10% を超えた分だけかかる。サーバーレスの機能の使用量は、この 10% の計算に入らない6。
クラウドサービスの 10% の調整は、日本語の文書の計算例で見ると分かりやすい7。11 月 1 日はウェアハウスが 100、クラウドサービスが 20 クレジットを使った。ウェアハウスの 10% の 10 を引くので、請求は 100 + 20 − 10 = 110 である。11 月 3 日はウェアハウスが 80、クラウドサービスが 5 で、10% の 8 より使用量の 5 のほうが小さいので 5 を引き、請求は 80 である。
サーバーレスの機能が使うクレジットは、料金表(Service Consumption Table)に倍率として載っている。倍率は、X-Small(いちばん小さいウェアハウス)を 1 時間動かすのと同じ量の計算あたりに使うクレジットの数である3。
| サーバーレスの | Snowflake が |
|---|---|
| 自動クラスタリング | 2 |
| マテリアライズドビューの | 2 |
| 検索最適化 | 2 |
| サーバーレスタスク | 0.9 |
| Snowpipe | 時間ではなく、 |
多くの機能には、これとは別にクラウドサービスの分が加わり、その分は 10% の調整の対象にならない3。
AI の機能: AI の機能は、AI Credits という別の単位で請求されることがある。ほかの計算のクレジット(料金表では Platform Credits という)とは足し合わせられない。Platform Credits の契約の割引は AI Credits には適用されず、別の値段表がある38。
保存(ストレージ): 毎日の保存量の平均で月ごとに計算し、圧縮した後の大きさで数える59。表のデータのほかに、次のものも数える9。
- 読み込むために置いたファイル
- Time Travel(過去の状態に戻すための過去のデータ)
- Fail-safe(Time Travel の後に Snowflake が 7 日間保つ復旧用のデータ)
- 削除されたデータを参照しているクローン
Time Travel と Fail-safe は、表のうち変わった部分だけを持つ。丸ごとの写しを持つのは、表を消したり空にしたりしたときだけである9。過去のデータを持つ日数は、表の種類で違う10。
| 表の | 過去の |
|---|---|
| 永続 | 7・ |
| 永続 | 7・ |
| 一時的な | 0・ |
transient は Fail-safe を持たない表で、temporary はセッションの間だけある表である10。文書は、短い間だけ使う表は transient にして Fail-safe の費用をなくし、長く使う表は永続にして Fail-safe で守るよう勧めている10。
データ転送: データを入れるのは無料で、外へ出すときにかかる。同じリージョンの中の転送は無料で、別のリージョンや別のクラウドへ出すときにかかる11。
クレジットの値段:エディション・リージョン・買い方
1 クレジットの値段は、クラウド、リージョン、エディションで決まる3。買い方は二つある3。
- オンデマンド: 使った分を月ごとに後払いする。
- キャパシティ: 一定の額を前もって買う。値段は、オンデマンドの値段に契約の割引を適用して決まる。
組織の使用量のビュー USAGE_IN_CURRENCY_DAILY は、使用量がどこから払われたかを示す。主なものは、前もって買った分(capacity)、前の契約から繰り越した分(rollover)、それらと無料の分を使い切った後にオンデマンドの値段で払う分(overage)である12。自分の組織の割引後の値段は、ビュー RATE_SHEET_DAILY で見られる13。
費用を見る:画面とビュー
ブラウザで使う画面 Snowsight の「Cost management」で、計算・保存・データ転送の費用を組織の通貨で見られる。費用の情報が出るまでに最大 72 時間かかり、時刻は UTC で表示される14。
数字を自分で集計するときは、使用量の記録を持つビューを使う15161718。
| ビュー | 分かる |
|---|---|
| METERING_DAILY_HISTORY | 日ごとの |
| METERING_HISTORY | 時間ごと |
| STORAGE_DAILY_HISTORY | 保存の |
問い合わせごとのクレジットは QUERY_ATTRIBUTION_HISTORY で見られる。何もしていない時間やサーバーレスの機能は入らず、遅れは最大 8 時間である17。
Snowflake は、その日の使用量が見込みの範囲を外れたときに、コスト異常として知らせる。見つけるには 30 日以上の使用量が要る8。クラスメソッドのさがらは、プレビューの段階でこの機能を試し、知らせの設定もメールアドレスで簡単にでき、設定しておいて損はない機能だと書いた19。
費用を振り分ける:オブジェクトタグとクエリタグ
文書は、費用を部署やプロジェクトに振り分ける方法を二つ挙げている20。
- オブジェクトタグ: ウェアハウスや利用者に、部署やプロジェクトのタグを付ける。
- クエリタグ: 一つのアプリケーションがいくつもの部署のために問い合わせを流すときに、問い合わせごとに部署のタグを付ける。
文書の例をもとにすると、タグは次のように作成して設定する。オブジェクトタグに付ける値は、作るときに ALLOWED_VALUES で挙げたものから選ぶ20。
CREATE TAG cost_center
ALLOWED_VALUES 'finance', 'marketing', 'engineering', 'product';
ALTER WAREHOUSE warehouse1 SET TAG cost_center = 'finance';
ALTER SESSION SET QUERY_TAG = 'COST_CENTER=finance';
文書は、共有のウェアハウスの費用を利用者に振り分ける SQL も載せている。その SQL は、何もしていない時間の費用を、利用者の使用量の割合に応じて振り分ける20。
上限を置く:リソースモニターと予算
Snowflake の文書は、コスト管理を、見る(可視性)、抑える(制御)、減らす(最適化)の三つに分けている21。抑える主な仕組みが、リソースモニターと予算である。予算はサーバーレスの機能とウェアハウスの両方の費用を扱えるが、リソースモニターはウェアハウスだけを扱う21。
リソースモニター: 期間(日・週・月・年、または区切らない)ごとのクレジットの上限と、上限に対する割合ごとの動きを決める2。
- アクション: 知らせる、実行中の問い合わせが終わってから止める、すぐに止めるの三つ。
- 作れる人: アカウントの管理者のロール(ACCOUNTADMIN)を持つ人だけ。
- 届かない範囲: サーバーレスの機能と AI の機能は数えられない。ウェアハウスのために動いたクラウドサービスの使用は、10% の調整の前の量で数えるが、止めることはできない。
- 精度: 1 クレジット単位で厳密に抑えるものではない。
- 知らせ: メールなどで知らせられるが、既定では無効になっている。
予算: 月ごとのクレジットの使用の上限を決める。アカウント全体を見るアカウント予算と、選んだオブジェクトやタグの付いたオブジェクトだけを見るカスタム予算がある422。
- 上限の意味: 予算の上限は、知らせるためだけに使われる4。
- 止めるには: 予算に、自分で書いた手順(ストアドプロシージャ)を組み合わせれば、ウェアハウスを止めるなどの動きをさせられる4。利用者ごとの上限(per-user quotas)では、AI の機能について、上限に達した利用者を自動で止められる。ウェアハウスの計算も利用者ごとに見張れるが、自動で止めることはできない23。
- 遅れ: 予算の数字は既定で最大 6.5 時間ごとに更新される。1 時間ごとにすると、予算そのものの計算の費用が 12 倍になる4。
予算が扱うのは計算の費用である4。保存とデータ転送に上限を置く仕組みは、文書に見当たらない。
ウェアハウスの側では、問い合わせの時間にも上限を置ける。STATEMENT_TIMEOUT_IN_SECONDS の既定は 2 日である24。文書は、応答が無いまま長く動き続ける問い合わせはクレジットを使いすぎると書いている25。
実務者と記者の見方:見積もりにくさ、遅れ、請求の読み方
クラウドの費用の管理を扱う業界団体 FinOps Foundation は、2026 年に更新した文書で、データの基盤はクレジットを絶えず使い、その速さも変わるので、費用の見積もりは本質的に難しいと書いた。記録の遅れのために、最初に見えるまでに 24 時間かかることがあるとも書いている26。
クラスメソッドの安原朋紀は、Snowflake Intelligence と Cortex Agents(Snowflake の AI の機能)を予算で管理する新しい機能を試した。閾値を超えたときに自動でアクションを実行できるようになったと書く一方で、この予算では、超えてからアクションが実行されるまでに最大 8 時間かかることがあり、その間に支出がさらに増えうると書いている27。
使った分だけ払う形は、費用の読み方をめぐる議論も生んだ。2023 年、食料品の配達の Instacart が Snowflake の使用を大きく減らしたという報道が出た。Snowflake は、支払いの予定と実際の使用量が混同されており、支出が大きく減ったわけではないと説明した28。The Register の Lindsay Clark はこの説明について、減ったのは使用量ではなく請求の額だという点では Snowflake の言い分はもっともだとした。そのうえで Clark は、Snowflake が顧客の費用の「最適化」を強調すると、Snowflake の導入と課金の形が予想外の高い請求を招いたと認めているようにも読める、と書いた29。
判断の手がかり:Well-Architected のコストの柱
Snowflake の Well-Architected Framework のコストの柱は、見えないものは抑えることも減らすこともできないと書き、使っている量を見ることを原則の一つに置いている30。同じ柱はリソースモニターについて、使用量の上限を厳しく守らせられる点が大事だと書いている。一方で、リソースモニターの文書は、1 クレジット単位で厳密に抑えるものではないとしている2。上限の手前で止めるのは、リソースモニターの文書が勧めるとおりである。
出典30件
-
Snowflake「Snowflake Pricing | Choose the Right Edition for Your Data Needs」日付なし、2026年10月20日取得(アーカイブ). https://www.snowflake.com/en/pricing-options/ ↩
-
Snowflake「Working with resource monitors | Snowflake Documentation」日付なし、2026年10月20日取得. https://docs.snowflake.com/en/user-guide/resource-monitors — SQL の例、届かない範囲、精度。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6
-
Snowflake「Snowflake Service Consumption Table」2026年10月12日発効、2026年10月20日取得(アーカイブ). https://www.snowflake.com/legal-files/CreditConsumptionTable.pdf — 買い方、サーバーレスの倍率、AI Credits。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7
-
Snowflake「Monitor credit usage with budgets | Snowflake Documentation」日付なし、2026年10月20日取得. https://docs.snowflake.com/en/user-guide/budgets ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7
-
Snowflake「Understanding overall cost | Snowflake Documentation」日付なし、2026年10月20日取得. https://docs.snowflake.com/en/user-guide/cost-understanding-overall — 請求の三つの柱。 ↩ ↩2 ↩3
-
Snowflake「Understanding compute cost | Snowflake Documentation」日付なし、2026年10月20日取得. https://docs.snowflake.com/en/user-guide/cost-understanding-compute — サーバーレスとクラウドサービスの 10% の調整。 ↩ ↩2 ↩3
-
Snowflake「コンピューティングコストについて | Snowflake Documentation」日付なし、2026年10月20日取得. https://docs.snowflake.com/ja/user-guide/cost-understanding-compute — 10% の調整の計算例。 ↩
-
Snowflake「Introduction to cost anomalies | Snowflake Documentation」日付なし、2026年10月20日取得. https://docs.snowflake.com/en/user-guide/cost-anomalies ↩ ↩2
-
Snowflake「Understanding storage cost | Snowflake Documentation」日付なし、2026年10月20日取得. https://docs.snowflake.com/en/user-guide/cost-understanding-data-storage ↩ ↩2 ↩3
-
Snowflake「Storage costs for Time Travel and Fail-safe | Snowflake Documentation」日付なし、2026年10月20日取得. https://docs.snowflake.com/en/user-guide/data-cdp-storage-costs — 表の種類ごとの日数。 ↩ ↩2 ↩3
-
Snowflake「Understanding data transfer cost | Snowflake Documentation」日付なし、2026年10月20日取得. https://docs.snowflake.com/en/user-guide/cost-understanding-data-transfer ↩
-
Snowflake「USAGE_IN_CURRENCY_DAILY view | Snowflake Documentation」日付なし、2026年10月20日取得. https://docs.snowflake.com/en/sql-reference/organization-usage/usage_in_currency_daily — capacity・rollover・overage。 ↩
-
Snowflake「RATE_SHEET_DAILY view | Snowflake Documentation」日付なし、2026年10月20日取得. https://docs.snowflake.com/en/sql-reference/organization-usage/rate_sheet_daily ↩
-
Snowflake「Exploring overall cost | Snowflake Documentation」日付なし、2026年10月20日取得. https://docs.snowflake.com/en/user-guide/cost-exploring-overall — 最大 72 時間の遅れ。 ↩
-
Snowflake「METERING_DAILY_HISTORY view | Snowflake Documentation」日付なし、2026年10月20日取得. https://docs.snowflake.com/en/sql-reference/account-usage/metering_daily_history ↩
-
Snowflake「METERING_HISTORY view | Snowflake Documentation」日付なし、2026年10月20日取得. https://docs.snowflake.com/en/sql-reference/account-usage/metering_history ↩
-
Snowflake「QUERY_ATTRIBUTION_HISTORY view | Snowflake Documentation」日付なし、2026年10月20日取得. https://docs.snowflake.com/en/sql-reference/account-usage/query_attribution_history ↩ ↩2
-
Snowflake「STORAGE_DAILY_HISTORY view | Snowflake Documentation」日付なし、2026年10月20日取得. https://docs.snowflake.com/en/sql-reference/organization-usage/storage_daily_history ↩
-
さがら「[新機能]アカウント・組織レベルでコストの異常を自動で検知・通知してくれる「Cost anomalies」機能がリリースされました | DevelopersIO」2025年5月17日、2026年10月20日取得. https://dev.classmethod.jp/articles/snowflake-cost-anomalies-pupr/ ↩
-
Snowflake「Attributing cost | Snowflake Documentation」日付なし、2026年10月20日取得. https://docs.snowflake.com/en/user-guide/cost-attributing — タグの SQL と、何もしていない時間の配り方。 ↩ ↩2 ↩3
-
Snowflake「Managing cost in Snowflake | Snowflake Documentation」日付なし、2026年10月20日取得. https://docs.snowflake.com/en/user-guide/cost-management-overview ↩ ↩2
-
Snowflake「Custom budgets | Snowflake Documentation」日付なし、2026年10月20日取得. https://docs.snowflake.com/en/user-guide/budgets/custom-budget ↩
-
Snowflake「Per-user quotas | Snowflake Documentation」日付なし、2026年10月20日取得. https://docs.snowflake.com/en/user-guide/budgets/per-user-quotas ↩
-
Snowflake「Parameters | Snowflake Documentation」日付なし、2026年10月19日取得. https://docs.snowflake.com/en/sql-reference/parameters ↩
-
Snowflake「Cost controls for warehouses | Snowflake Documentation」日付なし、2026年10月20日取得. https://docs.snowflake.com/en/user-guide/cost-controlling-controls ↩
-
FinOps Foundation「FinOps for Data Cloud Platforms: Practical Scenarios」2026年6月4日更新、2026年10月20日取得. https://www.finops.org/wg/finops-for-data-cloud-platforms-practical-scenarios/ — 作業部会の文書(Snowflake の社員も寄稿)。 ↩
-
安原朋紀「[新機能]Snowflake Intelligence と Cortex Agents を予算で管理できるようになりました | DevelopersIO」2026年3月13日、2026年10月20日取得. https://dev.classmethod.jp/articles/snowflake-si-resource-budgets-management/ ↩
-
Snowflake「Snowflake and Instacart: The Facts - Blog」2023年8月30日、2026年10月20日取得(アーカイブ). https://www.snowflake.com/blog/snowflake-and-instacart-the-facts/ ↩
-
Lindsay Clark「Bill cutting challenges ahead for Snowflake’s accountants」The Register、2023年9月5日、2026年10月20日取得. https://www.theregister.com/2023/09/05/snowflakes_instacart_protestations_opinion/ — 記者の論評。 ↩
-
Snowflake「Cost Optimization」(Well-Architected Framework、Well Architected Framework Team)2026年10月20日取得. https://raw.githubusercontent.com/Snowflake-Labs/sfquickstarts/master/site/sfguides/src/well-architected-framework-cost-optimization-and-finops/well-architected-framework-cost-optimization-and-finops.md ↩
この記事はAIを使用して執筆されました。内容には誤りが含まれる可能性があります。事実や数字の出典は脚注から確かめられます。