Claude Codeを使うたびに、開発コマンドやコーディング規約を説明していないでしょうか。指示を毎回入力しても、伝え漏れや表現の違いによって出力が安定しない場合があります。
CLAUDE.mdを用意すれば、プロジェクト構成、テスト手順、禁止事項などをセッションへ継続的に渡せます。ただし、配置場所や記述量を誤ると、指示の競合やコンテキストの浪費を招きます。
本記事では、CLAUDE.mdの役割、場所、作り方、ベストプラクティスを順に解説します。2026年時点の仕様を基準としていますが、提供状況は変わる可能性があるため、運用前にClaude Code公式ドキュメントも確認してください。
Claude CodeのCLAUDE.mdとは？
CLAUDE.mdは、Claude Codeへ毎回伝えたい前提やルールを保存するMarkdownファイルです。プロンプト、設定ファイル、自動メモとは役割が異なるため、何を任せられるか理解すると適切に運用できます。
継続指示を共有するMarkdownファイル
CLAUDE.mdは、Claude Codeへプロジェクト固有の指示を継続して伝えるファイルです。各セッションは新しいコンテキストで始まるため、チャットで伝えた規約が次回も引き継がれるとは限りません。リポジトリの構成、命名規則、テストコマンドを記録しておけば、作業開始時から同じ前提を参照できます。毎回必要になる情報を集約する用途に適しています。
繰り返す説明を毎回の会話から減らせる
何度も入力している説明はCLAUDE.mdへ移すと効率的です。会話ごとの指示が短くなり、実装内容や修正目的へ集中できます。保存に向く情報は次のとおりです。
- ビルド・テスト・静的解析のコマンド
- ディレクトリ構成と責任範囲
- 命名規則とコードスタイル
- 変更後に必要な確認作業
Reactプロジェクトなら、使用するパッケージマネージャーや型チェックの実行方法を記します。開発者が毎回補足している前提から移すと、効果を確かめやすくなります。
設定ファイルや自動メモとは役割が異なる
CLAUDE.mdは動作条件を機械的に設定するファイルではなく、Claudeへ渡す文脈です。似た仕組みとの違いを整理すると、書く内容を選びやすくなります。
| 仕組み | 主な役割 | 適した内容 |
|---|---|---|
| CLAUDE.md | 継続的な指示 | 規約・コマンド・構成 |
| 設定ファイル | クライアント動作の設定 | 権限・環境変数・機能設定 |
| 自動メモ | Claudeが蓄積する学習内容 | 修正履歴・利用者の好み |
| チャット | 今回だけの依頼 | 実装内容・調査対象・期限 |
永続的な規約はCLAUDE.md、今回限りの要望はチャットへ分けると、指示の責任範囲が明確になります。
禁止操作を強制する安全装置ではない
CLAUDE.mdに書いた指示は、必ず実行される強制設定ではありません。Claudeは内容を文脈として参照しますが、曖昧な指示や相互に矛盾する指示があれば判断が揺れる場合があります。削除コマンドの禁止や特定ファイルへのアクセス拒否を確実に適用したい場面では、権限設定、サンドボックス、PreToolUse Hookなども必要です。安全ルールの説明には使えますが、技術的な防止策とは分けて設計します。
Claude CodeのCLAUDE.mdはどこに置く？
CLAUDE.mdの場所によって、指示が適用される利用者やプロジェクトが変わります。グローバルな個人設定とチーム共有の規約を混在させず、必要な範囲へ配置するのが基本です。
用途別に4つの場所を選べる
配置場所は、誰に指示を共有するかで決めます。Claude Codeは複数階層のファイルを読み込むため、用途が異なる指示は分離してください。
| 範囲 | 主な場所 | 適した用途 |
|---|---|---|
| 組織 | OS別の管理用CLAUDE.md | 全社的な規約 |
| ユーザー | ~/.claude/CLAUDE.md |
個人共通の好み |
| プロジェクト | ./CLAUDE.md |
チーム共有の開発規約 |
| ローカル | ./CLAUDE.local.md |
個人用のプロジェクト設定 |
チームで共有する内容はリポジトリ直下、個人だけで使う内容はユーザーまたはローカルの範囲へ置くと管理しやすくなります。
上位階層から作業場所へ順に連結される
複数のCLAUDE.mdは、単純な上書きではなくコンテキストへ順番に加わります。起動した作業ディレクトリから祖先を探索し、ファイルシステムの上位側から作業場所側へ読み込まれる仕組みです。同じ階層では、CLAUDE.mdの後にCLAUDE.local.mdが追加されます。ただし、後から読まれた指示が必ず勝つわけではありません。内容を矛盾させず、適用範囲ごとに責任を分ける必要があります。
サブディレクトリの指示は必要時に加わる
作業ディレクトリより下にあるCLAUDE.mdは、起動時にすべて読み込まれるわけではありません。Claudeが対象ディレクトリ内のファイルを読み取り、作成、編集した段階で関連する指示が加わります。モノレポなら、フロントエンドとバックエンドで異なる規約を各ディレクトリへ配置できます。全体規約はルート、領域固有の規約は配下へ分けると、不要な指示でコンテキストを圧迫せずに済みます。
個人情報はCLAUDE.local.mdへ分ける
共有できない個人設定はCLAUDE.local.mdへ分離します。チーム用ファイルへ混ぜると、不要な環境差や機密情報がGitへ入る恐れがあります。
- 個人用サンドボックスの参照先
- ローカル環境だけの確認手順
- 個人固有のツール選択
- 共有不要なテストデータ名
CLAUDE.local.mdは通常、自分で.gitignoreへ追加します。対話型の/initで個人設定を選んだ場合を除き、自動登録を前提にせず、コミット対象を確認してください。
Claude CodeのCLAUDE.mdはどう作る？
最初から長い指示書を書く必要はありません。/initで初稿を作り、コードから判別できない規約を補足し、実際の出力を見ながら更新する流れが適しています。
/initで初稿を生成する
プロジェクトのルートでClaude Codeを起動し、/initを実行するとCLAUDE.mdの初稿を生成できます。Claudeがコードベースを調べ、ビルド、テスト、構成、規約の候補をまとめます。既存のCLAUDE.mdがある場合は、通常は上書きせず改善案を提示します。生成結果をそのまま採用せず、実在するコマンドか、現在の設計と一致するかを開発者が確認してください。/initは完成品ではなく、編集可能なたたき台として使います。
再説明した内容だけを選んで書く
CLAUDE.mdには、Claudeがコードを読んでも判断できない情報を優先して書きます。ファイルを見れば明らかな説明まで加えると、読む量だけが増えて指示の焦点がぼやけます。
- 過去に繰り返し修正した規約
- 新規参加者にも必要な前提
- 実行順を誤りやすい検証手順
- コードから推測できない設計判断
「同じ訂正を別セッションでも入力したか」を追加基準にすると、必要な情報を選別できます。再発を防ぎたい説明から小さく記録する方法が実用的です。
命令・背景・検証方法をセットにする
良い指示は、期待する動作を第三者が確認できる粒度になっています。「適切にテストする」のような表現では、実行範囲を判断できません。
| 項目 | 曖昧な記述 | 改善した記述 |
|---|---|---|
| 形式 | 正しく整形する | 保存前にnpm run lintを実行する |
| テスト | 十分に確認する | 変更箇所の単体テストを追加する |
| 配置 | 適切な場所へ置く | API処理はsrc/api/handlers/へ置く |
| 禁止 | 直接編集しない | 生成物ではなく生成元を修正する |
命令に背景や代替手段を添えると、想定外の状況でも目的に沿った判断を促せます。
/contextと監査で読み込みを確かめる
作成後は、指示が読み込まれているか確認します。Claude Code内で/contextを実行し、Memory filesに意図したファイルが表示されるか確かめてください。規約が反映されない場合は、起動位置、ファイル名、配置階層、矛盾する指示を順に調べます。対応バージョンでは/doctor prompt-auditを使い、古い記述や存在しないコマンドも監査できます。読み込みと内容の正しさを分けて検証すると、原因を絞れます。
Claude CodeのCLAUDE.mdをどう運用する？
効果を保つには、指示を短く具体的にし、用途に応じてルールやSkillsへ分けます。チームで採用する場合は、ソースコードと同じように変更内容をレビューし、古い情報を残さない運用が必要です。
200行未満を目安に絞り込む
CLAUDE.mdは短く保つほど指示の焦点が明確になります。公式ドキュメントでは、1ファイル200行未満が目安として示されています。長いファイルはコンテキストを消費し、Claudeが各指示へ従う精度を下げる場合があります。すべての設計資料を転記せず、毎回必要な判断基準だけを残してください。詳しい背景資料は別ファイルへ分け、必要な場面で参照する構成が適しています。
.claude/rules/で対象を限定する
特定のファイルやディレクトリだけに関係する規約は、.claude/rules/へ分けます。対象を限定すれば、関係のない作業へ指示が混ざる状態を避けられます。
| 条件 | 適した仕組み | 使用例 |
|---|---|---|
| 全作業で必要 | CLAUDE.md | 共通コマンド |
| 特定言語だけ | パス指定のRules | TypeScript規約 |
| 特定領域だけ | 配下のCLAUDE.md | API固有の設計 |
| 補足資料の参照 | @pathインポート |
Git運用資料 |
@pathは整理には役立ちますが、読み込んだ内容のコンテキスト消費量を減らす仕組みではありません。長文化への対策には、対象を限定するRulesが向いています。
Skillsは複数手順の作業へ使う
複数の工程をもつ手順や、必要時だけ参照する知識はSkillsへ分けます。CLAUDE.mdへすべて書くと、関係のないセッションでも長い説明が読み込まれます。
- リリース作業の確認手順
- コードレビューの評価基準
- 定型レポートの作成工程
- 特定ツールの操作ガイド
CLAUDE.mdには「毎回守る規約」、Rulesには「対象ファイル別の規約」、Skillsには「呼び出して使う作業手順」を置きます。読み込み頻度を基準に分けると、各仕組みの役割が明確です。
Gitレビューでチーム基準を育てる
チーム共有のCLAUDE.mdは、ソースコードと同じくGitで変更履歴を管理します。古いコマンドや矛盾する指示が残ると、Claudeの判断だけでなく開発者の理解も揺れます。実装レビューで同じ修正が繰り返された段階で規約を追加し、不要になった指示は削除してください。セキュリティ、法務、金銭に関係する出力はCLAUDE.mdへ任せきらず、担当者が最終確認します。継続的なレビューまで含めて運用設計と考えます。
Claude Code CLAUDE.mdのよくある質問（FAQ）
CLAUDE.mdを初めて作る際は、使用言語、長さ、機密情報、READMEとの違いで迷いやすいです。本文と重複しない疑問へ、実務で判断できる基準を示します。
CLAUDE.mdは日本語で書いてもよいですか？
CLAUDE.mdは日本語で書けます。Markdown形式の自然言語をClaudeが文脈として読むため、英語だけに限定されません。日本語の開発チームなら、曖昧な英訳を挟まず、普段使っている用語で規約を記したほうが認識をそろえられます。ただし、コマンド名、ファイルパス、変数名は実際の表記を変えずに記載してください。チームが正確にレビューできる言語を選ぶのが基本です。
CLAUDE.mdのおすすめの長さは何行ですか？
1ファイル200行未満が公式の目安です。ただし、200行まで埋める必要はなく、毎回必要な情報だけで目的を満たせる長さが適しています。短いプロジェクトなら、開発コマンド、構成、規約、検証手順だけで十分です。長くなった場合は、単純にインポートへ移すだけでなく、対象別のRulesや必要時に呼び出すSkillsへ分割します。行数よりも、指示の関連性と矛盾のなさを優先してください。
CLAUDE.mdにAPIキーを書いてもよいですか？
APIキー、パスワード、アクセストークン、秘密鍵は書かないでください。プロジェクト用のCLAUDE.mdはGitで共有される場合があり、履歴へ残ると削除後も漏えいリスクが続きます。認証情報は環境変数や認証情報管理サービスへ保存し、CLAUDE.mdには変数名と安全な利用手順だけを記載します。機密情報が必要な作業でも、値そのものと操作ルールを分離する運用が必要です。
CLAUDE.mdとREADME.mdの違いは何ですか？
CLAUDE.mdはClaude Codeへ継続指示を渡すファイル、README.mdは人間へプロジェクト概要を伝える文書です。セットアップ方法など共通する情報はありますが、読者と目的が異なります。READMEには利用者向けの導入説明、CLAUDE.mdには編集時の規約や検証コマンドを置くと整理できます。同じ説明を二重管理したくない場合は、CLAUDE.mdから@README.mdを参照できますが、内容が毎セッション必要か確認してから採用してください。
Claude Code CLAUDE.mdのまとめ
CLAUDE.mdは、Claude Codeへプロジェクトの規約やコマンドを継続して伝える指示ファイルです。チーム共通の内容はリポジトリ直下、個人設定はユーザー領域やCLAUDE.local.mdへ分けます。/initで初稿を作り、/contextで読み込みを確認しながら、繰り返し必要になる情報だけを追加してください。領域別の規約はRules、必要時だけ使う手順はSkills、強制したい安全制御は権限設定やHookへ分けると、短く矛盾のない状態を保てます。
コメント