Claude Code が前回のセッションを忘れる問題 — 5 分で入る MCP 永続記憶の仕組みと選び方

はじめに

Claude Code を毎日触っていると、ある違和感に気づく。前回のセッションで散々議論した設計判断や、踏み抜いたバグの回避策を、次のセッションでは全部もう一度説明し直している。標準の Claude Code はセッションをまたいだ完全な記憶を持たない設計で、CLAUDE.md と auto memory がそれを部分的に補うが、実装の試行錯誤や「なぜそうしないと決めたか」までは残らない。本記事では話題になっている MCP 永続記憶サーバー Linksee Memory を起点に、Mem0・neural-memory・mcp-memory-service など主要な選択肢を比較し、CLAUDE.md との役割分担まで整理する。

Linksee Memory が解いた「Claude が自分から思い出さない」問題

Linksee Memory は MCP（Model Context Protocol）サーバーとして配布される永続記憶レイヤーだ。claude mcp add -s user linksee -- npx -y linksee-memory の 1 行と Skill インストーラの実行で 5 分以内に有効化でき、データは ~/.linksee-memory/memory.db のローカル SQLite に保存される。クラウドへ送信されない設計のため、業務コードを扱うフリーランスや受託案件でも投入しやすい。

注目すべきは、単なる「履歴ストア」ではなく 6 層の構造化スキーマ を持っている点だ。Goal / Context / Emotion がセッションの枠組みを保存し、Implementation が「何が動き何が動かなかったか」を記録する。さらに Caveat（再発防止のための禁則）と Learning（一般化された知見）が分離されており、Caveat レイヤーは自動忘却から保護される。

著者が指摘する最大の落とし穴は「Claude が自分から recall / remember を呼ばない」点だ。MCP ツールを生やしただけでは Claude Code は能動的に過去を参照しないため、Skill 側でツール起動を誘導する仕組みと Stop フックの設定をセットで入れる必要がある。これを忘れると「永続記憶を入れたはずなのに体感が変わらない」という典型的な症状に陥る。

公式メモリと MCP メモリサーバーは何が違うか

Claude Code 公式の記憶機構は 2 系統ある。1 つはリポジトリ直下に置く CLAUDE.md などの 静的な指示書で、起動時に必ずコンテキストへ注入される。もう 1 つは ~/.claude/projects/<project>/memory/ 配下に保存される auto memory で、ユーザーの訂正や好みをモデル自身が書き留めて次回参照する仕組みだ。auto memory は git リポジトリ単位で worktree 間に共有される一方、フリーフォームの Markdown であり、構造化された検索・忘却制御は持たない。

これに対し MCP 系の永続記憶サーバーは「記憶を構造化して、必要時にツール呼び出しで取り出す」アプローチを取る。代表的な選択肢は以下のとおり。

Linksee Memory: 6 層スキーマ + Caveat 保護。日本語ドキュメントが充実し導入が最速。
Mem0: 既存 Mem0 プラットフォームとの統合。コンテキスト依存タスクの完了速度が 10 倍、トークン使用量が 90% 削減と公称。
neural-memory: SQLite ベースで再起動耐性に特化。シンプルで挙動が読みやすい。
mcp-memory-service: REST API + ナレッジグラフを備え、LangGraph・CrewAI・AutoGen など他フレームワークとも相互運用可能。アーキテクチャ判断・コードパターンを自動抽出する。

いずれも基本はローカル SQLite または埋め込み DB に保存され、外部送信を伴わないのが共通点だ。違いは「忘却ポリシー」と「他ツールとの相互運用性」に出る。単一の Claude Code セッションだけ強化したいなら Linksee や neural-memory、エージェント基盤を跨いで知識を共有したいなら mcp-memory-service が現実的な落としどころになる。

エンジニアへの影響 — どう使い分けるか

実務に入れるときに重要なのは、永続記憶 ≠ CLAUDE.md の置き換えという整理だ。以下のように役割を分けると破綻しにくい。

CLAUDE.md: 動かない事実を書く。フォルダ構成、命名規則、絶対やってはいけない操作。レビュー対象でバージョン管理する。
auto memory: ユーザー個別の 好みと過去の訂正。たとえば「冗長な要約を末尾に書かない」など Claude の振る舞いに直結するもの。
MCP 永続記憶: 試行錯誤のプロセス記録。なぜこの実装ではなくあの実装にしたか、どこでハマってどう抜けたか、再発防止すべき Caveat。

特にフリーランスのエンジニアにとって、案件横断で「同じ轍を踏まない」資産が Caveat として積み上がっていくのは強い。逆に MCP メモリに CLAUDE.md 相当の不変ルールを入れてしまうと、レビューされない暗黙知になり危険だ。導入時は Skill と Stop フックまでワンセットで入れ、最初の 1 週間は recall が呼ばれているかをログで確認するのが堅実な進め方になる。

まとめ

Claude Code の標準動作はセッション健忘で、CLAUDE.md と auto memory だけでは試行錯誤や禁則は残らない。Linksee Memory のような MCP 永続記憶サーバーは、6 層スキーマと Caveat 保護で「Claude に賢くなり続けてもらう」基盤になる。Mem0・neural-memory・mcp-memory-service など選択肢は揃ってきており、いずれもローカル保存で導入コストは 5 分前後。重要なのは Skill とフックまで含めて「Claude が自分から思い出す」状態を作り込むことと、CLAUDE.md との責務分離を意識することだ。AI コーディングが「会話の継続性」をどこまで持てるかは、今後のエージェント設計の中心テーマになっていく。

今日のその他のニュース

Anthropic 5 パターンでマルチエージェント設計を分類

Anthropic が示す Orchestrator-Workers / Routing / Parallelization / Evaluator-Optimizer / Prompt Chaining の 5 パターンを、Claude Code 実装にマッピングしたガイドが公開された。OMC のような多エージェント基盤を設計するときの構造的な見取り図として有用。

Claude Code の失敗をチームルールに昇格させる仕組み

Claude Code の誤動作を「個人の経験」で終わらせず、CLAUDE.md やルール集に昇格させて組織知化する運用記事。MCP 永続記憶と組織レベルのルール化は補完関係にある。

t-wada「2026 年のソフトウェア開発を考える」

和田卓人氏の Scrum Fest Niigata 2026 登壇資料。AI 時代のテスト・設計・組織の現在地を整理した内容で、はてブ 250 users と高い注目を集めている。