コンテキストウィンドウとは?9モデルで実測したトークン上限(2026)

コンテキストウィンドウとは、1回のリクエストでモデルが扱えるトークンの上限であり、入力と出力を合わせた数字です。

単位:          トークン。単語数でも文字数でもない(英語で約4文字が1トークン、ただし変動する)
範囲:          1リクエスト。メモリではなく、呼び出しをまたいで残らない
何が乗るか:    システムプロンプト、会話履歴全体、ツール定義、ツール結果、推論、返答
一般的なサイズ: 旧型や安価なモデルで200K、現行フラッグシップの多くで1M
2026年の最大:  1,131,072(Qwen 3.8 Max)。ちょうど1,000,000は1M帯の下限
超えた場合:    HTTP 400、出力なし。黙って切り詰められることはない
分からないこと: ウィンドウの遠い端をモデルがどれだけ正確に使えるか

コンテキストウィンドウとは何か?

1回のAPIリクエストに与えられたトークン予算です。 モデルが読むものと書くものが、すべてこの1つの数字に収まる必要があります。

APIはステートレスで、前回の呼び出しを覚えていません。毎ターン、アプリ側が会話全体を送り直し、コンテキストウィンドウは「その再送分+これから返ってくる応答」の上限として効きます。

だからこそ、ウィンドウは実質的な意味でのメモリではありません。セッションをまたいで名前を覚えているように見えるチャット製品は、そのテキストをどこかに保存し、リクエストごとにウィンドウへ貼り直しています。

何がコンテキストウィンドウを消費するのか?

リクエストの中身すべてと、レスポンスの中身すべてです。 見落とされがちなものほど、たいてい高くつきます。

• システムプロンプト。 セッションに1回ではなく、毎ターン計上されます。
• 会話履歴全体。 送り直しているユーザーとアシスタントの全ターン。
• ツール定義。 宣言したすべてのツールの名前、説明、JSONスキーマ。Claudeではさらにモデル別のtool-useシステムプロンプトが加算され、Opus 5で286トークン、Opus 4.7で675トークンです。
• ツール結果。 エージェントループでは単独で最大の項目になりがちで、ディレクトリ一覧やAPIレスポンスは数千トークンに達します。
• 推論トークン。 thinkingが有効なモデルでは、テキストが返らなくても推論分が計上され課金されます。
• 応答そのもの。 だからmax_tokensとコンテキストウィンドウは連動します。出力の余地を残さないリクエストは途中で切れます。

最後の点でつまずく人が多いところです。Claude Opus 5はthinkingがデフォルトで有効なので、旧モデルでは応答量ぴったりに設計できていたリクエストが、いまは書きかけで余地切れになることがあります。

各モデルのコンテキストウィンドウはどれくらい?

1Mトークンが主流帯の上限で、全体で最も多いサイズは256Kです。 2026-08-12時点のofoxカタログのテキストモデル119件のうち、25件が256K、22件が1Mでした。

フラッグシップ帯を、各ベンダーの公表値で並べます。

注目したい点が2つあります。公表ウィンドウが最大なのはQwen 3.8 Maxで、Kimi K3はこの中で唯一、最大出力がウィンドウ全体と同じです。理屈のうえでは1回の応答で100万トークンを書けます。DeepSeek V4 Flashは出力384,000で2番手、この帯の大半の3倍にあたり、長文を読むのではなく生成する用途では効いてきます。そして「1M」は実際には9通りの数字で、ちょうど1,000,000から1,131,072まで13%の開きが、何も測る前から存在します。

出典についても一言。ゲートウェイのカタログとベンダーのドキュメントは必ずしも一致しません。2026-08-12のofoxカタログはGrok 4.20を2,000,000と表示していましたが、xAI自身のモデルドキュメントは1,000,000としています。上の表はベンダー側の数字です。数字が重要な場面では、ベンダーのページで確認してください。

なぜ「1Mトークン」はモデルごとに同じ意味にならないのか?

トークンは固定量のテキストではなく、トークナイザー間の差は多くの人が思うより大きいからです。 同一の英文文書(2,638文字、420単語のサービス障害ポストモーテム)を1つのエンドポイント経由で9モデルに送り、各レスポンスのprompt_tokensを読みました。

計測は2026-08-12。同一入力で1.56倍の開きです。Claude Opus 5が外れ値なのは、Claude 4.7以降が新しいトークナイザーを使い同じテキストで「約30%多いトークン」を生成するとAnthropicが明記しているためです。

2つの表を重ねると、公称ウィンドウは使える数字ではなくなります。同じ420単語の文書が実際に何部入るかを見てください。

どれもおおむね1Mを謳っていますが、この文書に対する実容量は1.60倍ばらつきます。

この比率はコンテンツの種類で変わるので、別のワークロードにそのまま持ち込まないでください。TypeScriptファイルでは開きが1.53倍になり、最も少なかったのはGrokではなくGLM-5.2でした。中国語の文章では開きが1.88倍まで広がり、Claudeの2モデルはどちらも漢字1文字あたり約1トークンに近づき、そのサンプルでは1.00文字/トークン、Grokは1.87でした。ただしこれは規則ではなくサンプルです。句読点の多い別の中国語文では同じ2モデルが0.98と0.96文字/トークンになり、1文字で1トークンを超えるケースがあることを示しています。入力がコードや非英語なら、推測せず実測してください。

実務上のルールはひとつです。候補になっているモデルで、自分のコンテンツを測る。 max_tokens: 1のリクエストを1回投げればprompt_tokensが返り、費用はほぼゼロです。

コンテキストウィンドウを超えるとどうなる?

HTTP 400が返り、出力はありません。黙って切り詰められることはありません。 32,000トークンのモデルにわざと過大なリクエストを送り、挙動を確認しました。

{"error":{"code":null,
  "message":"<400> InternalError.Algo.InvalidParameter: Range of input length should be [1, 30720]",
  "type":"invalid_request_error"}}

この上限をよく読んでください。モデルの公称は32,000ですが、実際に強制される入力の上限は30,720で、残りは出力用に確保されています。公称ウィンドウは合計値であって入力枠ではなく、実際の上限は宣伝値より小さいことがあります。

エラーの形はベンダーごとに違うので、メッセージ文字列でのパターンマッチはやめてください。

• OpenAI互換エンドポイントは一般に400とcontext_length_exceeded系のコードを返します。
• Claudeはターンを正常に終えつつstop_reasonにmodel_context_window_exceededを返すことがあります。これはmax_tokensとは別物で、コード側で分岐が必要です。

両方に対応してください。ウィンドウが埋まって止まった応答と、max_tokensが小さくて止まった応答は別の障害で、対処も異なります。

コンテキストウィンドウが大きいと料金は上がる?

上がることもあり、ベンダー次第です。 2026年時点で課金方式は2種類あります。

• フラット。 Anthropicは1Mウィンドウ全体を標準単価で課金し、長文コンテキストの割増はありません。90万トークンのリクエストも9千トークンのリクエストも単価は同じです。
• 200K超で段階課金。 Gemini 3.1 Proはプロンプトが200Kを超えると入力が100万トークンあたり$2から$4、出力が$12から$18になります。Grok 4.20は同じ閾値で入力$1.25から$2.50、出力$2.50から$5.00に上がります。

つまり表向きの単価が安いモデルが、長文書の処理では高くつくことがあります。ワークロードが日常的に200Kを超えるなら、定価を比べる前に段階の切り替えを確認してください。なおプロンプトキャッシュのコスト計算は、どの段階に乗っていても上乗せで効きます。

公称ウィンドウは実際に使えるコンテキストと同じ?

同じではありません。このページで最も重要な注意点です。 1Mトークンを受け付けるモデルと、80万トークン目に埋めた事実を確実に取り出せるモデルは、別の話です。

検索精度が距離とともに劣化するのは公開モデルすべてに当てはまり、その差の大きさはスペック表ではなくベンチマークの問題です。別記事のLLMのコンテキストウィンドウ:200Kトークン超の実精度で、RULER、MRCR v2、NoLiMaが実際に何を測っているのかを整理しています。

公称ウィンドウはAPIが受け付ける上限、ベンチマークの数字はモデルがうまく使える範囲の目安、と分けて扱うのが安全です。

いまのウィンドウに、より多く詰め込むには?

どれもウィンドウを大きくはしません。中での消費を減らすだけです。 効果の大きい順に並べます。

1. プロンプトキャッシュ。 安定した接頭辞(システムプロンプト、ツール定義、繰り返し参照する文書)は、キャッシュヒット時にAnthropicほか数社で入力単価の約10%で課金されます。割引率はベンダーによって異なり、もっと深いところもあります。繰り返し呼び出す用途では最大のレバーで、変わるのはコストであって容量ではありません。
2. Compaction。 会話が上限に近づいた時点で、サーバー側が過去のターンを要約します。長時間動くエージェントセッションがエラーで止まらず走り続けます。
3. Context editing。 古いツール結果や過去の推論ブロックを履歴から取り除きます。エージェントループを埋めるのは会話よりツール出力で、コーディングエージェント固有の話はClaude Codeのトークン最適化にまとめています。
4. コンテンツに合ったトークナイザーを選ぶ。 上の表のとおり、この選択だけで実効容量が最大1.6倍変わります。ほかの最適化に手をつける前の話です。

9つのアカウントを作らずにベンダー横断でトークン数を比べるには?

正確に比べるには同じリクエストを別ベンダーのモデルへ送る必要があり、ベンダーごとに鍵もSDKも請求も別になります。 そこが摩擦です。サイジングの疑問ひとつのために9社と契約する人はいないので、この問いはたいてい実測ではなく経験則で片付けられます。

上に挙げたモデルはすべて同じOpenAI互換のHTTP形式を話すので、クライアント1つとモデルIDのループだけで足ります。max_tokens: 1を送ってprompt_tokensを読むだけなので、モデルは回答を書かず、計測コストは1セント未満です。

from openai import OpenAI

client = OpenAI(base_url="https://api.ofox.io/v1", api_key="YOUR_OFOX_KEY")
text = open("your_document.txt").read()

for model in [
    "anthropic/claude-opus-5",
    "openai/gpt-5.6-sol",
    "google/gemini-3.1-pro-preview",
    "moonshotai/kimi-k3",
    "z-ai/glm-5.2",
]:
    r = client.chat.completions.create(
        model=model, max_tokens=1,
        messages=[{"role": "user", "content": text}],
    )
    n = r.usage.prompt_tokens
    print(f"{model:32} {n:>7,} tokens   {len(text)/n:.2f} chars/token")

このページの計測値はすべてこのループで得たものです。ウィンドウサイズでモデルを決める前に、自分のコンテンツで走らせてください。ここまでの結果を見るかぎり、公称値はどちらの方向にも最大1.6倍ずれます。

参考情報源

• Claude Docs: コンテキストウィンドウ
• Claude Docs: 料金(トークナイザーの注記を含む)
• Claude Docs: プロンプトキャッシュ
• Claude Docs: compaction
• Gemini API 料金
• xAI: Grok 4.20 モデルカード
• OpenAI: GPT-5.6 Sol モデルカード
• ofox モデルカタログ