はじめに

.claude/rules/にルールファイルを増やしていくと、今から編集するファイルには関係ないルールまで、セッション（Claude Codeとの1回のやり取りのまとまり）のたびに全部まとめて読み込まれてしまいます。実はこれ、pathsというフィールドを1つ書き足すだけで解消できます。この記事では、その土台となる「YAMLフロントマター」「pathsフィールド」「Globパターン」の3つを、初めての方にも分かるように解説します。

この記事で分かること

.claude/rules/とは何か、なぜルールをファイルごとに分けて置けるのか
ルールが増えてきたときの、見通しのよいフォルダ構成の作り方
YAMLフロントマターという「設定を書く場所」の書き方
pathsフィールドで、ルールを「必要な時だけ」読み込ませる方法
pathsに書くGlobパターンの読み方・書き方

本題に入る前に：`.claude/rules/`の基本と最適な構造

.claude/rules/は、トピックごとにファイルを分けて置いておくためのフォルダです。ここに置いたMarkdownファイルは、サブフォルダの中も含めてClaude Codeがすべて自動的に見つけます。ただし実際にコンテキストへ読み込まれるタイミングは、次に説明するpathsフィールドの有無で変わります。

ルールが増えてきたら、種類ごとにサブフォルダを作ると見通しがよくなります。たとえば開発系ルールと役割（ペルソナ）系ルールを分けたい場合、次のような構造にできます。

your-project/
└── .claude/
    └── rules/
        ├── dev-rules/
        │   ├── code-style.md
        │   └── testing.md
        └── role-rules/
            └── reviewer.md

dev-rulesやrole-rulesといった名前自体に決まりはなく、プロジェクトに合わせて付ければ十分です。重要なのは「1ファイル1トピック」に分けること。次のpathsフィールドで「今どのルールが必要か」まで自動で絞り込めます。

① YAMLフロントマターとは

YAMLフロントマターは、Markdownファイルの先頭に書く「設定用のメモ欄」です。---という3つのハイフンで囲んだ内側に、項目名: 値という形式で設定を書きます。

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

# API開発のルール

- すべてのAPIエンドポイントに入力値の検証を含めること
- 標準のエラーレスポンス形式を使うこと

---から---までがフロントマター、それより下がルール本文です。フロントマターを付けなければ、そのルールはいつも通り常に読み込まれます。

つまずきポイント:インデント（字下げ）
paths:の下の行は、必ず半角スペースで字下げしてから-（ハイフン）を書きます。タブ文字や不揃いな字下げは正しく認識されません。「設定したのに効かない」ときは、まずインデントを疑ってください。

② `paths`フィールド：ファイルを触ったときだけ読み込む

pathsフィールドは、「このルールをいつ読み込むか」の条件を書く場所です。判定の流れを図にすると、次のようになります。

図の通り、pathsが無いルールはセッション開始時に読み込まれますが、pathsがあるルールは実際に一致するファイルをClaudeが開いた瞬間にだけ読み込まれます。この「待機する」一手間がコンテキストの節約につながります。指定の有無での挙動を表にもまとめます。

	`paths`を指定しない場合	`paths`を指定した場合
読み込むタイミング	セッション開始時に常に読み込む	一致するファイルを実際に開いたときだけ読み込む
コンテキストへの影響	常に消費する	使わないときは消費しない
向いている内容	プロジェクト全体で常に知っておいてほしいルール	特定のフォルダや拡張子にだけ関係するルール

たとえば、フロントエンドのファイルしか触らないセッションでは、pathsでsrc/backend/**と指定したバックエンド用のルールは一度も読み込まれません。pathsを付けなければ、関係のないセッションでも毎回コンテキストに乗ってしまいます。

③ Globパターンの書き方

pathsに書くパターンは、Globパターンと呼ばれる、正規表現より簡単な記号でファイルの一致条件を表す書き方に従います。よく使う書き方を表にまとめます。

パターン	一致するもの
`*/.ts`	どの階層のフォルダにあってもよい、拡張子`.ts`のファイル
`src/*/`	`src`フォルダの配下にあるすべてのファイル
`*.md`	プロジェクトのルート直下にあるMarkdownファイルのみ
`src/components/*.tsx`	特定のフォルダにあるReactコンポーネント

**が「どんなに深い階層でも一致する」という意味を持つ点がポイントです。src/**/*.tsというパターンを例に、実際のファイルと照らし合わせると次のようになります。

図の通り、srcのすぐ下だけでなくsrc/utils/deep/のような深い階層にも一致する一方、拡張子が違うファイル（.tsx）には一致しません。

複数の拡張子は、中カッコを使った「ブレース展開」でまとめられます。

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

これはsrc配下の.tsと.tsxの両方に一致するという意味です。

複数のパターンをまとめて指定したいとき（フロントエンドとバックエンドの両方を対象にしたい、等）の書き方は2通りあります。片方は公式ドキュメントに実例がある書き方、もう片方は推測です。初めて書くときは、確実な方だけ覚えておけば十分です。

書き方	記述例	確実さ
リスト形式（行を増やす）	`paths:`の下に`- "src/frontend/**"`のような行を並べる	公式ドキュメントの`.claude/rules/`の説明で、例として直接示されている書き方
カンマ区切り（1行にまとめる）	`paths: src/frontend/, src/backend/`	Skills機能側の説明で「rulesと同じ形式」とされていることからの推測。`.claude/rules/`自体に例はありません

# 確実な書き方: リスト形式
paths:
  - "src/frontend/**"
  - "src/backend/**"

迷ったら、公式ドキュメントに実例があるリスト形式が確実です。パターンが多いほど見返しやすいのもリスト形式です。

Globパターンでは[が特別な意味（[abc]で「a・b・cのいずれか」）を持ちます。フォルダ名に[をそのまま含めたい場合は\[とエスケープ（記号の意味を打ち消すこと）してください。忘れると、そのパターンだけ一致しなくなります。

まとめ：まず1つ、条件付きルールを作ってみる

.claude/rules/にルールファイルを1つ用意し、先頭にフロントマターを足してpathsを指定するだけで、「必要な時だけ読み込まれるルール」が作れます。まずは自分のプロジェクトで一番範囲の狭いルール（特定のフォルダやテストファイル向けのルールなど）から試してみてください。

---
paths:
  - "**/*.test.ts"
---

# テストのルール

- describeとitで構造化すること
- モックは最小限に抑えること

作ったら、対象外のファイルだけを開いたセッションで/contextコマンドを実行し、「Memory files」の一覧にそのルールファイルが出てこないことを確認してください。対象のファイルを開いた後に再度/contextを実行すると、今度は一覧に加わっているはずです。これが「必要な時だけ読み込まれている」ことの確かめ方です。最後に、よくあるつまずきを表でまとめます。

つまずきやすい点	原因	対処
`paths`を書いたのに効かない	インデント（字下げ）がタブ文字だったり揃っていない	半角スペースで字下げを揃える
特定のフォルダ名だけ一致しない	フォルダ名に`[`が含まれ、Globの特殊記号と衝突している	`\[`のようにバックスラッシュでエスケープする
ルールが常に読み込まれてしまう	`paths`フィールド自体を書き忘れている	フロントマターの中に`paths`があるか確認する