Loading...
  • ビルド
  • 管理
  • モデルと料金
  • クライアントSDK
  • APIリファレンス
Search...
⌘K
Log in
コンテキストウィンドウ
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...

Solutions

  • AI agents
  • Code modernization
  • Coding
  • Customer support
  • Education
  • Financial services
  • Government
  • Life sciences

Partners

  • Amazon Bedrock
  • Google Cloud's Vertex AI

Learn

  • Blog
  • Courses
  • Use cases
  • Connectors
  • Customer stories
  • Engineering at Anthropic
  • Events
  • Powered by Claude
  • Service partners
  • Startups program

Company

  • Anthropic
  • Careers
  • Economic Futures
  • Research
  • News
  • Responsible Scaling Policy
  • Security and compliance
  • Transparency

Learn

  • Blog
  • Courses
  • Use cases
  • Connectors
  • Customer stories
  • Engineering at Anthropic
  • Events
  • Powered by Claude
  • Service partners
  • Startups program

Help and security

  • Availability
  • Status
  • Support
  • Discord

Terms and policies

  • Privacy policy
  • Responsible disclosure policy
  • Terms of service: Commercial
  • Terms of service: Consumer
  • Usage policy
ビルド/コンテキスト管理

コンテキストウィンドウ

コンテキストウィンドウの仕組みと、効果的に管理するための戦略について説明します。

This feature is eligible for Zero Data Retention (ZDR). When your organization has a ZDR arrangement, data sent through this feature is not stored after the API response is returned.

会話が進むにつれて、やがてコンテキストウィンドウの制限に近づきます。このガイドでは、コンテキストウィンドウの仕組みと、効果的に管理するための戦略を紹介します。

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

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

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

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

長いコンテキストが劣化する理由と、それを回避するエンジニアリング方法の詳細については、効果的なコンテキストエンジニアリングを参照してください。

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

コンテキストウィンドウ図

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

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

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

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

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

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

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

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

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

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

コンテキストウィンドウと拡張思考の詳細については、拡張思考ガイドを参照してください。

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

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

拡張思考とツール使用を使用したコンテキストウィンドウ図

  1. 1

    最初のターンアーキテクチャ

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

    ツール結果の処理(ターン2)

    • 入力コンポーネント: 最初のターンのすべてのブロックとtool_result。拡張思考ブロックは対応するツール結果と一緒に返される必要があります。これは思考ブロックを返す必要がある唯一のケースです。
    • 出力コンポーネント: ツール結果がClaudeに返された後、Claudeはテキストのみで応答します(次のuserメッセージまで追加の拡張思考はありません)。
    • トークン計算: すべての入出力コンポーネントがコンテキストウィンドウにカウントされ、すべての出力コンポーネントが出力トークンとして請求されます。
  3. 3

    3番目のステップ

    • 入力コンポーネント: すべての入力と前のターンからの出力は、Claudeがツール使用サイクル全体を完了したため削除できるようになった思考ブロックを除いて転送されます。APIが返された場合、思考ブロックを自動的に削除するか、この段階で自分で削除することができます。これは次のUserターンを追加する場所でもあります。
    • 出力コンポーネント: ツール使用サイクルの外に新しいUserターンがあるため、Claudeは新しい拡張思考ブロックを生成し、そこから続行します。
    • トークン計算: 前の思考トークンはコンテキストウィンドウ計算から自動的に削除されます。他のすべての前のブロックはトークンウィンドウの一部としてカウントされ、現在のAssistantターンの思考ブロックはコンテキストウィンドウの一部としてカウントされます。
  • 拡張思考を使用したツール使用に関する考慮事項:
    • ツール結果を投稿する場合、その特定のツール要求に付随する完全な未修正の思考ブロック(署名部分を含む)を含める必要があります。
    • 拡張思考を使用したツール使用の効果的なコンテキストウィンドウ計算は以下のようになります: context_window = input_tokens + current_turn_tokens。
    • システムは暗号署名を使用して思考ブロックの真正性を検証します。ツール使用中に思考ブロックを保持しないと、Claudeの推論の連続性が破損する可能性があります。したがって、思考ブロックを変更すると、APIはエラーを返します。

Claude 4モデルはインターリーブ思考をサポートしており、Claudeがツール呼び出し間で思考し、ツール結果を受け取った後、より洗練された推論を行うことができます。

Claude Sonnet 3.7はインターリーブ思考をサポートしていないため、非tool_resultユーザーターンの間に拡張思考とツール呼び出しのインターリーブはありません。

拡張思考を使用したツールの使用の詳細については、拡張思考ガイドを参照してください。

Claude Mythos Preview、Claude Opus 4.7、Claude Opus 4.6、およびClaude Sonnet 4.6は100万トークンのコンテキストウィンドウを持っています。Claude Sonnet 4.5およびSonnet 4(廃止予定)を含む他のClaudeモデルは、20万トークンのコンテキストウィンドウを持っています。

単一のリクエストには、最大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 4.5+モデルは、モデルに残りのコンテキストを明示的に通知することで、これを変更し、利用可能なトークンを最大限に活用できます。

仕組み:

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

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

予算は100万トークン(コンテキストウィンドウが小さいモデルの場合は20万)に設定されています。

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

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

この認識により、Claudeは作業に残っている容量を決定し、長時間実行されるタスクでより効果的に実行できます。画像トークンはこれらの予算に含まれています。

利点:

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

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

複数のセッションにまたがるエージェントの場合、新しいセッションが開始されるときにコンテキスト回復が高速になるように状態アーティファクトを設計してください。メモリツールのマルチセッションパターンは具体的なアプローチを説明しています。長時間実行されるエージェントの効果的なハーネスも参照してください。

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

コンパクションでコンテキストを管理する

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

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

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

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

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

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

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

次のステップ

コンパクション

長時間実行される会話でコンテキストを管理するための推奨戦略。

コンテキスト編集

ツール結果のクリアと思考ブロックのクリアなどの細粒度戦略。

モデル比較テーブル

モデルごとのコンテキストウィンドウサイズと入出力トークン価格のリストについては、モデル比較テーブルを参照してください。

拡張思考の概要

拡張思考の仕組みと、ツール使用やプロンプトキャッシングなどの他の機能と一緒に実装する方法の詳細を学びます。

Was this page helpful?

  • Claude Sonnet 4.6、Sonnet 4.5、およびHaiku 4.5のコンテキスト認識
  • 新しいClaudeモデルでのコンテキストウィンドウ管理