シェル出力を圧縮する RTK を Claude Code に入れた翌日、rtk gain を見たら 80.3% 減と出ました。253 コマンドで 142.6K トークンの削減。ずいぶん効いているように見えます。

ただ、内訳の 96% はファイル読み取りでした。RTK を通ったシェル出力の集計なので、セッション全体が 80.3% 減ったわけでもありません。合計だけ眺めるより、自分が何を読ませていたのかを見るほうが面白い数字でした。

きっかけは Shin | Decision-OS さんの X の記事「なぜ同じAIを使っているのに、差が開いていくのか」(2026-08-13 投稿、2026-08-21 取得)。トークン消費を減らすツールを、何を減らすものなのかで並べていたのが気になりました。

出力を減らす道具と、読み直しを減らす道具

記事で紹介されていたのは次の 4 本です。どれもトークン消費に関わりますが、余計なコードを作らせないものと、できた出力を小さくするものでは使いどころが違います。説明とスター数は 2026-08-21 に確認したものです。

減らしたいもの ツール 記事での説明 GitHub スター
不要なコード Ponytail 不要な実装を作らせない 106,742
不要な出力 RTK AI が読む前にツール出力を小さくする 76,832
毎回読む必要のない指示 AGENTS.md Compactor 必要なときだけ読む文書へ移す 2
前回と同じ調べ直し Output Surface Integrity (OSI) 完了したことと再開に必要な情報を整理する 6

後ろの 2 本は投稿者自身が作ったものです。Compactor では、AGENTS.md の毎回読み込む部分を 20,664 文字から 14,284 文字に減らしたそうです。30.9% 減ですが、条件付きの指示を別の場所へ移したもので、情報を捨てたわけではないと説明されています。

大きく減っていたのは cat 相当の操作だった

RTK と Ponytail は 2026-08-20 に導入しました。RTK には削減量を見る rtk gain があるので、翌日に実行した結果を載せます。バージョンは rtk 0.45.0 です。

$ rtk gain
RTK Token Savings (Global Scope)
════════════════════════════════════════════════════════════

Total commands:    253
Input tokens:      177.5K
Output tokens:     35.2K
Tokens saved:      142.6K (80.3%)
Total exec time:   1m37s (avg 383ms)
Efficiency meter: ███████████████████░░░░░ 80.3%

By Command
────────────────────────────────────────────────────────────────────────
  #  Command                   Count   Saved    Avg%    Time  Impact
────────────────────────────────────────────────────────────────────────
 1.  rtk read                     28  136.4K   42.1%     0ms  ██████████
 2.  rtk grep                     35    2.2K   32.2%    1.2s  ░░░░░░░░░░
 3.  rtk ls -la /Users/nna...      2     967   67.2%     9ms  ░░░░░░░░░░
 4.  rtk git commit               21     727   49.8%    66ms  ░░░░░░░░░░

導入から 2 日分の数字です。合計 142.6K のうち、136.4K が rtk read による削減でした。シェルからファイルを読む cat 相当の操作で、28 回、1 回あたり約 4.9K トークン減っています。

検索の grep は 35 回で合計 2.2K、git commit は 21 回で 727 トークン。実行回数はそれなりにありますが、削減量ではファイル読み取りに遠く及びませんでした。

元記事の図にも、Read / Grep / Glob のような組み込みツールは Bash のフックを通らない場合があると注記されています。Claude Code が専用ツールで読んだファイルは、この集計には入りません。同じファイルを読む作業でも、どのツールを通るかで RTK が効く範囲が変わります。

Ponytail は削減量を数える仕組みがなく、入れた効果はまだ測れていません。

長い手順書は、すでに別ファイルに分けていた

Compactor の例を見て、自分の指示ファイルも数えました。こちらは文字数ではなくバイト数です。

$ wc -c CLAUDE.md ~/.claude/CLAUDE.md ~/.claude/RTK.md
    2717 CLAUDE.md
    3808 /Users/nnasaki/.claude/CLAUDE.md
     961 /Users/nnasaki/.claude/RTK.md
    7486 合計

毎回読むファイルは合計 7,486 バイト。記事を書くときだけ読む手順書 .claude/skills/blog-write/SKILL.md は 23,496 バイトありました。

大きい手順書を必要なときだけ読む、という分け方はすでにしていました。Compactor がやっている整理に近いことを、手元ではスキルへの分割で行っていたようです。

手元で足りなかったのは引き継ぎ

4 種類を自分の作業に当ててみると、不要なコードとシェル出力にはツールを入れ、毎回読む指示も分けていました。次のセッションへの引き継ぎだけは、その場で書いていて、何を残すかが決まっていませんでした。

次に見直すなら、何が終わっていて、どこから再開すればよいかの書き残し方です。OSI を使うかは中身を読んでから考えます。スター数ではほかのツールと大きな差がありましたが、自分の手元で対処が足りていなかったのは、ちょうどこの部分でした。