一行要約
context window は「working memory」であり、大きければ良いわけではない — トークン数が増えると精度と再現率が劣化する context rot が起きるため、「どれだけ入るか」より「何を入れるか」の設計が重要。
要点
context rot
A larger context window allows the model to handle more complex and lengthy prompts, but more context isn’t automatically better. As token count grows, accuracy and recall degrade, a phenomenon known as context rot. This makes curating what’s in context just as important as how much space is available. context window が大きいほど、モデルは複雑で長いプロンプトを扱えるようになる。だがcontext は多いほど自動的に良くなるわけではない。トークン数が増えるにつれて正確性と再現率は劣化する。これは context rot として知られる現象である。そのため、context に何を入れるかを選ぶことは、どれだけの余地があるかと同じくらい重要になる。
何がカウントされるか
リクエストに含まれるものすべてが context window に算入される。
- system prompt
messagesの全メッセージ(tool result、画像、文書を含む)- ツール定義
- Claude が生成する出力(extended thinking を含む)
prompt caching を使うと、入力の内訳は input_tokens / cache_read_input_tokens / cache_creation_input_tokens に分かれるが、3つとも window に算入される。
Cached prompt prefixes still occupy the context window: prompt caching changes what you pay for those tokens, not whether they count. キャッシュされたプロンプトの prefix も context window を占める。prompt caching が変えるのは、そのトークンにいくら払うかであって、それが数に入るかどうかではない。
モデル別の context window サイズ
| モデル | context window |
|---|---|
| Opus 5 / Opus 4.8 / Opus 4.7 / Opus 4.6 / Sonnet 5 / Sonnet 4.6 / Mythos Preview / Fable 5 / Mythos 5 | 1M トークン |
| その他(Sonnet 4.5 を含む) | 200k トークン |
- 1M のモデルでは 1M が既定。beta header は不要で、long-context のリクエストも標準価格で課金される
- 1M window のモデルは1リクエストで最大 128k の出力トークン(
max_tokens)を生成できる - 1リクエストあたり画像 / PDF ページは最大 600(200k window のモデルでは 100)。多数の画像や大きな文書ではトークン上限より先にリクエストサイズ上限に当たることがある
thinking との関係
thinking トークンは max_tokens の内数であり、出力トークンとして課金され、レート制限にも算入される。adaptive thinking では Claude が動的に配分を決めるため、リクエストごとに使用量が変わる。
過去の thinking ブロックが context に残るかはモデルによって違う(ここが最も間違えやすい)。
| モデル | 過去の thinking ブロック |
|---|---|
| Opus 4.5 以降、Sonnet 4.6 以降、Fable 5、Mythos 5、Mythos Preview | 既定で保持される。他の入力トークンと同様に算入される |
| それ以前の Opus / Sonnet、全 Haiku | API が自動的に剥がす。会話内容のためのトークン容量が温存される |
You do not need to strip the thinking blocks yourself: if you pass them back, the Claude API strips them automatically. thinking ブロックを自分で取り除く必要はない。そのまま返せば、Claude API が自動的に取り除く。
課金: thinking トークンは生成時に出力トークンとして1回課金される。保持するモデルでは、その後のリクエストで入力トークンとしても課金される。
thinking + tool use(唯一 thinking ブロックを返す義務がある場面)
You must return the thinking block with the corresponding tool results. This is the only case where you have to return thinking blocks. thinking ブロックは、対応する tool result とともに返さなければならない。thinking ブロックを返す必要があるのは、この場合だけである。
- tool result を送るとき、そのツール要求に付随する thinking ブロックを、署名を含めて一切変更せずに含めなければならない
- API は暗号署名で thinking ブロックの真正性を検証する。改変するとエラーになる
- tool result を返した後、Claude は次の
userメッセージまでテキストのみで応答する(interleaved thinking が有効な場合を除く)
context awareness
Sonnet 5 / Sonnet 4.6 / Sonnet 4.5 / Haiku 4.5 は残り context window(token budget)を追跡できる。
Context awareness is automatic: there is nothing for you to enable, and you never send the tags shown in this section yourself. The API injects them. context の把握は自動である。有効にする作業は何もなく、この節で示したタグを自分で送ることも決してない。API が注入する。
- system prompt に総容量が注入される:
<budget:token_budget>200000</budget:token_budget> - ツール呼び出しのたびに残量が注入される:
<system_warning>Token usage: 35000/200000; 165000 remaining</system_warning> - 画像のトークンもこの budget に含まれる
Opus 4.7 以降の Opus、Fable 5、Mythos 5 にはこのタグが注入されない。 これらでは task budgets(beta)で明示的に予算を与える。
context のあふれ方
| 状況 | 挙動 |
|---|---|
| 入力だけでモデルの context window を超えている | 全モデルで 400 invalid_request_error(“prompt is too long”) |
入力 + max_tokens が window を超える(Claude 4.5 以降) | リクエストは受理される。生成が上限に達したら stop_reason: "model_context_window_exceeded" で停止 |
| 同上(それ以前のモデル) | validation error。model-context-window-exceeded-2025-08-26 beta header で新挙動に opt-in できる |
送信前の見積もりには token counting API を使う。
context の管理手段
第一選択はサーバサイドの compaction。
For long-running conversations and agentic workflows, server-side compaction is the primary strategy for context management. 長時間続く会話やエージェント的なワークフローでは、サーバ側の compaction が context 管理の主たる戦略になる。
より特殊な要求には context editing:
- tool result clearing — agentic ワークフローで古い tool result を消す
- thinking block clearing — extended thinking 使用時に thinking ブロックを管理する(上記のモデル別既定を両方向に上書きできる)
複数セッションにまたがるエージェントでは、新セッション開始時に context の復元が速くなるように state artifact を設計する。
そのまま使える具体例
context awareness で API が注入するタグ(自分では送らない):
<budget:token_budget>200000</budget:token_budget><system_warning>Token usage: 35000/200000; 165000 remaining</system_warning>context あふれ時の分岐(Claude 4.5 以降):
入力のみで超過 → 400 invalid_request_error ("prompt is too long")
入力 + max_tokens 超過 → 受理され、生成中に stop_reason: "model_context_window_exceeded"原典で言及されている関連文書
- effective-context-engineering-for-ai-agents — context rot の理由と回避の設計(原典が明示的に参照)
- compaction — サーバサイド compaction の API
- manage-tool-context — ツール定義由来の context を減らす
- effective-harnesses-for-long-running-agents — 複数セッションにまたがる state 設計
- claude-prompting-best-practices — context awareness を活かす prompting
未取得の派生リンク
- https://platform.claude.com/docs/en/build-with-claude/thinking — thinking ブロックのモデル別既定
- https://platform.claude.com/docs/en/build-with-claude/context-editing — tool result / thinking block clearing
- https://platform.claude.com/docs/en/build-with-claude/token-counting — token counting API
- https://platform.claude.com/docs/en/build-with-claude/task-budgets — task budgets(beta)
- https://platform.claude.com/docs/en/build-with-claude/handling-stop-reasons
- https://platform.claude.com/docs/en/agents-and-tools/tool-use/memory-tool#multisession-software-development-pattern