.claude/rules/（ドットクロード・ルールズ）

CLAUDE.md を使っていて、内容が大きくなってきた人向け

プロジェクトが育つと、Claude Code に覚えさせる指示を書いた CLAUDE.md がどんどん長くなります。フロントの書き方ルールもAPIの作法も全部1ファイルに詰め込むと、200行を超えたあたりからClaudeの守りが甘くなる。公式も「200行以内を狙え」と書いています。.claude/rules/ は、その太りすぎた指示書をトピックごとのファイルに割って、しかも「このファイルを触ったときだけ読む」みたいな条件まで付けられる仕組みです。

先に紛らわしい言葉を1つ片付けます。ここで言う「ルール」は CLAUDE.md を分割した指示ファイルのこと。権限まわりの「許可/拒否ルール」、つまり allow/deny ルール とは別物です。同じ「ルール」でも意味が全然違うので、頭の中で分けておいてください。

噛み砕くと

新しい職場の分厚いマニュアルを思い浮かべてください。全部1冊にすると分厚すぎて誰も読まない。だから「経理の人向け」「開発の人向け」と章で分けて、棚に並べておく。.claude/rules/ はこの「章分け」にあたります。

さらに気が利いていて、「APIのファイルを開いた人にだけ、API向けの章を自動で手渡す」ことができる。読む人が必要な章だけ受け取るので、机の上が散らからない。これが paths という指定の正体です。

分けるだけじゃない。渡すタイミングまで決められる。ここが肝です。

大事な前提：分割しただけではコンテキストは軽くならない

よくある勘違いを先に潰します。「CLAUDE.md をファイルに割れば、Claudeが読む量が減って動きが軽くなる」——これは半分だけ正解です。

公式の仕様はこうです。paths という指定を付けないルールファイルは、起動のたびに無条件で全部読み込まれます。しかも .claude/CLAUDE.md と同じ優先度で。つまり、ただ3ファイルに割っただけだと、読み込まれる総量は CLAUDE.md に全部書いていた頃と変わりません。見た目が整理されるだけ。

読み込む量を本当に減らせるのは、paths で「このファイルを触ったときだけ読む」とスコープを切ったときだけです。ここを外すと「分けたのに軽くならない」で終わります。

「task-manager」を例に、実際の手順を見る

題材は task-manager というアプリにします。画面側がReact＋TypeScript、裏側がAPIという、よくある混在プロジェクト。.claude/CLAUDE.md にフロントの作法もAPIの作法も全部書いた結果、220行に膨らんで守りが甘くなってきた、という状態から始めます。

ステップ1: いまの CLAUDE.md がどう太っているか見る

開いてみると、こんな感じで雑多なルールが1ファイルに同居しています。

.claude/CLAUDE.md（220行）

## コードの書き方
- インデントはスペース2つ
- 変数名はキャメルケース

## テストの作法
- 変更を保存する前に npm test を必ず通す

## API の作法（src/api 配下だけの話）
- すべてのエンドポイントで入力チェックを入れる
- エラー応答は共通フォーマットに揃える

「API の作法」は src/api 配下を触るときしか関係ないのに、起動のたびに毎回読まれている。ここがムダです。

ステップ2: rules フォルダを作って、常時必要なものを切り出す

まず .claude/rules/ というフォルダを手動で作ります。Claudeが勝手に作ってくれるわけではないので、自分で mkdir .claude/rules と打つか、フォルダ作成の操作で用意してください。中に置けるのは拡張子が .md のファイルだけです。そのうえで、どのファイルを触っても効いてほしい共通ルールをここに移します。

task-manager/
├── .claude/
│   ├── CLAUDE.md           # プロジェクト全体の中心指示
│   └── rules/
│       ├── code-style.md   # コードの書き方
│       └── testing.md      # テストの作法

code-style.md と testing.md は paths を付けません。付けないと CLAUDE.md と同じ扱いで、起動時に常時読まれます。コードの書き方やテストの作法は、フロントでも裏側でも守ってほしいので、これでいい。

ステップ3: API 専用ルールに paths を付ける（ここが本題）

API の作法は src/api 配下を触るときだけでいい。なので api-design.md として独立させて、ファイルの先頭に paths を書きます。

.claude/rules/api-design.md

---
paths:
  - "src/api/**/*.ts"
---

# API Development Rules

- All API endpoints must include input validation
- Use the standard error response format
- Include OpenAPI documentation comments

先頭の --- で挟まれた部分が frontmatter という設定欄。ここに paths で「src/api 配下の .ts ファイル」と書いておくと、Claudeがそのファイルを読んだ瞬間にこのルールが効きます。逆にフロントのファイルしか触っていない間は、このルールは黙ったまま。コンテキストを食いません。

ステップ4: ここで初心者がやりがちな勘違い

paths を付けたルールは「Claudeが対象ファイルを読んだ瞬間」に効きます。毎回の操作で発火するわけではありません。公式も「マッチするファイルを読んだときに効く、毎回のツール使用で効くのではない」と明記しています。

つまり、まだ src/api のファイルを1つも開いていない段階では、API向けルールは効いていない。「書いたのに守ってくれない」と感じたら、まずClaudeがそのファイルに触れたかを疑ってください。

ステップ5: /memory でいま何が読まれているか確認する

狙い通りに読み込まれているかは、セッション中に /memory を叩けば一覧で見えます。

/memory

これで、いま読み込まれている CLAUDE.md と rules ファイルの一覧が出ます。code-style.md と testing.md は起動時から常時このリストに載っています。api-design.md については、Claudeが src/api 配下のファイルを読んだあとに /memory をもう一度開くと、リストに追加されているか確認できます。追加されていれば、そのルールがいま効いている証拠です。

ステップ6: ルールが効いているか、実際の返答で確認する

src/api/handlers/users.ts を Claude に渡して「このハンドラのエラー処理を直して」と頼んだとします。api-design.md が読み込まれていれば、Claudeは「エラー応答は共通フォーマットに揃える」という作法を踏まえた修正を返します。

私: src/api/handlers/users.ts のエラー処理を直してください。

Claude: users.ts を確認しました。api-design.md のルールに従って、
        エラー応答を共通フォーマットに統一する形で直します。

この「api-design.md のルールに従って」という一言が、ルールが読み込まれていた証拠になります。もし読まれていなければ、Claudeはルール名に触れず、自己流の形式で直してきます。

ステップ7: フロント専用ルールもスコープしておく（任意）

同じ要領で、Reactコンポーネント向けのルールも切り分けられます。複数の拡張子をまとめて指定したいときは、波カッコの展開が使えます。

---
paths:
  - "src/**/*.{ts,tsx}"
---

# フロントエンドのルール
- コンポーネントは1ファイル1つ
- 状態管理は既存の方針に揃える

{ts,tsx} と書くと .ts と .tsx の両方にマッチします。1行で2種類のファイルを拾えるので、いちいち2行に分けなくていい。

つまり .claude/rules/ は何をしてくれるのか

• やってくれる: 長くなった CLAUDE.md をトピック別ファイルに分けて、チームで保守しやすくする。さらに paths で「対象ファイルを触ったときだけ読む」条件読み込みができる
• やってくれない: paths を付けない分割だけで読み込み量を減らすこと。スコープを切らなければ起動時に全部読まれ、総量は CLAUDE.md 全部入りと同じ
• 意味が薄い場面: 指示が数十行で収まる小さなプロジェクト。分ける手間のほうが大きい。常時は不要で特定タスクのときだけ使う長い手順書は、rulesよりskillsのほうが軽い

使いどころ3シナリオ（具体題材で再現）

シナリオ1: フロントと裏側が混在する task-manager で、APIの作法だけ重くしたいとき

画面側のファイルを触っているときに、API向けの細かい作法まで毎回読まれるのはムダです。api-design.md に paths: ["src/api/**/*.ts"] を付けておけば、Claudeが src/api のファイルを開いたときだけ「入力チェックを入れろ」「エラー応答を共通フォーマットに揃えろ」が効きます。フロントのコンポーネントをいじっている間は黙ったまま。会話の余白を裏側の作法で埋めずに済みます。

シナリオ2: 料理ブログのサイトで、テストの書き方ファイルだけ常時効かせたいとき

レシピ投稿サイトを作っていて、「テストは必ず通してから変更を保存する」みたいな共通ルールがあるとします。これは画面でも裏側でも守ってほしいので、testing.md には paths を付けません。付けなければ CLAUDE.md と同じ優先度で起動時に毎回読まれます。何を触っていても効いてほしいルールは、あえてスコープを切らない。これが正しい使い分けです。

シナリオ3: 複数の自作プロジェクトで、自分好みの書き方を共通化したいとき

「インデントはスペース2つが好き」みたいな、プロジェクトに依存しない個人の好みは ~/.claude/rules/ に置けます。ここに置いたルールは、そのパソコンで開く全プロジェクトに効きます。仕事用とは別に自分の癖を1か所で管理できる。なお、個人ルールはプロジェクトのルールより先に読まれます。同じ話題でぶつかったら、後に読まれるプロジェクト側が勝ちます。

初心者が踏みやすい落とし穴

• 分割すれば軽くなる、は誤解。paths なしのルールは起動時に無条件で全部読まれ、.claude/CLAUDE.md と同じ優先度。読み込み総量は CLAUDE.md に全部書くのと変わりません。軽くしたいなら必ず paths でスコープを切ること
• paths は「対象ファイルを読んだ瞬間」に効く。毎回の操作で発火するわけではない。まだ対象ファイルに触れていない段階では、そのルールは効いていません
• 個人ルールとプロジェクトルールの優先順を逆に覚えがち。~/.claude/rules/ の個人ルールが先に読まれ、プロジェクトのルールが後。矛盾したら後に読まれるプロジェクト側が優先されます
• 常時不要な手順書まで rules に入れてしまう。特定タスクのときだけ使う長い手順は、起動時に常駐させない skills のほうが軽い。rulesは「常時、または対象ファイルを開いたときに効いてほしい指示」向けです
• 1ファイルに複数トピックを詰める。1ファイル1トピックが原則。testing.md api-design.md のように、ファイル名で中身が分かるようにします。サブフォルダに入れても再帰的に拾われます
• 効いているか確かめずに悩む。読み込まれているか不安なら /memory でロード一覧を確認。もっと細かく「いつ・なぜ読まれたか」まで追いたいときは InstructionsLoaded フックでログを取れます
• 権限の許可/拒否ルールと混同する。ここで言うルールは「指示を書いたファイル」のこと。コマンドの実行可否を決める権限ルールとは別物です

書き方

.claude/rules/<トピック名>.md
（ファイル先頭に条件読み込みの paths を書く場合）
---
paths:
  - "src/api/**/*.ts"
---

やってみるとこうなる

入力

.claude/rules/api-design.md を作り、先頭に
---
paths:
  - "src/api/**/*.ts"
---
と書いて、その下に API 向けの作法を並べる

出力例

Claudeが src/api 配下の .ts ファイルを開いたときだけ、その作法が読み込まれて効く。フロント側のファイルだけ触っている間は読み込まれず、会話の余白を消費しない。/memory を叩くと、いま読み込まれている CLAUDE.md と rules ファイルの一覧が確認できる。

関連項目

• CLAUDE.md
• CLAUDE.md Hierarchy（クロード・エムディー・ハイアラーキー）
• Context Window（コンテキストウィンドウ）
• Skills / Custom Commands（スキル／カスタムコマンド）
• Allow / Deny Rules（アロウ・デナイ・ルールズ）

公式ドキュメント

https://code.claude.com/docs/en/memory