Claude Codeのトークン消費を半減させた10の実践テクニック——MAXプランでも油断するとすぐ上限に達する

Home / Blog / Claude Codeのトークン消費を半減させた10の実践テクニック——MAXプランでも油断するとすぐ上限に達する

Claude Code MAXプランでもトークン消費は無制限ではない。CLAUDE.mdの最適化、/compact活用、Plan Mode、サブエージェント設計など、実測データ付きで節約術を解説。

エンジニアのゆとです。

「MAXプランにしたから無制限に使える」——そう思っていた時期が僕にもありました。

現実は違う。Claude Code MAXプランには「5時間あたりの使用量上限」がある。重い処理を連発していると、昼の2時間で上限に達して残り3時間使えなくなる。そういうことが普通に起きる。

無制限に見えるプランでも、トークン消費の最適化は意味を持つ。むしろMAXプランユーザーこそ「同じことをより少ないトークンでやる」技術を身につけるべきだ。

自分が実際に試した結果、消費トークン量を体感で40〜50%削減できた10のテクニックをまとめる。APIの従量課金ユーザーには金額の話で、MAXプランユーザーには使用量の話で、両方に刺さる内容になっているはず。

1. MAXプランの「5時間レート制限」を理解する

まず前提として、Claude Code MAXプランがどういう制限を持っているか整理しておく。

MAXプランの制限は「月の総使用量」ではなく「5時間ローリングウィンドウ内の使用量」という形式になっている。5時間で一定量を超えると、その窓がリセットされるまで制限がかかる。

つまりどういうことかというと、「朝の集中作業で大量に使い切る」という使い方が最も損だ。

NG: 午前中に重いタスクを集中させて上限に達し、午後に使えなくなる
OK: 1日を通して均等に使い、5時間窓内に収める

この構造を知っているかどうかで、MAXプランの体験がかなり変わる。「なんか途中から使えなくなった」と感じている人は、これが原因のことが多い。

APIの従量課金プランの場合は、そのままコストに直結する。Claude Sonnet 4.6の場合、入力 $3/Mトークン・出力 $15/Mトークン（2026年4月時点）。100,000トークンの会話を100回繰り返すと入力だけで $30。節約の余地は大きい。

2. CLAUDE.mdのサイズを削ぎ落とす

すべてのセッションで毎回読み込まれるCLAUDE.mdは、トークン消費の「固定費」だ。

ここが肥大化していると、何もしていない状態から既に数千〜数万トークンを消費してスタートする。しかも全セッションで。

自分がやった最適化：

不要なルールを削除する

「いつかやるかもしれないから書いておいた」系のルールが必ず混入している。3ヶ月以上参照されていないルールは消す。ルールが少ないほど、Claude Codeが迷いなく動く（これは副次効果として品質も上がる）。

階層分離で「常時読み込み」を減らす

重要だが毎回は要らない情報は、別ファイルに分けてリファレンスとして書く：

# CLAUDE.md（メイン — 常時読み込み）

## プロジェクト概要
Astroブログ。TypeScript + Cloudflare Workers。

## コーディング規約
詳細 → docs/coding-rules.md を必要に応じて参照

## 権限レベル
GREEN: ファイル操作 → 確認不要
YELLOW: 設定変更 → 事前報告
RED: デプロイ・外部API → 事前承認必須

# docs/coding-rules.md（詳細 — 必要時だけ読む）

## 命名規則
（長い詳細内容...）

メインのCLAUDE.mdはエッセンスだけ。詳細は参照先を示して、必要なときだけ読ませる。

自分の環境では、この整理だけでCLAUDE.mdのサイズを1,200行から380行に削減した。セッション開始コストが体感で変わった。

プロジェクト固有のCLAUDE.mdを使い分ける

プロジェクトルートのCLAUDE.mdはそのプロジェクト専用の情報だけにする。「全プロジェクト共通のルール」と「このプロジェクト固有の情報」を混ぜない。

共通ルールは ~/.claude/CLAUDE.md（グローバル設定）、プロジェクト固有は ./CLAUDE.md（ローカル設定）。Claude Codeは両方読むが、ローカルのCLAUDE.mdにグローバルと同じ情報を重複して書かない。

3. /compact と /clear の正しい使いどころ

コンテキスト管理コマンドを正しく使うだけで、消費トークンを大幅に抑えられる。

/compact — 文脈を保ちながら圧縮

/compact

会話履歴を要約に置き換える。完全に消去せず、要旨だけを残す。

効果的な使い方は「フォーカスを指定する」こと：

/compact 認証機能の実装状況と未解決の課題に絞って要約して

漠然と /compact だけ打つと、Claudeが重要度を判断して要約するが、自分が重要だと思っている点が抜けることがある。何を引き継ぎたいかを明示する癖をつけると、コンパクション後の精度が上がる。

/clear — 完全リセット

タスクが切り替わるときは /compact より /clear が正解。試行錯誤の痕跡、採用しなかった設計案、解決済みのエラーログ——これらは「コンテキスト汚染」と呼ばれる問題を引き起こす。全部消してゼロスタートのほうが、次のタスクの精度が上がる。

実際の運用として、タスクの切れ目でどちらを使うか判断する基準：

同じ機能の作業が続く → /compact
全く別のタスクに移る → /clear
コンテキスト使用量が80%超えた → /clear（/compact する余地なし）

コンテキスト使用量は /status で確認できる。70%が /compact の目安、80%を超えたら迷わず /clear。

4. Plan Mode で無駄な試行を減らす

Plan Mode（/plan または Shift+Tab でトグル）は、実装前に「何をするか」だけを出力させるモードだ。ファイルの読み書きが発生しない。

なぜこれがトークン節約になるか。

複雑な指示をいきなり実行させると、Claude Codeは試行錯誤しながらファイルを読んだり書いたりを繰り返す。方向性が間違っていると、その試行分のトークンが全部無駄になる。

Plan Modeを先に使うことで：

実装方針を確認してから実行 → 方向違いのやり直しがなくなる
「このファイルを読む必要はない」と判断できる
不要なファイル読み込みを事前にカット

# まずプランだけ出す
claude "JWTの認証機能を追加したい。何をどの順番で変更するかプランを見せて。まだ実行しなくていい"

# プランを確認してから実行
claude "さっきのプラン通りに実装して"

自分の感覚では、複雑なタスクでPlan Modeを使うと、いきなり実装させる場合と比べてトークン消費が30〜40%減る。失敗→やり直しのループがなくなるのが大きい。

5. effortレベルをタスクに合わせる

effortはClaude Codeの思考の深さを制御するパラメータだ。内部的にはExtended Thinking（拡張思考）のトークン予算を調整している。

effortレベル	思考トークン	向いているタスク
low	最小	明確な1問1答、フォーマット変換
medium（デフォルト）	中程度	通常のコード生成、リファクタリング
high	大	アーキテクチャ設計、複雑なバグ調査

CLIからの指定：

claude --effort low "この変数名、英語でいい名前を3つ提案して"
claude --effort high "この認証フローの設計レビューをして"

「とりあえずhigh」が一番もったいない使い方だ。

フォーマット変換、変数名提案、コメント追加——こういう「答えが一意に決まる問題」はlowで十分で、highにしても出力は変わらない。むしろ余計な思考ログが混入して応答が長くなることすらある。

highを使うべき場面を限定する：

アーキテクチャの設計判断
セキュリティに関わるコードのレビュー
複雑な依存関係が絡むバグ

「ここ一番」のときだけhighにする、という使い分けが一番コスパがいい。ultrathink でターン単位のブーストも使える（これはグローバルのeffort設定を変えずにそのターンだけ上げる）。

6. サブエージェントで「メインコンテキスト汚染」を防ぐ

大量のファイルを読む調査タスクをメインのセッションでやると、コンテキストがあっという間に逼迫する。

この解決策がサブエージェント委譲だ。

# サブタスクを別インスタンスに委譲
claude --subagent "tests/ ディレクトリを全部読んで、テストカバレッジの低い部分を report.md に書き出して"

サブエージェントは独立したコンテキストで動く。タスク完了後にコンテキストがリリースされるため、メインセッションには結果（report.md）だけが残る。

これがない場合：

メインセッションで大量のファイルを読む
そのコンテンツがコンテキストに積み重なる
以降のすべてのリクエストで、その読み込み分も入力トークンとして計上される

サブエージェント委譲が効果的なタスク：

大規模なコードベースのスキャン・分析
複数ディレクトリのリファクタリング（ディレクトリ単位で分割）
レポート作成（ファイルを読んでまとめる系）

実際の使い方として、自分は「読んで要約してファイルに書き出す」系のタスクはほぼ全部サブエージェントに投げるようにした。メインの会話が散らからなくて快適。

7. .claudeignore でノイズファイルを除外する

Claude Codeはプロジェクト内のファイルを文脈として参照することがある。node_modules、dist、ビルド成果物——こういうファイルを誤って読み込まれると、意味のないトークンを大量に消費する。

.claudeignore をプロジェクトルートに置く：

# .claudeignore

# ビルド成果物
dist/
build/
.next/
.astro/

# 依存関係
node_modules/
.pnpm-store/

# ログ・テンポラリファイル
*.log
*.tmp
coverage/
.nyc_output/

# 大きなバイナリ
*.png
*.jpg
*.pdf
*.mp4

# 秘匿情報
.env
.env.local
*.pem

.gitignore の書き方と同じ文法が使える。.gitignore を流用する形でいい。

注意点として、画像ファイルを除外すると「このサムネイル画像を改善して」みたいな指示ができなくなる。除外するのはClaude Codeが「間違えて読んでしまう」可能性のあるファイルだけにする。意図的に見せたいファイルは除外しない。

8. Read のoffset/limitでファイルの読み込みを絞る

「ファイル全体を読む」より「必要な部分だけ読む」のほうがトークン効率は圧倒的にいい。

Claude Codeには Read ツールに offset と limit パラメータがある。1,000行のファイルから特定の関数だけ必要なら、その範囲だけを読ませられる。

指示の出し方で差が出る：

# 非効率
"src/services/auth.ts の認証ロジックを確認して"
# → ファイル全体を読み込む

# 効率的
"src/services/auth.ts の validateToken 関数（100行目付近）だけ確認して"
# → 必要な範囲だけ読む

さらに、「全ファイルを漁る」系の指示も同様：

# トークンが爆発する指示
"src/ 配下を全部読んで、問題がある箇所を教えて"

# トークン効率のいい指示
"エラーハンドリングが不十分な可能性があるのは auth.ts と user.ts だと思う。この2ファイルだけ見て確認して"

的を絞った指示は「何を読まなくていいか」を自分が判断することで、Claudeが不要なファイルを読む機会を減らせる。

9. MCPサーバーは必要なものだけ有効にする

MCPサーバーの設定が多いほど、セッション開始時のオーバーヘッドが増える。

MCPサーバーを追加するたびにツールの定義がコンテキストに追加される。10個のMCPサーバーを常時有効にしていると、そのツール定義分だけ毎セッションの固定コストが上がる。

対策は「プロジェクト単位でMCPサーバーを分ける」こと：

// .mcp.json（プロジェクト固有のMCP設定）
{
  "mcpServers": {
    "filesystem": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/project"]
    }
  }
}