Claude Codeのrulesは、プロジェクトの .claude/rules/ に置くMarkdownファイルで、CLAUDE.mdに書いていた指示をテーマ別に分けて持てる仕組みです。paths フロントマターを付けると、該当するファイルを扱うときだけ読み込まれます。この記事では、ディレクトリの作り方、pathsの書き方とglobの落とし穴、CLAUDE.md・Skills・Hooksとの読み込み順の違いを設定例つきで整理する内容です。後半はチームでの共有、読み込みの確かめ方、分割すべき条件まで扱います。基準はClaude Code 2.1.318（2026年11月6日時点のnpm最新）です。
まとめ：.claude/rulesに分ける指示とCLAUDE.mdに残す指示の線引き
ビルドコマンドや命名規則のように、どの作業でも毎回必要な指示はCLAUDE.mdに残します。src/api/ の入力検証や、テストファイルの書き方のように一部のファイルにしか関係しない指示は、paths 付きのルールとして .claude/rules/ に切り出してください。該当ファイルを開くまでコンテキストに載らないので、CLAUDE.mdの肥大化を止められます。
rulesはあくまで文脈として渡される指示で、強制力はありません。コマンドの禁止は権限設定かフックで行い、複数手順の作業はSkillsに回します。CLAUDE.mdが200行に収まっていて規約も1種類なら、rulesを作る必要はありません。
.claude/rulesにルールファイルを置く手順と起動時に読まれる範囲
rulesは、CLAUDE.mdの置き場所と読み込み順を理解していると扱いやすくなります。導入直後の設定全体はClaude Codeの使い方（インストールから権限・CLAUDE.md設定まで）で扱っているので、ここではrules固有の部分に絞ります。
rulesディレクトリの作成とpathsなしルールが起動時に読まれる仕組み
公式ドキュメントのメモリの章によると、.claude/rules/ 配下の .md はサブディレクトリまで再帰的に探されます。paths を持たないルールは起動時に読み込まれ、優先度は .claude/CLAUDE.md と同じ扱いです。1ファイル1テーマにして、testing.md のように中身が分かる名前を付けます。
mkdir -p .claude/rules/backend
cat > .claude/rules/testing.md <<'EOF'
# テストの規約
- テストは Vitest で書き、ファイル名は *.test.ts にする
- 外部APIはモックし、実通信するテストは tests/e2e/ に置く
EOF作成後は新しいセッションで /context all を実行し、Memory filesの一覧にファイルが並ぶかを確かめます。起動時に読まれるルールはここに出ますが、paths付きのルールは該当ファイルに触れるまで出ません。
pathsフロントマターでルールを特定ファイルだけに効かせる書き方
pathsはrulesの中心機能で、つまずく箇所もここに集中します。
paths指定のYAML例と読み込みが起きるRead・Write・Editの3操作
ファイル先頭の --- で囲んだYAMLに、globを並べます。v2.1.84からYAMLのリストで書けるようになり、カンマ区切りの文字列も受け付けます（Claude CodeのCHANGELOG）。
---
paths:
- "src/api/**/*.ts"
- "tests/api/**/*.test.ts"
---
# API実装のルール
- ハンドラーは入力をzodで検証してから処理する
- エラー応答は { code, message } の形にそろえる読み込みが起きるのは、Claudeが該当ファイルをRead・Write・Editで扱ったときです。WriteとEditで新規作成・変更したときも読まれるのはv2.1.288からで、それ以前はReadのみでした。v2.1.293からは、Bashで1ファイルを cat や head で見た場合も対象に入ります。古い版を使い続けている端末では「新しいファイルを作るときにルールが効かない」現象が起きるので、版をそろえてください。
globの基準ディレクトリとブレース展開1,000件の上限で詰まる箇所
パターンの基準は、プロジェクトのルールなら .claude フォルダを含むディレクトリです。~/.claude/rules/ に置くユーザーのルールは、セッションの作業ディレクトリが基準になります。*.md はどの階層の .md にも一致し、直下だけに絞るなら /*.md と書きます。
{ts,tsx} のブレース展開は掛け算で増え、1ルールのpaths全体で展開後1,000パターン・4MiBが上限です。超えたパターンは展開されず、波括弧が文字のまま残って何にも一致しません。もう1つ見落とされやすいのがYAMLの書き損じで、解析に失敗するとフロントマターは無視され、paths無しのルールとして起動時に全体へ読まれます。絞ったつもりのルールが常に載る原因はたいていこれで、claude --debug で解析エラーを確認できます。
CLAUDE.md・rules・Skills・Hooksの読み込み順と役割の分け方
同じ「指示」でも、置き場所によって読まれる時期と効き方が違います。
管理ポリシーからCLAUDE.local.mdまで連結される読み込み順の実際
CLAUDE.mdは上書きではなく連結されます。範囲の広いものから順に並び、作業ディレクトリに近いものほど後ろに来ます。
| 種類 | 置き場所 | 読まれる時期 |
|---|---|---|
| 管理ポリシー | OSごとの管理パス | 起動時・除外不可 |
| ユーザー | ホームの.claude配下 | 起動時 |
| プロジェクト | リポジトリ直下と.claude配下 | 起動時（paths付きは該当時） |
| ローカル | CLAUDE.local.md | 起動時・同階層の最後 |
| サブディレクトリ | 配下の CLAUDE.md | そこを触った時点 |
中身はシステムプロンプトではなく、その後のユーザーメッセージとして渡されます。強く書いても厳密に守られる保証はない点が、設定ファイルとの決定的な違いです。
ユーザールールとプロジェクトルールが食い違ったときの優先順位の実態
ユーザーのrulesはプロジェクトのrulesより先に読まれ、文脈上はプロジェクト側が後ろに並びます。ただし公式ドキュメントは「どちらも他方を上書きしない。衝突するとClaudeはどちらに従うか分からない」と明記しています。解説記事には「範囲の狭いルールが優先される」と書くものがありますが、仕様としての優先順位はありません。
実務では、個人のrulesに書くのはエディタの好みや説明の粒度など、プロジェクト規約と重ならない事項に限ります。インデント幅やコミットの書式のように両方に書きたくなる項目は、プロジェクト側だけに置いてください。
毎回要る指示はrules・手順はSkills・強制はHooksに振り分ける基準
判断の軸は「常に文脈に要るか」と「破られたら困るか」の2つです。毎回の作業に効く短い規約はCLAUDE.mdかpaths無しのrules、特定ファイルにだけ効く規約はpaths付きのrulesに置きます。デプロイ手順のように複数ステップの作業は、呼ばれたときだけ読まれるClaude Skillsに回すと文脈を圧迫しません。
「本番DBに接続しない」のように破られると事故になる指示は、rulesに書いても止まりません。PreToolUseフックや権限のdenyで機械的に止めます。フックのイベントと書き方はClaude Code Hooksの設定方法にまとめています。
チームでrulesを共有するsymlink・除外設定・AGENTS.md併用の手順
複数リポジトリやモノレポで使い始めると、配る・外す・他ツールと併用するの3つが課題になります。
シンボリックリンクで共通ルールを配る手順と外部承認ダイアログ
.claude/rules/ はシンボリックリンクを辿るので、社内共通の規約を1か所で管理し、各リポジトリへリンクできます。
ln -s ~/company-claude-rules .claude/rules/shared
ln -s ~/company-standards/security.md .claude/rules/security.mdリンク先が作業ディレクトリの外なら、外部importと同じ扱いになり、プロジェクトごとに1回の承認ダイアログが出ます。注意したいのは、承認後もpaths無しのルールしか読まれない点です。paths付きの共通ルールはリンクでは配れないため、各リポジトリに実体を置くか、全プロジェクトに効く ~/.claude/rules/ に置きます。UNCパスなどネットワーク上のリンク先は辿られません。Windowsの開発者がいるチームでは、symlinkの作成に管理者権限か開発者モードが要る点も配布前に確認してください。
モノレポで他チームのrulesを外すclaudeMdExcludesの設定例
上位ディレクトリに他チームのCLAUDE.mdやrulesがあると、起動時にまとめて読まれます。claudeMdExcludes に書く絶対パスのglobが除外のための設定です。個人の判断で外すなら、リポジトリに入らない .claude/settings.local.json に書きます。
{
"claudeMdExcludes": [
"**/monorepo/CLAUDE.md",
"/home/dev/monorepo/team-payments/.claude/rules/**"
]
}この配列はユーザー・プロジェクト・ローカル・管理の各層で結合されます（設定ファイルと優先順位）。管理ポリシーのCLAUDE.mdだけは除外できません。symlink経由のrulesは、リンク側とリンク先のどちらのパスを書いても外れます（v2.1.239から）。
AGENTS.mdを併用するリポジトリでrulesが読まれ続ける条件
Claude Codeは既定で、CLAUDE.mdが無いリポジトリに限り AGENTS.md を読みます。この判定で数えるのはCLAUDE.md・.claude/CLAUDE.md・CLAUDE.local.mdの3つで、.claude/rules/ は数えません。つまりAGENTS.mdを他ツールと共有しつつ、Claude専用の補足だけをrulesに置く構成が成り立ちます。
逆に、CLAUDE.local.mdを1つ置いただけでAGENTS.mdが読まれなくなるので注意が要ります。各ツールの読み込み仕様はAGENTS.mdの読み込み仕様と配置手順で比較しています。
rulesが効かないときに読み込みをフックで記録して原因を絞る手順
「書いたのに守られない」ときは、まず読まれているかを確かめ、次に中身を疑う順で進めます。
InstructionsLoadedフックで読み込み理由をログに残す設定例
v2.1.69で追加された InstructionsLoaded は、CLAUDE.mdやrulesが文脈に読み込まれるたびに発火します（Hooksリファレンス）。matcherは読み込み理由の load_reason に当たり、paths付きルールの読み込みは path_glob_match になります。
{
"hooks": {
"InstructionsLoaded": [
{
"matcher": "path_glob_match|nested_traversal",
"hooks": [
{
"type": "command",
"command": "jq -c '{load_reason, file_path, trigger_file_path, globs}' >> ~/.claude/instructions-loaded.log"
}
]
}
]
}
}ログの trigger_file_path を見れば、どのファイルに触れたときにどのルールが載ったかが分かります。一度も記録されないならglobの誤り、起動時に記録されるならYAMLが壊れてpaths無し扱いになっていると判断できます。このフックは読み込みを止められず、出力も捨てられるので、用途は読み込みの記録専用です。
4万字の上限と/compact後に消えたように見える指示の再読込条件
paths付きルールとサブディレクトリのCLAUDE.mdには、1ファイルあたりの上限があります。200Kトークンのコンテキストでは40,000文字、1Mでは新しいモデルで150,000文字です。超えた分は冒頭しか渡らず、後半の指示は読まれません。この制限はv2.1.309から入ったため、以前は効いていた長いルールが急に後半だけ無視される形で表に出ます。
/compactの後は、ルート直下のCLAUDE.mdは読み直されますが、paths付きルールは該当ファイルに再び触れるまで戻りません。圧縮の発動点と挙動はauto-compactの仕組みを参照してください。
受託開発でrulesへ分割する条件とCLAUDE.md一枚で済ませる場面
rulesはファイルを増やすほど管理の手間も増えます。分けるかどうかは次の条件で決めます。
CLAUDE.mdが200行を超えた・領域ごとに規約が違うときの分割判断
分割に踏み切る条件は2つです。CLAUDE.mdが公式の目安である200行を超えたこと。もう1つは、フロントエンドとバックエンド、あるいは決済モジュールのように、領域ごとに守らせたい規約が違うことです。どちらかに当てはまったら、領域固有の部分をpaths付きルールへ移し、CLAUDE.mdには全体の規約だけを残します。@import で分けても一緒に読まれるため、文脈の節約にはなりません。
v2.1.283以降なら /doctor prompt-audit で、矛盾や古い記述を洗い出せます。複数チームが同じリポジトリでAIに規約を守らせる体制づくりは、生成AI開発・AI受託開発で開発標準の整理から相談を受けています。
小規模リポジトリや個人の試用でrulesを増やすと逆効果になる場面
ファイル数が数十程度で、CLAUDE.mdが数十行に収まるリポジトリでは、rulesに分けても得るものはほぼありません。pathsの書き損じで読まれていないことに気づかない、といった管理の失敗の方が起きやすくなります。この規模ならCLAUDE.md一枚で十分です。
個人で試している段階なら、~/.claude/rules/ に好みを1〜2ファイル置く程度に留めます。プロジェクト規約と同じ項目を書くと、前述のとおりどちらに従うか不定になります。
よくある質問（Claude Code rulesの書き方でつまずきやすい点）
.claude/rulesの導入時によく調べられる疑問をまとめました。
.claude/rulesはどのバージョンから使えますか？
CHANGELOGでは、v2.0.64で .claude/rules/ への対応が追加されています。pathsをYAMLのリストで書けるようになったのはv2.1.84、WriteとEditでもpaths付きルールが読まれるようになったのはv2.1.288です。チームで使うなら、全員の版を2.1.288以降にそろえておくと挙動の差が出ません。
rulesのファイル名や数に決まりはありますか？
拡張子が .md であれば名前は自由で、サブディレクトリに分けても再帰的に読まれます。数の上限は公式に示されていません。ただし起動時に読まれるファイルが積み重なると、合計の長さに対する警告が起動時や /status で表示されます。pathsで絞れるものは絞り、常時読まれるファイルを減らしてください。
paths以外のフロントマター（descriptionやglobs）は使えますか？
使えません。Claude Codeがrulesから読む項目は paths だけで、ほかの項目はエラーにならずに無視されます。Cursorのルールは globs で対象を指定するため、そのまま移すと絞り込みが効かず、移行後も常時読み込まれるルールという扱いです。Cursor側の書式は.cursorrulesと.cursor/rulesの書き方で確認できます。
rulesに書けば特定のコマンドを確実に禁止できますか？
できません。rulesとCLAUDE.mdは文脈として渡される指示で、Claudeが必ず従うという保証はありません。確実に止めるには、settings.jsonの permissions.deny か、PreToolUseフックで実行前に拒否します。組織で強制するための設定は、管理設定に置いてください。具体的な書き方はClaude Codeのセキュリティ設定で解説しています。
CLAUDE.mdの@importとrulesの違いは何ですか？
@path で取り込んだファイルは、取り込み元のCLAUDE.mdと一緒に必ず読まれます。整理には役立ちますが、文脈の消費量は減りません。paths付きのrulesは該当ファイルに触れるまで読まれないので、こちらは実際に文脈を節約できます。importの入れ子は4段までという制限もあります。
関連記事
- .clinerulesとは？書き方・配置場所とCline v4.1の読み込み仕様：Clineのルールファイルとの書式・読み込み条件の違い
- Claude Code Auto Memoryとは？MEMORY.mdの保存場所・読み込み上限と無効化の設定：自分で書くrulesと、Claudeが書き溜める自動メモリの分担
- Claude CodeのMCP設定｜claude mcp addの書き方とスコープ・.mcp.json例：rulesと同じくプロジェクト単位で共有する設定の扱い方
- Claude Codeを日本語で使う設定｜language・CLAUDE.md・日本語コミット：日本語の応答やコミットをCLAUDE.mdで指定する具体例
- Claude Codeのworktreeとは？claude -wの使い方とサブエージェントの並列実行：worktreeごとにpaths付きルールを効かせる際の前提
