最近、Claude Code ユーザーとの会話でよく出てくるテーマがあります。それは、100万トークンのコンテキストウィンドウが諸刃の剣であるということです。
これにより、Claude Code はより長く自律的に動作し、タスクをより確実に処理できるようになりますが、セッション管理を意識的に行わないと、コンテキスト汚染のリスクも生じます。
セッション管理はこれまで以上に重要になっており、それに関する質問も多いようです。ターミナルで1つのセッションを開いたままにするべきか、2つにするべきか？毎回新しいプロンプトで始めるべきか？コンパクト、巻き戻し、サブエージェントはいつ使うべきか？悪いコンパクトの原因は何か？
ここには、Claude Code の体験を大きく左右する驚くほど多くの詳細があり、そのほとんどはコンテキストウィンドウの管理に起因しています。
コンテキスト、コンパクション、コンテキストロットの簡単な入門
コンテキストウィンドウとは、モデルが次の応答を生成する際に一度に「見る」ことができるすべての情報です。システムプロンプト、これまでの会話、すべてのツール呼び出しとその出力、読み取られたすべてのファイルが含まれます。Claude Code のコンテキストウィンドウは100万トークンです。
残念ながら、コンテキストを使用するにはわずかなコストがかかり、これはしばしばコンテキストロットと呼ばれます。コンテキストロットとは、コンテキストが増えるにつれてモデルのパフォーマンスが低下する現象で、アテンションがより多くのトークンに分散され、古くて無関係なコンテンツが現在のタスクの妨げになるためです。当社の100万トークンモデルでは、約30万～40万トークンあたりでコンテキストロットが発生しますが、タスクに大きく依存するため、厳密なルールではありません。
コンテキストウィンドウにはハードな上限があるため、ウィンドウの終わりに近づいたら、作業中のタスクをより小さな説明に要約し、新しいコンテキストウィンドウで作業を続ける必要があります。これをコンパクションと呼びます。自分でコンパクションをトリガーすることもできます。
すべてのターンが分岐点
Claude に何かをお願いして、それが完了したとします。コンテキストにはいくつかの情報（ツール呼び出し、ツール出力、指示）が含まれており、次に何をするかについて驚くほど多くの選択肢があります。
- 続行 — 同じセッションで別のメッセージを送信
- /rewind (esc esc) — 以前のメッセージに戻り、そこから再試行
- /clear — 新しいセッションを開始。通常は、学んだことから抽出したブリーフを使用
- Compact — これまでのセッションを要約し、その要約の上で続行
- Subagents — 次の作業を、独自のクリーンなコンテキストを持つエージェントに委任し、結果だけを取り込む
最も自然なのは単に続行することですが、他の4つのオプションはコンテキスト管理を支援するために存在します。
新しいセッションを開始するタイミング
新しい100万トークンのコンテキストウィンドウにより、より長いタスクをより確実に実行できるようになりました。例えば、フルスタックアプリをゼロから構築させることも可能です。しかし、モデルのコンテキストが尽きていないからといって、新しいセッションを開始すべきでないというわけではありません。
私たちの一般的な経験則は、新しいタスクを開始するときは、新しいセッションも開始するべきだということです。
グレーゾーンは、関連するタスクを行う場合で、コンテキストの一部はまだ必要だが、すべては必要ない場合です。
例えば、実装したばかりの機能のドキュメントを書く場合です。新しいセッションを開始することもできますが、Claude は実装したばかりのファイルを再読み取りする必要があり、遅くなりコストもかかります。ドキュメント作成は高度な知能を必要とするタスクではないため、関連ファイルを再度読み取る必要がない効率性の向上のために、余分なコンテキストを維持する価値はあるでしょう。
修正する代わりに巻き戻す
良いコンテキスト管理を示す習慣を一つ選ぶとしたら、それは巻き戻しです。
Claude Code では、Esc を2回押す（または /rewind を実行する）と、以前の任意のメッセージに戻り、そこから再プロンプトできます。その時点以降のメッセージはコンテキストから削除されます。
巻き戻しは、修正において多くの場合より良いアプローチです。例えば、Claude が5つのファイルを読み、あるアプローチを試したがうまくいかなかったとします。あなたの直感は「それはうまくいかなかった。代わりにXを試して」と入力することかもしれません。しかし、より良い方法は、ファイル読み取りの直後に巻き戻し、学んだことを踏まえて再プロンプトすることです。「アプローチAは使わないで。foo モジュールはそれを公開していないので、直接Bに進んで」
また、「ここから要約」を使用して、Claude に学習内容を要約させ、ハンドオフメッセージを作成させることもできます。これは、何かを試してうまくいかなかった未来の自分から、過去の Claude へのメッセージのようなものです。
コンパクションと新しいセッションの比較
セッションが長くなると、負荷を軽減する方法が2つあります：/compact または /clear（新しく始める）です。これらは似ているように感じますが、動作は大きく異なります。
Compact は、モデルにこれまでの会話を要約させ、その要約で履歴を置き換えます。これは不可逆的で、何が重要かを Claude に任せることになりますが、自分で何も書く必要はなく、Claude は重要な学習内容やファイルをより徹底的に含める可能性があります。また、指示を渡すことで方向性を指定することもできます（/compact 認証リファクタリングに集中、テストデバッグは除外）。
/clear を使用する場合、あなたが重要なことを書き留めます（「認証ミドルウェアをリファクタリング中、制約はX、重要なファイルはAとB、アプローチYは除外済み」）そしてクリーンな状態で開始します。より多くの作業が必要ですが、結果として得られるコンテキストは、あなたが関連性があると判断したものになります。
悪いコンパクションの原因は？
長時間実行されるセッションを多く行っている場合、コンパクションが特に悪い場合があることに気づいたかもしれません。この場合、モデルが作業の方向性を予測できないときに、悪いコンパクションが発生することがよくあります。
例えば、長時間のデバッグセッションの後に自動コンパクションが作動し、調査内容を要約します。そして次のメッセージが「bar.ts で見たあの別の警告を修正して」だったとします。
しかし、セッションがデバッグに集中していたため、その別の警告が要約から落とされてしまう可能性があります。
これは特に難しい問題です。なぜなら、コンテキストロットのため、コンパクション時にはモデルの知能が最も低下しているからです。100万のコンテキストがあれば、自分がやりたいことの説明を添えて、積極的に /compact を行う時間がより多くあります。
サブエージェントと新しいコンテキストウィンドウ
サブエージェントはコンテキスト管理の一形態で、作業の一部が後で必要なくなる大量の中間出力を生成することが事前にわかっている場合に役立ちます。
Claude が Agent ツールを介してサブエージェントを起動すると、そのサブエージェントは独自の新しいコンテキストウィンドウを取得します。必要なだけ作業を行い、結果を統合して、最終レポートのみが親に返されます。
私たちが使用する思考テスト：このツールの出力は再び必要になるか、それとも結論だけで十分か？
Claude Code は自動的にサブエージェントを呼び出しますが、明示的に指示することもできます。例えば、次のように指示することができます：
- 「以下のスペックファイルに基づいて、この作業の結果を検証するサブエージェントを起動して」
- 「別のコードベースを読み通し、認証フローをどのように実装したかを要約するサブエージェントを起動して、その後自分で同じ方法で実装して」
- 「git の変更に基づいて、この機能のドキュメントを書くサブエージェントを起動して」
まとめ
まとめると、Claude がターンを終了し、新しいメッセージを送信しようとしているとき、あなたは決断のポイントに立っています。
将来的には、Claude 自身がこれを処理するのを支援してくれることを期待していますが、現時点では、これが Claude の出力を導く方法の一つです。
