Cypher MCP の位置づけと技術構造

ここで言う Cypher MCP は通常 Neo4j Labs の mcp-neo4j-cypher を指す。これは「AI のための長期記憶サービス」そのものではなく、 Neo4j のスキーマ取得と Cypher 読み書きを MCP ツールとして露出する graph DB 接続・操作レイヤー である。 2026 年時点では別系統の official Neo4j MCP server も存在し、こちらは HTTP 認証、 TLS、起動時チェックなどを備えている。 Cypher MCP を評価する際は「Labs の実験的サーバ」と「公式プロダクト系サーバ」を切り分ける必要がある。

プロダクト分類 — 「記憶エンジン」ではなく「DB 接続層」

Cypher MCP の本質は「記憶アプリケーション」ではなく、「知識グラフを AI から直接扱うための MCP ゲートウェイ」である。 Neo4j Developer Guide でも、 Cypher サーバの役割は「グラフ DB スキーマを取り出して LLM に Cypher 生成の前提を与え、読み書きクエリを実行させること」と明示されている。

つまり Mem0 のような「記憶抽出・更新・検索アルゴリズムを持つ memory engine」ではなく、 underlying Neo4j を AI に開放するインターフェース層である。これは設計思想上の重要な区別で、利用者側は schema 設計、書き込みポリシー、競合解決、評価、 security、テナント分離を自前で設計する責任を負う。

競合・代替の 4 層

Cypher MCP の競合は少なくとも 4 つの層に分かれる:

1. Official Neo4j MCP server — bearer / basic 認証、 TLS、 HTTP / STDIO、起動時検証、 GDS の自動無効化など本番運用に寄った機能
2. 同じ Neo4j Labs 内の他 MCP — Neo4j Memory MCP (エンティティ・関係・観測を書き込む知識グラフ記憶に特化)、 Data Modeling MCP (スキーマ設計・可視化・検証)
3. Google Cloud MCP Toolbox の Neo4j 連携 — より広いツール統合基盤の一部
4. 専用 memory layer — Mem0、 Zep など (DB 操作よりも記憶抽出、重複抑制、検索、スコープ管理を前面に出す)

Cypher MCP はこの中で 「もっとも低位で柔軟だが、もっともアプリ設計責任が大きい」 位置にある。

ターゲットユーザーと市場

ターゲットは Neo4j を既に使っているか、知識グラフを AI の基盤にしたい開発者・データエンジニア・プロダクトチーム。公式ページは Neo4j Aura、 Self-Managed、 Docker、 Desktop、 Sandbox を前提にし、クライアント側は Claude Desktop、 VS Code、 Cursor、 Windsurf、 Gemini CLI などの MCP 対応環境を想定する。

つまり市場としては「一般消費者向け記憶アプリ」ではなく、 「MCP 対応 AI ツールを業務データや知識グラフに接続したい B2D / B2B 開発者市場」 が主戦場。なお、このサーバは Neo4j Labs であり、公式 README は「活発にメンテされているが SLA も後方互換保証もない」と明言している。

技術要素とアーキテクチャ

3 つの中核ツール

主要コンポーネントはシンプルで、 3 系統が中核:

• get_neo4j_schema — APOC 依存、 apoc.meta.schema ベースで label ごとに既定 1000 ノードをサンプル (-1 でフルスキャン)
• read_neo4j_cypher — JSON 化された結果を返す
• write_neo4j_cypher — Cypher 実行の要約を返す

複数 DB 接続を同一セッションで扱うための namespace 機能 があり、 mydb-read_neo4j_cypher のようにツール名プレフィックスを切れる。

Transport

server README では STDIO / HTTP / SSE、ルート README では「HTTP は modern web deployment 向けの streamable HTTP」と整理される。ドキュメントは非同期に進化しているが、 local client と remote / web deployment の両対応を志向していることは明確。

データモデルとストレージ

データモデルは MCP サーバ独自ではなく、 Neo4j の property graph に完全委譲。ノード・リレーションシップ・プロパティから成る property graph を基本とし、 Cypher は宣言的クエリ言語。

ストレージ・検索・インデクシングも Neo4j 側の責務。 Neo4j 5 系の公式ドキュメントでは vector index と vector similarity functions がサポートされ、テキスト記憶を embedding として保持してセマンティック検索可能。

長期記憶用途の定石は三層化:

1. 構造記憶 = グラフ (ノード・関係)
2. 曖昧検索 = Neo4j の vector index
3. 最終応答 = LLM

Cypher MCP はその上の操作面を MCP に変換するだけで、検索品質や一貫性は underlying graph schema と index 設計に支配される。

セキュリティと運用上の注意

Labs 版 Cypher MCP は 2025 年に DNS rebinding 脆弱性 が報告され、 v0.4.0 で CORS middleware による web-based access の既定拒否で修正された。現行 README では allowed_hosts と allow_origins で既定 localhost / 127.0.0.1 のみ許可、ブラウザ系アクセスはブロック。

その他の運用 knob:

• NEO4J_READ_ONLY=true — 読み取り専用化
• NEO4J_READ_TIMEOUT — 長時間クエリ抑制
• NEO4J_RESPONSE_TOKEN_LIMIT — 過大応答抑制

ただし Labs 版は HTTP mode で「認証」そのものを前面に出しておらず、 SSE / HTTP mode の認証不足懸念 issue も立っている。 本番で HTTP 認証と TLS を必要とするなら official Neo4j MCP server を選ぶ のが妥当。

ロードマップと開発状況

「活発だが実験色が濃い」と要約できる。 2026-04-21 時点で neo4j-contrib/mcp-neo4j は 345 commits、 937 stars、 242 forks、 52 releases。最新の Cypher タグは mcp-neo4j-cypher-v0.6.0 (2026-04-10)。

主要マイルストーン:

• v0.4.0 (2025): DNS rebinding 対応、 CORS middleware
• v0.5.3 (2026-02-23): Python ベースイメージの security upgrade、既定 endpoint を /api/mcp/ から /mcp/ へ、 FastMCP version pin
• v0.6.0 (2026-04-10): _is_write_query 判定が単純 regex から EXPLAIN ベースへ (実 DB 実行セマンティクス寄りに)、 ToolError 標準化、起動時 ImportError 修正

公式ロードマップとしてまとまった artifact はなく、 GitHub の open issues 11 件と release notes が実質ロードマップの代替。 README 自体が「Neo4j Labs であり、後方互換保証なし」と明言しているため、 保守の活発さと API 安定性は別評価軸 で見る。

性能評価のフレーム

Cypher MCP には Mem0 のような公開ベンチマークは存在しない。一次情報で確認できるのは: 読み取りタイムアウト既定 30 秒、 read response の token truncation、 schema inspection のサンプリング、 AWS ECS Fargate / Azure Container Apps 向け cloud deployment ガイド。

つまり、この層の性能指標は「MCP サーバ自身の速さ」ではなく「Neo4j 側のクエリ計画、 indexes / constraints、データ量、 APOC / GDS の有無」に依存する。本番導入時は MCP サーバのメトリクスではなく、 Cypher の p50 / p95、 PROFILE / EXPLAIN、インデックスヒット率、 graph expansion の深さ、 LLM token 使用量を 別々に監視 すべきである。