Claude Code ルールディレクトリ
.claude/rules ディレクトリは CLAUDE.md をパス指定のマークダウンファイルに分割します。各ファイルは該当箇所でのみ読み込まれ、CLAUDE.md と同じ高優先度で適用されます。
問題: 一つの CLAUDE.md が過多な仕事を担っています。React の注意事項、API の規約、テストの基準が混在しており、マイグレーションファイルを編集しているときでも、セッションごとにすべてが読み込まれてしまいます。
すぐできること: 最初のターゲット指定ルールファイルを作成しましょう:
mkdir -p .claude/rules
echo "# Testing Rules
- Run tests before committing
- Mock external services in unit tests" > .claude/rules/testing.mdClaude はセッション開始時にそのルールを CLAUDE.md と並んで読み込み、2つの関心事がきれいに分離されます。
ルールディレクトリとは何か
Claude Code v2.0.64 以降、命令を整理するための新しい選択肢として .claude/rules/ ディレクトリが追加されました。肥大化した一つのメモリファイルの代わりに、複数のマークダウンファイルをその中に配置すると、Claude はセッション開始時にそれぞれをプロジェクトメモリに取り込みます。
Anthropic からの重要な注意: .claude/rules/ 内のファイルは CLAUDE.md と同じ高優先度で読み込まれます。これは重要です。Claude のコンテキストウィンドウはフラットではなく、ソースによって重みが異なります。
設定は不要です。.claude/rules/ 以下の .md ファイルはすべて、自動的にプロジェクトコンテキストの一部となります。
.claude/rules/
├── code-style.md # Formatting and conventions
├── testing.md # Test requirements
├── security.md # Security checklist
└── frontend/
├── react.md # React-specific patterns
└── styles.md # CSS conventions命令レイヤーにおける関心の分離です。スタイルファイルに影響を与えずにセキュリティルールを編集したり、その逆も可能です。
パス指定ルール: 強力な機能
ここがディレクトリの真価を発揮する場所です。ルールファイルは YAML フロントマターを通じて特定のファイルパターンをターゲットにできます:
---
paths: src/api/**/*.ts
---
# API Development Rules
- All endpoints must validate input with Zod
- Return consistent error shapes: { error: string, code: number }
- Log all requests with correlation IDsこのルールは Claude が src/api/**/*.ts に一致するファイルを操作しているときだけ有効になります。React コンポーネントを編集しているときは、API に関する注意事項は沈黙したままです。
複数のパスパターン
一つのファイルで複数のパターンを監視できます:
---
paths:
- src/components/**/*.tsx
- src/hooks/**/*.ts
---
# React Development Rules
- Use functional components exclusively
- Extract logic into custom hooks
- Memoize expensive computationsよく使うパスパターン
| パターン | マッチ対象 |
|---|---|
src/api/**/*.ts | src/api とサブディレクトリ内のすべての TypeScript ファイル |
*.test.ts | 任意のディレクトリ内のすべてのテストファイル |
src/components/*.tsx | components の直接の子のみ（ネストは含まない） |
**/*.css | プロジェクト内のすべての CSS ファイル |
優先度が重要な理由: 巨大な CLAUDE.md の問題
Claude のコンテキスト内のすべてのトークンが同じ重みを持つわけではありません。ソースはランク付けされており、Anthropic は CLAUDE.md とルールファイルが高優先度に位置すると明示しています。Claude はどちらも権威ある指示として扱います。
これが従来の作業方法における落とし穴を生んでいました。すべての規約を一つの巨大な CLAUDE.md に詰め込むと、データベースマイグレーションを行っているときでさえ、すべて が高い扱いを受けることになりました。API パターンと React パターンが注目を争い続けます。
どこでも高優先度 = 優先度なし。
すべてを重要とマークすると、Claude は今実際に何が適用されるかを判断できなくなります。命令が焦点から外れ、コンテキストが散漫になり、動作が予測不能になります。
コンテキスト優先度の階層
Claude が各ソースをどのように重み付けするかの概要:
| ソース | 優先度レベル | 意味 |
|---|---|---|
| CLAUDE.md | 高 | 権威ある命令として扱われる |
| ルールディレクトリ | 高 | CLAUDE.md と同じ重み |
| スキル | 中（オンデマンド） | トリガー時のみ読み込まれる |
| 会話履歴 | 可変 | 長いセッションで低下 |
| ファイル内容（Read ツール） | 標準 | 通常のコンテキスト、特別な重みなし |
ルールディレクトリは、高優先度のガイダンスを狭くスコープされたファイルに分散させることでモノリス問題を解決します。API ルールは高優先度のままですが、Claude が API ファイルを操作しているときだけです。
パスターゲティング = 優先度のスコープ指定
paths: エントリを持つルールは、Claude がマッチするファイルを操作しているときにのみ読み込まれ、高い注目を得ます:
---
paths: src/api/**/*.ts
---
# These instructions get high priority ONLY during API workこれが本質的な洞察です。物事を整然と整理しているだけでなく、命令がいつ追加の重みを得るかを選択しているのです。
ルール vs CLAUDE.md vs スキル
どれがどの役割を担うか?
| 機能 | 優先度 | 最適な用途 | 読み込みタイミング |
|---|---|---|---|
| CLAUDE.md | 高 | 普遍的な運用ワークフロー | すべてのセッション |
| ルールディレクトリ | 高 | ドメイン固有の命令 | すべてのセッション（パスでフィルタ） |
| スキル | 中 | 再利用可能なクロスプロジェクトの専門知識 | トリガー時にオンデマンド |
CLAUDE.md はどこでも適用されるものを保持します: ルーティングロジック、品質基準、連携プロトコル。短く保ちましょう。ここのすべての行が同じ高優先度バジェットを争います。
ルールは一つの領域に適用されるものを保持します: API ファイル用の API ルール、テストファイル用のテストルール。パスターゲティングにより、その高優先度が適切なタイミングにスコープされます。
スキルはプロジェクトをまたいで適用されるものを保持します: デプロイのプレイブック、レビューチェックリスト、ブランドガイド。何かがトリガーするまで低優先度で静かに待機します。
実践的な例
機密ディレクトリのセキュリティルール
---
paths:
- src/auth/**/*
- src/payments/**/*
---
# Security-Critical Code Rules
- Never log sensitive data (passwords, tokens, card numbers)
- Validate all inputs at function boundaries
- Use parameterized queries exclusively
- Require explicit authorization checks before data accessテストファイルの標準
---
paths: **/*.test.ts
---
# Test Writing Standards
- Use descriptive test names: "should [action] when [condition]"
- One assertion per test when possible
- Mock external dependencies, never real APIs
- Include edge cases: empty inputs, null values, boundariesデータベースマイグレーションのルール
---
paths: prisma/migrations/**/*
---
# Migration Safety Rules
- Always include rollback instructions
- Test migrations on a copy of production data first
- Never delete columns in the same migration that removes code using them
- Add columns as nullable first, populate, then add constraints巨大な CLAUDE.md からの移行
肥大化した CLAUDE.md は通常、優先度の飽和という症状です。すべてが重要とマークされているので、何も重要ではありません。修正方法は、ドメイン固有のセクションを取り出して、それぞれをパス指定のルールに落とし込むことです。
移行前（400行の CLAUDE.md 一本）:
# Project Context
...
## API Guidelines
- Validate inputs with Zod
- Return consistent errors
...
## React Patterns
- Use functional components
- Extract hooks
...
## Testing Rules
- Mock external services
...移行後（簡潔な CLAUDE.md + モジュール式ルール）:
# CLAUDE.md - Operational Core Only
## Routing Logic
- Simple tasks: execute directly
- Complex tasks: delegate to sub-agents
## Quality Standards
- Correctness > Maintainability > Performance.claude/rules/
├── api-guidelines.md # API section with paths: src/api/**/*
├── react-patterns.md # React section with paths: src/components/**/*
└── testing-rules.md # Testing section with paths: **/*.test.*CLAUDE.md は運用方法への焦点を保ちます。ドメイン知識は、アクティブなファイルがマッチしたときにのみ高優先度になるターゲット指定ルールに移動します。
優先度の飽和こそ、実際に解決していることです。コアの運用ガイダンスは常にオンです。ドメインルールは、Claude がそのレーンのファイルを編集しているときだけ声を上げます。それ以外では、沈黙。
ユーザーレベルのルール: すべてのプロジェクトへの個人デフォルト
プロジェクトルールだけが唯一のレイヤーではありません。すべてのプロジェクトで適用される個人ルールは ~/.claude/rules/ に保存されます:
~/.claude/rules/
├── preferences.md # Your personal coding preferences
├── workflows.md # Your preferred workflows
└── shortcuts.md # Custom patterns you always wantユーザールールが最初に読み込まれ、その上にプロジェクトルールが重なります。個人のデフォルトはどこへ行っても付いてきますが、プロジェクトが必要とする場合は上書きできます。
インデントスタイル、コミットメッセージの形式、好みのテストパターン、コードベースに関わらず常に使いたい小さな習慣など、_あなた自身_の作業スタイルを反映するものに役立ちます。
パスパターンでの波括弧展開
パスパターンは波括弧展開をサポートしているため、一つのエントリで複数の拡張子やディレクトリを同時にカバーできます:
---
paths:
- "src/**/*.{ts,tsx}"
- "{src,lib}/**/*.ts"
---
# TypeScript/React Rules
- Use strict TypeScript
- Prefer interfaces over type aliases for public APIs{ts,tsx} は .ts と .tsx の両方を取り込みます。{src,lib} は src/ と lib/ の両方をカバーします。ルールが関連するファイルタイプやフォルダにまたがる場合でも、フロントマターをコンパクトに保てます。
シンボリックリンク: プロジェクト間でのルール共有
.claude/rules/ 内ではシンボリックリンクが機能するため、一つの正規ルールソースを維持してリポジトリ間で共有できます:
# Symlink a shared rules directory
ln -s ~/shared-claude-rules .claude/rules/shared
# Symlink individual rule files
ln -s ~/company-standards/security.md .claude/rules/security.mdリンクされたファイルはローカルのものと同様に解決・読み込みされます。循環シンボリックリンクは検出・処理されるため、無限ループを心配する必要はありません。
コーディング標準をプロジェクト間で共有するチームに最適です。正規のルールリポジトリを一か所に保持し、必要なすべてのプロジェクトにシンボリックリンクします。
再帰的なサブディレクトリ探索
サブディレクトリも有効です。ツリー内のすべての .md ファイルが収集されます:
.claude/rules/
├── frontend/
│ ├── react.md
│ └── styles.md
├── backend/
│ ├── api.md
│ └── database.md
└── general.mdネストされていても、フラットでも、ローダーはディレクトリ全体を走査します。発見可能性を損なわずに関連ファイルを好みの方法でグループ化できます。
ベストプラクティス
ルールは焦点を絞る: ファイルごとに一つの関心事。セキュリティは一か所、スタイリングは別の場所。
わかりやすいファイル名を使う: api-validation.md は rules1.md よりずっと価値があります。
パスターゲティングを活用する: paths: のないルールはどこでも読み込まれます。ルールが関係ない作業に入り込み始めた瞬間にパターンを追加しましょう。
すべてをバージョン管理する: ルールはコードです。PR でレビューし、履歴を追跡し、逆効果になったものはリバートしましょう。
ルールの目的を文書化する: 各ファイルの先頭に、それがいつ適用されるべきかを説明する一行を書きましょう。
次のステップ
- CLAUDE.md を監査する: 特定のファイルタイプにしか適用されないセクションにフラグを立てる
- 一つのルールを抽出する: 最もドメイン固有なブロックを
.claude/rules/に移動する - パスターゲティングを追加する: そのルールを実際に対象とするファイルに向ける
- 繰り返す: Claude が不要なコンテキストを読み込むたびに、別のルールを抽出する
より広いメモリアーキテクチャと、一つの巨大なファイルが問題を引き起こす理由については、CLAUDE.md マスタリーを参照してください。優先度がより広いコンテキスト戦略にどう位置するかについては、コンテキスト管理とメモリ最適化をお読みください。
覚えておく: 目標は、画面上のファイルにマッチした高優先度のガイダンスを Claude に正確に渡すことです。それ以上でも以下でもなく。重要な場所に注目を集め、それ以外では静かに。これをオンデマンドでドメイン知識を読み込むスキルアーキテクチャと組み合わせれば、コンテキストウィンドウは無駄なく保たれ、命令は重みを保ちます。