Context Rot徹底解説 — なぜ長いコンテキストで性能が落ちるのか

Context Rotとは

Context Rot（コンテキスト腐敗）とは、LLMに渡す入力トークン数が増えるにつれて出力品質が劣化する現象です。Chroma社の研究チームが18のフロンティアモデルを対象に体系的に検証し、「すべてのモデルで性能が低下する」ことを実証しました。

重要なのは、コンテキストウィンドウが満杯に近づいたときだけでなく、容量に余裕がある段階でもトークンを追加するだけで性能が落ちるという点です。

Chroma研究の概要

実験設計

従来のベンチマークでは、長い入力ほどタスクの難易度も上がるため、「入力長の増加」と「タスクの複雑化」を分離できませんでした。Chroma研究はタスクの複雑さを一定に保ちながら、入力長のみを変化させる方法論で、この問題を解決しています。

テスト対象モデル（18モデル）

ファミリー	モデル
Claude	Opus 4、Sonnet 4、Haiku 3.5
GPT	GPT-4.1、GPT-4.1 mini、GPT-4.1 nano
Gemini	2.5 Pro、2.5 Flash
Qwen	Qwen3-235B、Qwen3-32B、Qwen3-8B

4つの実験

1. ニードル-質問類似度: 質問と回答の意味的類似度を変化させた場合の影響
2. ディストラクタの影響: 無関係な類似情報を混入させた場合の影響
3. ニードル-ヘイスタック類似度: 検索対象と周囲テキストの類似度の影響
4. ヘイスタック構造: テキストの論理的一貫性 vs シャッフルの影響

3つの劣化メカニズム

Context Rotは単一の原因ではなく、3つのメカニズムが複合的に作用して発生します。

1. Lost-in-the-Middle効果

LLMはコンテキストの冒頭と末尾に対する注意力が高く、中間部分への注意力が低下します。

注意力の分布イメージ:

高 ████                              ████
   ████                              ████
   ████                              ████
   ████  ██                      ██  ████
低 ████  ████  ██  ██  ██  ██  ████  ████
   ─────────────────────────────────────
   先頭    ← コンテキストの位置 →    末尾

重要な情報がコンテキストの中間に配置されると、モデルがそれを見落とす確率が高くなります。

2. アテンション希釈

Transformerの自己注意機構は、すべてのトークン間の関係を計算します。入力トークンが増えると、各トークンに割り当てられる「注意の割合」が薄まります。

トークン数  100: 各トークンへの平均注意 = 1/100 = 1.0%
トークン数 1000: 各トークンへの平均注意 = 1/1000 = 0.1%
トークン数 10000: 各トークンへの平均注意 = 1/10000 = 0.01%

実際にはアテンションは均等ではなく重要なトークンに集中しますが、全体的な希釈傾向は避けられません。

3. ディストラクタ干渉

意味的に類似しているが回答に無関係な情報（ディストラクタ）が、正しい情報の検索を妨害します。

Chroma研究では:

• ディストラクタ1個でも精度が低下
• ディストラクタ4個で劣化が大幅に加速

ディストラクタなし: "東京タワーの高さは333mです" → 正解率 95%
ディストラクタ1個:  + "スカイツリーの高さは634mです" → 正解率 85%
ディストラクタ4個:  + 類似の塔の情報4件追加 → 正解率 65%

モデル別の挙動パターン

Chroma研究で明らかになった各モデルファミリーの特徴的な振る舞いです。

Claudeファミリー

• 最も保守的な振る舞い: 不確実な場合は回答を控える（abstain）
• Opus 4の回答拒否率: 2.89%
• ハルシネーション率が最低
• ただし、フォーカスされた短いコンテキスト（約300トークン）とフルコンテキスト（約113Kトークン）の間で最大の性能差を示す

GPTファミリー

• ディストラクタ存在下で最もハルシネーション率が高い
• GPT-4.1の回答拒否率: 2.55%
• 回答を積極的に生成する傾向があるため、不正確な情報も出力しやすい

Geminiファミリー

• 500〜750トークン付近からランダムな単語を生成する挙動を示すケースあり
• 2.5 Proは最大の変動性（入力長による性能のばらつきが大きい）

Qwenファミリー

• タスク拒否率が最も高い（Qwen3-8Bで4.21%）
• 約5,000語付近からランダム出力が発生するケースあり

実用的なインパクト

LongMemEval実験の結果

集中的な短いプロンプト（約300トークン）とフルコンテキスト（約113Kトークン）を比較した実験で、すべてのモデルで顕著な性能ギャップが確認されました。

これは実運用のRAGシステムに直接的な示唆を与えます。検索した情報をすべてコンテキストに詰め込むよりも、本当に必要な情報だけを厳選して渡すほうが高精度になります。

ニードル-質問類似度の影響

質問と回答の意味的類似度が低いほど、入力長増加による性能劣化が急激になります。実際のユースケースでは質問と回答が完全一致することは稀であるため、Context Rotの影響は研究で示された以上に深刻である可能性があります。

対策と緩和戦略

1. コンテキストの情報密度を最大化する

# 悪い例: 検索結果をすべて投入
context = "\n".join(all_retrieved_chunks)  # 50チャンク = 25,000トークン

# 良い例: リランクして上位のみ投入
ranked = reranker.rank(query, all_retrieved_chunks)
context = "\n".join(ranked[:5])  # 5チャンク = 2,500トークン

2. 重要情報の配置を制御する

Lost-in-the-Middle効果を考慮し、最も重要な情報をコンテキストの先頭または末尾に配置します。

def arrange_context(
    system_prompt: str,
    critical_info: str,
    supporting_info: str,
    user_query: str
) -> str:
    """重要情報を先頭と末尾に配置"""
    return f"""{system_prompt}

{critical_info}

{supporting_info}

重要な前提（再掲）: {critical_info}

{user_query}"""

3. ディストラクタを除去する

セマンティック重複排除とリランキングで、関連度の低いチャンクを積極的に除外します。

4. コンテキストを分割する

大量の情報を1回で処理させるのではなく、Map-Reduceパターンで分割処理します。

Step 1: 各チャンクを個別に要約（Map）
Step 2: 要約を統合して最終回答を生成（Reduce）

5. 構造化テキストの活用

Chroma研究の意外な発見として、シャッフルされたコンテキストのほうが論理的に一貫したコンテキストよりも性能が高いケースがありました。これは、論理的な文章がディストラクタとして機能しうることを示唆しています。箇条書きや表形式など、意味的に独立したフォーマットが有効です。

実践ポイント

1. 「長いコンテキスト = 高性能」ではない: トークン数を減らすことが性能向上に直結する場合がある
2. リランキングは必須: Context Rotの最大の緩和策は、そもそも不要な情報を入れないこと
3. モデルの特性を理解する: Claudeは保守的（回答を控える）、GPTは積極的（ハルシネーションしやすい）
4. 情報の配置を設計する: 先頭と末尾に重要情報、中間にサポート情報
5. 定期的に検証する: Context Rotの影響はモデルアップデートで変化するため、継続的なベンチマークが必要

参考リンク

• Context Rot: How Increasing Input Tokens Impacts LLM Performance - Chroma Research
• GitHub: chroma-core/context-rot - 再現ツールキット
• Context Rot: Why LLMs Degrade as Context Grows - Morph
• Context rot: the emerging challenge that could hold back LLM progress