顧客が使えば使うほど、Snowflakeも伸びる——$3.5B到達を支えた「顧客成功連動型」収益設計

FY2025（2025年1月期）、Snowflakeの製品収益は約$3.5Bに到達しました。前年比25%以上の成長です。クラウドデータウェアハウス市場でAWSやGoogleといったプラットフォーム大手と正面から競合しながら、独立系SaaS企業としてこの規模を達成しています。

注目したいのは、成長の質です。新規顧客を大量獲得して数字を押し上げたわけではありません。既存顧客が使えば使うほど、Snowflakeの収益が自動的に増える仕組みが機能した結果です。

シートではなく「消費量」で課金する

多くのSaaSが採用するのは「シート数×月額固定」の課金モデルです。5人が使っても50人が使っても、シート数が同じなら請求額は変わりません。顧客企業の中でツールの活用が広がっても、ベンダー側の収益には反映されません。

Snowflakeはこれをまったく逆の設計にしました。課金はストレージ消費量とコンピュート使用量に連動します。クレジットと呼ばれる単位で使用量を計測し、使った分だけ請求される仕組みです。

顧客企業がデータ分析の用途を広げると、クエリの実行量が増えます。クエリが増えればコンピュートの消費も増え、その分だけSnowflakeへの支払いが増えます。顧客がサービスを深く使い込むほど、Snowflakeの収益も増える構造です。

これがいわゆる「拡張収益型プライシング」です。初回契約を取るための勝負ではなく、契約後の活用拡大が収益拡大に直結する設計になっています。

なぜこの構造が機能するのか

表面的には「使うほど高くなる」だけに見えます。でも実際の機能メカニズムは3つに分解できます。

まず、顧客の成功とベンダーの収益が同じ方向を向いています。固定課金の場合、顧客が積極的に使い込もうとベンダーの収益は変わりません。従量課金では逆です。顧客が活用を増やせばSnowflakeの収益も増えるため、SnowflakeはCSチームに投資する強い事業的メリットがあります。カスタマーサクセス組織が機能するのも、チャーン防止だけではなく、活用拡大が直接収益に結びつくからです。ここは固定シート型のSaaSとは根本的に異なります。

次に、既存顧客に上限なしのアップサイドがあります。固定シート型では、顧客の成長余地は人数上限によって決まります。消費量連動の場合、1社の顧客がデータ活用の範囲を広げるだけで、Snowflakeへの支払いは2倍にも3倍にもなります。月次レポートだけに使っていた顧客が、リアルタイム在庫管理や需要予測・マーケティング分析にも使い始めると、コンピュート消費は数倍に増えます。新規顧客を獲得しなくても、既存顧客の活用深化だけで収益が伸びます。

そして、営業コストをかけずに収益が自動拡張します。新規顧客を1社獲得するには営業活動が必要です。一方、既存顧客の使用量が増えることで発生する追加収益は、基本的に追加コストなしに積み上がります。顧客企業のデータエンジニアがクエリを書いて実行する、その行為そのものがSnowflakeの収益になる構造です。これが「顧客成功＝収益拡大の自動連動」の実態です。

コンピュートとストレージの分離が課金設計を支えた

AWS RedshiftやGoogle BigQueryも同種のサービスを提供しています。Snowflakeの決定的な違いのひとつは、コンピュートとストレージを完全に分離している点です。

従来のデータウェアハウスでは、ストレージとコンピュートが一体型のため、大量のデータを蓄積すると処理能力も同時に拡張しなければならず、コストが膨らみました。Snowflakeはこれを分離し、必要なときに必要なだけコンピュートを使えるようにしました。

この技術設計が従量課金モデルを成立させています。ストレージコストとコンピュートコストを別々に最適化できるため、顧客企業が規模に応じて柔軟に使用量を調整できます。「試しに小さく始めて、成功したら使用量を増やす」という購買パターンが自然に生まれます。参入ハードルが下がり、使い込むほど支払いも増えるという理想的なサイクルが回ります。

技術設計と課金設計が一体になっていることが、Snowflakeの競合優位の核心です。プライシング戦略単体で語られることが多いですが、実際にはアーキテクチャレベルの意思決定と不可分です。

この構造が示す普遍的なパターン

Snowflakeのケースを一言で表すなら、「顧客の成功体験をそのまま収益の増分に変換するモデル」です。

SaaSの多くは初期契約を取ることに集中します。契約後の活用度は「解約されないため」に管理されますが、活用が増えても収益が増えない設計では、深い活用推進にはコストがかかるだけです。従量課金はこの関係を逆転させます。顧客が深く使うことが、そのままベンダーの収益拡大になります。カスタマーサクセスへの投資が費用ではなく、収益拡大への直接投資として機能します。

データ・API・インフラ・コンテンツ消費など、「使用量」を明確に計測できる領域ではこの設計が有効です。逆に、使用量の計測が難しい業務支援ツールや、使用量の差が顧客体験の差になりにくいジャンルでは機能しにくい。設計が機能する領域を正確に見極めることが、まず重要です。

再現するなら何を問い直すか

自分のプロダクトやサービスに応用するとすれば、以下の問いが出発点になります。

顧客が成功したとき、数字として何が増えますか？データ処理量、API呼び出し数、レポート出力数、取引件数——増えるものがあれば、それを課金の軸にできる可能性があります。使用量の定義が先で、プライシングはその後です。

今の課金モデルは、顧客の活用拡大が収益拡大に連動していますか？固定シート型の場合、活用が増えてもベンダーには無関係です。カスタマーサクセスチームが活躍するほど自社収益が増える設計になっているか確認してください。そうでなければ、CSへの投資は常に費用として扱われます。

計測できる「使用量」は何ですか？従量課金の前提は計測可能性です。何を使用量とするかを定義し、それを顧客に透明に示せるかどうかが、実装の最初の一歩になります。この計測の透明性がなければ、顧客は不安を抱えたまま使い続けることになります。

Snowflakeが証明したのは「いいプロダクトを作れば売れる」という話ではありません。プロダクトの使われ方と収益構造を設計で一致させることで、成長が加速するという話です。課金モデルはプロダクト戦略の一部であり、後から変えにくい設計の核心です。$3.5Bという数字の裏には、この設計判断の積み重ねがあります。

AI編集部コメント