ハイブリッド memory アーキテクチャの設計指針

長期記憶を実装する際、純粋な Cypher MCP だけでも、純粋な Mem0 だけでも、それぞれ問題を抱える。実務で最も強い設計は 「Mem0 を user / session / agent ごとの軽量 memory plane、 Neo4j 系を enterprise canonical memory plane」 のハイブリッド構成である。本パートでは、この設計を支える 3 つの基本原則 (三層構成、 entity scope、 write gate) と評価指標を整理する。

「記憶の正本」を最初に決める

長期記憶設計でもっとも先に決めるべきは「何を記憶の正本にするか」である。

• Cypher MCP を採るなら、正本は property graph。記憶はノード・関係・時刻・証拠への参照として構造化される (explainable + schema-first)
• Mem0 を採るなら、正本は memory engine が管理する memory documents と entity scope。検索は semantic / BM25 / entity boost の融合 (integration-first)

二者択一せず併用する場合は、 どちらが正本でどちらが派生か を明示する。例: 「Mem0 が user / session memory の正本、 Neo4j が組織知識・監査証跡の正本」のような明確な責任分界を最初に書く。曖昧にすると重複記憶、整合性違反、削除伝播の漏れが必ず発生する。

三層構成

実運用で安定する典型構成:

┌────────────────────────────────────────┐
│ 短期バッファ (Prompt In-Context)        │
│ — 直前 N turns、現在 task の状態         │
└────────────────────────────────────────┘
              ▲
              │ retrieval
              ▼
┌────────────────────────────────────────┐
│ 耐久記憶 (Memory Plane)                  │
│ ┌────────────────┐  ┌──────────────┐   │
│ │ Mem0           │  │ Neo4j         │   │
│ │ user/session   │  │ canonical KB  │   │
│ │ hybrid retrieve│  │ graph + audit │   │
│ └────────────────┘  └──────────────┘   │
└────────────────────────────────────────┘
              ▲
              │ ingest
              ▼
┌────────────────────────────────────────┐
│ 外部文書知識 (RAG / Vector Store)        │
│ — manuals、 policy、 reference docs    │
└────────────────────────────────────────┘

各層は 異なる更新頻度・整合性要件・retention を持ち、混ぜないのが鍵。

Cypher MCP を長期記憶に使う場合の基本パターン

Schema 設計の基本

「事実」「出来事」「関係」を 明示的に分ける。典型的なノード型:

• User、 Agent、 Preference、 Project、 Event、 Artifact、 Constraint

典型的な関係:

• PREFERS、 WORKED_ON、 MENTIONED_IN、 CONTRADICTS、 SUPERSEDES

Properties で監査可能性を確保

ノード・関係に次の属性を持たせると一貫性検査と監査が容易:

• valid_from / valid_to (temporal 範囲)
• confidence (記憶の信頼度)
• source_session_id (どのセッション由来か)

Constraints で重複防止

Neo4j は constraint と index を正式サポート。 external_id や (user_id, key) の 一意制約 を張り、 upsert と重複防止をアプリ側 write policy に乗せる。

検索戦略 — Graph traversal と semantic recall を分離

• 曖昧検索・長文類似検索 → Neo4j vector index で candidate を拾う
• そのあと Cypher で 1〜2 hop の近傍や event timeline を引き直す

これにより「semantic で広く取り、 graph で深く絞る」段階的探索が成立する。

Mem0 を使う場合の基本パターン

Entity Scope を明示

• user_id / agent_id / app_id / run_id で境界を明示
• Mem0 Platform は複数 entity 記録を AND で引けない挙動を docs が明示しているため、 entity 横断クエリが必要なら設計段階で別経路を用意する

ADD-only への対応

2026 年時点の OSS は ADD-only 化が進行。古い記憶を update する代わりに新規 add し、検索時に最新を優先するアプローチに合わせる。 update / delete を頻繁に必要とするユースケースは Cypher 系が向く。

Hybrid retrieval の活用

semantic + BM25 + entity matching の score fusion を採用しているため、 query 設計時に「semantic 寄せたいか、 entity-exact 寄せたいか」をパラメータで明示する。日本語環境では BM25 と entity extraction が英語前提という open issue があるため、検索品質を必ず実データで評価する。

Write Gate — モデルに任せない 2 段階アーキテクチャ

統合方法は大きく二つ:

方式 A: Agent が MCP を直接叩く (低コスト・高リスク)

• Mem0 cloud MCP や Cypher MCP をそのまま tool として agent に見せる
• 開発が速いが、書き込みポリシーがモデル判断に依存しやすい
• 削除・更新の誤発火、 PII の意図しない記録、テナント越境のリスク

方式 B: アプリ側に memory service、 LLM には typed function call だけ (高コスト・低リスク)

• アプリケーション側に memory service を置く
• LLM には typed function call だけを見せ、 Cypher や REST は sidecar が処理
• 強制可能: 削除承認フロー、 PII マスキング、 schema validation、 tenant scoping
• 遅いが production-grade

実務上は Cypher で read-only server を AI に見せ、書き込みは別の validation service 経由 にする構成が安全。 Mem0 では entity scope を user_id / agent_id / app_id / run_id で明示し、更新・削除系は確認フローを挟む。

コスト・レイテンシ・一貫性の Trade-off

Mem0 の研究結果が分かりやすい benchmark 提供:

Cypher MCP 自体には公開ベンチマークなし。性能のボトルネックは通常 (a) graph expansion の深さ、 (b) vector query の品質、 (c) LLM answer synthesis のいずれか。

評価指標 — quality だけでは足りない

最低限、次を 別々に測定 する:

回答品質

• F1、 BLEU、 LLM-as-a-Judge

運用指標

• p50 / p95 latency
• token cost (input / output 別)
• retrieval recall@k
• 重複率 (同じ事実が複数記憶として記録される率)
• stale / conflict rate (古い記憶や矛盾記憶の発生率)
• tenant bleed 率 (entity scope を越えて他テナントの記憶が漏れる率)
• 削除伝播の完全性 (削除指示後に該当記憶が全層で消えているか)

実装上の注意点

• Memory poisoning: 悪意のある input が記憶に紛れ込む
• 誤抽出: LLM が事実でない内容を記憶として抽出
• 競合記憶: 矛盾する記憶が並存
• 英語偏重 retrieval: 多言語環境で日本語等の retrieval 品質が劣化
• スコープ誤設定: agent_id を間違えて他 user のメモリを読む
• schema drift (Cypher 系): 想定と異なる relation が増殖

実務的な推奨

ハイブリッド設計の最終形:

1. Mem0 = user / session / agent ごとの軽量 memory plane
   • 頻出嗜好、会話継続、コーディング履歴、ユーザ context
2. Neo4j 系 = enterprise canonical memory plane
   • 重要イベント、証拠、ワークフロー状態、関係推論、監査対象データ
3. 取得時 = まず Mem0 で low-latency な候補を取り、必要時だけ graph query で 1〜2 hop 展開

この方式なら Mem0 の speed と Cypher の explainability を同時に取れる。

導入手順は順番が重要:

1. 「記憶の正本」を決める (上記の責任分界)
2. scope と retention を設計 (user_id、 timestamp、 source attribution、 PII / 機密ポリシー、 conflict resolution rule)
3. write gate を置く (LLM 直叩きではなく typed function call → validation service)
4. 評価指標を定義 (quality + 運用 6 項目)
5. 小規模 PoC で評価指標を回し、 production scale-up

最終結論として、 Cypher MCP は「知識グラフを AI の長期記憶に昇格させる強力な primitive」、 Mem0 は「長期記憶を製品として扱う強力な abstraction」。前者は構造と統制、後者は速度と導入性。 2026 年時点で最も堅い選択は、グラフが本業なら Cypher / Neo4j 系を中核に、汎用 AI product の記憶面なら Mem0 を中核に、必要に応じて両者を疎結合で組み合わせることである。