10秒でいうと
毎回のセッションで最初に読まれるファイルです。
毎回読まれるということは、毎回トークンを使うということ。200行を目安に絞ります。
第3章のNo.25で「毎回言うことは書いて置く」と書きました。Claude Codeでの、その置き場所が CLAUDE.md です。
本ガイドのリポジトリにもあります。文体、見出し規約、フロントマターの定義、公式情報の確認先。このページを書いている今も読み込まれています。
どこに置くと何に効くか
公式ドキュメントの表です。下ほど範囲が狭く、あとから読まれます。
| 場所 | 範囲 | 共有先 |
|---|---|---|
| 組織のポリシー位置 | そのマシンの全セッション | 組織全員（除外できない） |
~/.claude/CLAUDE.md |
自分の全プロジェクト | 自分だけ |
./CLAUDE.md または ./.claude/CLAUDE.md |
このプロジェクト | チーム（Gitで共有） |
./CLAUDE.local.md |
このプロジェクト・自分だけ | 自分だけ（gitignore対象） |
見つかったものは上書きではなく連結されます。上のディレクトリから順に読まれ、起動した場所のものが最後に来ます。
使い分けの目安。チームで守るべきことはプロジェクトへ、自分の好みは ~/.claude/ へ、自分だけのこのプロジェクト用は CLAUDE.local.md へ。最後のものは .gitignore に入れてください。
何を書くか
毎回のセッションで持っていてほしい事実だけです。
- ビルドとテストのコマンド
- コードの規約（具体的に）
- プロジェクトの構成（どこに何があるか）
- 「必ずこうする」というルール
公式は追記のタイミングも示していて、これが実用的です。
- 同じ間違いを2回目にしたとき
- レビューで「これは知っておくべきだった」が出たとき
- 前のセッションと同じ訂正を打ったとき
- 新しいメンバーが同じ説明を必要とするとき
2回目というのが要点です。1回目は事故、2回目からは仕組みの問題です。
何を書かないか
手順は書きません。多段階の手続きや、コードベースの一部でしか効かないことは、スキル（No.40）かパス限定のルールへ移します。
理由は明快で、CLAUDE.md は毎回読み込まれるからです。PRレビューの詳しい手順を書いておくと、無関係な作業のときもそのトークンを払い続けます。
公式は200行を目安としていて、それを超えると文脈を食い、守られにくくなるとしています。長いほど効かなくなる、というのは直感に反しますが、実感とも合います。
書き方
公式が挙げている4点が、そのまま効きます。
具体的に。「きれいに書く」ではなく「インデントは2スペース」。検証できる粒度まで下ろします。
構造をつける。見出しと箇条書きで整理する。人が読みやすい構造は、Claudeにとっても読みやすい。
矛盾させない。2つのルールが衝突すると、どちらかが勝手に選ばれます。定期的に読み返して、古い行を消す。
強制ではないと知っておく。これが最も重要です。公式ははっきり書いています。CLAUDE.md は文脈であって、強制される設定ではありません。
必ず実行させたい処理は、
CLAUDE.mdではなくフックで書く。
本ガイドの制作でも同じ結論に至りました。同じ書式のルールを1日に3回破ったので、指示書に強く書き直すのをやめて、投稿前の検査プログラムに組み込みました（No.25、No.41）。
自動メモリ
CLAUDE.md とは別に、Claudeが自分で書く記憶があります。既定で有効です。
保存されるのは4種類。あなたの役割や好み、あなたが与えた訂正、コードから読み取れないプロジェクトの事情、外部の参照先。コードベースから分かることや、CLAUDE.md にすでに書いてあることは保存しません。
置き場所は ~/.claude/projects/<プロジェクト>/memory/ で、プレーンなMarkdownなので読めるし消せます。/memory で一覧を開けます。
| CLAUDE.md | 自動メモリ | |
|---|---|---|
| 書く人 | あなた | Claude |
| 中身 | 指示とルール | 学んだことと癖 |
| 共有 | Gitでチームへ | そのマシンだけ |
マシンローカルなので、チームでは共有されません。共有したいことは CLAUDE.md に書いてください。
やってみよう：CLAUDE.mdを健康診断する（5分）
すでに
CLAUDE.mdがあるプロジェクトで試してください。プロンプト
“`
CLAUDE.md を読んで、次を判定してください。・コードベースを読めば分かることが書かれている行（削除候補）
・手順になっていて、スキルへ移すべき行
・「注意する」で終わっていて、実際には守られない行
・他の行と矛盾している行直さないでください。指摘だけお願いします。
“`期待される結果：4分類で指摘が返る。削除候補が意外に多い。
うまくいかないとき：
/doctorでも似た点検ができます。コードベースから分かる内容を削り、経緯や規約を残す提案をしてくれます。
つまずきポイント
足すだけで消さない。失敗のたびに1行足すと、半年で読む気の起きない文書になります。足したら、どれかを消せないか考える。
説明を書く。「なぜこうするか」を長く書くと、毎回そのぶん払います。理由は1行に留めてください。
守られると思い込む。文脈であって強制ではありません。確実にやってほしいことはフックへ。
読み込まれているか確認しない。/context の「Memory files」に出ていなければ、Claudeは見ていません。
まとめ
- 置き場所は4段階。チームのことはプロジェクト、好みは
~/.claude/ - 書くのは毎回持っていてほしい事実。手順はスキルへ
- 200行が目安。長いほど効かなくなる
- 文脈であって強制ではない。必ず走らせたい処理はフックで
次に読む
※本記事の情報は 2026年8月時点のものです。