10月24日、Ashish Nainwalが「AI tokenomics: Balancing open-weight and frontier models for optimal ROI」と題した記事を公開した。オープンウェイトモデルとフロンティアモデルを使い分ける「AIトークノミクス」の設計によってROIを最大化する方法を、5年間のTCO試算を含めて解説している。
「全席ファーストクラス」のAI戦略が機能しない理由
記事の冒頭でAshishが使うたとえが核心を突いている。航空会社がなぜ全席ファーストクラスの機材を飛ばさないかを考えれば、AIコスト問題の構造は一瞬で理解できる。
銀行口座の残高照会も、マルチエージェントによる不正調査も、同じ「フロンティアモデル」に投げている企業はいまも多い。トークン単価は同じ。つまりすべての処理が「ファーストクラス席」を使っている状態だ。
解決策はシンプルだ。リクエストをタスクの複雑さに応じて分類し、適切なモデルに振り分ける（ルーティング）。それを単一のコントロールプレーン（AIゲートウェイ）で制御する。記事はこの設計思想を「AI tokenomics」と呼び、フロンティアモデル一択では5年スパンのTCOが最適化されない理由を具体的な数字で示している。
なぜ今オープンウェイトモデルなのか
4年前であれば「安い代わりに性能が足りない」という批判は正当だった。だが状況は変わった。記事はトークン市場価格の下落傾向を指摘しており、フロンティアモデルへの競争圧力が実際の価格に表れていると論じている。
モデル性能についても記事は具体的に整理している：
- 8Bパラメータクラス：分類・抽出・通常チャット → ユーザーがフロンティアとの差を体感しにくいレベル
- 30B〜120Bクラス：ドメイン推論 → 以前はフロンティアが必要だった領域をカバー
- フロンティア：複雑なマルチエージェントワークフロー → ここだけに予算を集中させる
つまり、「フロンティアが必要な処理」は想定より狭い。多くのユースケースは軽量なオープンウェイトモデルで十分な品質を達成できるという主張が、記事全体の前提になっている。
「安くなっているのに請求額が増える」逆説
トークン単価が下がっているのに、エンタープライズのAI支出は四半期ごとに増え続けている。この逆説の説明が記事の重要なパートだ。
記事によれば、Googleのトークン処理量は2024年5月の9.7兆/月から2025年5月には約480兆/月、さらに2026年5月には3.2京（quadrillion）/月超へと推移している。銀行の事例も示されている。Bank of AmericaのEricaは累計30億インタラクションを超え、Wells FargoのFargoは2024年だけで2億4,540万インタラクション（自社予測の2倍超）を記録した。
さらにエージェントAIがこの傾向を加速させる。従来は「1リクエスト＝1モデル呼び出し」だったが、エージェントはリクエストをステップ分解し、各ステップでモデルを呼び、失敗したら再試行する。トークン単価が半減しても、呼び出し回数が乗数的に増えれば総コストは上がる。「ルーティングが本当のレバー」という主張の根拠がここにある。
単価の議論だけを見ていると、この構造的なコスト増を見落とす。記事が「モデル選定よりルーティング設計が先」と主張するのは、この文脈においてだ。
実際のTCO試算：前提条件と結果
記事が公開しているモデリングの前提を整理する。
リクエスト分類（4ティア）
| ティア | 代表的ユースケース | トークン/リクエスト |
|---|---|---|
| Easy | 残高照会、社内チャットボット | 1,000 |
| Medium | クレーム分類、文書抽出 | 5,000 |
| Hard | AML調査、クレジットリスク | 8,000 |
| Complex | マルチエージェントワークフロー | 10,000 |
参照シナリオ：月間2,000万リクエスト、ティア比率は30/30/20/20、YoY成長率20%、5年間で約9兆トークン。GPU利用率は75%で計算。
試算結果（方向性として）
- フロンティアAPIのみ：5年間でトークン費用がほぼ倍増（成長率20%適用）。DLP・監査ツールのコストは別途。
- オンプレミス・オープンウェイトのみ：初期コストは重いが、その後フラット。最上位フロンティアモデル比で約80%削減、中位モデル比で約70%削減。
- ハイブリッド構成（Easy/Medium/Hardはオンプレミスでオープンウェイトモデルへルーティング、Complexのみフロンティア）：5年間TCOで約89%削減が最も効果が高く、段階移行できるため現実的。
なお、試算にはすべて約40%の誤差マージンが含まれており、記事も「自社のテレメトリで検証せよ」と明言している。この数字はあくまで設計判断の出発点であり、自社の処理分布やインフラコストによって結果は大きく変わりうる。
タイトルで「失敗する理由」と表現しているのは、この試算の裏返しだ。フロンティア一択のまま成長率20%の処理増に対応し続けた場合、5年後のコスト構造がハイブリッド構成と比較して最大89%分だけ非効率になりうる、という意味であり、記事の主眼はその非効率を避けるための設計論にある。
ガバナンスの観点：測定しないものはコントロールできない
記事が強調するもう一つの論点が規制対応だ。SR 26-2（米連邦準備制度による金融機関のモデルリスク管理ガイダンス）の下では、ベンダー提供モデルも内製モデルと同等のバリデーション義務を負う。「ベンダーが保証している」では監査対応にならない。
オープンウェイトモデルであればウェイトと評価履歴を自社で保持できる。サイレントアップデートもなく、ベンダーの都合によるAPIの廃止スケジュールにも左右されない。バージョン管理はガバナンスの問題であると同時に、再検証コストを避ける実務的なメリットでもある。
コスト削減の文脈で語られることが多いオープンウェイトモデルの採用だが、記事はこのガバナンス面を同等に重視している点で、単なるコスト最適化論にとどまらない視点を提供している。
詳細はAI tokenomics: Balancing open-weight and frontier models for optimal ROIを参照していただきたい。
