トークンマクシング：なぜあなたのAIエージェントは、すでに知っていることを再学習するのに4倍払うのか

2025年12月、Uberは5,000人のエンジニアにClaude Codeを配り、その隣に「消費トークン数」でチームを順位付けするリーダーボードを設置しました。リーダーボードは、リーダーボードがいつもそうであるように、狙い通りに機能しました。そして4月には、2026年のAI予算がまるごと消えていたのです。12ヶ月計画の、わずか4ヶ月目のことでした。

ですが、よく見てみると、その支出の多くは新しい思考を買っていませんでした。買っていたのは同じ思考の繰り返しです。エージェントが同じファイルを読み直し、昨日すでに知っていたことを再導出し、そして次のセッションではまた忘れる。知性はループの中でぐるぐる回っていました。そして請求額は、莫大でした。

この振る舞いには名前があります。トークンマクシング（tokenmaxxing） — AIモデルの利用量をできるだけ増やす、あるいは少なくとも生産的に見える程度に「見える化」する、という行動です。エージェントのループを増やし、コンテキストウィンドウを重くし、コーディングアシスタントへの呼び出しを増やす。

トークンは正当なテレメトリ（入力・出力・キャッシュ・推論）であり、コストやシステムの分析には本当に役立ちます。問題が始まるのは、消費量そのものがスコアボードになったときです。なぜならその瞬間、チームは2倍のコストをかけて、まったく同じプロダクトを出荷できてしまうからです。

そこで業界は、恥ずかしいトレンドに対して業界がいつもやることをやりました。「そのトレンドは終わった」と宣言したのです。Forbesは「tokenmaxxingは終わった」と言い、Fortuneは追悼記事を掲載しました。力任せのトークン浪費が行き止まりである、という点では両者とも正しい。

しかし、あの請求書を前にしたCTOが本当に抱えている問いには、どちらも答えていません。すなわち、「エージェントが、すでに知っていることを再学習するために払い続けているのが問題なら、代わりに何を作ればいいのか？」

答えは、より賢いプロンプトでも、より安いモデルでもありません。答えは、記憶するアーキテクチャです。そしてDevRevには、それがどれだけの価値を持つかを示すベンチマークの数字があります。

TLDR（要点）

• トークンマクシング（tokenmaxxing）とは、AIモデルの利用量を最大化すること — より長いプロンプト、より多くのエージェントループ、より重いコンテキストウィンドウ — を指し、しばしば「生産性の見える化」のシグナルとして使われます。問題は、その利用量のほとんどが、知性ではなくコンテキストの再構築を買っている点です。
• 無駄はプロンプトにあるのではなく、検索ループ（fetch → chunk → embed → retrieve → stuff → reason → forget → 繰り返し）の中にあります。
• 解決策はアーキテクチャにあります。永続的な構造化メモリが、検索ループそのものを丸ごと不要にします。
• DevRevの Enterprise-Bench による評価では、構造化メモリ型エージェントが、同一モデルのfetch型エージェントに対し、1回答あたり 94.3% の精度を、約4.4倍 少ないトークンで達成しました。
• 最も安いトークンは、そもそも使わなかったトークンです。

なぜ力任せのtokenmaxxingは失敗するのか？

トークンは、チームがAIを使っているかを確認する指標にはなります。「入力を測る指標としては優れているが、出力や成果を測る指標としては優れていない」と、DevRev共同創業者兼CEOのDheeraj Pandeyは言います。

AnalyticsWeekの2026年インファレンス経済レポートによると、企業のAI予算は2024年から2026年にかけて年間120万ドルから700万ドルへと拡大しました。出典は AnalyticsWeekの2026 Inference Economics レポート です。483%の増加 — それにもかかわらず、大半の組織はAIの出力品質がそれに比例して向上したとは報告していません。このギャップこそ、AIコスト最適化が財務の脚注から取締役会の議題へと格上げされた理由です。

fetch型のAIエージェントがクエリを処理するたびに、次のことが起こります。

1. Fetch（取得） — バラバラのシステムから生データを引き出す
2. Chunk（分割） — 扱いやすい断片に分ける
3. Embed（埋め込み） — ベクトル表現に変換する
4. Retrieve（検索） — 数千もの断片に対して類似検索を実行する
5. Stuff（詰め込み） — 上位の結果をコンテキストウィンドウに押し込む
6. Reason（推論） — ようやく、モデルが考える
7. Forget（忘却） — セッションが終わり、コンテキストは蒸発し、ステップ1から繰り返す

どのステップもトークンを消費します。実際に知性を生み出す唯一のステップ（ステップ6）よりも、ステップ1〜5の方が多くを消費するのが通常です。「返金はどこ？」という問い合わせに100回目の対応をするサポートエージェントを想像してみてください。

顧客レコードを再取得し、注文履歴を再び埋め込み、50個のポリシー断片を再ランキングし、それらすべてをウィンドウに詰め込んだうえで、モデルは昨日書けたはずの2行の返信を書く。この回答に数千トークンかかります。

1クエリのトークンコストは些細に見えますが、スケールを掛け合わせるとコストは深刻になります。Gartnerは2026年3月のインファレンス経済予測で、エージェント型AIモデルは標準的なチャットボットに比べてタスクあたり5〜30倍のトークンを必要とすると指摘しました。本番規模では、これが積み重なり、月間で数千万ドル規模の請求になります。

このパターンは特定のシステムに固有のものではありません。しかしDevRevはそれを数字にしました。Enterprise-Benchでは、データセットが大きくなるにつれてfetch型エージェントのトークンコストは29%上昇し、しかも精度は上がりませんでした。より多くのノイズに埋もれた同じ答えを見つけるために、より多くをコンテキストに引き込み続けたのです。

デモ規模では、あるタスクに関連するデータは全体の40%ですが、本番規模ではわずか0.16%です。問い自体が難しくなるわけではありません。難しくなるのは、増え続けるノイズの海の中から正しい答えを見つけることであり、fetch型エージェントは余分な走査のたびにトークンで支払うことになります。

プロンプト最適化の代わりになるものは何か？

解決策は、より大きなコンテキストウィンドウでも、より安いモデルでもありません。使い捨ての検索ではなく、永続的な構造化メモリの上に築かれた「すでに知っているシステム」です。

クエリのたびに1万個のドキュメント断片を処理・埋め込み・検索する代わりに、取り込み時に関係性を一度だけ構造化します。

正しく実装すれば、これこそが AIナレッジマネジメント が本来もたらすべきもの — システムがエンティティと関係性を毎回発見し直すのではなく認識する、ナレッジグラフ vs ベクターデータベース というアプローチです。

多くの実装は、これを関係性のアーキテクチャではなくドキュメントストレージとして扱ってしまい、要点を外しています。

隣接する動き — valuemaxxing（Forbes とNebius CROのMarc Boroditskyが提唱）と tokenminning（Towards Data Science）— はいずれも同じ方向を指しています。入力量を測るのをやめ、出力価値を測り始めよ、と。

しかしどちらも、そのアーキテクチャ上のメカニズムを名指ししていません。そのメカニズムこそが、永続的で構造化されたメモリ — チーム・顧客・プロダクト・コードにまたがる事前計算済みの関係性を保持する、生きたナレッジグラフです。

Computer Memory（by DevRev）がこれを解決します。これは、コンテキストを取得して再構築するのではなく、認識するナレッジグラフです。この一語の違いが、勝負のすべてです。検索（Retrieval）はクエリのたびに必要なものを再構築します — 高コストで、反復的で、欠損を伴う。認識（Recognition）はすでに保持しているものを想起します — 安価で、永続的で、正確です。

メモリアーキテクチャはトークンコストをどれだけ削減できるのか？

これを誠実に検証するため、DevRevは Enterprise-Bench を構築しました。正解を固定したまま、その周囲のデータをデモ規模から成熟した企業の規模へと（256倍まで）スケールさせる評価です。同じモデルファミリー、同じデータ、同じ質問で動く2つのエージェント。唯一の変数は、それぞれがどうやってデータに到達するか。一方は構造化メモリ層を通り、もう一方はfetch型のツール呼び出しを通ります。

出典: Enterprise-Bench, DevRev。

構造化メモリは、精度を効率と引き換えにするのではありません。両方を同時に向上させます。効率は1回答あたりのトークン数を減らすことから生まれ、精度は、1万個の断片の中から関連するものを1つ引き当てることを期待するのではなく、必要なものだけをモデルが推論することから生まれます。

これはアーキテクチャの転換です。システムが事前計算済みの関係性を持つ生きたナレッジグラフを維持していれば、大半の「検索」は、直接のグラフ走査またはSQLクエリへと縮約されます。

しかし、最も印象的な数字はトークン差ではありません。インターフェースに関する発見です。

エージェントを厳選されたツールから現実的なAPIサーフェスへ移すと、精度は18〜19ポイント低下しました。一方、モデルのバージョンを上げても、精度はわずか1ポイントしか動きませんでした。Enterprise-Benchの言葉を借りれば、「検索アーキテクチャは、基盤モデルの選択よりも本番性能の強い予測因子である」。

AIベンダーを選ぶ決め手であるモデルは、ほとんどの買い手が決して問わないもの — それがどうやってあなたのデータに到達するか — よりも重要ではないのです。

LLMコスト最適化戦略を評価するチームにとって、優先順位は明快です。プロンプトの小技は端をわずかに削り、モデルルーティングは役に立ちます。しかし、データの増加に伴って曲線そのものを曲げられる唯一のレバーは、アーキテクチャです。

Computerが実際のワークロードを14日で解決する様子をご覧ください → デモを予約する

本番環境における本当のtokenmaxxingとはどのようなものか？

アーキテクチャを正すことで得られるのは、請求額の縮小だけではありません。本番環境との接触を生き延びるエージェントが手に入ります。いまだにプロンプトを調整し続けているチームは、支えるべき売上より速くトークン請求が膨らむ中で、デッキチェアの配置を最適化しているようなものです。

では、メモリファースト版は実際にはどのようなものか？ 4つの層があり、それぞれが異なる種類の無駄なトークンを消していきます。

各段階は、無駄の中で最適化するのではなく、無駄のクラスそのものを消し去ります。段階1は再取り込みを、段階2は再計算を、段階3は過剰検索を、段階4はセッションごとの記憶喪失を消します。

このアーキテクチャが Computer Agent Studio を実現します。記憶するエージェントを作り、数分でデプロイする。これこそが、デモで感心されるだけのプロトタイプと、本番で20万件の実クエリを解決するシステムとを分けるものです — まさに BILLの実績 が70%の自律解決率で示している通りです。