【Claude Code中級編 #11】コンテキスト管理の技術——トークンを無駄にしない

長いセッションで「さっき決めたはずのことをClaudeが無視する」「試行錯誤のログが邪魔で的外れな返答が増えた」という現象が起きるのは、コンテキストの汚染と肥大化が原因であることが多い。

この記事でわかること：

コンテキストウィンドウの仕組みと「汚染」が起きる理由
/clear と /compact の使い分け
長期セッションでもパフォーマンスを保つ4つの戦略

コンテキストウィンドウとは

Claude Codeは会話の履歴をすべてコンテキストウィンドウに保持して動いている。これはトークン数に上限があり、会話が長くなるほど蓄積されていく。

新しい会話
  ↓
過去のやり取りがすべて含まれた状態で次のターンへ
  ↓
試行錯誤・失敗・やり直しも全部残る
  ↓
コンテキストが汚染・肥大化

重要な特性が2つある。

① コンテキストはロールバックできない

一度入った情報は消えない。「この前の提案は忘れて」と言っても、Claudeの内部では以前の流れを参照できる状態のまま。完全にリセットするには /clear が必要になる。

② 古い情報より新しい情報が優先される

コンテキストが長くなると、序盤の重要な指示より最後のやり取りの方が影響力を持つ。最初に決めたアーキテクチャ方針が、長いデバッグセッションの後に無視されるのはこのため。

コンテキストが重くなっているサイン

同じミスを繰り返す
「それはさっき決めましたよね」と確認が必要になる場面が増える
応答速度が徐々に遅くなる
関係ない過去の試行錯誤を参照した返答が出てくる

`/clear` — 完全リセット

/clear は会話履歴を全クリアするコマンド。CLAUDE.md の内容は残るので、プロジェクトのルールや技術スタックはリセット後も有効なまま。

/clear 実行後の状態

残るもの:
  - CLAUDE.md（プロジェクト指示書）
  - .claude/settings.json（ツール設定・Hooks）

消えるもの:
  - 会話の全履歴
  - ファイルの読み込み結果
  - 試行錯誤のログ

使うべきタイミング

タスクが完全に切り替わるとき

✅ バグ修正が終わって次は新機能の実装に入るとき
✅ あるファイルの作業が終わって別モジュールに移るとき
✅ 試行錯誤を捨てて最初からやり直したいとき

避けるべきタイミング

❌ 関連するタスクの途中（前の決定を引き継ぎたい場合）
❌ 重要な設計判断が記憶に残っているとき（先にCLAUDE.mdに書き出す）

`/clear` 前にやること

CLAUDE.mdに「決定事項」を書き戻してからクリアする。これをやらないと、長いセッションで積み上げた判断がすべて消える。

# CLAUDE.md への書き戻し例

## 設計決定（2026-04-10）

- APIレスポンスのキャッシュはRedisではなくDynamoDBで実装する（Redis導入コストの問題）
- エラーハンドリングはAPIゲートウェイ側で一元管理する方針

次のセッションでClaudeが同じ結論に再び辿り着く必要がなくなる。

`/compact` — 履歴を要約して圧縮

/compact は会話履歴を要約してトークンを節約するコマンド。/clear と違って記憶を保持したままコンテキストを軽くできる。

/clear   → 全消去（記憶なし）
/compact → 要約に置き換え（記憶あり・軽量）

使うべきタイミング

長いデバッグセッションや大量のファイル読み込みの後、まだ作業は続けたいがコンテキストが重くなってきたと感じるとき。

長いデバッグセッション（30分以上）
  ↓
/compact を実行
  ↓
「このエラーは〇〇が原因で、△△で解決した」という要約に圧縮
  ↓
引き続き同じコンテキストで作業できる

フォーカスを指定して圧縮する

/compact の後にフォーカス指示を渡すと、要約の精度が上がる。

/compact 認証周りのデバッグ結果と現在の実装状態を中心にまとめて

無指定だと均等に圧縮されるため、重要な決定事項が薄まることがある。作業のコアにフォーカスを当てる指示を入れる方が安全。

長期セッションの4つの戦略

① 1セッション1タスクの原則

複数のタスクを1つのセッションで片付けようとするとコンテキストが汚染される。タスクが切り替わるたびに /clear を打つ運用が最も安定する。

❌ よくあるパターン
「AのバグをFixして → Bの機能も追加して → ついでにCもリファクタして」
→ 試行錯誤が混在して精度が落ちる

✅ 推奨パターン
Aのバグ修正セッション → /clear → Bの機能追加セッション → /clear → ...

セッションを分けることへの心理的ハードルは高いが、実際には1セッション15〜30分で区切る方がトータルの作業効率が上がる。

② 決定事項はCLAUDE.mdに書き戻す

セッションを超えて価値のある情報はCLAUDE.mdに書き戻す。「コンテキストに入っているから大丈夫」という管理はセッションをまたいだ瞬間に崩壊する。

書き戻すべき情報の基準：

✅ アーキテクチャの判断（なぜこの構成にしたか）
✅ 採用・却下したライブラリ（理由つき）
✅ 繰り返し発生したエラーとその解決策
✅ 「次回からはこうして」という運用ルール

❌ 書き戻さなくていいもの
  → コードの実装内容（Gitに残る）
  → 試行錯誤の詳細（必要ならGitのコミット履歴を参照）

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

第5回で解説した Agent ツールを使うと、サブエージェントが独立したコンテキストで動く。メインセッションのコンテキストを消費せずに、調査・生成・確認などのタスクを切り出せる。

メインセッション（薄いコンテキスト）
  ├── Agent: 既存コードの調査 → 結果だけ返ってくる
  ├── Agent: テストコードの生成 → 結果だけ返ってくる
  └── Agent: ドキュメントの確認 → 結果だけ返ってくる

特に「大量のファイルを読み込んで調べる」タスクをサブエージェントに任せると、メインセッションのコンテキストが汚染されない。調査結果のサマリーだけが戻ってくる形になる。

④ 読み込む情報を最小化する

「とりあえず全部読ませる」運用はコンテキストを無駄に消費する。

❌ 非効率
Read: src/entire-directory/**

✅ 効率的
Grep: 特定の関数名やキーワードで絞り込む
→ 必要な部分だけ Read する

Claude Code が自律的にファイルを読み込むとき、CLAUDE.md に「調査前に必ずGrepで絞り込んでからReadすること」と書いておくと効果的。

コンテキストを汚染しないコツ

試行錯誤を始める前にコンテキストをクリーンな状態にしておくのが最も効果が大きい。

試行錯誤前に /clear

「うまくいかなかったアプローチ」がコンテキストに残ると、Claudeはその失敗パターンを参照して次の提案をする。新しいアプローチを試すなら、失敗ログをリセットしてから始める。

ファイル読み込みを必要最小限に

Read を使う前に Grep で絞る
→ マッチした行と前後だけ Read する
→ ファイル全体をコンテキストに入れない

エラーメッセージを丸ごと貼らない

長いスタックトレースをそのままペーストするとトークンを大量消費する。重要な行だけを抜き出してClaudeに渡す方がコンテキスト効率が上がる。

まとめ

やりたいこと	使う方法
完全リセットして新しいタスクを始める	`/clear`
記憶を保ちながら軽くする	`/compact <フォーカス指示>`
セッションをまたいで知識を引き継ぐ	CLAUDE.mdに書き戻す
メインコンテキストを汚染せずに調査する	Agentツール（サブエージェント）
そもそも無駄なトークンを使わない	GrepしてからRead・最小限の情報渡し

コンテキスト管理の本質は「何を入れるかより、何を入れないか」。不要な情報を入れない設計が、長いセッションでも精度を保つ一番の方法になる。

← 第10回：StopFailureとPermissionDenied——エラー・拒否への対処｜第12回：Sub agentとWorktreeの組み合わせ——並列開発の設計 →