MemPalaceは一週間で4.1万スターを獲得しました。これは誇張ではなく、痛みです。開発者たちはAIとの会話をこれ以上失いたくないのです。あらゆるデバッグセッション、あらゆるアーキテクチャ判断、「Xを試したがYのせいで失敗した」という文脈が、セッション終了と同時に消えてしまいます。
MemPalaceはそれを解決すると約束します。すべてをローカルに保存し、ChromaDBで検索し、LongMemEvalで96.6% recallを出す。APIキーも不要、クラウドも不要、コストもかからない。そしてそのスコアは本当に再現されています。
私はこのプロジェクトを心から尊重しています。チームが公開後48時間以内に誇張された数値を自ら訂正したことは、この分野では珍しい誠実さです。
ですが、コードとベンチマークを読んだあと、私はMemPalace、そしてMem0やZepを含む今あるほとんどすべてのメモリシステムが、問題の間違ったレイヤーを解いていると思うようになりました。
96.6%が実際に意味するもの
MemPalaceの看板スコアはraw verbatimモードから来ています。会話全体をChromaDBに入れ、semantic similarity searchを走らせ、上位5件を返す。要約も、抽出も、LLMの介在もありません。
これは力任せのアプローチですが、retrievalベンチマークでは見事に機能します。もしGraphQL移行について議論した会話そのものを保存していて、誰かが「なぜGraphQLに切り替えたのか」と聞けば、ChromaDBはそれを見つけます。元の文言がそこにあり、similarity searchがそれを拾うからです。
Palaceの比喩、wings、halls、rooms、closets、drawersは、技術的にはChromaDB上の階層的metadata filteringをうまく包装したものです。実際、彼ら自身のベンチマークの内訳はこうです。フィルタなし検索は60.9%、wingフィルタ追加で73.1%、wing + roomで94.8%。これは有用です。同時に、metadata fieldを持つベクトルDBなら標準的にできることでもあります。チームが最初に主張していた「+34% palace boost」も、後にまさにその効果だと訂正されました。
これは批判ではありません。構造化されたmetadata付きのraw verbatim storageは、正当な設計選択です。一つのことに最適化された選択です。過去の会話を見つけること。そしてその点では確かに優れています。
問題は、過去の会話を見つけることだけで十分か、ということです。
RetrievalはMemoryではない
思考実験をしてみましょう。あなたはMemPalaceを6か月使っていて、15のproject wingにまたがって2万件の会話断片を保存しています。そこで:
同僚が「今のauth戦略って何だっけ？」と聞きます。検索すると、MemPalaceは5つの断片を返します。1月にAuth0を選んだ断片、3月にClerkへの移行を議論した断片、4月に実際に移行した断片、5月に新しいClerk構成のedge caseを扱った2つの断片。このうちどれが 現在の状態 を表しているでしょうか。MemPalaceは知りません。時間的妥当性やsupersessionではなく、類似度順で5件返すだけです。結局、あなたかAIが全部読んでタイムラインを再構成しなければなりません。
次はこうです。「私たちのdatabase選定の立場は、最初から今までで変わったか？」これは、「私たちはPostgresを使う」のような知識のatomが作られ、その後更新されたり矛盾したりしたかをたどる必要があります。ですがraw verbatim searchが返すのは "database" という単語を含む断片だけです。物語の再構成は読者への宿題として残されます。
これが retrieval と memory の違いです。Retrievalはテキストを見つけます。Memoryは状態を理解します。何が現在で、何が置き換えられ、何が何と矛盾し、知識が時間とともにどう変化するかを扱います。
MemPalace自身もこのギャップは認識しています。彼らは contradiction detection utility（fact_checker.py）と temporal knowledge graph を作りました。ですが2026年4月の訂正時点では、その contradiction detector は knowledge graph の運用フローに接続されていません。別スクリプトとして存在しているだけです。これは「後で直せばいいバグ」ではありません。構造化された理解を、生の保存の上に載せる追加機能として扱うアーキテクチャの症状です。
誰も話さないPortability問題
私がretrieval品質以上に気にしている問題は、こちらです。
MemPalaceはすべてをローカルマシン上の ChromaDB + SQLite に保存します。独自形式です。export標準も、migration経路もありません。
今日あなたはClaude Codeと一緒にMemPalaceを使っています。6か月分の会話が、wingsとroomsにきれいに整理されているとしましょう。そこで:
Cursorに乗り換えます。メモリは持っていけるでしょうか。CursorにMemPalace MCP integrationがあり、MCPサーバーが動いていて、同じChromaDBインスタンスを指していれば、理論上は可能かもしれません。つまり、メモリはportableなのではなく、特定ツールから特定ランタイム経由でアクセスできるだけなのです。
スマホでもメモリを使いたい。MemPalaceはChromaDBを使うローカルPythonパッケージです。hostedオプションも、syncも、mobileパスもありません。
チームでshared memoryを使いたい。MemPalaceはsingle-user、single-machineです。multi-userの物語がありません。
Mem0やZepを試したい。2万件の断片はMemPalaceのChromaDB schemaに入っています。別システムがimportできる標準export formatがありません。
これはMemPalace固有の問題ではありません。業界全体のパターンです。どのメモリシステムも独自のstorage format、独自schema、独自retrieval logicを作ります。システムを変えるとメモリを失います。Harrison Chaseがモデル提供者について警告したのとまったく同じロックインが、今度はメモリ提供者側で起きているのです。
| システム | ストレージ | Portable? | 標準フォーマット? |
|---|---|---|---|
| MemPalace | ChromaDB + SQLite | No | No |
| Mem0 | Proprietary cloud | No | No |
| Zep | Neo4j cloud | No | No |
| Letta | Embedded in harness | No | No |
| Claude Memory | Behind API | No | No |
| ChatGPT Memory | Behind API | No | No |
すべての行がサイロです。あなたの記憶は、ツール選択の人質になっています。
本当に必要なMemoryとは何か
一歩引いて、本物のメモリシステムに何が必要かを考えると、retrievalは長い要件リストの一項目にすぎません。
Atomization: 会話を、事実、意思決定、好み、関係のような離散的知識単位に分解し、それぞれを追跡、更新、置換できること。Raw verbatim storageはこれをまるごと飛ばします。
Temporal awareness: 1月の「私たちはAuth0を使う」が、4月の「Clerkへ移行した」によって置き換えられたことを、ユーザーやAIが両方の断片を読んで推測しなくても理解できること。
Portability: ツール、デバイス、プラットフォームをまたいで一緒に動くメモリ。一台のマシン上の一つのベクトルDBに閉じ込められないこと。
Scope management: プロジェクト知識、個人の好み、セッション限定コンテキストを区別できること。すべてがすべてのクエリに属してはいけません。
Decay and relevance: ある知識は時間とともに価値が落ちます。すでにリファクタ済みのコードベースの実装詳細が、現在のアーキテクチャ判断と同じ重みで順位づけされてはいけません。
Protocol-level interoperability: どのハーネスでも、どのツールでも、どのバックエンドでも話せる標準契約。そうして初めて、メモリは一製品の機能ではなくインフラになります。
MemPalaceはメモリシステムの最初の要件、「データを失わない」はしっかり満たしています。ですが、上の六つがあって初めて、保存されたデータは働くmemoryになります。
AMCP: プロトコルとしてのMemory
だから私はAMCP、Agent Memory Continuity Protocolを作っています。Apache 2.0のオープン標準で、MCP（ツール）やA2A（エージェント協業）と並ぶ第三のエージェントインフラ層として位置づけています。
中核の考えはこうです。メモリは製品ではなく契約であるべきだ。どのハーネスでも、標準インターフェースでメモリを保存しrecallできるべきであり、どのバックエンドでもそのインターフェースを実装できるべきです。どのツールを使っても、ユーザーが自分のメモリを所有し続けられなければいけません。
AMCPは次を定義します。
- 知識単位のための標準atom shape
- Scopeとvisibility control（project, user, session）
- Similarity searchとscope filteringを含むrecall
- 可搬フォーマットでのexport/import
- Backend-agnostic transport（local SQLite, hosted cloud, third-party）
仕様は github.com/goldberg-aria/amcp にあります。
3122: ハーネス統合は実際にどうあるべきか
プロトコルは、動く実装がなければ単なる仕様書です。3122は、このアーキテクチャが本当に機能することを示すAMCPネイティブなコーディングハーネスです。
3122は二種類の状態を明確に分けます。
Continuity Runtime State はハーネスの中に残ります。Session transcript、trajectory compression（goal -> attempt -> failure -> verification -> next-step）、モデル切り替え時のhandoff snapshot、ファイル単位working memory。これらはハーネスが持つべき運用上の関心です。
Portable Memory はAMCPを通ります。item shapeは一つ。バックエンドは差し替え可能です。手元のSQLiteを使う local-amcp、ホスト型バックエンドの nexus-cloud、そしてプロトコルを話すものであれば何でもつなげられる third-party-amcp。
面白いのは統合の深さです。3122はAMCPを単なる検索APIとして呼ぶだけではありません。Trajectory-aware recallを使い、今作業しているファイルや遭遇したエラーに関係するatomを優先します。Context budgetも管理し、セッションが長くなると conversation recall、古いmemory、recent history の順に落としていきます。モデルを切り替えたときにはhandoff snapshotを出し、新しいモデルが最初のターンでcontext boostを得られるようにします。
これらはすべてハーネスロジックです。何を含めるかはハーネスが決める。AMCPは、その候補を提供する。きれいな分離でありながら、深い統合でもあります。
そして portability はこうです。
# すべてを書き出す
3122 memory export --format amcp-jsonl --output my-knowledge.jsonl
# バックエンドを切り替える
3122 memory migrate --from local-amcp --to nexus-cloud
# ワークスペースを消して作り直して再接続しても
# メモリは残るリポジトリは github.com/goldberg-aria/3122-harness にあります。
Raw Storageにも居場所はある
はっきりさせておきたいのですが、私はMemPalaceのやり方が間違っていると言っているのではありません。Semantic search付きのraw verbatim storageは有効な道具です。ノートPC上で過去のClaude会話を検索したい個人開発者にとっては、非常に良い選択です。
ですが、問題空間はローカル検索より大きい。チームにはshared memoryが必要で、ワークフローには構造化された知識が必要で、ユーザーにはツール変更に耐えるメモリが必要です。業界にはサイロを止める標準が必要です。
MemPalaceの96.6% recallは、retrieval問題が解けることを示しています。ですが、それが扱っていないもの、そして現在どのシステムもきちんと扱えていないものは、portabilityとstructureの問題です。
そのためにAMCPと3122があります。
地形
私たちはまだAI memoryの初期にいます。MemPalace、Mem0、Zep、Letta、そしてもちろんNexusやAMCPまで、この領域のあらゆるプロジェクトが異なるトレードオフを試しています。MemPalaceが一週間で4.1万スターを集めたという事実は、需要が本物であり、巨大だということを示しています。
私の賭けは、勝つアーキテクチャは三つの関心を分離するものだということです。
- ハーネス はコンテキスト管理を持つ。何をプロンプトに入れるか、どうトークンを配分するか、いつcompactするか
- メモリレイヤー は persistence と recall を持つ。atomの保存、temporal validity の管理、scope の扱い
- プロトコル は両者をつなぐ。だからハーネスもバックエンドもロックインを作れない
MCPがツールに対してやったことを、AMCPはメモリに対してやろうとしています。
あなたの会話はセッション終了と同時に死ぬべきではありません。でも同時に、一つのツールに永遠に閉じ込められるべきでもありません。
---
AMCP spec: github.com/goldberg-aria/amcp 3122 harness: github.com/goldberg-aria/3122-harness このシリーズの第1回: ハーネスは変わっても、記憶は変わってはいけない