Claude Code Rulesの完全ガイド【2026年最新】：CLAUDE.mdと.claude/rules/の使い分けを徹底解説

Claude Code Rulesとは？CLAUDE.mdと.claude/rules/の仕組みを完全解説【2026年最新】

室谷

今回はClaude Code Rulesの話をしましょう。これ、.AI（ドットエーアイ）コミュニティでも「どう設定すればいいの？」という質問がすごく多いテーマなんですよね。

テキトー教師

ほんとそうですよね。コミュニティのメンバーさんから「CLAUDE.mdに何を書けばいいのかわからない」とか「.claude/rules/ってCLAUDE.mdと何が違うの？」っていう声をよく聞きます。

室谷

Claude Codeをインストールして最初の壁がここだと思いますよ。コードは書いてくれるけど、プロジェクトのルールをちゃんと覚えさせるにはどうすればいいか、初見だと全然わからないですよね。

テキトー教師

そこをきちんと整理しておくと、Claude Codeの質が劇的に変わるんですよ。一回設定すれば毎回同じことを言わなくて済む。

それだけで使い心地が全然違います。

室谷

MYUUUでも全プロジェクトにCLAUDE.mdを必ず置くようにしていて・・・最初は「まあなくても動くだろう」と思っていたんですが、ある日全員で統一したら開発速度が体感で上がりましたね。

テキトー教師

その経験、まさにそれです。今回は「Claude Code Rules」として機能するCLAUDE.md、CLAUDE.local.md、そして.claude/rules/ディレクトリの使い分けまで、ひとつひとつ整理していきましょう。

Claude Code Rulesの全体像：4つのメモリ機能

Claude Code公式ドキュメント「How Claude remembers your project」の概要ページ（公式サイトより）

室谷

まず大前提として、Claude Codeのメモリ機能は大きく分けると2系統あります。「自分で書くCLAUDE.md」と「Claudeが自動で書くオートメモリ」です。

テキトー教師

この2つは目的が全然違うんですよね。整理すると、こういう構造になります。

種類	誰が書くか	何を書くか	スコープ
CLAUDE.md	自分（またはチーム）	コーディング規約・ワークフロー・アーキテクチャ	プロジェクト・ユーザー・組織
.claude/rules/	自分（またはチーム）	トピック別のルール（パス指定も可）	プロジェクト
CLAUDE.local.md	自分のみ	個人的な設定（gitignore対象）	現在のプロジェクトのみ
オートメモリ	Claude自身	ビルドコマンド・デバッグの知見・好み	作業ツリーごと

室谷

この表、わかりやすいですよね。CLAUDE.mdはチームで共有するもの、CLAUDE.local.mdは自分だけのもの、って切り分けがポイントで・・・

テキトー教師

「.gitignoreに入れるかどうか」で考えるとシンプルです。チームで共有したいルールはCLAUDE.md、自分だけのサンドボックスURLやテスト用データのパスはCLAUDE.local.mdに書く。

これだけ覚えておけば最初は十分ですよ。

室谷

あと、.claude/rules/が追加されたのは比較的最近のことで・・・これが結構強力なんですよ。CLAUDE.mdを肥大化させずに、トピック別でルールを管理できる。

テキトー教師

.claude/rules/は「モジュラールール」とも言われていて、ファイルごとにトピックを分けられるので、大規模プロジェクトやチーム開発で特に威力を発揮しますね。

CLAUDE.mdの置き場所と優先順位：プロジェクト・ユーザー・組織

Claude Code Rulesファイル階層図：組織・ユーザー・プロジェクト・サブディレクトリのスコープ構造

室谷

CLAUDE.mdはどこに置くかで適用範囲が変わります。これ、意外と見落としがちなポイントなんですよね。

テキトー教師

講座でも最初に説明するんですが、CLAUDE.mdは「スコープの階層」があって、より具体的な場所に置いたものほど優先度が高くなります。

室谷

公式ドキュメントを見ると、置き場所は主に4種類あります。

スコープ	ファイルの場所	用途
組織全体	macOS: `/Library/Application Support/ClaudeCode/CLAUDE.md`	ITポリシー・セキュリティ要件など
プロジェクト（チーム共有）	`./CLAUDE.md` または `./.claude/CLAUDE.md`	コーディング規約・アーキテクチャ説明
ユーザー（全プロジェクト共通）	`~/.claude/CLAUDE.md`	個人の好みやツールの設定
ローカル（個人・プロジェクト専用）	`./CLAUDE.local.md`	.gitignore対象の個人設定

テキトー教師

この表を見ると「組織全体」って項目があって驚く方もいますが、企業がClaude Codeを全社展開するときはここを使います。MDMやAnsibleでデプロイして、全社共通のコーディング規約を一元管理できるんです。

室谷

それは確かにエンタープライズ向けですね。個人や小規模チームなら「プロジェクト用CLAUDE.md」と「ユーザー用~/.claude/CLAUDE.md」の2つを使いこなせれば十分だと思います。

テキトー教師

ちなみに、CLAUDE.mdが見つかるしくみは「現在の作業ディレクトリから上に向かって探索」です。foo/bar/で実行すると、foo/bar/CLAUDE.md、foo/CLAUDE.mdと順番に読み込まれる。

どのファイルも全部コンテキストに追記される形で、上書きはされません。

室谷

これを知っておくと、サブディレクトリに専用のCLAUDE.mdを置くことで「このディレクトリに入ったときだけ追加のルールを適用する」ができますよね。

テキトー教師

そうなんですよ。モノレポで「このパッケージだけ特殊なルールがある」みたいなケースで使えます。

Claude Codeはそのサブディレクトリ内のファイルを読むときに、そこのCLAUDE.mdを追加で読み込んでくれますから。

効果的なCLAUDE.mdの書き方：サイズ・構造・具体性

室谷

CLAUDE.mdを「とりあえずプロジェクトの説明を長々と書く」場所だと思っている人が多いんですよ。実はそれが一番やりがちなNGパターンで・・・

テキトー教師

あー、これほんとよく見ます。コミュニティのメンバーさんで「なんかClaude Codeがルールを無視する」って悩んでいる人の大半が、CLAUDE.mdが長すぎるか、具体性が足りないかのどちらかです。

室谷

公式ドキュメントが推奨している目安が「1ファイル200行以内」なんですよね。それ以上長くなるとコンテキストを圧迫するし、遵守率も下がる・・・

テキトー教師

ポイントは3つあります。

サイズ: 1ファイル200行以内を目安にする。大きくなったら.claude/rules/に分割する
構造: markdownのヘッダーと箇条書きで整理する。密な段落より構造化されたリストの方が従いやすい
具体性: 検証できるレベルで具体的に書く

室谷

「具体性」がキモですよね。「コードをきれいに書いてください」はほぼ意味がない。

「インデントは2スペース」「コミット前にnpm testを実行」「APIハンドラはsrc/api/handlers/に置く」くらい具体的に書いて初めて効く。

テキトー教師

そう。「ふわっとした指示」を書いても、Claudeは最善を尽くすんですが解釈にブレが出やすい。

「コードレビューの指摘で毎回同じことを言われる」なら、それをそのままCLAUDE.mdに書くべきです。

室谷

実際にMYUUUで使っているCLAUDE.mdのパターンを紹介すると、構造はシンプルで・・・

## プロジェクト概要 → 2〜3行でプロジェクトの目的だけ
## ビルド・テストコマンド → npm run dev、npm testなど
## コーディング規約 → インデント、命名規則、ファイル構成
## やってはいけないこと → これが意外と重要w

テキトー教師

「やってはいけないこと」セクション、これ盲点ですよね。「このAPIは直接呼ばないでください」「このファイルは変更禁止」みたいなネガティブルールも明示しておくと、Claude Codeが意図しない変更をしにくくなります。

室谷

あとは矛盾が生まれないよう注意することですね。2つのCLAUDE.mdが互いに矛盾する指示を出すと、Claudeはどちらかを恣意的に選んでしまう。

定期的にレビューして古い指示は消す。

テキトー教師

チームが大きくなると特にそうですよね。「誰かが書いた古いルールがまだ残っている」みたいな状況が発生しがちなので、半期に一回くらいのペースで棚卸しすることをおすすめしています。

@importでファイルを参照する

室谷

CLAUDE.mdが大きくなってきたときのもう一つの対処法が、@path/to/file構文での参照です。

テキトー教師

READMEやpackage.jsonを直接参照できるのが便利で・・・毎回同じ情報を書かなくていいんですよね。

# CLAUDE.mdの例
プロジェクト概要は@READMEを参照してください。
利用可能なnpmコマンドは@package.jsonを確認してください。

## 追加指示
- Gitワークフロー: @docs/git-instructions.md

室谷

これ、インポートは最大5階層まで再帰的に展開される仕様で。ただ注意点として、初めて外部インポートを含むプロジェクトを開いたときは承認ダイアログが出ます。

テキトー教師

承認を断ったらインポートが無効のままになるので注意です。チームで使う場合は「初回起動時に承認してください」と周知しておくといいですよ。

.claude/rules/でルールをモジュール化する

Claude Code公式ドキュメントの.claude/rules/セクション解説（公式サイトより）

室谷

では次に.claude/rules/ディレクトリの話をしましょう。CLAUDE.mdと何が違うのかというと・・・

テキトー教師

一言で言うと「CLAUDE.mdを分割して管理するための仕組み」です。ディレクトリ構造はこんな感じになります。

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

室谷

これが便利なのは、トピックごとにファイルを分けられること。CLAUDE.mdがどんどん長くなる問題を根本的に解決できるんですよ。

テキトー教師

大規模なプロジェクトで特に効果的で・・・例えばフロントエンドとバックエンドで別のルールがある場合、rules/frontend/とrules/backend/のようにサブディレクトリで整理できます。

室谷

pathsフィールドを使えば、特定のファイルに対してのみルールを適用することもできますね。これがかなり強力で。

テキトー教師

「TypeScriptのファイルを編集するときだけこのルールを適用する」といった条件付きルールが書けます。frontmatterにこう書きます。

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

# APIルール

- 全エンドポイントには入力バリデーションを必ず含める
- エラーレスポンスは統一フォーマットを使う
- OpenAPIドキュメントコメントを記載する

室谷

パスはglobパターンで指定できて、複数パターンも指定可能です。**/*.tsなら全TypeScriptファイル、src/components/*.tsxならコンポーネントのみ、という使い分けができる。

テキトー教師

ちなみにpathsフィールドがないルールはCLAUDE.mdと同様に毎回読み込まれます。条件付きにしたいものだけpathsを書けばいい。

.claude/rules/とskillsの使い分け

室谷

ここで混同しやすいのが.claude/rules/とskillsの違いですね。

テキトー教師

そうなんですよ。端的に言うと、rulesは「毎回読み込まれる常設のルール」、skillsは「呼び出したときだけ読み込まれるタスク特化の手順書」という違いがあります。

室谷

「コーディング規約」みたいな常に適用したいものはrules、「デプロイ手順」や「PR作成の手順」みたいに特定のタスクで使うものはskillsって切り分けると自然ですね。

テキトー教師

毎セッションrules全体が読み込まれるので、あまり大量に入れるとコンテキストを圧迫します。「これは毎回必要か？」と問いながら振り分けるのが正解です。

シンボリックリンクで複数プロジェクトに共有する

室谷

.claude/rules/はシンボリックリンクに対応しているので、複数プロジェクトで同じルールを共有できるんですよ。

テキトー教師

これは便利ですよね。会社共通のセキュリティルールとか、チームの命名規則とかを一元管理できる。

# 共有ルールディレクトリをリンクする
ln -s ~/shared-claude-rules .claude/rules/shared

# 個別ファイルをリンクする
ln -s ~/company-standards/security.md .claude/rules/security.md

室谷

MYUUUでもこれを使って全プロジェクトに共通のセキュリティチェックルールを配布しています。1箇所更新すれば全プロジェクトに反映される。

cursor rules to claude code：Cursor Rulesとの違いと移行方法

室谷

「Cursor Rulesと比べてどうなの？」という話もしておきたいですね。Cursorから移ってくる人が多いので。

テキトー教師

.cursorrules、cursor rules for claude code・・・この辺のキーワードで調べる人が多いんですが、基本的な考え方はよく似ています。ただ機能の充実度でいうとClaude Codeの方が上だと思いますよ。

室谷

比較すると、こんな感じです。

機能	Cursor Rules	Claude Code Rules
プロジェクトルール	.cursorrules	CLAUDE.md / .claude/CLAUDE.md
モジュール化	.cursor/rules/	.claude/rules/
パス指定	glob対応	glob対応（frontmatter）
チーム共有	gitで管理	gitで管理
組織全体への適用	非対応	対応（managed policy）
オートメモリ	なし	あり（auto memory機能）

テキトー教師

Cursorからの移行はそんなに大変じゃないです。.cursorrulesの内容をCLAUDE.mdにそのままコピーして、ちょっと整理するくらいで動くことが多い。

室谷

ただ、AGENTS.mdを使っているプロジェクトもありますよね。Claude Codeが読むのはCLAUDE.mdだけなので、AGENTS.mdがあるリポジトリで使うときは注意が必要です。

テキトー教師

その場合の解決策は、CLAUDE.mdからAGENTS.mdをインポートする方法です。こう書けば両方のツールが同じルールを参照できます。

# CLAUDE.md
@AGENTS.md

## Claude Code固有の設定
- src/billing/配下の変更はプランモードを使う

室谷

これはスマートな解決策ですよね。2つのファイルを別々にメンテナンスしなくていい。

Claude Code User Rules：ユーザーレベルのグローバル設定

室谷

プロジェクトレベルのCLAUDE.mdの話が多かったので、次はユーザーレベルの設定を整理しましょう。

テキトー教師

~/.claude/CLAUDE.mdですね。これは全プロジェクトに適用されるので、個人の好みや習慣を書く場所として使います。

室谷

何を書くかというと・・・「自分はTypeScriptを好む」「コメントは日本語で書く」「テストは必ずvitest」みたいなプロジェクト横断的な個人設定です。

テキトー教師

あとは~/.claude/rules/にユーザーレベルのルールファイルを置くこともできます。プロジェクトルールより先に読み込まれますが、プロジェクトルールの方が優先度が高い仕様です。

室谷

優先順位はスコープが狭いほど高くなります。プロジェクトが最優先ということですね。

プロジェクト > ユーザー > 組織全体（ただし組織全体は除外不可）。

テキトー教師

「除外不可」というのがポイントで。claudeMdExcludesという設定でCLAUDE.mdを除外することができるんですが、マネージドポリシー（組織全体）のCLAUDE.mdだけは除外できません。

室谷

企業のセキュリティポリシーを個々の開発者がオフにできない仕組みですね。エンタープライズ向けにしっかり設計されている。

Claude Code Auto Memory：Claudeが自動的に学習する仕組み

室谷

オートメモリの話もしましょう。これ、Claude Code v2.1.59以降で使える機能で・・・すごく地味に便利なんですよ。

テキトー教師

「Claudeが自分で学習ノートを書く」という機能ですよね。自分では何も書かなくてもClaude Codeがセッションの知見を溜めていってくれる。

室谷

保存される場所は~/.claude/projects/<プロジェクト名>/memory/で、MEMORY.mdというファイルが中心になります。

テキトー教師

保存されるのはビルドコマンド、デバッグのパターン、コードの好み、ワークフローの習慣・・・「何度も聞かれたこと」をClaudeが「次は自分で覚えておこう」と判断して書き留める感じです。

室谷

重要なのは、オートメモリはセッションごとに自動で全部書くわけじゃなくて、Claudeが「次のセッションで使えそうだ」と判断したものだけを選んで保存するという点ですね。

テキトー教師

MEMORY.mdの最初200行（または25KB）がセッション開始時に読み込まれます。それ以上は読み込まれない。

だから長くなりすぎないようにClaude自身がMEMORY.mdを簡潔に保ちながら、詳細は別ファイルに分けていくんですよ。

室谷

/memoryコマンドで現在どんな内容が保存されているかを確認・編集できます。平文のmarkdownなので人間が読んで修正してOK。

テキトー教師

オートメモリはデフォルトでオンですが、オフにしたい場合は設定ファイルで"autoMemoryEnabled": falseを追加するか、環境変数CLAUDE_CODE_DISABLE_AUTO_MEMORY=1で無効化できます。

室谷

個人的には、オートメモリとCLAUDE.mdは役割が違うので両方使うのがベストだと思います。CLAUDE.mdは「チームで共有したいルール」、オートメモリは「自分の個人的な習慣や好みをClaudeが学習した結果」として分けて考えると整理しやすい。

テキトー教師

「自分では書かなかったけど、Claudeが勝手に覚えてくれた」ということが積み重なっていくので、使えば使うほどClaude Codeが自分に最適化されていく感覚があります。

Claude Code Rules GitHub：公開されているベストプラクティス集

室谷

GitHubやRedditでのルールのサンプルを参照しながら、実際に公開されているベストプラクティスを活用するのも有効ですよね。

テキトー教師

そうですね。ベストプラクティスとして押さえておきたいポイントを挙げると・・・

室谷

まず、海外のコミュニティで評価が高い構成パターンがあって。「CLAUDE.mdは短く、詳細は.claude/rules/に分散させる」というアプローチです。

テキトー教師

つまり、CLAUDE.mdには「地図」だけ書いて、詳細な手順はrules/の各ファイルに委ねる。CLAUDE.md自体には「APIルールはrules/api.md参照」みたいなインデックスだけ置く感じです。

室谷

あの有名な海外の記事でも「CLAUDE.md = Repo Memory（短く保つ）」「WHY（目的）・WHAT（構造）・HOW（ルールとコマンド）だけ書く」というアプローチが提唱されていました。

テキトー教師

この考え方、すごく実践的ですよね。「プロジェクトを初めて見るインターンに何を伝えるか」を基準にCLAUDE.mdを書くというアドバイスで・・・過剰に詳しく書くよりも、最低限の文脈を正確に伝える方が効果的です。

室谷

効果的なルールのテンプレートとして、よく見かけるパターンはこんな感じです。

コードスタイルルールの例:
- インデント2スペース
- セミコロンあり
- シングルクォート使用
- ファイル末尾に改行
テストルールの例:
- テストはvitest
- npm testでフルテスト実行
- モックはvi.mock()を使う

テキトー教師

「当たり前のことばかりじゃないか」と思うかもしれないんですが、これを書かないとClaude Codeがプロジェクトの文脈なしに動くわけで・・・明示することに意味があります。

室谷

「ルールが反映されない」という悩みがよく出るんですが、ほぼ全部「ルールが曖昧すぎる」か「ルールが矛盾している」のどちらかで解決できます。

/initコマンドでCLAUDE.mdを自動生成する

室谷

さて、「CLAUDE.mdって一から書くの大変じゃない？」という人に教えたいのが/initコマンドです。

テキトー教師

これ、地味にすごく便利で・・・実行するとClaude Codeがコードベースを分析して、CLAUDE.mdのドラフトを自動生成してくれます。

室谷

生成される内容はビルドコマンド、テスト手順、発見したプロジェクトの規約など。ゼロから書くよりずっとラクです。

テキトー教師

ただ、/initで生成したものはあくまでスタート地点です。「Claudeが発見できなかった情報」を追記していくことで完成度が上がります。

室谷

あと、CLAUDE_CODE_NEW_INIT=1という環境変数を設定すると、インタラクティブなマルチフェーズのフローになります。CLAUDE.md以外にskillsやhooksも一緒に設定できる。

テキトー教師

新規プロジェクトの立ち上げ時はこっちがおすすめですね。設計段階からClaude Codeのための環境を整えられるので。

室谷

既存のCLAUDE.mdがある状態で/initを実行すると、上書きではなく「改善提案」が出ます。「こういうセクションを追加するといいですよ」という感じで。

CLAUDE.mdがきかない・無視される場合のトラブルシューティング

室谷

「CLAUDE.mdを書いたけど全然効いてない」というケースについてお話しましょう。

テキトー教師

claude code rules mdやclaude code ルールで検索する人の多くが当たっているトラブルですよね。

室谷

まず確認すべきは/memoryコマンドを実行して、そのCLAUDE.mdが読み込まれているかどうかです。リストに出てこないなら、そもそも見えていないということです。

テキトー教師

よくある原因は4つあります。

ファイルの場所が間違っている → CLAUDE.mdがどこにあるか確認。./CLAUDE.mdか./.claude/CLAUDE.mdか
内容が曖昧すぎる → 「きれいなコードを書いてください」はダメ。具体的なルールに書き直す
複数のCLAUDE.mdが矛盾している → 同じトピックについて異なる指示が2箇所にある
ファイルが長すぎる → 200行を超えている場合は.claude/rules/に分割する

室谷

「/compactした後にルールが消えた気がする」という声もあるんですが、CLAUDE.mdはcompact後も完全に保持されます。compactが終わったらCLAUDE.mdを最初から再読み込みしてくれるので。

テキトー教師

もし「compactしたらルールが消えた」なら、それはCLAUDE.mdではなく会話の中で「次回から〇〇してください」と口頭で伝えたルールです。それはcompactで消えます。

ちゃんとCLAUDE.mdに書いておくことが大事。

室谷

/memoryで「Auto memoryのトグル」も確認できます。無効になっていたら、Claudeが学習した内容が次のセッションに引き継がれません。

claude code permission rules：危険なコマンドを制御する

室谷

もう一つ重要な概念が「パーミッションルール」です。これはCLAUDE.mdではなく、設定ファイル側で制御します。

テキトー教師

.claude/settings.jsonのpermissions.denyでシェルコマンドやファイルアクセスを制限できます。

室谷

例えば「削除系コマンドは自動実行しない」「本番環境のDBには接続しない」みたいな安全装置をここで設定できる。これはCLAUDE.mdの行動指針とは別物で、技術的な強制力があります。

テキトー教師

講座では「CLAUDE.mdはお願いベース、settings.jsonは強制」という表現で説明しています。CLAUDE.mdに「このファイルは変更しないでください」と書いてもClaude Codeに絶対の保証はない。

でもsettings.jsonのpermissionsなら確実にブロックできます。

室谷

両方使い分けるのが正解ですね。日常的な行動指針はCLAUDE.mdで、絶対に守らせたいセキュリティルールはsettings.jsonで。

Claude Code Rules Paths：パス別のルール管理を極める

室谷

.claude/rules/のpaths設定について、もう少し掘り下げておきましょう。

テキトー教師

globパターンの組み合わせが自由にできるので、プロジェクトの構造に合わせた細かい制御ができます。

室谷

よく使うパターンをまとめるとこんな感じです。

パターン	マッチするファイル
`*/.ts`	全ディレクトリのTypeScriptファイル
`src/*/`	src/配下の全ファイル
`*.md`	プロジェクトルートのMarkdownファイル
`src/components/*.tsx`	componentsディレクトリのReactコンポーネント
`*/.{ts,tsx}`	TypeScriptとTSXの両方

テキトー教師

複数パターンを指定したいときは、frontmatterで配列で書けます。src/**/*.{ts,tsx}とlib/**/*.tsとtests/**/*.test.tsを同時に指定するみたいな感じです。

室谷

path-specific rulesの使い方で個人的に気に入っているのが「テストファイル専用ルール」です。テストの書き方はプロダクションコードと全然違う考え方が必要なので、分けて管理する価値があります。

テキトー教師

tests/**/*.test.tsというパターンで「テストファイルを触るときだけ」追加指示を読み込む設定にしておくと、Claude Codeがテストを書くときのスタイルが格段に安定します。

室谷

.claude/rules/ディレクトリを使った構成を探している方は、シンプルに「.claude/rules/にトピック別markdownファイルを置く」だけなので難しくないです。

CLAUDE.mdのコミュニティ活用事例

室谷

実際のプロジェクトでどう活用されているかの事例を少し紹介しましょう。

テキトー教師

コミュニティのメンバーさんの事例だと、一番多いのが「Webアプリ開発での活用」ですね。Next.js + TypeScript構成で、CLAUDE.mdとrules/を組み合わせているパターンが多いです。

室谷

MYUUUで実際に運用しているのは・・・

CLAUDE.md → プロジェクト概要とビルドコマンドのみ（50行以内）
.claude/rules/code-style.md → TypeScript・Tailwindの規約
.claude/rules/api.md → APIルーティングとエラーハンドリングの規約
.claude/rules/testing.md → vitestの使い方と命名規則
CLAUDE.local.md → 自分のローカルDB URL（gitignore対象）

テキトー教師

このくらいの粒度に分けると、rulesとskillsの連携もうまくいくんですよ。rules/には常設のルール、skillsには「デプロイ手順」「PR作成のテンプレート」みたいなタスク特化の手順書を分けると、Claude Codeがとても使いやすくなります。

室谷

モジュラールールという考え方が定着してきましたよね。以前は全部CLAUDE.mdに書く人が多かったんですが、今は「トピック分割が当たり前」になりつつある。

テキトー教師

rulesとskillsの組み合わせは他のツールにない強みだと思います。「常設のルール」と「呼び出し型の手順書」を明確に分けられるのはClaude Code独自の設計ですから。

室谷

ここが本質なんですよね。Claude Code Rulesは単なる「設定ファイル」じゃなくて、AIエージェントに自分たちの文脈を伝え続けるための「知識管理システム」として設計されている。

まとめ：Claude Code Rulesを最大限活かすために

室谷

今回のまとめです。Claude Code Rulesは大きく「CLAUDE.md系」と「オートメモリ系」の2系統があって、役割が全然違います。

テキトー教師

ポイントを整理するとこうなります。

CLAUDE.md → チームで共有するルール。200行以内・具体的に書く
.claude/rules/ → CLAUDE.mdをトピック別に分割するための仕組み。paths指定でファイル別の条件付きルールも可能
CLAUDE.local.md → 自分だけの個人設定。.gitignore対象
~/.claude/CLAUDE.md → 全プロジェクト共通の個人設定
オートメモリ → Claudeが自動で学習・記録。/memoryで確認・編集できる

室谷

「CLAUDE.mdを書いてもきかない」という場合は、①ファイルが正しい場所にあるか、②内容が具体的か、③矛盾していないか、の3点を確認してみてください。

テキトー教師

あとは「定期的な棚卸し」も忘れずに。プロジェクトが進化するにつれてルールも変わります。

古いルールを放置すると矛盾の原因になるので、3ヶ月に一度くらい見直す習慣をつけるといいですよ。

室谷

Claude Code Rulesを使いこなせると、Claude Codeが本当に「プロジェクトを理解したチームメンバー」として働いてくれる感覚になります。最初の設定コストをかける価値は十分にありますよ。

よくある質問（FAQ）

Q. CLAUDE.mdとCLAUDE.local.mdの違いは？

室谷

CLAUDE.mdはgitで管理してチームと共有するファイル。CLAUDE.local.mdは.gitignoreに入れる個人専用ファイルです。

両方とも同じディレクトリにある場合、CLAUDE.local.mdはCLAUDE.mdの後に読み込まれます。

Q. CLAUDE.mdはどこに置けばいい？

テキトー教師

./CLAUDE.md（プロジェクトルート）か./.claude/CLAUDE.mdのどちらでも動きます。チーム全員がわかりやすいならプロジェクトルートに置くのがシンプルです。

.claude/rules/を多用するなら.claude/ディレクトリ内に統一した方が見通しがよくなります。

Q. CLAUDE.mdを書いてもClaude Codeが無視する場合は？

室谷

まず/memoryコマンドでファイルがリストに出ているか確認します。出ていなければファイルの場所を見直す。

出ていても効かないなら、指示の具体性を上げる・ファイルを短くする・矛盾する指示を削除する、の順で試してください。

Q. グローバルなルール設定はどこに書く？

テキトー教師

~/.claude/CLAUDE.mdがユーザー全体のグローバル設定です。ここに書いた内容は全プロジェクトに適用されます。

企業全体への適用はmanaged policyのCLAUDE.mdを使います。

Q. .claude/rules/の中を編集するにはどうする？

室谷

通常のテキストエディタで直接編集できます。/memoryコマンドでCLAUDE.mdを開く感覚で、rules/配下のファイルも同様に編集できます。

Q. プロジェクトのサブディレクトリだけにルールを適用できる？

テキトー教師

できます。.claude/rules/のpathsフィールドでディレクトリパターンを指定するか、そのサブディレクトリ内にCLAUDE.mdを置くことで実現できます。

後者の方がシンプルです。

出典

Claude Code 公式ドキュメント: Store instructions and memories