「トークンを最大90%削減」の主張を覆す、JetBrainsがClaude Code向けプロキシ「rtk」のコスト増を検証

関連記事 「トークンを最大90%削減」の主張を覆す、JetBrainsがClaude Code向けプロキシ「rtk」のコスト増を検証 Claude Codeの利用コスト削減を狙ってプロキシツール「rtk」を導入している開発者は、実際の請求額を再確認する必要があるかもしれない。JetBrainsが2026年7月20日に公開したベンチマーク評価によると、同ツールはコストを削減するどころか、低推論エフォート設定においてコストを中央値で7.6%増加させることが判明した。ツール独自の削減カウンターは膨大な節約を示しているものの、実際の課金システムとは乖離していると指摘されている。 ■期待されたコスト削減ツールの「不都合な真実」 Claude Code開発者の間で、トークンコストを60〜90%削減できる方法として広く共有されていたプロキシツール「rtk」(Rust Token Killer)。しかし、JetBrainsが2026年7月20日に公開した管理環境下でのベンチマークテストにより、実際にはセッションコストが中央値で7.6%増加することが明らかになった。この知見は、JetBrainsの研究員デニス・シリアエフ(Denis Shiryaev)氏による独立評価シリーズの第2弾であり、AIコーディングツール業界における主要なコスト削減の主張を体系的に覆すものとなった。 特に注目すべきは、実際のコストが増加した一方で、rtk自身の分析コマンド(rtk gain)は「9620万トークンを節約した」と記録していた点である。実際の請求額の増加と、自己申告による数千万トークンの節約というこの大きな乖離は、同ツールが存在しない仮定(反実仮想)を基準に測定しているという、ベンチマークが暴いた根本的な問題を浮き彫りにしている。 ■rtkの仕組みと削減のロジック rtkは、Claude Codeが発行するシェルコマンドをインターセプトし、生の出力の代わりに圧縮された要約をモデルに返す軽量なCLIプロキシである。技術的な前提は理にかなっている。開発者のコーディングエージェントが「git status」を実行すると、rtkがそれを傍受して実際のコマンドを実行し、11行の詳細な出力の代わりに「* master / M a.txt / ?? b.txt」のようなコンパクトな表現をモデルに渡す。Pythonのテスト実行では、19行のpytest出力を、失敗したテスト名を示す1行の要約に置き換える。Claude Codeの「PreToolUse」フックがこのインターセプトを透過的に処理するため、モデルは圧縮レイヤーの存在を認識しない。 マーケットプレイスの掲載情報では、Gitステータス、Dockerログ、テスト実行、ファイル操作のインテリジェントな圧縮により、Claude Codeのトークン消費を60〜90%削減できると主張されている。プロジェクト独自のベンチマーク文書では、コマンド出力の11万8,000トークンが2万4,000トークンに削減された30分間のセッションが紹介されており、これが2026年を通じてClaude Codeコミュニティで同ツールが急速に普及する要因となった。 ■JetBrainsによる検証実験の設計 シリアエフ氏は、現実的なワークロードでAIコーディングエージェントを評価するためのオープンベンチマークスイート「JetBrains SkillsBench」を使用し、4つの対照群を実行した。具体的には、10タスクのスモークテスト、同じ10タスクの3回反復、低推論エフォートでの全86タスク、高推論エフォートでの全86タスクである。バージョンはClaude Code 2.1.201とclaude-sonnet-5に固定され、実験全体で425回の有料試行を行い、計算コストは約320ドル(約5万2,160円、1ドル=163円換算)に上った。 実験設計の重要な特徴は、導入状況の追跡である。rtkが有効なすべての試行でフックの監査ログと分析データベースを保存し、「rtkが何も節約しなかった」のか「rtkが一度も実行されなかった」のかを区別できるようにした。実行全体で、フックは検出したBash呼び出しの33〜50%を書き換えた。 実際の計算リソースを投入する前に、シリアエフ氏は既存のベースラインログ83件を再生し、実際のセッションでrtkがどの程度関与できたかを分析した。その結果、構造的な限界が明らかになった。Claude Codeはファイルの読み込みに内蔵 of ReadおよびGrepツールを使用するため、Bashフックを完全にバイパスする。また、エージェントがシェルで実行するコマンドの約半分はrtkの対象外であり、Bash呼び出しの約6分の1はパイプやヒアドキュメント、置換を使用しているため、rtkは意図的に書き換えを拒否する。残った約3分の1のBash呼び出しが占めるのは、ツール実行結果の文字数の20%未満にすぎなかった。さらに、ツール実行結果自体もセッション全体の入力コストの一部にすぎない。同じコンテキストがエージェントのターンごとにキャッシュされた料金(新規トークンの10分の1)で再読み込みされるためである。 この分析により、理論上の最大削減率は入力トークンの約3%にとどまることが、有料試行を行う前の段階で予測された。そして、この予測は正確であることが証明された。 ■コストは削減されず、逆に増加 低推論エフォートでの80件のクリーンな対照タスク比較において、rtkを実行したグループは、タスクあたりのコストが中央値で7.6%高くなり(p=0.004)、ターン数が13.8%増加し(p=0.03)、キャッシュ読み込みが14.3%増加した(p=0.008)。rtkが効果を発揮すべき唯一の指標である、キャッシュされていない「新規入力」トークン(フックが実際に圧縮する唯一のトークンクラス)は3.2%の変化にとどまり、統計的に有意な差は認められなかった(p=0.23)。 コスト増加の原因は特定されている。フックがBash呼び出しを書き換えるほど、それらのタスクに対するペナルティが大きくなった。ログ分析によると、複合的なfind述語が使用エラーに書き換えられて再試行がトリガーされたことや、圧縮に起因する再読み込み、極端なケースにおける通常のばらつきが原因だった。レポートでは、これを「劇的な失敗というよりは、薄く組織的な課税のようなもの」と表現している。 高推論エフォートでは、このペナルティは再現されなかった。中央値の差は+0.1%(p=0.99)で、ターン数も横ばい(p=0.74)だった。しかし、どちらの条件においても、rtkが測定可能な削減効果をもたらすことは一度もなかった。同ツールは高エフォートではコストに影響せず、低エフォートではコストを増加させる結果となった。 ■タスクの品質には影響なし ベンチマークでは、コストとは別にタスクの品質も追跡した。どちらのエフォートレベルでも、結果に統計的な差は認められなかった。低エフォートでは「改善」が5件、「悪化」が4件、「引き分け」が71件。高エフォートでは「改善」が5件、「悪化」が4件、「引き分け」が62件だった(符号検定のp値はいぜれも1.0)。 rtkのイシュートラッカーに記録されている失敗モード(テスト出力の過剰なフィルタリング、終了コードの隠蔽、パイプへの圧縮テキストの供給など)は、実際にはほとんど発生しなかった。最も乖離の大きかったログを詳細に調査したところ、約150回のBash呼び出しの中で、破損した書き換えは1件、エージェントが意図的にフックをバイパスした例が1件のみだった。シリアエフ氏の報告書が指摘するように、ツールが適用するフィルターは「本物であり、しばしばエレガント」である。問題はrtkが何かを壊すことではなく、コストの大部分を占めない部分を圧縮していることにある。 ■自己評価カウンターの罠 最も示唆に富む発見は、各操作で節約されたと推定されるトークン数を記録するrtkの内蔵分析コマンド「rtk gain」に関するものである。低エフォートのフル実行において、実際の請求額が増加したにもかかわらず、「rtk gain」は9620万トークン(関与した全トークンの99.8%)を節約したと報告した。この乖離には3つの理由がある。 第一に、rtkは「圧縮前の生の出力全体」を比較対象(反実仮想)としてカウントしている。例えば、1.2MBのCSVファイルをcatした場合、32万トークンを「節約」したと記録される。しかし、Claude Codeはツール実行結果がその閾値に達する前に出力を切り捨てるため、ツールを使用していなくてもエージェントが受け取るのは数千トークンにすぎない。フル実行では、このような大規模な読み込みが190回記録され、1回あたり平均約50万6,000トークンが「節約」されたとカウントされていた。 第二に、rtkは実行時に対象の文字数を4で割ることでトークン数を推定しているが、セッションの入力コストの大部分は、新規トークンの10分の1の価格で請求されるキャッシュされた再読み込みによるものである。第三に、このフックはセッションのコンテキストの大部分をそもそも認識していない。 結果として、実際の課金システムでは決して適用されない仮定に基づいて、自ら「自己採点」を行っている状態になっている。 ■トークン削減ツールに共通するパターン JetBrainsは、注目を集めるトークン削減ツールが、管理された条件下では主張された効果のほんの一部しか発揮しない(あるいは逆効果になる)という検証結果を2回連続で公開した。出力トークンを65%削減すると謳った「Caveman」は実際のワークロードで8.5%の削減にとどまり、60〜90%の削減を謳った「rtk」は逆にコストを増加させた。 両方の研究で、同じ方法論的な罠が浮き彫りになった。初期の少数の試行(k=1)では劇的な効果が見られたものの、サンプルサイズを増やすと効果が消失するという点である。rtkの最初のスモークテストでは、rtkありのグループが35%高コストに見えたが、同じグループ内での同一タスクの試行でもコストに22%のばらつきがあった。3回反復すると、この差はノイズの中に消えた。この検証シリーズが2度にわたって示した教訓は、エージェントツールの「n=1(1回のみ)」の評価は信頼できないということである。 また、両ツールは構造的な「反実仮想」の問題を共有している。マーケティング用のベンチマークは「ツールが関与した部分」を測定しており、「セッション全体で実際にコストを押し上げている要因」を測定していない。チャット型のベンチマークは、エージェントの課金において支配的ではない出力ストリームの一部を圧縮しているにすぎない。 シリアエフ氏は、この分野のツールを評価する開発者に向けて、次のように明確な原則を述べている。「ツールが自己報告する節約額は、反実仮想(ツールを使わなかった場合の想定)に関する主張であり、実際の請求額に関するものではない」。ツールの差分表示ではなく、実際に対照群を用意して請求コストを測定することだけが、開発者が本当に知りたい答えを提供する唯一の評価方法である。JetBrainsは、同じベンチマークで検証すべき次のツールの推薦をコミュニティに呼びかけている。 ■注目ポイントQ&A ●rtkを導入すれば、実際にClaude Codeの利用料金を削減できますか? JetBrainsが425回の有料試行を行ったベンチマークテストによると、コスト削減効果は認められず、むしろ設定によってはコストが増加します。低推論エフォート設定では、通常のClaude Codeと比較してタスクあたりのコストが中央値で7.6%増加しました。高推論エフォート設定では、コストの差はほぼゼロ(+0.1%)でした。ツール内蔵のカウンターは9620万トークンの節約を報告していましたが、これは実際の課金システムとは異なる理論上の最大値を基準にしているためです。 ●なぜrtkの圧縮機能は、Claude Code의コストを左右するトークンに届かないのですか? 構造上の理由として、Claude Codeはファイルの読み込みに内蔵のReadやGrepツールを使用するため、rtkが依存するBashフックを完全にバイパスします。また、シェルで実行されるコマンドの約半分はrtkの対象外であり、Bash呼び出しの約6分の1はパイプやヒアドキュメントを使用しているため、rtkは意図的に書き換えを行いません。結果として、rtkが処理できるのはツール実行結果の文字数の20%未満であり、さらにツール実行結果自体もセッション全体の入力コストの一部にすぎません。同じコンテキストがターンごとにキャッシュ料金(新規トークンの10分の1)で再読み込みされるため、理論上の最大削減率は入力トークンの約3%にとどまります。 ●rtkを使用することで、Claude Codeが生成するコードなどの品質に影響はありますか? 測定可能な品質への影響は確認されませんでした。低推論および高推論エフォートの双方で86のタスクを実行した結果、統計的な差は認められず、タスクの成否に影響はありませんでした。懸念されていたテスト出力の過剰なフィルタリングや終了コードの隠蔽といった不具合も、実務上はほとんど発生していません。圧縮自体は機能していますが、コストに影響する部分に届いていないのが現状です。 ●トークン削減ツールが実際に効果的かどうかを開発者が判断するにはどうすればよいですか? ツール独自の節約カウンターではなく、複数回の試行における実際の請求コストを比較することが重要です。ツールの自己報告カウンターは、実際の課金システムが適用しない理論上の最大値を基準に計算されています。また、エージェントタスクは本質的にコストのばらつきが大きいため、1回限りの評価は信頼できません。代表的なタスクセットを用いて複数回の対照実験を行い、実際の請求書に基づいてコストを測定することが、信頼できる唯一の評価方法です。