Claude Codeのrules(ルール)とは？機能や使い方・設定方法をわかりやすく解説
Claude Codeにルールを設定できるって聞いたけど、どうやるんだろう？
rulesを使いこなせば、もっと効率よく開発できるのかな…
Claude Codeを使い始め「rules」という言葉を耳にする機会が増え、どんなものか気になっている人は多いですよね。
ただ、具体的な設定方法や書き方がわからず、手が止まってしまう人も少なくありません。
Claude Codeのrulesは、AIへの指示を事前に定義しておく仕組みです。うまく活用すれば、毎回同じ説明をする手間がなくなり、開発スピードが大きく変わります。
そこでこの記事では実際の設定例も交え、Claude Code rulesの特徴を解説します。使い方や効果的な書き方も紹介するので、ぜひ参考にしてください。
Claude Codeの特徴をおさらいしておきたい人は、次の記事を参考にしてください。
- rulesはClaude Codeへの指示を事前定義する仕組み
- プロジェクト・グローバル・ローカルの3種類がある
- 簡潔で具体的な指示文がrulesの効果を最大化する
Claude Code rules(ルール)とは？
Claude Code rulesとは、Claude Codeが作業する際に従うべき指示やルールを事前に定義しておく仕組みです。
通常、Claude Codeに何か作業を依頼するたびに、プロジェクトの背景やコーディング規約を毎回説明する必要があります。rulesを設定しておけば、Claude Codeは自動的にそのルールを読み込んで作業を開始するため、繰り返しの説明が不要になります。
具体的には、次のような内容をrulesに記載できます。
- 使用するプログラミング言語やフレームワーク
- コーディングスタイルの規約（インデント幅、命名規則など）
- 禁止するライブラリや処理の書き方
- プロジェクトのディレクトリ構成
- テストやドキュメントに関するルール
rulesは「CLAUDE.md」というファイルや「.claude/rules/」ディレクトリに記述します。プロジェクトごとに個別設定することも、すべてのプロジェクトに共通する設定を一括で定義することも可能です。
個人開発からチーム開発まで幅広く活用でき、Claude Codeをより自分の開発スタイルに合わせて動かせるようになります。
Claude Code rulesのメリット・デメリット
ここからは、Claude Code rulesを使うことで得られる利点と、設定しなかった場合に起きる問題を整理します。
- rulesを使うことでの具体的な利点
- rulesがないとどのような問題が起きるのか
それぞれ確認していきましょう。
使うことでの利点
rulesの最大の利点は、Claude Codeへの繰り返し説明をゼロにできる点です。
プロジェクト固有のルールをrulesに一度書いておけば、以降の会話で毎回説明する必要がなくなります。たとえば「TypeScriptを使っていて、テストはVitestで書く」というルールをあらかじめ定義しておけば、Claude Codeは最初からその前提で提案や実装を行います。
具体的なメリットをまとめると、次のとおりです。
- プロンプトの入力量が減り、作業スピードが上がる
- チーム内でAIへの指示を統一でき、成果物の品質にばらつきが出にくい
- 禁止事項を明記することで、好ましくないコードが生成されにくくなる
- 新しいメンバーがプロジェクトに加わった際も、rulesを読むだけで規約を把握できる
繰り返しの説明にかかるコストをなくせるのが、rulesの大きな強みといえます。
ないとどうなるのか
rulesを設定しないままClaude Codeを使い続けると、プロジェクトの一貫性が失われやすくなります。
rulesがない状態では、Claude Codeは毎回の会話の文脈だけを頼りに作業します。そのため、会話ごとにコードのスタイルや使用するライブラリが変わってしまうケースが起きやすくなります。
たとえば、ある会話ではESLintのルールに沿ったコードを生成したのに、次の会話では全く異なるスタイルで生成されるといった問題が生じます。チーム開発では、こうしたばらつきがコードレビューの工数増加につながります。
また、「このライブラリは使わない」「このAPIは直接呼ばない」といった禁止事項も、毎回伝えなければClaude Codeは知ることができません。rulesがなければ、知らずに禁止事項を破ったコードが生成されるリスクもあります。
rulesは、Claude Codeを安全かつ効率よく使うための土台といえます。
Claude Code rulesの活用シーン
ここからは、Claude Code rulesを実際にどう使うかを、個人開発とチーム開発のシーン別に紹介します。
- 個人開発での設定例
- チーム開発での設定例
シーンによって書くべき内容が変わるため、それぞれ確認してみてください。
個人開発での設定例
個人開発では、自分の開発スタイルや好みをrulesに反映させることが重要です。
毎回同じ説明を省いてスムーズに作業を始められるよう、自分がよく使う技術スタックを中心に記載するのがおすすめです。たとえば、以下のような内容をCLAUDE.mdに書いておくと効果的です。
## 技術スタック
- 言語: TypeScript 5.x
- フレームワーク: Next.js 14（App Router）
- スタイリング: Tailwind CSS
- テスト: Vitest + Testing Library
## コーディング規約
- 関数はアロー関数で統一する
- コンポーネントはnamed exportで書く
- anyの使用を禁止する
## 禁止事項
- momentjsは使用しない（date-fnsを使う）
- console.logは本番コードに残さない上記のように技術スタックと禁止事項を明記しておくだけで、Claude Codeが毎回同じ方向性でコードを生成するようになります。個人開発では「自分が何度も説明していること」を書き出す作業から始めると、rulesの内容が見つけやすくなります。
上記を踏まえ、Claude Codeでアプリ開発する方法を詳しく知りたい人は、次の記事を参考にしてください。
チーム開発での設定例
チーム開発では、個人の好みではなくチーム全体で合意したルールをrulesに記載することが前提になります。
Git管理下に置けるプロジェクトルール（CLAUDE.md）が、チーム開発では特に重要な役割を担います。コードレビューの基準やブランチ運用のルールも含めておくと、Claude Codeの提案がチームの方針と一致しやすくなります。
チーム開発のrulesに盛り込むべき内容の例は次のとおりです。
## チーム規約
- プルリクエストの説明には必ず変更理由を書く
- 関数の命名はキャメルケースで統一する
- 1つのファイルは200行以内に収める
## 禁止事項
- directなDB操作（必ずRepository層を経由する）
- 環境変数のハードコード（.envを使う）
## レビュー観点
- セキュリティ上の問題がないか確認する
- テストカバレッジが80%以上になっているか確認する上記のようなrulesをリポジトリに含めることで、チームメンバー全員が同じ前提でClaude Codeを使えるようになります。新メンバーのオンボーディングにも役立てられる点もメリットです。
Claude Code rulesの種類
Claude Code rulesには3種類があり、適用範囲がそれぞれ異なります。
- プロジェクトルール：特定プロジェクト内に適用
- グローバルルール：すべてのプロジェクトに適用
- ローカルルール：個人のみに適用（Git管理外）
適用範囲の違いを理解することが、rulesを正しく使いこなすための第一歩です。
プロジェクトルール
プロジェクトルールは、特定のプロジェクトのルートディレクトリに置く「CLAUDE.md」ファイルで設定します。
プロジェクトのルートに置かれたCLAUDE.mdは、Git管理対象に含められるためチーム全体で共有できる点が最大の特徴です。チームメンバー全員が同じrulesのもとでClaude Codeを使えるようになります。
適用範囲はそのプロジェクト内に限定されるため、プロジェクトAのルールがプロジェクトBに干渉することはありません。プロジェクトごとに技術スタックや規約が異なる場合にとても便利です。
グローバルルール
グローバルルールは、すべてのプロジェクトに共通して適用されるrulesです。
ホームディレクトリの「~/.claude/CLAUDE.md」に記載することで設定できます。どのプロジェクトでも変わらない個人の作業スタイルや好みを書いておくのに適しています。
たとえば「コメントは必ず日本語で書く」「レスポンスは簡潔にまとめてほしい」といった、自分だけに関わる設定はグローバルルールに書いておくのがおすすめです。プロジェクトルールとグローバルルールが両方ある場合、両方のルールが組み合わせて適用されます。
ローカルルール
ローカルルールは、プロジェクト内に置きながらもGit管理の対象外にするrulesです。
「.claude/rules/」ディレクトリ内に「*.local.md」の形式でファイルを作成し、そのパスを「.gitignore」に追加することで設定できます。チームには共有したくない個人の作業メモや、一時的な試験的ルールを書いておくのに向いています。
たとえば「このスプリント中はパフォーマンス改善を優先する」「自分のデバッグ用のログ出力は残しておく」といった、個人限定の一時的な指示をローカルルールに書いておけます。プロジェクトルールやグローバルルールと組み合わせて使うことが前提の仕組みです。
Claude Code rulesの設定方法
ここからは、Claude Code rulesの具体的な設定手順を解説します。
- 「CLAUDE.md」での設定手順
- 「.claude/rules/」での設定手順
どちらの方法も難しくはありませんが、用途によって使い分けが必要です。
「CLAUDE.md」での設定手順
CLAUDE.mdを使った設定は、最もシンプルな方法です。プロジェクトのルートディレクトリにCLAUDE.mdファイルを作成するだけで、rulesとして機能します。
手順は次のとおりです。
- プロジェクトのルートディレクトリに移動する
- 「CLAUDE.md」という名前でファイルを作成する
- マークダウン形式でルールを記述して保存する
- Claude Codeを起動すると自動的にファイルが読み込まれる
CLAUDE.mdはマークダウン形式で書けるため、見出しや箇条書きを使って読みやすく整理できます。ファイルの文字コードはUTF-8で保存することを推奨します。
チーム開発ではCLAUDE.mdをGitの管理対象に含めることで、リポジトリをクローンしたメンバーも同じrulesでClaude Codeを使えます。グローバルルールとして設定したい場合は「~/.claude/CLAUDE.md」に同じ手順で作成します。
「.claude/rules/」での設定手順
「.claude/rules/」ディレクトリを使う方法では、ルールをファイルごとに分割して管理できます。
テーマや用途ごとにファイルを分けられるため、rulesの内容が増えてきた際の管理がしやすくなります。
手順は次のとおりです。
- プロジェクトのルートに「.claude/rules/」ディレクトリを作成する
- ディレクトリ内にマークダウンファイル（例：coding-style.md、testing.md）を作成する
- 各ファイルにテーマごとのルールを記述して保存する
- Gitで共有しない場合は「*.local.md」のファイル名にして.gitignoreに追加する
ファイル名はルールの内容がわかるものにすると管理しやすくなります。たとえば「coding-style.md」「testing-rules.md」「security.md」のように分けると、後から見直す際にどこを修正すればよいかすぐにわかります。
rulesの効果的な書き方のコツ5つ
ここからは、Claude Code rulesをより効果的に機能させるための書き方のコツを5つ紹介します。
- 簡潔で具体的な指示にする
- コーディング規約を明記する
- 禁止事項を明確に定義する
- プロジェクト構成を記載する
- 定期的に見直し改善する
各コツを実践することで、rulesの精度と効果が大きく高まります。
簡潔で具体的な指示にする
rulesの文章は短く、具体的に書くことが重要です。
あいまいな表現のrulesはClaude Codeが正しく解釈できず、意図と異なるコードが生成される原因になります。たとえば「きれいなコードを書く」ではなく、「関数は1つにつき30行以内に収める」のように数値で示すのが効果的です。
悪い例と良い例を比較すると次のとおりです。
- 悪い例：「わかりやすい変数名にする」
- 良い例：「変数名は省略なしの英単語で命名する（例：usr → user、btn → button）」
ルールの数が多くなると、Claude Codeが処理しきれないケースも出てきます。1つのrulesファイルには、本当に必要なルールだけを厳選して記載することをおすすめします。
コーディング規約を明記する
使用する言語・フレームワーク・バージョンは、rulesに明示しておくことが大切です。
バージョンを明記しないと、古い構文や廃止予定のAPIを使ったコードが生成されることがあります。たとえば「React 18を使い、関数コンポーネントとHooksで実装する」と書いておくだけで、クラスコンポーネントを使ったコードが生成されにくくなります。
記載しておきたいコーディング規約の例は次のとおりです。
- インデントはスペース2つ（またはタブ1つ）で統一する
- 文字列はシングルクォートで囲む
- セミコロンは必ず付ける（または付けない）
- TypeScriptの型定義はinterfaceよりもtypeを優先する
エディタの設定ファイル（.editorconfig）がある場合は、その内容と矛盾しないよう注意が必要です。
禁止事項を明確に定義する
「やってはいけないこと」を明示的に書くことで、問題のあるコードの生成を防げます。
禁止事項があいまいなままだと、Claude Codeは「よかれと思って」禁止している処理を使ってしまうことがあります。「〇〇は使わない」ではなく「〇〇は使わない。代わりに△△を使う」のように、代替手段もセットで書くと効果的です。
禁止事項の記載例は次のとおりです。
- 「eval()は使用禁止。動的な処理はFunction constructorも使わない」
- 「moment.jsは使用禁止。日付処理にはdate-fnsを使う」
- 「ログインAPIのレスポンスにパスワードを含めない」
禁止事項は箇条書きでまとめると、Claude Codeが読み取りやすくなります。
プロジェクト構成を記載する
ディレクトリ構成や各フォルダの役割をrulesに書いておくと、Claude Codeがファイルの置き場所を正しく判断できるようになります。
プロジェクト構成の説明がないと、新しいファイルを適切でない場所に生成してしまうケースが起きやすくなります。たとえば「componentsディレクトリにはUIコンポーネントのみ置く。ビジネスロジックはhooksディレクトリに分離する」と明記しておくだけで、構成の乱れを防げます。
記載例は次のとおりです。
## ディレクトリ構成
src/
├── components/ # 再利用可能なUIコンポーネント
├── hooks/ # カスタムフック（ビジネスロジック）
├── pages/ # ページコンポーネント
├── utils/ # ユーティリティ関数
└── types/ # TypeScriptの型定義上記のように構成をrulesに含めておくと、Claude Codeがファイルを作成・修正する際の判断基準が明確になります。
定期的に見直し改善する
rulesは一度書いたら終わりではなく、定期的な見直しが必要です。
プロジェクトが進むにつれて技術スタックが変わったり、チームのルールが更新されたりすることがあります。古くなったrulesを放置すると、実態と異なる指示をClaude Codeに与え続けることになります。
見直しのタイミングの目安は次のとおりです。
- フレームワークやライブラリのメジャーバージョンが上がったとき
- チームのコーディング規約が更新されたとき
- Claude Codeが意図と異なるコードを繰り返し生成するようになったとき
- スプリントやフェーズの区切りのタイミング
rulesの見直しは「Claude Codeの動作がおかしいな」と感じた時が最大のサインです。定期的に内容を確認し、現状に合った内容に更新していくことをおすすめします。
上記を含め、Claude Codeのおすすめプロンプトを詳しく知りたい人は、次の記事を参考にしてください。
Claude Code rulesによくある疑問
最後に、Claude Code rulesに関してよく寄せられる疑問に回答します。
- rulesが反映されないときの対処法
- rulesの適切な長さ
- 途中でrulesを変更しても問題がないか
rulesが反映されないときはどうしたらいい？
rulesが反映されない場合、まずファイルの配置場所とファイル名を確認してください。
最も多い原因は、CLAUDE.mdの保存場所が正しくないケースです。プロジェクトルールのCLAUDE.mdは、プロジェクトのルートディレクトリ（package.jsonと同じ階層）に置く必要があります。
確認すべき点を順番に挙げると次のとおりです。
- ファイル名が「CLAUDE.md」になっているか（大文字・小文字を確認する）
- ファイルの保存場所がプロジェクトのルートになっているか
- ファイルの文字コードがUTF-8になっているか
- Claude Codeを再起動して再度試してみたか
上記を確認しても解決しない場合は、rulesの記述量が多すぎて処理しきれていないケースも考えられます。一時的に内容を半分に減らして試してみると、原因の特定に役立ちます。
rulesはどのくらいの長さが適切？
rulesの長さに明確な上限はありませんが、500〜1,000文字程度を目安にするのがおすすめです。
Claude Codeのコンテキストウィンドウには上限があります。rulesが長くなりすぎると、会話の内容を処理するスペースが減り、レスポンスの精度が下がることがあります。必要最小限のルールだけを厳選して書くことが、rulesの効果を最大化するうえで重要です。
rulesを短く保つための考え方は次のとおりです。
- 「毎回説明していること」だけをrulesに書く
- 「たまに必要なこと」は会話の中で都度伝える
- 複数のプロジェクトに共通するルールはグローバルルールに分けて書く
内容が増えてきた場合は、「.claude/rules/」ディレクトリでテーマごとにファイルを分けることで管理しやすくなります。
途中でrulesを変更しても大丈夫？
途中でrulesを変更しても問題はありません。
CLAUDE.mdの内容を更新すると、次回のClaude Codeの起動時から新しいrulesが適用されます。進行中の会話の途中でrulesを変更した場合は、会話を一度終了して新しいセッションを開始すると確実に反映されます。
チーム開発でrulesを変更する際は、次のことに注意してください。
- 変更内容をGitでコミットし、チームメンバーに周知する
- 既存の作業中のブランチへの影響がないか確認する
- 大きな変更は、スプリントの区切りなどタイミングを選んで行う
rulesの変更は柔軟に行えるため、「とりあえず試してみて、うまくいかなければ修正する」というアプローチで問題ありません。
まとめ
Claude Code rulesは、Claude Codeへの指示を事前に定義しておく仕組みです。
設定しておくことで、プロジェクトの技術スタックやコーディング規約を毎回説明する手間がなくなります。個人開発では作業スピードの向上に、チーム開発ではコード品質の統一に役立てられます。
rulesには次の3種類があり、用途に応じて使い分けることが大切です。
- プロジェクトルール：特定プロジェクト内で有効。Gitで共有できる
- グローバルルール：すべてのプロジェクトで有効。個人の作業スタイルに使う
- ローカルルール：個人限定で使う一時的な指示に向いている
設定方法は、CLAUDE.mdをプロジェクトのルートに作成するだけです。内容は500〜1,000文字を目安に、簡潔で具体的な指示を書くことが効果を高めるポイントになります。
まずは「毎回Claude Codeに説明していること」をCLAUDE.mdにまとめることから始めてみてください。
こちらの記事もおすすめ
