# 16Kから128Kへ、エージェント記憶のゲインは+18から+6に縮小：EvoMemBench サブセット再現とトークンコスト解剖 > Canonical: https://vxi.me/ja/posts/evomembench-agent-memory-budget-replication/ > Locale: ja-jp > Published: 2026-11-02 > Updated: 2026-11-02 > Markdown: https://vxi.me/ja/posts/evomembench-agent-memory-budget-replication.md
EvoMemBench ゲイン審査図：左は論文の口径（著者報告）で、Finding 3 は 16K 枠での最良の記憶ゲイン +14.5 ポイントを報告；中央は事前登録プローブで、コンテキスト予算を 16K から 128K に拡大するだけ、token を用途別に分解；右は Gorilla File System、各セル50問での当方の再測定で、BM25 ゲインは +4.0 から 0.0 に蒸発、ACE ゲインは +18.0 から +6.0 に縮小、ACE 記憶モジュールは自らの入力の 36.5% を占め、出力は記憶なしベースラインの約 7.4 倍。複合判定 PARTIAL、単一環境・ゲートウェイ表示エンドポイント・単回実行にのみ適用され、Finding 5 は未測定。
Gorilla File System サブセット上で、記憶ゲインのコンテキスト予算への依存と、記憶モジュール自体のコストを検証する。数値は一手の再測定による；論文が DeepSeek-V3.2 の元口径で得た結果を裁くものではない。
Agent に記憶を持たせるシステムは増える一方で、どれも「使うほど賢くなる」と言う。だが正面から答えられることの少ない問いがある：コンテキストウィンドウもまた大きくなっている。モデルが一度に読み込める量が増えていくなら、あらかじめ保存しておいた記憶はどれほどの値打ちがあるのか？ EvoMemBench はちょうどこの曲線に数字を与えた。15 種類の記憶手法を同一の評価プロトコルに載せ、こう報告している：コンテキスト予算を 16K から 128K に広げると、記憶なしベースラインに対する記憶手法の最良ゲインは +14.5 ポイントから +8.5 ポイントに縮み、しかも 128K 枠では既に記憶なしベースラインを下回る記憶手法が出ている。 私が気になるのは、この曲線がバックボーンを替えても成り立つかどうか——とりわけ最も安い档に替えた場合だ。理由は実務的だ：この種の実験の規模（128K 枠では長いコンテキストを繰り返し再生する）ではフラッグシップ価格では到底回らず、バックボーン選びはまず価格で一巡ふるいにかけられる；そして私が気にするデプロイ場面で量を回すのも、主に安い档だ。だから論文の設定一式を複製するのではなく、縮小版の問いを事前登録した：ゲートウェイで手に入る最も安い GPT の档で、単一の実行環境において、ゲインが予算とともに縮むという方向はまだ残っているか？ 結論を先に置く：**方向は残っていた。** 私の実行では最良ゲインは 16K の +18.0 ポイントから 128K の +6.0 ポイントに縮み、二種類の記憶手法が同じ方向に縮んだ。だが論文で最も鋭い一幕——128K で記憶がベースラインを割り込む——は現れなかった：検索記憶のゲインはゼロに戻っただけで、手続き型記憶はベースラインの上に残った。複合判定は PARTIAL、証拠の境界は文末に記す。 ## まず証拠の格付けを分ける この論文（arXiv:2605.18421、香港科技大学広州などの機関）は 2026 年 5 月に v1 が出て、10 月 30 日に v3 へ更新されたもので、新しい論文ではない。その仕事は、「Agent の記憶は本当に役に立っているのか」という問いに座標系を立てることだ：一方の軸は記憶の作用範囲（一つのタスクの内側／タスクをまたぐ）、もう一方の軸は内容の種類（知識／実行）で、四つの象限を成す；六つのデータセットが Table 2 で計 2,954 件の評価サンプルを持ち、それぞれ四象限に収まる；15 種類の記憶手法は六つのファミリーに分けられ、統一プロトコルのもとで長コンテキストのベースラインと比較される。常に添えておくべき条件が一つある：**論文のすべての記憶手法は同一のバックボーン DeepSeek-V3.2 を共有する**。そのランキングはこのバックボーンの下でのランキングであり、バックボーンを離れてランキングを語る意味はない。 論文の八つの結論のうち、本稿に直接関わるのは三つと半分だ。長コンテキストのベースラインは依然として強く、知識の保持と改訂で首位に立つ（Finding 1）；記憶のボトルネックは検索ではなく改訂にあり、手法たちは情報を蓄えるのは得意だが、証拠が変わったときに古い知識を改めるのは苦手だ（Finding 2）；さらに深い層では、ボトルネックは蓄えた情報を再利用可能な知識に形作ることであって、単に多く蓄えることではない（Finding 6）；手続き型記憶は実行系タスクに最も向いている（Finding 4）；そして難易度の反転：易しい問題では記憶は負のゲイン、難しい問題では記憶だけが得点できる（Finding 5）——この半分は私には測れなかった。理由は文末で述べる。 以上はすべて著者の報告だ。私の再測定が触れるのはそのうち一本だけ：Finding 3 のゲイン—予算曲線、しかも一つの象限の一つの環境においてだけだ。 ## 私の再現設計：最も安いバックボーンで、曲線は一本だけ この実験は事前登録済みで、設定は走らせる前にすべて固定した。以下の通りだ。サブセットは四象限のうち InEp-Exec（同一ターン内の実行タスク）を取り、その中の Gorilla File System という一つの環境だけを走らせる——これは複数ターンのツール呼び出しタスクの集まりで、タスクの成否は公式 runner 内蔵のチェッカーが判定し、追加の審査役は要らない。3 アーム：A0 記憶なしベースライン；A1 は BM25 検索記憶；A2 は手続き型記憶 ACE。コンテキスト予算は 2 段階：16K と 128K。各セル 50 件、計 300 episode、公式プロトコルのパラメータ（関数呼び出しモード、長コンテキストノイズ、記憶のスコープ）は公式スクリプトのまま。 バックボーンには、第三者の OpenAI 互換ゲートウェイ上で gpt-6-luna と表示されるエンドポイントを使い、全程固定して替えない。ここで身元の境界を先に言っておく：**表示はゲートウェイが出したもので、それが実際に提供しているモデルは私の側からは独立に検証できない**。したがって以下の当方の数字はすべて「この表示エンドポイント」に対してのみ成り立ち、論文の DeepSeek 口径の変種口径であって、同じ表ではない。 論文の設定との出入りと版の細部は、走らせる前に実験計画に書き込んだ。先に三件述べておく： - **サンプル数：v3 とリポジトリは一致、環境ごとに 50 件。** この論文の v1 の Table 2 には環境ごとに 200 件とあったが、v3 では 50 件に改められ、公式リポジトリが実際に配布するのも 50 件で、私が走らせたのはこの 50 件だ。これは同時に、環境ごと 50 件が論文自身の評価規模であることを意味する。後述の ±14 ポイントの統計区間は、論文の単一環境の数字も同じように背負っている。 - **手続き型記憶の実装を替えた。** 計画では当初 ReasoningBank の予定だったが、リポジトリとともに配布されるその実装は別の供給者の埋め込みキーに強く依存し、私にはゲートウェイという接続しかない。そこで同じ手続き型ファミリーに属し、論文のもう一つの看板手法でもある ACE に替えた。これは同一の手法ではない。判定の際はファミリーの方向として見るしかなく、手法同士を対応させて見ることはできない。 - **記憶アームの転送層を一層替えた。** 著者が記憶手法のために用意した呼び出し経路は別のクラウド事業者のバッチ接口で、その OpenAI 互換バックエンドは記憶タイプを拒否する；私はローカルの作業コピーの中で転送層だけを差し替えた。プロトコル、プロンプト、記憶ロジック、切り捨てと採点はすべて固定コミットの公式コードだ。ついでに、上流由来の非対称を一つ明かしておく：著者の OpenAI バックエンドは A0 アームの呼び出しに temperature 1 を付けているが、記憶アームの通る経路はこのパラメータを渡さない——私はそれをそのまま残し、揃えるためにコードを変えはしなかった。だから 3 アームの間には、記憶の違いのほかに、この生成パラメータの差も挟まっている。 ## 結果：縮小は再現、割り込みは起きず 6 セルの成功率は以下の通り（各セル n=50、公式の成功判定）： | アーム | 16K | 128K | ゲイン（同段階の A0 に対して） | |---|---|---|---| | A0 記憶なし | 38%（19/50） | 44%（22/50） | — | | A1 BM25 検索 | 42%（21/50） | 44%（22/50） | +4.0 → 0.0 | | A2 ACE 手続き型 | 56%（28/50） | 50%（25/50） | +18.0 → +6.0 | 二種類の記憶のゲインはどちらも、予算を広げると縮んだ。最良ゲインは +18.0 から +6.0 へ。論文が DeepSeek 口径、四つの環境で報告するのは +14.5 → +8.5 だ（途中は単調ではない：64K 枠では +7.8 まで落ち、128K 枠で +8.5 に戻している）。桁は同程度、方向は一致——だがこの二組の数字は同じ表のセルではなく、並べて大小を比べることはできない。 128K 枠の細部は別に語る価値がある。論文はこの枠では既にベースラインを割る手法があると言う；私のところではなかった。BM25 のゲインはちょうどゼロに蒸発し（44% 対 44%）、「割り込み」の敷居の上に留まって、踏み越えなかった；ACE はベースラインの 6 ポイント上にいた。この結果は論文の節を確かめるものでも反証するものでもない：私は 15 種類の手法のうち 2 種類、4 つの環境のうち 1 つしか測っておらず、しかも選んだのはちょうどスペクトルの両端——最も単純な検索記憶と、論文の実行象限で最も強い部類の手続き型記憶だ；論文が名指しで 128K で割り込むとした MemAgent、MemoBrain はどちらも含まれていない。だから「割り込まなかった」ことの一部は選択そのものによって決まっている。言えるのは、このサブセットとこのバックボーンでは、「記憶が 128K で負の資産になる」は起きず、起きたのは「安い記憶から先に効かなくなる」ことだけだ——検索記憶のゲインが予算に最も敏感で、手続き型記憶のゲインの方が長持ちする。ACE のあの 12 ポイントの縮小を分解してみると：半分はベースライン自体が強くなったこと（A0 が 3 件多く正解）、もう半分は ACE の後退（3 件少なく正解）から来ている——どちらの変動も 3 件という量でしかなく、合わせれば図形になるが、ばらして物語にはならない。このセルは論文の Finding 4 とも同じ向きだ：3 アームで唯一の手続き型手法である ACE が、両段階とも最強だった。 統計面では少し熱を冷ましておく：各セルは 50 件しかなく、1 セルの 95% 区間はおよそ ±14 ポイント、4 ポイントの差はタスク 2 件分にすぎない。幸い、6 セルは同じ 50 件のタスクを走らせているので、成否の反転をペアで見ることができる：16K 枠では、ACE はベースラインより 9 件多く正解し、少なく正解したのは 0 件；だが縮小の幅そのものをペア bootstrap にかけると、ACE のあの 12 ポイントの 95% 区間の下限はちょうど 0 の上に乗り、BM25 の縮小はゼロと区別がつかない。だから本稿の方向の判定は記述的なものだ：図形は論文と同じ向きで、ACE の一アームにはペアの証拠が下支えにある；どれか 1 セルだけを見て勝ち負けを争うのは、ノイズの中に結論を探すことだ。 ## 記憶が払う家賃：コスト解剖 論文はスコアを報告し、各手法の総 token も報告した——だがそれはタスク実行と記憶モジュールを合算した総数だ（その付録の効率表を見よ）。記憶モジュール自身の呼び出しを切り分けてはいない。今回は用途別に切り分け、論文にはない数字の組を得た。 300 episode で消費したのは約 1517 万の入力 token、54 万の出力 token。ACE は自らの 100 episode の中で、記憶モジュール——各ターンの後の内省と経験キュレーションの呼び出し——に 266 万 token を食わせた：ACE 自身の入力だけで数えれば、記憶モジュールは約 36.5% を占める；全程 300 episode の総入力に均せば 17.6% だ。その出力 token は記憶なしアームの約 7.4 倍、内省もキュレーションも生成型の呼び出しだからだ；しかも出力の単価は入力の 6 倍で、金額で数えれば、この 7.4 倍は入力側の比率よりも請求書を傷める。言い換えれば、ACE が 100 の入力 token を使うごとに、約 36.5 はタスク自体を進めるためではなく、記憶を維持するために使われている。BM25 は記憶の維持呼び出しを生まない：索引も検索もローカルで行い、モデルを呼ばない；だが検索されたテキストはやはりコンテキストに入らなければならず、その分の入力 token は自らのタスクの勘定に付く——節約できるのは維持の呼び出しであって、コンテキストではない。 桁の感覚は論文自身の効率表と照らすことができる：DeepSeek 口径、128K 枠で、ACE の総 token は記憶なしベースラインの約 1.8 倍、増えた分は ACE の総量の約 43.5% を占める——私がここで切り分けた 36.5% と同じ桁だ（口径は異なる：論文は総 token のベースライン比、私のは ACE の入力内部の用途分解だ）。 この数字の組は、「記憶は割に合うか」の勘定の仕方を変えた。+18 ポイントのゲインは無料ではない。ACE 一家だけで、家賃は自らの入力の三分の一を超え、おまけに 7 倍を超える出力が付く；しかもこの家賃は予算の段階と無関係に存在する——128K 枠でゲインが +6 ポイントに縮んだときも、ACE の記憶モジュールはほぼ同じ量の token を食い続けていた（16K 枠 134 万、128K 枠 132 万）。記憶手法を評価するとき、記憶自身の呼び出しは手法のコストに数え入れるべきで、インフラの中に隠して一括りにしてはならない。Luna 档の公開価格（入力 0.20 ドル、出力 1.20 ドル、いずれも 100 万 token あたり）で換算すると、今回の 300 件のタスクの総額は約 3.7 ドルになる（ゲートウェイ口座の実際の課金はその側の基準によるもので、私には見えない）——安いのはバックボーン、高いのは構造だ。 ## 測らなかった部分 - **Finding 5（難易度の反転）は未測定。** 事前登録には副次プローブを残してあり、著者自身の難易度区分を使い、CrossEp-Know 象限で「易しい問題では記憶が負、難しい問題では記憶が正」を測るはずだった。プローブはパイロット段階まで進んだところでゲートウェイ口座の枠を使い切り、私が止めた。判定可能なデータは得られていない。したがって本稿は Finding 5 にいかなる結論も下さない。それが上文に現れるときは著者の報告としてのみだ。 - 論文の長コンテキスト対照（Gemini-3-Flash、GPT-5-mini などの専有モデル）は私には再実行できず、そのスコアは著者の報告として引用する。 - 残りの三つの象限、他の 13 種類の手法、論文の DeepSeek-V3.2 の元口径は、いずれも本稿の証拠の範囲の外にある。 これは本ブログの以前の Beacon のツール横断記憶の実測とちょうどつながる。あのときの結論は：記憶は「リポジトリ自体からは導き出せない知識」に対してだけ増分があり、自動捕捉と蒸留の層は脆い、というものだった。二つの証拠の形は異なる——あちらは単一システムの深掘り、こちらは横並び評価プロトコルの下でのサブセット再現——だが指し示すのは同じことだ：**記憶のゲインは決して当然に存在するものではなく、一組の条件の関数だ**。今回加わった条件は予算だ：コンテキストが安く、大きくなるほど、あらかじめ保存した記憶の値打ちは下がる；先に効かなくなるのは、検索だけをする部類だ。 ## 結論 Agent の記憶ソリューションを選ぶ立場なら、この再現が支えられる使い方は三つだけだ。第一に、ゲインの前に予算を言え：どの記憶手法の言う向上も、それがどれだけのコンテキスト予算の下で測られたものかを問うべきだ。予算を一段広げれば、ゲインは半分以上蒸発するかもしれない。第二に、記憶モジュール自身の token をコスト表に書け：生成型の記憶（内省、キュレーション、要約）の家賃は自らの入力の三分の一を超えうる（本例では 36.5%）し、ゲインが縮んでも減りはしない。第三に、この種のツール呼び出しタスクでは、手続き型記憶（本例の ACE）の方が両段階とも強いが、その呼び出しコストを払わなければならない；純粋な検索記憶は予算が十分なとき真っ先にゲインがゼロに戻り、予算が本当に制約されている場面にだけ向く。この環境の外へ急いで持ち出すな：論文の Finding 7 が示すように、ウェブ検索や身体性など他の実行領域では、最も合う記憶の形は同じではない。 このベンチマーク自体への私の判定はこうだ：Finding 3 の縮小パターンは、エンドポイントを替え、サブセットに縮めても、方向はなお合っている。それがその最も有用な部分だ；ただしエンドポイントの身元は独立に検証できない以上、これはエンドポイントをまたぐ探索的な再現であって、バックボーンをまたぐ証明にはならない。128K でベースラインを割るという、より鋭い言い方は、私のサブセットには現れなかった。それがより多くの手法に成り立つかどうかを判定するには、誰かが元口径で残りの 13 種類の手法を走らせ終える必要がある。それは本稿の結論ではない。本稿が残した未決の問いだ。 --- *証拠の境界：論文の数字はすべて arXiv:2605.18421 v3 の著者報告；当方の数字は上記のサブセット、3 アーム 2 段階とゲートウェイ表示エンドポイントに対してのみ成り立ち、単回実行。完全なレシート（6 セルの生の件数、token の分解、偏差の登録と統計的制約）、問題ごとのデータとペア分析スクリプトは本稿とともに公開済み（文頭の publicRepository を見よ）、ファイルごとに SHA256SUMS で検証できる。* ## Verification context - Level: first-party - Verified: 2026-11-02T00:00:00.000Z - Environment: 公式リポジトリ DSAIL-Memory/EvoMemBench @5f550e0c、InEp-Exec サブセット（BFCL multi_turn_ours）の公式 runner と採点 - Environment: Gorilla File System 環境、リポジトリが実際に配布する全 50 件のサンプル、3 アーム × 2 段階の予算で計 300 episode - Environment: バックボーンは第三者ゲートウェイが gpt-6-luna と表示するエンドポイント（表示された身元は独立に検証できず、判定はその表示エンドポイントの範囲に限る） - Evidence mode: mixed - Public repository: https://github.com/vxime/evomembench-agent-memory-replication - Evidence commit: 7e31af44c93fa88fb130e9417d36951b5ca1ac9d - Evidence receipt: https://vxi.me/evidence/evomembench-agent-memory-budget-replication.json