研究解読 · 小互解読

Meta AIが「プロアクティブ・メモリ・エージェント」を提案——エージェントに「言うべき時だけ言う」を学ばせ、Terminal-Benchの正答率が8.3ポイント上昇

論文には「すでにオープンソース化済み」と書かれているが、コードリポジトリを確認したところ中身は空だった。一行のコードも一度も push されていない。
1分でわかる要点
  • Meta AIが「プロアクティブ・メモリ・エージェント」を提案。手を加えない実行エージェントと並行して動き、構造化されたメモリバンクを定期的に更新しながら、実行エージェントに一言口を挟むべきかどうかを能動的に判断する。
  • Terminal-Bench 2.0において、Claude Sonnet 4.5にこのメモリエージェントを組み合わせると正答率が37.6%から45.9%に上昇(8.3ポイント増)。τ²-Benchでは55.0%から61.8%に上昇(6.8ポイント増)。
  • アブレーション実験によれば、メモリエージェント自身に「口を挟むべきか」を判断させるやり方は、メモリバンクを全量そのまま表示する方式、毎ステップ強制的に口を挟ませる方式、メモリバンクなしで助言だけする方式、汎用メモリ検索レイヤーMem0を接続する方式と比べて、いずれも効果がより安定していた。
  • チームはオープンソースの小型モデルQwen3.5-27Bを使い、同様のメモリエージェントを訓練(教師ありファインチューニング+強化学習)することも試みた。実行エージェントをオープンソースモデルQwen3.5-122Bに差し替えたうえでこのメモリエージェントを組み合わせると、Terminal-Bench正答率は37.6%(オープンソース実行モデル自体のベースラインで、偶然にもSonnet 4.5のベースラインと同値)から41.1%に上昇し、3.5ポイントの改善だった。これはClaude Opus 4.6をメモリエージェントとして使ったバージョンの効果より小さい。
  • 論文本文に書かれているコードリポジトリは確認したところ空のリポジトリ(サイズ0、作成後一度もコードがpushされていない)であり、2026年7月13日時点で実際にはまだオープンソース化されていない。
1 何なのか · なぜ見る価値があるのか

Meta AIが最近発表した内容

Meta AIの研究チームは2026年7月9日、arXivに論文を発表し、長時間タスクを実行するAIエージェントの傍らに、いつ口を挟むべきか、いつ黙っているべきかだけを判断する「プロアクティブ・メモリ・エージェント」を配置する手法を提案した。

このやり方は直感に反する結果をもたらす。より非力なClaude Sonnet 4.5にこのメモリエージェントを組み合わせると、コマンドライン長時間タスクのベンチマークTerminal-Bench 2.0での正答率が、同じくメモリエージェントを組み合わせた、より高価なClaude Opus 4.6と並び、さらにOpus 4.6が単体で出した成績すら上回った。
📊
実データ: Terminal-Bench 2.0において、メモリエージェントを組み合わせたSonnet 4.5は45.9%を獲得し、同じくメモリエージェントを組み合わせたOpus 4.6と同点(いずれも45.9%)、かつOpus 4.6単体の43.5%を上回った。つまり、安価なモデルにこのメモリエージェントを足すだけで、より高価なモデルの実力に並んだということだ。

論文の全著者はMeta AI所属。解決しようとしている問題は具体的だ——AIエージェントが数百ステップにわたり連続して長いタスクをこなすとき、それらの情報が対話記録にはっきり残っているにもかかわらず、早い段階で自分が守るべきだったルールを「忘れて」しまうことがよくある。まずはこの問題そのものを見ていこう。

2 問題

タスクが長くなると、AIは守るべきルールをこっそり忘れてしまうのか

論文はこの失敗パターンにbehavioral state decay(行動状態の劣化)という名前を付けた。情報が失われるわけではなく、記録にちゃんと残っているのに、もう機能しなくなるのだ。

長時間タスクは絶えず新しい情報を生み出す——タスクの要件、環境に関する事実、過去に試したこと、診断済みの不具合、まだ終わっていないサブゴール。軌跡が伸びるにつれ、これらの情報はモデルが見えるコンテキストウィンドウから押し出されるか、あるいはウィンドウ内に残ってはいても、もはや実際の次の一手を左右しなくなる。論文はこの「今後の行動を制約し続けるべき」情報を execution state(実行状態)と総称している。

たとえて言うと

まるで壁一面に付箋を貼りまくるようなものだ。貼るときは一枚一枚しっかり覚えているのに、貼りすぎると、もう見上げなくなる。文字は壁に残っているのに、もう今の行動には影響しない。

次の時系列は、早い段階で記録された要件が、どうやって「生きている」状態から「記録には残っているが次の一手を左右しない」状態へと徐々に色あせていくかを示している。

ステップ2 · 記録
ルール: IPセグメントは単一数字でもよい
ステップ4
ルールは記録に残っている
ステップ6
ルールは記録に残っている
ステップ8 · 別のバグを修正
新しく書いた正規表現が単一数字セグメントを見落とす
結果
✗ 自分が早期に記録した要件に違反

タイムラインは左右にスワイプできます。最後まで見て結末を確認 →

情報はずっとそこにあったのに、もう次の一手を左右しない。論文はこれが長文コンテキストにおける「lost in the middle」(途中に埋もれた情報が無視される)現象と関係があるとしつつ、より強調しているのは行動レベルでの機能不全だとしている。

論文が挙げる3つの典型的な失敗

①早い段階である要件を発見していたのに、後で無関係な別のバグを修正する際、その要件に違反してしまう。
②あるコマンド、あるパラメータ、ある実装経路を試して明確に失敗していたのに、後でほぼ同一のバリエーションを再び試してしまう。
③すでにあるエラーパターンを診断していたのに、後で同じパターンを全く新しい問題として扱い、最初から処理し直してしまう。

論文はここから一つの判断を導く——単により長い履歴をモデルに与えるだけでは不十分だ。本当に欠けているのは、「記憶されたこの情報を今、意思決定に反映させ直すべきかどうか」を決める仕組みなのだ。

3 手法 · コア

横に記憶マネージャーを立たせ、作業はさせず「口を挟むべきか」だけを管理させる

これが論文の第一のコアだ。やり方はこうだ——作業をする実行エージェントは一文字も変えず、その傍らでもう一つ記憶エージェントを別に走らせる。固定ステップ数ごとに一度起こされ、まず構造化されたメモリバンクを整理し、それから実行エージェントの次のステップに一言口を挟むかどうかを決める。

実行エージェント
⇄
環境
→毎ステップ起動
記憶エージェント
(直近8件のメッセージを見る)
→注意喚起を注入
次のステップの判断

フロー図は左右にスワイプできます →