SaaSの価格設定に関する議論は、たいてい入り口を間違えています。
ティア構成で揉め、シート課金にすべきか利用量上限にすべきかで頭を悩ませ、競合をベンチマークし、「いくらなら払うか」を顧客アンケートで探る。そしていざローンチしてみると、マージンがじりじりと縮んでいくのを眺めながら「何が起きたのか」と首をひねる——よくある光景です。
答えははっきりしています。その価格モデルは、実コストではなく見積もりの上に組み立てられていたのです。そして見積もりというものは、驚くほど早く現実と乖離していきます。SaaSユニットエコノミクスの不都合な真実
プロダクト担当VPや価格コンサルタントが新プランのモデルを組むとき、彼らは仮定から逆算して数字を積み上げています。インフラコストは概算、共有リソースの消費は平均値、AIの利用量は推測、顧客ごとのばらつきは一本の線に均される。
モデル上、Growthプランの顧客の提供コストは月80ドル。ところが実際のインフラを辿ってみると、最もヘビーなアカウントでは190ドル近く、最もライトなアカウントでは12ドル程度、というのが現実です。平均だけを見れば問題なさそうに映る。しかしテール側が、静かに事業を蝕んでいるのです。
これは価格戦略の問題ではありません。データの問題です。もっと正確に言えば、必要なデータセットが欠けているという問題です。
なぜギャップが生まれるのか
従来のクラウドコスト管理ツールは、インフラ予算を扱うFinOpsチームのために作られてきました。請求データのエクスポートを読み込み、CloudTrailのログを解析し、支出をアカウント・リージョン・タグで整理する。EC2インスタンスをライトサイジングしたいエンジニアリングチームには十分役立ちます。
しかし価格設定には、まったく役に立ちません。
価格設定チームが必要とするのは、切り口の異なるコストデータです。顧客別、プロダクトライン別、機能別、そして実際に課金している利用単位別に整理されたデータ。請求データのエクスポートは、どの顧客がどのworkloadを走らせたのかを知りません。あるエンタープライズアカウントが、同じプランの他社の40倍のコンピュートを食うスキャンジョブを回していることも把握できません。AI機能がヘビーユーザーには通常ユーザーの3倍のコストを発生させていることも見えないのです。
請求レイヤーには、そもそもそのコンテキストがない。最初からなかったのです。請求レイヤーは、クラウドプロバイダーが顧客にいくら課金するかを伝えるために作られたものであって、各顧客のworkloadを動かすのに実際いくらかかっているかを教えるためのものではありません。
その問いに答えるには、まったく別のデータソースが必要になります。
ランタイムデータが変えるもの
実際のトラフィック、実際のサービスコール、実際のリソース消費をリアルタイムで読み取る——ランタイムデータでインフラを計測すると、コストの見え方は一変します。
どの顧客がどのworkloadを動かしているかが見える。データベースクエリを、それを引き起こした機能まで、さらにその機能を使った顧客まで遡ってたどれる。KafkaやElasticsearchのような共有リソースを観測し、どのテナントがどれだけ消費しているかを、Engineersにタグ付けを頼まずに把握できる。
これは机上の話ではありません。すでに実装され、まさにこの分析を本番環境で行っている企業が存在します。
彼らが見つけているものは何か。
多くの企業は、自社が思い描いていたコスト分布のメンタルモデルが的外れだったと気付きます。最軽量ユーザーと最重量ユーザーの差は、想像よりずっと大きい。ごく一部のアカウント——多くはエンタープライズで、プランスタックの中間帯にいる顧客——が、ARRを実質値引きに見せてしまうほどのペースでリソースを消費しているのです。
ある企業は、提供コストが売上を上回るアカウントを360件発見しました。総エクスポージャーは年間130万ドルの損失。ランタイム按分でコストを顧客に紐付けるまで、この損失は完全に見えていませんでした。しかもそれは、誰もが不採算だと予想していたアカウントに潜んでいたのではありません。健全なARRに見えるプランの中に紛れ込んでいたのです。
AI価格問題は、これから起こることの前触れ
この種のマージン圧迫は、収まるどころか悪化の一途をたどっています。
AI機能は、SaaSプロダクトのコスト構造を、シート課金や従量課金では捉えきれないかたちで変えてしまいます。マルチステップのワークフローを走らせるAIエージェントは、決まった量のコンピュートを消費するわけではありません。複雑さ、入力サイズ、呼び出すツールの数、その過程で燃やすトークン数によって消費量は変動します。同じAI機能を使っている2人の顧客のコストプロファイルが、10倍違うことも珍しくないのです。
もし価格モデルが両者を同じように扱っているなら、片方がもう片方の分を肩代わりしていることになります。
AIの価格設定を正しく組める企業は、トークン消費、エージェントのアクション、ツール呼び出しの回数を顧客単位で見える化し、その現実に沿った価格を組み立てられる企業です。シート単価でもなく、1,000リクエスト単価でもなく、プロダクト内で実際にコストを動かしているドライバーを反映した価格体系——これが求められます。
そのためにはランタイムデータが不可欠です。この粒度でデータを取る方法は、他にありません。
価格設定チームに開かれる可能性
マージンがマイナスに沈んでいるセグメントを、取締役会の資料に上がってくる前に特定できます。プランのティアごとにコストのばらつきが最も大きい層を把握し、実際の消費実態に沿った利用上限やアドオンを設計できます。新機能を価格付けしてリリースする前に、モデル化された仮定ではなく実測のベースラインデータで、マージンへの影響を検証できます。
これまで組めなかった価格モデルも実現可能になります。消費ベースの価格設定は、消費単位あたりの提供コストを正確に把握していれば、もはや賭けではなくなります。バリューベースの価格設定は、課金している成果を生み出すために実際いくらかかっているかを示せるようになれば、堂々と説明できるものになります。
エージェンティック時代においては、この課題はいっそう切迫します。完了タスクごとに250ドル請求するなら、そのタスクの実行コストが80ドルだったのか380ドルだったのかを知らなければなりません。この答えがすべてを変えます——どのワークフローの単価を上げるべきか、どれを設計し直すべきか、現行レートでどの顧客が採算に合っているのか。ランタイムデータがなければ、最も重要な価格判断を目隠しで下していることになります。
価格設定チームがずっと答えたかったのに、なかなか答えられなかった問い——「この顧客に、この価値を届けるのに、実際いくらかかっているのか?」に、ようやく答えられるようになるのです。
その答えを手にしたとき、価格戦略は当て推量ではなくなります。ビジネス上の優位性へと変わります。
次の価格レビューで問うべきこと
パッケージのティア構成や機能ゲーティングを議論する前に、その手前でひとつだけ問いを立ててください。「顧客ごと、プランごと、機能ごとの提供コストを、私たちは本当に把握できているだろうか?」
その答えがスプレッドシートと見積もりに基づくものであれば、その価格モデルは、プロダクトのスケールに耐えられない土台の上に建っています。
まずはコストの現実から始めてください。あとは、そこから自ずと決まります。
Attribute™は、タグ付けを必要とせず、ランタイムデータでクラウドおよびAIインフラのコストを顧客・プロダクト・機能に紐付けます。価格設定チーム向けの仕組みはこちらをご覧ください。