Memory MCP Server は、AI エージェントに「会話をまたいだ長期記憶」を持たせるための MCP サーバーだ。エンティティ(ノード)とリレーション(エッジ)からなる知識グラフを構築し、それをローカルの JSON ファイルに永続化する。

何を解決するか

LLM は単体ではセッションが終われば文脈を忘れる。Memory MCP Server を組み合わせると、ユーザーの嗜好・過去のやりとり・プロジェクト固有の前提知識をグラフとして書き留め、次の会話でそれを読み出せる。「前に伝えたことを毎回説明し直す」という、エージェントを使い続けるうえで一番の摩擦を減らせるのがこのサーバーの存在意義だ。

仕組みと使い方

エンティティの作成・検索・削除、リレーションの追加・削除、テキストによるグラフ検索といった操作が用意されている。データは JSON ファイルに保存されるため、中身を直接覗いて確認・編集できる透明性がある。MIT ライセンスのオープンソースで無料、ローカルにセルフホストする。

記憶の質はプロンプト設計次第

このサーバーは記憶の「保管庫」を提供するだけで、何を覚え何を捨てるかは判断しない。エージェントが無秩序にエンティティを作り続けると、グラフはすぐに雑多な事実の山になり、検索しても関連性の薄い情報が混ざる。「重要な事実だけを構造化して記録する」「会話の終わりに記憶を整理する」といった指示をシステムプロンプト側で与えて初めて、長期記憶として機能する。記憶の運用ルールは利用者が設計する領域だと考えたい。

スケールの限界

ストレージが単一の JSON ファイルである以上、扱える知識量には実用的な上限がある。エンティティが数万、数十万と増えるような大規模な知識ベースを構築する用途では、検索性能も含めて専用のグラフ DB のほうが適している。また単一ファイルはプロセス間で同時に書き込むと壊れやすく、複数のエージェントで共有する用途にも向かない。Memory MCP Server は、個人やプロジェクト単位の「程よい量の記憶」をエージェントに持たせる、軽量な選択肢として捉えるのが現実的だ。

🔴
会話に出てきた機微な情報が、そのまま平文で保存されます

何をエンティティとして書き留めるかを決めるのはエージェント側です。作業の途中で貼り付けた認証情報、顧客名、社内の未公開情報が「覚えておくべき事実」と判断されれば、ローカルの JSON ファイルに平文で残ります。書き込まれたことは画面上ほとんど目立たないため、気づかないまま蓄積されがちです。ファイルをバックアップ対象や同期フォルダに置いていると、そのまま複製されます。記憶を有効にする前に、保存先がどこで、誰がそのファイルを読めるかを確認してください。

記憶は「貯める」より「捨てる」設計が要る

このサーバーには記憶を古くする仕組みも、重要度を判定する仕組みも無い。エンティティは 書き込まれた分だけ増え続け、古い前提と新しい前提が同じ重みで並ぶ。過去に一度だけ 述べた仮の方針が、半年後の判断材料として読み出されるという壊れ方をする。

現実的な運用は、定期的にファイルを開いて中身を目で見ることに尽きる。JSON なので 人が読める形式であることが、ここでは利点になる。不要になったエンティティを削り、 古くなった事実を書き換える作業を、月に一度でも入れておくと記憶の質が保たれる。

プロジェクトをまたぐと文脈が混ざる

保存先を分けない限り、記憶は 1 つのファイルに集約される。複数のプロジェクトで同じ クライアント設定を使っていると、別案件の前提が混入した回答が返ってくる。 用途ごとに保存先を分けるか、エンティティ名にプロジェクトの接頭辞を付けるルールを 決めておくと、この混線を避けられる。