従量課金プライシングSaaS指標

従量課金(Usage-Based Pricing)とは?|座席課金からの移行が進む理由と設計の勘所

2026年09月17日 ・ MonaLens

毎月の請求書の金額が、先月と今月でまったく違う。以前ならクレーム扱いされかねなかったこの状態を、多くのAIプロダクトの利用者は当たり前だと受け止めるようになりました。

契約したのは同じプラン一つなのに、使った分だけ増減する。座席数を数える必要もない。

これが従量課金(Usage-Based Pricing)と呼ばれる課金モデルです。

なぜ今、これほど多くのAIプロダクトやSaaSが従量課金を選ぶようになったのでしょうか。座席課金の何が限界を迎え、従量課金の何がその代わりになっているのでしょうか。

請求書の金額が毎月変わるという体験は、売る側にとっても買う側にとっても、これまでのSaaSにはなかった感覚です。良くも悪くも、慣れが必要な仕組みだといえます。

この記事では、従量課金の定義から、広がっている背景、導入する側のメリットとリスク、課金単位の設計、そして計測の勘所までを順番に整理します。プロダクトの値付けを考えているPMや、ひとりでAIプロダクトを運営しているソロプレナーの方に、特に役立つ内容のはずです。

従量課金とは何か

従量課金とは、利用量に応じて金額が変わる課金モデルの総称です。電気やガスの料金と同じ発想だと考えると、イメージしやすいと思います。

対になる言葉が座席課金(シート課金)です。利用者数、つまりログインするアカウントの数に応じて金額が決まる、これまでのSaaSでもっとも一般的な方式でした。

座席課金との違い

座席課金は、契約した人数分の権利を毎月同じ金額で買う仕組みです。使っても使わなくても金額は変わりません。

一方の従量課金は、API呼び出し回数、処理したデータ量、生成したトークン数など、製品が実際に使われた量を基準に金額を決めます。使わない月は安く、使う月は高くなります。

この違いは、単なる計算方法の違いにとどまりません。座席課金では「アカウントを何個契約するか」という購買側の意思決定が価格を決めますが、従量課金では「製品がどれだけ価値を生んだか」が価格に直結します。

値付けの思想そのものが違うのです。両者の違いを整理すると、次のようになります。

観点 座席課金 従量課金
価格を決める要因 契約アカウント数 実際の利用量
使わない月の請求 変わらない 少なくなる
原価との連動 弱い 強い(特にAI系)
収益予測のしやすさ しやすい 難しくなりやすい

ハイブリッド型という現実的な着地点

実務では、純粋な従量課金だけで運用されるケースは多くありません。多くの企業は基本料金+従量課金というハイブリッド型を採用しています。

基本料金で最低限の収益を確保しつつ、一定の利用量を超えた分だけ従量で追加課金する形です。予測可能性と柔軟性のバランスを取る、現実的な着地点だといえます。

なぜ今、従量課金が急速に広がっているのか

従量課金という考え方自体は新しくありません。クラウドインフラの分野では、使った分だけ払うモデルは以前から一般的でした。

サーバーを時間単位で借りる、メッセージ送信を件数単位で払う、といった仕組みは長く存在してきました。

それでも近年になって改めて注目を集めているのには、いくつかの理由があります。

AIプロダクトの原価構造が変わった

もっとも大きな理由は、AIプロダクトの原価構造にあります。生成AIを組み込んだ機能は、利用者が使えば使うほど推論コストが積み上がる、という性質を持っています。

主要なAI API事業者の多くが、入出力のトークン数に応じた従量課金を公表された料金体系として採用しています。これは各社の料金ページで誰でも確認できる、広く知られた事実です。

自社のプロダクトがそうした従量課金のAPIを裏側で呼び出している以上、原価そのものが利用量に連動する構造になります。

座席課金のまま原価だけが利用量に比例して増えていくと、よく使う顧客ほど赤字になるという逆転現象が起きかねません。この原価とGTM投資の関係については、推論コストがGTMを変える|「AI税」時代の営業投資の考え方でも詳しく扱っています。

原価が利用量に連動するなら、価格も利用量に連動させたほうが自然です。従量課金は、AIプロダクトにとって理にかなった選択になりやすいのです。

顧客側の「使った分だけ払いたい」という感覚

理由はコスト側だけではありません。買う側の感覚も変わってきています。

座席課金は、アカウントを作ったのに使っていない従業員の分まで払い続けるという無駄を生みがちです。実際に価値を得た分だけ払いたいという感覚は、特に導入初期の企業や、少人数で複数のツールを併用するインディーハッカーにとって自然な要求です。

エンタープライズの世界でも、獲得のあとの拡大フェーズを製品内の利用実績で半自律的に伸ばすという発想が広がっています。エンタープライズAIにPLGは効くのか|獲得ではなく「拡大」を自律化するで扱ったように、従量課金は使えば使うほど自然に契約金額が伸びる仕組みでもあります。

従量課金のメリットとリスク

従量課金には明確な利点がありますが、無条件に良い仕組みというわけではありません。両面を見ておく必要があります。

提供側のメリット

提供側から見た最大のメリットは、価格と価値の連動です。顧客が大きな成果を得ているときは収益も伸び、逆に利用が小さいときは請求も小さいので、解約という極端な選択に至りにくくなります。

もう一つの利点は、利用を増やすこと自体がセールスになるという点です。営業担当者が値上げ交渉をしなくても、利用量が増えれば収益は自然に増えます。

契約時のハードルも下がりやすく、まずは小さく試してもらうという入口を作りやすいのも従量課金の強みです。

初期費用や最低契約金額が座席課金より小さく見えるぶん、稟議を通しやすいという実務上の利点もあります。特に予算の少ない部署や、個人で契約を判断できるインディーハッカーにとっては、この入口の軽さが導入のきっかけになりやすいのです。

見落とされがちなリスク

一方でリスクもあります。もっとも大きいのは、顧客側から見た予算の予測しにくさです。

今月いくら請求されるか分からない状態は、経理担当者にとって歓迎されるものではありません。

提供側にとっても、月次収益の予測が難しくなるという副作用があります。座席課金なら来月の収益はほぼ契約数から読めますが、従量課金は利用量という変数に左右されるため、収益予測モデルそのものを作り直す必要が出てきます。

以下は説明のための仮の数値例です。ある月に100社と契約している座席課金のプロダクトが、1社あたり月5万円で固定なら、来月の売上はほぼ500万円と読めます。

これが従量課金で1社あたりの請求が利用量に応じて2万円から10万円まで揺れ動く設計だった場合、同じ100社でも合計は200万円から1000万円まで幅を持つことになります。来月の着地を言い当てるのは、一気に難しくなります。

さらに、値付けを誤ると成長の天井が顧客の財布に握られるという事態も起こります。従量課金は成功と失敗のどちらの振れ幅も大きくする仕組みだ、と捉えておくのが安全です。

社内の目線でも注意が必要です。営業やカスタマーサクセスの評価指標を契約社数のままにしておくと、利用量を伸ばすインセンティブが働きません。

従量課金へ移行するなら、評価指標そのものも利用量や拡大収益に寄せていく必要があります。

課金単位(メトリック)をどう設計するか

従量課金を採用すると決めたら、次に来る問いは「何を数えて課金するか」です。この課金単位の選び方が、事業の成否を大きく左右します。

良いメトリックの条件

良い課金単位には、いくつかの共通した条件があります。

  • 顧客にとって価値と連動して増減すること。使えば使うほど得をしている実感があってこそ、増える請求額にも納得できます。
  • 顧客自身が予測・コントロールしやすいこと。挙動が想像しやすい単位は、突然の高額請求という不信感を生みにくくなります。
  • 事業者側にとっても計測しやすく、原価と相関すること。

この三つが揃って、初めて持続可能な課金単位になります。実際にどんな単位が選ばれているのか、プロダクトの種類別に見てみましょう。

プロダクトの種類 課金単位の例 選ばれる理由
生成AI・LLM系API 入出力トークン数 原価(推論コスト)と直結する
メール配信・通知系 送信件数 顧客の成果(到達数)と連動する
データ変換・パイプライン系 処理データ量 インフラコストと比例する
カスタマーサポート系 解決チケット数 成果(解決)に対して払う納得感がある

陥りやすい失敗パターン

反対に、失敗しやすいのは顧客がコントロールできない単位を選んでしまうケースです。たとえばアクセス数のように、顧客の営業努力ではなく外部要因で増減する指標を課金単位にすると、頑張って集客したのに請求が跳ね上がるという理不尽な体験を生みます。

もう一つの落とし穴は、測定が複雑すぎる単位です。顧客が自分で今月の利用量を見積もれないほど複雑な計算式は、信頼を損ないます。

シンプルさは、従量課金においてそれ自体が価値です。

課金単位を複数組み合わせすぎることにも注意が必要です。トークン数と保存容量と同時実行数を同時に請求書へ並べると、顧客は自分がいくら払うことになるのか、契約前に見積もれなくなってしまいます。

仮の数式で見る組み立て方

多くのハイブリッド型は、次のような形の数式で説明できます。あくまで説明のための仮の例で、実際の金額とは関係ありません。

月額請求額 = 基本料金 + max(0, 当月の利用量 - 無料枠) × 単価

たとえば基本料金を1万円、無料枠を1万トークン、超過分の単価を1トークンあたり0.5円と仮に置いたとします。利用量が無料枠の範囲に収まる月は請求額が1万円のままで、無料枠を5万トークン超えた月は1万円に2万5000円が上乗せされ、合計3万5000円になります。

この数式の形が良いところは、顧客が電卓ひとつで自分の来月の請求額を見積もれる点です。複雑な条件分岐や、複数の単位を掛け合わせる計算式は、この見積もりやすさを壊してしまいます。

従量課金下でプロダクトの「使われ方」を追う

課金の仕組みが変わると、見るべき数字も変わります。ここは見落とされがちなポイントです。

定額時代の計測との違い

座席課金の時代は、契約されたかどうかがゴールでした。しかし従量課金では、契約後にどれだけ使われ続けるかが収益そのものに直結します。

つまり、オンボーディングを終えた顧客が実際に機能を使い始め、使用量を伸ばしていくかどうかを追いかけることが、解約防止と同じくらい収益に直結する仕事になります。

座席課金であれば、極端な話、ログインさえしてもらえれば契約は続きます。従量課金ではログインだけでは足りず、使い続けてもらって初めて収益になるという前提に立たなければなりません。

無料トライアルの段階からこの視点を持っておくと、無料トライアルの有料転換を上げる|行動データで手をかけるべき人を見極めるで扱ったように、どの利用者に手をかけるべきかの判断がしやすくなります。

見るべき行動指標

具体的には、機能ごとの利用頻度、直近の利用量の伸び率、そして利用が急に止まった利用者の検知が重要になります。利用量が伸びている顧客は今すぐの拡大提案の対象になり、PQL(プロダクトクオリファイドリード)とは?|製品の使われ方で「今すぐ客」を見つけるで扱った考え方がそのまま活きてきます。

反対に、契約はしているのに利用量がゼロに近いまま数週間続いている顧客は、請求額の小ささに安心してはいけません。次の更新で解約される予兆として、早めに手を打つべき対象です。

こうした行動の変化は、集計されたダッシュボードの数字だけを眺めていても気づきにくいものです。MonaLensのようなN1分析の仕組みを使い、利用量が伸びている一人ひとりの行動を実際の画面遷移として追うと、なぜその顧客が使い続けているのかという理由まで見えてきます。

導入の進め方:いきなり全面移行しない

すでに座席課金で運営している場合、いきなり全面的に従量課金へ切り替えるのは危険です。既存顧客の請求額が急に不安定になれば、信頼を損ないかねません。

現実的なのは、新規メニューとしてハイブリッド型を先に試し、既存顧客には移行の猶予期間を設けるという段階的な進め方です。実際に多くの企業が、新プランでの検証を先行させてから全体の値付けを見直すという順序を踏んでいます。

移行の際は、課金単位の変更に伴って計測の仕組みそのものを見直す必要も出てきます。どの行動をどう数えるかを先に固めておくことが、後戻りのない移行につながります。

急に切り替えるのではなく、まずは新規顧客だけに適用し、既存顧客には移行の猶予期間を用意する。これだけでも、失敗したときに引き返せる余地が大きく変わります。

もう一つ有効なのは、利用量の上限に達しそうな顧客へ事前に通知する仕組みを、価格変更と同時に用意しておくことです。請求額が上がってから初めて気づくのと、事前に知らされているのとでは、同じ金額でも顧客の受け止め方がまったく違います。

まとめ

従量課金は、使った分だけ払うというシンプルな発想に見えて、価格設計・原価構造・計測のすべてを結びつける仕組みです。

座席課金からの完全な置き換えではなく、自社のプロダクトと顧客にとって何が公平な対価なのかを、あらためて問い直すきっかけとして捉えるのがよいと思います。

値付けを変えるという決断は、いつでも取り消せるわけではありません。既存顧客への影響を考えれば、慎重になって当然です。

それでも、原価と価値の両方が利用量に連動しつつある以上、従量課金という選択肢を検討の俎上に載せる意味は、これからますます大きくなっていくはずです。

MonaLensで、あなたのサイトの導線を可視化しませんか?

Cookieレスで、離脱ポイントとコンバージョンが数分でわかります。

無料で始める