context-degradation

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

コンテキストの問題が連鎖する前に、診断して修正します。コンテキスト劣化は二分できるものではなく、連続的なものです。ロスト・イン・ザ・ミドル、ポイズニング、注意散漫、混乱、衝突という、予測可能な5つの異なるパターンとして現れます。各パターンには固有の検出シグナルと緩和策があります。劣化は予測不能な障害モードではなく、測定可能な閾値を用いて取り組むべきエンジニアリング上の問題として扱います。

有効化するタイミング

• 長い会話の途中で、エージェントの性能が予期せず低下する場合
• エージェントが不正確な出力や無関係な出力を生成するケースをデバッグする場合
• 大規模なコンテキストを確実に処理する必要があるシステムを設計する場合
• 本番システムにおけるコンテキストエンジニアリングの選択を評価する場合
• エージェントの出力で「ロスト・イン・ザ・ミドル」現象を調査する場合
• エージェントの振る舞いにおけるコンテキスト関連の障害を分析する場合

他のスキルが担当する関連作業では、このスキルを有効化しないでください。

• アクティブな障害がない状態で、コンテキストの基本的な仕組みを説明する場合：context-fundamentals。
• 障害パターンが判明した後に、トークン効率を高める手法を適用する場合：context-optimization。

核心となる概念

注意のU字カーブを基準にコンテキスト内の配置を構成します。長いコンテキストを扱う実験では、先頭と末尾の情報は安定して注意を向けられますが、中間の情報は想起精度が大幅に低下します（claim-context-degradation-lost-middle-ruler）。これはモデルのバグではなく、注意の仕組みによるものです。最初のトークン（多くの場合、BOS）は「注意シンク」として働き、不釣り合いに大きな注意の配分を吸収します。その結果、コンテキストが拡大するにつれて、中間のトークンへの注意が不足します。

コンテキストポイズニングは、サーキットブレーカーの問題として扱います。ハルシネーション、ツールのエラー、誤って取得された事実がいったんコンテキストに入ると、自己参照が繰り返されることで問題が増幅します。目標のセクションがポイズニングされると、それ以降のあらゆる判断が誤った前提を強化します。検出には主張の出所を追跡する必要があります。復旧するには、ポイズニングが起きる前までコンテキストを切り詰めるか、検証済みの情報だけを使ってやり直す必要があります。

コンテキストを読み込む前に、徹底的にフィルタリングします。無関係な文書が1件あるだけでも、関連タスクの性能が測定可能なほど低下します。モデルは無関係なコンテキストを「読み飛ばす」ことはできません。与えられたすべての情報に注意を向ける必要があるため、関連情報と無関係な情報の間で注意の競合が生じます。必要になる可能性はあるものの、今すぐ関連するわけではない情報は、事前に読み込まず、ツール呼び出しの後ろに回します。

タスクのコンテキストを分離して、混乱を防ぎます。コンテキストに複数のタスク種別が含まれていたり、目的が切り替わったりすると、モデルは別のタスクの制約を取り込んだり、異なるコンテキストに適したツールを呼び出したり、複数の情報源の要件を混ぜ合わせたりします。コンテキストウィンドウを分けてタスクを明確に区分すると、相互混入を防げます。

コンテキストの衝突は、情報を積み重ねるのではなく、優先順位ルールで解決します。コンテキスト内に複数の正しいものの互いに矛盾する情報源がある場合（バージョンの不一致、見解の相違、複数の情報源からの取得など）、モデルはどれを適用すべきか判断できません。矛盾を明示し、情報源の優先順位を定め、古いバージョンはコンテキストに入る前に除外します。

詳細トピック

ロスト・イン・ザ・ミドル：検出と配置戦略

重要な情報はコンテキストの先頭と末尾に置き、中間には置かないでください。注意のU字カーブにより、中間に配置された情報の想起精度は10～40％低下します。4Kトークンを超えるコンテキストでは、この影響が顕著になります。

注意を向けられやすい位置に重要な発見事項を提示する要約形式を使います。明示的なセクション見出しと構造マーカーを追加します。これらは注意のアンカーを作り、長いコンテキスト内でモデルが情報をたどるのに役立ちます。文書全体を含める必要がある場合は、要点の要約を先頭に置き、重要な結論を末尾に付け加えます。

ロスト・イン・ザ・ミドルの兆候を監視します。コンテキスト内に正しい情報があるのにモデルが無視する、回答が提供されたデータと矛盾する、または長いプロンプトの前半で指示された内容をモデルが「忘れる」といった症状です。

コンテキスト汚染：防止と復旧

外部入力がコンテキストに入る前に、すべて検証します。ツールの出力、取得したドキュメント、モデルが生成した要約は、主な汚染要因の3つです。それぞれが未検証の主張を持ち込み、後続の推論ではそれらが事実として扱われます。

次の兆候から汚染を検知します。これまで成功していたタスクでの出力品質の低下、ツールとの不整合（誤ったツールやパラメーターの使用）、明示的に訂正しても続く幻覚です。これらが重なった場合は、モデルの能力の問題ではなく、汚染を疑ってください。

復旧するには、訂正を追加するのではなく、汚染された内容を取り除きます。汚染が始まる前までコンテキストを切り詰める、検証済みの情報だけを保持したクリーンなコンテキストで再開する、または汚染されたセクションを明示して、最初から再評価するよう依頼します。汚染されたコンテキストに訂正を重ねても、ほとんど効果はありません。元の誤りには引き続き注意の重みが残るためです。

コンテキストの注意散漫：蓄積よりも厳選

モデルが無関係な内容を無視することに頼らず、コンテキストに入れる内容を厳選します。調査によると、注意をそらすドキュメントが1つあるだけでも、測定可能な性能低下が生じます。この影響は線形ではなく、階段関数に従います。注意をそらすドキュメントが複数あると、問題はさらに悪化します。

取得したドキュメントを読み込む前に、関連性でフィルタリングします。名前空間と構造化によってセクションの境界を明確にします。事前読み込みよりもツール呼び出しによるアクセスを優先します。参照資料は取得ツールの背後に保管し、現在の推論ステップに直接関係する場合にのみコンテキストに入るようにします。

コンテキストの混乱：タスクの分離

異なるタスクは別々のコンテキストウィンドウに分割します。コンテキストの混乱は注意散漫とは異なり、単に注意が分散することではなく、モデルが別のコンテキストの制約を現在のタスクに適用してしまうことです。クエリの誤った側面に答える、別のタスクに適したツールを呼び出す、複数のソースからの要件を混在させた出力を生成するといった兆候があります。

タスクのコンテキスト間に明確な切り替えを設けます。タスクごとに目的、制約、ツール定義を分離する状態管理を使用します。1つのセッション内でタスクの切り替えが避けられない場合は、現在のセグメントに適用される制約を示す明示的な「コンテキストリセット」マーカーを使用します。

コンテキストの衝突：競合解決プロトコル

競合が発生する前に、ソースの優先順位ルールを定めます。コンテキストの衝突は汚染とは異なります。複数の情報が個別には正しいものの、互いに矛盾する状態です（バージョンの競合、視点の違い、事実が異なる複数ソースからの取得など）。

古い情報がコンテキストに入る前に除外するバージョンフィルタリングを実施します。矛盾を避けられない場合は、構造化された競合注釈で明示します。何が矛盾しているか、各主張がどのソースに由来するか、どのソースを優先するかを記載します。明示的な優先順位ルールがなければ、モデルは予測不能な形で矛盾を解決します。

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

これらのベンチマークは、設計上の制約を定めるために使用してください。普遍的な真理として扱わないでください。RULER形式のエビデンスが示すように、長いコンテキストへの対応をうたっていても、その長さで十分なタスク性能が得られるとは限りません（claim-context-degradation-lost-middle-ruler）。ニードル・イン・ア・ヘイスタックのスコアがほぼ完璧でも、実環境での長文コンテキスト性能を予測することはできません。

モデル固有の劣化しきい値

劣化が始まるタイミングは、モデルのファミリーやタスクの種類によって大きく異なります。一般的な目安として、複雑な検索タスクでは、うたわれているコンテキストウィンドウの60～70％で劣化が始まると考えてください（RULERベンチマークでは、32K以上のコンテキストをうたうモデルのうち、その長さで十分な性能を維持できたのは50％にとどまりました）。主な傾向は次のとおりです。

• 拡張思考機能を備えたモデルは、段階的な検証によってハルシネーションを減らしますが、レイテンシーとトークンコストは増加します
• エージェントやコーディングに最適化されたモデルは、ツール出力の多いコンテキストをより適切に扱える傾向があります
• 非常に大きなコンテキストウィンドウ（1M以上）を持つモデルは、より多くの生のコンテキストを処理できますが、依然としてU字型の劣化曲線を示します。ウィンドウを大きくしても問題はなくならず、発生が遅れるだけです

公開されているベンチマークに頼らず、必ず自分のワークロードで劣化しきい値を測定してください。モデル固有のしきい値は、モデルが更新されるたびに古くなります（落とし穴2を参照）。

直感に反する調査結果

コンテキスト戦略を設計する際は、研究に裏付けられた次の意外な結果を考慮してください。

並べ替えられたコンテキストが、一貫性のあるコンテキストを上回ることがあります。 一部の検索タスクでは、論理的な順序で並べたものより、まとまりのない（シャッフルされた）ヘイスタックのほうが優れた結果を出すことが、研究で示されています（claim-context-degradation-distractor-shuffled）。一貫性のあるコンテキストは誤った関連付けを生み、検索を混乱させる可能性があります。一貫性のないコンテキストは、完全一致を促すことがあります。コンテキストを整理すれば常に結果が良くなると決めつけず、両方の配置を試してください。

単一の妨害情報が、予想以上に大きな影響を与えます。 無関係な文書を1件追加したときの性能低下は、最初の1件の後に妨害情報をさらに追加したときの低下に比べ、はるかに大きくなります。妨害情報の防止は二者択一として捉えてください。コンテキストをクリーンに保つか、大幅な性能低下を受け入れるかです。

ニードルと質問の類似性が低いと、劣化が早まります。 類似性の低い内容をまたいだ推論が必要なタスクは、表層的な類似性の高いタスクよりも、コンテキストが長くなるにつれて早く劣化します。クエリと検索された内容との意味的な重なりを最大化するように検索を設計してください。

大きなコンテキストが性能を損なう場合

コンテキストウィンドウを大きくすれば性能が向上すると決めつけないでください。性能はモデル固有のしきい値までは安定しますが、その後急速に劣化します。緩やかな下降ではなく、崖のような非線形の曲線です。多くのモデルでは、ウィンドウがはるかに大きなサイズに対応していても、8K～16Kトークンで顕著な劣化が始まります。

コストも考慮してください。400Kトークンのコンテキスト処理にかかる時間と計算量は、200Kの場合の2倍ではなく、指数関数的に増加します。多くのアプリケーションでは、大規模なコンテキスト処理は経済的に現実的ではありません。

認知的なボトルネックを認識してください。コンテキストが無限にあっても、単一のモデルに数十件の独立したタスクで品質を維持させると、コンテキストを増やしても解決できない劣化が生じます。コンテキストを拡張するのではなく、タスクをサブエージェントに分割してください。

実践的な指針

4つのバケットによる緩和フレームワーク

発生している劣化パターンに応じて、以下の4つの戦略を適用します。

書き込み — スクラッチパッド、ファイルシステム、外部ストレージを使って、コンテキストをウィンドウの外に保存します。コンテキスト使用率がウィンドウの70%を超えた場合に使用します。これにより、ツール呼び出しを通じて情報にアクセスできる状態を保ちながら、アクティブなコンテキストを小さく保てます。

選択 — 検索、フィルタリング、優先順位付けを通じて、関連するコンテキストだけをウィンドウに取り込みます。注意散漫や混乱の兆候が現れた場合に使用します。読み込む前に関連性をスコアリングし、利用可能な情報をすべて含めるのではなく、しきい値を下回るものは除外します。

圧縮 — 要約、抽象化、観察のマスキングによって、情報を保ちながらトークン数を削減します。コンテキストが増加しているものの、内容がすべて関連している場合に使用します。冗長なツール出力を簡潔で構造化された要約に置き換え、繰り返されるパターンを単一の参照情報に抽象化します。

分離 — サブエージェントまたはセッション間でコンテキストを分割し、単一のコンテキストが劣化のしきい値を超えて増大するのを防ぎます。混乱や衝突の兆候が現れた場合、またはタスクが独立している場合に使用します。これは最も積極的な戦略ですが、複雑なマルチタスクシステムでは最も効果的なことがよくあります。

回復力を高めるアーキテクチャパターン

ジャストインタイムのコンテキスト読み込みを実装します。情報は事前に取得するのではなく、現在の推論ステップで必要になったときにだけ取得します。観察のマスキングを使い、処理後に冗長なツール出力を簡潔な参照情報に置き換えます。各エージェントがタスクに関連するコンテキストだけを保持するサブエージェントアーキテクチャを導入します。症状が現れてからではなく、モデル固有の劣化開始しきい値を超える前に圧縮を実行します。

例

例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

例3：コンテキスト汚染のサーキットブレーカー

symptom: agent keeps citing an incorrect retrieved claim after correction
diagnosis: poisoned context, not a missing-instruction problem
action:
  1. identify first turn where the bad claim entered
  2. truncate or restart from before that point
  3. reload only verified sources
  4. record the rejected claim and source provenance

例4：コンテキスト衝突の注釈

conflict:
  topic: billing API version
  source_a: docs/v1.md says endpoint is /charges
  source_b: docs/v2.md says endpoint is /payments
  precedence: docs/v2.md
  reason: current production version

ガイドライン

1. 開発中はコンテキストの長さとパフォーマンスの相関を監視します
2. 重要な情報はコンテキストの先頭または末尾に配置します
3. 劣化が深刻になる前に圧縮を実行するトリガーを実装します
4. 取得したドキュメントをコンテキストに追加する前に、正確性を検証します
5. 古い情報による衝突を防ぐためにバージョン管理を使用します
6. 異なる目的間でコンテキストが混乱しないようにタスクを分割します
7. 完璧な条件を前提とせず、段階的に性能が低下する設計にします
8. 徐々に大きなコンテキストでテストし、劣化のしきい値を見つけます

注意点

1. 通常のばらつきが性能低下に見えることがあります：モデルの出力品質は実行ごとに自然に変動します。品質が一度低下しただけで性能低下と判断しないでください。複数回の実行でベースラインを確立し、コンテキストの増加に伴う持続的かつ相関のある低下を確認します。ある実行で品質が5～10％低下しても、それはノイズです。同じ低下が40Kトークン以降に一貫して現れるなら、それはシグナルです。

2. モデル固有のしきい値は古くなります：ベンチマーク表に示された性能低下の開始値は、特定のモデルバージョンを反映しています。プロバイダーの更新、ファインチューニングの変更、インフラの変化によって、しきい値は上下どちらにも20～50％移動することがあります。公表済みのしきい値を恒久的なものと見なさず、四半期ごとに、また主要なモデル更新のたびに再ベンチマークしてください。

3. ニードル・イン・ア・ヘイスタックのスコアは誤った安心感につながります：ニードル・イン・ア・ヘイスタックで99％を獲得したモデルでも、本番環境で128Kトークンを適切に処理できるとは限りません。ニードルテストが測定するのは受動的なコンテキストからの単一事実の検索です。実際のワークロードでは、コンテキストウィンドウ全体にわたる複数の事実の推論、指示への従属、統合が必要です。実際のワークロードのパターンを反映したタスク固有のベンチマークを使用してください。

4. 矛盾する取得ドキュメントは気づかれないまま悪影響を及ぼします：検索パイプラインが、ある事実について互いに矛盾する2つのドキュメントを取得した場合、モデルは矛盾を知らせずに一方を選ぶことがあります。これは正しい応答に見えますが、実質的にはランダムです。ドキュメントをコンテキストに含める前に、検索レイヤーで矛盾を検出する仕組みを実装してください。

5. プロンプト品質の問題が性能低下に見えることがあります：プロンプトの構成が不適切だと（指示が曖昧、制約が不足、タスクの説明が不明確など）、コンテキストの性能低下と同じ症状、つまり出力の一貫性のなさ、指示の無視、誤ったツールの使用が生じます。性能低下と判断する前に、コンテキスト長が短い場合に同じプロンプトが正しく機能することを確認してください。2Kトークンで失敗するなら、問題はコンテキストではなくプロンプトにあります。

6. 性能低下は非線形で、崖のような急落が起こります：性能は徐々に低下するのではなく、モデル固有のしきい値までは安定し、その後急激に低下します。「緩やかな性能低下」を想定して設計されたシステムは、監視チェックが線形の低下を前提としているため、このパターンを見逃しがちです。しきい値そのものではなく、それより十分手前（既知の開始値の70％）にコンパクションのトリガーを設定してください。

7. コンテキストを整理しすぎると逆効果になることがあります：直感的には、適切に構造化された一貫性のあるコンテキストは、整理されていない内容より優れているはずです。しかし研究によると、検索タスクでは、まとまりのあるコンテキストが誤った関連付けを生むため、並べ替えたヘイスタックのほうが性能で上回る場合があります。構造化を強めることで特定のタスクに本当に役立つかどうかをテストし、役立つと決めつけないでください。

統合

このスキルは、発生中のコンテキスト障害の診断と緩和を担当します。障害が特定された後の実装手法は、隣接するスキルが担当します。

• context-fundamentals：障害が発生する前に、アテンションとコンテキストウィンドウについて概念的に説明します。
• context-optimization：診断後に、マスキング、キャッシュ、パーティショニング、その他のトークン効率化の手法を扱います。
• multi-agent-patterns：混乱や衝突を防ぐため、タスクを個別のコンテキストに分離します。
• evaluation：性能低下のテストと本番環境の監視を扱います。

参考資料

内部資料：

• 劣化パターンのリファレンス - 読むタイミング：特定の劣化パターンをデバッグし、実装レベルの検出コード（注意分析、汚染の追跡、関連性スコアリング、復旧手順）が必要な場合

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

• context-fundamentals - 読むタイミング：コンテキストウィンドウ、トークン予算、配置の仕組みに関する基礎知識が不足している場合
• context-optimization - 読むタイミング：劣化を診断し、具体的な緩和手法（圧縮、要約、マスキング）が必要な場合
• evaluation - 読むタイミング：劣化がユーザーに影響する前に検出するため、本番環境のモニタリングを設定する場合

外部リソース：

• Liu ら、2023 年「Lost in the Middle」 - 読むタイミング：U 字型の注意に関する主張の根拠となる一次研究が必要な場合、または位置を考慮したコンテキストレイアウトを設計する場合
• RULER ベンチマークのドキュメント - 読むタイミング：長文コンテキストのサポートに関するモデルの主張を評価する場合、またはコンテキスト負荷の高いワークロード向けにモデルを比較する場合
• AI 研究機関による本番環境向けエンジニアリングガイド - 読むタイミング：本番環境のインフラストラクチャにコンテキスト管理を実装する場合