Claude Code rules の使い方｜CLAUDE.md との違いと使い分け

1. claude rule の正体 — Claude Code の .claude/rules/ 機能とは

「claude rule」という検索語で出てくる本命は、Claude Code がプロジェクトの .claude/rules/ ディレクトリから読み込むルールファイルです。Claude Code はセッション開始時にこのディレクトリ内の .md ファイルを自動で発見し、プロジェクト固有の規約を記憶した状態で作業を始めます。

公式ドキュメント(code.claude.com/docs/ja/memory)では、rules は「指示をモジュール化し、チームが保守しやすくする」ための仕組みと位置づけられています。CLAUDE.md と同じく各セッションの冒頭でコンテキストに読み込まれますが、強制力のある設定ではなくあくまで「コンテキスト」である点も共通です。確実にブロックしたい操作は PreToolUse hook 側で実装する、という棲み分けになっています。

つまり「claude rule」とは、Claude Code 版のルール定義の仕組みであり、その実体が .claude/rules/ ディレクトリだと理解すれば構いません。

2. CLAUDE.md と rules の違い — いつどちらを使うか

最も多い疑問が「CLAUDE.md があるのに、なぜ rules が要るのか」です。違いは次の 3 点に集約できます。

1. 形式: CLAUDE.md はプロジェクトルートに置く単一ファイル。.claude/rules/ はトピック別に複数の .md を置けるディレクトリ。
2. 適用範囲: CLAUDE.md は基本的に全体へ。rules は paths を付ければ特定のファイルパスにだけスコープできる。
3. 読み込みタイミング: paths のないルールは起動時に常時、paths 付きルールは一致ファイルを開いたときだけ。

侍エンジニアの解説(generative-ai.sejuku.net)も、rules を「毎回同じ説明を繰り返す手間をなくす仕組み」と整理しています。SIOS の実践記事(tech-lab.sios.jp)が推すのはハイブリッド運用で、リポジトリ全体の基本ルールは CLAUDE.md に、領域ごとの詳細ルールは .claude/rules/ に分ける形です。公式が「CLAUDE.md は 200 行以下を目標に」と明言している以上、肥大化分の受け皿として rules を使うのが定石になります。

3. .claude/rules/ の置き方とディレクトリ構成

セットアップはシンプルです。次の手順で導入できます。

1. プロジェクトルートに .claude/rules/ ディレクトリを作る。
2. トピックごとに説明的なファイル名で .md を置く(code-style.md、testing.md、security.md など)。
3. 規模が大きければ frontend/ backend/ のようなサブディレクトリで整理する(.md は再帰的に発見される)。
4. セッションを開始すると、paths のないルールが起動時に読み込まれる。

公式ドキュメントが示す典型レイアウトは次の通りです。

your-project/
├── .claude/
│   ├── CLAUDE.md           # メインのプロジェクト指示
│   └── rules/
│       ├── code-style.md   # コードスタイルの規約
│       ├── testing.md      # テスト規約
│       └── security.md     # セキュリティ要件

paths を持たないルールは .claude/CLAUDE.md と同じ優先度で起動時に読み込まれます。つまり「全体に効かせたい一般ルール」をそのまま .claude/rules/ に置いても問題ありません。

4. paths frontmatter で適用範囲を絞る(パス固有ルール)

rules 機能の真価は paths frontmatter にあります。YAML フロントマターに paths を書くと、そのルールは指定パターンに一致するファイルを Claude が扱うときだけ適用されます。

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

# API 開発ルール

- すべての API エンドポイントは入力検証を含める
- 標準のエラー応答フォーマットを使う
- OpenAPI 用のドキュメントコメントを付ける

グロブパターンは拡張子・ディレクトリ・その組み合わせに対応し、ブレース展開で複数拡張子もまとめて指定できます。

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

代表的なパターンの意味は次の通りです。**/*.ts は任意のディレクトリ内のすべての TypeScript ファイル、src/**/* は src/ 配下すべて、*.md はルート直下のマークダウンを指します。paths を持たないルールは無条件にすべてのファイルへ適用されます。Zenn の解説(zenn.dev)が「動的にルールを読み込む」と表現しているのが、まさにこのパス固有ルールの挙動です。フロントエンドの規約をバックエンド作業中のコンテキストに載せない、といった節約ができます。

5. ユーザールールと共有 — ~/.claude/rules/ とシンボリックリンク

プロジェクトを越えて効かせたい個人の好みは、ホーム配下の ~/.claude/rules/ に置きます。ここに置いたルールはマシン上のすべてのプロジェクトに適用され、プロジェクトルールより先に読み込まれる(=プロジェクト側が優先される)仕様です。

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

チームで共通ルールセットを配りたい場合はシンボリックリンクが使えます。.claude/rules/ はリンクを解決して通常どおり読み込み、循環リンクも検出して安全に処理します。

ln -s ~/shared-claude-rules .claude/rules/shared
ln -s ~/company-standards/security.md .claude/rules/security.md

これで「共有リポジトリで管理する 1 つのルールセット」を複数プロジェクトから参照でき、規約のコピペ運用から脱却できます。

6. 効果的な rules の書き方 — 守るべきベストプラクティス

ルールは「書けば効く」ものではありません。公式の指針と現場知見(note)から、効かせるためのポイントを整理します。

1. 具体的に書く: 「適切にフォーマット」ではなく「2 スペースインデント」、「テストする」ではなく「コミット前に npm test」のように、検証可能な粒度にする。
2. 1 ファイル 1 トピック: testing.md にテスト規約、security.md にセキュリティ、と役割で分ける。混在は遵守率を下げる。
3. 禁止と代替をセットに: 「触るな」だけでなく「代わりにこうする」まで書く。
4. 矛盾を作らない: 複数ファイルで相反する指示があると、Claude はどちらか一方を任意に選んでしまう。定期的に棚卸しする。

短く具体的なルールほど遵守率が上がるのは CLAUDE.md と同じです。.claude/rules/ に分けたからといって 1 ファイルに詰め込みすぎると、結局ノイズで重要ルールが埋もれます。

7. 設定が効かないときのトラブルシュート

ルールが反映されないと感じたら、まず /memory コマンドを実行します。現在のセッションに読み込まれている CLAUDE.md・CLAUDE.local.md・ルールファイルが一覧表示されるので、目的のファイルがリストに出ているかを確認します。出ていなければ、Claude はそのファイルを見ていません。

チェックすべき点は次の通りです。

1. ファイルが .claude/rules/ 直下(またはサブディレクトリ)の .md になっているか。
2. paths 付きルールの場合、いま開いているファイルがそのグロブに一致しているか(一致しないと読み込まれない)。
3. 他のルールや CLAUDE.md と矛盾する指示がないか。

より詳しく追うなら、公式の InstructionsLoaded hook で「どの指示ファイルが、いつ、なぜ読み込まれたか」をログ化できます(code.claude.com/docs/ja/memory)。パス固有ルールやサブディレクトリの遅延読み込みをデバッグするのに有効です。なお、特定のタイミングで必ず実行させたい処理(コミット前など)は、ルールではなく hook で固定するのが確実です。

8. まとめ — rules で CLAUDE.md の肥大化を防ぐ

.claude/rules/ は、肥大化した CLAUDE.md の問題を構造で解決する機能です。全体の基本ルールは CLAUDE.md に残し、領域ごとの詳細は rules に分割、しかも paths で必要なファイルにだけ効かせる——この三層が 2026 年時点の現実的な型です。個人の好みは ~/.claude/rules/、共通規約はシンボリックリンクで配れば、チームでもメンテしやすくなります。まずは testing.md 1 枚から切り出し、/memory で読み込みを確認しながら育てていくのが最短ルートです。

出典: Claude Code 公式ドキュメント「Claude があなたのプロジェクトを記憶する方法」 / 侍エンジニア / SIOS Tech.Lab / Zenn(tmasuyama1114) / note(まさお)