rtk-ai/rtk
コマンドの出力を削ってからエージェントに渡し、読ませる量を減らす
どういうものか
AIのコーディングエージェントは、git status や npm test を自分で実行して、その出力を読んで次を決める。このとき出力は丸ごと文脈に積まれる。テストが1000件通ったログも、ls が返した数百行も、そのまま入る。rtk はコマンドとエージェントのあいだに入って、出力を削ってから渡す道具。本体は Rust の実行ファイル1つで、ランタイムの類は要らない。
削り方は、コマンドの種類ごとに4つの方針が使い分けられる。README の言葉では、雑音(コメント・空白・定型文)を落とす Smart Filtering、似たものをまとめる Grouping(ファイルはディレクトリごと、エラーは種類ごと)、関連する文脈は残したまま重複を切る Truncation、同じログ行を件数に畳む Deduplication。テストなら「失敗だけを残し、通ったものは件数に畳む」、ファイルを読むときは「本文の全部ではなく、構造と宣言部分を優先する」といった具合になる。対応するコマンドは100種類以上あり、git・GitHub CLI・テストランナー・ビルドやリント・パッケージマネージャ・AWS・コンテナまで、分野ごとに並べられている。
呼び出し方が少し変わっている。使う側がコマンドを打ち替えるのではなく、フックがエージェントの Bash コマンドを実行前に書き換える。README の説明では git status が rtk git status に置き換わる。初回に一度だけ設定を入れる必要はあるが、そのあとは打ち方を変えないまま、通り道だけが差し替わることになる。
rtk recall で読み戻せる作りになっている。どんなときに使うか
テストやビルドのログで会話が埋まるとき
失敗が1件でも、ログは数百行出る。エージェントはその全部を読み、次の質問のときも文脈として抱えたままになる。rtk は通ったテストを件数に畳むので、残るのは失敗のところだけになる。長い作業を1つの会話で続けたいときほど効いてくる。
大きなリポジトリで、状況確認だけで文脈が埋まるとき
ファイル数の多いリポジトリでは、git status や ls を1回打つだけで数百行が返る。エージェントは作業のたびにこれを読む。ディレクトリごとにまとめてから渡せば、同じことを確認しても、残る量が変わる。
注意点
「最大90%」は、Bash の出力に対しての数字。 README は “up to 90% of the bash output” と書いており、請求額が9割減るという意味ではない。同じ README に、削減は「各段階で薄まる(The reduction dilutes at every step)」と明記されている。加えて、rtk が表示するトークン数はバイト数を4で割った推定値だとも書かれている。絶対の数は概算として読む(README は、割合のほうは信頼できるとしている)。
削るということは、情報が落ちるということ。 通ったテストは件数になり、ファイルは本文より構造が優先される。ふだんは邪魔なものが減って助かるが、落ちたところに答えがある場面では、まず気づけない(失敗したときや切り詰めたときは読み戻せるが、それ以外は自分で打ち直すことになる)。全文が要ると分かっている作業では、切って使うほうがよい。
フックの外側は書き換わらない。 README は、Claude Code の組み込みツールである Read・Grep・Glob は Bash のフックを通らないため自動では書き換わらない、としている。エージェントがファイルを読む経路がそちらに寄っているほど、効果は小さくなる。また README は Windows のセットアップの注意として、一部のフィルタが ripgrep(rg)を呼ぶため、入っていないと警告が出ると書いている。
ライセンスは Apache-2.0。 手元で実行するぶんにも、製品に組み込むぶんにも扱いやすい部類になる。日本語の README も用意されている。