CLAUDE.md と自動メモリに、毎回言い直していることを移す

3回同じことを言ったら、それは依頼文ではなくファイルに書く合図です。

第7回の終わりに書いたとおり、依頼文の質を毎回の気合いで保つのは続きません。続かないものを続けようとする代わりに、置き場所を決めます。

覚える仕組みは2つある

Claude Code には性質の違う仕組みが2つあり、どちらもセッションの最初に読み込まれます。

大事な前提が1つあります。公式ドキュメントは、どちらも文脈であって、強制される設定ではないと書いています。Claude はこれらを読んで従おうとしますが、必ず守られるとは限りません。

必ず実行されてほしいものは、第13回で扱うフックとして書きます。ここを取り違えると、「書いたのに守られない」に延々と悩むことになります。

CLAUDE.md がいつ、どの順で読まれるか

読まれる場所は4つあり、広い範囲から順に連結されます。

上書きではなく連結です。ファイルシステムの根から作業フォルダに向かって並ぶので、起動した場所に近い指示ほどあとに読まれます。各フォルダの中では、CLAUDE.local.md が CLAUDE.md のあとに置かれます。

下位のフォルダにあるファイルは、起動時ではなく、Claude がそのフォルダのファイルを読んだときに読み込まれます。

いま何が読み込まれたかは /context で確認できます。書いたのに効いていないときは、まずここを見てください。ファイルの中身を疑う前に、そもそも読まれているかを確かめるほうが速く終わります。

何を書くか

4つに絞ると迷いません。ビルドとテストの通し方、コードの規約、ディレクトリの構成、そして「常にこうする」という決まりごとです。

書き方には条件があります。公式ドキュメントが挙げている基準は具体性で、次のように対比されています。

• 「コードを整形する」ではなく「インデントは半角スペース2つ」
• 「変更をテストする」ではなく「コミット前に npm test を走らせる」
• 「ファイルを整理する」ではなく「APIのハンドラは src/api/handlers/ に置く」

確かめられる形になっているかが判定の基準です。確かめられない規則は、守られたかどうかも分かりません。

長さの目安も示されています。1ファイルあたり200行未満です。長くなるほど文脈を食い、遵守の度合いが下がると書かれています。

実例として、このブログのファイル

BenriWorks のブログのリポジトリでは、検査の通し方をコマンドのまま並べています。

## 検証コマンド
npm run validate:content && npm run check:links
（加えて npm run typecheck / npm run lint / npm run test）

そして、不明点の扱い方を決めています。

不明な事実を推測で補完しない。
不明点は本文に {/* TODO: 要確認 — ... */} として残し、PRで報告する。

実際に一番働いているのが、この3行目です。分からないことを分からないまま書く形式を先に決めておくと、埋めるために推測する動機がなくなります。この講座の各回の冒頭にある注記も、ここから出ています。

書かないほうがよいこと

一般論は効きません。「読みやすいコードを書くこと」のような文は、書いても書かなくても結果が変わりませんでした。

更新が要る事実も、置き場所として向きません。バージョン番号や依存の一覧を書くと、直し忘れたときに古い情報が規約として効き続けます。そういうものは、実際の設定ファイルを読ませるほうが確実です。

矛盾も問題になります。公式ドキュメントは、2つの規則が食い違っていると、Claude がどちらかを恣意的に選ぶことがあると書いています。上位のフォルダの CLAUDE.md と下位のものが違うことを言っていないか、ときどき見直してください。

場所によって規則を変える

大きなリポジトリでは、場所によって規則が変わります。フロントエンドとバックエンドで書き方が揃わないのは、むしろ自然です。

.claude/rules/ に話題ごとのファイルを置くと、規則を分割できます。さらに、前書きに paths を書くと、該当するファイルを扱うときだけ読み込まれます。

---
paths:
  - "src/api/**/*.ts"
---

# API の規則

- すべてのエンドポイントで入力の検証を行う
- エラー応答は共通の形式を使う

paths のないファイルは常に読み込まれます。常に効かせたいものと、その場所でだけ効かせたいものを分けるための仕組みです。個人用の規則は ~/.claude/rules/ に置けば、全プロジェクトに効きます。

AGENTS.md をすでに持っている場合

別のコーディングエージェントを併用していると、AGENTS.md がすでにあるはずです。

Claude Code が読むのは CLAUDE.md で、AGENTS.md は読みません。公式ドキュメントが勧めているのは、取り込みの1行を書いた CLAUDE.md を作る方法です。

@AGENTS.md

## Claude Code

`src/billing/` 以下の変更ではプランモードを使う。

取り込んだ内容が先に読まれ、そのあとに Claude 固有の指示が続きます。1つの内容を2か所に書かずに済みます。

シンボリックリンクでも同じことができますが、Windows では管理者権限か開発者モードが要るので、この取り込みの形のほうが確実です。

自動メモリは、Claude が自分で書く

もう1つの系統です。

公式ドキュメントによれば、Claude は作業しながら4種類のメモを自分のために保存します。あなたの役割と好み、あなたが与えた訂正、コードや履歴からは分からない進行中の事情、そして情報の在りかです。

保存しないものも決まっています。コードベースから分かること（構成、ファイルの場所、修正の内容）と、CLAUDE.md にすでに書いてあることは飛ばされます。あなたが書いたものと重複しないように作られています。

保存先は ~/.claude/projects/<プロジェクト>/memory/ で、索引の MEMORY.md と話題ごとのファイルに分かれます。セッションの最初に読み込まれるのは索引の先頭200行（または25KB）までで、話題ごとのファイルは必要になったときに読まれます。

画面に「Saved 2 memories」「Recalled 2 memories」と出たときが、その読み書きが起きた瞬間です。

自動メモリとの付き合い方

3つだけ押さえておけば足ります。

中身は読めます。 /memory から開けます。ただのマークダウンなので、書き換えも削除もできます。

機械ごとに別です。 同じリポジトリの作業ツリーどうしでは共有されますが、別のパソコンや、クラウドのセッションには引き継がれません。

切れます。 /memory の切り替えか、プロジェクトの設定で autoMemoryEnabled を false にします。

自動メモリは便利ですが、チームに共有したい内容を置く場所ではありません。「この判断はこうする」とチームで決めたことは、CLAUDE.md に書いてコミットしてください。自動メモリに入ったままだと、書いた本人の機械の中にしか存在しません。

育て方

足すタイミングを決めておくと楽になります。公式ドキュメントが挙げている目安は、Claude が同じ間違いを2回したとき、レビューで指摘されたことが Claude も知っておくべき内容だったとき、前のセッションと同じ訂正を打ったとき、そして新しい人にも同じ説明が要りそうなときです。

BenriWorks では、ここに「事故が起きたとき」を足しています。触ってはいけないファイルを触られた、入れてはいけない情報が入った。そういうときは、原因を直すのと一緒に規約へ1行足します。

どれも、思いついたときではなく、必要が証明されたときに足すという点が共通しています。先回りして書いた規則は、たいてい守られません。

次の回

CLAUDE.md は、常に読まれる規約です。だから、どの作業にも関係することしか書けません。

その作業のときだけ要る手順には、別の置き場所があります。第10回のスキルがそれです。

参照した公式情報

• Anthropic「How Claude remembers your project」（code.claude.com/docs、2026年9月時点）
• 引用した規約は BenriWorks のブログリポジトリで実際に運用しているもの