CLAUDE.mdテンプレ4選｜そのままコピペで使える

結論: CLAUDE.mdはプロジェクト開始時にコピペするだけで、Claude Codeの出力品質を劇的に安定させる設定ファイルです。

この記事の要点:

• 要点1: CLAUDE.mdを適切に設定すると、毎回同じ指示を繰り返す手間がなくなり、開発効率が大幅に向上する
• 要点2: Web開発・データ分析・マーケティング・DevOpsの4プロジェクト別テンプレートをコピペ可能な形で全公開
• 要点3: 既存の「高度設定術」記事とは異なり、「今すぐ使えるテンプレート集」に特化

対象読者: Claude Codeを使い始めたばかりの開発者・非エンジニアのClaude Codeユーザー
読了後にできること: 今日のプロジェクトにそのまま使えるCLAUDE.mdを1つ手に入れられる

「CLAUDE.mdって書いてみたけど、毎回同じ指示をしてる気がする…」

Claude Code研修でよくある相談です。先日もフリーランスのWebデザイナーの方（Reactは少し触れる程度）から「毎回『TypeScriptで書いて』『コメントを日本語で』と指示しているのが面倒」という話を聞きました。

CLAUDE.mdに一度書いておけば、それらの指示はセッション開始時に自動で読み込まれます。つまり「いつも言っていること」をCLAUDE.mdに書くと、言わなくてよくなるんです。

この記事では、プロジェクト別のCLAUDE.mdテンプレートを4つ、そのままコピペして使える形で公開します。CLAUDE.mdの高度設定（Hooks・MCPなど）についてはCLAUDE.md高度活用ガイド（Hooks・MCP）で詳しく解説していますので、まずは「テンプレート集」として本記事をご活用ください。

まず5分で使えるミニCLAUDE.mdテンプレート3選

難しく考えなくていいです。まずこの3つのどれかをプロジェクトルートに `CLAUDE.md` として保存してください。

ミニテンプレート1：汎用ビジネス用途

# プロジェクト設定

## 基本ルール
- コメントとドキュメントは日本語で記述する
- 変数名・関数名は英語のキャメルケース
- 処理ごとにコメントを入れ、何をしているかを明示する
- エラーハンドリングを必ず実装する

## アウトプット品質
- コードは初心者でも読めるようにシンプルに書く
- 複雑な処理は小さい関数に分割する
- 不明な点は実行前に質問する

## 禁止事項
- 確認なしにファイルを削除しない
- 本番環境の設定ファイルを編集する前に確認を取る

活用例: Claude Code を日常業務ツールとして使っている非エンジニアの方に特に好評です。「日本語コメント」の指示を毎回しなくてよくなったという声が多い。

ミニテンプレート2：チーム開発向け

# チーム開発設定

## コーディング規約
- コード品質: ESLint + Prettier（設定ファイルは .eslintrc に従う）
- テスト: 新機能には必ずユニットテストを追加（Jest使用）
- PR前チェック: lint → test → build の順に必ず実行

## コミット規約（Conventional Commits）
- feat: 新機能
- fix: バグ修正
- docs: ドキュメント
- refactor: リファクタリング
- コミットメッセージは日本語可

## 開発フロー
- 新機能は必ずfeatureブランチで作業
- mainへの直接pushは禁止
- PRレビュー後にマージ

ミニテンプレート3：コンテンツ・マーケティング業務

# コンテンツ作業設定

## 文章スタイル
- 対象読者: 中小企業の経営者・担当者（40-50代）
- トーン: プロフェッショナルかつ親しみやすい
- 文体: 「です・ます」調
- 専門用語は必ず平易な言葉で補足する

## アウトプット形式
- 見出しはH2/H3を使った階層構造で
- 箇条書きより文章を優先（箇条書きは補足情報のみ）
- 数字・データには必ず出典を添える

## 禁止ワード
- 「革命的」「劇的」「最強」（代替: 「大幅な改善」「効果的な」）
- 架空の数字・体験談は書かない

CLAUDE.mdの基本概念や書き方の型については、CLAUDE.md書き方ガイドで詳しく解説しています。

テンプレート1：Web開発プロジェクト（Next.js + TypeScript）

フロントエンド開発で最もよく使われる構成です。研修先のWebエンジニアの方に試してもらったところ、「Claudeが勝手にany型を使わなくなった」「コンポーネント分割の粒度が揃うようになった」と好評でした。

# Web開発プロジェクト設定（Next.js + TypeScript）

## プロジェクト概要
- フレームワーク: Next.js 15（App Router）
- 言語: TypeScript（strictモード）
- スタイリング: Tailwind CSS
- 状態管理: Zustand
- テスト: Jest + React Testing Library
- デプロイ: Vercel

## コーディング規約

### TypeScript
- `any` 型の使用は禁止。`unknown` または適切な型定義を使う
- 型エイリアスには `type`、オブジェクト型インターフェースには `interface` を使い分ける
- オプショナルチェーン（?.）とNullish Coalescing（??）を積極的に使う
- enumは使わない。代わりに `as const` を使う

### コンポーネント設計
- Server Components をデフォルトにする（クライアント状態が必要な場合のみ `'use client'`）
- コンポーネントは1ファイル1コンポーネント
- Propsの型定義はコンポーネントの直上に記述
- ファイル名・コンポーネント名はPascalCase

### 命名規則
- 変数・関数: camelCase
- 定数: UPPER_SNAKE_CASE
- ファイル（コンポーネント以外）: kebab-case
- コメント: 日本語OK

## ディレクトリ構成
```
src/
├── app/          # Next.js App Router（ページ・レイアウト）
├── components/   # 再利用可能なUIコンポーネント
├── features/     # 機能別モジュール（components + hooks + types）
├── lib/          # 外部ライブラリの設定・ラッパー
├── hooks/        # カスタムhooks
├── types/        # 共通型定義
└── utils/        # ユーティリティ関数
```

## よく使うコマンド
```bash
npm run dev        # 開発サーバー起動（localhost:3000）
npm run build      # 本番ビルド
npm run test       # テスト実行
npm run lint       # ESLintチェック
npm run type-check # 型チェック
```

## 重要ルール
- 新機能には必ずユニットテストを追加する
- `console.log` はデバッグ後に削除する
- 環境変数は `.env.local` に記載し、`.env.example` も更新する
- 確認なしにpackage.jsonを変更しない

## 禁止事項
- `// @ts-ignore` の使用（代わりに型定義を修正する）
- デフォルトエクスポート（named exportを使う）
- 直接的なDOM操作（Reactのstateで管理する）

テンプレート2：データ分析プロジェクト（Python）

Pythonでデータ分析を行うプロジェクト向けです。研修先の経営企画部門の担当者（Python初学者）に試してもらったところ、「Claudeが出すコードのコメントが丁寧になって、何をしているかわかるようになった」と好評でした。

# データ分析プロジェクト設定（Python）

## プロジェクト概要
- 言語: Python 3.11+
- 主要ライブラリ: pandas, numpy, matplotlib, seaborn, scikit-learn
- 環境管理: venv（requirements.txtで管理）
- Jupyter: JupyterLab

## コーディング規約

### Pythonスタイル
- PEP 8に準拠する
- 型ヒントを必ず記述する（例: `def process(df: pd.DataFrame) -> pd.DataFrame:`）
- コメントは日本語でOK（関数のdocstringは英語が望ましい）
- 1行の長さは最大100文字

### データ処理の原則
- 元データは絶対に上書きしない（コピーしてから加工する）
- データ加工の各ステップをコメントで説明する
- 欠損値の処理は必ず明示する（削除 or 補完の判断を記録）
- 数値の単位・意味をコメントに記載する

### ファイル命名
- スクリプト: snake_case.py
- ノートブック: `01_eda.ipynb`, `02_preprocessing.ipynb`（番号プレフィックス）
- データ: `raw/` に生データ、`processed/` に加工済みデータ

## ディレクトリ構成
```
project/
├── data/
│   ├── raw/         # 元データ（絶対に変更しない）
│   ├── processed/   # 加工済みデータ
│   └── output/      # 分析結果・レポート
├── notebooks/       # Jupyterノートブック
├── src/             # Pythonモジュール
│   ├── data/        # データ取得・前処理
│   ├── features/    # 特徴量エンジニアリング
│   ├── models/      # モデル定義・学習
│   └── visualization/ # 可視化
├── tests/           # テスト
├── requirements.txt
└── README.md
```

## 分析のお作法
- EDA（探索的データ分析）をスキップしない
- 可視化には必ず軸ラベル・タイトル・単位を記載する
- 統計量の解釈コメントをセルに記載する
- 最終レポートには必ず「データの制約・限界」セクションを入れる

## 重要ルール
- 秘密情報（APIキー・個人情報）をノートブックに直接書かない（.envを使う）
- `df.drop(inplace=True)` は使わない（新しい変数に代入する）
- ランダムシードは必ず固定する（再現性確保）

## 禁止事項
- `except Exception: pass` での例外握り潰し
- マジックナンバーの使用（定数として定義する）
- 分析結果のハードコーディング（必ず計算から導く）

テンプレート3：マーケティング・コンテンツ業務

エンジニアではない方でもClaude Codeを業務に活用しているケースが増えています。このテンプレートはマーケティング担当者・コンテンツ担当者向けです。実際に研修先のマーケティング部門で使ってもらい、「記事の品質が安定してきた」と評価をいただいています。

# マーケティング・コンテンツ業務設定

## ブランドガイドライン

### 基本情報
- 会社名: {会社名}
- サービス名: {サービス名・ブランド名}
- ターゲット読者: {ターゲットの詳細}
- ブランドトーン: {プロフェッショナル/フレンドリー/etc.}

### 文体ルール
- 文体: 「です・ます」調（ですます体を統一する）
- 文長: 1文は60字以内を目安に
- 段落: 3〜5文で1段落
- 専門用語は初出時に必ず説明する

### 禁止表現
- 「革命的」「劇的」「最強」「絶対」（根拠なき誇張表現）
- 「〜させていただきます」（過剰敬語）
- 「とても」「非常に」の多用
- 競合他社の名指し批判

## SEOガイドライン
- メインキーワードを必ずH1タイトルに含める
- H2は5つ以上、H3はH2の下に配置
- メタディスクリプションは120字以内
- 内部リンクを最低2本含める
- 数字・統計には必ず出典URLを記載

## コンテンツ品質チェック
コンテンツを作成したら必ず確認:
- [ ] ターゲット読者が5分で読める分量か？
- [ ] 冒頭200字に記事の価値が伝わるか？
- [ ] 「今日から使える」具体的なアクションがあるか？
- [ ] 架空の数字・体験談はないか？
- [ ] 出典は一次ソースか？

## 出力形式のデフォルト
- 記事: Markdown形式
- SNS投稿: プレーンテキスト（改行あり）
- 資料（PowerPoint用）: 箇条書き形式
- メール: 件名+本文セットで出力

## 重要ルール
- 数字・統計は必ず出典を添える
- 架空の体験談・事例を書かない
- 「著者の経験」として書く場合は実体験のみ

テンプレート4：DevOps・インフラ業務

インフラ・運用担当者向けのテンプレートです。「誤ってDBを削除するコマンドを実行させてしまった」という話を研修で聞いてから、安全確認を必須にするルールをデフォルトで入れています。

# DevOps・インフラ業務設定

## 環境情報
- クラウド: {AWS/GCP/Azure/etc.}
- コンテナ: Docker + Kubernetes（{バージョン}）
- CI/CD: {GitHub Actions/CircleCI/etc.}
- IaC: {Terraform/Ansible/etc.}
- モニタリング: {Datadog/CloudWatch/etc.}

## 安全確認ルール（最重要）

### 必ず確認してから実行するコマンド
- データベースのDROP・TRUNCATE・DELETE
- 本番環境のRestart・Rollback
- セキュリティグループ・ファイアウォールの変更
- IAMポリシー・権限の変更

### 実行前に必ず確認すること
「このコマンドは{環境}に影響します。実行してよいですか？」

### ドライランを先に実行
- Terraformは必ず `terraform plan` を先に実行
- Ansibleは `--check` オプションで確認
- kubectl は `--dry-run=client` で確認

## コーディング規約

### スクリプト（Bash/Python）
- シバン行を必ず記載（`#!/bin/bash` or `#!/usr/bin/env python3`）
- エラーハンドリングを必ず実装（`set -e` / `try-except`）
- ログ出力を適切に入れる（タイムスタンプ・ログレベル）
- 環境変数はスクリプトにハードコーディングしない

### Terraform
- リソースには必ずtagsを設定（Owner・Environment・Project）
- `terraform.tfvars` に機密情報を書かない（.gitignoreに追加）
- Stateファイルはリモートバックエンド（S3/GCS）を使用

### Kubernetes
- Podには必ずresource limitsを設定
- Secretsは平文でConfigMapに書かない
- HealthcheckはLiveness + Readinessの両方を設定

## セキュリティチェックリスト
コードをマージする前に確認:
- [ ] 機密情報（パスワード・APIキー）がハードコーディングされていないか？
- [ ] IAMは最小権限の原則に従っているか？
- [ ] ネットワークアクセスは必要最小限のポートのみか？
- [ ] ログに機密情報が出力されていないか？

## インシデント対応
緊急時の連絡フロー:
1. 障害検知 → Slackの #incident チャンネルに投稿
2. 影響範囲の特定 → on-callエンジニアに連絡
3. 初期対応ログ → Confluenceの障害対応ページに記録

## 禁止事項
- 本番環境への直接アクセスを避ける（踏み台サーバー経由）
- root権限での通常作業（専用ユーザーを使う）
- パスワード・認証情報をSlack/Emailで共有する

CLAUDE.mdはどこに置く？4つの配置場所と階層

「テンプレートをコピペしたのに、Claudeが指示どおり動かない」という相談の多くは、CLAUDE.mdの置き場所が原因です。CLAUDE.mdはプロジェクト直下に置くだけでなく、ユーザー個人用・組織全体用など、用途に応じた複数の配置場所が公式に用意されています。

Claude Code公式ドキュメントによれば、CLAUDE.mdは以下の4つのスコープで配置でき、「スコープの広い順（組織→個人→プロジェクト→ローカル）」に読み込まれます。スコープが広いものほど先に読み込まれ、プロジェクト固有の指示はその後に重なります。

使い分けの実例:

• 「日本語コメントで書いて」など全案件で言いたいこと → ~/.claude/CLAUDE.md（ユーザー）に書けば、どのプロジェクトでも自動で効きます。本記事のミニテンプレート1はここに置くのがおすすめ。
• 「このプロジェクトはNext.js + TypeScript」などチーム共通ルール → ./CLAUDE.md（プロジェクト）に書いてGitにコミットすれば、チーム全員に同じ前提が共有されます。テンプレート1〜4はここ。
• 「自分だけのテスト用URL」など共有したくない設定 → ./CLAUDE.local.mdに書いて.gitignoreに追加します（公式ではCLAUDE.local.mdを.gitignoreへ加えることが推奨されています）。

サブディレクトリにも置ける: Claude Codeは現在の作業ディレクトリから親方向（ルートまで）をたどってCLAUDE.mdを探し、見つかったものをすべて読み込みます。さらにサブディレクトリのCLAUDE.mdは、起動時ではなくClaudeがそのフォルダ内のファイルを読むときに必要に応じて読み込まれます。モノレポで「フロントエンドだけのルール」「APIだけのルール」を分けたいときに有効です。

補足: プロジェクトのCLAUDE.mdは/initコマンドで自動生成できます。Claudeがコードベースを解析し、ビルドコマンドやテスト手順、規約を含む雛形を作ってくれます。既にCLAUDE.mdがある場合は、上書きではなく改善案を提示してくれます。

CLAUDE.mdの読み込み順とimport（@path）の正しい使い方

複数の場所にCLAUDE.mdを置いたとき、それらがどう合成されるかを理解しておくと、指示の競合トラブルを避けられます。

読み込み順：上書きではなく「連結」される

公式仕様では、見つかったCLAUDE.mdは互いに上書きせず、すべて連結されてコンテキストに入ります。ディレクトリツリー上はファイルシステムのルート側から作業ディレクトリ側へ順に並びます。つまり「作業ディレクトリに近い（より具体的な）指示ほど後に読まれる」ため、プロジェクト固有のルールがユーザー全体のルールの後に重なる形になります。同じディレクトリ内では、CLAUDE.local.mdがCLAUDE.mdの後に追記されます。

実務上のポイント: 上書きではなく連結なので、矛盾するルールを複数の階層に書くと、Claudeはどちらかを場当たり的に選びます。例えばユーザー設定で「コメントは英語」、プロジェクト設定で「コメントは日本語」と書くと挙動がブレます。階層をまたいで競合がないか、定期的に見直すのが大切です。

import機能：@pathで別ファイルを取り込む

CLAUDE.mdは@path/to/importという記法で、別のファイルを取り込めます。取り込まれたファイルは起動時にCLAUDE.mdと一緒に展開されてコンテキストに入ります。公式仕様で確認できるルールは次のとおりです。

• 相対パス・絶対パスの両方が使える。相対パスは「作業ディレクトリ」ではなく「importを書いたファイルの場所」を基準に解決される。
• 取り込んだファイルがさらにimportを持てる（再帰）。ただし最大4ホップまで。
• ホームディレクトリ展開（~/）が使える。複数のgit worktreeで個人設定を共有したいときは、~/.claude/配下のファイルをimportするのが公式の推奨パターン（例: @~/.claude/my-project-instructions.md）。
• コードブロック内やバッククォートで囲んだパスはimportされない。文章中で@READMEという文字列をそのまま見せたいときはバッククォートで囲む。

使用例（公式記載の書式に準拠）:

プロジェクト概要は @README を、利用可能なnpmコマンドは @package.json を参照。

# 追加の指示
- git運用ルール @docs/git-instructions.md

注意: importはあくまで「整理」のための機能であり、取り込んだファイルも起動時にコンテキストへ読み込まれるため、トークン節約にはなりません。本当に「必要なときだけ読ませたい」場合は、importではなく.claude/rules/のパス指定ルール（特定のファイル種別にだけ適用されるルール）を使うのが公式の推奨です。

ちゃんと読まれているか確認する：/memory コマンド

「書いたのに効かない」と感じたら、まず/memoryコマンドを実行してください。現在のセッションで読み込まれているCLAUDE.md・CLAUDE.local.md・ルールファイルの一覧が表示されます。ここに出てこないファイルは、Claudeから見えていません（＝置き場所が間違っている）。一覧に出ているのに従わない場合は、指示が曖昧か、階層間で矛盾している可能性が高いです。

なお公式ドキュメントは、CLAUDE.mdが「システムプロンプトそのものではなく、システムプロンプトの後に渡されるユーザーメッセージとして読み込まれる」と明記しています。つまり強制力のある設定ではなく、あくまでClaudeへの「文脈」です。「コミット前に必ず実行する」のように確実に実行させたい処理は、CLAUDE.mdではなくHooksで書くのが正解です。Hooksを含む高度設定はCLAUDE.md高度活用ガイド（Hooks・MCP）で解説しています。

【要注意】CLAUDE.md のよくある失敗パターン

失敗1：全部書きすぎる

❌ 300行を超える詳細な仕様書をCLAUDE.mdに書く
⭕ 「毎回繰り返している指示」だけをCLAUDE.mdに書く（50行以内が目安）

なぜ重要か: CLAUDE.mdが長すぎると、Claudeがどの指示を優先すべきか判断しにくくなります。また、コンテキストウィンドウの無駄遣いになります。「プロジェクト固有の必須ルール」に絞ることが大切です。

失敗2：矛盾するルールを書く

❌ 「コメントは日本語で」「docstringは英語で」という記述が同じファイルに混在
⭕ 優先順位を明記する、または対象ファイル種別ごとに分けて記述する

なぜ重要か: Claudeは矛盾する指示があると、どちらかを無視するか、毎回異なる選択をします。ルール間の矛盾を排除することが出力の安定性につながります。

失敗3：一度書いて更新しない

❌ プロジェクト開始時に書いたCLAUDE.mdを半年間そのまま放置
⭕ 新しいルールが決まったり、ライブラリがアップデートしたらCLAUDE.mdも更新する

なぜ重要か: 古いCLAUDE.mdは「Claudeが古い方法でコードを書く」原因になります。月1回のメンテナンスを習慣にしてください。

失敗4：秘密情報を書いてしまう

❌ APIキー・パスワード・顧客名などをCLAUDE.mdに直接記載
⭕ 秘密情報は環境変数（.env）で管理し、CLAUDE.mdには「環境変数名」だけを記載する

なぜ重要か: CLAUDE.mdはGitリポジトリにコミットされることが多いため、秘密情報を書くと情報漏洩のリスクがあります。

CLAUDE.mdの活用レベル別ロードマップ

上級の設定（Hooks・MCPなど）についてはCLAUDE.md高度活用ガイド（Hooks・MCP）で詳しく解説しています。まずは「入門〜基本」から始めてみてください。

プロジェクト別テンプレートの使い方

手順は非常にシンプルです。

1. この記事からテンプレートをコピーする
2. プロジェクトのルートディレクトリに CLAUDE.md というファイル名で保存する
3. {} で囲まれた部分を自分のプロジェクトに合わせて書き換える
4. Claude Codeで新しいセッションを開始する（自動でCLAUDE.mdが読み込まれる）

このプロジェクトのCLAUDE.mdを読んで、設定内容を確認したら教えてください。
また、このプロジェクトに追加した方がよいルールがあれば提案してください。

最初はこのプロンプトをClaudeに投げて、「CLAUDE.mdを理解しているか？」を確認することをおすすめします。

まとめ：今日から始める3つのアクション

1. 今日やること: この記事の4つのテンプレートから自分のプロジェクトに近いものを選び、そのままコピーして CLAUDE.md として保存する
2. 今週中: 1週間使ってみて「毎回言ってしまっているな」と気づいた指示をCLAUDE.mdに追記する
3. 今月中: チームメンバーと共有し、「このルールは必要か？」をレビューして最適なCLAUDE.mdに育てる

次回予告: 次の記事では「Claude Codeのカスタムスラッシュコマンド活用法」をお届けします。繰り返しの作業を1コマンドに圧縮する方法を解説します。

参考・出典

• How to Write a Good CLAUDE.md File — Builder.io（参照日: 2026-04-09）
• CLAUDE MD Templates — ruvnet/ruflo Wiki — GitHub（参照日: 2026-04-09）
• Creating the Perfect CLAUDE.md for Claude Code — Dometrain（参照日: 2026-04-09）
• CLAUDE.md for .NET Developers – Complete Guide with Templates — codewithmukesh.com（参照日: 2026-04-09）

著者: 佐藤傑（さとう・すぐる）
株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー約10万人。100社以上の企業向けAI研修・導入支援。著書『AIエージェント仕事術』（SBクリエイティブ）。SoftBank IT連載7回執筆（NewsPicks最大1,125ピックス）。

ご質問・ご相談はお問い合わせフォームからお気軽にどうぞ。