【2026年最新】CLAUDE.mdテンプレート集｜Web開発・データ分析・マーケ・DevOps別コピペで使える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書き方完全ガイドで詳しく解説していますので、まずは「テンプレート集」として本記事をご活用ください。

まず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 のよくある失敗パターン

失敗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書き方完全ガイドで詳しく解説しています。まずは「入門〜基本」から始めてみてください。

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

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

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ピックス）。

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