SaaS プライシングで AI クレジット制にすべきか・どう設計するかを考えるフレームワークを確認してみた
いわさです。
以前、こちらの記事で SaaS に AI 機能を追加する際の料金設計を COMPASS フレームワークで整理しました。
その後 COMPASS フレームワークの開発者である Zuora の Michael Mansard 氏本人からメッセージをいただきまして、フレームワークの続編が出ていることを教えてもらいました。
前回は「どの課金メトリクスを選ぶか」を 3x3 マトリクスと14の質問チェックリストで紹介しました。
その中でも各社事例を見るとクレジット制を採用するケースが増えていて、Salesforce は複数の AI エージェントの操作を「Flex Credits」という共通クレジットで課金し、HubSpot は AI 機能全般を「HubSpot Credits」で計量し、Notion は Custom Agent の利用だけをクレジット制にしています。
いずれも「複数の AI 機能の利用量を1つの共通単位にまとめる」というパターンです。
一方で、「クレジット制にしよう」と決めた後の設計が難しいですよね。
有効期限はどうするのか、使い切ったらどうなるのか、部署間で共有できるのか、レート表は固定か変動か...決めることが多いです。
上記の続編はまさにそこにフォーカスした内容で、クレジットモデルにすべきかどうかを判断する「Credit Model Flash Triage」と、クレジットモデルの設計で考えるべき項目を体系化した「12-Attribute Credit Model Taxonomy」という2つのツールが紹介されています。
今回こちらを確認してみたので紹介します。
クレジット制にすべきかを判断する Flash Triage
前回の記事では「何を計量するか」を考えましたが、今回の Flash Triage はその前段階です。
「そもそもクレジットという仕組みが自社に必要なのか」を判断するためのツールで、4つの質問に YES/NO で答えるだけで方向性がわかります。
| # | 観点 | 質問 |
|---|---|---|
| 1 | コスト変動性 | AI の推論コストが処理の種類によって大きく変わるか？（例: 簡単な要約と高度な分析では GPU の使用量が全然違う） |
| 2 | 機能の多様性 | AI が提供する機能が複数あり、それぞれ別の仕事を担っているか？ |
| 3 | 価値の差 | 一番軽い機能と一番重い機能で、顧客にとっての価値に大きな差があるか？ |
| 4 | 利用量の読みにくさ | 顧客がどのくらい使うか事前に予測しにくいか？ |
原文では以下のようなフローが示されています。
日本語にしたものを載せておきます。
フローの結果は5パターンに分かれます。
| パターン | 意味 |
|---|---|
| サブスクリプション | 月額定額のみ |
| ハイブリッド/従量（1メトリクス） | 定額＋従量課金を1種類の単位で |
| ハイブリッド/従量（最大3メトリクス） | 定額＋従量課金を2〜3種類の単位で |
| ハイブリッドクレジット | 定額＋クレジット制で複数機能を束ねる |
| クレジット | クレジットが課金の中心 |
下に行くほどクレジットの比重が上がります。
「ハイブリッド/従量」と「ハイブリッドクレジット」の違いは、従量部分を「リクエスト数」のような直接的な単位で計るか、「クレジット」という共通単位に変換するかです。
機能が1〜3種類なら直接計量できますが、機能が多様で重さもバラバラならクレジットで束ねたほうが管理しやすくなります。
AI 機能の場合はコスト変動性や利用量の読みにくさが YES になることが多いので、実際にはハイブリッド〜クレジットに行き着くケースがほとんどだと思います。
なお「定額のままにしたいが AI の利用量リスクは抑えたい」というケース（定額＋月間利用上限など）は、前回の記事の「14問で弱点が見つかったときの対処」で触れています。
ポイントは「コスト変動性」が一番重要な判定要素だという点です。
コスト変動性があって、さらに機能が多かったり価値に差があったりすると、クレジットで束ねないと利益率が安定しないという話ですね。
具体例で考えてみる
前回の記事で例に挙げた「カスタマーサポート SaaS に AI チャットボットを追加するケース」で Flash Triage を当てはめてみます。
| 観点 | 判定 | 理由 |
|---|---|---|
| コスト変動性 | YES | 長い会話は推論コストが高く、短い FAQ は低コスト |
| 機能の多様性 | NO | AI がやるのは「問い合わせ対応」という1つの仕事 |
| 価値の差 | NO | 解決した問い合わせの価値は概ね均一（1件は1件） |
| 利用量の読みにくさ | YES | 問い合わせ件数は季節や障害発生で大きく変動する |
コスト変動性は YES ですが、機能の多様性と価値の差が NO なので、判定は「シンプルな従量課金（解決件数ベース）で十分」になります。
前回の記事で 3x3 マトリクスから「アウトプット単位（解決件数で課金）」としたのと同じ結論になりました。
もう1つ、ServiceNow（IT運用・HR・カスタマーサービスなどの業務を AI で自動化するエンタープライズ向けプラットフォーム）みたいな複数エージェントを持つプラットフォームだとどうなるか。
| 観点 | 判定 | 理由 |
|---|---|---|
| コスト変動性 | YES | アラート分析（軽い）から自動評価（重い）まで推論コストに幅がある |
| 機能の多様性 | YES | IT 運用、HR、カスタマーサービスなど異なる仕事を複数のエージェントが担う |
| 価値の差 | YES | アラート要約と高度な自動評価では顧客にとっての価値が大きく異なる |
| 利用量の読みにくさ | YES | 部門ごとに利用パターンが異なり、予測が難しい |
4つ全て YES なので、「クレジットモデルが合っている」という判定になります。
実際 ServiceNow は 60 以上のレートカード（1 Now Assist〜4,000 Now Assist）でクレジットモデルを運用しています。
クレジットモデルの設計で考える12の属性
Flash Triage で「クレジットモデルが適切だ」と判断した後、次は「どう設計するか」です。
Mansard 氏が 100 以上の AI プロダクトを分析して、クレジットモデルの設計で決めるべきことを12項目・4カテゴリに整理しています。
カテゴリ1: 何を買うか（単位の設計）
| # | 項目 | 何を決めるか |
|---|---|---|
| 1 | 紐づけ先 | クレジットを何と交換するか（入力量/操作回数/成果物/ビジネス成果） |
| 2 | 変換レート | 1クレジット=1操作の固定か、操作の重さで変わるか |
| 3 | 使える範囲 | 特定の機能だけで使えるか、全プロダクト共通か |
カテゴリ2: いくらで買うか（価格の設計）
| # | 項目 | 何を決めるか |
|---|---|---|
| 4 | 単価の決め方 | 一律か、たくさん買うと安くなるか、個別交渉か |
| 5 | レート表の安定性 | 契約期間中にクレジットの消費レートが変わる可能性があるか |
| 6 | 利用状況の見える化 | リアルタイムでどこまで使用量が見えるか、アラートはあるか |
カテゴリ3: いつ使えるか（有効期限の設計）
| # | 項目 | 何を決めるか |
|---|---|---|
| 7 | 補充の仕方 | 一括購入か、毎月自動で付与されるか、残高が減ったら自動チャージか |
| 8 | 繰り越し | 月末に余ったクレジットは翌月に持ち越せるか、消えるか |
| 9 | 最終有効期限 | 購入からいつまで有効か（12ヶ月など）。期限が来たら没収か返金か |
カテゴリ4: 誰が使えるか（権限の設計）
| # | 項目 | 何を決めるか |
|---|---|---|
| 10 | プールの単位 | クレジットはユーザーごとか、チームごとか、組織全体で共有か |
| 11 | 移動の可否 | 部門間や子会社間でクレジットを移動できるか |
| 12 | 使い切ったとき | 残高ゼロになったらサービス停止か、速度制限か、超過課金か |
各社の設計を比較してみる
Mansard 氏の記事では以下の4社のクレジットモデルが12属性で分析されています。
- ServiceNow: IT運用・HR・カスタマーサービスの業務自動化プラットフォーム。AI 機能「Now Assist」をクレジットで課金
- HubSpot: マーケティング・営業・カスタマーサポートの CRM プラットフォーム。AI スイート「Breeze」をクレジットで課金
- Figma: デザインツール。AI によるプロトタイプ生成機能「Figma Make」をクレジットで課金
- Higgsfield: AI 動画生成プラットフォーム。動画生成をクレジットで課金
主要な項目に絞って比較してみます。
| 項目 | ServiceNow | HubSpot | Figma | Higgsfield |
|---|---|---|---|---|
| 紐づけ先 | 操作回数（Now Assist 単位） | 操作回数＋成果（解決会話/$0.50） | 成果物（生成結果） | 成果物（動画生成） |
| 変換レート | 60種類以上（1〜4,000 Assist） | シンプル（機能ごとに固定） | シンプル（1生成=固定） | シンプル（1動画=固定） |
| 使える範囲 | 全プロダクト共通 | 全 Hub 共通 | Figma Make 内のみ | プラットフォーム内共通 |
| 補充の仕方 | サブスク付与＋Assist Pack 追加購入 | プラン別月次付与＋追加購入 | 月次付与 | プラン別月次付与 |
| 繰り越し | あり（365日有効） | なし（月次リセット） | なし（月次リセット） | なし（月次リセット） |
| 使い切ったとき | Assist Pack 追加購入 | 管理者が超過ポリシーを選択可 | サービス停止 | サービス停止 |
比較してみると傾向が見えてきます。
ServiceNow は最も複雑なモデルです。
60 種類以上の変換レート、全プロダクト共通のクレジット、365日の有効期限と、設計項目をかなり細かく作り込んでいます。
Mansard 氏の記事によると Now Assist は 2025年末で年間契約額 $600M 以上に到達し、追加購入パック（Assist Pack）は月次 50% の成長率で伸びているとのこと。
大規模エンタープライズ向けだとこのくらい設計を作り込む必要があるんですね。
HubSpot は別の方向に進んでいます。
通常のクレジット消費に加えて、Customer Agent の「解決会話1件あたり $0.50」、Prospecting Agent の「推薦リード1件あたり $1.00」という成果ベースの課金を混ぜています。
前回の記事で「完全な成果ベースは10%未満」と書きましたが、こうやってクレジット制の中に成果ベースの要素を部分的に混ぜる形は増えてきそうです。
さいごに
本日は COMPASS フレームワークの第4弾「AI Credit Monetization」で追加された Flash Triage と12属性の設計フレームワークを紹介しました。
前回の記事と合わせると、AI 機能の料金設計は以下の流れで考えることができそうです。
- 3x3 マトリクス → 課金メトリクスの方向性を決める（前回の記事）
- 14の質問チェックリスト → メトリクスの妥当性を検証する（前回の記事）
- Flash Triage → クレジットモデルにすべきか判断する（今回の記事）
- 12属性 → クレジットモデルの具体設計を進める（今回の記事）
技術支援の中で「クレジット制にしようと思うんですがどう設計すればいいですか」と聞かれることがあるのですが、12属性があると「有効期限は？」「繰り越しは？」「使い切ったときは？」と1つずつ論点を潰していけるので、議論の整理に使えそうです。
なお、Mansard 氏の記事ではクレジット制への移行時の注意点として Cursor（AI コーディングエディタ）の事例が取り上げられています。
2025年6月16日に Pro プラン（$20/月）の仕組みを「月500回の高速リクエスト」から「$20分のクレジット」に変更したところ、事前の説明が不十分でヘビーユーザーが数日で使い切ってしまい大きな反発があったとのこと。
Cursor did not over-communicate this change nor provide significant notice. Crucially, they did not proactively provide easy ways for users to estimate how their specific usage would consume credits in the new model.
Cursor 公式ブログに謝罪記事が出ています。
CEO が謝罪と即時返金で対応したものの、料金モデルの変更は「計算の問題ではなく伝え方の問題」だという教訓は覚えておきたいですね。
Mansard 氏の記事は CC BY-SA 4.0 ライセンスで公開されています。
ホワイトペーパーに近い分量なので全部読むのは大変ですが、クレジットモデルの設計で悩んでいる方は眺めてみると良いと思います。
