2026年4月、GitHub で爆発的に注目を集めた AI メモリシステム「MemPalace」。LongMemEval ベンチマークで 96.6% というスコアを叩き出し、わずか1週間で 45,000 スター以上を獲得した。女優ミラ・ジョヴォヴィッチと開発者 Ben Sigman による共同プロジェクトという異色の出自も話題を呼んだ。
本記事では、MemPalace の仕組み・特徴と、コミュニティから寄せられたベンチマーク手法への批判の両面を整理する。
MemPalace の概要
MemPalace は、LLM に永続的なクロスセッションメモリを提供するオープンソースシステムだ。
- GitHub: milla-jovovich/mempalace
- ライセンス: MIT
- 言語: Python
- スター数: 45,000 以上（2026年4月時点）
古代の記憶術「記憶の宮殿（Method of Loci）」にインスパイアされた階層構造で、会話データを整理・保存する。
アーキテクチャ：宮殿の構造
MemPalace は会話データを以下の階層で管理する。
| 階層 | 役割 |
|---|---|
| Wing（翼） | トピックやプロジェクトをグループ化 |
| Hall（ホール） | メモリの種類を分類 |
| Room（部屋） | 特定の知識やアイデアを保持 |
| Closet / Drawer（クローゼット / 引き出し） | さらに細かい情報の格納 |
| Tunnel（トンネル） | 異なる Room 間の関連を結ぶナレッジグラフ |
この階層構造により、単純なベクトル検索とは異なる、構造化された記憶の管理を目指している。
主な技術的特徴
完全ローカル動作
- SQLite + ChromaDB でローカルにデータを永続化
- 外部 API 呼び出し不要
- データが端末から出ることがない
MCP 対応
Claude Code、ChatGPT、Cursor など主要な AI ツールと MCP（Model Context Protocol）経由で統合可能。セットアップ後は、AI アシスタントが自動的に MemPalace のメモリにアクセスできる。
AAAK 圧縮
MemPalace は「AAAK」という独自の省略圧縮方式を導入している。自然言語のテキストを省略記法に変換し、トークン消費を抑えることを狙う。ただし、実際の圧縮効率については議論がある（詳細は「LongMemEval ベンチマークと論争」セクションを参照）。
LongMemEval ベンチマークと論争
LongMemEval とは
LongMemEval は、AI システムの長期記憶能力を測定するベンチマークだ（論文: arXiv 2410.10813、ICLR 2025 採択）。500 問のテストセットで、数千の過去のやり取りから特定の情報を正確に検索・回答できるかを評価する。
MemPalace のスコア
MemPalace は以下のスコアを公表した。
- Raw モード: 96.6%（Recall@5）
- Hybrid v4 モード: 100%（500/500）
多くの商用 AI メモリシステムが 60〜75% のスコア帯に留まる中、この数値は衝撃的だった。
コミュニティからの批判
公開直後から、ベンチマーク手法に対して複数の問題が指摘された。
96.6% スコアの実態
GitHub Issue #214 で指摘された通り、96.6% のスコアは collection.add() + collection.query() という ChromaDB のデフォルト埋め込み（all-MiniLM-L6-v2）による Recall@5 の数値であり、MemPalace の特徴である宮殿構造（Wing、Room など）は一切関与していない。つまり、ChromaDB 単体のベクトル検索性能を測定した結果といえる。
100% スコアの問題
Hybrid v4 による 100%（500/500）のスコアは、開発セットで不正解だった 3 問を特定し、それらに対するパッチを当てた上で同じテストセットで再測定したものだった。テストセットへのオーバーフィッティングであり、汎化性能を示すものではない。
AAAK 圧縮の実効性
初期の README では「30倍のロスレス圧縮」を示唆する記述があったが、実際には AAAK は非可逆な省略処理であり、AAAK 適用時の LongMemEval スコアは 84.2%（Raw の 96.6% から大幅に低下）だった。
開発チームの対応
2026年4月7日、ミラ・ジョヴォヴィッチと Ben Sigman は README に「A Note from Milla & Ben」を追記し、以下を認めた。
- AAAK のトークンカウントにヒューリスティクスを使用しており、正確なトークナイザーではなかった
- 「30倍ロスレス圧縮」の表現は誤解を招くものだった
- AAAK vs Raw の正直なトレードオフは 84.2% vs 96.6%
MemPalace の評価：何が本物で何がバズか
評価できる点
- 完全ローカルで動作する AI メモリシステム という方向性自体は有用
- MCP 対応 により主要 AI ツールとの統合が容易
- MIT ライセンス でオープンソース
- 指摘に対して比較的迅速に README を修正した透明性
注意すべき点
- ベンチマークスコアは宮殿構造の性能ではなく ChromaDB のベクトル検索性能
- 100% スコアはテストセットへのオーバーフィッティング
- AAAK 圧縮を有効にするとスコアが 12 ポイント以上低下
- SNS での急速な拡散により、技術的な実態以上に期待値が膨らんでいる
導入判断のポイント：既存プロジェクトに MemPalace は必要か
MemPalace の導入を検討する前に、自分のプロジェクトの記憶インフラを棚卸しすることが重要だ。
既に存在しうる記憶層
多くの AI 活用プロジェクトには、すでに何らかの記憶の仕組みが組み込まれている。
| 記憶層 | 例 | カバー範囲 |
|---|---|---|
| エディタ/CLI の組み込みメモリ | Claude Code の auto-memory、Cursor の .cursorrules | フィードバック、ユーザー設定、プロジェクト文脈 |
| プロジェクト指示書 | CLAUDE.md、README | ワークフロー、規約、ツール設定 |
| ナレッジベース | Wiki、Notion、Obsidian | 構造化された知識の蓄積 |
| バージョン管理 | Git 履歴、PR、Issue | 変更の経緯と意図 |
MemPalace が提供する「セッション間の永続メモリ」は、これらと大きく重複する。特に Claude Code や Cursor のように MCP 対応のツールを既に使っている場合、ツール側の記憶機能が同じ役割を果たしている可能性が高い。
導入が有効なケース
- 記憶の仕組みを持たない AI ツールを使っており、ゼロから永続メモリを追加したい場合
- 複数の AI ツール間で記憶を共有したい場合（MemPalace を共通のメモリレイヤーとして使う）
導入を見送るべきケース
- 既存の記憶インフラで十分カバーされている場合
- ChromaDB のローカルプロセス常駐が運用コストに見合わない場合
- 宮殿構造による構造化検索を期待する場合（現時点では未成熟）
ベクトル検索だけなら代替手段がある
記事の横断検索や類似コンテンツの発見が目的であれば、MemPalace を介さず ChromaDB や他のベクトル DB を直接利用する方がシンプルだ。MemPalace の付加価値は宮殿構造による整理にあるが、前述の通りその部分はベンチマークに反映されていない。
まとめ
MemPalace は、LLM に永続的なローカルメモリを提供するという正しい問題に取り組んでいるプロジェクトだ。ただし、バイラルに拡散した「96.6%」「100%」というベンチマークスコアは額面通りに受け取れない。
AI メモリシステムを検討する際は、以下の観点で評価するとよい。
- ベンチマーク手法の詳細 — 何を測定しているのか、システムのどの部分が関与しているのか
- 実運用での性能 — ベンチマークと実際の利用シーンでの乖離はないか
- トレードオフの開示 — 圧縮や最適化が検索精度に与える影響が透明か
- 既存インフラとの重複 — 自分の環境に既にある記憶の仕組みで十分ではないか
MemPalace 自体はまだ若いプロジェクトであり、宮殿構造を活かした検索が実装・改善されれば、本来のコンセプトに近づく可能性はある。今後の開発動向に注目したい。