CLAUDE.mdはなぜ増え続けるのか。24.8万件の履歴が示した「理由を書く」効果
AIコーディングエージェント用の指示ファイルを開き、「この一行、今も必要だろうか」と迷った経験はないでしょうか。
追加するのは簡単です。失敗を一度見たら、再発防止のルールを一行足せばいい。ところが削除は怖い。その指示が何を防いでいたのか分からなければ、消した直後に昔の不具合が戻るかもしれません。
この非対称性を大規模な履歴データと対照実験で捉えたのが、2026年8月11日に公開された論文「Why Does CLAUDE.md Keep Growing? Catastrophic Remembering in Agentic Coding」です。
論文が付けた名前は「catastrophic remembering」、日本語にすれば「破局的な記憶保持」です。忘れてはいけないものを忘れるのではなく、消してよいものまで残し続ける。その結果、CLAUDE.md、AGENTS.md、copilot-instructions.mdのような指示ファイルが太り続けます。
結論を先に言うと、対策は単に短く書くことではありません。指示を追加した瞬間に「なぜ必要か」「何が起きたか」「いつ消せるか」を、次の保守担当者へ渡せる形で残すことです。
1,867リポジトリで指示は本当に増え続けた
研究チームは、公開GitHub上でエージェント向け指示ファイルを持つ1,867リポジトリを調べました。対象は1,801の複数版ファイル、29万9,440件の版間遷移、24万7,694件の指示寿命です。
観測結果はかなりはっきりしています。
- ファイルの寿命全体で、平均指示数は226%増えた
- 大規模な書き直しを除くと、1コミット当たり平均4.9件の指示が純増した
- 複数版を持つ1,576リポジトリのうち、64.3%で指示数が増え、減ったのは26.6%だった
- 最終版の中央値は39指示、90パーセンタイルは131指示だった
- 指示の総サイズも140%増えた
しかも、古い指示ほど消されやすくなるわけではありません。逆です。指示の削除ハザードは、経過コミット数に対して対数傾き-0.032で低下しました。95%信頼区間は-0.047から-0.019で、ゼロをまたぎません。
古くなった規則が自然に整理されるなら、年齢とともに削除確率は上がるはずです。実際には下がった。論文は、時間がたつほど「なぜこの指示を入れたのか」が回収できなくなり、安全に削除できなくなると解釈します。
大掃除をしても、10コミットでほぼ元に戻る
増えすぎた指示ファイルは、ときどき全面的に書き直されます。しかし論文の追跡では、それも根本解決になりませんでした。
書き直し時に指示数は直前の59.5%まで減ります。それでも、その後10コミットで91.5%まで戻りました。さらに増加率は、書き直し前の1コミット当たり4.1%から、書き直し後には4.9%へ上がっています。
指示の死の77.3%は、個別の判断による削除ではなく、大規模な書き直しか別ファイルへの移動で起きていました。一本ずつ理由を確認して剪定するより、まとめて作り直す方が心理的にも作業的にも安いからです。
しかし、理由を残さないまま作り直せば、次の失敗でまた規則が追加されます。大掃除は床をきれいにしますが、散らかる仕組みまでは直しません。ここは指示ファイル界の押し入れです。
問題は長さではなく、削除を許可する根拠がないこと
論文の中心は、指示の長さそのものより、指示を消すための根拠が失われる点にあります。
ある規則が本当に不要かを厳密に確かめるには、その規則を外した組み合わせを試す必要があります。規則同士が重複していれば、一つずつ外す試験だけでは足りません。論文は、指示集合の全組み合わせを調べる正直な監査を、指示数に対して指数的な費用になると定式化しています。
一方、追加時の理由が残っていれば判断は急に小さくなります。
- どの失敗を受けて追加したか
- 何が原因だと考えたか
- 追加後に同じ失敗が減ったか
- 別の対策で置き換えられたか
- どの条件を満たせば削除候補になるか
この情報があれば、保守担当者は全組み合わせを試さず、該当する失敗と検証結果に絞って再確認できます。
重要なのは「何をするか」の説明を長くすることではありません。「なぜ存在するか」と「結果はどうだったか」を残すことです。
コメントは余分な指示を99.3%減らした
観測研究だけでは、原因を断定できません。そこで論文は、IFEvalを逆向きに使う対照実験を設計しました。
通常のIFEvalは、明示された指示に応答が従ったかを検査します。この研究では指示を隠し、検査器だけを残しました。保守役は曖昧な失敗報告を受けながら、必要な指示集合を学びます。正解となる最小指示集合が既知なので、増えすぎた量と正しさを同時に測れます。
15ステップ、552件の保守履歴では、結果を伴う理由コメントを持たない条件の余剰サイズが+60.4%でした。理由コメントを持つ条件は-5.8%で、制約充足率はほぼ同等です。
51ステップ、184世界の長い実験では差がさらに広がりました。
- コメントなし：余剰サイズ+211.3%
- 理由コメントあり：余剰サイズ+1.4%
余分な指示の削減率は99.3%です。見た目だけコメントらしい雑音を渡した条件は+147.9%まで増えました。つまり「コメント欄を作る」だけでは足りず、失敗、仮説、結果を含む情報が必要です。
短くなっただけではない。指示追従も改善した
短い指示ファイルが美しいだけなら、運用上の優先度は高くありません。重要なのは、実際の応答品質がどう変わるかです。
研究は、人間が書いた制約を持つWildIFEvalにも余分な指示を混ぜました。余分な16指示がある条件では、本来の制約に対する正答率が65.6%から41.5%へ24.1ポイント落ちています。
そこから3回の保守を行うと、理由コメントを持つ条件は制約充足率を50.4%から62.0%へ引き上げました。絶対差は11.6ポイント、相対改善は23.1%です。
この評価はLLM判定に依存します。そこで別の判定モデルでも6,336件を再採点したところ、改善方向は再現され、効果は7.8ポイントでした。二つの判定器は個別判定で17.9%食い違いましたが、処置群と対照群の差の方向は維持されました。
これは「コメントが常に賢さを増す」という意味ではありません。余分な指示がない条件では、一貫した改善は出ていません。理由コメントの効果は、増殖した指示を安全に見直せることで、雑音による損失を取り戻す点にあります。
そのままAGENTS.mdにコメントを足せばよいのか
ここは論文の読み違えやすい部分です。
実験では、コメントは次の保守担当者には見えますが、実行役のモデルへ渡す前に除去されます。つまり、指示チャネルと保守理由チャネルが分離されています。
現在の多くのエージェント環境で、AGENTS.mdに書いたコメントが自動的に無視されるとは限りません。単に説明を大量追加すると、それ自体がコンテキストを増やし、実行モデルへ影響する可能性があります。
AICompanyとしての実務的な翻訳は、次の二層構造です。
- 実行役に渡す指示は、短く、観測可能で、重複を避ける
- 保守役だけが読む理由台帳に、追加理由と検証履歴を残す
理由台帳は、各指示について最低限、次の項目を持てます。
- 指示ID
- 実行役へ渡す短い指示
- 追加のきっかけになった失敗
- 原因仮説
- 追加後の結果
- 再発回数
- 削除または統合を検討できる条件
- 最終確認日
ツール側で分離できるなら、実行時には短い指示だけを組み立て、レビュー時には理由台帳も表示します。分離できない場合でも、別ファイルや監査記録として持つ方が、説明をすべて実行プロンプトへ押し込むより安全です。
小さく試すなら「追加」と「削除」を別のゲートにする
導入時に、いきなり既存ルールを自動削除する必要はありません。むしろ論文は、それを危険だと警告しています。
安全な第一歩は、追加時の記録だけを必須にすることです。
- 新しい指示には、具体的な失敗証拠を一つ結び付ける
- 原因仮説と期待する改善を書く
- 次回同じ条件で成功したかを記録する
- 重複候補を機械的に提示する
- 削除は人間が承認し、安全関連の指示は別扱いにする
この仕組みなら、既存ルールを消さずに将来の削除可能性を高められます。コメントを書くこと自体は何も削除しません。判断材料を未来へ送るだけです。
さらに、定期レビューでは指示の古さだけで削除しない方がよいでしょう。論文の結果では、古いことは不要である証拠ではなく、理由が失われている可能性の指標です。見るべきなのは年齢ではなく、根拠、最近の再現、代替策、依存関係です。
この研究だけでは言えないこと
証拠は強い一方、適用範囲には明確な限界があります。
第一に、公開GitHubの1,867リポジトリは大規模ですが、指示の自然言語、プログラミング言語、業種の分布は測られていません。非英語の指示ファイルへ同じ数値をそのまま当てはめることはできません。
第二に、対照実験の最小指示集合は2件か3件で、実地データの中央値39件より小さい設計です。15ステップ実験では一つのモデルが保守役と実行役を兼ねています。51ステップ結果は1シードです。
第三に、WildIFEval部分はコードの成否ではなく、文章制約をLLM判定器が採点しています。別判定器で方向は再現しましたが、人間の正解ラベルではありません。
第四に、履歴追跡は50%減を全面書き直しとする閾値、指示分割文法、版間マッチャーに依存します。マッチャーの手動検証は50遷移です。論文は、これらを未検証の自由度として明記しています。
最後に、理由が分かったからといって自動削除してよいわけではありません。論文自身、理由コメントを使った運用が一部の世界で指示を空にし、コメントなし条件の方が高得点だった例を報告しています。安全関連の指示は対象外にし、人間を削除経路に残すべきです。
結論。ルールより先に、ルールの寿命を設計する
この研究が面白いのは、長いプロンプトを単なる整理整頓の問題として扱わなかった点です。
指示は、失敗のたびに生まれます。ところが、その失敗と検証結果が残らなければ、指示だけが孤立して残る。削除の根拠が消え、追加だけが安全な選択になります。その積み重ねが、破局的な記憶保持です。
対策は、何でも短くすることではありません。指示の追加時に、存在理由、観測結果、見直し条件を同時に保存することです。そして実行役の指示と、保守役の理由を分ける。
CLAUDE.mdやAGENTS.mdを育てるとき、次に追加する一行より先に考えるべき質問はこれです。
「半年後の担当者は、この一行を安全に消せるだろうか」
答えが「理由が分からないから無理」なら、今書くべきなのはルールだけではありません。未来の削除を許可する証拠です。