2026年、Snowflakeコスト管理はどう変わるのか(ウェビナー要約)

• Snowflakeのプラットフォームはコンピュートとストレージの枠を大きく超えて拡大しており、新サービスのひとつひとつがコストの新たな死角になり得ます。
• SnowflakeのCortex AI関数は強力ですが、気づかぬうちに数千ドルを溶かしてしまう最も手軽な経路でもあります。あるお客様は、QA環境で実行するはずだったクエリが本番環境で実行され、3日間で6万ドルを費やしてしまいました。
• 最適化の前に、まず可視化が必要です。誰も存在を知らなかった、年間数十万ドル規模のworkloadsが次々と見つかっています。
• ROIが最も高い対策はたいていシンプルです。クエリの書き換えではなく、ジョブの実行頻度を下げることと、ウェアハウスのライトサイジングです。
• 成長する組織でコスト管理をスケールさせるには、あらゆるコストの疑問を中央チームに集約するのではなく、各チーム自身に可視性を持たせることが鍵です。

かつてSnowflakeといえば、コンピュートとストレージのことでした。しかし、それはもはや全体像ではありません。IanとDaveは、お客様がプラットフォーム上で稼働させているサービスの広がりを紹介しました。ネイティブアプリ、Streamlitアプリ、コンピュートプール上にデプロイされた機械学習モデル、急速に拡充するAI機能群、さらにはSnowflakeによるCrunchy Data買収を受けたPostgresのworkloadsまで含まれます。

これらはすべて、請求書の新しい明細項目として現れます。ここで現実的な追跡の問題が生じます。モニタリングの仕組みが新サービスの存在を認識していなければ、そのコストは単純に見えないのです。SELECTでは30名近いエンジニアのチームが、Snowflakeのリリースを先回りして追い続けることだけに専念しており、新しいコスト発生源は数か月後ではなく、リリースと同時にサポートされます。

Daveはさらに、これが単なる技術的な煩わしさにとどまらないと付け加えました。経営層がworkloadsをどこで動かすべきか意思決定する機会は増えており、それを裏付ける本当のコスト透明性なしには判断ができないのです。

SnowflakeのCortex関数(現在はAI SQLと呼ばれています)を使えば、Snowflake内にあるデータに対して直接AIを実行できます。Daveが挙げた例は、製品レビューのうち顧客が不満を表明しているものだけを1本のクエリで絞り込むというものです。数年前であれば、人間がすべてのレコードを手作業で確認してタグ付けする必要がありました。

その利便性には現実的なリスクが伴います。Daveが共有した顧客事例では、Cortex関数を組み込んだクエリがQA環境で実行されるはずが、本番環境のフルデータセットに対して実行され、3日間でトークン料金として6万ドルを消費しました。しかも、使える成果物は何も残りませんでした。

Ianは、なぜこれがいとも簡単に起こるのかを説明しました。AIの利用料は入力トークンと出力トークンで課金されます。入力トークンは、モデルに渡すデータの規模から事前におおよそ予測できます。しかし出力トークンは予測できません。モデルがどれだけ生成するかは質問の内容次第だからです。この非対称性こそが、実行前のAIコストの見積もりを非常に難しくしています。

SnowflakeでのAI支出をどう可視化するか

Snowflakeのaccount usageスキーマには、AI向けのビューが複数含まれています。多くは他のaccount usageビューと同様に、モデル別の時間単位の利用状況を提供します。AI SQL usageビューはクエリ単位で、使用されたモデルとクエリテキストを確認できますが、プロンプト自体は見られません。最も粒度が細かいのはAI observability eventsテーブルです。標準的なビューではなくテーブル関数を通じてアクセスするもので、利用の元となったプロンプトまで確認できます。ただしクエリは遅くなりがちで、Ianの理解では永続化されないため、長期的な分析は難しくなります。

SnowflakeのAI予算とクォータは、暴走する支出を本当に止められるのか

おおむね止められますが、重要な抜け穴がひとつあります。AI予算では、アカウントまたはタグ付けされたオブジェクトグループに対して月間クレジット上限を設定でき、Cortexエージェント、Cortex search、AI関数をカバーし、上限を超えると警告が出ます。ユーザー単位のクォータはさらに踏み込んで利用を実際にブロックしますが、適用の反映には数分かかり、クエリを即座には止められません。

その抜け穴とは、1回の大規模なリクエストが、システムが追いつく前に上限を超えてしまう可能性があることです。Ianが挙げたのは、巨大なレビューテーブル全体に対して感情分析関数を一発で実行するケースです。1万ドルを消費してしまい、ブロックされるのは次のクエリから、ということが起こり得ます。それでもクォータは、繰り返し実行されるケースや週末中走り続けるケースを捕捉できます。Ianは、クォータの設定こそこのセッションから持ち帰るべきただひとつのことだと述べました。ただし、本番環境に触れる前にQA環境で限定的なデータセットでテストするといった基本的な実践の代わりにはなりません。

AI支出のROIをどう測定するか

万能の公式はありません。まずは正確に測定できる側、つまりコストから始めましょう。価値の側はユースケース次第です。AIが既存の何か、たとえば手作業で感情分類をしていたチームを置き換えるのであれば、以前の時間とコンピュートのコストを新しいコストと比較します。新しいことを可能にする場合は、たいてい代理指標で測ることになります。節約できた時間、Jiraのようなシステムから取れるチケットやストーリーの処理速度、回収できた売上などです。いずれも明確な答えにならない場合のIanの提案は率直でした。止めてみて、誰が文句を言うか見ればよい、と。

最適化の作業を始める前に、まず実際にいくらかかっているのかを把握する必要があります。Ianは、初めてSELECTにログインしたお客様の事例を紹介しました。リストの最上位に年間85万ドルのworkloadがあり、その大半は、実はQAジョブの中で動いていたAI関数によるものでした。お客様はそれを停止しました。深い調査は不要でした。可視化だけで解決策が浮かび上がったのです。

Daveも同じ教訓を示す別の事例を紹介しました。Snowflakeからメールを1通送るためだけに年間1万ドルを費やしていたお客様の話です。実際のコストを一目見ただけで、そのworkloadをより安価な場所へ移す決断ができました。また、クエリ単位・workload単位のコストを初めて目にしたお客様から「3か月前に止めたはずなのに」という声をしょっちゅう聞くそうです。

可視化ができたら、次の問いは、その最適化が時間をかける価値があるかどうかです。ストレージで500ドル節約するためにエンジニアの1日を費やすのは割に合いません。数時間で2万ドル節約できるなら迷う余地はありません。Ianのアドバイスは、始める前にその計算を確認し、SQLを書き換える前にすぐ効く施策から片付けること、です。

見るべき場所がわかったあと、最もROIの高い対策は何か

1. 実行頻度を下げる。毎時実行で年間1万ドルかかるジョブは、日次実行で十分なら年間500ドル未満になります。設定変更ひとつで96%の削減です。毎時から3時間ごとに変えるだけでも、コストはおよそ3分の2減ります。
2. ウェアハウスをライトサイジングする。サイズを1段階上げるごとにコンピュートとコストは2倍になるため、大きいウェアハウスが割に合うのは、クエリ時間も実際に半分になる場合だけです。Ianの例では、取り込み用ウェアハウスをLargeからExtra Smallに下げたところ、平均クエリ時間は約5秒から約20秒になりましたが、誰もその遅延に気づかず、年間5万ドルの削減になりました。目安として有効なのが、CPUコア1つあたりスキャン対象パーティション約125個(Largeウェアハウスは64コア)という数字です。つまり、スキャンするパーティションが500個程度のクエリにExtra Smallより大きいサイズが必要になることはまずありません。
3. 「Snowflakeをメッセージキューとして使う」パターンに注意する。Daveは、SnowflakeをKafkaキューのように使い、本来設計されている大きめのバッチ処理ではなく、何百万もの小さな操作を実行しているチームを見てきました。これではウェアハウスが止まることなく稼働し続け、高額になります。workloadに適した技術を選びましょう。
4. 垂直方向だけでなく水平方向のスケーリングも検討する。Daveは、ウェアハウスのサイズは選ぶのにクラスタ数を見落としがちだと指摘しました。workloadによっては、単にサイズを上げるよりクラスタ数を増やすほうが良い結果をもたらします。
5. 難しい書き換えにはAIコーディングエージェントを使う。IanのSELECT社内の例では、実行のたびにフル再作成されていたデータセットに年間8,000ドル超がかかっており、クエリをインクリメンタル化する数時間の作業でその支出が消えました。Cocoのようなコーディングエージェントのおかげで、かつて数日かかったこの種の書き換えが、今では数時間で可能になったとも付け加えています。

データ取り込みについては、Ianによれば通常コンピュート支出の10〜20%程度を占め、その割合は低下傾向にあります。Snowpipe Streamingによって取り込みコストがおよそ10分の1になったお客様もおり、Icebergの採用も効果があります。Daveが挙げた最も簡単な取り込みコスト削減策は2つです。本当に必要なテーブルとカラムだけを取り込むこと、そして「できるだけリアルタイムに近く」をデフォルトにせず、実際のビジネスニーズに合わせた更新頻度にすることです。

DuckDBのような安価なエンジンへworkloadsを移したり、コスト削減のためにIcebergを採用する動きはあるのか

小規模な環境では、時折見られます。小さめの会社であれば、1人のエンジニアが特定のworkloadsをDuckDBのような選択肢に振り分けるのは十分現実的です。一方、集中管理されたアクセス制御を必要とする数千人規模のユーザーを抱える大規模環境では、管理が難しすぎるため稀です。Daveは、Icebergをコスト削減策として捉えたことはあまりないと述べました。Icebergの魅力は相互運用性にあります。追加のコンピュートを費やすことなく、同じデータを多くの場所から再利用できる点です。Ianは、Icebergは取り込みコストを下げ、ストレージの二重払いを避けられるものの、その上で複数のコンピュートエンジンを走らせる例はあまり見ないと補足しました。Daveがより頻繁に見るのは、SnowflakeからDatabricks、PostgresからSnowflakeとその逆など、適性に基づいてworkloads全体をプラットフォーム間で移動させるお客様です。彼にとってそれは、ストレージの最適化ではなくコンピュートの節約の問題なのです。

すべてのコストに関する質問に中央のデータチーム1つで答える体制はスケールしません。かつてその立場にいたDaveは、あらゆるデータ依頼が集中すると小さなチームがボトルネックになる様子を語りました。解決策は、エンドユーザー自身に、自分が発生させているコストへの可視性を与えることです。そうすれば、全員が自分の支出に対して責任ある組織の一員として行動できます。

その出発点はコスト配分です。支出をその責任を負うチームに紐づけることで、各自の注意を自分がコントロールできる範囲に向けられます。見る人によって必要なビューも異なります。経営層は一般に、日・週・月単位でグループ別コストを俯瞰できるハイレベルなダッシュボードを求めます。実務者は、自分のチームが動かしている具体的なものを見たいのです。

その情報に簡単にアクセスできることは、情報を持つことと同じくらい重要です。Daveは、対象者ごとに適切なダッシュボードを構築するか、MCPサーバーへのアクセスを提供してClaudeに適切な質問ができるようにすることを提案しました。Ianは、ユーザーに必要なのは使いやすいUIで提供される厳選された情報であることも多いと付け加えました。「探しに行かせるのではなく、届けてほしい」というわけです。

センター・オブ・エクセレンスには確かな役割がありますが、その範囲は限定的です。中央チームの仕事は、ユーザーにコスト改善の方法を助言し、その知見を組織全体に広めることであって、すべての最適化を自ら引き受けることではありません。Ianの言葉を借りれば、組織全体に代わってこれらを個別に実行するやり方では、いずれ限界が来るのです。