Seedance 2.5 is live — 30-second cinematic video with native audio & real-person references
Claudeのコンテキストウィンドウ:何がカウントされるか
2026/07/27

Claudeのコンテキストウィンドウ:何がカウントされるか

Claudeのコンテキストウィンドウは現在のモデルで1M。ツール定義、保持シンキング、キャッシュがすべて消費します。より多いことが必ずしも良いわけではありません。

コンテキストウィンドウとは、応答を生成する際にClaudeが参照できるすべての内容のことで、応答自体も含まれます。Anthropicはこれを作業用メモリと呼び、トレーニングコーパスとは区別しています[1]

重要なポイントは、その定義の直後にAnthropicが記載している文です:より多いコンテキストが自動的に良いわけではありません。トークン数が増えると、精度と再現率は低下します。これは、ドキュメントでコンテキスト劣化と呼ばれる現象です[1]。何を含めるかは、どのくらいのスペースがあるかと同じくらい重要です。

TL;DR

  • 現在のモデルでは1Mトークン:Opus 5、Opus 4.8/4.7/4.6、Sonnet 5、Sonnet 4.6、Fable 5、Mythos 5。Sonnet 4.5を含む他のモデルは200k[1]
  • 1Mがデフォルトです。ベータヘッダーは不要で、長いコンテキストのリクエストは標準の価格で請求されます[1]
  • 出力もカウントされます。拡張シンキングを含み、max_tokensは1Mウィンドウモデルで128kに制限されます[1]
  • リクエスト内のすべてがカウントされます:システムプロンプト、すべてのメッセージ、ツール結果、画像、ドキュメント、ツール定義[1]
  • 新しいモデルはデフォルトで前回のシンキングブロックを保持します。したがって、後のターンで入力として計上されます[1]
  • Sonnetモデルにはライブトークン予算が注入されます。OpusとFableにはそうではありません[1]

実際にカウントされるもの

Claudeのコンテキストウィンドウが占有するもの:システムプロンプト、ツール定義、ツール結果と画像を含むメッセージ、入力として再度計上される保持されたシンキングブロック、そしてこのターンの出力は128kに制限されます

一般的な間違いは、会話だけをバジェットすることです。完全なリスト[1]

  • システムプロンプト
  • messages内のすべてのメッセージ。ツール結果、画像、ドキュメントを含む
  • ツール定義
  • 出力 Claude がこのターンで生成するもの。拡張シンキングを含む

すべてのレスポンスは、usageフィールドでリクエストが消費した内容をレポートします。プロンプトキャッシングの場合、入力カウントはinput_tokenscache_read_input_tokenscache_creation_input_tokensに分割され、3つすべてがウィンドウにカウントされます[1]。キャッシュされているということは、ウィンドウから自由という意味ではありません。トークンあたりより安いという意味です。

リクエストを送信する前にサイズを決定するには、文字数から推定するのではなく、トークンカウントAPIを使用してください。

サイズと1Mの実際のコスト

モデルコンテキストウィンドウ
Opus 5、Opus 4.8、Opus 4.7、Opus 4.61M
Sonnet 5、Sonnet 4.61M
Fable 5、Mythos 51M
Sonnet 4.5と他の以前のモデル200k

お金と混乱を節約する2つの詳細[1]

これらのモデルでは1Mがデフォルトです。送信するベータヘッダーはなく、900kトークンのリクエストは9kのリクエストと同じトークンあたりレートで請求されます。ロングコンテキスト追加料金はありません。

最大出力は128k。1Mウィンドウモデルのどれでも。入力スペースがどのくらい残っているかに関わらず。

単一のリクエストは最大600の画像またはPDFページを含むことができます(200kウィンドウモデルでは100)。大きなペイロードはトークン制限に達する前にリクエストサイズ制限に達する可能性があります[1]

シンキングが計算を変える

シンキングトークンはmax_tokensのサブセットで、出力として計上され、レート制限にカウントされます。適応的シンキングにより、割り当ては要求ごとに異なるため、使用法はプロンプト長だけからは予測できません[1]

人々を驚かせる動作は、前回のシンキングブロックに何が起こるかです。

Opus 4.5以降、Sonnet 4.6以降、Fable 5、Mythos 5では、APIはデフォルトで前回のシンキングブロックを保持します。そして、それらは他の入力トークンと同じようにウィンドウにカウントされます。生成された時点で出力として1回計上されました。その後、保持されたブロックは、それらを含むその後のリクエストで入力として計上されます[1]

以前のOpusおよびSonnetモデルと、すべてのHaikuモデルでは、APIは自動的にそれらを削除します。

長いエージェント対話がコンテキストを、見える文字起こしが説明するより速く消費している場合、保持されたシンキングが通常理由です。シンキングブロッククリアリングは両方向でデフォルトをオーバーライドします。

コンテキスト認識:あるモデルは知っていて、他のモデルは知らない

これはほとんどの人が認識していない分割です[1]

Sonnet 5、Sonnet 4.6、Sonnet 4.5、Haiku 4.5は残りの予算を追跡します。APIはすべてのリクエストのシステムプロンプトにトータルを注入します:

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

そして各ツール呼び出し後に更新します:

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

これは自動です。これらのタグを自分で送信することはなく、画像トークンはカウントに含まれます。

Opus 4.7以降、Fable 5、Mythos 5はこれらのタグを受け取りません。それらについては、タスク予算を使用して明示的な予算をモデルに与えてください。現在ベータです。

実際の結果:Sonnetモデルは、長いタスク全体で残りのスペースに対してペースを設定できます。一方、Opusモデルはあなたが言わない限りペースを設定できません。これは、能力スコアとは何の関係もないティア間の本当の行動の違いです。

会話がウィンドウを超えて成長するとき

2つのサーバー側メカニズム。独自の切り詰めを構築する前に両方を知る価値があります[1]

圧縮は、会話が制限を超えて続行できるように、サーバーで会話の以前の部分を自動的に要約します。ベータ、Claude 4.6以降。

コンテキスト編集は、より的を絞った戦略を提供します。エージェント ワークフローで古いツール結果をクリアしることを含みます。これは通常、長い会話のトークンの大部分が実際に存在する場所です。

自分で構築した「最も古いメッセージをドロップ」ループに手を伸ばすより、どちらかを使用する方が優れています。そのループは、会話を首尾一貫させた、システムレベルのコンテキストを破棄する傾向があります。

それで機能させる

埋める代わりにキュレートしましょう。コンテキスト劣化はドキュメント化された動作です。デマではありません。900kトークンのプロンプトは、よく選ばれた90kのプロンプトより自動的に優れているわけではありません。

ツール定義をカウントしてください。すべてのリクエストにそれらが含まれており、大きなツールスキーマはすべてのターンで固定税です。

新しいモデルで保持されたシンキングを監視してください 長いエージェント実行中。

必要な動作を持つティアを選択してください。モデルが長いタスク全体で自分のペースを設定する必要がある場合、Sonnetの注入された予算がこれをネイティブに行います。

from openai import OpenAI

client = OpenAI(api_key="YOUR_REAPI_KEY", base_url="https://api.reapi.ai/v1")

resp = client.chat.completions.create(
    model="claude-opus-5",
    messages=[{"role": "user", "content": "Read this repository and summarize the architecture."}],
    max_tokens=16000,
)
print(resp.usage)   # the number to reconcile against

1Mウィンドウモデルのレートはreapi.ai/modelsにあります。

FAQ

Claudeのコンテキストウィンドウとは何ですか?

応答を生成する際にモデルが参照できるすべてのテキスト。応答自体を含みます。トレーニングデータではなく、作業用メモリです[1]

Claudeのコンテキストウィンドウはどのくらいの大きさですか?

Opus 5、Opus 4.8/4.7/4.6、Sonnet 5、Sonnet 4.6、Fable 5、Mythos 5では1Mトークン。Sonnet 4.5を含む以前のモデルは200k[1]

完全な1Mウィンドウを使用するのに追加料金がかかりますか?

いいえ。1Mウィンドウを持つモデルでは、1Mがデフォルトで、リクエストはロングコンテキスト追加料金なしで標準の価格で請求されます[1]

コンテキストウィンドウにカウントされるものは何ですか?

システムプロンプト、ツール結果、画像、ドキュメントを含むすべてのメッセージ、ツール定義、拡張シンキングを含む出力。キャッシュされた入力もカウントされます[1]

私のコンテキストが会話より速く満杯になるのはなぜですか?

新しいモデルでは、APIはデフォルトで前回のシンキングブロックを保持し、それらは後のターンで入力としてカウントされます[1]

より多いコンテキストは常に良いですか?

いいえ。Anthropicは、トークン数が増えると精度と再現率が低下することを文書化しており、これはコンテキスト劣化と呼ばれる現象です[1]

1つのリクエストはいくつの画像を含むことができますか?

1Mウィンドウモデルで最大600の画像またはPDFページ、200kウィンドウモデルで100。リクエストサイズ制限の対象[1]

会話がウィンドウを超える場合はどうなりますか?

サーバー側圧縮を使用してください。これは以前のターンを要約するため、会話は続行されます。またはコンテキスト編集を使用して古いツール結果をクリアしてください[1]

ウィンドウを埋める代わりに予算を立てる

Claudeのコンテキストウィンドウについて誰もが引用する数字は1Mで、それはその点についての最も興味深い事実ではありません。ロングコンテキスト統合が機能するかどうかを決めるのは、会計です:すべてのターンで同行するツール定義、入力として計上される保持されたシンキングブロック、スペースを消費し続けるキャッシュされたトークン、そして出力が同じ予算と競合します。

Anthropic自身のフレーミングが採用する正しいものです。ウィンドウは作業用メモリで、それ以上は自動的に良くはなく、そこに何を入れるかが残りのスペースの量より重要です。

参考文献

  1. Anthropic. Context windows — sizes by model, what counts, thinking behavior, context awareness, compaction, and overflow. Retrieved July 2026 from docs.claude.com/en/docs/build-with-claude/context-windows

さらに詳しく