context-degradation

コンテキスト劣化のパターン

言語モデルは、コンテキストが長くなるにつれて、予測可能な劣化パターンを示します。こうしたパターンを理解することは、障害の診断や、レジリエントなシステムの設計に不可欠です。コンテキストの劣化は二元的な状態ではなく、いくつかの異なる形で現れる性能低下の連続体です。

使用するタイミング

次のような場合に、このスキルを有効にします。

• 長い会話の途中でエージェントの性能が予期せず低下する場合
• エージェントが不正確または無関係な出力を生成する事例をデバッグする場合
• 大規模なコンテキストを確実に処理する必要があるシステムを設計する場合
• 本番システムにおけるコンテキストエンジニアリングの選択を評価する場合
• エージェントの出力で「途中の情報が失われる」現象を調査する場合
• エージェントの動作におけるコンテキスト関連の障害を分析する場合

基本概念

コンテキストの劣化には、いくつかの異なるパターンがあります。途中の情報が失われる現象では、コンテキスト中央の情報があまり注目されなくなります。コンテキスト汚染は、誤りが繰り返し参照されることで積み重なる現象です。コンテキスト散漫は、無関係な情報が関連情報を圧倒する状態です。コンテキスト混乱は、モデルがどのコンテキストを適用すべきか判断できない状態です。コンテキスト衝突は、蓄積された情報が直接矛盾するときに生じます。

これらのパターンは予測可能であり、圧縮、マスキング、分割、分離などのアーキテクチャパターンによって軽減できます。

詳細なトピック

途中の情報が失われる現象

最もよく記録されている劣化パターンは「途中の情報が失われる」現象です。評価対象のモデルでは、タスク性能がU字型の曲線を示すことがあります。コンテキストの最初と最後の情報には安定して注意が向けられますが、中央に埋もれた情報の想起精度は大幅に低下します。

実証的な証拠 『Lost in the Middle』の論文では、評価対象の検索／質問応答タスクにおいて、位置によって性能が変化することが報告されています。その程度はモデルやタスクによって異なり、一律に10～40％低下することや、単一の原因メカニズムを示すものではありません。

モデルは、内部状態を安定させるために最初のトークン（多くの場合BOSトークン）に膨大な注意を割り当てます。これにより、注意の「シンク」が生じ、注意の予算を消費します。コンテキストが長くなるにつれて限られた予算が分散し、中央のトークンに十分な注意の重みが割り当てられず、信頼性の高い検索が難しくなります。

実践的な影響 注意のパターンを踏まえて、コンテキスト内の情報の配置を設計してください。重要な情報はコンテキストの最初か最後に配置します。その情報が直接質問されるのか、それとも推論を支える必要があるのかを検討してください。後者の場合、配置の重要性は下がりますが、全体的なシグナル品質の重要性は高まります。

長い文書や会話では、注意されやすい位置に重要な情報を提示する要約構造を使用してください。モデルが構造をたどりやすくなるよう、明示的なセクション見出しやつなぎの表現を使用してください。

コンテキスト汚染

コンテキスト汚染は、幻覚、エラー、誤った情報がコンテキストに入り、繰り返し参照されることでさらに広がる現象です。いったん汚染されると、コンテキスト内に誤った信念を強化するフィードバックループが生じます。

汚染の発生経路 汚染は通常、3つの経路から発生します。1つ目は、ツールの出力に含まれるエラーや想定外の形式を、モデルが正しい情報として受け入れることです。2つ目は、取得したドキュメントに含まれる誤った情報や古い情報を、モデルが推論に取り込むことです。3つ目は、モデルが生成した要約や中間出力に幻覚が入り、それがコンテキストに残り続けることです。

汚染が積み重なる影響は深刻です。エージェントの目標セクションが汚染されると、元に戻すために多大な労力を要する戦略を立てるようになります。その後の判断のたびに汚染された内容が参照され、誤った前提が強化されます。

検出と復旧 以前は成功していたタスクの出力品質が低下する、エージェントが誤ったツールやパラメーターを使うなどツールとの不整合が起きる、修正を試みても幻覚が残り続ける、といった症状に注意してください。こうした症状が現れた場合は、コンテキスト汚染を疑ってください。

復旧には、汚染された内容の削除または置き換えが必要です。汚染が始まる前までコンテキストを切り詰める、コンテキスト内で汚染について明示して再評価を求める、または検証済みの情報だけを保持してクリーンなコンテキストから再開する、といった方法があります。

コンテキストによる注意散漫

コンテキストが長くなりすぎると、モデルが学習済みの知識よりも与えられた情報に過度に注目するようになり、コンテキストによる注意散漫が生じます。モデルは関連性にかかわらずコンテキスト内のすべてに注意を向けるため、内部知識のほうが正確な場合でも、与えられた情報を使おうとする圧力が生まれます。

注意散漫の影響 研究によると、コンテキスト内に関連性のないドキュメントが1つあるだけでも、関連するドキュメントを用いるタスクのパフォーマンスが低下します。注意をそらす情報が複数あると、性能の低下がさらに大きくなります。この影響は、絶対的な意味でのノイズの問題ではなく、注意の配分の問題です。関連性のない情報が、限られた注意の枠を関連情報と奪い合います。

関連性のないトークンは検索や推論を妨げることがありますが、その程度はアーキテクチャや推論の実装によって異なります。すべてのトークンに必ず均等に注意が配分されると推測しないでください。

軽減策 コンテキストに入れる情報を慎重に選別し、注意散漫を軽減してください。取得したドキュメントを読み込む前に、関連性によるフィルタリングを行います。名前空間や構成を活用して、関連性のないセクションを構造上無視しやすくします。情報を本当にコンテキストに含める必要があるのか、それともツール呼び出しでアクセスできるのかを検討してください。

コンテキストの混乱

コンテキストの混乱は、関連性のない情報が応答に影響し、品質を低下させることで生じます。注意散漫と関連していますが、別の問題です。混乱とは、注意の配分ではなく、コンテキストがモデルの振る舞いに与える影響を指します。

コンテキストに何かを入れると、モデルはそれに注意を向ける必要があります。モデルは関連性のない情報を取り込んだり、不適切なツール定義を使ったり、別のコンテキストに由来する制約を適用したりすることがあります。コンテキストに複数のタスク種別が含まれている場合や、1つのセッション内でタスクを切り替える場合は、特に混乱が問題になります。

混乱の兆候 質問の誤った側面に答える応答、別のタスクには適切に見えるツール呼び出し、複数の情報源からの要件が混在した出力に注意してください。これらは、現在の状況にどのコンテキストが適用されるのかについて混乱している兆候です。

アーキテクチャによる解決策 アーキテクチャによる解決策には、タスクごとに異なるコンテキストウィンドウを割り当てる明示的なタスク分割、タスク間の明確なコンテキスト切り替え、異なる目標のコンテキストを分離する状態管理があります。

コンテキストの衝突

蓄積された情報が直接矛盾し、相反する指針によって推論が妨げられると、コンテキストの衝突が発生します。これは、1つの情報が誤っているポイズニングとは異なります。衝突では、複数の正しい情報同士が矛盾します。

衝突の原因 衝突は、異なる情報源に矛盾する情報が含まれる複数情報源からの検索、古い情報と最新の情報がどちらもコンテキストに現れるバージョンの競合、異なる視点がそれぞれ妥当でありながら両立しない視点の競合などから、一般的に生じます。

解決方法 解決方法には、矛盾を特定して確認を求める明示的な競合のマーキング、どの情報源を優先するかを定める優先順位ルール、古い情報をコンテキストから除外するバージョンのフィルタリングなどがあります。

実証ベンチマークとしきい値

研究によって、設計上の判断に役立つ劣化パターンの具体的なデータが示されています。

RULER ベンチマークの調査結果 RULER ベンチマークは、厳しい調査結果を示しています。32K 以上のコンテキストに対応すると謳うモデルのうち、32K トークンで満足できる性能を維持するのはわずか 50％です。これは、論文で 2024 年に評価されたモデルとタスクの結果であり、現在のモデルの順位付けではありません。単純な干し草の山から針を探すテストでほぼ完璧なスコアを出しても、実際の長文コンテキスト理解に結び付くとは限りません。

運用中のモデルとワークロードを測定する 長文コンテキストの根拠として、出典のない普遍的なしきい値やベンダーのリーダーボードスコアを使用しないでください。プロンプト、モデルのスナップショット、デコード設定、正解データを固定したうえで、入力の長さ、関連する事実の位置、妨害情報の数、タスクの複雑さを変えて測定してください。正解率、拒否率／エラー率、レイテンシ、課金対象のトークン数を記録し、ばらつきを明らかにするのに十分な件数で繰り返してください。宣伝されているコンテキストの最大長ではなく、許容できるエラー予算に基づいて運用上限を選択してください。

直感に反する調査結果

研究によって、コンテキスト管理に関する想定を覆す、いくつかの直感に反するパターンが明らかになっています。

一貫性のない干し草の山のほうが、一貫性のあるものより優れた結果を出す 研究では、シャッフルされた（支離滅裂な）干し草の山のほうが、論理的に一貫したものより優れた結果を出すことが分かっています。これは、一貫性のあるコンテキストが誤った関連付けを生み、検索を混乱させる一方で、一貫性のないコンテキストではモデルが正確な照合に頼るためだと考えられます。

妨害情報が1つだけでも、影響は非常に大きい 無関係な文書が1つあるだけでも、性能は大幅に低下します。その影響はノイズの量に比例するのではなく、妨害情報が1つでも存在すると劣化が生じる階段関数に従います。

針と質問の類似度の相関 針と質問のペア間の類似度が低いほど、コンテキストの長さに伴う劣化が速くなります。類似性の低い内容を横断した推論が必要なタスクは、特に影響を受けやすくなります。

大きなコンテキストが逆効果になるとき

コンテキストウィンドウを大きくしても、性能が一様に向上するわけではありません。多くの場合、大きなコンテキストはメリットを上回る新たな問題を引き起こします。

性能劣化曲線 モデルの性能は、コンテキスト長に対して非線形に劣化します。あるしきい値までは性能が安定していますが、それを超えると急速に劣化します。このしきい値は、モデルやタスクの複雑さによって異なります。コンテキストウィンドウがはるかに大きなサイズに対応していても、多くのモデルでは8,000～16,000トークンあたりから顕著な劣化が始まります。

コストへの影響 処理コストは、コンテキスト長に応じて不均衡に増加します。標準的な密なアテンションでは、アテンション計算量は系列長に対して指数関数的ではなく二次関数的に増加します。エンドツーエンドのコストは、キャッシュ、アーキテクチャ、プロバイダーの料金設定によって異なります。400Kのリクエストの料金は、この計算量だけから推定することはできません。多くのアプリケーションでは、そのため大規模なコンテキスト処理は経済的に現実的ではありません。

認知負荷のたとえ コンテキストが無限にあったとしても、単一のモデルに数十の独立したタスクで一貫した品質を維持させることは、認知的なボトルネックを生み出します。モデルは項目間でコンテキストを絶えず切り替え、比較の枠組みを保ち、文体の一貫性を確保しなければなりません。これは、コンテキストを増やしても解決できない問題です。

実践的な指針

4つのアプローチ

4つの戦略で、コンテキスト劣化のさまざまな側面に対処できます。

書き出す：スクラッチパッド、ファイルシステム、外部ストレージを使って、コンテキストウィンドウの外に情報を保存します。これにより、情報へのアクセスを維持しながら、アクティブなコンテキストを簡潔に保てます。

選択する：検索、フィルタリング、優先順位付けによって、関連するコンテキストをウィンドウに取り込みます。関連性のない情報を除外することで、注意散漫に対処します。

圧縮する：要約、抽象化、観測結果のマスキングを通じて、情報を保ちながらトークン数を減らします。これにより、実効的なコンテキスト容量を拡大できます。

分離する：コンテキストが劣化するほど大きくならないよう、コンテキストをサブエージェントやセッションに分割します。これは最も強力な戦略ですが、多くの場合、最も効果的です。

アーキテクチャパターン

具体的なアーキテクチャパターンを通じて、これらの戦略を実装します。必要なときだけ情報を取得する、ジャストインタイムのコンテキスト読み込みを使用します。冗長なツール出力を簡潔な参照情報に置き換える、観測結果のマスキングを使用します。タスクごとにコンテキストを分離するため、サブエージェントアーキテクチャを使用します。コンテキストが上限を超える前に、増加したコンテキストを要約するコンパクションを使用します。

例

例1：劣化の検出

# Context grows during long conversation
turn_1: 1000 tokens
turn_5: 8000 tokens
turn_10: 25000 tokens
turn_20: 60000 tokens (degradation begins)
turn_30: 90000 tokens (significant degradation)

例2：Lost-in-Middleの緩和

# Organize context with critical info at edges

[CURRENT TASK]                      # At start
- Goal: Generate quarterly report
- Deadline: End of week

[DETAILED CONTEXT]                  # Middle (less attention)
- 50 pages of data
- Multiple analysis sections
- Supporting evidence

[KEY FINDINGS]                     # At end
- Revenue up 15%
- Costs down 8%
- Growth in Region A

ガイドライン

1. 開発中にコンテキスト長と性能の相関を監視する
2. 重要な情報はコンテキストの冒頭または末尾に配置する
3. 劣化が深刻になる前にコンパクションを開始する仕組みを実装する
4. 取得したドキュメントをコンテキストに追加する前に、正確性を検証する
5. 古い情報による衝突を防ぐため、バージョン管理を使用する
6. 異なる目標間でコンテキストが混乱しないよう、タスクを分割する
7. 完璧な条件を前提とせず、緩やかな性能劣化を想定して設計する
8. コンテキストを段階的に大きくしてテストし、劣化のしきい値を見つける

統合

このスキルはcontext-fundamentalsを基盤としており、基本的なコンテキストの概念を理解した後に学習してください。次の項目と関連しています。

• context-optimization - 劣化を緩和するテクニック
• multi-agent-patterns - 劣化を防ぐために分離を活用する方法
• evaluation - 本番環境で劣化を測定、検出する方法

参考資料

主な根拠：

• Lost in the Middle
• RULER

別個の内部向け「劣化パターンリファレンス」は含まれていません。

このコレクション内の関連スキル：

• context-fundamentals - コンテキストの基礎
• context-optimization - 緩和手法
• evaluation - 検出と測定

外部リソース：

• 注意機構とコンテキストウィンドウの制限に関する研究
• 「lost-in-middle」現象に関する研究
• AI 研究機関による本番環境エンジニアリングガイド

---

スキルのメタデータ

作成日：2025-12-20 最終更新日：2025-12-20 作成者：Agent Skills for Context Engineering Contributors バージョン：1.0.0

制限事項

• このスキルは、タスクが上記の説明範囲に明確に該当する場合にのみ使用してください。
• 出力を、環境固有の検証、テスト、専門家によるレビューの代わりとして扱わないでください。
• 必要な入力、権限、安全上の境界、成功基準が不足している場合は、作業を中止して確認を求めてください。