Claude Code を開き直すたびに、エージェントは先週の自分が何をしたかを覚えていない。CLAUDE.md を読み込んで「このプロジェクトはこういう構成です」と再学習し、それでも「なぜこのライブラリを選んだのか」は分からないまま手探りを始める。コーディングエージェントの“記憶”は、結局のところ人間が手で書き足すマークダウン一枚しかない。この健忘症をツール側で埋めにいくOSSがいま静かに増えていて、設計思想がはっきり分かれてきた。代表格の agentmemory と claude-mem を、一次ソースのリポジトリを突き合わせて読む。
なぜ「記憶」が別レイヤーとして必要なのか 🧠
LLM本体はステートレスだ。会話を閉じれば文脈は消え、次のセッションは白紙から始まる。長い CLAUDE.md に全部書けばいい、という発想もあるが、これは毎回まるごとプロンプトに積まれる。agentmemory の計測では、フル文脈を貼り続けると年間2000万トークン近くを食うのに対し、必要な記憶だけを引く方式なら17万トークン程度で済むという(README)。コンテキストウィンドウは「全部入れる」場所ではなく「いま関係するものだけ入れる」場所だ、という前提に立つと、検索可能な外部記憶が要る。
両ツールが採る基本形はほぼ同じだ。エージェントがツールを実行するたび(PostToolUse)に何をしたかを観測として捕まえ、LLMで要約・圧縮し、ベクトルとキーワードの索引に貯める。そして次のセッション開始時(SessionStart)に、いま着手している作業に関係する断片だけを引いて注入する。この「捕まえる・畳む・呼び戻す」の出入り口に、エージェントのライフサイクルへ自前スクリプトを差し込むhookと、エージェントに外部ツールを生やす標準プロトコルのMCPを使う。
agentmemory: 検索の作り込みと数字で殴る ⚙️
agentmemory はサーバー常駐型で、入れるのは速い。
npm install -g @agentmemory/agentmemory
agentmemory # メモリサーバーを起動(REST API は :3111)
agentmemory connect claude-code # エージェント側に hook と MCP を配線
観測が入ってから記憶になるまでのパイプラインが明示されているのが特徴で、PostToolUse フック → SHA-256で重複排除 → プライバシーフィルタ → 生ログ保存 → LLMで圧縮 → 構造化された事実 → ベクトル埋め込み → BM25+ベクトルの索引、という順で流れる。記憶は Working / Episodic / Semantic / Procedural の4層に整理され、呼び戻しは BM25・ベクトル・知識グラフの3系統を RRF(複数の検索順位を1つに融合する手法)でまとめる。
ここが私の評価点だ。多くの“AIメモリ”系ツールは仕組みの図だけ立派で精度を語らないが、agentmemory は長期記憶のベンチ LongMemEval-S(500問)で recall@5 が95.2%、と数字を出している。recall@5 は「上位5件に正解が含まれていた割合」で、要は注入候補の上位を見れば必要な記憶がほぼ取れている、という主張だ。埋め込みは @xenova/transformers でローカル実行(無料)、圧縮用LLMは Anthropic・OpenAI・Gemini・Ollama などから選べる。ライセンスは Apache-2.0、執筆時点で v0.9.27(2026年6月7日)。
claude-mem: プラグインとして溶け込ませる 🔌
同じ問題に、claude-mem は別の賭け方をする。インストールは1行だが、ここに落とし穴がある。
npx claude-mem install # hook 登録とワーカー起動まで一気にやる
# 注意: npm install -g claude-mem はライブラリだけ入り、hook は登録されない
Gemini CLI や OpenCode へ入れるなら --ide gemini-cli のように対象を指定する。中身は SessionStart / UserPromptSubmit / PostToolUse / Stop / SessionEnd の5つのライフサイクルフックと、ポート37777で動くワーカー(HTTP API と web UI 付き)。保存は SQLite を主データベースに、意味検索用に Chroma ベクトルDBを併用するハイブリッド構成だ。
面白いのは検索を「3層ワークフロー」として設計し、MCPツールを役割で割っている点で、search はIDと数十トークンの索引だけを返し、timeline で前後関係を、get_observations でID指定の本文を取りにいく。いきなり全文を注入せず、絞ってから取得することで約10倍のトークン節約をうたう。エージェントに「まず索引だけ見て、必要な分だけ展開しろ」と検索作法そのものを持たせている発想で、Claude Code のプラグインとして自然に馴染む。ライセンスは同じく Apache-2.0、v13系。
二つの設計をどう読むか
| agentmemory | claude-mem | |
|---|---|---|
| 入れ方 | 常駐サーバー + 配線コマンド | エージェントのプラグイン |
| 索引 | BM25+ベクトル+知識グラフをRRF融合 | SQLite + Chroma のハイブリッド |
| 検索の見せ方 | 4層記憶 + recall@5を公開 | 索引→展開の3層ワークフロー |
| 連携口 | hook / MCP(53) / REST(128) | hook(5種) / MCP(4ツール) |
| ライセンス | Apache-2.0 | Apache-2.0 |
同じ「捕まえる・畳む・呼び戻す」でも、agentmemory は検索エンジンを作り込み数字で正当化する方向、claude-mem は既存エージェントへの溶け込みと検索作法の軽さで勝負する方向だ。どちらも観測をLLMで要約してから貯める点は共通で、ここに実務上の最大の注意がある。圧縮は不可逆だ。要約の過程で「なぜそうしたか」の細部が落ちれば、後から引いた記憶が静かに事実とずれる。圧縮用モデルにツール実行ログを流すことになるので、秘匿情報のフィルタが効いているか(agentmemory はパイプラインに明示、claude-mem はモデル選択で制御)は導入前に必ず確認したい。
私ならまず、設定を頻繁に行き来する横断的な大規模リポジトリで、ローカル埋め込み構成のものから試す。常駐サービスが一つ増えるコストと、毎セッションの再説明が消える価値を、自分のワークフローで秤にかければいい。CLAUDE.md を人力でメンテし続けることに疲れているなら、記憶を別レイヤーに切り出すこの流れは、少なくとも実験する価値がある。