# Claude Memory MCP ガイド（2026）：それは何か、Claude Code がすでに覚えていること、外部 memory が本当に要る時 > Claude Code の built-in memory と external memory MCP の境界を整理する実用ガイドです。`CLAUDE.md` と auto memory がすでに担う役割を確認し、外部 persistence が本当に価値を持つ場面と、最も軽く安全な setup surface を見分けます。 - URL: https://blog.laozhang.ai/ja/posts/claude-memory-mcp - Published: 2026-04-15 - Updated: 2026-04-16 - Author: LaoZhang AI Team (https://blog.laozhang.ai/ja/about) - Topic: Claude Code - Tags: Claude Code, MCP, Memory, 開発ツール --- 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 の built-in memory と external memory MCP の分流図](https://blog.laozhang.ai/posts/ja/claude-memory-mcp/img/memory-routes.jpg) ## 外部層を足す前に、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 ガイド](https://blog.laozhang.ai/ja/posts/claude-code-memory) を使ってください。このページは deliberately narrower で、外部層が要るかどうかだけを判断します。 ## external memory MCP が本当に解くのはどんな threshold か ![external memory MCP を正当化する threshold board](https://blog.laozhang.ai/posts/ja/claude-memory-mcp/img/external-thresholds.jpg) 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 のどれを選ぶべきか ![plugin、remote MCP、project-shared の ownership ladder](https://blog.laozhang.ai/posts/ja/claude-memory-mcp/img/setup-ladder.png) 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](https://blog.laozhang.ai/ja/posts/claude-code-best-mcp-servers) より 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 の方がほぼ確実に価値があります。