Claude Code を使いこなす: セッション管理と 1M コンテキスト

Claude Code の利用状況を把握しやすくするための新しいスラッシュコマンド /usage をリリースしました。この機能は、お客様との数多くの会話をもとに作られたものです。

そうした会話のなかで繰り返し浮かび上がってきたのは、ユーザーごとにセッションの扱い方に大きなばらつきがあるということでした。特に、Claude Code を 1M コンテキストに更新して以降はなおさらです。

セッションは 1 つ、あるいはターミナルに開いたままの 2 つだけを使うタイプでしょうか？ それとも、プロンプトのたびに新しいセッションを立ち上げるタイプでしょうか？ compact や rewind、サブエージェント を使うのはどんなときでしょうか？ compact やセッションが「悪い」状態になるのは何が原因でしょうか？

ここには驚くほど細かいポイントが詰まっており、それらが Claude Code での体験を大きく左右します。そして、そのほぼすべてはコンテキストウィンドウの管理に行き着きます。

コンテキスト、コンパクション、コンテキストロットの簡単なおさらい

コンテキストウィンドウとは、モデルが次のレスポンスを生成する際に一度に「見える」すべての情報のことです。システムプロンプト、これまでの会話、すべてのツール呼び出しとその出力、そして読み込まれたすべてのファイルが含まれます。Claude Code のコンテキストウィンドウは 100 万トークンです。

残念ながら、コンテキストを使うことはパフォーマンスにわずかな影響を与えます。これはしばしばコンテキストロット（context rot）と呼ばれます。コンテキストロットとは、コンテキストが大きくなるにつれてモデルの性能が低下する現象のことです。アテンションがより多くのトークンに分散され、古くて無関係な内容が現在のタスクから注意を逸らし始めるためです。

コンテキストウィンドウは厳密な上限なので、その終わりに近づくと、取り組んでいたタスクは自動的により小さな要約にまとめられ、モデルは新しいコンテキストウィンドウで作業を継続します。これをコンパクション（compaction）と呼びます。自分でコンパクションをトリガーすることもできます。

すべてのターンが分岐点

Claude に何かを頼み、それが完了したとしましょう。ここでコンテキストには情報（ツール呼び出し、ツール出力、あなたの指示）が蓄積されており、次に何をするかについて驚くほど多くの選択肢があります。

• Continue（続ける） — 同じセッション内で別のメッセージを送る
• /rewind（esc esc） — 以前のメッセージまで戻り、そこからやり直す
• /clear — 新しいセッションを開始する。通常、直前に学んだことをまとめた簡単なブリーフを携えて
• Compact — これまでのセッションを要約し、その要約の上で作業を続ける
• サブエージェント — 次の作業のかたまりを、まっさらなコンテキストを持つエージェントに委任し、結果だけを引き戻す

最も自然なのはそのまま続けることですが、残り 4 つの選択肢はコンテキストを管理するために存在しています。

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

長時間セッションを維持するのと、新しいセッションを開始するのと、どちらを選ぶべきでしょうか？ 私たちの一般的な経験則は、新しいタスクを始めるときには新しいセッションも始める、というものです。

1M コンテキストウィンドウによって、たとえばフルスタックアプリをゼロから構築するような長時間タスクもより確実にこなせるようになりましたが、それでもコンテキストロットは発生しうるものです。

関連するタスクを続ける場合には、一部のコンテキストが引き続き必要なこともあれば、そうでないこともあります。たとえば、実装したばかりの機能のドキュメントを書くようなケースです。新しいセッションを始めることもできますが、そうすると Claude は実装したばかりのファイルを読み直さなければならず、より遅く、より高コストになります。

訂正するのではなく巻き戻す

Claude Code では Esc を 2 回押す（または /rewind を実行する）ことで、以前の任意のメッセージまで戻り、そこから再プロンプトできます。その時点以降のメッセージはコンテキストから破棄されます。

Rewind は訂正よりも優れたアプローチであることがよくあります。たとえば、Claude が 5 つのファイルを読み、ある方法を試してうまくいかなかったとしましょう。「それはうまくいかなかった、代わりに X を試して」と入力したくなるかもしれません。しかし、より良い手は、ファイルの読み込み直後まで巻き戻し、学んだことを踏まえて再プロンプトすることです。「アプローチ A は使わないで。foo モジュールはそれを公開していないから、直接 B に進んで」と。

「ここから要約して」 と伝えたり /rewind スラッシュコマンドを使ったりして、Claude に学びを要約してもらい、引き継ぎメッセージを作ることもできます。これは、何かを試してうまくいかなかった過去の自分から、未来の自分へのメモのようなものです。

コンパクション vs 新しいセッションの起動

セッションが長くなってきたら、不要なコンテキストを削る方法は 2 つあります。/compact と /clear（新しく始め直す）です。似ているように感じますが、振る舞いはまったく異なります。

Compact は、モデルにこれまでの会話を要約するよう頼み、履歴をその要約で置き換えます。情報は欠落しますが、自分では何も書かずに済み、Claude が重要な学びやファイルをより網羅的に含めてくれるかもしれません。指示を渡してステアリングすることもできます（/compact focus on the auth refactor, drop the test debugging）。

/clear ではあなた自身が重要なことを書き出し（「認証ミドルウェアをリファクタリングしている、制約は X、重要なファイルは A と B、アプローチ Y は除外済み」）、新しい状態から始めます。より手間はかかりますが、結果として得られるコンテキストはあなたが関連すると判断したものそのものになります。

悪い autocompact の原因は何か？

長時間セッションを多く走らせていると、コンパクションの結果が特に悪くなるタイミングに気づいたことがあるかもしれません。こうしたケースでは、モデルがあなたの作業の向かう先を予測できないときに、悪いコンパクションが起きやすいことがよくあります。

上記の例では、長いデバッグセッションのあとに autocompact が発動し、調査内容を要約します。ところが、次のあなたのメッセージが「じゃあ、さっき bar.ts に見えたもう 1 つの警告を直して」だったとします。

セッションがデバッグに集中していたため、もう 1 つの警告は要約から落ちていたかもしれません。

これは特に厄介です。なぜなら、コンテキストロットにより、コンパクションを行う時点のモデルはもっとも賢くない状態にあるからです。1M コンテキストがあれば、やりたいことの説明を添えて /compact を先回りで実行する余裕がより多く得られます。

サブエージェントと新しいコンテキストウィンドウ

サブエージェントは、ある作業のかたまりが二度と必要にならない大量の中間出力を生み出すと事前にわかっているときにうまく機能する傾向があります。

Claude が Agent ツールを通じてサブエージェントを生成すると、そのサブエージェントは自身の新しいコンテキストウィンドウを得ます。必要なだけ作業を行い、結果を統合して、最終レポートだけを親に返すことができます。

私たちが Anthropic で使っているメンタルテストはこうです。このツール出力をまた必要とするか、それとも結論だけで十分か？

Claude Code は自動的にサブエージェントを呼び出すこともありますが、明示的に指示したい場合もあるでしょう。たとえば、次のように伝えるとよいかもしれません。

• 「次の仕様ファイルに基づいてこの作業の結果を検証するサブエージェントを立ち上げて」
• 「このもう 1 つのコードベースを読み、認証フローをどう実装しているかを要約するサブエージェントを立ち上げて、その後、同じやり方で自分で実装して」
• 「自分の git 変更をもとに、この機能のドキュメントを書くサブエージェントを立ち上げて」

まとめ

どのコンテキスト管理機能を使うべきかを判断する助けとして、よくある状況、手を伸ばすべきツール、そしてその理由をまとめた表を用意しました。

みなさんが何を作られるか、楽しみにしています。

‍

今日から Claude Code を始めましょう。

著者について: Thariq Shihipar は Anthropic のテクニカルスタッフのメンバーで、Claude Code に取り組んでいます。

‍