- 最新の LLM では**入力トークン上限（コンテキストウィンドウ）**が数百万単位まで拡張されているが、単純な検索ベンチマーク（Needle in a Haystack, NIAH）で高得点を取れても、実際の長い入力での性能低下は明確に存在する
- 研究チームは18種類のモデルを対象にさまざまな実験を行い、入力長の増加だけを統制した状態でも性能低下と一貫しないパターンが繰り返し確認された
- 質問と答えの類似度低下、妨害文（ディストラクター）の追加、本文構造の変化に応じて、性能低下の速度が加速したり予測不能に変化したりする現象が目立った
- 構造的な文脈（論理的な段落の流れ）の維持がかえって性能に悪影響を与えるなど、入力の並べ方や構成方法が LLM の性能に大きく影響する
- 単純な反復テキストのコピーのような非常に簡単な作業でさえ、入力長が伸びるほど一貫した結果を出せない限界が明らかになり、実運用では文脈設計（コンテキストエンジニアリング）の重要性が強調される
研究の背景と目的
- 近年、LLM のコンテキストウィンドウが100万〜1000万トークンまで拡大し、長い入力でも「性能が保証される」という認識が広がっている
- Gemini 1.5 Pro、GPT-4.1、Llama 4 などが代表例
- 代表的なベンチマークであるNeedle in a Haystack (NIAH) は単純な文検索にすぎず、実際の長文文書要約や質疑応答など複合的な課題における性能低下を十分に反映できていない
- 本研究は、入力長のみを調整し、課題の難易度は固定する方式で性能変化を体系的に検証した
主な実験と結果
- **18種類の最新 LLM（Anthropic Claude、OpenAI GPT-4.1/4o/3.5、Gemini、Qwen など）**を対象に、計4種類の実験を設計:
- 質問と答え（Needle-Question）の意味類似度変化
- 妨害文（ディストラクター）の追加
- 本文（ヘイスタック）のテーマ・構造変化
- 反復単語コピー（出力長と入力長を同時に拡張）
- すべての実験で、入力長が長くなるほど性能は急激に低下し、とくに意味類似度が低い場合や妨害文が多い場合ほど低下幅が大きくなった
- 質問と答えの類似度が低いほど、長い入力で誤答率が急上昇した
- 妨害文を1つ追加しただけでも正答率は即座に下がり、4つ以上追加するとモデルごとに**混乱や幻覚（hallucination）**が大きく増加した
- 例: Claude 系列は誤答の代わりに「正答を見つけられない」と回避する傾向が強く、GPT 系列は自信のある誤答をより多く生成した
- **本文構造（論理的な流れ／ランダム配置）**によって性能が逆転する特異な現象も観察された
- 論理的な流れを保った元の本文（Original）では、むしろモデル性能がより悪化した
- 文がランダムにシャッフルされた本文（Shuffled）では、逆に検索性能が高くなった
- 反復単語コピー実験でも、入力・出力トークンが増えるほど誤答率、作業拒否、任意の単語生成など予測不能なパターンが増加した
- 例: 2,500〜5,000語以降、特定モデルでコピー拒否や任意テキスト生成などの異常な結果が急増
LongMemEval: 実戦的な長期対話評価
- 実際の会話記録を含む LongMemEval ベンチマークで、**集中入力（正答に関連する部分のみ含む）と全体入力（正答と無関係な文脈まで含む）**を比較
- すべてのモデルで集中入力のほうがはるかに高い正答率を示し、全体入力では関連内容を探すこと自体が追加課題として働き、性能が大きく低下した
- Claude 系列モデルは、とくに曖昧な状況で「正答なし」と回避する傾向が顕著だった
追加分析と示唆
- 妨害文ごとの混同率、回答位置の正確性、任意単語の生成位置など、モデルごとの内部動作パターンの違いを多様なグラフで精密に分析した
- 反復単語コピー実験では、正答単語が前方にあるほど精度が高いなど、位置依存の特性がある
- コンテキスト設計（情報の配置、論理的な流れの管理など）がモデル性能に与える影響は非常に大きく、実サービスへの適用時には単純なコンテキスト拡張だけでは一貫した性能を期待できないことを示唆する
結論
- LLM の長文入力処理能力はベンチマークの点数だけでは保証されず、実際には入力長の増加だけでも一貫しない性能低下が現れる
- 関連情報を単に含めるだけでは不十分であり、情報の配置・構造・妨害文・類似度などがすべて性能に決定的な影響を与える
- LLM 活用時には、**長文コンテキストの管理と設計（コンテキストエンジニアリング）**が不可欠である
2件のコメント
2.5が出てからかなり経っているのに、なぜ1.5なんだ
Hacker Newsの意見
私もこれにかなり近い経験がある。特にGemini Proを使うとき、長いテキストの参照を与えるなら、複数の文書を一度にコンテキストウィンドウへ入れるよりも、まず各文書を要約させてから質問し、必要なら詳細文書全体をRAGスタイルまたは簡単なエージェントループで渡したほうが、はるかに良い回答を得られた。同様に、Claude CodeをOpusやSonnetと一緒に使う場合も、コンパクション(compaction)が多く起こるほど結果が悪くなるのを実際に経験した。要約の質が落ちているからなのか、それともコンテキストウィンドウ内で関連性の低いデータの比率が高くなるからなのかははっきりしないが、コンテキストを空にして関連ファイルだけを読み直させると（以前の要約ですでに触れられていても）結果はずっと良かった
Geminiはチャットのコンテキスト上限に達する前から、すでに一貫性と推論力が崩れ始める。それでもこのレポートによれば多くの面で最良のモデルだ。結論として、コンテキストエンジニアリングは依然として重要で、RAGアプローチもなお有効だ
「コンパクション」とは結局、トランスクリプトを要約へ短縮することではないのか？ だとすれば、情報が実際に失われるのだから性能が落ちるのは当然だ。だがこれはコンテキストロット(context rot)のせいではない。本当のコンテキストロットの兆候は、オートコンパクト（自動圧縮）の閾値に近づいたときに現れる。私の理解は合っているだろうか？
理想的なコーディングエージェントなら、こうした過程を自動でやってくれそうだ。必要なコード、MCP応答、リポジトリマップなどを集め、ときどき要約し、それらすべてを新しいチャットメッセージにまとめて、本当に必要な部分だけを残すイメージだ。私はaiderというツールで、すでにこういうスタイルを使っているが、多くのコンテキストが必要な状況では、エージェント的または自動化されたワークフローよりずっと性能が良かった。ただし手間はかかる
NotebookLMを使ったことはある？ このアプリはバックグラウンドで文書を分割して要約してくれ、RAGを通じて文書全体にチャット形式で質問できる
Cursorで新機能やコード変更について長時間会話するほど、成果物が徐々に悪くなるのを経験している。最も良い結果が出たのは、明確で具体的な指示と計画を先に立て、修正するファイルをコンテキストプロンプトへ直接ドラッグしたときだった
「Explore → plan → code → test → commit」の流れで進めるほうが、はるかに役立った。必要なら各段階でコンテキストをクリアして効果を高められる
特定の作業に十分な情報が集まったら、その時点でコンテキストを保存する。品質低下が見えたら、ここまでの作業をもう一度要約して以前のチェックポイントに付け足す
この現象はよく知られているが、きちんと文書化された場所があまりないので、今回の記事はとてもありがたい。ベンチマークで簡単に測れないほど、実際の影響はもっと大きいと思う。本当に役に立つLLMベースのアプリは、モデルがこなせる限界点に張り付いている。つまり、実際の質問や作業で論理的に何度も「ジャンプ」しなければならないコンテキストをたどるときに意味がある。必要な論理的「ジャンプ」が増えるほど、コンテキストロットの問題は爆発的に悪化すると思う。各ジャンプごとに注意すべき対象が増えるからだ
コンテキストを簡単に切り落とす方法がぜひ必要だ。モデルと会話全体を自分で管理できれば、およそ20万トークンのコーディングセッションでも、もっと高いパフォーマンスを引き出せる気がする。だが現実には、良いインスタンスを使っていても2万トークンあたりを過ぎるとモデルがおかしくなり始め、セッションも完全にロットしてしまう。そこをそのまま切り捨てられたらいいのにと思う
ローカルLLMなら好きなようにコンテキストを編集できるので、LLMの応答そのものを修正しておけば、あとでモデルがそれを自分が元から言ったことだと思い込むこともある。だから望む方向へ誘導するのに有利だ。一方で、LLM-as-a-serviceのモデルはこうした機能を提供していない。検閲回避を容易にしてしまうからだ
「ねえClaude、これからコンテキストをリセットするから、今後も作業を続けられるようなプロンプトを1つ作って」と頼み、その後Claudeが提案したプロンプトを事前に確認して整えてから再投入する、という実験をしてみた
以前のチェックポイントへ簡単にロールバックできたら、本当に最高の機能になりそうだ
ほとんどのCLIエージェントでは、
/compressコマンドでこうした作業ができるClaude codeを使っていると、だんだん自分のミスと私の指示を区別できなくなってくる。混乱し始めたら、新しいセッションを開くのが正解だ。セッションが長くなるほど、同じループを回したり、自分でテストはもう壊れていると言い張って無視したりする（実際にはこのセッションで壊したのに）。私のプロンプトの入れ方が悪いのかもしれないが、最近のClaudeはいつの間にかIQが30くらい下がったように感じる
私もまったく同じ感覚だ。Maxプランでも、性能が良いときと悪いときがはっきりある
「自分のプロンプトやコンテキストが悪いんだろう」と考えてしまうのは、みんな内面化されたガスライティングを受けている感じがする
これは情報検索問題の一種ではあるが、コンテキスト長の変化による性能低下は、単純な検索回答とは違う働きをすることがあると思う。たとえば「このボタンを赤くするには？」のような質問や、「上の文はどのカテゴリに属するか？」のような問題では動きが異なるかもしれない。以前に印象的だった論文として Many-Shot In-Context Learning があった。この研究では、例示でコンテキストを埋めるほど性能が大きく向上する現象が示されている。結局のところ、問題ごとに実際に試してみないと、LLMがコンテキストの内容や長さによってどう変わるかは分からない。コンテキスト長が長くなれば必ず性能が下がる、と常に仮定してはいけない
lost-in-the-middle問題のように、例示の位置によって性能が変わることもあり得る内容がとてもクールで洞察に富んだ記事だ。ただ、メディアリテラシーの観点では、ChromaがベクターDB企業である点は知っておくとよい
最近Gemini 2.5 Flashで長編小説を何本か書いたが、コンテキストロットは確かに感じるものの、この記事で示されているよりずっと後になってから現れる。私の場合、5万〜10万トークンほど過ぎて初期コンテキスト（たとえば出力言語など）を無視し始めた。創作のような複雑なタスクは、効果の測定がより難しいか、あるいは目立ちにくいのかもしれない。いずれにせよ、ときどき抜けたコンテキストだけを再投入すれば、実用的な水準は保てる
私も似た経験がある。プロジェクトで動画トランスクリプトの検索機能を開発していたが、テキストが非常に長かった。GPT 4.1のようなモデルはコンテキストウィンドウが大きいのでRAGは不要だと思っていたのに、特に小型モデルで奇妙な現象がよく起きた。質問にきちんと答えず、ただコンテンツ全体の要約ばかり返すことがあった
興味深いレポートだ。モデルごとに推奨されるコンテキストサイズのようなものがあるのか気になる。自分のユースケースではどのあたりまでが適切なのか、見極める方法があるのか知りたい