In Silico

データ基盤

Snowflakeのウェアハウスとは？サイズとクレジット・自動停止

2026/10/19 シリーズ「Snowflake 入門」 第2回 / 全2回

🤖 AIを使用して執筆

シリーズSnowflake 入門全2回
  1. 第1回Snowflakeとは？仕組み・料金・使い方をわかりやすく解説
  2. 第2回Snowflakeのウェアハウスとは？サイズとクレジット・自動停止

このシリーズの紹介へシリーズ一覧へ

  • ウェアハウス
  • 仮想ウェアハウス
  • サイズ
  • クレジット
  • Snowflake
  • 自動サスペンド
  • 自動再開
  • マルチクラスター
  • スケーリングポリシー
  • スケールアップ
  • スケールアウト
  • Gen2
  • 第2世代標準ウェアハウス
  • Snowpark
  • MAX_CONCURRENCY_LEVEL
  • WAREHOUSE_LOAD_HISTORY
  • スピル
  • QAS
  • 料金
  • データ基盤
目次
背景・問い・要点
背景

Snowflake では、問い合わせを処理する計算機の集まりを仮想ウェアハウス（以下、ウェアハウス）という。利用者の問い合わせはまず、利用者の認証や問い合わせの組み立て（コンパイルと最適化）をするクラウドサービスの層が受け取り、ウェアハウスに渡す1。料金はクレジットという単位で数え、ウェアハウスは動いている間だけクレジットを使う。

ウェアハウスは、一つ以上のクラスター（ひとまとまりで動く計算機の組）でできている。能力を上げるには二つの方向があり、Snowflake の文書はこう呼んでいる。クラスターを大きくするのがスケールアップで、クラスターの数を増やすのがスケールアウトである2。

同時にたくさんの問い合わせが来て、ウェアハウスの資源が足りなくなると、あとから来た問い合わせは待たされる。待っている問い合わせの列を、待ち行列（キュー）という3。

問い

ウェアハウスの大きさと、止めるまでの時間は、どう決めればよいのか。

要点

大きさは、一段上げて時間がちょうど半分になる間は上げても費用が変わらないので、半分にならなくなったら、それ以上は上げない。止めるまでの時間は、問い合わせが来る間隔より短くしない。

一段上げるごとに 1 時間のクレジットは倍になり、時間が半分に届かなければその分だけ高くなる。止まるまでの待ち時間にも課金されるが、短くしすぎると止まっては動くを繰り返し、そのたびに最低 60 秒分がかかってキャッシュも消える。同時に来る問い合わせが待たされるときは、大きくせずにクラスターの数を増やす。

モデル・例示

夜の集計と朝のダッシュボードを、一つのウェアハウスで回す

※ この節の例は、説明のために作った架空のものです。

全国に店を持つパン屋の本部が、Snowflake の Enterprise エディションで、二つの仕事を一つの Medium のウェアハウスで回しているとする。

  • 夜の集計： 毎晩、その日の売上のデータを取り込み、店ごと、商品ごとにまとめ直す。Medium で 40 分かかる。
  • 朝のダッシュボード： 毎朝 9 時に、店長たちが売上の画面を一斉に開く。

夜の集計の大きさ： Medium は 1 時間に 4 クレジットを使う。一段大きい Large は 8 クレジットで、そのまた上の X-Large は 16 クレジットである3。本部が三つの大きさで同じ集計を流したところ、次の時間がかかったとする。

大きさ（かかった時間）使ったクレジット（止まるまでの待ち時間は除く）
Medium（40 分）4×40/60≈2.674 \times 40/60 \approx 2.67
Large（20 分）8×20/60≈2.678 \times 20/60 \approx 2.67
X-Large（14 分）16×14/60≈3.7316 \times 14/60 \approx 3.73

Large では 40 分が 20 分とちょうど半分になり、使うクレジットは変わらない。Snowflake の文書も、一段大きなウェアハウスで問い合わせが倍の速さになれば、その問い合わせの費用は変わらないと書いている4。X-Large では、時間は半分まで縮まず、費用が増える。本部は、夜の集計を Large で流すことにした。

朝のダッシュボード： 9 時に店長たちが一斉に画面を開くと、問い合わせがいくつも同時に届く。ウェアハウスの資源が足りなくなると、あとの問い合わせは待ち行列に入る3。ここでウェアハウスを大きくしても、待ち行列の問題は解きにくい。文書は、大きくするのは主に問い合わせを速くするためで、同時に来る問い合わせへの備えには、ウェアハウスを増やすかマルチクラスターのウェアハウスを使うよう勧めている32。

本部は、ダッシュボード用のウェアハウスを Medium のまま別に作り、クラスターを最小 1、最大 3 の範囲で自動で増減させる設定（自動スケール）にした。増やし方は、待ちを減らすことを優先する標準のポリシーにした5。

  1. 店長たちクラウドサービス1. 9 時に一斉に画面を開き、問い合わせが届く
  2. クラウドサービスクラスター 12. 処理できる分の問い合わせを割り当てる
  3. クラウドサービスクラスター 23. 問い合わせが待ち行列に入ったので、クラスターを一つ増やす
  4. クラウドサービスクラスター 24. 待っていた問い合わせを割り当てる
  5. クラスター 2クラウドサービス5. 集計の結果
  6. クラウドサービス店長たち6. 結果を返す
  7. クラウドサービスクラスター 27. 負荷の低い時間が続いたので、仕事が終わり次第止める（クラスター 1 は動き続ける）

クレジットは、動いていたクラスターの数だけかかる。Snowflake の文書は、Medium で最大 3 クラスターのウェアハウスを自動スケールで 2 時間動かす計算例を載せている。1 時間目はクラスター 1 だけが動いて 4 クレジット、2 時間目はクラスター 2 が 1 時間、クラスター 3 が 30 分加わって 4 + 4 + 2 = 10 クレジット、合わせて 14 クレジットである5。3 クラスターを最初から最後まで動かすと、24 クレジットになる5。

止め方： 夜の取り込みと集計は、終わったらすぐ止まってよい。ダッシュボードは、朝の間は続けて使われ、ウェアハウスが手元に持つデータの写し（キャッシュ）が残っていると速い。本部は、集計用のウェアハウスの自動サスペンドを 1 分、ダッシュボード用を 10 分にした。Snowflake が公開している設計の手引き Well-Architected Framework も、データを取り込み変換する処理（ELT）には 1〜2 分の短い時間、ダッシュボードには 10〜20 分の長めの時間を勧めている6。

本部が決めたのは、仕事ごとのウェアハウス、それぞれの大きさ、クラスターの数の範囲と増やし方、止めるまでの時間である。

仮想ウェアハウスとは：問い合わせと書き込みに要る計算の単位

ウェアハウスは、問い合わせにも、表へのデータの読み込みを含むすべての書き込み（DML）にも必要である3。いつでも動かしたり止めたりでき、動いている間でも大きさを変えられる3。

ウェアハウスどうしは計算資源を共有しないので、仕事ごとにウェアハウスを分けると、同じデータを読みながら互いの速さに影響しない7。Snowflake 社内の Snowflake 環境を支える技術者 Tamir Rozenberg は、2020 年の Snowflake のブログで、一つのウェアハウスに複数の種類の仕事を混ぜないことが大切だと書いた7。文書も、似た複雑さの問い合わせを同じウェアハウスで流すよう勧めている2。

一方で、分けすぎにも費用がかかる。SELECT の Ian Whitestone と Niall Woodward は、ウェアハウスが増えすぎると、それぞれが問い合わせで埋まらず、何もしない時間が増えると書いた。数はできるだけ少なくし、分けるのは、業務の領域ごとではなく、求める性能が違うときにするよう勧めている8。SELECT は Snowflake の費用を減らす道具を売る会社で、2026 年 1 月に DoiT に買収された9。

ウェアハウスには種類がある。ふつうの標準のウェアハウスのほかに、メモリを多く積んだ Snowpark 用に最適化されたウェアハウスがある。標準のウェアハウスにも、第 1 世代（Gen1）と第 2 世代（Gen2）がある。どれも SQL で作るときに選べ、あとから ALTER WAREHOUSE で変えることもできる1011。

大きさとクレジット：一段ごとに倍

大きさ（文書の言葉ではサイズ）は、ウェアハウスの一つのクラスターが使える計算資源の量である3。一段大きくするごとに、CPU、メモリ、手元のディスクが倍になり6、1 時間に使うクレジットも倍になる3。

大きさ1 時間のクレジット（第 1 世代）
X-Small1
Small2
Medium4
Large8
X-Large16
2X-Large〜6X-Large32、64、128、256、512

課金は秒単位だが、ウェアハウスが動き出すたびに最低 60 秒分がかかる3。61 秒動いて止まり、また動いて 60 秒未満で止まると、60 + 1 + 60 = 121 秒分の請求になる2。文書の表では、X-Small が 10 分動くと 0.167 クレジット、X-Large が 10 分動くと 2.667 クレジットである3。

SQL の CREATE WAREHOUSE で大きさを指定せずに作ると、X-Small になる12。画面の Snowsight で作るときの既定の大きさは、文書の大きさの表に X-Small と X-Large の両方が既定として書かれている。Snowsight で作るときは、大きさの欄を確かめてから作るとよい3。

大きくすると何が変わるか：速さが倍なら費用は同じ

大きなウェアハウスは使える資源が多いので、一般に問い合わせは速くなる。ただし、小さく単純な問い合わせは、大きくしても速くなるとは限らない3。データの読み込みの速さは、ウェアハウスの大きさよりも、読み込むファイルの数と大きさに大きく左右される3。

大きさを変えても、すでに動いている問い合わせには影響しない。増えた資源は、用意ができてから、待っている問い合わせと新しい問い合わせに使われる3。

費用の考え方は単純である。一段大きくすると 1 時間のクレジットは倍になるので、時間がちょうど半分になれば費用は変わらず、半分に届かなければ費用は増える4。

最初にどの大きさを試すかについては、Snowflake の中でも書き方が分かれている。

SELECT の共同創業者 Woodward は、費用に対して最も効率のよい大きさを選ぶ手順をこう勧めている。いつも X-Small から始め、問い合わせの時間が半分にならなくなるまで大きくし、そこで一段戻す。もっと速さが要るなら大きいほうを使ってよいが、その先は効きが落ちていくとも書いた13。最適な大きさをきちんと決めるには試すしかない、とも書いている13。

大きくすべき合図もある。問い合わせの途中でメモリが足りなくなると、データを手元のディスクに、さらに足りなければクラウドのストレージに書き出す。これをスピル（あふれ）と呼び、性能は大きく落ちる14。QUERY_HISTORY の列 bytes_spilled_to_local_storage と bytes_spilled_to_remote_storage にその量が出る15。Well-Architected Framework は、クラウドのストレージへのスピルが多い問い合わせは、より大きなウェアハウスに移す有力な候補だとしている6。

止め方：自動サスペンドと自動再開

自動サスペンドは、問い合わせが来ない時間が決めた長さに達するとウェアハウスを止める機能で、自動再開は、問い合わせが来たら動かす機能である。どちらも既定で有効になっている3。SQL で作ると、止まるまでの時間の既定は 600 秒（10 分）である12。

止めると、そのあとの計算の料金はかからない。代わりに、ウェアハウスが手元に持っていたデータの写し（キャッシュ）が消え、再開した直後の問い合わせは遅くなりうる2。止めるまでの時間を短くするほど、何もしていない時間の費用は減る。その代わり再開の回数が増え、そのたびにキャッシュを失い、最低 60 秒分がかかる。

どのくらいの長さにするかは、出典によって勧めが違う。

出典止めるまでの時間の勧め
Snowflake の文書5 分か 10 分、またはそれより短く。ただし問い合わせの間隔に合わせる
Well-Architected（コスト）キャッシュと応答時間を損なわない範囲でできるだけ短く。たいていは 60 秒より長く
Well-Architected（性能）取り込みと変換の処理は 1〜2 分、ダッシュボードは 10〜20 分
SELECTすべてのウェアハウスで 60 秒

文書は、問い合わせが 2〜3 分おきに来るなら、1〜2 分で止める設定は意味がないと書いている。止まってはすぐ動くことを繰り返すからである2。Well-Architected のコストの柱は、利用者が自動サスペンドを切れないよう権限を絞ることも勧めている16。Whitestone と Woodward は、60 秒より長い設定では、ウェアハウスが問い合わせを処理していない間も課金されると書いた8。

NTT データの技術ブログで井上樹は、あるウェアハウスの直近 3 か月の問い合わせの履歴から、止めるまでの時間を 1〜60 秒で変えたときの課金の時間を計算した。その環境では 11 秒が最も少なく、60 秒にすると、11 秒のときより 50% 以上多くかかった。ただしこの計算は、キャッシュの効果も、Snowflake が止める判断を約 30 秒ごとに行うという動き（井上の説明）も考えに入れていない。井上自身も、最適な値は仕事によって変わり、実際の運用での効果は限られており、理論的な検証の一例として見てほしいと断っている17。

同時に来る問い合わせ：待ち行列とマルチクラスター

ウェアハウスのクラスター一つが同時に処理する問い合わせの数の目安は、設定の MAX_CONCURRENCY_LEVEL で決まり、既定は 8 である18。それを超えて資源が足りなくなると、問い合わせは待ち行列に入る19。

待ちを減らす方法として、文書はウェアハウスを増やすことと、マルチクラスターのウェアハウスにすることを挙げている19。マルチクラスターのウェアハウスは Enterprise エディション以上で使え3、最小と最大のクラスターの数を決める5。

自動スケールのときの増やし方（スケーリングポリシー）は二つある5。

スケーリングポリシー増やし方
標準（既定）問い合わせが待ち行列に入るか、今のクラスターでは足りないと見込むと増やす。待ちを減らすのを優先する
エコノミー増やしたクラスターを少なくとも 6 分は忙しくできる負荷があると見込むときだけ増やす。クレジットを優先し、待ちが出ることがある

文書は、マルチクラスターは同時に来る問い合わせへの備えに向いており、遅い問い合わせやデータの読み込みを速くするには、マルチクラスターよりも大きさを変えるほうが効くとしている5。始めるときは、自動スケールで、最大 2〜3、最小 1 のように小さく設定するよう勧めている5。

ほかの選択肢：Gen2、QAS、Snowpark 用

第 2 世代（Gen2）の標準のウェアハウス： 日本語の文書では第2世代標準ウェアハウスと呼ぶ。速いハードウェアと、削除、更新、表の読み取りなどの処理の改良の上に作られている10。1 時間のクレジットは、AWS と Google Cloud で第 1 世代の 1.35 倍、Azure で 1.25 倍である。たとえば AWS の X-Small は 1.35 クレジットになる。5X-Large と 6X-Large は無い20。世代を指定しないときにどちらになるかは、リージョンや組織を作った時期で変わり、文書の中でも書き方がそろっていない10312。

データ分析のコンサルタント Jeff Skoldberg と Whitestone は SELECT のブログで、AWS では時間が 25.9% 以上縮まないと Gen2 で費用が下がらないと計算した。試した範囲では、Gen2 は手間なく問い合わせを速くし、たいてい費用も下げたとしている。ただし、ウェアハウスがその問い合わせのためだけに動き出す場合は、最低 60 秒分がかかるので、30 秒の問い合わせが 15 秒になっても費用は下がらず、むしろ増えると書いた21。Snowflake の文書も、費用や性能がどれだけ良くなるかを試して確かめるよう勧めている10。

Query Acceleration Service（QAS）： ほかより飛び抜けて多くの資源を使う問い合わせの処理の一部を、共有の計算資源に肩代わりさせる。Enterprise エディション以上で使え、ウェアハウスとは別に課金される22。新しく作る Gen2 とマルチクラスターのウェアハウスでは、既定で有効になっている12。

Snowpark 用に最適化されたウェアハウス： Snowpark は、Python などのコードを Snowflake の中で動かす仕組みである。このウェアハウスは、一つの計算機に標準のウェアハウスの 16 倍のメモリを持たせ、機械学習の学習のように大きなメモリを使う仕事に向く11。既定の構成の Medium は、1 時間に 6 クレジットを使う20。

監視：負荷と、何もしていない時間

ウェアハウスの負荷は、ある時間の区切りの中で、問い合わせが動いていた時間と待っていた時間をそれぞれ合計し、区切りの長さで割って数える。両方を足したものが合計の負荷で、1 なら、その区切りの間ずっと問い合わせ一つ分の仕事があったことになる23。文書に載っている計算では、5 分の区切りで、動いていた問い合わせの負荷が 0.92、待っていた問い合わせの負荷が 0.08 だった23。

文書は、負荷を見てこう判断するよう勧めている23。

負荷の履歴は、ACCOUNT_USAGE の WAREHOUSE_LOAD_HISTORY で 5 分ごとに見られる24。費用のほうは WAREHOUSE_METERING_HISTORY で 1 時間ごとに見られる。ウェアハウスが使ったクレジットの列 CREDITS_USED_COMPUTE と、問い合わせの処理に使った分だけの列 CREDITS_ATTRIBUTED_COMPUTE_QUERIES の差が、何もしていない時間の費用で、文書はそれを出す SQL を載せている25。

Whitestone と Woodward は、ウェアハウスを増やしすぎた例として、SELECT 自身のアカウントで、あるウェアハウスが動いている時間のうち問い合わせを処理していたのは 11% だけで、払っている時間の 89% は何もしていなかった例を、自社の製品の画面で示した8。Well-Architected のコストの柱は、ウェアハウスが動いている時間の 80% で問い合わせを処理していることを、目安の一つに挙げている16。

判断の手がかり：Well-Architected Framework の勧め

Snowflake の Well-Architected Framework のコストの柱は、ウェアハウスの設定について、Snowflake は設定の項目を少なくし、調整を Snowflake 自身が行うことを目指しているが、それでもウェアハウスの設定を正しく選ぶと費用や性能を良くできる場面がある、と書いている16。同じ柱は、ウェアハウスを仕事ごとに分けること、仕事が扱うデータの量に大きさを合わせること、大きいほど速いとは限らないことも挙げている16。性能の柱は、遅い問い合わせに対して、大きくする前にまず原因を調べるよう書いている6。

ウェアハウスの請求は、大きさと動いている時間とクラスターの数で決まる

ウェアハウスは一段大きくするたびに 1 時間のクレジットが倍になり、動き出すたびに最低 60 秒分がかかり、止まるまでの待ち時間にも課金される。マルチクラスターでは、動いたクラスターの数だけかかる。どの大きさを選び、いつ止め、いくつに分けるかで、同じ問い合わせの計算の請求が変わる。

速さが倍になる限り、大きくしても費用は変わらない。待ちが出るときは、大きさではなく数で備える。何もしていない時間の費用は、CREDITS_USED_COMPUTE と CREDITS_ATTRIBUTED_COMPUTE_QUERIES の差として数えられる。

出典25件

  1. Snowflake「Understanding compute cost | Snowflake Documentation」日付なし、2026年10月19日取得. https://docs.snowflake.com/en/user-guide/cost-understanding-compute — クラウドサービスの層の働き。 ↩

  2. Snowflake「Warehouse considerations | Snowflake Documentation」日付なし、2026年10月19日取得. https://docs.snowflake.com/en/user-guide/warehouses-considerations — 大きさの試し方、止める時間の勧め、スケールアップとスケールアウト。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7

  3. Snowflake「Overview of warehouses | Snowflake Documentation」日付なし、2026年10月19日取得. https://docs.snowflake.com/en/user-guide/warehouses-overview — 大きさとクレジット、走った時間ごとの請求の表、自動サスペンド。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13 ↩14 ↩15 ↩16 ↩17

  4. Snowflake「Increasing warehouse size | Snowflake Documentation」日付なし、2026年10月19日取得. https://docs.snowflake.com/en/user-guide/performance-query-warehouse-size — 倍の速さなら費用は同じ。 ↩ ↩2

  5. Snowflake「Multi-cluster warehouses | Snowflake Documentation」日付なし、2026年10月19日取得. https://docs.snowflake.com/en/user-guide/warehouses-multicluster — 最大化と自動スケール、二つのポリシー、クレジットの計算例。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9

  6. Snowflake「Performance」（Well-Architected Framework、Well Architected Framework Team）2026年10月19日取得. https://raw.githubusercontent.com/Snowflake-Labs/sfquickstarts/master/site/sfguides/src/well-architected-framework-performance/well-architected-framework-performance.md ↩ ↩2 ↩3 ↩4

  7. Tamir Rozenberg「Managing Snowflake’s Compute Resources」Snowflake Blog、2020年12月16日、2026年10月19日取得. https://www.snowflake.com/blog/managing-snowflakes-compute-resources/ ↩ ↩2 ↩3

  8. Ian Whitestone、Niall Woodward「Snowflake Cost Optimization: 15 proven strategies for reducing costs」SELECT、2024年2月11日、2026年10月19日取得. https://select.dev/blog/snowflake-cost-optimization-15-proven-strategies-for-reducing-costs ↩ ↩2 ↩3

  9. SELECT「SELECT is joining DoiT to scale our mission of eliminating data platform waste」2026年1月6日、2026年10月19日取得. https://select.dev/blog/select-is-joining-doit-to-scale-our-mission-of-eliminating-data-platform-waste ↩

  10. Snowflake「Snowflake generation 2 standard warehouses | Snowflake Documentation」日付なし、2026年10月19日取得. https://docs.snowflake.com/en/user-guide/warehouses-gen2 ↩ ↩2 ↩3 ↩4

  11. Snowflake「Snowpark-optimized warehouses | Snowflake Documentation」日付なし、2026年10月19日取得. https://docs.snowflake.com/en/user-guide/warehouses-snowpark-optimized ↩ ↩2

  12. Snowflake「CREATE WAREHOUSE | Snowflake Documentation」日付なし、2026年10月19日取得. https://docs.snowflake.com/en/sql-reference/sql/create-warehouse — 大きさと止める時間の既定、Gen2 の既定、QAS の既定。 ↩ ↩2 ↩3 ↩4

  13. Niall Woodward「Choosing the right warehouse size in Snowflake」SELECT、2022年11月26日、2026年10月19日取得. https://select.dev/blog/choosing-the-right-warehouse-size-in-snowflake — 著者は SELECT の共同創業者。 ↩ ↩2

  14. Snowflake「Queries too large to fit in memory | Snowflake Documentation」日付なし、2026年10月19日取得. https://docs.snowflake.com/en/user-guide/performance-query-warehouse-memory — スピル。 ↩

  15. Snowflake「QUERY_HISTORY view | Snowflake Documentation」日付なし、2026年10月19日取得. https://docs.snowflake.com/en/sql-reference/account-usage/query_history ↩

  16. Snowflake「Cost Optimization」（Well-Architected Framework、Well Architected Framework Team）2026年10月19日取得. 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 ↩ ↩2 ↩3 ↩4

  17. 井上樹「このSnowflakeウェアハウスの自動停止時間は何秒が最適なのか？クエリ履歴から算出するコスト最小化検証実験（超節約生活実験）」NTT DATA TECH、2025年12月1日、2026年10月19日取得. https://zenn.dev/nttdata_tech/articles/9df82505179e8a ↩

  18. Snowflake「Parameters | Snowflake Documentation」日付なし、2026年10月19日取得. https://docs.snowflake.com/en/sql-reference/parameters — MAX_CONCURRENCY_LEVEL と STATEMENT_QUEUED_TIMEOUT_IN_SECONDS の既定。 ↩

  19. Snowflake「Reducing queues | Snowflake Documentation」日付なし、2026年10月19日取得. https://docs.snowflake.com/en/user-guide/performance-query-warehouse-queue ↩ ↩2

  20. Snowflake「Snowflake Service Consumption Table」2026年10月12日発効、2026年10月19日取得（アーカイブ）. https://www.snowflake.com/legal-files/CreditConsumptionTable.pdf — Gen2 と Snowpark 用のクレジット。 ↩ ↩2

  21. Jeff Skoldberg、Ian Whitestone「Snowflake Generation 2 (Gen2) Warehouses: Are the Speed Gai…」SELECT、2025年5月23日、2026年10月19日取得. https://select.dev/blog/snowflake-generation-2-gen2-warehouses-are-the-speed-gains-worth-the-cost ↩

  22. Snowflake「Using the Query Acceleration Service (QAS) | Snowflake Documentation」日付なし、2026年10月19日取得. https://docs.snowflake.com/en/user-guide/query-acceleration-service ↩

  23. Snowflake「Monitoring warehouse load | Snowflake Documentation」日付なし、2026年10月19日取得. https://docs.snowflake.com/en/user-guide/warehouses-load-monitoring — 負荷の数え方と例。 ↩ ↩2 ↩3

  24. Snowflake「WAREHOUSE_LOAD_HISTORY view | Snowflake Documentation」日付なし、2026年10月19日取得. https://docs.snowflake.com/en/sql-reference/account-usage/warehouse_load_history ↩

  25. Snowflake「WAREHOUSE_METERING_HISTORY view | Snowflake Documentation」日付なし、2026年10月19日取得. https://docs.snowflake.com/en/sql-reference/account-usage/warehouse_metering_history — 何もしていない時間の費用を出す SQL。 ↩

この記事はAIを使用して執筆されました。内容には誤りが含まれる可能性があります。事実や数字の出典は脚注から確かめられます。