Claude Codeのコンテキスト管理術—トークン消費を抑える7つの工夫

Claude Codeのコンテキスト管理術—トークン消費を抑える7つの工夫 | mohablog

Claude Codeを使っていると、会話が長くなるにつれてレスポンスが遅くなったり、突然コンテキストが圧縮されて前の指示が飛んでしまったりすることがあります。自分もあるプロジェクトで、複雑なリファクタリングの途中にコンテキスト圧縮が走って、それまでの方針がリセットされてしまった経験がありました。

この記事では、Claude Codeのコンテキストウィンドウを効率よく使い、トークン消費を抑えるための7つの実践テクニックを紹介します。Claude Code 1.0系(2026年4月時点)を前提にしています。

目次

コンテキストウィンドウの仕組みを理解する

Claude Codeが保持する情報の正体

Claude Codeの会話は、すべてトークンという単位でカウントされています。ユーザーの入力、Claude Codeの応答、読み込んだファイルの中身、ツール実行の結果——これらすべてがコンテキストウィンドウに積み上がっていきます。

公式ドキュメントによると、コンテキストウィンドウの上限に近づくと自動的に古い会話が圧縮される仕組みになっています。この圧縮は要約ベースで行われるため、細かいニュアンスや具体的なコード片が失われる可能性があります。

トークン消費の内訳を把握する

意外と見落としがちなのが、ファイル読み込みによるトークン消費です。たとえば1000行のソースファイルを1つ読むだけで数千トークンを消費します。Claude Codeは必要に応じてファイルを読み込みますが、大きなファイルを何度も参照すると、それだけでコンテキストの大部分を占めてしまいます。

/costコマンドを使うと、現在のセッションでどれだけトークンを消費しているか確認できます。

$ /cost
Total cost: $0.42
Total input tokens:  45,230
Total output tokens: 12,890

定期的にこの数値を見る習慣をつけておくと、「思ったより消費してるな」というタイミングに気づけます。

CLAUDE.mdは「短く・的確に」が鉄則

やりがちなアンチパターン

CLAUDE.mdはプロジェクトのルールや構成をClaude Codeに伝えるための設定ファイルですが、あれもこれもと書き込みすぎるケースをよく見かけます。以下のようなCLAUDE.mdは典型的なアンチパターンです。

# プロジェクト概要
このプロジェクトは2024年1月に開始された...
(中略:プロジェクトの歴史を50行にわたって記述)

# ディレクトリ構成
src/
  components/
    Button.tsx
    Modal.tsx
    Header.tsx
    ...
(中略:全ファイルを列挙)

# コーディングルール
1. 変数名はキャメルケースで...
2. インデントはスペース2つで...
(中略:30項目以上のルール)

このようなCLAUDE.mdは毎回の会話で全文がコンテキストに読み込まれるため、100行を超えるとそれだけで無視できないトークンコストになります。しかも、ディレクトリ構成やファイル一覧はClaude Codeが自分で探索できる情報なので、書く意味がほとんどありません。

効果的なCLAUDE.mdの書き方

CLAUDE.mdには「Claude Codeがコードを読むだけでは分からない情報」に絞って書くのがポイントです。

# 技術スタック
- TypeScript 5.4 + React 19 + Next.js 15 (App Router)
- DB: PostgreSQL 16 (Supabase)
- テスト: Vitest + Playwright

# 開発ルール
- APIレスポンスの型は src/types/api/ に定義する
- コンポーネントはnamed exportのみ(default export禁止)
- エラーハンドリングは Result型パターンを使う

# コマンド
- dev: pnpm dev
- test: pnpm test
- lint: pnpm lint
約20行 — 必要最小限の情報だけを記載

この程度の分量であれば、トークン消費は数百程度で済みます。調べてみると、35行前後のCLAUDE.mdが最もコスト効率が良いという報告もあり、「短く・効く」が基本方針になります。CLAUDE.mdの設計についてはClaude CodeのCLAUDE.md設計 — チーム開発ルールを統一する仕組みで詳しく解説しています。

セッション管理—/clearと/compactの使い分け

/clearで会話を完全リセットする

/clearは会話履歴をすべて消去するコマンドです。タスクの区切りで使うのが基本で、たとえば「認証機能の実装」が終わって「ダッシュボードのUI作成」に移るタイミングなどが適しています。

$ /clear
Conversation cleared.

注意点として、/clearを実行すると会話中に確認したファイルの内容やこれまでの方針もすべて消えます。CLAUDE.mdに書いてあるルールは再読み込みされますが、会話内で合意した暗黙の方針は失われるので、必要なら事前にメモしておくのが安全です。

/compactで要約して会話を継続する

/compactはこれまでの会話を要約してコンテキストを圧縮するコマンドです。タスクの途中でトークン消費が気になり始めたときに便利です。

$ /compact
Conversation compacted. Previous context summarized.

カスタムプロンプトを渡して、要約時に保持したい情報を明示することもできます。

/compact 「現在の実装方針とTODOリストは必ず保持して」
Conversation compacted with custom focus.

以下の表で両者の違いをまとめます。

項目/clear/compact
会話履歴完全に消去要約して圧縮
トークン削減効果最大(ゼロに戻る)中程度(要約分は残る)
コンテキスト継続性なし要約ベースで維持
適したタイミングタスク切り替え時タスク途中でのリフレッシュ
カスタマイズ不可要約プロンプト指定可能

タスクが完全に切り替わるなら/clear、同じタスクを継続しつつコンテキストを軽くしたいなら/compact、という使い分けが基本です。

ファイル参照は必要最小限に絞る

@ファイル指定で読み込み範囲を制御する

Claude Codeにファイルを参照させるとき、何も指定しないとClaude Codeが自分で判断してファイルを読みに行きます。これ自体は便利ですが、関連しそうなファイルを次々と読み込むため、トークン消費が膨らみがちです。

代わりに、プロンプトの中で@ファイルパスを使って必要なファイルを明示的に指定すると、不要な読み込みを防げます。

// アンチパターン:曖昧な指示
「認証周りのバグを直して」
→ Claude Codeがauth関連のファイルを片っ端から読む
→ トークンが一気に膨らむ

// 推奨:ファイルを明示する
「@src/auth/login.ts の validateToken 関数でJWT検証が失敗するバグを修正して」
→ 必要なファイルだけ読み込まれる

ディレクトリ丸ごと参照の落とし穴

@src/ を見て全体的にリファクタリングして」のような指示は、ディレクトリ配下のファイルを大量に読み込む原因になります。ファイル数が多いプロジェクトでは、これだけでコンテキストの大部分を使い切ることもあります。

大規模なリファクタリングが必要な場合は、対象を絞って段階的に進める方がトークン効率も作業品質も上がります。1つのh2セクションの変更を1セッションで完了させるくらいの粒度が目安です。

プロンプト設計でトークンを節約する

悪い指示と良い指示の比較

プロンプトの書き方ひとつでトークン消費は大きく変わります。入力トークンだけでなく、曖昧な指示はClaude Codeの出力も膨らませるので二重に効いてきます。

// 悪い例:冗長で曖昧な指示
「このプロジェクトはReactとTypeScriptで作られたWebアプリで、
ユーザー管理機能があって、ログイン画面のバリデーションが
うまく動いてないので、ちゃんとしたバリデーションに直してほしい。
あと、エラーメッセージも日本語にしてほしい。」

// 良い例:簡潔で具体的な指示
「@src/pages/Login.tsx のメールバリデーションを修正。
- RFC 5322準拠の正規表現に変更
- エラーメッセージを日本語化」

プロジェクトの説明はCLAUDE.mdやコード自体から分かるので、指示には「何をしてほしいか」だけを簡潔に書くのが効果的です。Claude Codeは賢いので、必要な背景は自分でコードから読み取ってくれます。

出力形式を事前に制約する

Claude Codeの出力も当然トークンを消費します。「詳しく説明して」という指示より、出力形式を指定した方がトークン効率は良くなります。

// 出力が膨らみやすい指示
「このコードの問題点を教えて」
→ 長文の解説が返ってくる

// 出力を制約した指示
「このコードの問題点を箇条書き3点以内で簡潔に」
→ 必要十分な回答で済む

特にコードレビューや調査タスクではこの差が顕著です。

サブエージェントでコンテキストを分離する

調査タスクを委任するパターン

Claude Codeには、サブエージェントを使ってタスクを別のコンテキストに委任する機能があります。これはコンテキスト管理の観点で非常に強力です。

たとえば「このリポジトリでどのAPIエンドポイントが定義されているか調べて」のような調査タスクは、結果が膨大になりがちです。メインの会話でこれを実行すると、ファイル読み込みや検索結果がすべてコンテキストに乗ります。

サブエージェントに委任すれば、調査は別のコンテキストで実行され、メインには要約された結果だけが返ります。

// メインのコンテキストを節約する使い方
「Agentを使って、src/api/ 配下の全エンドポイントを
調査して一覧にまとめて」

→ サブエージェントが独自のコンテキストで調査
→ メインには一覧表だけが返る

並列実行でスループットを上げる

サブエージェントは並列実行も可能です。たとえば「フロントエンドの型エラーを修正」と「バックエンドのテスト追加」を同時に別エージェントで走らせれば、メインのコンテキストを節約しつつ作業を並列化できます。

ただし注意点もあります。

  • 並列エージェント同士はお互いの作業内容を知らない
  • 同じファイルを同時に編集するとコンフリクトする
  • 依存関係があるタスクには向かない

独立したタスクに分割できる場合に有効な手法です。Claude Codeの生産性を上げるテクニックはClaude Codeで開発効率を劇的に上げる方法でも紹介しています。

コンテキスト消費のモニタリングと自動圧縮への備え

/costで消費傾向を把握する

/costコマンドは単に現在の消費量を見るだけでなく、「このセッションの消費ペース」を体感するための手段です。たとえば、ファイルの大量読み込みが発生した直後に/costを打てば、「あの操作でこれだけ増えたのか」と実感できます。

目安として、入力トークンが10万を超えたら/compactを検討するくらいの感覚で運用すると、意図しない自動圧縮に巻き込まれにくくなります。

自動圧縮が走る前にやるべきこと

コンテキストウィンドウの上限に近づくと、Claude Codeは自動的に古い会話を圧縮します。このタイミングは自分で制御できないため、重要な文脈が失われるリスクがあります。

対策として、以下の3つを普段から意識しておくと安全です。

  • 重要な設計方針はCLAUDE.mdに書いておく(圧縮されても毎回再読み込みされる)
  • 長いセッションでは定期的に/compactで手動圧縮する(保持したい情報を指定できる)
  • タスクの区切りごとに/clearでリセットして仕切り直す

Hooks機能を使ったワークフローの自動化についてはClaude CodeのHooks機能を活用して開発を自動化しようも合わせてどうぞ。

まとめ

Claude Codeのコンテキスト管理で押さえておきたいポイントを振り返ります。

  • CLAUDE.mdは35行前後に抑え、Claude Codeが自力で分からない情報だけを書く
  • /clearと/compactをタスクの区切りや消費量に応じて使い分ける
  • ファイル参照は@で明示指定し、不必要な読み込みを防ぐ
  • プロンプトは簡潔・具体的に。冗長な背景説明はClaude Codeに任せる
  • サブエージェントを使って調査タスクのコンテキストを分離する
  • /costで定期的にトークン消費を確認し、10万トークンを目安に/compactを実行する
  • 重要な設計方針はCLAUDE.mdに記載しておけば、圧縮後も保持される

よくある質問(FAQ)

Q. コンテキストウィンドウの上限に達したらどうなる?

Claude Codeが自動的に古い会話の要約・圧縮を行い、新しいメッセージを受け付けられるようにします。ただし、圧縮された部分の詳細な情報(具体的なコード片や細かい指示内容など)は失われる可能性があります。重要な方針はCLAUDE.mdに記載しておくことで、圧縮後も確実に参照されます。

Q. /compactをどのくらいの頻度で使うべき?

明確な基準はありませんが、/costで確認して入力トークンが10万前後になったタイミングが一つの目安です。また、Claude Codeのレスポンスが遅くなってきたり、以前の指示と矛盾する回答が出始めたら、コンテキストが膨らんでいるサインかもしれません。作業の自然な区切りに合わせて使うのが、効率と継続性のバランスが取りやすいです。

Q. サブエージェントを使うとコストは増える?

サブエージェントは独自のコンテキストを持つため、トークン自体は追加で消費されます。ただし、メインのコンテキストが膨張して自動圧縮が何度も走ったり、圧縮で文脈が失われてやり直しになる方が、トータルのコストは高くつきます。大きな調査タスクや独立した修正作業はサブエージェントに委任した方が、結果的にコスト効率が良くなるケースが多いです。

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!
目次