使用量ベースの料金体系は、パブリッククラウド、プライベートクラウド、または組み込み型の展開を通じてソフトウェアを提供する企業にとって最も一般的なアプローチとなっています。2026 年時点で、サプライヤーの 74% が使用量ベースのモデルを採用しており、56% が 2027 年までに使用量ベースの収益が増加すると予測しています。
使用量ベースの料金戦略は単純そうに聞こえるかもしれませんが、実行には連鎖的な意思決定が伴います。選択した価値指標がパッケージを形作り、パッケージが料金体系ページを形作ります。料金体系ページが顧客による請求額の解釈を形作ります。また、顧客が請求額をどのように解釈するかによって、移行がスムーズに進むか、解約やサポートチケットが大量に発生するかが決まります。
以下では、価値指標の選び方、モデルを説明する料金体系ページの設計方法、そして本来は堅実な使用量ベースの料金体系の立ち上げを台無しにしてしまう実行ミスについて説明します。
ハイライト
適切な価値指標の選択が重要です。顧客が予測または制御できない指標は、他のすべてを適切に実行しても、料金体系モデルを損なうおそれがあります。
移行の順序付けが重要です。新規顧客を先に移行し、次にオプトイン移行を行い、その後セグメントごとに展開します。
予想外の高額請求は製品の問題です。支出上限、製品内での使用状況の可視化、プロアクティブな通知は、料金体系と同時にリリースする必要があります。
SaaS の使用量ベースの料金体系とは
サービスとしてのソフトウェア (SaaS) (サブスクリプション型アクセスのソフトウェア) の使用量ベースの料金体系では、顧客はアクセスに対する定額料金ではなく、使用量に基づいて支払います。使用量ベースの SaaS 料金体系は、送信メッセージ 1 件ごとに請求される Twilio、クレジット 1 件ごとに請求される Snowflake、トークン 1 件ごとに課金される多くの人工知能 (AI) アプリケーションプログラミングインターフェース (API) を支えるモデルです。
SaaS 製品の使用量ベースの料金体系で選択すべき価値指標
使用量ベースの料金体系における価値指標は、顧客の支払い方法を決定する測定単位です。料金体系のその他すべての要素は、この選択から導かれます。
優れた指標には 3 つの特性があります。
価値に応じて拡張: 顧客が製品を使用する量が増えると、金額が増加します。たとえば、50 万件のレコードを処理する顧客は、5,000 件を処理する顧客より多く支払うことになります。
登録前に把握しやすい: 顧客は、他の情報を求めることなく、すでに持っている情報だけで請求額を見積もることができます。
明確に測定可能: サービスのコスト計算方法を顧客に明示できます。
SaaS の使用量ベースの料金体系と AI 製品における有効な指標としては、API コール、アクティブユーザー、処理済みレコード、保存または転送されたギガバイト (GB)、完了したエージェントアクション、消費済みトークンなどが挙げられます。
うまく機能しない傾向がある指標には、以下のものがあります。
内部コンピューティングユニット: 顧客が監視または制御できない「処理ユニット」ごとに請求している場合、更新時に顧客の混乱や反発が生じる可能性があります。
価値の増加を伴わずに増加する指標: データベースの行数に基づく請求は一見シンプルに思えますが、顧客が製品の利用とは見なさない日常的なバックグラウンド操作によって行数が膨らむことに気づいた時点で問題が生じます。
顧客が制御できない指標: 顧客の意図的な行動ではなく、システム側の動作に基づいて数値が増加する場合、信頼を急速に損なうことになります。
顧客がすでに持っている情報だけで毎月の請求額を素早く見積もることができない場合は、指標を見直す必要があります。
指標を選択した後の使用量ベースの料金体系の仕組み
SaaS の使用量ベースの料金体系では、計量 (イベントレベルでの使用量の正確なカウントなど)、レーティング (未加工の使用データをドル金額に換算するなど)、請求処理 (請求書の提示と支払いの回収など) の 3 つの要素が機能することが必要です。
指標を選択して使用量を計量すると、レーティングは次の 3 つの形式をとります。
ユニットごとの定額料金: 各ユニットの料金は、ボリュームに関係なく同じです。これは説明が簡単で、顧客の使用量が安定している場合に適しています。
数量段階制: 使用量がしきい値を超えると、ユニットあたりの価格が下がります。たとえば、最初の 10,000 コールの料金は 1 コールあたり $0.002、次の 90,000 コールは $0.0015 です。最も利用量の多い顧客がより低いユニットコストの恩恵を受けるこの仕組みは、インフラストラクチャー型製品では標準的です。
段階制: 各段階のレートは、その段階のユニットにのみ適用されます。顧客は、一律の混合レートではなく、使用量の各ブロックに対して常にその段階のレートを支払います。
Stripe の Billing インフラストラクチャーはこの 3 つのモデルをすべて処理できるため、レーティング済みの請求書をゼロから構築していた財務チームやエンジニアリングチームの負担を軽減できます。シンプルさを優先するなら定額制、ボリューム割引によって拡大を促したい場合は数量段階制または段階制を選択することを推奨します。
使用量ベースの料金体系のオファーをパッケージ化する方法
従量課金 (PAYG) は、提供側には予測しにくい収益、顧客側には予測しにくい請求をもたらす可能性があります。開発者向けツールの段階を超えて成熟した製品の多くは、ハイブリッドモデルを採用しています。これは、一定の使用量を含むベースサブスクリプションと、その使用量を超過した場合の超過料金を組み合わせたモデルです。ベースは予測可能な経常収益を提供し、超過分は顧客の成長とともに収益拡大をもたらします。
どのモデルを選択する場合でも、予測可能性を高める以下の 4 つの仕組みは最初から導入する価値があります。
無料枠またはトライアルクレジット: 従量課金が開始される前に提供される固定の使用量です。AI API では一般的な仕組みで、$5〜$10 程度のクレジットにより開発者がテストできます。
支出上限: 顧客が月次請求額に設定する上限額です。上限を下回る間は製品が通常どおり動作しますが、上限に達すると使用を一時停止するか、アップグレードを促す通知を表示します。これは開発者ツールでは一般的な仕組みで、暴走したスクリプトによって、顧客が $40 を想定していたにもかかわらず $4,000 の請求が発生することがあります。
利用コミット割引: 顧客は、単価を低く抑える見返りとして最低利用量にコミットします。予算の見通しを重視する大手顧客に適しています。
バンドル: PAYG よりも割引価格で販売される、あらかじめパッケージ化された使用量です。「$15 で 10,000 コール」対 1 コールあたり $0.002 といった形で提供されます。正式なコミットなしに予測可能性を求める、使用量を予測できる顧客に適しています。
使用量ベースの料金体系への移行を、既存の顧客ベースの解約を防ぎながら段階的に進めるには
既存の製品を、まったく新しい製品を立ち上げるのではなく、使用量ベースの料金体系に移行する場合、移行が難しくなることがあります。次のような選択肢があります。
まず新規顧客から
既存の顧客が現在のプランを維持しながら、すべての新規登録に使用量ベースの料金体系を導入することを検討してください。既存の顧客ベースに影響を与える前に、少なくとも 60〜90 日間はこの戦略を継続することを推奨します。より広範な展開にコミットする前に、購入率、平均支出額、予想外の高額請求に関する苦情の実データが必要です。
次はオプトイン移行
一時的なレート割引やボーナスクレジットなどのインセンティブを提供し、既存の顧客に自発的な切り替えを促します。先行提供版として位置づけることが効果的です。最初にオプトインした顧客は、多くの場合、最もエンゲージメントの高いユーザーであり、他のすべてのユーザーにプロセスを展開する前に、何がわかりにくいかをフィードバックしてくれます。
セグメントごとの展開
必須移行に進む際は、最も規模が小さいか、リスクの低いコホートから始めます。たとえば、PAYG の柔軟性から失うものが少なく、得るものが大きい、最下位プランの月次サブスクリプション登録者などが該当します。大規模なアカウントから始めることは避けてください。
高リスクのアカウントを慎重に移行
契約途中の年間サブスクリプション登録者は、更新日まで既存の料金体系を適用します。請求額が大幅に増加する顧客には、請求 1〜2 サイクルにわたって移行を円滑にするクレジットを提供します。B2B SaaS 契約では大幅な料金変更に対して通知期間が必要になる場合があるため、契約条件を確認することを推奨します。
移行期限を明確に設定する
移行に 6 カ月かかる場合は、早期に通知し、終了の 90 日前、60 日前、30 日前にリマインドメールを送信します。終了日は変更不可とすることが重要です。期限のない移行は無期限に引き延ばされ、解決が困難な 2 種類の料金体系が混在する混乱を招く可能性があります。
使用量ベースの料金体系の立ち上げ時に用意すべき顧客向けコミュニケーション資材
コミュニケーションの質は、必要なサポートの対応件数を左右します。変更を発表する前に、次の 3 つの資材を用意しておくことを推奨します。
告知メール
変更内容を顧客に正確に伝えることが重要です。指標、単価、変更日を明記します。顧客ごとの具体的な変更例として、新しいレートでの請求額の見積もりや使用量見積もりツールへのリンクを記載します。シンプルなスライダーひとつでも、サポートチケットを大幅に削減できます。Stripe を使用している場合は、顧客の過去の使用量データがすでに蓄積されているため、見積もりの精度が高まります。
「変更点」ページ
請求が以前の料金体系からどのように変わるかを説明する料金体系ページが必要です。これはヘルプセンターに掲載し、指標の定義、料金表、3 つの使用量レベルでの請求額の例を記載します。
少なくとも、よくあるご質問セクションでは次の質問に答える必要があります。
「含まれている使用量を超過した場合はどうなりますか?」: 超過料金率、通知の有無、上限の設定など、具体的に記載します。
「利用限度額を設定できますか?」: 支出上限を設定している場合は、顧客にその旨を伝えます。設定していない場合は、サポートにこの問い合わせが寄せられることを想定する必要があります。
「請求額が増加する前に通知されますか?」: 具体的な通知条件 (上限の 80%、$X のしきい値、サイクル終了時のサマリーなど) を説明します。
「現在の契約はどうなりますか?」: 移行期間中の条件、更新日、移行支援クレジットの有無を明示的に記載します。
CSM と営業スクリプト
専任の顧客サクセスマネージャー (CSM) は、多くの顧客が予算計画を立てにくいと感じる、変動する請求額の増加に対する懸念や異議に対応できます。こうした問題に対処するために、CSM は顧客の使用量の傾向と、新しいモデルではその増加にどのくらいのコストがかかるかを顧客に提示できます。使用量が上がると請求額も上がる、つまり顧客が得る価値も高まっていることを明確に伝えます。利用コミット契約またはバンドルは、定額料金モデルに縛られることなく顧客が求める予測可能性を提供できるため、これらについて話し合うことを推奨します。
使用量ベースの料金体系を導入する際に避けるべきミス
使用量ベースの料金体系の立ち上げは、防げるはずの実行上のミスが原因で失敗することがあります。
以下の点に注意してください。
予測できない指標の選択: 登録前に請求額を見積もることができないと、顧客は解約する可能性があります。料金体系の他の部分を構築する前に、適切な指標を選択することが重要です。
支出上限なしの立ち上げ: 支出上限は基本的な信頼の仕組みです。これがないと、公の場での苦情やアカウントの解約リスクが生じます。
すべての顧客を一度に移行する: 顧客ベース全体に影響が及んでから初めて問題が発覚する事態は避けなければなりません。移行を段階的に進めることで、そのような事態を防げます。
料金体系ページへの投資不足: 使用量ベースの料金体系ページでは、顧客が問い合わせる前に、指標の説明、請求額の例示、料金予測に関する懸念の解消を行う必要があります。
予想外の高額請求をサポートの問題として処理する: 想定外の高額請求を個別のサポート対応で処理すると、通知漏れ、製品内での支出の可視性の欠如、上限設定の欠如といった製品上の問題が覆い隠されます。まず製品側を修正する必要があります。
立ち上げ後の改善をスキップする: 立ち上げが順調であることを示す指標には、使用量ベースの料金プランと以前の定額料金プランとの購入率、超過分による拡大収益、移行後 90 日間のチャーンレート、請求関連のサポートチケット数などがあります。立ち上げ後にチケット数が大幅に増加した場合、コミュニケーション施策や料金体系ページが機能していません。
Stripe Billing でできること
Stripe Billing を使用すると、シンプルな継続課金から従量課金、商談による契約まで、自由な方法で顧客への請求と管理ができます。コーディング不要で数分でグローバルな継続課金の受け付けを開始することも、API を使用してカスタム連携を構築することもできます。
Stripe Billing のメリット
柔軟な料金体系の提供: 従量課金、段階制料金体系、定額料金 + 超過料金など、柔軟な料金モデルでユーザーのニーズにすばやく対応できます。クーポン、無料トライアル、日割り計算、アドオンのサポートも組み込まれています。
グローバルに拡大: 顧客が希望する決済手段を提供することでコンバージョンを向上させます。Stripe は 100 以上の現地決済手段と 130 以上の通貨をサポートしています。
売上を伸ばし解約を防止: Smart Retries と回収ワークフローの自動化で、売上回収を効率化し、決済不履行による解約を減らせます。Stripe のリカバリツールは、2024 年に 65 億ドル以上の売上回収をサポートしました。
業務効率の向上: Stripe のモジュール型税務管理、収益レポート、データツールを活用して複数の収益管理システムを 1 カ所に統合。外部のソフトウェアとも簡単に連携できます。
この記事の内容は、一般的な情報および教育のみを目的としており、法律上または税務上のアドバイスとして解釈されるべきではありません。Stripe は、記事内の情報の正確性、完全性、妥当性、または最新性を保証または請け合うものではありません。特定の状況については、管轄区域で活動する資格のある有能な弁護士または会計士に助言を求める必要があります。