Claude Code にはすでに二つの built-in memory surface があります。CLAUDE.md は明示ルール、auto memory は繰り返しから学ぶ pattern を担います。Claude Memory MCP はそれとは別で、Claude Code の built-in な machine-local memory boundary の外に context を置いたり取り出したりする external MCP server を指します。
この分け方が見えると recommendation もすぐ変わります。問題が repo rules、startup instructions、繰り返し現れる preference、one-machine habits にとどまるなら、先に整えるべきなのは built-in layers です。重要な文脈を /compact の後も残したい、複数 tools をまたいで retrieval したい、マシン間で continuity を持ちたい、あるいは team で共有したい。そこまで来て初めて external memory MCP が現実的な選択肢になります。
Anthropic の current Claude Code memory docs と MCP docs も、この二つを別 surface として扱っています。CLAUDE.md と auto memory は Claude Code の built-in behavior で、MCP servers は approval、scope、operator trust、third-party risk を伴う external integrations です。だから最初に考えるべきなのは、どの tool が強そうかではなく、どの layer がこの context を先に持つべきかです。
| いまの問題が... | 先に見るべきもの | なぜその lane が先か |
|---|---|---|
| repo rules、起動時に必要な instructions、明示ルール | CLAUDE.md | これは Claude が最初から見る built-in explicit layer だから |
| 繰り返し修正される habits、one-machine preference | auto memory | これは built-in learning layer であって、universal shared store ではないから |
/compact 後の continuity、cross-tool retrieval、cross-machine continuity、team sharing | external memory MCP | ここで初めて built-in の normal boundary を越えるから |
上の二つで説明できるなら、まだ server は足さない方がいいです。外部 memory が値を持つのは、三つ目がはっきり実務上の bottleneck になっている時だけです。
外部層を足す前に、Claude Code は何をすでに覚えているのか
memory という言葉だけで考えると、Claude Code には一つの大きな記憶機能があるように見えます。実際には役割が分かれています。
CLAUDE.md は explicit rule layer です。テスト手順、review expectation、危険操作の境界、directory ごとの注意点、長く残すべき workflow rules はここに置きます。価値は “魔法” ではなく、“最初から見えていること” にあります。
auto memory は learning layer です。反復的な correction から学べる habits や preference を持たせるのに向いています。ただし current docs の contract はかなり明確で、これは machine-local layer です。どこでも自動で共有される万能 memory ではありません。
だから実務上の問いは「Claude は覚えるか」ではなく「どの layer に何を持たせるべきか」です。repo rules なら CLAUDE.md、反復的な pattern なら auto memory、cross-tool や cross-machine の continuity なら external memory MCP。この分担が見えた時点で、かなりの confusion は消えます。
/memory と /context も飛ばさない方がいいです。external memory が必要だと思っていた問題の多くは、実際には built-in contract が explicit でないだけ、あるいはロードされている layer を誤解しているだけです。built-in memory の全体像や /compact troubleshooting が必要なら、別ページとして Claude Code Memory ガイド を使ってください。このページは deliberately narrower で、外部層が要るかどうかだけを判断します。
external memory MCP が本当に解くのはどんな threshold か
external memory MCP は “より強い memory 全般” ではなく、built-in の外にある continuity problem に効くものです。
一つ目は compaction survival です。/compact のたびに重要な作業文脈が抜け落ち、その再構成コストが高いなら、chat の外にある persistence surface が必要になってきます。
二つ目は cross-tool retrieval です。必要な知識が repo rules や learned habits ではなく、notes、issue history、shared docs、別 tool にあるなら、これは built-in memory の話というより retrieval の話です。
三つ目は cross-machine continuity。Claude Code の built-in memory は今も machine-local です。複数のマシンや remote environment をまたいで同じ memory surface を使いたいなら、built-in の外に出る理由として十分です。
四つ目は team sharing。ここは upgrade しやすい一方で、やり過ぎやすいポイントでもあります。team memory が正当化されるのは、shared recall や shared retrieval が本当に workflow の一部になっている時だけです。
market の memory-MCP pages はだいたいこの四つを売っています。そこから学ぶべきなのは “external memory の典型的な job は何か” であって、“Claude Code に標準で足りない機能一覧” ではありません。
plugin、remote MCP、project-shared のどれを選ぶべきか
external threshold が real だと分かったら、次は product name より ownership を先に決める方がきれいです。
基本は personal first です。まだ一人で workflow を試している段階なら、setup は personal に留める方がいいです。plugin-like path でも remote MCP でも構いませんが、まず証明すべきなのは “本当に外部 memory が必要か” です。
Remote MCP は、external retrieval や external persistence そのものが価値の中心なら自然です。ただし remote は operator trust、service availability、dependency boundary を増やします。marketing の強さで選ぶのではなく、名前が付けられる continuity failure を閉じるかどうかで選ぶべきです。
Project-shared はもっと後ろです。Anthropic が local / project / user を分けているのは、ownership が recommendation を変えるからです。repo が integration を持つべきなのは、それが already shared workflow になってからです。
だからこのページは Claude Code で最初に入れるべき MCP より narrow である必要があります。あちらは broader MCP choice、こちらは memory-specific な escalation judgment です。
memory-MCP の claim を hype のまま読まないための見方
Anthropic の official docs が built-in baseline を定義し、vendor pages は external market signal を見せます。この順番を逆にしない方が安全です。
それぞれの claim を operational question に変えると判断しやすくなります。
Persistent memory: 何がどこまで persistent なのか。/compact後か、cross-tool か、cross-machine か、team 全体か。Works with Claude: MCP extension として動くのか、built-in feature のように聞こえるだけなのか。Shared memory: data ownership は誰か。誰が書けるか。prompt-injection risk は誰が負うか。Easy setup: 一人で簡単なのか、repo として maintainable なのか。
間違った upgrade は、単に役に立たないだけでなく、low-trust な外部 context を新しく持ち込みます。だから built-in の official truth を baseline にしてから、gain・ownership・maintenance cost で external layer を比べる順番が必要です。
まだ何も足さない方がいいケース
このページの高い価値は、読者によっては “いまは足さない” と言えることです。
次のどれかに当てはまるなら、外部 layer を急がない方がいいです。
- repo rules がまだ
CLAUDE.mdに整理されていない - auto memory が散らかっていて、本来 explicit に書くべきものまで背負っている
/memoryで何がロードされているか未確認- 痛みの正体が continuity gap より context bloat に近い
- workflow がまだ one-machine / one-repo に留まっている
この状態で外部 memory server を足しても、confusion を隠すだけになりやすいです。だから stop rule は FAQ ではなく本文の前半にあるべきです。
FAQ
Claude Code に memory MCP は最初から必要ですか？
たいてい不要です。問題が repo rules、learned habits、one-machine continuity に留まるなら、まず CLAUDE.md と auto memory を整える方が先です。
Claude Code は built-in で何を覚えていますか？
CLAUDE.md による explicit rules と auto memory による learned patterns です。ただし universal shared memory ではありません。
/compact が external layer を正当化するのはどんな時ですか？
重要な文脈が compaction のたびに消え、それを chat の外で持つ必要がある時です。rule がそもそも CLAUDE.md に書かれていないだけなら、先に built-in を直します。
plugin と remote MCP のどちらを先に考えるべきですか？
最初は最も軽い personal setup です。remote は external retrieval / persistence 自体が主目的の時だけ前に出ます。project-shared はさらに後です。
どんな時に “まだ何も足さない” が正解ですか？
CLAUDE.md、auto memory、/memory の役割がまだ整理されていない時です。その段階では better built-in hygiene の方がほぼ確実に価値があります。