どのモデルカードにも「200K コンテキスト」「1M コンテキスト」といった数字が載っています。ディスク容量のような性能表記に見えますが、実際は リクエストごとに使い切る予算 に近いものです——そしてそれを使うものの大半は、あなたが入力したテキストではありません。
数値の最終確認: 2026年8月26日。
コンテキスト長とは何か
モデルに記憶はありません。呼び出すたびに、会話の全体をもう一度送ります——システムプロンプト、これまでのすべてのターン、添付ファイル——そしてモデルは一語書く前にそのすべてを読みます。
コンテキスト長とは、そのひとまとまりの最大サイズ であり、トークンで測ります。トークンは小さなテキストの断片で、英語ではおよそ単語の 4 分の 3 です。
つまり保存領域ではありません。モデルがあなたの書類を広げられる机の大きさであり、リクエストごとにまっさらに片づけられます。
今日の実際の上限
| コンテキスト長 | そのサイズのモデル |
|---|---|
| 32,768 | Qwen 2.5 Coder 32B |
| 200,000 | Claude Haiku 4.5 |
| 262,144 | Kimi K2.7 Code |
| 400,000 | GPT-5 ファミリー全体（Codex 各種を含む） |
| 1,000,000 | Claude Opus 5、Claude Sonnet 5、Qwen3 Coder Flash と Plus |
| 1,048,576 | Gemini 2.5 および 3.x ファミリー、DeepSeek V4 Pro |
二点、注目に値します。
100 万トークンはおよそ 75 万語 ——長編小説が数冊分です。これを必要とするアプリケーションはほとんどなく、必要だと感じる場合はたいてい、コンテキストの問題ではなく検索の問題を抱えています。
1,048,576 は 2²⁰ であり、マーケティング用の丸めた数字ではありません。ちょうど 1,000,000 と書いてあるならそれは丸めた値、1,048,576 と書いてあるなら実際のバッファサイズの報告です。
すべてのテキストモデルのトークン価格とコンテキスト長は チャットモデルのページ にあります。
実際に何がそれを埋めるのか
ここはモデルカードが教えてくれない部分です。Anthropic のドキュメントは最小限のリクエストについて正確なトークン数を公開しており、示唆に富みます:
| 送られた内容 | 入力トークン |
|---|---|
| 5 語のシステムプロンプト＋2 語のメッセージ | 14 |
| 9 語の質問＋ツール定義 1 つ | 403 |
| 画像 1 枚＋「Describe this image」 | 1,028 |
| PDF 1 つ＋「Please summarize this document.」 | 2,188 |
ツール定義ひとつでおよそ 390 トークン。 ツールを 20 個持つエージェントは、ユーザーが何も入力しないうちに窓の約 8,000 トークンを使い、しかもリクエストのたびに支払います。
画像は約 1,000 トークン。 スクリーンショット 20 枚で 20,000 です。
そして会話自体が膨らみます。 ターン 10 はターン 1 から 9 を抱えています。始めは小さく感じたチャットが、終わりにはリクエストの中で最大のものになります。
つまり「200K コンテキスト」のモデルでも、15 個のツールと長いシステムプロンプトと数枚のスクリーンショットを抱えたエージェントの中では、200K から始まりません。かなり下から始まり、ターンごとに縮んでいきます。
落とし穴: 同じ文章が同じトークン数とは限らない
コンテキスト長はトークンで測られますが、トークンはモデルをまたいで安定した単位ではありません。
Anthropic 自身のドキュメントには、Claude 4.7 以降が新しいトークナイザーを使っており 「同じ入力テキストが以前のモデルより約 30 パーセント多いトークンを生む」 と書かれています。
つまり、旧モデルで 150,000 トークンと測られたプロンプトは、新しいモデルでは 195,000 前後になりえます——同じ言葉で、窓を 30 パーセント多く使い、費用も 30 パーセント増える。ある一つのモデルに合わせて文書処理のパイプラインを設計したあとで乗り換えたなら、まだ収まると決めつける前に測り直してください。
プロバイダーは確認する手段を用意しています。Anthropic のトークン計測エンドポイントは無料で呼べます。実際に動かすつもりのモデルで数えてください。
足りなくなると何が起きるか
穏やかな性能低下ではありません。プロバイダーによって、エラーが返る、入力が切り詰められる、履歴が黙って捨てられる——三つ目が危険です。モデルはもう全体を見られない会話をもとに、自信をもって答えてしまうからです。
出口は三つ、手間の少ない順に:
削る。 古いターンを落とすか要約する。実装がいちばん安く、チャットならたいていこれで足ります。
キャッシュする。 コンテキストの大部分が固定の接頭部——長いシステムプロンプトや参照文書——なら、プロンプトキャッシュによってプロバイダーがそれを保存し、読み直しにはごく一部だけ課金します。窓は広がりませんが、埋めるコストの大半は消えます。
検索する。 コーパス全体を送るのをやめ、関連する部分だけを送る。工数は増えますが、データが増えても悪化しない唯一の方法です。
より大きなコンテキスト窓に手を伸ばすのは四つ目の選択肢で、たいてい最も高くつきます——その窓に入るすべてのトークンを、リクエストごとに支払うからです。
窓が大きいと高くつくのか
トークン単価では変わりません。同じリクエストなら、1M コンテキストのモデルが 200K のモデルより高いレートで課金されることはありません。Claude Sonnet 5 は入力 100 万トークンあたり 2.00 ドルで、500 トークン送ろうと 50 万トークン送ろうと同じです。
ただし 窓が大きいと、多く使うのが容易になります。あなたを止めていたはずのエラーが消えるからです。100 万トークンの窓を 100 万あたり 2.00 ドルで埋めれば、1 リクエストで 2.00 ドル——そのリクエストが月に 5 万回起きるチャットの 1 ターンなら、計算はすぐに深刻になります。
どちらにせよ規律は同じです。許される最大ではなく、できるだけ少なく送ること。
短くまとめると
- コンテキスト長は 1 回の リクエストの最大サイズであり、トークンで測る。記憶ではない。
- 今日の上限はおよそ 33K から約 1M まで。実運用の大半は下のほうで十分に収まる。
- ツール定義（各 ~390 トークン）、画像（~1,000）、PDF（~2,000）、そして送り直される履歴が、あなたのプロンプトより速くそれを埋める。
- 同じ文章でもモデルが違えばトークン数は違う——乗り換えたら測り直す。
- 窓が大きくてもトークン単価は上がらない。ただ、多く使うのが容易になるだけ。
ElliSekiz でさらに見る
コンテキスト長とトークン価格を並べて比べる。 チャットモデルのページ にすべてのテキストモデルと入力・出力レートが載っています。
そのうえで自分のプロンプトを測る。 どのモデルページにも playground があります——何かを見積もる前に、実際のリクエストを走らせて本物のトークン数を読んでください。
出典
- OpenRouter models API,
https://openrouter.ai/api/v1/models（コンテキスト長、2026-08-26 参照） - Anthropic — Token counting（文書化された例の数値、トークナイザーの変更、無料の計測エンドポイント）