定額の裏側(4) 名前が沈む前に — レント回収と交換可能性の勾配

連載「定額の裏側」第4回。コスト構造説(第2回)は価格差の土台を、認知吸収説(第3回)は補助金の理由を説明した。残る問いは「API はなぜあの高さで売れ続けるのか」。本稿の答えはこうだ——売れ続けない。売れ続けないことをラボ自身が知っているからこそ、今のうちに取っている。

当初の仮説:「機械に回されることへの恐怖」

私が最初に立てた仮説は「恐怖説」だった。エージェントに組み込まれると、モデルはユーザーから見えない部品になる。名前が消えることへの恐怖が、API への高価格(=組み込み利用への抑止)として現れているのではないか、と。

しかしこの定式化にはねじれがある。組み込まれることを本当に恐れるなら、合理的な手は API を安くして組み込み需要を独占することのはずだ。高くすれば競合に組み込み需要を譲るだけで、抑止にならない。

だから再定式化する。これは恐怖ではなく、沈む前のレント回収である。

named demand の消滅と回収のタイマー

前連載「フロンティアモデル包囲網」の影5で論じた構造をここで使う。エージェントの抽象化レイヤーが厚くなるほど、「どのモデルか」という指名(named demand)はユーザーの視界から沈んでいく。

今、API で Opus を指名して高い単価を払う開発者は、何に金を払っているのか。「このモデルでなければならない」という指名の確信にである。そしてこの確信には賞味期限がある。同格モデルの飽和(影2)とルーティング基盤の成熟が、指名を「設定ファイルの1行」に格下げしていくからだ。

ラボの視点に立てば、価格戦略は自明になる。**指名が効いているうちは、指名料を最大限取る。**コモディティ化したあとに値下げ競争で取れる利益は薄い。だから今の API 価格には、原価に加えて「named demand が残存している期間のレント」が乗っている。これは強欲ではなく、消えゆく資産の合理的な減価償却である。

交換可能性は一枚岩ではない — 勾配の構造

「とはいえモデルなんてもう交換可能でしょう」という声には、現場から半分だけ同意する。交換可能性はユーザーからの距離に比例する勾配として存在しているからだ。

エンドユーザー層:ほぼ完全に交換可能。 ルーティング基盤(OpenRouter 等)はモデル名を config の1行にした。難易度に応じて安いモデルと高いモデルを振り分けることで、公開ベンチマークでは大幅なコスト削減と品質維持が報告されている(RouteLLM 系の研究)。ユーザーは「どのモデルか」どころか「単一のモデルですらない」状態で使っている。

ツール層:ドロップダウン1つ。 Cursor も Cline も、モデル切替は UI 上の選択肢にすぎない。私の環境でも、Hermes Agent から見ればモデルはレーン設定の一項目であり、別途走らせている Claude Code でもモデルはコマンド一つで切り替わる。どちらの世界でも、名前はすでに設定値の階層に沈んでいる。

開発者層:まだ摩擦が残る。 ここが重要だ。エージェントを本気で運用している人間は、モデル交換が config 1行で済まないことを知っている。プロンプトの「方言」(同じ指示でも応答の癖が違う)、tool calling の挙動差、長文コンテキストでの劣化特性の違い、トークナイザの違いによる実効コスト差。私自身、Hermes のレーンでモデルを差し替えるたびに回帰テストで泣かされている。

そしてプロトコル層には皮肉がある。**MCP(Model Context Protocol)——Anthropic が提案・OSS 化し、のちに Linux Foundation 配下の Agentic AI Foundation へ寄贈された標準——は、ツール接続とコンテキスト供給を標準化することで、モデル固有の統合資産という moat を薄くする方向に働く。**規格の統一は、規格を作った者をも交換可能にする。寄贈によって標準が一社の手を離れたこと自体が、この方向性を一段押し進めている。

レント回収のタイマーとは、この勾配が時間とともに開発者側へ浸食していく速度のことだ。エンドユーザー層の交換可能性はすでにほぼ100%。残っているのは開発者層の摩擦だけであり、評価ツールとアダプタ技術の成熟がそれを削っていく。API の高価格が維持できるのは、この摩擦が残っている間だけである。

もう一つの壁 — 「そんなに高いなら使えない」

レント回収説には、供給側の論理だけでは閉じない穴がある。需要側の壁だ。しかもこの壁は、よく見ると二階建てになっている。

個人の実感から始めたい。私は、月額20ドルが2,000ドルになっても払うつもりでいた。フロンティアモデルが生む生産性を考えれば、それは合理的な支払い意思のはずだった。実際、私が産出するソフトウェアの生産性は本当に数十倍になった。——だが、生産性ほどには収入は増えなかった。払うほどには、増えないのだ。この実感の正体を分解すると、壁の二つの階が見えてくる。

一階の壁:組み込む側のユニットエコノミクス

その価格では、組み込む側のユニットエコノミクスが成立しないという壁である。

具体的に計算してみよう。リサーチ系エージェントが1タスクで5回のモデル呼び出しを連鎖させ、各呼び出しがコンテキスト込みで入力10万トークン・出力5千トークンだとする。ここでは Opus 4.5 以降の Opus 級($5/$25 per MTok)を例に取ると、1タスクあたり約 $3.1(為替145円/$なら約450円)。これを SaaS の機能として月10万タスク提供すれば、推論原価だけで月数千万円。ソフトウェア事業の生命線である粗利80〜90%の構造とはまったく両立しない。だから現場の応答は決まっている——「高いなら使わない」「安いモデルに逃がす」「機能ごと削る」。(なお Fable 5 / Mythos 5 級は $10/$50 と別価格帯であり、最上位を使えばこの壁はさらに高くなる。)

ここに構造的な皮肉がある。トークン需要の爆発的成長の本命はエージェント経済のはずなのに、その需要は価格に最も敏感なのだ。人間のサブスクユーザーは習慣で払う(第3回)。だがエージェントの呼び出し回数は純粋に経済計算で決まり、習慣もブランド忠誠も持たない。レントを乗せられる named demand と、量を運んでくる価格弾力的な需要が、別のセグメントにいる。

二階の壁:払う側の価値捕捉

一階のユニットエコノミクスをクリアしても、その上にもう一枚壁がある。冒頭の実感——生産性は数十倍、収入はそうならない——の構造だ。

生産性の向上は価値の創出であって、捕捉ではない。支払い原資になるのは捕捉のほうだけだ。そして市場価格は生産性ではなく競争で決まる。私の生産性が数十倍になったとき、同じ道具を持つ競合の生産性も上がっている。成果物の市場価格には下方圧力がかかり、生産性の果実の大半は、発注者と社会の側へ余剰として流れていく。人月ベース・予定価格ベースの値付けが残る日本の受託構造では、この力学はさらに増幅される——速く作れることが、請求可能額を減らす方向に働く値付け体系すらある。加えて、需要獲得側の律速段階(商談、入札日程、与信と実績の積み上げ)は、コーディング速度では加速しない。生産性は即時に上がるが、収入は遅延と分散を伴ってしか追いつかない。

帰結はこうだ。「$20が$2,000になっても払う」が成立するのは、ユーザーが追加で$2,000以上を捕捉できる場合だけである。ところがモデル自身が引き起こすデフレ——全員の生産性向上による成果物価格の低下——が、そのユーザーの捕捉を圧縮する。つまり高額プランの天井を決めるのは、ラボの原価でもモデルの能力でもなく、「顧客の顧客」の財布だ。ラボは、自分の製品が生む価格破壊によって、自分の値上げ余地を下流から削られている。蛇が自分の尾を食う構造である。

そしてこの二階建ての壁の内側に、ラボ自身もいる。データセンター・電力・チップに先行コミットされた投資額は、もはや「プレミアム価格 × 限定数量」で回収できる規模ではない。投資額に見合った売上を上げる方法は、量の側にしかない。つまりレント回収戦略は、続ければ続けるほど、自らの投資回収を不可能にしていく——レントの最大化と総収入の最大化が、ある点から先で背反する。

価格の実績がこの力学を裏書きしている。Opus 級の API 価格は、旧 Opus 4 / 4.1 の $15/$75 から、Opus 4.5 以降の $5/$25 へと短期間で約67%下がった。レートカードの推移そのものが、壁に押し返されてきた痕跡である。

だから本稿の結論をもう一段精密化する。恐怖説(第一次)→レント回収説(第二次)ときて、最終形は時限スキミング説だ。マーケティングの教科書にあるスキミングプライシング——指名買いが効く層から高く取り、需要の壁に当たるたびに段階的に値下げして量の市場へ降りていく——の軌道に、API 価格は綺麗に乗っている。今日の高価格は永続戦略ではなく、降りていくエスカレーターの現在位置である。そして降下速度を決めるのはラボの意思ではない。下流——組み込む事業者の粗利と、その先にいる「顧客の顧客」の捕捉力——である。

実務への含意 — モデル可搬性を設計要件に昇格させる

レント回収説を受け入れるなら、開発者側の合理的応答は一つしかない。ラボが「沈む前に取る」なら、こちらは「沈む前に可搬になる」。

API 価格が恣意的なレントを含むなら、その価格は将来も恣意的に動く(上にも下にも)。特定モデルの価格・規約・提供形態に自分のアーキテクチャを人質に取られない状態を、機能要件と同格の設計要件にする。具体的には:

1. プロンプトとツール定義をモデル非依存の形式で資産化する。 プロンプトをコードに埋め込まず、モデル別の方言差分(システムプロンプトの流儀、tool calling のスキーマ差)をテンプレート層で吸収する。資産はあくまで「意図の記述」であり、方言への翻訳は機械的にやる。

2. 自社評価セットを持つ。 これが可搬性の心臓部だ。自分の実タスクから抽出した数十〜数百件の回帰テスト(入力、期待される性質、自動判定ロジック)を持ち、新モデル・代替モデルに対して常時実行できる状態にしておく。「乗り換えられるか」を意見ではなく測定で答えられることが、ベンダーに対する唯一の交渉力である。ベンチマークの公開スコアは役に立たない。あなたのタスクはベンチマークに入っていない。

3. アダプタ層を一枚挟む。 モデル API への直接依存をコードベース全体に散らさない。Hermes ではゲートウェイがこの役割を担っている——Vault・Bot・Memory を束ねる結節点で、モデルの差し替えをレーン単位で隔離する。この一枚の有無が、乗り換えコストを「全面改修」と「設定変更+回帰テスト」に分ける。

4. 価格改定をイベントとして監視する。 モデルの価格・レート制限・規約は、依存ライブラリの脆弱性情報と同じ重みで監視対象に入れる。トークナイザ変更による実効コスト増(レート表は同じでも請求額が変わる)のような「静かな値上げ」も含めて。

5. ユニットエコノミクスを価格曲線の上で設計する。 時限スキミング説が正しいなら、価格は今後も段階的に下がる。だから「今日のレートで成立しない機能」は捨てるのではなく、いつ成立するかを計算して待ち行列に入れる。1タスクあたりの推論原価上限を要件として先に決め(検収条件と同格に)、現行レートで超過するなら、モデル階層の引き下げ・キャッシュ・バッチで届くか、届かないなら次の値下げ局面までペンディングか、を判定する。逆に、競合が「今日の価格では無理」と見送った機能は、次の値下げで真っ先に成立する空白地帯である。価格曲線を読むことは、ロードマップを読むことと同じだ。

可搬性はタダではない。アダプタ層と評価セットの維持には実コストがかかる。だがレント回収説が正しいなら、これは保険料として安い。勾配のどちら側に自分を置くか——交換する側か、交換される側の道連れか——は、設計で選べる。

次回は視点をラボ側の戦略に移す。「危険だから限定公開する」「開発を減速すべきだ」——あのナラティブ群を、経済の言葉で分解する。