【Claude Code】Rulesの使い方をわかりやすく解説

この記事では、AIが開発ルールを自動で守る「Claude Code Rules」について解説します。ルールの記述方法から、プロジェクト全体、特定のフォルダ、またはテストファイルなど、用途に応じたルール設定の適用範囲まで、システムエンジニア初心者が開発を効率的に進めるためのポイントを分かりやすく説明します。

作成日: 2026年05月10日更新日: 2026年09月29日

開発環境

OS: Windows10（WSL2 / Ubuntu）
Editor: Visual Studio Code
Node.js: v22.22.2
claude-code: 2.1.118

Claude Code Rules（ルールズ）とは？

システム開発の現場では、同じような指示や設定を何度も繰り返して行うことがよくあります。このような作業は、手間がかかり、効率的ではありません。

「Rules（ルールズ）」は、このような非効率さを解決するための仕組みです。ルールをファイルに一度記述しておくだけで、AIである「Claude（クロード）」がそのルールを自動的に守って作業を進めてくれます。これにより、毎回同じ指示をAIに与える必要がなくなり、作業をスムーズに進めることができるようになります。

CLAUDE.md という名前のファイルをプロジェクト内に配置するだけで、このルールが自動的に有効になります。特別な設定は必要ありません。
この CLAUDE.md ファイルを置く場所によって、そのルールの「スコープ」（影響範囲）が変わります。例えば、プロジェクト全体に適用する「グローバル」なルールにしたり、特定のフォルダ（「サブディレクトリ」）内だけに適用するルールにしたりすることが可能です。
さらに、.claude/rules/ という特定のフォルダの中に設定ファイルを置くことで、ファイルの種類ごと（例：HTMLファイルの場合、JavaScriptファイルの場合など）に異なる条件付きのルールを設定することもできます。これにより、より細かくAIの挙動をコントロールできます。

公式ドキュメント: https://code.claude.com/docs/ja/memory

配置場所で有効範囲が変わる

プログラミングでは、設定ファイルやルールを記述したファイルをどこに置くかによって、その設定が適用される範囲が変わります。これは、効率的な開発やチームでの共同作業において非常に重要な考え方です。

~/.claude/CLAUDE.md → すべてのプロジェクト

このパスにある ~ (チルダ) は、お使いのパソコンの「ホームディレクトリ」を表します。これは、ユーザーアカウント専用の特別なフォルダのことです。ここに CLAUDE.md というファイルを置くと、その設定はお使いのパソコン上にある「すべてのプロジェクト」に適用されます。つまり、どのプロジェクトを開いても、このファイルに書かれた設定やルールが自動的に読み込まれるということです。これは、自分自身の開発環境全体に共通する設定をしたい場合に利用します。
my-project/CLAUDE.md → このプロジェクトだけ

my-project は、いま作業している特定のプロジェクトのフォルダを表しています。例えば、ウェブサイトを開発しているなら、そのウェブサイトのプロジェクトフォルダを指します。このプロジェクトフォルダの直下に CLAUDE.md というファイルを置くと、その設定は「このプロジェクトだけ」に適用されます。他のプロジェクトには影響しません。これは、特定のプロジェクトにだけ適用したい固有の設定やルールがある場合に便利です。
my-project/src/CLAUDE.md → src/ 以下だけ

my-project/src/ は、特定のプロジェクトフォルダの中にある src (ソース) というサブフォルダを指します。src フォルダには、通常、プログラムのソースコード本体が格納されます。ここに CLAUDE.md というファイルを置くと、その設定は「src/ フォルダとそのサブフォルダ以下」にのみ適用されます。プロジェクト全体ではなく、特定のコード部分にのみルールを適用したい場合に役立ちます。

チーム共有したいもの は CLAUDE.md（Git に入れる） 個人用 は CLAUDE.local.md（gitignore 対象）

開発をチームで行う場合、全員が同じ設定やルールを使うことが重要です。

チームで共有したい設定やルール は、ファイル名を CLAUDE.md として作成します。このファイルは、Git というバージョン管理システムに「入れる」ことが推奨されます。Gitに入れることで、チームのメンバー全員が同じ設定ファイルを利用でき、変更履歴も管理できます。これにより、チーム全体で一貫した開発環境を維持し、共同作業をスムーズに進めることができます。
自分だけが使う個人用の設定やメモ は、ファイル名を CLAUDE.local.md とします。このファイルは、Gitの管理対象から「gitignore 対象」として外すことを強く推奨します。gitignore は、Gitに「このファイルはバージョン管理しない」と指示するための設定です。個人用の設定ファイルが誤ってチームに共有されたり、バージョン管理の履歴に残ったりするのを防ぎ、プライベートな情報を守るために重要です。

ビフォー・アフター

システム開発の現場では、コードの書き方に関するルール（コーディング規約）や、品質を保つための指示が多数存在します。これらはプロジェクトの成功のために非常に重要です。しかし、これらの指示を開発メンバー間で毎回確認したり、コードをレビューする際に指摘したりすることがあります。

例えば、以下のような指示を毎回伝えていることはありませんか？


1# 毎回こう打っていませんか？
2> コメントは日本語で書いて
3> テストは必ず書いて
4> console.log は残さないで

このようなルールを毎回口頭やコメントで伝えるのは、手間がかかりますし、伝え忘れが発生する可能性もあります。開発が進むにつれて、ルールの数も増え、管理が複雑になることも考えられます。

そこで、「CLAUDE.md」のようなファイルに、あらかじめ開発に関するルールを定義しておくことで、この問題を解決できます。CLAUDE.mdにルールを書いておけば、Claude（AI）がそのルールを理解し、自動的にコードを生成したり、レビューしたりする際に、定義されたルールを守ってくれるようになります。


1# CLAUDE.md に書いておけば、毎回の指示は不要
2✓ CLAUDE.md loaded
3（Claude が自動でルールを守ってくれる）

その結果、毎回指示をする手間がなくなり、開発効率が向上します。

このように、開発におけるルールを明文化し、それをシステムに活用することで、開発作業の効率化と品質向上が期待できます。これが、システムエンジニアとして働く上で、非常に役立つ考え方の一つです。

ルールファイルの構造

このセクションでは、プロジェクト内で共通のルールをまとめたファイルについて説明します。このファイルは、プロジェクトに参加する全てのエンジニアが守るべきガイドラインを定めています。

ファイルは特別な構文を必要とせず、Markdown形式で作成されます。Markdownは、シンプルで読みやすい文章を作成するための書式で、見出しやリストなどを簡単に記述できます。

以下に示すのが、ルールファイルの具体的な構造です。


1┌──────────────────────────────┐
2│ # プロジェクトルール           │
3│                              │
4│ ## コーディング規約            │
5│ - コメントは日本語で書く        │
6│ - console.log は残さない      │
7│                              │
8│ ## コミット                   │
9│ - feat / fix / chore を使う   │
10└──────────────────────────────┘

このルールファイルは、プロジェクトの一番上の階層にあるディレクトリ（「プロジェクトルート」と呼びます）に CLAUDE.md という名前で保存されます。

ファイルの内容について

ファイルの中身は、プロジェクト全体のルールを定義する「# プロジェクトルール」という一番大きな見出しから始まります。その中に、さらに具体的なルールが分類されて記述されています。

## コーディング規約

このセクションでは、プログラムコードを書く上での共通のルールが定められています。

コメントは日本語で書く プログラムのコードに説明を追記する「コメント」は、日本語で記述するように定めています。これにより、チーム内の誰もがコメントの内容を理解しやすくなり、プログラムの意図や動作をスムーズに共有できるようになります。
console.log は残さない console.log は、プログラムが正しく動作しているか確認したり、エラーを見つけたりするために、一時的に情報を画面に表示する機能です。しかし、開発が終わって実際に利用される製品版のプログラムに console.log が残っていると、意図しない情報が表示されたり、プログラムの動作が遅くなったりすることがあります。そのため、最終的なプログラムには残さないようにします。

## コミット

このセクションでは、プログラムの変更を保存する際（これを「コミット」と呼びます）のルールが定められています。

feat / fix / chore を使う コミットを行う際には、「コミットメッセージ」と呼ばれる変更内容の説明を付けます。このルールでは、そのメッセージの冒頭に、変更の種類を示す特定のキーワードを使うように定めています。
- feat：新しい機能を追加したとき
- fix：プログラムの不具合（バグ）を修正したとき
- chore：新機能の追加や不具合の修正ではない、プログラムの保守や設定の変更などを行ったときこのようにすることで、プログラムの変更履歴を見たときに、どのような種類の変更が行われたのかを一目で理解しやすくなります。

実例 1: プロジェクトルートの CLAUDE.md

このセクションでは、プロジェクトにおけるルールをまとめた CLAUDE.md というファイルについて説明します。

CLAUDE.md ファイルは、プロジェクトの最も上の階層である「プロジェクトルート」に配置されます。プロジェクトルートとは、プロジェクト全体を管理するフォルダの一番上に位置する場所です。ここにルールファイルを置くことで、プロジェクトに関わる全ての人がすぐにルールを確認できるようになります。


1my-project/
2  └── CLAUDE.md   ← ここに作る

この CLAUDE.md ファイルには、プロジェクトを進める上で守るべき具体的なルールが記述されています。チームで開発を行う際には、このようなルールを明確にすることで、開発の品質を保ち、作業をスムーズに進めることができます。


1# プロジェクトルール
2
3## コーディング規約
4- コメントは日本語で書く
5- 関数には必ず JSDoc コメントを付ける
6- console.log は本番コードに残さない
7
8## コミット
9- コミットメッセージは日本語でよい
10- feat / fix / chore のプレフィックスを使う

プロジェクトルールについて

CLAUDE.md ファイルの中身は、大きく分けて「コーディング規約」と「コミット」に関するルールで構成されています。それぞれのルールについて詳しく見ていきましょう。

コーディング規約

コーディング規約とは、コードを書く上での約束事のことです。これにより、コードの品質を均一に保ち、他の人が読んでも理解しやすいコードになります。

コメントは日本語で書く: コードの中に書く説明文（コメント）は、日本語で書くことをルールとしています。これにより、日本の開発チームであれば誰でもコメントの内容を理解しやすくなります。コメントは、コードが何をしているのか、なぜそのように書かれているのかを説明するために非常に重要です。
関数には必ず JSDoc コメントを付ける: JSDocコメントとは、JavaScriptの関数に対して、その関数の目的、受け取る情報（引数）、返す情報（戻り値）などを特定の形式で記述するコメントのことです。これにより、関数がどのような役割を持つのか、どのように使えば良いのかが明確になり、他の開発者が関数を理解しやすくなります。
console.log は本番コードに残さない: console.log は、プログラムの動作を確認したり、エラーの原因を探したりするために、開発中に情報を画面に出力する際に使われる命令です。しかし、この命令が本番環境（実際にユーザーが使う環境）のコードに残っていると、セキュリティ上の問題や、プログラムの処理速度が遅くなる原因となることがあります。そのため、開発が終わったら必ず削除する、というルールになっています。

コミット

コミットとは、バージョン管理システム（Gitなど）を使って、コードの変更履歴を記録する操作のことです。コミットに関するルールは、変更履歴を分かりやすく管理するために重要です。

コミットメッセージは日本語でよい: コードの変更内容を説明する文章（コミットメッセージ）は、日本語で書いても良いというルールです。これにより、開発者が変更内容を正確に伝えやすくなります。コミットメッセージは、後から変更履歴を振り返る際に非常に役立ちます。
feat / fix / chore のプレフィックスを使う: コミットメッセージの先頭に、feat、fix、chore といった特定のキーワードを付けるルールです。これにより、そのコミットがどのような種類の変更を行ったのかを一目で判別できます。
- feat: 新しい機能を追加した変更であること。
- fix: バグ（プログラムの誤り）を修正した変更であること。
- chore: コードの整理や設定の変更など、機能追加やバグ修正以外の軽微な変更であること。

これらのルールを守ることで、プロジェクトのコードが整理され、チームでの開発がより効率的でスムーズに進むようになります。

動作確認：CLAUDE.md が読み込まれるか

このセクションでは、システムが CLAUDE.md という名前の設定ファイルを正しく読み込んでいるかを確認する方法を説明します。システムが意図した通りに動作するためには、設定ファイルが適切に読み込まれていることが重要です。

まず、以下のコマンドを実行します。


1claude

この claude コマンドは、システムを起動するために使用します。このコマンドを実行することで、システムが起動し、必要な設定ファイルを読み込み始めます。

コマンドを実行すると、以下のような出力結果が表示されます。

出力結果
1✓ CLAUDE.md loaded
2（Claude が起動し、ルールを読み込んだことが確認できる）

この ✓ CLAUDE.md loaded は、CLAUDE.md が読み込まれたことを示しています。ただし、起動時にどのような表示が出るかはバージョンや環境によって変わります。

読み込まれたかどうかを確実に確認したい場合は、セッション内で /context を実行してください。


1/context

/context の Memory files の一覧に CLAUDE.md が並んでいれば、そのファイルは読み込まれています。一覧に出ていない場合、Claude はそのファイルを見ていません。配置場所が正しいかを確認してください。

CLAUDE.md は各セッションの開始時に読み込まれます。外部エディタで直接編集した場合、その変更が現在の会話にすぐ反映されないことがあります。

CLAUDE.md は、セッションが始まるときに読み込まれるファイルです。そのため、会話の途中で外部のエディタからファイルを書き換えても、いま進行中の会話には反映されないことがあります。

変更を確実に反映させたい場合は、次のいずれかを行ってください。

/memory でファイルを開いて編集・保存する
/compact を実行する（Claude が CLAUDE.md をディスクから読み直します）
新しいセッションを開く

スコープを理解する

プログラミングやシステム設定において「スコープ」とは、ある設定や変数が影響を及ぼす範囲のことを指します。ここでは、CLAUDE.md というファイルが、その配置場所によってどのように影響範囲を変えるかについて説明します。

CLAUDE.md は 配置場所によってスコープが変わる のが特徴です。


1~/.claude/CLAUDE.md        ← グローバル（全プロジェクト）
2  └── CLAUDE.md            ← プロジェクトルート
3       └── CLAUDE.local.md ← ローカル上書き（gitignore推奨）
4            └── src/CLAUDE.md  ← サブディレクトリ（そのフォルダのみ）

上記のように、CLAUDE.md ファイルは様々な場所に置かれる可能性があります。それぞれの配置場所が意味するスコープ（影響範囲）は以下の通りです。

~/.claude/CLAUDE.md: これは、ユーザーのホームディレクトリ（~）にある隠しフォルダ内に配置されます。このファイルで設定された内容は、「グローバル」と呼ばれ、お使いのコンピュータ上の全てのプロジェクトに対して影響を及ぼします。
CLAUDE.md (プロジェクトルート): これは、特定のプロジェクトの最も上位のフォルダ（プロジェクトルート）に配置されます。このファイルの設定は、その特定のプロジェクト全体に影響を与えます。
CLAUDE.local.md: このファイルもプロジェクトルートに配置されますが、主に開発者のPC環境固有の設定や、CLAUDE.md の内容を一時的に変更したい場合に使用されます。「ローカル上書き」とあるように、プロジェクト共通の CLAUDE.md の設定を、このファイルの内容で上書きすることができます。通常は、他の開発者と共有しない設定であるため、バージョン管理システム（例：Git）の管理対象から外すこと（gitignore推奨）が推奨されます。
src/CLAUDE.md: これは、src のような特定のサブディレクトリ（フォルダ）内に配置されます。このファイルの設定は、そのサブディレクトリとその中にあるファイルにのみ影響を及ぼします。最も限定された範囲の設定となります。

これらのファイルは、上から順に読み込まれ、下のルールが優先される という特性があります。

これは、もし複数の CLAUDE.md ファイルで同じ設定項目に対して異なる値が指定されていた場合、より下位（より具体的な場所）に配置されたファイルの設定が最終的に適用される、という意味です。例えば、グローバルな設定とプロジェクトルートの設定で競合する項目があれば、プロジェクトルートの設定が優先されます。さらに、プロジェクトルートの設定とサブディレクトリの設定で競合する項目があれば、サブディレクトリの設定が優先される、といった具合です。この仕組みにより、広範囲の設定を基本としつつ、特定の場所でその設定を細かく変更したり、上書きしたりすることが可能になります。

(1) グローバルルール（全プロジェクト共通）

このセクションでは、システム開発において非常に重要な「グローバルルール」について説明します。グローバルルールとは、すべてのプロジェクトに共通して適用される、基本的な決まり事のことです。

まず、このルールがどこに配置されるのかを見てみましょう。


1~/
2  └── .claude/
3       └── CLAUDE.md   ← ここに作る

このパスは、ルールが記述されたファイルの場所を示しています。

~/ は、お使いのパソコンの「ホームディレクトリ」という場所を指します。これは、普段使うファイルやフォルダが置かれている、自分専用の場所だと考えてください。
.claude/ は、ホームディレクトリの直下にある「.claude」という名前のフォルダです。「.（ドット）」から始まるフォルダは、通常、システムの設定ファイルや特別な情報を格納するために使われることが多いです。
CLAUDE.md は、実際にルールが書かれているファイルの名前です。「.md」はMarkdown形式のファイルであることを示しています。

次に、このファイルに書かれている具体的なルールを見てみましょう。


1# グローバルルール
2
3- 回答は常に日本語で返す
4- コードブロックには言語名を明示する

# グローバルルール: これは、このファイルのタイトルであり、このファイル全体がグローバルルールについて定義していることを示します。
回答は常に日本語で返す: このルールは、システムが何か情報を提供したり、質問に応答したりする際に、必ず「日本語」で返答するように指示しています。例えば、エラーメッセージや確認メッセージなども、すべて日本語で表示されるようになります。これにより、利用者が内容を正確に理解しやすくなります。
コードブロックには言語名を明示する: プログラムのコードを文書内に記載する場合、それがどのプログラミング言語（例えば、Python、Java、JavaScriptなど）で書かれているのかをはっきりと指定するというルールです。これにより、コードを読んだ人がすぐにそのコードの種類を判断でき、理解しやすくなります。

このファイルは すべてのプロジェクト で読み込まれます。

これは、この CLAUDE.md ファイルに書かれているルールが、これから開発する全てのシステムやソフトウェアプロジェクトに対して適用されることを意味します。個別のプロジェクトごとにルールを決めるのではなく、最初から共通の決まり事を設けることで、どのプロジェクトでも一貫した品質や運用が保たれ、開発効率も向上します。

(2) プロジェクトルール（このプロジェクトだけ）

このセクションでは、いま取り組んでいる「このプロジェクトだけ」に適用される、特別なルールについて説明しています。


1my-project/
2  └── CLAUDE.md   ← ここに作る

まず、上記のコードブロックをご覧ください。 my-project/は、プロジェクトが保存されているフォルダの名前を表しています。その中のCLAUDE.mdというファイルが、このプロジェクトのルールを書き込む場所であることを示しています。「← ここに作る」という指示は、まさにこの場所にCLAUDE.mdという名前のファイルを作成してください、という意味です。.mdはMarkdown形式のファイルであることを示しており、見出しや箇条書きなどを使って読みやすい文書を作成できます。

次に、「チーム共有したいルールはここに書いて コミット する」という指示についてです。これは、以下のことを意味しています。

チーム共有したいルール: プロジェクトを円滑に進めるために、チームのメンバー全員が知っておくべき約束事や作業の進め方などを指します。例えば、ファイルの命名規則やコードの書き方、特定の機能の実装方法など、プロジェクト特有の取り決めがこれに該当します。
ここに書いて: これらのルールを先ほど指定されたCLAUDE.mdファイルに具体的に記述してください、ということです。
コミット: ルールをCLAUDE.mdファイルに書き込んだ後、その変更内容をバージョン管理システム（例：Git）を使って記録として保存し、チームメンバー全員がそのルールを参照できるようにする作業のことです。コミットすることで、変更がプロジェクトの履歴に残り、他のチームメンバーも最新のルールを確認し、それに従って作業を進めることができます。

このように、プロジェクトごとに独自のルールを明確にし、それをチーム全員で共有することは、開発をスムーズに進めるために非常に大切です。

(3) ローカル上書き（自分だけのカスタマイズ）

このセクションでは、プロジェクト全体の設定に影響を与えず、あなたのローカル環境（つまり、あなたのPC上）だけで有効な、自分だけのカスタマイズ設定を行う方法について説明します。

CLAUDE.md がプロジェクト全体の共通ルールや設定を記述するファイルであるのに対し、CLAUDE.local.md は、あなた個人の環境に合わせた特別な設定を追加するためのファイルです。


1my-project/
2  ├── CLAUDE.md
3  └── CLAUDE.local.md   ← ここに作る

このように CLAUDE.local.md というファイルを作成することで、プロジェクトの標準的な設定（CLAUDE.md）はそのままに、あなた個人の作業を効率化するための設定や、一時的な設定を柔軟に適用できます。

CLAUDE.local.md には、以下のような内容を記述することができます。


1# ローカル専用ルール（コミットしない）
2
3- デバッグ時は詳細ログを出力する
4- 私の名前は田中。コミットメッセージに含めない

この例で示されているように、# ローカル専用ルール（コミットしない） というコメントは、このファイルに書かれた内容はあなた個人のためのものであり、Gitなどのバージョン管理システムに含めてチームメンバーと共有してはいけないことを明確に示しています。

デバッグ時は詳細ログを出力する: プログラムに問題がないか確認する（デバッグする）際に、通常よりも詳しい情報を画面に表示する設定です。これは一時的に多くの情報が必要な場合に便利ですが、他の開発者には不要な情報であることが多いため、自分だけの設定としておきます。
私の名前は田中。コミットメッセージに含めない: こちらは、コミットメッセージ（Gitで変更内容を記録する際のコメント）に個人的な情報を含めないようにするといった、プライベートなルールやメモを記述する例です。

.gitignore に追加しておくこと。チームメンバーに個人設定が共有されてしまう。

非常に重要な注意点として、CLAUDE.local.md のような個人設定ファイルは、必ず .gitignore ファイルに追加してください。.gitignore は、Gitが特定のファイルやフォルダをバージョン管理の対象外にするための設定ファイルです。

もし .gitignore に CLAUDE.local.md を追加しないと、誤ってこのファイルがGitリポジトリにコミットされてしまい、チームメンバー全員にあなたの個人設定が共有されてしまう可能性があります。これにより、他の開発者の環境で予期せぬ問題が発生したり、あなたのプライベートな情報が共有されてしまったりすることがあります。

個人設定は、あくまでご自身の開発環境でのみ利用するように心がけましょう。

(4) サブディレクトリルール（特定フォルダだけ）

ソフトウェア開発のプロジェクトでは、たくさんのファイルやフォルダが使われます。これらのファイルやフォルダには、それぞれ役割や性質があります。そのため、プロジェクト全体に適用されるルールもあれば、特定のフォルダの中にだけ適用されるルールも存在します。

今回ご紹介する「サブディレクトリルール」は、まさに後者の「特定のフォルダだけに適用されるルール」のことです。特定のフォルダに特化したルールを設けることで、そのフォルダ内のコードの品質を高く保ち、開発を効率的に進めることができます。

例えば、以下のようなファイル構造のプロジェクトがあったとします。


1my-project/
2  ├── CLAUDE.md
3  └── src/
4       └── CLAUDE.md   ← ここに作る

この例では、my-project/ というプロジェクトの中に CLAUDE.md というファイルがあり、さらに src/ というフォルダの中に CLAUDE.md というファイルが作られることを示しています。ここで注目していただきたいのは、src/ というフォルダです。

src/ フォルダは「ソースコード」を意味し、プログラムの本体となる重要なコードが置かれることが一般的です。そのため、この src/ フォルダの中のファイルを扱う際には、特別なルールが適用されます。

具体的には、src/ 以下のファイルを触るときだけ、次のようなルールが適用されることになります。


1# src ルール
2
3- 新しいファイルは TypeScript で作成する（.js は使わない）
4- API レスポンスには必ず型定義を付ける
5- 秘密情報（APIキー等）はハードコードせず環境変数から読み込む

これらのルールについて、もう少し詳しく説明いたします。

新しいファイルは TypeScript で作成する（.js は使わない）
- 「TypeScript（タイプスクリプト）」は、JavaScript（ジャバスクリプト）というプログラミング言語に「型（かた）」という仕組みを追加したものです。型とは、変数やデータの種類（数字なのか、文字なのか、など）をあらかじめ決めておくことです。
- TypeScriptを使うと、プログラムの間違いを開発中に見つけやすくなり、より信頼性の高いコードを書くことができます。そのため、src/ フォルダ内では、.js（JavaScriptのファイル拡張子）ではなく、.ts（TypeScriptのファイル拡張子）のファイルを使うことがルールとなっています。
API レスポンスには必ず型定義を付ける
- 「API（アプリケーションプログラミングインターフェース）」とは、異なるプログラム同士が情報をやり取りするための窓口。例えば、あるWebサイトが天気予報の情報を他のサービスから受け取る場合、その情報がAPIを通じて提供されます。
- 「APIレスポンス」とは、そのAPIから受け取るデータのことです。このデータがどのような形（例えば、気温は数字、都市名は文字、など）をしているのかを、「型定義」として明確にルールとして定めることが重要です。
- 型定義をすることで、受け取ったデータが期待通りの形であるかを確認でき、データの誤りによる不具合を防ぐことができます。
秘密情報（APIキー等）はハードコードせず環境変数から読み込む
- 「秘密情報」とは、APIキーやデータベースのパスワードなど、外部に漏れてはいけない重要な情報のことです。これらの情報が漏洩すると、セキュリティ上の大きな問題につながる可能性があります。
- 「ハードコード」とは、秘密情報をプログラムのコードの中に直接書き込んでしまうことです。これはセキュリティ上非常に危険であり、また、開発環境と本番環境で異なる設定が必要な場合にも対応が難しくなります。
- 「環境変数」とは、プログラムが実行されるコンピュータの環境に設定しておく変数（値）のことです。秘密情報をコードの中に直接書くのではなく、環境変数として設定し、プログラムからその環境変数を読み込むようにすることで、秘密情報がコードと一緒に公開されるリスクを防ぎ、より安全に扱うことができます。

これらのルールは、src/ フォルダ内のコードが、より安全で、より高品質に、そして開発しやすい状態を保つために非常に大切な役割を果たしています。開発を進める際には、どのフォルダにどのようなルールが適用されるのかを意識して作業を進めていきましょう。

実例 2: .claude/rules/ で条件付きルール

ここでは、.claude/rules/ という特別なフォルダー（ディレクトリ）を使うことで、設定やルールを適用する方法について説明します。

CLAUDE.mdというファイルは、プロジェクト全体で常に読み込まれて、そこに書かれているルールが常に適用されます。これは、全てのファイルに共通で適用したいルールを設定するときに使います。

一方、.claude/rules/ というフォルダーの中にファイルを作成すると、そのファイルは特定の条件が満たされたときにだけ読み込まれて、中のルールが適用されるようになります。これを「ファイルの種類に応じて条件付きで読み込める」と表現します。これにより、特定の目的を持つファイルに対してだけ、特別なルールを適用することが可能になります。

例えば、以下のような構成が考えられます。


1my-project/
2  └── .claude/
3       └── rules/
4            ├── coding-style.md   ← 常時読み込み
5            └── testing.md        ← テストファイルだけ

この例では、coding-style.mdというファイルは、プロジェクト内の全てのファイルに対して常に適用されるコーディングのルール（コードの書き方の決まりごと）を持っています。

一方で、testing.mdというファイルは、テストに関するファイルを開いたときや、テスト関連の作業を行うときにだけ読み込まれて適用されるルールを持っています。このように、必要な場面でのみルールを適用することで、プロジェクトの管理をより効率的に行うことができます。

常時読み込まれるルール（paths なし）

.claude/rules/coding-style.md


1# コーディングスタイル
2
3- 変数名・関数名はキャメルケースで書く
4- インデントは 2 スペース
5- コメントは日本語で書く

これは、あるツール（ここではClaudeという名前のツールを想定しています）を使う際に、どのような設定ファイルが適用されるかについての説明です。通常、設定ファイルはプログラムの動作を決める指示書。

paths: という記述がない場合、このファイルに書かれたルールは、ツールが動くたびに、いつでも適用されるということを意味します。ちょうど、会社に出社したら必ず守るべきルールのように、常に意識されるものだと考えてください。

CLAUDE.md というファイルも、同じようにルールを記述できる場所ですが、そこに全てのルールをまとめて書く必要があります。しかし、今回紹介しているような方法では、コーディングスタイル、セキュリティに関するルール、データベースのルールなど、トピック（テーマ）ごとにファイルを分けて管理できるというメリットがあります。これは、ルールが増えてきたときに、どこに何が書いてあるかを探しやすくなり、管理が非常に楽になる仕組みです。

ここで書かれているのは、プログラムの書き方に関する共通のルール、つまりコーディングスタイルです。複数のエンジニアが協力して一つのシステムを開発する際に、全員が同じ書き方をすることで、誰が書いたコードでも読みやすく、理解しやすくなります。これは、チーム開発において非常に重要な要素です。

変数名・関数名はキャメルケースで書く 変数名とは、プログラムの中でデータを一時的に保存しておく箱に付ける名前のことです。また、関数名とは、特定の処理を実行するための一連の命令に付ける名前のことです。キャメルケースとは、単語の区切りを大文字にすることで表現する命名規則の一つです。例えば、『firstName』や『calculateTotalPrice』のように、ラクダのコブのように文字が大文字・小文字で変化することから、この名前がついています。これによって、単語と単語の区切りが分かりやすくなり、読みやすいコードになります。
インデントは 2 スペース インデントとは、プログラムのコードの行頭に空白（スペース）やタブを入れることです。プログラムは、ある条件の時だけ動く部分や、繰り返し動く部分など、処理のまとまりがいくつか存在します。インデントを入れることで、これらの処理のまとまりがどこからどこまでかを視覚的に分かりやすく表現できます。このルールでは、そのインデントを『2スペース』で統一することを定めています。これにより、誰が見てもコードの構造が同じように見えるようになります。
コメントは日本語で書く コメントとは、プログラムのコードの動きや意図を説明するために、コードの中に書くメモ書き。コメントに書かれた内容は、プログラムの実行には影響しません。このルールでは、コメントを日本語で書くことを定めています。これにより、コードを読んだときに、その部分が何をしているのか、なぜそのように書かれているのかを、他の人が理解しやすくなります。

パス条件付きルール（テストファイルだけに適用）

このセクションでは、これから説明するルールが「どのファイルに適用されるか」を定義しています。


1---
2paths:
3  - "**/*.test.ts"
4  - "**/*.test.tsx"
5  - "**/*.spec.ts"
6---
7
8# テストルール
9
10- テスト名は「should [期待する結果] when [条件]」の形式で書く
11- 外部依存はモックする（内部モジュールはモックしない）
12- afterEach で副作用を必ずクリーンアップする
13- テストファイル1つにつき describe ブロックを1つにまとめる

上記のコードブロックは、この後に続く「テストルール」が適用されるファイルのパスを指定しています。具体的には、以下のいずれかの条件を満たすファイルにルールが適用されます。

**/*.test.ts: 任意のディレクトリ（**）にある、.test.ts で終わるファイル。例えば src/utils/math.test.ts のようなファイルです。
**/*.test.tsx: 任意のディレクトリにある、.test.tsx で終わるファイル。これは主にReactなどのUIコンポーネントのテストファイルで使われます。
**/*.spec.ts: 任意のディレクトリにある、.spec.ts で終わるファイル。.test.ts と同様にテストファイルを示す一般的な命名規則の一つです。

これらのルールは、主にTypeScriptやJavaScriptで書かれたテストコードに対して適用されることを示しています。つまり、アプリケーションの通常のコードではなく、特定のテストファイルだけに適用される決まりごとであることを理解してください。

ここからは、実際にテストコードを書く際に守るべき具体的なルールを説明します。これらのルールは、テストコードをより分かりやすく、保守しやすくするために重要です。

テスト名は「should [期待する結果] when [条件]」の形式で書く

テストの名前は、そのテストが「何を」「どのような状況で」検証しているのかを明確に伝える役割があります。この命名規則に従うことで、テストコードを読んだ人が一目でそのテストの意図を理解できるようになります。
- should [期待する結果]：そのテストが成功した場合に何が起きるべきか、何が正しい振る舞いであるかを説明します。
- when [条件]：その「期待する結果」が得られるための前提条件や状況を説明します。
例:
- should return true when input is valid: 「入力が正しい場合、trueを返すはず」というテストです。
- should throw an error when user is not authenticated: 「ユーザーが認証されていない場合、エラーをスローするはず」というテストです。
このように書くことで、テストが失敗した際にも、どの条件で何が期待通りではなかったのかを素早く特定しやすくなります。
外部依存はモックする（内部モジュールはモックしない）
- 外部依存とは何か？ テスト対象のコードが直接コントロールできない、外部の要素のことを指します。例えば、データベース、ネットワーク上のAPI、ファイルシステム、あるいは時間などです。これらの要素は、テストを実行するたびに状態が変わったり、処理に時間がかかったりする可能性があります。
- モックするとは何か？ 外部依存の代わりに、テストのために用意した「偽物」や「ダミー」のオブジェクト、関数を使用することを「モックする」と言います。モックを使用することで、外部の影響を受けずに、テスト対象のコードが正しく動作するかどうかを独立して検証できます。
  
  なぜモックするのか？
  1. 独立性: 外部サービスがダウンしていてもテストが失敗しないようにします。
  2. 速度: ネットワーク通信やデータベースアクセスなどの遅い処理をスキップし、テストを高速化します。
  3. 再現性: 常に同じ条件でテストを実行できるようになります。
- 内部モジュールはモックしない 同じプロジェクト内で作成された別のファイル（内部モジュール）は、通常はモックしません。なぜなら、それらはテスト対象のコードの一部であり、実際の挙動を検証するために、そのまま使用することが望ましいからです。モックしすぎると、アプリケーション全体の結合が正しく機能しているかを検証できなくなってしまうことがあります。
afterEach で副作用を必ずクリーンアップする
- afterEach とは何か？ 多くのテストフレームワークには、afterEach という機能があります。これは、一つ一つのテストが実行された「後」に、必ず実行される処理を定義するためのものです。
- 副作用とは何か？ テストが実行されることによって、テスト環境に何らかの変化をもたらすことを「副作用」と呼びます。例えば、グローバル変数の値を変更したり、一時ファイルを生成したり、タイマーを設定したりするなどが挙げられます。
- なぜクリーンアップが必要か？ あるテストが残した副作用が、次に実行されるテストに影響を与えてしまうことがあります。これにより、本来成功するはずのテストが失敗したり、逆に失敗するはずのテストが成功したりするなど、テスト結果が不安定になる原因となります。afterEach を使ってテストごとに環境をリ元の状態に戻す（クリーンアップする）ことで、各テストが独立して実行され、信頼性の高いテスト結果を得られるようになります。
テストファイル1つにつき describe ブロックを1つにまとめる
- describe ブロックとは何か？ describe ブロックは、関連する複数のテストをグループ化するために使われる機能です。これによって、テストコードの構造を整理し、何に関するテストが集まっているのかを明確にすることができます。
- なぜ1つにまとめるのか？ 一つのテストファイルが、ある特定の機能やコンポーネントに関するテストのみを含むようにすることで、そのファイルの目的が明確になります。もし複数のdescribeブロックが一つのファイルに存在すると、そのファイルが多くの異なることをテストしているように見え、ファイルの目的が曖昧になる可能性があります。
このようにdescribeブロックを一つにまとめることで、テストファイルの意図を明確にし、コードの可読性を向上させ、テストの管理を容易にします。

frontmatter の注意点

frontmatter とは、ファイルの一番先頭に記述する設定情報やメタデータのことです。これは、特定のシステムやツールがファイルをどのように扱うか、あるいはどのような情報が含まれているかなどを認識するために使われます。

この frontmatter は、必ず --- (ハイフン3つ) で囲む必要があります。この --- は、frontmatter の開始と終了を示す区切り線の役割を果たします。

この --- で囲まれた frontmatter の記述は必須です。もし記述を忘れてしまうと、意図しない動作が発生する可能性があります。具体的には、通常であればfrontmatterに書かれた条件に基づいて処理されるはずのものが、条件なしで常に読み込まれてしまうことになります。これにより、パフォーマンスの低下や、不必要なファイルまでが処理の対象となってしまう問題が発生する場合がございます。

以下に frontmatter の記述例を示します。


1---
2paths:
3  - "**/*.test.ts"
4---

この例では、paths という項目で、どのファイルを対象とするかを指定しています。 "**/*.test.ts" のような記述は、glob パターン と呼ばれる記法です。glob パターン を使うことで、ファイル名やディレクトリ名をワイルドカード（* や ** など）を使ってまとめて指定することができます。

この glob パターン を利用することで、例えば「どのディレクトリにあっても .test.ts で終わるすべてのファイルを対象にする」といったように、柔軟にマッチさせたい対象ファイルを指定することが可能になります。これにより、必要なファイルだけを正確に選び出して処理を行うことができます。

動作確認：paths 付きルールが適用されるか

この項目では、「paths 付きルール」が正しく適用されるかを確認します。「paths 付きルール」とは、特定のファイルやディレクトリのパス（場所）に関連付けられた、特別な指示や設定のことです。あるファイルが処理される際に、そのファイルのパスに基づいて特定のルールが自動的に適用されることを確認します。


1claude "auth.test.ts のテストを確認して"

上記のコマンドは、claudeというツール（AIアシスタントのような役割を果たすもの）に対して、「auth.test.ts」というファイル（認証機能のテストが書かれたファイルです）の内容を確認するように指示しています。

このclaudeがauth.test.tsというファイルを読み込む際、システムは自動的にtesting.mdという別のファイルに書かれているルールを適用します。これは、手動で何か設定しなくても、auth.test.tsファイルが読み込まれると同時に、testing.mdに定義されたテスト関連の指示や設定が使われることを意味しています。これにより、特定のファイルに対して効率的に作業を行うことが可能になります。

使い分けの基準

プロジェクトを進める上で、さまざまな設定やルールをどこに記述するかはとても大切です。この表は、どのような設定をどこに置くべきかの基準を示しています。

やりたいこと	置き場所
プロジェクトで常に守ること	CLAUDE.md
src/ だけに適用したいルール	src/CLAUDE.md
テストファイルだけに適用	.claude/rules/ + paths
自分だけのカスタマイズ	CLAUDE.local.md（gitignore）

各項目の説明

プロジェクトで常に守ること
- これは、プロジェクト全体にわたって、全てのメンバーが共通して守るべき基本的なルールや設定を指します。
- このような全体に関わる重要な情報は、プロジェクトのルートディレクトリ（一番上の階層）にある「CLAUDE.md」というファイルに記述します。
- このファイルを見ることで、プロジェクトの全体的な方針や主要な設定をすぐに確認できます。
src/ だけに適用したいルール
- 「src/」ディレクトリは、一般的にプロジェクトの主要なソースコード（プログラムの本体）が置かれる場所です。
- もし、この「src/」ディレクトリ内でのみ適用したい、特定のルールや設定がある場合は、「src/CLAUDE.md」というファイルを作成し、そこに記述します。
- このようにすることで、ソースコードに特化した設定を明確に管理し、他の部分のルールと混同することなく適用できます。
テストファイルだけに適用
- ソフトウェア開発において、作成したプログラムが正しく動くかを確認するための「テストファイル」を記述することがよくあります。
- テストファイルに対してのみ適用したいルールがある場合は、「.claude/rules/」というディレクトリ内に、適切なファイルパス（+ paths）でルールファイルを配置します。
- このようにルールを分けて管理することで、テストコード特有の要件に対応し、テストの実行や管理を効率的に行えるようになります。
自分だけのカスタマイズ
- プロジェクトの共通ルールとは別に、自分自身の開発環境や作業方法に合わせて、個人的な設定やカスタマイズをしたい場合があります。
- このような自分だけの設定は、「CLAUDE.local.md」というファイルに記述します。
- 重要な点として、「gitignore」と指定されていることがあります。これは、このファイルをGitなどのバージョン管理システムから除外し、他の開発者と共有しないという意味です。
- 個人的な設定なので、他の人の環境には影響を与えず、かつ誤って共有されることを防ぐために「gitignore」に含めるのが一般的です。

よくあるトラブル

ルールが反映されない

原因: 会話の途中で CLAUDE.md を外部エディタから編集し、その内容が現在の会話に読み込まれていない

「CLAUDE.md」とは、使用している開発ツール（例えばClaude Code）にルールを伝えるファイルのことです。このファイルはセッションの開始時に読み込まれるため、会話の途中で外部のエディタから書き換えても、進行中の会話には反映されないことがあります。

まず /context を実行し、Memory files の一覧に対象のファイルが入っているかを確認してください。一覧に入っているのに内容が古い場合は、次のいずれかで読み直させます。

→ /memory で編集・保存する、/compact を実行する、または新しいセッションを開く

paths 付きルールが効かない

原因: frontmatter の --- を書き忘れている

「paths 付きルール」とは、設定するルールを、全てのファイルに適用するのではなく、「特定のファイルにだけ適用したい」という場合に使う設定方法です。例えば、「テストファイル（*.test.ts）にだけ、このルールを適用したい」といった使い方をします。

この「paths 付きルール」がうまく機能しない場合の原因として、「frontmatter」という部分の書き忘れが挙げられます。「frontmatter」とは、ファイルの先頭に書く、そのファイル全体に関する特別な設定情報のことです。そして、このfrontmatterの始まりと終わりを示すために、「---」（ハイフンを3つ並べたもの）という区切り記号が必要です。

以下の例を見てください。もし---を書き忘れてしまうと、その設定はfrontmatterとして認識されず、意図しない形で常に読み込まれてしまいます。---で囲むことによって、「ここからここまでは特別な設定情報ですよ」とツールに正しく伝えることができます。これにより、指定したpaths（パス、つまりファイルの場所や名前のパターン）に応じて、ルールが正しく適用されるようになります。


1# NG（常時読み込みになる）    # OK（条件付きになる）
2paths:                       ---
3  - "**/*.test.ts"           paths:
4                               - "**/*.test.ts"
5                             ---

おわりに

この記事では、AIが開発ルールを自動で守る「Claude Code Rules」について学びました。CLAUDE.mdファイルにルールを記述し、その配置場所によって適用範囲をグローバルからサブディレクトリまで柔軟に設定できます。コーディング規約やコミットルールを統一することで、開発を効率化し、品質を向上させることが可能です。また、frontmatterを用いて特定のファイルに条件付きルールを適用する方法や、会話の途中でルールを書き換えたときに /memory や /compact、新しいセッションで読み直させる方法も理解できました。