AI機能の料金設計、トークン従量ではなく「仕事の単位」で売る理由

AI機能の料金設計で最初に決めるのは、従量課金か定額かといった料金モデルの種類ではない。顧客に出す請求のメーターを、原価のメーターから切り離すかどうかである。「AI機能 料金設計 従量課金」で検索すると上位に並ぶのは決済・課金事業者による料金モデルの解説と従量課金の導入手順で、どの型があるかの列挙としては整っているが、売り手が最初に決める一点には答えていない。本稿はその一点に絞る。

なぜAI機能の値付けはトークン原価に引きずられるのか

モデルの層で始まった課金の論理を、そのまま上の層に持ち込んでいるからである。

a16zは、トークン課金は正しい場所、すなわちモデルの層で始まったと書いている。2020年にOpenAIがAPIを公開したとき、モデルが消費した計算量に課金することは素のままの推論を計測する妥当な方法だった。だがその2年後のChatGPTの登場をきっかけに、その基盤の上にもっと多くのことをするアプリケーションの波が立ち上がった。独自のデータやツール、ワークフローの論理を組み合わせ、顧客に代わって仕事を仕上げるプロダクトである。そうしたアプリケーションがその仕事をトークンで値付けすると、モデル提供者のコスト構造を顧客との関係に持ち込むことになり、プロダクトの価値をコストが下がり続ける単位に縛りつけることになる、というのがa16zの主張だ。同社は別の節で、従来のSaaSなら利用者が1人増えても限界原価はほとんど増えないのに対し、AIアプリケーションでは利用者1人ごとに推論や検索などの限界原価が発生し、売上の伸びが事業の弱さを隠しうる、という前提を置く。そこから、価格の設計で粗利を守る必要を論じている（生成AI機能の値付けはトークン従量課金でいいのか ― a16z調査に見る「価値単位」の価格設計）。

ここから先は本稿の読みである。持ち込みが起きる理由の1つは、原価の側が実際に読めないことにあると考えられる。米メディアEveryでAI利用コストの運用ルールを作ったArielle Shipperの実録が、その読めなさを具体的に見せている。同社は1つのモデルに全面的に寄せず、仕事ごとにいちばん合うものを使う。そのため、強みも価格構造も違う新しいモデルが出るたびに、コストの予測は難しくなる。彼女自身が、精緻な配分の仕組みを作っても数日どころか数時間で陳腐化すると書いている。記事の末尾にある一例が分かりやすい。Every CEOのDan Shipperは、ある晩、必須ではないタスクにSol（ultra）を走らせて2,000ドルを使っている（AI 利用コストの予算管理はどうすべきか ― 支出230%増でもトークン予算を設けない Every の判断基準）。これは社内の利用の1件であって、プロダクトの値付けの話ではない。だが、原価を日次で予測しようとしても精緻な仕組みが数時間で古くなる、という現実の側面は共通している。読めない数字を請求の単位に据えれば、読めなさはそのまま顧客に渡る。

顧客の側がどう受け取るかについては、a16zの整理がある。顧客がトークンについて尋ねるとき求めているのは、比較可能性か統制のどちらかである。だがトークン単価を請求の単位にすると、顧客は本来なら明快なROIの計算で済んだはずのものを、プロダクトごとの計算量の予測作業に変えられてしまう。自分の業務の件数は数えられても、1件が通る計算量の内訳は数えられないからだ。

「価値単位」で値付けするとは、何を切り離すことなのか

2つの表を切り離すことである。料金モデルの名前を選ぶことではない。

a16zの層分け（モデルへのアクセス、仕事、成果のどこで値付けするか）そのものは、既にキュレーション記事で扱った。本稿が取り出したいのは、その実装として同社が書いている分離である。本稿はこれを2つの表として言い直す。

• 価値の表: 顧客が買う1単位がいくらか。顧客価値、支払意思、競合で決まる
• 消費量の表: その1単位が原価をいくら食うか。モデル構成、ルーティング、キャッシュなど原価側の条件で決まる

a16zが書いているのは、この2つを別の意思決定として扱えば、原価側の改善による粗利の上振れを売り手が残せる、という点だ。原価が下がったとき、顧客は計算量の実費を精算しているのではなく仕事に対して払っているので、恩恵の一部をアプリケーション側が残せる場合がある。同社はこれを、透明性の問題と切り分けて一文で言い切っている。

“Transparency does not require the billing meter and the underlying cost meter to be the same.”

訳: 透明性のために、請求のメーターと背後の原価のメーターが同じである必要はない。

出典: a16z by a16z, 2026-08-28

実例として同社が挙げるClayは、層ごとに別のメーターを使っている。原価が予測できるモデルには固定価格を保ち、変動が大きく高価な推論モデルについては実際のトークン原価をマークアップなしで通過させる。2026年の価格メモで、過去にクレジットを誤って値付けし長年赤字で運用したセグメントがあったことも認めているという。

顧客がこうした単位を好む傾向を示す数字もある。a16zが技術系のAI購買層50人に行った調査では、認識できる仕事に紐づくクレジットを選んだのが27人で、トークンを選んだのは14人だった。同社自身の調査で50人という規模なので、市場全体の結論としては読めない。ただし、クレジットという器にすれば済む話でもない。同社は、トークン数を不透明な内部通貨に置き換えただけのクレジットは弱い体系であり、メーターを隠しただけで改善していないと書いている。判定基準は理解可能性であり、顧客が数文で理解できないクレジット体系は複雑すぎる、とされる。

原価が動いたとき、その変動をどこで受けるのか

価値の表ではなく、消費量の表とマージンで受ける。ここが分離のいちばんの効き目である。

a16zの論の前提は、トークンが「コストが下がり続ける単位」だという点にある。だから価値単位で値付けすれば下がった分の取り分を残せる、という筋になる。しかし、原価が上がる側の観測も同じ時期の元記事に出ている。

Dwarkesh Patelは、今後数年で計算資源が10倍以上高くなりうると論じている。足元の事実として挙げているのは2つだ。計算資源のスポット価格は2月の底から40%以上上がっている。そしてラボが確保するような大口の計算資源ではもっと強く、GoogleはSpaceXから、GB200とGB300の混成である11万基のGPUを月9億ドルで借りていると報じられており、これは同じGPUの時間当たりスポット価格のおよそ2倍にあたる。論の骨格は、モデルが賢くなるほど同じ計算資源をより良く収益化できるため、計算資源の限界価値（したがって限界価格）が極端に高くなる、というものだ。帰結の1つとして、現在よく使われているAIの用途の多くが価格的に成り立たなくなると書いている（AIのAPI料金はどこまで上がるのか——収益10倍成長と計算供給3倍の需給ギャップが招く値上げ構造）。

この元記事の性質と射程は書いておく。Patel自身が、執筆を2時間に時間制限した実験的な記事であり、多くの重要な副次論点は詰め切れていないと冒頭で断っている。収益が年10倍で伸び続けるという前提も、彼が「仮にそうだとしたら」と置いた仮定である。彼はいずれ計算資源は再び安くなるとも書いており、値上げの論は供給が年3倍にとどまる現在の局面に限定されている。そしてここが重要だが、彼が論じているのはラボが借りる計算資源の価格であって、アプリケーションが払うAPIのトークン単価ではない。彼が収益10倍の説明として挙げる調整弁は3つ（ラボの利益率の上昇、計算資源の価格の上昇、推論に充てる割合の上昇）で、計算資源の値上がりはそのうちの1つである。利益率については、AnthropicのFable推論が2025年の40%から今年はおそらく80%超へ上がったという見立てを示しつつ、限界の計算資源では違うかもしれないと括弧で限定し、利益率だけで説明するには来年末に90%台半ばが必要で非現実的だと退けている。つまり利益率は値上げを吸収する経路として挙げられたものではない。他方、彼は効率の良いモデルを訓練できたラボが大きなプレミアムを取れるようになるとも、現在よく使われている用途の多くが価格的に成り立たなくなるとも書いているので、利用者側の価格に波及する含みはある。API のトークン単価そのものの予測値を書いていない、というだけである。言えるのは、原価が下がり続けるという前提だけを置くのは危ない、というところまでだ。

実務側からも、同じ方向を向いた観測はある。Everyの記事は、これまでAI実験に金を投じられたのは、定額の月額の下で重い利用を補助するサブスクリプションがコストの大半を負担していたからだと書き、シニア応用AIエンジニアのNityesh Agarwalが「その時代は残り少ない」と言ったことを伝えている。彼は、明日のAIを動かすデータセンターが足りない計算資源制約の世界にいるとも語っている。記事は続けて、AI企業が予算の大きい法人顧客を優先するため、とくに個人の利用コストは上がると予想している。対象が個人の利用コストである点は押さえておきたい。これはアプリケーション提供者がAPIに払う原価の予想ではない（AIのトークンコストはどう最適化するのか ― 「トークン監査」とマルチモデル運用に見る効率化の実務）。

ここから先は本稿の読みである。原価が上がる可能性を織り込むと、分離の効用の言い方が変わる。「原価が下がるから取り分を残せる」のは半分にすぎない。残りの半分は、値上げの時期と幅を売り手の側で選べることだ。ここは限定して言う必要がある。トークンを請求の単位にしても、売り手が自分でトークンの価格表を決めて据え置けば、改定の時期は選べる。選べなくなるのは、原価をそのまま顧客に通す設計にした場合である。そのとき原価が動けば請求額が自動で動き、売り手は顧客ごとに事後の説明をするしかない。2つの表に分けてあれば、売り手の判断で決める対象が2つ残る。顧客向けの単価をいつ・どれだけ見直すか。そして見直すまでの差をマージンで受けるか。a16zが挙げるClayが、原価の予測できるモデルは固定価格、変動が大きく高価なモデルだけ実コストの通過という二階建てにしているのは、この線をモデルごとに引いた例として読める。ここで誤解してはいけないのは、分離が値上げを不要にするわけではないことだ。原価が上がれば、どこかで顧客の1単位あたりの負担が上がるか、売り手のマージンが削れるかのどちらかになる。分離が与えるのは、その負担をいつ・どれだけ・どの形で渡すかを決める余地であって、負担そのものの消滅ではない。改定の周期を顧客との契約に先に書いておけるかどうかが、実務上の分かれ目になる。本稿は、顧客の見積もりを壊さない周期として四半期を置くが、これは検証すべき仮説である。

もう1つ、トークンがそもそも仕事の量を表していないという問題がある。Grok 4.5について、xAIは主要なモデルのおよそ2倍のトークン効率で動くと主張している。価格は100万トークンあたり入力2ドル・出力6ドルで、Everyが比較したフロンティアのモデル——Claude Opus 4.8が5ドルと25ドル、GPT-5.6 Solが5ドルと30ドル——よりかなり安い（AIコストを大きく下げるモデルルーティングを誰が設計するのか ― Grok 4.5と「100万トークン当たり収益」の時代）。単価の差は記事に書かれた数字で、出力では最大5倍の開きがある。トークン効率の約2倍はxAIの自称であり、独立した検証ではない。仮にこの自称が正しいとすれば、同じ仕事を通しても、どのモデルを使うかで消費トークン数と単価の両方が動く。そうであれば、トークンを請求の単位にした時点で、顧客から見た「1回分の仕事の値段」は売り手が内部でモデルを差し替えるたびに変わることになる。顧客が見積もれないのは当然である。

自分の組織のAI機能で最初に決める価格単位は何か

顧客が請求書を見る前からすでに数えている仕事の単位を、1つ選ぶことである。

a16zが立てている問いが、そのまま出発点になる。「AIの料金指標は何か」ではなく、「顧客がすでに理解している価値の単位は何か、そしてそれを一貫して測れるか」である。カテゴリごとに価値の包み方が違うため、AIアプリケーションに共通の指標は存在しない、というのが同社の整理だ。与信審査1件、月次レポート1本——自分の組織のAI機能が何を仕上げているかによって、答えは違う。

決めるべきことは4つに整理できる。1・2・4はa16zが挙げている論点で、3と、4つを置く順序が本稿の整理である。

1. 単位を選ぶ（a16z）。顧客がすでに理解していて、一貫して測れる単位を使う
2. 1単位の値段を決める（a16z）。顧客価値、支払意思、競合で決める
3. 1単位が食う原価を別の表で持つ（本稿）。モデル構成、ルーティング、キャッシュで決まる。原価の改善も悪化も、まずこの表に書く
4. 通過させる範囲を明示する（a16z）。極端に高価で変動の大きいモデル利用だけは、ハイブリッドの明示的な構成要素としてトークンの通過料金を残す。既定の表現にはしない

この4つのうち、値付けの部署だけで完結するのは2だけである。1は顧客理解を持つ側、3はモデル構成を持つ技術側、4はその境界の判断だ。経営が決めるべきは、3の表を誰が持ち、どの頻度で見直すかの一点である。本稿の立場は、消費量の表はモデルを切り替えるたびに更新し、顧客向けの単価との整合は四半期ごとに見る、という2段の頻度を置くことだ。モデルの差し替えで消費量が動きうることは、xAIのトークン効率の主張と各モデルの単価差が示す範囲で言える。一方、顧客向けの単価を四半期より短い周期で触れば見積もりが壊れるというのは、本稿の仮説である。表の持ち主と頻度を決めないままにすると、原価が動いたときに動くのは消費量の表ではなく請求額のほうになる。そうなった瞬間、価値単位という看板の裏側で、やっていることはトークン従量課金に戻っている。

なお、同じトークン原価を買い手としてどう予算に織り込むかは生成AIのトークンコストは、なぜ日本企業の予算サイクルと噛み合わないのかで扱った。そちらが扱うのは自分の組織が支払う側の稟議と予算サイクルで、本稿は自分の組織が請求する側の価格単位である。立場が逆なので打ち手も逆向きになる。買い手としては原価の変動を予算プロセスで吸収し、売り手としてはその変動を顧客の請求額に自動で渡さない。また、特定のモデル提供者への依存をどこまで許すかという調達側の判断はAIのベンダーロックイン回避は、設計ではなく値段の問題だで扱っている。本稿の4で通過料金を残す範囲を決める判断は、その裏返しとして、どのモデルの価格変動なら顧客に見せてよいかを決める作業にあたる。

まとめ: 料金モデルを選ぶ前に、メーターを2本に分ける

AI機能の料金設計の最初の決定は、従量課金かクレジットか成果課金かという型の選択ではない。顧客に出す請求のメーターと、原価のメーターを別物として持つかどうかである。a16zの購買層調査では、認識できる仕事に紐づくクレジットを選んだ人がトークンを選んだ人を上回った。規模と出所に限りはあるが、顧客が分かりやすい単位を好む傾向を示す一材料にはなる。そして分離がもっとも効くのは、原価が下がったときではなく上がったときである。Dwarkesh Patelが計算資源の10倍以上の値上げを論じている局面では（対象はラボが借りる計算資源の価格で、API単価の予測ではない）、原価の変動を請求額へ自動で流さない構造そのものが選択肢になる。分離は値上げを不要にはしない。値上げの時期と幅を売り手の側で選べるようにするだけである。次の価格改定で決めるべきは、顧客がすでに数えている仕事の単位を1つ選ぶこと、そして1単位が食う原価の表を誰が持ち、モデルの切り替えのたびに更新して四半期ごとに単価との整合を見る体制にするかを決めること、この2点である。