はじめに

CLAUDE.md は、セッションのたびに全文が Claude に読み込まれます。書いた分だけコンテキストを消費し、量が増えるほど肝心なルールが埋もれて守られなくなります。「詳しく書くほど良い」は成り立ちません。

そこで必要になるのが、「書くか、書かないか」の判断基準です。

先日、肥大化したルールファイルを整理したので、書くときに気をつけることを公式ドキュメントをもとにまとめます。

判断基準

公式ベストプラクティスが示す判断基準は、「これを削除すると Claude が間違いを犯すか」を1行ずつ問うことです。ミスしないなら削除します。

つまり、消しても Claude がミスしないルールは、書いてある意味がないということです。残す価値があるのは、Claude が推測できないことだけです。

例えば「配列の変換には map を使う」は書く価値がなく、「日付処理は必ず自前の DateUtil を通す」は書く価値があります。

この問いは見直しのときだけでなく、書くときにも使えます。「これを書かないと Claude はミスするか」と裏返して問えば、書く前に不要なルールに気づけます。

書く価値がないルール

消しても Claude がミスしないルールには、次のようなものがあります。

一般知識・チュートリアル

ライブラリの基本的な使い方や、言語の標準的な文法・構文の説明です。Claude が最初から知っていることは、消しても生成されるコードが変わりません。

他の文書に書いてあること

同じルールが複数の規約文書に書かれていると、いつか片方だけが更新されて食い違います。残す場合も、書き写すのではなく「詳細は◯◯を参照」といった1行にします。

同じ文書内の重複

方針を変えたとき、古い記述を消し忘れると、同じファイルの中で指示が食い違います。
公式ドキュメントは「2 つのルールが互いに矛盾している場合、Claude は 1 つを任意に選択する可能性があります」と警告し、CLAUDE.md や rules を定期的に確認して、古い指示や矛盾する指示を削除することを勧めています。

書く価値があるルール

書く価値があるのは、コードや一般知識からは推測できないものです。公式ベストプラクティスは、CLAUDE.md に含めるものとして次を挙げています。

Claude が推測できない Bash コマンド
デフォルトと異なるコードスタイルのルール
テストの指示と、使うテストランナー
リポジトリの運用ルール（ブランチ命名、PR の規約）
プロジェクト固有のアーキテクチャ上の決定
開発環境の癖（必須の環境変数など）
よくある落とし穴や、自明でない挙動

CLAUDE.md は AI に読ませるコメントであり、価値の判断基準は人間向けのコードコメントと同じ「推測できないことだけを書く」です。

どこに書くか

書くと決めたルールには、次の選択があります。どこに書くかです。置き場所によって読み込まれ方が変わるため、これもコンテキストの消費に関わります。

rules と読み込まれ方

置き場所の代表が .claude/rules/ です。指示をトピックごとの複数ファイルに分けて、保守しやすく整理するための公式の仕組みで、書くこと・書かないことは CLAUDE.md と同じ基準で考えられます。

ルールの読み込まれ方は2種類あります。

毎回読み込み：プロジェクトルートの CLAUDE.md と、paths 指定のない .claude/rules/*.md。起動時に全文が読み込まれる。公式は CLAUDE.md について 200行以下を推奨
条件付き読み込み：ファイル冒頭の --- で囲むメタデータ欄（frontmatter）に paths: を書いた rules。マッチするファイルを Claude が読んだ時点でコンテキストに入る
```
---
paths:
  - '**/*.test.ts'
---
```

条件付き読み込みでも、コンテキストの消費がなくなるわけではありません。対象ファイルを扱うときにはファイル全体が読み込まれます。テスト規約なら、テストに触れた時点で丸ごとです。どの読み込まれ方でも、コンテキストの消費は書いた量に比例します。

分割の判断

分割で読み込みが減るのは、読み込まれるタイミングが分かれるときだけです。同じ paths: '**/*.test.ts' を持つ3ファイルに分けても、テストを編集する瞬間には3つとも同時に読み込まれ、合計行数は1ファイルのときと同じです。@path インポートで別ファイルへ分けた場合も、インポート先は起動時に読み込まれるため、コンテキストは減りません。

公式が rules に示している分け方の単位は、行数ではなく「1ファイル1トピック」です。testing.md や api-design.md のように、1つのファイルには1つの主題の規約だけを入れ、ファイル名を見れば何の規約か分かるようにします。条件付き読み込みにしたうえで、残った内容が1つの主題に収まっているなら、行数を理由に分割する必要はありません。

行数が気になったときの順番は、先に削る、それでもスコープが分かれるなら分割です。逆にすると、重複や一般知識が複数ファイルに散らばって、直しにくくなります。

CLAUDE.md と rules の使い分け

実際にスコープが分かれる場合は、置き方が2つあります。違いは規約ファイルを置く場所です。

my-project/
├── CLAUDE.md
├── .claude/
│   └── rules/
│       └── testing.md     # 規約を1箇所に集める（paths で対象を指定）
└── src/
    └── api/
        ├── CLAUDE.md      # 規約をコードのそばに置く
        └── users.ts

規約をコードのそばに置いて一緒に管理するなら各ディレクトリの CLAUDE.md、規約を1箇所に集めたい場合や、離れた複数のパスに同じルールを当てる場合は paths を指定した rules が向きます。

skills という選択肢

複数ステップの手順や、ときどきしか使わないドメイン知識は、ルールではなく skills に置くのが公式の推奨です。

skills で起動時に読み込まれるのは名前と説明だけで、本文は依頼に関連すると Claude が判断したときか、名前で呼び出されたときに読み込まれます。条件付き読み込みの条件がファイルパスで決まる rules に対し、skills は何を頼まれたかで決まります。

チェックリスト

書くとき

それは Claude が知らないことか（一般知識なら書かない）
既に他の文書やヘルパーにないか（あるなら参照の1行にする）
それはルールか、手順か（複数ステップの手順やドメイン知識なら skills へ）
常に必要か、特定のファイルを扱うときだけ必要か（後者なら paths 付きの rules へ）

見直すとき

消したら Claude がミスするか（しないなら消す）
同じ話題が2箇所に書かれていないか（片方だけ更新されて食い違う）
分割するなら、読み込まれるタイミングが分かれるか（分かれないなら削る方が先）

参考