AIエージェントに『前回どこまでやったか』を覚えさせるMCP-Memory──GoogleのOKF形式で記憶を人間可読なMarkdownに残す

Claude Desktop・Cursor・Antigravity・Windsurf・CodexといったAIコーディングツールに、セッションをまたいだ永続的な長期記憶を持たせるMCPサーバー「MCP-Memory」が公開されている。README本文で確認できる特徴は、メモリの記録形式にGoogleがGitHubで公開する「Open Knowledge Format（OKF v0.2）」を採用し、人間が読めるMarkdownファイルとSQLiteの高速インデックスを二重に保持する設計だ。

3行まとめ

• MCP-Memoryは、AIエージェントの記憶をOKF v0.2形式（YAMLフロントマター付きMarkdown）でmemory/フォルダに保存し、同時にSQLite FTS5で全文検索インデックスを作る
• 提供するMCPツールは6種類：memory_store・memory_retrieve・memory_search・memory_delete・memory_get_last・memory_update_last
• memory_get_lastとmemory_update_lastは「セッション開始直後に前回の続きを取得する」「マイルストーン達成時に更新する」という運用を、README自身が"AGENT DIRECTIVE"として明記している

二層構造——人間が読めるMarkdownと、高速なSQLiteインデックス

READMEはこのアーキテクチャを次のように説明している。

Human-Browseable OKF Directory: Automatically dumps and syncs every memory to disk as a raw .md file inside the memory/ bundle directory with hierarchical index.md progressive disclosure files […] High-Performance SQLite Indexing: SQLite FTS5 (Full-Text Search) and automatic triggers for sub-20ms key lookups and instant keyword searches.

（人間が閲覧可能なOKFディレクトリ：すべてのメモリを自動的にディスクへダンプ・同期し、memory/バンドルディレクトリ内の生の.mdファイルとして保存する。階層的なindex.mdによる段階的開示ファイルを伴う。〔中略〕高性能なSQLiteインデックス：SQLite FTS5（全文検索）と自動トリガーにより、20ミリ秒未満のキー検索と即座のキーワード検索を実現する）

保存されるメモリ1件は、次のようなYAMLフロントマター付きMarkdownとして書き出される（READMEのサンプルより）。

---
type: Agent Memory
title: Coding Style
key: user/preferences/coding_style
namespace: default
tags:
- preferences
- style
status: stable
generated:
  by: mcp-memory/0.2.0
  at: '2026-08-12T19:23:35Z'
created_at: '2026-08-12T19:23:35Z'
updated_at: '2026-08-12T19:23:35Z'
---

User prefers functional programming style with explicit type annotations.

この形式が準拠するOKF（Open Knowledge Format）v0.2の仕様書は、GoogleCloudPlatformのGitHub組織が公開するknowledge-catalogリポジトリのokf/SPEC.mdにあり、実際に本文まで開いて読んだ。リポジトリ自体のREADMEには、「Knowledge Catalog（旧Dataplex）」というGoogle Cloudの製品に関連するツール・エージェント・サンプルを集めたものだと説明されている一方、末尾には「This repository and its contents are not an official Google product.（このリポジトリとその内容は、Googleの公式製品ではない）」という免責文言も明記されていた。つまり、GoogleCloudPlatformというGitHub組織の下でホストされてはいるものの、OKF仕様自体もGoogleの正式な製品・標準としての位置づけではなく、あくまでサンプル・ツール群の一部という扱いになる。MCP-Memory自体はfellowgeek氏個人によるプロジェクトで、Google自身が開発したツールではない点も合わせて注意が必要だ。

SPEC.mdの本文（v0.2）を実際に読むと、status（draft|stable|deprecated、デフォルトはstable）やstale_after（絶対時刻でのstale判定）といったフィールドは、v0.1から追加された「加算的な変更（additive changes）」であり、MCP-Memoryのmemory_storeツールがオプションで受け付けるパラメータは、この最新のv0.2で追加された機能をそのまま使う形になっていることが確認できた。仕様書はさらに、type: Attested Computationという特別な概念タイプ（値そのものだけでなく、その値を導き出した計算過程ごと記録する仕組み）を独立した章（§10）で定義しており、記事本文で紹介したmemory_storeのconcept_typeオプションにある「Attested Computation」は、この仕様のこの部分を指していたことが裏取りできた。

6つのMCPツール——「前回の続き」を扱う専用ツールがある

READMEが列挙する6つのツールのうち、4つ（memory_store・memory_retrieve・memory_search・memory_delete）は一般的なCRUD操作にあたる。memory_storeはkey・content・project_rootを必須パラメータとし、tags・namespace・concept_type（Metric、Playbook、Attested Computation等）・status（draft|stable|deprecated）・stale_after（有効期限）・sources（出典の配列）といったOKF準拠のメタデータをオプションで受け付ける。

残る2つは、セッション間の引き継ぎに特化している。README本文はそれぞれに「AGENT DIRECTIVE（エージェントへの指示）」というラベルを付けて説明している。

memory_get_last — AGENT DIRECTIVE (Session Start): Retrieves the last recorded session checkpoint (system/last_memory) so the AI agent immediately knows where work was left off when opening a project or starting a session.

（memory_get_last——エージェントへの指示（セッション開始時）：直近に記録されたセッションのチェックポイント（system/last_memory）を取得し、AIエージェントがプロジェクトを開いた際やセッション開始時に、作業がどこで中断されたかを即座に把握できるようにする）

memory_update_last — AGENT DIRECTIVE (Milestones & Progress): Updates the canonical session checkpoint (system/last_memory) whenever completing a milestone, making key changes, or pausing work.

（memory_update_last——エージェントへの指示（マイルストーンと進捗）：マイルストーンを達成したとき、重要な変更を行ったとき、作業を中断するときに、正規のセッションチェックポイント（system/last_memory）を更新する）

これは、AIコーディングエージェントに「前回の続きから作業を再開させる」という、複数セッションにまたがるプロジェクトで頻繁に問題になる課題への直接的な対策として設計されていることが読み取れる。READMEが挙げる6つのツールを一覧にすると次の通り。

セットアップとプロジェクト分離

READMEによれば、セットアップはpython3 setup.pyという対話式ウィザードで、Antigravity・Claude・Cursor・Windsurf・Codexの各クライアントを自動検出して設定するとされる。手動設定の場合は、Claude Desktop等のJSON設定にrun.shへのパスを、Codex Desktopの場合は~/.codex/config.tomlにTOML形式で記述する。Claude Code CLIではclaude mcp add --scope user memory -- /ABSOLUTE/PATH/TO/run.shという1行で追加できるという。

デフォルトでは、メモリはプロジェクトのルートディレクトリ内にmemory/（Markdownファイル）と.mcp_memory/memories.db（SQLiteインデックス）として分離保存される。環境変数MCP_MEMORY_DB_PATHとMCP_MEMORY_DIRをホームディレクトリ配下のパスに設定すれば、複数プロジェクトで共有する単一のグローバルストアとしても使えるとREADMEは説明している。

テストコードが示す守備範囲──パストラバーサル対策に5件

リポジトリのtest_memory.pyを実際に開いて確認すると、23件のユニットテストが定義されていた。内訳を見ると、シリアライズ・パース、OKF準拠性の検証、SQLiteでのFTS検索、memory_get_last/memory_update_lastの一連のフロー、といった機能テストに加え、keyパラメータに../../etc/passwdのような相対パス・絶対パス・バックスラッシュを含む攻撃的な入力を渡した際に、意図したディレクトリの外へ書き込めてしまわないかを検証するテストが5件（test_memory_path_rejects_parent_traversalなど）含まれていた。AIエージェントが渡すkey文字列をそのままファイルパスの一部として使う設計である以上、パストラバーサル対策はこのツールの信頼性を左右する部分であり、少なくともテストコードのレベルではこの観点が意識されていることが確認できた。ただし、これらのテストが実際にCIで継続的に走っているか、テストがカバーしていない攻撃パターンが残っていないかまでは、この記事の範囲では検証していない。

実際にインストールして動かしたわけではない

この記事はGitHubリポジトリのREADME本文、OKF仕様書（SPEC.md）の本文、knowledge-catalogリポジトリのREADME、test_memory.pyのテストコードをそれぞれ実際に開いて確認した内容にもとづく。MCP-Memoryが実運用でどの程度安定して動くか、memory_storeで保存した内容が複数セッションにまたがって実際に一貫して取得できるかは確認していない。開発者「fellowgeek」の実名や所属もREADMEからは分からなかった。GitHub上のスター数はこの記事執筆時点で197だった。

Zenn・Qiitaともに日本語での言及はほぼ見当たらない（Qiitaでヒットした2件は一般的な「エージェント記憶」比較記事で、この実装固有の言及ではなかった）。この記事を書いている自分自身は、MCP-Memoryを実際にインストールしてClaude CodeやCursorから使ってみる検証は行っておらず、README記載の仕様をそのまま紹介するにとどまる。

関連記事: MCP（Model Context Protocol）とは / AIに毎回同じ説明をするのが面倒──「朝会」方式で引き継ぎをなくす運用

感想・指摘はコメント欄へ。