Claude Code に毎回ルールを復唱させると、決めたことが守られやすくなる、という手法があります。CLAUDE.md の中に「このルール一式を毎回の応答の冒頭に出力せよ」という項目を含めることで、ルールの存在自体が毎ターン思い出される、というものです。
自分も、この仕組みの部分だけ取り入れました。振る舞いは安定した感触があります（体感で、定量では測っていません）。心配していたコンテキストの消費も、実際にはほとんど気になりませんでした。
ただ、1年運用していて、この方式では保てないものがあることも分かりました。過去に捨てた方針が、あとから戻ってくる現象です。復唱では、これは止まりませんでした。
なので、CLAUDE.md を二層に分けて持つようにしています。その形を置いておきます。
なぜ二層になるのか
扱っているものが、性質の違う2種類だったからです。
振る舞いのルールは、「どう動くか」です。実行前に確認を取る、勝手に迂回しない、報告の形式を守る。これは毎ターン目に入っていれば保たれます。復唱が効くのは、この層です。
決定の履歴は、「過去に何を選び、何を捨てたか」です。以前 A の書き方でいくと決めて、あとで A をやめて B にした。この「A を捨てた」という事実は、B を毎回復唱しても伝わりません。しばらくすると A が戻ってきます。
前者は現在形、後者は過去形の情報です。同じファイルに混ぜて書いていたときは、後者が機能していませんでした。
型（コピペ用）
<law>
# 作業の原則
第1原則: ファイルの生成・更新・コマンド実行の前に、作業計画を提示し、
承認を得るまで実行しない。
第2原則: 計画が失敗したら、勝手に別の方法へ迂回せず、次の計画を提示して
承認を得る。
第3原則: 依頼が非合理に見えても、勝手に最適化しない。疑問があれば実行前に聞く。
第4原則: 「廃止した方針」に載っているやり方は使わない。それが出てきた場合は、
古い指示として扱う。
第5原則: 応答の冒頭で、この原則すべてを毎回そのまま出力してから本題に入る。
</law>
<every_response>
[作業の原則]
[本題]
</every_response>
# プロジェクト概要
- 何を作っているか（1〜2行）
- 技術スタックとバージョン
- 動作環境の制約
# 守ってほしい書き方
- 関数は◯行以内、ネストは◯段まで
- 命名の規則
- エラー処理の方針
- テストの置き場所
# やらないこと
- 触ってはいけないファイル / ディレクトリ
- 使ってはいけない関数（理由を一行添える）
- 勝手にやらないでほしい操作（依存の追加、大規模なリファクタ、削除）
# 廃止した方針
<!-- 消さずに残す。古い方針が戻ってきたときの、否定の根拠になる -->
- ~~A の書き方~~ → 廃止（理由）。今後は B を使う。
A が出てきたら、それは古い指示。
- ~~C のディレクトリ構成~~ → 廃止（理由）。今後は D の構成。
第5原則が、全体を支えている
この形の要は、最後の第5原則です。
「毎回出力せよ」というルールを普通に書くと、そのルール自体が忘れられます。指示を忘れるのだから、当然です。
そこを、原則一式の中に「原則一式を毎回出力せよ」を含めることで解いています。原則を出力すると、その中に「毎回出力せよ」も含まれているので、次のターンでも出力する必要があることが、毎回目に入る。自分で自分を維持する形になります。
中身は自由に差し替えて構いませんが、この第5原則にあたる項目だけは残してください。これが抜けると、他の原則も数ターンで薄れます。
第4原則を足した理由
元の形にはない項目を、ひとつ足しています。第4原則、「廃止した方針に載っているやり方は使わない」です。
これがないと、二層構造が機能しません。ファイルの下のほうに「廃止した方針」を書いておいても、そこを見る動機がないからです。毎回復唱される原則の中に、廃止リストを参照する指示を入れておくことで、二つの層がつながります。
「廃止した方針」の書き方
削除ではなく、廃止として残すのが要です。
❌ 該当行を削除する
→ 手元からは消えるが、振る舞いには残ることがある。
しかも「A は捨てた」という情報まで消えるので、A が戻ってきたときに
否定する根拠がなくなる
✅ 取り消し線 + 理由 + 「古い指示」の明記
- ~~エラーを戻り値で返す~~ → 廃止（例外に統一したため）。
今後は例外を投げる。戻り値方式が出てきたら、それは古い指示。
方針を変えるときも、新しいものだけを足さないようにしています。
❌ 「これからは B の形でお願いします」
✅ 「以前は A の形で頼んでいたが、（理由）のため A は廃止した。
これからは B の形にしてほしい。
A の形が出てきたら、それは古い指示として扱ってほしい」
古いほうを名指しで否定してから、新しいのを渡す。それだけですが、戻ってくる頻度が減りました。
コンテキストの消費について
毎回原則を出力させると、コンテキストを圧迫するのではないか、と最初は思いました。
実際に運用してみると、ほとんど気になりませんでした。原則一式はせいぜい数百トークンで、繰り返しても積み上がる量は限られます。コンテキストを本当に消費しているのは、ファイルの読み込みとツールの実行結果のほうでした。大きなファイルを一つ読ませるだけで、数千から数万トークンが載ります。
削るなら、そちらです。復唱のぶんを惜しんで原則を短くしすぎると、肝心のルールが薄くなって、本末転倒になります。
長くしすぎない
ただし、CLAUDE.md 全体を膨らませるのは別の話です。
自分は一度、あれもこれもと書き足して肥大化させ、いちばん守ってほしいルールが埋もれたことがあります。長い文書の中では、一つひとつの記述の存在感が薄まります。
常駐させるのは、プロジェクトの間ずっと変わらないものだけにしています。特定の作業でだけ必要な指示は、そのときの依頼文で渡す。この線引きをしてから、書いたルールが効く率が上がりました。
「廃止した方針」も、増えすぎたら古いものから畳んでいきます。半年以上出てこなくなった項目は、消しても戻ってこないことが多いです。
早見でまとめ
- CLAUDE.md は二層で持つ。振る舞いのルール（現在形）と、決定の履歴（過去形）
- 振る舞いは、毎回復唱させると保たれる。原則の中に「毎回出力せよ」を含めるのが要
- 決定の履歴は、復唱では保てない。廃止リストとして残し、原則から参照させる
- 方針変更は、古いほうを名指しで否定してから新しいのを渡す
- 復唱のコンテキスト消費は誤差。食っているのはファイル読み込みとツール出力
- 全体は長くしない。常駐は、ずっと変わらないものだけ
振る舞いが安定しない、と感じるときと、決めたはずのことが戻ってくる、と感じるときでは、打つ手が違います。同じ「守ってくれない」に見えるのですが、層が別なので。役に立ったらストックして、CLAUDE.md を組み直すとき見返してください。
ふだんはraplsworks.comで、WordPressプラグイン開発やClaude Codeまわりのことを書いています。