Claude CodeのCLAUDE.mdを育てる：規則と作業記録を分ける

長く守る規則を短く明示する

使用する構成、必須の確認方法、避ける変更など、繰り返し必要になる指示をまとめます。コードから簡単に読める大量の事実を複製するより、判断を誤りやすい制約を優先します。公式の記憶機能や適用範囲は利用中の版の資料で確認します。

規則には理由や対象を短く添えます。「変更禁止」だけでは、ファイル全体が対象なのか特定の動作なのか分かりません。例外がある場合も、誰のどの判断で使えるのかを明確にします。

今回の状態は別に保存する

作業中のブランチ、確認した版、未解決事項は変わりやすい情報です。常設の規則へ混ぜると、次回も同じ状態だと誤解される可能性があります。更新時点と証拠への参照を持つ作業メモへ分けます。

過去にテストが通ったという記録は、現在のソースの証拠とは限りません。再利用する場合は、対象のファイルや入力が変わっていないか照合します。

矛盾を見つけたときに優先関係を確認する

別の範囲向けの指示や古いタスクの制約を、現在の要件へ無条件に適用しないようにします。反対に、曖昧な記憶を根拠に現在の守りを外すのも避けます。適用範囲と最新の明示的な要求を確認し、不明な部分だけを切り出します。

規則を増やす前に失敗の原因を分類する

指示が守られなかったとき、毎回禁止文を追加する前に、情報が読み込まれていたか、範囲が曖昧でなかったか、別の指示と矛盾していなかったかを調べます。実行を確実に制限したい条件なら、文章による注意ではなく権限や既存の検証の役割かもしれません。行動を案内する情報と、実際に強制する境界を分けて設計してください。

記憶の点検では、新しい担当者が最初に読む情報だけで対象と制約を判断できるかを確認します。過去の失敗を全部並べると、現在も必要な条件が埋もれます。繰り返す判断の要点を常設へ残し、一回のタスクの詳細は履歴へ分けることで、短さと再開可能性を両立させます。記憶の量そのものではなく、現在の判断に役立つかを評価します。

具体例で考える

架空の開発で、常設の規則に前回の「文言だけ修正」が残り、今回はフォーム機能の追加を依頼されています。

常設：入力検証と既存権限を保つ。
今回：フォームの送信前確認を追加。
過去の範囲：文言だけの修正は前回の記録。
確認：現在の対象ファイルと実際の状態。

前回の狭い作業範囲を永久の制限にしない一方、入力検証のような継続する規則は維持します。情報の寿命を分けることで、同じ説明の繰り返しと古い指示の誤適用を両方減らせます。

確認課題と合格の目安

プロジェクトのメモを、常設規則、現在の状態、履歴の三群へ分類してください。

• 各情報の有効範囲と更新時点が分かる。
• 過去の検証結果を現在の結果と混同しない。
• コードと食い違う複製情報を減らせる。