クロード・コードにおけるコンテキスト管理

Claude Codeのコンテキストウィンドウが1Mになった。これで状況は大きく変わる。ただし、根本的なルールは変わらない。ウィンドウを大きくしたからといって、不適切なセッション管理が改善されるわけではない。

実際に結果を左右するのは、各ターン終了後に下す決断だ：

• 同じセッションを続けるか
• /rewind より良い分岐へと進むか
• /clear より良い分岐へ進み
• /compact 要約は保持する
• 次のチャンクをサブエージェントに移す

これこそが、Claude Codeにおける真のコンテキスト管理層だ。セッションがうまくいかない原因の多くは、モデルの性能が低いことによるものではない。間違ったコンテキストを長く持ち越してしまうことに起因しているのだ。

2026年4月15日のAnthropic公式ガイダンスはこの点を明確にした：すべてのターンは分岐点である。このページは、それを実用的なオペレーティングシステムへと変換する。

即効策

以下の2つのルールを直ちに適用する：

1. **新しいタスクには新しいセッション。**作業内容が本質的に変わった場合は、/clearを実行するか、新しいclaudeセッションを開始する。
2. **道に迷ったら、修正するのではなく巻き戻す。**Claudeが間違った分岐に進んでしまった場合、「それはうまくいかなかった、代わりにこれを試す」という指示を古いコンテキストの上に積み重ねるのではなく、/rewindを使用する。

この2つの習慣だけを取り入れても、セッションの平均的な質は急速に向上する。

コンテキスト、コンパクション、そしてコンテキストの腐敗

コンテキストウィンドウとは、モデルが次の応答のために参照できるすべての情報のことだ：

• システムプロンプト
• 会話履歴
• ツールの呼び出しと出力
• コンテキストに読み込まれたファイル
• 読み込まれたメモリと命令

Claude Codeは以前よりもはるかに多くの情報を保持できるようになった。しかし、だからといってコンテキストが不要になるわけではない。

コンテキストが増大するにつれ、パフォーマンスが低下する可能性がある。Anthropicはこれを「コンテキストの腐敗」と呼んでいる。注意がより多くのトークンに分散し、古い情報が残り続け、現在実際に重要視しているタスクと、古くて無関係な詳細が競合し始めるのだ。

ウィンドウが満杯になると、Claude Codeはセッションを圧縮する。つまり、現在の会話はより短い要約にまとめられ、その要約を基に作業が継続される。便利だが、情報の損失を伴う。

最大の過ちは、コンテキストをアーカイブのように扱うことだ。それはアーカイブではない。アクティブなワーキングメモリなのだ。

すべてのターンは分岐点である

Claudeがターンを終えると、いくつかの有効な手がある。どれが正しいかは、現在のコンテキストが依然として機能しているかどうかに依存する。

このページから1つの表を覚えるなら、それを使え。

5つの日常的なシナリオ

ここで抽象化が実用的なものとなる。実際のセッションのほとんどは、これらのパターンのいずれかに当てはまる。

1. 機能実装がドキュメント作成に変わる

認証ミドルウェアを完成させたばかりで、その変更に関するマイグレーションノートやドキュメントを作成したい。

最善の策：同じセッションで続ける

理由：コード、決定事項、エッジケースは依然として有用だ。その状態を再構築するのは時間の無駄になるだけだ。

2. Claudeが間違った実装方針を選んでしまった

正しいファイルを読み込んだものの、コードベースに合わないアプローチを採用してしまった。

最善の策：/rewind

理由：有用な探索は残し、失敗したブランチは破棄する。

3. 1つのタスクに、デバッグの残骸が多すぎる

同じ機能の開発中だが、作業履歴には無駄な試みや行き止まりのログが散在している。

最善の策：ヒント付きの/compact

理由：タスク自体は変わらない。セッションを整理する必要があるだけだ。

4. コーディングからロードマップの計画へと切り替えている

関連する領域だが、タスクの性質は異なる。

最善の手：/clear、または新しいセッションを開始する

理由：実装の残滓は、今やほとんどノイズに過ぎない。

5. 広範な監査が必要だが、重要なのは結論だけだ

別のリポジトリへの副次的な調査、仕様確認、あるいは広範囲な検索を行いたい。

最善策：サブエージェント

理由：中間的なノイズを親スレッドから排除するためだ。

同じセッションにとどめるべき場合

以下の場合は同じセッションで処理を続ける：

• タスクが依然として同一である場合
• Claudeが読み込んだばかりのファイルが依然として直接関連している場合
• 現在の推論チェーンが依然として有用である場合
• すべてを読み直すよりも、継続する方が速く、コストも低い場合

典型的な例：機能を実装したばかりで、その機能に関するドキュメントをClaudeに作成させたい場合だ。最初からやり直すことも可能だが、その場合、Claudeは既に文脈として把握しているコードを読み直さなければならない。タスクが関連しており、現在のセッションがまだ十分に整理されているなら、継続するのが合理的だ。

問うべきは「これは関連しているか？」ではない。「現在のコンテキストは依然として役に立つか？」である

新しいセッションを開始するタイミング

Anthropicの経験則は単純だ。新しいタスクを始める時は、新しいセッションも始めるべきだ。

以下の場合は、一から始めるべきだ：

• ある機能から別の機能に移行した場合
• セッションにデバッグや探索のノイズが多く含まれている場合
• 前の作業ブランチが完了したとき
• 次のタスクで異なるファイル、異なる目標、または異なる制約が必要になったとき

これは1Mコンテキストの場合でも重要だ。ウィンドウが大きければ、コンパクションが行われるまでの余裕が増える。ただし、無関係なコンテキストが無害になるわけではない。

新しいセッションへの移行の好例：

• 認証のリファクタリングを完了し、次に課金を開始する
• 実装を終え、ロードマップの計画に取り掛かる
• 1つの不具合のデバッグに40分費やし、別の課題に移行する

継続性が必要な場合は、新しいセッションの最初のプロンプトに短い引き継ぎ文を書き込む：

We just finished the auth middleware refactor.
What matters for this new task:
- the session format stayed unchanged
- files that matter now are X and Y
- we ruled out approach Z

New task: write the migration notes and docs.

古いセッション全体を引きずって持ち越すよりも、その方がすっきりしていることが多い。

修正する代わりに巻き戻す

/rewind これは、Claude Codeにおける最も効果的なセッション管理ツールの一つであり、かつ最も活用されていないものの一つでもある。

Claudeが大量のファイルを読み込み、誤ったアプローチを選択した際、次のように応答すると：

That didn't work. Try B instead.

というように返答すると、失敗した試み、その推論、そしてあなたの修正がすべて同じコンテキスト内に残ることになる。場合によってはそれで問題ないこともある。しかし、多くの場合、それは単なる「汚染」に過ぎない。

より良いパターン：

1. 有用な探索の直後の時点まで巻き戻す
2. 有益なファイル読み取りは保持する
3. 失敗した分岐は捨てる
4. そこで学んだことを踏まえて、その地点から再度プロンプトを出す

例：

Don't use approach A. The foo module does not expose that.
Go straight to approach B using the existing adapter in src/lib/foo.ts.

これにより、不要な分岐が積み重なることなく、Claudeに有用なコンテキストが提供される。

巻き戻しが最適なのは、以下の場合だ：

• 探索が有益だった場合
• 試みた実装が間違っていた場合
• 具体的なことを学んだ場合
• 証拠は残したいが、失敗の経緯は残したくない場合

/compact 対照的に、/clear

これらは互換性がない。

/compact を使用するのは、以下の場合だ：

• タスクが依然として同じ場合
• セッションが肥大化している場合
• Claudeに重要な学習内容を保持させたい場合
• 作業が同じ方向で継続している場合

圧縮を制御できる：

/compact focus on the auth refactor, drop the test debugging

モデルが最悪のコンテキスト状態に達する前に、1Mコンテキストにより積極的にコンパクションを行う時間が確保できるため、これは特に有用だ。

/clear を使用するタイミング：

• 新しいタスクの場合
• 現在のコンテキストを信用できなくなった場合
• 何が残るかについて完全に制御したい場合
• ロスのある要約を信頼するよりも、自分でハンドオフを記述したい場合

違いは単純だ：

• /compact claudeに何が重要かを決めさせる
• /clear 何が重要だったかを決めるのは自分だ

悪いコンパクトの原因

Anthropicの説明がここで役立つ：モデルがあなたの作業の次の方向性を予測できない場合、悪いコンパクトがよく発生する。

例：

1. ある問題のデバッグに長い時間を費やす
2. オートコンパクトが実行される
3. 要約はそのデバッグの道筋に焦点を当てる
4. 次のプロンプトで、別の（だが関連する）問題に切り替えた
5. コンパクト化処理が重要ではないと判断したため、求めていた詳細が除外された

これが、実際の作業の多くにおいて、手動の/compactが受動的なautocompactに勝る理由だ。要約を行う前に、Claudeに次の方向性を指示することができる。

役立つルール：

• 次の段階が分かっているなら、Claudeが推測する前に要約を行う

悪い例：

• 45分間デバッグする
• オートコンパクトを実行させる
• その後、急に方向転換する

良い例：

• デバッグフェーズを完了させる
• /compact focus on the fix plan and the files that matter nextを実行する
• 実装段階へ進む

避けるべきアンチパターン

不適切なコンテキスト管理は、通常、劇的な問題にはならない。それは単に、小さな怠慢な判断の積み重ねに過ぎない。

以下の点に注意する：

• 無関係な作業に1回の長時間のセッションを使う
• 不良ブランチを巻き戻す代わりに修正する
• 次のフェーズが分かっているのにオートコンパクトを待つ
• 親セッション内でノイズの多い調査を行ってしまう
• 「関連している」という理由だけで継続する

これらは、優れたモデルを矛盾しているように見せてしまう習慣だ。

サブエージェントを使って中間ノイズを排除する

サブエージェントは単なる委任ツールではない。コンテキスト管理ツールである。

アンソロピック・メンタル・テストは強力だ：

この中間出力は再び必要になるか、それとも結論だけで十分か？

答えが「結論だけ」なら、サブエージェントを使う方が多くの場合、よりすっきりした解決策となる。

サブエージェントに適した候補：

• 別のコードベースを読み込み、パターンを要約する
• 仕様書に基づいて実装を検証する
• Gitのdiffからドキュメントを作成する
• メインスレッドを煩わせたくない広範囲な検索を実行する
• 特定の監査を実行し、結果を報告する

これが機能する理由：

• 子プロセスには新しいコンテキストウィンドウが割り当てられる
• 多くの中間的なツール出力を生成できる
• 最終的な統合結果のみが親プロセスに戻ってくる

これは、メインセッションを長く有効に保つための最も簡単な方法の一つだ。

実用的なセッションルール

簡潔なプレイブックが欲しい場合は、以下を使用する：

ルール1：新しいタスクには新しいセッション

「関連」は「同一」とは異なる。

ルール2：間違った分岐なら、巻き戻す

失敗したパス自体がノイズとなっている場合、その上に修正を重ねてはならない。

ルール3：同じタスク、肥大化したコンテキスト、ヒントを使ってコンパクト化

何が残るべきか既に分かっているなら、自動圧縮を待たないこと。

ルール4：次のステップがノイズを含む場合は、サブエージェントを使用する

決定のためには親コンテキストを維持し、消耗させないこと。

ルール5：コンテキストが大きければ強制リセットは減るが、リセットがなくなるわけではない

1Mコンテキストは真のアップグレードだ。無敵ではない。

1Mコンテキストが実際に変えたもの

100万件のコンテキストは、セッション管理の経済性を3つの点で変えた：

1. 強制的なコンパクションの減少
2. より長い一貫性のあるタスクのための余裕が増えた
3. 状況が悪化する前に、先手を打ってコンパクションを行う時間が確保された

以下の必要性は変わらなかった：

• 新しいタスクでは最初からやり直す
• 不良なブランチを巻き戻す
• 無関係な作業に古びたデバッグを引きずらない
• ノイズの多い作業をサブエージェントに押し込む

1Mコンテキストのリリース後に生じた最大の誤解は、「これで全てを1つのセッションに収められる」というものだった。技術的には、より長いセッションも可能だ。しかし運用上は、それよりも明確な境界線を設けるべきだ。

/usage そして注目すべき点

Anthropicによると、新しい/usageコマンドは、長時間実行されるセッションや新しい100万コンテキストのウィンドウに関する顧客との対話に基づいて導入されたという。これは実際の問題に合致している。ほとんどのユーザーは単にコンテキストを増やすだけでなく、それをどのように使用しているかについて、より明確な可視性を必要としているのだ。

日々の意思決定においては、次の3点に注目すべきだ：

• 現在のタスクが依然として同じタスクであるかどうか
• 現在のコンテキストが依然として役に立っているか
• 次のステップには詳細な中間出力が必要か、それとも結論だけでよいか

これは、生のトークン数だけに固執するよりも、はるかに実践的なアプローチだ。

より良いコンテキストの習慣ループ

実際の業務日にこの手順を使ってみよう：

1. 明確なタスク1つでセッションを開始する
2. 現在のコンテキストがまだ有用な間は続ける
3. 分岐がうまくいかなくなったら巻き戻す
4. 自然なフェーズの変化で、ヒントを添えてまとめる
5. タスクが変わったらクリアする
6. 雑多な副次作業にはサブエージェントを起動する

これが動作モデルだ。

30秒の意思決定テスト

次に何をすべきか迷ったときは、次の3つの質問を自問するのだ：

1. これはまだ同じタスクか？
2. 現在の状況は、依然としてプラスになっているか？
3. 次のステップで生み出される中間成果物は、後で必要になるか？

答えが：

• はい / はい / はい → 続ける
• はい / いいえ / はい → 圧縮する
• はい／はい／いいえ → サブエージェント
• いいえ／いいえ／たぶん → クリアして再起動

これだけで、深く考えすぎることなく適切な判断を下せるのが普通だ。

出典

• Claudeコードの使用：セッション管理と100万文字のコンテキスト
• サブエージェント - Claude ドキュメント

関連ページ

• Claude Codeにおける1Mコンテキストウィンドウ
• コンテキストバッファの管理
• コンテキスト・エンジニアリング
• 動的な開始コンテキスト