Partnered With:

Claude Code コンテキストの正しい処理方法: セッションが長くなるのを避け、モデルが「愚か」にならないようにします

この記事を読むのに必要な時間は 22 分

圧縮からロールバックまで、これらのテクニックをマスターすることで、Claude Codeが長時間の会話中でも常に高いレベルの出力を維持できます。

原文タイトル：Claude Code の使用：セッション管理と 1M コンテキスト
原著者：Thariq、Claude Code チームメンバー
翻訳：宝玉、AI 研究員

BlockBeats 注：AI プログラミングツールが常に「拡大表示」されている中、多くのユーザーがコンテキストが大きいほど体験が自然に向上すると誤解しています。しかし、Claude Code の研究者からのこのリアルタイム分析は、より冷静な答えを示しています：出力の品質を真に決定するのは、ウィンドウのサイズそのものではなく、それをどのように管理するかです。

「/usage」の更新から、「継続、巻き戻し、圧縮、クリア、サブエージェント」といった微操作の分解まで、この記事は頻繁に見落とされがちな能力を明らかにしましたーーそれが上下文スケジューリングの能力です。これはエンジニアリング上の問題だけでなく、認知上の問題でもあります：いつ過去を保持すべきか、いつ自発的に忘れるべきか、どのタイミングでタスクを分離すべきか、いつリスタートすべきか。これらの選択肢は、AI が「協力」しているか、「足を引っ張って」いるかを直接決定します。以下は原文の内容です：

今日、私たちは /usage コマンドの新しい更新をリリースしました。これは、Claude Code 内でのご自身の使用状況をより明確に把握するのに役立つものです。この決定の背後には、最近ユーザーとの複数回にわたる深い対話があります。

これらの対話の中で、私たちは何度も1つの現象を耳にしました：人々のセッション管理の習慣は様々です。特に最近、Claude Code はコンテキストウィンドウを 100 万まで拡張したことで、この差異がさらに明確になりました。

あなたは、ターミナル内で1〜2つのセッションのみを保持する習慣がありますか？それとも、各入力プロンプトごとに新しいセッションを開始しますか？圧縮（Compact）、巻き戻し（Rewind）、またはサブエージェント（Subagents）をいつ通常使用しますか？また、悪い圧縮の原因は何でしょうか？

実は、ここには多くの学びがあります。これら些細なように見える詳細は、Claude Code の使用体験に大きく影響を与えています。そして、これらすべての核心は、1つのことに帰結します：あなたのコンテキストウィンドウをどのように管理するか。

クイックガイド：コンテキスト、コンテキストの圧縮、コンテキストの減衰

「コンテキストウィンドウ」とは、モデルが次の回答を生成する際に、一度に「見ることができる」すべての情報のことです。これには、システムプロンプト、これまでのチャット履歴、各ツール呼び出しとその出力結果、モデルが読んだすべてのファイルなどが含まれます。現在、Claude Code は最大 1 ミリオントークンの超大規模コンテキストウィンドウを持っています。

ただし、コンテキストを使用することにはいくらかのコストがかかります。これを通常コンテキストロットと呼んでいます。対話履歴が長くなるにつれて、モデルが処理する情報量が膨大になり、その結果、モデルのパフォーマンスが低下する現象です。これは、モデルの注意がより多くのトークンに分散されたためです。古い内容で重要ではなくなったものが、モデルが実行しているタスクに干渉し始めます。

コンテキストウィンドウには厳格な容量制限があります。そのため、ウィンドウをいっぱいにする寸前になると、行っているタスクを短い説明にまとめ、その説明を持って新しいコンテキストウィンドウで作業を続ける必要があります。

このプロセスをコンパクションと呼んでいます。もちろん、いつでもこの圧縮プロセスを手動でトリガーすることもできます。

想像してください。さっき、Claude に何かを手伝ってもらい、それが完了しました。今、コンテキストにはいくつかの情報（ツールの呼び出し、ツールの出力結果、あなたの指示など）が詰め込まれています。

次に何をすればよいでしょうか？驚くかもしれませんが、選択肢は実はたくさんあります：

· 継続（Continue）— 同じセッション内で、直接次のメッセージを送信する

· リワインド（/rewind または Esc キーを2回押す）— タイムトラベルし、以前のメッセージに戻り、そこから再試行を開始する

· クリア（/clear）— 新しいセッションを開始し、通常、直前の会話から抽出した簡潔な要約を添える

· コンパクト（Compact）— 現在の会話を要約し、その要約を元に作業を継続する

· サブエージェント（Subagents）— 次の段階の作業を、独自のクリーンなコンテキストを持つ別の AI エージェント（AI Agent）に委任し、その最終作業結果のみを取得する

直接「継続」することは最も自然な反応かもしれませんが、他の4つのオプションは、コンテキストをより良く管理するのに役立つよう設計されています。

新しいセッションを開始すべきタイミングは？

古いセッションを維持すべきか、新しいセッションを開始すべきか。経験則として、新しいタスクを開始するときは新しいセッションを開始すべきです。

100万のコンテキストウィンドウは、「今、より長く、より複雑なタスクを非常に信頼性の高い方法で完了できること」を意味します。例えば、Claudeにゼロからフルスタックアプリを構築してもらうなどです。

ただし、時には関連するタスクを実行することもあります。この場合、以前のコンテキストの一部を保持する必要がありますが、全てを保持する必要はありません。たとえば、新機能を書き終えた直後で、その機能の使用方法の文書を作成する必要があるとします。もちろん、新しいセッションを開始することもできますが、その場合、Claudeは書いた全コードファイルを再度読まなければならないため、処理が遅くなりコストもかかることになります。

「リワインド」を「修正」の代わりに使用する

私に「優れたコンテキスト管理能力」を代表する良い習慣を挙げさせるならば、それは間違いなく「リワインド（Rewind）」をうまく活用することです。

Claude Code では、Esc キーをダブルクリックする（または /rewind コマンドを実行する）と、任意の過去のメッセージに戻ることができ、そこからヒントを再提示することができます。そのノード以降のすべての会話は、コンテキストから完全に破棄されます。

AI の誤りを修正する際、「バックトラック」はしばしばより賢明なアプローチです。例を挙げると、Claude は 5 つのファイルを読み、1 つの方法を試みて失敗しました。あなたの本能的な反応はおそらく、ダイアログボックスに「この方法はうまくいかない、X 方法に変えてみてください。」と入力することでしょう。しかし、より賢い方法は、Claude がちょうどその 5 つのファイルを読んだ時点にバックトラックし、学んだ教訓を持って再び話しかけることです。「A 方法を使わないでください、foo モジュールはそれをサポートしていないので、代わりに B 方法を試してください。」

さらに、「ここから要約（summarize from here）」機能を使用して、Claude に自身の学びをまとめてもらうこともできます。これは、ちょうど落とし穴に落ちた直後の「未来の Claude」が、まだ行動を起こしていない過去の自分にメモを残してくれたような感覚です。

Context Compression vs New Session

会話が長くなるにつれて、その負担を軽減するためには、/compact（圧縮）を使用するか、/clear（クリアして最初から）を使用することができます。これらの操作は似ていますが、実際の動作は大きく異なります。

Compact（圧縮） は、モデルがこれまでの対話を要約し、この要約で長い履歴を置き換えることです。このプロセスは「損失あり」であり、重要な「何が重要か」の決定権を Claude に委ねることを意味します。

利点は、何も書く必要がなく、そして Claude は重要な経験教訓やファイルの記録を保持する際、あなたよりもより慎重かもしれないことです。また、圧縮の方向を制御するために指示を与えることもできます（例：/compact は認証モジュールの再構築に重点を置き、テストデバッグに関する内容を削除します）。

そして、/clear を使用する場合は、自分で要点をまとめる必要があります（例：「現在、認証ミドルウェアをリファクタリング中です。現在の制限事項は X で、関連する重要なファイルは A および B ですが、Y メソッドは除外されています」）。その後、非常にクリーンな状態で再スタートします。少し手間がかかりますが、その結果生じる新しいコンテキストは、あなたが本当に関連性のある本質だと考えるものの100％です。

どのような「圧縮」が失敗する可能性がありますか？

長時間のセッションが頻繁に立ち上がっている場合、圧縮の効果が非常に悪い状況に遭遇する可能性が高いです。私たちは、このような「失敗」が通常特定のポイントで発生することを発見しました：それは、大規模言語モデル（LLM）が次の作業方向を予測できない瞬間です。

たとえば、長いコードデバッグの後、システムは自動的に圧縮をトリガーし、以前のトラブルシューティングプロセスを要約しました。その結果、あなたは直後に「今、bar.ts で見た別の警告も修正してください。」とコメントしました。

しかし、さっきのセッションは前のバグのデバッグに完全に焦点を合わせていたため、修正しなかった警告はおそらく重要でない情報と見なされ、まとめ時に直ちに破棄された可能性が高いです。

これは非常に厄介な問題です。コンテキストの減衰に制約されているため、モデルは圧縮を実行する瞬間において、最も賢明でない状態にあることがよくあります。幸いにも、100 万のコンテキスト容量を備えているため、今では「次に何をしようとしているか」の説明を積極的に持参し、/compact を事前に実行するためのより広い余地があります。