何をしたか

「セッションを跨ぐとAIエージェントが前回の経緯を忘れる」——これはもう共有された悩みだと思います。
ではAIに聞いたとき、AIは何を薦めてくるのか。それを数えました。

13問 × 3エンジン = 39回答（2026-09-04 実測）
エンジン: Claude (claude-opus-4-8) / GPT-5.x / Perplexity (sonar)
システムプロンプトなし・質問文そのまま送信（普通のユーザーが受け取る既定の答えを見たいため）
質問は問題起点。製品名を一切出していない。例:
- 「Claude Codeがセッションをまたぐと過去の経緯を忘れてしまいます。記憶を持たせる方法を教えてください。」
- 「過去に決めた設計方針とコードがずれていないかを検出できるツールはありますか？」
- 「記憶MCPをnpmパッケージ名と導入コマンド付きで列挙して」

結果

挙がったもの	回答数(/39)	出た質問数(/13)
CLAUDE.md	15	7
Mem0	14	6
ADR（Architecture Decision Record）	10	6
Qdrant	8	5
Chroma	7	5
`@modelcontextprotocol/server-memory`	7	4
Letta	7	3
Zep	6	3
MemGPT	4	3
OpenMemory / Linksee Memory	各2	各2
claude-mem / memori	各1	各1

1位はツールではなくファイルでした。 2位のMem0を挟んで3位がADR——これもツールではなく慣習です。
つまり現時点でAIの既定解は「プロダクトを入れろ」ではなく「書き留めろ」。

（先に開示しておくと、私は linksee-memory というOSSのMCPサーバーを書いています。
それがこの39回答で挙がったのは2回です。数字は自分に不利な側もそのまま載せます。）

「CLAUDE.mdに書け」は正しい。ただし守備範囲が違う

まずAIの回答は妥当です。CLAUDE.md も ADR も、コストがほぼゼロで効果が出る。
最初にやるべきなのは間違いなくこちらで、これを飛ばしてツールを入れるのは順番が逆です。

ただ、実務で事故る場面を並べてみると、この2つが構造的に持てない情報があります。

	持てるもの	持てないもの
CLAUDE.md	書いたこと	書き忘れたこと。書いた後に変わったこと
ADR	決めたこと	決めた後、コードが決定から離れていったこと

事故の多くは3番目のカテゴリで起きます。「決めたのに、ずれた」。

具体的には、こういう形で出ます。

先週「MongoDBは強整合性の要件を満たさないので却下」と決めた。
今週、別セッションのエージェントが、その却下理由を知らずに同じ選択肢を再提案する。
CLAUDE.md には「Postgresを使う」と書いてある。だからエージェントは却下された選択肢を知らない。
書いてあるのは結論だけで、却下の理由と、却下されたという事実が落ちている。
ADR には書いてある。しかしADRはファイルであって、エージェントが行動する直前に読まれる保証がない。

ここで重要なのは、「ずれ」には2種類あって、扱いが正反対だということです。

supersession（意図的な上書き）: 決定を変えた。これは正常。むしろ記録されるべき更新。
drift（事故）: 誰も変えると決めていないのに、実態が決定から離れた。これは検出されるべき異常。

この2つを区別せずに「差分が出ました」と言うツールは、実務ではノイズになります。
毎回「それは意図的に変えました」と言い続けることになるからです。

だとすると要件は3つ

決定に同一性を持たせる（後から「あの決定」と参照できる。本文の全文一致ではなく識別子で）
supersession と drift を区別する（人間が「これは意図的な変更」と宣言できる経路を必ず持つ）
エージェントが行動する前に再注入する（保存されていても、行動の直前に出てこなければ意味がない）

3番目が一番見落とされます。記憶の問題は多くの場合保存ではなく想起のタイミングの問題です。
「セッション開始時に読み込む」だけでは足りず、編集や決定の直前に出てこないと事故は止まりません。

自分の実装

私が書いている linksee-memory はここを狙ったMCPサーバーです。
ローカルのSQLite 1ファイルに置いて、Claude Code / Cursor / Codex / Gemini CLI が同じファイルを読みます。

npx -y linksee-memory setup

決定を固定する:

linksee this: MongoDBは強整合性要件を満たさないため却下。Postgresを採用。

ずれているものを聞く:

what's drifting?

固定した決定に反する動きが出たとき、エージェントが動く前にその決定を差し戻します。
実装はMIT・GitHub にあります。

この記事では比較表を作りません。 上の表に並んだツールを、同じ手順で実際に入れて動かした結果は
「使い心地の5場面」として別記事にまとめます（公開後にここにリンクします）。
測っていない範囲を表にすると、それは比較ではなく広告になるので。

おまけ: この測定は誰でも自分の製品でできます

一番再利用できるのはここだと思うので、手順を置いておきます。特別なものは要りません。

質問はJSONで持ちます。

{
  "target": "自分のプロダクト",
  "questions": [
    { "id": "a01", "lang": "ja",
      "question": "Claude Codeがセッションをまたぐと過去の経緯を忘れてしまいます。記憶を持たせる方法を教えてください。" },
    { "id": "a02", "lang": "en",
      "question": "What is the best MCP server for persistent memory across AI coding agents?" }
  ]
}

やることは3つだけです。

各エンジンのAPIに、システムプロンプトなしで質問文をそのまま投げる
（プロンプトで誘導すると、測っているのは自分のプロンプトになります）
回答テキストから固有名を数える。自社名だけでなく競合の出現数も数えるのが本体です。
自社が0でも「誰が枠を取っているか」が分かれば次の一手が決まります
Web検索するエンジン（Perplexityなど）は引用元URLも保存する。
どのドメインが答えを組み立てているかが、そのまま「どこに居ればいいか」の答えになります

3番目で私は一度失敗しています。引用元を保存しないバージョンのスクリプトで走らせてしまい、
最も重要なデータを丸ごと捨てていました（しかもエラーは出ません。静かに空になるだけです）。
answers[engine] に citations が入っているかを、判定に使う前に必ず確認してください。

数える対象を「自社が出たか」だけにしないこと。枠を誰が取っているかのほうが情報量が多いです。
今回で言えば、「1位が製品ですらなかった」という事実が一番の収穫でした。

追記（2026-09-08） コメントで測定設計に3点の指摘をいただきました。(1) 各（質問, エンジン）の試行が1回なので、表の下位（Letta / Zep / MemGPT）は順位として読める精度がない。(2) 質問の言語（ja / en）を混ぜて集計している。(3) 引用元ドメインの結果が未掲載。いずれもその通りで、手元で言語別に割り直すと Letta / Zep / MemGPT は英語の質問でしか出ておらず、下位の順位は言語の違いでした。9/14に同じ質問セットを3回繰り返す再測定を行い、回数でなく幅（最小〜最大）・言語別・引用元ドメイン別の表をこの記事に追記します。上の表は、それまで「上位は確か、下位は未確定」として読んでください。

測定日 2026-09-04 / n=39回答（13問×3エンジン） / 実測: KanseiLINK
執筆にAIの支援を使っています。測定・集計・結論はすべて自分で実行・確認したものです。

同じ測定を自分の製品でやってみた方は、結果を教えてください。「1位が製品ですらなかった」が他のカテゴリでも起きるのか知りたいです。役に立ったら LGTM を。