パス固有ルールと条件付き規約読み込み

パス固有ルールは Claude Code の命令システムの条件付き層である——異なるフォルダ、ファイルタイプ、サブツリーが、すべてのプロジェクトを単一のモノリシックな CLAUDE.md に収めることなく、異なるコーディング規約を受け取れるようにするメカニズムである。CCA-F（Claude Certified Architect — Foundations）試験のタスクステートメント 3.3「条件付き規約読み込みのためのパス固有ルールの適用」は Domain 3（Claude Code の設定とワークフロー、20% の比重）に位置し、ブループリントの中で最も準備が不十分なサブトピックの1つである。このタスクステートメントを通過する受験者は、.claude/rules/ ディレクトリがどのように発見されるか、paths: グロブパターンが特定のターゲットファイルに対してルールファイルをどのように有効化するか、そしてパス固有ルールがより広い CLAUDE.md 階層をどのように置き換えるのではなくそれと相互作用するかを正確に知っている。

この学習ノートでは CCA-F 受験者がアーキテクチャレベルで設計できると期待される全領域を解説する：パス固有ルールの根拠、.claude/rules/ ディレクトリの発見モデル、ルールファイルの形状（YAML フロントマター + ルール本文）、paths: グロブ構文、Claude Code が現在考慮中のファイルの規約を解決する際のルール有効化ロジック、フレームワーク固有サブツリーのための規約の分離、テストファイル専用ルール、モノレポパッケージスコープルール、複数のルールファイルが一致する場合の優先順位、ディレクトリレベルの CLAUDE.md ファイルとの関係、そしてセッション中にどのルールが実際にアクティブかをデバッグする方法。最終的な落とし穴セクションと5問の FAQ がすべての抽象的な概念をタスク 3.3 を最も多く出題する code-generation-with-claude-code シナリオに結び付ける。

パス固有ルール — ファイルの場所に基づく異なる規約の適用

プロジェクトルートの CLAUDE.md はそのプロジェクトのすべてのタスクに対して評価される。これは小規模で均質なコードベースには合理的なデフォルトである。コードベースが均質でなくなる瞬間——バックエンドパッケージが1つのフレームワークを使用し、フロントエンドが別のものを使用し、生成コードフォルダは手動編集してはならず、テストファイルは本番コードとは異なるアサーションスタイルを使用する——単一のルート CLAUDE.md は条件テキストの壁になる（「src/api/* を編集している場合は...；tests/* を編集している場合は...；ファイルが .generated.ts で終わる場合を除いて...」）。Claude はこれらの条件をシステム的な指示よりも信頼性が低い形で従い、ファイルは維持不可能なモノリスに成長する。

パス固有ルールは、アーキテクトがファイルの場所に条件付きで規約を表現できるようにすることでこれを解決する。「テストを編集している場合」という分岐をルート CLAUDE.md に詰め込む代わりに、アーキテクトは .claude/rules/ の下に小さなルールファイルを配置し、そのフロントマターで「このルールは Claude Code が tests/** に一致するファイルを操作している場合にのみ適用される」と宣言する。Claude Code は現在のターゲットファイルがルールの paths: パターンの1つに一致する場合にのみルールをコンテキストに読み込む。無関係なルールはコンテキストの外に留まり、関連するルールは常に存在し、ルート CLAUDE.md はリーンに保たれる。

パス固有ルールがアーキテクチャ的に存在する理由

パス固有ルールが取り組む設計上の問題は編集の瞬間における命令の関連性である。Claude Code が apps/web/src/pages/index.astro を編集しようとしている場合、Astro の規約が重要であり、Python バックエンドの ruff フォーマットルールは重要でない。フロントエンドの編集のためにバックエンドのルールをコンテキストに読み込むことは純粋なノイズである——トークンを消費し、フレームワーク間の混乱のリスクを高め、実際に関連するルールに Claude が与える注意を希薄化する。パス固有ルールは Claude Code の答えである：命令の読み込みをファイルの場所にスコープして、すべてのタスクが最小かつ正しいセットの規約を見るようにする。

CLAUDE.md ファイルとの違い

CLAUDE.md ファイルは現在の作業ディレクトリの上の階層（グローバル、プロジェクト、ディレクトリ）に存在する場合に常に読み込まれる。パス固有ルールはグロブパターンに基づいて Claude Code が触れようとしているファイルが一致するかどうかに応じて条件付きで読み込まれる。2つのシステムは共存する：CLAUDE.md はプロジェクト全体の不変量（「すべての場所で TypeScript の strict モードを使用する」、「すべての公開関数は JSDoc を持たなければならない」）を運び；パス固有ルールはサブツリー固有の規約（「テストは vitest.describe グループを使用する」、「このディレクトリは自動生成されており、手動で編集してはならない」）を運ぶ。これらを互換と見なすことは頻繁な CCA-F の落とし穴である。

.claude/rules/ ディレクトリ — YAML ルールファイルとその発見

Claude Code はパス固有ルールを規約的な場所で探す：プロジェクトルートの .claude/rules/ ディレクトリ。そのディレクトリ内のすべてのファイル（通常 Claude Code のバージョンに応じて .yaml、.yml、または .md 拡張子を持つ）が候補ルールである。Claude Code はセッション開始時に各候補のフロントマターを読み取り、paths: パターンをインデックスし、エージェントが読み取り、書き込み、または編集しようとしている各ファイルに対してそれらを評価する。

ディレクトリレイアウト

my-project/
├── CLAUDE.md                      # プロジェクト全体、常に読み込まれる
├── .claude/
│   ├── rules/
│   │   ├── frontend.yaml          # apps/web/** に適用
│   │   ├── backend.yaml           # services/api/** に適用
│   │   ├── tests.yaml             # **/*.test.ts に適用
│   │   └── generated.yaml         # **/*.generated.ts に適用
│   └── commands/                  # カスタムスラッシュコマンド（タスク 3.2）
├── apps/
│   └── web/
│       └── CLAUDE.md              # ディレクトリスコープ CLAUDE.md（タスク 3.1）
├── services/
│   └── api/
└── tests/

ルールファイルは軽量である——通常それぞれ数箇条の箇条書き。ディレクトリはバージョン管理されるため、すべての貢献者とすべての CI 実行が同じ規約を見る。

ユーザーレベル vs プロジェクトレベルルール

Claude Code の設定階層はユーザーレベルルール（~/.claude/rules/ に格納され、開発者のマシン上のすべてのプロジェクトに適用される）とプロジェクトレベルルール（リポジトリ内の .claude/rules/ に格納され、そのプロジェクトにのみ適用される）を区別する。ユーザーレベルルールはチームメイトに押し付けるべきでない個人的な好みに有用である（好みのコミットメッセージのフレーズ、個人的なエイリアス）。プロジェクトレベルルールはすべての貢献者に適用されなければならないチームの規約のためである。CCA-F の問題はこの区別を定期的にテストする。

発見は自動的

カスタムスラッシュコマンドとは異なり、名前で呼び出す必要があるが、パス固有ルールはユーザーからの明示的な参照を必要としない。Claude Code はセッション開始時に .claude/rules/ ディレクトリをウォークすることで自動的に発見する。CLI フラグなし、import ステートメントなし、スラッシュコマンドなし——ルールはセッションが開くとすぐにアクティブになる。

YAML ルールファイルの構造 — paths フロントマター、ルール本文、優先順位

すべてのパス固有ルールファイルは同じ2部構成を持つ：YAML フロントマターブロックとルール本文。フロントマターはルールがいつ適用されるかを制御し；本文が実際の命令を運ぶ。

フロントマターフィールド

---
name: "Frontend Astro conventions"
description: "Astro + Tailwind conventions for apps/web"
paths:
  - "apps/web/**"
  - "apps/web/src/**/*.astro"
priority: 50
---

• name — Claude Code がどのルールが適用されたかを表示する際に使用される短いラベル。
• description — 1行のサマリー（チームドキュメントに役立つ；必須ではない）。
• paths — グロブパターンの配列；ターゲットファイルが少なくとも1つのパターンに一致する場合にルールが有効化される。
• priority — 2つのルールが同じファイルに一致する場合に競合を解決するオプションの整数（高い優先順位が勝つ）。

ルール本文

--- デリミタの下、ルール本文は規約を説明する自由形式の散文または箇条書きリストである。CLAUDE.md とまったく同じように書かれる——命令的な命令、短く、スキャンしやすい。

---
paths:
  - "apps/web/**"
---

## Astro コンポーネント規約

- ページには `.astro` ファイルを使用し；`.svelte` コンポーネントは `src/components/` の下に共存させる。
- スタイルは Tailwind ユーティリティクラスに；ページファイルにインライン `<style>` ブロックは使用しない。
- データフェッチはコンポーネントのフロントマターで行い、`<script>` タグ内では決して行わない。
- i18n には `src/i18n.ts` の `useTranslations(lang)` ヘルパーを使用する。

なぜ YAML フロントマターで他のものではないのか

YAML フロントマターは静的サイトジェネレーター（Astro、Jekyll、Hugo）、ドキュメントツール（MDX、Docusaurus）、および Claude Code 自身のスラッシュコマンドとスキルが使用する同じ規約である。再利用は重要：エンジニアはすでにフォーマットを知っており、エディタはすでに構文ハイライトしており、CI リンターは検証できる。この1つの機能のために独自の設定構文を採用することは摩擦になるだけで利益がない。

paths グロブパターン — src/**、tests/**、*.test.ts などのマッチング

paths: 配列は正規表現ではなくグロブパターンを使用する。これは CCA-F タスク 3.3 の問題で最も頻繁に見逃される機械的な詳細である。

試験で目にするグロブ演算子

• * は単一のパスセグメント内の任意の文字のシーケンスに一致する（/ を越えない）。
• ** は任意の数のパスセグメントに一致し、ゼロを含む。src/** は src/a.ts、src/a/b.ts、src/a/b/c.ts に一致する。
• ? は正確に1文字に一致する。
• [abc] はブラケット内の文字のいずれか1つに一致する。
• {json,yaml,yml} はカンマ区切りの代替のいずれか1つに一致する（ブレース展開）。

一般的なパターンとそれが一致するもの

paths:
  - "src/**"                # src/ 以下のすべて
  - "**/*.test.ts"          # どこにでもあるすべての .test.ts ファイル
  - "**/*.{test,spec}.ts"   # すべての .test.ts または .spec.ts ファイル
  - "services/api/src/**"   # バックエンドパッケージのソースツリーのみ
  - "**/generated/**"       # ツリーのどこにでもある generated/ フォルダ
  - "!**/node_modules/**"   # 否定 — node_modules を除外

パターンは（.claude/ フォルダを含む）プロジェクトルートに相対的に評価される。絶対パス、~ 展開、環境変数はサポートされていない。

グロブは正規表現ではない

グロブ src/*.ts は src/ 直下の TypeScript ファイルのみに一致する。src/components/Button.ts には一致しない。再帰的に一致させるには ** を使用しなければならない。正規表現 src/.*\.ts は両方に一致するが、paths: の解釈方法ではない。2つのメンタルモデルを混在させることは CCA-F Domain 3 の上位5つの落とし穴の1つである。

否定パターン

! が先頭に付いたパターンは、そうでなければ一致するファイルを除外する。否定は「src/ 以下のすべて（生成ファイルを除く）」に適用するルールに有用である：

paths:
  - "src/**"
  - "!src/**/generated/**"

評価器はパターンを順番に処理し、最後の一致が勝つため、リストの末尾の否定は前の包含をオーバーライドする。

ルール有効化ロジック — Claude Code が現在のファイルに適用するルールを決定する方法

Claude Code がファイルを読み取り、書き込み、または編集しようとする場合、次の有効化シーケンスを実行する：

1. ファイルのパスをプロジェクトルートに相対的に計算する。 apps/web/src/pages/index.astro は /my-project/ に相対的に正規化される。
2. .claude/rules/ で発見されたすべてのルールファイルをウォークする。 各ルールについて、paths: 配列の各パターンを相対パスに対して評価する。
3. ルールの paths: パターンの少なくとも1つが一致する場合にルールが有効化される。 否定パターンは同じルールのリスト内の前の一致を拒否権行使できる。
4. 有効化されたルール本文は編集または読み取りを生成する推論ターンのためにClaude のコンテキストに読み込まれる。
5. 有効化されていないルールは完全に省略される——トークンを消費せず、応答に影響しない。

有効化はセッションごとではなくファイルごとに起こる

長いエージェント実行は多くのファイルに触れる可能性がある。パス固有ルールの有効化はファイルごと（効果的にはファイルを名指しするツール呼び出しごと）に評価される。apps/web/src/index.astro の編集は frontend ルールを有効化する；次の services/api/src/main.ts の編集は代わりに backend ルールを有効化する。Claude Code はセッション開始時にルールのセットを「固定」してセッション全体にわたって運ぶことをしない。

実際の有効化の様子

tests/login.test.ts を読み取ることから始まり、次に src/auth.ts を読み取り、src/auth.ts を編集し、bash pnpm test を実行するセッションを想像してほしい。最初の Read ツール呼び出しは tests.yaml を有効化する；src/auth.ts の Read と Edit は backend.yaml（または src/** をターゲットにするルール）を有効化する；Bash 呼び出しはファイルパスルールを有効化しない、なぜなりファイルをターゲットにしないからである。4つのツール呼び出し、3つの異なるルール有効化、ユーザーからの手動介入ゼロ。

なぜファイルごとの有効化が重要か

ファイルごとの有効化は、ルールがサブツリーをまたいでリークできないことを意味する。エージェントが Python パッケージから TypeScript パッケージに移動すると、Python フォーマットルールは読み込まれなくなり、TypeScript strict モードルールがその場所を取る。これがパス固有ルールのアーキテクチャ上の成果である：コンテキスト内の規約は常に作業中のファイルに適用される規約である。

規約の分離 — フレームワーク固有のディレクトリへのフレームワーク固有ルールの適用

パス固有ルールの最も明確なユースケースは異質なコードベース内のフレームワークの分離である。マーケティングサイトに Astro を、内部ダッシュボードに Next.js を、Python バックエンドに FastAPI を使用するプロジェクトは、3つのフレームワークの規約すべてを単一の CLAUDE.md に詰め込むことは合理的にできない。規約は一部の場所で矛盾する（React のフックルール vs Astro のアイランド、FastAPI の依存性注入 vs 何もなし）、そして特定のファイルのルールのほとんどは特定のタスクに関係ない。

典型的な3フレームワークレイアウト

.claude/
└── rules/
    ├── astro.yaml         # paths: ["apps/marketing/**"]
    ├── nextjs.yaml        # paths: ["apps/dashboard/**"]
    └── fastapi.yaml       # paths: ["services/api/**"]

各ルールファイルはそのフレームワークの規約のみを運ぶ：コンポーネントパターン、データフェッチのイディオム、スタイリングアプローチ、テストライブラリ。Claude Code がマーケティングサイトのコンポーネントを編集している場合、Astro の規約のみを見る。FastAPI のルートを編集している場合、Python と FastAPI の規約のみを見る。クロス汚染なし、モンスター CLAUDE.md 内の条件テキストなし。

分離はフレームワーク間の混乱のリスクを低減する

パス固有ルールなしで、3つのフレームワークを1つの CLAUDE.md でカバーしようとするアーキテクトは「Astro ファイルを編集している場合はスタイリングに Tailwind を使用する；Next.js ファイルを編集している場合は CSS モジュールを使用する；FastAPI ファイルを編集している場合は Python なので何も使用しない」という文を書かなければならない。各条件は Claude への認知的負荷であり、間違ったブランチが従われる小さな確率である。.claude/rules/ による規約の分離はそれらの条件を完全に削除する——Astro のルールは単純に「スタイリングには Tailwind ユーティリティクラスを使用する」であり、when editing ガードは必要ない、なぜならルールは Astro ファイル以外では有効化されないからである。

テスト固有ルール — テストファイルと本番コードの異なる規約

テストファイルはほぼ常に独自のルールファイルに値する。本番コードを良くする規約（最小限のコメント、小さな関数、共有ヘルパー、重複を避ける）はテストにはしばしば完全に間違いであり、そこでは明確さが抽象を上回り、反復的なスキャフォールディングはセットアップを隠す共有フィクスチャより好ましい。

典型的なテスト固有ルール

---
name: "Test file conventions"
paths:
  - "**/*.test.ts"
  - "**/*.test.tsx"
  - "**/*.spec.ts"
  - "tests/**"
---

## テスト規約

- 関連するテストをグループ化するために `describe` ブロックを使用する；ファイルごとに1つのトップレベル `describe`。
- すべてのテストの `it(...)` 文字列は文として読める：「入力が空の場合に null を返す」。
- 空行区切り付きの明示的な arrange/act/assert セクションを優先する。
- テストのセットアップを共有ヘルパーに抽出しないこと（3つ以上のファイルで使用される場合を除いて）。
- モックは各テスト内でインラインで作成し、ファイルの先頭にホイストしない。

なぜ別のルールファイルが CLAUDE.md のセクションに勝るのか

「テストファイルを編集している場合」というタイトルのルート CLAUDE.md のセクションは、Claude がセクションを適用することを覚えることに依存する。paths: ["**/*.test.ts"] を持つ別のルールファイルはターゲットファイルがテストの場合に無条件に適用され、そうでない場合には決して適用されない。後者は構造的により信頼性が高い。

Claude Code によるコード生成シナリオ

CCA-F のコード生成シナリオはテストファイルルールを直接出題する。エージェントが「ログインフローのテストを追加する」よう求められ、Claude Code が login.test.ts を開く際に——ユーザーがルールに名前を付けたからではなく、グロブが自動的に有効化したから——テスト固有のルールが読み込まれる正しいアーキテクチャを含むシナリオ問題が出る。

モノレポのユースケース — 単一リポジトリでのパッケージ固有の言語とフレームワークルール

大規模なモノレポはパス固有ルールの標準的な場所である。企業のリポジトリには TypeScript ウェブアプリ、Go CLI、Python データパイプライン、Rust サービスが含まれる可能性があり、それぞれが完全に異なるツール、スタイルガイド、テスト規約を持つ。単一のルート CLAUDE.md はクロスパッケージ不変量（「すべてのコミットメッセージは conventional commits に従う」）を運ぶことができ、各パッケージの規約は独自のルールファイルに存在する。

現実的なモノレポレイアウト

mono/
├── CLAUDE.md                      # チーム全体の不変量
├── .claude/
│   └── rules/
│       ├── web-app.yaml           # paths: ["packages/web/**"]
│       ├── cli-tool.yaml          # paths: ["packages/cli/**"]
│       ├── data-pipeline.yaml     # paths: ["packages/pipeline/**"]
│       └── rust-service.yaml      # paths: ["services/gateway/**"]
├── packages/
│   ├── web/
│   ├── cli/
│   └── pipeline/
└── services/
    └── gateway/

なぜルールファイルがパッケージスコープ CLAUDE.md 単独に勝るのか

モノレポはパッケージごとに CLAUDE.md ファイルをネストすることもできる（packages/web/CLAUDE.md、packages/cli/CLAUDE.md）。これは正当であり、多くの小さなケースでは十分である。ルールファイルが価値を追加するのは、単一の規約が複数のパッケージにまたがる必要がある場合（例えば「すべての生成コードはこのヘッダーコメントを使用する、パッケージに関係なく」）または規約がパッケージ全体ではなくパッケージのファイル拡張子スライスに適用される必要がある場合である。paths: ["**/*.generated.ts"] を持つパス固有ルールはすべてのパッケージにわたって生成ファイルに一致し、単一の CLAUDE.md の配置では達成できないことである。

モノレポルールの衛生

ルール本文を短く保つこと。10のパス固有ルールファイルがそれぞれ300行のモノレポは、ごく簡単な編集でも何百トークンものオーバーヘッドを読み込む。各ルール本文は、エンジニアが30秒で読めるほど小さく、すべての箇条書きが重要なほど具体的であるべきである。

ルールの競合 — 複数のルールが同一パスに一致する場合の優先順位

単一のファイルが複数のルールファイルに一致することは一般的で正当である。tests/integration/auth.test.ts は tests.yaml（**/*.test.ts により）と integration-tests.yaml（tests/integration/** により）の両方に一致する可能性がある。Claude Code は1つを選んで他を削除するのではなく——一致するすべてのルールを読み込む。競合解決は、ルールの命令が矛盾する場合に重要である。

優先順位の順序

2つ以上のルールが同じファイルに一致し、その命令が競合する場合、優先順位は次の順序で解決される：

1. より具体的な paths: パターンが勝つ。 より少ないファイルに一致するパターンはより具体的と見なされる。tests/integration/** は tests/** より具体的であり、これは ** より具体的である。
2. より高い priority: フィールドが勝つ。 具体性が等しい場合、より高い priority: 値のフロントマターを持つルールが低い優先順位のルールをオーバーライドする。
3. 後で読み込まれたルールが最終的なタイブレーカーとして勝つ。 ルール発見の順序は決定論的であり（通常 .claude/rules/ 内のファイル名のアルファベット順）、他のすべての解決基準が等しい場合に後のルールの命令が優先される。

非競合の合成

ほとんどのマルチルール有効化は競合ではない——加法的である。tests.yaml と backend.yaml の両方に一致するファイルは、両方の命令セットをコンテキストに取得し、それらはクリーンに合成される（「describe/it を使用する + 構造化エラー応答を使用する」）。競合解決は真の矛盾（「Tailwind を使用する」vs「CSS モジュールを使用する」）にのみ重要である。アーキテクトは優先順位に頼って解決するのではなく、矛盾を最小化するようにルールを設計するべきである。

CLAUDE.md との競合

階層内の CLAUDE.md から高い場所にある命令と矛盾するパス固有ルールはサイレントに勝つわけではない。CLAUDE.md の命令はデフォルトの規約セットを形成し；パス固有ルールはそれを補完する。両者が真に不一致の場合、パス固有ルールをローカルの例外として扱い、それをルール本文で明示的にする：「このサブツリーでは X というプロジェクト全体のルールから逸脱する、なぜなら Y だからである。ここではローカルルールに従うこと。」明示的なフレーミングにより Claude がどちらに従うかを推測することを防ぐ。

ディレクトリ CLAUDE.md との相互作用 — CLAUDE.md 命令の上に積み重なるルール

パス固有ルールはディレクトリレベルの CLAUDE.md ファイルを置き換えない——共存する。この積み重ねを理解することはタスク 3.1 とタスク 3.3 の両方に中心的である。

3層命令モデル

1. ルート CLAUDE.md — 常に読み込まれ、プロジェクト全体の不変量を運ぶ。
2. ディレクトリ CLAUDE.md ファイル — 現在の作業ディレクトリが CLAUDE.md のディレクトリと同じかそれ以下の場合に読み込まれる。ディレクトリ固有の無条件コンテキストを追加する。
3. .claude/rules/ のパス固有ルール — ターゲットファイルのパスに基づいて条件付きで読み込まれ、現在の作業ディレクトリとは独立している。

3つの層すべてが積み重なる。apps/web/src/index.astro の編集はルート CLAUDE.md、apps/web/CLAUDE.md、および .claude/rules/astro.yaml ルールファイルを同時に取り込める。3つが合わさってその編集の完全な命令コンテキストを形成する。

各層をいつ使用するか

• ルート CLAUDE.md をプロジェクトのすべてのファイルに適用される不変量に使用する。例：「pnpm を使用し、npm は使わない」、「コミットメッセージは conventional commits に従う」、「すべての PR にはテストが必要」。
• ディレクトリ CLAUDE.md を、ファイル拡張子やファイルタイプに関係なく、そのサブツリーで常に関連するコンテキストをサブツリー全体で共有する場合に使用する。例：apps/web/CLAUDE.md はウェブアプリのすべてのファイルに適用されるウェブアプリのデータフェッチパターンとルーティング規約を文書化する。
• パス固有ルールを、適用可能性がファイルパターンに条件付きの場合（テスト vs 本番、生成 vs 手書き、ある拡張子 vs 別の拡張子）または、ルールが複数のディレクトリにまたがらなければならない場合（パッケージに関係なくすべての *.generated.ts ファイル）に使用する。

なぜ積み重ねが試験に重要なのか

CCA-F の引っかけ回答はディレクトリ CLAUDE.md とパス固有ルールを定期的に混同する。2つは関連しているが互換ではない。ディレクトリ CLAUDE.md はディレクトリサブツリー内で無条件；パス固有ルールはグロブパターンに条件付きであり、作業ディレクトリと独立している。これらのメンタルモデルを混在させると、過度に大きいルート CLAUDE.md（過少スコープ）または単一ファイルとして存在すべきだったサブツリー固有の条件（過大スコープ）のいずれかの設計を生む。

アクティブルールのデバッグ — 特定のファイルに対してどのルールが適用されているかの確認

サイレント失敗はパス固有ルールに関する最も一般的なフラストレーションである：ルールファイルはコミットされ、パターンは正しそうに見えるが、Claude が規約を無視している。特定のファイルに対してどのルールが実際にアクティブかを確認できることは、すべての CCA-F 受験者が持つべき運用スキルである。

アクティブルールを確認する3つの方法

1. Claude に直接聞く。 「apps/web/src/index.astro に現在どのルールファイルが読み込まれていますか？各ルールファイルの名前と一致した paths: パターンをリストしてください」のようなセッションレベルのプロンプトが Claude が可視性を持つインベントリを生成する。
2. Claude Code の診断出力を使用する。 Claude Code のバージョンに応じて、CLI は現在の作業ファイルに一致したルールファイルを含むアクティブな設定をリストするコマンド（または同等のスラッシュコマンド）を公開する。
3. 代表的な編集のドライラン。 Claude にターゲットファイルをどのように編集するかを説明するよう求める；出力がルールの規約を反映している場合、ルールはアクティブである。反映していない場合は、paths: パターンのタイポを検査する。

一般的な失敗モード

• グロブのタイポ。 ** の欠落、間違った拡張子、ディレクトリ名のスペルミス。パターンを反復的に絞り込んで修正する。
• ベースディレクトリの間違い。 パターンはプロジェクトルートに相対的に評価され、現在の作業ディレクトリに相対的ではない。ルートの .claude/rules/ ファイルの src/** は ./src/** に一致し、./apps/web/src/** には一致しない。
• .gitignore されているファイル。 .gitignore されている生成ファイルはディスク上に依然として存在し、Claude Code がそれらを編集する際にパス固有ルールに一致する——これは正しい動作であるが、時々驚きを生む。
• ユーザーレベル vs プロジェクトレベルの場所の不一致。 ~/.claude/rules/ に配置されたルールは1台のマシンにのみ適用され、リポジトリにコミットされない。リポジトリ内の .claude/rules/ に配置されたルールはすべての貢献者に適用される。これらを混在させると「私のマシンでは動作する」バグが生じる。

ルールデバッグを第一級のワークフローとして扱う

ルールはコードである。.claude/rules/ ディレクトリを他のコードと同じ規律で扱うこと：アトミックな変更をコミットし、PR でグロブパターンをレビューし、レビュアーが有効化の表面をサニティチェックできるよう PR の説明に代表的な一致ファイルのサンプルを含める。

やさしい解説: パス固有ルールの全体像をカバーする3つの全く異なる類比

類比1：レストランのステーション固有のレシピカード

複数のステーション——グリル、パティスリー台、コールドステーション、ピザ窯——を持つ大きなレストランを想像してほしい。ヘッドシェフはレストラン全体の基準の単一のマスターブックを持つ（「左から右にプレートを盛る」、「グラムで量を測る」、「サービス前にアレルゲンを呼び出す」）。そのマスターブックはルート CLAUDE.md である。しかし各ステーションにはそのステーションでのみ適用される命令が記されたラミネートカードが作業台の上にある——パティスリーカードは「チョコレートを31℃にテンパリングする」と言い、ピザカードは「オーブンを485℃で90秒」と言う。それらのカードはパス固有ルールである。グリルラインのコックはパティスリーカードを読まない——グリルからは見えない——しかしパティスリーのコックにとって常にそこにある。カードはマスターブックを置き換えない；ステーション固有の規約でそれを補完する。Claude Code が編集しているパスは、エージェントが作業しているステーションである；ルールファイルは各ステーションの上に掛かっているラミネートカードである。マスターブックと関連するステーションカードの両方が同時にコックの前にある。どのコックも一度にすべてのステーションのカードを扱う必要がない。

類比2：図書館のセクション固有のサイネージ

公共図書館には入り口に掲示された一般ルールがある——「飲食禁止、大声での会話禁止、21日以内に本を返却する」。それらの一般ルールはルート CLAUDE.md である。図書館内で、特定のセクションが追加のサイネージを掲示する：子供のセクションには「おはなしタイムのラグでは靴を脱いでください」、希少本の部屋には「ペン禁止、鉛筆のみ、写真撮影禁止」、コンピューターラボには「30分セッション、個人用 USB ドライブ禁止」。それらのセクション固有のサインがパス固有ルールである。子供のセクションの利用者は一般ルールと子供のセクションのサインを見る；希少本の部屋の研究者は一般ルールと希少本のサインを見る。一般ルールは変わらない——どこにでも適用される——しかし各部屋は独自の条件付き層を追加する。正規表現スタイルのマッチングスキームは、1つのマスターサインに長い条件文ですべてのセクションの例外をエンコードしようとするようなものである。誰もそれを読まないし、誰も従わない。別のセクション固有のサインの方がより信頼性が高い、これがまさに Claude Code がパス固有ルールを .claude/rules/ 以下の独自のファイルに分けている理由である。

類比3：電気技師の配線コードオーバーレイ

認定電気技師は全国電気コードを持ち歩く（常時オンのルールブック——ルート CLAUDE.md）。しかし建築基準はローカルでもある：特定の都市はその管轄内でのみ適用される修正を持ち；特定の建物タイプ（病院、データセンター、住宅）はその建物タイプにのみ適用される追加の要件を持ち；特定の部屋（湿潤エリア、爆発防止環境、屋外設置）はその部屋でのみ適用されるさらなる要件を持つ。病院の手術室を配線する電気技師は全国コード、病院コード、湿潤エリアコードを同時に従う。3つのうちのいずれも他を上書きしない——それらは積み重なる。住宅の台所での配線作業は全国コードと住宅コードに従うが、病院コードには従わない。オーバーレイは純粋に場所ベースである。Claude Code のパス固有ルールはまさにこの種のオーバーレイである：ファイルの場所（paths: グロブによって一致した）がどの条件付きルールブックが適用されるかを決定し、無条件のプロジェクト全体の CLAUDE.md の上に積み重なる。

どの類比がどの試験問題に適合するか

• パス固有ルールが存在する理由に関する問題 → レストランのステーションの類比（作業場ごとの命令の関連性）。
• ルールが CLAUDE.md とどのように積み重なるかに関する問題 → 図書館のサイネージの類比（常時オンのルールとセクション固有のルール）。
• モノレポ / 条件付き適用可能性に関する問題 → 電気技師のコードオーバーレイの類比（管轄ベースの積み重ね）。

一般的な試験の落とし穴

CCA-F Domain 3 はパス固有ルールに関して5つの繰り返す落とし穴パターンを常に利用する。5つすべてがコミュニティの合格報告で文書化され、もっともらしい引っかけ選択肢として偽装されて出現する。

落とし穴1：paths が正規表現ではなくグロブを使用する

paths: パターンはグロブであり、正規表現ではない。引っかけ回答は正規表現演算子（.*、\d+、否定の [^abc]）を使ったパターンを説明し、正しいとして提示する。それらは間違いである。グロブは *、**、?、[abc]、{a,b,c}、! を使用する。回答が paths: を正規表現として扱っている場合は除外すること。

落とし穴2：ルールが CLAUDE.md 階層を置き換える

パス固有ルールは CLAUDE.md 階層を補完する；置き換えない。引っかけ回答は .claude/rules/ を CLAUDE.md の「新しいモダンな代替」として枠組みするか、パス固有ルールを優先して CLAUDE.md の削除を推奨する。どちらの枠組みも間違いである。正しいアーキテクチャは、チーム全体の不変量のためのリーンなルート CLAUDE.md プラス条件付きサブツリーのためのターゲットを絞ったパス固有ルールである。

落とし穴3：ルールのインポートまたは有効化が必要

パス固有ルールは .claude/rules/ から自動的に発見される。それらを有効化するためにインポートステートメント、CLI フラグ、スラッシュコマンドの呼び出しは必要ない。「ルールを読み込む」ステップを追加する引っかけ回答（/load-rules スラッシュコマンド、@import path/to/rule.yaml 参照、enabled: true フィールド）は過度に設計されており間違いである。

落とし穴4：ユーザーレベルルールがチーム全体に適用される

~/.claude/rules/ のルールはローカル開発者のマシンにのみ適用される；リポジトリにコミットされず、チームメイトや CI には伝播しない。すべての貢献者に適用されなければならないルールはプロジェクトルートの .claude/rules/ の下に属する。チームの規約を ~/.claude/rules/ に配置する、またはマシン固有の好みをプロジェクトルールディレクトリに配置する引っかけ回答は反対方向に間違いである。

落とし穴5：パターンの具体性が唯一のタイブレーカー

2つのルールが同じファイルに一致する場合、paths: パターンの具体性が最初のタイブレーカーであるが、唯一のものではない。priority: フロントマターフィールドが同等の具体性を持つルールの間でタイを破り、読み込み順序が最終的なタイブレーカーである。「より長いパスを持つルールファイルが常に勝つ」と言う引っかけ回答は priority: フィールドと明示的オーバーライドメカニズムを無視している。

実践アンカー

パス固有ルールの概念は CCA-F の6つのシナリオのうちの1つで最も多く出現する。以下をシナリオクラスター問題のアーキテクチャの背骨として扱うこと。

Claude Code によるコード生成シナリオ

これはタスク 3.3 を最も直接的に出題するシナリオである。その中では、Claude Code が非自明なコードベース——通常は複数のパッケージを持つモノレポ、フロントエンドとバックエンドの混合、別個のテストディレクトリ、生成またはオートマネージされたファイルで手動編集してはならない——にわたってコードを生成およびリファクタリングするために使用される。シナリオはパス固有ルールに強く依存する：正しいアーキテクチャはチーム全体の不変量のための薄いルート CLAUDE.md、フレームワーク固有の規約のための .claude/rules/ 以下のパッケージごとのルールファイル、テスト規約のための **/*.test.ts ルール、Claude にファイルが自動管理されていることを伝える **/generated/** または **/*.generated.ts ルールである。引っかけ回答はすべての規約を単一のルート CLAUDE.md に詰め込む、生成ファイルルールを無視する（Claude が次の生成で上書きされるコードを手動編集する），またはチームルールをユーザーレベルのディレクトリに配置することを定期的にする。

また、同じファイルに複数のルールファイルが一致する場合の優先順位の順序をテストする問題、否定パターンの使用（「src/ 以下のすべて（生成ファイルを除く）」に適用するルール）をテストする問題、およびルール有効化の確認——オペレーターが特定のターゲットファイルに対して正しいルールが読み込まれていることをどのように確認するか——に関する問題が出る。開発者の生産性を向上させる claude のシナリオもパス固有ルールに触れるが、その主な比重はタスク 3.3 よりもタスク 3.1（CLAUDE.md 階層）にある。

FAQ — パス固有ルールのよくある質問

Claude Code におけるパス固有ルールとは正確に何か？

パス固有ルールは .claude/rules/ に格納された YAML フロントマターファイルであり、その paths: 配列はグロブパターンのリストを宣言する。ルール本文は、現在のターゲットファイルが宣言されたパターンの少なくとも1つに一致する場合にのみ Claude のコンテキストに読み込まれる。パス固有ルールは無条件の CLAUDE.md 階層の上にある条件付き層である。ルールファイルはセッション開始時に自動的に発見される——インポートなし、有効化フラグなし、スラッシュコマンドは不要——そしてルートおよびディレクトリ CLAUDE.md ファイルとそれらを置き換えるのではなく共存する。標準的なユースケースは異質なコードベースでのフレームワークの分離、テストファイルの規約、生成ファイルの保護、モノレポでのパッケージスコープルールである。

ルールファイルのパスは正規表現かグロブパターンか？

グロブであり、正規表現ではない。使用する演算子は *（1つのパスセグメント、任意の文字）、**（ゼロ以上のパスセグメント）、?（単一文字）、[abc]（文字クラス）、{a,b,c}（ブレース代替）、!（否定）である。paths: 内で .*、\d+、またはアンカー付き数量子のような正規表現演算子を使用しようとすると、サイレントに一致に失敗する。この区別は CCA-F タスク 3.3 で最も頻繁にテストされる機械的な詳細の1つである。ルールを構築する際は、最も粗いパターンで機能するもの（** または src/**）から始め、代表的なファイルで有効化を確認し、次に必要に応じてパターンを絞り込むこと。

パス固有ルールは CLAUDE.md ファイルを置き換えるか？

しない。パス固有ルールは CLAUDE.md 階層を補完する——置き換えない。正しいアーキテクチャは、プロジェクト全体の不変量を運ぶリーンなルート CLAUDE.md、オプションでサブツリー無条件コンテキストのためのディレクトリ CLAUDE.md ファイル、プラス .claude/rules/ の条件付きサブツリー規約のためのパス固有ルールである。3つの層すべてが積み重なる：ファイルの編集は同時にルート CLAUDE.md、ディレクトリ CLAUDE.md、および複数のパス固有ルールファイルを有効化でき、そのすべてが Claude が見る命令コンテキストに貢献する。パス固有ルールを CLAUDE.md の新しい代替として枠組みする CCA-F の引っかけ回答は間違いである；システムは相補的である。

2つのルールファイルが同じターゲットファイルに一致する場合はどうなるか？

両方のルールファイルが有効化され、両方のルール本文がコンテキストに読み込まれる。それらの命令が単に加法的であれば（1つがテスト規約をカバーし、他がバックエンドエラー処理をカバーする）、クリーンに合成される。それらの命令が真に競合する場合、優先順位は次の順序で解決される：(1) より具体的な paths: パターンを持つルールが勝つ；(2) 同等に具体的なルールの中では、より高い priority: フィールドが勝つ；(3) 最終的なタイブレーカーとして、後で読み込まれたルールが勝つ。アーキテクトは、より具体的なルール内の明示的な「ローカルの例外」フレーミングが暗黙的なオーバーライドより好ましいため、優先順位に頼って解決するのではなく真の競合を最小化するようにルールファイルを設計するべきである。

特定のファイルに対してどのルールがアクティブかをどのように確認するか、そしてサイレント有効化失敗の原因は何か？

3つの方法が機能する：(1) セッション内で Claude に直接聞く（「apps/web/src/index.astro に現在どのルールファイルが読み込まれていますか？」）；(2) CLI 経由で Claude Code の診断出力を使用する；(3) 代表的な編集をドライランして Claude の提案した変更がルールの規約を反映しているかどうかを確認する。最も一般的なサイレント失敗の原因は、グロブのタイポ（** の欠落、間違った拡張子）、間違ったベースディレクトリに相対的に評価されるパターン（パスは .claude/ を含むプロジェクトルートに相対的に解決され、現在の作業ディレクトリではない）、および現在の作業ディレクトリではなくユーザーレベルの ~/.claude/rules/ ディレクトリにチーム全体のルールを配置することである。ルールディレクトリをコードとして扱うこと：バージョン管理し、PR でグロブパターンをレビューし、レビュアーが有効化の表面をサニティチェックできるよう PR の説明に代表的な一致ファイルを含める。

参考資料

• CLAUDE.md configuration — Claude Code Docs: https://docs.anthropic.com/en/docs/claude-code/claude-md
• Claude Code settings reference: https://docs.anthropic.com/en/docs/claude-code/settings
• Claude Code features overview: https://docs.anthropic.com/en/docs/claude-code/overview
• Custom slash commands and skills: https://docs.anthropic.com/en/docs/claude-code/slash-commands

関連する ExamLab トピック：Claude Code CLAUDE.md 階層、カスタムスラッシュコマンドとスキル、大規模コードベース探索のコンテキスト管理、組み込みツールの選択と適用。