Claude Codeのトークンを最大98%削るOSS10選｜4レイヤー分類と公表値・出典URL付き比較マトリクス

この記事はClaude CodeのトークンやAPI課金を減らしたい開発者向け（CLIとMCPの存在を知っている前提）。

Max x20が1時間で枯れた、$40/日のAPI請求が来た。

ここ1ヶ月、SNS上でそういう悲鳴が目に見えて増えました。

The Registerが2026年3月31日付で報じたクォータ枯渇問題（出典）では、Max 5x利用者から「以前は8時間使えた枠が1時間で枯渇」との証言が紹介されています。

同時期に、海外OSS界隈では「Claude Codeのトークンを刈る」専用ツールがほぼ毎週リリースされるようになりました。

Caveman 41,300スター、RTK 31,200スター、context-mode 8,500スター。

数字だけ見ると派手ですが、どれか1本だけ入れても効きどころがズレてると空振りします。

私は10本を「出力」「入力」「MCP/ツール出力」「セッション記憶」の4レイヤーに並べ直して読みました。

私の見方では、この地図が無いと選べない。

以下、公表値と出典URL付きで並べます。

Claude Codeトークン削減ツール10選 比較マトリクス

まず一枚表から。

各数字は各プロジェクトの公式README・著者ブログ・第三者実測記事に記載された「公表値」であり、私の実測値ではありません。

出典URLは各ツール節で明示します。

この表、眺めるだけで示唆が出ます。

削減率が大きい順に並べても、レイヤーが全部バラバラ。

ここが一番大事。

そもそもトークンはどこで食われているのか

Anthropic公式の「Claude Codeコスト管理」ページ（出典）は、主要な消費源として4つを挙げています。

MCPサーバー定義のオーバーヘッド、ファイル全文の読み込み、CLIコマンドの全出力、会話履歴の蓄積。

Hacker Newsで共有された分析スレッド（出典）では、プログラミングタスクの内訳は「入力93.4%・推論2.5%・出力4.0%」と整理されています。

この数字を見ると、出力だけ削っても全体は動かないという話になります。

ここがCaveman問題の核心です。

つまり4レイヤーの分担はこう整理できます。

• 出力レイヤー: Claudeの返答テキスト（全体の約4%）→ Caveman、claude-token-efficient
• 入力レイヤー: ファイル読み込み・CLAUDE.md（全体約93%のうち、人間側が用意するプロンプト）→ claude-token-optimizer、Headroom、Token Savior、token-reducer
• ツール出力レイヤー: Bash/MCPの戻り値（全体約93%のうち、機械が生成して流し込む部分）→ RTK、context-mode、Token Optimizer MCP
• セッション記憶レイヤー: 会話履歴・ghost tokens → MCP-Memory-Service、Token Optimizer（ghost）

buildtolaunch掲載のレポート（出典）には「Claudeに読ませたファイルはすべてセッション中、コンテキストに恒久的に積み上がる」とあり、これが$1,600の請求につながったと書かれています。

同レポートは入力とツール出力の2レイヤーに手を入れない限り体感は動かないと示唆していて、全体の93%がこの2箇所に集中している数字と符合します。

Caveman: 出力レイヤーの定番、ただし全体効果は限定的

Cavemanは16歳の開発者が作ったCLAUDE.md方言集。

Claudeに「洞窟人みたいに話せ」と指示して返答テキストを圧縮する仕組みです。

GitHub公式READMEのベンチマーク表（出典）から数字を引きます。

10タスク平均: 1,214 → 294 トークン/レスポンス（65%削減）
最大: Reactレンダリングバグ説明 1,180 → 159 トークン（87%削減）
PostgreSQLセットアップ: 2,347 → 380 トークン（84%削減）

— Caveman GitHub README

Decryptの記事（出典）でも広く報じられました。導入は5分。

ここから先が大事な話です。

Decrypt同記事の分析では「実世界の節約は実際には全セッションの約4%程度」とも書かれています。

前段で見たとおり、出力はそもそも全体の4%。

出力を65%削ると、全体では4%×65%＝約2.6%の節約という計算になります。

Cavemanのレビュー記事（出典）も「学習・アーキテクチャ議論・顧客向け生成には不向き」と明確に線引きしています。

私の見方では、Cavemanは「財布が痛いから入れる」ツールではなく「返答がうるさいから黙らせる」ツールです。

節約の主力として期待すると当てが外れます。

私なら導入は5分で済む方を優先します。

RTK: ターミナル出力を刈る、実測89%の本命

Rust Token Killer（RTK）はCLIプロキシ型。

Claude CodeのPreToolUseフックでBashコマンドを途中で受け取り、Rust製バイナリ（10ミリ秒未満のオーバーヘッド）で「不要行のフィルタ・まとめ・短縮・重複削除」を効かせます。

全体の93%を占める入力レイヤーのうち、機械が吐き出す部分をダイレクトに狙うツール。

KiloCodeリポジトリのDiscussion #5848（出典）に投稿された実測値がインパクト大。

2週間で約1,000万トークン削減（89%）。

cargo test: 155行 → 3行（98%）、git status: 119文字 → 28文字（76%）。

— KiloCode Discussion #5848

zerotopete.comの実測記事（出典）では、cargo test 約4,800トークン→11トークン、git diff 約21,500→1,259トークンと書かれています。

公式30分セッションデモは約118,000→約23,900トークン（約80%削減）。

公式READMEの説明文も本質を突いていて、「Claude Codeのセッションは89%のトークンを浪費している。

原因はプロンプトではなく、生のターミナル出力がコンテキストに突っ込まれていることだ」と明記されています（出典）。

オーバーヘッドは10ミリ秒未満。

対応エディタはClaude Code、Cursor、Gemini CLI、Aider、Codex、Windsurf、Cline。

公式READMEは「実測値はプロジェクトサイズに依存、中規模TypeScript/Rustプロジェクト想定」と注記しています。

これはありがたい注記です。

万能じゃないと先に言ってくれる姿勢は私は好きです。

Token Savior: ファイル全文読み込みを記号に置換

Token Saviorは入力レイヤーのうち「人間が指示して読み込ませる」側を刈るツール。

105言語のコードをSQLiteにインデックス化し、Claudeが `find_symbol()` や `get_backward_slice()` で必要箇所だけ拾えるようにします。

公式README（出典）のベンチマーク値。

find_symbol(): 4,100万文字 → 67文字（-99.9%）
get_backward_slice(): 130行 → 12行（-92%）
60タスクのフルベンチマーク: 143万文字 → 21.6万文字（-85%）

— Token Savior GitHub README

内部はSQLite WAL + FTS5 + sqlite-vecのハイブリッド。

BM25とベクター検索（all-MiniLM-L6-v2 384次元）をRRFで合体させ、TTLは「0.4×最近性 + 0.3×アクセス頻度 + 0.3×タイプ加重」で計算されます。

v2.6.0は2026年4月20日リリース。

これ、地味にやばい構成。

buildtolaunchの「読ませたファイルは全部コンテキストに積み上がる」問題（前述）に対する、もっとも根本的な対処がこの方向性です。

context-mode: MCPツール出力をサンドボックス化する新世代

context-modeは、MCPツール呼び出しの戻り値をそのままコンテキストに注入せず、SQLite+FTS5にサンドボックス化してBM25検索で必要行だけ返す仕組み。

著者ブログ（出典）の記述が核心を突いています。

誰もが「生データをコンテキストに投げ込むツール」を作っていた。

出力側を解決する人間がいなかった。

— context-mode 著者ブログ

公式READMEの数字（出典）が強烈。

Playwrightスナップショット: 56.2KB → 299B（99%削減）
GitHubイシュー20件: 58.9KB → 1.1KB（98%削減）
アクセスログ: 45.1KB → 155B（100%削減）
30分で壁に当たっていたセッションが、同じ200Kトークンで3時間走るようになった。

— context-mode README / 著者ブログ

著者ブログでは全体94%削減と公表されています。

6つのサンドボックスツール（ctx_execute / ctx_batch_execute / ctx_execute_file / ctx_index / ctx_search / ctx_fetch_and_index）で11言語対応。

対応プラットフォームは12種（Claude Code・Gemini CLI・VS Code Copilot・Cursor・OpenCode・Codex CLI・Kiroほか）。

v1.0.89は2026年4月14日。

ライセンス費用は0円です。

ひとつ注意点。

ライセンスはElastic License 2.0（ソース公開・条件付き商用可）で、自社SaaSに組み込んで利用する範囲は許可されています。

禁止されるのは「context-mode自体をマネージドサービスとして他者に再販する」ケースだけです。

残り6本：短く並べる

残り6本（Headroom／claude-token-optimizer／Token Optimizer MCP／MCP-Memory-Service／token-reducer／Token Optimizer）は粒度を落とします。

トップ4ほどの実測の厚みは各READMEにないので、公表値と仕組みだけ拾います。

補足。

token-reducerはスター13・コミット24で、他の6本と同列に扱うのは公平じゃない気もしますが、アーキテクチャ（BM25+ベクター+AST+TextRank）として面白いので名前だけ拾っています。

Token Optimizer MCPの「95%以上」も、他ツールと違って測定条件が公開されていないため、表では括弧付きで扱いました。

4箇所を同時に刈る：組み合わせは可能か

MCP-Memory-Service作者が公開したGist（出典）が、実用レベルで一番まとまった検討資料です。

6層スタック（RTK + context-mode + MCPlex + Caveman + Context-Provider + Memory-Service）で1時間セッション合計約58,500トークン削減、約58%削減と試算されています。

削減率の単純加算は罠です。

Caveman 65%＋RTK 89%＋Token Savior 97%＝251%引けるわけではない。

同じレイヤーを刈り合うケース（claude-token-optimizer と Token Savior など）は食い合って伸びません。

組み合わせの鉄則はこうなります。

• レイヤーが違えば独立して効く（Caveman×RTK×context-mode×MCP-Memory-Service）
• 同じレイヤーは食い合うので1本に絞る（Token Savior と claude-token-optimizer は同時運用しない）
• 合計値の目安は「各レイヤー1本ずつ積み上げたGistの58%」が現実的な天井

導入の進め方：3ステップで土台から積む

私の見方では、ヘビーユーザーが今日から進めるなら次の3ステップで進めるのが安全です。

いきなり10本全部入れるとどれが効いたか分からなくなります。

ステップ1：Anthropic公式の基本運用を先に固める

具体的には `/clear` でセッションをこまめにリセット、`/compact` で過去履歴を圧縮、CLAUDE.mdは200行以下、subagentsで責任範囲を分離する、の4点です（公式出典）。

期待結果はクォータ消費が体感で2〜3割落ちること。

詰まりどころは「CLAUDE.mdが気付くと500行を超えている」ケース。

私は週1で行数を確認しています。

ステップ2：RTKまたはcontext-modeをツール出力レイヤーに入れる

具体的にはRTKをRust製バイナリ（5分インストール）として導入し、PreToolUseフックでcargo testやgit diffの出力を絞ります。

MCPツールを多用しているならcontext-modeのほうが効きどころが大きい。

期待結果は1セッションあたり5万〜10万トークンの削減。

詰まりどころは「RTKが絞りすぎてClaudeが必要な行を見逃す」場合で、フィルタ条件のチューニングが要ります。

ステップ3：入力レイヤーかセッション記憶レイヤーで1本だけ追加

具体的にはファイル全文読み込みが習慣ならToken Savior、セッションを跨ぐ開発ならMCP-Memory-Service。

Cavemanは最後でいい。

「返答がうるさい体感」を消したいなら入れる、節約額には期待しない、というスタンスです。

期待結果は1時間セッションで合計約58%削減（doobidoo Gistの6層スタック試算）に乗ること。

詰まりどころは同じレイヤーで2本入れて食い合うパターンで、1レイヤー1本のルールを崩さないことです。

Cavemanを1番目に入れたくなる気持ちはわかるのですが、全体の4%レイヤーから始めると「入れたのに請求が変わらない」という感想になりがち。

入力とツール出力から潰すのが合理的です。

キャッシュと公式機能：ツール入れる前の土台

Anthropic公式のプロンプトキャッシング（出典）だけで、キャッシュ読み取りは通常単価の0.1倍。

Sonnet 4.6 で $3/MTok → $0.30/MTok、Opus 4.7 で $5/MTok → $0.50/MTok。

ただしThe Registerの記事によれば、2026年3月に「10〜20倍のトークンコスト増加を引き起こすキャッシュ関連バグ」がコミュニティで特定されたとされています。

Anthropicは「Extra Usage有効時はキャッシュTTLが60分→5分に短縮」と説明。

ここはユーザー側で設定を見直す余地があります。

公式Compaction（出典）もbeta中ですが、1Mコンテキスト使用時は約83.5%でコンパクション発動、バッファ約33Kトークン確保。

`/compact Focus on the API changes` のようにカスタム指示を付けられるので、OSSツールを足す前にこの挙動を把握しておいたほうが建設的です。

ツール導入で残る限界

Hacker Newsの長いスレッド（出典）には、この手のツール全体に対する冷めた指摘がいくつか並んでいて参考になります。

「Answer is always line 1」のような指示は自己回帰モデルの動作原理に反する。

モデルが誤った方向に早期コミットするリスクがある。

Anthropicは出力のデフォルトを最適化するインセンティブがある。

Claudeに統合されていない機能は、おそらく性能を改善しない。

— Hacker News スレッド要旨

Cavemanのレビュー記事も「顧客向けアプリケーション」「ニュアンスが必要なコンテンツ」「学習目的の会話」では不向きと明言しています。

正確性・丁寧さが必要な場面で切り替えるためのスイッチ設計（セッション単位・プロジェクト単位のON/OFF）はどのツールにも欲しい機能です。

そしてこれが一番重要。

出力削減を狙った結果、入力のCLAUDE.mdが肥大してトータルで損をするケースが複数報告されています。

200行という目標は公式ベストプラクティスの数字ですが、実運用ではもっと刈り込むくらいでちょうど良さそうです。

FAQ

Q. Claude Code Max x20で月$200払っているのに、さらにツール入れる価値ある？

A. Max x20は5時間ウィンドウで約220,000トークン。

The Registerの報道にあるように「想定より速く枯渇」するケースが実在します。

RTK実測89%・context-mode 94%のレイヤーでトークンが食われているなら、ツール導入で5時間の作業時間を実質的に延ばせる可能性があります。

課金額を下げる目的より「枠を使い切らない」目的で見ると費用対効果が出しやすいです。

Q. 削減率を足し算して「99%削れます」と書いていいですか？

A. 書くと信頼を失います。

doobidooのGistの6層スタック試算でも合計約58%。

レイヤーが違うツールを組み合わせても、同じトークンを二重に数えることになるので単純加算は成立しません。

各ツール単位の公表値は併記、合算は1時間セッションで約58%（doobidoo Gistの試算）が現実ライン、と整理するのが安全です。

Q. Cavemanだけ入れればとりあえず効果ありますか？

A. 出力レイヤーは全体の約4%なので、Cavemanの65%削減は全体では約2.6%の影響にとどまるという計算がDecrypt記事で示されています。

「返答がうるさい」「礼儀的な前置きが鬱陶しい」問題には効きますが、請求額や枠消費への影響を期待するならRTK・context-mode・Token Saviorのほうが桁が違います。

Q. OSSではない（Elastic License 2.0）context-modeを業務で使っていい？

A. Elastic License 2.0で禁止されているのは「context-mode自体をマネージドサービスとして他者に再販する」ケースだけです。

自社SaaSに組み込んで使う、社内の開発支援に入れる、個人プロジェクトで使う、いずれも許可範囲内。

SaaS同梱も問題ありません。

商用の懸念があるのは「context-modeをラップして別社向けに売る」事業をやるときだけです。

Q. Token Optimizer MCP と token-reducer の「95%以上」「90〜98%」は信じていい数字ですか？

A. 両者とも測定条件・ベンチマーク手法がREADMEに記載されていません。

token-reducerはスター13・コミット24で採用実績も薄い段階です。

公表値として並べる価値はありますが、「数字の比較対象」として Caveman 65%（10タスク実測）・RTK 89%（2週間1,000万トークン実測）と同列には並べられない、と理解しておくのが無難です。

参考リンク

• Anthropic公式: Claude Codeコスト管理 / ベストプラクティス / Compaction / プロンプトキャッシング
• 第三者実測・分析: The Register（クォータ枯渇） / Decrypt（Caveman分析） / zerotopete（RTK実測） / context-mode著者ブログ / Caveman実測レビュー / buildtolaunch（$1,600請求の原因）
• コミュニティ資料: Hacker News（93.4%/2.5%/4.0%内訳・批判スレ） / KiloCode Discussion（RTK 89%実測） / doobidoo 6層スタックGist / dev.to 9 Verified Tools

※この記事の内容は執筆時点のものです。AIは進化が速い分野のため、最新の仕様は公式サイトでご確認ください。