原文タイトル:Claude Code を利用する:セッション管理と 1M コンテキスト
原著者:Thariq,Claude Code チームメンバー
原文翻訳:宝玉,AI 研究員
BlockBeats 注:AI プログラミングツールが常に「拡張ウィンドウ」を行っている今日、多くのユーザーがコンテキストが大きくなれば体験が自然に向上すると誤解しています。しかし、Claude Code の研究員からのこの最前線の回想では、より冷静な答えが提示されています:出力の品質を真に決定するものは、ウィンドウのサイズそのものではなく、それをどのように管理するかです。
/usage からの更新、そして「進める、巻き戻す、圧縮、クリア、サブエージェント」といった微操作の分解まで、この記事はしばしば見落とされる能力を明らかにしました——コンテキストのスケジューリング能力。これはエンジニアリング上の問題であると同時に認知上の問題でもあります:いつ過去を保持し、いつ自発的に忘れるべきか、いつタスクを分割すべきか、いつ新しいゲームを始めるべきか。これらの選択肢は、AI が「協力する」か「足を引っ張る」かを直接決定します。以下は原文の内容です:
本日、私たちは /usage コマンドの新しいアップデートをリリースしました。これは、Claude Code でのご自身の使用状況をより明確に理解するのをサポートすることを目的としています。この決定の背後には、直近でユーザーとの数回の深い対話がありました。
これらの対話の中で、セッション管理におけるユーザーの習慣の多様性について何度も耳にしました。特に最近、Claude Code がコンテキストウィンドウを 100 万にスケールアップしたことで、この違いがより明確になりました。
あなたはターミナルで開いておくセッションが 1 〜 2 つだけの習慣ですか?それとも各入力プロンプトごとに新しいセッションを開始しますか?通常、どのような状況で圧縮(Compact)、巻き戻し(Rewind)、またはサブエージェント(サブエージェント)を使用しますか?圧縮がうまくいかない不快な状況を招いた理由は何ですか?
これには学ぶべき点がたくさんあります。これら些細なように見える細部は、Claude Code の使用体験に大きな影響を与えています。そしてこれらすべての核心は、1 つのことに集約されます:コンテキストウィンドウの管理方法。

「コンテキストウィンドウ」とは、モデルが次の回答を生成する際に同時に「見る」ことができる情報のことです。これには、システムプロンプト、これまでのチャット履歴、各ツール呼び出しとその出力結果、さらには読んだすべてのファイルなどが含まれます。現在、Claude Code は最大 1,000,000 トークンの超大規模コンテキストウィンドウを持っています。
しかし、コンテキストを使用することには少しのコストがかかります。これを通常コンテキストロットと呼びます。対話履歴が長くなるにつれ、モデルが処理する情報量が増えすぎてしまい、その注意力が散漫になり、過去の重要な情報を忘れたり、無関連な内容に干扰されたりする現象です。
コンテキストウィンドウには硬性容量制限があります。そのため、ウィンドウをいっぱいにしようとすると、自分の作業を簡潔な記述にまとめて、その記述を持って新しいコンテキストウィンドウで作業を続ける必要があります。
このプロセスをコンパクションと呼びます。もちろん、いつでもこの圧縮プロセスを手動でトリガーすることもできます。

想像してみてください。あなたがClaudeに何かを手伝ってもらい、それがすでに完了したとします。今、あなたのコンテキストにはいくつかの情報が詰まっています(ツールの呼び出し、ツールの出力結果、指示など)。
次はどうすればいいでしょうか?驚くかもしれませんが、選択肢がたくさんあることに気づくかもしれません:
· 継続(Continue)—同じセッション内で、次のメッセージを直接送信する
· リワインド(/rewind または Esc キーを2回連続で押す)—タイムトラベルし、以前のメッセージに戻り、そこから再試行を開始する
· クリア(/clear)—新しいセッションを開始し、通常は直前の会話から抽出した簡潔な要約を含める
· コンパクト(Compact)—現在の会話を要約し、その要約を基に作業を継続する
· サブエージェント(Subagents)—次の段階の作業を、独自のクリーンなコンテキストを持つ別の AI エージェントに委任し、最終的な作業結果のみを取得する
直接「継続」することは最も自然な反応ですが、他の4つのオプションは、コンテキストをよりよく管理するのに役立つよう設計されています。

長時間続く古いセッションを維持すべきか、新しいセッションを開始すべきか。私たちの経験則は、新しいタスクを開始するときは新しいセッションも開始すべきだということです。
100 万のコンテキストウィンドウは、今やより長く、より複雑なタスクを非常に信頼性の高い方法で完了できることを意味します。例えば、Claude にゼロからフルスタックアプリケーションを構築してもらうことなどが挙げられます。
しかし、時には関連するタスクを実行しているかもしれません。その場合、以前のコンテキストの一部を保持する必要がありますが、全てではありません。たとえば、新機能の開発が終わり、今度はその機能のためのドキュメントを作成する必要がある場合です。もちろん新しいセッションを開始することもできますが、その場合、Claude は先ほど書いた全てのコードファイルを再度読まなければならないため、処理が遅くなり、コストがかかります。

「優れたコンテキスト管理能力」を代表する良い習慣を1つ挙げるとすれば、それは間違いなく「リワインド(Rewind)」をうまく活用することです。
Claude Code では、Esc キーをダブルクリックする(または /rewind コマンドを実行する)と、以前の任意のメッセージに戻ることができ、そこから再びヒントを再発行することができます。そのノード以降のすべての会話は、コンテキストから完全に削除されます。
AI のエラーを修正する際、"バックトラッキング" は通常より賢明な選択肢です。例えば、Claude が 5 つのファイルを読み、1 つの方法を試みて失敗したとします。あなたの本能的な反応は、ダイアログボックスに「この方法は機能しない、X 方法に変えてみてください。」と入力することかもしれませんが、より賢明なアプローチは、その 5 つのファイルを読み終えた直後の時点にバックトラックし、学んだ教訓を持ちながら、「A 方法を使わないでください、foo モジュールはそれをサポートしていません―直接 B 方法を試してみてください。」と再度伝えることです。
さらに、「ここから要約(summarize from here)」機能を使用して、Claude が学んだ教訓を要約メッセージにまとめることさえできます。これはまるで、ちょうど穴に落ちた「未来版の Claude」が、まだ行動を開始していない過去の自分にメモを残したかのような感覚です。

会話が長くなるにつれて、その会話を「軽くする」ためには、/compact(コンパクト化)または /clear(リセットして新しく始める)の 2 つの方法があります。これら 2 つの操作は似たように聞こえますが、実際の振る舞いは大きく異なります。
コンパクト(Compact) は、モデルがこれまでの対話を要約し、この要約で長い履歴を置き換えることです。このプロセスは「損失あり」であり、つまり、何が重要かを決定する権限を Claude に委ねることを意味します。
利点は、何も書く必要がないこと、さらに、Claude が重要な経験やファイル記録を保持する際、あなたよりも熟考する可能性がある点です。また、コンパクトの方向を制御するための指示を与えることで(例:/compact は認証モジュールの再構築に焦点を当て、テストデバッグに関する部分は破棄する)、コンパクトを管理することができます。

そして、/clear を使用する場合は、自分で要点をまとめる必要があります(例:「現在、私たちは認証ミドルウェアを再構築しており、現在の制約条件は X で、関連する重要なファイルは A と B です。また、方法 Y は除外されました」)。その後、非常にクリーンな状態から再開する必要があります。これには少々手間がかかりますが、新しいコンテキストから生じるものは、あなたが本当に関連性のある精華だと考えるものです。

長時間のセッションを頻繁に行っている場合、非常に効果の悪い「圧縮」に遭遇する可能性が高いです。このような「失敗」は通常、特定の瞬間に発生することがわかっています。それは、大規模言語モデル(LLM)が次の作業方向を予測できないときです。
たとえば、長いコードデバッグの後、システムが自動的に圧縮をトリガーし、以前のトラブルシューティングプロセスを要約しました。その結果、すぐに次のようなメッセージを送信しました。「さて、bar.ts で見たもう一つの警告も修正してください。」
しかし、先ほどのセッションの焦点がデバッグ前のバグに完全に置かれていたため、修正されていない警告はおそらく重要でない情報と見なされ、要約時に直接破棄されてしまった可能性が高いです。
これは非常に困難な問題です。コンテキストの減衰が制約されているため、モデルは圧縮時に最も「知能」がオフラインになることがよくあります。しかし、100 万のコンテキスト容量があるおかげで、/compact を事前に実行する際に、自分の次に何を行いたいかの説明を積極的に記述しておくことができます。

サブエージェントは、コンテキストを管理する素晴らしい手段でもあります。特定の作業が多くの「阅後即焚」(後で使用しない)中間結果を生むことが予想される場合、この手法は非常に有効です。
クロードがエージェントツールを介してサブエージェントを派生させると、その小さなエージェントは完全に新しいコンテキストウィンドウを取得します。そこで自由に作業し、何をしても構いません。成功すれば、それに結果を洗練させ、最終的なレポートだけを「親」のクロードに返します。
サブエージェントを使用するかどうかを判断する「魂の問い」は:将来、これらのツールの詳細な出力を見る必要がありますか、それとも最終的な結論だけが欲しいですか?
Claude Code は裏でサブエージェントを自動的に呼び出しますが、時々はあなたがそれに非常に明確に指示することもできます。 たとえば、それに次のように言うことができます:
· 「サブエージェントを派遣して、以下の仕様書に基づいて、私たちが行った作業が正しいかどうかを検証してください」
· 「サブエージェントを派遣して、別のコードライブラリを網羅し、そのライブラリがどのように認証フローを実装しているかをまとめ、私が真似てここでも実装してください」
· 「サブエージェントを派遣して、私の Git 変更履歴に基づいて、この新機能について説明書を作成してください」
要するに、Claude が回答を完了し、新しいメッセージを送信しようとしているときに、あなたは意思決定の分岐点に立っています。
将来的には、Claude が十分に賢くなり、これらすべてを自動的に処理できるようになることを期待しています。しかし、現時点では、これらの意思決定を熟達することが、Claude が高品質の結果を提供するための道筋です。

BlockBeats の公式コミュニティに参加しよう:
Telegram 公式チャンネル:https://t.me/theblockbeats
Telegram 交流グループ:https://t.me/BlockBeats_App
Twitter 公式アカウント:https://twitter.com/BlockBeatsAsia