何が起きたか
Meta AIが、長時間タスクを走らせるAIエージェントの精度を上げる新しい構成を公開しました。ポイントは、実行役の「Action Agent」には手を加えず、別に「Memory Agent」を置くことです。Memory Agentは一定間隔で直近ステップのスライディングウィンドウを読み、構造化されたメモリバンクを更新し、そのうえで「次の呼び出しにひと言リマインドを差し込むか、黙っているか」を判断します。コードはGitHubで公開されています。
狙いは、論文が「behavioral state decay（行動状態の劣化）」と呼ぶ失敗モードの解消です。エージェントの判断を支えている状態が、膨れ上がるタスク履歴の中に散らばり、コンテキストウィンドウの奥に埋もれ、やがて落ちる。しかも厄介なのは、テキストとしてまだ文脈に残っていても、実際の振る舞いを左右しなくなる点です。Meta AIは、履歴を長くするだけではこの問題は解けないと明言しています。
なぜ「保存・検索」だけでは足りないのか
既存のメモリ基盤の多くは、保存・更新・検索に最適化されています。それはパーソナライズやセッションをまたいだ想起にはよく効きます。しかしタスク実行中のエージェントに必要なのは、別の判断です——「この記憶は、今この瞬間に引き戻す価値があるか」。
ここには明確なトレードオフがあります。リマインドが少なすぎれば同じミスを繰り返し、多すぎればレイテンシとトークンを食い、目の前の作業から注意を逸らします。要約器との違いもここにあります。要約器は「何を残すか」を決めますが、Metaの仕組みは「保存済みの実行状態が次の一手に影響すべきか」を決めます。失敗の型はタスクごとに違うため、固定の要約ルールではこの判断は下せない、というのが著者らの主張です。
メモリバンクの三層と二段階の処理
メモリバンクは3つのセクションに分かれます。進捗と未解決リスクを追う「private status」（Action Agentには一切見せない）、要件・ファイルパス・設定といった安定した事実を置く「Knowledge Memory」、そして何を試して何が起きたか——失敗したコマンド、効いた修正、棄却した仮説——を残す「Procedural Memory」です。
処理は二段階。Phase 1でメモリバンクを更新し、Phase 2で「保存済みの記憶が次の判断に影響すべきか」を決めます。更新は自由な上書きではなく、あらかじめ定義されたツール呼び出し経由に限定されます。そして「介入しない」ことも方針の一部として明示的に扱われます。
効き方はドメインで割れた
tau2-Benchでは航空とリテールが各約10ポイント改善した一方、テレコムは3ポイントにとどまりました。研究者らは、この不均一さこそがMemory Agentが固定ルールで集約しているのではなく、タスクごとに介入頻度を変えている証拠だとしています。
アブレーションも示唆的です。毎ステップでメモリバンク全体を丸ごと渡す版は、フルシステムより悪化しました。「黙る」選択肢を外して毎回何かを返す版は競争力を保ったものの、ドメイン間で改善が安定しません。メモリバンクを持たないアドバイザー型は、伸びる領域と落ちる領域が混在しました。維持されたメモリバンクと選択的リマインドの組み合わせが最良だった、という結論です。検索でレコードを引く本番向けメモリ層Mem0も上回っており、差は「何を取り出すか」だけでなく「取り出した状態をどうループに戻すか」にあると整理されています。
tau2-Benchの航空タスクには分かりやすい例があります。ユーザーがGold会員だと主張したがツール側の照会では一般顧客だった場面で、ベースラインは主張のまま補償を認めました。Memory Agentは「検証済みのツールデータに従え」というリマインドを差し込んでいます。残る誤りの多くは記憶そのものではなくキャリブレーション——推測に過ぎない推論を過信する類——だったとされます。
モデル側の含意
Memory AgentにはClaude Opus 4.6が使われました（同モデルはその後複数回アップデートされています）。改善幅は弱いエージェントほど大きく、強いエージェントでも消えませんでした。Opus 4.6を実行役にした場合でもTerminal-Benchで2.4ポイント、tau2-Benchで2.5ポイントの改善です。つまりこれは「弱いモデルの穴埋め」だけの技術ではない、という読み方になります。
主要版は専用学習を必要とせず、プロンプトされたエージェントとして動きます。加えて、巨大な実行モデルを凍結したまま、小さいQwen3.5-27BをMemory Agentとして学習させる実験も行われました。無学習では性能が落ちましたが、教師ありファインチューニングで回復し、その後の強化学習で「いつ記憶を呼び戻すか」の判断が改善しています。
残る論点として、両エージェントの同時学習、固定スケジュールではなく必要時に記憶を呼び出す設計、そして逐語的な記憶とタスク特化の抽象化のどちらが有効かの見極めが挙げられています。業界に標準解はまだありません。オープンソースのMastraは全履歴を文脈に保持せず、2つのバックグラウンドエージェントで会話を監視・圧縮します。長い対話での「context rot」を防ぐGAMも、Metaと同様にMem0と比較しています。知識を能動的に追加・修正・忘却する生涯記憶システムの研究も進んでいます。
💼 事業会社視点：これは自社にどう効くか
実務的な含意は「エージェント基盤の作り直しは不要」という一点に集約されます。この仕組みはAction Agentを改変しないプラグアンドプレイ型で、既存のエージェントやハーネスに横付けできます。すでに社内でコーディングエージェントやカスタマーサポート自動化を走らせている日本企業にとって、モデル乗り換えより投資対効果の読みやすい打ち手です。
特に効くのはtau2-Benchの検証結果が示す領域です。航空・リテールで各約10ポイント伸びた一方、テレコムは3ポイント。ECやSaaSのサポート自動化を担う事業責任者は、自社のタスク型がどちらに近いかを見極める必要があります。「ユーザーの自己申告よりツールの照会結果を優先する」という航空の事例は、会員ランク・契約プラン・返品可否など、日本のEC・サブスク運用でそのまま起きている事故そのものです。ここはPoCで再現検証する価値があります。
受託開発・SIerには収益機会が生まれます。Knowledge Memory（要件・ファイルパス・設定）とProcedural Memory（失敗コマンドと効いた修正）の切り分けは、顧客ごとの運用知見をそのまま資産化できる構造です。コードはGitHubで公開されており、Mem0のような既製メモリ層を上回った点も提案材料になります。
経営判断としては二つ。第一に、エージェント精度の議論を「もっと大きいモデル／長いコンテキスト」から「いつ思い出させるか」へ移すこと。第二に、Qwen3.5-27Bの実験が示すように、記憶役だけを小型モデルに寄せればコスト構造を変えられます。ただしMemory AgentにOpus 4.6級を使う前提では推論コストが積み上がるため、まずは失敗の再発コストが高い業務から限定投入するのが現実的です。