コンテキストウィンドウ

会話が長くなるにつれて、最終的にはコンテキストウィンドウの制限に近づきます。このガイドでは、コンテキストウィンドウの仕組みと、それを効果的に管理するための戦略を説明します。

長時間実行される会話やエージェント型ワークフローでは、サーバーサイドコンパクションがコンテキスト管理の主要な戦略です。より専門的なニーズには、コンテキスト編集がツール結果のクリアや思考ブロックのクリアなどの追加戦略を提供します。



コンテキストウィンドウを理解する

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

ClaudeはMRCRやGraphWalksなどの長文コンテキスト検索ベンチマークで最先端の結果を達成していますが、これらの成果はコンテキストにどれだけ収まるかだけでなく、コンテキストに何が含まれているかに依存します。

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

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

• 段階的なトークンの蓄積： 会話がターンを重ねるにつれて、各ユーザーメッセージとアシスタントの応答がコンテキストウィンドウ内に蓄積されます。以前のターンは完全に保持されます。
• 線形的な増加パターン： コンテキストの使用量は各ターンごとに線形的に増加し、以前のターンは完全に保持されます。
• コンテキストウィンドウの容量： 利用可能なコンテキストウィンドウの合計（最大100万トークン）は、会話履歴を保存しClaudeから新しい出力を生成するための最大容量を表します。
• 入出力フロー： 各ターンは以下で構成されます：
  • 入力フェーズ： 以前のすべての会話履歴と現在のユーザーメッセージを含みます
  • 出力フェーズ： 将来の入力の一部となるテキスト応答を生成します



拡張思考を使用したコンテキストウィンドウ

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

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

ただし、以前の思考ブロックはClaude APIによってコンテキストウィンドウの計算から自動的に除外され、後続のターンでモデルが「見る」会話履歴の一部にはならないため、実際の会話コンテンツのためのトークン容量が保持されます。

以下の図は、拡張思考が有効な場合の特殊なトークン管理を示しています：

• 拡張思考の除外： 拡張思考ブロック（濃い灰色で表示）は各ターンの出力フェーズで生成されますが、後続のターンの入力トークンとして引き継がれることはありません。思考ブロックを自分で除外する必要はありません。それらを返送した場合、Claude APIが自動的にこれを行います。
• 技術的な実装の詳細：
  • 会話履歴の一部として以前のターンの思考ブロックを返送した場合、APIはそれらを自動的に除外します。
  • 拡張思考トークンは、生成時に一度だけ出力トークンとして課金されます。
  • 実効コンテキストウィンドウの計算は次のようになります：context_window = (input_tokens - previous_thinking_tokens) + current_turn_tokens。
  • 思考トークンにはthinkingブロックが含まれます。

このアーキテクチャはトークン効率が高く、思考ブロックがかなりの長さになる可能性があるため、トークンを無駄にすることなく広範な推論が可能になります。



拡張思考とツール使用を組み合わせたコンテキストウィンドウ

以下の図は、拡張思考とツール使用を組み合わせた場合のコンテキストウィンドウのトークン管理を示しています：

• 拡張思考を使用したツール使用に関する考慮事項：
  • ツール結果を送信する際は、その特定のツールリクエストに付随する変更されていない思考ブロック全体（署名部分を含む）を含める必要があります。
  • ツール使用を伴う拡張思考の実効コンテキストウィンドウの計算は次のようになります：context_window = input_tokens + current_turn_tokens。
  • システムは暗号署名を使用して思考ブロックの真正性を検証します。ツール使用中に思考ブロックを保持しないと、Claudeの推論の連続性が損なわれる可能性があります。したがって、思考ブロックを変更すると、APIはエラーを返します。

Claudeのツール選択は、大きな入力ドキュメントでも機能するように設計されています。つまり、会話に10万トークン以上のツール以外のコンテキストが含まれている場合でも、適切なツールを選択する（または正しく使用を控える）ことができます。ツール自体が消費するコンテキストを削減するには、ツールコンテキストの管理を参照するか、ツール検索ツールでツール定義を遅延させてください。

Claude Opus 4.8、Claude Mythos Preview、Claude Opus 4.7、Claude Opus 4.6、およびClaude Sonnet 4.6は、Claude API、Amazon Bedrock、Vertex AIで100万トークンのコンテキストウィンドウを持っています。Microsoft Foundryでは、Claude Opus 4.8は20万トークンのコンテキストウィンドウを持っています。Claude Sonnet 4.5およびSonnet 4（非推奨）を含む他のClaudeモデルは、20万トークンのコンテキストウィンドウを持っています。

Claude Fable 5およびClaude Mythos 5（claude-fable-5およびclaude-mythos-5）は、Claude APIで100万トークンのコンテキストウィンドウを持っています。100万の最大値はデフォルトでもあり、1回のリクエストで最大12万8千の出力トークン（max_tokens）を生成できます。

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



Claude Sonnet 4.6、Sonnet 4.5、Haiku 4.5におけるコンテキスト認識

Claude Sonnet 4.6、Claude Sonnet 4.5、およびClaude Haiku 4.5はコンテキスト認識機能を備えています。この機能により、これらのモデルは会話全体を通じて残りのコンテキストウィンドウ（つまり「トークンバジェット」）を追跡できます。これにより、Claudeは作業に使えるスペースがどれだけあるかを理解することで、タスクの実行とコンテキストの管理をより効果的に行えます。Claudeはこのコンテキストを正確に使用するように訓練されており、残りのトークン数を推測するのではなく、最後までタスクを継続します。モデルにとって、コンテキスト認識がないことは、時計なしで料理コンテストに参加するようなものです。コンテキスト認識モデルは、残りのコンテキストに関する情報を明示的に受け取ることでこれを変え、利用可能なトークンを最大限に活用できるようになります。

仕組み：

会話の開始時に、Claudeは総コンテキストウィンドウに関する情報を受け取ります：

<budget:token_budget>1000000</budget:token_budget>

バジェットは100万トークンに設定されます（より小さいコンテキストウィンドウを持つモデルでは20万トークン）。

各ツール呼び出しの後、Claudeは残りの容量に関する更新を受け取ります：

<system_warning>Token usage: 35000/1000000; 965000 remaining</system_warning>

この認識により、Claudeは作業に残っている容量を判断でき、長時間実行されるタスクでより効果的な実行が可能になります。画像トークンもこれらのバジェットに含まれます。

利点：

コンテキスト認識は、特に以下の場合に価値があります：

• 持続的な集中を必要とする長時間実行のエージェントセッション
• 状態遷移が重要なマルチコンテキストウィンドウのワークフロー
• 慎重なトークン管理を必要とする複雑なタスク

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



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

会話が定期的にコンテキストウィンドウの制限に近づく場合、サーバーサイドコンパクションが推奨されるアプローチです。コンパクションは、会話の前半部分を自動的に要約するサーバーサイドの要約機能を提供し、最小限の統合作業でコンテキスト制限を超えた長時間実行の会話を可能にします。これはClaude Fable 5、Claude Mythos 5、Claude Opus 4.8、Claude Mythos Preview、Claude Opus 4.7、Claude Opus 4.6、およびClaude Sonnet 4.6でベータ版として利用可能です。

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

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



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

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

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

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



次のステップ