コンテキストウィンドウ

概要

コンテキストウィンドウは、LLMが一度の推論で扱えるトークン量の上限です。モデルに渡すプロンプト（システム指示・会話履歴・添付資料）と、モデルが生成する出力の合計がこの枠に収まらなければならず、あふれた分は切り捨てるか要約するしかありません。人間にたとえるなら「作業机の広さ」で、机に載せた資料は参照できますが、載せきれなかった資料はその瞬間のモデルにとって存在しないのと同じです。

この上限はモデルごとに固定されており、初期のGPT-3が約2,000トークン（日本語で数ページ分）だったのに対し、現在の主要モデルは10万〜100万トークン級まで拡大しています。とはいえ「大きければ万事解決」ではありません。長い入力は推論コストとレイテンシを押し上げ、しかも後述するように長すぎる文脈は精度を落とすことが知られています。チャットボットの会話履歴管理、RAGでの資料の詰め込み方、プロンプトエンジニアリングでの情報の配置 — LLMを使う設計判断のほぼすべてが、この「机の広さ」を前提条件として組み立てられます。

なぜ生まれたか

コンテキストウィンドウは「便利な機能」として設計されたものではなく、Transformerというアーキテクチャの構造的な制約から生じた概念です。Transformerの中核であるセルフアテンションは、入力中のすべてのトークンどうしの関係を計算するため、計算量とメモリがトークン数nに対してnの2乗で増えます。1,000トークンなら100万通り、10万トークンなら100億通りの組み合わせを扱うことになり、無制限に長い入力は物理的に処理できません。そこで学習時に「この長さまで」と決めた上限が、そのままモデルの仕様として現れたのがコンテキストウィンドウです。

一方でユーザー側の要求は「契約書を丸ごと読ませたい」「リポジトリ全体を理解させたい」と際限なく長文化します。この需要と2乗コストの綱引きが、位置エンコーディングの改良や、アテンションのメモリ効率化、KVキャッシュの圧縮といった長文化技術の開発競争を生み、数年で上限を数百倍に押し広げてきました。コンテキストウィンドウの歴史は、Transformerの弱点を工学で埋め続けてきた歴史そのものです。

詳細

何がウィンドウを消費するのか

コンテキストウィンドウを消費するのは、ユーザーが今打った質問だけではありません。実際のAPIリクエストでは、（1）システムプロンプト（役割指示や出力形式の指定）、（2）これまでの会話履歴の全文、（3）RAGで検索してきた参照資料、（4）ツール定義（Function Callingのスキーマ）、そして（5）これから生成する出力の分まで、すべてが同じ枠を分け合います。チャットが「長く話していると昔の話を忘れる」のは、履歴が枠からあふれて古い発言が切り捨てられるためです。LLMは呼び出しのたびに毎回、履歴全体を最初から読み直しているのであって、会話を「記憶」しているわけではない — この点を押さえると、コンテキスト管理の必要性が腑に落ちます。

KVキャッシュ — 長さがそのままメモリコストになる

コンテキストウィンドウの実体的なコストを理解する鍵が「KVキャッシュ」です。Transformerは生成中、それまでに読んだ各トークンのKey/ValueベクトルをGPUメモリに保持し、新しいトークンを生成するたびに参照します。同じ計算を毎回やり直さないためのキャッシュですが、そのサイズは「トークン数 × レイヤ数 × 隠れ次元」に比例して線形に膨らみます。数十万トークンの文脈を保持すると、KVキャッシュだけでモデル本体の重みに匹敵する数十GBを占めることも珍しくありません。長いコンテキストの利用料金が高く、応答も遅くなるのはこのためで、量子化によるKVキャッシュの圧縮や、複数リクエストで共通するプロンプト前半部を再利用するプロンプトキャッシュといった最適化が、実運用ではコストを大きく左右します。

Lost in the Middle — 長ければ読めるとは限らない

上限が100万トークンあっても、その全域を等しく「読めている」わけではありません。研究では、長い文脈の冒頭と末尾に置かれた情報はよく参照される一方、中間に埋もれた情報の想起精度が大きく落ちる「lost in the middle」現象が報告されています。精度がU字カーブを描くこの性質は実務に直結します。重要な指示や判断材料は文脈の先頭か末尾に配置する、RAGでは検索結果の重要なものを端に寄せて並べる、といったプロンプトエンジニアリングの定石は、この現象への対策です。「とりあえず全部入れる」は、コストを増やしながら精度も下げる最悪手になり得ます。

長文化の歴史と設計への影響

上限の拡大は驚くほど速く進みました。2020年のGPT-3は2,048トークン、2023年のGPT-4は8K〜32K、同年のClaude 2で100K、2024年以降はClaude 3やGemini 1.5が20万〜100万トークン級に到達しています。数年で数百倍という拡大は、RoPE系の位置エンコーディングの外挿、FlashAttentionによるメモリ効率化、長文データでの継続学習といった技術の積み重ねの成果です。

この拡大は「巨大なウィンドウに資料を全部入れればRAGは不要になるのでは」という設計論争も生みました。実際には、コーパスがGB級になれば依然として全量は入らず、入るとしてもトークン課金と応答時間が跳ね上がるため、「検索で絞り込んでから文脈に入れる」RAGの価値はなくなっていません。むしろ実務の焦点は「どちらか」ではなく、限られた枠に何をどの順で載せるかという「コンテキストエンジニアリング」に移りつつあります。AIエージェントが長時間の作業でツール実行結果を溜め込みながら要約・取捨選択していくのも、この延長線上にある技術です。コンテキストウィンドウは、LLM時代の設計者にとってのメモリ設計 — 何を載せ、何を捨てるかという普遍的な資源管理の問題なのです。