本ページはプロモーションが含まれています

AI

CLAUDE.mdとrulesの違い｜書き方ガイド

トム

・都内自社開発企業勤務／Javaバックエンドエンジニア
／Java歴10年以上 ・首都圏在住30代
・資格：基本情報技術者／応用情報技術者／Java Silver／Python3エンジニア認定基礎 詳細なプロフィール

Claude Codeを使いはじめて1ヶ月くらい経った頃、「同じ指示を毎回打つの、地味にしんどくない？」と気づきました。

コミットメッセージは日本語で、シークレットはコミット禁止、Pythonはuv使って…。毎セッション説明していた頃が懐かしいです。

そこで出てくるのが rules という仕組みです。

CLAUDE.mdと似ているようで役割が違い、SkillsやSubagentsとも線引きが曖昧で、最初は正直「結局どれに何を書けばいいの？」と混乱しました。

結論はこうです。CLAUDE.mdは「常に読まれる就業規則」、rulesは「必要なときだけ呼ばれる部署のマニュアル」。

書き方は5原則で足ります——断言形で書く、200行以内に収める、pathsで自動ロードを絞る、放っておくと間違えることだけ書く、月1で棚卸しする。

半年運用してたどり着いたこの5原則に加えて、Python/Git/セキュリティ向けにそのまま使えるテンプレート3種と、rulesが効かないときのチェックリストも実例つきで置いておきます。

読み終わる頃には、自分のプロジェクトに最初の1ファイルを置けるはずです。

この記事でわかること

  • rulesの基本と、CLAUDE.md・Skills・Subagentsとの違い
  • rulesの書き方5原則（断言形・200行以内・paths指定・失敗ドリブン・棚卸し）
  • Python/Git/セキュリティ向けにそのまま使えるテンプレート3種
  • rulesが効かないときのチェックリストと原因の切り分け方

Claude Code rulesとは？まず1分でわかる結論

Claude Code rulesとは、Claudeに守らせたいプロジェクト固有の約束事を書いたMarkdownファイル群のことです。

.claude/rules/ ディレクトリに置くのが標準で、CLAUDE.mdを補完する形で動きます。

ざっくり言うと、CLAUDE.mdが「会社全体の就業規則」、rulesが「部署ごとの業務マニュアル」みたいな関係です。

前者は常に読まれて、後者は関係する作業のときだけ呼ばれる、という違いがあります。

rulesに書くのは「約束事」

rulesに書く内容は、コーディング規約・命名規則・禁止事項・運用フローなど、Claudeが放っておくと忘れたり間違えたりすることが中心です。

たとえば「秘密情報をコミットしない」「テストは必ず実DBで実行する」など、ミスると痛い系の指示が向いています。

逆に「丁寧に書いてください」みたいな抽象的なお願いは、書いても効きません。

Claudeは曖昧な指示を高確率でスルーするので、断言形＆具体例で書くのが鉄則です。

CLAUDE.md・Skills・Subagentsとの位置づけ

Claude Codeには「設定っぽいファイル」が複数あって、最初はマジで混乱します。

私も最初はCLAUDE.mdとrulesの区別がついていませんでした。役割を一段上から見るとこんな感じです。

  • CLAUDE.md：全セッションで常にロードされるグラウンドルール
  • rules：特定のパスや領域で必要なときだけロードされる業務マニュアル
  • Skills：「ある作業をやってほしい」とClaudeが判断したときに呼ばれる専門家の手順書
  • Subagents：別コンテキストで動く小さなClaude（並列タスクや調査用）
あわせて読む
あわせて読む

AGENTS.mdとの違い

もう一つ紛らわしいのが AGENTS.md です。

これはClaude Code専用の仕組みではなく複数のAIコーディングツールが共通で読みにいく業界標準フォーマットですが、Claude Codeは自動では読み込みません。

使うにはCLAUDE.mdの先頭に @AGENTS.md と書いて明示的にインポートするか、ln -s AGENTS.md CLAUDE.md でシンボリックリンクする必要があります。

両方を運用するなら、内容を重複させないのがコツです。

Claude固有の指示はCLAUDE.md・rules側に寄せ、AGENTS.mdにはツール共通で通じる最低限の方針だけを残すと管理が楽になります。

rulesとCLAUDE.md・Skillsの違いを表で整理

rules・CLAUDE.md・Skillsの違いを一番シンプルに言うと、「いつコンテキストに載るか」が違います。

常時か、ファイル操作時か、必要だと判断されたときか、の3パターンです。

読み込まれるタイミングと適用範囲の違い

3つを表にするとこうなります。コンテキスト消費の観点で見ると、選び方の方針が一気にクリアになります。

項目CLAUDE.mdrulesSkills
読み込み毎セッション常時該当パス操作時関連タスク発生時
コンテキスト消費常に消費条件付きで消費呼ばれた時だけ
適用範囲プロジェクト全体特定ディレクトリ・ファイル特定タスク
サイズ目安200行以内1ファイル200行以内制限ゆるめ
向いている内容全体方針・基本ルール領域固有の規約手順書・専門知識

どう使い分けるかの判断フロー

私が普段やっている判断フローはこんな感じです。「常に意識してほしいか？」を最初に問うのがポイントです。

  • 全タスクに効かせたい基本方針 → CLAUDE.md
  • 特定ディレクトリやファイル種別の規約 → .claude/rules/
  • 特定の手順をきっちり踏ませたい作業 → Skills
  • 独立して走らせたい調査・実装 → Subagents

rulesファイルの3つの種類と置き場所

rulesは適用スコープに応じて、プロジェクト・グローバル・ローカルの3種類に分けられます。

それぞれ置き場所と使いどころが違うので、まず全体像を押さえておくとラクです。

プロジェクトルール（.claude/rules/）

プロジェクトルールは .claude/rules/ 配下に置くMarkdownファイルです。

Gitで管理してチーム全員に共有するのが基本で、ファイル単位でトピックを分けるのが王道です。

私のリポジトリだと、こんな感じで分けています。トピックを分けておくと、後から自分が見直すときも見つけやすいです。

.claude/rules/
├── secrets-safety.md       # 秘密情報の取り扱い（常時ロード）
├── browser-automation.md   # Playwright系の規約
├── wp-manager.md           # WordPress管理スクリプトの規約
└── settings.md             # 設定ファイル運用ルール

グローバルルール（~/.claude/CLAUDE.md）

グローバルルールは ~/.claude/CLAUDE.md に書く、全プロジェクト共通の方針です。

「コメントは日本語」「TDDで進める」みたいな、自分の働き方そのものに関わるルールを置く場所です。

注意点として、グローバル側に書きすぎるとどのプロジェクトでも重く効きすぎて、固有のルールが霞んでしまいます。

私は10〜30行くらいの最小限に絞っています。

ローカルルール（.claude/settings.local.json 周辺）

ローカルルールは自分のマシンだけに効かせたい設定で、.claude/settings.local.json や個人用のメモが該当します。

Gitignoreしておくのが基本で、チームに共有したくない個人の好みやAPIキー周りの扱いを書きます。

Auto memory（自動メモリ）との使い分け

rulesとよく混同されるのが、Auto memoryと呼ばれる自動記憶の仕組みです。

rulesは人間が明示的に書く固定ルールなのに対し、Auto memoryはClaudeが会話の中から学んだ内容を自動で書き足していく記憶です。

使い分けの目安はシンプルです。

「必ず守らせたい約束事」はrulesに、「毎回思い出してほしい文脈（過去の経緯や好み）」はAuto memoryに任せる、と考えておけば迷いません。

あわせて読む

rulesの基本的な書き方｜5つの原則

rulesの書き方には、効くものと効かないものがハッキリ分かれます。私が半年運用して「これは外せない」と思った5つの原則を紹介します。

原則1：断言形で書く（「なるべく」は禁句）

断言形で書くのが最重要です。「なるべく」「できれば」「望ましい」みたいな曖昧表現は、Claudeにとって「やらなくてもいい」と同義になります。

「絶対にしない」「必ず使う」のように、白黒つけて書きましょう。日本語の婉曲表現は、AI相手だと不利に働く場面が多いです。

原則2：1ファイル200行以内に収める

1ファイルあたり200行以内が目安です。200行を超えると、コンテキスト消費が膨らむうえに、Claudeが指示を守る確率も体感で下がります。

長くなりそうなら、トピックごとに別ファイルへ分割するのが正解です。

「これ1行消したらClaudeが間違えるか？」を自問して、不要な行は容赦なく削るのがおすすめです。

実際に2026年8月、CLAUDE.mdに全部詰め込んで運用していたら、指示への反応がどこか鈍っていることに気づきました。

rulesファイルをトピック別に分割し、pathsで必要なときだけ読み込む形に変えたところ、指示の遵守精度が明らかに改善しました。

1ファイルに詰め込みすぎている自覚があるなら、それは分割のサインです。

原則3：pathsで自動ロード制御

paths frontmatterを使うと、該当パスを操作するときだけrulesを読ませることができます。

常時ロードを避けてコンテキストを節約できる、地味だけど一番効く機能です。

なお、paths: のYAMLリスト形式は環境によって読み込まれないことがあります（GitHub Issue #17204で報告済み・クローズ済み）。

効かない場合は globs: "**/*.ts" のように1行のカンマ区切り文字列で書く方法を試してください。

---
description: Playwright自動化スクリプトのコーディング規約
paths:
  - python/browser_automation/**/*.py
---

# ブラウザ自動化スクリプト ルール

- setup_context() を使ってコンテキストを生成すること
- time.sleep() ではなく human_delay() を使うこと

原則4：「放っておくと間違える」ことだけ書く

書く内容は「放っておくとClaudeが間違えること」に絞るのがコツです。「変数名はわかりやすく」みたいな当たり前のことは書く必要はありません。

Claudeは元からそれくらいできます。

私の場合、過去のセッションでClaudeにやらかされたことをメモしておいて、再発したらrulesに昇格させる運用にしています。

失敗ドリブンで育てるのが現実的です。

原則5：定期的に棚卸しして肥大化を防ぐ

rulesは放置すると確実に肥大化します。月1くらいで棚卸しして、もう要らない指示・重複している指示・抽象的すぎる指示を削るのを習慣にしましょう。

「足す」より「削る」のほうが効果が出やすいです。

AI設定あるあるとして、増やせば賢くなる気がしますが、実際は逆で、ノイズが増えると指示の遵守率が落ちます。

すぐ使えるrulesテンプレート3パターン

ここからは、私が実際に使っているテンプレートを3つ紹介します。コピーして自分のプロジェクトに合わせて削っていくのが、一番速い導入方法です。

Pythonプロジェクト向けテンプレート

Pythonプロジェクトでは、依存管理ツールと共通モジュールの強制が一番効きます。

Claudeは何も言わないと pip install や requirements.txt に流れがちなので、明示しておくと事故が減ります。

---
description: Pythonスクリプトのコーディング規約
paths:
  - "**/*.py"
---

# Python ルール

- 依存管理は uv を使う。requirements.txt は使わない
- 新規スクリプトは common/ の共通モジュールを使う
- 関数には docstring を日本語で書く
- 命名は PEP8 準拠（クラスはPascalCase、関数はsnake_case）

シークレット・安全運用ルール

シークレット系は事故ったときのダメージが大きいので、rulesに必ず1ファイル置いておくべきです。

常時ロード設定にして、Claudeが「うっかり」やらかすのを防ぎます。

---
description: 秘密情報・設定ファイル安全ルール
---

# 秘密情報の取り扱い

- .env / config.json / credentials.json は絶対にコミットしない
- 新規設定ファイルを作ったら .example も作る
- ログに秘密情報を出力しない
- ハードコードせず、環境変数か config_manager から読み込む

Git運用・コミットメッセージのルール

Git周りはチームの色が出やすい部分です。

コミットメッセージの言語・プレフィックス・PRの作り方など、好みを明文化しておくと毎回説明する手間が省けます。

---
description: Git操作とコミットメッセージのルール
---

# Git ルール

- コミットメッセージは日本語で書く
- プレフィックスは feat / fix / chore / doc / refactor を使う
- コミット前に pre-commit run --all-files を実行する
- --no-verify は使わない
- main ブランチへの force push は禁止

rulesが効かない原因と対処法｜よくある3パターン

「rules書いたのにClaudeが守ってくれない…」というケースは、だいたい3パターンに集約されます。

順にチェックしていけば、ほぼ原因が特定できます。

paths指定とファイル配置のミスマッチ

一番多いのは、paths のglobパターンが実ファイル配置とズレているパターンです。

src/**/*.ts と書いたつもりが、実際は app/src/ 配下だった、みたいなやつです。

paths指定なしのrulesは常時ロードになるので、まずはpathsを外して効くか試してから、効いたらpathsで絞り込むのが安全な手順です。

指示が抽象的すぎて無視されるパターン

「丁寧にコードを書く」「保守性を意識する」みたいな抽象指示は、書いてあっても無視されます。

Claudeにとって判定できない指示は、ノイズとして処理されるからです。

具体的な動詞と対象を入れて、「〇〇のときは〇〇する」の形にリライトすると効きます。

たとえば「関数が30行を超えたら分割する」のように、判定可能な形にするのがコツです。

CLAUDE.mdとの重複・矛盾を解消する

CLAUDE.mdとrulesで指示が矛盾していると、Claudeはより新しく出てきた指示や、より具体的な方を優先する傾向があります。

意図せず古いルールが効きっぱなしになることもあります。

定期的に grep で同じキーワードを横断検索して、重複や矛盾を見つけたら片方に寄せるのが運用上のコツです。

よくある質問（FAQ）

rulesとCLAUDE.mdの優先順位は？

全体に常に効かせたい方針はCLAUDE.md、特定領域だけに効かせたい規約はrulesです。迷ったらrulesから始めて、複数ファイルで重複してきたらCLAUDE.mdに昇格させるのが運用しやすいです。

.mdcファイル（Cursor形式）は使える？

Claude Codeは標準で .md を読みます。Cursorの .mdc 形式をそのまま使う必要はなく、frontmatter付きの .md に書き換えるのが素直です。Cursor互換の運用が必要なら、両方置いて差分を最小化する手もあります。

rulesは何個まで作っていい？

個数制限はありません。ただし常時ロードされるrulesが増えるほどコンテキストを消費するため、体感では常時ロードを2〜3個までに抑え、残りは paths（または globs）指定で必要時だけロードする運用が無難です。

rulesはどこに書けばいい？

プロジェクト固有のルールなら .claude/rules/ 配下、全プロジェクト共通の方針なら ~/.claude/CLAUDE.md、自分のマシンだけの設定なら .claude/settings.local.json 周辺に書きます。迷ったら、まずチームで共有したい内容かどうかで判断すると早いです。

rulesが効かないときはどうすればいい？

まず paths（または globs）のパターンが実ファイル配置とズレていないか確認します。次に指示が「丁寧に書く」のような抽象表現になっていないかを見直し、最後にCLAUDE.mdとの重複・矛盾がないかを grep で横断検索します。この3パターンでほぼ原因が特定できます。

AGENTS.mdとCLAUDE.mdはどちらを使うべき？

Claude Codeだけで使うならCLAUDE.mdで十分です。Codex・Cursor・Gemini CLIなど複数のAIツールを併用するなら、共通ルールをAGENTS.mdにまとめ、CLAUDE.mdの先頭に @AGENTS.md と書いてインポートする方法が管理しやすいです。

Auto memoryとrulesの違いは？

rulesは人間が明示的に書く固定ルール、Auto memoryはClaudeが会話から自動で学んで書き足す記憶です。「必ず守らせたい約束事」はrulesに、「毎回思い出してほしい文脈」はAuto memoryに任せるのが使い分けの目安です。

あわせて読む

まとめ｜rulesは「Claudeとの契約書」として育てる

この記事のポイント

  • rulesは .claude/rules/ 配下に置く、領域別のClaude向けマニュアル
  • CLAUDE.mdは常時ロード、rulesは paths で条件付きロードが基本
  • 断言形で書く・200行以内・失敗ドリブンで育てる、の3点が効く
  • 効かないときは paths のglob・抽象表現・CLAUDE.mdとの重複を疑う

rulesは一度書いて終わりではなく、Claudeとの付き合いの中で少しずつ育てていく「契約書」みたいなものです。

最初から完璧を目指さず、まずは secrets-safety.md のような事故防止系から1ファイル置いてみるのがおすすめです。

私自身も半年運用してきて、たまに棚卸しして削るたびに「あ、最初から要らなかったな」というルールが出てきます。

それくらいでちょうどよくて、AIの設定は引き算の美学だと最近思っています。明日からあなたのプロジェクトでも、最小の1ファイルから始めてみてください。

※本記事の内容は2026年8月時点のClaude Code仕様に基づきます。rules・CLAUDE.md周りは仕様変更が比較的頻繁なため、最新の挙動は公式ドキュメントも合わせてご確認ください。

  • この記事を書いた人
  • 最新記事

トム

・都内自社開発企業勤務／Javaバックエンドエンジニア
／Java歴10年以上 ・首都圏在住30代
・資格：基本情報技術者／応用情報技術者／Java Silver／Python3エンジニア認定基礎 詳細なプロフィール

-AI