Memory MCPの使いどころ｜AIの記憶5方式の選び分け

「毎回おなじ前提から説明し直しているので、覚えさせたい」。AIエージェントを業務で使い始めた人から、この相談をよく受けます。

覚えさせる、と言っても入れ物はひとつではありません。人が書く指示ファイルを置く方法もあれば、AIが自分で書き足していく方法もあります。どこに置くかで、あとから効いてくるものが変わります。

この記事は、その選択肢を並べたうえで、知識グラフ型のMemory MCPがどこに位置するかを整理します。運営元のWEBMARKSは、Memory MCPを自環境へ接続していません。ここから先は公式リポジトリと公式ドキュメントの記載確認（2026-08-03確認）に基づく整理で、使ってどうだったかという体感は書きません。

進行役は3人です。若葉さんが言葉のところから聞き、高梨課長が自分の手で動かす側から聞き、鈴木さん（本誌監修）が答えます。

01AIエージェントに記憶を持たせる方法は、Memory MCPだけなんですか？

若葉さん

若葉さんの発言

AIは話した内容をそのまま覚えていてくれるものだと思っていました。記憶を持たせる、というのは別の話なんですか。

鈴木さん

鈴木さんの発言

別の話です。会話が終われば忘れるのが既定で、残したいなら置き場所を先に決めます。ノートを1冊渡すのか、名簿を渡すのかで、あとの使い勝手が変わります。

Memory MCPとは、AIの記憶を「エンティティ・リレーション・観察」という知識グラフのかたちで保存するMCPサーバーです。MCPは、AIに外部のツールを触らせるための共通の口を指します。

先に、この記事で押さえてほしいところを挙げます。

1. 知識を3つの層で持ちます。事実そのものが観察、事実の持ち主がエンティティ、持ち主どうしのつながりがリレーションです
2. Claude Codeにも記憶の仕組みがあります。人が書くCLAUDE.mdと、Claudeが自分で書き足すauto memoryです。Memory MCPはその代役ではなく、複数のMCPクライアントから同じ知識グラフを見たいときの選択肢にあたります
3. 溜めた記憶は、呼び出し方を誤ると精度を下げます。全件を毎回読み込む呼び方を避け、検索と削除のツールを使い分けるのが対処の中心です

位置づけも先に確かめておきます。Memory MCPは、GitHubのmodelcontextprotocol/serversが公開する公式リファレンス実装のひとつです（出典: 同リポジトリ）。同リポジトリのREADMEは、収録サーバーを「教育用のサンプル実装であり、本番運用を前提にしたソリューションではない」と説明しています（出典: 同リポジトリREADME、2026-08-03確認）。

これは、MCPの選び方｜AIエージェントに任せる範囲から見る5軸で整理した提供元の信頼レベルのうち、もっとも慎重な確認を要する層にあたります。使ってはいけないという意味ではなく、業務で使うなら自分で確かめる範囲が広い、という意味です。

02Memory MCPを含め、記憶の残し方が違うと、AI活用の現場では何が変わるんですか？

記憶の持たせ方は、大きく5つに分かれます。「誰が書き込むか」「どう読み込まれるか」で並べると、Memory MCPの居場所が見えます。

上から下へ進むほど、記憶の粒度は「まとまった文章」から「事実の単位」へ細かくなります。

並べ替えて分かるのは、粒度の細かさと取り出しやすさが自動では結びつかないことです。細かく分けても、取り出すときに全部を持ってくれば、まとまった文章を丸ごと読むのと同じ荷物量になります。細かくした値打ちは、絞って取り出したときに初めて出ます。

知識グラフが向くのは、人物・案件・決定事項のように、複数の対象どうしのつながりをたどって参照したい場面です。逆に、毎回変わらず守ってほしい固定ルールだけなら、わざわざ知識グラフへ分解する手間は要りません。

MCPというしくみ自体の選び方、つまり権限範囲・提供元・更新頻度・障害時の影響・代替手段という見方は、記憶の方式を問わず共通です。

03Memory MCPの知識グラフって、AIエージェントの中では何がどうつながっているんですか？

若葉さん

若葉さんの発言

エンティティ、リレーション、観察。どれが何なのか、名前だけだと頭に入ってこなくて。

鈴木さん

鈴木さんの発言

社員名簿を思い浮かべると近いです。1人ずつのカードがあって、カードとカードを線でつなぎ、カードには気づいたことを1行ずつ書き足していく。その3点セットです。

Memory MCPの知識グラフは、3種類の要素でできています（出典: 同リポジトリREADME、2026-08-03確認）。

観察は「1つの観察につき1つの事実」という原子性が前提です（出典: 同リポジトリREADME）。ここが効いてくるのは、あとで一部だけを消したくなったときです。複数の事実を1つの観察へ詰め込むと、古くなった部分だけを外す操作ができなくなります。

04Memory MCPの9つのツールは、AI社員のどんな動きに当たるんですか？

知識グラフを操作するツールは9種類あります（出典: 同リポジトリREADME、2026-08-03確認）。

役割で束ねると、あとで効いてくる差が見えます。増やす側と減らす側は、書いた内容がそのまま結果になります。取り出す側だけは、同じ知識グラフでも呼び方によって返る量がまったく変わります。精度の話は、ほぼこの取り出し側で決まります。

保存形式はJSONLで、既定のファイル名はmemory.jsonlです。保存場所を変えたいときは、環境変数MEMORY_FILE_PATHにファイルパスを指定します（出典: 同リポジトリREADME）。

05Memory MCPをClaude Codeへ繋ぐとき、AIエージェント側で何をするんですか？

高梨課長

高梨課長の発言

接続そのものは、自分の手でできる範囲でしょうか。それとも環境を用意する話になりますか。

鈴木さん

鈴木さんの発言

手元で完結します。ローカルのプロセスとして起動するかたちなので、サーバーを立てる話にはなりません。ただ、保存先だけは最初に決めておいたほうがいいです。

接続はローカルプロセス（stdio）で完結します。Claude Codeの公式ドキュメントが示す構文に沿うと、次の1本で登録できます（出典: Claude Code公式MCPドキュメント）。

# 1. サーバーを登録する（自分専用のlocalスコープが既定）
claude mcp add --transport stdio memory -- npx -y @modelcontextprotocol/server-memory

# 2. 接続状態を確認する
claude mcp list

保存先を分離したいときは、環境変数を添えて登録します。

# プロジェクトごとに保存先を分けたい場合
claude mcp add --env MEMORY_FILE_PATH=/path/to/このプロジェクト専用/memory.jsonl --transport stdio memory \
  -- npx -y @modelcontextprotocol/server-memory

06Memory MCPをチームで共有するとき、AI社員ごとの承認はどうなるんですか？

ここまでは自分ひとりの環境の話です。同じ設定をチームへ配ると、承認の扱いが変わります。

チームで共有する場合は--scope projectを付け、.mcp.jsonへ書き出します。local・project・userというスコープの考え方は、MCPサーバーの種類を問わず共通です。project scopeのサーバーは、実行者ごとに1回、個別の承認が要ります（出典: Claude Code公式MCPドキュメント）。

07CLAUDE.mdとauto memoryがあるのに、AI導入でMemory MCPを足す理由は何ですか？

Claude Code自身にも、記憶の仕組みが2つ用意されています（出典: Claude Code公式ドキュメント、2026-08-03確認）。CLAUDE.mdは人が書く指示ファイルで、auto memoryはClaudeが自分の学びを書き足す自動追記ログです。

auto memoryの保存先は~/.claude/projects/<project>/memory/です。ここは索引役のMEMORY.mdと、詳細を書く複数のトピックファイルで構成されます。セッション開始時に読み込まれるのはMEMORY.mdの先頭200行または25KBまでで、それを超えた分は読み込まれません（出典: 同ドキュメント）。トピックファイルは、必要になったときにClaudeが個別に読みに行きます。

この構造が示しているのは、入り口を小さく保つ設計が最初から組み込まれているということです。全部を持っているのに、毎回持ち出すのは索引だけ。詳細は名前を指されたときに開く。あとで見るMemory MCPの課題は、この仕組みが用意されていない点から生まれます。

CLAUDE.mdの書き方はCLAUDE.mdの書き方｜7章テンプレートと200行の分け方にまとめています。ここで押さえておきたいのは、CLAUDE.mdもauto memoryも「文脈」として扱われ、強制力を持たない点です。

08AnthropicのMemory toolとMemory MCPは、生成AIの記憶として何が違うんですか？

もうひとつ、紛らわしい存在があります。AnthropicのAPIが提供する「Memory tool」です。これはMCPサーバーではなく、Messages APIへmemory_20250818という識別子を渡すと使える組み込み機能です。Claude 4以降の全モデルに対応しています（出典: Anthropic Platform Docs）。

ファイル操作はClaude側が要求し、実行するアプリ側が保存先を管理します。この点はMemory MCPと似ていますが、知識グラフではなく/memories配下のファイル群として記憶を持たせる設計です。

似ているのは「Claudeが記憶の出し入れを要求し、外側が保存を引き受ける」という関係だけです。渡す入り口も、持ち方の形も、管理する主体も違います。名前で選ぶと取り違えます。

09結局、AIエージェントの記憶はMemory MCPを含めどの方式へ寄せればいいんですか？

ここまでの4つを、向く場面と向かない場面で並べます。裏返して読むと、選ばない理由のほうがはっきりします。

AGI Journalを運営するWEBMARKS自身も、記憶の持たせ方はCLAUDE.mdとauto memoryの組み合わせに寄せています。知識グラフでなければ表現しにくい関係が、今のところ少ないためです。Memory MCPを否定する理由ではありません。

10Memory MCPで記憶が増えると、AIエージェントの精度はどこから落ちるんですか？

高梨課長

高梨課長の発言

記憶が増えると重くなる、という理解で合っていますか。

鈴木さん

鈴木さんの発言

重いというより、必要な話が埋もれる、が近いです。知識グラフ全体を返す呼び方をしていると、増えた分だけ関係のない事実まで一緒に付いてきます。

知識グラフが育つと、read_graphを呼ぶたびにグラフ全体がコンテキストへ返ります（出典: 同リポジトリREADME）。エンティティも観察も増える一方だと、無関係な事実まで一緒に読み込まれ、必要な事実が埋もれます。

この設計は、Claude Code自身のauto memoryと対照的です。auto memoryはMEMORY.mdに200行・25KBという上限を設けています（出典: Claude Code公式ドキュメント）。超えそうになるとClaudeへ短くするよう促し、実際に超えても書き込みは成功したうえで索引の書き直しをエラーで促し、超過分は次回読み込まれません。Memory MCPの参照実装には、この種の上限も自動的な整理も組み込まれていません。

差は機能の優劣ではなく、誰が上限を決めるかです。片方は仕組みの側が決めています。もう片方は、決める役が運用する側に回っています。決めないまま使うと、上限が無いのではなく、上限を誰も決めていない状態になります。

精度が落ちてきた兆候は、次のような形で現れます。

• read_graphを呼ぶたびに、いま必要な話と無関係なエンティティまで大量に返ってくる
• 同じ事実が言い回しを変えて、複数の観察として重複している
• 矛盾した観察が同じエンティティに残ったままになっている

11肥大化したMemory MCPの知識グラフは、AI社員の運用でどう棚卸しするんですか？

対処は、9種類のツールを使い分けることに集約されます。

1. read_graphを既定の呼び出しにしない：search_nodesで対象を絞る、open_nodesで名前が分かっているノードだけを取り出す、を優先します
2. 重複・陳腐化した観察をdelete_observationsで棚卸しする：1事実1観察の原則を保てば、古い観察だけをピンポイントで消せます
3. 使われなくなったエンティティはdelete_entitiesで削除する：つながるリレーションも連鎖して消え、孤立したリレーションが残りません
4. 索引と詳細を分ける階層を、運用ルールとして自分たちで課す：Memory MCP自体は、auto memoryのような階層やサイズ上限を強制しません。だからこそ「まず検索、全件取得は最後の手段」と明文化します
5. 毎回変わらず必要なルールはCLAUDE.mdへ格上げする：知識グラフ側は、都度参照すればよい関係情報だけに絞り込みます

入れ替えているのは、記憶の中身ではありません。取りに行き方です。同じ知識グラフでも、まず名前を指す作法にしておけば、育っても返ってくる量は増えません。

12Memory MCPでつまずくのは、AIエージェントの権限設計のどこですか？

高梨課長

高梨課長の発言

削除まで任せてよいのか、そこが気になります。消えたものは戻せませんよね。

鈴木さん

鈴木さんの発言

削除系だけは分けて考えています。公式の説明でも、つながるリレーションまで一緒に消える動きになっているので、確認を挟む設定にしておくほうが安心です。

1つめ、観察を1文にまとめすぎる。原子性の原則に反して複数の事実を1つの観察に詰め込むと、一部だけが古くなったときにdelete_observationsで部分的に消せません。結局、観察全体を削除して書き直す手間が増えます。

2つめ、保存先を指定せず、複数プロジェクトで既定のファイルを共有してしまう。MEMORY_FILE_PATHを設定しなければ、保存先はサーバーディレクトリ内のmemory.jsonlという既定値のままです。プロジェクトごとに指定しないと、別案件の知識グラフが混ざる余地が生まれます。

3つめ、削除系ツールをフル権限のまま使わせる。delete_entitiesはつながるリレーションまで連鎖して削除し、対象が存在しない場合も静かに処理されます（出典: 同リポジトリREADME）。Claude Codeならmcp__memory__delete_entitiesのような形式で権限ルールの対象にできます。

{
  "permissions": {
    "ask": [
      "mcp__memory__delete_entities",
      "mcp__memory__delete_relations"
    ]
  }
}

配分の考え方は、Claude Codeの権限設定｜AIエージェントに任せる範囲と3列の配分で扱った枠組みと同じです。静かに処理されるということは、失敗しても画面には何も出ないということでもあります。

13導入前に、AI導入の担当者はMemory MCPの何を確かめるんですか？

ここまでの内容を、着手前に確かめる項目へ落とします。

• 保存先をMEMORY_FILE_PATHで明示し、プロジェクトごとに分離したか
• read_graphを既定にせず、search_nodes・open_nodesを優先する運用にしたか
• 観察を1事実1文の粒度で書く運用を徹底したか
• delete_entities・delete_relationsなど削除系ツールの権限をaskまたはdenyで絞ったか
• 毎回変わらず必要なルールはCLAUDE.mdへ、都度参照でよい関係情報はMemory MCPへ、役割を分けたか
• 定期的に知識グラフ全体を棚卸しし、重複・矛盾した観察を削除する運用を決めたか
• Claude Code以外のクライアントからも同じ知識グラフを使う予定があるかを確認したか
• Memory MCPが公式リファレンス実装であり、本番運用を前提に作り込まれていないことを踏まえたか

埋まらない欄が残っているうちは、繋がないほうが安全です。特に保存先と削除権限は、あとから直すと、すでに混ざった記憶をほどく作業が付いてきます。

14よくある質問

15まとめ｜今日やる3つのこと

選び方は、機能の多さではなく「つながりをたどりたいか」で分かれました。繋いだあとに効いてくるのは、書き方ではなく取り出し方でした。そして削除だけは、任せる前に線を引いておく操作でした。