はじめに

「コンテキストウィンドウが大きいほど高性能」と思っていませんか？

実は、LLMに 情報を与えれば与えるほど、回答精度が下がる という逆説的な現象が起きることがあります。これが コンテキストロット（Context Rot） です。

本記事では、AIエージェント開発において避けて通れないこの問題について、原因から対策まで解説します。

コンテキストロットとは

コンテキストロットとは、LLMが処理する入力コンテキストが長くなるにつれて、パフォーマンスが劣化する現象です。

技術的な上限（例：100万トークン）の範囲内であっても、コンテキストウィンドウが埋まるにつれてLLMの性能は低下します。

Stanfordの研究では、わずか20件のドキュメント（約4,000トークン）を与えただけで、LLMの精度が 70-75%から55-60%に低下 したと報告されています。情報が間違っているわけでも欠けているわけでもなく、モデルが単に注意を払わなくなるのです。

なぜ起こるのか？

Transformerアーキテクチャの制約

現代のLLMはTransformerアーキテクチャに基づいており、すべてのトークンが他のすべてのトークンに対して注意（Attention）を向けます。

\text{計算量} = O(n^2)

つまり、トークン数に対して 二乗のオーダー で計算量が増加します。

トークン数	追跡すべき関係の数
10,000	1億
100,000	100億
1,000,000	1兆

コンテキストが長くなるほど、モデルはペアワイズの関係を捕捉する能力が希薄化し、重要な情報への注意が散漫になります。

Lost-in-the-Middle問題

研究者たちは 「Lost-in-the-Middle（中間で失われる）」問題 を発見しました。

モデルは、コンテキストウィンドウの 最初と最後 に置かれた情報には高い精度で応答しますが、中間に埋もれた情報 は見落としやすくなります。同じ情報でも、配置位置によって精度が大きく変わるのです。

AIエージェントにおける影響

エージェントシステムでは、コンテキストロットの影響が特に深刻です。

エージェントが複数のステップを経てタスクを実行すると、コンテキストウィンドウは累積的に成長し、「注意の希薄化」が起こります。重要な制約が埋もれ、ツール選択がドリフトし始めます。

実際に起こる問題

ツール選択のドリフト - 最初に与えられた指示を忘れ、不適切なツールを選択
制約の無視 - セキュリティ制約や出力形式の指定を見落とす
フォーカスの喪失 - 本来のタスクから逸脱した行動を取る

対策

1. JIT（Just-in-Time）検索

すべての情報を事前にロードするのではなく、必要な時に必要な情報だけを取得 する戦略です。

# ❌ Bad: すべての情報を事前にロード
context = load_all_documents()
response = llm.generate(context + query)

# ✅ Good: 必要な時に必要な情報だけを取得
def jit_retrieve(query):
    relevant_docs = vector_db.search(query, top_k=3)
    return llm.generate(relevant_docs + query)

Claude Codeもこの戦略を採用しており、情報が関連するときにのみ取得することで、モデルの推論空間をクリーンに保っています。

2. コンテキスト圧縮（Compaction）

冗長な情報を取り除き、参照だけを保持する方法です。

# ❌ Bad: ファイル内容をすべて履歴に保持
chat_history.append({
    "role": "assistant",
    "content": f"Created file with content:\n{file_content}"  # 500行のコード
})

# ✅ Good: パスのみを保持（可逆的）
chat_history.append({
    "role": "assistant", 
    "content": "Output saved to /src/main.py"
})

Compactionは 可逆的 です。後でコードを読む必要があれば、ツールを使ってファイルを読み取れます。

3. コンテキスト要約（Summarization）

一定のトークン数（例：128kトークン）に達したら、LLMを使って履歴を要約します。

def summarize_if_needed(context, threshold=128000):
    if count_tokens(context) > threshold:
        # 最新のツール呼び出しは詳細を保持
        recent = context[-5:]
        # 古い部分は要約
        old_summary = llm.summarize(context[:-5])
        return old_summary + recent
    return context

要約は 非可逆的（Lossy） です。重要な情報が失われる可能性があるため、最新のやり取りは生のまま保持することが推奨されます。

4. マルチエージェント構成

複雑なタスクを小さなサブタスクに分割し、専門のサブエージェントに処理させます。

各エージェントは クリーンなコンテキスト で動作し、必要な結果のみを親エージェントに返します。これにより、コンテキストの肥大化を防げます。

5. Pre-Rot Threshold の設定

コンテキストロットが発生する前に、積極的に対策を実行します。

# モデルの公称上限ではなく、実効的な上限を設定
PRE_ROT_THRESHOLD = 256_000  # 1Mウィンドウでも256k以下で管理

def process_with_context_management(context, query):
    if count_tokens(context) > PRE_ROT_THRESHOLD:
        context = compact_or_summarize(context)
    return llm.generate(context + query)

モデルが100万トークンのコンテキストウィンドウを持っていても、性能劣化は多くの場合256k以下で始まります。APIエラーを待つのではなく、事前に対策を打ちましょう。

まとめ

問題	対策
情報過多による注意散漫	JIT検索で必要最小限の情報だけを提供
履歴の肥大化	Compactionで参照のみ保持
長期タスクでの性能劣化	要約とPre-Rot Thresholdの設定
複雑なワークフロー	マルチエージェント構成で責務分離

コンテキストロットは、AIエージェント開発における「静かなる脅威」です。大きなコンテキストウィンドウを持つモデルでも、適切なコンテキストエンジニアリング なしには、その能力を十分に発揮できません。

「情報は多ければ多いほど良い」のではなく、「適切な情報を適切なタイミングで」 が、信頼性の高いAIエージェント構築の鍵です。

参考資料