この記事で分かること
結論:AI企業の損益は「利用量」を売上と原価の両方に効かせて組みます
AI企業の損益計算書を組むときに最初に壊れるのは、従来型SaaSのモデルテンプレートです。SaaSモデルの標準形は「顧客数 × 単価 = 売上」で売上を作り、原価はごく小さい固定費として置きます。ソフトウェアの複製コストがほぼゼロだからです。ところがAI製品では、顧客が1回推論を実行するたびに計算資源が消費されます。この消費は売上原価に変動費として立ちます。したがって、利用量が増えても価格が動かない契約では、売上が1円も増えないまま原価だけが積み上がります。
結論として、AI企業の財務モデルは次の形にします。「顧客数 × 顧客あたり利用量 × 単価」で売上を作り、同じ「顧客数 × 顧客あたり利用量」に単位推論コストを掛けて変動原価を作ります。利用量というドライバーを1本だけ置き、そこから売上と原価の両方を引くのが要点です。従来型SaaSモデルでは、売上ドライバーと原価ドライバーが分離していても実害がありませんでした。AI企業では、この2つを分離した瞬間にモデルが現実を説明しなくなります。
そして提供形態によって、この「利用量」がどこに効くかが変わります。外部モデルのAPIを使うアプリケーションでは利用量が直接に外部への支払いになりますが、自社でモデルを保有する企業では設備投資が先行し、償却と固定費として原価に乗ります。本記事は財務モデルを組む側の視点に徹し、4つの提供形態それぞれの損益の形、価格設計3方式の比較、モデルの入力構造までを扱います。投資判断のためにこれらを検証する観点(技術・単位経済性・競争優位のDD)はAI企業のVC・グロース投資DDに譲ります。
全体像:提供形態4分類と損益の形
4つの提供形態を、モデルを組むうえで意味のある4項目で対比します。以下は本記事が提案する整理枠組みであり、業界共通の定型分類があるわけではありません。「粗利率の水準感」は本記事の設例を計算した結果であり、実在企業の実績値ではありません。
| 分類 | 売上の計上パターン | 原価の構成 | 粗利率(設例) | スケール時の挙動 |
|---|---|---|---|---|
| ①外部モデルを使うアプリケーション | 月額課金または利用量課金。契約期間にわたり均等または実績に応じて計上 | 外部API利用料が変動費として直接に売上原価へ。ほかに人手レビュー・アプリ基盤・サポート配賦 | 28.2% (価格方式で大きく振れる) | 顧客数を増やしても粗利率はほぼ動かず、1顧客あたり利用量が増えると急落 |
| ②自社モデルを保有するアプリケーション | ①と同じだが、初期の導入・カスタマイズ収益が混ざりやすい | 推論基盤の減価償却・保守、学習およびデータ整備の費用、電力。変動費の比率は小さい | 27.5% | 固定費を配賦する母数が増えるため、顧客数・利用量の規模に到達すると改善 |
| ③モデル/API提供 | 従量課金。実際の利用実績に応じて計上され、月ごとの振れが大きい | 計算資源の容量確保費用(階段状の固定費)+電力等の変動費 | 40.0% (容量の使い切り具合で33.8〜46.7%) | 容量の枠内では改善するが、容量を1段追加した月に粗利率が落ちる |
| ④AIを組み込んだ既存ソフト | 既存のライセンス/サブスクリプション収益のまま。AI機能単独の売上が立たないことが多い | 従来の原価に、AI機能分の推論コストが上乗せされる | 66.7% (追加前は80.0%) | 利用が広がるほど原価が増えるが、価格に転嫁しにくく粗利率が下がる |
この4分類のうち、どれに当たるかで置くべき入力項目が変わります。LLMを外部から調達するのか自社で持つのかという選択は、製品の性格だけでなく損益の形そのものを決めます。特化型と汎用型のどちらを使うかという選択軸は金融特化AIと汎用生成AIの違いで扱っています。
推論コストが損益に乗る仕組み
従来型SaaSの財務モデルが単純だったのは、限界費用がほぼゼロだったからです。顧客が1人増えても、その顧客が製品を10倍使っても、追加で発生する費用はほとんどありません。だから売上原価は小さく、粗利率は高位で安定し、売上が伸びれば粗利額もほぼ比例して伸びました。売上の予測さえ正しければ、粗利は自動的に決まったわけです。
AI製品ではこれが成り立ちません。推論は実行のたびに計算資源を消費します。外部モデルを利用しているなら、その消費はそのまま外部への支払いになります。会計上は、製品の提供に直接ひもづく費用ですから売上原価に区分するのが自然です(費用の区分は各社の会計方針によります)。結果として、次の3つが同時に起こります。
- 粗利率が売上と一緒には伸びません。売上に対して一定割合の変動費が常にかかるため、規模の拡大だけでは粗利率が改善しません。
- 同じ売上でも顧客ごとに粗利が違います。定額契約なら、よく使う顧客ほど粗利が薄くなります。
- 粗利率が顧客ミックスで動きます。売上・顧客数・解約率が一定でも、利用量の分布が変われば粗利率が変わります。
変動費と固定費の分解、および営業レバレッジという一般的な考え方はコスト構造とマージン予測で扱っています。ここではAI企業に固有の点、すなわち変動費の量を決めるのが「契約金額」ではなく「顧客の使い方」であるという点に集中します。従来のSaaS指標体系(ARR・CAC・LTVなどの指標)には、この「使い方」を捉える変数がそもそも入っていません。
①外部モデルを使うアプリケーション:設例の前提
架空のAI企業株式会社ミナト・インテリジェンスを置きます。業務文書の作成・要約を支援する製品を提供し、推論は外部のモデル提供者のAPIを利用しています。単位はすべて円・月次で統一します。以下の数値はすべて架空です。
- 利用量の単位:処理件数(件/月)
- 単位推論コスト:1件あたり12円(外部API利用料および付随する処理費用)
- 顧客あたり固定原価:20,000円/月(アプリ基盤・サポート体制の配賦)
- 顧客3社:軽ユーザーL社 2,000件/月、中ユーザーM社 10,000件/月、重ユーザーH社 20,000件/月(合計32,000件)
この前提のもとで発生する原価は、価格方式にかかわらず同じです。L社 24,000+20,000=44,000円、M社 120,000+20,000=140,000円、H社 240,000+20,000=260,000円、合計444,000円。検算:24,000+120,000+240,000=384,000円(変動費)、20,000×3=60,000円(固定費)、384,000+60,000=444,000円で一致します。変わるのは売上の作り方だけです。ここから価格設計の話に入ります。
②自社モデルを保有するアプリケーション:先行投資が償却として乗る
比較のため、自社でモデルを保有する架空企業株式会社セイオ・ニューロを置きます。月次売上40,000千円に対する原価は、推論基盤の減価償却・保守15,000千円、モデルの学習およびデータ整備6,000千円、電力・スケール分4,000千円、サポート配賦4,000千円で、合計29,000千円です。粗利11,000千円、粗利率27.5%となります。検算:15,000+6,000+4,000+4,000=29,000千円、40,000-29,000=11,000千円、11,000÷40,000=0.275=27.5%。
この形の特徴は、原価の大半が利用量に反応しないことです。変動費は4,000千円(売上比10.0%)にとどまります。したがって利用量が増えても粗利率は大きく崩れませんが、逆に売上が想定に届かないと固定費を回収できません。モデルを組むうえでは、次の2点が判断ポイントになります。
- 資産計上か費用処理か:研究開発費は発生時に費用として処理することとされており、自社利用のソフトウェアは将来の収益獲得または費用削減が確実である場合に資産計上する扱いが示されています(企業会計審議会「研究開発費等に係る会計基準の設定に関する意見書」、1998年3月13日)。学習コストやモデル開発費をどこまで資産計上できるかは個別の判断になるため、会計方針を確認せずにモデルの前提を置かないことが重要です。
- 償却スケジュールの分離:推論基盤の設備投資は取得時期ごとにレイヤーを分けて償却を計算します。この実装方法はCapex・減価償却スケジュールの作り方のとおりで、AI企業だから特別な方法が必要になるわけではありません。異なるのは、その償却費が販管費ではなく売上原価に入る点です。
③モデル/API提供:容量が階段状に増える
架空のモデル提供事業者株式会社ハルカ・モデルズを置きます。単価30円/件、変動原価6円/件(電力等)、計算資源は「1ブロック=月600,000件の処理能力、月額6,000千円」の単位でしか調達できないものとします。
| 月間処理量 | 必要ブロック | 売上(千円) | 変動原価 | 容量費用 | 粗利 | 粗利率 |
|---|---|---|---|---|---|---|
| 100万件 | 2 | 30,000 | 6,000 | 12,000 | 12,000 | 40.0% |
| 120万件(容量を使い切る) | 2 | 36,000 | 7,200 | 12,000 | 16,800 | 46.7% |
| 130万件(1ブロック追加) | 3 | 39,000 | 7,800 | 18,000 | 13,200 | 33.8% |
検算:120万件のとき 36,000-7,200-12,000=16,800千円、16,800÷36,000=0.4667=46.7%。130万件のとき 39,000-7,800-18,000=13,200千円、13,200÷39,000=0.3385=33.8%。処理量が10万件(8.3%)増えただけで、粗利率は46.7%から33.8%へ12.9ポイント下がります。これは失敗ではなく、階段状の容量調達に伴う正常な挙動です。年次モデルで平準化してしまうと、この段差が消えて実態と合わなくなります。
④AIを組み込んだ既存ソフト:転嫁できない原価
架空の業務ソフト会社株式会社トウカ・ワークスを置きます。既存製品は月額30,000円/社、原価6,000円/社で粗利率80.0%でした。ここにAI機能を追加し、1社あたり月4,000円の推論コストが発生するとします。価格を据え置けば原価は10,000円、粗利20,000円、粗利率66.7%となり、13.3ポイント低下します。検算:30,000-10,000=20,000円、20,000÷30,000=0.6667=66.7%、80.0-66.7=13.3ポイント。
価格を34,000円へ改定できれば、粗利24,000円、粗利率70.6%(24,000÷34,000=0.7059)まで戻ります。粗利額は元の24,000円と同額ですが、粗利率は80.0%には戻りません。原価が増えたぶん売上を増やしても、比率は希釈されるためです。この分類でモデルを組む際は、値上げの実現率(何%の顧客が改定価格を受け入れるか)を明示的な入力にしておくと、経営判断に使えるモデルになります。
価格設計3方式の比較(定額・従量・ハイブリッド)
ミナト・インテリジェンスの設例に戻ります。原価は444,000円で固定ですから、3つの価格方式で売上と粗利がどう変わるかを整数で計算します。
方式①:定額(シート課金・利用量上限なし)
1社あたり月額150,000円とします。中位の利用量を想定して設定した価格、という位置づけです。
| 顧客 | 利用量 | 売上 | 変動原価 | 固定原価 | 粗利 | 粗利率 |
|---|---|---|---|---|---|---|
| L社(軽) | 2,000件 | 150,000 | 24,000 | 20,000 | 106,000 | 70.7% |
| M社(中) | 10,000件 | 150,000 | 120,000 | 20,000 | 10,000 | 6.7% |
| H社(重) | 20,000件 | 150,000 | 240,000 | 20,000 | ▲110,000 | ▲73.3% |
| 合計 | 32,000件 | 450,000 | 384,000 | 60,000 | 6,000 | 1.3% |
検算:150,000×3=450,000円、450,000-444,000=6,000円、6,000÷450,000=0.0133=1.3%。粗利額の合計でも 106,000+10,000-110,000=6,000円で一致します。
この方式の損益分岐利用量も求められます。粗利=150,000-12N-20,000=130,000-12N(Nは月間件数)ですから、ゼロになるのは N=130,000÷12=10,833.3件です。検算:12×10,833=129,996円で粗利は4円のプラス、12×10,834=130,008円で8円のマイナス。月10,833件を超える顧客は赤字顧客という線がはっきり引けます。M社(10,000件)は分岐点のすぐ手前におり、利用が9%増えただけで赤字に転じます。
方式②:従量(利用量課金)
1件あたり20円、基本料なしとします。
| 顧客 | 利用量 | 売上 | 原価合計 | 粗利 | 粗利率 |
|---|---|---|---|---|---|
| L社(軽) | 2,000件 | 40,000 | 44,000 | ▲4,000 | ▲10.0% |
| M社(中) | 10,000件 | 200,000 | 140,000 | 60,000 | 30.0% |
| H社(重) | 20,000件 | 400,000 | 260,000 | 140,000 | 35.0% |
| 合計 | 32,000件 | 640,000 | 444,000 | 196,000 | 30.6% |
検算:40,000+200,000+400,000=640,000円、640,000-444,000=196,000円、196,000÷640,000=0.3063=30.6%。今度は重ユーザーほど粗利率が高くなり、代わりに軽ユーザーが赤字になります。1件あたりの貢献利益は20-12=8円ですから、顧客あたり固定原価20,000円を回収するには20,000÷8=2,500件が必要です。L社の2,000件では500件分足りず、8×500=4,000円の赤字になります。表の▲4,000円と一致します。
方式③:ハイブリッド(基本料+従量)
基本料50,000円(月2,000件までを含む)、超過分は1件18円とします。
| 顧客 | 超過件数 | 売上 | 原価合計 | 粗利 | 粗利率 |
|---|---|---|---|---|---|
| L社(軽) | 0件 | 50,000 | 44,000 | 6,000 | 12.0% |
| M社(中) | 8,000件 | 194,000 | 140,000 | 54,000 | 27.8% |
| H社(重) | 18,000件 | 374,000 | 260,000 | 114,000 | 30.5% |
| 合計 | 26,000件 | 618,000 | 444,000 | 174,000 | 28.2% |
検算:50,000+(8,000×18)=194,000円、50,000+(18,000×18)=374,000円、50,000+194,000+374,000=618,000円。618,000-444,000=174,000円、174,000÷618,000=0.2816=28.2%。3社すべてが黒字になり、粗利率のばらつきも12.0〜30.5%に収まります。
3方式を実務の判断軸で対比すると次のとおりです。なお3方式の価格水準はそれぞれ独立に置いた仮設定であり、売上総額の大小そのものを比較する意味はありません。見るべきは顧客ごとの粗利の散らばり方です。
| 判断軸 | ①定額 | ②従量 | ③ハイブリッド |
|---|---|---|---|
| 収益予測のしやすさ | 高い。契約数×単価で確定する | 低い。利用量の変動がそのまま売上の変動になる | 中程度。基本料が下限を作り、超過分だけが変動する |
| ヘビーユーザーの採算 | 危険。設例では▲110,000円。使われるほど赤字が拡大 | 良好。+140,000円(35.0%) | 良好。+114,000円(30.5%) |
| ライトユーザーの採算 | 良好。+106,000円(70.7%) | 赤字。▲4,000円。固定原価を回収できない | 薄いが黒字。+6,000円(12.0%) |
| 営業のしやすさ | 高い。予算化しやすく稟議が通りやすい | 低い。顧客側が総額を読めず予算化しにくい | 中程度。上限額の提示や超過アラートの運用が必要 |
| モデル上の扱い | 売上は顧客数のみに連動。原価は利用量に連動(分離する) | 売上・原価とも利用量に連動(同じドライバー) | 基本料=顧客数連動、超過=利用量連動の2層に分ける |
定額方式が危険なのは、価格の設定時に想定した利用量を顧客が超えても、契約上は何も起きないためです。解約もせず、値上げ交渉もなく、顧客満足度も高いまま、粗利だけが静かに消えます。従来型SaaSでは「利用が増えている=良い兆候」でしたが、この方式のAI製品では逆になります。ハイブリッド方式が実務で選ばれやすいのは、収益予測のしやすさと採算の安全性を両立できるためです(本記事の整理であり、どの方式が正しいかは製品と顧客層によります)。
なお、契約形態が変わっても収益認識の考え方そのものは変わりません。Bookings・Billings・Revenue・繰延収益のつながりはSaaS企業の収益モデリングで扱っているため、本記事では再説明せず、AI固有の原価側に集中しています。
財務モデルの組み方:利用量を1本のドライバーにする
手順は次のとおりです。ドライバー分解の一般論(何を売上の起点に置くか、トップダウンとボトムアップの使い分け)は売上予測とドライバー設計に譲り、ここではAI企業固有の実装だけを書きます。
- 顧客をセグメントに割ります。業種や規模ではなく利用量の水準で割ります。軽・中・重の3区分で十分に機能します。全社平均の利用量を1つ置くと、平均が実在しない架空の顧客像になります。
- セグメントごとに「顧客数」と「顧客あたり月間利用量」を別々の入力行にします。この2行を掛けたものが共通ドライバーです。片方だけを動かす感度分析ができるようにするため、掛けた値を直接入力しないことが重要です。
- 価格テーブルを別表にします。基本料・含まれる利用量・超過単価の3項目を、方式を切り替えられる形で持ちます。3方式を比較する場合は、選択セルとINDEX関数などで切り替える構成にします。
- 売上を計算します。ハイブリッドなら「基本料×顧客数+MAX(利用量-含まれる量, 0)×超過単価×顧客数」です。MAX関数を入れないと、含まれる量に満たない顧客の売上がマイナスになります。
- 変動原価を計算します。共通ドライバー×単位推論コスト。ここで参照するセルは、売上計算で参照したのと同じセルでなければなりません。
- 容量費用を計算します。自社基盤を持つ場合は「=CEILING(月間利用量合計 ÷ 1ブロックあたり処理能力, 1) × ブロック単価」で階段状に置きます。ハルカ・モデルズの設例では、120万件で CEILING(1,200,000÷600,000,1)=2、130万件で CEILING(1,300,000÷600,000,1)=3となり、表の必要ブロック数と一致します。
- 粗利を出し、セグメント別の粗利率を並べます。全社粗利率だけを見ると、赤字セグメントの存在が黒字セグメントに隠されます。
- 単位推論コストと単価を感応度分析の変数にします。単位推論コストは技術の進展や調達条件で変わりうる前提であり、最も感応度の高い入力の1つです。コストが1割下がった場合と1割上がった場合を、データテーブルで並べて確認します。
Excelでの実装例(シート構成)
| シート/行 | 内容 | 数式の例 |
|---|---|---|
| 前提 | 単位推論コスト、顧客あたり固定原価、ブロック単価・能力、価格テーブル | すべて直接入力(青字) |
| 顧客セグメント | 軽・中・重の顧客数と顧客あたり利用量 | 直接入力。前月+新規-解約で展開しても可 |
| 利用量合計 | 共通ドライバー | =SUMPRODUCT(顧客数レンジ, 利用量レンジ) |
| 売上 | セグメント別に計算し合計 | =顧客数*(基本料+MAX(利用量-含有量,0)*超過単価) |
| 変動原価 | 利用量に比例 | =利用量合計*単位推論コスト |
| 容量費用 | 階段状の固定費 | =CEILING(利用量合計/ブロック能力,1)*ブロック単価 |
| 粗利チェック | セグメント別粗利率と全社粗利率 | =粗利/売上(赤字セグメントを条件付き書式で強調) |
AIに任せる範囲と、人が判断する範囲
この作業のうち生成AIに任せられるのは、形式が決まっている部分です。価格方式ごとの計算表の雛形作成、数式のドラフト、単位の統一チェック、設例の検算、チェックリストの整形などが該当します。一方で、単位推論コストをいくらと置くか、原価をどこまで売上原価に区分するか、値上げの実現率をどう仮定するかは、社内の実績データと会計方針に基づく人の判断です。AIの出力に含まれる数値は、自社の請求明細や利用ログと突き合わせるまで前提として使えません。生成AIをファイナンス実務に組み込む際の全体的な考え方は生成AI×ファイナンス実務を参照してください。
計算表の雛形を作らせる場合のプロンプト例です。
役割:AI SaaS企業の財務モデルを組む担当者を支援するアナリスト。 目的:価格方式(定額/従量/ハイブリッド)ごとに、顧客セグメント別の売上・売上原価・粗利・粗利率を比較する計算表の雛形を作る。 入力(この値のみを使い、他の数値は補わないこと): - 顧客セグメント:軽=月2,000件、中=月10,000件、重=月20,000件。各1社。 - 単位推論コスト:12円/件(変動費、売上原価) - 顧客あたり固定原価:20,000円/月(売上原価) - 価格:①定額150,000円/月 ②従量20円/件 ③基本料50,000円(2,000件まで)+超過18円/件 単位:すべて円・月次。千円・百万円へ換算しないこと。 出力形式:方式ごとに1つの表。列は「顧客/利用量(件)/売上/変動原価/固定原価/粗利/粗利率」。 最終行に合計を置き、粗利率は小数第1位まで。マイナスは▲で表記。 計算方法: - 売上(ハイブリッド)=基本料+MAX(利用量-2,000, 0)×超過単価 - 変動原価=利用量×単位推論コスト - 粗利率=粗利÷売上 禁止事項: - 与えていない前提(成長率・解約率・値引き・税金)を追加しないこと。 - 実在企業の価格や原価を参照しないこと。 - 数値を丸めて合計を合わせないこと。 不明情報の処理:計算に必要な前提が不足している場合は、推測せず「不足している前提」として列挙すること。 出典表示:外部の数値を一切使わないため、出典欄には「入力値のみ」と記載すること。 検算:各方式について、①各行の粗利の合計=合計行の粗利 ②合計粗利÷合計売上=合計粗利率 の2点を計算して示すこと。 レビュー項目:定額方式で粗利がゼロになる利用量(損益分岐点)を計算し、根拠式とともに示すこと。
モデルの検証方法
AI企業の損益モデルに固有の検証項目です。生成AIの出力一般の検証手順(ハルシネーションの見抜き方、数値照合の型)は生成AI出力の検証手順に譲ります。
- 利用量セルを2倍にして、粗利率が下がることを確認します。定額方式なら必ず下がります。下がらない場合は、原価が利用量ではなく売上に連動して置かれています(=SaaSの発想が残っています)。
- 売上を2倍にして、粗利率がほとんど動かないことを確認します。粗利率が大きく改善する場合、変動費が固定費として置かれている可能性があります。
- 顧客数だけを増やし、利用量を据え置いて再計算します。分類②③では粗利率が改善し、分類①ではほぼ変わらないのが正しい挙動です。
- 容量費用の段差を確認します。CEILINGの境界(設例では600,000件の倍数)を1件またいだときに固定費が1ブロック分だけ増えるかを、実際に値を入れて確認します。
- 単位を確認します。「件/月」と「件/年」、「円/件」と「千円/件」の混在が最も多い誤りです。利用量の行と単価の行に単位を明記します。
- セグメント別粗利を1社単位に割り戻し、赤字顧客の有無を確認します。全社粗利率が黒字でも、設例の定額方式のように赤字顧客が混在していることがあります。
- 損益分岐利用量を独立に手計算し、モデルの出力と一致するかを確認します。設例では130,000÷12=10,833.3件でした。
機密情報・個人情報の注意
価格設計の検討では、顧客名と契約金額、顧客別の利用実績が同じ表に並びます。これは営業上の機微情報であり、外部の生成AIサービスにそのまま入力すべきではありません。プロンプトに渡す場合は、顧客名を「軽・中・重」などの匿名のセグメント名に置き換え、金額は構造の検証に必要な範囲に絞ります。また、利用ログには顧客の業務内容が反映されることがあり、内容によっては個人情報や取引先の秘密情報を含みます。社内ルールの作り方と入力可否の判断基準は生成AIに入れてよい情報・いけない情報を参照してください。
よくある失敗
- SaaSの粗利率80%をそのまま置く。最も多い誤りです。設例のとおり、推論コストが乗ると粗利率は大きく下がります。まず自社の請求明細から単位推論コストを求め、そこからモデルを組み直します。
- PoC・実証契約の売上を継続収益として積む。期間限定で更新前提のない契約を年換算して将来に延ばすと、売上の基盤を過大に見積もります。契約書の更新条項を確認し、継続収益と一時収益を分けて置きます。
- 推論コストを販管費に入れて粗利を良く見せる。製品提供に直接ひもづく費用を販管費に置けば粗利率は見かけ上改善しますが、比較可能性が失われ、投資家やレビュアーからは必ず指摘されます。区分を変えた場合は理由を明示します。
- 全社平均の利用量を1つだけ置く。平均値では赤字顧客の存在が見えません。利用量の分布は偏るのが通常であり、平均的な顧客は実在しないことが多いためです。
- 単位推論コストが将来大きく下がる前提を、根拠なくモデルに入れる。コスト低下を織り込むこと自体は妥当ですが、低下率は最も感応度の高い前提の1つです。前提として明示し、感応度分析の対象にします。
- 年次モデルだけで容量投資を判断する。階段状の容量費用は月次でしか見えません。段差をまたぐ月の粗利率悪化が、年次では平準化されて消えます。
日本企業・日本市場での留意点
- 従量課金と予算制度の相性。年度予算を固定額で承認する企業では、総額が読めない従量課金が購買部門で通りにくいことがあります。上限額付きのハイブリッド方式が選ばれやすいのは、この制約に対応するためです(本記事の整理です)。
- 収益認識の考え方。役務の提供に係る収益は、履行義務の充足に応じて各事業年度に帰属する扱いが法人税基本通達に定められています。定額契約と従量契約では収益が帰属する期間の考え方が異なりうるため、契約変更を検討する際は税務・会計の担当者に確認します。
- ソフトウェア関連費用の会計処理。研究開発費は発生時に費用処理し、自社利用のソフトウェアは将来の収益獲得または費用削減が確実である場合に資産計上する扱いが示されています。モデル開発費用をどう扱うかで、損益と資産の見え方が変わります。
- 為替の影響。外部モデルを海外事業者から調達している場合、単位推論コストは外貨建てになり、売上は円建てのままとなることがあります。この場合、為替が売上原価だけに効く非対称な構造になります。前提の為替レートをモデルの入力に明示します。
実務チェックリスト
- 自社の提供形態が4分類のどれに当たるかを特定した(複数に該当する場合は事業別に分けた)
- 単位推論コスト(円/件など)を、請求明細または利用ログから実績値として算出した
- 利用量の単位(件・回・トークン・時間のいずれか)を1つに定め、全シートで統一した
- 顧客を利用量の水準でセグメント分けし、平均値で代表させていない
- 「顧客数」と「顧客あたり利用量」を別々の入力行として持っている
- 売上と変動原価が、同じ利用量セルを参照している
- 価格テーブル(基本料・含まれる利用量・超過単価)を独立した表に切り出した
- ハイブリッド方式の売上計算にMAX関数を入れ、マイナスの超過が出ないようにした
- 自社基盤がある場合、容量費用をCEILINGで階段状に置いた
- 推論コストを売上原価に区分し、販管費に混ぜていない
- PoC・一時収益を継続収益から分離した
- セグメント別の粗利率を出力し、赤字セグメントを可視化した
- 定額方式を採る場合、損益分岐利用量を計算し、契約上の上限や超過条項の要否を検討した
- 単位推論コストと単価を感応度分析の変数に設定した
- 月次で組み、容量費用の段差が見える粒度になっている
価格方式別の粗利モデルを実際に組む
本記事の設例(顧客3社・3方式)をそのまま入力して、セグメント別粗利と損益分岐利用量が出るシートを作れば、自社データに差し替えるだけで使える雛形になります。モデリングラボの演習で手を動かして確認できます。
よくある質問(FAQ)
利用量の単位は、件数とトークンのどちらで持つべきですか。
財務モデルの入力としては、顧客との契約書に書かれている単位で持つのが原則です。請求の根拠と一致するためです。そのうえで、原価側の単位(外部モデル提供者からの請求単位)が異なる場合は、「1件あたり平均◯単位」という換算率を独立した入力行として置きます。換算率は実績から求め、モデルの中に埋め込まずに前提シートに出します。技術要因で換算率が変わったときに、そこだけを差し替えられるようにするためです。
粗利率が低いAI企業は、ビジネスモデルとして劣っているのですか。
粗利率の水準だけでは判断できません。粗利率が低くても、顧客あたりの粗利額が大きく解約率が低ければ、事業として成立します。逆に粗利率が高くても、獲得コストを回収する前に解約されれば成立しません。重要なのは粗利率がどの変数に反応するかを把握し、価格設計と原価構造でその反応を制御できる状態にあるかどうかです。なお本記事は財務モデルの組み方を扱うものであり、特定の企業や投資の推奨ではありません。
すでに定額で契約している顧客が赤字だと分かった場合、モデル上どう扱えばよいですか。
現行契約の残存期間は赤字のまま置き、更新時点で価格改定または利用量上限を導入するシナリオを別に置くのが実務的です。ここで必要な入力は「改定を提示する顧客の割合」と「そのうち受け入れる割合」の2つで、両方を明示的な前提として持ちます。改定を拒否した顧客が解約するケースも織り込むと、価格改定の期待値が計算できます。楽観・基本・保守の3ケースで並べると意思決定に使えます。
まとめ
AI企業の損益計算書を組むときの要点は3つです。第1に、提供形態によって損益の形が違います。外部モデルを使うアプリケーションでは推論コストが変動費として売上原価に立ち、自社モデルを保有する企業では設備の償却と学習費用が固定費として乗ります。モデル/API提供では容量が階段状に増え、既存ソフトへの組込では原価だけが増えて価格に転嫁しにくくなります。
第2に、従来型SaaSの「限界費用ほぼゼロ」は成り立ちません。粗利率は売上と一緒には伸びず、顧客ミックスの変化だけで動きます。SaaSの粗利率をそのまま置いた瞬間に、モデルは現実を説明しなくなります。
第3に、価格設計は損益構造そのものです。設例では、同じ顧客3社・同じ原価444,000円に対して、定額方式では合計粗利6,000円(1.3%)で重ユーザーが▲110,000円の赤字、従量方式では196,000円(30.6%)だが軽ユーザーが▲4,000円の赤字、ハイブリッド方式では174,000円(28.2%)で3社すべてが黒字となりました。財務モデルでは利用量を1本の共通ドライバーとして置き、売上と原価の両方から同じセルを参照させます。この構造さえ作れば、価格方式の比較も損益分岐利用量の算出も、同じモデルの上で完結します。
出典・参考(2026-08-16確認)
- 企業会計審議会「研究開発費等に係る会計基準の設定に関する意見書」(平成10年3月13日)— 研究開発費の費用処理、自社利用ソフトウェアの資産計上要件。https://www.fsa.go.jp/p_mof/singikai/kaikei/tosin/1a909e1.htm
- 日本公認会計士協会「研究開発費及びソフトウェアの会計処理に関する実務指針について」— ソフトウェア制作費の具体的取扱い。https://jicpa.or.jp/specialized_field/post_785.html
- 国税庁「法人税基本通達 第2章第1節第3款 役務の提供に係る収益」— 履行義務の充足に応じた収益の帰属時期。https://www.nta.go.jp/law/tsutatsu/kihon/hojin/02/02_01_03.htm
- 本記事の数値はすべて架空の設例に基づく計算結果です。実在企業の財務数値・価格・評価額は使用していません。AI製品の料金・性能は変動するため本記事では扱っていません。
※本記事は教育目的の一般的な解説であり、法務・税務・会計・投資に関する助言ではありません。実際の判断は専門家にご確認ください。設例は理解のための仮設例です。AI製品の仕様・料金は変更されることがあるため、利用前に各社の公式情報をご確認ください。