Claude Codeを使い始めた頃、セッションを閉じるたびに同じことを説明し直していた。「前回、日時の計算でミスがあったからJST基準で頼む」「あのプロジェクトは先週A案で合意した」。毎回これを手打ちするのは面倒だし、伝え忘れると同じ失敗が繰り返される。

Claude Codeにはmemory機能がある。セッションをまたいで学びを蓄積する仕組みだ。ただし何でも記憶させればいいかというと、そうでもなかった。200行の上限があり、何を覚えさせて何を捨てるかの設計が思った以上に重要だった。

memory機能とは -- 仕組みの基本

Claude Codeのmemoryは、セッション間で持続する記憶の仕組み。実体はMEMORY.mdというファイルで、セッション開始時にClaude Codeがこのファイルを読み込むことで過去の学びを引き継ぐ。

保存の仕方に特徴がある。MEMORY.md本体には1行の要約（インデックス）だけを書き、詳細な内容は個別のメモリファイルに分離する。これは200行制限に対処するための工夫だ。本体に詳しい手順書を書き込んでいくと、あっという間に上限に達する。

CLAUDE.mdとは似ているようで別物になる。CLAUDE.mdは「意図的に設計するルール」、memoryは「セッション中に蓄積される学び」。CLAUDE.mdの書き方については「CLAUDE.mdの育て方」を参照してほしい。

4タイプの使い分け

memoryに何を保存するか。試行錯誤の末、4つのタイプに分類して運用するようになった。

タイプ	何を記憶させるか	保存タイミング	具体例
user	ユーザー自身の属性・好み	属性を新たに学んだ時	「PM職、事業開発担当」「日本語で応答」
feedback	やるべき/やるべきでないの教訓	ミスを指摘した時、うまくいった時	「曜日計算はJST基準で」「ルート直下にフォルダ作成禁止」
project	進行中プロジェクトの状況・決定事項	プロジェクトの状況が変わった時	「4月5日以降のリリース凍結」「A案で合意済み」
reference	外部情報の在処	有用なリソースを発見した時	「営業データはDriveの○○フォルダ」

4タイプの中で最も頻繁に使うのがfeedbackだ。Claude Codeに何かミスを指摘するたびにここへ記録される。「曜日計算はJST基準で」「ファイルはルート直下に作らない」といった教訓が溜まっていく。次のセッションでは、この教訓を読み込んだ状態で作業が始まるため、同じ失敗が繰り返されにくくなる。

project typeは「今どうなっているか」の最新状態を保持する役割だ。プロジェクトの状況は時間とともに変わるので、古い情報はこまめに削除しなければならない。「先月凍結した」という記録を残したまま翌月を迎えると、Claude Codeは凍結がまだ続いていると誤解してしまう。

user typeは頻繁に変わらない。役割や基本的な好みを最初に数件登録すれば十分で、追加する機会はほとんどない。reference typeは「情報がどこにあるか」だけを記録する。内容そのものは書かない。

feedbackタイプを本格的に運用し始めてから、Claude Codeとの付き合い方が変わった。以前はセッションを開くたびに「あのミスに気をつけなきゃ」と意識する必要があったが、memoryに記録しておけば過去の失敗を勝手に学んでくれる。起動するたびに前回の学びがリセットされる、というストレスが消えたのは想像以上に大きかった。

MEMORY.mdの運用テクニック

200行制限の中で必要な記録を維持するために、いくつかの運用ルールを決めている。

インデックス形式を徹底する。 MEMORY.mdには1行の要約と詳細ファイルへのリンクだけを書く。

悪い例:

## 曜日計算ルール
- システム時刻はUTCなので日本時間の曜日を間違える
- セッション開始時に `TZ='Asia/Tokyo' date` コマンドで確認する
- 推奨フォーマット: 2026-04-01（火）14:30
（5行消費）

良い例:

- [曜日計算はJST基準で](feedback_datetime_jst.md) -- 繰り返し指摘されている曜日計算ミスを防ぐ
（1行で済む）

この差は大きい。1トピック5行で書くと40トピックで200行に達するが、1行インデックスなら200トピック分を保持できる。

定期的な棚卸しも欠かせない。 特にproject typeは古くなりやすい。「4月5日以降リリース凍結」という記録は、凍結解除後には不要だ。月に1回、MEMORY.mdを開いて古い記録を削除する時間を取っている。

feedback typeの書き方にもコツがある。 「気をつける」だけでは次回も同じミスを招く。「○○しない、代わりに○○する」まで書かないとAIは正しい行動を取れない。「推測で数字を作らない」ではなく「推測で数字を作らない、データがなければ"不明"と明記する」のように、代替行動をセットで記述するのが大事だ。

memoryとCLAUDE.mdの棲み分け

memoryとCLAUDE.mdの使い分けに最初は迷った。どちらも「Claude Codeへの指示」という点では同じに見えたからだ。

整理するとこうなった。

CLAUDE.md: 「こうしてほしい」 -- 意図的に設計するルール・方針
memory: 「こうだった」 -- セッション中の体験から蓄積される事実・教訓

もう少し具体的に言えば、CLAUDE.mdは「最初から書くもの」で、memoryは「使っているうちに溜まるもの」だ。CLAUDE.mdに「日本語で応答」「事実と推論を分ける」と書くのは意図的な設計になる。一方、memoryに「曜日計算でミスが起きた」と記録されるのはセッション中の学びだ。

ここで重要なのが「昇格パターン」になる。memoryに溜まった教訓のうち、繰り返し重要だと判明したものはCLAUDE.mdまたは.claude/rules/にルールとして正式に移す。

例を挙げると、「曜日計算はJST基準で」という教訓がmemoryに3回記録された。3回も繰り返されるということは、memoryの1行メモでは根本解決になっていないということだ。そこで.claude/rules/datetime-handling.mdというルールファイルを作り、具体的な手順まで含む正式なルールに昇格させた。

memoryは「仮置き場」で、CLAUDE.md/rulesは「正式なルール置き場」。この関係を意識すると、何をどこに書くかで迷わなくなった。

最初はCLAUDE.mdに何でも書いていた。memoryとの棲み分けに悩んでいた時期が正直ある。ただ運用を続けるうちに面白いことが起きた。Claude Code自身が「これはmemoryに保存しましょうか？」「CLAUDE.mdに追加しますか？」と提案してくれるようになったのだ。AIがこの棲み分けを学習してくれると、人間が毎回判断する手間も減っていく。

やりがちな失敗と対策

失敗1: 何でもmemoryに入れた。 便利だからと手当たり次第にmemoryへ保存していたら、1ヶ月で200行制限に到達してしまった。重要な記録が新しい記録に押し出され、結局「AIが以前覚えていたはずのことを忘れている」という事態に陥る。保存する前に「これは次のセッションでも本当に必要か」と一呼吸置くようになってから改善した。

失敗2: feedbackの書き方が曖昧だった。 「日時計算に気をつける」とだけ書いていた時期がある。これではAIは何に気をつければいいか分からない。翌セッションでも曜日を間違えた。具体的に「JST基準で計算する。セッション開始時にdateコマンドで確認する」と書き直して、ようやく再発が止まった。

失敗3: memoryを一度も見返さない。 半年間棚卸しをサボっていたところ、既に終了したプロジェクトの記録が大量に残り続けていた。「リリース凍結中」という古い記録をAIが読み込み、現在の作業方針と矛盾する提案が返ってくる。月1回のMEMORY.md棚卸しを習慣にしてからは、この問題は起きていない。

memory機能は「AIに何を覚えさせるか」の設計だ。4タイプの分類でmemoryの役割を明確にし、200行制限の中で本当に必要な記録だけを残す。蓄積された教訓が一定の重要度に達したら、CLAUDE.mdやrulesに昇格させていけばいい。このサイクルが回り始めると、セッションをまたいでも「前回の続き」から始められるようになる。

セッション間の引き継ぎをさらに強化する「handoff」の仕組みについては今後詳しく書く予定