RTKを個人開発で試した。コマンド出力の削減量と実行時間を比べる

RTKはコマンド出力を短くするツールです。AIに渡るテキストを減らせると聞き、実際にどの出力が変わるのか、自分の個人Gitプロジェクトで比べました。

2026年9月28日にWSL2上で3種類のコマンドを試すと、Gitの状態表示と差分は短くなり、検索は変わりませんでした。一方、RTKを通したコマンドは実行時間が長くなりました。出力が短くなることと、AIの仕事が速く終わることは別です。

その後、このブログの作業でも普段使いを始めました。10月5日までの8日分を集計すると、履歴に残ったコマンド出力は推定40.1万トークン相当、約14.5%減っていました。詳しく読む時は元の出力を取る、という使い方での結果です。

WSL2で同じコマンドを7回ずつ実行した

環境はWSL2 / Linux x86_64、RTK v0.50.0です。通常のコマンドとrtkを付けたコマンドをそれぞれ1回ウォームアップし、その後7回ずつ、実行順を交互に変えました。検索条件と対象範囲もそろえ、7回の出力が同一であることを確かめています。

出力は標準出力のUTF-8バイト数、時間はコマンド開始から終了までです。

対象	通常の出力	RTKの出力	削減率
Gitの状態表示	184 B	88 B	52.17%
直前のコミットとの差分（対象を限定）	83,913 B	58,490 B	30.30%
テキスト検索（71ファイルで各1行一致）	4,880 B	4,880 B	0.00%

同じ試行の実行時間の中央値です。

今回のコマンド単体では、RTKを通すと約15〜24 ms長くなりました。RTKの起動や出力整形にかかった分が含まれます。
短い出力をモデルが読む時間や、AIの確認・再実行にどう影響するかは測っていません。

検索が変わらなかったのは、今回のように短い一致行が複数ファイルへ散らばる条件では、RTKが元の表示を保つためです。
状態表示も52%減っていますが、実際に減ったのは96 Bでした。

9月28日にCodexにRTKを普段使う設定を頼みました。一週間ほど経ったので、どれくらい減ったかも集計してもらいました。

対象は9月28日〜10月5日、8日分の2,152件の実行記録です。失敗や削減ゼロの記録も含め、出力が増えた分は差し引きました。

合計同士で割ると、削減率は約14.5%。

RTKのトークン数は、出力のバイト数を4で割って切り上げた推定です。
実際のモデル用トークナイザーで数えたものではなく、履歴に残らない操作もこの集計には入っていません。RTKの集計仕様

削減量の約75%は検索出力からでした。大きく減ったのは3種類。

2,152件のうち1,108件は、rtk proxyで短くせずに出力を取っています。
記事の根拠を拾う時、コードを細かく読む時、失敗原因を追う時まで省略すると困るので、元の内容を読んでいる。
何でも削って14.5%じゃなく必要な詳細は残した使い方で、この割合。

最初の3コマンド比較では、Gitの状態表示と差分は短くなり、検索は変わりませんでした。
コマンド単体の時間は延びるが、普段使いでも出力は約15%減らすことができた。
塵積で使い続ければ削減効果は大きくなると思うので、多少遅くなることは現状受け入れて使い続けてみようと思う。