目次

「さっき言ったことを覚えていない」「長い文書を読ませたら前半の内容を無視した」——LLMを使っていると、こうした「忘れ」に直面することがある。これはLLMのコンテキストウィンドウという仕組みに由来する、設計上の本質的な制約だ。

コンテキストウィンドウとは何か

コンテキストウィンドウとは、LLMが一度の処理で参照できるトークン数の上限を指す。

LLMは、テキストを「トークン」と呼ばれる単位に分解して処理する。英語では1単語がおおよそ1〜2トークン、日本語では1文字が1〜2トークンになることが多い。「1,000トークン」は日本語で大まかに500〜700文字程度に相当する。

コンテキストウィンドウは、このトークンをいくつまで同時に処理できるかの上限だ。最近のモデルでは数万トークンから百万トークン規模に達しているが、それでも上限はある。ウィンドウ内のすべてのトークンが処理対象であり、ウィンドウ外に出た情報は一切参照できなくなる。

なぜ制限が生まれるか——O(n²)の壁

コンテキストウィンドウに制限がある最大の理由は、Transformerアーキテクチャの計算コストにある。

Transformerのコアは「Self-Attention(自己注意機構)」だ。これは、入力されたすべてのトークンが互いにどの程度「関連するか」を計算する仕組みだ。たとえばnトークンの入力に対して、n×n通りの関係性を計算する必要がある。

これを計算量として表すとO(n²)(nの二乗に比例)になる。トークン数が2倍になれば計算量は4倍、10倍になれば100倍になる。この急激な増加が、コンテキストウィンドウ拡大の大きなボトルネックだ。

メモリについても同様だ。n²の注意行列をGPUのVRAMに保持する必要があり、長いコンテキストでは単純にメモリが不足する。百万トークン対応のモデルが登場し始めているが、推論コストも相応に跳ね上がる。

「ロスト・イン・ザ・ミドル」問題

コンテキストウィンドウ内に収まっていても、長い入力では別の問題が生じる。「ロスト・イン・ザ・ミドル(Lost in the Middle)」と呼ばれる現象だ。

研究によると、LLMは入力の冒頭末尾の情報を中間部分より有効に活用する傾向がある。つまり、長い文書の中央付近に重要な情報を置くと、それが「見落とされる」ことが起きやすい。

これはSelf-Attentionの学習パターンに起因する。訓練データの多くが冒頭・末尾に重要情報を配置する構造を持つため、モデルがその位置バイアスを学習してしまう。コンテキストウィンドウが拡大されても、この問題は完全には解消されていない。

ウィンドウを超えた情報の「消滅」

コンテキストウィンドウはスライディングウィンドウのように働く。会話が続くと古い発言がウィンドウから押し出される。LLMにとって、ウィンドウ外の情報は文字通り「存在しない」ものと同じだ。

ここで重要な誤解を解消しておきたい。LLMには会話の「記憶」を蓄積していく仕組みが、アーキテクチャの基本構造として存在しない。過去の会話を「覚えている」ように見えるのは、その会話履歴がコンテキストウィンドウ内にまだ含まれているからだ。ウィンドウから外れれば、それは消える。

人間の「ワーキングメモリ」の限界に似ているが、より絶対的だ。人間なら重要な情報は長期記憶に転送されるが、基本的なLLMにはそのような仕組みがない。

対策:RAGと外部メモリ

この制約に対応する代表的な手法がRAG(Retrieval-Augmented Generation)外部メモリだ。

RAGは「必要な情報だけを検索して、その都度コンテキストに注入する」仕組みだ。大量の文書をベクトルデータベースに保存しておき、ユーザーの質問に関連する部分だけを検索・取得して、LLMのプロンプトに組み込む。これにより、事実上のコンテキストを拡張できる。

外部メモリはより高度なアプローチだ。会話の要約を保存しておき、次のセッションで参照する手法、重要な事実をKey-Value形式で保存するメモリモジュール、エージェントアーキテクチャ上での情報の蓄積と検索などが含まれる。

これらはコンテキストウィンドウの制約を「解決」するのではなく、「回避」する工夫だ。根本的な制約はアーキテクチャレベルに存在し続ける。

実用上の注意点

コンテキストウィンドウの性質を理解した上で、実用的な使い方のポイントを整理する。

長い文書を扱う場合、重要な情報は冒頭か末尾に置く方が効果的だ。複数の会話を一つのセッションで続けると、初期の指示や文脈が失われる可能性がある。長い会話では、途中で「これまでの指示を再掲する」ことが品質維持に有効だ。

また、コンテキストウィンドウの数字(トークン数)は参考値として理解すべきだ。最大値まで使っても、ロスト・イン・ザ・ミドル問題により中間部の情報が軽視される可能性がある。技術仕様の最大値と、実効的な性能は異なる。


まとめ

コンテキストウィンドウはLLMの「作業机の広さ」に相当する。机に載せきれないものは処理できない、というシンプルな制約だ。

O(n²)の計算コストという根本的な制約により、この机を無限に広げることは現状では不可能だ。ロスト・イン・ザ・ミドル問題も加わり、長いコンテキストでは情報の扱いが不均一になる。

RAGや外部メモリで回避策は取れるが、コンテキストウィンドウの本質的な限界を理解した上で設計することが、LLMアプリケーション開発の基本となる。

免責事項 — 掲載情報は執筆時点のものです。料金・機能は変更される場合があります。最新情報は各公式サイトをご確認ください。