Knowledge Graphの勉強をしていたら、きのうXでとんでもない情報が流れてきました。
映画バイオハザード（Resident Evil）シリーズでアリスを演じたMilla Jovovich氏が、AIエージェント向けのメモリーシステムを共同開発してOSSで公開した。
共同開発者のBen Sigman氏がXで発表し、2日でGitHub Star 8,800超。Hacker Newsでもトップに上がり、コミュニティが沸いています。
正直、最初は「セレブの名前を使ったマーケティングか？」と思いました。でもリポジトリのコードとベンチマーク手法を読んでいくと、アーキテクチャの設計思想が本当に面白い。一方で、ベンチマークの主張にはコミュニティから重要な指摘も出ています。
この記事では、MemPalaceの仕組みを技術的に読み解きつつ、ベンチマーク論争も正直に紹介します。
MemPalaceとは何か
AIの「記憶喪失問題」
AIとの会話で生まれた意思決定、デバッグ記録、設計議論 — これらはセッション終了とともに消滅します。README によると、半年間の日常利用で約1,950万トークン分の知識が失われる計算です。
既存のメモリーシステム（Mem0やZepなど）は、AIに「何を覚えるか」を判断させます。「ユーザーはPostgresを好む」という事実は残るけど、なぜPostgresを選んだのかという会話の文脈は捨てられる。
MemPalaceのアプローチは逆です：
Store everything, then make it findable.
（全部保存して、見つけられるようにする）
要約で情報を失うのではなく、構造で検索性を確保するという設計思想です。
基本スペック
| 項目 | 内容 |
|---|---|
| 言語 | Python 3.9+ |
| ストレージ | ChromaDB（ベクトル検索）+ SQLite（Knowledge Graph） |
| 動作環境 | 完全ローカル（APIキー不要、クラウド不要） |
| ライセンス | MIT |
| MCP対応 | 19ツール提供 |
| 対応LLM | Claude, GPT, Gemini, Llama, Mistral 等（テキストを読めるモデルなら何でも） |
コスト比較
| アプローチ | 年間コスト |
|---|---|
| LLM要約方式 | ~$507 |
| Mem0（有料プラン） | $228〜$2,988（月額$19〜$249の年換算） |
| MemPalace（wake-up + 検索） | ~$10 |
インストール
pip install mempalace
# 初期セットアップ（対話形式でWing/Roomを構成）
mempalace init ~/projects/myapp
# データの取り込み
mempalace mine ~/projects/myapp # プロジェクトファイル
mempalace mine ~/chats/ --mode convos # 会話エクスポート（Claude, ChatGPT, Slack）
mempalace mine ~/chats/ --mode convos --extract general # 自動分類（決定、好み、マイルストーン等）
# 検索
mempalace search "why did we switch to GraphQL"
「記憶の宮殿」アーキテクチャ — How it works
古代ギリシャの弁論家たちは、スピーチの内容を架空の建物の部屋に配置して暗記しました。建物の中を歩き回れば、アイデアが見つかる。MemPalaceはこの**Method of Loci（記憶の宮殿）**をAIメモリーに応用しています。
階層構造
Palace（宮殿）
└─ Wing（翼）= 人 or プロジェクト
│
├─ Room（部屋）= 具体的なトピック（auth-migration, ci-pipeline等）
│ ├─ Closet（クローゼット）= 圧縮サマリ → 高速検索用
│ └─ Drawer（引き出し）= 原文そのまま保存
│
├─ Hall（廊下）= 同じWing内のRoom間をつなぐ接続
│ facts / events / discoveries / preferences / advice
│
└─ Tunnel（トンネル）= 異なるWing間で同名Roomをつなぐ接続
Wing が最上位の分類、Room が具体的なトピック、Hall はRoom間を記憶タイプ（facts, events, discoveries, preferences, advice）でつなぐ廊下、Tunnel は異なるWing間で同じトピックを横断的にリンクする通路です。
Tunnel — Wing間の横断検索
同じRoom名が複数のWingに存在すると、Tunnel が自動で張られます。これが強力です。
wing_kai / hall_events / auth-migration
→ 「KaiがOAuthトークンのリフレッシュをデバッグ」
wing_driftwood / hall_facts / auth-migration
→ 「チームがClerkへの移行を決定」
wing_priya / hall_advice / auth-migration
→ 「PriyaがAuth0よりClerkを承認」
同じトピック（auth-migration）が人・プロジェクト・アドバイスの3つの文脈から引ける。「auth周りの経緯を教えて」と聞くだけで、関連する全Wingから情報が集まります。
構造だけで検索精度 +34%
22,000件の実会話メモリーでの検証結果：
| 検索方法 | Recall@10 | 改善幅 |
|---|---|---|
| 全Closet検索（絞り込みなし） | 60.9% | — |
| Wing内に絞り込み | 73.1% | +12% |
| Wing + Hall | 84.8% | +24% |
| Wing + Room | 94.8% | +34% |
フォルダ構造がそのまま検索精度に直結する。「構造は飾りではなく、プロダクトそのもの」という思想が数字で裏付けられています。
4層メモリースタック
起動時はL0 + L1の約170トークンだけをロード。数ヶ月分のコンテキストをこのサイズで持てるのがポイントです。必要なときだけL2・L3に降りていく。
AAAK圧縮
MemPalaceのもう一つの核心技術がAAAK — AI専用に設計されたロスレス圧縮方言です。人間が読むものではなく、AIが高速に読むための短縮表記。
英語 vs AAAK
英語（~1,000トークン）：
Priya manages the Driftwood team: Kai (backend, 3 years),
Soren (frontend), Maya (infrastructure), and Leo (junior,
started last month). They're building a SaaS analytics platform.
Current sprint: auth migration to Clerk.
Kai recommended Clerk over Auth0 based on pricing and DX.
AAAK（~120トークン）：
TEAM: PRI(lead)|KAI(backend,3yr) SOR(frontend) MAY(infra) LEO(junior,new)
PROJ: DRIFTWOOD(saas.analytics)|SPRINT: auth.migration→clerk
DECISION: KAI.rec:clerk>auth0(pricing+dx)|★★★★
同じ情報で約8倍の圧縮。AIはMCPサーバーのmempalace_statusレスポンスからAAAKを自動学習するので、手動設定は不要です。
特定のモデルに依存しないのも特徴で、Claude, GPT, Gemini, Llama, Mistralなどテキストを読めるモデルならどれでも動作します。ローカルLLMと組み合わせれば完全オフラインの記憶スタックが実現できます。
AAAKの品質に関する注意: 後述のベンチマーク論争セクションで触れますが、コミュニティからは「ロスレス」という表現に対して検索品質への影響を指摘する声もあります。
Knowledge Graphと矛盾検出
SQLiteベースのTemporal Entity-Relationship Graphを内蔵しています。Zep（Graphiti）がNeo4jに依存するのに対し、MemPalaceはSQLiteで完結。
時間軸付きファクト管理
from mempalace.knowledge_graph import KnowledgeGraph
kg = KnowledgeGraph()
# ファクトの追加（有効開始日付き）
kg.add_triple("Kai", "works_on", "Orion", valid_from="2025-06-01")
kg.add_triple("Maya", "assigned_to", "auth-migration", valid_from="2026-01-15")
# ファクトの無効化（終了日付き）
kg.invalidate("Kai", "works_on", "Orion", ended="2026-03-01")
# 特定時点での状態クエリ
kg.query_entity("Maya", as_of="2026-01-20")
# → [Maya → assigned_to → auth-migration (active)]
# 時系列ストーリー
kg.timeline("Orion")
# → プロジェクトの時系列ストーリー
ファクトに有効期間があるので、「今のKaiの担当は？」と「1月時点でのKaiの担当は？」で異なる結果が返ります。
矛盾検出
READMEでは以下のような矛盾検出が紹介されています：
入力: 「SorenがAuth移行を完了した」
出力: 🔴 AUTH-MIGRATION: 帰属の矛盾 — 担当はMayaであり、Sorenではない
入力: 「Kaiは2年前から在籍している」
出力: 🟡 KAI: wrong_tenure — 記録では3年（2023-04開始）
Knowledge Graphに登録されたファクトとの照合で、帰属ミスや日付の矛盾を検出する仕組みです。
使い方 — 3つの利用シーン
1. MCP Server連携（Claude Code / Cursor）
# MCPサーバーとして接続（1回だけ）
claude mcp add mempalace -- python -m mempalace.mcp_server
# あとは普通に会話するだけ
# 「先月のauth周りの決定って何だっけ？」
# → AIが mempalace_search を自動で呼び出して回答
19のMCPツールが使えるようになります：
| カテゴリ | ツール数 | 主な機能 |
|---|---|---|
| Palace読取り | 7 | 検索、Wing/Room一覧、taxonomy取得 |
| Palace書込み | 2 | Drawer追加・削除 |
| Knowledge Graph | 5 | エンティティ照会、ファクト追加・無効化 |
| Navigation | 3 | グラフ走査、Tunnel探索 |
| Agent Diary | 2 | AAAK日記の読み書き |
2. ローカルLLM — 完全オフライン構成
# wake-upでL0+L1コンテキストを生成
mempalace wake-up > context.txt
# Llama / Mistral等のSystem Promptに貼るだけ
または検索結果をプロンプトに注入：
mempalace search "auth decisions" > results.txt
# results.txt をプロンプトに含める
クラウドに一切データを送らずにAIメモリーを実現できます。
3. Auto-Save Hooks（Claude Code用）
{
"hooks": {
"Stop": [{
"matcher": "",
"hooks": [{
"type": "command",
"command": "/path/to/mempalace/hooks/mempal_save_hook.sh"
}]
}],
"PreCompact": [{
"matcher": "",
"hooks": [{
"type": "command",
"command": "/path/to/mempalace/hooks/mempal_precompact_hook.sh"
}]
}]
}
}
- Save Hook: 15メッセージごとに自動セーブ（トピック、決定、引用、コード変更）
- PreCompact Hook: コンテキスト圧縮前の緊急セーブ
ベンチマーク — 公式スコア
READMEおよびBENCHMARKS.mdで報告されているスコア：
| ベンチマーク | モード | スコア | API呼び出し |
|---|---|---|---|
| LongMemEval R@5 | Raw（ChromaDBのみ） | 96.6% | ゼロ |
| LongMemEval R@5 | Hybrid v4 + Haiku rerank | 100%（500/500） | ~500 |
| LoCoMo R@10 | Raw, session level | 60.3% | ゼロ |
| Palace構造の効果 | Wing+Room絞り込み | +34% R@10 | ゼロ |
96.6%のrawスコアは「APIキーなし・クラウドなし・LLM不使用」の条件下では最高の公開スコアとされています。
既存メモリーシステムとの比較
| 項目 | MemPalace | Mem0 | Zep (Graphiti) | Supermemory |
|---|---|---|---|---|
| ストレージ | ChromaDB + SQLite | クラウド | Neo4j | クラウド |
| 動作環境 | 完全ローカル | クラウド/セルフホスト | クラウド/Enterprise | クラウド |
| コスト | 無料 | $19–249/月 | $25/月〜 | — |
| Knowledge Graph | SQLite（temporal） | あり | Neo4j（temporal） | — |
| MCP対応 | 19ツール | あり | あり | — |
| 圧縮 | AAAK（AI専用方言） | LLM要約 | LLM要約 | LLM要約 |
| 設計思想 | 全保存 + 構造検索 | AI選別 + 抽出 | AI選別 + グラフ | AI選別 |
| ライセンス | MIT | OSS + 有料 | OSS + 有料 | — |
MemPalaceの最大の差別化は**「全保存 + 構造で見つける」という設計思想と完全ローカル動作**です。一方で、Mem0やZepはプロダクション環境での実績が豊富で、エンタープライズサポートがある点で優位です。
批判の声も — ベンチマーク論争を正直に見る
公開直後から、ベンチマーク手法に対してコミュニティから重要な指摘が出ています。特にPenfield Labsの検証記事とHacker Newsでの議論が詳しいので、主なポイントを整理します。
LongMemEval: 検索ステップのみ
本来のLongMemEvalベンチマークは3段階を要求します：
- 関連セッションの検索（Retrieval）
- 回答の生成（Generation）
- GPT-4による正誤判定（Judging）
MemPalaceの実装はステップ1のみ。gold session IDがtop-5に含まれるかを確認する検索リコールのタスクであり、end-to-endのベンチマークとは異なります。
LoCoMo: top_k=50問題
MemPalaceのBENCHMARKS.md自身が認めている問題です：
top-k=50 exceeds that count. This means the ground-truth session is always in the candidate pool regardless of the embedding model's ranking.
各会話のセッション数は19〜32。top_k=50に設定すると全セッションが候補に入り、実質的にClaude Sonnetに「どれが正解？」と聞いているだけになります。
AAAK「ロスレス」の実態
READMEでは「30x compression, zero information loss」と謳われていますが、ベンチマーク結果を見ると：
- Raw（非圧縮）: 96.6% R@5
- AAAK圧縮後: 84.2% R@5
12.4ポイントの品質低下が計測されています。ロスレス圧縮であれば品質低下は起こりえません。
teaching-to-the-test
100%スコアの達成には、dev-setで失敗した3問に対する個別パッチ（引用フレーズのブースト、人名ブースト、特定テキストのパターンマッチ）が含まれています。held-outテスト（450問、チューニング対象外）のスコアは**98.4%**と報告されています。
内部ドキュメントの誠実さ
興味深いのは、BENCHMARKS.mdには5,000語以上の詳細な方法論ノートがあり、上記の制約を正直に記述している点です。問題は、README やXでの告知ではこれらの注意書きが省略されていることです。
それでも本物の価値
上記の指摘を踏まえても、Palace構造による+34%の検索精度向上は批判記事でも否定されていません。22,000件の実データでの検証結果であり、Wing/Hall/Roomによる絞り込みがセマンティック検索の精度を大幅に向上させるという知見は有効です。
まとめ
MemPalaceは、ベンチマークの見せ方には議論があるものの、アーキテクチャの設計思想には学ぶ価値があるプロジェクトです。
本物の価値：
- 「全保存 + 構造で見つける」という、LLM要約に頼らない設計思想
- Wing / Hall / Room の階層構造で検索精度+34%
- 完全ローカル動作で年間~$10
- MCPサーバー対応で既存のAIワークフローに統合可能
注意点：
- ベンチマークスコアは検索リコールであり、end-to-endの評価ではない
- AAAK圧縮には検索品質への影響がある
- BENCHMARKS.mdを読んで自分で判断することを推奨
個人的には、自分のObsidian vaultでmempalaceの構造を試してみています。Wing（部門 / 学習 / プロジェクト）にRoom（具体的なトピック）を紐づけて、セマンティック検索を重ねるだけで「蓄積したノートが引ける資産になる」感覚があります。
ベンチマークは鵜呑みにしない。でも、良いアーキテクチャは読んで損がない。そういうプロジェクトだと思います。