このレッスンで学ぶこと
- コンテキストウィンドウとは何か、なぜ管理が必要なのかを理解する
/compactを効果的なタイミングで使い、セッションの質を保つ- 長大なファイルを扱うときの分割・要約戦略を身につける
- サブエージェントへの委譲でメインの会話のコンテキストを節約する考え方を理解する
- セッションを分割すべきタイミングを見極められるようになる
前提条件
- 入門コース Lesson 3（基本コマンド）を修了していること
- 実践コース Lesson 8（プロンプト設計）を読んでいると理解がスムーズです
コンテキストウィンドウとは何か
Claude Codeとのやり取りでは、これまでの会話、読み込んだファイルの内容、実行したコマンドの出力がすべて「コンテキスト」として保持されています。このコンテキストを保持できる容量には上限があり、これをコンテキストウィンドウと呼びます。
コンテキストウィンドウは、人間でいう「今この瞬間に覚えていられる作業記憶」に近いものです。会話が長くなったり、大きなファイルを何度も読み込んだりすると、このウィンドウはどんどん埋まっていきます。
重要なのは、コンテキストウィンドウが埋まるほど、Claude Codeの応答品質が落ちる傾向があるという点です。満杯に近づくと、以前の指示を見落としたり、関係のない情報に引っ張られたりすることがあります。たった一度のデバッグセッションやコードベース探索だけでも、数万トークンを消費することは珍しくありません。
つまり、コンテキストウィンドウは「使い切ってから心配するもの」ではなく、常に意識して管理すべき資源だということです。このレッスンでは、その具体的な管理方法を扱います。
ステータスラインや/contextのような機能を使うと、現在どれくらいコンテキストを消費しているかを確認できます。「なんとなく重くなってきた」と感じる前に、数値で状況を把握する習慣をつけましょう。
/compact を効果的に使う
コンテキストウィンドウが埋まってくると、Claude Codeは自動的に会話履歴を要約（compact）してスペースを空けます。しかし、自動圧縮に任せきりにするのではなく、自分のタイミングで明示的に/compactを実行したほうが、結果をコントロールしやすくなります。
基本の使い方
/compactこれだけで、現在の会話を要約し、重要なコード変更や決定事項を保持したまま、コンテキストを圧縮してくれます。
指示付きで圧縮の精度を上げる
何を優先して残してほしいかを指定すると、より意図に沿った要約になります。
/compact 認証まわりの変更内容とテスト結果を中心に残して/compact APIのエンドポイント設計の決定事項を優先的に残して圧縮すべきタイミングを見極める
次のような兆候が見えたら、/compactを検討するタイミングです。
- 同じファイルを何度も読み直している
- 会話の前半部分の内容を、Claude Codeがうまく参照できていない
- ステータスラインの残量表示が少なくなっている
区切りのよいタイミングで実行する
1つの調査やタスクが一段落したタイミングで/compactを実行します。タスクの途中で圧縮すると、進行中の細かい文脈が失われるリスクがあります。
必要なら指示を添える
後続の作業で必ず参照する情報（変更したファイル一覧、テストコマンド、設計判断）がある場合は、それを優先して残すよう指示します。
/compactは会話を要約して圧縮しますが、関連する文脈はある程度残ります。一方/clearはコンテキストを完全にリセットします。前のタスクと全く関係のない新しいタスクに移るときは、/compactではなく/clearを使ったほうが、無関係な情報に引っ張られずクリーンに始められます。
CLAUDE.mdに圧縮時の方針を書いておくこともできます。
## コンパクション方針
- 圧縮時は、変更したファイルの一覧とテストコマンドを必ず残すことこうしておくと、自動圧縮が走った場合でも、重要な情報が失われにくくなります。
長大なファイルを扱う際の分割・要約戦略
数千行のログファイルや、大規模な設定ファイル、肥大化したレガシーコードを丸ごと読み込ませると、それだけでコンテキストの大部分を消費してしまいます。
戦略1: 必要な範囲だけを指定する
ファイル全体ではなく、関係する関数・セクションだけを対象にするよう指示します。
src/legacy/order-processor.ts の中の calculateShipping 関数だけを見て、
バグの原因を調査して。ファイル全体を読み込む必要はない。戦略2: grep的に絞り込んでから読ませる
「このキーワードを含む箇所を探して、該当部分だけ詳しく見て」という指示は、全文読み込みより効率的です。
このログファイルの中で "ERROR" を含む行を抽出して、
直近のエラーパターンを分析して。戦略3: 要約を挟んでから次のステップに進む
長いファイルを読ませた後、そのまま作業を続けるのではなく、一度要約させてから次に進むと、後続のやり取りが軽くなります。
このファイルの主要な処理フローを箇条書きで要約して。
要約ができたら、その要約をもとに次の指示を出す。戦略4: 分割して段階的に処理する
巨大な移行作業やコードベース全体の調査は、一度に終わらせようとせず、ファイル単位・モジュール単位で区切って進めます。
まず src/api 配下のファイル一覧を取得して。
その後、1ファイルずつ順番に処理を進める。Claude Codeは指示がなければ、念のため広く読みにいく傾向があります。「ファイル全体を読む必要はない」「この関数だけ見ればいい」と明示するだけで、無駄なコンテキスト消費をかなり抑えられます。
サブエージェントへの委譲でコンテキストを節約する
調査や検証のために多くのファイルを読む必要があるとき、それをメインの会話で行うと、調査結果がすべてコンテキストに残り続けます。サブエージェントを使うと、調査作業を別のコンテキストウィンドウで実行させ、要約だけをメインの会話に戻すことができます。
サブエージェントの基本的な考え方
サブエージェントは、メインの会話とは独立したコンテキストウィンドウを持つ「特化型の作業者」です。たとえば、認証システムの実装方法を調べたいとき、関連ファイルを10個読む必要があったとしても、それらのファイル内容はサブエージェント側のコンテキストに留まり、メインの会話には調査結果の要約だけが返ってきます。
サブエージェントを使って、認証システムがトークンのリフレッシュを
どう処理しているか調査して。既存のOAuthユーティリティがあれば、
それも報告して。この指示を出すと、Claude Codeはファイル探索をサブエージェントに委譲し、メインの会話は調査結果の要約だけを受け取ります。結果として、メインの会話のコンテキントは無駄に膨らみません。
委譲が向いている場面
| 場面 | 理由 |
|---|---|
| 大規模なコードベース調査 | 多数のファイルを読む必要があり、メインに残すと無駄が多い |
| 実装後の検証・レビュー | 実装した本人とは別の視点でチェックさせたい |
| 並行して進められる独立したタスク | メインの作業を止めずに別の調査を進められる |
検証にもサブエージェントを使う
調査だけでなく、実装が終わったあとの確認作業にもサブエージェントは有効です。
サブエージェントを使って、今回の変更にエッジケースの考慮漏れがないかレビューして。実装の文脈を引きずらない新しいコンテキストでレビューさせることで、思い込みによる見落としを防ぎやすくなります。
Lesson 1で扱ったコードレビューの委譲や、Lesson 2のリファクタリング検証は、実はこのサブエージェントの仕組みを裏側で活用しています。「なぜか会話が長くなってもコンテキストが圧迫されにくい」と感じた場面があれば、それはサブエージェントが調査を肩代わりしていたからかもしれません。
セッションを分割すべきタイミングの見極め方
すべてのタスクを1つのセッションで続けるのは、必ずしも効率的ではありません。次のようなサインが見えたら、セッションを分けることを検討しましょう。
分割すべきサイン
- 無関係なタスクに脱線した: 最初は機能Aの実装をしていたのに、いつの間にか関係のないバグ調査をしている
- 同じ間違いを2回以上修正している: コンテキストが失敗したアプローチで散らかっている状態
- 会話が長時間・複数日にまたがる: 1日かけて複数の異なる機能に取り組んだ場合など
- チームメンバーに引き継ぐ: 別の人が作業を引き継ぐ場合、クリーンな状態からのほうがわかりやすい
分割の判断フロー
flowchart TD
A["今のタスクと次にやりたいことは関連している?"]
B["同じ問題を2回以上<br/>修正しようとした?"]
C["セッションが長時間・<br/>複数日にまたがる?"]
D["そのまま続行"]
E["/clear して<br/>新しいプロンプトで再開"]
F["/compact で要点を残しつつ継続"]
A -->|関連性が低い| E
A -->|関連性が高い| B
B -->|はい| E
B -->|いいえ| C
C -->|はい| F
C -->|いいえ| D
style E fill:#fff3e0,stroke:#e65100
style D fill:#e8f5e9,stroke:#2e7d32同じ問題を2回以上修正し続けているセッションは、たいてい「失敗したアプローチの残骸」でコンテキストが汚れています。そのまま3回目の修正を試みるより、/clearして、学んだことを踏まえた具体的なプロンプトで仕切り直したほうが、結果的に速く正確な解決にたどり着けます。
セッションを名前付けして管理する
複数のセッションを並行して進める場合は、名前を付けて管理すると、後から見つけやすくなります。
claude --resumeセッション再開時にわかりやすい名前（例: oauth-migration、checkout-bugfix）を付けておくと、数日後に再開する際もスムーズです。
まとめ
このレッスンでは、Claude Codeとの長いセッションを効率的に保つための、コンテキスト管理の考え方を学びました。
- コンテキストウィンドウは有限の資源であり、満杯に近づくほど応答品質が落ちる
/compactは区切りのよいタイミングで、必要なら指示を添えて使う。/clearとは目的が異なる- 長大なファイルは「全部読む」のではなく、範囲を絞り込み、要約を挟みながら段階的に扱う
- サブエージェントへの委譲によって、調査や検証をメインの会話から切り離し、コンテキストを節約できる
- 脱線・同じ修正の繰り返し・長時間化のサインが見えたら、セッション分割を検討する
コンテキスト管理は、Claude Codeを使い込むほど効いてくるスキルです。プロンプトの質（Lesson 8）とコンテキストの質（このレッスン）の両方を意識できるようになると、Claude Codeとのやり取りはぐっと安定します。
次のステップ
実践コースもいよいよ最終回です。Lesson 10: 生産性を計測し継続的に改善するでは、ここまで学んだテクニックの効果をどう測り、チームに広げ、改善し続けるかを学びます。