トークン on Claude Code 始めました

コンテキストの87%が使い捨てだったので自分で対策した話

Thu, 16 Apr 2026 00:00:00 +0000

MAXプランの週間クォータが3日で溶けた。

×20のクォータがあるはずなのに、水曜には残量が怪しくなってる。それ自体は「まあそんなもんか」で済ませてたんだけど、ふと気になった。コンテキストウィンドウの中身って、実際どうなってるんだろう。

前の記事ではAI秘書のトークン節約について書いた。CLAUDE.mdを削ったり、MCPツール定義を削ったり。でも今回はAI秘書じゃなくて、Claude Code自体の話。道具のほうが大食いだったとは。

きっかけ

4月14日、スペイン語圏のあるツイートが目に留まった。

「Claude Codeのトークン浪費の大半はユーザー側に原因がある」

言いたいことはわかる。CLAUDE.mdが肥大化してるとか、プロンプトが冗長だとか。でも「大半がユーザー側」って、ちゃんと測って言ってるのか？

じゃあ俺が測ってやる、と思った。

実測してみた

Claude Codeの内部transcript（セッションを記録してるJSONL）を解析した。

1ターンあたり188,000トークン。うち164,000トークン（87%）が会話履歴。

CLAUDE.mdは12,700トークン。MCPツール定義は3,900トークン。合わせても全体の9%。これを半分にしても5%弱しか浮かない。

本丸は会話履歴の肥大化だった。CLAUDE.mdを必死に削ってた自分がちょっと恥ずかしい。

犯人はツールI/O

じゃあ履歴の中身は何か。

開いて驚いた。履歴の約80%がツールの入出力だった。 ファイルの読み取り結果、Bashコマンドの出力、grepの結果。AIがその場で使って、判断して、次に進んだ時点で役目を終えてるデータ。

なのに、それがコンテキストウィンドウにずっと居座って、毎ターントークンを食い続けている。

50ターンのセッションだと、最初のほうにgrepした結果がまだコンテキストにいる。もう二度と見ることはないのに。

/compactの矛盾

「/compactすればいいじゃん」って思うかもしれない。自分もそう思ってた。

でも/compactの仕組み、AIに全履歴を読ませて要約させるんだよね。

トークンを節約するために、トークンを大量に消費する。しかも要約の過程でニュアンスが消える。「あの時なぜこの設計にしたか」みたいな文脈が、丸められて消えることがある。

要約後にまた作業を続ければ、また肥大化して、またcompactして…の繰り返し。根本解決じゃない。

時間じゃなく、種類で分ける

ここで発想を変えた。

MemGPTやLangChainのSummaryBufferMemoryは、古いものから要約する。時間ベースの圧縮。でも問題は「古さ」じゃない。

10ターン前の「この設計にした理由」は今でも価値がある。さっきのgrepの結果は、1ターン前でも用済み。

時間じゃなく、種類で分ければいい。

会話本文（人間が書いたこと、AIが答えたこと）→ 残す
ツール入出力（ファイル内容、コマンド結果）→ 退避する

この発想で作ったのがThroughlineだ。

3層モデル

Throughlineは会話を3つのレイヤーに分解してSQLiteに保存する。

L1（Skeleton） — 古いターンの一行要約。軽量モデルが生成する。1ターン約10トークン。

L2（Body） — 直近20ターンの会話本文。ユーザーの発言とAIの応答がそのまま残る。圧縮なし、ロスレス。

L3（Detail） — ツール入出力、システムメッセージ。SQLiteに退避してコンテキストには一切残さない。必要になったらAIが自分でSQLiteから引っ張ってくる。

/clearを打っても大丈夫。SQLiteは消えないから、次のセッション開始時にトランザクション一発で前セッションの記憶を引き継ぐ。PIDを追いかけたり、時間窓で判定する必要はない。決定的に動く。

数字で言うとこう。

Throughlineなし（50ターン、/clearなし）：
 コンテキスト ≈ 125,000トークン（80%が用済みのツールI/O）

Throughlineあり（50ターン → /clear → 復帰）：
 コンテキスト ≈ 13,000トークン
 （直近20ターンのL2 + 古い30ターンのL1要約）

約90%の削減。

失敗した設計の話もしておく

最初からこの形だったわけじゃない。

初期の設計では、L2を「重要な判断の構造化抽出」にしようとした。[DECISION] WebSocketを採用、[CONSTRAINT] ポート8080は使えない みたいなタグ付きで、会話から重要な情報だけ引き抜くイメージ。

AI秘書のトークン節約を必死に調べた記録

Sun, 12 Apr 2026 12:00:00 +0900

やらかした

前回の記事で、AIアシスタントに記憶と人格を持たせて秘書にした話を書いた。俺専属のAI秘書ができて、よし本格運用だ、と意気込んだ。

3日で週次リミットに到達した。

ClaudeのMAXプラン、x20の上限。普段ガッツリ開発してても週末まで余裕で持つ枠。それを3日で溶かした。自分でもびっくりした。画面に「今週はもう使えません」って出たとき、「え、もう?」って声が出た。

犯人は明らかだった。秘書は起動しっぱなしで、メールもカレンダーもDiscordも、全部Claudeに読ませて判断させてた。そりゃ減る。人間一人分の事務仕事を24時間AIに回してるんだから、減らないわけがない。

でも困る。困るので必死に調べた。この記事はその記録。

トークン節約の世界に迷い込む

「Claude Code トークン節約」とかで検索して、辿り着いたのが3つ。

ECC (Everything Claude Code)
RTK (Rust Token Killer)
Caveman

最初は名前だけ見てもさっぱりわからなかった。でも触って調べてるうちに、ある一つの共通原則に気づいた。

腑に落ちた共通原則

人間向けのフォーマットは、AIにとって無駄が多い。

考えてみれば当たり前だった。コマンドの出力も、ファイルの中身も、エラーメッセージも、全部「人間が読みやすい」ように作られてる。空白、罫線、色、親切な説明、ヘッダー。AIにとってはそのほとんどがノイズで、トークンを食うだけの飾りだ。

トークン節約の本質は、人間向けのフォーマットをAI向けに削ってから渡すこと。そしてAI向けに吐かせた出力をさらに圧縮すること。3つのツールは、それぞれこの前提を別の角度から解決してた。

ECC — 凄い人がうまいことやってくれるやつ

正直まだ全貌はつかめてない。でも入れて動かすと、Claudeの振る舞いが明らかに整理される。スキルやフック、エージェントの定義が大量に入ってて、Claudeが「こういうときはこう動け」というレールに乗って動くようになる。

俺の理解だと、ECCは「凄い人たちが知見を詰め込んだ設定集」に近い。自分で考えなくても、ベストプラクティスに沿って動いてくれる。トークン節約の観点だと、無駄な探索や脱線が減る分、結果的に消費が落ちる。直接削ってるというより、余計なことをしなくなるタイプの節約だ。

RTK — コマンドの返答を簡略化してAIに渡す

こっちはわかりやすい。Claudeがコマンドを実行したとき、その出力を横取りしてAI向けに削ってくれる。

たとえば git status や ls の出力、普通に流すと人間向けの装飾がそのまま渡るけど、RTK通すと余計な情報を落とした状態でClaudeに渡る。rtk をコマンドの頭につけるだけでいい。フィルタがない対象はそのまま素通しするから壊れないのも良い。

グローバルのCLAUDE.mdに「全コマンドに rtk プレフィックスを付ける」と書いておけば、Claudeが勝手にそうしてくれる。設置コスト低いわりに効きが体感できる。

Caveman — AIの出力を要約する(今回は見送り)

これはまだ入れてない。RTKが「入力」側を削るのに対して、Cavemanは「出力」側を削る、という理解。Claude自身の応答を短く圧縮する方向性らしい。

入れなかった理由は単純で、秘書がカタコトになったら嫌だから。せっかく人格と言葉遣いを作り込んだ秘書が、急にぶっきらぼうに返してきたら萎える。限定的に、たとえば開発用のセッションだけ有効にする、みたいな使い方はできたんだろうけど、そこまで調べる前に「今回はいいや」と見送った。

このへんは俺の用途の都合で、純粋に開発だけで使ってる人には普通に強力だと思う。

自分の開発スタイルで、ここから追加でやれそうなこと

3つのツールで「土台」の節約はできた。ここから先は、自分の癖に合わせた追加の削り方を考えてる。まだ試してない、これからやる話。

変数名や関数名で報告されても、俺にはわからん

俺の開発スタイルはコードをほぼ書かない。命名は全部Claudeがやってる。だからClaudeから「handleUserSubmit を修正しました」と言われても、正直ピンとこない。

これって裏を返すと、Claudeが報告のために変数名や関数名を引用するのは俺にとって情報量ゼロということ。人間向けには親切な情報でも、俺という読者にとってはノイズに近い。

だったら「送信ボタンを押したときの処理を直した」と意味のわかる言葉で説明してもらえばいい。名前の引用を減らせば、そのぶん報告は短くなるし、俺の理解も早い。一石二鳥。

判断を求められてる部分は手厚く、前段の説明は薄く

あと気づいたのが、Claudeの報告って「やったこと」の説明がけっこう長い。でも俺が一番読みたいのは最後の「で、どうする?」の部分。

判断を求められてる箇所、つまり俺が返事しないと進まない部分は手厚く書いてほしい。でもその前段——どのファイルを読んで、何を確認して、どういう経緯で、みたいな情報——は正直、結論出す上ではそんなに要らない。必要になったら聞くから、デフォルトは薄くていい。

この2つはルールファイルに書いて渡せば効くはずで、次はそこを詰めていく予定。

まとめ

トークン節約って、要するに AIに人間向けフォーマットを読ませない ことなんだな、というのが今回の一番の気づき。

ECCは「余計なことをしない」方向で、RTKは「入力を削る」方向で、Cavemanは「出力を削る」方向で、それぞれ別の角度から同じ原則を解こうとしてる。全部入れれば最強、というより、用途に合うものを選ぶのがよさそう。俺の場合は秘書の言葉遣いを守りたいからCavemanは見送った。

そしてここから先は、自分の読み方の癖に合わせてさらに削っていく番だ。名前じゃなくて意味で説明してもらう、前段は薄く、判断は手厚く。この辺を詰めたらまた書こうと思う。

リミット食らったのは痛かったけど、おかげで「AIに渡す情報の設計」というテーマに向き合うきっかけになった。結果オーライ、かもしれない。