Rules（ルール）

Rules は、.claude/rules/ ディレクトリに配置するマークダウンファイルで、Claude Code が作業中に自動的に参照するプロジェクトのルールブックです。CLAUDE.md がプロジェクト全体の「業務マニュアル」だとすると、Rules は業務ごとの詳細な手順書です。

Rules とは

Rules を使うと、プロジェクト固有のコーディング規約、Git ワークフロー、セキュリティポリシーなどを個別のファイルに分けて管理でき、Claude Code がそれらを自動的に読み込んで遵守します。

ポイント: Rules は .claude/rules/ 配下にマークダウンファイルを置くだけで有効になります。特別な設定やインストール作業は不要です。

身近な例えで理解する

CLAUDE.md = 校則

全校生徒が常に守る基本ルール。いつでも適用されます。

Rules = 各教科のテストの注意事項

数学では関数電卓使用可、英語では辞書持ち込み不可 ── そのテストを受けるときだけ必要なルールです。

校則はいつでも適用されますが、教科ごとの注意事項は「そのテストを受けるとき」だけ必要です。同じように、Rules は paths フロントマターを使えば「特定のファイルを触るとき」だけ適用させることができます。

なぜ Rules が必要なのか

1. CLAUDE.md を短く保てる

公式ドキュメントでは CLAUDE.md は 200行以内 が推奨されています。全てのルールを CLAUDE.md に書くと超過しやすいため、Rules に分割して CLAUDE.md をコンパクトに保ちます。

2. トピックごとに整理できる

Git のルール、コーディング規約、セキュリティルールが1ファイルに混在すると管理しにくくなります。1ファイル1トピックに分けることで、追加・修正・削除が簡単になります。

3. パス別にルールを適用できる

paths フロントマターで特定のファイルパスに絞ったルール適用ができます。不要なルールがコンテキストに入らないので、AI の判断精度が上がり、トークンも節約できます。

4. カスタムコマンド・サブエージェントと連動する

スターターキットのコマンド・エージェントは「CLAUDE.md や .claude/rules/ のルールに準拠」と設計されており、ルールを整備するほど出力品質が向上します。

Rules の公式フォーマット

基本構造

.claude/rules/ 配下にマークダウンファイルを配置します。ファイル名はトピックを表す名前にします（testing.md、security.md 等）。サブディレクトリも再帰的に読み込まれます。

.claude/rules/
├── git-workflow.md       # Git ワークフロー
├── coding-standards.md   # コーディング規約
├── testing.md            # テストルール（パス別）
├── security.md           # セキュリティルール
└── review-process.md     # コードレビュールール

無条件ルール（全ファイルに適用）

paths フロントマターを付けないルールは、セッション開始時に無条件で読み込まれます。プロジェクト全体に常に適用されるルールに使います。

無条件ルールの例

# セキュリティルール

- 機密情報をソースコードにハードコーディングしない
- `.env` ファイルをコミットしない
- データベースの削除コマンドを実行しない

パス別ルール（特定ファイルにのみ適用）

YAML フロントマターの paths フィールドでグロブパターンを指定すると、マッチするファイルを Claude が操作するときだけ読み込まれます。不要なルールがコンテキストに入らないため、トークンの節約と判断精度の向上につながります。

パス別ルールの例

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

# API 開発ルール

- 全エンドポイントに入力バリデーションを実装する
- 統一されたエラーレスポンス形式を使用する

無条件ルール

paths フロントマターなし。セッション開始時に常に読み込まれる。例: セキュリティルール、Git ワークフロー

パス別ルール

paths フロントマターでグロブパターンを指定。マッチするファイルを操作するときだけ読み込まれる。例: テストルール、API ルール

flowchart TD START(["セッション開始"]) LOAD["無条件ルール読み込み
security.md, git-workflow.md 等"] WORK["ファイル操作"] CHECK{"paths パターンに
マッチ？"} PATHLOAD["パス別ルール追加読み込み
testing.md 等"] SKIP["パス別ルールなし"] APPLY(["全ルール適用して作業"]) START --> LOAD --> WORK --> CHECK CHECK -->|"マッチ"| PATHLOAD --> APPLY CHECK -->|"しない"| SKIP --> APPLY style START fill:#e0e7ff,stroke:#6366f1,color:#1e293b style LOAD fill:#ecfdf5,stroke:#10b981,color:#1e293b style CHECK fill:#fef3c7,stroke:#f59e0b,color:#1e293b style PATHLOAD fill:#ecfdf5,stroke:#10b981,color:#1e293b style APPLY fill:#e0e7ff,stroke:#6366f1,color:#1e293b

無条件ルールとパス別ルールの適用フロー

グロブパターン

パターン	マッチするファイル
`*/.ts`	全ディレクトリの TypeScript ファイル
`src/*/`	src 配下の全ファイル
`*.md`	プロジェクトルート直下のマークダウンファイル
`src/components/*.tsx`	特定ディレクトリの TSX ファイル
`*/.{ts,tsx}`	ブレース展開で複数拡張子をマッチ

複数パターンを指定可能です:

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

サンプルルール

5つのサンプルルールを用意しています。以下にそれぞれの全文を掲載します。

coding-standards.md

.claude/rules/coding-standards.md

# コーディング規約

- 同じロジックを複数箇所に書かない（DRY）。3回以上繰り返すコードは共通化を検討する
- 現時点で必要のない機能を先回り実装しない（YAGNI）
- 変数・関数はキャメルケース、クラス・型はパスカルケース、定数はアッパースネークケースで命名する
- マジックナンバーは定数に置き換える（`if (status === 3)` → `if (status === STATUS_COMPLETED)`）
- 1つの関数は1つの責務に限定し、50行以内を目安にする
- ネストは3段階以内に抑え、早期リターンを活用する
- エラーを黙って握りつぶさない（空の catch ブロック禁止）。ユーザー向けメッセージとシステムログを区別する
- 使用していないインポートは削除する
- インポート順序を統一する（標準ライブラリ → 外部ライブラリ → プロジェクト内）

git-workflow.md

.claude/rules/git-workflow.md

# Git ワークフロー

- ブランチ作成前に必ずメインブランチで `git pull` してソースを最新化する
- ブランチ名は `feature/#42-user-auth`、`fix/#123-login-error`、`docs/#45-api-spec` の形式にする（プレフィックス + Issue 番号 + 概要）
- コミットメッセージは日本語で記述し、Issue 番号がある場合は先頭に含める（例: `#42 ユーザー認証のログイン機能を実装`）
- 1つの論理的な変更を1コミットにまとめ、関連しない変更を混ぜない
- PR のタイトルと説明は日本語で記述し、`Closes #番号` で Issue を連携する
- 本番ブランチ（main / master）に直接プッシュしない

review-process.md

.claude/rules/review-process.md

# コードレビュールール

- 全ての問題を報告する。エラーを見過ごしたり軽視しない
- 指摘にはファイルパス、行番号、具体的な修正コード例を含める
- 指摘レベルを分類する: 🔴 Critical（本番障害・セキュリティ問題、マージ前に必須修正）、🟡 Warning（品質上の問題、修正推奨）、🔵 Suggestion（改善提案、対応任意）
- レビュー観点: ロジック正確性、セキュリティ（security.md 参照）、テスト（testing.md 参照）、コーディング規約（coding-standards.md 参照）、パフォーマンス、エラー処理
- レビュー指摘には全て対応する（明示的にスキップ指示がない限り）
- プロジェクトルールとレビューコメントが競合する場合はプロジェクトルールを優先し、理由を説明する
- 修正完了後は PR に対応内容のサマリーをコメントとして投稿する

security.md

.claude/rules/security.md

# セキュリティルール

## 禁止事項

- データベースの削除・初期化コマンド（`flush`、`drop`、`reset` 等）を絶対に実行しない
- 機密情報（API キー、パスワード、シークレット）をソースコードにハードコーディングしない。環境変数を使用する
- `.env` ファイルをコミットしない

## 実装時のチェック項目

- 全ての API エンドポイントに認証チェックを入れる
- SQL クエリは ORM を使用する。生 SQL の場合はパラメータバインディングを使う
- ユーザー入力をそのまま HTML に出力しない（XSS 対策）
- シェルコマンドにユーザー入力を直接渡さない
- API レスポンスに不要な機密データを含めない
- ログにパスワード・トークン等の機密情報を出力しない
- ファイルアップロードには拡張子・サイズの制限を設ける

testing.md

.claude/rules/testing.md

---
paths:
  - "tests/**/*"
  - "test/**/*"
  - "**/*.test.*"
  - "**/*.spec.*"
  - "**/*_test.*"
---

# テストルール

- TDD を実践する: テストを先に書き、テストを通す実装を書く
- テストコードを修正・削除してテストを通すことは絶対に禁止。テストが失敗したら実装コードを直す
- 全テストを毎回実行せず、修正内容に影響するテストファイル・テストクラスのみを対象に実行する
- テスト名は「何をテストしているか」がわかるように命名する（`test('ユーザー名が空の場合にバリデーションエラーを返す')` ）
- 正常系、異常系（不正入力でエラー）、境界値（最大文字数ちょうど / +1）、エッジケース（null、空文字、特殊文字）を網羅する
- テスト間の依存関係を作らない。各テストは独立して実行可能にする

注目: testing.md だけが paths フロントマターを持つパス別ルールです。テスト関連ファイル（tests/**/*, **/*.test.*, **/*.spec.* 等）を操作するときだけ読み込まれます。

サンプルとして用意しているルール

ファイル	`paths`	内容
`git-workflow.md`	なし（常時適用）	ブランチ命名、コミットメッセージ、PR 作成
`coding-standards.md`	なし（常時適用）	DRY/YAGNI、命名規則、エラー処理、可読性
`testing.md`	`tests/*/`, `*/.test.*` 等	TDD、テストコード不可侵性、最小テスト原則
`security.md`	なし（常時適用）	禁止事項、セキュリティチェック項目
`review-process.md`	なし（常時適用）	レビュー観点、指摘レベル、対応ルール

ルール作成のコツ

簡潔に書く - ルールはガイドではない。具体的で検証可能な指示を箇条書きにする
1ファイル1トピック - ファイル名がトピックを表すようにする
パス別ルールを活用する - 全ファイルに不要なルールは paths で絞り、コンテキストを節約する
CLAUDE.md と重複させない - ルールは CLAUDE.md の詳細版。同じ内容を両方に書かない
シンボリックリンクで共有可能 - 複数プロジェクトで共通のルールは ln -s でリンクできる

ベストプラクティス: ルールは「ガイド」ではなく「チェックリスト」として書きましょう。「〜を心がける」ではなく「〜する / 〜しない」と断言形で記述すると、Claude がルールを明確に理解し遵守率が高まります。また、各ルールに「なぜ」を付記すると、エッジケースでの判断が安定します。

ユーザーレベルのルール

~/.claude/rules/ に配置したルールは、全プロジェクトで個人的に適用されます。プロジェクト固有でない個人の好みはここに置きます。

~/.claude/rules/
├── preferences.md    # 個人のコーディング好み
└── workflows.md      # 個人のワークフロー

ユーザーレベルのルールはプロジェクトルールより先に読み込まれ、プロジェクトルールが優先されます。個人のルールとプロジェクトのルールが矛盾する場合は、プロジェクト側が採用されます。

まとめ: Rules は CLAUDE.md の補完として、トピック別にルールを分割管理できる仕組みです。無条件ルールとパス別ルールを使い分けることで、必要な場面で必要なルールだけを AI に読み込ませ、精度とコスト効率を両立できます。