RTKのトークン削減レポートが胡散臭い?コストベンチマークで検証してみた
RTK reports token savings, but our cost benchmarks disagree
RTK reports token savings, but our cost benchmarks disagree
RTK(Redux Toolkit)はトークンの節約効果があるとのレポートを出していますが、実際に手元のコストベンチマークを計測してみると、どうも数字が一致しません。同じような現象に直面している方、あるいはこの計算ロジックの裏側を知っている方がいれば、ぜひ知見を共有してください。
こうした「ハック」は全部まやかし(snakeoil)だっていうのは、みんな内心分かってるはずだ。cavemanであれRTKであれ、あるいはその他いろんな生産性向上だのトークンコスト削減だのを謳うハックやスキル、claude.mdみたいなものにしてもね。
私の場合、専用のローカルコード埋め込みモデルを使ってコードベースをインデックス化する方法がうまくいった(ベンチマークは古いが)。CPU側で多少コストはかかるけど、私のベンチマークではトークン使用量と実効時間がかなり減ったよ。もちろん、統計的なノイズやホスト側の負荷に依存するし、十分に大規模なベンチマークを実行するのは単にコストがかかりすぎるから、話半分に聞いておいてくれ。
なぜこれがうまくいくのかって?LLMは基本的に言葉やフレーズを総当たり(brute force)で処理して、それをfind/grep/pgrepといったコマンド(あるいは最近ここで話題になったようなPythonスクリプト - https://news.ycombinator.com/item?id=49654229 )に流し込むからさ。セマンティック検索なら類似性を探してくれるから、総当たりを減らせる。もちろん、最初に全てをインデックス化するコストはかかるけどね。
プロジェクトはこちら:https://github.com/ory/lumen
その通りだね。「従業員をケチって使うな」というのは、たいていの管理職がいずれ学ぶ教訓だけど、エージェントオーケストレーターも同じことを学ばざるを得なくなるんだろうな。
要点:
平均コスト(RTKなし → RTKあり):
Claude/Fable: $1.72 → $1.64(約5%安)
DeepSeek: $0.115 → $0.121(約5%高)
Claudeの削減分のほぼ全ては単一のタスクによるもの。それを除外すれば削減幅は1%未満。
一番大事なところを理解するのに何度か読み直したよ。この記事、本当に肝心な結論を隠しすぎだ。
こういうツールのほとんどは中身のない「ヴェイパーウェア」みたいだな。HeadroomやRTKのベンチマークを見ても、実際には何のコスト削減にもなっていない。もしそんな単純な前処理ステップで解決できるなら、AIラボが自前で最適化を組み込まない理由がないだろ?
推測するに、ほとんど機能していないか、むしろモデルの挙動を混乱させているだけじゃないかな。独立したベンチマークが必要だと思うよ。
これらのツールが抱える同じ問題を示している事例が他にもある:
https://blog.jetbrains.com/ai/2026/07/rtk-claude-code-token-
https://brandonbarker.me/writing/headroom-fewer-tokens-bigge
この手法は最初から怪しいと思っていたよ。LLMは一般的なbashツールから特定の出力が返ってくることを前提に学習されているからね。期待と違う出力が来ると、LLMはツールが壊れているか、引数が間違っているか、あるいはツールのバージョンが違うのかなどと考えて、さらにツールを呼び出すようになる→結果、トークンが増えるというわけだ。grepやtailを多用するようにプロンプトに詳しく書くだけで、特別なツールなんていらないんじゃないか?
こういうのがただの「まやかし」だと気づく人が増えていて嬉しいよ。ベンチマークのような客観的な指標がなければ、どんな主張も意味がない。
スキルやプラグインについても同じ感想だな。特定のプロジェクトや環境で重要なコンテキストを提供するものもあるけれど、「JSのテストを書く」とか「仕様を作る」といった汎用的なスキルにはすごく懐疑的だ。うちの会社内にもそういうスキルが山ほどあるけど、単なる一文のプロンプトより優れているというベンチマークを見たことがない(統計的に有意なレベルでね)。
数ヶ月前に「これは機能しないと思う」っていう記事を書いたんだ。こうやって数値が出てきたのは良いことだね。
https://mroczek.dev/articles/the-token-compression-illusion-why-im-skeptical-of-rtk/
俺はツール使用の結果を要約させるために、一番安いモデル(例えばflash-lite)でサブエージェントを立ち上げているよ。自分のベンチマークでうまくいくし、汎用性も高い唯一の方法だね。
RTKのゲイン(削減量)出力をまともに見たことがある奴なら、ベンチマークなんて不要で、機能していないのは一目瞭然だろ。エージェントが
rtk command-that-prints-100k-tokens | tail -5
を実行したとする。実際には5行、トークンにして100程度しか使わないのに、RTKは「100kトークンの削減」なんて報告するんだ。当然、その中のtail -5が何をしてるかなんて分かっちゃいない。
さらに悪いことに、RTKはデフォルトでその削減統計を保存しようとするから、サンドボックス環境を壊す原因になる。rtkを頭につけると、時々ランダムに自動実行モードが拒否されることもあるしね(統計の保存を無効にしてもこれは関係ない)。
正直、CLIの基礎を知っている人間がなぜRTKのゲインなんて数値を真に受けるのか理解できないよ。ターミナルをほとんど使ったことがないような「雰囲気コーダー」が、その数値を見ていい気分になっているだけなんじゃないか?
とはいえ、繰り返されるテスト結果の出力を圧縮する用途なんかには多少は使える。でも、ホワイトリストに入れたコマンドに対してのみ使うべきだ。提案されているみたいに何でもかんでもラップするのは馬鹿げている。
俺はtreesitterを使ってファイルやディレクトリの概要を作るツールを使ってるよ:https://github.com/resolveworks/trace
ベンチマークはとっていないけど、目的はトークンの節約というより時間の短縮だ。モデルが状況を把握するために何度もツールを呼び出す必要があって、全体像を掴むのに苦労していることに気づいたからね。