原価の裾から値をつける

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

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

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

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

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

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

課金単位に割る

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

見落としやすいのが保存と検索だ。ストレージと埋め込みは解約まで課金が残る。他のアクションとは別枠で数える。

実測する

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

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

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

平均を捨てて分布を見る

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

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

月次原価/人   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に任せられるが、価格の最終決定は自分の仕事として残す。

今日のまとめ

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

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