Tokenmaxxingは死んだ、されどTokenmaxxing万歳

• 企業のAI導入初期に、トークン使用量を成果評価に結びつけたtokenmaxxingは、無意味なコストを生んだ一方で、AIツールの利用を組織内に強制的に広める役割も果たした
• Metaでは個人ごとのトークン使用量が評価に結びつけられると、数値を上げるために2つのエージェントを一日中会話させるような形式的な利用まで現れた
• 以前は長時間のエージェント実行は、小さな誤りが積み重なる累積誤差(compounding error) のため危険だったが、最近ではより多くのトークンがより良い結果を生む累積正確性(compounding correctness) の流れが台頭している
• セキュリティ分野では、Mythosのようなモデルに大きなトークン予算を投じて脆弱性を探す手法が登場し、防御側が攻撃側より多くの計算を使わなければならない構造が生まれている
• 今後は高価な最上位モデルに無制限に支出するよりも、安価なオープンモデルをループでより多く回すやり方が、tokenmaxxingの実用的な中心になる可能性がある

---

無意味なトークン消費から始まったtokenmaxxing

• tokenmaxxing は、役員が従業員に多くのトークンを使わせようとすることで、実際の価値が低い作業にもトークンが消費される現象を指す
• 代表例としてMetaは、成果評価を個人別のトークン使用量と結びつけたと批判された
  • あるMeta社員は、トークン数値を上げるために2つのエージェントを一日中互いに会話させていたと伝えている
• 表面的には、経営陣が収益もないままコストだけを燃やしているように見えたが、AIツール利用を強制的に普及させようとする方針としても見られる
• 数か月前まで、組織内にはAIツールの使用を強く拒むシニア人材が多く、説得に成功しても、ツールを奇妙だったり悪い結果が出やすい使い方で使うことがあった
• こうした状況で、上から降りてくるトークン使用圧力は、壁を突き破るための鈍重な強制手段として機能した

コスト圧力で終わった最初の無制限利用方針

• tokenmaxxing方針は一定の効果を上げ、今ではほぼすべてのチームが少なくとも多少はAIでコーディングする状態になっている
• 多くのチームはまだRamp InspectやStripe Minionsのような独自システムを作れてはいないが、基本的にはCursorをサイドバーで使うレベルには到達している
• トークン使用量が大きく増える中、OpenAIとAnthropicは上場を進める状況でサブスクリプション提供量を制限し、API価格を引き上げている
• トークン補助も減るにつれ、無制限トークン利用方針を見直すチームが出てきた
• 従来の意味での無制限tokenmaxxing は、コスト審査に耐えにくい段階に近づいている

累積誤差から累積正確性へ

• AIツールへの期待は、人が継続的に監督しなくても難しく退屈な作業を処理させることにある
  • 大規模なコード移行
  • 毎朝の競合調査
  • インバウンドとアウトバウンドのフロー処理
• 以前はAIを長く動かすほど、モデルの小さな誤りや幻覚がプロジェクト内に蓄積し、巻き戻しが難しくなった
• この現象は累積誤差(compounding error) と呼ばれ、人の監督を多く必要としたため、エージェントを24時間回す理由も乏しかった
• 今では、より多くのトークンを使うほど正答の可能性が高まる累積正確性(compounding correctness) の環境へ変わりつつある
• トークン支出が結果の品質と結びつくなら、再びトークンを多く使おうとするインセンティブが生まれる

セキュリティ分野で先に見えるトークン予算競争

• サイバーセキュリティでは、すでにトークン支出が成果と直接結びつく事例が現れている
• Cybersecurity is Proof of Work Now はAnthropicのMythosを例に挙げ、システムを強化するには攻撃者が悪用に使うより多くのトークンを脆弱性発見に使わなければならないと見る
• AISIはMythosの試行1回あたり100Mトークンを予算化しており、これは1回あたり$12,500、10回実行で$125,000規模に相当する
• 100Mトークン予算を与えられたモデルは収穫逓減の兆候を見せず、AISIはテストされたトークン予算範囲において、予算が増えるほどモデルが継続的に進歩したと明らかにしている
• この構造では、巧妙さよりも計算作業量と支払可能なトークン予算の方が重要になる

ループと長時間エージェント実行

• Boris ChernyがClaude Codeの舞台で語ったloops への関心も、同じ流れにつながっている
• loopsの基本構造は、エージェントが自分のターンを終えるまで実行し、終わったら同じプロンプトを再び開始するというものだ
• 重い仕様を自動で分割し、エージェントが時間の経過とともに部分ごとに解決していくようにできる
• この概念は新しいものではなく、昨年7月から存在しており、一時は「Ralph Wiggum loop」と呼ばれていた
• 以前はプロンプト設計やエージェントの挙動に対する深い理解が必要だったが、累積正確性のおかげで、繰り返すほど改善する近似的な結果を期待しやすくなっている

オープンモデルが生むコスト対効果の高い反復実行

• 長期的には、tokenmaxxingの勝者はオープンモデルプラットフォームかもしれない
• 最上位研究所のモデルに大量のトークンを支出する方式は、CFOの審査を通りにくい
• オープンモデルが良くなるほど、安価なモデルをループ内でより多く回す方式の魅力が増す
• たとえばClaudeが1反復あたり1.1倍の改善をもたらし、GLM 5.2が1.05倍の改善だがコストは約5分の1なら、GLM 5.2のループを5倍回す方が有利かもしれない
• 「Other things」セクションでも、GLM 5.2は最先端ではないがfrontierモデルよりはるかに安いと評価されている
  • GLM 5.2: 入力100万トークンあたり約$1.4、出力100万トークンあたり約$4
  • Opus 4.Xシリーズ: 入力100万トークンあたり$5、出力100万トークンあたり$25
  • Haiku 4.5: 入力100万トークンあたり$1、出力100万トークンあたり$5
  • GLM 5.2はHaikuより強く、一部ベンチマークではGPT 5.5より強い場合もあるという

開発者向け支出とパイプライン向け支出の違い

• tokenmaxxingには異なる2つの形がある
• 1つ目は開発者向けトークン支出だ
  • 開発者がClaude Codeのようなツールを使い、loopsを実行し、多くのトークンを消費する
  • エンジニアの生産性を高めるなら良い支出になりうる
• 2つ目はパイプライン向けトークン支出だ
  • 開発者は依然として手でコードを書き、そのコードで特定作業のための使い捨てエージェントを作る
  • これらのエージェントは非決定的で脆弱な形で動作しながら、多くのトークンを消費する
  • パイプラインが実際に機能するときにだけ良い支出だが、そのようなエージェントは決定的なパイプラインほど正確ではなかった
• 幻覚コストを減らすため品質確認エージェントを追加し、その確認エージェントの誤りを捉えるためさらに別のエージェントを付けると、トークンコストは3倍になる
• 使い捨てパイプライン型ツールは、特定作業用エージェントとしてよりも、特定作業向けの外装をかぶせた汎用プラットフォームとして扱われる流れが強まっている

ソフトウェアファクトリーと極端なトークン支出

• 自然な行き着く先はソフトウェアファクトリー、さらに言えばダークファクトリーだ
• この構造では、コードベースが人の監督なしにコードを作り、レビューし、バグを修正し、テストを書く
• 人は仕様を入れてアプリケーションを受け取る役割だけを担う
• StrongDMのソフトウェアファクトリー は、この方向を極端まで押し進めた事例として言及されている
• StrongDM側は、エンジニアが1日$1000分のトークンを使うことを目標にすべきだと主張したが、これは誇張と宣伝色が強いと評価されている
• 自社のソフトウェアファクトリーは月$600程度を使っているとし、現時点でエンジニア1人あたりシニアGoogleエンジニア並みのコストをトークンに使うのは過剰だと見ている
• ただし、トークンに大金を投じようとするインセンティブは潜在的に存在しており、まだ普及を待っている状態にある