Claude Codeのトークン消費量について調べてみたので備忘録としてまとめる。
1. 導入
-
トークンとは、AIモデルがテキストを処理する際の最小の処理単位
- 日本語の場合、1文字〜数文字が1トークンになることが多く、英語とは変換比率が異なる。
- Claude Codeはトークン量(=コンテキストの大きさ)に応じて課金・レート制限がかかる。
- 不必要にトークンを消費しないことが重要
今回は以下3つの観点でまとめる。
- コンテキスト管理テクニック
- モデルの最適な使用
- その他のTips
2. コンテキスト管理テクニック
トークンコストはコンテキストサイズに影響するため、「コンテキストを小さく保つこと」が非常に重要。
2.1 セッションをこまめにリセット・整理する
背景
- Claude Codeは新しい発言だけでなく、それまでの会話履歴全部を毎回まるごと再送信している
- ターンを重ねるごとに「前回までの履歴」に「今回の分」が積み重なり、1リクエストあたりのコストが雪だるま式に増えていく
ターン1: [履歴なし] + 質問1 → 小さいリクエスト
ターン3: [履歴1+2] + 質問3 → 大きいリクエスト
ターン10: [履歴1〜9] + 質問10 → かなり大きいリクエスト
- つまり「今回の質問自体は短いから安いはず」は誤りで、コストは会話全体の長さで決まる。長時間セッションを開きっぱなしにしていると、内容の薄い一言のやり取りでもセッション全体分のトークンを毎回払うことになる。
対策
-
セッションを新しくする:無関係な作業に切り替えるときはセッションを新しくする。または、
/clearで会話をリセットする。 -
履歴を要約する:
/compactで要約する。また、カスタム指示を与えることで要約時に何を残すかを指摘できる。
例)/compact コードサンプルとAPIの使い方を中心に残して
のように、要約時に何を残すかを指定できる。-
また、CLAUDE.mdに圧縮方針をあらかじめ書いておくことも可能
# Compact instructions compactの際はテスト出力とコードの変更点を中心に要約してください
-
2.2 MCPサーバー・ツールまわりを最適化する
背景
- MCPサーバーが接続されていると、そのサーバーが提供するツール群の情報(サーバー名・説明・ツール一覧)分がコンテキストに乗り続ける。(ツールの詳細な入力スキーマ自体は既定で遅延読み込みされ、実際に使うまでは展開されない。)
- 未使用あるいは使用頻度の低いMCPサーバーを繋ぎっぱなしにしていると、呼ばれることのないツールの分も常にコンテキストを圧迫し続ける。
接続中のMCPサーバー:GitHub / Slack / Notion / Jira / Figma(5個)
今回のタスクで実際に使うのは… GitHubのみ
それでも毎リクエストのコンテキストには
[GitHub: 名前・説明・ツール一覧] ← 使う
[Slack : 名前・説明・ツール一覧] ← 使わないのに乗り続ける
[Notion: 名前・説明・ツール一覧] ← 使わないのに乗り続ける
[Jira : 名前・説明・ツール一覧] ← 使わないのに乗り続ける
[Figma : 名前・説明・ツール一覧] ← 使わないのに乗り続ける
が毎回積まれた状態で送信される
対策
-
未使用のMCPサーバーは無効化する:
/mcpで構成済みサーバーを確認し、今使っていないものは切る。 -
CLIツールを優先する:MCP経由よりもCLIコマンドをClaudeに実行させる。同じ操作でも、
ghなどのCLIコマンドで直接実行した方がMCP経由より、ツール定義のオーバーヘッドがなくコンテキスト効率が良い傾向にあるため。
2.3 CLAUDE.mdは薄く保つ
背景
- CLAUDE.mdはセッション開始時に全文が必ずコンテキストへ読み込まれる。PRレビューなど特定ワークフロー向けの詳細説明を書き込んでしまうと、それと無関係な作業のときも毎回同じトークンを払い続けることになる。
対策
- スキルに移す:手順・スクリプト・参考資料を伴うワークフロー的な内容(PRレビュー手順など)は、オンデマンドで読み込まれるスキルに移す。
-
.claude/rules/に移す:特定のファイル/ディレクトリ(例:src/api/**/*.ts)を触るときだけ適用したい規約・制約は、パス指定できる**.claude/rules/**に切り出す。該当パスを触らない限り読み込まれないため、CLAUDE.mdに書くより条件付きでコンテキストを節約できる。
.claude/rules/
api.md (paths: src/api/**/*.ts)
frontend.md (paths: src/frontend/**/*.tsx)
db.md (paths: src/db/**/*.ts)
例)src/api/users.ts を編集するとき
↓
api.md だけが条件に一致してロードされる
frontend.md / db.md は今回のパスに一致しないため読み込まれない
→ CLAUDE.mdに全部書いて毎回全文読ませるのではなく、
触っているファイルに関係あるルールだけがその都度乗る
- CLAUDE.mdは200行以内を目安にする:上記のスキル・rulesへの切り出しを進め、CLAUDE.mdには本当に毎回必要な最小限のことだけを残す。
2.4 プロンプトの書き方と作業の進め方
背景
- 「このプロジェクトを改善して」のような曖昧な指示は、Claudeに広範囲のスキャンを誘発し、不要なファイル読み込みを増やす。
- 方向性を確認しないまま実装まで進めてしまうと、間違った実装が生成され、そのやり取り(生成→指摘→修正)自体が余分なターンとコンテキストを増やす。
対策
- 具体的なプロンプトを書く:「auth.tsのlogin関数に入力バリデーションを追加して」のように具体化すると、最小限のファイル読み込みで済む。
- プランモードを使う:複雑なタスクの実装前にプランモード(Shift+Tab)で探索・提案させ、承認してから実行させる。方向性が間違っていた場合の高コストな手戻りを防げる。
-
早めに軌道修正する:おかしな方向に進み始めたらEscで即座に止める。
/rewindやEscダブルタップで会話とコードを直前のチェックポイントに戻せる。
2.5 フックで「読ませる量」自体を減らす
背景
- ログファイルやテスト出力などの生データをそのままClaudeに読ませると、それだけで大量のトークンを消費してしまう。中身のほとんどは無関係な行で、必要なのはごく一部(エラー行など)ということが多い。
$ npm test の生の出力をそのままClaudeに渡す場合
PASS src/utils.test.ts
PASS src/api.test.ts
PASS src/user.test.ts
...(成功ログが延々と続く)...
FAIL src/auth.test.ts
✕ should reject invalid token
Tests: 1 failed, 249 passed, 250 total
(全1万行)
→ 本当に必要なのはFAILした数行だけなのに、
1万行 ≈ 数万トークンをまるごとコンテキストに投入している
対策
-
フックで前処理する:Claudeに見せる前にデータを絞り込める。たとえば1万行のログファイルをそのまま読ませず、フック側(PreToolUseフック)で
ERRORだけgrepして渡せば、トークンを削減できる。
$ npm test を実行
↓
PreToolUseフックが出力を "FAIL|✕" でgrepしてフィルタ
↓
FAIL src/auth.test.ts
✕ should reject invalid token
→ 必要な数行(数百トークン)だけがコンテキストに入る
3. モデルの最適化
3.1 タスクに応じてモデルを使い分ける
-
/modelでセッション途中でもモデルを切り替え可能。
3.2 拡張思考(Extended Thinking)を調整する
- 拡張思考によって発生するthinkingトークンは出力トークンとして課金されるため、単純なタスクは
/effortまたは/modelでeffort levelを下げる。
通常の応答
プロンプト → 回答
拡張思考が有効な場合
プロンプト → 内部推論(thinking)【出力トークンとして課金】 → 回答
4. その他のTips
4.1 使用量の可視化
-
/usageで確認する:現在のセッションのトークン使用量・キャッシュ統計を確認できる。 -
/contextで確認する:何がコンテキストを消費しているかの内訳を確認できる。 -
ステータスラインに表示する:コンテキスト使用量を常時表示するように
/statusline等で設定しておけば、都度コマンドを打たなくても使用状況を把握できる。
4.2 プロンプトキャッシュ
- Claude Codeはプロンプトキャッシュにより、システムプロンプトなど繰り返し送信される内容のコストを自動的に削減している。
- キャッシュの有効期限(TTL)は利用形態によって異なる。
4.3 使用状況の分析
-
/insights:直近セッションを分析し、作業内容・つまずきポイント・改善提案をHTMLレポートとして出力してくれる。自分の使い方の癖を振り返るのに便利。
まとめ
| ジャンル | 今日から使える一手 |
|---|---|
| コンテキスト管理 | CLAUDE.mdは200行以内に。 |
| モデルの最適な使用 | タスクに応じてモデルの使用や拡張思考を調整。 |
| その他 |
/usage、/context、/insightsで可視化。 |