Claude Code を毎日回している人にとって、トークンの話は二種類ある。請求書が膨らむ話と、週の枠に当たって手が止まる話だ。削りどころは同じではない。日本語の記事では両方が「節約術」として一緒くたに並んでいることが多いので、この記事では各見出しに【API】【サブスク】【共通】を付けて分けた。まず自分がどちら側かを決めてから読み進めてほしい。
目次
その節約は、請求書の話か、枠の話か
従量課金（Claude Console や各クラウド経由）で使っている場合、消費したトークンがそのまま金額になる。公式ドキュメントは企業導入の実績として、1人あたり稼働日で約13ドル、月150〜250ドル、90%のユーザーは稼働日30ドル未満という数字を出している。削った分だけ請求が減る、素直な世界だ。
サブスク（Pro / Max / Team / Enterprise）は違う。払う額は先に決まっていて、制約は枠のほうにある。Team と Enterprise については、1人あたりの枠が5時間のローリング窓と週次の窓で回り、Claude のチャットや Cowork と共有される、と公式が明記している。
枠は全モデル共通なので、セッション上限や週次上限に当たったあとに /model でモデルを落としてもアクセスは戻らない。ここには例外があって、「Opus の上限に達しました」というモデル個別のメッセージが出ている場合は、モデルを切り替えれば作業を続けられる。手が止まったら、どちらのメッセージが出ているかを先に確かめてほしい。
同じ「トークンを減らす」でも、前者は金額を削る作業、後者は締め出されるまでの時間を伸ばす作業になる。以降の節は、効果の大きい順に並べてある。
削る前に測る【共通】
どこが太っているかを見ずに手を入れると、効かない場所を削って満足することになる。測る道具は3つある。
/context は現在の文脈の内訳を色つきのグリッドで見せる。文脈を食っているツール、肥大したメモリファイル、容量の警告まで出るので、最初に叩くならこれ。
/usage はサブスク利用者に効く。直近の消費をスキル・サブエージェント・プラグイン・MCPサーバごとに割り振って、それぞれの割合を出してくれる。長すぎる文脈やキャッシュミスのように、全体の10%以上を占める挙動には警告が付く。d と w で24時間と7日を切り替えられる。数字はこの端末のセッション履歴から計算した概算なので、別の端末や claude.ai の分は入らない。
ローカルのログを自分で集計したいなら ccusage がある（MIT ライセンス / Copyright (c) 2025 ryoppippi）。Claude Code が端末に残す JSONL を読むだけで、データを外に送らない。
# 文脈の内訳を見る（Claude Code のセッション内で実行）
/context
/usage
# ローカルのセッションログから日次の内訳を出す
npx ccusage@latest daily筆者はこの順で見ている。/context で「今この会話が何で重いか」を掴み、/usage で「先週なにに枠を使ったか」を見る。両方を見ないと、目の前の会話だけを直して満足してしまう。
毎ターン載っているものを削る【共通】
入力トークンは、会話の長さだけで決まらない。何も打っていない時点で必ず載っているものがある。
MCP は「繋いでいるだけで数万トークン」ではない
第三者の記事でよく見るのが「MCPサーバを4本繋ぐと毎メッセージ7,000トークン」「重い構成なら5万超」という数字だ。生の Messages API を自分で叩いているなら、この指摘は正しい。公式の料金ページは「ツール使用のリクエストは、tools パラメータに入れたぶんを含む入力トークンの総数で課金される」と明記している。ツール使用時に自動で足されるシステムプロンプトだけで Opus 5 は286〜406トークン、bash ツールの定義でさらに325トークンが乗る。
ところが Claude Code の公式ドキュメントには、こう書いてある。
MCP tool definitions are deferred by default, so only tool names enter context until Claude uses a specific tool.
（MCPのツール定義は既定で遅延読み込みされる。Claude が特定のツールを実際に使うまで、文脈に入るのはツール名だけ）
出典: Manage costs effectively — Claude Code 公式ドキュメント
繋いだ本数ぶんのスキーマが毎ターン丸ごと乗る、という前提は現在の Claude Code には当てはまらない。翻訳記事の数字をそのまま信じてサーバを全部外すと、能力だけ失って削減はさほど出ない。
それでも公式が挙げる削りどころは2つある。ひとつは、gh や aws のような CLI が使える領域では MCP より CLI のほうが文脈効率が良いこと（ツール一覧そのものが乗らない）。もうひとつは、使っていないサーバを /mcp から無効にすること。実際にどれだけ食っているかは /context と /usage のサーバ別内訳で見える。推測で外す作業ではない。
手順の知識はスキルへ移す
CLAUDE.md はセッション開始時に読み込まれる。PRレビューの手順やDBマイグレーションの段取りをそこに書いておくと、まったく関係ない作業をしている間もその文字数を毎ターン払い続ける。
スキルは読み込まれ方が違う。公式の表現を借りると、スキルの本体は使われたときにだけ読み込まれるので、長い参照資料は必要になるまでほとんど無料だ。名前と説明だけが常駐して、呼ばれて初めて中身が開く。
公式が挙げている目安は「CLAUDE.md は200行未満、必須事項だけ」。筆者もグローバルの CLAUDE.md をこの線で維持していて、手順書は全部スキルに逃がしている。判断の基準は単純で、コードを読めば分かることは書かない。ディレクトリ構成やクラス名を文章で説明した瞬間、実体とずれ始める在庫を抱えることになる。
# CLAUDE.md に置いて効くもの（例）
- 常に必要な規約（ブランチ運用、コミット形式、禁止事項）
- コードを読んでも分からない決定（なぜこの構成にしたか）
- 環境固有の事実（どのドライブに何を置くか）
# スキルへ逃がすもの
- 手順（リリース、レビュー、移行の段取り）
- 長い参照表・テンプレート
- 特定の作業でしか使わない知識コンパクション時に残してほしいものを指定することもできる。CLAUDE.md にこう書いておくと、要約で消えると困る情報を守れる。
# Compact instructions
When you are using compact, please focus on test output and code changes会話の持ち方を変える【サブスク】
長く開けっぱなしのセッションが枠を食う理由は、公式ドキュメントがはっきり書いている。Claude Code は毎リクエストで会話全体を送り、ツールを使うたびにその結果を積んでまた送る。キャッシュ経由で安く読み直しているだけで、送っていること自体は変わらない。1日開けっぱなしの会話に一行の質問を投げると、その日ぶんの履歴まるごとが使用量として引かれる。
/clear は無料、/compact は無料ではない
「文脈が60%を超えたら早めに /compact」という助言をよく見かける。半分は当たっているが、コストの説明としては不正確だ。公式の記述はこうなっている。
/compactは要約する対象の会話を読むので、大きな文脈のコンパクションはそれ自体が大きなリクエストになる。続きが要らず新しく始めたいだけなら、/clearはコストがかからない。
出典: Manage costs effectively — Claude Code 公式ドキュメント（原文からの訳）
続きの文脈が要るなら /compact、要らないなら /clear。無関係な作業に移るときに惰性でコンパクションを走らせるのは、いちばんもったいない使い方になる。
キャッシュが切れる時刻を意識する
休憩から戻った最初の一投は、キャッシュ寿命を過ぎていると文脈全体を処理し直す。寿命はサブスクで1時間、usage credits を使い始めると5分に落ちる。APIキーやクラウド経由は既定で5分。昼休みを挟んで戻ったときの1発目が妙に重いのは、この仕組みで説明がつく。
脇の質問と、部分的な巻き戻し
長い作業の途中で別の疑問が湧いたとき、/btw を使うと会話に足さずに質問できる。答えが履歴に残らないので、次のターン以降の入力が太らない。
/rewind（Esc の二度押し）はコードと会話をチェックポイントまで戻すコマンドだが、公式の説明には「または会話の一部を要約する」と書かれている。全部を潰さずに、重い部分だけを畳める。
大量の出力を伴う作業は、サブエージェントに投げると本体の文脈が汚れない。テストの実行、ドキュメントの取得、ログの処理あたりが該当する。冗長な出力はサブエージェント側の文脈に留まり、本体には要約だけが返る。
複数のエージェントを同時に走らせる Agent teams は話が別で、公式は「プランモードで動かすと標準的なセッションの約7倍のトークンを使う」と書いている。各メンバーが自分の文脈窓を持つので、人数にほぼ比例して増える。複数エージェントの運用そのものに興味があれば、複数AIエージェントを1画面に統合した Claude Mission Control の開発ガイドで実際の構成を書いている。
外から持ち込む量を決める
Web の取得は文脈を一気に食う。公式が挙げている目安がこれ。
| 取り込むもの | データ量 | おおよそのトークン数 |
|---|---|---|
| 平均的なWebページ | 10 kB | 約2,500 |
| 大きなドキュメントページ | 100 kB | 約25,000 |
| 論文PDF | 500 kB | 約125,000 |
PDFを1本読ませると、20万トークン級の文脈なら半分以上が埋まる。100万トークンの窓を使っていても1割を超える。読ませる前に、必要なのが全文なのか一節なのかを決めておくと効く。
依頼の書き方も同じ話につながる。「このコードベースを改善して」は広い探索を誘発し、「auth.ts のログイン関数に入力検証を足して」は最小限のファイル読み込みで済む。AIへの依頼の組み立て方そのものはバイブコーディングの進め方をまとめたガイドで扱っている。
課金の仕組みを利用する【API】
プロンプトキャッシュ
同じ前置きを何度も処理させる代わりに、キャッシュから読ませる。倍率は入力単価に対してこうなっている。
| 操作 | 倍率 | 有効期間 | 元が取れる条件 |
|---|---|---|---|
| 5分キャッシュの書き込み | 1.25倍 | 5分 | 1回読まれた時点 |
| 1時間キャッシュの書き込み | 2倍 | 1時間 | 2回読まれた時点 |
| キャッシュの読み出し | 0.1倍 | 直前の書き込みと同じ | — |
読み出しが標準入力単価の10%なので、5分キャッシュは一度ヒットしただけで書き込みの割増を回収する。設計上の結論は単純で、長くて変わらないものを前に、短くて毎回変わるものを後ろに置く。前置きが固定されているほどキャッシュの前方一致が長く効く。
import anthropic
client = anthropic.Anthropic()
# 前に置くほど再利用が効く: 仕様書・規約・長い前提
# 後ろに置く: 毎回変わる指示
response = client.messages.create(
model="claude-opus-5",
max_tokens=4096,
system=[
{
"type": "text",
"text": SPEC_AND_CONVENTIONS, # 長くて変わらない
"cache_control": {"type": "ephemeral"},
}
],
messages=[{"role": "user", "content": todays_request}], # 毎回変わる
output_config={"effort": "medium"},
)
print(response.usage) # cache_read_input_tokens が伸びていれば効いているeffort が減らすのは作業量そのもの
effort パラメータは5段階ある。公式の説明では、これは応答内のすべてのトークンに効く。本文、ツール呼び出しと引数、思考のすべてだ。効果が分かりやすいのはツール呼び出しで、effort を下げると呼び出しの回数そのものが減る。
| レベル | 公式の位置づけ | 向く場面 |
|---|---|---|
max |
上限なしの最大能力 | 本当に難しい問題だけ。多くの作業では費用の増加に対して品質の伸びが小さい |
xhigh |
長時間の作業向けに拡張 | 30分を超えるエージェント作業やコーディング |
high |
既定。パラメータ省略と同じ | 複雑な推論、難しい実装 |
medium コスト削減の第一手 |
バランス型。適度なトークン節約 | 速度と費用と性能の釣り合いが要る作業 |
low |
最も効率的。能力は下がる | 単純な作業。公式はサブエージェント用途を名指ししている |
Claude Code からは /effort か /model の画面で変えられる。既定は Claude Code でも high で、effort に対応する全モデルのうち Opus 4.7 だけが xhigh から始まる。ここに落とし穴が2つある。
1つ目。会話の途中で effort を変えるとプロンプトキャッシュが効かなくなる。effort の値はレンダリングされるプロンプトに影響するので、前のターンのキャッシュ前方一致と噛み合わなくなる。公式の助言は「最初にレベルを決めて、その会話の中では変えない」。節約のつもりの切り替えが、キャッシュを捨てて逆効果になる。
2つ目。Opus 5 では effort を下げても、目に見える返答は確実には短くならない。effort が制御するのは思考量であって出力の長さではない。返答を短くしたいならプロンプトで長さを指定する。
単価そのものを見る
fast mode は Opus 5 / Opus 4.8 で入力10ドル・出力50ドル（標準は5ドル・25ドル）。入力も出力も2倍で、速さと引き換えの割増になっている。速いから得、という話ではない。
Batch API は入力・出力とも50%引きだが、非同期処理なので Claude Code の対話には使えない。まとめて回せる周辺の自動化には効く。
タスク予算（task budgets）はエージェントループ全体にトークンの目安を渡す機能で、モデルが残量を見ながら仕事を配分する。ただし公式の対応表は「Claude Code と Cowork では未対応」と明記している。Messages API を直接叩く構成でだけ使える。助言的な目安にとどまり、強制力は持たない。硬い上限は従来どおり max_tokens の役目になる。
道具を足すときはトレードオフごと引き受ける【共通】
ここまでは設定と習慣の話で、追加インストールは要らない。ここからは道具を足す話になる。効果は大きいが、副作用も大きい。
この分類の実在するツールを11本、スター数とライセンス本文まで確かめた一覧はClaude Codeのトークンを削るOSS 11本に分けて置いた。人気の2本が商用利用や再提供を許していないので、仕事で使うなら先に目を通してほしい。
コードベースを索引化する
grep で1ファイルずつ読ませる代わりに、コードをグラフ化して自然言語で引く。筆者は CodeGraph を入れていて（@colbymchenry/codegraph v1.5.0 / MIT ライセンス / Copyright (c) 2026 Colby Mchenry）、作業ディレクトリ全体を1つのグラフにしている。公式ドキュメントも、型のある言語ではコードインテリジェンス系プラグインを推奨している。定義へのジャンプ1回が、grep と複数ファイルの読み込みを丸ごと置き換えるという理屈だ。
トレードオフは真実の源が2つになること。索引と実体がずれると、AIはずれた索引を信じて自信満々に間違える。同期のタイミングを運用に組み込めないなら、入れないほうが安全になる。
ツールの出力を圧縮する
ビルドログやテスト出力は、AIに届く前に絞れる。公式ドキュメントが載せている例は、PreToolUse フックでテスト実行コマンドを書き換え、失敗行だけを返すというもの。1万行のログを読ませる代わりに、数百トークンで済ませる発想だ。
{
"hooks": {
"PreToolUse": [
{
"matcher": "Bash",
"hooks": [
{ "type": "command", "command": "~/.claude/hooks/filter-test-output.sh" }
]
}
]
}
}筆者の環境では、この考え方を全 Bash コマンドに広げたフックを常駐させている。累計の実測値と、そこから分かる「縮まないコマンド」の一覧は次の節に載せた。
トレードオフは非可逆であること。落とした情報は戻らないので、原因不明のバグを追っている最中は切ったほうがいい。「エラーの前後3行」に絞った結果、必要な1行が4行前にあった、という事故は起こりうる。
返答の冗長さを削る
AIの返答そのものを短く書かせるスキル群がある。実演では出力が半分程度になるものもある。筆者は入れていないので、効果は未検証と書いておく。
ここでの副作用は分かりやすい。削られた返答はそのまま会話履歴になり、次のターン以降の入力になる。短くした履歴の上で続きを考えさせるので、後半の回答品質に響く可能性がある。
筆者の環境では何をどう削っているか【共通】
ここまでの手当てを実際に入れている環境の中身を、測れる範囲で出しておく。数字はすべてこの記事を書いた時点（2026年7月30日）に取り直した実測値。
固定費：MCPは4本、手順は40個のスキルへ
接続している MCP サーバは4本だけ。コードの索引、外部記憶、スクレイピング、文字起こしで、どれも「外のシステムに繋ぐ」用途に絞ってある。
過去に入れて外したものが3系統ある。ひとつは実際の呼び出しが0回で、扱う対象のファイルも0件だったので撤去した。ひとつは使用実績が0だったので無効化した（設定は残してあるので1コマンドで戻せる）。もうひとつは系統ごと外した。判断の材料は毎回、実際に呼ばれた回数だ。使っていない接続を切る作業は、能力を落とさずに固定費だけ減らせる数少ない手当てだ。
逆にスキルは40個入れてある。手順書、チェックリスト、媒体別の執筆基準あたりが中身で、これは呼ばれるまで開かないので常時の負担にならない。グローバルの CLAUDE.md は155行で、公式の目安である200行の内側に収めている。
出力圧縮：2,461回で72.1%、ただし縮まないものは縮まない
Bash の出力を書き換えるフックの累計が、2,461回の実行で約569万バイトを159万バイトにしている。削減率72.1%。内訳を見ると、この手当ての向き不向きがはっきり出る。
| コマンド | 実行回数 | 削減率 |
|---|---|---|
ls 効果が最大 |
1,163 | 84.7% |
find |
347 | 77.1% |
grep |
247 | 72.1% |
git status |
79 | 64.4% |
git diff |
105 | 56.9% |
npm test |
29 | 36.6% |
cat |
273 | 28.1% |
git log |
114 | 14.7% |
tail |
69 | 9.3% |
定型の一覧はよく縮む。中身が一点物の出力はほとんど縮まない。tail の9.3%と git log の14.7%がその代表で、ここに手を入れても得るものは少ない。「出力圧縮で9割減」という売り文句を見たときは、自分の作業で定型出力が占める比率に当てはめて読むのが正しい。ファイル一覧を大量に叩く探索フェーズでは効くし、ログを1本ずつ読む調査フェーズでは効かない。
圧縮フックに入れた安全弁
この種のフックは PreToolUse でコマンドを書き換えるので、書き換えた後のコマンドを自動許可にしたくなる。ここに穴があった。許可を返す実装だと、設定側で読み取りを禁止しているファイルにも cat や grep 経由で到達できてしまう。
いまは .env・秘密鍵・証明書・認証情報らしい文字列を含むコマンドを検出したら、フックは何もせずに抜けて通常の許可判定に委ねている。効率化のために入れた仕組みが権限の抜け道になるのは、削減率と引き換えにしていいものではない。フックで自動許可を返す設計にするなら、ここは先に考えておいたほうがいい。
会話の持ち方：40%で警告、知識は外に置く
停止時のフックが、文脈の使用率が40%を超えると警告を出すようにしてある。正直に書くと、その警告文は「/compact を実行してください」になっている。公式の記述を読み直したあとの考えは少し違う。続きの文脈が要らない場面では /clear のほうが妥当で、この文面はいずれ直す。
知識そのものは会話に溜めない。決定・失敗・好みは外部のノートに書き、セッション開始時のフックが必要な分だけ注入する。この方針で一度事故を起こしていて、ノート検索に「一致したノートの本文を丸ごと返す」ツールを使ったところ、20万字を超えて読めなくなった。いまは検索は ripgrep で直接引き、当たったノートだけを開いている。
この失敗から引き出せる教訓は、節約の文脈でそのまま効く。戻り値の量を見ずにツールを繋ぐと、節約のために入れた仕組みが最大の浪費源になる。外部記憶も、コード索引も、検索ツールも、繋いだ瞬間に「1回呼ぶと何トークン返ってくるのか」を測る対象になる。
索引：169MB を1つのグラフに
コードの索引は作業ディレクトリ全体で1つにまとめてあり、データベースは169MBある。リポジトリごとに分けないのは、どのプロジェクトの話をしていても同じ引き方で済むからだ。裏返しとして、更新のずれが全体に効く。索引を足すなら、この同期をどう運用に組み込むかまで決めておく必要がある。
よくある誤解【共通】
調べ直すたびに、古い前提のまま出回っている話に当たる。公開時点（2026年7月）の一次情報で確認できたものを並べる。
| よく見る話 | 公式ドキュメントの記述 |
|---|---|
| MCPを繋いでいるだけで毎ターン数万トークン持っていかれる | Claude Code では既定で遅延読み込み。実際に使うまで文脈に入るのはツール名だけ。生の Messages API を自分で叩く場合は tools の中身ぶんが課金される |
| 1Mトークンの文脈は割高だから避けるべき | Claude 4.6 以降は100万トークンの文脈窓を標準単価で含む。90万トークンのリクエストも9千トークンと同じ単価。避ける理由があるとすれば品質と速度であって、単価ではない |
| モデルを新しくしたらトークンが増えた。無駄遣いしている | Claude 4.7 以降は新しいトークナイザを使い、同じ文章で約30%多いトークンを生む仕様。世代をまたいだトークン数の比較は成立しない。節約を測るなら同一モデル内で比べる |
| fast mode は速く終わるぶん安く済む | Opus 5 / 4.8 で入力・出力とも標準の2倍の単価 |
| effort を下げれば返答が短くなって節約になる | Opus 5 では effort を変えても返答の長さは確実には変わらない。effort が決めるのは思考量。長さはプロンプトで指定する |
文脈が埋まる前に、とにかく早めに /compact |
/compact は要約対象を読むので、それ自体が大きなリクエストになる。続きが要らないなら /clear はコストがかからない |
まとめ：筆者ならこの順で手を付ける
削るなら、道具を足す前に「毎ターン黙って載っている固定費」から。効果が最も大きく、副作用が最も小さいのはそこだけだ。
順序をもう一度書くと、①/context と /usage で測る、②CLAUDE.md とツール構成という固定費を削る、③/clear と /btw と隔離で会話を軽く保つ、④キャッシュと effort という課金の仕組みに合わせる、⑤それでも足りなければ道具を足す。上から順に、効果が大きくて副作用が小さい。
最後に、動画やこの記事のような「削減術」の一覧を見たときに思い出してほしいことがある。索引を足せば同期の手間が増え、圧縮を挟めばデバッグ時に外す判断が要り、返答を短くすれば後半の品質を見張ることになる。複雑さもコストだ。全部入れた環境は、壊れる場所も増える。
今日やる一手を選ぶなら、/context を一度叩いて、自分の文脈で何がいちばん場所を取っているかを見るところから。削る場所は、たいてい予想と違うところにある。
この記事の一次情報の出典: Pricing / Effort / Task budgets / Manage costs effectively / Commands（いずれも Anthropic 公式・2026年7月30日に確認）。価格と上限は変動が速いので、判断の前に各自で引き直してほしい。
