はじめに

ChatGPTやClaudeと長く会話していると、「さっき話した内容を急に忘れられてしまった」「長いPDFを渡したら処理が遅くなった、あるいは途中の情報を見落とされた」という経験をしたことはないでしょうか。この背景にあるのが「コンテキストウィンドウ」と呼ばれる仕組みです。

本記事では、コンテキストウィンドウの基本的な考え方から、2020年前後から2026年現在に至るまでの技術的な進化の歴史、そして「トークン数を増やせば解決」というわけにはいかない技術的な理由までを、専門用語をできるだけかみ砕きながら解説します。読み終える頃には、モデル選定やプロンプト設計の際に「コンテキストウィンドウ」という言葉に振り回されることが減るはずです。

想定読者：生成AIを日常的に使っているものの、コンテキストウィンドウの仕組みまでは説明できない、という初心者〜中級者の方。

対象読者

ChatGPTやClaudeなどの生成AIを日常的に使っているが、「コンテキストウィンドウ」の仕組みまでは詳しく知らない方
長い会話や大きなドキュメントを扱うと精度が落ちる理由を知りたい方
RAG（検索拡張生成）と長いコンテキストウィンドウのどちらを使うべきか迷っている方
モデル選定の際に「トークン数」という指標をどう読み解けばいいか知りたい方
コンテキストウィンドウがどのような経緯で拡大してきたのか、歴史的な流れを俯瞰したい方

この記事でわかること

コンテキストウィンドウの正確な定義と、「記憶」との違い
トークンという単位の考え方とおおよその換算目安
GPT・Claude・Geminiなど主要モデルにおけるコンテキストウィンドウ拡大の歴史（2020年〜2026年）
コンテキストウィンドウに上限がある技術的な理由（Attentionの計算量、KVキャッシュ、位置エンコーディング）
「Lost in the Middle」「Context Rot」など、大きなコンテキストウィンドウを使う上での落とし穴
広告されているコンテキストウィンドウの数値と、実際に使える範囲（実効コンテキスト）の違い
RAG（検索拡張生成）と長いコンテキストウィンドウをどう使い分けるべきか
2026年7月末時点における主要モデルのコンテキストウィンドウ比較

本編

全体像

コンテキストウィンドウは、よく「AIの作業机の広さ」に例えられます。机が広ければ広いほど一度にたくさんの資料を広げて参照できますが、机の広さそのものが「記憶力」というわけではありません。会話が終わって次の机に移れば（＝新しいセッションを始めれば）、前の机に広げていた資料は基本的に引き継がれません。

この「机の広さ」は、この6年ほどで劇的に広がってきました。まずは全体の流れをざっと俯瞰してみましょう。

この図から分かるとおり、コンテキストウィンドウの拡大は決して滑らかな右肩上がりではなく、いくつかの技術的なブレイクスルーを経て段階的に進んできました。次の章から、この背景にある基本概念と歴史を詳しく見ていきます。

基本概念：そもそもコンテキストウィンドウとは何か

コンテキストウィンドウとは、生成AIモデルが一度の応答生成において「参照できる」テキストの最大量のことです。ここには、ユーザーが入力したプロンプトや会話履歴だけでなく、モデル自身が生成する出力（回答）も含まれます。

誤解されやすいポイントを整理しておきます。

「記憶」ではなく「作業スペース」：コンテキストウィンドウは長期的な記憶装置ではありません。会話が終了すれば（新しいセッションを開始すれば）、原則としてそれまでのやり取りはモデルには引き継がれません。あくまで「今、目の前に広げている資料」の範囲です。
単位は「トークン」：文字数ではなく「トークン」という単位で数えられます。トークンは単語よりも小さい単位（サブワード）に区切られることが多く、英語ではおおよそ1トークン＝0.75語程度が目安とされます。日本語を含む多言語では、英語よりも1文字あたりのトークン消費が大きくなる傾向がある点にも注意が必要です。
入力と出力の合計：コンテキストウィンドウは、入力したプロンプトの分だけでなく、モデルが生成する出力分も含めた合計値でカウントされます。

目安として、Anthropicの公開資料によれば100万トークンはおよそ55万語（英語）、20万トークンはおよそ15万語・書籍500ページ相当とされています。日本語の技術文書であれば、これより実質的に扱える分量は少なくなる可能性がある点は念頭に置いておくとよいでしょう。

これまでの経緯：コンテキストウィンドウはこう伸びてきた

現在のほぼすべての生成AIモデルは、2017年にGoogleの研究者らが発表した論文「Attention Is All You Need」で提案されたTransformerというアーキテクチャをベースにしています¹。この論文が導入した「Self-Attention（自己注意機構）」こそが、コンテキストウィンドウという概念そのものの土台になっています。

そこから現在に至るまでの主要な変遷をまとめたのが下の表です。

時期	モデル	コンテキストウィンドウ	備考
2020年	GPT-3	2,048トークン	大規模言語モデルの実用性を広く印象づけた世代
2022年11月	ChatGPT（GPT-3.5ベース）	4,096トークン	一般公開され、生成AIブームの起点となる
2023年3月	GPT-4 / Claude 1	8,192〜32,768トークン / 当初約9,000トークン	Claudeは同年5月に10万トークンへ拡張
2023年11月	GPT-4 Turbo / Claude 2.1	128,000トークン / 200,000トークン	両社が「業界最大」を競い合った時期
2024〜2025年	Gemini 1.5 Pro / GPT-4.1 / Llama 4 Scout	100万〜200万トークン / 約105万トークン / 理論値1,000万トークン	「100万トークン時代」の幕開け
2025年8月	Claude（Sonnet 4など）	100万トークン（ベータ提供）	専用ヘッダー指定と一定の利用実績が必要な試験提供
2026年	Claude Opus/Sonnet/Fable 5系、GPT-5.5/5.6、Gemini 3.1 Pro、DeepSeek V4、MiniMax M3など	100万トークンが標準仕様に	ベータではなく追加費用なしの標準提供へ。オープンウェイトモデルも追随

この年表から見えてくるポイントをいくつか補足します。

2023年後半は「10万〜20万トークン競争」の時期でした。 OpenAIがGPT-4 Turboで128,000トークンを実現すると、Anthropicは同月にClaude 2.1で200,000トークンを打ち出し、当時「業界最大」を謳いました。

2024年から2025年にかけて、桁が一つ変わりました。 Googleが2024年にGemini 1.5シリーズで100万〜200万トークンを実現したのを皮切りに、2025年にはOpenAIのGPT-4.1が約105万トークン、MetaのLlama 4 Scoutに至っては理論値1,000万トークンを謳うようになります。ただしLlama 4 Scoutの1,000万トークンという数値には注意が必要です。実際の学習過程では25.6万トークン程度の系列長でしか訓練されておらず、この数値はアーキテクチャ上の理論値に近いという指摘が技術コミュニティから出されています²。

Claudeは当初、100万トークンをベータ機能として慎重に提供していました。 2025年8月ごろの提供開始時点では専用のベータヘッダーの指定や一定の利用階層が必要とされていましたが、2026年に入ってからはOpus・Sonnet・Fableの各シリーズで追加費用のかからない標準仕様として提供されるようになっています。

そして2026年、100万トークンは「当たり前」になりました。 Claude、GPT、Geminiといった主要な商用モデルだけでなく、DeepSeek V4やMiniMax M3、Qwenシリーズといった中国系のオープンウェイトモデルも軒並み100万トークン級のコンテキストウィンドウを実現し、入力トークン単価が大手商用モデルの数十分の1程度まで下がっているケースもあります。

余談ですが、この記事を執筆している2026年7月末の時点だけでも、Claude Opus 5（7月24日発表）、OpenAIのGPT-5.6 Solファミリー（7月に一般提供開始）、GoogleのGemini 3.6 Flash（7月21日発表）と、わずか10日ほどの間に主要3社がそれぞれ新しいモデルを投入しています。裏を返せば、この分野の数値は本記事のような解説記事であっても、公開から数週間で古くなる可能性があるということです。具体的な数値を重視する場合は、必ず各社の公式ドキュメントで最新情報を確認することをおすすめします。

なぜ「大きくするだけ」では済まないのか：技術的な仕組み

「じゃあコンテキストウィンドウはどんどん大きくすればいいのでは」と思うかもしれません。しかしこれは単なる設定値の変更では済まない、いくつかの技術的な制約が絡んだ問題です。ここでは3つの観点から見ていきます。

1. Self-Attention（自己注意機構）の計算量

Transformerの核心であるSelf-Attentionは、入力された各トークンが「他のすべてのトークン」との関連度を計算する仕組みです。N人が参加する会議で、全員が全員の発言内容を突き合わせて確認し合う場面を想像してください。参加者が2倍になると、確認し合うべき組み合わせの数はおよそ4倍に膨れ上がります。これと同様に、Self-Attentionの計算量はトークン数nに対しておおむねO(n²)、つまりnの2乗のペースで増加します。これが、コンテキストウィンドウを増やすほど計算コストが急激に膨らむ最大の理由です。

2. KVキャッシュとメモリの制約

文章を1トークンずつ生成していく際、毎回すべてのトークンについて計算をやり直すのは非効率です。そこで多くのモデルは、一度計算した「Key」と「Value」と呼ばれる情報をキャッシュ（KVキャッシュ）として保持し、使い回します。これにより1トークンあたりの生成コストはO(n)まで抑えられますが、その代わりキャッシュそのものがGPUメモリを消費し続け、コンテキストが長くなるほどメモリ使用量が線形に増加します。目安として、数百億パラメータ級のモデルで100万トークン分のKVキャッシュを保持しようとすると、モデル自体の重みとは別に数百GB規模のGPUメモリが必要になるという試算もあります³。

3. 位置エンコーディング（RoPEなど）の限界

「太郎が花子を助けた」と「花子が太郎を助けた」が違う意味になるように、モデルは各トークンの「順番」を認識する必要があります。多くの現行モデルは、RoPE（Rotary Position Embeddings、回転位置埋め込み）と呼ばれる方式でこの順序情報を扱っています。ところがRoPEを含む多くの位置エンコーディング方式は、学習時に見た系列長を超えると性能が急激に劣化するという弱点を持っています。

このためコンテキストウィンドウを事後的に拡張するには、YaRNやNTK-aware scalingといった専用の手法が用いられます。これらはRoPEの周波数パラメータを調整することで、追加学習の量を抑えながら元のモデルより長い系列を扱えるようにする技術です⁴。

つまり「コンテキストウィンドウを2倍にする」という一見単純な変更の裏には、計算量・メモリ・学習データという3つの制約を同時にクリアする必要があるということです。

2026年7月時点の主要モデル比較

ここまでの歴史を踏まえて、本記事執筆時点（2026年7月31日）で確認できた主要モデルのコンテキストウィンドウを一覧にまとめます。

モデル（提供元）	コンテキストウィンドウ	備考
Claude Opus 5 / Sonnet 5 / Fable 5（Anthropic）	100万トークン（標準・追加費用なし）	Haiku 4.5は20万トークン。最大出力は12.8万トークン
GPT-5.6 Sol（OpenAI）	約105万トークン	最大出力12.8万トークン。2026年7月に一般提供開始
Gemini 3.1 Pro（Google DeepMind）	100万トークン	後継とされるGemini 3.5 Proは2026年7月末時点で「近日公開」の状態が続いており、200万トークンという情報もあるが未確定⁵
Llama 4 Scout（Meta、オープンウェイト）	理論上1,000万トークン	実運用上の実効性については議論がある（前章参照）
DeepSeek V4 / MiniMax M3（オープンウェイト・中国系）	100万トークン	入力トークン単価が大手商用モデルの数十分の1程度に収まる場合がある
Qwen3.5系（オープンウェイト・中国系）	ネイティブ25.6万トークン、YaRNで最大約101万トークンまで拡張可能⁶	Llama 4 Scoutと同様、ネイティブ長と拡張後の数値の区別が必要

この表からも分かるとおり、「100万トークン」は2026年半ば時点でほぼ業界標準になりつつある。一方で、同じ「100万トークン」という表示でも実際にどこまで精度を保って使えるか（実効コンテキスト）には大きな差があることが、複数の第三者検証で指摘されています。次の章で詳しく見ていきましょう。

なお、この分野は数週間単位で状況が変わるため、上記はあくまで執筆時点のスナップショットです。最新の数値については各社の公式ドキュメントを確認することを強くおすすめします。

よくある落とし穴と対策

Lost in the Middle（U字型の性能劣化）

2023年にスタンフォード大学などの研究チームが発表した論文「Lost in the Middle: How Language Models Use Long Contexts」⁷は、生成AIモデルが長いコンテキストの中のどこに置かれた情報を得意・不得意とするかを検証しました。結果として明らかになったのが、次のようなU字型の傾向です。

情報が置かれた位置	精度の傾向
コンテキストの先頭付近	高い
コンテキストの中盤	大きく低下（実験条件によっては30%以上の低下も）
コンテキストの末尾付近	高い

この現象は、GPT-3.5やGPT-4、Claude 1.3を含む複数のモデルファミリーで再現性のある傾向として報告されました。背景には、RoPEなどの位置エンコーディングが持つ「遠くのトークン同士ほど関連度を低く見積もる」という性質と、それをさらに強調するSoftmax正規化の仕組みがあると考えられています。

Context Rot（コンテキストの劣化）

Lost in the Middleよりも新しい概念として、民間の研究グループ（Chroma Research）が提唱した「Context Rot」があります。これは情報の位置だけでなく、単純に入力が長くなるにつれて性能が非一様に劣化していく現象を指す言葉です。18種類のモデルを対象にした調査では、公称のコンテキストウィンドウに達するはるか手前で30〜50%程度の精度低下が見られたケースが報告されています。なお、この調査は査読付き学術論文ではなく民間企業による技術レポートである点は留意してください。

興味深いのは、「整理された読みやすい入力の方が、ランダムにシャッフルされた入力よりもかえって性能が下がる」という直感に反する報告がある点です。モデルが構造的なパターンに引きずられて誤った推論をしてしまう可能性を示唆しています。

広告値と実効コンテキストのギャップ

「200Kトークン」と表示されているモデルでも実際には13万トークン程度から性能劣化が始まる、「100万トークン」のモデルも60万〜70万トークンあたりから怪しくなり始める、といった報告が複数見られます。カタログスペックの数字は「上限」であって「性能保証」ではないと捉えておくのが安全です。実際に使う用途で自分なりに検証してから本番投入することをおすすめします。

コストとレイテンシ

コンテキストウィンドウを目一杯使うことは無料ではありません。処理するトークン数に比例してコストがかかり、100万トークンを1回埋めるだけの料金は、モデルによって数十倍から百倍近い開きがあります。また、コンテキストが長くなるほど応答生成にかかる時間（レイテンシ）も増える傾向があります。

RAG（検索拡張生成）はもう不要なのか

100万トークン級のコンテキストウィンドウが登場し始めた2024年ごろ、「これだけ大きければRAGはもう不要になるのでは」という見方が広がりました。しかし2026年時点の実態を見る限り、この予測は早計だったと言えそうです。

RAGには、コンテキストウィンドウをただ大きくするだけでは代替できない利点があります。

クエリ単位のコストを大幅に下げられる（関連する数千〜数万トークンだけを抽出して渡すため）
アクセス権限のあるドキュメントだけに絞り込んでからモデルに渡せるため、情報漏洩のリスクを抑えやすい
どの文書を根拠に回答したかを追跡しやすく、監査対応にも向いている

2026年時点で主流になりつつあるのは、どちらか一方を選ぶのではなく両者を組み合わせる「ハイブリッド構成」です。

実務上の目安としては、「1つの文書がコンテキストの予算内に収まり、質問もその文書だけに関するものであれば、検索の仕組みを介さずそのまま渡してしまう」というシンプルな判断基準が有効だとする報告もあります。逆に対象文書が数百〜数千件にわたるような場合は、素直に検索の仕組みを組み合わせるべきでしょう。

まとめと次のステップ

コンテキストウィンドウは「一時的な作業スペース」であり、永続的な記憶ではない
2020年時点の2,048トークンから、2026年には主要モデルの多くが100万トークンに到達した
しかし、Self-Attentionの計算量（O(n²)）、KVキャッシュのメモリ消費、位置エンコーディングの限界という3つの技術的制約があるため、「数字を大きくするだけ」では済まない
Lost in the MiddleやContext Rotのような落とし穴があり、広告上の数値と実際に使える範囲（実効コンテキスト）は必ずしも一致しない
RAGは「不要」になったわけではなく、コスト・追跡性・アクセス制御の観点から今も有効。2026年時点ではRAGと長いコンテキストを組み合わせるハイブリッド構成が主流になりつつある
この分野の数値は数週間単位で更新されるため、具体的な数字は常に公式ドキュメントで確認する習慣をつけたい

さらに学びたい方へ

Attention Is All You Need（Transformer原論文）
https://arxiv.org/abs/1706.03762
Lost in the Middle: How Language Models Use Long Contexts
https://arxiv.org/abs/2307.03172
YaRN: Efficient Context Window Extension of Large Language Models
https://arxiv.org/abs/2309.00071
Claudeのコンテキストウィンドウ（Anthropic公式ドキュメント）
https://platform.claude.com/docs/en/build-with-claude/context-windows
Gemini 3.1 Pro モデルカード（Google DeepMind）
https://deepmind.google/models/model-cards/gemini-3-1-pro/

免責事項: 本記事は当社が確認した時点の情報に基づく参考情報であり、正確性・完全性・最新性を保証せず、利用により生じたいかなる損害についても弊社は責任を負いません。

Vaswani, A. et al., "Attention Is All You Need" (2017). https://arxiv.org/abs/1706.03762 ↩
Llama 4のアーキテクチャに関する技術的分析では、公称の1,000万トークンに対し実際の学習系列長は25.6万トークン程度に留まるとの指摘がある。 ↩
数百億パラメータ級モデルにおけるKVキャッシュのメモリ試算例（Meta AI, 2025年）を参照。モデルやバッチサイズ、精度（FP16/FP8など）によって数値は変動する。 ↩
YaRN: Efficient Context Window Extension of Large Language Models. https://arxiv.org/abs/2309.00071 ↩
2026年7月時点の報道ベースの情報であり、Google DeepMindによる公式発表・仕様確定はまだ行われていない。 ↩
Qwen3.5の公式Hugging Faceモデルカードによれば、ネイティブのコンテキスト長は262,144トークンで、YaRNを用いることで最大1,010,000トークンまで拡張可能とされている。 ↩
Liu, N. F. et al., "Lost in the Middle: How Language Models Use Long Contexts" (2023). https://arxiv.org/abs/2307.03172 ↩