コンテキストウィンドウ

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

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

コンテキストウィンドウの理解

「コンテキストウィンドウ」とは、言語モデルがレスポンスを生成する際に参照できるすべてのテキストを指し、レスポンス自体も含まれます。これは言語モデルが訓練された大規模なデータコーパスとは異なり、モデルの「ワーキングメモリ」を表します。コンテキストウィンドウが大きいほど、モデルはより複雑で長いプロンプトを処理できます。コンテキストウィンドウが小さいと、長い会話にわたって一貫性を維持するモデルの能力が制限される可能性があります。

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

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

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

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

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

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

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

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

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

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

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

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

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

1Mトークンコンテキストウィンドウ

Claude Opus 4.6、Sonnet 4.5、およびSonnet 4は100万トークンのコンテキストウィンドウをサポートしています。この拡張コンテキストウィンドウにより、はるかに大きなドキュメントの処理、より長い会話の維持、より広範なコードベースでの作業が可能になります。

1Mトークンコンテキストウィンドウを使用するには、APIリクエストにcontext-1m-2025-08-07 ベータヘッダーを含めてください：

curl https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "anthropic-beta: context-1m-2025-08-07" \
  -H "content-type: application/json" \
  -d '{
    "model": "claude-opus-4-6",
    "max_tokens": 1024,
    "messages": [
      {"role": "user", "content": "Process this large document..."}
    ]
  }'

重要な考慮事項：

• ベータステータス： これは変更される可能性のあるベータ機能です。機能と価格は将来のリリースで変更または削除される場合があります。
• 使用量ティアの要件： 1Mトークンコンテキストウィンドウは、使用量ティア 4の組織およびカスタムレート制限を持つ組織で利用可能です。下位ティアの組織は、この機能にアクセスするために使用量ティア4に進む必要があります。
• 利用可能性： 1MトークンコンテキストウィンドウはClaude API、Microsoft Foundry、Amazon Bedrock、およびGoogle CloudのVertex AIで現在利用可能です。
• 価格： 200Kトークンを超えるリクエストは自動的にプレミアム料金（入力2倍、出力1.5倍の価格）で課金されます。詳細については価格ドキュメントをご覧ください。
• レート制限： ロングコンテキストリクエストには専用のレート制限があります。詳細についてはレート制限ドキュメントをご覧ください。
• マルチモーダルの考慮事項： 大量の画像やPDFを処理する場合、ファイルのトークン使用量が異なる場合があることに注意してください。大きなプロンプトと大量の画像を組み合わせる場合、リクエストサイズの制限に達する可能性があります。

Claude Sonnet 4.5とHaiku 4.5のコンテキスト認識

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

仕組み：

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

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

バジェットは200Kトークン（標準）、500Kトークン（claude.ai Enterprise）、または1Mトークン（ベータ、対象組織向け）に設定されます。

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

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

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

メリット：

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

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

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

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

会話が定期的にコンテキストウィンドウの制限に近づく場合、サーバーサイドコンパクションが推奨されるアプローチです。コンパクションは、会話の初期部分を自動的に要約するサーバーサイドの要約機能を提供し、最小限の統合作業でコンテキスト制限を超える長時間の会話を可能にします。現在、Claude Opus 4.6向けのベータ版として利用可能です。

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

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

新しいClaudeモデルでのコンテキストウィンドウ管理

新しいClaudeモデル（Claude Sonnet 3.7以降）は、プロンプトと出力トークンがコンテキストウィンドウを超えた場合、サイレントに切り捨てるのではなく、バリデーションエラーを返します。この変更により、より予測可能な動作が提供されますが、より慎重なトークン管理が必要になります。

Claudeにメッセージを送信する前にトークン使用量を見積もるには、トークンカウントAPIを使用してください。これにより、計画を立て、コンテキストウィンドウの制限内に収めることができます。

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

次のステップ