「100万トークンのコンテキストウィンドウ」という宣伝文句に惹かれて、有料プランに加入した人は多いでしょう。
しかし、実際に使ってみると長い会話の途中でAIが以前の内容を忘れてしまう。
そんな経験をした人は少なくありません。
海外のRedditでは、この問題に関する興味深い議論が展開されていました。
本記事では、その議論を参考にしながらLLMのコンテキストウィンドウについて解説します。
コンテキストウィンドウとは何か
LLM（大規模言語モデル）には「コンテキストウィンドウ」と呼ばれる概念があります。
簡単に言えば、AIが一度に処理できる情報量の上限です。
この情報量はトークンという単位で測定されます。
日本語の場合、1文字が1〜2トークン程度に相当します。
つまり、10万トークンのコンテキストウィンドウがあれば、およそ5万〜10万文字程度の情報を保持できる計算です。
各社のLLMは、このコンテキストウィンドウの大きさを競うように発表しています。
100万トークン、200万トークンといった数字が飛び交う状況です。
宣伝値と実効値のギャップ
ところが、海外のユーザーコミュニティでは興味深い報告が相次いでいます。
宣伝されているコンテキストウィンドウの数値と、実際に使用できる「ホットメモリ」の数値に大きな差があるというのです。
あるユーザーは次のような報告をしました。
有料版で約32,768トークン（2の15乗）を超えた時点から、AIの応答品質が急激に低下すると。
具体的には、同じ内容を繰り返し説明したり、以前の会話内容を参照できなくなったりする現象が発生するそうです。
別のユーザーからは、こんな報告もありました。
「Deep Research」のような特定のモードでは良好なパフォーマンスを維持できる。
しかし、通常の会話では早い段階で「記憶喪失」が起きる、と。
WebアプリとAPIの違い
この問題を理解するうえで重要なのは、WebアプリとAPIの違いです。
技術に詳しいユーザーからは、次のような指摘がありました。
Google AI Studioでフル機能のコンテキストウィンドウを使えるAPIは正常に動作する。 もし悪意ある制限であれば、APIでも同様の問題が起きるはず
つまり、Webアプリ版で経験する制限は、モデル自体の問題ではないかもしれません。
サービス提供側の最適化によるものである可能性があります。
Webアプリでは、応答速度を高速に保ちサーバーコストを抑える必要があります。
そのため、直近の約32,000トークン程度を「ホットキャッシュ」に保持している可能性があります。
それより古い情報は、別の方法で管理しているのでしょう。
問題は、この古い情報を適切に取得できない場合があることです。
RAG（検索拡張生成）の限界
コンテキストウィンドウの制限を補う技術として、RAG（Retrieval-Augmented Generation）があります。
全ての会話履歴をメモリに保持するのではなく、必要に応じて過去の情報を検索・取得する仕組みです。
理論上、この方式であれば膨大な量の情報を扱えるはずです。
実際、「100万トークン対応」という宣伝の多くは、このRAG技術を前提としています。
しかし、現実は複雑です。
「RAGは動作するときは動作する。しかし、大半の場合は正しく機能しない」というユーザーの声もありました。
検索の精度や、関連情報の取得タイミングに課題があるようです。
推論トラップとシコファンシー問題
コンテキストウィンドウとは別に、LLMの振る舞いに影響を与える要因も指摘されていました。
「推論トラップ」と「シコファンシー（追従性）」の問題です。
推論トラップとは、LLMが不明確な質問に対して確認を求めず、自分で補完してしまう傾向のことです。
「役に立つ」ことを優先するあまり、曖昧さを無視して回答を生成してしまいます。
シコファンシーは、RLHF（人間のフィードバックからの強化学習）によってAIが過度に従順になる現象です。
「わからない」と答えることが「不親切」と判断されてしまう。
だからAIは、無理にでも回答を生成しようとします。
これらの問題は、文脈が失われたときに特に顕著になります。
AIが以前の会話内容を正確に把握できていない。
それでも認めずに推測で回答してしまうためです。
ユーザーができる対策
現状では、ユーザー側でいくつかの対策を講じることが有効です。
まず、一つの会話を長く続けない方法があります。
トピックごとにチャットを分割しましょう。
コンテキストウィンドウの制限に達する前に新しいセッションを開始すれば、品質の低下を避けられます。
重要な情報を明示的に繰り返すことも効果的です。
AIに覚えておいてほしい前提条件や制約は、適宜リマインドしましょう。
API経由での利用を検討するのも一つの選択肢です。
Webアプリ版よりも安定したパフォーマンスを得られる場合があります。
ただし、技術的な知識が必要です。
サービス提供側への期待
最終的には、サービス提供側の改善が必要です。
宣伝値と実効値に乖離があるなら、その点を明確に説明すべきでしょう。
例えば「最大100万トークン対応（ホットメモリは32,000トークン、それ以外はRAGで検索）」のような表記であれば、ユーザーは適切な期待を持てます。
また、RAGの精度向上も重要な課題です。
コンテキストウィンドウからオフロードされた情報を、必要なときに正確に取得できる仕組み。
その改善が求められます。
まとめ
LLMのコンテキストウィンドウは、宣伝されている数値がそのまま「常に利用可能なメモリ」を意味するわけではありません。
WebアプリとAPIの違い、ホットキャッシュの制限、RAGの精度など、複数の要因が実際のユーザー体験に影響を与えています。
このような技術的背景を理解しておくと、AIツールをより効果的に活用できます。
長い会話で「AIが急に記憶喪失になった」と感じたら、それはバグではないかもしれません。
システムの設計上の制約である可能性があります。
AIサービスを評価する際は、宣伝文句だけでなく実際のユースケースでのパフォーマンスを確認しましょう。
各サービスの公式ドキュメントやユーザーコミュニティの情報を参考にすると、より実態に近い判断ができます。
LLM技術は日々進歩しています。
コンテキストウィンドウの実効的な拡大も、今後改善されていく領域の一つでしょう。
現時点での制約を理解しつつ、技術の発展に期待しましょう。
