CLAUDE.md を「雑に長文で埋める箱」だと思っていると、だいたい損をする。効くのは、毎回ブレると困る前提だけだ。逆に、巨大な社内規約や操作マニュアルを丸ごと押し込んでも、Claude Code はそこを丁寧に読み上げる執事にはならない。
Claude Code でいう CLAUDE.md は、リポジトリや作業フォルダに置く指示メモだ。Claude Code がその場所で作業するときの癖付けに使う。ここに何を書けば手戻りが減るか、何を書いても効きが鈍いかを分けておくと、コンテキストの無駄食いがかなり減る。
まず効くのは、「この場所では何を優先するか」を短く固定することだ。たとえば、出力の形式、触ってよい範囲、依頼が曖昧なときの確認順、勝手に壊してはいけないもの、よく使うコマンドやディレクトリ構成などだ。逆に効きにくいのは、毎回変わる具体的な作業指示、長すぎる背景説明、抽象的なお作法の羅列である。そこを混ぜると、肝心のルールが埋もれる。
最初に押さえるべきなのは、CLAUDE.md は「長い説明書」ではなく「現場の癖」を書く場所だという点だ。たとえば、こんな書き方はかなり効く。
# このリポジトリでの作業ルール
- まず `README.md` と `docs/` を確認する
- 変更は最小限にする
- 既存の命名規則を壊さない
- 大きい削除や移動の前に必ず確認を取る
- テストがある場合は、変更に関係する範囲だけ先に実行する
- 迷ったら推測で進めず、質問する
この程度でいい。長い理屈はいらない。Claude Code にとって大事なのは「この場所では何を守るべきか」が一目でわかることだ。筆者は最初、背景事情まで丁寧に書きたくなって、三十行くらいの説明を入れてしまったことがある。結果、実際に欲しい「何を触ってよいか」の指示が薄まり、質問が増えた。そこは痛い。
もう少し踏み込むなら、ファイル整理や文書作成でも CLAUDE.md は効く。たとえば、案件ごとのフォルダで書面を整えるなら、「このフォルダでは原本を残す」「ファイル名は日付_案件名_版数で統一」「勝手にPDF化しない」「要約だけでなく差分も残す」といった運用を明記しておくと、後で探し回る手間が減る。ディスク削減なら、「キャッシュ候補はここ」「削除前に一覧を出す」「巨大ファイルでも中身を見ずに消さない」と書いておくと事故が少ない。人間の補助としてかなり使える。
# 書類整理のルール
- 原本ファイルは移動せず、整理用フォルダにコピーを作る
- 変更前に、対象ファイル一覧を出す
- 名前を変えるときは元ファイル名もログに残す
- 相談なしに削除しない
- PDF は必要と言われたときだけ作る
ここで効くのは、手順そのものではなく「やってはいけないこと」だ。Claude Code は指示がないと、便利そうな方向に動こうとする。そこが人間と少し違う。便利さが裏目に出ると、フォルダをきれいにしたつもりで必要な中間ファイルまで消してしまう。そういう事故を防ぐには、禁止事項を短く切って書くのがいちばん強い。
一方で、書いても効きにくいものがある。代表は、毎回変わる案件固有の事情だ。たとえば「この顧客は今回だけこの形式で出したい」「今回は例外的にこのフォルダだけ触る」といった話は、CLAUDE.md に固定するとすぐ腐る。そういう内容は、その都度の依頼文で渡したほうがいい。CLAUDE.md は常設ルール、個別依頼は作業指示だ。ここを混ぜると、次回以降に古い条件が残ってややこしくなる。
効きにくいもののもう一つは、広すぎる理想論だ。「品質を高く保つ」「丁寧に確認する」「最善を尽くす」といった文は、気持ちはわかるがあまり意味がない。Claude Code に必要なのは、どう確認するか、何を確認したら止まるか、どのファイルを優先するか、どこまで自動で進めてよいかだ。抽象語は、具体策がないとただの飾りになる。
# 望ましい進め方
- 変更前に関連ファイルを先に読む
- 影響範囲が広いときは一度止まって確認する
- 生成物がある場合は、既存のものを壊さず追記する
この手の文も、悪くはないが、効きは弱い。なぜなら「影響範囲が広い」の判断基準が曖昧だからだ。ここを本当に効かせたいなら、たとえば「3ファイル以上をまたぐ変更は確認する」「削除、移動、上書きは確認する」といった線引きに落とすほうがいい。
- 3ファイル以上をまたぐ変更は、先に方針を確認する
- 削除、移動、上書きは実行前に確認する
- 新しい依存関係の追加は提案だけにとどめる
こういう、動作に結びつくルールは強い。逆に、自然言語で長々と書いた「お願い」は弱い。Claude Code に遠慮は通じない。通じるのは、境界線だ。
実運用でいちばん効くのは、CLAUDE.md を「作業のハンドブック」ではなく「判断の基準表」にすることだ。たとえばこんな分け方がしやすい。
# この作業場の基準
## まず守ること
- 既存の構成を勝手に変えない
- 破壊的な操作は確認する
## 迷ったら聞くこと
- どの案を採るか分岐する場合
- 既存ファイルのどれを正本にするか決める場合
## そのまま進めてよいこと
- 誤字修正
- 参照の追加
- 明らかな軽微修正
このくらいの粒度なら、Claude Code はかなり動きやすい。読み手の人間にとってもわかりやすい。長い説明より、この線引きのほうがずっと役に立つ。
注意したいのは、CLAUDE.md に「全部」を入れようとすると逆効果になることだ。長くなりすぎると、読むコストが上がるだけでなく、古いルールが残りやすい。筆者は一度、共通ルールと案件ルールを同じ CLAUDE.md に詰め込んで、しかも更新し忘れた。すると、前の案件の命名規則が次の案件にも残り、ファイル整理のつもりが余計に散らかった。あれは地味にしんどい。固定したいルールだけを置く、という割り切りが必要だ。
もう一つ、効きにくさの原因として多いのが、依頼文との役割分担ミスだ。CLAUDE.md には常設ルールを書く。作業ごとの条件は、その場で渡す。たとえば、同じフォルダでも「今日は要約だけ」「今日は差分も作る」「今日は削除候補の洗い出しだけ」といった違いは、CLAUDE.md に入れず毎回の指示で書くべきだ。
このフォルダのルールは CLAUDE.md に従ってください。
今回は削除はせず、重複候補だけ一覧化してください。
一覧にはファイルサイズと更新日も含めてください。
この分け方をすると、CLAUDE.md は短く保てるし、毎回の依頼は明確になる。結果として、Claude Code の動きも安定しやすい。
実務でのコツは、最初から完璧な CLAUDE.md を作らないことだ。最初は「守ってほしい境界線」を3〜5個だけ書く。使ってみて、毎回聞かれて困る点や、勝手に進められて困った点を足す。これがいちばん崩れない。逆に、最初から大百科にすると、書いた本人も読まない。
Claude Code を使うなら、CLAUDE.md は「優先順位を固定する薄いメモ」にしておくのが正解だ。効くのは、境界、例外、命名、削除や上書きの扱い、確認のタイミング。効きにくいのは、毎回変わる事情、抽象的な美徳、長い背景説明だ。ここを分けておくだけで、手戻りはかなり減る。
次にやるなら、CLAUDE.md を一度見直して、「毎回書かなくていいこと」だけを残すのがいい。余計な説明を削るほど、Claude Code は仕事しやすくなる。