目次
こんにちは、マサシです。
千葉でWeb制作をしています（スタジオについて）。
コードを書くとき、僕はClaude Code（ターミナルで動くAIのやつ）を毎日使っています。
便利なんですが、ずっと気になっていることがあって。
トークン、使いすぎなんですよね。
5時間ごとの利用枠にわりとすぐ当たるし、従量課金の分の請求も地味に効いてくる。
そんなときに token-diet というものを見つけました。
「常時オンで、平均31%の請求が減る。しかも正確さは落ちない」と書いてある。
…本当かな、と思いました。
こういう「◯%削減」の数字って、だいたい一番よく効く条件での話だったりするので。
なので、信じる前に自分の仕事でそのまま測ってみることにしました。
先に、この記事で確認できたこと・できていないこと
大事なところなので最初に書きます。
| 内容 | |
|---|---|
| 確認できたこと | 同じ質問を token-diet オフ／オンで流したときの、出力トークンが平均 −54.4%（タスク別で −40〜−64%）／請求額が平均 −26.4%（同 −11〜−50%） |
| 確認できていないこと | ファイル編集をずっと続ける長時間セッションでの効き・Codex側の効き・品質の「点数化」（品質は目で見て比べただけ） |
| 対象 | Claude Code（claude CLI 2.1.214）／モデルは Sonnet 5 |
| 測り方 | 使い捨ての検証フォルダに --project で導入し、4種類の質問を各3回ずつオフ／オンで実行（計24回） |
| かかった実費 | このベンチ全24回の合計で $0.87 |
つまりこの記事は「短い質問をたくさん投げる使い方で、どれだけ減るかを測った記録」です。
「あらゆる使い方で31%減る」を検証したわけではありません。
そこは正直に分けて書きます。
token-diet って何なの
まず、測る対象の正体から。
token-diet は、Claude Code・Codex・Cursor・Windsurf・Cline に対応した「トークン効率化スキル」です。
一回インストールすると、以後毎回のセッションで常時オンになって、AIの返答をムダなく短くしてくれる、という仕組み。
GitHubの公式ページには、こう書いてあります。
「平均で請求が約31%減る（セッションの種類で −17〜−54%）、出力は −30〜−81% 減る。しかも Sonnet 5 の実走行で」。
この「31%」と「出力 −30〜−81%」が、今回ちゃんと出るのかを見ます。
インストールはワンライナーです。
# 公式のインストール（--project で今いるフォルダだけに入れられる）
curl -fsSL https://raw.githubusercontent.com/Kulaxyz/token-diet/main/install.sh | bash -s -- -a claude --project
--project を付けると、~/.claude（全体設定）ではなく今いるフォルダの .claude/ にだけ入ります。
いきなり全体に入れるのは怖かったので、僕はこれで使い捨てフォルダに入れて試しました。
外そうと思えば --uninstall で消せます。
返答を短くするって、要は「雑になる」ってことじゃないんですか？
そこがいちばん気になるよね。だから今回は「トークンが減ったか」だけじゃなくて、「答えの中身が痩せてないか」も一緒に見たよ。
どう測ったか（同じことをやれば再現できます）
やり方はシンプルです。
Claude Code には、返答をJSONで受け取るオプションがあって、その中に実際に使ったトークン数と金額が入っています。
# --output-format json にすると usage（トークン数）と total_cost_usd（金額）が返る
claude -p "質問文" --model sonnet --output-format json
これを使って、次のようにしました。
・token-diet を入れていない空フォルダと、--project で入れたフォルダを用意する
・同じ質問を、両方のフォルダで実行する
・出てきた output_tokens（出力トークン）と total_cost_usd（金額）を記録する
・毎回のブレをならすため、各質問を3回ずつ回して平均を取る
質問は、自分がふだんAIに聞くような内容を4つ選びました。
・Next.jsのApp RouterとPages Routerの違いを説明して（日本語・説明多め）
・配列を分割するchunk関数をTypeScriptで書いて（日本語・コード）
・HTTPキャッシュの仕組みを説明して（英語・説明多め）
・Reactの「Maximum update depth exceeded」の直し方を教えて（日本語・デバッグ）
実際に返ってきたJSONの中身は、こんな感じです。
# 同じ「Next.js Routerの違いを説明して」への返答（1回目）
オフ → output_tokens=3715, total_cost_usd=0.0669
オン → output_tokens= 934, total_cost_usd=0.0248
同じ質問なのに、出力が 3715 → 934 に減っています。
これを4種類×3回、オフとオンでそれぞれ回しました。
結果：出力トークンは平均54%減った
まず出力トークン（AIが書いて返す量）から。
数字で並べるとこうです。
| 質問（各3回の平均） | オフ | オン | 出力の削減 |
|---|---|---|---|
| Next.js Routerの違い（JA） | 2,523 | 903 | −64% |
| chunk関数を実装（JA・コード） | 597 | 271 | −55% |
| HTTPキャッシュを説明（EN） | 1,286 | 640 | −50% |
| Reactエラーの対処（JA） | 1,399 | 833 | −40% |
| 4タスク平均 | 1,451 | 662 | −54.4% |
出力トークンは、全部のタスクで素直に減りました。
平均 −54%、いちばん減ったNext.jsの説明で −64%。
公式が言っている「出力 −30〜−81%」の範囲に、ちゃんと収まっています。
ここは主張どおりでした。
説明が長くなりがちな質問（Next.jsの違い）ほどよく効いて、もともと短い質問（chunk関数）は削り幅が小さい、という順番も納得感があります。
ここが本題：出力が半分になっても、請求はそこまで減らない
さて、問題はここからです。
「出力が54%減った」なら、請求も同じくらい減ると思うじゃないですか。
減りませんでした。
同じ実測データで、請求額（total_cost_usd）の削減率を並べるとこうなります。
| 質問 | 出力の削減 | 請求の削減 |
|---|---|---|
| Next.js Routerの違い | −64% | −50% |
| chunk関数を実装 | −55% | −11% |
| HTTPキャッシュを説明 | −50% | −20% |
| Reactエラーの対処 | −40% | −16% |
| 平均 | −54% | −26.4% |
出力は半分以下になっているのに、請求は平均で26%しか減っていない。
とくにchunk関数のような短い質問だと、出力が55%減っても請求は11%しか下がりませんでした。
なぜこうなるのか。
理由は2つあります。
ひとつは、token-diet は「短く答えてね」という指示文を毎回のセッションに注入する仕組みなので、入力側は逆に少し増えること。
もうひとつが大きくて、Claude Code の請求は、返答の長さよりもプロンプトのキャッシュに多くを払っている、ということです。
Claude Code は毎ターン、それまでの文脈やツールの定義をまるごと送り直していて、その大部分はキャッシュの作成・読み込みの料金です。
出力トークンは、請求全体の中では意外と小さい割合。
だから出力を半分にしても、請求全体はそこまで動かない。
答えが短い質問ほど、この差が大きく出ます。
逆に、Next.jsの説明のようにもともと出力が多い質問では、請求もちゃんと −50% 減りました。
公式の「平均31%減」は、いろんなセッションをならした平均値なんですね。
短い一問一答をポンポン投げる使い方だと、体感の請求はそこまで減らない。
出力が多い作業や、長く回すセッションでこそ、31%に近づく。
そういう性質のものだと分かりました。
これは実際に自分で測らないと、たぶん「31%減るんだ」で終わっていたところです。
品質は落ちるのか（短くなった分、何が消えたか）
いちばん心配していたのがここでした。
短くなった代わりに、答えが痩せていないか。
chunk関数の実装で、オフとオンの返答を並べてみます。
オフ（token-dietなし）の返答は、こうでした。
function chunk<T>(array: T[], size: number): T[][] {
if (size <= 0) {
throw new RangeError("size must be a positive integer");
}
const result: T[][] = [];
for (let i = 0; i < array.length; i += size) {
result.push(array.slice(i, i + size));
}
return result;
}
このあとに、使用例が5パターン（空配列・割り切れない場合・エラーになる場合まで）と、動きの説明が箇条書きで付いていました。
オン（token-dietあり）は、こうです。
function chunk<T>(arr: T[], size: number): T[][] {
if (size <= 0) throw new Error("size must be greater than 0");
const result: T[][] = [];
for (let i = 0; i < arr.length; i += size) {
result.push(arr.slice(i, i + size));
}
return result;
}
使用例は3パターン、説明の箇条書きは無し。
関数の中身は、どちらも正しく動きます。
エラー処理（サイズが0以下のとき弾く）も、ちゃんと両方に入っている。
つまり芯は残っていて、周りの説明と例が削られたという感じでした。
ただ、細かく見ると差はあります。
オフは RangeError（範囲の間違い、という具体的なエラー）を投げていたのが、オンでは普通の Error になっていました。
エッジケースの使用例も減っている。
だから「学びながら書きたい」「網羅的な例がほしい」ときは、オンだと物足りないかもしれません。
そういうときは、その質問だけ /token-diet off で一時的に切る、という使い方ができます。
僕の感想としては、答えを知っている人が手数を減らしたいときは快適、知らないことを教わりたいときは少し薄い、という道具でした。
じゃあ結局、入れたほうがいいんですか？入れないほうがいいんですか？
「長い作業をよく回す人」「答えの要点だけ早くほしい人」は入れる価値あり。「一問一答で丁寧な説明がほしい人」は、体感ほど請求は減らないから期待しすぎない。僕はそんな線引きにしたよ。
まとめ：数字は本物だった。ただし「どこで効くか」が肝
測ってみて分かったことを、最後に3行で。
・出力トークンは主張どおり本当に減る（自分の環境で平均 −54%、公式の範囲内）
・でも請求の体感は出力ほど減らない（平均 −26%・短い質問だと −11%まで下がる）
・効きどころは「出力が多い・長く回すセッション」。試すなら --project で使い捨てフォルダに入れて、合わなければ --uninstall
「平均31%減」という数字そのものは、盛っていませんでした。
ただ、その31%が自分の使い方で出るとは限らない。
そこは、うたい文句を鵜呑みにせず一度測ってみる価値があるな、と思いました。
今回みたいに、--output-format json で自分のトークン数を出して比べるだけなら、実費$1もかかりません。
気になっているツールがあるなら、自分の環境で1回測ってみるのがいちばん早いです。
僕自身がそうだったので。
こういう「話題のツールを実際に試して、効くところと効かないところを切り分ける」みたいなことも、制作のかたわらでやっています。
技術的な検証や失敗の記録は、ブログにほかにも置いています。