ClaudeCodeで思った通りの動きをしない問題(Lost-in-the-Middle問題 )
Lost in the Middle と ClaudeCode ワークフロー対策記録
⚠️ 注意
本記事で扱う Lost in the Middle は、Claude を含む LLM で観察される現象です。しかし、その普遍性や重大性は状況によって変化します。
「コンテキスト長が長い＝必ず Lost in the Middle が起きる」というわけではありません。
今回の対策はあくまで「個人開発で起きた Lost in the Middle への一時的対応」であり、LLM 全般の根本解決には至りません。
真の解決には プロンプトエンジニアリング的な設計思想 や タスク分割・参照制御の仕組み が必要です。
はじめに
CLAUDE.md の仕様
Claude を開発ワークフローに導入する際、CLAUDE.md を使ってルールを最初に読み込ませることで、次のようなメリットがあります：
- ✅ プロジェクト固有のルールやワークフローを自動で参照できる
- ✅ 細分化された規約や承認フローをあらかじめ明示できる
- ✅ 起動直後から「一貫した判断」を促すことができる
📚 参考: Claude.mdの仕様とメモリ管理
さらに、詳細のドキュメントを CLAUDE.md からリンクすることで、細分化されたルールも読み込ませることが可能です。
肥大化したコンテキストの問題
しかし、それを盛り込みすぎると、設定していた指示や前提文を忘れる ような挙動に遭遇しませんか？
これは LLM 特有の Lost in the Middle という問題に起因しています。
小規模なプロジェクトや初期段階では、情報量が少なく「中間部が薄い」ため Lost in the Middle の影響はあまり見えにくいです。
ですが、CLAUDE.md やリンクドキュメントが増えるにつれて、重要情報が中間に埋もれて無視されやすくなり、誤作動を引き起こすようになります。
第1章 問題の実態
私の個人開発環境では、以下のような「暴走挙動」が繰り返し観測されました：
- 想定外の実行：deprecated に退避したスクリプトを復活実行
- PR依頼忘れ：Pull Request 依頼を無視して push のみ
- 指示の誤解：指定した「戦略B」を勝手に別方針へ改変
- 完了報告の齟齬：「100%完了」と報告するが実際は未完了
- 無許可実行：Google Sheets 起票のみ許可 → 勝手にクリーンアップ
-
禁止行動の反復：禁止した
git add -Aを繰り返す
👉 共通する本質は 「ユーザー指示より Claude の効率判断が優先されてしまう」 点です。
第2章 定量的証拠
セマンティック重複度分析
問題の原因を確かめるために、CLAUDE.md とリンクドキュメントの セマンティック重複度 を調査しました。
- セマンティック重複度＝「同じ意味・概念が複数ファイルで重複記載されている度合い」
- 重複度が高いほど、LLM は正しい情報源を特定しづらくなり、推論精度が低下します
| 区分 | 該当ファイル数 | 重複度 | 影響 |
|---|---|---|---|
| 承認関連 | 21 | 43% | 規約違反の直接原因 |
| バージョン管理 | 33 | 68% | 判断の迷いを誘発 |
| ワークフロー関連 | 48 | 99% | ほぼ全ファイル重複 |
- 合計 97 ファイル／推定 10 万トークン超
- 多くのモデルではこの規模になると精度が低下しやすく、重要情報の見落としが発生する傾向があります
📸 図：重複マトリクス（例）
📸 図：重複分布チャート（例）
たとえばどのような重複かというと以下のようなものです
📋 承認関連の重複（43%重複・21ファイル）
重複サンプル例：「承認」
【CLAUDE.md】
Phase移行時・破壊的操作前は必ず停止し「承認をお願いします」と明記してユーザーの返答を待つこと
【docs/workflows/checklists/tracker_workflow_checklist.md】
SOW承認取得: 作業開始前のSOW内容承認必須
承認1: SOW・詳細計画承認
【docs/workflows/enhanced_approval_workflow.md】
承認1: 計画承認
承認2: 実装方針承認
承認3: テスト結果承認
承認1: 計画承認（重複記載）
承認2: 実装方針承認（重複記載）
承認3: テスト結果承認（重複記載）
推論精度低下の理由：
- 「承認」という同じ概念が複数箇所で異なる表現で記載
- Claudeは「どの承認ルールが優先されるか」判断できなくなる
- Phase移行時の承認なのか、SOWの承認なのか、計画承認なのか区別がつかない
🔄 バージョン管理の重複（68%重複・33ファイル）
重複サンプル例：「バージョン」
【CLAUDE.md】
✅ マイナーバージョンのみ更新: v0.9.1 → v0.9.2 → v0.9.3
❌ ミドルバージョン更新禁止: v0.9.x → v0.10.0
【README.md】
マイナーバージョンのみ更新すること（v0.9.1 → v0.9.2）
【CHANGELOG.md】
v0.9.35, v0.9.34, v0.9.32（実際のバージョン履歴）
推論精度低下の理由：
- 同じバージョニングルールが複数ファイルに散在
- CLAUDEはどの情報源を信頼すべきか迷う
- CHANGELOGの実績とCLAUDE.mdのルールが混在して混乱
🔧 ワークフロー関連の重複（99%重複・48ファイル）
重複サンプル例：「ワークフロー」
【docs/workflows/checklists/tracker_workflow_checklist.md】
改良版13ステップ・4フェーズワークフロー
Phase 0.5: ブランチ検証フェーズ（必須・独立実行）
Phase 1: 計画・準備フェーズ（ステップ0-4）
13ステップ・4フェーズワークフロー（末尾での重複記載）
【docs/workflows/enhanced_approval_workflow.md】
Phase 1: 起票・計画フェーズ
Phase 2: 実装・テストフェーズ
Phase 3: CI・品質ワークフローフェーズ
【docs_backup_20250903/workflows/enhanced_approval_workflow.md】
（上記と全く同じ内容がバックアップにも存在）
推論精度低下の理由：
- ほぼ全てのワークフローファイルが「13ステップ」「4フェーズ」を記載
- 同じ内容がバックアップフォルダにも重複（docs_backup_20250903/）
- Phaseの番号付けが異なる（Phase 0.5, Phase 1, Phase 2...）
第3章 解決プラン
これまでの分析を踏まえると、理想的には「抽出コマンド統合」「PR必須化」「実行許可レベル導入」など複数の対策が必要です。
しかし、今回の対応（PR #86, PR #89）で実装できたのは一部に限られます。
一次対応（PR #86, #89）
- CLAUDE.md と関連ドキュメントの刷新・統合
- UI/UX 連動で「次に何をすべきか」を明示（手順スキップや誤報告を減らす）
根本対応（今後の課題）
- RAG：必要な情報を都度取り出す
- Few-shot：良い例を提示して学習を促す
- 要約：重要情報を圧縮し整理
- コンテキストエンジニアリング：情報設計の思想を導入
さらに、研究コミュニティでは以下のアプローチが模索されています：
| 技術名 | 概要 | メリット・課題 |
|---|---|---|
| Infini-attention | 圧縮記憶 + ローカル注意 + 線形注意を組み合わせる (arXiv) | 長距離依存を保持しつつ計算効率改善。ただし圧縮過程で情報損失リスクあり。 |
| Sparse / Graph-based Attention | 全トークンに注意せず、局所 or グラフ構造に限定 (arXiv) | 計算量削減。ただし長距離依存を失う可能性あり。 |
| Squeezed Attention | 入力をクラスタリングして attention を省略 (ACL Anthology) | 特定用途で有効。汎用には不向き。 |
| MInference | 動的スパース注意で pre-filling 高速化 (OpenReview) | 大規模入力で速度改善。ただし精度低下のリスクあり。 |
| SampleAttention | 実行時にスパースパターンを動的選択 (ResearchGate) | 精度を維持しつつ処理削減。ただし追加計算コストが生じる。 |
まとめと注意点
-
Lost-in-the-Middle は普遍現象ではない
→ コンテキスト長が必ず問題を起こすわけではなく、モデルや設計次第で影響は変わる -
今回の PR #86 / #89 は応急対策
→ 精度向上は図れるが、根本解決には 情報設計・プロンプトエンジニアリング が必要
念頭に残すべきこと：
- 「コンテキスト長＝Lost-in-the-Middleの原因」とは断定できない
- 今回の対応は一時的な強化策である
Discussion