論文が実際に行ったこと
先行研究が無視していた2つの軸
今回の設定は、新しい手法の提案ではなく再評価です。著者らは、既存の2つのメモリベースの手法（「オンラインのタスクストリームから学習し、テキスト形式のメモリバンクを維持することで時間の経過とともに改善する」エージェント）を取り上げ、彼らが次のように説明する2つの軸で評価を広げました。「(1) 分散を定量化するために複数回の実行を含めること、および (2) タスクの順序の影響を調査するためにタスクをランダムにシャッフルすること」
これらはいずれも、実証的な機械学習の大部分において標準的な慣行ですが、これまでは欠落していました。これが今回の方法論的な貢献のすべてであり、それだけで結果を覆すには十分でした。
発見1：メモリを追加する前から測定にノイズが多かった
彼らの最初の観察結果をそのまま引用します。「エージェントの評価は、複雑な環境や複数ステップのタスクにおいて本質的にノイズが多く、その上に自己改善ループを重ねることで、このノイズがさらに増幅される可能性がある」
これは2つの部分から構成されているため、2回読み返してください。複数ステップのタスクにおけるエージェントのベンチマークは、それ自体がノイズを含んでいます。同じエージェント、同じタスクでも、実行が異なればスコアも異なります。そして、自己改善ループはそのノイズの多いシグナルを取り込み、メモリバンクにフィードバックし、それが次の実行を方向付けます。ノイズは単に持続するだけでなく、複利的に蓄積していくのです。
独自の評価を行っているすべての人に対する実用的な教訓：メモリのオンとオフを1回だけ実行して比較しても、得られる情報はほとんどありません。もしあなたが、数値が一度上がったからという理由でメモリの変更を本番環境にデプロイしたことがあるなら、この論文はそれが証拠にならなかった理由を説明してくれています。
発見2：タスクの順序が成果の大部分を担っていた
2つ目の観察結果は衝撃的です。「エージェントの改善はタスクの順序に大きく依存している。先行研究は、暗黙のカリキュラムを課すデフォルトの順序を採用していることが多く、それが成功のための隠れた前提条件として機能している」
暗黙のカリキュラムとは、デフォルトのタスクシーケンスが、たまたま「易しいものから難しいものへ」となっていたり、有用な教訓を教えてくれるタスクが、それを必要とするタスクの前に配置されていたりしたことを意味します。エージェントはその順序で学習し、改善しました。順序をシャッフルすると改善幅は縮小します。メモリバンクは、誰も意図的に設計せず、報告もしていなかった「教育シーケンス」の恩恵を受けていたのです。
これは、新しい装いをしたおなじみの失敗モードです。不正でも怠慢でもありません。分野が未成熟であるために、誰もコントロールしようと考えなかった「制御されていない変数」なのです。
彼らが検証し、部分的にのみ確認された仮説
著者らは否定的な結果だけで立ち止まりませんでした。彼らはメモリバンクを手作業で検査し、ある仮説を立てました。「タスクと環境の仕様不足（underspecification）が、この脆弱性に寄与している」。言い換えれば、タスクや環境が「何が正しい状態なのか」をエージェントに十分に明確に伝えていないため、エージェントが曖昧または誤った教訓を書き込んでしまうということです。
そこで彼らは、「詳細なルーブリックや環境からのフィードバックなど、より適切な仕様定義を可能にする情報をメモリ構築プロセスに組み込む」ことで、この仮説を検証しました。
その結果、アブストラクトの中で最も誠実な一文が生まれました。「この追加情報は、以前の実験におけるパフォーマンスの低下を部分的に解消するものの、依然として大きなギャップが残っており、他の未解明の要因がこの脆弱性に寄与していることを示唆している」
「部分的に」。 「大きなギャップが残っている」。 「他の未解明の要因」。これは、研究チームが自らの解決策を過大評価することを拒んでいる証拠であり、この論文が信頼に値する理由でもあります。
この論文が示していること、示していないこと
この境界線を正しく理解することは、見出しよりも重要です。
カテゴリ全体ではなく、2つの手法を研究したものである。 この再評価は、2つのメモリベースの自己改善手法を対象としています。サーベイ論文ではなく、エージェントメモリに対するすべてのアプローチが脆弱であると主張しているわけではありません。
人間が介在せずにエージェントが自らメモリを書き込むケースを対象としている。 具体的な研究対象は、人間の介在なしに、オンラインのタスクストリームからテキスト形式のメモリバンクを維持するエージェントです。これは、人間がプロジェクトの制約を書き留めたり、チームがファイル内で規約を維持したりすることとは異なります。文書化されたコンテキストが役に立たなくなると言っているわけではありません。
これは信頼性に対する批判であり、否定ではない。 発見されたのは、報告されている成果向上が順序に依存しており、ノイズが多いということであり、メモリに効果がないということではありません。効果がタスクの順序に依存する手法であっても、特定の順序においては依然として効果があります。
製品名は挙げられていない。 これらはベンチマークにおける研究手法です。これを特定のベンダーのメモリ機能に対する判決として読み取るのは、論文が意図していない飛躍であり、誰もそのような解釈をすべきではありません。
そして、逆の方向性を示す結果とも共存している。 この4日前に発表された研究では、自己蒸留されたガイドラインを注入することによる実際の成果向上が測定されており、その効果の大きさはモデルに依存することが示されています。これについては「AIエージェントにどの程度のメモリを与えるべきか」で取り上げています。両方とも真実であり得ます。つまり、成果向上は存在するものの、報告されているその効果の大きさは、既存の文献が示唆するほど安定していないということです。この矛盾を解消するのは、より優れた評価方法であり、それこそがこの論文が求めている「複数回の実行にわたる結果の報告と、困難な条件下でのストレステスト」です。
人々が誤解しがちなポイント
「エージェントのメモリは機能しない」 論文はそうは言っていませんし、著者らもそう言わないように細心の注意を払っています。2つの手法、1つの評価プロトコル、順序依存の成果向上、というのが事実です。
「だからメモリはスキップして、より大きなコンテキストウィンドウを使うべきだ」 これは別の問題であり、独自の答えがあります。この論文によって影響を受けるものではありません。この領域については「なぜ長いコンテキストはメモリではないのか」で解説しています。
「解決策はルーブリックだ」 ルーブリックと環境からのフィードバックは役に立ちましたが、ギャップを完全に埋めることはできませんでした。それらを万能の解決策として扱うことは、「大きなギャップが残っている」という一文を無視することになります。
「ベンチマークは役に立たない」 逆です。この論文は、適切に実行（複数回の実行、順序のシャッフル）すれば、ベンチマークが極めて有益であることを証明しています。
「エージェントにメモリを自己管理させれば、勝手に解決する」 これこそが、この論文が最も直接的に覆している信念です。監視のない自己改善ループは、評価のノイズをメモリバンクに増幅させてしまいます。
「社内のA/Bテストで向上が見られたから大丈夫」 もしそのA/Bテストが、固定されたタスク順序での単一の実行であったなら、この論文はまさに「それがまだ証拠とは言えない理由」を説明しています。
解決策：メモリを検査可能にし、真剣に測定する
論文は2つの推奨事項で締めくくられており、これらはすぐに実践可能な部分です。1つ目は評価についてです。複数回の実行にわたって報告し、困難な条件下でストレステストを行うことです。2つ目は、開発者にとってより興味深いものです。「仕様不足に関する我々の発見は、効果的な人間の監視を可能にし、エージェントが予期せぬ方法で失敗するのを防ぐシステムとインターフェースを求めている」
人間の監視。インターフェース。メモリ構築に組み込まれた仕様定義。これらを総合すると、推奨事項は「エージェントに与えるメモリを減らす」ことではなく、「エージェントが監視なしに書き込むブラックボックスとしてメモリを放置するのをやめる」ということです。
実用的なセットアップのために、以下の3つのことが導かれます。
ばらつきとシャッフルした順序で評価する。 最低3回は実行し、タスクのシーケンスを入れ替えてください。シャッフルしたことで成果向上が消えた場合、タスクの順序自体がカリキュラムになっていたことが分かります。
蓄積する前に仕様を定義する。 論文における部分的な解決策は、メモリ構築にフィードバックされる、より優れたタスクと環境の仕様定義でした。実際には、これは「正しく完了した状態」がどのようなものかを文章で書き留めることを意味し、エージェントが抽出した教訓が「何に対して正しいか」を判断できるようにします。
メモリを人間が読み取り、編集できるようにしておく。 何が書き込まれたかを確認できなければ、次の50回の実行に影響を与える曖昧な、あるいは誤ったエントリーをキャッチすることはできません。
この最後のポイントこそが、MemoryLakeが構築された目的です。肥大化する一方の不透明なストレージではなく、人間が読み取り、修正し、削除できる個々のエントリーとしてのメモリです。セットアップは3つのステップで行えます。
ステップ 1: APIキーを作成する
MemoryLakeにサインインし、APIキーを作成します。接続するツール間で共通の認証情報が1つ発行されます。
ステップ 2: 最初のメモリをアップロードする
論文でエージェントに欠けていると指摘された仕様を、それぞれ1つの主張を含む短いエントリーとして書き込みます。
繰り返し発生するタスクにおける「正しい」の定義。 ルーブリックを文章で記述します。これは、論文が効果的であると認めた唯一のカテゴリです。
環境がアナウンスしない制約。 レート制限、順序の要件、最近の行がないステージングデータベースなど。エージェントが推測できない環境からのフィードバックです。
すでに除外されたアプローチとその理由。 シャッフルされたタスク順序の下では、エージェントが頼れるカリキュラムはありません。文書化された却下理由が、幸運なシーケンスの代わりとなります。
これまでに複数回行った修正。 人間が2回言わなければならなかったことは、監視なしのループが自ら導き出せるはずがありません。
ステップ 3: AIとエージェントを接続する
使用しているツールを接続します。MemoryLakeはMCPおよびAPI経由でアクセスできるため、Claude Code、Codex、OpenClawなどのMCPネイティブなエージェントはMCPサーバーを指定することで接続でき、他のアシスタントはAPIを介して同じメモリを読み取ることができます。
ここで、3つの率直な限界について説明します。最初の1つがこの記事の要点です。MemoryLakeはこの研究に参加しておらず、ここで説明されている脆弱性を解決するものではありません。 厳選されたメモリレイヤーが自己改善型エージェントを信頼できるものにする、という主張は一切ありません。著者らが述べているように、他の要因は未解明のままであり、それはどのようなストレージにも当てはまります。検査可能なレイヤーが提供するのは、彼らが求めている「人間の監視」であり、回帰テストでバグを発見する代わりに、不正なエントリーを修正する能力です。これは、あなたやあなたのエージェントが書き込んだものだけを保持します。また、これは評価ハーネス（評価環境）ではないため、複数回実行する規律はあなた自身で実装する必要があります。
実務において何が変わるのか
単一実行の比較は、結果としてカウントされなくなります。 最も低コストで導入でき、最もリターンの大きい変更です。3回の実行とシャッフルを行いましょう。
「エージェントがそれを学習した」は、検証すべき主張になります。 メモリを開き、エントリーを読み、抽出された教訓が本当に正しいかどうかを確認してください。
ルーブリックの作成がエンジニアリング業務になります。 仕様不足が脆弱性の原因として挙げられています。何が正しい状態であるかを定義することは、もはや単なるドキュメント作成の雑務ではありません。
順序への非依存性が設計目標になります。 エージェントが特定のタスクシーケンスでしか改善しない場合、それはメモリシステムではなく、カリキュラムを持っているに過ぎません。
蓄積することよりも、剪定（削除）することの方が重要になります。 ノイズの下で書き込まれた誤ったエントリーは、正しいエントリーと一緒に注入されてしまいます。これは「なぜRAGはメモリではないのか」の背景にある一般的な問題です。
エージェントメモリを評価するためのベストプラクティス
少なくとも3回は実行する。 実行間のばらつきは、元の研究が省略していた2つの軸の1つでした。
意図的にタスクの順序をシャッフルする。 改善が順序に依存しているかどうかは、本番環境にデプロイする前に知っておべきです。
最高の数値ではなく、ばらつき（スプレッド）を報告する。 論文の要求を一行で表したものです。
メモリの前にルーブリックを書く。 メモリ構築における仕様定義の改善は、測定可能な効果をもたらした介入策でした。
エージェントが書いたものを読む。 手作業による検査こそが、著者らが仕様不足の仮説を発見した方法です。
エントリーに日付を入れ、古いものは削除する。 ノイズがある状況下では、古い誤ったエントリーは、空のストレージよりも悪影響を及ぼします。
2つの手法からカテゴリ全体の結果を主張しない。 「メモリは機能する」とも「メモリは機能しない」とも言えません。
設計段階から人間をループに組み込んでおく。 論文自体の締めくくりの推奨事項は、効果的な人間の監視を可能にするシステムとインターフェースです。その具体的な形については「AIメモリとは何か、何ではないのか」で議論されています。
結論
エージェントのメモリはパフォーマンスを向上させるのでしょうか？この論文の証拠に基づけば、答えは「時々向上させるが、報告されているほどではなく、著名な2つの手法で測定された差異の多くは、誰も制御していなかったタスクの順序に起因していた」となります。著者らはその意味について慎重です。エージェントの評価は自己改善ループを追加する前からノイズが多く、ループはそのノイズを増幅させ、仕様定義を改善することは役立つものの大きなギャップを残し、他の要因は未解明のままです。
実務者にとってこれがもたらす変化は、アーキテクチャの変更というよりも、主に規律の面です。比較は複数回実行してください。順序をシャッフルしてください。エージェントが推測することを期待するのではなく、正しい状態がどのようなものかを書き留めてください。そして、メモリは人間が実際に読める場所に保管してください。なぜなら、論文自体の結論は、よりスマートな無人ループを求めるものではなく、人間の監視を求めているからです。検査し修正できるメモリは、自己改善するメモリよりも控えめな主張ですが、この証拠に照らし合わせると、それこそが持ちこたえる主張なのです。