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

言語モデルは、コンテキスト長が増加するにつれて予測可能な劣化パターンを示します。これらのパターンを理解することは、障害を診断し、耐性のあるシステムを設計するために不可欠です。コンテキスト劣化は二値的な状態ではなく、複数の異なる方法で現れるパフォーマンス劣化の連続体です。

使用時機

以下の場合にこのスキルを有効化してください:

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

コア概念

コンテキスト劣化は複数の異なるパターンを通じて現れます。lost-in-middle現象により、コンテキストの中央に位置する情報の注目度が低下します。コンテキスト汚染は、繰り返された参照を通じてエラーが複合するときに発生します。コンテキスト散漫は、無関係な情報が関連内容に圧倒されるときに発生します。コンテキスト混乱は、モデルがどのコンテキストが適用されるかを判定できないときに生じます。コンテキスト衝突は、蓄積された情報が直接矛盾するときに発生します。

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

詳細トピック

Lost-in-Middle現象

最もよく文書化されている劣化パターンは「lost-in-middle」効果であり、モデルはU字型の注目曲線を示します。コンテキストの開始と終了に位置する情報は確実な注目を受けますが、中央に埋め込まれた情報は劇的に低下した想起精度に悩みます。

経験的証拠 研究では、コンテキストの中央に配置された関連情報が、開始または終了の同じ情報と比較して10～40%低い想起精度を示すことが実証されています。これはモデルの失敗ではなく、注目メカニズムとトレーニングデータ分布の結果です。

モデルは最初のトークン(多くの場合BOS トークン)への大量の注目を割り当てて、内部状態を安定化させます。これは注目バジェットを吸収する「注目シンク」を作成します。コンテキストが成長するにつれて、限定されたバジェットはより薄く伸ばされ、中央のトークンは確実な検索のための十分な注目重みを獲得できません。

実践的な含意 注目パターンを念頭に置いてコンテキスト配置を設計してください。重要な情報をコンテキストの開始または終了に配置してください。情報が直接照会されるか、推論をサポートする必要があるかを検討してください。後者の場合、配置はあまり重要ではありませんが、全体的なシグナル品質はより重要です。

長いドキュメントや会話については、重要な情報を注目が有利な位置に配置するサマリー構造を使用してください。明示的なセクションヘッダーと遷移を使用して、モデルが構造をナビゲートするのを支援してください。

コンテキスト汚染

コンテキスト汚染は、幻覚、エラー、または誤った情報がコンテキストに入り込み、繰り返された参照を通じて複合するときに発生します。汚染されると、コンテキストは誤った信念を強化するフィードバックループを作成します。

汚染の発生方法 汚染は通常3つの経路を通じて発生します。第一に、ツール出力はモデルが基本的事実として受け入れるエラーまたは予期しない形式を含むことができます。第二に、取得されたドキュメントはモデルが推論に組み込む誤った、または時代遅れの情報を含むことができます。第三に、モデルが生成したサマリーまたは中間出力は、コンテキストに残存する幻覚を導入する可能性があります。

複合効果は深刻です。エージェントの目標セクションが汚染されると、実質的な努力で元に戻すのに時間がかかる戦略が開発されます。その後のすべての決定は汚染されたコンテンツを参照し、誤った仮定を強化します。

検出と回復 症状に注意してください。以前成功したタスクの出力品質の低下、エージェントが間違ったツールまたはパラメータを呼び出すツール誤配置、および修正の試みにもかかわらず持続する幻覚が含まれます。これらの症状が現れたときは、コンテキスト汚染を検討してください。

回復には、汚染されたコンテンツの削除または交換が必要です。これには、汚染ポイント前のコンテキストへの切り詰め、コンテキスト内の汚染を明示的に記して再評価を求める、またはクリーンなコンテキストで再開して検証済みの情報のみを保持することが含まれるかもしれません。

コンテキスト散漫

コンテキスト散漫は、コンテキストが非常に長くなり、モデルが訓練知識を犠牲にして提供される情報に過度に焦点を当てるときに生じます。モデルは関連性に関係なくコンテキストのすべてに注目し、これは関連性がより高い場合でも提供された情報を使用する圧力を作成します。

気晴らし効果 研究は、コンテキスト内の単一の無関係なドキュメントでも、関連ドキュメントを含むタスクのパフォーマンスを低下させることを示しています。複数の気晴らしは劣化を複合します。効果は絶対的な意味でのノイズについてではなく、注目配置についてです。無関係な情報は限定された注目バジェットについて関連情報と競合します。

モデルは無関係なコンテキストを「スキップ」するメカニズムを持ちません。提供されるすべてに注目する必要があり、この義務は無関係な情報が明確に有用でない場合でも散漫を作成します。

軽減戦略 コンテキストに入る内容を慎重に選別することで散漫を軽減してください。取得されたドキュメントを読み込む前に関連性フィルタリングを適用してください。名前空間と組織を使用して、無関係なセクションを構造的に無視しやすくしてください。情報が本当にコンテキストにある必要があるか、代わりにツール呼び出しを通じてアクセスできるかを検討してください。

コンテキスト混乱

コンテキスト混乱は、無関係な情報が品質を低下させる方法で応答に影響を与えるときに生じます。これは散漫に関連していますが異なります。混乱は、注目配置ではなく、コンテキストがモデル動作に与える影響に関連しています。

コンテキストに何かを入れると、モデルはそれに注目する必要があります。モデルは無関係な情報を組み込む、不適切なツール定義を使用する、または異なるコンテキストから来た制約を適用する可能性があります。混乱は、特にコンテキストが複数のタスクタイプを含むとき、または単一セッション内でタスク間を切り替えるときに特に問題です。

混乱の兆候 クエリの間違った側面に対応する応答、別のタスク用に適切に見えるツール呼び出し、または複数のソースからの要件を混在させる出力に注意してください。これらはどのコンテキストが現在の状況に適用されるかについての混乱を示します。

アーキテクチャ上の解決策 アーキテクチャ上の解決策には、異なるタスクが異なるコンテキストウィンドウを取得する明示的なタスク分割、タスクコンテキスト間の明確な遷移、および異なる目的のコンテキストを分離する状態管理が含まれます。

コンテキスト衝突

コンテキスト衝突は、蓄積された情報が直接矛盾するときに発生し、推論を脱線させる矛盾した指導を作成します。これは1つの情報が誤っている汚染とは異なります。衝突では、複数の正しい情報が互いに矛盾します。

衝突の原因 衝突は、異なるソースが矛盾した情報を持つマルチソース検索、時代遅れと現在の情報の両方がコンテキストに現れるバージョン衝突、および異なるの視点が有効であるが互換性がない遠近法衝突から一般的に生じます。

解決アプローチ 解決アプローチには、矛盾を識別して明確化を要求する明示的な衝突マーク、どのソースが優先されるかを確立する優先ルール、および時代遅れの情報をコンテキストから除外するバージョンフィルタリングが含まれます。

実証的なベンチマークと閾値

研究は、設計上の決定を指示する劣化パターンに関する具体的なデータを提供しています。

RULERベンチマーク結果 RULERベンチマークは悲観的な結果を示します。32K+コンテキストを主張するモデルの50%のみが32Kトークンで満足のいくパフォーマンスを維持しています。GPT-5.2は現在のモデルの中で最も少ない劣化を示しており、多くはまだ拡張コンテキストで30ポイント以上低下します。単純なneedle-in-haystackテストの完璧に近いスコアは、実際の長コンテキスト理解に変換されません。

モデル固有の劣化閾値

モデル	劣化開始	深刻な劣化	注記
GPT-5.2	約64Kトークン	約200Kトークン	思考モード使用時の最高の全体的劣化耐性
Claude Opus 4.5	約100Kトークン	約180Kトークン	200Kコンテキストウィンドウ、強力な注目管理
Claude Sonnet 4.5	約80Kトークン	約150Kトークン	エージェントとコーディングタスク用に最適化
Gemini 3 Pro	約500Kトークン	約800Kトークン	1Mコンテキストウィンドウ、ネイティブマルチモーダル
Gemini 3 Flash	約300Kトークン	約600Kトークン	Gemini 2.5の3倍の速度、81.2% MMMU-Pro

モデル固有の動作パターン 異なるモデルはコンテキスト圧力下で異なる障害モードを示します:

• Claude 4.5シリーズ: 較正された不確実性による最も低い幻覚率。Claude Opus 4.5はSWE-bench Verifiedで80.9%を達成しています。ファブリケーションではなく、拒否または明確化を求める傾向があります。
• GPT-5.2: 利用可能な2つのモード - インスタント(高速)と思考(推論)。思考モードはステップバイステップ検証を通じて幻覚を削減しますが、レイテンシを増加させます。
• Gemini 3 Pro/Flash: 1Mコンテキストウィンドウを備えたネイティブマルチモーダル。Gemini 3 Flashは前世代よりも3倍の速度改善を提供しています。テキスト、コード、画像、オーディオ、ビデオ全体でマルチモーダル推論に強力です。

これらのパターンは異なるユースケースのモデル選択を指示します。高い利害関係があるタスクはClaude 4.5の保守的なアプローチまたはGPT-5.2の思考モードから利益を得ます。速度が重要なタスクはインスタントモードを使用する可能性があります。

直感に反する発見

研究は、コンテキスト管理に関する仮定に異議を唱えるいくつかの直感に反するパターンを明かします。

シャッフルされたヘイスタックは一貫性のあるものより優れている 研究では、シャッフルされた(不一貫な)ヘイスタックが論理的に一貫したものよりも良いパフォーマンスを生成することが発見されました。これは、一貫したコンテキストが検索を混乱させる虚偽の関連性を作成する可能性がある一方で、一貫性のないコンテキストはモデルを正確なマッチングに依存するよう強制することを示唆しています。

単一の気晴らしは過度な影響を持つ 単一の無関係なドキュメントでさえ、パフォーマンスを大幅に低下させます。効果はノイズの量に比例しませんが、気晴らしの存在がトリガーとなる段階関数に従います。

ニードル質問の類似性相関 ニードルと質問ペア間の低い類似性は、コンテキスト長でより速い劣化を示しています。異なるコンテンツにわたる推論が必要なタスクは特に脆弱です。

より大きいコンテキストが悪影響を与えるとき

より大きいコンテキストウィンドウはパフォーマンスを均一に改善しません。多くの場合、より大きいコンテキストは利益を上回る新しい問題を作成します。

パフォーマンス劣化曲線 モデルはコンテキスト長で非線形劣化を示します。パフォーマンスは閾値まで安定したままですが、その後急速に劣化します。閾値はモデルとタスク複雑性によって異なります。多くのモデルでは、コンテキストウィンドウがはるかに大きなサイズをサポートしている場合でも、8,000～16,000トークン付近で有意な劣化が始まります。

コスト含意 処理コストはコンテキスト長で不釣り合いに増加します。400Kトークンコンテキストを処理するコストは200Kのコストの2倍ではなく、時間とコンピューティングリソースの両方で指数関数的に増加します。多くのアプリケーションでは、これは大規模コンテキスト処理を経済的に不可能にします。

認知負荷のメタファー 無限のコンテキストであっても、単一のモデルに数十の独立したタスクの一貫した品質を維持するよう求めることは、認知的なボトルネックを作成します。モデルはアイテム間のコンテキストを絶えず切り替え、比較フレームワークを維持し、文体の一貫性を確保する必要があります。これはより多くのコンテキストが解決する問題ではありません。

実践的なガイダンス

4バケットアプローチ

4つの戦略は、コンテキスト劣化のさまざまな側面に対応しています。

書く: スクラッチパッド、ファイルシステム、または外部ストレージを使用して、ウィンドウ外でコンテキストを保存してください。これはアクティブなコンテキストを精選された状態に保ちながら、情報へのアクセスを保持します。

選択: 検索、フィルタリング、優先順位付けを通じて関連するコンテキストをウィンドウに取得してください。これは無関係な情報を除外することで散漫に対応します。

圧縮: 要約、抽象化、観察マスキングを通じて情報を保持しながらトークンを削減してください。これは有効なコンテキスト容量を拡張します。

分離: 異なるタスク用にサブエージェント間またはセッション間でコンテキストを分割して、単一のコンテキストが劣化するのに十分な大きさになるのを防いでください。これは最も攻撃的な戦略ですが、しばしば最も効果的です。

アーキテクチャパターン

特定のアーキテクチャパターンを通じてこれらの戦略を実装してください。ジャストインタイムコンテキスト読み込みを使用して、必要なときにのみ情報を検索してください。観察マスキングを使用して、冗長なツール出力をコンパクトな参照に置き換えてください。サブエージェントアーキテクチャを使用して、異なるタスク用のコンテキストを分離してください。圧縮を使用して、成長するコンテキストを制限を超える前に要約してください。

例

例1: 劣化の検出

# 長い会話中にコンテキストが成長
turn_1: 1000 tokens
turn_5: 8000 tokens
turn_10: 25000 tokens
turn_20: 60000 tokens (劣化が開始)
turn_30: 90000 tokens (大幅な劣化)

例2: Lost-in-Middle緩和

# 重要な情報をエッジに配置してコンテキストを整理

[CURRENT TASK]                      # 開始位置
- Goal: 四半期レポートを生成する
- Deadline: 週末

[DETAILED CONTEXT]                  # 中央(注目が少ない)
- 50ページのデータ
- 複数の分析セクション
- 支援証拠

[KEY FINDINGS]                     # 終了位置
- 売上が15%増加
- コストが8%削減
- 地域Aでの成長

ガイドライン

1. 開発中にコンテキスト長とパフォーマンスの相関を監視してください
2. 重要な情報をコンテキストの開始または終了に配置してください
3. 劣化が深刻になる前に圧縮トリガーを実装してください
4. 取得されたドキュメントを検証して、コンテキストに追加する前に正確性を確認してください
5. バージョン管理を使用して、時代遅れの情報が衝突を引き起こすのを防いでください
6. タスクを分割して、異なる目的全体でのコンテキスト混乱を防いでください
7. 完全な条件を仮定するのではなく、グレースフルな劣化の設計をしてください
8. 劣化閾値を見つけるために、徐々に大きいコンテキストでテストしてください

統合

このスキルはcontext-fundamentalsに基づいており、基本的なコンテキスト概念を理解した後に学習するべきです。接続先:

• context-optimization - 劣化を軽減するテクニック
• multi-agent-patterns - 分離を使用して劣化を防ぐ
• evaluation - 本番環境での劣化の測定と検出

参考資料

内部参照:

• Degradation Patterns Reference - 詳細な技術リファレンス

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

• context-fundamentals - コンテキスト基礎
• context-optimization - 軽減テクニック
• evaluation - 検出と測定

外部リソース:

• 注目メカニズムとコンテキストウィンドウ制限に関する研究
• 「lost-in-middle」現象に関する研究
• AIラボからの本番環境エンジニアリングガイド

---

スキルメタデータ

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

制限事項

• このスキルは、タスクが上記で説明されたスコープと明確に一致する場合にのみ使用してください。
• 出力を、環境固有の検証、テスト、または専門家による検討の代替物として扱わないでください。
• 必要な入力、権限、安全上の境界、または成功基準が不明な場合は停止して、明確にしてください。