Snowflake標準WHがGen2既定化、FinOps担当のコスト再計算

数百人規模の情報システム部門でSnowflake（クラウド型データウェアハウスサービス）の運用とコスト管理を担うFinOps担当者にとって、月次のクレジット消費予算が読めなくなる変更が今年すでに恒久適用されている。Snowflakeは動作変更バンドル2026_03を2026年6月12日の週に全アカウントで無効化不可の状態にし、新規に作成する標準ウェアハウス（クエリ実行の計算リソース単位）のデフォルト世代をGen1からGen2へ切り替えた[1][2]。既存のGen1ウェアハウスは自動移行しないため、影響が出るのは「今後」新規作成する分だけだが、その今後が知らぬ間に積み上がるのがこの変更の厄介な点だ。

対象になるのは、IaC（Infrastructure as Code）テンプレートやdbtの初期設定でウェアハウスを量産している組織、部門ごとにウェアハウスを新規発行する運用をしている組織である。GENERATION句（世代を明示するオプション）を書かないままCREATE WAREHOUSEを実行し続けると、Gen2対応リージョンでは意図せずクレジット単価の高いGen2が既定で作られる。本稿では、BCR-2250の適用範囲と、Gen1・Gen2のクレジット消費・性能差、GENERATION句明示のルール化、そしてFinOps担当が着手すべき予算再試算の手順を順に整理する。

予備知識

• 標準ウェアハウス（Standard Warehouse）: Snowflakeでクエリを実行する計算リソースの基本単位。XSMALLからX6LARGEまでのサイズでクレジット消費量が変わる。
• クレジット（Credit）: Snowflakeの課金単位。ウェアハウスの稼働時間とサイズに応じて消費され、契約単価で金額に換算される。
• 動作変更バンドル（Behavior Change Bundle）: Snowflakeが仕様変更をまとめて段階的に有効化する仕組み。Disabled by default→Enabled by default→Generally Enabledの順で進み、最終段階に達すると管理者による無効化ができなくなる。
• GENERATION句: CREATE WAREHOUSE／ALTER WAREHOUSE文でウェアハウスの世代（Gen1またはGen2）を明示的に指定するオプション。

クレジット単価変動を組織横断で予算化・意思決定する枠組みを、Snowflake以外の文脈も含めて整理できる

クラウドFinOps 第2版 ―協調的でリアルタイムなクラウド価値の意思決定

created by Rinker

• Amazon
• 楽天市場
• Yahooショッピング
• メルカリ

BCR-2250とは何か、Gen2既定化はどこまで適用されるか

BCR-2250は新規標準ウェアハウスの既定世代をGen1からGen2へ切り替える変更で、既存ウェアハウスは対象外という点が実務上の急所になる。

動作変更バンドル2026_03は2026年4月のリリース10.12でDisabled by defaultとして提供が始まり、5月8〜14日のリリース10.17でEnabled by defaultへ、6月12〜18日のリリース10.21でGenerally Enabledへ進んだ[2]。Generally Enabledに達した機能は管理者が個別に無効化できないため、この記事執筆時点（2026年8月）ではすでに全アカウントで恒久適用されている。Snowflakeはこの変更の影響度を「Medium」と分類している[2]。

適用条件には地域差がある。Gen2に対応したリージョンでのみ新規ウェアハウスの既定がGen2になり、Gen2非対応のリージョンでは引き続きGen1が既定のままだ[1]。

Snowflakeが個別に非対応と挙げているのはAWS EU（Zurich）、AWS Africa（Cape Town）、GCP Middle East Central2（Dammam）、Azure US Gov Virginia（FedRAMP High PlusおよびStandardの両環境）である[3]。加えてBCR-2250本文は、中華人民共和国内のリージョンではGen2標準ウェアハウス自体が提供されず、この動作変更も適用されないと明記している[1]。この非対応リストに含まれない主要リージョンの多くは、すでにGen2既定化の対象と考えたほうがよい。

既存のGen1ウェアハウスについては、Snowflakeが「稼働中・サスペンド中を問わず、明示的に変更しない限りGen1のまま」と明記している[1]。加えてX5LARGEとX6LARGEの2サイズはGen2に対応しておらず、サイズ指定だけで常にGen1になる[3]。

ウェアハウス設計とコスト管理の基本操作を、現役データエンジニアの実務目線で押さえられる

ゼロからのデータ基盤 Snowflake実践ガイド

created by Rinker

• Amazon
• 楽天市場
• Yahooショッピング
• メルカリ

Gen1とGen2でクレジット消費と処理性能はどれだけ変わるか

Gen2は同一サイズでクレジット消費が2〜3割増えるが、処理時間の短縮で相殺されるケースが多く、単純な値上げとは言い切れない。

Snowflakeが公開するService Consumption Table（2026年8月18日発効版）によると、Gen2のクレジット消費率はAWSとGCPでGen1の1.35倍、Azureで1.25倍である[4]。具体例として、LARGEサイズのGen1が1時間あたり8クレジットの場合、同サイズのGen2はAWSで10.80クレジット、Azureで10.00クレジットになる[4]。

一方で性能面では、Snowflakeはコア分析処理でGen1比約2.1倍、DELETE・UPDATE・MERGEなどのDML処理で最大4.4倍高速という数値を2025年5月2日時点で公表している[5]。GA発表時にはCanvaが移行後にコストを約3割削減した事例、Brazeがユーザープロファイル処理のコストを6割削減しGDPR対応処理を4割高速化した事例が紹介されている[5]。

単価上昇分を処理時間短縮とダウンサイジングで吸収できるかどうかは、ワークロードのクエリ特性次第で変わる。ここが予算再試算で最も検証すべき点になる。

FinOpsの費用分解

Bedrockコスト可視化強化、LLM利用のFinOpsが動き出す

生成AI基盤としてAmazon Bedrock（マネージド生成AI基盤、複数の基盤モデルをAPI経由で呼び出せるサービス）を使う企業が増えている。複数モデルを切り替えながら使える利便性の裏で、月次の請求書に並ぶのは合計金額だけ、という状態[…]

なぜGENERATION句を明示するルール化が必要か

デフォルト任せの運用を続けると、Gen2対応リージョンで作成する新規ウェアハウスは意図せずクレジット単価の高いGen2になるため、作成時に世代を明示する運用ルールが要る。

世代の指定はCREATE WAREHOUSEまたはALTER WAREHOUSEのGENERATION句、あるいはRESOURCE_CONSTRAINTパラメータで行う[3]。

CREATE WAREHOUSE my_wh GENERATION = '2';
ALTER WAREHOUSE my_wh SET GENERATION = '2';
-- 代替表記
CREATE WAREHOUSE my_wh RESOURCE_CONSTRAINT = STANDARD_GEN_2;

問題は、IaCテンプレートやdbtプロジェクトのCREATE WAREHOUSE文にGENERATION句が最初から書かれていないケースが大半である点だ。テンプレートを更新しない限り、量産されるウェアハウスは今後すべてGen2既定になる。TerraformのSnowflakeプロバイダなど既存のリソース定義に世代を指定する記述がなければ、モジュールを呼び出すたびにSnowflake側の既定値がそのまま適用される仕組みも同じ構造の落とし穴だ。

たとえば月内に新規ウェアハウスを10個、既定世代のまま作成した場合、AWSでは同数をGen1で作った場合より最大で約35%多いクレジットを消費する計算になる[4]。ウェアハウス変更申請のレビュー項目にGENERATION句の指定有無を加えておけば、この見落としを承認段階で止められる。

FinOpsの視点では、GENERATION句を全社共通のテンプレートと承認フローの両方に明記するルール化が、コスト予測可能性を保つ最短経路になる。

データ基盤のクラウド横断

GCP「borderless Lakehouse」、脱ETLのマルチクラウド分析基盤

SnowflakeとBigQueryを事業部ごとに使い分け、両者をまたぐデータ統合基盤の刷新を検討している数千人規模企業のデータ基盤担当者は、部門横断の分析を行うたびにETL（Extract-Transform-Load、データを抽出・変[…]

FinOps担当が着手すべきコスト再試算と予算見直しの手順

FinOps担当が取るべき対応は、既存Gen1の棚卸、新規分のクレジット再試算、ルール化、月次モニタリングの4ステップに整理できる。

倍率の話だけでは足りない。同じ2026_03バンドルのBCR-2269により、新規に作成するGen2およびマルチクラスタウェアハウスでは、クエリアクセラレーションサービス（QAS）が既定で有効になる。既定の最大スケールファクタは2で、ウェアハウスサイズの2倍までコンピュートを追加で借りられる[6]。QASの消費はウェアハウス利用とは別建てで課金されるため[7]、1.35倍だけを反映した試算は体系的に過少になる。再試算では、Gen2の倍率とQASの追加分を分けて見積もる必要がある。

第一に、SHOW WAREHOUSESで既存ウェアハウスの世代を棚卸しする。自動移行はないため、現状の大半はまだGen1のはずだが、これを前提の起点として記録しておく必要がある。第二に、今後新規作成が見込まれるウェアハウス分について、AWS・GCPは1.35倍、Azureは1.25倍の単価上昇を反映した予算を再試算する[4]。既存の年間クレジット予算をそのまま据え置くと、新規発行分が積み上がるほど期中の予算超過リスクが高まる。

第三に、GENERATION句明示のルールをIaCテンプレートと申請フローの両方に反映する。第四に、月次のクレジット消費を世代別に分解してモニタリングし、Gen2化でダウンサイジングが可能な箇所を継続的に洗い出す。処理時間短縮を活かしてワンサイズ小さいウェアハウスに切り替えられれば、単価上昇分を相殺できる余地がある。

棚卸しの単位はウェアハウス単体だけでなく、利用部門やプロジェクト単位のチャージバック区分に揃えておくと、Gen2化によるコスト増減を利用側に説明しやすくなる。月次モニタリングでは新規作成分のクレジット消費が再試算の前提から外れていないかを確認し、乖離が大きい部門から優先的にヒアリングする運用が現実的だ。ダウンサイジングの検証は、まず影響が小さい非本番環境のウェアハウスから試すと、本番のSLAを損なわずに効果を見極められる。

SIer保守契約下の日本企業でGen2既定化への対応が遅れやすい理由

Gen2既定化の技術的な挙動そのものは日本企業でも海外企業と変わらないが、対応までの所要時間には差が出る。

まず前提を押さえておく。非対応リージョンにAWS Tokyo・AWS Osaka・Azure Japan Eastはいずれも含まれない[1][3]。つまり国内から使う主要リージョンはすべてGen2既定化の対象で、「日本は当面関係ない」という判断はできない。

多くの日本企業はSnowflake運用をSIerに委託し、ウェアハウス作成はSIerが管理するTerraformやdbtのテンプレート経由で行われる。テンプレートにGENERATION句を追加する改修は保守契約上の作業依頼になり、契約範囲や工数の確認から始まる場合が多い。加えて年度予算は稟議で確定済みのことが多く、期中のクレジット単価上昇を反映した追加予算は通常の予算サイクル外の申請になりやすい。

IT部門の判断は、GENERATION句明記のテンプレート改修をSIerとの次回保守契約更改を待たずに依頼することに尽きる。決裁側の判断は、期中のクレジット単価変動を織り込んだ予備予算枠をあらかじめ承認プロセスに組み込むかどうかで、これを認めない限り稟議の往復が対応の遅延要因として残る。

まとめ

今回の変更の核心は、Gen2化そのものが値上げではなく、GENERATION句を明示しない限り新規作成分のクレジット単価が予測できなくなる点にある。AWS・GCPで約1.35倍、Azureで約1.25倍という単価上昇は、Snowflake公表のコア分析2.1倍・DML最大4.4倍という性能改善で相殺できる場合があるが、それはワークロード次第だ。

IT部門担当者の次の一手は、IaCテンプレートとdbtプロジェクトのCREATE WAREHOUSE文を洗い出し、GENERATION句を明示する改修を優先着手することだ。決裁側の判断材料は、新規作成分の単価上昇を織り込んだ期中予備予算を承認プロセスに組み込むかどうかであり、既存Gen1ウェアハウスは自動移行しないため急ぐ必要はないが、新規分は待ったなしという点を押さえておく必要がある。

よくある質問（FAQ）

Q1. 既存のGen1ウェアハウスは自動的にGen2に変わりますか。
変わりません。稼働中・サスペンド中を問わず、ALTER WAREHOUSEで明示的に変更しない限りGen1のままです[1]。

Q2. Gen2のクレジット消費は必ずGen1より高くなりますか。
単価はAWS・GCPで約1.35倍、Azureで約1.25倍高くなりますが、処理時間短縮とダウンサイジングで総コストが相殺・低下する場合もあります[4][5]。

Q3. 既存のGen1ウェアハウスをGen2に切り替えるにはどうすればよいですか。
ALTER WAREHOUSE 名前 SET GENERATION = ‘2’、またはRESOURCE_CONSTRAINT = STANDARD_GEN_2で明示的に指定します[3]。

出典