Dense-Mem セルフホスト MCP メモリサーバー 初回利用ガイド

向いている人

Dense-Mem は、AI エージェントにセルフホストの長期メモリを持たせ、PostgreSQL と Redis の両方を運用する意思がある開発者やチームに向いている。セッションに一時的なコンテキストを足すだけで、データベース運用は避けたいなら、これは適さない。記憶の自動化契約は MCP（Streamable HTTP、エンドポイント /mcp）として外部に提供される。まず正確なエビデンスをステージングし、サーバー側で検証済みポリシーによって意味的な状態を導出し、アクティブなエビデンスコンテキストとグラフ状の Relationship ハンドルを返す。知識・ライフサイクル・来歴・検索・認可・監査の永続的な権威はすべて PostgreSQL が担い、Redis は調整専用である。ブラウザルートはファーストパーティのインターフェースであり、外部向けの自動化入口ではない。

利用の前提と向かないケース：

• 起動には embedding と verifier の 2 つの AI サービス設定（後述の 5 変数）がすべて必要で、設定なしで動くモードはない。
• 利用前に知っておくべきデータ送信の副作用：エビデンステキスト、proposal コンテキスト、recall クエリは、設定したプロバイダーへすべて送信される。プロバイダーをセルフホストすればトラフィックは自分の境界内に留まり、ホステッドサービスではそうならない。
• 公式にサポートされる MCP クライアントの一覧、リソース要件、運用コストの根拠は示されておらず、これらは未確認である。

3 分で最初の試行

前提：docker compose を実行できるマシン。.env に POSTGRES_PASSWORD、CONTROL_PORTAL_TOKEN、AI_API_KEY を記入する。さらに起動には embedding と verifier の完全な設定、すなわち AI_API_URL、AI_API_KEY、AI_API_EMBEDDING_MODEL、AI_API_EMBEDDING_DIMENSIONS、AI_VERIFIER_MODEL が要る。公式に明記された起動前提であり、オプション扱いしてはならない。

注意：照会型の初回試行でも、recall クエリは設定したプロバイダーへ送信される。

公式の主経路（Docker Compose）：

curl -fsSLo docker-compose.yml \
  https://raw.githubusercontent.com/markhuangai/dense-mem/main/examples/docker-compose.base.yml
curl -fsSLo .env.example \
  https://raw.githubusercontent.com/markhuangai/dense-mem/main/examples/.env.example

cp .env.example .env
# Fill in POSTGRES_PASSWORD, CONTROL_PORTAL_TOKEN, and AI_API_KEY.
${EDITOR:-vi} .env

docker compose up -d

コンテナ起動後、MCP クライアントから /mcp に接続する。最初の呼び出しは照会型の recall_memory が良い。公式には「アクティブなエビデンスコンテキストと Relationship ハンドルを返す」と説明されている。起動直後でまだエビデンスを書き込んでいないインスタンスで何を返すかは、根拠には書かれていない。成功の目安：docker compose up -d が正常に完了し、クライアントが /mcp 経由でサービスにアクセスできること。

ユースケース

ケース 1：来歴つきのセッション横断メモリをエージェントに持たせる。シーン：エージェントがセッションをまたいだ事実を記憶し、後で出所を説明できるようにしたい。やり方：remember でエビデンスを書き込み、その後 recall_memory でアクティブなエビデンスコンテキストを呼び出して確認する。remember のパラメータと入力フォーマットは根拠に記載がなく、「公式のエビデンス書き込み入口である」ことまでしか確認できない。期待できる結果：エビデンスが受け入れられ、意味的な状態はサーバー側ポリシーで導出される。

ケース 2：ある関係がどう形成されたかを説明する。シーン：ある Relationship の形成過程を他者や下流システムに示したい。やり方：trace_memory を呼ぶ。公式には「同一チームの 1 つの Relationship に沿って、エビデンス・意思決定・来歴を追跡する」と説明されている。パラメータと戻り値の構造は根拠に記載がなく、「この照会機能が提供されている」ことまでとどめ、ここでサンプルを捏造しない。

利用の境界

• 読み書きの性質：remember はエビデンスの書き込み。retract_evidence は呼び出し元所有のエビデンスを引退させ、append-only の来歴を保持する。correct_relationship はアクティブな Relationship の、オーナーに限る置き換え（元の関係を置き換え、support lineage を保持）。recall_memory、trace_memory、export_memory_pack は照会・エクスポート型。公式はツールごとの読み書きフラグを示しておらず、照会系が決して書き込まないかは未確認である。
• 修正経路は上記の引退と置き換えの 2 つだけで、それ以外の書き込みは取り消し可能と解釈すべきでない。
• 認証情報とデータ面：.env の必須 3 値に加え、実行は PostgreSQL（永続）、Redis（調整）、外部 AI プロバイダーに依存する。エビデンステキスト、proposal コンテキスト、recall クエリはプロバイダーへ送信され、自分の境界内に留まるかはそのデプロイ位置次第である。
• 未確認：デフォルトポートと完全な URL、データの保持・削除ポリシー、チームやテナントの分離セマンティクス、CONTROL_PORTAL_TOKEN 以外の認証詳細。