はじめに：新しいモデルが来ても、トークン代は減らない
2026 年 6 月 9 日、Anthropic が新しいフラッグシップ Claude Fable 5 / Mythos 5（クロード フェイブル ファイブ / クロード ミトス ファイブ）を公開しました。料金は 100 万トークンあたり入力 $10・出力 $50。現行の主力 Claude Opus 4.8（入力 $5・出力 $25）のちょうど 2 倍です。
性能は上がりましたが、財布には逆風です。同じ作業を新モデルに任せれば、それだけでトークン代は単純計算で 2 倍。しかもエージェントにコードを書かせると、git diff やテストログ、インストールの出力で、AI に渡る文字は放っておくほど積み上がります。単価が 2 倍のうえに量も増える——ここで AI コーディングのコストがじわじわ効いてきます。
そこで考えました。モデルを変えずに、AI に渡すトークンそのものを減らせないか？ しかも、答えの質は落とさずに。
このテーマには、LLM に渡る前のテキストを圧縮する道具がいくつもあります。ただ、名前が似ていて、互いに引用し合い、効く場所も微妙に違う。そこで 4 つを実際に動かし、本物のリポジトリでトークン数を前後で測りました。
先に答えを言うと——迷ったら、まず rtk を入れておきましょう。もっと削りたいなら headroom も。 この 2 つで大半のトークンは削れます。実際、シェル出力の圧縮はちゃんと効き（中央値 80%、巨大な diff では 99% 超）、「効く理由」と「効かない場面」がツールごとにきれいに分かれていました。以下、理由と使い分けを実測しながら説明します。
この記事でわかること
- AI コーディングのトークン代を下げる 4 つのツール（rtk / lean-ctx / headroom / h5i）の違い
- 実測した削減率（コマンド別の前後比較）
- どの場面でどれを使えばいいか（初心者向けのたとえ付き）
- 圧縮しても答えの質は落ちないのか（公式ベンチで確認）
なぜ CLI 出力がトークンを食うのか
AI エージェント（Claude Code や Codex）は、git diff や grep -rn、インストーラのログを そのまま コンテキストに取り込みます。uv.lock を 1 回再生成しただけで diff が数千行 = 100 万トークン超、ということが普通に起きます。
LLM が本当に必要としているのは「何が変わったか」の要約であって、ロックファイルの全行ではありません。そこで「LLM に届く前に出力を間引く / 要約する」中間ツールが登場します。
4 つのツールはレイヤーが違う
最初に混乱したのがここでした。4 つとも「トークン削減」と書いてありますが、効く場所が違います。図にするとこうです。
| ツール | 層 | 役割 |
|---|---|---|
| rtk | シェル出力 | git / ls / grep / diff などの出力を圧縮 |
| lean-ctx | シェル出力＋ファイル読み | rtk と同じ役割の代替。さらにファイル読みに強い |
| headroom | API リクエスト | コンテキスト全体を圧縮する proxy（内部で rtk か lean-ctx を利用） |
| h5i | コマンド出力＋git | 出力を圧縮しつつ、原本と来歴を git に記録（後から復元可） |
引用関係も独特です。headroom は rtk バイナリを同梱してシェル出力の書き換えに使っています（README に「Huge thanks to the RTK team」と明記）。h5i は headroom の line-folding 技術を借りています（Apache-2.0）。競合というより、重ねて使う前提で作られています。
1 点だけ注意。rtk と h5i は同じ「コマンド出力」の層なので、同じコマンドに両方をかけると二重圧縮になります（しかも h5i が残す原本が rtk で削った後の出力になってしまう）。普段の使い捨ては rtk、記録も残したいコマンドだけ h5i、とコマンドごとに片方を選ぶのがコツです。headroom は別の層（会話）なので、こちらは気にせず重ねて OK。
計測方法
- トークンカウンタ: tiktoken の
o200k_base（GPT-4o 系）。Claude のトークナイザとは厳密には異なりますが、削減「率」の傾向は共通です。 - 対象リポジトリ:
chopratejas/headroom（Python + Rust、402 コミット、3,150 ファイル）を浅くクローン。 - 比較: 各コマンドを「素の出力」と「ツール経由」で実行し、トークン数を比較。
結果①：rtk（シェル出力の書き換え）
実測した結果です。
| ケース | 素のtok | rtk tok | 削減 |
|---|---|---|---|
git log -30 | 10,635 | 1,676 | 84.2% |
git diff HEAD~5（uv.lock 8,112行再生成を含む） | 1,171,880 | 5,914 | 99.5% |
ls -la | 1,599 | 303 | 81.1% |
find *.py | 10,400 | 180 | 98.3% |
grep 'def ' | 173,975 | 4,253 | 97.6% |
read（aggressive） | 31,165 | 2,017 | 93.5% |
env | 1,039 | 346 | 66.7% |
典型値で 60〜99%、中央値 ~80%（計測した全 10 コマンド）。 最大のインパクトは「巨大だが情報密度の低い出力」——lockfile の diff、再帰 grep、長いインストールログ——で、ここが 99% 級に落ちます（上表は代表 7 ケース）。
自分の実利用ログでも裏が取れた
rtk は累積セーブを自己集計しています（rtk gain）。筆者の実環境では:
Total commands: 3,527
Tokens saved: 5.2M (79.3%)
ベンチの中央値 ~80% と実運用 79.3% がほぼ一致。「測ったら出来すぎ」ではなく、日常的にこの水準で効いていることが分かります。
注意:
rtk readは既定が全文素通し（--level none）。削減したいなら-l minimal/aggressiveを明示します。
結果②：headroom（コンテキスト圧縮）
headroom の本体価値は proxy 層での「コンテキスト全体の圧縮」。これは headroom.compress() を直接呼べば proxy も実 API キーも不要でローカル実測できます。
会話履歴に検索結果・コミットログ・diff を "参照テキスト" として積んだ状態（合計 309,248 トークン）を、フルパイプライン（ML 圧縮 Kompress ＋ SmartCrusher ＋ CacheAligner）で圧縮:
| 指標 | 値 |
|---|---|
| tokens_before | 309,248 |
| tokens_after | 21,295 |
| 削減 | 93.1%（287,953 トークン減） |
役割が分かれている
試しているうちに分かったのですが、ツールの出力（tool_result）を積んだ会話では、headroom は router:excluded:tool と表示してそこを圧縮しませんでした。役割が分かれているのです。
ツールの出力（
git diffの生データなど）を削るのは rtk / lean-ctx の仕事。headroom が削るのは、会話そのものや、検索で取り込んだ長い文章のほう。
だから 2 つは競合しません。rtk が出力を 80% ほど削り、そのあと会話に残った本文を headroom がさらに 93% 削る、という重ね方になります。これはコードを読んでも確認できました。
注意：headroom の圧縮（Kompress）は要約なので、元の文章とは変わります。だから直近のやりとりや、いま読んでいるコードは触らない設計です。効かせるのは「古くなった文脈」だけ、と考えると安全です。
でも「消したら困る」のでは？ ── CCR（戻せる圧縮）
要約して捨ててしまうと、AI が後で詳細を欲しくなったとき困りそうです。headroom はそこに CCR（Compress-Cache-Retrieve、戻せる圧縮）という仕組みを持っています。コードを読むと、流れはこうです。
- 圧縮するときに、元データを手元にいったん取っておく
- 圧縮後の文章に「足りなければ取りに来てね」という目印を残す
- AI が必要と判断したら
headroom_retrieveを呼んで元データを取り戻す
headroom のドキュメント自身が「戻せる圧縮は、戻せない圧縮に勝つ」と書いています。攻めて削っても、最悪 AI が取りに来られるので事故りにくい、という発想です。
注意：この控え（キャッシュ）は既定で 5 分で消えます。あくまで「その場の保険」です。原本を長く残したいなら、後で出てくる h5i のほうが向いています。
圧縮しても精度は落ちないのか
「要約したら答えが悪くなるのでは？」という当然の疑問に、headroom は公式の精度テストで答えています。
| テスト | 圧縮なし | headroom | 差 |
|---|---|---|---|
| GSM8K（算数の推論） | 0.870 | 0.870 | ±0 |
| TruthfulQA（事実性） | 0.530 | 0.560 | +0.030 |
算数は変わらず、事実性はむしろ少し上がっています。余計なノイズが減って答えやすくなった、と読めます。公式は実際の作業でも、コード検索で 92%、障害調査で 92%、issue 分類で 73% 削れたとしていて、本記事の自前計測（93.1%）とも近い水準でした。
結果③：rtk vs lean-ctx 直接対決
lean-ctx は rtk の代わりに headroom へ差し替えられます（HEADROOM_CONTEXT_TOOL=lean-ctx）。同じコマンドを lean-ctx -c "..." と rtk で測った結果です。
| ケース | 素 | rtk | rtk% | lean-ctx | lc% | 勝者 |
|---|---|---|---|---|---|---|
| git log -30 | 10,635 | 1,676 | 84.2% | 625 | 94.1% | lean-ctx |
| git diff（1.17M） | 1,171,880 | 5,914 | 99.5% | 1,171,880 | 0.0% | rtk |
| ls -la | 1,599 | 303 | 81.1% | 331 | 79.3% | rtk |
| find *.py | 10,400 | 180 | 98.3% | 2,607 | 74.9% | rtk |
| grep 'def ' | 173,975 | 4,253 | 97.6% | 45,925 | 73.6% | rtk |
| env | 1,039 | 346 | 66.7% | 197 | 81.0% | lean-ctx |
git diff が lean-ctx で 0.0%、完全に素通し。 1,171,880 トークンが 1 トークンも減りません。計測ミスを疑って調べました。
lean-ctx の git diff が無圧縮な件を裏取りする
「0% は怪しい、何かのミスでは」と疑い、3 つの角度から検証しました。
① 小さい diff でも同じ。 101 トークンの小さな working-tree diff でも lean-ctx は 99 トークン（ほぼ無圧縮）。サイズ依存ではありません。
② lean-ctx 自身のベンチが設計思想を明かす。 lean-ctx benchmark run を回すと、大きな削減は READ MODES（map 97.5% / signatures 93% / cache 99.9%） から来ていて、中身を削らない aggressive モードは ~15% しか減りません（元の情報は 100% 残る）。要するに、情報を捨てないことを優先するツールでした。
③ 公式 README の作りが裏付ける。 README には次の記述があります（いずれも原文ママ）。
- "Up to 99% token savings"（見出しの謳い文句）
- "Cached re-reads: ~13 tokens"（再読込はキャッシュで ~13 トークン）
- "56 pattern modules compress git, npm, cargo, docker, kubectl, terraform and more (270 passthrough rules)"
つまり lean-ctx の削減は キャッシュとパターン整形から来ており、270 もの "passthrough（素通し）ルール" が示すように「意味ある出力はそのまま通す」設計です。diff はこの素通し側に入っている、と読めます。
結論：lean-ctx の git diff 0% は計測ミスではなく設計思想。 中身を削ってまで diff を縮めないのが lean-ctx の考え方でした。私のベンチは「中身を削る」rtk 向きのお題だったので、lean-ctx には不利だったわけです。
lean-ctx の本来の得意分野を測る
公平を期すため、lean-ctx を本来の戦場で測り直しました。
武器①：見出しだけ読む
コードファイルには「関数の見出し（名前・引数・戻り値）」と「中身（実際の処理）」が入っています。lean-ctx はコードを解析して、見出しだけを取り出す読み方ができます。本でいえば、全ページではなく目次だけを読むイメージです。server.py（31,232 tok）で測ると:
| 読み方 | トークン | 削減 |
|---|---|---|
signatures（関数の見出しだけ／18言語対応） | 1,127 | 96.4% |
map（見出し＋どのファイルが何を呼ぶか） | 1,093 | 96.5% |
（比較）rtk read -l aggressive | 2,028 | 93.5% |
「中身は要らない、どんな関数があるか分かればいい」という段階で、rtk の read aggressive を上回ります。
武器②：再読込キャッシュ
lean-ctx は一度見たファイルを覚え、2 回目以降は 1 行スタブに畳みます。未読ファイルでコールド→ウォームを実測:
| ファイル | 素 | コールド読み | ウォーム再読込 |
|---|---|---|---|
| anthropic.py | 24,101 | 24,109 | 20（99.9%減） |
| wrap.py | 35,488 | 35,495 | 19（99.9%減） |
返ってくるスタブの実物がこれです:
F2 cached wrap.py [3991L 35488t] (read #3)
「このファイルはもう読んだ（3,991 行 / 35,488 トークン、3 回目）」と AI に伝えて、同じファイルを貼り直すのをやめさせます。AI は同じファイルを何度も読み直しがちなので、長い作業ほどこれが効いてきます。rtk にはこの仕組みはありません。
武器③：terse モード（出力側を削る）
lean-ctx terse に off / lite / full / ultra を渡すと、ここまでと違って AI の "返答" のしゃべりすぎ を抑えられます（lite: 箇条書き / full: diff と一言だけ / ultra: ほぼコードだけ）。公式は出力トークンを 25-65% 減らすとしています。これは入力ではなく出力側の話で、実際に AI を動かさないと測れないので本記事では数値は出していません。ただ「削る場所」がもう 1 つある、という意味で覚えておくと便利です。
得意がきれいに分かれた
| rtk | lean-ctx | |
|---|---|---|
| シェル出力フィルタ（diff/grep/find） | ◎ 圧勝 | △ 保全優先で控えめ |
| ファイル読み（見出しだけ抽出） | ○ 93.5% | ◎ 96-97% |
| 再読込キャッシュ | ✗ なし | ◎ 99.9%（1行スタブ） |
| 出力側の削減（terse） | ✗ | ○ 25-65%（出力） |
lean-ctx は「弱い」のではなく、得意な場所が違うだけでした。コードを何度も読み返す作業なら、lean-ctx の方が効きます。
裏取り：実測 vs 公式主張
各ツールの公式 README・自己ベンチと、実測を突き合わせました。
| 項目 | 本実測 | 公式の主張 | 整合 |
|---|---|---|---|
| rtk 全体 | 中央値 ~80%（実ログ 79.3%） | 「60-90%」 | ✅ |
| rtk git log / ls | 84.2% / 81.1% | 「-80% / -80%」 | ✅ ほぼ一致 |
| rtk git diff | 99.5% | 「-75%」（典型値） | ✅ 巨大 lockfile ゆえ高め |
| lean-ctx git diff | 0%（素通し） | 「270 passthrough rules」＝素通し設計 | ✅ 仕様どおり |
| lean-ctx ファイル読み | map 96.5% / sig 96.4% | 「Up to 99% token savings / Cached re-reads: ~13 tokens」 | ✅ |
| headroom 本文圧縮 | 93.1% | 「60-95% fewer tokens」 | ✅ 範囲内 |
| h5i 巨大ログ圧縮 | 99.8%（git log -p）、全文復元はバイト一致 | 「up to 95%」 | ✅ 公称以上＋復元も実証 |
すべて公式の主張の範囲に収まりました。
h5i は「圧縮もできる」が本質は別
h5i には 2 つの顔があります。
- エージェント連携・来歴記録（本来の主目的）: git を「AI の作業ノート」として使い、複数エージェントがメッセージを残し合ったり（"Agent Radio"）、「誰が・なぜ・何を考えてこのコードを書いたか」を Git ref / LFS に記録する。
- トークン圧縮:
h5i capture run -- コマンドでコマンド出力を畳む（line-folding は headroom 由来）。
今回は ② の観点で見ました。h5i の圧縮で面白いのは、畳んだ原本の「しまい方」です。
AI には短い要約を渡し、元の全文は git の中に番号（sha256）付きで保管します。あとで h5i recall object を打つと、その番号から全文がそのまま戻ります。長いテスト/ビルドのログを、こんな 1 枚のカードに畳むイメージです。
テスト: pytest / 結果: 失敗 / 成功120・失敗1 / 全文は番号 sha256:… で保管
「戻せるか（可逆性）」で並べると
「畳んだ全文を取り戻せる」のは h5i だけの特権ではありません。実は各ツールが、それぞれの形で持っています。並べるとこうです。
| ツール | 戻せるか | 戻し方 | どれくらい残る |
|---|---|---|---|
| rtk | △ 一部 | コマンドが失敗したときだけ全文を別保存 | その場かぎり |
| lean-ctx | ○ | tee で出力をファイルに残す | ファイルとして残る |
| headroom | ○（CCR） | headroom_retrieve で取り戻す | 5 分のキャッシュ |
| h5i | ◎ | recall object で取り戻す | git に永続（版管理） |
「攻めて圧縮しても、いざとなれば戻せる」——この考え方自体は headroom も CCR として持っています。違いは残し方です。headroom は 5 分の控え、h5i は git に番号付きで永久保存。前者は「その場の保険」、後者は「あとから監査できる証拠」です。用途で選び分けるところです。
h5i も実測した
h5i capture run を他ツールと同じ条件で測りました。
| ケース | 素 | h5i 要約 | 削減 |
|---|---|---|---|
git log -p -30（巨大ログ） | 1,220,612 | 2,044 | 99.8% |
grep 'def ' | 14,284 | 828 | 94.2% |
find *.py | 3,157 | 322 | 89.8% |
ls -laR（小さい出力） | 1,382 | 1,448 | -4.8% |
大きく繰り返しの多いログで 90〜99.8%。公式の「最大 95%」とも整合します。一方、ls -laR のような小さい出力では逆に増えます（-4.8%）——h5i はラッパーの定型文を足すので、短い出力には向きません。h5i の出番は "長大なログ" だと数字でも分かります。
畳んでも全文が戻る
h5i の真価は「消さずに退避する」こと。実際に検証しました。
git log -p -30の生出力 = 2,717,348 バイト / 約 122 万トークン- AI が見る要約 = 約 2,000 トークン（99.8% 減）
h5i recall objectで復元 = 2,717,348 バイト、元と完全にバイト一致 ✅
AI に渡る量は 99.8% 減らしつつ、原本は 1 バイトも欠けずに戻りました。
つまり h5i は「トークン圧縮」と「作業の記録・監査」を兼ねたツールです。圧縮だけが目的なら大げさですが、「削った証拠を版管理して残し、あとで誰でも取り戻せる」のが持ち味です。git の上で動くので、rtk や headroom と一緒に使っても干渉しません。
ちなみに「h5i を入れれば headroom はいらないのでは？」と思うかもしれませんが、置き換えにはなりません。h5i が圧縮するのは h5i capture run で包んだコマンド出力（rtk と同じシェル出力の層）で、会話そのものには手を出しません。会話本文を削るのは headroom の役目なので、会話が膨らむ長丁場ではそちらが効きます。両者は別の層を担当している、というだけです。
初心者向けまとめ：結局どれを使えばいい？
どれも「AI に渡す文章を短くして、トークン代を下げる」道具です。でも得意な場面が違います。
| 道具 | やること | たとえ | ユースケース |
|---|---|---|---|
| rtk | コマンドの出力を短くする | 長いログを 3 行メモにする | git diff や npm install のログでコンテキストが埋まるとき |
| lean-ctx | ファイルを賢く読む・使い回す | 一度渡した資料は「さっき渡したやつ」で済ます | 同じコードを何度も読み返す作業のとき |
| headroom | 会話まるごとを圧縮する | 入口で荷物をまとめて圧縮する | 長時間まわして会話が膨らんできたとき |
| h5i | 圧縮しつつ原本を保管 | 要約を渡し、原本は番号付きで倉庫へ | あとで全文を見たい・記録を残したいとき |
選び方はシンプルです。
- まずは rtk。入れるだけでコマンドの出力が 8 割減ります。効果がいちばん分かりやすい。
- コードをよく読むなら lean-ctx を足す（rtk と入れ替えてもいい）。
- もっと削りたい・長くまわす日は headroom を上に重ねる。
- 出力を消したくない、あとで全文が要るなら h5i。圧縮というより「記録」の道具です。
大事なのは、これらは競合しないこと。働く場所が違うので、rtk ＋ headroom ＋ h5i のように重ねて使えます。
結論：まず rtk、足りなければ headroom
- とりあえず rtk を入れる。 コマンドの出力が 8 割減ります。これだけで十分効きます。
- もっと削りたいなら headroom も入れる。 会話の本文をさらに 93% 圧縮します。
- lean-ctx と h5i は用途次第。コードを何度も読むなら lean-ctx、ログを消さず残したいなら h5i。
インストール方法は各リポジトリに書いてあります。
- rtk: github.com/rtk-ai/rtk
- headroom: github.com/chopratejas/headroom
- lean-ctx: github.com/yvgude/lean-ctx
- h5i: github.com/h5i-dev/h5i
よくわからなければ、Claude Code に URL を貼って「これ入れて」と言うだけで OK。だいたいインストールまでやってくれます（この記事の検証も、最初はその一言から始まりました）。
参考・出典
- headroom（リポジトリ）: https://github.com/chopratejas/headroom
- headroom（PyPI,
headroom-ai）: https://pypi.org/project/headroom-ai/ - rtk / Rust Token Killer: https://github.com/rtk-ai/rtk
- lean-ctx: https://github.com/yvgude/lean-ctx
- h5i: https://github.com/h5i-dev/h5i
- tiktoken（トークンカウンタ）: https://github.com/openai/tiktoken
- ベンチ対象リポジトリ:
chopratejas/headroom（402 コミット / 3,150 ファイル時点）
計測は単一マシン（Apple Silicon / arm64）・単一リポジトリでの結果です。環境や対象によって数字は前後します。公式の主張（rtk 60-90% / headroom 60-95% / lean-ctx の挙動）はいずれも各 README・自己ベンチに基づきます。
