原価の裾から値をつける

値付けで一番危ないのは、高くつけすぎて売れないことではない。原価を知らないまま安く出すことだ。裏でLLMを動かすプロダクトは、無料枠の設計を1つ間違えるだけで、売上より原価の伸びの方が速くなる。

ここで出すのは「いくらにするか」ではない。「いくらまでなら壊れないか」を先に出す。金額の最終決定は自分の仕事だが、その前段の原価計算と選択肢の整理はAIに任せられる。

手順0: その機能を落とせないか先に問う

上限設計に入る前に、もっと安い解決策がある。変動費を生む機能は、単価だけでなく上限3段の実装・原価ログの計装・月次の再計測・キルスイッチの運用という付帯コストを丸ごと連れてくる。落とせるなら、どんな上限設計より安くて確実だ。

先に問う3つ。

1. その機能は製品価値の核か、飾りか。核でないなら落とす候補になる
2. 落としたとき、売り文句のどこが変わるか。変わらないなら落としてよい
3. まだ課金を始めていないか。購入者ゼロなら無傷で落とせる。始めた後は約束の取り下げになる

落とすと決めても、実装を消す必要はない。プランのfeaturesから外す、UI導線を切る、APIキーを設定しない。この3つで機能は止まる。コードは資産として残せる。

2026年9月、pediaの買い切り5,000円・無期限プランには、上限のないAIチューターが付いていた。損益分岐は約1,850回で、それを超えると永久に純損失が続く設計だった。上限をどう設計するかを検討する前に「この機能は本当に要るか」を問うたところ、医療安全上の理由でUIからは既に外されており、残っていたのはプランの約束文言だけだったと分かった。featuresから2行消すだけで、赤字構造そのものが消え、上限もキルスイッチもトークン記録も不要になった。上限設計に何時間もかける前に、この問いを1回通すだけで済む場合がある。

課金単位に割る

機能一覧ではなく、原価が発生するアクションの一覧を作る。原価構造が違うものは混ぜない。

要約サービスを例にすると、記事の要約は入力トークン×本文長、動画の処理は文字起こし秒数と要約の両方、チャットは往復回数×文脈長というように、アクションごとに変動要因がまったく違う。1つの「利用料」にまとめてしまうと、どのアクションが原価を押し上げているか見えなくなる。

見落としやすいのが保存と検索だ。ストレージと埋め込みは、ユーザーが使わなくなっても課金が続く。解約されるまで原価が残るものは、他のアクションとは別枠で数える。

実測する

「あのモデルは1Kトークンいくら」から掛け算した数字は原価ではない。実際のログから出す。

各アクションのAPI呼び出しに、入力トークン数・出力トークン数・モデル名・ユーザーID・アクション名を必ずログする。ログしていないなら、値付けの前にこれを入れる。計測は前のレッスンで扱った通り、実装と同時に入れるものであって、値付けの直前に慌てて後付けするものではない。

最低2週間、またはアクション200件のどちらか遅い方まで貯める。1アクションあたりの実費を、モデルごと・アクションごとに円で出す。ここまでの実測が取れるまでは、値付けを確定しない。仮の数字で確定したプランは、後から上げにくい。

平均を捨てて分布を見る

ここが値付けの型の中心になる。出すのは4つ。ユーザー1人あたり月次原価のP50・P90・P95・P99。平均は使わない。

LLM利用は裾が重い。上位1%のユーザーが原価の3〜5割を占めることは普通に起きる。平均で利益率を着地させると、そのユーザーが1人来ただけでプランが赤字に転じる。「ライト・ミドル・ヘビーが2:6:2で分布する」という仮定も、裾の1人を平均側に押し込んでいる点では同じ罠にはまっている。

月次原価/人   P50: ¥__   P90: ¥__   P95: ¥__   P99: ¥__   最大: ¥__

判定の目安はP99が月額の40%以内に収まるかどうか。収まらない場合は、次の上限設計で抑える。

上限を3段で設計する

数値をドキュメントに書いただけでは設計にならない。コードに入っていることを確認する。

キルスイッチはサービス全体にかける方だ。個別ユーザーの使いすぎではなく、プロンプトのバグやループでAPIを叩き続ける事故を止めるためのものになる。

2026年9月、社内の論文パイプラインが、プロバイダ未指定時に外部の生成AI APIへ黙って流れる既定値を持っていたことがあった。上限も件数ゲートも実行前の予告もなく、1日だけで数千件のリクエストが発生した。従量課金APIを既定値にしない、一括処理は件数と概算費用を予告してから走らせるというルールは、この経験から生まれている。上限設計は「起きたら困るから念のため」ではなく、実際に起きた事故を踏まえた必須工程だ。

プラン表を引く

3プランが標準形になる。

Freeの枠は「たくさん試せる」ではなく「1回価値に届く」で引く。到達に必要な回数は、前のレッスンで定義したactivationの基準から出す。推測しない。

年額は月額の10〜12ヶ月分にする。割引ではなく、前受けでキャッシュを厚くするのが目的だ。3プランを並べて客に選ばせるのではなく、どれを選ばせたいかを先に決め、その1つだけを推奨表示にする。医療・専門職向けの場合は、経費で落ちる価格帯と個人の自腹の価格帯が別物になるので、想定購入者がどちらの財布かを先に書いておく。

2週間で仮定を実測に差し替える

値付けは1回で終わる作業ではない。

ローンチから14日後、実ユーザーのP50・P95・P99を再計測し、分布の表を更新する。枠を上げるのは自由だが、下げるのは既存ユーザーには適用せず、新規からにする。想定と実測が2倍以上ずれていたら、プラン構造そのものを引き直す。

罠リスト

値付けで繰り返し起きる失敗と、その対処をまとめる。

AIが越えない線

原価計算とプラン案の作成はAIに任せられる。しかし価格の最終決定は自分の仕事として残す。AIは実測した原価とP50・P90・P95・P99の分布、上限の実装状況、選べる価格の候補までを並べる。そこから先、いくらにするかを選ぶのは本人であって、AIが断定で金額欄を埋めるものではない。予告して、承認を得て、実行する順番はここでも変わらない。

今日のまとめ

3行で振り返る。

• 上限設計の前に、その機能自体を落とせないか問う。落とせれば上限設計そのものが不要になる
• 平均でなくP50・P90・P95・P99の分布で原価を見る。裾の重いユーザーが原価の大半を占めることが普通に起きる
• プランは2週間で仮定を実測に差し替える。価格の最終決定は本人の仕事として残す

次のレッスンでは、値をつけたプロダクトを実際に人に届ける6点セットに進む。