コンテキストウィンドウ

会話が長くなると、最終的にはコンテキストウィンドウの制限に近づきます。長時間実行される会話やエージェント型ワークフローでは、サーバーサイドコンパクションがコンテキスト管理の主要な戦略です。



コンテキストウィンドウの仕組み

「context window」（コンテキストウィンドウ）とは、言語モデルが応答を生成する際に参照できるすべてのテキストを指し、応答自体も含まれます。これは言語モデルが訓練された大規模なデータコーパスとは異なり、モデルの「作業メモリ」を表します。より大きなコンテキストウィンドウにより、モデルはより複雑で長いプロンプトを処理できるようになりますが、コンテキストが多ければ自動的に良くなるわけではありません。トークン数が増えるにつれて、精度と再現率が低下します。これは*コンテキストロット（context rot）*として知られる現象です。このため、コンテキストに何を含めるかを厳選することは、利用可能なスペースの量と同じくらい重要です。

次の図は、APIリクエストにおける標準的なコンテキストウィンドウの動作を示しています¹：

¹ claude.aiなどのチャットインターフェースでは、ローリング方式の「先入れ先出し」ベースでコンテキストウィンドウを管理することもできます。

• 段階的なトークンの蓄積： 会話がターンを重ねるにつれて、各ユーザーメッセージとアシスタントの応答がコンテキストウィンドウ内に蓄積され、以前のターンは完全に保持されます。
• コンテキストウィンドウの容量： コンテキストウィンドウ（モデルに応じて最大100万トークン）には、会話履歴とClaudeが生成する新しい出力が保持されます。
• 入出力フロー： 各ターンは以下で構成されます：
  • 入力フェーズ： これまでのすべての会話履歴と現在のユーザーメッセージを含みます
  • 出力フェーズ： 次のターンの入力の一部となるテキスト応答を生成します

リクエスト内のすべてがコンテキストウィンドウにカウントされます：システムプロンプト、messages内のすべてのメッセージ（ツール結果、画像、ドキュメントを含む）、そしてツール定義です。Claudeがそのターンで生成する出力も、拡張思考を含めてカウントされます。すべての応答は、リクエストが消費した量をusageフィールドで報告します。プロンプトキャッシングを使用する場合、入力カウントはinput_tokens、cache_read_input_tokens、cache_creation_input_tokensに分割され、3つすべてがウィンドウにカウントされます。送信前にリクエストを見積もるには、トークンカウントAPIを使用してください。



モデル別のコンテキストウィンドウサイズ

Claude Opus 5、Claude Opus 4.8、Claude Opus 4.7、Claude Opus 4.6、Claude Sonnet 5、Claude Sonnet 4.6は、Claude API、Amazon Bedrock、Google Cloud、Microsoft Foundryで100万トークンのコンテキストウィンドウを持っています。Claude Mythos Previewも100万トークンのコンテキストウィンドウを持っています。

Claude Fable 5とClaude Mythos 5（claude-fable-5とclaude-mythos-5）も100万トークンのコンテキストウィンドウを持っています。100万トークンのコンテキストウィンドウを持つ任意のモデルへの単一のリクエストは、最大128kの出力トークン（max_tokens）を生成できます。Claude Sonnet 4.5を含むその他のClaudeモデルは、20万トークンのコンテキストウィンドウを持っています。

100万トークンのコンテキストウィンドウを持つすべてのモデルでは、100万がデフォルトです。ベータヘッダーは不要で、長いコンテキストのリクエストは標準価格で課金されます。

単一のリクエストには、最大600枚の画像またはPDFページ（20万トークンのコンテキストウィンドウを持つモデルでは100枚）を含めることができます。多数の画像や大きなドキュメントを送信する場合、トークン制限の前にリクエストサイズ制限に達する可能性があります。

モデル別のコンテキストウィンドウサイズの一覧については、モデル比較表を参照してください。



思考を伴うコンテキストウィンドウ

思考を使用する場合、思考トークンを含むすべての入力および出力トークンがコンテキストウィンドウの制限にカウントされますが、マルチターンの状況ではいくつかの微妙な違いがあります。

思考トークンはmax_tokensパラメータのサブセットであり、出力トークンとして課金され、レート制限にカウントされます。適応的思考では、Claudeが思考の割り当てを動的に決定するため、思考トークンの使用量はリクエストごとに異なります。

以前のアシスタントターンの思考ブロックがコンテキストウィンドウに残るかどうかは、モデルによって異なります。Claude Opus 4.5以降のOpusモデル、Claude Sonnet 4.6以降のSonnetモデル、Claude Fable 5、Claude Mythos 5、Claude Mythos Previewでは、APIはデフォルトで以前の思考ブロックを保持し、それらは他の入力トークンと同様にコンテキストウィンドウにカウントされます。それ以前のOpusおよびSonnetモデルとすべてのHaikuモデルでは、APIは以前の思考ブロックを渡し返した際に会話履歴から自動的に削除し、会話コンテンツのためのトークン容量を保持します。モデルごとのデフォルトについては、モデル別の思考ブロック保持を参照してください。どちらの方向にもデフォルトを上書きするには、思考ブロッククリアを使用してください。

次の図は、以前の思考ブロックを削除するモデルで思考が有効になっている場合のトークン管理の仕組みを示しています：

• 思考ブロックの削除： 以前の思考ブロックを削除するモデルでは、思考ブロック（濃いグレーで表示）は各ターンの出力フェーズで生成されますが、後続のターンの入力トークンとしては引き継がれません。思考ブロックを自分で削除する必要はありません。渡し返した場合、Claude APIが自動的に削除します。
• 課金： 思考トークンは、生成された時点で一度だけ出力トークンとして課金されます。以前の思考ブロックを保持するモデルでは、保持されたブロックは後のリクエストの入力の一部となり、会話履歴の残りの部分と同様に入力トークンとして課金されます。



思考とツール使用を伴うコンテキストウィンドウ

次の図は、以前の思考ブロックを削除するモデルで思考とツール使用を組み合わせた場合のトークン管理の仕組みを示しています：

• 思考を伴うツール使用に関する考慮事項：
  • ツール結果を送信する際は、そのツールリクエストに付随する変更されていない思考ブロック全体を、署名を含めて含める必要があります。
  • APIは暗号署名を使用して思考ブロックの真正性を検証します。思考ブロックを変更すると、APIはエラーを返します。

ツール定義自体が消費するコンテキストを削減するには、ツールコンテキストの管理を参照するか、ツール検索ツールでツール定義を遅延させてください。



コンテキスト認識

Claude Sonnet 5、Claude Sonnet 4.6、Claude Sonnet 4.5、Claude Haiku 4.5にはコンテキスト認識があります。これらのモデルは、会話全体を通じて残りのコンテキストウィンドウ（「トークンバジェット」）を追跡します。これにより、モデルは残りのトークン数を推測するのではなく、残っているスペースに対して長時間実行されるタスクを管理できます。コンテキスト認識は自動的に機能します。有効にする必要はなく、このセクションに示されているタグを自分で送信することもありません。APIがそれらを注入します。



仕組み

すべてのリクエストのシステムプロンプトで、APIはClaudeに合計コンテキストウィンドウを伝えます：

<budget:token_budget>200000</budget:token_budget>

バジェットはリクエストで利用可能なコンテキストウィンドウと一致します。Claude Sonnet 5とClaude Sonnet 4.6では100万トークン、Claude Sonnet 4.5とClaude Haiku 4.5では20万トークンです。このセクションの例は、20万トークンのコンテキストウィンドウを持つモデルを示しています。

各ツール呼び出しの後、APIはClaudeに残りの容量の更新を伝えます：

<system_warning>Token usage: 35000/200000; 165000 remaining</system_warning>

画像トークンはこれらのバジェットに含まれます。

Claude Opus 4.7以降のOpusモデル、Claude Fable 5、Claude Mythos 5は、これらの注入されたタグを受け取りません。Claude Opus 4.7以降のOpusモデル、Claude Fable 5、Claude Mythos 5では、ベータ版のタスクバジェットを使用して、モデルに明示的なバジェットを与えることができます。

コンテキスト認識を使用するためのプロンプトのガイダンスについては、プロンプトのベストプラクティスを参照してください。



コンパクションによるコンテキスト管理

会話が定期的にコンテキストウィンドウの制限に近づく場合は、サーバーサイドコンパクションを使用してください。コンパクションは、サーバー上で会話の以前の部分を自動的に要約するため、会話はコンテキストウィンドウの制限を超えて継続できます。Claude 4.6以降のモデルとClaude Mythos Previewでベータ版として利用可能です。

より特殊なニーズには、コンテキスト編集が追加の戦略を提供します：

• ツール結果のクリア： エージェント型ワークフローで古いツール結果をクリアします
• 思考ブロックのクリア： 拡張思考を使用する際に思考ブロックを管理します

キャッシュされたプロンプトプレフィックスは引き続きコンテキストウィンドウを占有します。プロンプトキャッシングは、それらのトークンに対して支払う金額を変更するものであり、カウントされるかどうかを変更するものではありません。



コンテキストウィンドウのオーバーフロー動作

入力だけでモデルのコンテキストウィンドウをすでに超えている場合、APIはすべてのモデルで400 invalid_request_error（「prompt is too long」）を返します。

Claude 4.5モデル以降では、入力トークンとmax_tokensの合計がコンテキストウィンドウサイズを超える場合、APIはリクエストを受け入れます。その後、生成がコンテキストウィンドウの制限に達すると、stop_reason: "model_context_window_exceeded"で停止します。それ以前のモデルでは、APIは代わりに検証エラーを返します。それらのモデルでmodel_context_window_exceededの動作をオプトインするには、model-context-window-exceeded-2025-08-26ベータヘッダーを使用してください。詳細については、停止理由とフォールバックを参照してください。

コンテキストウィンドウの制限内に収めるには、Claudeにメッセージを送信する前にトークンカウントAPIを使用してトークン使用量を見積もってください。



次のステップ