モデルを Opus 5.5 / Sonnet 5.5 に替えたついでに、「前のモデル向けの注意書き、まだ全部要るのか？」と指示ファイルを見直した。対象は、毎セッション読み込ませている全プロジェクト共通の CLAUDE.md と、そこから import している 2 ファイルだ。13.6KB のうち、Claude に読ませなくても困らない部分が量で 3 分の 2 を超えていた。context に残したのは 4.4KB、35 行だ。
モデルは新品なのに、渡していたのは前のモデル向けの注意書きの束だったことになる（新入社員に、前任者が辞める前に書いた「あの人の癖」メモを毎朝読ませるようなもの）。しかも削った側には、2 月にこの blog でも紹介した優先度ラベル付きの構成がまるごと入っている。
この記事では、モデルを替えたときに CLAUDE.md のどの行を残し、どれを消すかの判断基準をまとめる。その仕分けを Claude Code（Pro $20/月、Max $100〜200/月）にやらせるときの指示も載せる。
モデルを替えると、効いていた行が邪魔になる理由
理由は 3 つあり、どれも公式ドキュメントに書かれている。
1 つ目は、新しいモデルが既定でやるようになったこと。書いても挙動は変わらないのに、行は毎回 context を食う。公式の best practices は、肥大した CLAUDE.md は本当に守らせたい指示まで無視させると書く。memory のページは 1 ファイル 200 行未満を目安にし、@ での import は整理には役立つが読み込まれる量は減らない、としている。
2 つ目は、前のモデルの癖を補う指示が、逆向きに効くこと。公式のプロンプトガイドによれば、Opus 4.5 / 4.6 はシステムプロンプトに敏感になり、「CRITICAL: You MUST」のような強い言い方は過剰に発火しうる。同じガイドは、モデル名の付いた書き方はそのモデルで測ったものとして扱い、別のモデルに使う前に測り直せ、とも書く。Sonnet 5.5 向けのガイドも「最終回答まで所見をため込め」のような古い指示を外すよう書いている。
3 つ目は、道具側が引き取ったこと。Claude Code 本体の指示や hook が既にやっていることを CLAUDE.md で重ねて言う必要はない。CLAUDE.md は助言で、hook は必ず実行される、と公式は区別している。
1 行ずつの判断: 消したら今のモデルは間違えるか
判断の軸は公式の問い「この行を消したら Claude は間違えるか」1 つで足りる。間違えないなら消す。残す行は、置き場所をもう一段選ぶ。
独立したブロックとして書いた HTML コメントは、Claude Code が context に入れる前に剥がす（コードブロックの中は剥がされない）。経緯を人間向けに残しても token はかからない。
筆者のファイルでは、行の種類ごとに次の行き先になった。
| 行の種類 | 筆者の例 | 行き先 |
|---|---|---|
| モデルが既定でやる一般論 | SOLID / DRY、「推測より証拠」 | 消す |
| 前のモデルや道具の穴埋め | 旧タスク管理ツールの切り替え注記、日付の確かめ方 | 消す（本体の指示と重なる） |
| 強調・優先度ラベル | 赤・黄・緑の 3 段階 | 外して普通の文に |
| もう使っていない仕組み | 外部ツールへの記憶の自動保存手順 | 消す（組み込みの auto memory と二重） |
| hook が強制している規則 | 保護ブランチへの push 禁止 | 止められたときに別の原因と取り違えないよう、止めている hook の名前だけ 1 行残す |
| 経緯・日付・許可の代償 | sandbox の許可を足した日と理由 | HTML コメントへ |
| 環境固有の落とし穴 | sandbox 内では /tmp に直接書けない | 残す（理由を 1 句添えて） |
残ったのは、ほぼ最後の行の種類だけだった。モデルが賢くなっても、手元の sandbox の事情までは推測できない。強調は公式も「どうしても守られない 1 行にだけ」としている。目立たせるためのラベルのはずが、全行に付けるとどれも目立たなくなる（全員が班長の班）。rules・skill・auto memory の置き分けはauto memory と CLAUDE.md の使い分けにまとめた。
Claude Code に仕分けさせる指示
仕分けは自分でやらず、エージェントに表を作らせて、人は判断が要る行だけ見ればよい。最初に /doctor prompt-audit（Claude Code v2.1.283 以降）を走らせる。旧モデル向けの書き方・存在しないファイルへの参照・ファイル同士の矛盾を拾い、修正案を出してくれる。頼むまでファイルは変わらない。
残る「消したら間違えるか」の判断は、次のように頼む。
~/.claude/CLAUDE.md と、そこから @ で読み込んでいるファイルを 1 行ずつ仕分けて。まだ編集はしないで。
基準は「この行を消したら、今のモデルが間違えるか」。判断の前に次を読むこと:
- https://code.claude.com/docs/en/best-practices の CLAUDE.md の節
- https://code.claude.com/docs/en/memory の Write effective instructions
- いま使っているモデルの prompting ガイド（前のモデルとの違い）
各行を「消す / hook に任せる / paths 付きの rules か skill へ移す / HTML コメントへ / 残す」に分けて表で返して。
- hook に任せる行は、その操作を止める hook が settings.json か導入済み plugin の hooks に実際にあるかを開いて確かめてから
- 残す行には、モデルが自力では分からない理由を 1 句で添える
- IMPORTANT・MUST・絵文字の優先度は外した書き直し案を出す
- 過去の事故から足したらしい行で理由が読めないものは、消さずに「要確認」にする
返ってきた表で人が見るのは次の 4 か所だ。
| 見る所 | 理由 |
|---|---|
| 「hook に任せる」の行 | 強制しているつもりの設定が、本当にその操作を止めるかは試すまで分からない。筆者の環境では、git push の引数を glob で絞った permission の deny ルールが実測で一致せず、保護ブランチへの push を実際に止めていたのは hook だけだった |
| 「消す」に入った環境固有の行 | 一般論と見分けにくい。手元でしか起きない失敗かどうかは持ち主しか知らない |
| 「移す」案の行き先が import 先か paths の無い rules | 整理にはなるが context は減らない |
| 「要確認」の行 | 事故の経緯を知るのは人だけ。理由を思い出せて、今のモデルでも起きうるなら行は残し、経緯を HTML コメントに書く。思い出せなければ消す |
直した表を渡し、そのとおりに編集させる（prompt-audit の修正案も、採るものだけ同時に）。
削った後に確かめること
確かめるのは 2 つでよい。新しいセッションで /context を開き、Memory files に載る量が減ったかを見る。筆者のファイルはバイト数で 13.6KB から 4.4KB になった（/context では token 数で出る。HTML コメントを含めたファイル自体は約 8KB）。もう 1 つは、削った行に関わる作業を一度やらせて、挙動が変わらないかを見ることだ。公式も「コードのように扱い、挙動が実際に変わるかで確かめよ」としている。
削るのは一度で終わらない。これで身軽になった、と思いきや、35 行まで削ったファイルは 2 週間半で 55 行、量にして約 2.6 倍に戻った（リバウンドの速さだけは一人前）。ただ、足された行の大半は sandbox やワークツリーの落とし穴、つまり表の「残す」に入る種類だった。一般論に近い行も数行戻ってきているので、そちらは次のモデル更新でまた同じ問いにかける。肥大を測る物差しは行数ではなく、その行が今のモデルに必要かどうかだ。
まとめ
- モデルを替えたら、CLAUDE.md は書き足す前に削る。軸は「消したら今のモデルが間違えるか」
- 必ず守らせたいことは hook、一部の作業でだけ要ることは paths 付きの rules か skill、経緯は HTML コメントへ
- 仕分けはエージェントに表で出させ、人は hook・環境固有・移す先・要確認の行だけ見る
- 削った後は
/contextで量を、実際の作業で挙動を確かめる
次のモデル更新のときも、同じ指示をもう一度渡せばよい。そのとき消える行が、今回残した行の中にもきっとある。チームの CLAUDE.md や hook の設計まで含めて外から整えたい場合は、AI実装支援も選択肢の一つになる。
