RTK：AIコーディングエージェントのtokenを節約するCLIプロキシ

Wed, 27 May 2026 13:52:01 +0800

rtk-ai/rtk は、AIコーディングエージェント向けのコマンドラインプロキシです。考え方はかなり直接的です。多くの agent は開発中に ls、cat、grep、git status、git diff、テストコマンド、ビルドコマンドを頻繁に呼び出しますが、その生の出力は長く、重複も多くなりがちです。RTK は、その出力が LLM のコンテキストに入る前にフィルタリングと圧縮を行い、モデルがより短く有用な結果を読めるようにします。

プロジェクト： rtk-ai/rtk

解決しようとしている問題

AIコーディングツールで本当に高くつくのは、モデル呼び出し回数だけではありません。コンテキストに詰め込まれる無効な情報もコストになります。

たとえば：

ls -la は大量の権限、時刻、無関係なファイルを出力することがあります。
git diff には重複したコンテキストが多く含まれることがあります。
pytest、cargo test、npm test が失敗したときに重要なのは、失敗したケースとスタックトレースであり、すべての成功項目ではありません。
docker ps、kubectl pods、aws コマンドはフィールドが多い一方、agent が必要とするのは少数の重要情報だけです。

これらの出力がそのままモデルのコンテキストに入ると、token はすぐに消費されます。RTK の目的はこれらのコマンドを置き換えることではなく、コマンドと AIコーディングエージェントの間に「圧縮プロキシ」を挟むことです。

RTK の基本的な動き

RTK の README では、コマンド出力が LLM context に届く前に結果をフィルタリングして圧縮するツールとして説明されています。Rust 製の単一バイナリで、多くの一般的な開発コマンドに対応し、低オーバーヘッドを強調しています。

主に次の4つの処理を行います。

Smart Filtering：コメント、空白、定型文、価値の低いノイズを取り除く。
Grouping：ディレクトリ、エラー種別、ステータスなどで似た項目をまとめる。
Truncation：重要なコンテキストを残し、重複や重要度の低い部分を切る。
Deduplication：重複ログを短いカウント表現に折りたたむ。

agent から見ると、コマンド自体は見慣れた開発コマンドのままです。変わるのは、モデルに返される結果が短くなる点です。

対応しているコマンド

RTK が対象にするのは、日常的な開発現場でよく使うコマンドです。

ファイル確認：rtk ls、rtk read、rtk find、rtk grep
Git：rtk git status、rtk git log、rtk git diff
GitHub CLI：rtk gh pr list、rtk gh pr view、rtk gh issue list
テスト：rtk pytest、rtk go test、rtk cargo test、rtk vitest、rtk playwright test
ビルドと lint：rtk lint、rtk tsc、rtk next build、rtk cargo clippy
コンテナとクラウド：rtk docker ps、rtk docker logs、rtk kubectl pods、rtk aws sts get-caller-identity
データとログ：rtk json、rtk deps、rtk env、rtk log

この種のツールは、agent がコマンド出力を高頻度で読む場面に向いています。コードを書くためのツールではなく、agent が読むノイズを減らすためのツールです。

インストールと接続方法

README にはいくつかのインストール方法が示されています。

Homebrew：

`1`	`brew install rtk`

Linux/macOS のクイックインストール：

`1`	`curl -fsSL https://raw.githubusercontent.com/rtk-ai/rtk/refs/heads/master/install.sh \| sh`

Cargo：

`1`	`cargo install --git https://github.com/rtk-ai/rtk`

インストール後は、まずバージョンと統計情報を確認できます。

1
2

rtk --version
rtk gain

AIコーディングツールに接続するには、初期化コマンドを使います。

rtk init -g
rtk init -g --gemini
rtk init -g --codex
rtk init -g --agent cursor
rtk init --agent windsurf
rtk init --agent cline

初期化後は、対応する AI ツールを再起動する必要があります。hook に対応した agent では、Bash コマンドが実行前に書き換えられます。たとえば git status は rtk git status になり、agent は圧縮された出力を受け取ります。

注意点

RTK の効果は、agent が本当に shell コマンド経由で情報を読んでいるかに左右されます。

README では、Claude Code の組み込み Read、Grep、Glob のようなツールは Bash hook を通らないため、RTK によって自動的には書き換えられないと説明されています。RTK を介入させるには、cat、head、tail、rg、grep、find などの shell コマンドを使うか、rtk read、rtk grep、rtk find を直接呼び出す必要があります。

ここは重要です。RTK はすべての agent I/O を透明に圧縮するものではありません。shell コマンド層のプロキシに近いものです。

Windows ユーザーについても、README では rtk.exe をダブルクリックするのではなく、PATH に置いて Command Prompt、PowerShell、Windows Terminal から使うことを推奨しています。完全な hook 体験が欲しい場合は、WSL の方が自然だとも述べています。

向いているユーザー

RTK は次の3種類のユーザーに向いています。

AIコーディングを多用するユーザー：毎日 agent に多くの git、rg、テスト、ビルドコマンドを実行させる人。
大規模リポジトリのユーザー：コマンド出力が数百行になり、agent が無関係なコンテキストに埋もれがちなチーム。
token コストとコンテキストウィンドウを気にする人：モデルの注意を失敗、変更、重要ファイルに向けたい人。

プロジェクトが小さい場合や、agent が主に IDE 組み込みツールでファイルを読む場合、RTK の効果はそれほど強く感じないかもしれません。真価を発揮するのは、コマンドライン出力が長く、かつ頻繁に発生する開発フローです。

私の見方

RTK の方向性は実用的です。多くの AIコーディングワークフローは、より強いモデル、より大きなコンテキスト、より長いタスクに注目しています。しかし開発現場にはもっと素朴な問題があります。agent は必要以上に多くのものを読んでしまうことが多いのです。

コマンド出力を先に圧縮してからモデルに渡せば、token 消費を減らせますし、ノイズによってモデルが誤った方向へ引っ張られる可能性も下げられます。

ただし魔法のスイッチではありません。RTK をうまく使うには、agent の作業を shell コマンド寄りにし、現在のツールで hook が本当に効いているか確認する必要があります。Codex、Claude Code、Gemini CLI、Cursor、Windsurf のような場面では、RTK は試す価値のある「コンテキスト節流器」です。開発コマンド自体は変えずに、agent が読む結果をよりきれいにします。

RTK on KnightLiブログ