RTKでClaude Codeの料金は下がる？検証で見えた表示と請求額の差

Claude Code を使っていると、利用上限や API の料金が気になってきます。そこで目に入るのが、「入れるだけでトークンを60〜90%削減」と紹介される RTK です。入れてみたら rtk gain に大きな数字が並んだ。けれど、上限に達する早さや請求額は、あまり変わった気がしない。そう感じている人もいるはずです。

この記事では、RTK が何を減らしていて、何を減らしていないのかを、料金で比べた2つの検証をもとに説明します。効く場面、導入の仕方、自分の環境で確かめる方法、料金を減らすために先に見直すところも扱います。内容は2026年10月時点で確認したものです。

RTKで出力は短くなる。ただ、料金は下がらなかった

RTK を入れると、AI に渡るコマンドの出力はたしかに短くなります。しかし、RTK あり・なしで料金を比べた2つの検証では、料金は下がりませんでした。条件によっては、少し増えています。

2つの検証は、どちらも同じ課題を RTK ありとなしで解かせて、かかった料金を比べたものです。1つは JetBrains、もう1つは Quesma が公表しています。結果を1つの表にします。

項目	検証1（JetBrains）	検証2（Quesma）
公表の時期	2026年7月	2026年9月
課題集	SkillsBench の86タスク	Terminal-Bench 2.1（85タスクと89タスク）
実行の回数	425回	1,740回
かけた費用	約320ドル	1,500ドル超
エージェントとモデル	Claude Code 2.1.201、claude-sonnet-5	Claude Code 2.1.220 と Fable 5.0／OpenCode 1.18.25 と DeepSeek V4 Pro
RTK のバージョン	0.43.0	0.45.0
料金の変化	effort が低い設定で +7.6%（タスクごとの中央値）、高い設定で +0.1%	Fable で +1%（差なし）、DeepSeek で +17%（どちらもタスクごとの平均）
やりとりの回数	effort が低い設定で +13.8%、高い設定で変化なし	DeepSeek で +18%
品質	差なし	合格率が 84% → 83%（Fable）、71% → 69%（DeepSeek）
RTK が書き換えた端末のコマンド	33〜50%	Claude Code で31%、OpenCode で51%
RTK が届く範囲	Bash はツールの出力の文字数の20%弱。そこを70%削っても、入力トークンの約3%	端末の出力は、Fable の入力の約7%
キャッシュ読み込みの単価	通常の入力の10分の1	Fable で10分の1、DeepSeek で30分の1
`rtk gain` が表示した節約量	9,620万トークン（扱った出力の99.8%）	3億4,920万トークン（89%。DeepSeek の445回）

2026年10月時点で確認した内容です。

表のいちばん下の行と、「料金の変化」の行を見比べてください。RTK 自身は数千万〜数億トークンの節約を表示しているのに、料金は減っていません。 私は、この記事でいちばん大事なのはこの差だと考えています。RTK がうそをついているわけではありません。出力は本当に短くなっています。ずれているのは、「短くなった量」を「節約できたお金」と読んでしまう、こちらの受け取り方です。

もう1つ、先に書いておきます。2つの検証は、どちらも使った分だけ払う API の料金で比べています。Pro や Max などの定額プランで、利用上限に達するまでの時間が延びるかどうかは、どちらも測っていません。

RTKとは何か。「削減」しているのはコマンドの出力

RTK（Rust Token Killer）は、シェルのコマンドの出力を、AI が読む前に短くするツールです。 減らしているのは「コマンドの出力」で、料金そのものではありません。

RTK は、Rust で書かれた1つの実行ファイルで、100種類を超えるコマンドに対応しています。Claude Code では、フック（PreToolUse）という仕組みを使います。AI が git status を実行しようとすると、フックがそれを rtk git status に書き換えます。RTK は本物のコマンドを実行し、結果を短くまとめてから AI に返します。AI の側は、RTK があることを意識しません。

短くするやり方は、コマンドの種類ごとに決まっています。

テスト（cargo test、pytest など）: 失敗したものだけを残し、成功したものは件数にまとめる
git log: ハッシュ、作者、件名だけにする
git push: 進み具合の表示を消して、確認の1行だけにする
ls: 1行に1ファイルではなく、件数つきの木の形にする

「60〜90%削減」という数字は、こうしたコマンドごとの出力の減り方を指しています。RTK の README も、執筆時点では「bash の出力を最大90%減らす。それは請求額を90%減らすことと同じではない」と書いています。bash の出力は入力トークンの一部で、入力トークンは請求額の一部です。段を1つ下りるたびに、効果は薄まります。

ここで見落としやすいのが、フックが効くのは Bash ツールを通るコマンドだけという点です。Claude Code は、ファイルの読み込みに Read、検索に Grep と Glob という専用のツールを使います。これらは Bash を通らないので、RTK は手を出せません。README にもそう書かれています。

シェルのコマンドはBashとRTKを通ってAIに届き、ファイルの読み込みと検索はRead・Grep・Globの専用ツールを通ってRTKを経由せずに届くことを示した図

私は、RTK の説明を読むときは「何の何%なのか」を必ず確かめるようにしています。分母が「コマンドの出力」なのか「請求額」なのかで、同じ90%でも意味がまったく違うからです。

導入の仕方（簡単に）

入れ方は、3つの段で終わります。

RTK を入れる。 macOS は brew install rtk、Windows は winget install rtk-ai.rtk（PATH の設定は不要）です。GitHub の Releases から自分の OS 用のファイルを取り、PATH の通った場所に置く方法もあります
Claude Code につなぐ。 rtk init -g を実行すると、settings.json にフックが入り、RTK.md が作られます。そのあと Claude Code を再起動します
動いているか確かめる。 rtk --version でバージョンが表示され、rtk gain で集計の画面が出れば入っています

注意が2つあります。cargo install rtk で入れると、同じ名前の別のソフト（Rust Type Kit）が入ることがあります。rtk gain が動かなければ、別のものが入っています。もう1つは Windows です。README では、v0.37.2 以降はネイティブの Windows でもフックがそのまま動くとされています。一方、公式ドキュメントのトラブル対処のページには、「ネイティブの Windows ではフックが動かない」という説明が残っています。README の説明に照らすと、これは v0.37.2 より前の動きです。

私は Windows で、Releases の zip から rtk.exe を C:\Users\ユーザー名\.local\bin\ に置き、Git Bash の ~/.bash_profile で PATH を通してから rtk init -g --auto-patch を実行する流れで入れました。私の環境では、ここで1つつまずきました。settings.json に入ったフックの command が rtk hook claude のままだと認識されず、次のように rtk.exe の場所を省略せずに書き直す必要がありました。

json "command": "C:/Users/ユーザー名/.local/bin/rtk.exe hook claude"

実際に動いている私の settings.json は、次のとおりです。

Claude Codeのsettings.jsonのPreToolUseに、Bashを対象にしてrtk.exeの場所を省略せずに書いたRTKのフックの設定

原因までは確かめていませんし、すべての Windows の環境でこうなるとは限りません。rtk gain の数字がいつまでも増えないときは、この書き方を試してみてください。

外すときは rtk init -g --uninstall で、フックと RTK.md と settings.json の設定が消えます。OS ごとの細かい手順は、公式の README を見るのが確実です。

検証1: 86のタスクで比べると、低いeffortで料金が増えた

JetBrains の検証では、effort（考える深さの設定）が低いときに料金が増え、高いときは差がありませんでした。 料金が下がった条件は、1つもありません。

この検証は、RTK を rtk init -g で入れたそのままの状態と、何も入れていない Claude Code とで、同じタスクを解かせています。フックが実際に動いたことを、RTK 自身の記録で1回ずつ確かめているのが特徴です。「RTK が効かなかった」のか「RTK が動いていなかった」のかを、分けて見られるようにしてあります。

結果で目を引くのは、RTK が唯一短くしているはずの「新しい入力」が、ほとんど動かなかったことです。代わりに増えたのは、やりとりの回数とキャッシュ読み込みでした。フックがコマンドを多く書き換えたタスクほど、料金の増え方も大きくなっています。

原因は1つではありません。記録を調べた結果として挙がっているのは、次の3つです。

find の条件を組み合わせた書き方が、書き換えのあとでエラーになり、やり直しが起きた
短くされた出力では足りず、読み直しが起きた
もともとのばらつき

JetBrains はこれを、派手な失敗ではなく「薄く広くかかる税のようなもの」と表現しています。品質のほうは、どちらの effort でも差がありませんでした。RTK がテストの結果を削りすぎて AI が間違える、といった心配された失敗は、ほとんど起きていません。

2つの検証で、RTK gainが表示した節約量（9,620万トークン、3億4,920万トークン）と料金の変化（+7.6%、+17%）を並べた図

私がこの検証でいちばん参考になると感じたのは、お金をかける前の試算です。過去の記録を調べて、「RTK が入っていたら、どこまで触れたか」を先に数えています。その答えが、入力トークンのごく一部でした。試算の時点で、結果はほぼ見えていたことになります。

検証2: 1,740回の比較では、モデルによって結果が分かれた

Quesma の検証では、Claude Code と Fable の組み合わせで差がなく、OpenCode と DeepSeek の組み合わせでは料金が増えました。 結論は「汎用の節約ツールとしては勧めない」です。

こちらは、端末の操作が多い課題集を選んでいます。RTK にとって有利なはずの条件です。各タスクを、RTK なしで5回、ありで5回ずつ実行しています。

合計の金額だけを見ると、Fable では RTK ありのほうが少し安くなりました。ところが、その差のほとんどは、たった1つのタスクから来ていました。そのタスクでは、RTK ありのほうが半分ほどのやりとりで終わっています。ほかのタスクでの差は、1%に届きません。同じタスクを DeepSeek で解かせると、逆に RTK ありのほうがやりとりが増え、高くつきました。

DeepSeek で料金が増えた理由は、はっきりしています。1回あたりの入力は少し減ったのに、やりとりの回数がそれ以上に増えたからです。やりとりが1回増えると、そこまでの会話がもう一度読み込まれ、AI の出力も増えます。出力を削って浮いた分は、すぐに消えてしまいます。

コマンドの出力を短くすると情報が足りなくなり、読み直しでやりとりの回数が増えて、料金が減らなくなる流れを示した図

不具合が料金を押し上げた例もあります。AI が使った find のオプションに、RTK の find が対応していませんでした。フックは、やり直しのたびに同じ書き換えをくり返します。その結果、339回続けて失敗し、その1回の料金は RTK なしの約9倍になりました。Quesma は、検証のあとに出た 0.46.0 でこの不具合は直ったと書いています。

私は、この2つ目の検証で「モデルによって結果が違う」ことが分かったのが大きいと見ています。性能の高いモデルは、head や tail を自分で使って、出力をもともと短くしています。Claude Code の Bash の呼び出しの約半分は、そうやって自分で出力を絞っていました。RTK が削れる余地が、最初から小さいわけです。

なぜ料金が下がらないのか。4つの理由

理由は4つあります。RTK が届く範囲が狭いこと、入力の大半が単価の安いキャッシュ読み込みであること、節約量の数え方が請求と合っていないこと、やりとりが増えることです。

1. RTKが届くのは、入力のごく一部

AI に渡る入力には、こちらの指示、システムの指示、これまでの会話、ツールの出力が入っています。RTK が短くできるのは、このうち「Bash を通ったコマンドの出力」だけです。しかも、Bash で実行されるコマンドのうち、RTK が書き換えるのは一部です。python3 のような対応していないコマンドや、パイプでファイルに書き出す形のコマンドは、そのまま通ります。

AIに渡る入力トークンの帯のうち、RTKが届く部分を70%削っても入力の約3%にしかならないことを示した図

2. 入力の大半は、単価の安いキャッシュ読み込み

Claude Code は、やりとりのたびに、それまでの会話をまるごと送り直します。ただし、前回と同じ部分はプロンプトキャッシュから読み込まれ、通常の入力よりずっと安い単価で計算されます。コマンドの出力も、2回目以降はこのキャッシュ読み込みになります。つまり、出力を1,000トークン削っても、その後のやりとりで浮くのは、1,000トークン分の通常の料金ではありません。

3. `rtk gain` は「削った文字数」を数えている

rtk gain の数字は、「元の出力の文字数から、短くした後の文字数を引いて、4で割ったもの」です。請求されたトークンを数えているわけではありません。ここから、2つのずれが生まれます。

もともと届かなかった分まで数える。 Claude Code は、大きすぎるツールの出力を自分で切り詰めます。1.2MB の CSV を読んだとき、RTK は「32万トークン節約」と記録しましたが、RTK がなくても AI に渡るのは数千トークンでした
頼まれていない分まで数える。 head -1 でファイルの1行目だけを読んだコマンドに対して、ファイル全体との差が「節約」として記録された例があります

これが、ここまでに書いた原則の1つ目です。ツールが表示する「節約したトークン」は、そのツールがなかった場合の想定との差で、請求額の差ではありません。 JetBrains は「ツールが自己申告する節約量は、想定についての主張であって、請求額についての主張ではない」とまとめています。

4. 出力を削ると、やりとりが増えることがある

原則の2つ目です。AI のコーディングの料金は、キャッシュ読み込みとやりとりの回数で決まる部分が大きく、出力を削っても、やりとりが増えれば打ち消されます。

同じ機能を、何も入れない Claude Code、RTK、別の節約ツールで作り比べた動画があります。RTK が出力を切ったあとに何が起きたかが、記録つきで分かります。

この動画では、RTK を入れた回のほうが、何も入れない回よりトークンの合計が5.5%多くなりました。AI への要求の回数はどちらも111回で同じでしたが、RTK ありのほうが1回あたりの要求が大きくなっています。RTK がビルドの出力を切り詰めて最後の結果が見えなくなり、AI がもう一度ビルドを実行した場面も確認されています。同じ作者の以前の比較では RTK のほうが少なく済んでいて、作者自身が「1回ずつの比較では言い切れない」と断っています。

RTK の開発チームも、追加のやりとりが起きる場合があることを認めていて、改善を進めていると説明しています。私は、この4つのうち、いちばん見落とされやすいのは2つ目だと感じています。「トークンが減れば、同じ割合で料金が減る」という前提が、キャッシュのある環境では成り立ちません。

それでもRTKが効く場面

RTK が向いているのは、長いログを出すコマンドを何度も実行する作業と、コンテキスト（AI が一度に覚えておける量）を空けておきたい場面です。 料金を一律に下げる道具としてではなく、使いどころを選ぶ道具として見るのがよいと私は考えています。

効きやすい条件を挙げます。

テストやビルドのログが長い。 何百件もテストが通る表示を、失敗した数件だけにできます。これは RTK がいちばん得意とするところです
Bash を多く使う使い方をしている。 git、docker、kubectl のようなコマンドを AI に何度も実行させる作業です
コンテキストがすぐ埋まる。 出力が短ければ、同じセッションで扱える量が増えます。これは料金とは別の利点です
出力を自分で絞らないモデルを使っている。 Quesma は、RTK は以前のモデルではもっと役に立っただろうと書いています

Claude Code の公式ドキュメントも、フックでデータを前もって絞る方法を紹介しています。1万行のログを AI に読ませる代わりに、フックでエラーの行だけを抜き出して渡す、という例です。「AI に渡す前に出力を絞る」という考え方そのものは、公式にも認められたやり方です。

逆に、効きにくいのは次のような使い方です。

ファイルを読んで直す作業が中心で、コマンドをあまり実行しない
エディタの拡張機能から使っていて、専用のツール（Read、Grep、Glob）が中心になる
料金の大半がキャッシュ読み込みになっている

2つの検証をした側も、結果は課題集でのものだと断っています。1つのタスクでは、RTK でやりとりが半分になった例もありました。「効いた」という体験談に出てくる79.6%や91.9%といった数字は、どれも rtk gain の表示です。うそではありませんが、料金を比べた数字ではありません。自分の作業がどちらに近いかは、測ってみないと分かりません。

自分の環境で確かめる方法

確かめ方は、同じ作業を RTK あり・なしで複数回ずつ行い、料金か利用量で比べることです。 rtk gain の数字は、この比較には使いません。これが原則の3つ目です。

手順は次のとおりです。

ふだんよくやる作業を1つ決める。 テストを直す、小さな機能を足す、など、何度でも同じ条件で始められるものにします
RTK なしで、複数回やる。 毎回、新しいセッションで同じ指示から始めます。終わったら、そのセッションの利用量を記録します
RTK ありで、同じ回数やる。 条件は、RTK の有無だけを変えます
フックが動いたかを確かめる。 rtk gain --history で、その作業のコマンドが記録されているかを見ます。記録がなければ、「効かなかった」のではなく「動いていなかった」ことになります
料金か利用量で比べる。 差が、同じ条件での1回ごとのぶれより小さければ、「差はない」と判断します

RTKの効果を確かめる5つの段。作業を1つ決める、RTKなしで複数回、RTKありで同じ回数、フックが動いたか確かめる、料金か利用量で比べる

1回ずつの比較で決めないことが大切です。JetBrains の検証では、同じタスクを同じ条件でやり直しただけで、料金が中央値で22%ぶれました。最初の10タスクを1回ずつ比べたときは「RTK ありが35%高い」と出ましたが、3回ずつに増やすと、その差はぶれの中に消えています。

利用量は、Claude Code の /usage で見られます。API で使っている人には、セッションのトークンの使用量と料金の見積もりが表示されます。定額プランの人には、プランの上限に対する使用状況が表示されます。

RTK には、料金の内訳を見る rtk cc-economics というコマンドもあります。キャッシュの読み込みと書き込みの量を、RTK の節約量と並べて見られます。私は、RTK を入れたら rtk gain より先にこちらを見ることをおすすめします。自分の料金のどこが大きいのかが分かれば、削るべき場所も分かるからです。

料金を本当に減らすには、大きいところから見直す

節約ツールを足す前に、料金の大半を占めている部分を先に見直すほうが効きます。 効果が大きく、手間が少ない順に並べます。

関係のない作業に移るときは、セッションを切り替える。 /clear で新しく始めます。会話が長いほど、やりとりのたびに読み込まれる量が増えます。前の作業の会話が残っていると、その後のすべてのやりとりで余分に払うことになります
毎回読み込まれる指示ファイルを短くする。 CLAUDE.md はセッションの最初に読み込まれ、関係のない作業のときも入ったままになります。公式ドキュメントは、200行より短く保ち、特定の作業だけに必要な手順はスキルに移すことを勧めています
モデルと effort を作業に合わせる。 公式ドキュメントでは、ふだんのコーディングには Sonnet、複雑な設計の判断には Opus、という使い分けが勧められています。考える量（thinking）のトークンは出力として計算されるので、簡単な作業では effort を下げると減らせます
指示を具体的に書く。 「このコードを良くして」のようなあいまいな頼み方は、広い範囲の読み込みを招きます。ファイルと関数を名指しすれば、読む量が減ります
長い出力が出る作業は、サブエージェントに任せる。 テストの実行やログの処理を任せると、長い出力はサブエージェントの側に残り、元の会話には要約だけが戻ります

この順番にしたのは、1と2が「すべてのやりとりにかかる部分」だからです。コマンドの出力は、出たときにしか増えません。会話の長さと指示ファイルの長さは、やりとりのたびに効いてきます。同じ手間をかけるなら、毎回かかるほうを先に削るのが筋だと私は考えています。

これらの方法は、Claude Code の公式ドキュメントにまとまっています。使っていない MCP サーバーを止める、/context で何が場所を取っているかを見る、といった方法も載っています。

よくある質問

RTK を入れると Claude Code の料金は下がりますか？

料金で比べた2つの検証では、下がりませんでした。条件によって、差がないか、少し増えています。ただし、どちらも課題集での結果です。テストやビルドのログが長い作業では違う結果になる可能性があるので、自分の作業で比べて確かめてください。

rtk gain に表示される「節約したトークン」は正しいですか？

「コマンドの出力をどれだけ短くしたか」の目安としては使えます。ただし、文字数を4で割った推定で、請求されたトークンではありません。RTK がなくても AI に届かなかった分まで含まれることがあるので、節約できた金額としては読めません。

RTK はどんな作業なら効果がありますか？

テストやビルドのように長いログを出すコマンドを、AI に何度も実行させる作業です。コンテキストを空けておきたいときにも役に立ちます。ファイルの読み書きが中心の作業では、RTK を通らない専用のツールが使われるので、効果は小さくなります。

RTK を入れると、回答の品質は下がりますか？

1つ目の検証では、品質に差はありませんでした。2つ目の検証では、合格率が1〜2ポイント下がりましたが、小さな差です。品質が落ちるというより、情報が足りずにやりとりが増える形で影響が出ます。

Pro や Max の定額プランでも、RTK を入れる意味はありますか？

2026年10月時点では、定額プランで利用上限に達するまでの時間が延びるかを、RTK あり・なしで比べた検証は見つかっていません。2つの検証は、どちらも API の料金で比べたものです。入れる場合は、/usage に表示されるプランの使用状況を、同じ作業のあり・なしで見比べてください。

この記事の更新方針

次のことが変わったら、内容を見直します。確認時点は2026年10月です。

RTK あり・なしで料金を比べた、新しい検証が公表されたとき（冒頭の表に足します）
定額プランの利用上限への影響を測った検証が出たとき
RTK が、Read・Grep・Glob などの専用のツールの出力にも対応したとき
RTK の節約量の数え方（rtk gain）が変わったとき
追加のやりとりを減らす改善が RTK に入り、それを確かめた検証が出たとき
Claude Code のキャッシュの単価や、利用量の表示（/usage）が変わったとき
Windows でのフックの動きについて、公式の説明がそろったとき

「節約した」という表示より、請求額を見る

RTK は、やると言っていることをきちんとやる道具です。コマンドの出力は短くなり、品質もほとんど落ちません。ただ、「出力が短くなること」と「料金が下がること」のあいだには、いくつも段があります。

RTK が短くするのは、Bash を通るコマンドの出力だけ。入力全体から見ると一部
入力の大半は、単価の安いキャッシュ読み込み
rtk gain は削った文字数からの推定で、請求額ではない
出力を削った結果、やりとりが増えると、浮いた分は消える
料金で比べた2つの検証では、下がらなかった

RTK をすでに入れている人は、外す必要も、信じ込む必要もありません。まず rtk cc-economics か /usage を開いて、自分の料金のどこが大きいのかを見てください。そのうえで、よくやる作業を1つ選び、RTK あり・なしで数回ずつ比べる。続けるか外すかは、その数字で決めれば十分です。

これは RTK に限った話ではありません。トークンを節約すると名乗る道具に出会ったら、「その数字は、何と何を比べた差なのか」を確かめる。それだけで、表示に振り回されずに済みます。