シートベース価格は終わりつつある。その後継となるモデルとは

シートベース価格が成り立っていたのは、ソフトウェアがデスクトップのものだった時代です。ユーザーがいて、その数を数え、ライセンスごとに支払う。提供される価値とコストの関係は、おおむね明快でした。

AI による自動化、ワークフローオーケストレーション、人手を介さずにプロセスを実行するツールの時代に、人間のシート単位で課金することは、価値が実際に生み出される仕組みとの乖離をますます広げています。レコードを自動で補完し、通話を自動で要約し、フォローアップメールを自動で生成する CRM は、営業担当者が席に着いているかどうかにかかわらず、意味のある仕事をしています。ワークフロー自動化プラットフォームは、誰もキーボードに触れなくても、一晩で1万件の顧客レコードを処理できます。シート単位のモデルは、そのどちらの成果にも値段をつけられません。

ベンダーは価格体系を、多くの買い手が調達モデルを見直すより速く切り替えています。このずれが、直近の3年間のエンタープライズ契約に署名したときには、どの CFO も予想しなかった予算超過を生み出しています。

シートベース価格が構造的な圧力にさらされている理由

3つの独立した力が、同時にシートベースのモデルに押し寄せています。

AI はシートを補強するだけでなく、置き換えつつあります。 エンタープライズ向けソフトウェアの生産性ツールが当初約束したのは、シート1つあたりの生産性を高めることでした。いま見え始めている現実は、一部の機能を、シートを持たない AI エージェントが担うようになっていることです。かつてアウトバウンドのシーケンスを回すために15人の SDR を必要としたセールス開発チームは、いまや5人の SDR と AI オーケストレーションレイヤーで、同程度のボリュームをこなせます。この変化は、セールスパイプラインにおける AI エージェントで詳しく取り上げています。シート単位で支払っていて、シート数が減っていくなら、ベンダーは別の価格レバーを必要とします。AI のアクションや API コールに対する使用量ベースの価格設定は、その最有力の選択肢です。

ワークフロー自動化は、利用パターンを変えます。 従来のシートベースのツールは、機能の消費量が人員数に比例すると想定していました。マーケティング担当者が1人でマーケティングプラットフォームを使い、その利用量は勤務時間に応じて増えるという前提です。ワークフロー自動化は、この前提を覆します。1人の担当者が、自分が関与しなくても1日に1,000回実行されるワークフローを設定できます。提供される価値は、シート数とは無関係になります。

企業は、使われていないシートへの支払いを拒み始めています。 シートベース価格への最も直接的な圧力は単純です。組織がライセンスを棚卸しした結果、支払い済みのシートの30〜40%が、ほとんど、あるいはまったく使われていないことに気づいているのです。Productiv の SaaS 管理に関する調査によると、平均的なエンタープライズは、SaaS 支出の37%を、十分に活用されていないツールやシートに費やしています。この分析を実施した調達チームは、更新の交渉で強く押し返しています。シートベース価格にこだわるベンダーは、アクティブな拡張の場面では取りこぼしを出し、更新の場面ではシート1つ1つを巡って争うことになります。

台頭する4つのモデル

使用量ベースの価格設定。 消費したものに対して支払います。API コール、AI アクション、処理したレコード、送信したメール、使用したストレージなどです。通信分野の代表例は Twilio、データ分野では Snowflake です。OpenView の年次 SaaS ベンチマークは、この変化を追跡しています。使用量ベースの価格設定は、スタートアップ向けの差別化要因から、成長ステージとエンタープライズのソフトウェアの双方で主流のモデルへと移りました。新しい CRM や生産性ツールのベンダーは、以前は定額のシート機能だった機能に、使用量メーターを加えつつあります。とりわけ、コスト構造が本当に変動する AI 機能で顕著です。

買い手側のリスクは、ビルショックです。使用量ベースの価格設定は、予測の責任を、ベンダー（固定のシート費用）から買い手（変動する消費コスト）へと移します。使用量を少なく見積もった企業は、予算を超える請求書に直面しますが、容易な救済手段はありません。多く見積もった企業は、コミットした最低料金に無駄なお金を払うことになります。

成果ベースの価格設定。 ソフトウェアが定義された結果をもたらしたときに支払います。このモデルは、パフォーマンスマーケティング（クリック課金、コンバージョン課金）で最も成熟していますが、B2B SaaS でも登場しつつあります。一部のレベニューインテリジェンスプラットフォームは、影響を与えたパイプラインや成約した案件に基づいて課金します。リーガルテックのプラットフォームには、処理した契約数に基づいて課金するものがあります。HR テックのプラットフォームには、成立した採用数に基づいて課金するものがあります。

成果ベースの価格設定は、ベンダーのインセンティブを買い手の成果に一致させるため、理想的に聞こえます。交渉上の難しさは、「成果」が何を意味するのかを定義すること、それをほかの要因ではなくソフトウェアの貢献として帰属させること、そして測定方法が正確であると同時に操作されにくいことを確保することにあります。

モジュールベースの価格設定。 シート単位ではなく、利用するユーザー数にかかわらず、有効にした機能モジュールごとに支払います。HubSpot のこのモデルへの移行は示唆に富んでいます。各ハブでシートに課金するのではなく、価格の一部を、機能へのアクセス（Marketing Hub、Sales Hub、Service Hub）に対して支払うモデルへと移し、各ティア内ではより柔軟なユーザーアクセスを認めています。こうした価格構造が実際の評価の場面でどう働くかは、Rework と HubSpot CRM の比較をご覧ください。

モジュールベースの価格設定は、特定の機能を、多くのライトユーザーにわたって深く使いたい買い手に向いています。モジュールの機能の一部しか必要ないのに、価格設定がモジュール全体を求める場合には、破綻します。

ハイブリッドモデル。 エンタープライズ向けソフトウェアの多くは、ハイブリッドな構造に落ち着きつつあります。コアユーザー向けの基本シート課金に、消費量の多い機能への使用量ベース課金を組み合わせるものです。Salesforce の Einstein AI の価格設定、HubSpot の Operations Hub、Monday.com のエンタープライズ向け AI アドオンはいずれもこのパターンに従っています。コミットした基本料金に、AI 搭載機能の変動する消費料金が上乗せされる形です。

ハイブリッドモデルは、最も一般的であり、最もわかりにくいものです。年間18万ドルの Salesforce 契約を承認した CFO は、AI 機能によって第3四半期までに4万ドルの使用料が加わるとは想定していなかったかもしれません。契約上は認められていました。予算の議論では、それを想定していなかったのです。

ビルショックの問題

ビルショックは、使用量ベースの価格設定における買い手側の最大のリスクです。理論上の話ではなく、記録されているパターンです。Zuora の Subscription Economy Index は、使用量ベースの収益がほかのどの価格モデルのカテゴリーよりも速く成長したこと、そしてそれに伴って予期しない請求書に対する買い手の不満も増えたことを示しています。

仕組みは単純です。買い手には、新しい機能の使用量を予測するための優れたモデルがありません。企業が使用量ベースの AI 機能を初めて採用するとき、消費ペースは経験に基づく推測にすぎません。その推測はしばしば外れ、ベンダーはそのばらつきから利益を得ます。ベンダーのコストはユニットエコノミクスで上限が決まり、御社のコストは御社の消費量で決まるからです。

使用量ベースの契約でビルショックを防ぐ契約条項は3つあります。

通知トリガー付きの使用量上限。 請求額が定義されたしきい値に達する前に、ベンダーが通知し、御社が明示的に継続を承認しない限り消費を停止します。多くのベンダーはハードキャップに抵抗します（ソフトな警告を好みます）が、通知トリガーは交渉可能です。過去90日間の平均消費量を上限とし、75%に達した時点でメールアラートを出すのが、妥当な出発点です。

ロールオーバー付きの料金下限とコミット最低料金。 月間の最低消費量にコミットするなら、未使用分のロールオーバーの権利を交渉してください。ロールオーバーがなければ、未使用の最低料金は失効し、超過料金は別途発生します。ロールオーバーがあれば、消費が超過した月は、まず積み立てた枠から差し引かれます。これにより、正味のばらつきは大幅に減ります。

精算の頻度。 年次の精算は買い手に有利です。月次ではなく、年度末に消費量を突き合わせるからです。月次の精算では、請求額が毎サイクル変動し、キャッシュフローと予算管理が複雑になります。月次の精算請求ではなく、月次の上限を設けたうえで、四半期ごとまたは年次の精算を求めてください。

調達で変わること

シートベースのソフトウェアの予算編成は単純です。人員数に1シートあたりの費用を掛け、人員が大きく増えたら変更注文を出します。財務部門はそのシナリオを自信を持ってモデル化できます。

使用量ベースのソフトウェアの予算編成には、別の分析アプローチが必要です。必要なのは人員モデルではなく、消費モデルです。具体的には次のとおりです。

使用量のベースラインを構築する。 使用量ベースの契約に署名する前に、30〜60日間をトライアルまたは限定的な導入に費やし、実際の消費ペースを記録します。ベンダーの見積もりを鵜呑みにしないでください。使用パターンは、御社のワークフローとデータ量に固有のものです。ベンダーの見積もりは、御社には当てはまらない可能性のある平均値に基づいています。

ばらつきのシナリオをモデル化する。 単一の予算額ではなく、3つのシナリオで消費予測を組み立てます。ベースライン（想定する使用量）、成長（導入が順調に進んだ場合のベースラインの20%増）、スパイク（大規模なキャンペーンやデータベース移行などの、特定の高消費シナリオ）です。予算は、緊急の承認を必要とせずに、成長シナリオを吸収できる設計にしてください。

AI 機能の予算を分ける。 AI 機能は、従来のソフトウェア機能とはまったく異なるコスト構造を持っています。チームでの利用拡大や新しいユースケースによって、消費量が予測不能に急増することがあります。AI アドオンの予算は、基本プラットフォームの費用とは別の項目として扱い、予算サイクルに四半期ごとの見直しを組み込んでください。

複数年の使用料率を交渉する。 複数年契約を結ぶなら、シート価格の固定だけでなく、消費単価の固定を交渉してください。シート費用は固定しても、API の価格をベンダーが毎年変更できる3年契約は、見かけほどの保護にはなりません。CRO が磨く予測の規律は、ここに直接当てはまります。消費のモデル化は予測の問題であり、予測のケイデンスが確立しているチームほど、うまく対処できます。

価格モデルのリスク評価

署名の前に、どのような価格構造についても、このフレームワークを使って3つの観点から評価してください。

予算の予測可能性スコア（1〜5）： この価格構造で、毎月の請求額はどれだけ予測できるか。定額のシート料金は5です。上限なしの完全な使用量ベースは1です。上限と通知トリガー付きのハイブリッドは3〜4です。スコアをつけたうえで、御社の予算管理プロセスが、その価格構造が持ち込むばらつきの水準を吸収できるかどうかを判断します。

ベンダーとの利害の一致スコア（1〜5）： 御社がより多くの価値を得たとき、ベンダーはより多く稼げるか。成果ベースの価格設定では、ベンダーの収益は御社の成果に連動します（スコア：5）。年次更新の純粋なシートベース価格では、ベンダーのインセンティブは、初年度の御社の価値を最大化することではなく、更新時に御社を囲い込むことにあります（スコア：2〜3）。使用量ベースの価格設定はその中間に位置します。ベンダーの収益は御社の消費量に連動しますが、消費量は価値と相関するものの、価値を直接測るものではありません。スコアをつけたうえで、その価格構造が、ベンダーに持たせたいインセンティブを生むかどうかを検討してください。

更新時の交渉力スコア（1〜5）： 更新時に、どれだけの交渉力を持っているか。乗り換えコストの高いシートベース契約では、更新時に弱い立場に置かれます。移行コストを負担する覚悟がない限り、交渉力は限られます。使用量ベースの契約では、データが手に入ります。実際に消費した量を正確に示し、予測と比較して、エビデンスに基づいて交渉できます。成果ベースの契約は、成果が測定可能で、それが自社の貢献だと説得力をもって示せるなら、最も強い交渉力を与えてくれます。3年後の更新の交渉がどのようなものになるかを基準に、契約ごとにスコアをつけてください。

3つのスコアを合計します。合計10〜15なら、扱いやすい価格構造です。8を下回る場合は、署名の前により強い交渉が必要です。これは合否を判定するツールではありません。交渉の切り札をどこに使うべきかを教えてくれる、リスクプロファイルです。

買い手がいますぐやるべきこと

現在の契約がシートベースで、今後12か月以内に更新を迎えるなら、更新の交渉の様子は変わっています。使用量ベースやハイブリッドの価格設定へと移行しようとしているベンダーは、更新を切り替えの機会として使おうとします。初期価格は現在のシート費用と同程度に見えても、利用が増えると請求額が大きく膨らむ使用量ティアが組み込まれていることが少なくありません。

署名の前に、次のことを尋ねてください。

「AI 機能を全ユーザーに展開した場合、価格はどうなりますか？」具体的な金額を聞き出してください。「使用量に応じて増えます」といった曖昧な答えでは不十分です。全面的に導入したときの総額を知る必要があります。

「この価格モデルの下で、最も急成長しているお客様の請求額は、2年目に1年目と比べてどうなりましたか？」これによって、モデル上の理論的な挙動ではなく、実際のばらつきのパターンが見えてきます。

「使用量ベースの要素には、どのような上限や保護措置が用意されていますか？」これに具体的に答えられないベンダーは、リスクの兆候として扱ってください。

シートベース価格からの転換は、本質的に買い手に不利というわけではありません。成果ベースの価格設定は、うまく運用されれば、買い手がソフトウェアの価値を考える方法により近いものです。使用量ベースの価格設定は、適切な上限とモデル化があれば、効率的な導入に報い、使われていないシートに対して罰を与えることはありません。価格モデルの変更を踏まえてプラットフォームの乗り換えが理にかなうかを検討するチームにとって、Rework と Salesforceのような直接比較は、さまざまな価格構造の下での実際の TCO をモデル化する、有用な出発点になります。

しかし、移行期には非対称なリスクが生じます。ベンダーは、多くの買い手が評価フレームワークを見直すより速く、新しいモデルへ移行しています。消費モデルも交渉した上限もないまま使用量ベースの契約に署名する買い手は、値付けしていないリスクを引き受けています。交渉が始まる前に分析フレームワークを構築する買い手は、対等な立場で交渉できます。

関連記事

• ミッドマーケット企業におけるソフトウェアスプロールの本当のコスト：価格モデルの分散が、ツールを抱えすぎるコストをどう増幅させるか
• 新しい B2B 購買委員会：会議室に本当にいるのは誰か：価格モデルの転換について、社内の誰が承認すべきか
• 成功を予測する POC と、全員の時間を無駄にする POC：消費モデルにコミットする前に、使用量ベースのツールをどう評価するか