この記事で書くこと
Claude Codeを毎日の仕事で使うようになって1年以上になります。CLAUDE.md（プロジェクトのルールファイル）に「これは守ってほしい」と書いても、実際には守られなかったり、私自身が後から見返して「これじゃ伝わらないな」と気づいたりすることが何度もありました。
この記事では、そうやって書き直しを繰り返す中で見えてきた「書いたのに効かないルール」と「ちゃんと機能するルール」の違いを、6つの観点に整理して紹介します。CLAUDE.mdに限らず、Cursorの.cursorrulesやその他のAIエージェント向け指示書にも応用できる内容です。
1. ルールは、それが使われる場所の近くに書く
ルールを書くとき、つい「まとめて一箇所に」書きたくなります。プロジェクト概要の総論セクション、心構えのまとめ、注意事項リストの一項目。しかしその場所は、実際にAIがその行動を取る瞬間からは遠く離れています。作業の真っ最中に、離れた場所に書かれた注意書きをわざわざ思い出しに戻ることは、人間でもAIでも起きにくいものです。
効かない例：ファイル冒頭の「基本方針」セクションの隅に「作業中に不要になった一時ファイルは整理すること」と一文だけ書いてある。読まれてはいるはずなのに、実際の作業フェーズでは思い出されない。
効く例：デプロイ手順を書いたセクションそのものの中に、「デプロイ完了後、一時的に作成したスクリプトを削除する」という一行を埋め込む。手順を1つずつ実行していく過程で自然と目に入るため、思い出す必要すらなくなる。
2. 禁止だけで終わらせず、代わりにすべきことまで書く
「〇〇してはいけない」という禁止事項は、境界がはっきりしているケースでは機能します。しかし実際の作業には、禁止に該当するかどうか微妙なケースが必ず出てきます。そのとき禁止だけが書かれていると、判断の手がかりがなく、結局はAIが自己流の解釈で進めてしまいます。
効かない例：「ユーザーの確認なしに破壊的な操作を行わないこと」。では確認が取れない・返事が来ない場合はどうすればいいのかが書かれていない。
効く例：「ユーザーの確認なしに破壊的な操作を行わないこと。確認が取れない場合は、その操作をスキップして他の作業を進め、完了報告にスキップした理由を明記する」。禁止の先にある行動まで指定されているので、境界のケースでも迷いません。
3. ルールには理由を添える
理由のないルールは、想定されていたケースの外に出た瞬間に機能しなくなります。逆に「なぜそれが必要か」がわかっていれば、少し形の違う似たケースにもAIが自分で応用して判断できます。ルールを丸暗記させるのではなく、判断の物差しそのものを渡すイメージです。
効かない例：「金曜の夕方以降は大きな変更を行わないこと」。理由が書かれていないので、「祝日の前日は？」「担当者が長期不在の期間は？」といった似たケースに応用できません。
効く例：「金曜の夕方以降に大きな変更を行うと、週末に問題が起きても対応できる人が少ない。だから対応できる人を確保できないタイミングでの変更は避ける」。理由が「対応できる人がいない状態を避けること」だとわかれば、祝日前や長期休暇前にも同じ判断を自然に適用できます。
4. 同じルールを複数の場所に書かない
似た内容のルールを、目につきやすいという理由で複数のファイルに書いてしまうことがあります。一見親切に見えますが、後でどちらか一方だけが更新されると、2つの資料の内容がずれてしまい、AIがどちらを信じればいいのかわからなくなります。
CLAUDE.mdの運用では、ルールの「正本」をどこか1箇所に決め、他の場所からはそこへのリンク（または参照の一文）だけを置くようにすると、更新のたびに矛盾が生まれる心配がなくなります。プロジェクトが大きくなるほど、この一元管理は効いてきます。
5. グレーゾーンのケースで実際に試してみる
ルールを書き終えたとき、多くの場合は「明らかにOKな例」と「明らかにNGな例」しか思い浮かべていません。それだけで安心してしまうと、実際に運用が始まってから、想定していなかった境界線上のケースに毎回悩まされることになります。
ルールを確定させる前に、あえて判断が割れそうなケースを1つか2つ想定し、「このルールの文面だけで、AIが迷わず判断できるか」を実際に試してみるのが有効です。私は新しいルールを書いたら、少し意地悪な質問をAI自身に投げて「このケースはどう判断する？」と聞くようにしています。想定外の解釈が返ってきたら、その場でルールを直します。
6. あいまいな指示語を、具体的な対象と基準に置き換える
「これ」「それ」「適切に」「必要に応じて」といった言葉は、書いている本人には具体的なイメージがあっても、後で読む側（AIを含む）には何を指しているのか伝わりません。特に「適切に」は、判断の基準そのものをAI側に丸投げしてしまう言葉です。
効かない例：「古くなったファイルは適切に整理してください」。「古くなった」がいつからを指すのか、「整理」が削除なのか移動なのかが何も決まっていません。
効く例：「作業用フォルダの中で、最終更新日から30日以上経過したファイルは、削除ではなくアーカイブ用フォルダへ移動する」。対象・基準・行動が、すべて具体的に決まっています。
まとめ
| 原則 | 効かないルールの例 | 効くルールへの直し方 |
|---|---|---|
| 行動の近くに書く | 総論セクションの隅にある注意書き | 手順そのものの中に直接埋め込む |
| 代替行動とセットにする | 「〇〇してはいけない」だけの禁止 | 「代わりに△△する」まで明記する |
| 理由を添える | 理由抜きの断定的なルール | 「なぜ必要か」を一文添え、応用を効かせる |
| 正本を1つにする | 同じ内容を複数ファイルに重複記載 | 正本を1箇所に決め、他は参照にする |
| グレーゾーンで試す | 明らかな例だけで安心する | 境界線上のケースを実際にAIへ投げて検証する |
| 指示語を具体化する | 「これ」「適切に」等のあいまいな表現 | 具体的な対象・数字・条件に置き換える |
CLAUDE.mdは一度書いて終わりのファイルではなく、AIが実際に迷った箇所を見つけるたびに育てていくものだと感じています。曖昧さを「AI側の推測力」で埋めることを前提にしたルールは、いつか必ずすれ違いを生みます。ルールを書くこと自体より、そのルールが実際に機能しているかを確かめ続けることのほうが、地味に重要な作業だと思います。
普段はAI（Claude）に日々の仕事を任せながら、その記録を「クジラとAIと」という日記ブログにも書いています。よろしければそちらもどうぞ。