--- Title: "トークンマクシング：なぜあなたのAIエージェントは、すでに知っていることを再学習するのに4倍払うのか" Url: "https://devrev.ai/blog/tokenmaxxing" Last Updated: "2026-07-21" Author: "Nivedita Bharathi" Excerpt: "消費トークン数を生産性のシグナルとする「トークンマクシング（tokenmaxxing）」は終わった。だがアーキテクチャの問題は残る — AIエージェントはクエリのたびにコンテキストをゼロから再構築する。メモリファースト・アーキテクチャがトークン浪費を95%削る仕組みを解説。" Reading Time: 4 --- # トークンマクシング：なぜあなたのAIエージェントは、すでに知っていることを再学習するのに4倍払うのか 2025年12月、Uberは5,000人のエンジニアにClaude Codeを配り、その隣に「消費トークン数」でチームを順位付けするリーダーボードを設置しました。リーダーボードは、リーダーボードがいつもそうであるように、狙い通りに機能しました。そして4月には、[2026年のAI予算がまるごと消えていた](https://www.forbes.com/sites/janakirammsv/2026/05/17/uber-burns-its-2026-ai-budget-in-four-months-on-claude-code/)のです。12ヶ月計画の、わずか4ヶ月目のことでした。 ですが、よく見てみると、その支出の多くは新しい思考を買っていませんでした。買っていたのは同じ思考の繰り返しです。エージェントが同じファイルを読み直し、昨日すでに知っていたことを再導出し、そして次のセッションではまた忘れる。知性はループの中でぐるぐる回っていました。そして請求額は、莫大でした。 この振る舞いには名前があります。**トークンマクシング（tokenmaxxing）** — AIモデルの利用量をできるだけ増やす、あるいは少なくとも生産的に見える程度に「見える化」する、という行動です。エージェントのループを増やし、コンテキストウィンドウを重くし、コーディングアシスタントへの呼び出しを増やす。 トークンは正当なテレメトリ（入力・出力・キャッシュ・推論）であり、コストやシステムの分析には本当に役立ちます。問題が始まるのは、消費量そのものがスコアボードになったときです。なぜならその瞬間、チームは2倍のコストをかけて、まったく同じプロダクトを出荷できてしまうからです。 そこで業界は、恥ずかしいトレンドに対して業界がいつもやることをやりました。「そのトレンドは終わった」と宣言したのです。[Forbesは「tokenmaxxingは終わった」と言い](https://www.forbes.com/sites/timkeary/2026/06/02/why-tokenmaxxing-is-out-and-valuemaxxing-is-in/)、[Fortuneは追悼記事を掲載しました](https://fortune.com/2026/05/28/tokenmaxxing-is-dead-companies-didnt-get-the-roi-from-ai-they-wanted-to-see/)。力任せのトークン浪費が行き止まりである、という点では両者とも正しい。 しかし、あの請求書を前にしたCTOが本当に抱えている問いには、どちらも答えていません。すなわち、**「エージェントが、すでに知っていることを再学習するために払い続けているのが問題なら、代わりに何を作ればいいのか？」** 答えは、より賢いプロンプトでも、より安いモデルでもありません。答えは、記憶するアーキテクチャです。そしてDevRevには、それがどれだけの価値を持つかを示すベンチマークの数字があります。 ## **TLDR（要点）** - **トークンマクシング（tokenmaxxing）**とは、AIモデルの利用量を最大化すること — より長いプロンプト、より多くのエージェントループ、より重いコンテキストウィンドウ — を指し、しばしば「生産性の見える化」のシグナルとして使われます。問題は、その利用量のほとんどが、知性ではなくコンテキストの再構築を買っている点です。 - 無駄はプロンプトにあるのではなく、検索ループ（fetch → chunk → embed → retrieve → stuff → reason → forget → 繰り返し）の中にあります。 - 解決策はアーキテクチャにあります。永続的な構造化メモリが、検索ループそのものを丸ごと不要にします。 - DevRevの [Enterprise-Bench](https://devrev.ai/blog/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 レポート](https://oplexa.com/ai-inference-cost-crisis-2026/) です。483%の増加 — それにもかかわらず、大半の組織はAIの出力品質がそれに比例して向上したとは報告していません。このギャップこそ、AIコスト最適化が財務の脚注から取締役会の議題へと格上げされた理由です。 fetch型のAIエージェントがクエリを処理するたびに、次のことが起こります。 1. **Fetch（取得）** — バラバラのシステムから生データを引き出す 2. **Chunk（分割）** — 扱いやすい断片に分ける 3. **Embed（埋め込み）** — ベクトル表現に変換する 4. **Retrieve（検索）** — 数千もの断片に対して類似検索を実行する 5. **Stuff（詰め込み）** — 上位の結果をコンテキストウィンドウに押し込む 6. **Reason（推論）** — ようやく、モデルが考える 7. **Forget（忘却）** — セッションが終わり、コンテキストは蒸発し、ステップ1から繰り返す どのステップもトークンを消費します。実際に知性を生み出す唯一のステップ（ステップ6）よりも、ステップ1〜5の方が多くを消費するのが通常です。「返金はどこ？」という問い合わせに100回目の対応をするサポートエージェントを想像してみてください。 ![retrieval loop tokenmaxxing](https://cdn.sanity.io/images/umrbtih2/production/15531036077d8c2fedbfcc5599640d217a7d9784-2400x2400.png) 顧客レコードを再取得し、注文履歴を再び埋め込み、50個のポリシー断片を再ランキングし、それらすべてをウィンドウに詰め込んだうえで、モデルは昨日書けたはずの2行の返信を書く。この回答に数千トークンかかります。 1クエリのトークンコストは些細に見えますが、スケールを掛け合わせるとコストは深刻になります。Gartnerは[2026年3月のインファレンス経済予測](https://www.gartner.com/en/newsroom/press-releases/2026-03-25-gartner-predicts-that-by-2030-performing-inference-on-an-llm-with-1-trillion-parameters-will-cost-genai-providers-over-90-percent-less-than-in-2025)で、エージェント型AIモデルは標準的なチャットボットに比べてタスクあたり5〜30倍のトークンを必要とすると指摘しました。本番規模では、これが積み重なり、月間で数千万ドル規模の請求になります。 このパターンは特定のシステムに固有のものではありません。しかしDevRevはそれを数字にしました。[Enterprise-Bench](https://devrev.ai/blog/enterprise-bench)では、データセットが大きくなるにつれてfetch型エージェントのトークンコストは29%上昇し、しかも精度は上がりませんでした。より多くのノイズに埋もれた同じ答えを見つけるために、より多くをコンテキストに引き込み続けたのです。 ![Total tokens on the largest runs claude computer tokenmaxxing benchmark](https://cdn.sanity.io/images/umrbtih2/production/0df5514b17b4d7a7d9fca93886835771b7e08b8f-5334x3000.png) デモ規模では、あるタスクに関連するデータは全体の40%ですが、本番規模ではわずか0.16%です。問い自体が難しくなるわけではありません。難しくなるのは、増え続けるノイズの海の中から正しい答えを見つけることであり、fetch型エージェントは余分な走査のたびにトークンで支払うことになります。 > [!INFO] > **重要ポイント:** 無駄はプロンプトにあるのではありません。検索アーキテクチャにあります。根本的に記憶喪失なシステムの中でトークン使用量を最適化するのは、病そのものではなく症状を治療しているにすぎません。本当の問いは「クエリあたりのトークンを減らす」ことではなく、「なぜシステムは、すでに答えを知っている問いを尋ねているのか？」です。 ## **プロンプト最適化の代わりになるものは何か？** 解決策は、より大きなコンテキストウィンドウでも、より安いモデルでもありません。使い捨ての検索ではなく、永続的な構造化メモリの上に築かれた「すでに知っているシステム」です。 クエリのたびに1万個のドキュメント断片を処理・埋め込み・検索する代わりに、取り込み時に関係性を_一度だけ_構造化します。 正しく実装すれば、これこそが [AIナレッジマネジメント](https://devrev.ai/blog/ai-knowledge-management) が本来もたらすべきもの — システムがエンティティと関係性を毎回発見し直すのではなく認識する、[ナレッジグラフ vs ベクターデータベース](https://devrev.ai/blog/knowledge-graph-vs-vector-database) というアプローチです。 多くの実装は、これを関係性のアーキテクチャではなくドキュメントストレージとして扱ってしまい、要点を外しています。 隣接する動き — **valuemaxxing**（[Forbes](https://www.forbes.com/sites/timkeary/2026/06/02/why-tokenmaxxing-is-out-and-valuemaxxing-is-in/) とNebius CROのMarc Boroditskyが提唱）と **tokenminning**（Towards Data Science）— はいずれも同じ方向を指しています。入力量を測るのをやめ、出力価値を測り始めよ、と。 しかしどちらも、そのアーキテクチャ上のメカニズムを名指ししていません。そのメカニズムこそが、永続的で構造化されたメモリ — チーム・顧客・プロダクト・コードにまたがる事前計算済みの関係性を保持する、生きたナレッジグラフです。 [Computer Memory](https://devrev.ai/platform/computer)（by DevRev）がこれを解決します。これは、コンテキストを取得して再構築するのではなく、認識するナレッジグラフです。この一語の違いが、勝負のすべてです。検索（Retrieval）はクエリのたびに必要なものを再構築します — 高コストで、反復的で、欠損を伴う。認識（Recognition）はすでに保持しているものを想起します — 安価で、永続的で、正確です。 > [!INFO] > **重要ポイント:** アーキテクチャが最適化に勝るのは、作業を圧縮するのではなく、作業そのものを無くすからです。AI予算に対する正しい問いは「1回の呼び出しでトークンをどう減らすか？」ではなく、「そもそも存在すべきでない呼び出しはどれか？」です。 ## **メモリアーキテクチャはトークンコストをどれだけ削減できるのか？** これを誠実に検証するため、DevRevは [Enterprise-Bench](https://devrev.ai/enterprise-bench-methodology) を構築しました。正解を固定したまま、その周囲のデータをデモ規模から成熟した企業の規模へと（256倍まで）スケールさせる評価です。同じモデルファミリー、同じデータ、同じ質問で動く2つのエージェント。唯一の変数は、それぞれがどうやってデータに到達するか。一方は構造化メモリ層を通り、もう一方はfetch型のツール呼び出しを通ります。 | 指標 | fetch型検索 | 構造化メモリ | 差分 | | --- | --- | --- | --- | | 精度 | 63.6% | 94.3% | +30.7ポイント | | 正答1件あたりのトークン数 | 約24,461 | 約5,598 | 約4.4倍少ない | | データ増加に伴うトークンコスト | +29%上昇 | ほぼ横ばい | 規模拡大で差が広がる | | 厳選ツール → 現実的インターフェース | 精度 –18〜–19ポイント | – | モデルではなくアーキテクチャ | *Enterprise-Bench の結果: fetch型検索 vs 構造化メモリ* _出典: [Enterprise-Bench, DevRev](https://devrev.ai/enterprise-bench-methodology)。_ ![TOKENS PER CORRECT RESPONSE ← proves the efficiency gain tokenmaxxing benchmark report](https://cdn.sanity.io/images/umrbtih2/production/e323dbe65cf69a899a4898fb564cee5e23928cb4-5334x3000.png) 構造化メモリは、精度を効率と引き換えにするのではありません。両方を同時に向上させます。効率は1回答あたりのトークン数を減らすことから生まれ、精度は、1万個の断片の中から関連するものを1つ引き当てることを期待するのではなく、必要なものだけをモデルが推論することから生まれます。 これはアーキテクチャの転換です。システムが事前計算済みの関係性を持つ生きたナレッジグラフを維持していれば、大半の「検索」は、直接のグラフ走査またはSQLクエリへと縮約されます。 しかし、最も印象的な数字はトークン差ではありません。インターフェースに関する発見です。 エージェントを厳選されたツールから現実的なAPIサーフェスへ移すと、精度は18〜19ポイント低下しました。一方、[モデルのバージョンを上げても、精度はわずか1ポイントしか動きませんでした](https://devrev.ai/enterprise-bench-methodology)。Enterprise-Benchの言葉を借りれば、「検索アーキテクチャは、基盤モデルの選択よりも本番性能の強い予測因子である」。 AIベンダーを選ぶ決め手であるモデルは、ほとんどの買い手が決して問わないもの — それがどうやってあなたのデータに到達するか — よりも重要ではないのです。 > [!INFO] > インファレンス（推論）の請求書をCFOに説明しなければならない立場なら、この完全な方法論には1時間の価値があります。数字がどう計測されたかを正確に示し、256倍のデータ増加を通じて答えを一定に保ち、そしてスケールが増すにつれてfetch型エージェントがデータに存在しない答えを捏造してしまう特定の失敗モード —「デカルト的ショートカット（Cartesian shortcut）」— を名指ししています。 > > **[Enterprise-Benchの方法論をダウンロードする](https://devrev.ai/enterprise-bench-methodology)。** LLMコスト最適化[戦略を評価するチームにとって、優先順位は明快です。](https://devrev.ai/blog/llm-cost-optimization)プロンプトの小技は端をわずかに削り、モデルルーティングは役に立ちます。しかし、データの増加に伴って曲線そのものを曲げられる唯一のレバーは、アーキテクチャです。 [Computerが実際のワークロードを14日で解決する様子をご覧ください → デモを予約する](https://devrev.ai/demo) ## **本番環境における本当のtokenmaxxingとはどのようなものか？** アーキテクチャを正すことで得られるのは、請求額の縮小だけではありません。本番環境との接触を生き延びるエージェントが手に入ります。いまだにプロンプトを調整し続けているチームは、支えるべき売上より速くトークン請求が膨らむ中で、デッキチェアの配置を最適化しているようなものです。 では、メモリファースト版は実際にはどのようなものか？ 4つの層があり、それぞれが異なる種類の無駄なトークンを消していきます。 | 段階 | 層 | 役割 | トークンへの効果 | | --- | --- | --- | --- | | 1. 取り込み (Ingest) | Computer AirSync | 50以上のツールと双方向・権限考慮で同期。データは事前構造化された状態で届く | 再取得・再パースなし | | 2. 記憶 (Remember) | Computer Memory | 生きたナレッジグラフ。チーム・顧客・プロダクト・コードにまたがる関係性を事前計算 — 検索ではなく認識 | コンテキストを再構築しない | | 3. 推論 (Reason) | Agent + Computer Memory | クエリが構造化メモリに到達 → SQL/KG経路 → 精密なコンテキスト → LLMが必要なものだけを推論 | LLM起動前に大半の作業が完了 | | 4. 実行 (Act) | Computer Agent Studio | セッションをまたいで記憶するエージェント。スキルが積み上がり、数ヶ月ではなく数分でデプロイ | セッションごとの再構築なし | *メモリファースト・アーキテクチャ: 4つの層、それぞれが無駄トークンのクラスを消す* 各段階は、無駄の中で最適化するのではなく、無駄のクラスそのものを消し去ります。段階1は再取り込みを、段階2は再計算を、段階3は過剰検索を、段階4はセッションごとの記憶喪失を消します。 ![4-STAGE ARCHITECTURE ← shows the solution system tokenmaxxing](https://cdn.sanity.io/images/umrbtih2/production/99d1542c74a010dfe9d5c2608ed4f148e7900e79-2400x2400.png) このアーキテクチャが Computer Agent Studio を実現します。記憶するエージェントを作り、数分でデプロイする。これこそが、デモで感心されるだけのプロトタイプと、本番で20万件の実クエリを解決するシステムとを分けるものです — まさに [BILLの実績](https://devrev.ai/customers/bill) が70%の自律解決率で示している通りです。 > [!INFO] > Computerが[どのように動作するか](https://devrev.ai/how-computer-works)をエンドツーエンドで解説しています。短く言えば、あなたのAIは「クレジットカードを持った金魚（すぐ忘れる）」であることをやめ、「記憶を持った同僚」になります。 > > [Computerが実際のワークロードを14日で解決する様子をご覧ください → デモを予約する](https://devrev.ai/demo) > > [BILLの事例を読む: 20万件の実クエリで70%解決 →](https://devrev.ai/customers/bill) > >