Shin | Decision-OS さんの X の記事「なぜ同じAIを使っているのに、差が開いていくのか」(2026-08-13 投稿、2026-08-21 取得)を読みました。AI のトークン消費を減らすツールを4本並べた記事ですが、ツールの優劣ではなく「それぞれが AI の仕事の別の場所にある摩擦を減らしている」という並べ方をしています。

コーディングエージェントを日常的に使っていて、使用量の表示が気になる人向けです。先に要点だけ:

  • 削減ツールは「書く・読む・毎回読まされる・やり直す」のどの無駄を削るかで分類できる。別の分類のツールは効果が足し合わさり、同じ分類に2本入れても重なるだけ
  • 4本のうち1本(シェル出力を圧縮する RTK)を手元に入れて測ったら、253 コマンドで 142.6K トークン削減(80.3%)。ただしその 96% はファイル読み取り1種類が稼いでいた
  • 自分の運用にどの分類の手当てが無いかを見ると、次に入れるものが決まる。人気(スター数)は分類の重要度とは別に動く

4つの無駄と、それぞれを削るツール

以下は上記 URL、2026-08-21 取得。記事が挙げている摩擦は「不要なコードを書く。不要な出力を読む。今の仕事とは関係ないルールまで毎回読む。前回どこまで終わったのか分からず、次の AI がもう一度調べ直す」の4つです。ツールとの対応を表にするとこうなります。

摩擦 ツール 何をするか(記事の説明) GitHub スター(2026-08-21)
不要なコードを書く Ponytail 不要な実装をそもそも作らせない 106,742
不要な出力を読む RTK ツール出力が AI のコンテキストへ入る前に小さくする 76,832
関係ないルールを毎回読む AGENTS.md Compactor 毎回読み込む必要のない指示を常時領域から外す 2
前回の探索をやり直す Output Surface Integrity (OSI) 仕事を終えた後、次の AI が同じ探索をしなくて済むよう完了・再開状態を整理する 6

後ろの2本は投稿者自身の自作です。記事にも「優劣を比較しているのではない」と断りがあります。Compactor については、自分の AGENTS.md で毎回読み込む部分を 20,664 文字から 14,284 文字(30.9% 減)にした、ただし「情報を 30.9% 捨てたわけではない」、条件付きの規則を外に出して必要なときに読ませる形にした、と書かれています。

シェル出力の圧縮で減ったのは、ファイル読みだけだった

4本のうち RTK と Ponytail は 2026-08-20 に手元の環境(Claude Code)へ入れました。RTK は rtk gain で削減量が取れるので、その出力を貼ります(2026-08-21 実行、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日分、253 コマンドで 142.6K トークンの削減です。ただし内訳を見ると、136.4K(96%)は rtk read(シェルからのファイル読み取り。cat 相当で、1回あたり約 4.9K トークン減)の28回が稼いでいて、35回走った grep は合計 2.2K しか減っていません。git commit は21回で 727 トークンです。

もう1つ、元記事の図(画像内、英文)に、Read / Grep / Glob のような組み込みツールは Bash のフックを迂回することがあり、すべてのツール出力が圧縮されるわけではない、という注記があります。Claude Code はファイル読み取りや検索を専用ツールで行い、シェルを経由しません。RTK が効くのはシェルを通った出力だけなので、専用ツールで読んだ分は上の数字に入っていません。どちらの経路が多いかは、手元のログを見ないと分かりません。

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

Compactor の 30.9% と並べる対照として、手元で毎セッション読み込まれている指示ファイルの大きさも数えました。

$ 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 バイトで、常時の3倍あります。この分け方は Compactor がやっている「条件付きの規則を外へ出す」と同じ形を、ハーネスの仕組み(スキルは必要なときだけ読む)で手作業にしたものです。

自分の運用の空白の探し方

ここからは見立てです。

上の実測から言えるのは、シェルから大きなファイルを読む場面が無い人には、この圧縮はほとんど効かないだろう、ということです。

この記事の使いどころは、ツールを選ぶことより、自分の運用を4つの摩擦に当てて空白を探すことだと思います。手元では「不要なコードを書く」「不要な出力を読む」「関係ないルールを毎回読む」の3つには手当てがありましたが、「前回の探索をやり直す」は、セッションをまたぐ引き継ぎを毎回その場で書いていて、型がありませんでした。軸に載せて初めて気づいた空白で、次に手を付けるのはここです。OSI をそのまま入れるか、完了状態を書き残す型を自分で決めるかは、OSI を読んでから決めます。

スター数と摩擦の重要度は独立に見えます。2スターと10万スターが同じ表に並びますが、後ろの2本が座る「指示の整理」「完了状態の整理」は、道具が無くても各自の手作業で何となく回ってしまう領域です。無駄は大きいが手作業で何となく回るので、ツールの需要が立たない、と読んでいます。

RTK の内訳が1種類に偏っていたのは、削減ツールを入れたあとで必ず見るべきところだと思います。合計の 80% という数字だけを見ると全体が軽くなった気がしますが、実際に軽くなったのは特定の操作1つでした。

次にやること

  • 自分の運用を「不要なコードを書く」「不要な出力を読む」「関係ないルールを毎回読む」「前回の探索をやり直す」の4行に当て、手当てが無い行を見つける
  • シェル出力の圧縮を入れるなら、先に自分がファイルをシェル経由で読んでいるかを確かめる。専用ツールで読んでいる分には効かない
  • 削減ツールを入れたら、合計ではなく内訳を見る。手元では合計 80% のうち 96% が1種類の操作だった