Claude Rules MD とは｜CLAUDE.md で AI を統制する設計
「claude rules md」で検索した人が本当に求めているのは、Claude Code がセッション開始時に自動で読み込む CLAUDE.md というルール定義ファイルの正体と書き方です。本記事では、rules ファイルの位置づけ、書くべき 4 要素、paths と階層スコープによる範囲制御、Cursor .mdc や AGENTS.md との違い、そして cursor2claude などの変換ツールまでを 1 本で押さえます。
「claude rules md」は Claude Code がプロジェクトルートで自動読み込みする CLAUDE.md を指します。これは AI に毎回プロンプトで規約を伝えなくて済むようにする rules ファイル(standing orders) で、セッションを越えて効く永続コンテキストとして機能します。
書くべきは 役割・コード規約・動作ガードレール・プロジェクト固有知識 の 4 要素です。paths フィールドで適用範囲を絞り、@path 構文で別ファイルを取り込めば、500 行を超える肥大化や「効かないルール」の問題を構造的に避けられます。
Cursor の .mdc は YAML フロントマターと glob を持つ唯一の構造化フォーマットですが、CLAUDE.md は 階層走査(managed → project → user → local) で粒度を制御します。複数 AI を併用するチームは cursor2claude や rule-porter で単一ソースから各形式に出力 するのが 2026 年時点の現実解です。
目次 (9)
- 1. claude rules md の正体 — Claude Code が読む rules ファイル
- 2. なぜ rules ファイルが必要か — セッションを越えて効く standing orders
- 3. CLAUDE.md に書くべき 4 要素 — 役割・規約・ガードレール・固有知識
- 4. paths と階層スコープで「効く範囲」を制御する
- 5. @import 構文で巨大化を防ぐ — ルール分割の作法
- 6. 効くルール / 効かないルール — よくある落とし穴 5 つ
- 7. Cursor .mdc / AGENTS.md / Copilot との違い
- 8. 変換ツール cursor2claude と claude-rules — 複数 AI 統一の現実解
- 9. まとめ — 今日から書き始める rules.md 最短ルート
1. claude rules md の正体 — Claude Code が読む rules ファイル
「claude rules md」という検索語で出てくる本命は、Claude Code のプロジェクトルートに置く CLAUDE.md です。Claude Code はセッションを開始する瞬間にこのファイルを自動で読み込み、プロジェクト固有のルールを記憶した状態で作業を始めます。
これは「rules ファイル」と呼ばれる仕組みの一種で、MindStudio の解説(参考：mindstudio.ai)では「セッション間で一貫した指示を保持する永続的なコンテキスト文書」と定義されています。
ツールごとに名前は違います。Claude Code は CLAUDE.md、Cursor は .cursor/rules/ 配下の .mdc ファイル、Windsurf は .windsurfrules、GitHub Copilot は .github/copilot-instructions.md。ファイル名は違っても役割は同じで、AI に「このプロジェクトでの正しい振る舞い」を恒常的に教え込むためのファイルです。
つまり「claude rules md」とは、Claude Code 版の rules ファイルである CLAUDE.md の通称だと理解すれば構いません。
2. なぜ rules ファイルが必要か — セッションを越えて効く standing orders
AI コーディングを使った人なら、誰しも同じ説明を繰り返した経験があるはずです。「TypeScript は type でなく interface を使う」「テストは Vitest」「/src/legacy/ は触らない」。これらをチャットごとに毎回プロンプトに書くのは、人間にとってもコンテキストウィンドウにとっても無駄です。
rules ファイルは、この毎回コストをゼロにします。一度書いて置いておけば、新しいセッションでも AI が最初からプロジェクト基準で動きます。軍隊の用語を借りれば、これは「standing orders(常設命令)」に相当します。個別の指示ではなく、明示的に変更されない限り効き続ける基本方針です。
実例として、Apple Support アプリのリポジトリにも CLAUDE.md が同梱されていたことが 2026 年に確認されています(関連解説は当サイトの Apple も採用した CLAUDE.md を参照)。世界で最も厳しい品質基準を持つ組織が、AI に渡すコンテキストファイルを本番リポジトリに含めている事実は、rules ファイルが「趣味の工夫」ではなく現代の開発インフラだという証明です。
3. CLAUDE.md に書くべき 4 要素 — 役割・規約・ガードレール・固有知識
何を書けば効くのか。MindStudio の整理を踏まえると、効果的な CLAUDE.md は次の 4 ブロックで構成されます。
1. 役割とコンテキスト: プロジェクトの性質と意思決定の枠組みを 2〜4 文で定義します。「これは BtoB SaaS のフロントエンドで、可読性より安定性を優先する」といった大方針です。
2. コード規約: 具体的で実行可能な指示が必須です。「クリーンコードを書け」のような抽象語は無意味で、「関数は 30 行を超えたら抽出する。ただし可読性のために残す合理性がある場合を除く」のように、判断の閾値まで含めて書きます。
3. 動作ガードレール: 自律的に動く AI に対して、必ず確認が必要な操作と禁止事項を明記します。「/scripts/migrations/ 配下は明示指示なしに編集しない」のような禁止ルールは、プロンプトで毎回注意するより遥かに信頼性が高い手段です。
4. プロジェクト固有知識: 既知の癖、環境セットアップ、進行中の移行、外部 API の制約など、開発者の頭の中にある暗黙知を文書化します。これが最も価値の高い情報で、汎用 LLM 知識ではカバーできない領域です。
4. paths と階層スコープで「効く範囲」を制御する
CLAUDE.md は単一の巨大ファイルになりがちですが、Claude Code には適用範囲を絞る仕組みが用意されています。
ひとつは YAML フロントマターの paths フィールドです。Agent Rules Builder の解説(参考：agentrulegen.com)によると、次のように書くとそのルールブロックは指定パスで動くときだけ強く効くようになります。
---
paths:
- "src/api/**/*.ts"
---
# API 開発ルール
- レスポンスは Zod スキーマで必ず検証する
- HTTP ステータスコードは constants.ts の定数を使用する
もうひとつは階層スコープです。Claude Code は managed policy → project → user → local の 4 段階を上位から下位へ走査し、より具体的な配置が広域ルールを上書きします。これにより組織共通方針と個人設定を同居させられます。さらにサブディレクトリにも CLAUDE.md を置けるため、モノレポでパッケージごとに異なる規約を持たせるのも自然です。
5. @import 構文で巨大化を防ぐ — ルール分割の作法
rules ファイルでよくある失敗は、すべてをルートの CLAUDE.md に詰め込み 1,000 行を超えてしまうことです。MindStudio は「500 語を超えると効果が低下する」と明確に警告しています。
Claude Code は @path 構文による別ファイル参照に対応しています。たとえばルート CLAUDE.md には全体方針だけを置き、詳細を分割します。
# プロジェクト基本方針
このリポジトリは BtoB SaaS 管理画面です。
@./rules/coding-style.md
@./rules/testing.md
@./rules/forbidden-paths.md
こうすると、ドメインごとに分割しながらも論理的にはひとつの rules セットとして扱えます。テスト規約だけ更新したいときに API 規約に触らずに済むため、レビュー粒度も小さく保てます。Claude Code の /memory コマンドで現在読み込まれているファイル一覧を確認できるので、想定どおりロードされているかも検証可能です。
6. 効くルール / 効かないルール — よくある落とし穴 5 つ
rules ファイルは万能ではなく、書き方次第で逆効果になります。MindStudio と Agent Rules Builder の指摘を統合すると、避けるべき落とし穴は以下の 5 点です。
- 過度な長さ: 500 語を超えると AI の遵守率が下がります。階層分割と
@importで各ファイルを短く保ちます。 - 矛盾する指示: 「型を厳密に」と「動けば良い」が同居すると AI は混乱します。レビュー時に矛盾検出が必須です。
- 陳腐化: プロジェクト進化で実態が変わってもファイルが古いと、AI は古い規約を強制し続けます。四半期ごとの棚卸しを推奨します。
- 曖昧語の濫用: 「適切に処理する」「クリーンに書く」は判断基準を持たないため AI に伝わりません。閾値・関数行数・命名規則など定量化できる箇所はすべて数値化します。
- 禁止事項の欠落: やってほしいことより、やってほしくないことの方が事故防止に効きます。マイグレーションファイル、本番設定、生成済みコードなど触らせたくない領域は明示的に列挙します。
7. Cursor .mdc / AGENTS.md / Copilot との違い
複数 AI を併用するチームは形式の違いに悩みます。DEV Community の解説(参考：dev.to)が指摘する通り、構造化フォーマットを持つのは Cursor の .mdc だけで、他はすべてフラットな Markdown です。
Cursor の .mdc は YAML フロントマターで globs: "**/*.tsx" のような glob パターンを取り、alwaysApply ブール値や description フィールドでルール種別を分類できます。一方 CLAUDE.md は階層走査と paths フィールドで範囲を制御しますが、構造の表現力は Cursor より低めです。
AGENTS.md は OpenAI 系エージェントが想定するフラット形式、GitHub Copilot の .github/copilot-instructions.md も同様にフラット形式です。つまり Cursor から他へ変換するときは構造情報の一部を必ず捨てることになり、逆方向の変換は人手で構造を補う必要があります。
8. 変換ツール cursor2claude と claude-rules — 複数 AI 統一の現実解
ツール間の差を埋めるため、変換ツールがいくつか登場しています。
cursor2claude(参考：github.com/hcastro/cursor2claude)は .cursor/rules/**/*.{md,mdc} を走査し、alwaysApply: true のルールは常時適用、description 付きはコンテキスト依存、それ以外は手動扱いとして整理し、ひとつの CLAUDE.md に再構成します。sync で一括変換、watch でファイル変更を監視して自動同期、status で同期状態を確認できます。
claude-rules(参考：github.com/lifedever/claude-rules)は逆に「テンプレートから rules を生成する」アプローチを取り、base 層(コア原則)・language 層(TypeScript/Python 等)・framework 層(Vue/React 等)の 3 層構造で、Claude Code・Cursor・Antigravity・GitHub Copilot 用に同時出力します。具体例として「関数は 30 行以下」「ファイルは 300 行以下」のような定量基準が組み込まれているのが特徴です。
rule-porter(参考：forum.cursor.com)も同様で、Cursor の .mdc を CLAUDE.md・AGENTS.md・Copilot Instructions に変換します。「Cursor を単一ソースにして他に配る」モデルは、構造化フォーマットを起点にすればロスが最小化できるため、2026 年時点で最も合理的な運用パターンです。
9. まとめ — 今日から書き始める rules.md 最短ルート
claude rules md は、CLAUDE.md という Claude Code の rules ファイルそのものを指す検索語でした。最短で導入するなら、次の順序が現実的です。
まずプロジェクトルートに CLAUDE.md を作成し、役割・規約・ガードレール・固有知識の 4 ブロックの骨組みを置きます。次に既存プロンプトで毎回繰り返している規約を移植し、500 語を超えそうなら @import で別ファイルに分割します。サブディレクトリ単位の特殊ルールがあれば、そこに専用 CLAUDE.md を置き階層走査に任せます。
複数 AI を併用するなら、Cursor .mdc を単一ソースにして cursor2claude か rule-porter で同期させるのが現実解です。最初から完璧を目指さず、月次で見直しながら定量基準と禁止事項を増やしていくことで、AI が毎回違う答えを返す状態から、毎回プロジェクト基準で動く状態に少しずつ近づきます。これが 2026 年時点の rules ファイル運用の到達点です。
