コンテキストウィンドウ

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

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

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

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

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

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

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

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

Claude Fable 5.1、Claude Mythos 5.1、Claude Fable 5、Claude Mythos 5、Claude Opus 5.5、Claude Opus 5、Claude Opus 4.8、Claude Opus 4.7、Claude Opus 4.6、Claude Sonnet 5、Claude Sonnet 4.6、およびClaude Mythos Previewは、1Mトークンのコンテキストウィンドウを備えています。これらのいずれに対しても、1回のリクエストで最大128kの出力トークン（max_tokens）を生成できます。Claude Sonnet 4.5を含むその他のClaudeモデルは、200kトークンのコンテキストウィンドウを備えています。

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

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

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

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

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

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

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

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

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

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

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

1. 1

   最初のターンの構成

   • 入力コンポーネント： ツール設定とユーザーメッセージ
   • 出力コンポーネント： 思考 + テキスト応答 + ツール使用リクエスト
   • トークン計算： すべての入力および出力コンポーネントがコンテキストウィンドウにカウントされ、すべての出力コンポーネントは出力トークンとして課金されます。
2. 2

   ツール結果の処理（ターン2）

   • 入力コンポーネント： 最初のターンのすべてのブロックとtool_result。対応するツール結果とともに思考ブロックを返す必要があります。これは思考ブロックを返さなければならない唯一のケースです。
   • 出力コンポーネント： ツール結果がClaudeに渡し返された後、Claudeはテキストのみで応答します（インターリーブ思考が有効でない限り、次のuserメッセージまで追加の思考は行われません）。
   • トークン計算： すべての入力および出力コンポーネントがコンテキストウィンドウにカウントされ、すべての出力コンポーネントは出力トークンとして課金されます。
3. 3

   新しいユーザーターン（ターン3）

   • 入力コンポーネント： すべての入力と前のターンの出力が引き継がれます。完了したツール使用サイクルの思考ブロックは、もはやコンテキストに残る必要はありません。以前の思考ブロックを削除するモデルでは、渡し返すとAPIが自動的に破棄し、以前の思考ブロックを保持するモデルでは、思考ブロックのクリアでクリアしない限り残ります。ここは次のuserターンを追加する場所でもあります。
   • 出力コンポーネント： ツール使用サイクルの外に新しいuserターンがあるため、Claudeは新しい思考ブロックを生成し、そこから続行します。
   • トークン計算： 以前の思考ブロックを削除するモデルでは、以前の思考トークンはもはやコンテキストウィンドウにカウントされません。その他の以前のブロックはすべて引き続きコンテキストウィンドウにカウントされ、現在のassistantターンの思考ブロックも同様です。

• 思考を伴うツール使用に関する考慮事項：
  • ツール結果を送信する際は、そのツールリクエストに付随する思考ブロック全体を、署名を含めて変更せずに含める必要があります。
  • 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では1Mトークン、Claude Sonnet 4.5とClaude Haiku 4.5では200kトークンです。このセクションの例は、200kトークンのコンテキストウィンドウを持つモデルを示しています。

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

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

画像トークンはこれらの予算に含まれます。

Claude Opus 4.7以降のOpusモデル、Claude Fable 5.1、Claude Mythos 5.1、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ベータヘッダーを使用してください。詳細については、停止理由とフォールバックを参照してください。

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

次のステップ