Claude Code のルールとは？ .claude/rules フォルダと paths フロントマターによる読み込み制御 (2026年版)

Anthropic の記憶（memory）に関するドキュメントでは、次のように紹介されています。「大規模なプロジェクトでは、.claude/rules/ ディレクトリを使用して指示を複数のファイルに整理できます。これにより、指示がモジュール化され、チームでの維持管理が容易になります。」

ルールは Markdown ファイルです。プロジェクトの .claude/rules/ ディレクトリに、testing.md や api-design.md のように、内容を示す名前を付けてトピックごとに配置します。「すべての .md ファイルは再帰的に検出されるため、frontend/ や backend/ のようなサブディレクトリにルールを整理することも可能です」。

ルールには2つの種類があります：

• paths フロントマターのないルール: すべてのセッションの開始時に読み込まれます。
• パス指定（path-scoped）ルール: paths フィールドを持ち、Claude が一致するファイルを操作するときにのみ読み込まれます。

ドキュメントでは、このトレードオフを次のようにまとめています。「ルールは、セッションごと、または一致するファイルが開かれたときにコンテキストに読み込まれます。常にコンテキストにある必要がないタスク固有の指示については、代わりにスキル（skills）を使用してください。スキルは、呼び出したとき、または Claude がプロンプトに関連すると判断したときにのみ読み込まれます。」

paths フィールドのないルールは、プロジェクトの指示の一部として動作します。「paths フロントマターのないルールは、起動時に .claude/CLAUDE.md と同じ優先度で読み込まれます。」

これにより、スコープのないルールは、Claude が見る内容を変えることなく、長い CLAUDE.md を分割する手段となります。内容は依然として毎セッション読み込まれますが、別々のファイルに分かれているためメンテナンスが容易になります。

パス指定ルールは、glob パターンをリストした YAML フロントマターで始まります。

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

- すべての API エンドポイントには入力バリデーションを含めること
- 標準のエラーレスポンス形式を使用すること

ドキュメントでは、トリガーについて具体的に述べています。「パス指定ルールは、Claude が一致するファイルに対して Read、Write、または Edit ツールを使用したときに読み込まれます。」また、Claude が cat や単一ファイルへの head など、読み取りとみなされる Bash コマンドで一致するファイルを表示したときにも読み込まれ、プロジェクトディレクトリへのシンボリックリンク経由でも機能します。

ここから2つの結論が導かれます：

• ファイル名に言及するだけでは不十分です。 ルールが読み込まれるのは、Claude が一致するファイルを読み取り、書き込み、または編集したときであり、プロンプトでファイル名を指定したときではありません。
• ルールは開始時には存在しません。 Claude が一致するファイルに触れるまで、そのルールはコンテキスト内にはありません。

パターンのマッチング方法

パターンはルールのベースディレクトリからの相対パスです。プロジェクトルールの場合はルールの .claude フォルダを含むディレクトリ、ユーザーレベルのルールの場合はセッションの主要な作業ディレクトリになります。

複数のパターンをリストしたり、src/**/*.{ts,tsx} のようなブレース展開を使用したりできます。ブレース展開には制限があります。ルールの paths リスト全体で「1,000 個の展開パターンと 4 MiB」という予算を共有し、これを超えるパターンは展開されずに使用されるため、そのブレースはいかなるファイルにもマッチしなくなります。

角括弧 [] は glob 構文です。括弧式として読み取れない [ を含むパターンは無効となり、何もマッチしません（ただし、そのルールの他のパターンは機能し続けます）。リテラルの [ にマッチさせるには、エスケープしてください。

よくある落とし穴はワークツリー（worktrees）です。ドキュメントによると、隣接する Git ワークツリー内のファイルに対してパス指定ルールを読み込ませるには、そのワークツリーで Claude Code を起動するか、/cd でセッションをそこに移動させる必要があります。

フロントマターに含めることができるもの

重要なフィールドは1つだけです。「paths は Claude Code がルールから読み取る唯一のフィールドであり、他のフィールドはエラーなしで無視されます。」 Claude Code はルールを読み込む前にフロントマターを取り除くため、コンテキストを消費しません。

YAML の解析に失敗した場合、ルールは静かに消えるわけではありません。Claude Code は「フロントマターを無視し、paths がないものとしてルールを読み込みます」。フロントマターのタイポは、スコープ付きルールを「毎セッション読み込まれるルール」に変えてしまいます。解析エラーを確認するには claude --debug を実行してください。

ルールはプロジェクト単位だけではありません。「~/.claude/rules/ にある個人用ルールは、マシンのすべてのプロジェクトに適用されます。」これらは、特定のコードベースに依存しない好みの設定に適しています。

ユーザールールとプロジェクトルールで意見が食い違う場合、順序が重要になります。「Claude Code はプロジェクトルールの前にユーザーレベルのルールを読み込むため、プロジェクトルールはユーザールールよりもコンテキストの後方に表示されます。どちらのセットも他方を上書きすることはありません。ユーザールールとプロジェクトルールが競合する場合、Claude はいずれかに従う可能性があるため、両者の一貫性を保つようにしてください。」競合する CLAUDE.md レイヤーを調整するためのガイドでは、これらの競合を見つける方法を解説しています。

シンボリックリンクによるルールの共有

.claude/rules/ ディレクトリはシンボリックリンクをサポートしているため、チームで1つのルールセットを維持し、それを複数のプロジェクトにリンクさせることができます。シンボリックリンクが作業ディレクトリの外を指している場合、Claude Code はそれを外部インポートとして扱います。リンクされたルールは、プロジェクトの外部インポートを承認するまで読み込まれず、承認後は paths フィールドのないものだけが読み込まれます。ネットワークパスへのシンボリックリンクは一切読み込まれません。

どちらもユーザーが記述する指示ですが、見つけられ方と読み込みのタイミングが異なります。

サブディレクトリ内の CLAUDE.md ファイルもオンデマンドで読み込まれるため、ディレクトリによるスコープ設定はいずれでも可能です。ルールはパターンによるスコープ設定を追加し、場所に関わらずすべてのテストファイルを対象にするなど、ディレクトリを横断した指定が可能です。

オンデマンドファイルには制限が共有されています。パス指定ルールとサブディレクトリの CLAUDE.md ファイルにはそれぞれファイルごとのサイズ制限があり、それを超えたファイルは冒頭部分のみが Claude に渡されます。Claude Code のサブディレクトリ CLAUDE.md 制限に関するガイドで、具体的な数値と確認方法を解説しています。

他のコーディングツールと指示を共有している場合は、Cursor と Claude Code で1つの記憶を共有するためのガイドで、それぞれが読み取るファイルについて解説しています。

コンパクション（履歴の圧縮）は、2種類のルールを異なる方法で処理します。コンテキストウィンドウのドキュメントでは、プロジェクトルートの CLAUDE.md とスコープなしルールはコンパクション後に「ディスクから再注入（Re-injected）」されると記載されていますが、paths: フロントマターのあるルールはオンデマンドで再読み込みされます。

その理由は次の通りです。「パス指定ルールとネストされた CLAUDE.md ファイルは、Claude がトリガーファイルを読み取り、書き込み、または編集したときにメッセージ履歴に読み込まれるため、コンパクションによって他のすべてと一緒に要約されて消えてしまいます。」コンパクション後、パス指定ルールは Claude が再び一致するファイルに触れるまで戻ってきません。

ドキュメントには、脱落してはならないルールについての直接的な指示があります。「ルールをコンパクション後も維持する必要がある場合は、paths: フロントマターを削除するか、プロジェクトルートの CLAUDE.md に移動してください。」Claude Code の自動コンパクションの狙い所に関するガイドでは、コンパクションが保持するその他の内容について解説しています。

ルールにスコープを設定し、開始時から存在することを期待する。 パス指定ルールは、セッション開始時ではなく、Claude が一致するファイルに触れたときに読み込まれます。

フロントマターに description などのフィールドを追加する。 paths だけが読み取られ、他のフィールドはエラーなしで無視されます。

無効な YAML を書く。 その場合、ルールは paths がないものとして、毎セッション読み込まれます。

必須のルールを paths の後ろに置く。 コンパクション後、一致するファイルに再び触れるまでそのルールは消えてしまいます。

矛盾するユーザールールとプロジェクトルールを保持する。 どちらも他方を上書きしません。Claude はいずれかに従う可能性があります。

隣接するワークツリーで実行する。 別のワークツリーのパス指定ルールは、セッションをそこで開始するか /cd で移動しない限り読み込まれません。

ステップ 1: CLAUDE.md をトピックファイルに分割する

長い CLAUDE.md の自己完結した各セクションを、.claude/rules/ 内の独自のファイルに移動し、内容を示す名前を付けます。最初はこれらにスコープを設定しないでください。Claude が見る内容はまだ何も変わりませんが、ファイルは読みやすく、レビューしやすくなります。

ステップ 2: 特定の場合にのみ関連するルールにスコープを設定する

支払いモジュール、テストフレームワーク、フロントエンドディレクトリなど、特定のファイルにのみ関係するルールに paths を追加します。コンパクションを生き残る必要があるルールを含め、Claude がすべてのタスクで従うべきものはスコープを設定しないままにします。各パターンをリポジトリの実際のファイルパスと照らし合わせて確認し、各スコープ付きファイルをファイルサイズ制限内に収めます。

ステップ 3: 実際にどのルールが読み込まれたかを確認する

/context を実行して、起動時にどの CLAUDE.md とルールファイルが読み込まれたかを確認します。パス指定ルールは、トリガーされるまでそこには表示されません。トリガーが発生する様子を監視するには、ドキュメントで推奨されている InstructionsLoaded フックを使用します。これにより、どの CLAUDE.md やルールファイルが、いつ、なぜ読み込まれたかがログに記録されます。読み込まれるべきルールが読み込まれていない場合は、パターン、ベースディレクトリ、フロントマター、およびプロジェクトルールをスキップする --setting-sources によってプロジェクト設定が除外されていないかを確認してください。

ルールが読み込まれているのに Claude がそれに従わない場合は、AI エージェントが指示ファイルを無視する理由に関するガイドで他の原因を確認してください。また、Claude に与えた修正が定着しない場合は、Claude Code が修正を忘れる問題に関するガイドで修正の行き先を解説しています。

ルールは、リポジトリ内のコードをどのように書くべきかという指示には最適です。しかし、その背後にある推論、つまりなぜその慣習が存在するのか、どのような代替案が試されたのか、どの決定がコードではなく会議から生まれたのかといったことを記述するのにはあまり向いていません。そのようなコンテキストは、複数のリポジトリや複数のツールにとって重要です。

MemoryLake は、そのようなコンテキストを1つのリストとして維持し、Claude Code や、接続した Codex、ChatGPT などの他のアシスタントから利用できるようにするための記憶（memory）レイヤーです。

エントリはあなた自身の言葉で記述します。.claude/rules/ ファイル、CLAUDE.md ファイル、自動記憶、またはベンダーのストアから何かが読み取られたり、書き込まれたり、削除されたりすることはありません。Claude Code は Anthropic が説明する方法でルールを読み込み続けます。

ステップ 1: API キーを作成する

サインインしてダッシュボードからキーを生成します。キーは MemoryLake ワークスペースに属し、Claude アカウントとは別個のものです。

ステップ 2: 最初の記憶をアップロードする

ルールの背後にある理由から始めましょう。なぜその慣習が存在するのか、それが何に取って代わったのか、以前は何がうまくいかなかったのか。1つのエントリにつき1つのポイントを記述し、日付を入れ、それが説明するリポジトリやルールファイルのラベルを付けます。

ステップ 3: AI とエージェントを接続する

Claude Code や使用している他のアシスタントを接続します。ルールはリポジトリに残り、推論は作業が行われる場所ならどこでも利用可能になります。

第一の違いは、何も失うことなく CLAUDE.md が短くなることです。トピックファイルが同じ指示を担い、スコープ付きのものは不要なセッションでコンテキストを消費しなくなります。

第二に、いつルールが有効になっているかがわかるようになります。スコープなしルールは最初から存在し、コンパクション後も戻ってきます。スコープ付きルールは最初の一致するファイルと共に現れ、コンパクション後に脱落する可能性があります。

第三に、ルールが欠けている場合に、推測するのではなく /context や InstructionsLoaded フックを使って確認できるようになります。

1ファイルにつき1トピック。 内容がわかる名前をファイルに付けます。

重要なルールはスコープを設定しない。 これにより毎セッション読み込まれ、コンパクションを生き残ります。

条件付きのものだけスコープを設定する。 そして、実際のパスに対してパターンをテストします。

フロントマターでは paths のみを使用する。 他のフィールドは無視されます。

YAML を検証する。 無効なフロントマターは、スコープ付きルールをどこでも読み込まれるようにしてしまいます。

ユーザールールとプロジェクトルールの一貫性を保つ。 どちらも他方を上書きしません。

/context で確認する。 そして InstructionsLoaded フックを使用してトリガーをデバッグします。

Claude Code のルールは、指示をトピックごとに分割する .claude/rules/ 内の Markdown ファイルです。paths のないルールは起動時に .claude/CLAUDE.md と同じ優先度で読み込まれ、コンパクション後に再注入されます。paths のあるルールは、Claude が一致するファイルを読み取り、書き込み、または編集したときに読み込まれ、コンパクションによって要約され、再びトリガーされるまで消えます。~/.claude/rules/ にあるユーザーレベルのルールはプロジェクトルールの前に読み込まれ、どちらも他方を上書きしません。

長い指示をトピックファイルに分割し、真に条件付きのものだけにスコープを設定し、必須のルールはスコープを設定せず、/context で読み込まれた内容を確認しましょう。