Claude Code: CLAUDE.md vs .claude/rules/ の実践的な使い分け

はじめに

ども！龍ちゃんです。前回「Claude Code→GitHub Copilot移行で使える設定ファイル6つの対応表」で両ツールの設定ファイルを整理しました。

その記事では、特定のファイルにだけルールを適用する「条件付き適用」について、こう整理しました。

GitHub Copilot は *.instructions.md で glob パターンを指定できます。では Claude Code は？ 実は .claude/rules/ で、同じことができるようになりました。

.claude/rules/ を使えば、肥大化した CLAUDE.md を複数ファイルに分割できます。さらに paths: frontmatter で適用範囲も制御可能です。

今回は、ディレクトリ別 CLAUDE.md との比較を通じて .claude/rules/ の使い方を学んでいきます。

この記事の結論

先に結論をお伝えします。

基本方針: .claude/rules/ でルールを一元管理しつつ、特殊なディレクトリだけ CLAUDE.md を使う「ハイブリッドアプローチ」がおすすめです。

以下、この結論に至った理由を詳しく解説していきます。

関連記事

中央集権 vs 分散管理とは

まず、この記事で使う用語を整理します。

注意: 「中央集権」「分散管理」は公式の用語ではなく、僕が整理のためにつけた呼び方です。

• 中央集権: ルールを一箇所に集約して管理（.claude/rules/）
• 分散管理: ルールをプロジェクト全体に分散して配置（ディレクトリ別 CLAUDE.md）

それぞれ詳しく見ていきましょう。

中央集権：.claude/rules/

ルールを 一箇所に集約 して管理する方法です。

project/
└── .claude/
    └── rules/
        ├── code-style.md      # コードスタイル
        ├── frontend.md        # フロントエンド固有
        └── backend.md         # バックエンド固有

特徴:

• すべてのルールが .claude/rules/ に集まる
• 「ルールどこ？」→「.claude/rules/ 見て」で済む
• paths: frontmatter で適用範囲を制御

分散管理：ディレクトリ別CLAUDE.md

ルールを プロジェクト全体に散らばらせる 方法です。

project/
├── CLAUDE.md              # ルート
├── frontend/
│   └── CLAUDE.md          # フロントエンド固有
├── backend/
│   └── CLAUDE.md          # バックエンド固有
└── docs/
    └── CLAUDE.md          # ドキュメント固有

特徴:

• 各ディレクトリに CLAUDE.md が存在
• そのディレクトリで作業する時だけ読み込まれる
• プロジェクト全体を探す必要がある

比較表

チーム開発なら中央集権

チーム開発では、中央集権（.claude/rules/） をおすすめします。

理由1: PRレビューがしやすい

ルールが一箇所にあると、変更点が明確です。

# PRの差分

.claude/rules/code-style.md | 3 ++-
.claude/rules/security.md   | 5 +++++
2 files changed, 7 insertions(+), 1 deletion(-)

分散管理だと、こうなります：

# PRの差分

frontend/CLAUDE.md    | 2 ++
backend/CLAUDE.md     | 3 +++
api/v1/CLAUDE.md      | 1 +
api/v2/CLAUDE.md      | 1 +
services/auth/CLAUDE.md | 2 ++
5 files changed, 9 insertions(+)

「どのCLAUDE.mdがどこにあるか」を把握していないと、レビューが大変です。

理由2: 新メンバーのオンボーディング

新メンバー: 「このプロジェクトのルールってどこにありますか？」

中央集権: 「.claude/rules/ を見てください」
分散管理: 「えーと、各ディレクトリにCLAUDE.mdがあって...」

理由3: ルールの重複・矛盾を防げる

分散管理では、同じルールを複数のCLAUDE.mdに書いてしまうことがあります。

# frontend/CLAUDE.md
コンポーネントは関数コンポーネントで書いてください。

# frontend/components/CLAUDE.md
Reactコンポーネントは関数形式を使用してください。  ← 重複！

中央集権なら、rules/react.md に一本化できます。

paths: frontmatter の使い方

「でも、フロントエンドとバックエンドで違うルールを適用したい」という場合は、paths: を使います。

注意: glob パターンは必ず引用符（"）で囲んでください。* や { で始まるパターンは YAML の予約文字として解釈されるため、引用符がないとパースエラーになります。

# .claude/rules/frontend.md
---
paths:
  - "src/frontend/**/*"
  - "src/components/**/*"
---

# フロントエンドルール

- React は関数コンポーネントを使用
- スタイルは Tailwind CSS
- 状態管理は Zustand

# .claude/rules/backend.md
---
paths:
  - "src/api/**/*"
  - "src/services/**/*"
---

# バックエンドルール

- FastAPI を使用
- 型ヒントは必須
- Pydantic でバリデーション

これで、該当ディレクトリで作業する時だけルールが適用されます。

特殊なディレクトリではCLAUDE.mdが生きる

「じゃあ、ディレクトリ別CLAUDE.mdは不要？」

いえ、特殊なディレクトリでは CLAUDE.md が有効です。

特殊なディレクトリとは

「他のコードとは性質が違う」ディレクトリです。

例1: docs/CLAUDE.md

docs/ ディレクトリは、他のMarkdownファイルとは性質が違います。

• コード内のコメントやREADME → 開発者向け、簡潔に
• docs/ 内のMarkdown → 読者向け、丁寧に説明

# docs/CLAUDE.md

このディレクトリはブログ記事・ドキュメントの執筆用です。

## 他のMarkdownとの違い

- README.md → 開発者向け、簡潔に
- docs/ 内 → 読者向け、丁寧に説明

## 執筆ルール

- 文体：ですます調
- 見出し：H2から開始
- コードブロック：必ず言語を指定
- 画像：alt テキストを必ず含める

## ディレクトリ構成

- `docs/article/` - ブログ記事の下書き
- `docs/research/` - 調査結果
- `docs/specs/` - 仕様書（変更不可）

これは paths: で指定するより、docs/CLAUDE.md として置いた方が直感的です。

例2: experiments/CLAUDE.md

実験的コードは、品質基準が通常と異なります。

# experiments/CLAUDE.md

このディレクトリは実験的なコード用です。

## 通常のコードとの違い

- テストは不要
- ドキュメントは最低限でOK
- 動けばいい（リファクタリング不要）

## 注意

- 本番コードにコピペしないこと
- 実験が成功したら、ちゃんと書き直して別ディレクトリへ

なぜ paths: より CLAUDE.md が良いのか

1. 文脈が自己完結する: そのディレクトリを開けば、ルールが分かる
2. READMEと同じ感覚: 人間にとっても分かりやすい
3. 特殊性が明示される: 「ここは他と違う」が伝わる

GitHub Copilot との比較

ここで、GitHub Copilot との設計思想を比較してみましょう。

対応関係

構文の比較

Claude Code:

# .claude/rules/api.md
---
paths:
  - "src/api/**/*.ts"
---

# APIルール

GitHub Copilot:

# api.instructions.md
---
applyTo: "src/api/**/*.ts"
---

# APIルール

ほぼ同じ思想ですね。キーが paths: か applyTo: かの違いだけ。

両ツールの収束傾向

前回記事でも触れましたが、個人的には Claude Code と GitHub Copilot の設定方法は集約されつつあるのでは？と感じています。

• 条件付き適用（glob パターン）
• 複数ファイルへの分割
• Markdownベースの設定

片方を学べば、もう片方にも応用できます。

推奨構成：ハイブリッドアプローチ

まとめると、こうなります：

project/
├── CLAUDE.md                 # プロジェクト全体の基本方針（薄く）
├── .claude/
│   └── rules/
│       ├── code-style.md     # コードスタイル（グローバル）
│       ├── frontend.md       # フロントエンド（paths指定）
│       ├── backend.md        # バックエンド（paths指定）
│       └── security.md       # セキュリティ（グローバル）
├── docs/
│   └── CLAUDE.md             # ドキュメント固有（特殊）
└── experiments/
    └── CLAUDE.md             # 実験用（特殊）

判断フロー

まとめ

ポイント:

1. 基本は中央集権: .claude/rules/ でルールを一元管理
2. 特殊なディレクトリだけ分散: docs/、experiments/ など
3. 両者は補完関係: 排他的に選ぶ必要はない

Claude Code と GitHub Copilot、どちらも「中央管理 + 条件付き適用」の方向に進化しています。今のうちにこの設計パターンを身につけておくと、ツールが変わっても応用が効きますよ。

参考リンク

公式ドキュメント

• Claude Code Memory – CLAUDE.md と .claude/rules/ の公式説明
• GitHub Copilot Custom Instructions

関連記事

• Claude Code→GitHub Copilot移行で使える設定ファイル6つの対応表

ここまで読んでいただき、ありがとうございました！

設定ファイルの置き場所、地味だけど長期的には効いてくる設計判断です。チーム開発では特に、「どこを見ればルールが分かるか」を明確にしておくと、みんなが幸せになれます。