Thariq @trq212
本日、Claude Codeの利用状況をより把握しやすくするため、/usageの新アップデートをリリースします。これは多数のお客様との対話から得られた知見に基づくものです。 ヒアリングで繰り返し挙がったのは、セッションの管理方法に大きなばらつきがあるという点でした。特にClaude Codeの100万トークンコンテキストへのアップデート以降、その傾向が顕著です。
ターミナルで開きっぱなしのセッションを1〜2個だけ使うのか？プロンプトごとに新しいセッションを始めるのか？compact、rewind、サブエージェントはいつ使うのか？「悪いcompact」は何が原因で起きるのか？
ここには驚くほど細かいノウハウがあり、Claude Codeの使い心地を大きく左右します。そしてそのほとんどは、コンテキストウィンドウの管理に行き着きます。
Today we’re rolling out a new update to /usage to help you understand your usage with Claude Code, this was informed by a number of conversations with customers.
What came up again and again in these calls is that there is a lot of variance in how you might manage your sessions, especially with our new update to 1 million context in Claude Code.
Do you only use one session or two sessions that you keep open in a terminal? Do you start a new session with every prompt? When do you use compact, rewind or subagents? What causes a bad compact? There’s a surprising amount of detail here that can really shape your experience with Claude Code and almost all of it comes from managing your context window.
コンテキストウィンドウとは、モデルが次の応答を生成する際に「見える」すべての情報のことです。システムプロンプト、これまでの会話、すべてのツール呼び出しとその出力、読み込まれたすべてのファイルが含まれます。Claude Codeのコンテキストウィンドウは100万トークンです。
ただしコンテキストの使用にはわずかなコストがあり、これはしばしば「コンテキストロット」と呼ばれます。コンテキストロットとは、コンテキストが膨らむにつれてモデルの性能が低下する現象です。注意がより多くのトークンに分散され、古い無関係な内容が現在のタスクから注意を逸らし始めるのです。
コンテキストウィンドウは絶対的な上限なので、終わりに近づくと、これまで取り組んできたタスクをより小さな記述に要約し、新しいコンテキストウィンドウで作業を続ける必要があります。これをコンパクションと呼びます。自分でコンパクションをトリガーすることもできます。
The context window is everything the model can "see" at once when generating its next response. It includes your system prompt, the conversation so far, every tool call and its output, and every file that's been read. Claude Code has a context window of one million tokens. Unfortunately using context has a slight cost, which is often called context rot. Context rot is the observation that model performance degrades as context grows because attention gets spread across more tokens, and older, irrelevant content starts to distract from the current task. Context windows are a hard cutoff, so when you’re nearing the end of the context window, you will need to summarize the task you’ve been working on into a smaller description and continue the work in a new context window, we call this compaction. You can also trigger compaction yourself.
Claudeに何かを頼んで、それが完了したとします。コンテキストにはいくつかの情報（ツール呼び出し、ツール出力、あなたの指示）が入っています。次に何をするか、選択肢は驚くほどたくさんあります。
- Continure — 同じセッションで次のメッセージを送る
- /rewind（esc esc） — 前のメッセージまで戻ってそこからやり直す
- /clear — 新しいセッションを始める。通常は今わかったことを凝縮した簡潔なブリーフを添える
- Compact — これまでのセッションを要約し、その要約の上で作業を続ける
- Subagents — 次の作業ブロックを、独自のクリーンなコンテキストを持つエージェントに委任し、結果だけを取り込む
最も自然なのは「続ける」ですが、他の4つの選択肢はコンテキスト管理のために存在します。
Say you've just asked Claude to do something and it's finished, you’ve now got some information in your context (tool calls, tool outputs, your instructions) and you have a surprising number of options for what to do next:
- Continue — send another message in the same session
- /rewind (esc esc) — jump back to a previous message and try again from there
- /clear — start a new session, usually with a brief you've distilled from what you just learned
- Compact — summarize the session so far and keep going on top of the summary
- Subagents — delegate the next chunk of work to an agent with its own clean context, and only pull its result back in
While the most natural is just to continue, the other four options exist to help manage your context.
いつ新しいセッションを始めるか長時間のセッションを維持するか、新しいセッションを始めるか？
私たちの一般的な目安はこうです：新しいタスクを始めるときは、新しいセッションも始めるべき。100万トークンのコンテキストウィンドウは、より長いタスクをより信頼性高く実行できるようになったことを意味します。
例えば、フルスタックアプリをゼロから構築させるようなケースです。ただし時には、関連するタスクで「一部のコンテキストは依然として必要だが、すべてではない」という場面もあります。例えば、実装したばかりの機能のドキュメントを書く場合。
新しいセッションを始めることもできますが、そうするとClaudeは実装したばかりのファイルを再度読み直さなければならず、より遅く、より高コストになります。
When do you keep a long running session vs starting a new one? Our general rule of thumb is when you start a new task, you should also start a new session.
1M context windows do mean that you can now do longer tasks more reliably, for example to have it build a full-stack app from scratch.
Sometimes you may do related tasks where some of the context is still necessary, but not all. For example, writing the documentation for a feature you just implemented. While you could start a new session, Claude would have to reread the files that you just implemented, which would be slower and more expensive.
良いコンテキスト管理を示す習慣を1つ挙げるなら、rewindです。
Claude Codeでは、Escを2回叩く（または/rewindを実行する）ことで、過去のどのメッセージにもジャンプして再プロンプトできます。その時点以降のメッセージはコンテキストから削除されます。
リワインドは多くの場合、修正よりも優れたアプローチです。例えば、Claudeが5つのファイルを読み、あるアプローチを試したが、うまくいかなかった。あなたの直感は「うまくいかなかった、Xを試して」とタイプすることかもしれません。しかし、より良い動きはファイル読み込みの直後までリワインドし、学んだことを添えて再プロンプトすることです。「アプローチAは使わないで、fooモジュールはそれを公開していない。Bに直行して。」
「ここから要約」 を使って、Claudeに学習内容を要約させハンドオフメッセージを作らせることもできます。これは、何かを試してダメだった「過去のClaude」から「未来のClaude」への引き継ぎメッセージのようなものです。
If I had to pick one habit that signals good context management, it’s rewind.
In Claude Code, double-tapping Esc(or running /rewind) lets you jump back to any previous message and re-prompt from there. The messages after that point are dropped from the context. Rewind is often the better approach to correction. For example, Claude reads five files, tries an approach, and it doesn't work. Your instinct may be to type "that didn't work, try X instead." but the better move is to rewind to just after the file reads, and re-prompt with what you learned. "Don't use approach A, the foo module doesn't expose that — go straight to B." You can also use “summarize from here” to have Claude summarize its learnings and create a handoff message, kind of like a message to the previous iteration of Claude from its future self that tried something and it didn’t work.
セッションが長くなったら、軽量化する方法は2つあります：/compactか/clear（そして新しく始める）です。似ているように感じますが、挙動は大きく異なります。 Compactは、モデルにこれまでの会話を要約させ、履歴をその要約で置き換えます。ロッシーです — 何が重要だったかをClaudeに判断させることになります。ただし自分で何も書く必要はなく、Claudeが重要な学びやファイルを含めるのにより徹底的かもしれません。指示を渡してステアリングすることもできます（/compact 認証リファクタリングに集中、テストデバッグは捨てて）。
/clear では、何が重要かを自分で書き留めて（「認証ミドルウェアをリファクタリング中、制約はX、重要なファイルはAとB、アプローチYは却下済み」）、クリーンに始めます。手間はかかりますが、得られるコンテキストは自分が関連すると判断したものだけです。
Once a session gets long, you have two ways to shed weight: /compact or /clear (and start fresh). They feel similar but behave very differently. Compact asks the model to summarize the conversation so far, then replaces the history with that summary. It's lossy, you're trusting Claude to decide what mattered, but you didn't have to write anything yourself and Claude might be more thorough in including important learnings or files. You can also steer it by passing instructions (/compact focus on the auth refactor, drop the test debugging).
With /clear you write down what matters ("we're refactoring the auth middleware, the constraint is X, the files that matter are A and B, we've ruled out approach Y") and start clean. It's more work, but the resulting context is what you decided was relevant.
長時間セッションを多く回していると、コンパクションが特に酷くなる時があることに気づくかもしれません。私たちがよく見るのは、モデルがあなたの作業の方向性を予測できないときに悪いコンパクションが発生するというパターンです。
例：長いデバッグセッションの後にオートコンパクトが発火し、調査内容を要約した。
次のあなたのメッセージは「では、bar.tsで見つけたあの別の警告を直して」。しかし、セッションがデバッグに集中していたため、その「別の警告」は要約から落とされている可能性があります。
これが厄介なのは、コンテキストロットによって、モデルがコンパクトする時点で最も知能が低くなっているからです。 100万トークンのコンテキストにより、やりたいことを記述しながら先回りして/compactする余裕ができました。
If you run a lot of long running sessions, you might have noticed times in which compacting might be particularly bad. In this case we’ve often found that bad compacts can happen when the model can’t predict the direction your work is going. For example autocompact fires after a long debugging session and summarizes the investigation and your next message is "now fix that other warning we saw in bar.ts." But because the session was focused on debugging, the other warning might have been dropped from the summary. This is particularly difficult, because due to context rot, the model is at its least intelligent point when compacting. With one million context, you have more time to /compact proactively with a description of what you want to do.
サブエージェントもコンテキスト管理の一形態で、「あとで二度と必要にならない大量の中間出力が出ると事前にわかっている作業ブロック」 に有効です。 ClaudeがAgentツールでサブエージェントをスポーンすると、そのサブエージェントは独自のフレッシュなコンテキストウィンドウを得ます。必要なだけ作業をして結果を統合し、最終レポートだけが親に戻ります。
私たちが使っているメンタルテスト：「このツール出力は後で再び必要になるか？それとも結論だけでいいか？」
Claude Codeは自動的にサブエージェントを呼びますが、明示的に指示したい場合もあります。例：
- 「サブエージェントを立ち上げて、この仕様ファイルに基づいてこの作業の結果を検証して」
- 「サブエージェントを派生させて、別のコードベースを読み認証フローの実装方法を要約して。その後、同じやり方で自分で実装して」
- 「サブエージェントを派生させて、私のgit変更に基づいてこの機能のドキュメントを書いて」
Subagents are a form of context management, useful for when you know in advance that a chunk of work will produce a lot of intermediate output you won't need again. When Claude spawns a subagent via the Agent tool, that subagent gets its own fresh context window. It can do as much work as it needs to, and then synthesize its results so only the final report comes back to the parent. The mental test we use: will I need this tool output again, or just the conclusion? While Claude Code will automatically call subagents, you may want to tell it to explicitly do this. For example, you may want to tell it to:
- “Spin up a subagent to verify the result of this work based on the following spec file”
- “Spin off a subagent to read through this other codebase and summarize how it implemented the auth flow, then implement it yourself in the same way”
- “Spin off a subagent to write the docs on this feature based on my git changes”
要するに、Claudeがターンを終え、あなたが新しいメッセージを送ろうとしているとき、そこには意思決定ポイントがあります。
時間の経過とともに、Claude自身がこれを処理するのを支援するようになっていくと予想していますが、現時点では、これがClaudeのアウトプットをガイドする方法の1つです。
In summary, when Claude has ended a turn and you’re about to send a new message, you have a decision point.
Overtime we expect that Claude will help you handle this itself, but for now this is one of the ways you can guide Claude's output.
