第1回：Token Economy時代の指標、VOI・KOI — 1ドルあたりの成果を最大化するAIの手法

企業の社内業務やプロダクトへの大規模言語モデル（LLM）の実装が進むにつれ、多くの CIO や CFO が共通の課題に直面しています。制御しきれない「インフラコストの増大」です。

社内で誰も見返さない単純なメール要約や文書検索に、最高峰・最高価格のフロンティアモデルを使い続けてしまう現象は、いまや「Tokenmaxxing（トークン過剰消費）」という言葉を生むほど広がっています。AI の利用量そのものを「生産性の指標」と捉えてしまう組織文化は、かつて IT 業界がエンジニアの評価を書いたコードの行数（Lines of Code = LOC）で測り、冗長なコードを増やしてしまった歴史とよく似ています。

本稿では、報道や国内外の実態をもとに、Tokenmaxxing がもたらす経営リスク、その第一防衛線として広がる「モデルルーター」の現状、そしてその先にある成果駆動型の最適化について考察します。

1. 「Tokenmaxxing」が生み出している実態

自社の AI コストや用途を正確に把握できている企業は、現状で全体の 10% 未満にとどまると見られています。現場では、インフラ予算の超過や評価ルールの回避がすでに起きています。

事例	何が起きたか	数字で見ると
Meta「Claudeonomics」の閉鎖	従業員が手作りした「外部モデルを誰が一番使ったか」を競うリーダーボードが社内に存在。スコア稼ぎのために AI エージェントへ微細な修正を大量生成させる行為が起き、報道を受けてダッシュボードは閉鎖された。	全社で30日間に約 60〜73.7 兆トークンを消費。個人1位は30日間で約 2,000 万ドル（約27億円）相当を消費。
Uber の予算超過	自律型コーディングツールの利用が急増し、通年の AI 予算を最初の数ヶ月で使い切った。放置されたエージェントがクエリを再実行し続け、無自覚にトークンを消費していた。	バックエンドのコード変更の 11% を AI エージェントが自律実行するまでに拡大。
ベンチャーキャピタルの実例	あるVCがスタッフ5人に上位アカウントを付与したところ、メール返信や要約といった単純作業に最高峰モデルを使い続けた。	5人だけで月間 1,500 万円を超えるペースの請求が発生。

Meta の事例は、消費量の桁がイメージしにくいため数字を整理しておきます。

Meta「Claudeonomics」閉鎖直前の30日間
全社の消費量と、個人1位の消費額

73.7兆

消費トークン数（30日・全社）

約2,000万ドル

個人1位の消費額（30日）

<10%

コストを把握できている企業

ここで起きているのは、かつて LOC やコミット数を評価指標にした結果、品質ではなく「行数」や「コミット数」を増やす行動が生まれたのと同じ構図です。指標が目標になると、指標そのものが壊れる。グッドハートの法則がそのまま当てはまります。

「Tokenminimizing（トークン削減）」への急旋回

こうした従量課金への懸念から、企業は厳格な利用制限やアクセス上限（ガバナンス）を設定し始めています。

企業・業種	取った対策
AT&T / Zscaler	予算圧迫への懸念から特定の開発ツールへのアクセスを一時遮断。法務やマーケティングには安価な軽量モデルのみを割り当てる職種別ガバナンスを徹底。
米航空宇宙・防衛大手	従業員1人あたり月額 250 ドルのハードキャップを導入。パワーユーザーが最初の4日間で枠を使い切ったため、システム側で最上位モデルへのアクセスを強制的にオフに設定。
大手航空会社	トークンの割り当てを特定の「プロジェクト」と「そのプロジェクトの予想収益」に直接紐付け、財務チームがインフラコストとして管理。

さらに製薬大手のノボノルディスクのように、過去の臨床試験データを LLM で分析した際、AI 機能のない標準の Microsoft Excel で処理した方が安価で信頼性も高いと判断し、現実的な運用へ戻す動きも出ています。「Excel の方が良い結果を出せるなら、Excel に留まるべきだ」という考え方です。

2. 第1の防衛線：「モデルルーター」の台頭

この財務的なリスクを抑える仕組みとして、現在広がっているのが「モデルルーター（Model Routers）」です。

ユーザーにモデルを選ばせるのではなく、入力（プロンプト）の複雑さやタスクの種類を分類器でリアルタイムに評価し、それを処理できる「最小かつ最安のモデル」へ自動で振り分けます。

flowchart LR
    U["リクエスト<br/>（プロンプト）"] --> C{"分類器<br/>複雑さ・種類を評価"}
    C -->|単純なタスク| S["軽量・低価格モデル"]
    C -->|中程度のタスク| M["中位モデル"]
    C -->|高度なタスク| L["最上位モデル"]
    classDef s fill:#dcfce7,stroke:#16a34a,stroke-width:2px;
    classDef m fill:#fef9c3,stroke:#ca8a04,stroke-width:2px;
    classDef l fill:#fee2e2,stroke:#dc2626,stroke-width:2px;
    class S s;
    class M m;
    class L l;

主要プレイヤーのルーティング手法と導入実績

企業・サービス	特徴とルーティングの仕組み	コスト削減・運用のスタッツ
Palantir（Evolve）	複数プロバイダーを横断。ルーター切り替えだけでなく、トークンの重複消費を防ぐプロンプト調整も自動化。	重量級から小型 Nano モデルへ自動切り替えし、計算コストを 97% 削減。顧客の建設会社では全体のトークン消費を 60% 削減。
OpenRouter / Not Diamond	コスト重視か品質重視かを10段階で設定可能。裏側で Not Diamond の予測エンジンを採用。	動的選択の統計では、安価な Gemini Flash 系が約 33% を占め、最上位モデルの呼び出しは 10% に抑制。
Sakana AI	複数の AI モデルをリアルタイムに協調・切り替えするシステム。	数学は特定モデル、科学は Google 系へルーティングし、低コストで最高峰のフロンティアモデルに並ぶ性能を実現。
Databricks（Unity AI Gateway）	予算監視・アクセス制御を行うゲートウェイ。	アリ・ゴドシ CEO が「予算を使い切りそうな大企業の間で非常に人気がある」と言及。
Cognition（Devin）	タスクの難易度に応じて最適な AI エージェントへ業務を自動分配するルーターを内蔵。	バグチェックなどの単純作業には最上位モデルの約100分の1のコストで動く自社特化モデルを適用し、コストを 35% 削減。

各社が公表している削減率を並べると、ルーティングによる効果の大きさが見えてきます。

ルーティング／モデル切り替えによるコスト削減率（各社公表値）

Cognition（自社特化モデルへ）35%

Palantir 顧客（トークン消費）60%

Palantir（重量級→Nano の計算コスト）97%

中国製OSSへの切り替え（AI予算）99%

※ 対象・測定条件は各社で異なるため、削減率の単純比較はできません。あくまで規模感の目安です。

中国製オープンソースモデルへのシフトと「AI 金融市場」の誕生

足元では、米国製クローズドモデルの高いコストを避け、コストパフォーマンスに優れる中国製オープンソースモデル（アリババの Qwen や DeepSeek など）へリクエストを振り替えることで、AI 予算を100分の1（99% 削減）に圧縮する動きが増えています。

この移動を受けて、オープンソース AI のホスティングを行う Together AI は月間処理トークン数が数ヶ月で大幅に増加し、年商換算売上は10億ドルを突破。Fireworks AI や Runpod といったインフラ事業を行う企業にも投資が集まっています。

さらに、ブラックボックス化しがちな AI プロバイダーの請求に対し、インフラの可視化とヘッジを行う金融の仕組みも生まれ始めています。主要モデル価格を実際の取引量で加重平均して追跡する「Ornn Token Price Indices」のローンチや、シカゴ・マーカンタイル取引所（CME）などによる「計算力先物市場（Compute Futures）」の開発など、AI インフラの金融化が進んでいます。

3. 現行ルーティングが抱える「盲点」

ここで、現在主流のモデルルーターには、ビジネス運用上の重要な見落としがあります。

それは、モデルルーターがプロンプト（入力）の形にだけ最適化しており、その出力がもたらす成果（KPI）の価値には最適化していないという点です。

入力の複雑さと、ビジネス上の価値は、必ずしも一致しません。この2軸で整理すると、現行ルーターが取りこぼす領域が見えてきます。

入力の複雑さ × ビジネス価値のマトリクス

プロンプトは単純

プロンプトは複雑

価値：高い

ケースA
短い要約でも経営判断に直結。
現行ルーターは軽量モデルへ回すが、本来は最上位モデルや複数モデル検証が必要。

複雑かつ重要。
最上位モデルの投入が妥当。
ルーターの判断と価値が一致する。

価値：低い

単純かつ低価値。
軽量モデルで十分。
ルーターの判断と価値が一致する。

ケースB
長文だが誰も見返さない備忘録。
現行ルーターは高価格モデルへ回すが、軽量モデルやローカルSLMで十分。

対角線（左下・右上）では、現行ルーターの判断とビジネス価値が一致します。しかし、もう一方の対角線でミスマッチが起きます。

ケースA：プロンプトは単純だが、失敗が許されない業務。「この進捗データを1行にまとめて」という短いプロンプトでも、その1行が数億円規模のプロジェクトの意思決定に使われるなら、わずかな誤りも許されません。コストをかけてでも最上位モデルや複数モデルによる検証を行うべき場面です。しかし現行ルーターは「単純」と見なして最安モデルへ回します。
**ケースB：プロンプトは複雑で長文だが、ビジネス価値が低い業務。**大量の社内文書を読み込ませた複雑な問い合わせでも、それが「誰も見返さない社内メモの誤字チェック」であれば、どれだけ長文でも軽量モデルやローカル SLM で十分です。しかし現行ルーターは「高度な思考が必要」と判断して高価格モデルへ回します。

入力の複雑さ（トークン長やプロンプトの難易度）だけを基準にしている限り、AI の投資対効果（ROI）を最大化することはできません。「そのタスクがどれだけビジネスの成果（KPI）に寄与するか」を基準にしたルーティングへの移行が必要だと考えています。

4. 「入力駆動型」から「成果駆動型」への進化

現在のモデルルーターは、主に次のように考えます。

flowchart TB
    subgraph IN["入力駆動型（現行）"]
      direction TB
      A1["このプロンプトは難しいか？"] --> A2["どのモデルなら処理できるか？"] --> A3["一番安く十分な品質を出すのは？"]
    end
    subgraph OUT["成果駆動型（次の段階）"]
      direction TB
      B1["このタスクはどのKPIに効くか？"] --> B2["そのKPIに必要な品質はどれだけか？"] --> B3["その品質を満たす中で1ドルあたり最も成果を出すのは？"]
    end
    IN -.進化.-> OUT
    classDef in fill:#e0e7ff,stroke:#4f46e5,stroke-width:1.5px;
    classDef out fill:#dcfce7,stroke:#16a34a,stroke-width:1.5px;
    class A1,A2,A3 in;
    class B1,B2,B3 out;

入力駆動型は正しい方向です。しかし次の段階へ進むには、モデルを選ぶ前に立てる問いそのものを見直す必要があります。

ここで重要なのは、単なるコスト削減ではありません。AI コストを下げること自体が目的になると、品質まで落としてしまう危険があります。一方で品質だけを追いかけると、すべてが高価格モデルに流れ、Tokenmaxxing に戻ってしまいます。

見るべきなのは、次の比率です。

\text{成果} \div \text{コスト}

AI に使った1ドルが、どれだけの品質や KPI 改善を生んだのか。この比率を見なければ、AI の本当の投資対効果は測れません。

5. VOI、KOI、そして Nishiki

この課題に対して私が提案しているのが、VOI（Value on Investment） と KOI（KPI on Investment） という考え方です。そしてそれを実装するのが、Nishiki というオープンソースのツールです。

flowchart LR
    VOI["VOI（何を目指すか）<br/>AI投資を金額ではなく<br/>価値で測る"]
    KOI["KOI（どう測るか）<br/>KPI ÷ コスト"]
    NISHIKI["Nishiki（何で測るか）<br/>実データでモデル候補を測定し<br/>最適な経路を選ぶ"]
    VOI --> KOI --> NISHIKI
    classDef a fill:#e0e7ff,stroke:#4f46e5,stroke-width:2px;
    classDef b fill:#fef9c3,stroke:#ca8a04,stroke-width:2px;
    classDef c fill:#dcfce7,stroke:#16a34a,stroke-width:2px;
    class VOI a;
    class KOI b;
    class NISHIKI c;

VOI：Value on Investment

VOI は、AI への投資を単なるコストではなく、価値で測るという考え方です。

100万トークンを使ったから価値があるのではありません。高いモデルを使ったから価値があるのでもありません。重要なのは、その AI 出力が何を生んだのかです。正答率が上がったのか。人間の確認時間が減ったのか。問い合わせ対応が速くなったのか。売上、継続率、ミス削減、審査速度、照合精度など、実際の KPI にどう効いたのか。必要なのは、トークン数ではなく、価値を測る物差しです。

KOI：KPI on Investment

KOI は、VOI を実務で測れる形に落とし込んだ指標です。

\text{KOI} = \frac{\text{KPI}}{\text{Cost}}

つまり、AI にかかったコストに対して、どれだけ KPI を達成できたかを測ります。ROI が「投資対効果（Return on Investment）」を表すのに対し、KOI は Return の位置に KPI を置いたものです。

ただし重要なのは、安いモデルを無条件に選ぶことではありません。Nishiki では、必ず品質フロア（最低品質ライン）を置きます。

タスク	品質フロアの例
財務書類の照合	人間の最終判定との一致率が一定以上でなければ候補から外す
契約書の抽出	F1 スコアが一定水準を下回るモデルは使わない
問い合わせ分類	誤分類率が許容範囲を超えるモデルは除外する

そのうえで、品質フロアを超えた候補の中から、最も KOI の高い経路を選びます。これにより、品質を守りながら、1ドルあたりの成果を最大化することができます。

6. Nishiki が目指す「成果連動型モデルルーティング」

Nishiki は、AI・LLM エージェントのソースコードを読み込み、実データに基づいて「1ドルあたりの品質・費用対効果」を測定・最適化する OSS です。

既存の AI エージェントに対して、Nishiki は次のような問いに答えます。

いまのモデル構成は、本当に費用対効果が高いのか
品質を落とさずに、どこまで安いモデルへ置き換えられるのか
どのモデルが、1ドルあたり最大の KPI を出しているのか
どのタスクには高性能モデルを使うべきで、どのタスクは軽量モデルで十分なのか

実測例

Nishiki を使った2つの測定結果を紹介します（詳細はNishiki のプロジェクト記事を参照してください）。

測定対象	現状	Nishiki が見つけた経路
抽出タスク（軽量・数分で再現可能）	フロンティアモデルが品質1位（F1 0.94）だが、1ドルあたりの価値は最下位	DeepSeek がその品質の 84% を約 1/117 のコストで達成。1ドルあたり約 100 倍の品質。
財務照合エージェント（実運用・Bedrock・50件）	現行のマルチモデル構成は KOI 28	同等以上の品質を保ちつつ累積コストを 73% 削減し、KOI を 3.8〜4.3 倍に改善。

財務照合エージェントでの改善（実運用・50件）

−73%

累積コスト削減（品質は同等以上）

3.8〜4.3倍

KOI（1ドルあたりの成果）の改善

現在のモデルルーターは、主にプロンプトの内容を見てモデルを選びます。Nishiki が目指しているのは、その次の段階です。つまり、プロンプトに対して最適なモデルを選ぶのではなく、KPI に対して最適なモデルを選ぶということです。

入力の難易度ではなく、成果への寄与度を見る。トークン数ではなく、1ドルあたりの KPI を見る。コスト削減ではなく、成果あたりのコスト最適化を見る。ここに、Tokenmaxxing 時代の次の AI インフラの方向性があると考えています。

結論

Tokenmaxxing の本当の問題は、AI の使用量は測れているのに、その AI が生んだ価値を測れていないことです。

モデルルーターは、この問題に対する重要な第一歩です。無駄に高いモデルを使わず、タスクに応じて最小限のモデルへ振り分けることで、AI コストの増大を抑えられます。しかし、それだけではまだ十分ではありません。

次に必要なのは、入力の複雑さではなく、出力がもたらす成果に基づいたルーティングです。AI コストに対して、どれだけ価値を生み出せたのか。AI コストに対して、どれだけ KPI を改善できたのか。その問いに答えるために、VOI、KOI、そして Nishiki という考え方が必要になると考えています。

Tokenmaxxing への対抗策は、AI を使わないことでも、単に安いモデルへ逃げることでもありません。必要なのは、AI を、成果に対して正しく使うことです。

Nishiki は、そのための実験的な OSS として開発しています。ご興味がある方はGitHub リポジトリ（matu79go/nishiki）をご参照ください。