🤖 machine learning

Why Does CLAUDE.md Keep Growing? Catastrophic Remembering in Agentic Coding

本論文は、CLAUDE.mdのようなエージェンティックなコーディングプロンプトにおける無制限な増大の原因として「破滅的な記憶（catastrophic remembering）」を特定し、指示の追記は低コストである一方でその削除は計算量的に極めて困難であることを実証した上で、プロンプト内のコメントに潜在的な推論を埋め込むことがこの発散を効果的に停止させ、指示への追従性能を大幅に向上させることを提案する。

原著者： Kushal Chakrabarti

公開日 2026-08-12

📖 1 分で読めます☕ さくっと読める

CC BY 4.0

原著者： Kushal Chakrabarti

原論文は CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) でライセンスされています。 ✨ これは以下の論文のAI生成解説です。著者が執筆または承認したものではありません。技術的な正確性については原論文を参照してください。免責事項の全文を読む

想像してみてください。あなたは、ブログ記事を書いたりコードを修正したりといった特定の仕事をする、非常に賢いけれど少し忘れっぽいロボットの助手に、仕事を教えています。まず、あなたはシンプルなルールのリストを与えます。「3つの段落を使うこと」「『とても（very）』という言葉を使わないこと」「必ず笑顔で終えること」。これはプロンプトと呼ばれます。人工知能の世界において、これらのプロンプトはロボットのための取扱説明書のようなものです。

さて、ロボットがミスをしたとしましょう。あなたは新しいルールを追加して修正します。「よし、それから、正確に5つの箇条書きを使うようにして」。ロボットは再挑戦しますが失敗し、あなたはさらに別のルールを追加します。「そして、すべての文章の最初の文字を大文字にするのを忘れないで」。時間が経つにつれ、このルールのリストはどんどん長くなっていきます。コンピュータサイエンスには、ロボットが新しいことを学ぶと、以前学んだことを誤って消去してしまう**破滅的忘却（catastrophic forgetting）**という有名な問題があります。しかし、この論文が話しているのはその逆の問題、**破滅的記憶（catastrophic remembering）**です。これは、ロボット（あるいはそれを管理する人間）がルールを加え続け、不要になった古いルールを決して削除しないときに起こります。リストはあまりにも巨大で乱雑になり、ロボットは混乱し、動作が遅くなり、再びミスをし始めます。大きな疑問は、「なぜこのリストは永遠に増え続けるのか？そして、どうすればそれを止められるのか？」ということです。

終わりのないリストの謎

South Park CommonsのKushal Chakrabarti氏は、なぜこれらの「エージェンティック（agentic）」な指示リスト（ソフトウェアプロジェクト内でよく CLAUD.md や AGENTS.md といった名前のファイルで見られるもの）が際限なく増え続けるのかを調査することにしました。彼らはGitHub上の約1,870件の実世界のソフトウェアプロジェクトを調査し、247,000件以上の個別の指示の履歴を追跡しました。

彼らは奇妙なパターンを発見しました。これらのリストが縮小することはほとんどないのです。代わりに、ファイルの更新ごとに平均で4.9個の新しい指示が増えています。ファイルの全期間を通じて、指示の数は226%増加し、3倍以上になっています。平均的なファイルは39個の指示を持ちますが、中には100個を超えるものもあります。

研究者たちは問いかけました。「なぜ人々は、古い不要なルールをただ削除しないのだろうか？」

彼らが発見した犯人は、ルールが「古くなった（stale）」ことでも、悪いルールがすぐに消え去るわけでもありませんでした。問題は**不完全な想起（imperfect recall）**でした。例えるなら、こういうことです。あなたがリストに新しいルールを追加するとき、なぜそれを追加したのかをあなたは知っています。例えば、ロボットが4つの段落を書いてしまうので、「3つの段落を使う」というルールを追加したかもしれません。しかし、その「理由」はあなたの頭の中にあるだけです。それは書き残されていません。

時間が経過し、他の人々がファイルを編集したり、プロジェクトが変化したりすると、その元の理由は消えてしまいます。半年後にリストを見たとき、「3つの段落を使う」というルールは目に飛び込んできますが、なぜそれがそこにあるのかは分かりません。ロボットが喋りすぎたからでしょうか？それとも上司からの指示だったのでしょうか？その理由がなければ、ルールを削除することはリスクに感じられます。もし削除したら、ロボットがまた壊れてしまうのではないかと不安になるのです。だから、そのままにしておきます。その一方で、新しい問題に対して新しいルールを加え続けます。その結果、誰も理解できないほど膨張し、混乱したルールのリストが出来上がります。著者はこれを、破滅的記憶、つまり「忘れるべきすべてを覚え続けてしまうこと」と呼んでいます。

「ブルドーザー」効果

研究では、人々がこれらの乱れたリストを修正しようとする方法についても面白いことが判明しました。彼らは単に一つや二つの悪いルールを削除することは滅多にありません。代わりに、彼らは「すべて削除」ボタンを押す傾向があります。データによると、指示の削除の**76.8%**は、誰かが一度にファイルの半分以上を削除する巨大な「書き換え」の中で行われています。それは、どの雑草を抜くべきか決められないために、庭全体を焼き払い、ゼロからやり直す庭師のようなものです。

しかし、ここからが肝心な点です。この「焼き払い」の後でさえ、庭は再び生い茂ります。リストは再び、以前と同じ速いペースで増え始めます。これは**ラチェット効果（ratchet effect）*と呼ばれます。サイズは下がりますが、成長の速度*は変わりません。根本的な原因――つまり、なぜルールが追加されたのかを人々が思い出せないという事実――が解決されていないため、リストは再び埋まっていくのです。

「コメント」の魔法

では、リストが永遠に増え続けるのを止めるにはどうすればよいのでしょうか？論文は、ソフトウェアエンジニアが何十年も前から使っている解決策を提案しています。それはコメントです。

通常のコンピュータコードでは、プログラマーはコードの横に、なぜそのような書き方をしたのかを説明する小さなメモを書きます。これらのメモはコンピュータには見えませんが、次にそのコードを読む人間には役立ちます。研究者たちは、このトリックがAIプロンプトでも機能するかどうかをテストしました。

彼らは、「メンテナー（維持管理者）」（AIエージェント）がプロンプトを構築し、修正しなければならないシミュレーションを設定しました。一つのグループでは、メモなしで指示を書かなければなりません。もう一つのグループでは、各指示の横に、その理由を説明するコメントを付けることが許可されました。例えば、「3つの段落を使う」の横に、「ラウンド3でロボットが4つの段落を書いてしまったため追加」といったコメントを付けることができます。

結果は劇的でした。

コメントなしの場合： プロンプトは、仕事を遂行するために必要な最小限のサイズよりも**211.3%**も大きくなりました。
コメントありの場合： プロンプトはほぼ完璧なサイズに保たれ、最小限のサイズよりわずか**1.4%**しか増えませんでした。

コメントはタイムマシンの役割を果たしました。それらは各ルールの「潜在的な推論（隠れた理由）」を保存しました。メンテナーが後でリストを見たとき、コメントを見ることで、そのルールがまだ必要であることを理解したり、あるいはもはや不要であると気づいて安全に削除したりすることができました。コメントは、不要な指示の**99.3%**を取り除いたのです。

実際にうまく機能するのか？

研究者たちは、単にリストを短くするだけでなく、ロボットが実際に優れた仕事をしたかどうかも確認しました。プロンプトが役に立たない指示で膨張していると、ロボットは混乱し、より多くのミスを犯すことが分かりました。コメントを使ってリストを清潔で集中したものに保つことで、指示に従うロボットの能力は最大**23.1%**向上しました。

また、この手法は、指示が複雑で「メンテナー」が非常に賢いAIエージェントである場合でも有効であることが示されました。AIが有能であればあるほど、ルールを過剰に追加する傾向がありますが、同時に、物事を制御するためのこれらの役立つコメントからもより多くの恩恵を受けるのです。

大きな教訓

論文は、遊び心がありつつも真剣な問いで締めくくられています。「英語が新しいコードであるならば、なぜ私たちはまだコメントを持っていないのか？」

人間のプログラマーがずっと前に、「なぜその行を書いたのか」を説明する必要があることを学んだのと同様に、AIプロンプトを管理する人々（およびAIエージェント）も、なぜそのルールを追加したのかを書き留める必要があります。その説明がなければ、ルールは積み重なり、システムは混乱し、パフォーマンスは低下します。解決策は、ルールを追加するのをやめることではありません。それぞれの横に小さなメモを書き、次の人（あるいはロボット）が、何を保持し、何を捨てるべきかを正確に判断できるようにすることです。そうすることで、混沌とした増殖するモンスターを、清潔で効率的なツールへと変えることができるのです。

技術要約：エージェンティック・コーディングにおける破滅的な記憶（Catastrophic Remembering）

1. 問題：エージェンティック・プロンプトの無制限な増大

エージェンティック・コーディングのリポジトリでは、AIエージェントを導くためのコンテキストファイル（例：CLAUDE.md、AGENTS.md、copilot-instructions.md）への依存が強まっている。経験的な観察によれば、これらのファイルには指示が際限なく蓄積されるという病理的な成長パターンが見られる。指示は、ファイルが全面的に書き換えられるかリポジトリが廃止されるまで、削減されることがほとんどない。

この増大は、単なる新しい要件の追加によるものではない。それはメンテナンスの失敗を意味している。制約が蓄積するにつれ、指示への追従性能は低下する。本論文は、その根本原因が「指示の陳腐化（古い指示が無関係になること）」や「コンテンツの脆弱性（弱い指示が早期に消滅すること）」ではなく、**不完全な想起（imperfect recall）**にあることを特定している。

メンテナーが指示を追加する際、その追加に対する根拠（潜在的な推論）は、多くの場合、暗黙的であるか記録されない。時間の経過とともに、複数の作成者がファイルを編集するにつれ、この潜在的な推論は減衰していく。根拠（rationale）を伴わずに指示を削除することは、正当性の退行（correctness regression）を招く高いリスクを伴う。その結果、指示の「危険度（hazard）」（削除される確率）は、指示が古くなるにつれて減少する。これにより、「ラチェット効果」が生じる。すなわち、追加は安価で頻繁に行われる一方で、削除はリスクが高く稀であるため、プロンプトのサイズが発散してしまうのである。著者はこの現象を**破滅的な記憶（Catastrophic Remembering）**と呼んでいる。これは、継続学習における「破滅的な忘却（catastrophic forgetting）」の逆であり、更新の許可（根拠）が失われたために、上書きすべきであったものをシステムが保持し続けてしまう状態を指す。

2. 手法

2.1 実世界のレポジトリにおける経験的分析

著者は、エージェンティック・コンテキストファイルを含む1,867件のGitHubリポジトリを対象とした大規模な観察研究を行った。

データ範囲: 299,440回のバージョン間遷移にわたる247,694件の指示の寿命を追跡した。
セグメンテーション: Markdownの構造と文の境界を用いて、ペイロードから指示を抽出した。
マッチング: 文字列の完全一致、正規化された文字列、ファジーマッチの3段階のプロセスにより、コミット間での指示の生存を追跡した。
競合リスク: 「削除（メンテナーによる判断）」と「全面的な書き換えまたは移行（大量削除）」を区別した。指示の死の77.3%は全面的な書き換えによって発生しており、これらを削除ハザードを分離するための競合リスクとして検閲（censored）した。
統計モデリング: 指示の年齢 $a$ と作成者数に基づき、削除ハザード $h(a)$ を分析するために、Nelson-Aalen推定法およびガンマ・フレイル・モデルを用いた。

2.2 理論的枠組み

本論文は、プロンプトのメンテナンスを、検閲されたノイズ混じりのフィードバックから、観測不可能な制約集合 $C$ をオンライン推定するプロセスとしてモデル化している。

潜在的推論の減衰: 指示 $d$ の根拠 $r_d$ の復元可能性は、年齢 $a$ とともに減衰し、 $\rho(d, a)$ と表記される。
平衡状態: 復元可能な根拠がない場合、最適な推定器は「追記のみ（append-only）」となる。タスクの制約が固定されていても、 $\bar{\rho}(a) \to 0$ のとき、平衡サイズ $|D_\infty|$ は発散する。
コストの非対称性: 指示の追加コストは $O(1)$ であるが、ある指示が余剰であること（および安全に削除できること）を、その根拠なしに検証するコストは、指示のサブセットをテストするために必要な反事実的検証の組合せ爆発により $O(2^{|D|})$ となる。

2.3 制御実験（逆IFEval）

因果メカニズムを検証するため、著者はIFEvalベンチマークを反転させた制御環境を構築した。

セットアップ: モデルの指示追従能力を評価する代わりに、「メンテナー」エージェントに対し、一般的な目的とノイズ混じりのフィードバックから、既知の指示セット（最小被覆 $D^\star$ ）を再構成させるタスクを与えた。
介入: メンテナーは、潜在的な推論（発生した失敗、仮説、および結果）をエンコードしたコメントを用いて、新しい指示に注釈を付けることができる。
群分け:
1. コントロール群: コメントなし。
2. プラセボ群: コメントの形状をしたノイズ（推論を含まない一般的なテキスト）。
3. 処置群: 特定の潜在的推論をエンコードした情報量の多いコメント。
評価: システムは、過剰サイズ（ $|D_t|/|D^\star| - 1$ ）と制約充足度を測定した。
WildIFEvalへの拡張: 第2の実験では、これを実世界の人間が書いたプロンプトに適用し、ノイズとなるディストラクター（妨害要素）を含む状況下での指示追従の回復を測定した。

3. 主な貢献と結果

3.1 破滅的な記憶の経験的証拠

無制限な増大: エージェンティック・プロンプトはその寿命の中でサイズが3倍以上に増大し（+226%）、1コミットあたり純増で+4.9個の指示を加えている。
ラチェット効果: ファイルが全面的に書き換えられると、以前のサイズの約60%にリセットされるが、直ちに増大を再開し、しばしば書き換え前よりも速い速度で成長する（書き換え後のコミットあたり4.9%増 vs 書き換え前の4.1%増）。
削除ハザード: 指示が削除される確率は、指示が古くなるにつれて減少する（ログ・ハザード勾配: -0.032/commit）。これは「陳腐化」仮説（陳腐化すればハザードは上昇すると予測する）に矛盾しており、「不完全な想起」を支持している。
作成者の相互作用: より多くの異なる人間による編集が行われると、削除ハザードはさらに速く減衰する。これは、元の作成者の根拠の喪失が駆動要因であることを裏付けている。

3.2 解決策：プロンプト・コメント

潜在的な推論をプロンプトのコメントにエンコードすることは、無制限な増大を阻止するための十分な介入となる。

過剰サイズの削減: 制御されたIFEval反転実験において、情報量の多いコメントは、51ステップにおける過剰サイズを、コントロール群の**+211.3%から、処置群の+1.4%**へと減少させた。15ステップのホライゾンでは、過剰サイズを+60.4%から-5.8%へと減少させた。
正当性の維持: このサイズ削減は、制約充足度を低下させることなく達成された。実際、充足度は同等か、あるいはわずかに向上した。
実世界への影響: WildIFEval実験において、ノイズ混じりのディストラクターを含むプロンプトに情報量の多いコメントを追加すると、コメントのないコントロール群と比較して、指示追従が23.1%（11.6パーセントポイント）向上した。
アブレーション（切除実験）: この恩恵は、具体的に**結果に基づいた推論（outcome-grounded reasoning）**によってもたらされる。単に試行を記述するだけで結果に触れないコメントや、一般的な「ノイズ」としてのコメントは、過剰サイズの削減に失敗した。

3.3 理論的洞察

本論文は、潜在的な推論の復元可能性が、安定したプロンプト・メンテナンスのための必要十分条件であることを定式化している。これがない限り、システムは「全面的な書き換え」という、根本的な未検証の制約の蓄積に対処できない戦略に陥り、「破滅的な記憶」状態へと強制的に追い込まれる。

4. 重要性と主張

本論文は、エージェンティック・プロンプトの無制限な増大に関する最初の根本原因分析を提供し、その責任を「指示の陳腐化」から**「不完全な想起」**へと転換したことを主張している。

パラダイムシフト: プロンプトのメンテナンスを、単なる制約管理ではなく、情報の保存の問題として再定義している。ソフトウェアエンジニアリングが数十年前、コメントによって「なぜ（why）」の問題を解決したのと同様に、エージェンティック・コーディングにも同じ規律が求められている。
実用性: 本研究は、単純で構造化されたコメントが、制御された設定においてプロンプトの膨張を99%以上削減し、ノイズの多い現実世界のシナリオにおいて、指示追従能力を大幅に回復できることを示している。
限界: 著者はその範囲について謙虚である。コーパスは英語の公開GitHubリポジトリに限定されている。制御実験は、機械的に検証可能な制約（IFEval）と特定のモデル構成に依存している。本論文は、コメントがすべてのプロンプトエンジニアリングの課題を解決すると主張しているのではなく、特にエージェンティック・コンテキストファイルの増大とメンテナンスのダイナミクスに焦に焦点を当てている。

中心的なテーゼは、もし英語が新しいコードであるならば、エージェンティック・プロンプトもソフトウェアエンジニアリングの規律を採用しなければならないということである。すなわち、「なぜ（why）」を記録することこそが、「何を（what）」（指示）を安全に管理する唯一の方法である。 これがなければ、エージェントは必然的に破滅的な記憶に陥り、使用不可能な制約を蓄積し続け、システムが機能不全に陥ることになる。