Snowflake料金体系をやさしく解説｜クレジット・ストレージ・サーバーレス・Cortex AIのコストまで

Snowflakeの料金体系をやさしく解説|クレジット・ストレージ・転送量の仕組み Snowflake
2026.04.28
この記事をシェアする𝕏B!FacebookLINEPocket

はじめに:Snowflakeの料金は基本3本柱で考える

Snowflakeの料金は、まず「コンピュート」「ストレージ」「データ転送」の3本柱で考えると理解しやすいです。ただし、最近のSnowflakeではSnowpipe、Dynamic Tables、Search Optimization、Cortex AI関数など、通常の仮想ウェアハウスとは別の形でクレジットを消費する機能も増えています。本記事では、基本の3本柱に加えて、サーバーレス機能やCortex AIのコスト注意点まで初心者向けに整理します。

料金・単価・無料枠は契約形態やリージョン、時期によって変わる可能性があります。本記事に記載する金額はすべて参考例です。実際に契約・運用する際は、必ずSnowflake公式の料金ページとService Consumption Tableで最新情報を確認してください。

Snowflake料金の全体像

Snowflakeの課金は、次の5カテゴリに整理できます。

課金カテゴリ課金単位主な対象注意点
コンピュートクレジット仮想ウェアハウス、SQL実行、COPY INTO起動中はクエリがなくても課金される
ストレージTB/月テーブル、ステージ、Time Travel、Fail-safe更新・削除が多いテーブルは保持データが増える
データ転送GB別リージョン・別クラウドへの外向き転送通常利用では小さいが、DRや共有設計で増える
サーバーレスクレジットSnowpipe、Dynamic Tables、Auto Clustering、Search Optimization、Serverless Tasksなどウェアハウスとは別に消費される
Cortex AIトークン・ページ・クレジットAI_COMPLETE、AI_TRANSLATE、AI_SENTIMENT、AI_EXTRACTなど大量行に実行すると急増しやすい

「3本柱で考える」のは、まず全体感をつかむための入口です。本番運用ではサーバーレス機能・Cortex AIのコストも併せて監視する必要があります。

料金を決める4つの要素

Snowflakeの料金は、おおよそ次の4要素の組み合わせで決まります。

  • クラウド:AWS / Azure / Google Cloud によって単価が異なります。
  • リージョン:同じクラウドでも、東京・大阪・USリージョンなどで単価が違います。
  • エディション:Standard / Enterprise / Business Critical / VPS でクレジット単価が変わります。
  • 契約形態:オンデマンド契約 / 事前購入(キャパシティ) / 通貨建てなどで単価が変わります。

同じワークロードでも、組み合わせ次第で月額コストは大きく変わります。「Snowflake = いくら」という固定金額のイメージではなく、「使う構成によって単価が決まる」と覚えておくとよいでしょう。

① コンピュート料金:ウェアハウスのクレジット消費

Snowflakeでクエリを実行する「仮想ウェアハウス」は、起動している時間に応じてクレジットを消費します。クエリの本数ではなく、ウェアハウスが起動している時間で課金される点が特徴です。

  • ウェアハウスは起動から最低60秒分課金され、その後は秒単位で課金されます。
  • クエリが流れていなくても、ウェアハウスが起動中であればクレジット消費が続きます。
  • そのため AUTO_SUSPEND による自動停止と、AUTO_RESUME による自動再開の設定が重要です。

仮想ウェアハウスの基本についてはSnowflakeウェアハウスとは?も合わせてご覧ください。

エディション別クレジット単価(参考例)

注意:以下の金額はあくまで一部リージョン・一部クラウド・オンデマンド契約における参考例です。実際の単価は、クラウド、リージョン、エディション、契約形態、通貨、購入条件によって変わります。最新の正確な金額はSnowflake公式の料金ページで確認してください。

エディション1クレジットあたりの参考例主な特徴
Standard約 $2 前後基本機能
Enterprise約 $3 前後マルチクラスタ、マテリアライズドビュー など
Business Critical約 $4 前後HIPAA対応強化、PrivateLinkなど
VPS個別見積専用環境

ウェアハウスサイズ別のクレジット消費

ウェアハウスはサイズが大きいほど、1時間あたりのクレジット消費量が増えます。サイズが1段階上がるごとに、おおよそクレジット消費が倍になるイメージです。

サイズ1時間あたりのクレジット消費(目安)
X-Small1
Small2
Medium4
Large8
X-Large16
2X-Large32
3X-Large64
4X-Large128

大きいウェアハウスは高速ですが、その分時間あたりの単価も高くなります。「大きいサイズで短時間」と「小さいサイズで長時間」のどちらが安いかは、クエリの内容によって変わるため、本番ETLでは両方を比較するのがおすすめです。

② ストレージ料金:保存データ・Time Travel・Fail-safe

ストレージ料金は、Snowflakeに保存されているデータ量(TB/月)に応じて発生します。テーブルや内部ステージのデータだけでなく、Time Travel(過去データを参照する仕組み)やFail-safe(障害時のリカバリ用領域)で保持されるデータも、ストレージ使用量に影響します。

  • Snowflakeは内部で自動圧縮されるため、元データサイズと実際の課金対象サイズは一致しません。
  • Time Travel(既定1日、Enterprise以上で最大90日)とFail-safe(通常7日)の分も保持されます。
  • 大量UPDATE / DELETE / MERGEが多いテーブルは、過去バージョンが保持されてストレージ消費が増えやすくなります。
  • 正確な単価はクラウド・リージョン・契約形態(オンデマンド / キャパシティ)で変わります。

たとえば一部リージョンでは、オンデマンドで 約$40/TB/月、キャパシティ契約で 約$23/TB/月 といった水準が紹介されることがありますが、これらはあくまで参考例です。最新の金額は必ず公式ページで確認してください。

③ データ転送料金:外向き通信に注意

Snowflakeから別リージョンや別クラウドへデータを送り出す場合、データ転送料金(GB単位)が発生する場合があります。同一リージョン内でのやり取りは原則無料ですが、クロスリージョンのレプリケーションやデータ共有、外部ステージへの書き出しなどは課金対象になり得ます。

  • 通常のBI・ETL利用では、データ転送費は全体コストの中で小さい場合が多いです。
  • DR(災害対策)、Cross-Region Replication、別アカウントへのShare、別クラウドへのアンロードが増えると、転送費が無視できなくなります。
  • SnowflakeへINSERT/COPYで取り込む方向は、データ転送費としては通常無料に見えるケースが多いですが、コピーを実行するウェアハウスのクレジットは消費します。

④ サーバーレス機能の課金:ウェアハウスとは別にクレジットを消費する

Snowflakeには、自分で仮想ウェアハウスを指定せず、Snowflake側が管理するコンピュートで処理される機能があります。これらはサーバーレス機能として、通常のウェアハウスとは別にクレジットを消費する場合があります。

機能課金の考え方注意点
Snowpipe取り込み処理に応じてサーバーレスクレジット消費小さいファイルが大量にあると効率が悪くなりやすい
Auto Clusteringクラスタリング維持のためにクレジット消費頻繁に更新される大規模テーブルは注意
Search Optimization Service検索最適化の維持でクレジット消費全テーブルに設定せず、検索条件が明確な列に限定する
Materialized View自動更新でクレジット消費更新頻度が高い元テーブルではコスト増になりやすい
Dynamic Tables自動更新処理でクレジット消費Target Lagと更新頻度を見直す
Serverless TasksSnowflake管理のコンピュートで実行固定ウェアハウス利用との比較が必要

サーバーレス機能のクレジット単価は、通常のウェアハウスとは別に設定されています。設定して放置するのではなく、定期的にAccount Usageビューで使用量を確認しましょう。

⑤ Cortex AI関数の料金:トークン数・ページ数・モデルに注意

Snowflake Cortex AI関数は、通常のSQLとは違い、AIモデルの利用量に応じてクレジットを消費します。特に AI_COMPLETE、AI_TRANSLATE、AI_SENTIMENT、AI_SUMMARIZE、AI_EXTRACT などは、入力トークン、出力トークン、ページ数、モデルによってコストが変わる場合があります。

関数・機能主なコスト要因注意点
AI_COMPLETE入力トークン、出力トークン、モデル出力を長くしすぎない
AI_TRANSLATE翻訳する文字量・トークン量大量テキストを全件翻訳する前に試算する
AI_SENTIMENT対象テキスト量レビュー全件などに実行する場合は注意
SUMMARIZE / AI_SUMMARIZE_AGG入力文量、出力文量長文・大量行の要約はコスト増になりやすい
AI_EXTRACTファイルページ数、抽出項目数、トークンPDFや画像の大量処理は事前検証する
Document AI / PARSE_DOCUMENTページ数・ファイル数スキャン対象を絞る

Cortex AI関数を使うときの注意点:

  • いきなり全件実行せず、まず LIMIT 10 で検証する
  • WHERE 条件で対象データを絞る
  • プロンプトを短く・明確にする
  • 出力形式を固定して無駄な文章を減らす
  • 高額モデルを使う前に軽量モデルで試す
  • 本番実行前に件数、文字数、ページ数を見積もる

各関数の使い方はSnowflake Cortex AI関数まとめ、AI_COMPLETE入門、AI_EXTRACT入門もご覧ください。

月額コストのシミュレーション

料金イメージをつかむために、いくつかのパターンで月額コストの大まかな目安を考えてみます。※すべて参考例です。実際の金額はクラウド・リージョン・エディション・契約・使用量で大きく変わります。

パターンA:小規模BI(個人〜小チーム)

  • X-Smallウェアハウスを平日のみ、1日あたり数時間使う
  • ストレージは数十GB程度
  • データ転送はほぼなし
  • 月額コストは小さく、コンピュートが大半を占めるイメージ

パターンB:中規模ETL + BI

  • 夜間バッチでMedium〜Largeウェアハウスを使う
  • 日中はBI用にSmall〜Mediumを使う
  • ストレージは数百GB〜数TB
  • Snowpipe、Dynamic Tables、Materialized Viewなどサーバーレス機能も少し使う

パターンC:大規模分析基盤

  • 複数のウェアハウス、マルチクラスタを併用
  • ストレージは数十TB以上
  • クロスリージョンレプリケーションでデータ転送費も発生
  • Auto Clustering、Search Optimization、Serverless Tasksなど多数活用
  • キャパシティ契約での割引が前提

パターンD:Cortex AIで問い合わせレビューを分析する場合

  • 通常のウェアハウス利用に加えて、AI関数の利用量が発生する
  • AI_COMPLETE や AI_SENTIMENT を問い合わせ全件に実行する場合、対象件数・文字数・モデル・出力長でコストが変わる
  • 正確な金額は公式のService Consumption TableやUsage Historyで確認する
  • 初回はサンプルデータで実行して、1件あたりの平均コストを把握してから全件実行する

コストを確認するSQL

実際の使用量とコストは、SNOWFLAKE.ACCOUNT_USAGE スキーマのビューで確認できます。代表的なSQLをいくつか紹介します。

アカウント全体のクレジット消費(サービス別・日次):

SELECT
  SERVICE_TYPE,
  DATE_TRUNC('day', START_TIME) AS USAGE_DATE,
  SUM(CREDITS_USED) AS CREDITS_USED
FROM SNOWFLAKE.ACCOUNT_USAGE.METERING_HISTORY
WHERE START_TIME >= DATEADD('day', -30, CURRENT_TIMESTAMP())
GROUP BY 1, 2
ORDER BY USAGE_DATE DESC, CREDITS_USED DESC;

ウェアハウス別のクレジット消費:

SELECT
  WAREHOUSE_NAME,
  DATE_TRUNC('day', START_TIME) AS USAGE_DATE,
  SUM(CREDITS_USED) AS CREDITS_USED
FROM SNOWFLAKE.ACCOUNT_USAGE.WAREHOUSE_METERING_HISTORY
WHERE START_TIME >= DATEADD('day', -30, CURRENT_TIMESTAMP())
GROUP BY 1, 2
ORDER BY USAGE_DATE DESC, CREDITS_USED DESC;

重いクエリ Top 50 (実行時間ベース):

SELECT
  QUERY_ID,
  USER_NAME,
  WAREHOUSE_NAME,
  TOTAL_ELAPSED_TIME / 1000 AS ELAPSED_SECONDS,
  BYTES_SCANNED,
  ROWS_PRODUCED,
  QUERY_TEXT
FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY
WHERE START_TIME >= DATEADD('day', -7, CURRENT_TIMESTAMP())
ORDER BY TOTAL_ELAPSED_TIME DESC
LIMIT 50;

ストレージ使用量の推移:

SELECT
  USAGE_DATE,
  STORAGE_BYTES / POW(1024, 4) AS STORAGE_TB,
  STAGE_BYTES   / POW(1024, 4) AS STAGE_TB,
  FAILSAFE_BYTES / POW(1024, 4) AS FAILSAFE_TB
FROM SNOWFLAKE.ACCOUNT_USAGE.STORAGE_USAGE
WHERE USAGE_DATE >= DATEADD('day', -30, CURRENT_DATE())
ORDER BY USAGE_DATE DESC;

クレジット使用量・ウェアハウス使用量の確認手順は、Snowflakeクレジット使用量を確認する方法とSnowflakeウェアハウス使用量を確認する方法も合わせてご覧ください。

Cortex AI関数の使用量を確認するSQL

Cortex AI関数の利用量は、Account Usageの専用ビューで確認できます。実際の列名はSnowflakeの仕様変更で変わる可能性があるため、まず DESC VIEW で列構成を確認するのがおすすめです。

DESC VIEW SNOWFLAKE.ACCOUNT_USAGE.CORTEX_AI_FUNCTIONS_USAGE_HISTORY;

列を確認したら、用途に応じて次のように集計できます。

SELECT
  START_TIME,
  FUNCTION_NAME,
  MODEL_NAME,
  USER_NAME,
  ROLE_NAME,
  WAREHOUSE_ID,
  TOKEN_CREDITS,
  TOKENS,
  CREDITS
FROM SNOWFLAKE.ACCOUNT_USAGE.CORTEX_AI_FUNCTIONS_USAGE_HISTORY
WHERE START_TIME >= DATEADD('day', -7, CURRENT_TIMESTAMP())
ORDER BY START_TIME DESC;

列名やビュー名は更新される可能性があるため、最新の構成はSnowflake公式ドキュメントを確認してください。

Resource Monitorで予算超過を防ぐ

Resource Monitorは、仮想ウェアハウスのクレジット消費に上限を設定し、超えそうになったら通知・停止する仕組みです。月500クレジットを上限にし、90%で通知、100%で停止するシンプルな例は次のようになります。

USE ROLE ACCOUNTADMIN;

CREATE OR REPLACE RESOURCE MONITOR monthly_budget
  WITH CREDIT_QUOTA = 500
       FREQUENCY = MONTHLY
       START_TIMESTAMP = IMMEDIATELY
  TRIGGERS
    ON 80 PERCENT DO NOTIFY
    ON 90 PERCENT DO NOTIFY
    ON 100 PERCENT DO SUSPEND
    ON 110 PERCENT DO SUSPEND_IMMEDIATE;

ALTER ACCOUNT SET RESOURCE_MONITOR = monthly_budget;
  • Resource Monitorは仮想ウェアハウスの使いすぎ防止に有効です。
  • アカウント全体またはウェアハウス単位で設定できます。
  • ただし、すべてのサーバーレス機能やCortex AI関数の支出を完全に止められるわけではありません。
  • サーバーレスやCortex AIはAccount Usageビューによる監視も組み合わせます。
  • 通知先メールや、超過時の運用ルール(誰が一次対応するか)も決めておきましょう。

Resource Monitorの詳しい設定はSnowflake Resource Monitor入門もご覧ください。

Resource Monitorだけでは防げないコスト

Resource Monitorは強力ですが、すべてのコストが完全に上限固定されるわけではありません。特に次のような領域は、別途監視を組み合わせる必要があります。

  • Serverless Tasks、Snowpipe、Auto Clustering、Search OptimizationなどのサーバーレスクレジットはResource Monitorの対象外になる場合があります。
  • Cortex AI関数の利用も、ウェアハウスとは別枠でクレジットを消費します。
  • METERING_HISTORY を SERVICE_TYPE 別に確認し、急増しているサービスがないか定期チェックします。
  • コスト急増時にまず見るべき画面は、Snowsightの Admin → Cost Management です。
  • さらに詳細を見る場合は SNOWFLAKE.ACCOUNT_USAGE のビュー(METERING_HISTORY、WAREHOUSE_METERING_HISTORY、CORTEX_AI_FUNCTIONS_USAGE_HISTORYなど)を確認します。

Snowflakeコスト削減チェックリスト

  • AUTO_SUSPEND は60〜120秒を基本にする
  • 開発用ウェアハウスはX-Smallから始める
  • 本番ETLは「大きいウェアハウスで短時間」と「小さいウェアハウスで長時間」の両方を比較する
  • Resource Monitorを必ず設定する
  • サーバーレス機能は便利だが、設定後に消費量を確認する
  • Cortex AI関数は必ず少量データで検証してから全件実行する
  • AI関数は対象件数、文字数、ページ数を事前に見積もる
  • 高額モデルを全件に使わない
  • Time Travel保持期間を必要以上に長くしない
  • 大量UPDATE/DELETE/MERGEがあるテーブルはストレージ増に注意する
  • Search OptimizationやMaterialized Viewは費用対効果を確認してから使う
  • 不要なステージファイルを定期的に削除する
  • 定期的にCost Management画面とAccount Usageビューを確認する

クエリの重さを下げる観点では、Snowflake Query Profile入門でボトルネックを可視化するのも有効です。

よくある質問

Q. Snowflakeは無料で使えますか?

  • 無料トライアルがあります。
  • 無料枠やクレジット額は時期により変わる可能性があります。
  • 最新情報は公式トライアルページで確認してください。Snowflake無料トライアル登録方法も参考になります。

Q. Cortex AI関数はウェアハウス料金だけで使えますか?

  • 通常のウェアハウス課金とは別に、AI関数の使用量に応じたクレジット消費が発生する場合があります。
  • トークン数、ページ数、モデルに注意してください。

Q. Resource Monitorを設定すれば絶対に予算超過しませんか?

  • ウェアハウスの使いすぎ防止には有効です。
  • ただし、サーバーレス機能やAI関数などは別途監視が必要な場合があります。
  • 完全な予算管理にはCost Management画面とAccount Usageの確認も必要です。

Q. COPY INTOは無料ですか?

  • データ転送料金としては無料に見えるケースが多いです。
  • ただし、COPY INTOを実行するウェアハウスのコンピュートクレジットは消費します。
  • Snowpipeを使う場合はSnowpipeのサーバーレスクレジットを消費します。

まとめ

Snowflakeの料金は、まずコンピュート・ストレージ・データ転送の3本柱で理解すると分かりやすいです。ただし、実務ではSnowpipe、Dynamic Tables、Search Optimization、Cortex AI関数など、ウェアハウスとは別にクレジットを消費する機能もあります。料金を正しく管理するには、AUTO_SUSPEND、適切なウェアハウスサイズ、Resource Monitorに加えて、SnowsightのCost Management画面やAccount Usageビューで定期的に使用量を確認することが大切です。

本記事に記載した金額・サイズ別クレジット・サーバーレス機能の挙動はすべて参考例であり、最新の正確な情報はSnowflake公式の料金ページとService Consumption Tableで必ず確認してください。

参考リンク

※リンク先のパスはSnowflake側の構成変更で変わる可能性があります。最新URLは公式ドキュメントのトップから検索してください。

関連記事

この記事をシェアする𝕏B!FacebookLINEPocket