AIエージェントに長い作業を任せていると、最初は的確だった返答が途中から的外れになったり、同じ指示を繰り返す羽目になったりすることがある。原因の多くは「コンテキスト・ロット(context rot)」と呼ばれる現象だ。本記事では、その正体と、業務でAIを使い倒すチームが実践している具体的な対策を、社内ナレッジベース(RAG)にありがちな「情報の腐敗」も含めて整理する。
「さっきの指示、もう忘れてる」の正体
チャットやClaude Codeのようなコーディングエージェントを長時間使っていると、序盤で伝えた設計方針を後半で無視されたり、同じ確認を何度もされたりする経験がある人は多いはずだ。これは単なる「AIの気まぐれ」ではなく、コンテキストウィンドウが埋まっていくにつれて応答の質が落ちる、構造的な現象として説明できる。
研究コミュニティではこれを「コンテキスト・ロット」と呼ぶ。会話やタスクの履歴が長くなるほど、重要な情報が大量のトークンの中に埋もれてしまい、モデルがそれを適切に参照できなくなる現象だ。ウィンドウの上限に達する前、上限の30〜50%程度を使った時点ですでに劣化が始まるという報告もある。
Lost in the Middle：真ん中の情報はなぜ無視されるのか
この問題の土台になっているのが、2023年に発表された“Lost in the Middle”という研究だ。関連する情報が入力の冒頭か末尾にあるときは正答率が高い一方、真ん中に置かれると正答率が30%以上落ちる、という現象が複数のモデルで再現されている。原因はアーキテクチャ側の性質(位置エンコーディングの減衰やsoftmaxによる注意の偏り)にあり、モデルの規模や賢さだけでは解決しない。
つまり「コンテキストウィンドウが100万トークンあるから安心」ではない。ウィンドウが大きいほど劣化が始まる位置が後ろにずれるだけで、途中で重要な指示や仕様が埋もれるリスクそのものは消えない、という点は覚えておきたい。
コンテキストエンジニアリングの4原則
LangChainが整理した「Write / Select / Compress / Isolate」という4つの戦略は、特定のフレームワークに依存せず、Claude Agent SDKのような他のエージェント基盤にもそのまま応用できる考え方として広く参照されている。
| 原則 | やること | 業務での具体例 |
|---|---|---|
| Write(書き出す) | 会話に留めず外部に永続化する | 作業計画やTODOをファイルやチケットに書き出し、セッションが切れても参照できるようにする |
| Select(選び取る) | 必要な情報だけをその都度取り込む | 全文を貼らず、関連ファイルやドキュメントを都度検索・読み込みさせる(RAGもここに含まれる) |
| Compress(圧縮する) | 今後も必要なトークンだけ残す | 長くなった会話やログを要約し直してから作業を再開する |
| Isolate(分離する) | サブタスクごとにコンテキストを分ける | 調査・実装・レビューを別々のエージェント(サブエージェント)に担当させ、結果の要約だけを本流に戻す |
共通するのは「コンテキストウィンドウは容量無限の保存庫ではなく、都度入れ替える作業机」という発想だ。机の上に資料を積み上げ続けるのではなく、必要な資料だけを都度出し入れし、終わったものはファイルに戻す——という感覚に近い。
Claude Codeの現場運用：CLAUDE.mdとセッションの区切り方
Claude Codeの公式ベストプラクティスでも、この4原則に沿った運用が推奨されている。
- CLAUDE.mdは「全部乗せ」にしない——リポジトリの前提や実行コマンドなど、毎回必要になる情報だけを短い箇条書きで書く。100〜150項目程度を目安に、細かい知識はSkillやドキュメントへのリンクに逃がす。
- キリのいいところでセッションを切る——1つの論理的な作業単位が終わったら、要点を短くまとめてから新しいセッションを始める。長い会話を漫然と続けるより、コンテキストが「新しく空いた机」に近い状態を保てる。
- サブエージェントに調査を切り出す——大量のログやコードを読ませる調査は、本流の会話とは別のサブエージェントに任せ、要約だけを受け取る。本流のコンテキストを汚さない。
- 大きなファイルをチャットに貼らない——ツールにファイルを読ませ、必要な部分だけを引用させる。全文貼り付けはコンテキストを一気に消費し、劣化を早める。
もう一つの落とし穴：社内ナレッジベース(RAG)の「情報腐敗」
コンテキスト・ロットは1回のセッション内の話だが、もっと長いスパンで同じ問題が起きるのが社内向けのRAG(検索拡張生成)チャットボットだ。海外の解説記事では、企業のRAG導入プロジェクトの7〜8割が本番運用にたどり着かないと指摘されている。原因の多くはモデルの性能ではなく、参照させているドキュメント側の「衛生状態」にある。
- 同じ規程やマニュアルがSharePointやメール添付、ローカルフォルダに複数バージョン残っており、検索エンジンは「意味的に近い」版を拾うだけで「最新」の版とは限らない。
- 更新した規程を再インデックスし忘れ、チャットボットが古い情報を答え続けても、参照元の鮮度を追跡していなければ誰も気づかない。
- 重複ドキュメントや不統一なメタデータが検索スコアを歪め、関連度の高い情報が埋もれる。
別の分析記事も、モデル選びやプロンプトの工夫より前に、ドキュメントの整理・重複排除・鮮度管理を「ステップ0」として扱うべきだと強調している。
RAG運用チェック表
| 症状 | よくある原因 | 対策 |
|---|---|---|
| 古い規程・古い仕様を答える | 更新後の再インデックス漏れ | ドキュメント更新をトリガーに自動再インデックスする仕組みを組む |
| 同じ内容で答えがブレる | 同一文書の複数バージョンが並存 | 正本(single source of truth)を1箇所に定め、旧版は検索対象から除外する |
| 関係ない部署の情報を答える | 権限設定を考慮しない索引付け | アクセス権限をメタデータとして持たせ、検索時にフィルタする |
明日から使えるチェックリスト
- 長い作業は「区切り」を意識し、要点をファイルやチケットに書き出してから次のセッションへ進む。
- 重要な指示・制約は会話の冒頭か直前(末尾)に置き、真ん中に埋もれさせない。
- 調査や大量ログの処理はサブエージェントに切り出し、本流には要約だけを戻す。
- 社内ナレッジベースは「モデルより先にドキュメントの鮮度と正本管理」を点検する。
主な情報源
- LangChain Blog: Context Engineering for Agents
- GitHub: langchain-ai/context_engineering
- arXiv: Lost in the Middle: How Language Models Use Long Contexts
- Claude Code Docs: Best Practices
- Mem0: Context Window Is RAM, Not Storage
- DEV Community: 70% of Enterprise RAG Deployments Fail Before Production
- Fram: Enterprise RAG — Use Cases, Common Pitfalls, & Effective Solutions
各ツールは提供元の規約に従ってご利用ください。情報は各情報源の公開時点のものです。収集・要約はAI、公開判断は人。