容量は測定値であり、百万トークンの謳い文句ではない

モデルカードの「1M tokens」という行は、APIが受け付ける上限であり、モデルがうまく使える量の保証ではない。2026年8月、ofox.aiは同一の420語の英文ドキュメントを9つの旗艦モデルに送り、まったく同じテキストで1.56倍のトークン数のばらつきを測定した——Grok 4.20で614トークン、Claude Opus 5で957。宣伝されているウィンドウはカードの主張であり、本当の容量は測定値である。そしてTheorem 3によれば、ある性質はそのメカニズムが実装され測定しているときにのみ保証される。ここでのメカニズムはトークナイザと検索精度曲線であり、どちらも見出しの数字には現れない。

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

コンテキストウィンドウは単一のAPIリクエストに対するトークン予算である。モデルが読むすべてと書くすべてが1つの数字に収まらなければならず、APIはステートレスである——直前の呼び出しを覚えていない。各ターンでアプリケーションは会話全体を再送し、ウィンドウはその再送と来る返答がどれほど大きくてよいかの天井である。

だからウィンドウはいかなる有用な意味でも記憶ではない。セッションをまたいであなたの名前を覚えているように見えるチャット製品は、そのテキストをどこかに保存し、各リクエストでウィンドウに貼り戻している。永続性はあなたのアプリケーションにあり、モデルにはない。

ウィンドウに何がカウントされるか

リクエスト内のすべて、にレスポンス内のすべてを加えたもの。人が忘れる部分はたいてい最も高価なものだ：

• システムプロンプト。 セッションにつき1回ではなく、毎ターンカウントされる。
• 完全なメッセージ履歴。 再送する以前のすべてのユーザーとアシスタントのターン。
• ツール定義。 宣言する各ツールの名前、説明、JSONスキーマ。Claudeではこれらに加え、モデルごとのツール使用システムプロンプトが付く。Opus 5で286トークン、Opus 4.7で675。
• ツール結果。 エージェントループではしばしば最大の単一項目。ディレクトリ一覧やAPIレスポンスは数千トークンに達する。
• 推論トークン。 思考が有効なモデルでは、推論はカウントされ、テキストが返されなくても課金される。
• 返答そのもの。 だからmax_tokensとコンテキストウィンドウは相互作用する。出力の余地を残さないリクエストは切り詰められる。

「1M tokens」は9つの異なる数字である

[UNIQUE INSIGHT] 宣伝されているウィンドウはAPIが受け付ける上限であり、モデルがうまく使える量ではない——両者の隔たりはベンチマークの問題であってカードの問題ではない。本当の容量を決めるメカニズムはトークナイザと検索精度曲線であり、どちらも見出しの数字には現れない。

ofox.aiが2026-08-12にカタログ化した9つの旗艦モデルにおいて、「1M」は9つの異なる整数に解ける。きっちり1,000,000（Claude Opus 5、Grok 4.20、DeepSeek V4 Flash）から1,131,072（Qwen 3.8 Max）まで。何も測る前の13%のばらつきである。119モデルのテキストカタログ全体では、最も一般的なウィンドウは256K（25モデル）、22が1M。

これらの数字の出所に関する注意。ゲートウェイのカタログとベンダーのドキュメントは常に一致するとは限らない。2026-08-12、ofoxカタログはGrok 4.20を2,000,000と記載したが、xAI自身のモデルドキュメントは1,000,000としている。正直な比較はベンダー数字を使い、数字が重要な場合はベンダーのページを確認する。カードは主張、ベンダーのドキュメントはより強い主張、あなたのコンテンツで測ったprompt_tokensだけがあなたの質問に答える。

同一入力での1.56倍のばらつき

より深い驚きは、トークナイザ——ウィンドウの数字ではなく——が荷重を支えるメカニズムだということだ。ofoxは同一の2,638文字の英文ドキュメント（420語のサービス事後分析）を9つのモデルに1つのエンドポイント経由で送り、各レスポンスのprompt_tokensを読んだ：

• Grok 4.20：614トークン（4.30文字/トークン）
• GPT-5.6 Sol：626（4.21）
• GLM-5.2：632（4.17）
• DeepSeek V4 Flash：634（4.16）
• Gemini 3.1 Pro：684（3.86）
• Claude Opus 4.6：698（3.78）
• Qwen 3.8 Max：706（3.74）
• Kimi K3：716（3.68）
• Claude Opus 5：957（2.76）

同一入力で1.56倍のばらつき。Claude Opus 5が外れ値なのは、AnthropicがClaude 4.7以降は同じテキストで約30%多くのトークンを生成する新しいトークナイザを使うと文書化しているからだ。

2つの表を組み合わせると、宣伝ウィンドウは有用な数字ではなくなる。その同じ420語ドキュメントが実際に収まる部数は、Claude Opus 5の1,045部からGPT-5.6 Solの1,677部まで——すべて「約1M」を宣伝するモデルで1.60倍の差である。

比率はコンテンツタイプによって一定ではない。TypeScriptファイルではばらつきは1.53倍で、GLM-5.2がGrokよりもむしろ経済的だった。中国語の散文ではばらつきは1.88倍に広がり、両方のClaudeモデルは中国語文字あたり約1トークンに落ち、Grokは1.87だった。これをサンプルとして扱い、ルールとしてではない。2つ目の、句読点の多い中国語の文章では、同じ2つのモデルは0.98と0.96文字/トークンになり、ある文字は1トークンより高くつくことを意味する。入力がコードや非英語なら、想定ではなく測れ。

なぜトークン単価はベンダー間で比較できないか

トークンは固定量のテキストではないので、トークン単価は直接比較できない。トークン単価が安いベンダーでも、トークナイザが密なら語あたりでは高くつく。Anthropicは完全な1Mウィンドウを長文コンテキスト割増なしの標準料金で請求し、900Kトークンのリクエストはトークンあたり9Kのものと同じコストになる。Gemini 3.1 Proは200Kを超えると入力100万トークンあたり2ドルから4ドルへ、Grok 4.20は同じ閾値で1.25ドルから2.50ドルへ上がる。見出しの料金が安いモデルが長文ワークでは高くつく可能性があり、トークナイザの違いはあなたが落ちる階層の上に乗る。

定価と宣伝ウィンドウを読む予算比較は2つの主張を読んでいる。実際のドキュメントでprompt_tokensを測り、適用される階層料金を掛ける予算比較は1つの測定値を読んでいる。前者は推測、後者は請求可能な数字である。

ウィンドウは利用可能なコンテキストではない

最も重要な留保は、1Mトークンを受け付けるモデルは、トークン800,000の位置に埋めた事実を確実に見つけるモデルと同じではないということだ。検索精度は距離とともに低下し、すべての公開モデルでそうであり、その隔たりの大きさはベンチマークの問題であってカードの問題ではない。ofoxはRULER、MRCR v2、NoLiMaを実際にそれを測るベンチマークとして挙げている。RULERは合成コンテキストで制御された深さの検索を探り、MRCR v2は長文ドキュメントのマルチホップ検索を追い、NoLiMaは質問と証拠の語彙的オーバーラップを取り除いてもモデルがまだ答えを見つけるかをテストする。これらのスコアは「1Mコンテキスト」の隣のカードには現れない。

宣伝ウィンドウをAPIが受け付ける上限として扱い、ベンチマークの数字をモデルがうまく使える量の指標として扱う。最初の数字は契約、2つ目は測定値である。100万トークンを受け付けるが深さ500Kで60%の精度で検索するモデルの利用可能なコンテキストは宣伝よりはるかに下であり、ウィンドウはその隔たりを埋めない——別のメカニズム（ルーティング、検索、再構築）だけが埋める。

メカニズムは測定であり、スペックではない

[ORIGINAL DATA] Everythinkでは、コンテキストウィンドウを主張された他のあらゆる性質と同様に扱う。Theorem 3によれば、ある性質はそのメカニズムが実装され測定しているときにのみ保証される。「1M tokens」の行の背後にメカニズムはない。あなた自身のコンテンツのprompt_tokensがメカニズムである。我々はプロバイダに決める前に測り、プロバイダが新しいトークナイザを出したときに再測する。見出しの数字はいずれの方向にも最大1.6倍ずれたからだ。

これは再測定の規律である。トークナイザは物理学の安定した性質ではない。それはソフトウェアの人工物であり、ベンダーはAnthropicがClaude 4.7で行ったように、同じテキストで30%多いトークンを生成する新しいもので置き換えられる。それが起きると、古いトークナイザからキャッシュした容量推定はすべて同じ30%だけ間違っており、その上に構築したコスト推定も同様である。焼かれるチームは、一度測り、数字を設定ファイルに書き、二度と戻らなかったチームである。正直でい続けるチームは、どんな計器を再校正するように、スケジュールで再測定する。

これは我々にとって新しい規律ではない。HAI Engineは2016年から本番にあり、毎回の予測は複数のSistersに分岐する——それぞれ型付きのAIエージェントで、固有の人格と固有のコンテキスト予算の決定を持つ——その後、Oracleがその草稿を較正済みのアンサンブルに統合する。予測は1つの巨大なプロンプトではなく、ルーティングされた有界プロンプトの集合であり、その界は測定値であってカードの行ではない。

[PERSONAL EXPERIENCE] 我々は10年間エージェントのコンテキスト予算を測ってきた。目にする最も確実な間違いは、宣伝ウィンドウサイズでモデルを選び、本番で実ワークロードがカードが暗示したより35%少ないドキュメントしか収まらないと発見するチームだ。修正は決して大きなウィンドウではない。修正は、選択対象のモデルで自分のコンテンツを測ること——max_tokens: 1の1リクエストがprompt_tokensを返し1セント未満で済む——そしてそれに従ってルーティングすることだ。

ルーティングは検索に先行する

これは「the space is the router」と同じ原則である。Everythinkでは、network→community→roomトポロジが何かが応答する前にクエリをルーティングする。世界全体を1つのウィンドウに注ぎ込んで、トークン800,000の位置でモデルが正しい事実を見つけることを期待しない。関連するコンテキストを持つroomにルーティングし、モデルが実際に見るウィンドウを小さく、新鮮に、測定済みにする。容量は検索の問題になる前にルーティングの問題であり、検索はスペックの問題になる前に測定の問題である。

the 21 papersはこれを法典化する。Theorem 3は「大きいほどよい」とは言わない。ある性質はそれを保証するメカニズムが存在し測定しているときにのみ成り立つと言う。容量について、そのメカニズムはあなたのコンテンツを読むトークナイザと、深さにおけるモデルの検索を読むベンチマークである。宣伝数字はどちらでもない。

顧客主権は測定の上で動く

顧客主権——あなたのnetwork、あなたのブランド、あなたのデータ——は容量測定に対する静かな依存を持つ。network→community→roomトポロジを所有するとき、どのコンテキストがどのエージェントに届くかをあなたが決め、その決定は「何が収まるか」のあなたの推定と同じだけしか良くない。カードを信じる主権的な運営者は、本当の決定をベンダーのマーケティングコピーに手渡す。自分のコーパスを測る主権的な運営者は、ルーティングの決定をそれが属する社内に保つ。inclusion by designにも同じことが当てはまる。従量制データプランの低接続ユーザーは、百万トークンの放水ホースではなく、小さく良くルーティングされたウィンドウで最もよく供される。「小さく良くルーティングされた」は、測ったときにのみ行える測定である。

持っているウィンドウにより多く収める方法

これらはどれもウィンドウを大きくしない。すべてウィンドウ内で費やすものを減らす。収益の順に：

1. プロンプトキャッシュ。 安定したプレフィックス——システムプロンプト、ツール定義、繰り返し問うドキュメント——は、Anthropicや他のいくつかのベンダーでキャッシュヒット時に約10%の入力料金で請求される。正確な割引は様々で一部ではより深い。これは繰り返し呼び出しに対する最大のレバーであり、コストを変え、容量は変えない。
2. Compaction。 会話が制限に近づいたときの以前のターンのサーバー側要約で、長いエージェントセッションがエラーを出さずに動き続けるようにする。
3. コンテキスト編集。 古いツール結果と古い推論ブロックをトランスクリプトから取り除く。エージェントループは会話よりもツール出力で満たされる。
4. コンテンツに合ったトークナイザを選ぶ。 上の測定が示すように、その決定だけで、他を最適化する前に最大1.6倍の有効容量に値する。

最初の3つは予算を管理する。4つ目はどの予算に対して測るかを選ぶ。4つすべてはメカニズムであり、どれもカード上のより大きな数字ではない。

ウィンドウを超えると何が起きるか

HTTP 400が返り、出力はない。黙って切り詰められるものはない。ofoxは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互換エンドポイントは一般にcontext_length_exceeded風コードの400を返す。Claudeは代わりにstop_reason: "model_context_window_exceeded"でターンを終えることがあり、それはmax_tokensとは別で、コードに独自の分岐が必要である。両方を扱う。ウィンドウが満ちて早期に止まったレスポンスは、max_tokensが小さくて止まったレスポンスと同じ失敗ではなく、修正も異なる。

主要な要点

• 宣伝ウィンドウはAPIが受け付ける上限であり、モデルがうまく使える量ではない。 本当の容量は測定値であり、測定値はトークナイザと検索精度曲線である。
• 「1M tokens」は9つの異なる数字であり、同じ420語ドキュメントはある旗艦モデルで別のものより1.6倍多くの部数収まる。トークン単価はトークナイザ密度で調整しない限りベンダー間で比較できない。
• 自分のコンテンツを測る。 max_tokens: 1の1リクエストがprompt_tokensを返し1セント未満で済む。ウィンドウサイズでモデルを選ぶ前に実ワークロードで実行し、ベンダーが新しいトークナイザを出したときに再実行する。
• メカニズムは測定であり、スペックではない。 Theorem 3によれば、ある性質はそのメカニズムが実装され測定しているときにのみ保証される。「1M」の行にはメカニズムがない。prompt_tokensがメカニズムである。
• ルーティングは検索に先行する。 世界をウィンドウに注ぎ込まない。まず関連コンテキストにルーティングする——Everythinkのnetwork→community→roomトポロジは製品レベルで同じ原則である——モデルが見るウィンドウを小さく、新鮮に、測定済みにする。

よくある質問

コンテキストウィンドウは記憶と同じですか？ いいえ。コンテキストウィンドウはリクエストごとであり、永続しない。APIはステートレスである。各ターンで会話全体を再送し、ウィンドウは1つのリクエストが含んでよいものの天井である。その外のものは、アプリケーションが保存して再送しない限り消える。セッションをまたいであなたを覚えているように見える製品は、保存したテキストをウィンドウに再注入しており、モデルの記憶から引いているのではない。

100万トークンは何語ですか？ 英文の散文では、約440,000から685,000語——一般的な経験則が認めるより広い範囲。ofoxの同一ドキュメントでの測定では、9モデルのうち8つが100万トークンあたり587,000から684,000語に収まる。Claude Opus 5は新しいトークナイザのため約439,000の低い外れ値。コードはより密（約2.4から3.6文字/トークン）、中国語はさらに密（0.9から1.9）で、同じ1Mウィンドウはそれらをはるかに少なくしか収めない。

2026年に利用可能な最大のコンテキストウィンドウは？ 1Mトークンは主流層の頂点。いくつかのベンダーはきっかりの数字よりわずかに上にいる。Qwen 3.8 Maxが1,131,072、GPT-5.6が1,050,000、Gemini、GLM、Kimi K3が1,048,576。2026-08-12のofoxカタログの119テキストモデルのうち、最も一般的なウィンドウは256K（25モデル）、22が1M。

なぜ同じファイルはGPTよりClaudeで多くのトークンを使うのですか？ トークナイザが違う。Anthropicは、Claude 4.7以降が以前のClaudeより同じテキストで約30%多いトークンを生成する新しいトークナイザを使うと記している。ofoxの英文テストドキュメントで、Claude Opus 5は957トークンを使い、GPT-5.6 Solは626を使った——同一入力で1.53倍の差。何も悪くない。モデルは単に数え方が違い、トークン単価はそれで調整しない限りベンダー間で比較できない。

モデルのコンテキストウィンドウを増やせますか？ いいえ。モデルによって固定されており、上げるパラメータはない。変えられるのはどれだけ費やすかである。プロンプトキャッシュは安定プレフィックスの再送コストを下げ、コンテキスト編集は古いツール結果を取り除き、compactionはより古いターンを要約する。これらは予算を管理し、拡張はしない。

容量を推測するのをやめて測り始めたいなら、あなたのnetworkを作成しよう——何かが応答する前にルーティングするトポロジで、エージェントが実際に見るウィンドウをあなたが測ったものにする。

Sources

• 2026 — ofox.ai, "What Is a Context Window? Token Limits by Model (2026)" — https://ofox.ai/blog/what-is-a-context-window-token-limits-by-model-2026/
• 2026 — Anthropic, "Context windows" — https://platform.claude.com/docs/en/build-with-claude/context-windows
• 2026 — Anthropic, "Pricing, including the tokenizer note" — https://platform.claude.com/docs/en/about-claude/pricing