Claude Code を使っていて、こう思ったことはないですか。
「さっき直したはずのことを、また同じようにやってる」「毎回プロジェクトの前提を説明し直すのが面倒」。
その原因はだいたい CLAUDE.md を書いていない、または書き方がよくないからです。この記事では、AIにちゃんと「伝わる」CLAUDE.md の書き方を、公式の仕様に沿って整理します。
結論（先に要点）
-
CLAUDE.mdは 毎回のセッション開始時に自動で読み込まれる指示書 - 置き場所によってスコープが変わる（ユーザー全体 / プロジェクト / ローカル）
- 効くコツは3つ：200行以内・具体的に書く・矛盾させない
- まずは
/initで自動生成、そこから育てるのが王道
こんな人向け
- Claude Code は使えるが
CLAUDE.mdはまだ書いていない - 書いてはいるが、あまり効いている実感がない
-
copilot-instructions.mdやAGENTS.mdとの違いが分からない
そもそも CLAUDE.md とは
Claude Code は毎回のセッションをまっさらなコンテキストで始めます。つまり前回の会話は覚えていません。そこで、セッションをまたいで持たせたい指示を書いておくのが CLAUDE.md です。プレーンなMarkdownで書いておくと、Claudeがセッション開始時に読み込みます。
ポイントは、これは**「強制設定」ではなく「コンテキスト」**だということ。Claudeは読んで従おうとしますが、絶対強制ではありません。だからこそ「いかに伝わるように書くか」が効きます。
Step 1. まず /init で雛形を作る
ゼロから書く必要はありません。プロジェクトのルートで /init を実行すると、Claudeがコードベースを解析して、ビルドコマンドやテスト方法、規約を拾った CLAUDE.md を自動生成してくれます。
/init
💡 すでに
CLAUDE.mdがある場合、/initは上書きせず「改善案」を提案してくれます。安心して実行できます。
生成された雛形に、Claudeが自力で気づけない情報（チーム独自のルールなど）を足していく、という流れが公式の推奨です。
Step 2. 置き場所でスコープを使い分ける
CLAUDE.md は置く場所で適用範囲が変わります。読み込み順は「広いスコープ → 狭いスコープ」で、狭いほうが後に読まれます。
| スコープ | 置き場所 | 用途 |
|---|---|---|
| ユーザー全体 | ~/.claude/CLAUDE.md |
全プロジェクト共通の個人設定 |
| プロジェクト |
./CLAUDE.md または ./.claude/CLAUDE.md
|
チームで共有する設定（gitに入れる） |
| ローカル | ./CLAUDE.local.md |
個人のプロジェクト固有設定（.gitignore推奨） |
チーム共有したい規約は ./CLAUDE.md、自分専用のsandbox URLやテストデータは CLAUDE.local.md、という使い分けです。
Step 3. 「効く」書き方の3原則
ここが本題です。公式が挙げているコツを、実例つきで。
① サイズは200行以内に
CLAUDE.md は毎回コンテキストに丸ごと読み込まれます。長いほどトークンを食い、しかも指示の遵守率が下がります。目安は1ファイル200行以内。
② 具体的に、検証できる粒度で書く
これが一番効きます。曖昧な指示は守られません。
# 悪い例（曖昧）
- コードをきれいにフォーマットする
- 変更はテストする
- ファイルを整理する
# 良い例（具体的・検証可能）
- インデントはスペース2つ
- コミット前に `npm test` を実行する
- APIハンドラは `src/api/handlers/` に置く
「ちゃんとやる」ではなく「何をどうやるか」まで書く。これだけで挙動が変わります。
③ 矛盾させない
複数の CLAUDE.md（ルート、サブディレクトリ、.claude/rules/）で指示が食い違うと、Claudeはどちらかを勝手に選びます。定期的に見直して、古い・矛盾する指示は消しましょう。
Step 4. ファイルを分割する：@import と .claude/rules/
指示が増えてきたら分割できます。
@path 構文で別ファイルを取り込めます。
See @README for project overview and @package.json for available commands.
# Additional Instructions
- git workflow @docs/git-instructions.md
ただし注意。@import は「整理」には役立つが、コンテキスト削減にはならない（取り込んだファイルも起動時に丸ごと読み込まれる）。
本当にコンテキストを節約したいなら .claude/rules/ のパススコープルールが有効です。特定のファイルを触るときだけ読み込まれます。
---
paths:
- "src/api/**/*.ts"
---
# API開発ルール
- 全エンドポイントに入力バリデーションを入れる
- 標準エラーレスポンス形式を使う
これなら、APIファイルを触るときだけこのルールが読み込まれ、普段はコンテキストを消費しません。
ハマったポイント
書いたのに従ってくれない
/memory を実行して、その CLAUDE.md が実際に読み込まれているかをまず確認します。リストに出てこなければ、Claudeはそもそも見ていません。置き場所が正しいかチェックしてください。
/memory
それでも従わない場合は、だいたい「指示が曖昧」か「他のファイルと矛盾」のどちらかです。
AGENTS.md はどうなる？
Claude Code が読むのは CLAUDE.md であって AGENTS.md ではありません。すでに AGENTS.md を使っているなら、CLAUDE.md から取り込めば両立できます。
@AGENTS.md
## Claude Code 固有
- `src/billing/` 配下の変更は plan mode を使う
ここまでのまとめ
-
/initで雛形を生成 - 置き場所でスコープを使い分ける
- 200行以内・具体的・矛盾なし、の3原則
- 増えたら
@importか.claude/rules/で分割
応用：同じ CLAUDE.md を複数モデルで使うとき
CLAUDE.md を整えると、次に出てくるのが「この指示書、Claude だけじゃなく Codex や他のモデルでも同じように試したい」というニーズです。モデルごとに挙動を比較したい場面ですね。
そのとき地味に面倒なのが、モデルごとに別々のAPIキーやエンドポイントを管理すること。私の場合は、複数モデルを1つの窓口にまとめられる第三者APIゲートウェイ（EvoLink など）経由にして、同じ CLAUDE.md を使い回しながらモデルだけ切り替えています。キー管理が1本化されるので、比較検証がだいぶラクになります。
モデル切り替えの具体的な設定は別記事で詳しく書く予定です。
まとめ
冒頭の「また同じことをやってる」「毎回説明し直す」——これらはほぼ CLAUDE.md で解決します。
ポイントは「強制設定ではなくコンテキスト」だと理解すること。だから具体的に・短く・矛盾なく書くほど効きます。まずは /init で雛形を作って、/memory で読み込みを確認しながら育てていけば、Claude Code の使い心地は一段変わります。
参考（公式ドキュメント）