「テストの前にlintを走らせて」「パッケージマネージャはpnpm」「自分はバックエンド担当」。Claude Codeを開いて最初にやることが、この手の再説明になっている人は多い。挨拶より先に業務連絡である。セッションをまたぐと会話の中身は消えるので、何もしなければ毎回ゼロからの説明になる。
Claude Codeにはセッションをまたいで知識を残す仕組みが2つある。あなたが書く「ルールの書類」であるCLAUDE.mdと、Claude自身が書く「学習ノート」であるauto memoryだ。名前だけ見るとどちらも「記憶」に見えるので、「auto memoryがあるなら、もう説明しなくていいよね？」と期待したくなる。ところが、誰が書き、いつ読まれ、誰に届くかがまるで違う。この違いを押さえないと、覚えてほしいことがCLAUDE.mdに溜まり、守ってほしいことがmemory任せになる（そして「言ったはずなのに」が毎日起きる）。
この記事は公式ドキュメントの記述を土台に、CLAUDE.md・rules・auto memory・Skillsの4つを比較表と判断フローに落とす。前提はClaude Code（Pro $20/月、Max $100〜200/月）を日常的に使っていることだけだ。
Claude Code auto memoryとは — Claudeが自分で書く学習ノート
auto memoryはデフォルトで有効で、保存先は ~/.claude/projects/<project>/memory/ だ。同じgitリポジトリのworktreeやサブディレクトリは、この1つのディレクトリを共有する。
中身はインデックスの MEMORY.md と、トピック別のファイルに分かれる。
~/.claude/projects/<project>/memory/
├── MEMORY.md # インデックス。毎セッション先頭部を読む
├── user_role.md # 役割・嗜好
├── feedback_testing.md # テスト手法への修正
└── reference_api.md # 外部情報の場所
Claudeが自動で残すのは次の4種類だ。
- user: あなたの役割、専門領域、作業の好み
- feedback: あなたが与えた修正、承認した進め方
- project: 進行中の作業、期限、意思決定のうちコードやgit履歴から辿れないもの
- reference: issue trackerやダッシュボードなど、外部情報の場所
「保存する価値がある」とClaudeが判断したときだけ書くので、毎セッション新しいメモが増えるわけではない（あなたの独り言まで几帳面に書き留める後輩ではない）。逆に、コードやgit履歴から導出できる事実と、CLAUDE.mdに既に書いてあることはスキップされる。
読み込みには上限がある。セッション開始時に読まれるのは MEMORY.md の先頭200行または25KBのうち先に達した方までで、超過分は読まれず、短縮を促す警告が出る。MEMORY.md はあくまで目次であって、日記帳ではない。トピックファイルは開始時には読まれず、Claudeが必要と判断したときにオンデマンドで開く。
止めたいときは3通りある。
./.claude/settings.jsonに"autoMemoryEnabled": falseを書く- 環境変数
CLAUDE_CODE_DISABLE_AUTO_MEMORY=1を設定する - セッション中に
/memoryでトグルする
/memory はCLAUDE.md・CLAUDE.local.md・auto memoryの保存場所を一覧し、ファイルを選んでエディタで開ける管理画面でもある。古いメモはここから手で消してよい。というより、消すのはあなたの仕事だ。
CLAUDE.mdは「守らせる」ための書類
CLAUDE.mdはセッション開始時に必ず読まれる。読み込みは4階層で、上から順に適用される。
- Managed policy: 組織のITが配置する。macOSなら
/Library/Application Support/ClaudeCode/CLAUDE.md。全ユーザー・全プロジェクトに効き、除外できない - User:
~/.claude/CLAUDE.md。あなたの全プロジェクトに効く - Project:
./CLAUDE.mdまたは./.claude/CLAUDE.md。gitに入り、チームに共有される - Local:
./CLAUDE.local.md。個人用で、.gitignoreに入れる
サブディレクトリのCLAUDE.mdは、そのディレクトリで作業したときにオンデマンドで読まれる。@path 構文で他ファイルを埋め込むこともでき、再帰は最大4段階までだ。
書くべきは「毎セッション、Claudeが知っていないといけないこと」。ビルド・テストコマンド、コード規約、アーキテクチャの要点、「常に〇〇する」「〇〇は禁止」の原則、チームで決めたこと。逆に、コードから導出できる事実、そのセッション限りの嗜好、マルチステップの手順は書かない。
サイズは1ファイル200行未満が目安で、超えると遵守度が落ちる。4MiBを超えるファイルはスキップされる。長くなったときの逃がし先は2つある。
./.claude/rules/: CLAUDE.mdのモジュール化版。frontmatterにpaths: ["src/**/*.ts"]のようなglobを書くと、該当ファイルを読むときだけ読み込まれる。pathsがなければCLAUDE.mdと同じ優先度で常時読まれる- Skills:
SKILL.mdに手順や参考資料を書く。説明文だけがセッション開始時に読まれ、本文は/skill-nameで呼ぶかClaudeが必要と判断したときだけ読まれる。disable-model-invocation: trueにすると、明示的に呼ぶまでClaudeからは見えない
settings.jsonとの役割分担まで含めた話はCLAUDE.mdとsettings.jsonの使い分けにまとめている。本記事はauto memoryとの境界に絞る。
比較表: CLAUDE.md・rules・auto memory・Skills
| 項目 | CLAUDE.md | ./.claude/rules/ | auto memory | Skills |
|---|---|---|---|---|
| 書き手 | あなた | あなた | Claude | あなた |
| 読み込みタイミング | セッション開始時に常時 | 常時、または paths 一致ファイルを読むとき | 開始時に MEMORY.md 先頭200行/25KBのみ。他はオンデマンド | 説明文は常時、本文はオンデマンド |
| 共有範囲 | gitでチーム共有 | gitでチーム共有 | そのマシンのみ。同一リポジトリのworktree間では共有 | gitでチーム共有 |
| 向いている内容 | ビルドコマンド、規約、アーキテクチャの要点、チームの決めごと | 言語別・ディレクトリ別のルール | あなたの役割・好み、受けた修正、進行中の作業、参照URL | 複数ステップの手順、参考資料、チェックリスト |
| 向かない内容 | 一時的な嗜好、長い手順、参考資料 | プロジェクト全体のルール | コードから導出できる事実、CLAUDE.mdに既にある事項 | 毎回参照すべき基本ルール |
表で一番効くのは「共有範囲」の行だ。auto memoryはリポジトリに入らない。あなたのマシンでどれだけ学習が進んでも、その賢さはあなたのマシンから一歩も出ず、同僚のClaude Codeは何も知らない。
判断フロー: 毎回言い直していることはどこへ置く？
「守らせたい」の行き先がCLAUDE.mdで止まらず、hooksまで伸びている点だけ補足しておく。CLAUDE.mdもauto memoryも、Claudeが参照するコンテキストであって強制力のある仕組みではない。「テスト前に必ず型チェック」を絶対に飛ばさせたいなら、PreToolUse などのhooksで機械的に組み込む。memoryに書いたのに守られなかった、という不満の多くはここの取り違えだ（memoryは付箋であって、門番ではない）。
もう1つ、memoryに「任せる」と書いたのは、あなたが書くファイルではないからだ。役割や好みは会話の中で伝えれば、Claudeが価値ありと判断した分だけ残る。残るかどうかの最終判断はClaude側にあるので、確実に残したければ CLAUDE.local.md に自分で書く。
よくある置き間違い
1. そのセッション限りの指示をCLAUDE.mdに書く
# ./.claude/CLAUDE.md
このセッションは小規模リファクタ専用。型チェック後にコミットするとよい。
次のセッションでは無関係なのに毎回読まれ、コンテキストを食う。その場限りの指示はチャットで伝える。繰り返し必要になった時点で、チーム共通ならCLAUDE.md、個人の好みならauto memoryに任せる。
2. コマンド名をmemoryに覚えさせる
npm run test を npm run vitest に改名したのに、memoryが旧コマンドを推薦し続ける（本人は親切のつもりだ）。memoryの内容はコード変更に同期しない。書かれた時点で正しかった事実が、そのまま残る。コマンド名のような「コードから導出できる事実」はそもそもmemory向きではなく、CLAUDE.mdかコード自体に置く。古いメモは /memory から開いて消す。
3. チームに広めたい学びがmemoryに眠っている
「migrationは手で書かずgeneratorを使う」と何度も伝え、memoryには残った。しかし同僚のClaude Codeは、今日も元気に手書きのmigrationを提案してくる。memoryは ~/.claude/projects/ 配下のマシンローカルな場所にあり、リポジトリには入らない。チームで守らせたい決まりは、gitに入る ./CLAUDE.md か ./.claude/rules/ に昇格させる。
この3つはどれも「書く場所を間違えた」のではなく「読まれる範囲を見誤った」問題だ。「言ったはずなのに」が起きたら、まず誰に・いつ読まれる場所に書いたのかを確認するとよい。
まとめ
覚えさせるか守らせるかは、「誰が書くか」と「誰に届くか」で決まる。
- チームに届けたい規約・コマンド → gitに入る CLAUDE.md。パス限定なら
./.claude/rules/ - 時々使う長い手順・参考資料 → Skill にしてオンデマンド化
- 自分の役割・好み・進行中の作業 → auto memory に任せる。確実に残すなら
CLAUDE.local.md - 省略されると困る処理 → hooks で強制
まず「毎回言い直していること」を書き出して、上のフローに1つずつ通してみてほしい（書き出してみると、思ったより長いリストになる。それ自体が収穫だ）。CLAUDE.mdが200行を超えているなら、参考資料の部分をSkillに逃がすところから始めるのが公式の推奨でもある。
チームでClaude Codeを運用するとなると、CLAUDE.mdやrulesの設計は個人の好みでは済まなくなる。規約の置き場所から強制の仕組みまで含めて外から整えたい場合は、AI実装支援も選択肢の一つになる。
