CLAUDE.mdの書き方｜何を書く・どこに置く・実例【2026年10月】

結論: CLAUDE.mdはClaude Codeが毎セッション最初に読む「プロジェクトへの指示書」で、書き方の型は「何を書くか（WHY/WHAT/HOW）」「どこに置くか（4層）」「どう育てるか（間違えたら1行足す）」の3点に集約できます。

この記事の要点:

• 置き場所は4層（組織ポリシー / ユーザー / プロジェクト / ローカル）。広い層から順に連結して読み込まれ、上書きではない
• 1ファイルの目安は200行未満（公式ドキュメントの推奨）。WHY/WHAT/HOWの3層で書くと守られやすい
• 最初は最小骨格（本記事の1本）で始め、Claudeが間違えるたびに追記して育てる。用途別のフル版テンプレは姉妹記事にまとめています

対象読者: Claude Codeを使い始めたエンジニア・非エンジニアビジネスパーソン
読了後にできること: 今日中に自分のプロジェクト用CLAUDE.mdを書き、どこに置けば読まれるか・読まれたかを自分で確認できる

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

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

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

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

この記事では、CLAUDE.mdの書き方を「何を書くか」「どこに置くか」「書いた後にどう確認・更新するか」の順で、公式ドキュメント（2026年9月6日時点）の仕様に沿って解説します。最小骨格のテンプレートも1本載せているので、今日からすぐ使えます。

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

CLAUDE.mdとは何か — 毎セッション最初に読まれる指示書

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

公式ドキュメントでは「memory（メモリ）」の仕組みの一部として説明されていて、読み込みの挙動は次のとおりです。

• セッション開始時に、該当する層のCLAUDE.mdがまとめて読み込まれる
• サブディレクトリに置いたCLAUDE.mdは、そのディレクトリ内のファイルをClaudeが読んだタイミングでオンデマンドに読み込まれる
• 会話が長くなって/compactで圧縮された後も、プロジェクトルートのCLAUDE.mdは再度読み込まれる
• いま何が読み込まれているかは/context（Memory files欄）と/memoryで確認できる

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

CLAUDE.mdがない場合の問題

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

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

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

どこに置くか — 4層の配置場所と読み込み順

CLAUDE.mdは4つの層に置けて、それぞれスコープが異なります。まず「自分が書こうとしている内容はどの層のものか」を決めてから書き始めると迷いません。

読み込みの順番と重なり方は、書き方に直結するので押さえておきましょう。

• 広い層から狭い層へ順に連結される（組織 → ユーザー → プロジェクト → ローカル）。後の層が前の層を「上書き」するのではなく、全部がまとめて渡ります。したがって層をまたいで矛盾するルールを書かないことが第一のコツです
• プロジェクト層は、作業ディレクトリから親ディレクトリ方向にたどって見つかったCLAUDE.mdも読み込まれます。モノリポでは「ルートに共通ルール、各パッケージ直下に固有ルール」の二段構えが自然です
• 1ファイルの目安は200行未満。公式ドキュメントが明示している数字で、これを超えたら別ファイルに分けて@pathでimportするか、.claude/rules/に分割します（この2つの深掘りはベストプラクティス20選に譲ります）
• CLAUDE.md内のHTMLコメント（<!-- -->）は、Claudeに渡す前に除去されます。「これはメモ」と書いてもAIには届かないので、AIに読ませたくない補足はコメントに、読ませたいことは本文に書き分けられます

実務では「プロジェクトルートのCLAUDE.mdをGitコミット + ~/.claude/CLAUDE.mdで個人設定」という二層構造が最もよく機能します。個人的な実験ルールはコミットせずにCLAUDE.local.mdへ逃がすと、チームのファイルが汚れません。

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

何を書くか — WHY/WHAT/HOWの3層構造

正直に言うと、「なんでもかんでも書き込もう」という発想がCLAUDE.mdを壊します。長いほど守られるわけではなく、本当に守ってほしいルールが埋もれるだけです。研修でも「長ければ長いほどいい」という誤解が多いです。

効果的な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分で書いて動かしながら育てる

研修先で「まず何を書けばいいか」と聞かれたとき、最初に渡しているのがこの1本です。30分かけて完璧なCLAUDE.mdを作るより、5分でこの骨格を埋めて動かし、間違えるたびに1行足す方が、実際には早く使えるようになります。

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

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

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

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

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

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

埋めるときのコツは「重要なルール」を3つで止めることです。10個書きたくなったら、それは骨格ではなくあとで育てる材料なので、いったん置いておきます。

Web開発（フルスタック）・データ分析・ドキュメント作成・業務自動化の用途別に、ディレクトリ構成やテスト方針まで書き込んだフル版が必要な場合は、CLAUDE.mdテンプレ4選にまとめています。本記事の骨格で始めてから、必要な節だけフル版から足す使い方が一番失敗しません。

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

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

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

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

• 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なしの引用）
- 架空の体験談・事例（「ある企業では〜」）

書き方を押さえたら「用途別のCLAUDE.mdテンプレート」から選んで組み合わせられます。

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

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

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

⭕ 正しいアプローチ: 「毎回必要な情報」だけCLAUDE.mdに。詳細は別ファイルにして@docs/architecture.mdのように@pathで参照する（importされたファイルはCLAUDE.mdと一緒に読み込まれます）

なぜ重要か: 公式ドキュメントは1ファイル200行未満を目安に挙げています。長すぎると重要な指示が薄まり、Claudeが優先順位を取り違えます。200行に近づいたら、話題ごとに.claude/rules/へ分割するか、別ファイルにして@pathで参照しましょう。

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

❌ よくある間違い:

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

⭕ 正しいアプローチ:

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

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

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

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

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

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

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

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

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

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

CLAUDE.mdを自動生成する方法 — /init とジェネレーター

Claude Codeには/initコマンドがあり、現在のプロジェクト構成を分析して自動的にCLAUDE.mdの雛形を生成してくれます。すでにCLAUDE.mdがある場合は、ゼロから作り直すのではなく既存ファイルの改善提案を出す挙動です。

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

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

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

Claude Code をまだ導入していない段階で雛形だけ先に用意したい場合や、/init では読み取れない業務ルール（社内の禁止事項・レビュー体制・回答の口調など）を最初から含めたい場合は、当社が無料公開しているCLAUDE.mdジェネレーターが使えます。ブラウザ上で会社名・技術スタック・よく使うコマンド・禁止事項に答えると、本記事で解説したWHY/WHAT/HOWの3層構造に沿った雛形がそのまま出力されます。

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

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

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

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

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

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

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

グローバル設定は「自分専用のClaude Codeの性格」を定義するものです。一度書いておくと全プロジェクトで一貫した動作になります。プロジェクト層と矛盾する内容（インデント幅など）はここに書かず、プロジェクト側に任せるのが安全です。

書いた後の確認 — 読まれているか・効いているかを見る3コマンド

「書いたのに守られない」という相談の半分は、そもそも読み込まれていないケースです。書いたら次の3つで確認します。

• /context: 現在のセッションに読み込まれているMemory files（CLAUDE.mdやrules）と、それが消費しているコンテキスト量が見えます。ファイル名が出てこなければ、置き場所かファイル名（CLAUDE.local.mdのつづりなど）を疑います
• /memory: 読み込み対象のメモリファイル一覧を表示し、その場で開いて編集できます。「どの層のどのファイルが効いているか」を確かめる最短ルートです
• /doctor: CLAUDE.mdが長すぎるときに整理（トリム）を提案してくれます。200行の目安を超えたら一度かけてみてください

もう1つ知っておきたいのは、CLAUDE.mdの内容はシステムプロンプトではなく、その後のユーザーメッセージとしてClaudeに渡るという公式の説明です。つまり「厳密に強制される設定」ではなく「強い指示」であり、絶対に守らせたいルール（特定コマンドの禁止、本番への書き込み禁止など）はHooksで機械的に止める必要があります。Hooksの設計はベストプラクティス20選で扱っています。

参考・出典

• Manage Claude’s memory — Anthropic公式ドキュメント（参照日: 2026-09-06。配置4層・読み込み順・200行目安・@import・/init・/memory・/contextの仕様はこの資料に基づく）
• Best Practices for Claude Code — Anthropic公式ドキュメント（参照日: 2026-03-27）
• Writing a good CLAUDE.md — HumanLayer Blog（参照日: 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を実行するか本記事の最小骨格を埋め、「重要なルール」を3つだけ書いて/contextで読み込まれたことを確認する
2. 今週中: チームのコーディング規約をプロジェクト層のCLAUDE.mdに反映し、Git経由で全メンバーが同じファイルを使う状態にする（個人の実験はCLAUDE.local.mdへ）
3. 今月中: ~/.claude/CLAUDE.mdで自分専用のスタイルを定義し、Claudeが間違えるたびに1行追記して育てる運用を習慣にする

あわせて読みたい:

• CLAUDE.mdテンプレ4選 — 用途別フル版をコピペで使う
• CLAUDE.md ベストプラクティス｜設定の書き方20選 — Hooks・rules・importで運用を固める
• Claude Code Channels完全ガイド — Telegram・Discordで非同期AI開発
• AI導入戦略ガイド — 中小企業のAI活用ロードマップ

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

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