コンテキストウィンドウ
Context Window ・ こんてきすとうぃんどう
LLMが1回の呼び出しで読み書きできるトークン量の上限。入力と出力の合計がこの枠に収まる必要がある。
✦ 30秒で試す — 航海10分前に名乗った名前を、AIは次の瞬間に忘れることがあるモデルが前の会話を踏まえて答えられるのはなぜ？予想してみる概要
コンテキストウィンドウは、LLMが1回の呼び出しで扱えるトークン量の上限です。モデルに渡すもの（システムへの指示・会話の履歴・添付した資料）と、モデルがこれから生成する出力の合計が、この枠に収まらなければなりません。人間にたとえるなら「作業机の広さ」で、机に載っている資料は参照できますが、載せきれなかった資料は、その瞬間のモデルにとって存在しないのと同じです。
大事なのは、LLM が会話を覚えているわけではない、という点です。モデルの重みは訓練後に固定されていて、呼び出しのあいだに何も残りません。チャットで話が通じているのは、アプリが毎回それまでの会話を丸ごと枠に入れて送り直しているからで、枠からあふれた古い発言は、モデルからは二度と見えなくなります。
枠の大きさはモデルごとに決まっていて、2020年の GPT-3 の2,048トークンから、2026年には主要なモデルの多くが100万トークン級まで広がりました。ただし大きければ万事解決ではありません。長い入力は料金とレイテンシを押し上げ、しかも長すぎる文脈では読み落としが増えることが知られています。会話の履歴の管理、RAGで資料をどれだけ入れるか、プロンプトエンジニアリングで情報をどこに置くか — LLM を使う設計判断の多くが、この机の広さを前提に組み立てられます。
なぜ生まれたか
コンテキストウィンドウは便利な機能として設計されたものではなく、Transformerという構造の制約から生まれた概念です。Transformer の中核の自己注意は、入力中のすべてのトークンどうしの関係を計算するので、素直に実装すると計算量とメモリがトークン数 n の2乗で増えます。1,000トークンなら100万通り、10万トークンなら100億通りの組み合わせです。さらにモデルは、訓練で見た長さを超える位置の扱いを学んでいないので、訓練時の長さを大きく超えると急に質が落ちます。そこで「この長さまで」と決めた上限が、そのままモデルの仕様として表に出たのがコンテキストウィンドウです。
一方で使う側の要求は「契約書を丸ごと読ませたい」「リポジトリ全体を理解させたい」と際限なく長くなります。この要求と2乗のコストの綱引きが、長い位置にも外挿しやすい位置エンコーディング（RoPE とその拡張）、注意の計算をメモリ効率よく行う FlashAttention（2022年）、生成中に保持する KV キャッシュの削減、長い文書での追加学習といった技術を生み、数年で上限を数百倍に押し広げました。コンテキストウィンドウの歴史は、Transformer の弱点を工学で埋め続けてきた歴史でもあります。
詳細
何が枠を消費するのか
枠を消費するのは、ユーザーがいま打った質問だけではありません。実際のAPIリクエストでは、（1）システムプロンプト（役割の指示や出力形式の指定）、（2）これまでの会話履歴の全文、（3）RAGで検索してきた参照資料、（4）ツールの定義（Function Callingのスキーマ）、（5）ツールの実行結果、そして（6）これから生成する出力の分までが、すべて同じ枠を分け合います。出力の上限（max tokens）も枠の一部なので、入力を詰め込みすぎると、長い回答を書く余地がなくなります。
LLMは呼び出しのたびに、枠の中身を最初から全部読み直して次のトークンを決めています。会話が長くなると、アプリ側は枠に収めるために古い履歴を切り捨てるか、要約して短くするしかありません。長く話していると「昔の話を忘れる」のは、モデルが忘れたのではなく、その発言がもう枠に入っていないからです。
下の部品で、会話を続けて枠をあふれさせてみてください。最初に名乗った往復がこぼれ落ちると、名前を聞いても答えられなくなります。「要約する」で古い往復を短い要約に圧縮すると空きができますが、要約に残さなかった細部は戻りません。
「話を続ける」を押して旅行の相談を進めてください。1往復ごとに、その分のトークンが枠に積まれます。枠は400トークンしかありません。
KVキャッシュ — 長さがそのままメモリのコストになる
コンテキストウィンドウの実際のコストを理解する鍵が KV キャッシュです。Transformerは生成中、それまでに読んだ各トークンの Key と Value のベクトル（注意の計算に使う中間結果）をGPUのメモリに残しておき、新しいトークンを1つ作るたびに参照します。同じ計算を毎回やり直さないためのキャッシュで、その大きさは「2（K と V）× 層の数 × KV のヘッド数 × ヘッドの次元 × トークン数 × 1要素のバイト数」です。
たとえば Llama 3.1 70B（80層、KV ヘッド 8、ヘッドの次元 128）を16ビットで動かすと、1トークンあたり 2 × 80 × 8 × 128 × 2 バイト ≒ 0.31MB、12万8千トークンの文脈では約40GB になり、1本の会話だけで大型の GPU 1枚分のメモリを占めます。この式の「KV のヘッド数」を減らす工夫が GQA（Grouped-Query Attention）で、複数の問い合わせヘッドで K と V を共有して、キャッシュを数分の1に縮めます（Llama 3.1 70B の問い合わせヘッドは64個ですが、KV ヘッドは8個です）。長い文脈の料金が高く応答も遅くなるのはこのためで、量子化による KV キャッシュの圧縮や、複数のリクエストで共通する前半部分の計算結果を再利用するプロンプトキャッシュが、実運用のコストを大きく左右します。
Lost in the Middle — 長ければ読めるとは限らない
上限が100万トークンあっても、その全域を等しく読めているわけではありません。2023年の研究（Liu らの “Lost in the Middle”）では、長い文脈の冒頭と末尾に置いた情報はよく使われる一方、中ほどに埋もれた情報を使う精度が大きく落ちることが報告されました。精度が U 字を描くこの性質は実務に直結します。重要な指示や判断材料は文脈の先頭か末尾に置く、RAGでは検索結果の重要なものを端に寄せる、といったプロンプトエンジニアリングの定石は、この現象への対策です。その後のモデルでは改善が進んでいますが、「とりあえず全部入れる」はコストを増やしながら精度も下げうる手です。
長文化の歴史と設計への影響
上限の拡大はとても速く進みました。2020年の GPT-3 は2,048トークン、2023年3月の GPT-4 は8K と 32K、同年7月の Claude 2 が100K、11月には Claude 2.1 が200K、GPT-4 Turbo が128K に広げます。2024年2月の Gemini 1.5 Pro が100万トークン（のちに200万）に届き、2025年には Meta の Llama 4 Scout が1,000万トークンをうたいました。2026年の時点では、主要な商用モデルの多くが100万トークン級の枠を持っています。
この拡大は「巨大な枠に資料を全部入れればRAGは要らないのでは」という議論も生みました。実際には、GB 級の社内文書は依然として入りきらず、入るとしてもトークン課金と応答時間が跳ね上がるので、「検索で絞り込んでから文脈に入れる」RAG の価値はなくなっていません。むしろ焦点は、限られた枠に何をどの順で載せるかという「コンテキストエンジニアリング」に移っています。AIエージェントが長い作業の途中でツールの実行結果を要約し、不要になったものを捨てながら進むのも、この延長にある技術です。コンテキストウィンドウは、LLM 時代の設計者にとってのメモリ設計 — 何を載せ、何を捨てるかという資源管理の問題なのです。
試問
400トークンしかない小さなコンテキストウィンドウで、旅行の相談を7つの話題まで続けます。「話を続ける」で往復が1つずつ積まれ、枠があふれると古い往復からこぼれ落ちます。「古い往復を要約する」を押すと、最新の1つ以外が短い要約に圧縮されます。
「話を続ける」を押して旅行の相談を進めてください。1往復ごとに、その分のトークンが枠に積まれます。枠は400トークンしかありません。