context-degradation

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

コンテキストの障害が連鎖する前に、原因を特定して修正します。コンテキストの劣化は二者択一ではなく、連続的に進行し、「中間部の情報喪失」「汚染」「注意散漫」「混乱」「衝突」という、予測可能な5つの異なるパターンとして現れます。それぞれのパターンには、固有の検出シグナルと緩和策があります。劣化は予測不能な障害モードではなく、測定可能な閾値を用いて対処するエンジニアリング上の問題として扱います。

使用するタイミング

次の場合に、このスキルを使用します。

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

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

• 進行中の障害を伴わずに、コンテキストの基礎的な仕組みを説明する場合：context-fundamentals。
• 障害パターンが判明した後に、トークン効率化の手法を適用する場合：context-optimization。
• 圧縮または引き継ぎ用の要約戦略を設計する場合：context-compression。
• 大規模な出力、ログ、一時的な状態をプロンプトの外部に保持する場合：filesystem-context。

核となる概念

コンテキストの配置は、注意のU字曲線に沿って構成します。長文コンテキストの実験では、冒頭と末尾は安定して注意が向けられる一方、中間部では想起の精度が大幅に低下します（claim-context-degradation-lost-middle-ruler）。これはモデルのバグではなく、注意の仕組みに起因します。最初のトークン（多くの場合はBOS）が「注意の吸い込み口」として働き、注意の予算を不均衡に吸収します。その結果、コンテキストが拡大するにつれて、中間部のトークンに向けられる注意が不足します。

コンテキスト汚染は、サーキットブレーカーの問題として扱います。幻覚、ツールエラー、誤って取得した事実がいったんコンテキストに入ると、自己参照が繰り返され、誤りが積み重なります。目標を記したセクションが汚染されると、その後のすべての判断が誤った前提を強化します。検出には主張の出所を追跡する必要があり、復旧するには汚染が始まる前まで切り詰めるか、検証済みの情報だけを含むコンテキストで再起動する必要があります。

コンテキストを読み込む前に、積極的にフィルタリングします。無関係なドキュメントが1つあるだけでも、関連タスクのパフォーマンスが測定可能なほど低下します。モデルは無関係なコンテキストを「読み飛ばす」ことができません。与えられたすべてに注意を向ける必要があるため、関連情報と無関係な情報の間で注意の取り合いが生じます。必要になる可能性はあっても、今すぐ関係しない情報は事前に読み込まず、ツール呼び出しの先に置きます。

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

コンテキストの衝突は、情報を積み重ねるのではなく、優先順位のルールによって解決します。コンテキストに、複数の正しいものの相互に矛盾する情報源（バージョンの競合、観点の競合、複数の情報源からの検索結果）が含まれると、モデルはどれを適用すべきか判断できません。矛盾を明示し、情報源の優先順位を定め、古いバージョンがコンテキストに入る前に除外します。

詳細なトピック

Lost-in-Middle：検出と配置戦略

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

注意が向きやすい位置に重要な知見を示す要約構造を使用してください。明示的なセクション見出しと構造マーカーを追加してください。これらは注意のアンカーを作り、モデルが長いコンテキストをたどりやすくします。ドキュメント全体を含める必要がある場合は、重要なポイントの要約を先頭に付け、重要な結論を末尾に追加してください。

Lost-in-Middleの兆候を監視してください。コンテキストに正しい情報があるのにモデルが無視する、回答が提示されたデータと矛盾する、長いプロンプトの早い段階で示した指示をモデルが「忘れる」といった症状です。

Context Poisoning：予防と回復

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

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

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

Context Distraction：蓄積ではなく選別

モデルが無関係な内容を無視することに頼るのではなく、コンテキストに入れる情報を選別してください。研究によると、妨げとなるドキュメントが1つあるだけでも、測定可能な性能低下が生じます。この影響は線形ではなく、段階的に増加します。妨げとなるドキュメントが複数あると、問題はさらに深刻になります。

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

Context Confusion：タスクの分離

異なるタスクは、別々のコンテキストウィンドウに分けてください。Context ConfusionはDistractionとは異なります。これは、単に注意が分散することではなく、モデルが現在のタスクに誤ったコンテキストの制約を適用する問題です。兆候として、クエリの誤った側面に回答する、別のタスクに適したツールを呼び出す、複数の情報源の要件が混在した出力を生成するといった症状があります。

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

Context Clash：競合解決プロトコル

競合が発生する前に、情報源の優先順位ルールを確立してください。Context ClashはPoisoningとは異なります。複数の情報が個別には正しいものの、相互に矛盾する状態を指します（バージョンの競合、視点の違い、異なる事実を含む複数情報源からの取得など）。

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

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

これらのベンチマークは、設計上の制約を定めるために使用してください。普遍的な真理として扱わないでください。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. 通常のばらつきが性能低下のように見えることがあります：モデルの出力品質は実行ごとに自然に変動します。品質が一度低下しただけで性能低下と診断しないでください。複数回の実行でベースラインを確立し、コンテキストの増加に関連した継続的な低下があるかを確認します。1回の実行で品質が5〜10％低下するのはノイズですが、40Kトークンを超えた後に同じ低下が一貫して現れるなら、それはシグナルです。

2. モデル固有のしきい値は古くなります：ベンチマーク表に記載された性能低下の開始値は、特定のモデルバージョンを反映したものです。プロバイダーの更新、ファインチューニングの変更、インフラの変化により、しきい値はどちらの方向にも20〜50％変動することがあります。公開されたしきい値を恒久的なものとして扱うのではなく、四半期ごと、および大規模なモデル更新のたびに再ベンチマークしてください。

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

4. 矛盾する検索ドキュメントは、気付かれないまま悪影響を及ぼします：RAG パイプラインが、ある事実について意見の異なる2つのドキュメントを検索すると、モデルは矛盾を示さずに一方を選ぶことがあります。これは正しい回答に見えますが、実質的にはランダムです。ドキュメントがコンテキストに入る前に、検索レイヤーで矛盾の検出を実装してください。

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

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

7. コンテキストを過度に整理すると逆効果になることがあります：直感的には、適切に構造化された一貫性のあるコンテキストは、整理されていない内容より優れているはずです。しかし研究によると、検索タスクでは、まとまりのあるコンテキストが誤った関連付けを生むため、シャッフルされたヘイスタックのほうが優れた結果を示すこともあります。構造化を多用した形式が特定のタスクに本当に役立つかをテストしてください。役立つと決めつけないでください。

統合

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

• context-fundamentals：障害が発生する前に、アテンションとコンテキストウィンドウについて概念的に説明します。
• context-optimization：診断後に、マスキング、キャッシュ、分割、その他のトークン効率化手法を扱います。
• context-compression：蓄積されたコンテキストをコンパクトにする必要がある場合に、構造化された要約と引き継ぎを扱います。
• filesystem-context：生の出力、ログ、スクラッチ状態を外部に退避し、汚染されたコンテキストや肥大化したコンテキストをプロンプト内に残さずに調査できるようにします。
• multi-agent-patterns：タスクを別々のコンテキストに分離し、混乱や衝突を防ぎます。
• evaluation：性能低下テストと本番環境の監視を扱います。

参考資料

内部資料：

• 劣化パターンのリファレンス - 次の場合に読みます：特定の劣化パターンをデバッグし、実装レベルの検出コード（アテンション分析、ポイズニングの追跡、関連性スコアリング、復旧手順）が必要な場合

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

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

外部リソース：

• Liu et al., 2023「Lost in the Middle」 - 次の場合に読みます：U 字型アテンションに関する主張を裏付ける一次研究が必要な場合、または位置を考慮したコンテキストレイアウトを設計する場合
• RULER ベンチマークのドキュメント - 次の場合に読みます：長いコンテキストへの対応に関するモデルの主張を評価する場合、またはコンテキスト負荷の高いワークロード向けにモデルを比較する場合
• AI 研究機関による本番環境向けエンジニアリングガイド - 次の場合に読みます：本番環境のインフラストラクチャでコンテキスト管理を実装する場合

---

スキルのメタデータ

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