CLAUDE.mdには、ビルド・テストコマンド、命名規則、ディレクトリ構成、禁止事項など「Claude Codeへ毎回説明していること」を短く具体的に書きます。プロジェクトのルートに置けばチームで共有でき、個人専用の設定はCLAUDE.local.mdや~/.claude/CLAUDE.mdへ分けられます。
この記事では、CLAUDE.mdの役割、配置場所、書くべきこと、すぐ使えるテンプレート、/init・/memory、Auto memoryや.claude/rules/との使い分けまで、2026年7月24日時点の公式仕様に沿って解説します。
CLAUDE.mdとは
CLAUDE.mdは、Claude Codeに継続して守ってほしいルールをMarkdown形式で記録するファイルです。たとえば次の内容を指定できます。
- プロジェクトの概要とディレクトリ構成
- 使用するコマンドや開発手順
- コーディング規約と命名規則
- テスト・ビルド・リントの実行方法
- 編集してはいけないファイル
- 回答時の言語や報告形式
最初から長い説明書を作る必要はありません。まずは、毎回伝えている指示を3〜5個に絞って書き、必要に応じて育てる方法がおすすめです。
# Project instructions
- 回答と作業報告は日本語で行う
- 変更前に既存コードの規約を確認する
- 修正後は `npm test` を実行する
- 秘密情報をコードやログに含めない
CLAUDE.mdの配置場所と適用範囲
配置場所によって、指示が適用される範囲が変わります。
| 配置場所 | 主な用途 | 適用範囲 |
|---|---|---|
./CLAUDE.md |
チームで共有するプロジェクトルール | そのプロジェクト |
~/.claude/CLAUDE.md |
個人の好みや共通ルール | 自分が扱う全プロジェクト |
サブディレクトリ内のCLAUDE.md |
特定領域だけの追加ルール | その配下の作業 |
通常はリポジトリのルートにCLAUDE.mdを置き、Gitでチーム共有します。個人的な回答スタイルなど、チームに共有する必要がない設定は~/.claude/CLAUDE.mdに分けると管理しやすくなります。
Claude Codeは作業ディレクトリから上位階層の指示を読み込みます。また、サブディレクトリ内のファイルを扱う際は、その階層にあるCLAUDE.mdも参照します。大規模なプロジェクトでは、共通ルールをルートに、固有ルールを各サブディレクトリに置くと整理できます。
CLAUDE.mdの作り方
/initでひな型を作る
対象プロジェクトでClaude Codeを起動し、次のコマンドを実行します。
/init
Claude Codeがプロジェクトを調べ、CLAUDE.mdのひな型を作成します。生成された内容はそのまま使わず、実際のコマンドや規約に合っているか確認してください。
手動で作成する
プロジェクトのルートにCLAUDE.mdという名前のテキストファイルを作り、Markdownで指示を書くだけでも利用できます。ファイル名の大文字・小文字や配置場所を間違えないようにしましょう。
/memoryで読み込み状況を確認する
現在読み込まれているメモリーファイルを確認したい場合は、Claude Codeで次を実行します。
/memory
意図したCLAUDE.mdが表示されない場合は、現在の作業ディレクトリとファイルの配置を確認します。
すぐ使えるCLAUDE.mdテンプレート
最小構成のテンプレート
小規模なプロジェクトでは、目的・主要コマンド・注意点が分かれば十分です。
# Project overview
このリポジトリは〇〇を管理するプロジェクトです。
## Commands
- 開発: `npm run dev`
- テスト: `npm test`
- ビルド: `npm run build`
## Rules
- 既存の設計と命名規則に合わせる
- 修正範囲を必要最小限にする
- 作業後に変更内容とテスト結果を日本語で報告する
WordPressサイト向けテンプレート
# WordPress project instructions
## Environment
- 本番サイトを直接編集する前に対象ページを確認する
- URLのスラッグは明示的な指示がない限り変更しない
- 既存テーマとプラグインの仕様を優先する
## Content rules
- 読者の検索意図に最初に答える
- 見出しはH2から始め、階層を飛ばさない
- 内部リンクは文脈に合うページだけを設定する
- 根拠のない実績、体験談、数値を作らない
## Verification
- 更新後に公開ページを開いてタイトルと本文を確認する
- リンク切れとスマートフォン表示を確認する
JavaScript・TypeScript向けテンプレート
# Development guide
## Stack
- TypeScript
- Node.js
- React
## Commands
- Install: `npm ci`
- Lint: `npm run lint`
- Test: `npm test`
- Build: `npm run build`
## Coding rules
- TypeScriptの`any`は原則使わない
- 既存のフォーマッター設定に従う
- 新しい依存関係の追加前に理由を説明する
- APIキーや個人情報をコミットしない
## Definition of done
- 関連テストが成功している
- 型エラーとリントエラーがない
- 変更したファイルと確認結果を報告する
CLAUDE.mdに書くべき内容
効果が高いのは、Claude Codeがリポジトリだけを見ても判断しにくい情報です。
- 正式なテスト・ビルドコマンド
- チーム固有の命名規則
- 変更時に必ず確認するファイル
- 禁止されている操作や依存関係
- 完了条件と報告してほしい項目
- モノレポ内の各パッケージの役割
「きれいなコードを書く」のような抽象的な指示より、「変更後にnpm run lintと対象テストを実行する」のように、確認可能な指示にします。見出しと箇条書きを使い、1項目を短くすると読みやすくなります。
CLAUDE.mdとAuto memoryの違い
どちらもセッションをまたいで情報を引き継ぐ仕組みですが、書く人と用途が異なります。CLAUDE.mdは利用者が明示的に作る指示書、Auto memoryはClaudeが修正内容や好みから蓄積するメモです。公式ドキュメントでは、両方とも会話開始時にコンテキストとして読み込まれると説明されています。
| 項目 | CLAUDE.md | Auto memory |
|---|---|---|
| 書く人 | 利用者・チーム | Claude |
| 主な内容 | 規約、作業手順、構成、禁止事項 | 修正から得た学び、デバッグ情報、好み |
| 向く用途 | 毎回必ず共有したい前提 | 作業中に見つかった知見の蓄積 |
ここで大切なのは、CLAUDE.mdが強制設定ではなく「文脈」である点です。絶対に実行させたくない操作は、文章だけに頼らず権限設定やPreToolUse hookなどの仕組みで制御します。
CLAUDE.local.mdと.claude/rules/の使い分け
1つのCLAUDE.mdが長くなったら、目的に応じて分割します。個人的なテストデータやローカル環境の注意点はCLAUDE.local.mdへ、特定のファイルだけに適用する規約は.claude/rules/へ移すと、チーム共有ルールが読みやすくなります。
./CLAUDE.md：プロジェクト全体で共有する標準./CLAUDE.local.md：その作業環境だけで使う個人設定。通常は.gitignoreへ追加~/.claude/CLAUDE.md：すべてのプロジェクトに共通する個人設定.claude/rules/*.md：テーマ別またはパス別のルール
たとえばTypeScriptファイルだけに適用する規約なら、ルールファイルのYAMLフロントマターへpaths: ["**/*.ts"]を設定できます。多段の手順や、必要なときだけ参照したい知識は、常時読み込ませずSkillsへ分ける方法もあります。
CLAUDE.mdは何行まで書くべきか
公式ドキュメントは、1ファイルあたり200行未満を目安にしています。長いほど高性能になるわけではありません。CLAUDE.mdは会話と同じコンテキストを消費し、情報が増えすぎると重要な指示が埋もれやすくなります。
削る基準は「Claudeがリポジトリを見れば分かるか」「毎回の作業で必要か」「行動を確認できる指示か」の3点です。詳細な設計背景はREADMEや設計文書へ置き、CLAUDE.mdから@path/to/fileで参照します。矛盾する古いルールも定期的に削除しましょう。
書かないほうがよい内容
次の情報はCLAUDE.mdに保存しないでください。
- APIキー、パスワード、秘密鍵
- 顧客や従業員の個人情報
- 頻繁に変わり、すぐ古くなる情報
- 実際の設定と矛盾する長大な説明
- 同じ内容の重複した指示
秘密情報は環境変数や適切なシークレット管理機能で扱います。また、古い指示は誤作業の原因になるため、コードレビューと同様に定期的に見直しましょう。
@pathで他のファイルを読み込む
CLAUDE.mdから別ファイルを参照したい場合は、@path/to/file形式でインポートできます。
# Project instructions
- 共通の開発ルールは @docs/development-guide.md を参照
- API仕様は @docs/api-conventions.md を参照
ホームディレクトリを基準にしたパスや相対パスも利用できます。インポートは再帰的に処理されますが、深さには上限があります。コード例として記載しただけの@pathが誤って読み込まれないよう、コードフェンス内の記述はインポートとして評価されません。
ルールを複数のファイルに分けすぎると全体像が分かりにくくなります。まずは1つのCLAUDE.mdで始め、複数チームで共有する規約など、明確な理由がある部分だけを分割するとよいでしょう。
CLAUDE.mdが効かないときの確認ポイント
ファイル名と場所を確認する
CLAUDE.mdの綴りと大文字・小文字、現在の作業ディレクトリを確認します。別のプロジェクト階層でClaude Codeを起動していると、意図したファイルが対象にならないことがあります。
/memoryで実際の読み込みを確認する
推測で直す前に/memoryを実行し、対象ファイルが一覧にあるか確認します。読み込まれていなければ配置を、読み込まれているのに反映されなければ指示の具体性や競合を見直します。
矛盾する指示を整理する
ユーザー共通設定、プロジェクトの設定、サブディレクトリの設定に矛盾がないか確認します。同じルールを複数箇所に書くより、責任を持つファイルを1つ決めるほうが保守しやすくなります。
指示を短く具体的にする
長い背景説明の中に重要なルールが埋もれている場合は、見出しと箇条書きで整理します。「できれば」ではなく、「変更後は必ずテストを実行する」のように行動を明確にします。
よくある質問
CLAUDE.mdはGitにコミットしてもよいですか？
チーム共通のプロジェクトルールであれば、ルートのCLAUDE.mdをGitにコミットして共有する運用が適しています。ただし、秘密情報や個人専用の設定は含めないでください。
README.mdとの違いは何ですか？
README.mdは主に人間向けの導入資料です。CLAUDE.mdはClaude Codeが作業時に参照する具体的な指示を記載します。重複を避けるため、詳しい説明は既存ドキュメントに置き、CLAUDE.mdから参照する方法もあります。
CLAUDE.mdは長いほど効果がありますか？
長さよりも、正確さと具体性が重要です。古い情報や曖昧なルールが増えると判断を迷わせます。最小構成から始め、繰り返し発生する問題だけを追加してください。
ルールを変更したらClaude Codeを再起動する必要がありますか？
現在のセッションでの読み込み状態は/memoryで確認できます。変更が確実に反映された状態で作業したい場合は、内容を保存したうえで新しいセッションを開始するのが分かりやすい方法です。
まとめ
CLAUDE.mdには、Claude Codeがプロジェクトで迷いやすい判断基準を短く具体的に書きます。まずはルートに最小構成のファイルを作り、/memoryで読み込みを確認してください。運用中に繰り返し指示した内容だけを追加すると、保守しやすく実用的な設定になります。
Claude Codeを初めて使う方は、Claude Codeの始め方もあわせて確認してください。さらに活用したい場合は、CLAUDE.mdとSkillsの実践ガイドやClaude Codeを効率化するコツも参考になります。
公式仕様は、AnthropicのClaude Codeメモリー（CLAUDE.md）とClaude Codeドキュメントで最新情報を確認できます。
コメント