CLAUDE.mdでプロジェクトのルールを伝える

01繰り返し伝えるルールだけをプロジェクトファイルに移す

前の記事では、Claude Codeに依頼するたびに入力ファイル、標準ライブラリの使用、元のCSVを変更しないこと、実行コマンド、期待出力まで直接書いていました。同じプロジェクトで作業を続けるなら、こうしたルールを毎回書き直す代わりにCLAUDE.mdへ整理できます。Claude Codeはセッション開始時にこのファイルを読み、プロジェクトの文脈として使います。

ただし、CLAUDE.mdをアクセス制御の仕組みや絶対的な強制ルールと考えてはいけません。公式ドキュメント上、このファイルは文脈であり、具体的で簡潔なほど従いやすくなります。そのため「常に完全に守られる」と仮定せず、実際の変更内容は引き続き確認する必要があります。

02チーム共有・個人共通・個人プロジェクト用のファイル位置を分ける

公式ドキュメントで案内されている配置場所は用途が異なります。プロジェクトルートの`./CLAUDE.md`は、チームで共有するプロジェクトルールに適しています。`~/.claude/CLAUDE.md`は個人の全プロジェクトに共通して適用するメモで、`./CLAUDE.local.md`は特定プロジェクトで個人的にだけ使い、.gitignoreに追加できます。

./CLAUDE.md
~/.claude/CLAUDE.md
./CLAUDE.local.md

今回の例では、実行コマンドやデータ規則のようにプロジェクト自体に属する内容を扱うため、`./CLAUDE.md`を使います。個人的な好みやローカルパスをチーム共有ファイルに混ぜない方が管理しやすくなります。

03/initで下書きを作り、そのまま確定しない

セッションで`/init`を使うと、Claude Codeがコードベースを分析し、ビルド・テストコマンドや慣例を含むCLAUDE.mdの下書きを作成できます。すでにCLAUDE.mdがある場合は上書きせず、改善案を提案する形で動作すると公式ドキュメントに説明されています。したがって`/init`はルールを自動決定するコマンドではなく、人が整えるための下書きを得る出発点と考えるのが適切です。

/init

下書きが作られたら、実際のプロジェクトに合わないコマンド、存在しないテスト、過度に一般的な指示が入っていないか確認します。この記事ではClaude Codeを実際には実行していないため、`/init`がどのような文を生成したかという例の応答を作り、実際の出力のようには示しません。

04家計簿例のCLAUDE.mdを35行に整理する

以下は、このシリーズの架空プロジェクトに必要なルールだけをまとめたCLAUDE.mdです。公式ドキュメントでは1ファイル200行未満が推奨されており、今回の例は35行に保っています。目標・データ・Pythonのルール・実行コマンド・期待結果・作業ルールを分け、人が読んでもすぐ理解できるようにします。

# Project: vibe-expenses

## Goal
- Read expenses.csv and summarize expense amounts.
- Keep the example small and understandable for beginners.

## Data
- Input file: expenses.csv
- Encoding: UTF-8
- Columns: date, category, amount
- date format: YYYY-MM-DD
- category values stay in English.
- amount is treated as an integer.

## Python rules
- Use only the Python standard library.
- Prefer csv for reading CSV files.
- Do not add third-party packages.
- Keep functions short and names descriptive.
- Do not modify expenses.csv.

## Commands
- Run: python summarize.py expenses.csv
- On Windows, py summarize.py expenses.csv is also acceptable.

## Expected result
- 2026-09 = 26600
- 2026-10 = 9800

## Working rules
- Explain the planned change before editing files.
- Change only files needed for the requested task.
- Do not invent extra input columns or business rules.
- If a requirement is unclear, ask before expanding scope.
- After editing, show what changed and how to verify it.

ここにはパスワード、APIキー、実際の顧客パスなどの秘密情報を入れません。プロジェクト指示ファイルは作業の文脈を伝えるためのものなので、公開または共有されても問題のないルールを中心に書く方が安全です。

05長い説明より確認できるルールを優先する

CLAUDE.mdは長いほどよいわけではありません。「コードを上手に書く」のように判定しにくい文より、「外部パッケージを追加しない」「expenses.csvを変更しない」「実行コマンドはこれ」といった、実際の変更結果と照合できるルールの方が有用です。必要であれば`@パス`構文で別ファイルの内容を取り込めますが、今回の小さな例では別ファイルを読み込む必要はありません。

• プロジェクトに実際に存在するファイル名とコマンドだけを書く。
• 1回だけ必要な作業指示を毎回CLAUDE.mdに積み重ねない。
• 禁止事項は、何をしてはいけないのか具体的に書く。
• 完了を判断できる期待値や確認コマンドを残す。
• 個人の秘密情報やAPIキーをプロジェクトルールファイルに入れない。

ルールを追加した後も、Claude Codeが実際にどのファイルを変更するかは別途確認する必要があります。CLAUDE.mdはレビューの代わりになる仕組みではなく、繰り返し説明する必要があるプロジェクトの文脈を減らす仕組みです。

06ルールファイルを作ったら、次の作業前に読み直す

CLAUDE.mdを保存したら、次の機能を依頼する前に人が一度ファイルを読みます。現在のコードや実行コマンドが変わっているのに古い指示が残っていると、かえって誤った文脈を与えることがあります。特に期待出力やファイル名が変わった場合は、ルールファイルもあわせて更新する必要があります。

次の記事では、このルールを維持したまま新機能をすぐ実装せず、planモードで先に設計します。目標は、`--by-category`オプションで2026-09のfood 20500, transport 2900, supplies 3200を出力する機能にどのような変更が必要かを、計画段階で確認することです。

自分で確認する項目

Claude Code公式ドキュメント（2026-09-22確認）とこのシリーズの架空例を基準に作成 · Claude Codeの実行なし · 本記事に実行対象のPythonコードなし

• プロジェクト`./CLAUDE.md`、個人全体`~/.claude/CLAUDE.md`、個人プロジェクト`./CLAUDE.local.md`の配置と用途が公式ドキュメントと一致するか確認
• `/init`がコードベースを分析して下書きを作り、既存のCLAUDE.mdを上書きせず改善を提案するという説明を公式ドキュメントと照合
• CLAUDE.mdを強制設定ではなくプロジェクトの文脈として説明しているか確認
• 例のCLAUDE.mdが35行で、公式ドキュメント推奨の1ファイル200行未満の範囲に入っているか確認
• 例のルールに実行コマンド・データ規則・禁止事項・期待結果・確認の流れが含まれているか確認
• 実際の`/init`実行結果やClaude Codeの応答を作り出したと表現していないか確認