この記事の結論
Claude Codeのトークン節約は、会話を毎回送り直す量を減らすのが先です。僕の会社では1リクエストの平均が約20〜27万トークンで、費用の59%がキャッシュの読み直しでした。
目次9項目
【無料・メールだけ】Claude Code 2daysセミナー（第二の脳構築講座）の次回開催の案内を受け取る →
Claude Codeのトークン節約で僕が最初に手を付けたのは、モデル選びではなく「毎回送り直している量」でした。Claude Codeは質問のたびに会話全体を送るので、前提と履歴が太いほど、一言の確認でも重くなります。僕の会社では、その量を測ってから対策の順番を決めました。
2026年9月16日、直近7日の201セッションを集計しました。1リクエストあたりの平均コンテキストは約20〜27万トークンで、セッションを開いた直後でも中央値で約9万トークンが積まれていました。
この記事では、集計から分かった原因の順位、効いた対策、重い処理を止めるために作ったフックと、それを3日で止めた理由まで書きます。「何から削れば枠が持つの？」と迷っている方は、最初の2章で順番がつかめます。
Claude Codeのトークン節約は「毎回送り直す量」を減らすのが先
Claude Codeのトークン節約でいちばん効くのは、1回ごとに送る文脈そのものを小さくすることです。出力を短くする工夫より、読み直される量を減らすほうが効き目は大きくなります。
公式ドキュメントの説明では、Claude Codeはリクエストのたびに会話全体を送ります。ツールを使えば、その結果を載せたリクエストがさらに1回増えます。
送り直した履歴は、プロンプトキャッシュで安い単価で読み直されます。ただ単価が安くても、20万トークンあれば毎回その量の処理がかかります。
ここでいうコンテキストとは、1回の応答のためにモデルへ送る情報の全部です。会話の履歴、読んだファイル、ツールの結果、毎回読み込まれる設定のファイルが入ります。
コンテキストの中身は/contextと/usageで見る
公式では、何が文脈を占めているかは /context で見るよう案内されています。今の使用量は /usage で確かめられ、ステータスラインに常に出すこともできます。
ProやMaxの契約なら、/usage には最近の使用量の内訳も出ます。スキル・サブエージェント・プラグイン・MCPサーバーごとの割合で、d と w で直近24時間と7日を切り替えられます。
長いセッションほど、一言の質問が重くなる
公式の説明にも、一日中開いたセッションでは1行の質問でも会話全体の分を使うとあります。休憩がキャッシュの寿命を超えると、次の1通で文脈を全部処理し直します。
待機中のセッションでも消費は起きます。定期タスクや別のセッションからのメッセージが届くと、そのたびに文脈を丸ごと送るためです。見えないところで回る分も、節約の対象になります。
201セッションを数えて分かった、トークンを食う6つの原因
僕の会社の集計では、いちばん大きな原因は毎回読み込まれる固定の前提で、全処理トークンの約33%を占めていました。effortや思考の深さは、6つの中で最も小さい原因でした。
集計日は2026年9月16日です。直近7日の201セッション・11,655往復と、直近30日の25,713リクエストを、手元に残る会話の記録から重複を除いて数えました。
1リクエストの平均コンテキストは約20万4,000〜27万トークンでした。中央値は19万〜23万、上位1割は48万〜60万トークンまで伸びていました。
30日分をAPIの単価に直すと、内訳はキャッシュの読み直しが59%、書き込みが29%、出力が12%で、新しい入力はほぼ0%です。この内訳をもとに、原因を削れる見込みの大きい順に並べました。
| 順位 | 原因 | 実測の手がかり | 削減の見込み（社内の試算） |
|---|---|---|---|
| 1 | 固定の前提の肥大 | プラグイン21個の説明文だけで40,198トークン。うち18個は60日間0回 | 20〜30% |
| 2 | セッションの長寿命化 | 1セッション平均96.7往復・最長1,761往復 | 15〜25% |
| 3 | 巨大なツールの結果 | 10万字超の結果が30日で3,697件（ファイル読み込み2,371件・ブラウザ操作1,309件） | 10〜15% |
| 4 | スクリーンショット | 30日で7,011枚が会話に混入 | 5〜10% |
| 5 | セッション間の連携・定期タスク | 待機中にも文脈を丸ごと送る | 3〜8% |
| 6 | effort・思考 | 出力の42.5%が思考。ただし出力は費用の12% | 3〜6% |
6位は小さく、思考が出力の4割を占めていても、出力そのものが費用の1割強なので、削っても上限が見えています。
逆に上位の2つは、作業の中身と関係なく毎回かかっていた分です。だから対策は、この順位のとおり上から当てると決めました。
7日の読み直しは23.7億トークン、上位10本で49%
消費の偏りも大きく、7日間のキャッシュの読み直しは合計23.7億トークンでした。そのうち上位10セッションだけで49%です。
長く伸びた少数のセッションが、全体の半分を食っていたことになります。料金と枠の関係は、Claude Codeの料金とMax 20xの実測に詳しく書きました。
出力の97.3%が上位のモデルに寄っていた
モデル別では、出力の97.3%がOpusとFableで、SonnetとHaikuは2.4%でした。一覧化や整形のような軽い作業まで、上のモデルで処理していたことになります。
効いた順に並べた、Claude Codeのトークン節約の対策
対策は、固定の前提を削る、会話を案件ごとに切る、大きな結果を入口で絞る、の順に当てました。モデルやeffortを下げるのは、その後です。
使っていないプラグインを止めて、毎セッション約4万トークン減
最初にやったのは、60日間で一度も使っていない18個のプラグインを無効にする作業です。1セッションあたり39,601トークン減り、週11,655往復に掛けると約4.5億トークン相当になります。
公式は、CLAUDE.mdが会話の開始時に読み込まれる点を挙げ、特定の作業の手順はスキルへ移すよう勧めています。スキルは呼んだときだけ読み込まれ、CLAUDE.mdは200行以内が目安です。
MCPのツール定義は、既定では後から読み込む形です。最初に入るのは名前とサーバーの説明だけですが、使っていないサーバーは /mcp で止められます。
案件が変わったら/clearで会話を切る
2つ目は、話題が変わったら /clear で新しい会話に切り替える運用です。公式も、古い文脈は以後のすべての送信でトークンを無駄にするとして、関係のない作業に移るときの /clear を勧めています。
/compact で要約して続ける方法もあります。ただ公式の説明では、要約そのものが会話全体を読む大きなリクエストです。続きが要らないなら、/clear には費用がかかりません。
僕の会社では、1セッション平均96.7往復を40往復以下にする目標を置きました。続きの作業は長い会話を伸ばさず、引き継ぎのメモを新しい会話で読ませます。
公式には、/clear の前に /rename で名前を付けておけば、後から /resume で戻れるとも書かれています。切るのが怖い人は、この組み合わせから始めると安心です。
--continue と --resume の使い分けや、引き継ぎメモの書き方はClaude Codeのセッションを再開する方法にまとめました。
ファイル読み込みとツールの結果に上限を付ける
3つ目は、巨大な結果を入口で絞る対策です。ファイル読み込み1回の結果は平均197KBで、30日で計868MBが文脈に入っていました。
このとき、ファイル読み込みの上限 CLAUDE_CODE_FILE_READ_MAX_OUTPUT_TOKENS を25000にしました。MCPの結果の上限 MAX_MCP_OUTPUT_TOKENS は20000です。
10月28日に公式を確かめると、どちらも既定は25,000トークンでした。MCPの結果は1万トークンを超えると警告が出ます。既定でも上限はあるので、下げるかは結果の大きさを見て決めれば足ります。
社内のルールでは、ファイルは全文ではなく必要な行だけ読むと決めています。大きなログやCSVは、grep で該当の行だけ取り出させます。
スクリーンショットは自動で半分の大きさにする
ブラウザ操作のスクリーンショットは、30日で7,011枚が会話に入っていました。社内の見積もりでは1枚およそ1,500トークンで、一度入ると以後の全ターンで読み直されます。
そこで、スクリーンショットに大きさの指定が無いときは、縦横を半分に縮めるフックを入れました。トークンは約4分の1になります。
ページの中身の確認は、文字の取得を基本にしました。画像を撮るのは、レイアウトを見るときだけです。
軽い作業は軽いモデルのサブエージェントへ
一覧化・整形・検索のような軽い作業は、Haikuで動くサブエージェントに回すルールにしました。出力に占めるSonnetとHaikuの割合を、2.4%から35%以上へ上げるのが目標です。
公式も、簡単なサブエージェントには model: haiku を指定する例を出しています。長いテストの出力やログの処理を任せれば、要約だけがメインの会話に戻ります。
担当ごとのモデルの決め方は、Claude Codeのモデル変更とサブエージェントのmodel指定に分けて書きました。
effortとモデルの格下げは最後に回す
effortの既定は、このときxhighからmediumに下げました。ただ効き目は3〜6%と見ていて、品質を落とさずに取れる分だけ取る位置づけです。
同じ週の量を各モデルで回した試算では、Fableを100%とするとOpus 5は78%、Sonnet 5は31%でした。費用の6割がキャッシュの読み直しで、その単価の並びが入出力の単価表と違ったためです。
僕はこの結果から、モデルを1段下げるより先に、送る量を減らすほうが確実だと判断しました。
重い処理の起動を止めるPreToolUseフック（cost-guard-gate.py）の中身
重い処理の歯止めには、ツールが動く直前に走るPreToolUseのフックを使いました。消費が一定を超えたら、Workflowや上位モデルへの委譲を deny で止める作りです。
ここでいうPreToolUseとは、ツールの実行直前にフックが呼ばれる時点です。公式の説明では、permissionDecision に deny を返すと呼び出しが止まり、理由の文がClaudeに渡ります。
置き場所は ~/.claude/hooks/ で、呼ばれるのはWorkflow・Agent・ブラウザ操作のときだけに絞りました。関係のないツールでは、そもそも動きません。
段階ごとの動きを、消費の目安と並べます。
| 段階 | 消費の目安 | フックの動き |
|---|---|---|
| 通常・注意 | 〜69% | 何も止めない |
| 節約 | 70%〜 | Workflow（複数のエージェントを一括で動かす機能）を止める |
| 厳格 | 85%〜 | 上に加え、Fableで動く深掘り・検品の担当への委譲も止める |
| 常時 | 段階に関係なし | スクリーンショットに大きさの指定が無ければ、半分の指定を足して通す |
スクリーンショットの縮小は、公式の updatedInput（実行前にツールの引数を差し替える項目）で実装しています。止めずに、指定を書き足して通す形です。
止めるときの理由の文には、代わりの手段と解除の方法を書きました。AIが止まったまま固まらず、軽いモデルのエージェント2〜3本で同じ調査をする代案を出せるようにするためです。
判定の物差しは、手元の記録から数えた自前の台帳
段階の判定には、手元の会話の記録から今週の消費を足し上げる自前の台帳を使いました。公式の週次の使用率を受け取れたときはそちらを正とし、無いときは台帳の値で判定します。
依頼を送った直後に動く UserPromptSubmit のフックも同じ台帳を読み、依頼を軽・中・重に分けて委譲を促します。
公式の説明では、このフックは依頼の文を書き換えられず、additionalContext で文脈を足すだけです。
普段の段階では、軽い依頼のときしか文を足しません。足す文もトークンになるからです。その軽い依頼のときに、1ターンの文脈が25万トークンを超えていれば、/clear や /compact を促す一文も足します。
フックの作り方の全体は、Claude Code hooksの使い方と実録に書いています。
自前の台帳が公式47%の時点で116%と判定し、自動停止の段を止めた
自動で止める段は、2026年9月19日に止めました。台帳の予算が公式の週次枠と合っておらず、公式は全モデル47%なのに、台帳は116%で厳格と判定していたからです。
台帳は公式の値が無いとき、APIの単価に直した額を自分で決めた予算で割っていました。その予算が実際の枠の約4割しかなく、枠を半分以上残したまま上位モデルへの委譲を止めていました。
いまは段階の判定を止めていて、重い作業を枠の理由で止めることも、弱いモデルへ回すこともしていません。動いているのは、スクリーンショットの縮小と、軽い依頼の委譲を促す部分だけです。
再開するなら、先に予算を公式の使用率に合う額へ直してから、と決めています。直さずに戻すと、すぐ厳格の段に入るからです。
当時の設定がすべて残っているわけでもありません。10月28日に設定ファイルを見ると、effortの既定はxhighで、読み込み上限の2つの環境変数も入っていませんでした。
いまも今週の消費は台帳の表示で確かめていますが、段階の判定には使っていません。重い作業を枠の理由で止めない、と社内のルールに書き直しました。
採用しなかったトークン節約策と、その理由
APIキーへの切り替え、他社のAIへの振り分け、時間帯で重い作業を寄せる方法は採りませんでした。検証すると、どれも前提が合わなかったからです。
APIキーを環境変数に置く方法は、社内の記録では「上限を超えたら自動で切り替わる」という前提が誤りでした。キーを置くと全リクエストがAPIの従量課金になり、購読の枠は使われません。
枠を超えて使い続ける正規の方法は、使用量クレジットです。公式の説明では、claude.aiの契約でログインしたうえで /usage-credits から設定します。
他社のAIへの振り分けは、文脈が切れて手戻りが増えるので見送りました。SonnetとHaikuへの振り分けで足りると判断しています。
午前中に重い作業を寄せる方法は、参考にとどめました。週次の枠はトークンで数えるもので、時間帯で枠が増える根拠は確認できなかったためです。
枠に当たって止まったときの待ち方や、5時間と週の枠の違いは、Claude 週間制限のリセットはいつ？5時間制限との違いにまとめています。
Claude Codeのトークン節約を自社で始める5つの手順
始めるなら、測る、固定の前提を削る、会話を切る、の順です。フックで止める仕組みは最後で足ります。
/contextで中身を見る：何が文脈を占めているかを確かめ、/usageで最近の内訳も見る- 使っていない拡張を止める：60日使っていないプラグインと、
/mcpで使っていないMCPサーバーを止める - CLAUDE.mdを200行以内にする：特定の作業の手順はスキルへ移す
- 案件が変わったら
/clear：続きは引き継ぎのメモに書かせ、新しい会話で読ませる - 軽い作業用の担当を1つ作る：定義ファイルに
model: haikuを書き、一覧化と整形を任せる
効いたかを判断するために、数字の目標も置いておくと迷いません。僕の会社では、1ターンの平均文脈を20万4,000トークンから13万以下へ、という目標にしました。
週次枠は、水曜で60〜70%使っていたのを、金曜で70%以下に抑える目標です。数字が2週間動かなければ、再開のときに止める段階の基準を下げると決めています。
まとめ
- Claude Codeのトークン節約は、毎回送り直す文脈の量を減らすのが先。消費の大半は出力ではなく読み直し
- 僕の会社の2026年9月16日の集計では、1リクエスト平均約20〜27万トークン、費用の59%がキャッシュの読み直し
- 効く順は、固定の前提を削る、案件ごとに
/clear、大きな結果を入口で絞る。effortは3〜6%の範囲 - 重い処理を止めるPreToolUseのフックは、自前の台帳が公式とずれて誤判定し、9月19日に自動停止の段を止めた
- 僕なら最初に
/contextで中身を見て、使っていないプラグインを止めるところから始めます
よくある質問
Claude Codeの/compactと/clearは、どちらがトークン節約になりますか？
続きが要らないなら/clearです。公式の説明では、/compactは要約のために会話全体を読むので、それ自体が大きなリクエストになります。/clearには費用がかかりません。続きを残したいときは、/compactの後ろに残してほしい内容を書いて要約させます。
effortを下げれば、Claude Codeのトークン消費は大きく減りますか？
大きくは減りません。僕の会社の30日の集計では、思考を含む出力は費用の12%でした。effortで動くのはこの範囲なので、効き目は3〜6%と見ています。先に、毎回送り直している文脈の量を減らすほうが効きます。
MCPサーバーは入れているだけでトークンを使いますか？
少しは使います。公式の説明では、MCPのツール定義は既定で後から読み込む形で、最初に文脈へ入るのはツール名とサーバーの説明だけです。使っていないサーバーは/mcpで止められます。
サブエージェントに任せると、トークンの節約になりますか？
メインの会話の節約にはなります。長いテスト結果やログの処理をサブエージェントに任せると、要約だけがメインに戻るからです。ただしサブエージェント自身のリクエストも枠を使うので、軽い作業には軽いモデルを指定します。
