2023年に 32Kトークン で「広い」と言われたコンテキストウィンドウは、いまや 100万トークン(1M)級 が上位モデルの前提になった。2026年9月時点で、Anthropic・OpenAI・Google の3社はいずれも上位モデルの公式仕様に100万トークン前後の入力上限を載せている。個々のモデル名と数字は新しいモデルが出るたびに入れ替わるので、それは現行モデルとカットオフの一覧と各社の公式ページに任せ、本記事では世代が変わっても使える「数字の読み方」と「付き合い方」を中心に書く。

「100万トークン」とは、日本語で 新書 8〜10冊分、ソースコードなら 数万行。1セッションでこれだけ「視界に入れていられる」時代になった。だが、容器に入ることと、中身を最後まで読めていることは別だ。OpenAI が公表している多針型の長文ベンチ(MRCR)の値を見ると、同じモデルでも入力が長くなるほど点が下がり、その下がり方はモデルと世代で大きく違う(§1・§4で詳しく扱う)。

私の率直な評価を先に書く: 容器の大きさだけ見て選ぶ時代は終わった。重要なのは「実効コンテキスト × コスト × 渡し方」の3点だ。本記事では、コンテキストとは何かの定義から、スペック表の読み方、なぜ大きいだけでは不十分なのか、自分の用途で実効範囲を確かめる方法、長文で課金が跳ねる仕組み、そして個人〜小規模チームが今日から効かせられる節約5手まで、公式の数字と公開ベンチの実数値を交えて整理する。

CONTEXT WINDOW · 2023→2026

3年で容器は 250倍 に膨らんだ

— 1M が「贅沢品」から「前提」になった年表

2023
4K〜200K
GPT-3.5・初期GPT-4は4K〜32K。論文1本でいっぱい。11月に Claude 2.1 が200Kを出した。
2024
128K〜2M
GPT-4 Turbo(128K)・Claude 3(200K)が標準に。6月に Gemini 1.5 Pro が2Mを開発者へ開放。
2025
1Mが広がる
4月に GPT-4.1、8月に Claude Sonnet 4(ベータ)が1Mに対応。
2026
1M=標準
Claude・GPT・Gemini の上位モデルがそろって100万トークン級(9月時点)。

だが「対応」と「最後まで読めている」は別。OpenAI の長文ベンチ MRCR(8針)で、GPT-5.5 は 4K〜8K の98.1%から 512K〜1M では74.0%に下がる。
下がる幅はモデルと世代で違う(OpenAI「Introducing GPT-5.5」2026年4月23日の評価表。詳しくは§1・§4)。

1. 1M対応が並んだ——でも「最後まで読めている」とは限らない

1M 対応はこの2年で一気に広がった。2025年4月に OpenAI の GPT-4.1 が約105万トークン、同年8月に Anthropic の Claude Sonnet 4 が(ベータで)100万トークンに対応し、2026年9月時点では Anthropic・OpenAI・Google の上位モデルがそろって100万トークン前後を公式仕様に載せている。2023年に 32K で「広い」と感動していた頃から、わずか3年で 30倍以上。容器の大きさ競争はゴールに見えた。

ところが、各社が自分で公表している長文ベンチの値を見ると、話はそう単純ではない。長さ別の値がそろっているのが OpenAI の MRCR v2(8針)だ。AI との長い会話の中に「バクについての詩を書いて」のような同じ種類の依頼を8回紛れ込ませておき、「2番目の詩を返して」と指定した1つを正確に返させる。よく似たものの中から順番まで区別させる、多針型の needle-in-a-haystackだ。点数は、返した文が正解の文とどれだけ一致したかで付ける。長さ別の結果はこうなっている。

  • GPT-5.5: 4K〜8K で98.1%、128K〜256K で87.5%、512K〜1M で74.0%
  • GPT-5.4(同じ表の1世代前): 同じ3つの帯域で97.3% → 79.3% → 36.6%
  • Claude Opus 4.7(同じ表に OpenAI が並べた値): 128K〜256K で59.2%、512K〜1M で32.2%
  • GPT-6 Astra(2026年9月の発表): 256K〜512K で100.0%、512K〜1M で96.3%(同じ表の GPT-5.6 Sol は91.5%・73.8%)

出典(2026年9月26日確認): OpenAI「Introducing GPT-5.5」(2026年4月23日)・「GPT-6 Astra」(2026年9月3日)の評価表。ベンチの仕組みは OpenAI MRCR のデータセット説明。モデル名は発表当時のもの。

読み取れることは2つある。1つは、同じモデルでも入力が長くなるほど点が下がること。もう1つは、下がり方がモデルと世代で大きく違うことだ——1M 近くの帯域で GPT-5.4 は4割を切ったが、2026年9月の GPT-6 Astra は9割台を保った。順位は世代ごとに入れ替わるので、この数字そのものはすぐ古くなる。長く残るのは「公称の上限と、実際に精度を保てる範囲は別の数字だ」という教訓のほうだ。

誤解しないでほしい。これは「Claude や GPT がダメ」という話ではない。1Mを完全に使い切る用途は、実はそれほど多くない。300K(≒新書2〜3冊分)まで安定して読めれば、ほとんどのコーディング・リサーチ・要約タスクは完結する。問題は「1M対応」という数字だけ見て選ぶと、判断軸を見誤ることだ。

2. コンテキストとは何か——容器と中身を分けて理解する

用語を整理しておく。コンテキスト周辺で 3つの言葉が混ざりがちだ。

用語の整理 × 3

トークン・ウィンドウ・コンテキスト

① TOKEN — 文字の単位
AIがテキストを処理する最小単位。日本語1文字 ≒ 1〜1.5トークン、英語は約4文字で1トークン。「ありがとう」は5トークン前後。
② WINDOW — 容器のサイズ
1回のやり取りでモデルが扱える 最大トークン数。入力+出力(推論の途中経過を含む)の合計。API では入力だけで超えるとエラーになり、チャットアプリやエージェントは古い部分を要約・削除して収めるものが多い。
③ CONTEXT — 容器の中身
今ウィンドウに載っている内容そのもの。システムプロンプト・会話履歴・添付・ツール出力すべて含む。

要は 「ウィンドウ=容器のサイズ」「コンテキスト=中身」「トークン=単位」。
容器が大きくても、中身が雑なら答えも雑になる。

もうひとつ、「コンテキスト」と「メモリ」を混同しないこと。コンテキストはそのセッション内のみで、チャットを閉じれば消える。一方、ChatGPT Memory や Claude Memory のような セッションを跨いで覚える機能は別物だ。メモリの中身も最終的にはコンテキストへ注入されるが、ユーザーから見れば 永続的な記憶 vs 一時的な作業領域という違いがある。

よくある勘違い: 「コンテキストウィンドウが大きい=AIが賢い」ではない。容器の大きさは 「何を視界に入れていられるか」の上限でしかなく、推論能力・知識量・指示遵守の精度はまた別の指標で測られる。新しいモデルが出るたびに「コンテキスト 1M!」だけが見出しになりがちだが、それは性能の一面に過ぎない。

3. 容器のサイズは3つの数字で読む

モデルのスペック表を見るとき、コンテキストまわりで確認すべきは3つだけだ。ここを押さえておけば、どのモデルが出てきても同じ手順で比較できる。

① 入力上限

カタログでいちばん目立つ数字。ただしこれは「入る量」であって「読める量」ではない——次章で扱うとおり、実効はここより大幅に小さい。

② 出力上限

見落とされがちだが、入力上限より一桁小さい。2026年9月時点の主要モデルでも、100万トークン入れられるのに返せるのは6.5万〜12.8万程度だ。「長い文書を丸ごと書き換えさせる」用途ではこちらが先に詰まる。

③ 課金モデル

全域フラットか、閾値を超えると単価が跳ねるか。ここが実運用でいちばん効くのに、スペック表には載らないことが多い。§5で試算する。

以下は2026年9月29日時点の各社の公式ページの値だ。世代が変われば数字は動くので、上の3つの軸が実際にどう差になるかの実例として読んでほしい。いまの具体的なモデル名は現行モデルとカットオフの一覧で、数字は各社の公式ページで確かめること。

系列(2026年9月時点の例)入力上限出力上限長文の課金
Anthropic 上位(Claude Fable 5.1・Opus 5.5・Sonnet 5.5)1,000,000128,000上限まで同じ単価
Anthropic 軽量(Claude Haiku 4.5)200,00064,000—
OpenAI(GPT-6 Astra・Sol)1,050,000128,000272K超の入力で、そのリクエスト全体が入力2倍・出力1.5倍
Google(Gemini 3.1 Pro・プレビュー)1,048,57665,536200K超で入力 $2→$4、出力 $12→$18

出典(2026年9月29日確認): Anthropic Models overview・Pricing/OpenAI GPT-6 Astra・GPT-6 Sol のモデルページ/Google Gemini 3.1 Pro Preview・Gemini API pricing

表を見ると、入力上限はどこもほぼ横並びで、差がつくのは出力上限と課金の形のほうだ。上限が同じなら、窓の大きさはもう選定理由にならない。むしろ Anthropic は上限まで単価が変わらず、OpenAI と Google は一定の長さを超えると単価が上がる——同じ「1M対応」でも、長文をどれだけ気軽に投げられるかが違う。これは単なる料金設計ではなく、「長文ワークロードをどう扱うか」の違いを表している。詳細はコスト章で試算する。

実務での選び方はこうなる。常用する文書サイズで決めるのが基本だ——200K帯までに収まるなら、窓の大小よりその帯域での精度の安定と閾値の手前に収まるかどうかで選ぶ。300Kを超える巨大文書を常時扱うなら、そこで初めて実効範囲の広さと長文の単価が選定理由になる。1本に絞らず用途で使い分けるのが現実解で、この判断の仕方自体は世代が変わっても変わらない。

上限はどこで確かめるか

数字はまとめサイトや記事の表(この記事の表も含めて)ではなく、各社の公式ページで確かめる。見る場所はだいたい決まっている。

  • Anthropic: モデル概要ページの比較表に「Context window」「Max output」の行がある。長文の課金は料金ページの「Long context pricing」の節。
  • OpenAI: API ドキュメントのモデルごとのページに「context window」「max output tokens」と、長いプロンプトの料金の注記がある。
  • Google: Gemini API のモデルページに「Input token limit」「Output token limit」、料金ページに「prompts > 200k tokens」の区分がある。

もう1つ見落としやすいのが、同じ上限でも入る文章の量はモデルで違うことだ。上限はトークンで数えるので、トークナイザ(文字をトークンに分ける仕組み)が変わると、同じ文書のトークン数も変わる(§5の補足)。モデルを乗り換えたら、上限に対して余裕があるかを自分の文書で数え直すのが安全だ。

4. 「大きいほど良い」が成立しない3つの理由

前章のスペック表は容器の物理的サイズを示しただけだ。では、宣言された容器を本当に使い切れているのか。結論から書くと、上限いっぱいまで同じ精度で読めると考えないほうがいい。理由は3つある。

理由①: Lost in the Middle(真ん中で迷子)

2023年にスタンフォード大などの研究者(Liu ら)が論文「Lost in the Middle」で報告した現象だ。複数の文書から答えを探すタスクなどで、モデルは答えが入力の冒頭か末尾にあるときに最もよく正解し、中ほどにあるときは大きく精度を落とした。長文対応をうたうモデルでも同じ傾向だった。

体感としては、「長いPDFを丸ごと貼って『○○の数字は?』と聞くと、ちょうど真ん中あたりの数字を取り違える」。これがLost in the Middleだ。程度はモデルによって違うが、長文の中ほどに置いた情報は取りこぼしやすいという前提で、渡し方を工夫するのが安全だ。

理由②: Context Rot(文脈の腐敗)

会話を続けるほど、初期に出した指示が薄まっていく現象。「敬語で答えて」と冒頭で指定したのに、20往復後にはタメ口に戻っている——あれがContext Rotだ。

原因は2つ。① 初期指示が会話履歴の中で相対的に古く・軽く扱われる。② 長くなった履歴のせいでアテンションが分散し、特定のトークンを参照しにくくなる。Anthropic は開発者向けドキュメントで、トークン数が増えるほど正確さと想起が落ちる現象を context rot と呼び、「どれだけ入るか」と同じくらい「何を入れるか」を選ぶことが大切だと書いている。2025年9月には「コンテキストエンジニアリング」という題の技術記事で、この問題への対処を意識的なスキルとして整理した。

理由③: 公称コンテキスト ≠ 実効コンテキスト

§1の値のうち、1M 近く(512K〜1M)の帯域だけを並べるとこうなる。どれも OpenAI の発表の評価表で、同じ OpenAI MRCR v2(8針)の値だ。

OpenAI MRCR v2(8針)× 512K〜1M

1M 近くで、指定した1つを正確に取り出せるか

GPT-6 Astra 2026年9月 96.3%
GPT-5.5 2026年4月 74.0%
GPT-5.6 Sol 2026年9月 73.8%
GPT-5.4 2026年4月 36.6%
Claude Opus 4.7 2026年4月・OpenAI の表 32.2%

出典: OpenAI「Introducing GPT-5.5」(2026年4月23日。GPT-5.5・GPT-5.4・Claude Opus 4.7)・「GPT-6 Astra」(2026年9月3日。GPT-6 Astra・GPT-5.6 Sol)の評価表。モデル名は発表当時のもの。
同じ表の短い帯域(4K〜8K)では GPT-5.5 が98.1%、GPT-5.4 が97.3%。いずれも OpenAI が自社の発表で示した値で、第三者の測定ではない。

これは「点の低いモデルがダメ」という話ではない。同じ表の短い帯域では GPT-5.5・GPT-5.4 とも97%を超えており、ほとんどの実務(コードレビュー、長文記事執筆、議事録要約、リサーチ統合)は 1M よりずっと手前で完結する。問題なのは「1Mあるんだから1M投げ込めばいいでしょ」という使い方だ。また、これらはOpenAI が自社の発表で示した値で、同じ条件で比べられるのは表の中だけだ。Google もGemini 3.1 Pro のモデルカード(2026年2月)に MRCR v2(8針)の値を載せていて、128K(平均)の84.9%に対し 1M では26.3%だが、帯域の区切り方が違うので上の棒には並べていない。Anthropic の Claude Opus 5.5 などの発表ページには、長さ別のこの種の値は載っていない。いま使うモデルの実力は、次の方法で自分の用途に合わせて確かめたい。

自分の用途で「実効範囲」を確かめる

ベンチの数字は、文書の種類も質問の仕方も自分の用途とは違う。いちばん確かなのは、自分の文書で小さな needle-in-a-haystack を作ることだ。

  1. 実際に使う種類の文書(コード・議事録・契約書など)を用意し、答えがはっきりした事実を3〜5個、冒頭・中ほど・末尾に散らして入れる(文書にもともとある事実を使ってもよい)。
  2. 「全部を挙げて、どこに書いてあったかも示して」と、複数の事実を同時に取り出させる。1つだけ聞くと、実力より良く見える(単針と多針の差)。
  3. 同じ質問を 50K・200K・500K のように長さを変えて繰り返し、答えが崩れ始める長さを記録する。
  4. 取り出すだけでなく「AとBを比べて」のように組み合わせる質問も入れる。統合が要る質問ほど早く崩れやすい。

崩れ始めた長さの手前が、そのモデルとその用途での「実効コンテキスト」だ。モデルを替えたら測り直す。数十分でできる確認だが、スペック表の数字より実務の判断に効く。

5. コストの罠——長文で単価が跳ねるモデル、跳ねないモデル

前章で「実効は上限より手前」と書いた。そこにもう1つ重なる罠が「長文を投げると課金が跳ねる」ことだ。ここはベンダーによって設計が分かれている。

モデル(2026年9月時点)標準単価(入力 / 出力、100万トークンあたり)長文時
Claude Opus 5.5$4 / $201M全域で同じ単価
GPT-6 Sol$2 / $10272K超の入力でリクエスト全体が入力2倍・出力1.5倍
GPT-6 Astra$10 / $50同上
Gemini 3.1 Pro(プレビュー)$2 / $12200K超で入力 $4・出力 $18

具体的に試算する。500Kトークンの文書を投げて50Kの応答を1回もらうケース——大型コードベース全体や年次レポートを一気に要約する典型ケースだ。

  • Claude Opus 5.5(フラット): $4 × 0.5 + $20 × 0.05 = $3.00
  • GPT-6 Sol(272K超の割増し): $4 × 0.5 + $15 × 0.05 = $2.75(割増しが無ければ $1.50)
  • Gemini 3.1 Pro(200K超の単価): $4 × 0.5 + $18 × 0.05 = $2.90(200K以下の単価なら $1.60)
  • GPT-6 Astra(272K超の割増し): $20 × 0.5 + $75 × 0.05 = $13.75

読み方は2つある。1つは、閾値を超えた瞬間に同じモデルの費用が約1.8倍になること。GPT-6 Sol は短い入力なら Claude Opus 5.5 の半額だが、500K では差がほぼ消える——「どのモデルが安いか」は入力の長さで逆転する。もう1つは、単価の高い旗艦モデルに割増しが重なると桁が変わること(GPT-6 Astra は Opus 5.5 の4倍強)。比べる相手と自分の平均的な入力長で、計算し直してから選ぶこと。

閾値のある料金では、分けられる作業は閾値の手前に分けるのが効く。500Kを250Kずつ2回に分ければ、GPT-6 Sol は割増しがかからず $1.50 で済む(ただし全体を一度に見渡す必要がある作業には使えない)。「AIのトークン・セッションコスト節約」でも触れた構造だ。

補足: 同じ文書でも、トークン数はモデルで変わる。上限も課金もトークンで数えるので、トークナイザが変わると同じ文書の費用と余裕が変わる。Anthropic は公式のモデル概要で、Claude Opus 4.7 から使っている現在のトークナイザでは 1M トークンに入るのが約55.5万語、それ以前のモデルでは約75万語だと書いている。同じ英文がおよそ1.35倍のトークンになる計算だ。単価が据え置きでも、乗り換えたら実際の請求額で比べるのが確実だ。

6. 節約の5手——個人開発者がすぐ効く順

「容器は1Mあるが実効はそれより手前、しかも長く使うと金がかかる」——ここまでで分かった。では現場でできる対策は何か。私が日常的に使っていて効果が大きい順に5つ並べる。

実効TIPS × 5

コンテキスト節約の優先順位

① セッションを切る
話題が変わったら新しいチャットを開く。古い文脈を引きずらないだけで Context Rot は消える。Claude Code なら /compact や新セッション開始。
② 全文ではなく抜粋を渡す
100ページのPDFを丸ごと貼るのは最悪手。grep / 検索で関連箇所を切り出し、3〜5ページに圧縮してから渡す。RAGの発想を1人でやるイメージ。
③ 重要指示は末尾に再掲
Lost in the Middle 対策。冒頭で出したルールを 末尾で1行繰り返す。「上記を踏まえ、出力は◯◯形式で」のように。
④ プロンプトキャッシュ
同じシステムプロンプトや資料を何度も使うなら、Anthropic/OpenAI のプロンプトキャッシュで キャッシュから読んだ部分の入力単価が基本の1割以下になる(2026年9月時点の公式料金)。APIを叩いてるならまず設定する。
⑤ ファイルアドレスを明示
「N番目のファイル、◯行目」のようにアドレスを切ると、長文でも参照精度が上がる。AIへの 「インデックス付き目次」を最初に渡す感覚。

5つの中で 最大効果は ①「セッションを切る」。チャットを切るだけでハルシネーション体感が目に見えて減る。
④ は API 開発者向け、UI(claude.ai / ChatGPT)からは自動でやってくれる範囲。

個人的なベストプラクティスは 「①と②を徹底するだけで体感の精度が大きく変わる」こと。Claude Code を使うときも、長い1セッションで続けるよりも、論点が変わるたびに /compact や新規セッションでリセットする方が、最終的なアウトプットの質が安定する。

まとめ

本記事のポイントを整理する。

  • コンテキストウィンドウ = 1回のやり取りでAIが扱える最大トークン数。容器のサイズ。
  • 2026年9月時点、Anthropic・OpenAI・Google の上位モデルはそろって100万トークン級。入力上限の差は小さく、差がつくのは出力上限と長文の課金。
  • 公称の上限と実効の範囲は別。OpenAI が公表する多針ベンチ MRCR(8針)では、同じモデルでも入力が長くなるほど点が下がり、1M 近くの値は Claude Opus 4.7 の32.2%(OpenAI の表)から GPT-6 Astra の96.3%まで開いていた。
  • 実効範囲は自分の文書に事実を散らし、長さを変えて測るのがいちばん確か。モデルを替えたら測り直す。
  • 長文の課金は、上限まで同じ単価のもの(Anthropic)と、閾値を超えると割増しになるもの(OpenAI は272K・Google は200K)がある。安い・高いは入力の長さで逆転する。
  • 節約は 「セッションを切る・抜粋・末尾再掲・キャッシュ・アドレス明示」の5手、特に①②が効く。

容器が大きくなったのに、結局やっていることは 「何を渡し、何を渡さないか」の取捨選択だ。いまのAI活用スキルは、もはや「全部詰める力」ではない。必要なものだけを正しく渡し切る判断力こそが、モデルが何世代替わっても長く使えるスキルになる——というのが、1M が当たり前になった今の私の結論だ。

FAQ

Q1. トークン数を事前に測る方法は?

OpenAI は tiktoken ライブラリ、Anthropic は API にトークン数を数える機能(token counting)がある。日本語1文字 ≒ 1〜1.5トークン、英語1単語 ≒ 1.3〜1.8トークンが目安だが、トークナイザの世代で変わる(§5の補足)。コードも種類で大きく変わるので、長文を投げる前に実測するのが安全だ。

Q2. 「メモリ機能」とコンテキストはどう違う?

コンテキストはセッション内のみで、チャットを閉じれば消える。メモリ(ChatGPT Memory / Claude Memory)はセッションをまたいで覚え続ける別機構。メモリの中身も内部的にはコンテキストの一部として注入されるが、ユーザーから見れば永続 vs 一時の違いがある。

Q3. RAGとコンテキストウィンドウの関係は?

RAGは「コンテキストに必要な情報だけを動的に取得して載せる」仕組み。1Mウィンドウがあっても全部詰めると重く・遅く・高くなるので、検索で関連箇所だけ抜くRAGは現在も主流。詳しくはRAGとは何かを参照。

Q4. なぜ1M対応でも、もっと手前で精度が落ちる?

学習時の主な系列長と推論時の系列長のミスマッチ、アテンション機構の位置エンコーディングの限界、複数情報の統合に必要な計算量の急増などが重なる。「対応」と「全域で精度維持」は別の問題だ。どこから落ちるかはモデルと用途で違うので、§4の方法で自分の文書で測るのが確実だ。

Q5. MCPサーバーはコンテキストを節約する?

する。MCPは必要なときだけツール経由で情報を取りに行く仕組みなので、最初から全部コンテキストに載せる必要がなくなる。ファイル全文を貼る代わりに「読みに行く」発想に切り替えるイメージだ。

Q6. 実効範囲に収まらない長い文書は、どう分割・要約すればいい?

目的で分ける。① 全体の要約が欲しいなら、章ごとに要約してから要約どうしをまとめる二段構えにする。② 特定の答えを探すなら、全文を渡さず検索で関連箇所だけ抜く(RAG)。③ 全体を横断して比べる必要があるときだけ、実効範囲に収まる長さで1回に渡す。分割するときは見出しの単位で切り、前後の段落を少し重ねておくと、切れ目で話が途切れにくい。