Nocturne Memory レビュー: MCP エージェントに「人格ごと持ち運べる記憶」を与える SQLite/PostgreSQL サーバー

解決しようとしている問題は「記憶の置き場所」であって検索精度ではない

README が繰り返し述べるのは、ChatGPT の記憶は ChatGPT に、Claude の記憶は Claude に閉じているという指摘だ。モデルを乗り換えた時点で文脈がゼロに戻る。Nocturne Memory はこの状態を「記憶がモデル側にあるから起きる」問題として扱い、記憶を独立した MCP Server に移す。図で示されている構成は単純で、中央に Nocturne Memory が座り、Claude、Gemini、GPT といったクライアントがそこへ読み書きする。対象読者は、複数の MCP クライアントを日常的に使い分けている個人、あるいは AI に継続的な人格や関係性を持たせたいと考えるユーザーだ。仕事の文脈を溜める用途より、README の表現を借りれば「主権智能体（Sovereign AI）」の記憶を預ける用途を想定している。ベクター検索の精度改善を狙うツールではない点は、導入前に押さえておきたい。

記憶はベクターではなくツリー構造で、パス指定で取り出す

README の用例を見ると、AI が新規セッションで最初に呼ぶのは read_memory("system://boot") で、次に search_memory("jobstation")、続いて read_memory("core://work_jobstation/commercialization") のように個別のノードを読む。つまり記憶は埋め込みベクトルの集合ではなく、core:// や system:// といったスキーム付きのパスで識別されるノードの木として格納されている。検索はあくまで入口で、実際の内容はパスを指定して取りに行く。README は「新对话只载入你指定的核心设定，其余按需调取」と説明しており、起動時に全記憶をコンテキストへ流し込まない設計だと読み取れる。README が示す数値では、96.9 万字の記憶庫で最初のメッセージが読み込むのは 7.2K 字、過去 30 日で全記憶の 78% がいずれかの会話で参照されたとされている。ただしこの数値は README の主張であり、独立した検証は提供されていない。

ロールバックと人間による確認が記憶操作の前提になっている

README のスクリーンショット説明には、Memory Explorer でのツリー閲覧、Memory Detail での内容とメタデータの編集、Review & Audit での差分表示とワンクリックの承認またはロールバック、そして「AI の操作ごとに自動バックアップ、削除は人間の確認が必要」とある。これは長期記憶サーバーとしては珍しい方向性だ。記憶を書き込む主体が LLM である以上、誤った自己認識や誤った事実がそのまま永続化される危険がある。Nocturne Memory はそれを、書き込みを不可逆にせず差分として見せ、削除だけは人間が承認するという運用で抑えようとしている。記憶を「AI に任せて自動で育つもの」ではなく「人間が監査できる資産」として扱っている点が、他の記憶レイヤーとの設計上の分かれ目になる。

インストールは 2 ステップ、ただしクライアントごとに args が変わる

README の手順は短い。git clone https://github.com/Dataojitori/nocturne_memory.git を実行し、ディレクトリに入って pip install -r backend/requirements.txt を走らせる。前提は Python 3.10+ と Node.js で、Node.js は初回起動時に Dashboard のフロントエンドをビルドするために使われる。MCP クライアントへの接続では、エントリポイントの指定がクライアントによって異なる。README は Antigravity の場合に args を backend/mcp_wrapper.py に向ける必要があると明記している（Windows の CRLF 問題への対処とされている）。それ以外のクライアントでは backend/mcp_server.py を指す。インストールを AI に任せるためのプロンプトも README に用意されており、その中で「どのクライアントを使っているかを必ず確認する」よう指示されている。つまり、ここを間違えると動かない。インストール前に自分のクライアントがどちらのパスを要求するかを確定させておく必要がある。

公開 Demo は読み取り専用で、書き込みは自分のインスタンスが要る

README にはインストール不要の試用経路が用意されている。OpenAI Codex なら .codex/config.toml に [mcp_servers.nocturne_memory_demo] を追加し、url = "https://misaligned.top/mcp" を設定する。Antigravity なら MCP 設定に serverUrl として同じ URL を書く。ただし README の注記どおり、Demo は読み取り専用で read_memory と search_memory しか公開していない。記憶を書く、更新する、削除するといった操作を試すには自分のインスタンスを立てる必要がある。評価の順序としては、まず Demo で想起の質を確かめ、納得してからローカルへ移すのが無駄が少ない。逆に、Demo の応答だけを見て「記憶が書ける」と判断すると、実際の運用で必要になる書き込み経路の確認を後回しにしてしまう。

Namespace 分離は複数人格向けで、マルチユーザー向けではない

README は Namespace 分離に触れ、Alice と Bob のように複数の AI 人格を同時に運用する場合、それぞれに独立した記憶空間を持たせられると説明している。これは同一ユーザーが複数のペルソナを飼う場面を想定した機能だ。注意したいのは、これがチームや組織で記憶を共有するための仕組みとして説明されていないことだ。README には認証、権限管理、監査ログ、同時書き込みの競合解決についての記述が見当たらない。複数人が同じインスタンスへ接続する運用を考えるなら、その部分は自分で設計する必要がある。個人が自分の AI のために 1 インスタンスを立てる、という使い方が README の想定に最も近い。

保存先は SQLite と PostgreSQL の二択、選択は運用で決まる

バッジとトピックから、コアの保存先が SQLite と PostgreSQL の両方に対応していることが読み取れる。SQLite はファイル 1 つで完結するため、個人がローカルで動かす場合の初期コストは低い。PostgreSQL は常駐プロセスと接続設定が必要になる代わりに、複数プロセスからの接続やバックアップ運用に向く。どちらを選ぶかは、記憶を書き込む主体が 1 つの MCP クライアントだけか、複数クライアントから同時に触るかで変わる。README はこの選択基準までは示していないので、backend/requirements.txt と設定ファイルを読んで、どのドライバが実際に必要になるかを確認したうえで決めるのが確実だ。記憶は蓄積されるほど移行が重くなるため、最初の選択が後から効いてくる。

OpenClaw の代替として見るなら、互換の範囲を自分で確かめる必要がある

リポジトリの説明には OpenClaw のドロップイン代替とあるが、README 本文で確認できるのは「OpenClaw を含む MCP 対応クライアントで使える」という記述までだ。既存の OpenClaw 環境が持つツール名、記憶のパス体系、設定キーがそのまま通るのかは、この資料からは判断できない。移行を前提にするなら、現在使っているツール呼び出しの一覧と、Nocturne Memory が公開する read_memory、search_memory などの名前を突き合わせる作業が先に来る。また、記憶の実体を別サーバーへ移す以上、既存の記憶データをどう持ち込むかという移行経路も別途確認が要る。ドロップインという語だけを根拠に本番環境を切り替えるのは避けたい。

どんな用途で失敗するか: 想起の設計を人間がやらされる

この方式の弱点は、記憶の構造を人間が設計し続ける必要がある点だ。README の用例では core://work_jobstation/commercialization のようなパスが既に整備されており、AI はそれを読むだけで済んでいる。しかし新しい話題が増えるたびに、どの階層へどう置くかを決めるのは運用側の仕事になる。ベクター RAG なら文書を放り込めば類似検索が勝手に効くが、Nocturne Memory ではパスの命名と階層設計が想起の質を直接左右する。加えて、起動時に system://boot で読み込む核心設定を絞り込みすぎれば必要な文脈が落ち、広げすぎれば README が掲げるトークン節約の利点が消える。この調整は自動化されておらず、使いながら手で詰めるしかない。手間をかけたくない用途、とりあえず大量の文書を検索させたい用途には向かない。

編集部の結論

導入を検討すべきなのは、複数の MCP クライアントを併用していて、モデルを切り替えても同じ記憶を引き継ぎたい個人開発者や小規模チーム。逆に、社内の複数ユーザーで共有する記憶基盤や、監査ログを厳密に求められる用途には向かない。まず backend/requirements.txt と backend/mcp_server.py の中身を読み、記憶の保存先が SQLite か PostgreSQL かを決めたうえで、Demo サーバー（https://misaligned.top/mcp）に read_memory と search_memory だけを繋いで、自分の用途で想起が成立するかを確認するのが最初の一歩になる。

公式情報源

1. Dataojitori/nocturne_memory on GitHub
2. License: MIT
3. Project website
4. README
5. Releases