コンテキストウィンドウとは、モデルが一度に「見る」ことができるトークン総量の上限です。プロンプト、会話履歴、検索で取得した資料、そしてモデル自身がすでに出力した返答まで、すべてが順番に一つの系列に並べられます。ウィンドウの大きさが決めるのはモデルの「作業台」の広さであり、賢さではありません。1Mトークンのウィンドウには千ページ超の文書が収まりますが、モデルがその全ページを本当に使いこなせるという意味ではないのです。
コンテキストウィンドウの中身は実際何なのか
ウィンドウに入っているのはファイルではなくトークンです。プロンプト、会話履歴、検索で拾った断片、ツールが返した結果は、すべてトークンに切り分けられ、順序どおりに一つの系列へ詰め込まれます。モデルは位置エンコーディングで前後関係を判別するだけで、「フォルダ」という概念は持ちません。1Mトークンは日本語に換算すると数十万字、千ページ超の文書に相当する分量です。ただしこれは「収まる」というだけで、「覚えている」という意味ではないことに注意してください。
注意機構に潜む請求書
モデルがこの系列を読み解く手段が自己注意機構（セルフアテンション）です。新しいトークンを一つ生成するたび、それ以前のすべてのトークンと一つずつ関連度を計算するため、計算量は系列長に対して二乗で増えます。長さが2倍になれば、アテンション部分の計算量は4倍になるのです。さらに大きな請求書がKVキャッシュです。推論時には各トークンのキー・バリューベクトルを再計算回避のためにGPUメモリに常駐させ続けなければなりません。Llama-3.1-8Bを例に取ると、1トークンあたり約128KBのキャッシュが必要で、128Kコンテキストなら約16GB、1Mトークンでは約128GBものVRAMを消費します。「ウィンドウを2倍に」は決して無料ではありません。VRAMを直接食いつぶし、最初のトークンが返るまでの応答を遅くし、長コンテキストAPIの課金を押し上げるのです。
収まるのに、なぜ見つけられないのか
請求書を払えることと、使いこなせることは別問題です。注意の重みはsoftmaxで正規化され、合計が常に1になります。トークンが増えるほど、一つひとつのトークンに行き渡る注意は薄く希釈されていきます。スタンフォード大学の2023年の実験「Lost in the Middle」はこれを鮮やかに示しました。肝心の情報をコンテキストの冒頭や末尾に置けば、モデルは速く正確に見つけ出します。しかし真ん中に隠すと、正解率は20ポイント以上も落ち、コンテキストを与えない場合より悪くなることさえあるのです。さらに大きな落差は評価方法に潜んでいます。「干し草の山から針を探す（needle-in-a-haystack）」テストは「一文を見つけられるか」しか問いませんが、これはほぼすべてのモデルが満点を取れます。一方、NVIDIAのRULERベンチマークがマルチホップ追跡や集計といった現実的なタスクに切り替えると、32K対応をうたうモデルのうち32Kの長さで合格水準を保てるのは半数だけでした。公称ウィンドウと実効ウィンドウの間には、しばしば数倍もの開きがあるのです。
広く流布している3つの誤解
誤解1：ウィンドウが大きいほど、モデルはよく覚える。 ウィンドウは作業台であり、ハードディスクではありません。ウィンドウを広げても、モデルパラメータ内の「長期知識」が増えるわけではなく、一度に広げられる資料が増えるだけです。会話が終わり、ウィンドウがクリアされれば、モデルは何も「覚えて」いません。会話をまたいだ長期記憶を担うのは、検索拡張生成のような外部記憶の仕組みです。
誤解2：長コンテキストがRAGを時代遅れにする。 知識ベース全体をウィンドウに流し込むのは高くつき、遅いのです。入力トークンは量に応じて課金され、超長コンテキストでは最初のトークンまでの遅延もVRAM消費も現実のコストになります。エンジニアリングの現場の主流はむしろ逆で、まずセマンティック検索で最も関連の高い数断片に絞り込み、それをウィンドウの中で精読します。複数の文書をまたいで答えをつなぎ合わせる必要がある問いには、GraphRAGのような構造化検索の手法もあります。長いウィンドウと検索はライバルではなく相棒なのです。
誤解3：トークン数＝有効な記憶。 公称1Mトークンのモデルでも、本当の推論が求められるタスクでは、実効的な長さが公称値の数分の一にとどまることがあります。「収まる」と「使いこなせる」は別物です。次にモデルカードの数字を見たら、もう一言問いかけてみてください。「私のタスクの長さでは、精度はどれだけ残るのか」と。
ウィンドウサイズの数字はどう読むべきか
まずタスクから見ます。数件の契約書を読む、コードリポジトリを分析するといった用途なら、数十K〜128Kで十分なことがほとんどです。全コーパスに対するQ&Aでは、ボトルネックはウィンドウの上限ではなく検索の質にあることが多いのです。次に実効性を見ます。RULERやLongBenchのような長コンテキストベンチマークで、目標の長さにおける実際の性能を確認しましょう。公称の最大値だけを見るのではありません。最後にコストを見ます。長コンテキストの入力トークンは単価が高く、KVキャッシュは同時実行数を制限します。ウィンドウは大きければいいのではなく、「足りる長さの範囲で、最も安定し、最もコストが低い」ものが正解です。
