Compute-adjusted LTV（計算コスト反映LTV）の算出方法

• AIプロダクトが同じサブスクリプション料金を受け取りながらも、顧客ごとに推論コストの消費量が大きく異なることで、顧客全体の粗利率は安定しているという従来のLTVの前提が崩れている状況
• 核心はCompute-Adjusted LTVであり、固定・半固定のサブスクリプション売上に変動の大きい計算コストが組み合わさったAIプロダクトの顧客単位の収益性を測定する
• 2社の顧客が同じ価格を支払っていても、一方は推論コスト $110、もう一方は$15を消費し、実際の粗利がまったく異なる構造
• 会社平均の粗利率だけを見ると、一部セグメントが損益分岐点にとどまっていたり損失を出していたりする事実が隠れ、平均値の罠が生じる
• 固定のAIサブスクリプション売上と変動する計算コストを同時に持つ企業は、セグメント別の粗利を必ず把握することで、価格設定・予測・拡大におけるミスを減らせる

---

従来型ソフトウェアLTVの新たな問題

• 従来型SaaSでは、似た顧客をもう1社サービスするためのコスト差が大きくないため、サブスクリプション粗利率をそのままLTVに適用できた
  • 基本LTV = Cohort ARPA / Revenue Churn Rate
  • 粗利反映版 = Cohort ARPA × Gross Margin / Revenue Churn Rate
• AIプロダクトでは、推論呼び出し、completion、ワークフロー実行、エージェント作業、生成出力ごとに直接的かつ変動的なコストが発生し、そのコストと利用量は顧客ごとに異なる
• ICONIQ Capitalの2026年1月 State of AIレポートからの引用
  • 拡大段階のAI B2B企業では、モデル推論が総売上の平均**23%**を占める
  • AIプロダクトの平均粗利率は2024年の41%から2026年には約**52%**へ上昇すると予測されるが、従来型SaaS水準にはなお届かない

同じサブスクリプション料金、異なる顧客エコノミクス

• 月額$200のAIワークフロープロダクトの例では、パワーユーザー（顧客A）は推論コスト$110、ライトユーザー（顧客B）は$15を消費するが、従来のLTVでは同じように計算される
• 利用量が多いこと自体が悪いわけではなく、ヘビーユーザーは**定着性（sticky）**が高く、拡大が速く、プロダクトの支持者になり得る
  • ただし価格モデルが計算コストを回収できなければ、高い利用量は粗利率を静かに圧迫、または破壊する
• Jellyfishの2026年4月の分析（開発者12,000人・企業200社の2026年第1四半期トークン使用量）からの引用
  • マージされたPR 1件あたりのコストは、最低利用帯の**$0.28から最高利用帯の$89.32**まで、319倍の差
• 平均粗利率の利用はサブスクリプション型AIプロダクトで誤解を招き、あるセグメントは高収益で、別のセグメントは損益分岐点レベルである可能性がある

Compute-adjusted LTVの式に入る売上

• AI売上を3つに分類

  • Direct AI Revenue

    • AI SKU、AIアドオン、AIシート、AIユーザーライセンス、AI利用パッケージ、AIクレジットバンドル、AI超過利用売上など、AI機能に直接支払われる最も明快な入力値

  • AI-Attributed Revenue

    • 標準プランが$200、AIプランが$275の場合、差額の**$75**は、AIが主な違いであればAI帰属売上として扱える。ただし方法論の文書化が必要
    • 上場テック企業はAI売上のタグ付けを適切に実施しており、公開市場では必須

  • AI-Influenced Revenue

    • AIによって更新・受注・拡大が生じたという商業的シグナルではあるが、売上への影響を分離できない場合、ユニットエコノミクスの式の分子として使うには不適切なため、別途追跡する
• ルール：可能ならDirect AI Revenueを使い、説明可能であればAI-Attributed Revenueを使い、AI-Influenced Revenueは別途追跡する

Compute-Adjusted LTVの式

• Compute-Adjusted LTV = Compute-adjusted Gross Profit per Customer / Revenue Churn Rate
  • Compute-adjusted Gross Profit per Customer = AI Revenue per Customer − Fully Burdened AI COGS per Customer
  • Fully Burdened AI COGS = Inference Costs + AI Infrastructure Costs + Support Costs + Customer Success Costs + DevOps
• コストは粗利レベルで**完全負担（fully burdened）**として計算し、単に売上から推論コストだけを差し引く方法は、LLMコストしかない場合でなければ過少計上になる
• Customer Successは導入・維持に集中し、クォータを持たない場合にのみCOGSに含める

Compute-adjusted LTVの例：Acme SaaS

• 月額$200のAIワークフロープロダクトを純粋な従量課金ではなくサブスクリプション形式で販売し、売上は固定だが計算消費は変動する

• 会社平均

  • Compute-adjusted Gross Profit = $200 − $55 − $11 − $12 − $8 = $114
  • Compute-Adjusted LTV = $114 / 2% = $5,700
  • 従来型LTV = ($200 − $7 − $12 − $8) / 2% = $8,650

• ヘビーユーザー

  • 推論 $110、AIインフラ/DevOps $15、サポート $15、CS $10
  • Gross Profit = $200 − $110 − $15 − $15 − $10 = $50、LTV = $50 / 2% = $2,500

• ライトユーザー

  • 推論 $15、AIインフラ/DevOps $8、サポート $10、CS $7
  • Gross Profit = $200 − $15 − $8 − $10 − $7 = $160、LTV = $160 / 2% = $8,000

• 解釈

  • どちらのセグメントもCACは$1,200と仮定
  • 顧客単位のAIコストを反映すると、ヘビーユーザーは一般的な基準である3:1 LTV:CACベンチマークを下回る
  • これはヘビーユーザーが悪い顧客だという意味ではなく、運営者がより良い問いを立て、価格とコスト分布の比率を再検討すべきだというシグナル
  • ヘビーユーザーの維持期間、拡大速度、プラン移行、公正利用しきい値（fair-use threshold）、単純なワークフローの低コストモデルへのルーティング、利用クレジット・超過利用課金、ヘビーユーザー数などを点検する必要がある

Compute-adjusted LTVを使うべき場合

• AIがサブスクリプションまたはそれに近いモデルで販売され、計算コストが顧客ごとに大きく異なる場合に使う
  • 推論コストが売上の10%超、利用量がセグメントごとに大きく変動、LTV:CACで価格・CAC予算・顧客獲得を決める場合に特に有用
• 推論コストが小さい、または均一なら、ダッシュボードを複雑にする必要はない
  • AI計算が売上の5%未満で顧客単位の変動性が低ければ、既存の粗利反映LTVで十分
• 純粋な従量課金プロダクトは別の指標に集中し、ハイブリッド（プラットフォームサブスクリプション + 従量課金）モデルでは両方の視点が必要

最小実行可能分析（Minimum Viable Analysis）

• 完璧なデータは不要だが、分布分析のための顧客単位の利用量データは必要
• 顧客単位が理想だが、セグメント単位でもよい出発点になる
  • まずライト・コア・パワーユーザーに分け、その後SMB・ミッドマーケット・エンタープライズ、プラン種別、獲得チャネルを追加する
• 目的は初日から会計上の完璧さを求めることではなく、平均LTVが弱い顧客エコノミクスを隠していないかを確認し、欠落データを見つけること

実務CFOの結論

• 過去のSaaSプレイブックでは高い利用量をほぼ常にポジティブに見ていたが、AI SaaSでは価格モデルとコスト構造がそれを支えられる場合にのみ有効
• Compute-Adjusted LTVは、計算および関連COGSを反映した後、サブスクリプション型AIプロダクトが収益性のある顧客関係を作れているかを把握するのに役立つ
  • CAC Payback、GRR、NRR、粗利率、LTV:CACを置き換えるものではなく、AI-native・AI-enabled SaaSのユニットエコノミクスを拡張する指標
• AI粗利率が従来型SaaSより低くてもパニックになる必要はないが、計算を避けるべきではなく、顧客単位のAIエコノミクスを理解する企業が、より良い価格設定・予測・拡大を実現する