【コピペOK】実務で使っている CLAUDE.md テンプレート7選──用途別にそのまま使えます

CLAUDE.md を**「プロジェクト概要を書くファイル」**だと思っていた頃、Claude Code の出力品質は安定しませんでした。

ある日、CLAUDE.md にコーディング規約・禁止事項・出力フォーマットまで詰め込んだところ、同じプロンプトでも出力精度が明らかに変わったのです。この記事では、私が実務プロジェクトで使い回している CLAUDE.md テンプレート 7 選を、用途別にそのまま貼れる形で紹介します。

---

1. CLAUDE.md が出力品質を左右する理由

Claude Code はタスク実行前に CLAUDE.md を「システムプロンプト的コンテキスト」として読み込みます。つまり、ここに何を書くかで Claude の振る舞いが根本的に変わります。

Before / After の実例

	Before（概要だけ記載）	After（テンプレート適用後）
指示	「ユーザー一覧 API を作って」	同じ
出力	Express + JavaScript / any 多用 / エラーハンドリングなし	Next.js Route Handlers + TypeScript 厳密型 / Zod バリデーション付き / エラーレスポンス統一
手戻り	3 回以上の修正依頼	ほぼ 0 回

CLAUDE.md に書くべき要素とその関係を図にすると、次のようになります。

ポイント: 上流（プロジェクト概要）から下流（タスク固有の指示）へ情報が絞り込まれるほど、Claude の出力ブレが減ります。

---

2. テンプレート①：Web アプリ開発（Next.js + TypeScript）

最も汎用的なテンプレートです。フロントエンド〜BFF まで幅広く対応します。

# CLAUDE.md

## プロジェクト概要
- プロダクト名: {{PRODUCT_NAME}}
- 概要: {{一文で説明}}
- リポジトリ構成: モノレポ（Turborepo）

## 技術スタック
- Framework: Next.js 15 (App Router)
- Language: TypeScript 5.x（strict: true）
- Styling: Tailwind CSS v4
- State: Zustand
- DB: PostgreSQL + Prisma ORM
- Auth: NextAuth.js v5
- Test: Vitest + Testing Library
- Linter/Formatter: Biome

## コーディング規約
- 関数コンポーネントのみ使用（class コンポーネント禁止）
- named export を優先（default export は page.tsx / layout.tsx のみ）
- 型定義は `types/` ディレクトリに集約し、`interface` を優先
- API レスポンスは `ApiResponse<T>` 型で統一
- エラーハンドリングは `Result<T, E>` パターンを使用
- コメントは日本語で書く

## 禁止事項
- `any` 型の使用（`unknown` + 型ガードで代替）
- `console.log` でのデバッグ出力（logger ユーティリティを使用）
- `useEffect` 内でのデータフェッチ（Server Components or SWR/TanStack Query）
- インラインスタイル
- `var` 宣言

## 出力フォーマット
- ファイル単位でコードブロックを分ける
- ファイルパスをコードブロック冒頭にコメントで明記
- 変更理由を 1-2 行で添える

## ディレクトリ構造
```
src/
├── app/          # App Router pages
├── components/   # UI コンポーネント（Atomic Design は不採用）
│   ├── ui/       # 汎用 UI（Button, Modal 等）
│   └── features/ # 機能単位のコンポーネント
├── lib/          # ユーティリティ・ヘルパー
├── types/        # 型定義
├── hooks/        # カスタムフック
└── server/       # Server Actions, DB クエリ
```

---

3. テンプレート②：API 設計・実装（REST / GraphQL）

API の設計思想まで書いておくと、エンドポイントの命名やレスポンス形式が揃います。

# CLAUDE.md

## プロジェクト概要
- サービス名: {{SERVICE_NAME}}
- API 方式: REST（OpenAPI 3.1 準拠）
- ベース URL: `/api/v1`

## 技術スタック
- Runtime: Node.js 22 LTS
- Framework: Hono
- Language: TypeScript（strict: true）
- Validation: Zod
- ORM: Drizzle ORM
- DB: PostgreSQL 16
- Docs: OpenAPI (Scalar UI)
- Test: Vitest

## API 設計規約
- リソース名は複数形・ケバブケース（例: `/user-profiles`）
- レスポンス envelope:
  ```json
  {
    "success": true,
    "data": {},
    "meta": { "timestamp": "ISO8601" }
  }
  ```
- エラーレスポンス:
  ```json
  {
    "success": false,
    "error": {
      "code": "VALIDATION_ERROR",
      "message": "human-readable message",
      "details": []
    }
  }
  ```
- ステータスコード: 200/201/204/400/401/403/404/409/422/500 のみ使用
- ページネーション: cursor-based（offset 禁止）
- 認証: Bearer トークン（JWT）を Authorization ヘッダーに付与

## 禁止事項
- SQL 直書き（Drizzle のクエリビルダーを使用）
- レスポンスに DB カラム名をそのまま露出（DTO に変換）
- N+1 クエリ
- `try-catch` の握りつぶし

## 出力フォーマット
- 新しいエンドポイントを実装する際は、ルート定義 → バリデーション → ハンドラ → テスト の順に出力
- Zod スキーマから型を自動推論（`z.infer<typeof schema>` を使用）

---

4. テンプレート③：インフラ構築（Terraform / AWS CDK）

インフラコードこそ CLAUDE.md の効果が大きい領域です。命名規則やセキュリティポリシーを明記しておくと、レビュー指摘が激減します。

# CLAUDE.md

## プロジェクト概要
- プロジェクト: {{PROJECT_NAME}}
- IaC ツール: Terraform 1.9+
- クラウド: AWS（東京リージョン: ap-northeast-1）
- 環境: dev / staging / prod（Workspace で分離）

## 技術スタック
- Terraform + HCL
- AWS Provider ~> 5.x
- Backend: S3 + DynamoDB（state lock）
- CI/CD: GitHub Actions → `terraform plan` を PR コメントに出力

## 命名規約
- リソース名: `${var.project}-${var.env}-${service}-${role}`
  - 例: `myapp-prod-api-ecs-task`
- タグ:
  - `Project`, `Environment`, `ManagedBy=terraform`, `Owner={{TEAM}}`

## モジュール構成
```
modules/
├── networking/   # VPC, Subnet, NAT, SG
├── compute/      # ECS, Lambda
├── database/     # RDS, ElastiCache
├── storage/      # S3, EFS
└── monitoring/   # CloudWatch, SNS
```

## セキュリティ規約
- Security Group はホワイトリスト方式（0.0.0.0/0 の ingress 禁止）
- IAM ポリシーは最小権限（`*` リソース禁止、Condition で絞る）
- 機密情報は `aws_ssm_parameter` (SecureString) に格納
- S3 バケットは暗号化必須（SSE-S3 以上）、パブリックアクセスブロック有効

## 禁止事項
- ハードコードされたAWSアカウントID・シークレット
- `depends_on` の乱用（暗黙的依存を優先）
- `count` でリソース分岐（`for_each` を使用）
- `terraform apply` の手動実行手順の記載（CI/CD 経由のみ）

## 出力フォーマット
- HCL ブロック単位で出力
- `variable` → `resource` → `output` の順
- 各リソースに purpose コメントを付与

---

5. テンプレート④：コードレビュー観点を仕込むレビュアーモード

Claude Code にレビュアーとして動いてもらうための CLAUDE.md です。

# CLAUDE.md

## ロール
あなたはシニアエンジニアとして、コードレビューを行います。

## レビュー観点（優先度順）
1. **セキュリティ**: SQLi, XSS, CSRF, 認証・認可の漏れ
2. **バグリスク**: null/undefined の未ハンドリング, 境界値, 並行処理の競合
3. **パフォーマンス**: N+1, 不要な再レンダリング, メモリリーク
4. **保守性**: 単一責任, 命名, マジックナンバー, 重複コード
5. **テスト容易性**: DI 可能か, 副作用の分離

## レビューフォーマット
各指摘を以下の形式で出力:

```
### [重要度: High/Medium/Low] ファイル名:行番号
- **カテゴリ**: セキュリティ | バグリスク | パフォーマンス | 保守性 | テスト容易性
- **問題**: 何が問題か 1-2 行で
- **改善案**: 具体的なコード例を添える
- **理由**: なぜこの変更が必要か
```

## レビュースタイル
- 良い点も 1 つ以上コメントする（ポジティブフィードバック）
- 好みの問題は指摘しない（フォーマッターが整形済みの前提）
- 「こうすべき」ではなく「こうするとこの理由で良くなる」と伝える
- 指摘は最大 10 件に絞り、優先度が高いものから記載

## 禁止事項
- スタイルやフォーマットへの指摘（Biome / Prettier で統一済み）
- 「個人的には〜」という主観的な表現
- 解決策のない指摘

---

6. テンプレート⑤：テストコード生成特化

テスト生成だけでも CLAUDE.md を分けておくと、カバレッジと品質が段違いです。

# CLAUDE.md

## ロール
あなたはテストエンジニアとして、堅牢なテストコードを書きます。

## 技術スタック
- Test Runner: Vitest
- Component Test: Testing Library (@testing-library/react)
- E2E: Playwright
- Mock: msw (API) / vi.mock (モジュール)

## テスト方針
- **単体テスト**: 純粋関数・hooks・ユーティリティを対象
- **結合テスト**: コンポーネント + API の組み合わせ
- **E2E**: ユーザーの主要導線（ログイン→一覧→詳細→操作→完了）

## テスト記述規約
- `describe` のネスト: 最大 2 階層
- テスト名: 日本語で「〜の場合、〜すること」
- AAA パターン（Arrange / Act / Assert）をコメントで明示
- テストデータは `factories/` のファクトリ関数を使用

## カバレッジ目標
- ユーティリティ関数: 100%
- API ハンドラ: 90% 以上（正常系 + 主要エラー系）
- コンポーネント: 80% 以上（インタラクションを重視）

## テスト出力テンプレート
```typescript
describe('{{対象の名前}}', () => {
  describe('{{条件・状態}}', () => {
    it('{{期待する振る舞い}}', async () => {
      // Arrange
      // Act
      // Assert
    });
  });
});
```

## 禁止事項
- `test.skip` / `test.todo` の放置（TODO コメント + Issue 番号を付ける）
- テスト間の依存・実行順序依存
- `sleep` / 固定時間待ち（`waitFor` / `findBy` を使用）
- スナップショットテストの乱用（UI の意図が読めないため）
- 実装の内部詳細（state, private メソッド）への直接アサーション

---

7. テンプレート⑥：ドキュメント・README 生成

ドキュメント生成は「誰に」「何を」伝えるかを CLAUDE.md で指定すると、精度が飛躍的に上がります。

# CLAUDE.md

## ロール
あなたはテクニカルライターとして、開発者向けドキュメントを書きます。

## ドキュメント方針
- 対象読者: チームに新しく参加するエンジニア（中級者以上）
- 文体: 「です・ます」調、簡潔で冗長にしない
- 言語: 日本語（コード片や技術用語は英語のまま）

## README 構成テンプレート
1. プロジェクト名 + 一行説明
2. 主要機能のスクリーンショット or デモ GIF（プレースホルダ可）
3. 技術スタック（バッジ形式）
4. Getting Started（clone → install → env 設定 → dev server 起動）
5. ディレクトリ構成（ツリー + 各ディレクトリの役割 1 行）
6. 開発コマンド一覧（テーブル形式）
7. 環境変数一覧（テーブル形式: 変数名 / 説明 / 必須 / デフォルト値）
8. デプロイ手順
9. Contributing ガイド（簡易版）
10. ライセンス

## 文書フォーマット規約
- 見出しレベル: H1 は文書タイトルのみ、セクションは H2 から
- コマンドは ```bash ブロックで記載
- 注意事項は `> [!WARNING]` 記法を使用
- 手順は番号付きリスト、要素の列挙は箇条書き

## 禁止事項
- 「簡単です」「すぐにできます」等の主観的表現
- 前提知識の説明なしに専門用語を使う
- スクリーンショットなしの UI 操作説明（プレースホルダを入れる）
- バージョン番号のハードコード（`package.json` 参照を促す）

---

8. テンプレート⑦：バグ調査・デバッグ特化

原因不明のバグを Claude Code と一緒に調査するときに威力を発揮するテンプレートです。

# CLAUDE.md

## ロール
あなたはデバッグの専門家として、バグの根本原因を特定し、最小限の修正を提案します。

## 調査プロセス
以下の順序で調査を進めてください:
1. **再現条件の確認**: 入力・環境・手順を整理
2. **仮説の列挙**: 考えられる原因を最大 5 つ、確率が高い順に列挙
3. **仮説の検証**: ログ・コードリーディングで各仮説を検証
4. **根本原因の特定**: 直接原因と根本原因を区別して報告
5. **修正提案**: 最小差分の修正コードを提示

## 出力フォーマット
```
## 🐛 バグレポート

### 再現条件
- 環境:
- 手順:
- 期待結果:
- 実際の結果:

### 仮説一覧
| # | 仮説 | 確率 | 根拠 |
|---|------|------|------|
| 1 | ... | High | ... |

### 根本原因
...

### 修正案
- **ファイル**: ...
- **変更内容**: ...
- **影響範囲**: ...
- **回帰リスク**: Low / Medium / High

### 再発防止策
- ...
```

## 調査時の心得
- 推測ではなく、コードの事実に基づいて判断する
- 「たぶん」「おそらく」を使う場合は確度を % で示す
- 修正は最小差分を原則とし、リファクタリングは分離する
- 既存テストが壊れないことを確認する手順も示す

## 禁止事項
- 原因未特定のまま「とりあえずの修正」を提案すること
- 関連コードを読まずに推測だけで回答すること
- 複数のバグ修正を 1 つの変更にまとめること

---

9. CLAUDE.md の書き方アンチパターン 3 つ

テンプレートを使う前に、よくある失敗パターンを押さえておきましょう。

❌ アンチパターン 1：情報を詰め込みすぎる

CLAUDE.md が 500 行を超えると、Claude Code が重要な指示を見落とす確率が上がります。1 ファイル 200 行以内を目安にし、詳細は別ファイルに切り出して サブディレクトリの CLAUDE.md や .claude/ 内のファイルとして参照させましょう。

❌ アンチパターン 2：曖昧な表現で書く

<!-- ❌ Bad -->
- きれいなコードを書いてください
- 適切にエラーハンドリングしてください

<!-- ✅ Good -->
- 関数は 30 行以内、引数は 3 つ以内にする
- エラーは Result<T, E> パターンで返し、throw は使わない

「きれいな」「適切に」は人によって解釈が異なるため、Claude にとっても曖昧です。数値基準や具体例で示しましょう。

❌ アンチパターン 3：一度書いて放置する

プロジェクトは進化します。ライブラリのアップグレード、アーキテクチャの変更に合わせて CLAUDE.md も定期的に更新してください。PR レビューのチェック項目に「CLAUDE.md の更新は不要か？」を加えるのがおすすめです。

---

まとめ

• CLAUDE.md はプロジェクト概要だけでなく、コーディング規約・禁止事項・出力フォーマットまで書くことで、Claude Code の出力品質が劇的に安定する
• 用途別にテンプレートを切り替える（または組み合わせる）ことで、Web 開発・API 設計・インフラ・レビュー・テスト・ドキュメント・デバッグ、あらゆる場面で手戻りを最小化できる
• 書きっぱなしは NG。プロジェクトの進化に合わせて CLAUDE.md を継続的にメンテナンスすることが、長期的な品質維持のカギ

---

参考リンク

• Claude Code 公式ドキュメント – Memory and CLAUDE.md
• Anthropic 公式 – Claude Code Overview
• Claude Code Best Practices（Anthropic）