Skip to content
←

필사 모드: AIエージェントのメモリは実際にどう作られているのか — 4つの設計と、ベンチマークが実際に証明したこと

日本語
0%
정확도 0%
💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

はじめに — 「メモリ」は一つではない

「AIエージェントにメモリを付けた」という文は、ほとんど何の情報も与えてくれません。その言葉が指しうる設計が少なくとも4つあり、それぞれコストも失敗の仕方も違うからです。ファイルにメモを書き留めておくこと、会話が長くなったら要約して前半を捨てること、事実を抽出して埋め込んでおき質問のたびに取り出すこと、エンティティと関係をグラフとして積み上げること — この4つはすべて「メモリ」と呼ばれますが、同じものではありません。2026年1月に出たサーベイ(arXiv:2602.06052)が「メモリは今年だけで数百本の論文が出た」と書くほど、この言葉は過積載になっています。

そこで本稿がまず答える質問はこれです — 各設計が実際に何をし、どちらが優れているという根拠は実際に測定されたことがあるのか。結論から言うとこうです。各設計が何をするのかは、製品ドキュメントに明確に書かれています。一方、「どちらがより正確か」についての公開された根拠は、思ったよりずっと弱いのです。最も多く引用される比較論文の表を直接読むと、その表で1位だったのはどのメモリシステムでもなく、「会話全体をそのままプロンプトに全部貼る」方式でした。そしてそのベンチマークを直接開いてトークンを数えてみると、なぜそうなるのかも説明がつきます。本稿はその過程を一つずつ確認します。

本稿はコンテキストエンジニアリングの回で扱った設計パターンを繰り返しません。ここでやろうとしているのは根拠の監査(audit)です — どの数字が、誰によって、どんな条件で、何と比較して測定されたのか。

4つの設計はそれぞれ何をするのか

まず用語を固定しましょう。以下の4つは排他的ではなく、実際の製品はたいてい混ぜて使います。

1. スクラッチパッド / ファイルメモリ。エージェントがファイルにメモを書き、後で読みます。Anthropicのmemory toolがまさにこの形です — 公式ドキュメントによれば、/memoriesディレクトリの下にファイルを作り、読み、直し、消します。重要なのは、これが完全にクライアントサイドだという点です。ドキュメントの表現では、Claudeはファイル操作を要求するだけで、実行はあなたのアプリケーションがあなたのストレージに対して行います。ドキュメントはこのパターンをjust-in-timeのコンテキスト回収と呼びます — あらかじめ全部積み込むのではなく、学んだことを書き留めておき、必要なときに読む、ということです。

2. 要約 / コンパクション。会話が長くなったら、前半を要約に差し替えます。Anthropicのサーバーサイドcompactionがこれです。ドキュメントによれば、入力トークンが設定した閾値に達するとAPIが会話を要約してcompactionブロックを作り、以後のリクエストではそのブロックより前のすべてのコンテンツブロックを自動的に捨てます。ベータヘッダーはcompact-2026-01-12、戦略名はcompact_20260112です。ドキュメントが明かす理由が興味深いところです — 単に上限を超えないためではなく、「会話が長くなると応答品質が落ちるため」アクティブなコンテキストを小さく保つ、というのです。

3. ベクトル回収。会話から事実を抽出して埋め込んでおき、質問のたびに類似したものを取り出します。Mem0の基本構成がこの系統です。プロダクションRAGパターンの検索パイプラインと技術的には同じものであり、違うのは対象が文書ではなく会話だという点です。

4. 知識グラフ。エンティティと関係をグラフとして積み上げます。ZepのGraphitiが代表的で、時間情報をエッジに付けて「いつからいつまで真だったか」を扱います。グラフをどう抽出し、何をエンティティとみなすかはそれ自体が大きなテーマで、知識グラフを実際に構築するとドメイン知識をオントロジーとしてモデリングするの回で別途扱いました。コーパスへの問い合わせ側の話はGraph RAGの回にあります。

研究側の系譜を一つ挙げておくと、この分野の出発点としてよく引用されるMemGPT(arXiv:2310.08560、2023年10月)は、オペレーティングシステムの階層メモリからアイデアを借りて「仮想コンテキスト管理」を提案しました。速いメモリと遅いメモリの間でデータを移し、大きなメモリがあるかのように見せるという発想です。いまの製品のファイルメモリとコンパクションは、この系譜の上にあります。

出荷された製品と研究論文はどこで分かれるのか

ここで最初の重要な区別が出てきます。

出荷された製品が実際に推しているのは1番と2番です。これは意外かもしれません。Anthropicのドキュメントを見ると、context editingのページはこう案内しています — ほとんどのユースケースではサーバーサイドcompactionが長い会話の主たる戦略であり、context editingの細かい戦略群は、何を消すかをより細かく制御する必要がある特定の状況向けだ、と。compactionのドキュメントも同じことを言っています: 長時間実行の会話とエージェントワークフローで推奨される戦略だ、と。

つまり、商用プラットフォームがデフォルトとして勧める「メモリ」はベクトルでもグラフでもなく、要約して捨てる + ファイルに書き留めるです。最も単純な2つです。

研究とスタートアップが競っているのは3番と4番です。Mem0、Zep、LangMem、A-Memのようなシステムがここにあり、論争もすべてここで起きています。では、こちらの方が優れているという根拠はどれほど固いのでしょうか。

どの設計がより正確か — 最も引用される表を直接読む

この質問について最も広く引用される根拠はMem0論文です(Chhikaraら、arXiv:2504.19413、2025年4月28日投稿、ECAI 2025)。アブストラクトのヘッドラインはこうです — LLM-as-a-Judge指標でOpenAI比26%の相対改善、グラフメモリを使うと基本構成より約2%高いスコア、そしてフルコンテキスト比91%低いp95レイテンシと90%以上のトークンコスト削減。

ところが、論文本文のTable 2をそのまま移すとこうなります。すべて著者による自己測定であり、LoCoMoベンチマーク基準で、JはLLM-as-a-Judgeスコアです。

方式メモリトークン検索p95総p95Jスコア
フルコンテキスト (会話全体をそのまま投入)26,031—17.117s72.90% ± 0.19
Mem0 グラフ—0.476s (p50)2.590s68.44%
Mem0 (基本)1,7640.200s1.440s66.88%
Zep3,9110.778s2.926s65.99% ± 0.16
LangMem12759.82s60.40s58.10% ± 0.21
OpenAI4,437—0.889s52.90% ± 0.14
A-Mem2,5201.485s4.374s48.38% ± 0.15

ヘッドラインの数字は算術的には正しいです。直接検算してみました — 66.88を52.90で割ると1.264なので、OpenAI比26%の相対改善は合っています。1から(1.440を17.117で割った値)を引くと91.6%なので、フルコンテキスト比91%低いp95も合っています。68.44から66.88を引くと1.56%pなので、「約2%高い」も合っています。何も捏造されていません。

問題は同じ表の一番上の行です。フルコンテキストが72.90%で1位です。会話全体をそのままプロンプトに貼る、メモリシステムと呼ぶことすらできない方式が、すべてのメモリシステムに勝ちました。論文もこれを隠していません — 本文には、約26,000トークンを丸ごと入れるフルコンテキストが依然として最も高いJスコア(約73%)を出すと書かれており、Mem0グラフは「計算的に扱いにくいフルコンテキストにのみ劣る」と明記しています。

したがって、正確に言うとこうです。26%というヘッドラインは、OpenAIの52.90%を基準に測ったものです。表の中で最も弱い比較対象です。表の中で最も強いベースラインにはどのメモリシステムも勝てず、アブストラクトはその事実に言及していません。嘘はありませんが、フレーミングは選別的です。論文が売っている本当の価値は正確さではなくコストです — 1,764トークンで、26,031トークン方式の92%水準の正確さを出すということ。それは実際に有用な結果であり、正直に言えば、それが結論であるべきです。

表をもう少し眺めると、別のことにも目が留まります。LangMemはメモリが127トークンで、検索p95が59.82秒です。60秒かかる検索は、どのプロダクションでも正常な設定ではありません。他人のシステムを最適な設定で動かすことがどれほど難しいかを示すシグナルであり、このシグナルがそのまま次の話につながります。

なぜフルコンテキストが勝ったのか — ベンチマークを直接開いてみた

フルコンテキストが勝った理由を知るには、LoCoMoが何かを見る必要があります。

LoCoMoはもともと会話メモリのベンチマークです(Maharanaら、arXiv:2402.17753、2024年2月27日)。論文のTable 1が記述するデータセットはこうです — 50会話、会話あたり平均304.9ターン、平均19.3セッション、平均9,209.2トークン。質問は5つのカテゴリに分かれます: single-hop、multi-hop、temporal、commonsense/world knowledge、そしてadversarial。

ところがMem0論文は、フルコンテキストに26,031トークンを入れたと書いています。9,209と26,031は3倍近く違います。どちらが正しいのかを確かめるために、公開データセットを直接ダウンロードして数えてみました。

公開リポジトリ(snap-research/locomo)に実際に入っているファイルはlocomo10.jsonです。名前のとおり10会話です — 論文が記述した50会話ではありません。tiktokenのcl100k_baseで会話本文(発話テキストと画像キャプション)だけを数えた結果はこうです。

locomo10.json  (直接測定、tiktoken cl100k_base、発話テキスト + BLIPキャプション)
  会話数:              10           (論文Table 1は50会話を記述)
  会話あたりトークン:  最小 12,218 / 最大 23,406 / 平均 20,034 / 中央値 21,387
                               (論文Table 1は平均9,209.2)
  会話あたりセッション: 平均 27.2 (最小19、最大32)   (論文は平均19.3)
  会話あたりターン:    平均 588.2                     (論文は平均304.9)

  質問総数:            1,986
    カテゴリ1 single-hop      282
    カテゴリ2 multi-hop       321
    カテゴリ3 temporal         96
    カテゴリ4 open-domain     841
    カテゴリ5 adversarial     446   <- 446問中444問に`answer`フィールドがない
                                   (`adversarial_answer`フィールドのみ存在)

つまり、皆がベンチマークしている公開ファイルは、論文が記述したデータセットのおよそ2倍の長さです。私の測定値20,034トークンは、Zepが主張した「16,000~26,000トークン」の範囲と一致し、Mem0の26,031トークンとも方向が合います(Mem0側はタイムスタンプや観察フィールドなどのスキャフォールディングをより多く含めた可能性が高いです)。論文アブストラクトの「平均9Kトークン」とは合いません。

これがフルコンテキストが勝った理由です。会話一つが2万トークンなら、最近のモデルのコンテキストウィンドウに何の負担もなく収まります。長期メモリに圧力をかける試験ではなく、ただ全部入れればいい試験なのです。Zepが自社ブログで指摘した文が的確です — 全部入れる方が専門のメモリシステムより良い結果を出すなら、そのベンチマークは実際のエージェントが受けるメモリ圧力を測っていない、ということです。

カテゴリ5も注目に値します。446問中444問にはanswerフィールドがそもそもありません(代わりにadversarial_answerが入っています)。そのため、Mem0とZepはどちらもこのカテゴリを評価から除外しました。全質問の22.5%が事実上使えない状態だという意味であり、この除外が、次の章で起きる事故の原因になります。

ベンダー同士で数字が合わないとどうなるか — Mem0対Zepの記録

この分野で「測定されたこと」と「主張されたこと」の隔たりを最もよく示す出来事が、2025年5月に公開の形で残っています。時系列で整理するとこうです。

2025年4月28日。Mem0論文が公開されます。Zepを65.99%と報告し、SOTAを主張します。

2025年5月6日。Zepがブログで反論します(Daniel Chalef、Preston Rasmussen)。要旨は、Mem0がZepを誤って実装したまま測定した、というものです。具体的に3点を挙げます — 会話参加者の両方にuserロールを与え、単一ユーザーのアイデンティティがメッセージごとに入れ替わるかのようにしたこと、タイムスタンプをZepのcreated_atフィールドではなくメッセージ本文に付け足したこと、検索を並列ではなく逐次で回してレイテンシを膨らませたこと。そのうえで、正しく実装すればZepは84%だと主張します。

2025年5月9日。Mem0のCTOであるDeshrajがZepのリポジトリにイシューを開きます(getzep/zep-papersのイシュー5番)。反論の核心は算術です — Zepの84%は、皆が除外することにしたカテゴリ5の正答を分子には入れ、分母からは除いた計算だ、というのです。これを正すと84%ではなく58.44%だというのです。約25.56%pが水増しされたという主張です。

2025年5月12日。ZepのChalefが計算ミスを認めます。ただし訂正された値は58.44%ではなく75.14% ± 0.17(10回実行の平均)でした。そして残りの批判 — Mem0の実験設定とLoCoMoの選択自体が間違っているという主張 — は撤回しませんでした。Zepはブログにも訂正告知を付け、いまもその文言が残っています。

2025年5月19日。イシューは「非アクティブのため」クローズされます。

ここで重要なのは、両陣営の数字が最後まで一致したことがないという事実です。Mem0はZepが58.44%だと言い、Zepは訂正後も75.14%だと言います。同じベンチマーク、同じシステムで、17%pの差。どちらが正しいのか、本稿は判定しません — 判定する根拠が公開されていないからです。

算術が筋の通るものかどうかは確認できます。私が数えたとおり、カテゴリ1~4が1,540問、カテゴリ5が446問です。カテゴリ5の正答を分子に入れ、分母を1,540のままにすると、25.56%pを水増しするにはカテゴリ5で約394問(446問の88%)が正答扱いになる必要があります。Mem0が主張したメカニズムと規模は互いに矛盾しません。ただしこれは主張の内的整合性の確認であって、どちらのスコアが正しいかの証明ではありません。

この出来事から実務者が持ち帰るべき教訓は、「誰が悪者か」ではありません。競合製品を最適な設定で動かして測定することは善意でも非常に難しく、だからベンダーが他社製品について報告した数字は基本的に弱い証拠だということです。先に見たLangMemの60秒検索も同じカテゴリのシグナルです。Zepの65.99%も、Zepが自らの手で測った75.14%も、それぞれ自らの利害関係が付いています。

より難しいベンチマークではどうか — LongMemEval

LoCoMoが簡単すぎるなら、より難しいものがあります。LongMemEval(Wuら、arXiv:2410.10813、2024年10月にv1、2025年3月にv2、ICLR 2025)です。

設計は明らかにより攻撃的です。500問で、標準設定が2つあります — LongMemEval_Sは1問あたり約115kトークン、LongMemEval_Mは500セッションで約150万トークン。LoCoMoの2万トークンとは桁が違います。そしてLoCoMoになかった能力を明示的に試験します: 情報抽出、マルチセッション推論、時間推論、知識更新(事実が変わる状況)、そして棄権(知らないなら知らないと言うこと)。

論文が報告する結果はこうです。アブストラクトは「商用チャットアシスタントとロングコンテキストLLMが30%の正確度低下を示す」と書きますが、本文はより正確に30%~60%の性能低下と書いています。そして商用システムについての文には、必ず保存すべき但し書きが付いています — 手作業の評価で最新の商用システムが30%~70%の正確度にとどまったものの、それはLongMemEval_Sよりはるかに単純な設定での話だった、ということです。つまり、実際の難易度での商用システムのスコアではありません。

Zepは自らの論文(arXiv:2501.13956、2025年1月)でLongMemEvalを好むと明かし、最大18.5%の正確度改善と90%のレイテンシ削減を報告します。「最大(up to)」という限定語が付いており、著者による自己測定です。同じ論文はDMRベンチマークでMemGPT比94.8%対93.4%を報告しますが、1.4%pの差を根拠にSOTAを語るのは、それ自体として薄弱です。

ここで正直に言わなければならないことがあります。LongMemEvalの上でMem0、Zep、ファイルメモリ、コンパクションを同一条件で並べて回した独立した第三者比較は、私が確認した範囲では公開されていません。各ベンダーが自分のパイプラインで自分のプロンプトを使って測った数字があるだけです。共通のベンチマークがなければ、ベンダーAの自己測定とベンダーBの自己測定を並べて比較することはできません — 本稿がそのような表を作らない理由です。

Anthropicの39%は何を測った数字なのか

商用側の数字も同じ物差しで見てこそ公平です。

Anthropicが2025年9月29日にcontext editingとmemory toolを発表した際に公開した数値はこうです — memory toolとcontext editingを併用するとベースライン比で39%の性能向上、context editing単独では29%の向上。そして100ターンのウェブ検索評価では、context editingがなければコンテキスト枯渇で失敗していたはずのワークフローを完走させつつ、トークン消費を84%削減したとのことです。

この数字に付いている条件をそのまま移すとこうです。第一に、エージェンティック検索に関する内部評価セット(internal evaluation set)が基準です。ベンダーによる自己測定であり、外部からは再現できません。第二に、ベースラインの絶対スコアが公開されていません。39%の向上が40点から55.6点なのか、70点から97点なのかが分かりません。第三に、3つの数字はそれぞれ別のものを測っています — 39%と29%は正確度の系列、84%はトークン消費です。

そしてもう一つ、時間の経過とともに生じたずれがあります。あの39%は、2025年9月にcontext editing + memory toolの組み合わせを測った数字です。ところが、いまAnthropicのドキュメントが長時間実行の会話の主たる戦略として勧めているのはサーバーサイドcompactionであり、それはベータヘッダーがcompact-2026-01-12である後発の機能です。つまり、広く引用される39%は、現在の推奨デフォルトを測った数字ではありません。これはAnthropicが何かを間違えたという意味ではなく、製品が動く速度より数字がゆっくり老いる、という意味です。ベンダーの数値を引用するときは、その数値がどの時点のどの構成を測ったものかを併記すべきです。

測定されていないもの — 失敗の仕方

正確度の表には出てこない失敗があります。こちらはおおむね、ベンチマークではなくドキュメントの警告文の形でのみ存在します。

メモリ汚染とプロンプトインジェクション。エージェントが読んだ内容をメモリに書き、そのメモリを後で信頼して読むなら、汚染された入力一つがセッションを越えて持続します。Anthropicのドキュメントはmemory toolについてパストラバーサル攻撃を明示的に警告しています — /memories/../../secrets.envのようなパスがメモリディレクトリ外のファイルに届きうるため、すべてのコマンドのすべてのパスを検証せよ、というものです。実行主体はあなたのアプリケーションなので、防御もあなたの仕事です。

機微情報の記録。同じドキュメントの表現をそのまま移すと、Claudeは機微情報をメモリファイルに書くことをたいてい(usually)拒否します。より強い保証が欲しければ、ハンドラーがファイルを書く前に機微データをふるい落とす検証を自分で付けるように、と案内しています。「たいてい」という限定語を「しない」に格上げして読んではいけません。

知識更新。ユーザーが転職すれば、以前の職場の情報は間違いになります。LoCoMoにはこれを試験する質問がそもそもありません(Zepの指摘であり、私がカテゴリ分布を確認した結果とも一致します)。LongMemEvalは知識更新を5つの能力の一つとして明示しています — だからより良い試験です。

無限成長と失効。Anthropicのドキュメントは、ファイルサイズに上限を設け、長く参照されていないメモリファイルを定期的に消すよう勧めています。つまり「何を忘れるか」についてのポリシーが必要だという意味ですが、この部分を自動でうまく解く公開された根拠はありません。

これらの失敗について公開された定量比較は事実上ありません。だからメモリシステムを選ぶとき、正確度の表だけを見るのは、間違った軸を見ていることになりかねません。

それで何を使うべきか — 決定ルール

根拠の状態を踏まえた決定ルールはこうです。「状況次第だ」で終わらせはしません。

1. 会話や作業がコンテキストウィンドウに収まるなら、メモリシステムを付けないでください。そのまま全部入れてください。Mem0論文自身の表がこの結論を支持しています — 2万トークンのLoCoMoで、フルコンテキストが72.90%ですべてのメモリシステムに勝ちました。これはベンチマークの弱点ですが、同時に、あなたの状況がそのベンチマークに似ているなら、そのまま適用される結論でもあります。

2. 収まらないなら、まずコンパクションとファイルから。商用プラットフォームがデフォルトとして勧めるのがこの2つだという事実自体がシグナルです。サーバーサイドcompactionはクライアント側の要約コードなしで動き、ファイルメモリはあなたがストレージを制御します。どちらも実装面が小さく、失敗したときにデバッグできます(ファイルは開いてみればいい)。ベクトルやグラフは、ここで失敗を確認してから取り出す道具です。

3. セッションを横断する事実の回収が実際の失敗地点だと確認されたら、ベクトル。ここで売られているのは正確さではなくコストです。Mem0の表を正直に読めば、そのシステムの価値は、1,764トークンで26,031トークン方式の約92%の正確さを出すことにあります。それが必要なトレードオフなら良い選択であり、そうでなければ違います。

4. 時間とともに変わる関係を扱う必要があるなら、グラフ。「いつからいつまで真だったか」「この人がいま所属しているチームは」のような質問です。ただしGraph RAGの回で整理した索引コストと更新の負担がそのまま付いてきます。

5. 何を選ぶにせよ、あなたのクエリで評価してください。これは決まり文句ではなく、本稿が確認した事実から直接導かれる結論です。公開ベンチマークの一つは論文と公開ファイルの統計が食い違っており、その上でベンダー同士が17%pを争って合意に至らず、商用の数値は再現不可能な内部評価です。この状態で他人のランキング表を信じてアーキテクチャを選ぶのは、根拠のない選択です。20~50問の自前の評価セットの方が、本稿に出てきたどの数字よりもあなたにとって有用です。

いつ使うべきでないか

正直に書くべき部分です。

  • 会話が短い。ほとんどのチャットボットセッションは数千トークンです。メモリインフラを付ける理由がありません。
  • 間違った記憶が正しい記憶より高くつく。医療・法律・金融のように、誤ったパーソナライゼーションが損害を生むドメインでは、記憶しない方が安全です。先に見たとおり、汚染と更新失敗についての定量的な根拠がありません。
  • 規制対象データを扱っている。メモリは定義上、個人データを持続させます。削除請求権と保持ポリシーを設計していないなら、付けないでください。
  • まだ失敗を確認していない。「後で必要になりそうだから」でメモリを付けるのは、本稿が見てきた根拠が支持しない選択です。

おわりに

まとめるとこうです。「エージェントメモリ」は少なくとも4つの設計をひとまとめにした言葉であり、それぞれが何をするのかは製品ドキュメントに明確に書かれています — ファイルスクラッチパッド、コンパクション、ベクトル回収、知識グラフ。商用プラットフォームがデフォルトで勧めるのは前の2つ、最も単純な2つです。

一方、「どちらがより正確か」の公開された根拠は弱いのです。最も引用される比較の表で1位はメモリシステムではなくフルコンテキストであり(72.90%対68.44%)、そのベンチマークを直接開いてみると会話一つが平均2万トークンで、そもそも長期メモリに圧力をかけられない試験でした。その上でベンダー2社が互いの測定に反論し、一方が計算ミスを認めた後も、2つの数字は最後まで交わりませんでした。より難しいベンチマークは存在しますが、その上での独立した第三者比較は公開されていません。

これはこの分野が偽物だという意味ではありません。コンテキストを管理する問題は実在し、コンパクションとファイルメモリは実際に出荷され動いています。ただし、「メモリを付ければ良くなる」という文には、まだその文を支持する公開された測定が付いていません。だからランキング表ではなく、あなたの失敗から出発してください。何がうまくいかないのかを先に確認し、最も単純なものから付け、あなたのクエリで測ってください。道具ではなく、失敗が先です。

参考資料

현재 단락 (1/101)

「AIエージェントにメモリを付けた」という文は、ほとんど何の情報も与えてくれません。その言葉が指しうる設計が少なくとも4つあり、それぞれコストも失敗の仕方も違うからです。ファイルにメモを書き留めておく...

작성 글자: 0자원문 글자: 13,452자작성 단락: 0/101