CLAUDE.mdのテンプレートがほしい——この記事ではコピペで使える7パターンを用途別に公開する。全て実際のプロジェクトで使った実績のあるテンプレートを、Anthropic公式のベストプラクティスに沿って設計してある。
テンプレートの選び方: 自分のプロジェクトに近いものを選んでコピペ→プロジェクト名と固有ルールを書き換え→使いながら失敗からルールを追加。完璧に書く必要はない。5行から始めて育てるのが正解。→「CLAUDE.md書き方ガイド」
テンプレート①｜ブログ運営（WordPress）
WordPressサイトを運営する人向け。非エンジニアでもそのまま使える。設計の意図: ルール1（本番直接編集禁止）はファイル破壊防止、ルール2（alt空禁止）はSEO、ルール3（sed禁止）は私が実際にPHPを壊した事故から追加した必須ルール。SSH情報を書いておくとClaude Codeがリモートサーバーに直接接続して作業できる。
# プロジェクト概要
WordPressで運営するブログサイト。
# 最重要ルール
1. 本番サーバーのファイルを直接編集しない（ローカルで確認してから）
2. 画像のaltタグを空にしない（SEOに悪影響）
3. sedでPHPファイルを編集しない（}が消える事故実績あり）
4. 1つの作業が終わったら確認を求めること
5. 日本語で回答すること
# サーバー情報
- SSH: ssh -i ~/.ssh/key -p 10022 user@server
- WP-CLI: php8.1 /usr/bin/wp --path=/path/to/public_htmlテンプレート②｜Webアプリ開発（Next.js）
# プロジェクト概要
Next.js 14 + TypeScript + Prisma のSaaSアプリ。
# 最重要ルール
1. Pages Routerを使う（App Routerに変更しない。SEO上の要件）
2. sedでファイルを編集しない（Pythonで行単位編集）
3. テストはvitest（jestを使わない。設定が競合する）
4. コミットメッセージはConventional Commits形式
5. .envファイルを読まない
# コマンド
- テスト: pnpm test
- lint: pnpm lint
- ビルド: pnpm build
- デプロイ: vercel --prodテンプレート②の設計意図
なぜPages Routerを明記するか: Next.jsにはApp Router（新方式）とPages Router（旧方式）の2つがあり、Claude Codeは最新のApp Routerを提案しがち。既存プロジェクトがPages Routerで構築されている場合、「App Routerに変更しない」と明記しないとルーティングが壊れる。なぜConventional Commitsか: コミットメッセージを統一することで、後からの変更追跡とCHANGELOG自動生成が可能になる。Claude Codeはこの形式でメッセージを自動生成する。
テンプレート③｜データ分析
# プロジェクト概要
売上データの分析と月次レポート作成。
# ルール
1. 元データファイルを上書きしない（必ずコピーを作ってから加工）
2. 集計結果にはデータの出典と期間を記載
3. グラフは日本語ラベルで作成
4. 出力はoutput/ディレクトリに保存
5. 日本語で回答テンプレート③の設計意図
なぜ「元データを上書きしない」が最重要か: データ分析で最も致命的なミスは元データの破壊。Claude Codeにデータ加工を指示すると、デフォルトでは元ファイルを上書きしようとすることがある。「コピーを作ってから加工」を明記することで、この事故を100%防げる。非エンジニアが最初に使うテンプレートとしても安全性が高い。出力先ディレクトリを指定しておくと、加工結果が散らばらずに管理しやすい。
テンプレート④｜Python開発
# プロジェクト概要
Python 3.12 + FastAPI のAPIサーバー。
# ルール
1. 型ヒントを必ず使う
2. テストはpytest（unittestを使わない）
3. フォーマットはruff format
4. docstringはGoogle形式
5. 環境変数は.envから読む（python-dotenv使用）
# コマンド
- テスト: pytest
- lint: ruff check .
- 起動: uvicorn main:app --reloadテンプレート⑤｜Reactフロントエンド
# プロジェクト概要
React 19 + TypeScript + Vite のSPA。
# ルール
1. コンポーネントは関数コンポーネントのみ（classコンポーネント禁止）
2. 状態管理はZustand（Redux/Recoilは使わない）
3. スタイリングはTailwind CSS
4. テストはVitest + Testing Library
5. import文は絶対パス（@/components/等）を使用
# コマンド
- dev: pnpm dev
- test: pnpm test
- build: pnpm buildテンプレート④⑤の設計ポイント
Python（④）: 型ヒント必須はPython 3.12時代のベストプラクティス。Claude Codeはデフォルトで型ヒントなしのコードを書くことがあるため、明記が必要。pytest vs unittestも同様で、プロジェクトのテストフレームワークを統一するために明記する。ruffは2026年のPython linter/formatterの主流で、blackやflake8を置き換えている。
React（⑤）: 「classコンポーネント禁止」は2026年では当然だが、Claude Codeが古い学習データに基づいてclass構文を使う場合があるため明記。状態管理ライブラリ（Zustand/Redux/Recoil等）はClaude Codeが推測できないため、CLAUDE.mdに書くのが必須。書かないと毎回「どの状態管理を使いますか？」と聞かれるか、勝手にReduxを選ばれる。
テンプレート⑥｜モバイルアプリ（Flutter）
# プロジェクト概要
Flutter + Dart のクロスプラットフォームアプリ。
# ルール
1. 状態管理はRiverpod
2. テストはflutter_test
3. ディレクトリ構成はfeature-first
4. APIクライアントはdio
5. ローカライゼーションはflutter_localizations
# コマンド
- 実行: flutter run
- テスト: flutter test
- ビルド: flutter build apkテンプレート⑦｜インフラ・DevOps
# プロジェクト概要
AWS CDK + TypeScript のインフラ管理。
# ルール
1. 本番環境のリソースを直接削除しない（まずdev環境でテスト）
2. CDKのスタック名は環境名をプレフィックスにする（dev-/stg-/prd-）
3. セキュリティグループは最小権限の原則
4. シークレットはSSM Parameter Store or Secrets Manager
5. 変更前にcdk diffで確認
# コマンド
- デプロイ: cdk deploy --all
- 差分確認: cdk diff
- テスト: npm testテンプレート⑥⑦の設計ポイント
Flutter（⑥）: Riverpodは2026年のFlutter状態管理のデファクト。Claude CodeはProvider（旧世代）を提案することがあるため明記が必要。feature-firstディレクトリ構成は大規模アプリで可読性を維持するための設計方針で、「lib/features/auth/」「lib/features/payment/」のように機能ごとにディレクトリを分ける。
DevOps（⑦）: 最も慎重さが求められるテンプレート。「本番環境のリソースを直接削除しない」は最重要ルール。Claude Codeに「このリソースを削除して」と指示すると、確認なしにプロダクションリソースを消す可能性がある。環境名プレフィックス（dev-/stg-/prd-）でスタック名を統一することで、開発環境と本番環境を取り違えるリスクを減らす。cdk diffで変更前確認を必須にするルールは、IaC運用の基本中の基本。
テンプレート⑧｜自己改善プロトコル（全テンプレート共通で追加推奨）
どのテンプレートにも末尾に追加すべき「自己改善プロトコル」。Claude Codeが間違いを犯した時、自動でルールを追記させる仕組み:
# 自己改善プロトコル（CLAUDE.mdの末尾に追加）
## ミス対応
- Claude Codeが間違いを犯した場合、再発防止ルールをこのファイルに追加する
- 追加時は「理由」を必ず添える（WHYなしのルールは禁止）
- 同じミスを2回繰り返さないことが最優先
## 記録フォーマット
- [日付] ルール内容（理由: WHY）このプロトコルがあると、使えば使うほどCLAUDE.mdが成長し、Claude Codeのミスが減っていく。公式ドキュメントでもMemory機能の活用として推奨されている。
テンプレート比較表｜どれを選ぶ？
| # | テンプレート | 対象 | 行数 | 難易度 |
|---|---|---|---|---|
| ① | ブログ運営 | 非エンジニア | 15行 | 簡単 |
| ② | Webアプリ（Next.js） | フロントエンド | 20行 | 普通 |
| ③ | データ分析 | 非エンジニア | 10行 | 簡単 |
| ④ | Python開発 | バックエンド | 18行 | 普通 |
| ⑤ | React | フロントエンド | 18行 | 普通 |
| ⑥ | Flutter | モバイル | 15行 | 普通 |
| ⑦ | インフラ・DevOps | SRE/インフラ | 18行 | やや難 |
非エンジニアなら①か③、Webエンジニアなら②か⑤、バックエンドなら④が最も使いやすい。
選び方の詳細判断基準
| あなたの状況 | おすすめ | 理由 |
|---|---|---|
| プログラミング未経験 | ①ブログ or ③データ分析 | 技術用語が少なく、日本語指示だけで使える |
| フロントエンド開発 | ②Next.js or ⑤React | コンポーネント設計・テスト方針が明確 |
| バックエンド開発 | ④Python | API設計・テスト・型ヒントのルール |
| モバイルアプリ開発 | ⑥Flutter | Riverpod・feature-first構成 |
| インフラ・SRE | ⑦DevOps | 安全なデプロイ・最小権限の原則 |
| どれにも当てはまらない | ①ブログの「最重要ルール」だけコピペ | 5行ルールは全プロジェクト共通で使える |
テンプレートの使い方
- 上のテンプレートから自分の用途に近いものを選ぶ
- プロジェクトのルートに
CLAUDE.mdとして保存 - 中身を自分のプロジェクトに合わせて書き換える
- 使いながら「Claudeが間違えたこと」をルールとして追加していく
完璧に書く必要はない。まず5行だけ書いて使い始め、失敗から学んでルールを追加していくのが最も効率的。→「書き方ガイド」の5行ルール参照。
テンプレートの成長例｜1ヶ月目→3ヶ月目
テンプレートは使い始めてから「育つ」もの。ブログ運営テンプレート①の1ヶ月目→3ヶ月目の実例:
| 時期 | CLAUDE.mdの変化 | 追加されたルール |
|---|---|---|
| Day 1 | テンプレート①をコピペ（15行） | — |
| Week 1 | +2行（18行） | 「記事内でなかむら先生の名前を出さない（『獣医師』と表記）」 |
| Week 2 | +3行（21行） | 「wp_insert_postでscriptタグ追加禁止（wp_kses_postで除去される）」 |
| Month 1 | +5行（26行） | 「外部CSSはenqueue方式で読み込む」「JSONLDは外部ファイル化」 |
| Month 2 | +4行（30行） | 「相対パス禁止（mod_pagespeedでCSS崩壊した実例）」 |
| Month 3 | 棚卸しで-5行（25行） | 不要になったルール2つを削除。残りを整理 |
全てのルールが「実際の失敗」から生まれている。推測でルールを書くと肥大化の原因になる。失敗した時だけ追加し、3ヶ月ごとに棚卸しして不要なルールを削除する。このサイクルが最も効率的なCLAUDE.mdの育て方。
/initとテンプレートの組み合わせ
最強の始め方は/initで自動生成→テンプレートの「最重要ルール5行」を冒頭に手動追加:
# Step 1: /initで自動生成
cd ~/my-project && claude
/init
# → プロジェクト構造を自動分析してCLAUDE.mdを生成
# Step 2: テンプレートの最重要5行を冒頭に追加
# CLAUDE.mdの先頭に以下を手動追加:
# 1. [プロジェクト固有の最大リスク]を禁止
# 2. [過去の事故から学んだルール]
# 3. [チーム固有の規約]
# 4. 1作業完了ごとに確認を求める
# 5. 日本語で回答する/initだけだとプロジェクト概要と技術スタックは入るが、「禁止事項」は入らない。禁止事項は過去の失敗から人間が手動で追加する必要がある。テンプレートのルール部分はこの「禁止事項の雛形」として活用する。
テンプレートを使った効果
テンプレートを使う前と後で、Claude Codeの出力品質がどう変わるか:
| 場面 | テンプレートなし | テンプレートあり |
|---|---|---|
| テストフレームワーク | 毎回「jestとvitestどっち？」と聞かれる | vitestで自動生成 |
| コミットメッセージ | 英語で一般的なフォーマット | 日本語でConventional Commits |
| PHP編集 | sedで編集→}が消えてエラー | Pythonで行単位編集（事故0件） |
| ファイル操作 | 確認なしに変更を実行 | 1作業ごとに確認を求める |
| データ加工 | 元ファイルを上書きする場合がある | コピーを作ってから加工 |
テンプレートを使うだけで、Claude Codeの「事故率」が劇的に下がる。特に禁止事項（「sedでPHP編集しない」「元ファイルを上書きしない」）の効果が大きい。テンプレートをコピペする3分の投資で、月に何時間もの手戻り時間を節約できる。
テンプレートに共通する5つの原則
- 60行以内 — 超えたらrules/やSkillsに分割
- WHYを書く — 「なぜそうするか」を添える
- 禁止形で書く — 「〜しない」の方が遵守率が高い
- 最重要5行を冒頭に — Claudeは冒頭を重視する
- 日本語でOK — 遵守率に差はない
これらの原則の詳細は「書き方ガイド」で解説。
チームでテンプレートを使う場合
チームでClaude Codeを導入する場合、CLAUDE.mdテンプレートをチーム標準として共有する方法:
- テンプレートをGitリポジトリに含める: CLAUDE.mdをプロジェクトルートに配置し、Git管理。全メンバーが同じルールで作業できる
- 変更はPRベースで: CLAUDE.mdの修正はPRを出してチームレビュー。「なぜこのルールを追加したか」をコミットメッセージに記録
- 個人設定はCLAUDE.local.mdに: メンバー個人の好み（「日本語で回答」等）はCLAUDE.local.mdに書き、.gitignoreに追加
- 新メンバーのオンボーディング: 「まずCLAUDE.mdを読んでからClaude Codeを使い始めて」とルール化
CLAUDE.mdがチームの「コーディング規約+AI運用ルール」を兼ねるため、新メンバーのオンボーディングコストが大幅に下がる。agents.mdとの使い分けは「agents.md比較ガイド」を参照。
肥大化対策は「肥大化防止ガイド」、CLAUDE.mdの基礎は「CLAUDE.mdとは？」、Skillsは「Skills完全ガイド」、使い方は「使い方ガイド」、コマンドは「コマンド早見表」を参照。
まとめ｜テンプレートをコピペして、使いながら育てる
8つのテンプレートから自分に合うものを選んでコピペするだけ。最初から完璧を目指す必要はない。使いながら失敗からルールを追加し、3ヶ月ごとに棚卸しする。これがCLAUDE.mdの正しい付き合い方。
よくある質問
Q: テンプレートをそのまま使って大丈夫？
大丈夫。ただしプロジェクト概要とサーバー情報は自分のものに書き換えること。ルール部分はそのまま使える汎用的な内容にしてある。使い始めてClaude Codeが間違えた時に、プロジェクト固有のルールを追加していく。「最初から完璧に書こう」とするのは間違い。テンプレートをコピペして、使いながら育てるのが正しいアプローチ。3ヶ月後には自分のプロジェクトに完全に最適化されたCLAUDE.mdが出来上がっている。
Q: テンプレートを複数組み合わせていい？
良い。例えばフロントエンド（⑤React）とバックエンド（④Python）を組み合わせて、フルスタックプロジェクトのCLAUDE.mdを作れる。ただし合計60行以内に収めること。超える場合は.claude/rules/に分離する。モノレポの場合はルートに共通ルール、サブディレクトリに固有ルールを配置する設計も有効。→「agents.md比較ガイド」のモノレポセクション
Q: /initで自動生成したものとテンプレート、どっちがいい？
/initで自動生成→このテンプレートの「最重要ルール5行」を冒頭に手動追加、が最強の組み合わせ。/initはプロジェクト構造を自動認識するが、禁止事項は入らないため、手動でルールを追加する必要がある。
Q: 英語で書いた方がいい？
日本語で問題ない。公式ドキュメントでも言語制限はなく、日本語でもClaudeの遵守率に差はない。チーム内の共通言語で書くのが最も効率的。
Q: テンプレートをGit管理すべき？
CLAUDE.md本体はGit管理してチーム共有する。ただしCLAUDE.local.md（個人設定）と.claude/settings.local.json（APIキー等）は.gitignoreに追加すること。→「CLAUDE.mdとは？」のGit管理セクション
カスタマイズのコツ
テンプレートをコピペした後のカスタマイズのポイント:
| カスタマイズ項目 | やり方 | 注意点 |
|---|---|---|
| プロジェクト概要 | 自分のプロジェクト名・技術スタックに書き換え | 1-3行で簡潔に |
| 最重要ルール5行 | 実際にClaude Codeが間違えたことを追加 | 「推測」でなく「実績」に基づいて |
| コマンド情報 | テスト・lint・ビルド・デプロイのコマンドを追加 | Claude Codeがpackage.jsonから読めるものは省略可 |
| サーバー情報 | SSH接続先やDB接続情報を追加 | パスワードは書かない（APIキーも） |
| 自己改善プロトコル | テンプレート⑧を末尾に追加 | 全テンプレートに共通で追加推奨 |
