コンテキスト管理 & /clear 戦略

なぜ「コンテキスト管理」が大事か

Claude Code は会話が長くなるほど コンテキストウィンドウ (1 リクエストで扱える最大トークン) に近づきます。 詰まると次の症状が出ます:

• 🐌 応答が遅くなる (毎回大量の履歴を再送するため)
• 💸 コストが膨らむ (input トークン × 単価で課金)
• 🤔 混乱しやすくなる (古い指示と新しい指示が衝突)
• ✂️ 古い情報が落とされる (上限超過時に頭から truncate)

長時間セッションでは コンテキストを意図的にコントロール するのが上級者の習慣です。

トークン経済 (Token Economy) — 何が context を食うか

⚠️ 特に危ないのは Bash の長いログ出力。npm install のフル出力を入れると 1 万トークン超もある。 解決策: head, tail, grep でフィルタ、または subagent 経由で要約だけ受け取る。

/clear vs /compact vs 新規セッション

/compact の挙動

会話履歴を Claude 自身が要約し、要約だけを残す。重要な判断や決定事項は要約に含まれる が、細かいコードのやり取りは消える。 30〜60 分のセッション後の「中休憩」で打つと効果的。

/clear の使いどき

• ✅ 「次は別のタスクをやる」と明確に切り替わる時
• ✅ Plan Mode で計画レビュー → 実装は新規セッションで
• ✅ デバッグの試行錯誤で文脈が混雑した時
• ❌ 同じタスクの途中 (続きを覚えていてほしい時) — /compact を使う

長時間セッションの 3 段階パターン

パターン A: 計画 → 実装 → レビューの分離

[セッション 1] Plan Mode で大規模変更を計画
   → 計画を CLAUDE.md か別ファイルに書き出して保存
   → /clear

[セッション 2] 計画ファイルを @ 参照しつつ実装
   → 完了したらコミット
   → /clear

[セッション 3] git diff を見せて自己レビュー

→ 各セッションがクリーンな状態で始まり、各々のタスクに集中できる。

パターン B: 1 機能 = 1 セッション

機能ごとにセッションを切る。claude --resume で過去のセッションは ID で戻せる:

claude --resume               # 直前のセッション
claude --resume <session-id>  # 特定セッション (一覧は ~/.claude/projects/ 下)

パターン C: 短時間バースト + Subagent

複雑な調査は Subagent (ch6-l5) に投げて、結果のサマリだけ親に戻す。 親セッションのコンテキストを節約しつつ、深い調査ができる。

/cost でモニタリング

> /cost
Total input tokens:     45,302
Total output tokens:     8,114
Total cost (estimated): $0.62
Session length:         01:23:14

定期的に確認する習慣を。5 万トークンを超えたら /compact の合図、と覚えておくと良い。

実用 Tips

• 🧹 タスク完了したら /clear か新規セッション — 「ついで作業」を同じ context でやらない
• 🎯 @ で必要なファイルだけ指定 — claude 起動直後に @README.md するより、必要になった時に @ する方が節約
• ✂️ 長いログは head/tail/grep でフィルタしてから渡す
• 🔁 会話が混乱したら早めに /compact — 粘らない方が結果的に早い
• 📁 Plan は別ファイルに保存 — 次セッションで @plan.md で読める
• ⚡ 重い調査は Subagent — 親 context を汚さない (ch6-l5 で詳説)

よくあるアンチパターン

• 🚫 「とりあえず全部 Read」 — 必要になってから @ で指定する
• 🚫 長時間 1 セッション固定 — 節目で /compact せず context が肥大
• 🚫 /clear 恐怖症 — リセットすると不安だが、節目では切るべき
• 🚫 巨大ログを丸ごと貼る — > ! npm install 2>&1 | tail -50 のように絞る