CLAUDE.mdの書き方が分からない、何を書けばいいの？——Claude Codeを使い始めた人が最初にぶつかる壁です。
結論から言います。CLAUDE.mdには5行だけ書けば十分です。
「え、5行？」と思うかもしれません。しかし実際に200行のCLAUDE.mdを60行に削り、さらに最重要5行を明確にしたところ、Claudeのルール遵守率が目に見えて改善しました。この記事では、非エンジニアでも5分で書けるテンプレートから、上級者のベストプラクティスまで、実物のCLAUDE.mdのbefore/after付きで解説します。
CLAUDE.mdとは？
CLAUDE.mdは、Claude Codeがセッション開始時に自動で読み込む「指示書」です。プロジェクトのルートディレクトリに置くMarkdownファイルで、ここに書いた内容がClaudeの行動指針になります。
イメージとしては、新入社員に渡すオンボーディングメモです。「うちのプロジェクトではこういうルールだよ」とClaudeに毎回説明する手間を省けます。
CLAUDE.mdの場所、配置方法、agents.mdとの違いは「CLAUDE.mdとは？場所・作り方・使い方」で解説。公式ドキュメントでは「Memory」機能の一部として位置づけられている。
まず20行のテンプレートをコピペしてください
ベストプラクティスの前に、まずこれをコピペしてください。非エンジニアでも5分で完成します。
非エンジニア向けテンプレート（ブログ運営）
# プロジェクト概要
ペットフードの比較サイト。WordPressで運営。
# 絶対にやってはいけないこと
- 本番サーバーのファイルを直接編集しない（ローカルで確認してから）
- 画像のaltタグを空にしない（SEOに悪影響）
- sedでPHPファイルを編集しない（}が消えてPHP構文エラーになった実績あり）
- 「犬を持つ」と書かない（「犬を飼っている」が正しい日本語表現）
# 作業の進め方
- 1つの作業が終わったら必ず確認を求めること
- 迷ったら作業を止めて質問すること
- 大きな変更は事前に計画を見せること
# 言語
- 日本語で回答することこれは私が実際に使っているCLAUDE.mdをベースにしたテンプレートです。技術的な正確さは不要です。Claude Codeがpackage.jsonやディレクトリ構造を見て技術スタックは自動で把握します。あなたが書くべきは「Claudeがコードを見ても分からないこと」だけです。
非エンジニア向けテンプレート（データ分析）
# プロジェクト概要
売上データの分析と月次レポート作成。CSV/Excelファイルが中心。
# ルール
- 元データファイルを上書きしない（必ずコピーを作ってから加工）
- 集計結果にはデータの出典と期間を必ず記載すること
- グラフは日本語ラベルで作成すること
# 出力先
- 加工後のファイルは /output/ ディレクトリに保存エンジニア向けおすすめテンプレート（40行版）
# プロジェクト概要
Next.js 14 + TypeScript + Prisma のSaaSアプリ。
# 技術的なルール（WHY付き）
- Pages Routerを使う。App Routerに変更しない
理由: SEO上の要件。既存全ページがPagesRouterで実装済み
- sedでファイルを編集しない
理由: }が消えて構文エラーになった実績あり。Pythonで行単位編集すること
- テストはvitest。jestを使わない
理由: 既存テストが全てvitest。混在させると設定が競合する
- コミットメッセージはConventional Commits形式（feat:, fix:, docs:等）
# 禁止事項
- node_modulesを直接編集しない
- .envファイルをコンテキストに含めない
- 既存APIの破壊的変更をしない（後方互換性を維持）
# コマンド
- テスト: pnpm test
- lint: pnpm lint
- ビルド: pnpm build
- デプロイ: vercel --prod
# 自己改善プロトコル
- Claudeが間違いを犯した場合、再発防止ルールをこのファイルに追加する
- 追加時は「理由」を必ず添えること（WHYなしのルールは禁止）テンプレートをもっと見たい方は「CLAUDE.mdテンプレート集｜用途別7パターン」を参照。
非エンジニアが最初に書くべき3行
プログラミング知識がなくても、最低限この3行を書いておくだけでClaude Codeの出力品質が変わる:
# 最低限の3行（非エンジニア向け）
1. 日本語で回答すること
2. 元のファイルを壊さないこと（バックアップを取ってから作業）
3. 大きな変更をする前に確認を求めることこの3行があるだけで、Claude Codeが(1)英語で回答する、(2)ファイルを壊す、(3)勝手に大改修する、という3大トラブルを防げる。技術的な正確さは不要。「自分が心配していること」を素直に日本語で書けばよい。→「非エンジニア活用術」
書くべきこと / 書くべきでないこと
| 書くべきこと | 書くべきでないこと |
|---|---|
| プロジェクト固有のルール（「sedでPHP編集禁止」） | package.jsonの内容（Claudeが直接読む） |
| チームの規約（コミットメッセージ形式等） | 一般的なプログラミング常識 |
| 過去に起きた事故の再発防止ルール | ファイル一覧やディレクトリ構成（Claudeが自動把握） |
| 使用する言語（「日本語で回答」） | 「丁寧に」「慎重に」等の曖昧な指示 |
| 禁止事項とその理由（WHY） | 10行以上のコード例（skills/rulesに分離） |
判断基準: 「この行を消したら、Claudeが間違いを犯すか？」→ Noなら削除。コードから分かる情報を転記するのはトークンの無駄遣い。Claudeはpackage.jsonやディレクトリ構造を直接読んで技術スタックを把握できる。
CLAUDE.mdの書き方｜5つのベストプラクティス
テンプレートをコピペしたら、以下のルールに沿って自分のプロジェクトに合わせて調整する。Anthropic公式のベストプラクティスでもこれらの原則が推奨されている。
1. 「5行ルール」— 最重要ルールを5行に絞る
これが当サイト独自の主張。CLAUDE.mdに何十行もルールを書いても、Claudeは全てを同じ重要度で扱う。結果として本当に重要なルールが他のルールに埋もれ、遵守されにくくなる。本当に守ってほしいルールを5行以内に絞り、ファイルの冒頭に置くのが最も効果的。
5行に入れるべきものの選定基準: 「これを破った時のダメージが最大のもの」を優先する。「日本語で回答」は低ダメージだが、「sedでPHP編集禁止」はファイル破壊につながるため高ダメージ。高ダメージのルールほど冒頭に配置する。
私のCLAUDE.mdの冒頭5行はこれです：
# 最重要ルール（この5つは絶対に守ること）
1. sedでPHPを編集しない（Pythonで行単位編集）
2. WordPressはstyleタグを自動除去する（外部ファイル化が必須）
3. 複数サイトを運営する場合、サイトを混同しない
4. 1つの作業が終わったら確認を求める
5. 日本語で回答するこの5行は全て過去に実際にClaudeが間違えたことから生まれたルールです。推測でルールを書くのではなく、失敗から学んだことだけを書く。これが最も効果的な書き方です。
2. 60行以内に収める
公式推奨は200行以内だが、実務では60行前後が最適。CLAUDE.mdはセッション開始時にClaudeのコンテキストに注入される。長いCLAUDE.mdは毎セッションで大量のトークンを消費し、Proプランのトークン制限を早く消費する原因にもなる。60行は「ルールの網羅性」と「トークン効率」のバランスが最も良いライン。
wc -l CLAUDE.md # 200以下なら安全、60以下が理想60行を超えたら、詳細ルールは.claude/rules/やSkillsに分割してください。分割方法は「CLAUDE.md肥大化対策ガイド」で解説しています。
3. WHYを書く（WHATだけ書かない）
「何をするか」だけでなく「なぜそうするか」を書くのが2番目に重要なポイントです。Claudeは理由を理解すると、ルールに書いていない未知の状況でも適切に判断できるようになります。
# 悪い例（WHATだけ）
- TypeScriptのstrictモードを使うこと
# 良い例（WHY付き）
- TypeScriptはstrictモード必須
理由: 既存コードが全てstrict前提。offにするとanyが混入して型安全性が崩壊する4. 禁止形（〜しない）で書く
Claudeは「推奨」より「禁止」の方が遵守率が高いという報告が多い。やってほしくないことは「〜しない」で明確に書く。特にデータ破壊につながる操作（ファイル削除、DB変更、本番環境操作等）は必ず禁止形で書く。推奨形（「〜すること」）は優先度が低いルールに使う。
# 効果が低い
- Pythonで行単位の編集を使ってください
# 効果が高い
- sedでPHPファイルを編集しない（}が消えてPHP構文エラーになる）5. 日本語で書いてOK
公式ドキュメントでも言語の制限はなく、日本語でも英語でも遵守率に差はないとされている。チーム内の共通言語で書くのが最も効率的。日本語プロジェクトなら日本語で全く問題ない。
私のCLAUDE.md Before/After（実物公開）
Before（200行超 → ルール無視が頻発）
以前の私のCLAUDE.mdは200行を超えていた。プロジェクト概要、15変数の回帰モデル仕様、全禁止事項、コマンド集、デプロイ手順——全てを1ファイルに詰め込んでいた。
| 指標 | Before（200行超） | After（60行） |
|---|---|---|
| CLAUDE.md行数 | 200行以上 | 60行 |
| sedによるPHP破壊事故 | 月2〜3回 | 0回 |
| /clearの頻度 | 1日5〜6回 | 1日3回 |
| ルール無視の発生 | 頻繁（特にセッション後半） | ほぼなし |
| セッション開始時のトークン消費 | 大（CLAUDE.md全文ロード） | 小（60行のみ） |
結果：Claudeが禁止事項を無視する頻度が増加。特に「sedでPHPを編集しない」ルールを無視してファイルが壊れる事故が複数回発生しました。
After（60行 → 遵守率改善）
移動したもの：
- 回帰モデル仕様 →
.claude/skills/keiba-predict.mdに移動 - コマンド集 →
.claude/rules/server-commands.mdに移動 - デプロイ手順 →
.claude/rules/deploy.mdに移動 - コードから分かる情報 → 全削除
残したもの：
- 最重要5行ルール（冒頭）
- プロジェクト概要（3行）
- 自己改善プロトコル（5行）
変化の実感：
- sedによるPHP破壊事故が0件に（以前は月2〜3回発生）
- /clearの頻度が減った（コンテキスト圧迫が軽減）
- セッション後半でもルールが守られるようになった
自己改善プロトコルを組み込む
CLAUDE.mdを「育てる」最も効果的な仕組みが自己改善プロトコル。Claude Codeが間違いを犯した時、再発防止ルールをCLAUDE.mdに自動追加させる仕組み。
# 自己改善プロトコル（CLAUDE.mdの末尾に追加）
## セッション中のミス対応
- Claude Codeが間違いを犯した場合、再発防止ルールをこのファイルに追加すること
- 追加時は「理由」を必ず添えること（WHYなしのルールは禁止）
- 同じミスを2回繰り返さないことが最優先
## 例
- ❌ 追加: 「altタグを空にしない」（WHYがない）
- ✅ 追加: 「altタグを空にしない（SEOに悪影響。Googleの品質監査で指摘された実績あり）」このプロトコルがあると、使えば使うほどCLAUDE.mdが成長し、Claude Codeのミスが減っていく。Anthropicのベストプラクティスでも「CLAUDE.mdを育てる」ことが推奨されている。
.cursorrules / copilot-instructions.md との使い分け
CursorやGitHub Copilotにも同様の指示ファイルがある:
| ファイル | 対応ツール | 場所 |
|---|---|---|
| CLAUDE.md | Claude Code | プロジェクトルート |
| .cursorrules | Cursor | プロジェクトルート |
| .github/copilot-instructions.md | GitHub Copilot | .github/ディレクトリ |
内容は共通化できる。CLAUDE.mdの内容を.cursorrulesにもコピーしておけば、ツール間で一貫したコーディング規約を維持できる。ただし各ツール固有の機能（Claude Codeの/init、Cursorの@記法等）に関するルールは個別に書く必要がある。
段階的開示（Progressive Disclosure）の設計
CLAUDE.mdが大きくなったら段階的開示の設計に移行する。全ルールをCLAUDE.md本体に詰め込むのではなく、必要な時に必要なルールだけをClaudeに渡す設計。
| レイヤー | 場所 | ロードタイミング | 書く内容 |
|---|---|---|---|
| 常時ロード | CLAUDE.md本体 | 毎セッション開始時 | 最重要5行+プロジェクト概要（20〜60行） |
| 条件付きロード | .claude/rules/*.md | 該当ファイル操作時 | PHPルール、テストルール、Git操作ルール等 |
| 呼び出し時のみ | .claude/commands/*.md（Skills） | /スラッシュコマンド実行時 | SEO分析手順、デプロイ手順、レビュー手順等 |
この設計により、セッション開始時のトークン消費を最小限に抑えつつ、必要な場面では詳細なルールを適用できる。CLAUDE.md本体が20行でも、rules/とcommands/を合わせれば数百行のルールを管理できる。
# 段階的開示のディレクトリ構成例
~/my-project/
├── CLAUDE.md # 最重要5行+概要（常時ロード、20行）
└── .claude/
├── rules/
│ ├── php-safety.md # PHP操作時のみ（globs: "**/*.php"）
│ ├── testing.md # テスト時のみ（globs: "**/*.test.*"）
│ └── git-commit.md # commit時のみ
└── commands/
├── seo-audit.md # /seo-audit で呼び出し
└── deploy.md # /deploy で呼び出しCLAUDE.mdの効果を測る方法
「CLAUDE.mdを書いて本当に効果があるのか？」を定量的に測る方法:
| 指標 | 測り方 | 改善の目安 |
|---|---|---|
| ルール違反回数 | 1週間のセッションで禁止事項を破った回数をカウント | 週3回→0回 |
| 手戻り回数 | 「やり直して」「それは違う」と指示した回数 | 50%減 |
| /clear回数 | コンテキストが汚れてリセットした回数 | 減少=CLAUDE.mdが軽量で効果的 |
| セッション時間 | 同じタスクを完了するまでの時間 | 短縮=ルールが効いている |
私の場合、Before/Afterで最も劇的に改善したのは「sedによるPHP破壊事故」で、月2〜3回→0回に完全に解消された。この1つのルールだけで月10時間以上の手戻り時間を節約できた。
効果が分かりにくい場合のチェック方法: 1週間CLAUDE.mdなしで作業し、翌週CLAUDE.mdありで作業して比較する。特に「やり直して」「それは違う」と言った回数を比較すると、CLAUDE.mdの効果が数値で見える。多くの場合、CLAUDE.mdありの方が50%以上手戻りが減る。
もう1つの確認方法として、Claude Codeに直接聞く:
# CLAUDE.mdのルールが認識されているか確認
> CLAUDE.mdの最重要5行を教えて
# 特定ルールの認識確認
> 「sedでPHP編集禁止」というルールを覚えてる？
> なぜそのルールがあるか理由を説明してClaudeが理由まで正しく説明できれば、そのルールは確実に認識されている。
よくある質問
Q: agents.mdとの違いは？
CLAUDE.mdは「プロジェクト全体のルール」で毎セッション読み込まれる。agents.mdは「特定エージェントタスクの指示書」でサブエージェント起動時のみ読み込まれる。memory.mdはClaude Codeが自動で書く学習メモで、人間は基本的に編集しない。3ファイルの詳細比較は→「CLAUDE.md vs agents.md vs memory.md」
Q: Git管理すべき？
はい。.claude/settings.local.jsonだけ.gitignoreに追加してください。
Q: CLAUDE.mdが無視される・反映されないときは？
200行を超えていないか確認。超えている場合は60行以内に削り、残りをrules/skillsに分割する。→「CLAUDE.md肥大化対策」
Q: /initで自動生成と手動作成、どっちがいい？
/initで自動生成したものをベースに、手動で「禁止事項」「最重要5行」を追加するのがベスト。/initだけだと禁止事項が入らないため、プロジェクト固有の注意点は必ず手動で追記する。
Q: チームでCLAUDE.mdを管理するコツは？
CLAUDE.mdの変更はPRベースでレビューする。「なぜこのルールを追加したか」をコミットメッセージに書く。個人設定はCLAUDE.local.md（.gitignoreに追加）に書き、チーム共有のCLAUDE.mdを個人設定で汚さない。→「CLAUDE.mdとは」のチーム運用セクション
まとめ｜CLAUDE.mdの書き方は「5行ルール」から始めよ
CLAUDE.mdの書き方で最も大事なのは「5行ルール」——本当に守ってほしいルールを5行に絞り、ファイルの冒頭に置くこと。
| ステップ | やること | 所要時間 |
|---|---|---|
| 1 | テンプレートをコピペ（上記参照） | 1分 |
| 2 | プロジェクト名と概要を書き換え | 2分 |
| 3 | 自分のプロジェクトの「絶対にやってはいけないこと」を3〜5行追加 | 5分 |
| 4 | Claude Codeで使い始める。ミスがあったらルール追加 | 随時 |
| 5 | 60行を超えたら.claude/rules/に分離 | 10分 |
完璧を目指す必要はない。使いながら失敗から学んで育てるのがCLAUDE.mdの正しい付き合い方。推測でルールを書くのではなく、実際にClaude Codeが間違えた時だけルールを追加する。この「実際の失敗→ルール追加→再発防止」のサイクルが回り始めると、1ヶ月後にはあなたのプロジェクトに完全に最適化されたCLAUDE.mdが出来上がる。
Claude Code全体の使い方は「使い方ガイド」、CLAUDE.mdの基礎は「CLAUDE.mdとは」、テンプレート集は「テンプレート7パターン」、肥大化対策は「肥大化防止ガイド」、agents.mdとの違いは「agents.md比較」、コマンド一覧は「コマンド早見表」を参照。
参考文献・公式リソース
- Claude Code Memory（CLAUDE.md）公式ドキュメント
- Claude Code ベストプラクティス（Anthropic Engineering Blog）
- 効果的なCLAUDE.mdの書き方（Zenn）
- Claude Code 公式ドキュメント
- Claude Code セキュリティポリシー
