【検証】「LLM API費を50〜80%削減」のTokenTamerを実測 — Pythonは本当に80%減、でも効くのは「再読み込み」だけ

こんにちは、七宮さん(@shichinomiya_s)です。

前回の記事では、LLMに送るコンテキストを圧縮してAPI代を減らすツール「Headroom」を実測しました。あれから1週間ちょっと、今度は「肥大化したコード文脈をリアルタイム圧縮し、LLM API費を50〜80%削減。モデルが本当に必要な情報は失わない」と謳う新顔、TokenTamerが登場しました（公開からまだ3日）。Headroomがデータの「詰め直し」だったのに対し、こちらはAST（構文木）でコードを骨組みだけに削るアプローチ。本当に50〜80%も減るの？というわけで、今回も実際にMacへ導入して、実在のOSSコードとClaude Code風の会話ペイロードでトークン削減率を実測してみました。

結論から言うと、PythonとTypeScriptの単一ファイルなら謳い文句どおり80%減が本当に出ます。今回の実測ではPython(requests)が80.8%、TypeScript(vue core)が80.5%削減。一方でJavaScript(express)は23.7%止まり、JSON・YAML・散文は0%と対象を選びます。さらにエージェント風セッション全体では削減は38.3%、しかも「同じファイルを2回以上読む」会話でないと1トークンも減りません。数字とあわせて正直にレビューします。

TokenTamerとは何か — コードを「シグネチャだけの骨組み」に削るプロキシ

TokenTamerは、コーディングエージェント（Claude Code、Aider、Cursorなど）とLLM APIの間に挟まるローカルプロキシです。リクエストのメッセージ配列を覗き、「いま作業中ではない」コードをスケルトン（骨組み）化してからAPIへ転送します。キモは3つ。

• ASTスケルトン化 — Pythonは構文木を解析し、関数・メソッドの中身を ... に置換。シグネチャ・import・クラス構造・型注釈は残す。JS/Go/RustなどC系言語は波かっこの対応を数えるヒューリスティックで同様の処理。
• tool-aware圧縮 — エージェントが同じファイルを何度も読み直すと、古い読み込み結果（staleリード）が会話履歴に溜まります。TokenTamerは各ファイルの最新の読み込みだけ残し、古い分を骨組みに差し替えます。
• 安全側に倒す設計 — ユーザーが言及しているファイルや、ファイル名が特定できないコードブロックは触らない。ツール定義やtool_useブロックも無傷。

導入してみる — pipで一発、依存も軽い

GitHubからcloneしてpipで入れるだけ。モデルのダウンロードもAPIキーも不要で、今回の計測は全部ローカルで完結します。

git clone https://github.com/borhen68/TokenTamer.git
python3.13 -m venv venv
./venv/bin/pip install -e ./TokenTamer

導入は数十秒で完了。今回はプロキシとして立てるのではなく、中身の圧縮エンジン（SkeletonizerとContextAnalyzer）をPythonから直接呼び、圧縮の前後でトークン数がどう変わるかをtiktoken（cl100k_base、TokenTamer自身が使っているのと同じ方式）で数えました。

検証環境

圧縮対象は実在のOSSファイル4本（requestsのsessions.py 920行、expressのapplication.js 631行、ginのcontext.go 1,516行、vue coreのeffect.ts 582行）に、package-lock風JSON・k8s風YAML・README散文を加えた7種です。

検証結果① 言語別の削減率 — Python/TSは80%、JSは24%

各ファイルを単体でスケルトン化し、前後のトークン数を数えました。

ASTで正確に解析できるPythonと、シグネチャ行が拾いやすいTypeScriptは謳い文句の上限80%に実際に到達。一方、prototype拡張だらけのexpressのJSは波かっこヒューリスティックがあまり刺さらず24%止まりでした。そしてHeadroomはJSONを59%圧縮しましたが、TokenTamerはJSON・YAML・散文には一切手を付けません。コード専用ツールです。

骨組み化の出力はこんな感じです。importとシグネチャ・docstringの構造は完全に残ります（920行が144行になります）。

# [TOKEN-GUARD: Compressed — structural skeleton only]
"""requests.sessions ..."""
from .adapters import HTTPAdapter
...
def merge_setting(request_setting: Any, session_setting: Any,
                  dict_class: type=OrderedDict) -> Any:
    ...

検証結果② セッション全体では38.3%減 — ただし「再読み込み」がある場合のみ

次が本命。Claude Code風の会話（4ファイルをツールで読みながら作業する29メッセージ、計93,458トークン）を組み立て、tool-aware圧縮に通しました。

同じファイルを3回ずつ読み直す「エージェントあるある」なセッションでは、古い読み込み8個が骨組みに置き換わり38.3%削減。しかし各ファイルを1回しか読まないセッションでは削減ゼロでした。最新の読み込みは常に無傷で残す安全設計なので、当然こうなります。つまり節約が生まれるのは「会話が長くなって同じファイルを読み直す」フェーズから。短い質問への回答用途では何も起きません。

検証結果③ 安全性とレイテンシ — 壊さない・速い

「必要な情報は失わない」の方の主張も確認しました。

• アクティブファイル保護 — ユーザーが「main.pyを直して」と言及した場合、main.pyのコードは無傷のまま、言及されていないutils.pyだけ骨組み化されました ✅
• 構造の保持 — Pythonスケルトンはast.parseを通り、関数・クラス名は31個中31個残存 ✅
• 散文は不変 — コードブロックを含まないmarkdownは1文字も変わらず ✅
• 処理速度 — 93,458トークンのペイロード圧縮が平均24.76ms（中央値24.87ms / p95 25.28ms、20回計測）。プロキシとして挟んでも体感ゼロです。

「50〜80%削減」の正体 — 条件付きでは本当

実測を整理すると、謳い文句の数字はこう読むのが正確です。

• 80% — Python/TypeScriptの単一ファイルの骨組み化率としては本当。ただしJS(express)は24%、Goは48%と、言語ごとのパーサ品質に大きく依存。
• 50% — 会話全体でこれを出すには、staleリードが大量に溜まる長いセッションが必要。今回の「3回読み直し」想定で38.3%でした。
• READMEにある「長セッションで〜73%オフ」はAnthropicのプロンプトキャッシュ併用が前提の数字で、圧縮単体の効果ではありません。

なお正直にお伝えすると、今回は圧縮エンジン単体の実測で、プロキシとして実際のClaude Code↔API通信に挟むE2E動作（HTTPS横取り設定を含む）までは検証していません。骨組み化されたコードで応答品質が落ちないかも、今回はスコープ外です（シグネチャは全部残るので理屈上は実装詳細を聞かない限り影響しにくいはずですが、未計測のことは断言しません）。

向いている用途・注意点

向いている人：

• Claude CodeやAiderで長時間セッションを回し、同じファイルを何度も読み直す使い方をしている人
• Python / TypeScript 中心のリポジトリで作業している人（圧縮が一番効く）
• API従量課金で、入力トークンの肥大化が財布に直撃している人

注意点：

• JSON・YAML・設定ファイル・散文は1トークンも減りません（HeadroomがJSONを59%圧縮したのとは対照的）
• JavaScriptの圧縮率は控えめ（実測24%）。言語によるムラが大きい
• 各ファイル1回読みの短いセッションでは効果ゼロ
• 公開3日の若いツールで、HTTPS横取りなどプロキシ運用部分の枯れ具合は未知数

まとめ

「50〜80%削減」は誇大広告ではないが、「Python/TSのコードを、何度も読み直す長セッションで」という条件付きの数字でした。

• 単一ファイルの実測: Python 80.8% / TypeScript 80.5% / Go 47.7% / JavaScript 23.7%
• JSON・YAML・散文は0%（コード専用）
• Claude Code風セッション全体では38.3%減。ただし再読み込みが無いと0%
• シグネチャ31/31保持・アクティブファイル無傷・処理は93kトークンで約25ms

長いエージェントセッションをPython/TSリポジトリで回している人なら、試す価値は十分あると思います。

検証ノート（再現情報）

本記事の数値はすべて筆者のMacでの実測です。検証手順と環境を残しておきます（同じ手順で再現できます）。

環境

再現コマンド

git clone https://github.com/borhen68/TokenTamer.git
python3.13 -m venv venv
./venv/bin/pip install -e ./TokenTamer tiktoken matplotlib

# サンプル: 実在OSSファイルを取得
curl -sfLo sessions.py https://raw.githubusercontent.com/psf/requests/main/src/requests/sessions.py
curl -sfLo application.js https://raw.githubusercontent.com/expressjs/express/master/lib/application.js
curl -sfLo context.go https://raw.githubusercontent.com/gin-gonic/gin/master/context.go
curl -sfLo effect.ts https://raw.githubusercontent.com/vuejs/core/main/packages/reactivity/src/effect.ts

# 計測ハーネス（Skeletonizer / ContextAnalyzer を直接呼び、
# tiktoken cl100k_base で前後のトークン数を比較）
./venv/bin/python measure.py

生ログ要約

per_file:
  sessions.py (requests)    7,336 -> 1,405 tok (-80.8%) / 920 -> 144 行
  effect.ts (vue core)      3,577 ->   699 tok (-80.5%) / 582 -> 120 行
  context.go (gin)         12,091 -> 6,325 tok (-47.7%) / 1,516 -> 664 行
  application.js (express)  3,525 -> 2,688 tok (-23.7%) / 631 -> 490 行
  JSON / YAML / markdown:   変化なし (was_compressed=false)
python_skeleton_parses: true / signatures_kept: 31/31
session (4ファイル×3回読み, 29 msgs): 93,458 -> 57,672 tok (-38.3%), stale 8個を骨組み化
session (各1回読み): 31,184 -> 31,184 tok (-0%)
active_file_check: main.py無傷 / utils.pyのみ骨組み化
latency: mean 24.76ms / median 24.87ms / p95 25.28ms (20回, 93,458 tokペイロード)

rawログは runs/20260611-tokentamer-context-compression/results/ に保存。本文中の数値はこのログと突き合わせ済みです。