Claude CodeのCLAUDE.md入門|プロジェクトルールを短く保つ設計
CLAUDE.mdの役割、置き場所、最小テンプレート、分割方法、読み込み確認、古いルールを削除する基準を初心者向けに解説します。
Claude Codeへ毎回「このコマンドを使う」「このフォルダは変更しない」と説明する代わりに使えるのがCLAUDE.mdです。プロジェクト固有の約束をMarkdownで残し、別の会話でも読み込ませられます。
ただし、長いほど良いわけではありません。CLAUDE.mdは強制設定ではなく、Claudeへ渡す文脈(=作業の前提になる情報)です。この記事では、短く、具体的で、検証できるルールへ絞る方法を解説します。
CLAUDE.mdは毎回必要なルールを渡す場所
CLAUDE.mdに向くのは、検査コマンド、命名規則、変更禁止領域など、作業のたびに変わらない情報です。毎回の会話には、そのときだけの目的、対象ファイル、完成条件を書きます。
次のように分けると迷いません。
- CLAUDE.md: 「検査には
npm run checkを使う」「コード内コメントは日本語で書く」 - 会話の指示: 「記事詳細ページの見出し崩れを直す」「今回はCSSだけを変更する」
今回だけの期限や作業メモは、次の作業では古い情報になります。反対に、恒久ルールを会話だけで伝えると毎回説明が必要です。Anthropic公式のメモリ解説は、追記する目安として「同じ誤りが2回起きた」「前のセッションと同じ訂正をまた入力した」を挙げています。この目安に当てはまる情報だけをCLAUDE.mdへ移すと、自然に短く保てます。
普段の依頼を具体的にする方法は、Claude Codeへの指示の書き方でも確認できます。
なお、CLAUDE.mdは安全装置ではありません。公式の権限設定の解説は、CLAUDE.mdの指示はClaudeの行動を導くが、Claude Codeが許可する操作そのものは変更しないと明記しています。削除禁止などを技術的に止めたい場合は、後述する権限設定やHooksを使います。
置き場所を共有範囲で決める
チームで共有するプロジェクトルールは、リポジトリ直下の./CLAUDE.mdまたは./.claude/CLAUDE.mdに置けます。Gitで共有すれば、同じリポジトリを使う人が共通の指示を利用できます。すべてのプロジェクトで使う個人ルールは~/.claude/CLAUDE.md、そのプロジェクトだけの個人メモは./CLAUDE.local.mdが候補です。
読み込みの順番も知っておくと混乱しません。Claude Codeは、起動した作業ディレクトリから親フォルダの方向へCLAUDE.mdを探し、見つかったファイルを上書きではなく連結して読み込みます。順番はファイルシステムのルート側(=上の階層)が先、作業ディレクトリ側が後です。下位フォルダのCLAUDE.mdは、その中のファイルを読むときに読み込まれます。内容が矛盾すると、Claudeがどちらに従うかは保証されません。階層をまたいで同じテーマのルールを書くときは、片方に寄せます。
配置先の比較表
| 目的 | 配置先 | 共有範囲 | 書く内容の例 |
|---|---|---|---|
| 全プロジェクトで使う個人設定 | ~/.claude/CLAUDE.md | 自分だけ | 表記、普段使うツール |
| チーム共通のプロジェクト設定 | ./CLAUDE.mdまたは./.claude/CLAUDE.md | リポジトリ利用者 | 検証コマンド、設計方針 |
| そのプロジェクトだけの個人設定 | ./CLAUDE.local.md | 自分だけ | ローカル環境固有のメモ |
| 特定のファイルやフォルダ向けの設定 | ./.claude/rules/*.md | ファイルの管理方法による | フロントエンドだけの規則 |
CLAUDE.local.mdを共有リポジトリで使うときは、誤ってコミットしない設定が要ります。方法は2つあります。GitHub公式の解説によると、チーム全員に同じ除外を配りたいならルートの.gitignoreへ、自分の手元だけで除外したいなら.git/info/excludeへ書きます。CLAUDE.local.mdは個人メモなので、.git/info/excludeのほうが向く場面もあります。
1つ注意があります。Gitの公式ドキュメントにあるとおり、ignore設定は「まだ追跡していないファイル」だけに効きます。すでにコミットしてしまったファイルは、ignoreへ書き足しても追跡対象や過去の履歴から消えません。誤ってコミットした場合は、追跡の解除と履歴の確認を別に行う必要があります。
APIキー、パスワード、実トークンは、どのCLAUDE.mdにも書きません。
最初は「プロジェクト情報・変更範囲・検証」の3種類だけ書く
最初から完全な規則集を作る必要はありません。公式のベストプラクティスは、CLAUDE.mdを短く人が読める形に保ち、コードから推測しにくいコマンド・規則・注意点へ絞るよう案内しています。まずは次の3種類だけ書きます。
- プロジェクト情報: コードを見ても分からない前提(何のサイトか、どの構成か)。
- 変更範囲: 触ってよい場所と、触ってはいけない場所。
- 検証: 変更後に実行するコマンドと、失敗したときの約束。
# プロジェクト概要
- Astroで作る静的サイトです。
# 変更ルール
- 指定されたファイル以外は変更しないでください。
- 秘密情報をコード、ログ、記事へ書かないでください。
# 検証
- TypeScriptを変更したら `npm run check` を実行してください。
- 失敗した場合は、エラーを隠さず報告してください。
良いルールは、守れたか判定できます。「きれいに書く」ではなく「インデントは2空白」、「十分に検査する」ではなく「変更後にnpm run checkを実行する」と書きます。コマンドは、実際に使えることを確かめてから記載します。ゼロから書くのが大変なら、/initでプロジェクトを分析した土台を作らせてから削る方法もあります。
1行ずつ「削るとClaudeの失敗が増えるか」で見直す
長すぎるCLAUDE.mdは、会話で使える文脈を消費し、重要なルールが埋もれる原因になります。公式資料は1ファイル200行未満を目標として示していますが、これは製品の強制上限ではありません。長くても全文が読み込まれます。だからこそ、行数合わせではなく中身で削ります。
判断の物差しは1つです。その1行を削ったとき、Claudeの失敗が増えるかどうか。増えないなら削除候補です。公式が挙げる削除候補は次のとおりです。
- コードを読めば分かる説明(フォルダ構成の逐一の解説など)
- その言語では当たり前の標準的な慣習
- バージョン番号など変わりやすい情報
- 長いチュートリアルや手順書の全文
- ほかの行と重複・矛盾する記述、今は使わないコマンド
たとえば、次の文章は情報が混ざっています。
このプロジェクトでは品質を大切にしているため、変更するときは
必要に応じて各種テストを行い、既存の雰囲気を壊さず、関係のない
場所にはなるべく触れないよう十分注意して作業してください。
判定できる形へ圧縮すると、次の3行になります。
- 変更前に対象ファイルを列挙してください。
- 指定外のファイルは変更しないでください。
- 変更後に `npm run check` を実行してください。
長い指示が失敗を招きやすい理由と削り方は、Claude Codeへの指示が長すぎると失敗する理由も参考になります。
長くなったら読み込む範囲とタイミングを分ける
削っても足りないときは、置き場所を分けます。ここで大事なのは「いつ読み込まれるか」の違いです。
@docs/testing.mdのような@インポート(=別ファイルの読み込み)は、ファイルの整理には役立ちます。ただし、読み込んだ先も起動時の文脈へ入るため、分割しただけでは情報量は減りません。インポートは最大4段まで再帰できますが、節約策ではないと覚えてください。
特定のファイルだけに必要な規則は、.claude/rules/のパス指定ルールへ移します。ルールファイルのpaths指定に一致するファイルをClaudeが読むときだけ読み込まれるので、起動時の文脈を圧迫しません。
繰り返し使う長い手順や参照資料は、Skill(=必要なときだけ読み込まれる手順書)へ移せます。公式のSkills解説によると、Skill本文は使われるときだけ読み込まれます。CLAUDE.md内の手順が長くなった場合の移し先として公式も挙げています。
分け方の早見表
| 手段 | 読み込まれるタイミング | 向いている内容 |
|---|---|---|
| CLAUDE.md本文 | 毎回、起動時 | 毎回の作業で必要な短いルール |
@インポート | 毎回、起動時(節約にはならない) | 本文の整理・分割 |
.claude/rules/*.md(paths指定) | 対象ファイルを読むときだけ | 特定フォルダだけの規則 |
| Skill | そのSkillを使うときだけ | 長い手順書・参照資料 |
| 権限設定(permissions) | 常に強制される | 禁止・確認必須の操作 |
読み込み・効き目・強制を別々に確かめる
ファイルを置いただけで完了にせず、3段階で確認します。
- 読み込みの確認。Claude Codeのセッションで
/contextを実行し、Memory filesの一覧に対象のCLAUDE.mdがあるかを見ます。なければ、起動したディレクトリ、ファイル名、配置階層を順に見直します。/memoryは役割が別で、CLAUDE.mdや自動メモの場所を一覧して開くためのコマンドです。中身を編集したいときに使います。 - 効き目の確認。小さな依頼で動作を試します。
このプロジェクトで変更後に実行する検証コマンドを答えてください。
実際のファイル変更はしないでください。
期待するコマンドが返るかを見た後、実作業では実行結果まで確認します。テストの終了コードや出力など、合否を読める証拠を完成条件にします。
- 強制の確認。絶対に止めたい操作は、CLAUDE.mdではなく権限設定で守ります。権限ルールはdeny(禁止)、ask(確認)、allow(許可)の順で評価されます。設定方法はClaude Codeの権限設定とClaude CodeのHooks検診で確認できます。
指示が効かないときは、文章を追加する前に、曖昧な表現、似たルールの重複、別階層のCLAUDE.mdとの矛盾を調べます。強い言葉を重ねるより、短く具体化するか、強制可能な設定へ移すほうが効きます。
よくある質問
CLAUDE.mdはどこに置けばよいですか
チームで共有するなら、リポジトリ直下の./CLAUDE.mdまたは./.claude/CLAUDE.mdが分かりやすい選択です。全プロジェクト共通の個人設定は~/.claude/CLAUDE.md、そのプロジェクトだけの個人メモは./CLAUDE.local.mdへ分けます。
CLAUDE.mdは何行まで書けますか
強制的な行数上限はありません。公式資料は1ファイル200行未満を目標として示していますが、長くても全文が読み込まれます。200行だけを合否にせず、各行が毎回必要か、重複や矛盾がないかで削ります。仕様や推奨値は変わることがあるので、2026-07-26時点の公式ドキュメントで最新の案内を確認してください。
CLAUDE.mdが読み込まれたか確認するにはどうしますか
/contextを実行し、Memory filesの一覧に対象ファイルがあるかを確認します。/memoryは指示ファイルや自動メモの場所を一覧して開くためのコマンドで、読み込みの確認とは役割が違います。
READMEの内容をCLAUDE.mdへ全部コピーしてよいですか
避けたほうが管理しやすくなります。READMEは人がプロジェクトを理解するための説明、CLAUDE.mdはClaudeが作業時に守る具体的な指示へ絞ります。@でREADMEをインポートしても起動時の文脈へ全部入るため、量の問題は解決しません。Claudeが判断に使う要点だけを書きます。
CLAUDE.mdに書けば禁止操作を確実に防げますか
防げません。CLAUDE.mdは行動を導く文脈であり、Claude Codeが許可する操作そのものは変更しないためです。特定のツール、コマンド、ファイル操作を止める必要がある場合は、deny・ask・allowの権限ルールやHooksを併用します。
まとめ
CLAUDE.mdには「毎回必要で、コードから推測しにくく、守れたか判定できるルール」だけを残します。次の3つから始めてください。
- プロジェクト情報・変更範囲・検証コマンドの3種類だけで、まず短いCLAUDE.mdを作る(
/initの土台を削ってもよい)。 /contextで読み込みを確認し、小さな質問で検証コマンドが返るかを試す。- 200行に近づいたら、1行ずつ「削ると失敗が増えるか」で削り、対象限定の規則は
.claude/rules/へ、長い手順はSkillへ、禁止事項は権限設定へ移す。
公式一次情報
確認日: 2026-07-26
- How Claude remembers your project(Anthropic公式): CLAUDE.mdの配置先、連結される読み込み順、
@インポート(最大4段)、.claude/rules/、/contextと/memoryの役割、200行未満の目標を説明。 - Best practices for Claude Code(Anthropic公式): CLAUDE.mdを短く保つ基準と、各行を削除したら失敗が増えるかで見直す考え方、削除候補の種類を説明。
- Extend Claude with skills(Anthropic公式): 繰り返す手順や長い参照資料をSkillへ分けると、本文は使われるときだけ読み込まれる仕組みを説明。
- Configure permissions(Anthropic公式): deny・ask・allowの評価順と、CLAUDE.mdの指示は許可される操作自体を変更しないことを明記。
- Ignoring files(GitHub Docs): 共有する除外規則は
.gitignoreへ、共有しないローカル専用の除外規則は.git/info/excludeへ書けることを説明。 - gitignore Documentation(Git公式): ignore設定は未追跡ファイルだけに効き、すでに追跡されているファイルには影響しないことを定義。
続き(結論と実データ)はnoteに置いています
ここでは手順のところまで書きました。実際に出た数字、うまくいかなかった条件、そのまま使える設定ファイルは、 note の記事にまとめてあります。