![[AIコンテキスト #2] 長いコンテキストが回答を台無しにする理由のカバー画像](/assets/images/posts/2441c21a-97a2-413d-93be-21c88b2120cb/1.jpg)
第1回では、コンテキストウィンドウが有限である理由を見ました。ところが最近のモデル仕様を見ると、こんな疑問が浮かびます。すでに100万トークンのモデルがあるなら、コードベースでも文書でも丸ごと入れればいいのではないか。節約する意味はあるのか、と。
今回覆す通説はまさにこれです。コンテキストウィンドウに「入る」ことと、モデルがそれを「うまく使う」ことはまったく別の問題です。コンテキストが長くなるほどモデル性能が低下する現象は複数の研究で確認されており、エージェントを長時間動かした人なら誰もが実感しています。セッション後半になると回答が散漫になり、すでに直したバグをまた直そうとする、あの瞬間です。
lost in the middle：中央は読まれない
2023年にスタンフォードの研究者が発表した「Lost in the Middle」論文は、この分野で最も頻繁に引用される成果の一つです。長いコンテキストのさまざまな位置に正解文書を埋め込み、モデルがどれだけ見つけられるか測定したところ、正確度はU字曲線を描きました。先頭と末尾の情報はよく見つけますが、中央の情報は検索率が急落します。深刻な場合、正解を中央に置いたときの性能は、文書を与えずに質問した場合より低くなりました。
モデルが20個の文書を「すべて読む」のは事実です。ただし、注意を均等には配分しません。分厚い報告書の序論と結論に集中し、本論は目で流し読む人に似たパターンが、アテンションの重みにも現れます。
モデル発表資料によく登場する「干し草の山から針を探す（needle in a haystack）」テストのスコアは、この問題を隠しがちです。長いテキストに1文を埋め込み、そのまま見つけさせる単純な検索課題で、最新モデルの多くは満点に近い結果を出します。実務の作業は単純な検索ではありません。複数箇所の情報を結び付けて推論する課題にすると、同じモデルでもコンテキストが長いほどスコアが下がります。
context rot：長さそのものが性能を削る
2025年、ベクトルDB企業のChromaはこの現象を「context rot」と名付けた技術レポートを発表しました。主要18モデルを対象に、入力長だけを増やして同じ課題を行わせたところ、課題の難易度が同じでも、入力が長くなるだけで性能は一貫して低下しました。コンテキストウィンドウの仕様内であってもです。
原因はいくつか重なっています。まずアテンションの構造的な限界です。アテンションの重みは総量が決まった予算のようなもので、トークンが増えるほど1トークンに割り当てられる分が薄くなります。無関係な内容が多く混ざるほど、本当に重要なシグナルが埋もれるのです。次は学習分布の問題です。モデルが学習したテキストの大半は短い文書なので、数十万トークンの入力はモデルにとって訓練中ほとんど見ていない未知の状況です。仕様上は処理できても、その長さでの推論品質まで保証されるわけではありません。
そのため実務では「実効コンテキスト」という感覚が必要です。仕様が20万トークンでも、複雑な推論課題で品質が維持される範囲はそれよりはるかに短いと考えるのが安全です。仕様の数字は「ここまで入れてもエラーにならない」という意味であって、「ここまで入れても賢くいられる」という意味ではありません。
エージェントのコンテキストは長いだけでなく、散らかっている
エージェントでは問題がさらに深刻になります。第1回で見たように、エージェントのコンテキストにはツール呼び出しの結果が蓄積されますが、その蓄積物は長いだけでなく、互いに矛盾しているからです。
典型的なシナリオを見てみましょう。エージェントがバグを直すためにファイルを読み、修正し、もう一度読みます。するとコンテキストには同じファイルの修正前と修正後のバージョンが並びます。失敗したテストログと成功したテストログもあります。次の判断でどちらを参照するかは保証されません。古いバージョンを見て「まだバグがありますね」と言い、完了済みの修正を再開する行動は、ここから生じます。
こうした失敗パターンには名前があります。誤った情報（幻覚を含む要約など）がコンテキストに入り、その後の判断を連鎖的に汚染するのがcontext poisoning、蓄積した履歴が長すぎて新しい指示より過去のパターンの反復に引きずられるのがcontext distraction、似ているが異なる情報が混ざって混乱を招くのがcontext confusion、矛盾した情報が衝突するのがcontext clashです。名前を知らなくても症状には覚えがあるでしょう。セッション後半のエージェントが同じミスを繰り返し、するなと言われたことをする理由は、たいていこの4つのいずれかです。
品質低下に気づくサイン
長いセッションで次のサインが見えたら、コンテキストの問題を疑うべきです。
- 解決済みの問題を再び持ち出したり、同じファイルを何度も読んだりする
- セッション序盤に決めたルール（コーディング規約や触らないファイル）を破り始める
- 回答が冗長になり、直前の質問ではなく、かなり前の話題に引っ張られる
- 直前に伝えた情報を無視し、コンテキスト内の古い情報で回答する
重要なのは、モデルが「疲れている」わけではないという点です。モデルは毎ターン、最初から読み直すステートレスな機械です。変わったのはモデルではなく、読むべきコンテキストの状態です。長く、散らかっていて、矛盾したコンテキストが入力されるため、出力品質が低下します。
まとめ
- コンテキストに入っているからといって、うまく使われるわけではありません。中央の情報の検索率が下がるlost in the middleも、長さそのものが性能を削るcontext rotも、研究で確認された現象です。
- 仕様の数字は上限であって、品質の保証ではありません。複雑な推論が必要な作業ほど、実効コンテキストは仕様よりはるかに短いと考えるべきです。
- エージェントのコンテキストにはツール呼び出しの残骸が蓄積し、矛盾まで含まれます。poisoning・distraction・confusion・clashの4つの失敗パターンが、セッション後半の品質低下の主因です。
診断が終わったので、次回からは処方に入ります。まず基本ツールの/clearと/compactから始めます。どちらも「コンテキストを空にする」点は同じですが、動作原理はまったく異なり、誤って使うと作業の文脈まで消してしまいます。いつ消去し、いつ圧縮するのか、その基準を整理します。