AIライティングアシスタントを運営するある創業者が、自社の「ソフトウェア費用」は月額$40,000だと私に話してくれた。その内訳を分解してみると、$34,000はOpenAIとAnthropicのAPI利用料だった——そしてその金額は一切、売上原価に含まれていなかった。月額$19のプロジェクト管理ツールのすぐ隣で、「ソフトウェア・サブスクリプション」という一般勘定科目に紛れ込んでいたのだ。彼が報告していた粗利益率は91%。だが推論費用を本来あるべき場所に移した後の実際の粗利益率は58%だった。
これは単なる簿記上の技術的な問題ではない。ソフトウェア企業に見える事業と、工場のように振る舞う事業——販売する一単位ごとに実質的な変動投入コストを消費する事業——との違いを分けるものだ。GPT-5、Claude、Gemini、あるいはその他のホスティング型モデルの上に構築しているなら、LLMの利用料は間接費ではない。それは売上原価であり、そうでないものとして扱うということは、実際にいくら利益を上げているのかを本当には把握していないということだ。
この間違いがこれほど起きやすい理由
従来型のSaaSは、一世代分の創業者たちに「ソフトウェア費用は固定費である」という考え方を叩き込んできた。ホスティング費用を払い、CRMに料金を払い、Slackに料金を払う——そしてそれらの請求額は、特定の顧客がどれだけ製品を使おうと連動して動くことはない。だからOpenAIから最初のAPI請求書が届いたとき、それを同じ心理的な引き出しにしまい込むのは自然なことだ。「事業を回すために支払っているツール」として。
問題は、LLM APIの請求がSaaSのサブスクリプションのようには振る舞わないということだ。それは原材料のように振る舞う。顧客がプロンプトを送信するたびにトークンを消費し、トークン一つひとつに価格がついている。1日に50回リクエストを送る顧客は、2回しか送らない顧客に比べて、提供コストが大幅に高くつく。これはまさに売上原価の教科書的な定義だ——利用状況にかかわらず事業を維持するために支払うコストとは対照的に、特定顧客への製品提供に直接連動して増減するコストのことである。
業界データもこの重要性の高まりを裏づけている。ICONIQの2026年1月版「State of AI」レポートによると、スケーリング段階にあるAI B2B企業では、推論費用が総収益の平均23%を占めるまでになっており、これらの企業の84%が、AIインフラコストに直接起因する6ポイント以上の粗利益率の悪化を報告している。これは「その他営業費用」に吸収できるような誤差の範囲ではない。むしろ事業における単一最大のコスト要因であることが多く、それにふさわしい扱いを受けるべきである。
売上原価と営業費用の境界線を正しく引く
売上原価と営業費用を分ける原則は、入力が倉庫いっぱいの部品ではなくモデルAPIになったからといって変わるわけではない。**有償顧客に製品を届けるためのコストは売上原価に、製品を構築するためのコストは営業費用（研究開発費）に計上する。**この原則をAIラッパーに適用すると、次のような区分になる。
売上原価に含まれるもの:
- 本番環境の推論コスト — チャット補完、埋め込み呼び出し、分類処理、エージェントのツール呼び出しループなど、稼働中の製品が有償顧客のために行うすべてのAPI呼び出し
- モデルのホスティング／GPU計算資源 — ホスティング型APIを呼び出す代わりに、自社または賃貸インフラでオープンウェイトモデルを稼働させている場合、顧客リクエストの提供に起因する計算時間
- 推論を支えるインフラ — 本番リクエストに対応するために存在するベクトルデータベースへの問い合わせ、埋め込みパイプラインの実行、オーケストレーションのオーバーヘッド
- AI特有のサポートコスト — 顧客向けにモデル出力の問題をトリアージすることが職務であるサポートエンジニアは、一般的な販管費ではなく製品提供コストである
営業費用（通常は研究開発費）に含まれるもの:
- 開発・テスト用の推論 — エンジニアが機能を反復開発したり、不具合を調査したり、新しいモデルバージョンを評価したりする際に送るすべてのプロンプト
- ファインチューニングと評価の実行 — モデルの構築や改善は研究開発であり、提供ではない
- 社内AIツール — チームのChatGPT Enterpriseの席数やGitHub Copilotのライセンスは、顧客への提供コストではなく生産性向上のための費用である
この区分を可能にする実務上のステップは地味だが不可欠だ。**初日から本番環境と開発環境のトラフィックに別々のAPIキーまたは請求プロジェクトを使うこと。**エンジニアが製品の本番環境と同じキーに対してプロンプトをテストしていたら、後から請求額を正しく配分する方法はなくなり、毎月必ず実際の利益率を過大評価するか過小評価するかのどちらかになってしまう。
AI製品における「本当の」粗利益率とは
この区分を行うと、出てくる数字がこれまで見慣れたものとは違って見えてくるはずだ。従来型のSaaS企業は、当然のように70〜80%の粗利益率を目標にする。AIネイティブの製品は同じようにはいかない。Bessemer Venture Partnersの2026年2月版プライシング・プレイブックによると、典型的なAI製品の粗利益率は50〜60%で、従来型SaaSの80〜90%というレンジを大きく下回る。ICONIQのデータでも、業界平均のAI製品粗利益率は上昇傾向にあるものの、2024年の41%、2025年の45%から、2026年時点でもわずか52%にとどまっている。
これを間近で管理してきた事業者から生まれた有用な経験則がある。**持続可能でスケール可能なビジネスモデルを目指すなら、LLMコストを売上原価全体のおおむね20%未満に抑えること。**この閾値を超えると、事業が成長するにつれて利益率の圧縮はむしろ加速する傾向にある。なぜなら、より大口の顧客ほど製品をより多く使う、決して少なく使うわけではないからだ。コーディングアシスタントやドキュメント処理エージェントなど、一部のAI依存度の高いカテゴリでは、LLMコスト比率が売上原価の30〜40%に達しながらも事業として成立しているが、それはその現実を見越して意図的に価格設定を行っているからにほかならず、なりゆき任せでそうなったわけではない。
本当に重要な数字は、会社全体を平均した粗利益率ではない——顧客ごとのコストである。あるAI機能のヘビーユーザーは、同一のサブスクリプション階層にいるライトユーザーに比べて、生の推論コストで50倍から100倍も提供コストがかかることがある。これを追跡していなければ、どの顧客が採算に合っていて、どの顧客を毎月ひそかに補助金で支えているのかが分からない。最初の10社の顧客では問題なく見えていた定額プランも、そのうちの1社がワークフローを本番稼働させてリクエスト量を20倍に増やした瞬間から、赤字を出し始めることがある。
リクエスト単位のコストモデルを構築する
始めるために大掛かりなツールは必要ない——必要なのは、すべてのリクエストで正しい数値をログに記録するという規律だ。基本の計算式はシンプルである。
request_cost = (input_tokens / 1,000,000) × input_price_per_million
+ (output_tokens / 1,000,000) × output_price_per_million出力トークンは通常、単位あたり入力トークンの2〜5倍のコストがかかる。生成は、プロンプトを読み込むよりも計算負荷が高いためだ——したがって、入力と出力を分けずに総トークン数だけを追跡するリクエストコストモデルは、長い応答を伴うものすべてで体系的に価格を見誤ることになる。2026年半ばの価格を用いた実例を挙げると、入力トークン2,000と500トークンの応答からなるリクエストを、主流のミドルティアモデル（おおよそ入力$3／出力$15、いずれも100万トークンあたり）で処理すると、コストは約$0.0135になる。同じ形のリクエストを月に50,000回実行すると、その一つの機能だけでおよそ$675の推論コストがかかる計算になる——5桁の「クラウドコスト」という科目に埋もれていれば見えない数字だが、その機能とそれを生み出した顧客セグメントに紐づけた途端、はっきりと見えてくる。
これを実行可能にするために:
- すべてのリクエストでトークン数をログに記録する。コストだけでなく。ほとんどのモデルプロバイダーはAPIレスポンス自体に入力・出力トークン数を返してくるので、これは新しいデータソースではなく、単なるログ記録の変更にすぎない。
- 各リクエストに顧客IDと機能識別子をタグ付けする。そうすることで、月次だけでなく、アカウント単位・製品機能単位でコストを集計できる。
- 請求期間ごとに顧客単位のコストを計算し、その顧客が支払っている金額と比較する。これが、平均化された粗利益率ではなく、価格帯が実際の提供コストと本当に見合っているかどうかを教えてくれる数字だ。
- **品質が許す範囲で、より安価なモデルにルーティングする。**すべてのリクエストが最も高性能（かつ最も高価）なモデルを必要とするわけではない——分類、抽出、単純な整形といったタスクは、より小型で安価なモデルでも十分な性能を発揮することが多く、モデルルーティングは、プロバイダーの価格設定とは異なり、完全に自社でコントロールできる数少ない利益率のレバーの一つである。
見つけ出した利益率を守るための価格設定
推論費用が正しく売上原価として分類されると、価格設定の議論は変わってくる。事業者がよく使う基準は、ユニットあたりのトークンコストのおおよそ3〜5倍で価格を設定することだ。たとえば$0.30のタスクを$1.00以上で提供する。この倍率自体に魔法があるわけではなく、利用量の変動、モデル価格の変動、そして生の推論費用に付随するサポートやインフラのコストを吸収する余地を残すためである。
従量課金制は、AI企業が価格設定と売上原価を連動させ続けるための標準的な方法になっている。トークン単位、リクエスト単位、あるいは完了したタスク単位で課金すれば、収益はコストを左右するのと同じ変数に応じてスケールし、定額サブスクリプションのように利用が急増したときに乖離していくことがない。完全な従量課金制への移行の準備がまだできていないなら、少なくとも「最低利用量プラス超過分」の階層を構築し、典型的な利用量を大きく超えた顧客がその月だけ静かに赤字要因になってしまうことを防ぐべきだ。
コードと同じくらい監査可能なコスト構造を保つ
これは単なる任意の簿記上の衛生管理ではない——自社のビジネスモデルが機能していると分かっていることと、資金調達のデューデリジェンスの電話で、投資家側のアソシエイトが本来6か月前に自分たちで構築しておくべきだった顧客単位のコストモデルを作り上げてしまい、その場でようやく機能していないと発覚することとの違いなのだ。この会話を回避できる創業者は、OpenAIの請求額が無視できないほど大きくなるまで待つ人たちではなく、最初のAPI呼び出しから推論コストを顧客と機能に紐づけている人たちである。
Beancount.ioは、プレーンテキストでバージョン管理された会計を提供し、推論支出を適切な勘定科目に紐づけ、本番環境と開発環境のAPI利用を分離し、実際の売上原価を毎月の収益と突き合わせることを容易にする——ブラックボックスの分類もベンダーロックインもない。無料で始める——プレーンテキスト会計へ乗り換える開発者やAIネイティブの創業者たちが増えている理由を、ぜひご覧いただきたい。