【2026年最新】CLAUDE.md書き方完全ガイド｜テンプレート5選とベストプラクティス

結論: CLAUDE.mdはClaude Codeへのプロジェクト指示ファイルで、適切に書くことでAIが毎回同じ品質で作業できるようになります。

この記事の要点:

• CLAUDE.mdはプロジェクトルートまたは.claude/ディレクトリに配置するAIへの指示書
• 200行以内・WHY/WHAT/HOW構造で書くと効果が高い
• Web開発・データ分析・ドキュメント作成など用途別テンプレートで即利用可能

対象読者: Claude Codeを使い始めたエンジニア・非エンジニアビジネスパーソン
読了後にできること: 今日中に自分のプロジェクト用CLAUDE.mdを作成し、Claude Codeの精度を劇的に上げる

「Claude Codeに指示しても毎回微妙にズレた出力が来る…」

企業向けAI研修で、最近よく相談されるのがこの悩みです。

先日、ある製造業の情報システム担当者から相談を受けました。「ChatGPTと同じ感覚でClaude Codeを使ったら、コードのスタイルがバラバラになってしまって、チームメンバーが書いたコードと混在して困っています」というものでした。原因を聞くと、CLAUDE.mdを全く設定していなかったんです。

CLAUDE.mdを正しく設定してもらったら、その週のうちにコードレビューの指摘件数が半分以下になったと報告をいただきました。CLAUDE.mdは、Claude Codeを「使える状態」にするための最重要設定ファイルなんです。

この記事では、CLAUDE.mdの書き方を、コピペできるテンプレートつきで徹底解説します。Web開発・データ分析・ドキュメント作成など用途別のテンプレートも全公開しますので、今日からすぐ使えます。

AIエージェントの基本概念や導入ステップについては、AIエージェント導入完全ガイドで体系的にまとめています。

CLAUDE.mdとは何か — プロジェクト指示ファイルの役割

CLAUDE.mdは、Claude Codeが自動的に読み込む「プロジェクトへの指示書」です。チームに新しいエンジニアが入ったときに渡すオンボーディングドキュメントと同じ役割を果たします。ただし読み手はAIです。

正式には「memory file」とも呼ばれ、以下のタイミングで自動的に読み込まれます：

• Claude Codeセッション開始時
• サブエージェント（Taskツール）起動時
• スラッシュコマンド実行時

一度書いておけば、毎回同じプロジェクトルール・コーディングスタイル・禁止事項をAIに伝え続けてくれます。「毎回同じことを説明するのが面倒」という問題が完全に解消されます。

CLAUDE.mdがない場合の問題

研修現場でよく目にするのが「CLAUDE.mdなし状態」の弊害です：

• コードスタイルが毎回ランダムに変わる（タブvsスペース、シングルvsダブルクォートなど）
• 禁止されているライブラリを提案してくる（会社のセキュリティポリシー違反）
• テスト環境と本番環境を混在させるコードを書いてくる
• 既存の設計パターンを無視してゼロから実装しようとする

これらは全て、CLAUDE.mdで解決できます。

CLAUDE.mdのファイル配置 — 3種類の場所と優先順位

CLAUDE.mdは3つの場所に置けて、それぞれスコープが異なります。

実務では「プロジェクトルートのCLAUDE.mdをGitコミット + ~/.claude/CLAUDE.mdで個人設定」という二層構造が最もよく機能します。

事例区分: 想定シナリオ
以下は100社以上の研修経験をもとに構成した典型的なシナリオです。
5人のWebエンジニアチームで、全員が個別にClaude Codeを使っていた会社。プロジェクトルートに1つのCLAUDE.mdを置いてチーム全体で共有したところ、「Claudeが変なライブラリを提案してくる」という苦情がゼロになった、というケースは珍しくありません。

CLAUDE.mdの基本構文 — WHY/WHAT/HOWの3層構造

正直に言うと、「なんでもかんでも書き込もう」という発想がCLAUDE.mdを壊します。200行を超えるとClaudeが重要な指示を読み飛ばし始めるんです。研修でも「長ければ長いほどいい」という誤解が多いです。

効果的なCLAUDE.mdは3つの層で構成されます：

WHY層：プロジェクトの背景と目的

なぜこのプロジェクトが存在するか、ゴールは何かを1〜2段落で書きます。

## プロジェクト概要
Uravation社の顧客向けポータルサイト。
目的: 顧客が自社のAI研修進捗を確認・管理できるWebアプリ。
ターゲット: 非エンジニアの人事担当者（スマホ操作前提）。

WHAT層：技術スタック・アーキテクチャ

どんな技術を使っているか、どんな構成かを箇条書きで簡潔に。

## 技術スタック
- フロントエンド: Next.js 14 (App Router), TypeScript, Tailwind CSS
- バックエンド: Node.js 20, Express, PostgreSQL 15
- デプロイ: Vercel (フロント), Railway (バックエンド)
- テスト: Vitest (ユニット), Playwright (E2E)

## 禁止ライブラリ
- momentjs (date-fnsを使う)
- lodash (ネイティブメソッドで代替)
- classnames (clsxを使う)

HOW層：作業ルールとコーディング規約

Claudeに「どう動いてほしいか」を具体的に指示します。

## コーディング規約
- インデント: スペース2つ（タブ禁止）
- クォート: シングルクォートを使う
- セミコロン: 必ずつける
- 関数: アロー関数を優先、最大50行
- コメント: JSDocスタイルで重要な関数に必ず書く

## 作業ルール
- ファイル変更前に必ず現状を読んで確認する
- 変更範囲を最小限にする（不要な行を変えない）
- テストが通らなければコードを完成とみなさない
- 不明な点があれば作業前に質問する

## 禁止事項
- console.log本番コードへの混入
- any型の使用（TypeScript）
- 環境変数のハードコーディング

用途別テンプレート集 — 今すぐコピペして使える5選

研修先で「テンプレートがあれば最高なんですが」と何度も言われてきました。ということで、実際によく使われる5種類を完全公開します。

テンプレート1: Web開発（フルスタック）

# プロジェクト: [プロジェクト名]

## 概要
[1〜2文でプロジェクトの目的を記述]
ターゲットユーザー: [誰が使うか]

## 技術スタック
- フロントエンド: [技術名 + バージョン]
- バックエンド: [技術名 + バージョン]
- データベース: [技術名 + バージョン]
- デプロイ先: [Vercel / AWS / etc.]

## ディレクトリ構成（重要部分のみ）
src/
  app/          # Next.js App Router
  components/   # UIコンポーネント
  lib/          # ユーティリティ・API呼び出し
  types/        # TypeScript型定義

## コーディング規約
- インデント: スペース2つ
- クォート: シングルクォート
- セミコロン: あり
- 命名規則: コンポーネントはPascalCase、関数はcamelCase

## 禁止事項
- any型の使用
- console.log（デバッグ後は必ず削除）
- 環境変数のハードコーディング

## テスト方針
- ユニットテスト: ビジネスロジックに必須
- E2E: 主要ユーザーフロー（ログイン・購入等）に必須

## コミットメッセージ形式
feat: 新機能
fix: バグ修正
refactor: リファクタリング
docs: ドキュメント更新
test: テスト追加

不明な点があれば作業前に必ず確認すること。

テンプレート2: データ分析・機械学習

# プロジェクト: [データ分析プロジェクト名]

## 概要
目的: [何を分析・予測するか]
データソース: [どのデータを使うか]
出力形式: [レポート / ダッシュボード / APIなど]

## 技術スタック
- 言語: Python 3.11
- 主要ライブラリ: pandas, numpy, scikit-learn, matplotlib
- Jupyter環境: JupyterLab
- データストレージ: [S3 / BigQuery / PostgreSQLなど]

## ファイル命名規則
- ノートブック: YYYYMMDD_説明.ipynb（例: 20260320_churn_analysis.ipynb）
- データファイル: raw/ processed/ trained/ で分類
- モデル: models/model_名前_v1.pkl

## コーディング規約
- 関数には必ずdocstringを書く
- マジックナンバーは定数に（ファイル冒頭にまとめる）
- データの前処理は再現性のためにスクリプト化
- 乱数シードは必ず固定（RANDOM_SEED = 42）

## 禁止事項
- 生データの直接上書き（必ずraw/に保存して加工版をprocessed/に）
- print文での結果確認（loggingモジュールを使う）
- 絶対パスのハードコーディング（pathlib.Pathを使う）

## 分析の出力要件
- 全ての数値に単位を明記
- グラフには必ずタイトル・軸ラベル・凡例
- 結論は必ず根拠の数字とセットで書く

不明な点があれば作業前に必ず確認すること。

テンプレート3: ドキュメント・記事作成

# プロジェクト: [メディア/ドキュメントプロジェクト名]

## 概要
目的: [何のためのドキュメントか]
ターゲット読者: [誰が読むか・想定知識レベル]
トーン: [カジュアル / フォーマル / 技術的]

## 記事構成ルール
- タイトル: 40文字以内、キーワードを前方に、数字を含める
- 見出し（H2）: 5個以上
- 文字数: 3,000字以上
- 冒頭: 必ず具体的なエピソードや問題提起から始める（定義から始めない）

## 文体
- 敬体（「〜です」「〜ます」）を使う
- 「〜なんです」「実は〜」などのカジュアル表現OK
- 難しい用語には最初の登場時に括弧で説明を添える
- 段落は3〜4文以内に収める

## 禁止表現
- 「〜は非常に重要です」（なぜ重要かを書く）
- 「〜と言われています」（誰が言っているか明記）
- 「〜することができます」→「〜できます」に短縮

## 必須要素
- コピペできるプロンプト例（コードブロックで）
- 失敗パターンと回避策（【要注意】セクション）
- まとめの3アクション（今日・今週・今月）

不明な点があれば作業前に必ず確認すること。

テンプレート4: 業務自動化スクリプト

# プロジェクト: [自動化スクリプトプロジェクト名]

## 概要
自動化対象: [何の作業を自動化するか]
実行環境: [OS、Python/Node.jsバージョン]
実行頻度: [毎日 / 毎週 / 手動実行]

## 技術スタック
- 言語: Python 3.11
- パッケージ管理: pip + requirements.txt
- 設定管理: .env（python-dotenv）

## ファイル構成
main.py          # エントリーポイント
config.py        # 設定読み込み
utils/           # 共通ユーティリティ
logs/            # ログファイル（Gitignore済み）
tests/           # テストコード

## エラーハンドリング規約
- 全ての外部API呼び出しにtry/exceptを書く
- エラーはloggingモジュールでERROR以上のレベルで記録
- 重大エラーは管理者にメール通知（[担当者メール]）
- リトライ処理: 3回まで、指数バックオフで

## 設定管理
- 全ての設定値は.envまたは設定ファイルに
- APIキーはコードに絶対に書かない
- .env.exampleにサンプルを必ず置く

## テスト要件
- 主要関数に最低1つのユニットテスト
- 外部APIはモック必須

不明な点があれば作業前に必ず確認すること。

テンプレート5: 汎用スターター（5分で始めるミニマル版）

# プロジェクト: [プロジェクト名]

## 目的
[1〜2文でゴールを記述]

## 技術環境
- 言語: [言語 + バージョン]
- 主要ライブラリ: [ライブラリ名]

## 重要なルール
1. [最重要ルール1]
2. [最重要ルール2]
3. [最重要ルール3]

## やってはいけないこと
- [禁止事項1]
- [禁止事項2]

## 作業前に確認すること
不明な点は作業前に必ず質問する。
仮定した点は「仮定:」と明記してから進む。

ミニマル版は「とりあえず今日から使いたい」という方向けです。30分かけて完璧なCLAUDE.mdを作るより、まず5分でミニマル版を作って動かしながら育てる方が、実際には早く使えるようになります。

ベストプラクティス — 何を書くべきか・書きすぎないコツ

「書きすぎ」は「書かなすぎ」と同じくらい危険です。研修先で最もよく目にする失敗がこれです。

書くべき内容（必須要素）

書かなくてよい内容（削除すべきノイズ）

• Git履歴・変更ログ → git logで確認できる
• 外部ドキュメントの内容そのまま転記 → URLリンクを1行書けばいい
• 現在の作業進捗 → セッションごとに変わるから意味がない
• 一度しか使わないワンオフの指示 → チャットで直接指示する
• 汎用的なプログラミング常識 → 「コメントを書く」「エラーハンドリングをする」は不要

CLAUDE.mdを育てるコツ

完璧なCLAUDE.mdを最初から作ろうとしないことです。

実際に研修でお勧めしている方法は「Claudeが間違えたらCLAUDE.mdに追記する」という反復改善法です。間違えるたびに1行追記していくと、2〜3週間でそのプロジェクトに最適なCLAUDE.mdが完成します。

# CLAUDE.mdの育て方（プロンプト）
今日、Claudeが[具体的に間違えた内容]という間違いをしました。
この間違いを防ぐために、CLAUDE.mdに追記すべきルールを1〜2行で提案してください。
既存のルールと重複しないようにしてください。

不明な点があれば作業前に必ず確認してください。

実例3選 — 実際のプロジェクトでの使用例

実例1: Next.js + Supabaseの業務アプリ

事例区分: 想定シナリオ
以下は100社以上の研修経験をもとに構成した典型的なシナリオです。

従業員30名のIT企業で、社内の勤怠管理アプリをClaude Codeで開発するケースです。

CLAUDE.mdに「Supabase Row Level Security（RLS）は全テーブルに必須」「部署ごとのデータ分離はRLSポリシーで実装」と明記することで、セキュリティ上の重大な実装漏れを防いでいます。

## セキュリティ要件（最重要）
- Supabase RLSは全テーブルに必須（無効化禁止）
- ユーザーは自分の部署のデータのみ参照・編集可能
- 管理者ロールのチェックは必ずサーバー側で行う（クライアント側のみは禁止）
- APIキーはサーバー側のみ（ブラウザへの露出禁止）

実例2: データ分析チームのCLAUDE.md

事例区分: 想定シナリオ
以下は100社以上の研修経験をもとに構成した典型的なシナリオです。

小売業の分析チーム（5名）が、Pythonで売上分析レポートを自動化するケース。

「分析結果の数値は必ず四捨五入（小数点以下2桁）」「グラフのカラーパレットは会社のブランドカラー（#0057B8）を使う」などの細かい指示をCLAUDE.mdに書くことで、毎回の出力が会社の基準に合ったものになります。

## 出力品質基準
- 数値の表示: 小数点以下2桁に統一（round(x, 2)）
- 金額: 万円単位、3桁区切り（例: 1,234万円）
- グラフのプライマリカラー: #0057B8（会社ブランドカラー）
- グラフサイズ: 幅12インチ × 高さ6インチを標準とする
- レポートの結論は必ず冒頭に配置（エグゼクティブサマリー形式）

実例3: ブログ記事量産チームのCLAUDE.md

事例区分: 想定シナリオ
以下は100社以上の研修経験をもとに構成した典型的なシナリオです。

メディア系企業のコンテンツチーム（3名）が、SEO記事を量産するケース。

## 記事品質基準
- タイトル: 40文字以内、ターゲットキーワードを前方に
- 文字数: 本文3,000字以上
- H2: 5個以上（目次の充実度）
- 内部リンク: 2本以上（ピラーページへの誘導）
- 冒頭: 読者の悩みを共感から始める（定義説明から入らない）

## 絶対に書いてはいけないこと
- 架空の統計・数字（出典なし）
- 「〜という調査によると」（調査名・URLなしの引用）
- 架空の体験談・事例（「ある企業では〜」）

【要注意】よくある失敗パターン4選

失敗1: 長すぎるCLAUDE.md（200行オーバー）

❌ よくある間違い: ドキュメントを全部CLAUDE.mdに転記してしまう

⭕ 正しいアプローチ: 「毎回必要な情報」だけCLAUDE.mdに。詳細は別ファイルにして@docs/architecture.md を読めと1行書く

なぜ重要か: Claude Codeはコンテキストウィンドウを賢く管理していますが、CLAUDE.mdが長すぎると重要な指示が薄まります。200行を目安に、それ以上になったらSKILL.mdなどの別ファイルに分離しましょう。

失敗2: 「お願い」「〜してほしい」という曖昧な表現

❌ よくある間違い:

なるべくシンプルなコードを書いてほしいです。
できればコメントも書いてもらえると助かります。

⭕ 正しいアプローチ:

関数は1つにつき最大50行以内にすること（超える場合は分割必須）。
全パブリック関数にJSDocコメントを必須とする。

なぜ重要か: 「なるべく」「できれば」はAIに対して意味をなしません。ルールは断言形で書きましょう。

失敗3: プロジェクトの目的を書かない

❌ よくある間違い: 技術スタックと禁止事項だけ書いて、何を作っているかを書かない

⭕ 正しいアプローチ: 最初の数行でプロジェクトの目的・ターゲットユーザー・完成イメージを書く

なぜ重要か: Claudeはコンテキストが豊かなほど判断精度が上がります。「誰のために何を作っているか」を知ることで、コードの実装方針が変わります。

失敗4: 一度書いたら更新しない

❌ よくある間違い: 最初に作ったCLAUDE.mdをそのまま6ヶ月使い続ける

⭕ 正しいアプローチ: Claudeが間違えたタイミングで都度更新する（コードと同じように保守する）

なぜ重要か: プロジェクトは変わります。技術スタックが変わった、新しい禁止事項が増えた、チームルールが変わった — これらをCLAUDE.mdに反映しないと、AIが古いルールで動き続けます。

CLAUDE.mdを自動生成する方法

Claude Codeには/initコマンドがあり、現在のプロジェクト構成を分析して自動的にCLAUDE.mdの雛形を生成してくれます。

# プロジェクトディレクトリで実行
/init

# または新しいプロジェクトの場合
まず現在のプロジェクト構成を分析して、CLAUDE.mdの雛形を作成してください。
技術スタック、ディレクトリ構成、推奨するコーディング規約を含めてください。
不足している情報があれば最初に質問してから作成を開始してください。

自動生成された雛形は完璧ではありませんが、「何を書けばいいかわからない」という最初のハードルを大きく下げてくれます。生成後に実際のプロジェクトルールに合わせて修正するのが最も効率的です。

グローバルCLAUDE.md活用法 — 個人の設定を全プロジェクトに

~/.claude/CLAUDE.md（グローバル設定）には、全プロジェクトに共通する「自分のスタイル」を書きます。

# グローバル設定（全プロジェクト共通）

## 私の作業スタイル
- 複雑な実装に入る前に、必ず実装方針を提案して私の確認を取ること
- ファイルを大きく変更する前に、変更箇所のリストを示すこと
- 「完了しました」の報告では、変更したファイルパスと変更内容の要約を含めること

## コミュニケーション
- 技術的な説明は専門用語を避けて平易な言葉で
- 選択肢がある場合は最大3つまで提示、推奨案を明確にする
- 不明な点は作業前に必ず確認する

## コーディングスタイル（個人的好み）
- コメントは日本語で書く
- 変数名は英語（ローマ字ではなく英単語を使う）
- マジックナンバーは必ず定数化

仮定した点は必ず「仮定: 〜」と明記してください。

グローバル設定は「自分専用のClaude Codeの性格」を定義するものです。一度書いておくと全プロジェクトで一貫した動作になります。

参考・出典

• Writing a good CLAUDE.md — HumanLayer Blog（参照日: 2026-03-27）
• Best Practices for Claude Code — Anthropic公式ドキュメント（参照日: 2026-03-27）
• How to Write a Good CLAUDE.md File — Builder.io（参照日: 2026-03-27）
• claude-md-templates — GitHub（参照日: 2026-03-27）
• CLAUDE.md Best Practices — UX Planet（参照日: 2026-03-27）

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

1. 今日やること: 現在のプロジェクトで/initコマンドを実行してCLAUDE.mdの雛形を生成し、3つだけルールを追加する
2. 今週中: チームのコーディング規約をCLAUDE.mdに反映し、全メンバーがGit経由で共有できるようにする
3. 今月中: ~/.claude/CLAUDE.mdグローバル設定を作成し、自分専用のClaude Codeスタイルを確立する

次回予告: 次の記事では「Claude Codeの始め方2026年最新版」をテーマに、インストールから初期設定・基本操作まで、最新情報をお届けします。

あわせて読みたい:

• Claude Code Channels完全ガイド — Telegram・Discordで非同期AI開発
• AI導入戦略ガイド — 中小企業のAI活用ロードマップ

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

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