長時間動くAIエージェントは、途中で得た情報を忘れるだけではない。情報が履歴やコンテキスト内に残っていても、次の行動を決めるときに効かなくなる。
たとえば、エージェントが次の事実を途中で確認したとする。
- 本番環境は変更してはいけない
- あるコマンドは権限エラーで失敗した
- 修正対象は
config/ではなくdeploy/にある - テストは通ったが、リリース手順が未完了である
履歴が長くなると、これらは画面上に残っていても、次のツール呼び出しや判断に反映されないことがある。結果として、失敗した操作を繰り返したり、初期の制約を破ったり、完了していない仕事を見落としたりする。
Meta AIの研究者らによる Remember When It Matters: Proactive Memory Agent for Long-Horizon Agents は、この問題を behavioral state decay（行動に効く状態の減衰） と呼ぶ。重要なのは、記憶を大量に検索して渡すことではなく、いまの次の一手に必要な記憶だけを、必要な瞬間に介入させることだという。
これは、企業がAIエージェントを業務に入れる際の設計にも直結する。長いコンテキストウィンドウやRAGを追加しただけでは、エージェントが「過去に知ったことを守って行動する」ことは保証されない。
長い履歴があっても、エージェントは過去の制約を守れるとは限らない
長期タスクでは、エージェントが観測、ツール実行、失敗、再計画を何度も繰り返す。必要な実行状態は、一箇所にまとまっていない。
依頼の制約 → 環境を調査 → ツール実行 → エラーを診断
→ 一部を修正 → テスト → 次の作業を判断
この流れで次の判断を制約する情報には、少なくとも五種類ある。
| 種類 | 例 | 忘れたときに起きること |
|---|---|---|
| 要件・ポリシー | 削除禁止、返金条件、承認が必要な操作 | 業務ルールや安全境界を破る |
| 環境の事実 | 作業ディレクトリ、利用可能なツール、設定値 | 存在しない場所や手段を前提にする |
| 失敗した試行 | 権限拒否されたAPI、失敗したコマンド | 同じ失敗を再試行する |
| 診断・発見 | エラーの原因、成功した修正 | 解決済みの問題を再調査する |
| 未完了の下位目標 | テスト、承認、対外連絡、後処理 | 「できた」と誤って完了扱いにする |
論文が指摘するのは、これらがコンテキストから完全に消える場合だけではない。履歴に存在しても、モデルの現在の行動を十分に制約しない場合がある。したがって、コンテキストを長くすることと、過去の実行状態を行動へ反映することは別問題である。
「記憶を検索する」から「記憶を介入させる」へ
提案されたProactive Memory Agentは、実際にツールを使って作業する action agent と、横で見守る memory agent を分ける。action agent自体のモデル、ツール、基本指示は変えない。
action agent ──操作・観測──→ 実行環境
↑ │
│ 必要なときだけ短いリマインド │ 直近の軌跡
│ ↓
memory agent ──状態を更新・選別──→ memory bank
memory agentが行う仕事は二段階である。
- 記憶を管理する: 直近の実行履歴を基に、要件、環境の事実、失敗した方法、成功した修正、未解決の論点を構造化して更新する。古くなった情報は削除できる。
- 介入するか決める: 更新後の記憶を見て、次のaction agentの判断に効くときだけ、短いリマインドを渡す。不要なら何も渡さない。
ここで「何もしない」は失敗ではなく、明示的な選択肢である。論文の設計では、memory agentの私的な進捗管理はaction agentへ見せず、実行に必要な短い文脈だけを一時的に注入する。記憶バンク全体を毎回渡して、現在の作業をかえって散漫にしないためだ。
たとえば、エージェントが同じ権限エラーにつながるコマンドを再実行しようとしているときだけ、次のような介入をする。
この方法は先ほど権限拒否で失敗している。まず読み取り専用の手順か、必要な承認経路を確認する。
一方、エージェントがすでに適切な手順で進んでいるなら、リマインドは挟まない。これは単なる要約ではなく、次の行動に介入するかどうかの制御である。
常時表示のメモリは、必ずしも最良ではない
「大事な情報を毎回すべて与えればよい」と考えたくなる。しかし、不要な情報は入力トークン、遅延、注意の分散を増やす。しかも、古い状態や曖昧な推測が常に混ざると、エージェントを誤誘導しかねない。
論文は、Claude Sonnet 4.5をaction agent、Claude Opus 4.6をmemory agentとしたτ²-Benchで、記憶の扱いを比較している。以下は同論文のアブレーション結果の要点であり、研究用ベンチマークでの結果であって、そのまま業務システムの効果を保証するものではない。
| 方式 | 記憶の扱い | τ²-Benchのマクロ平均 pass@1 |
|---|---|---|
| memoryなし | 追加の記憶なし | 57.5% |
| memory bank全体を毎回渡す | 記憶は管理するが、選別しない | 61.5% |
| 毎回リマインドを渡す | 選別するが、沈黙できない | 63.5% |
| 提案方式 | 記憶を管理し、必要なときだけ介入 | 64.3% |
常時リマインドはタスク数に重みを置く指標では近い結果だったが、論文では領域を均等に扱うマクロ平均で選択的な介入が最も良い。ここから一般化できるのは、「毎回知らせる」ことよりも、情報の有効期限、現在の作業との関係、介入の副作用を管理することが重要だという点である。
ベンチマークの改善値は、どこまで読めるか
論文では、memory agentの追加により、二種類の長期エージェント評価でpass@1が改善したと報告している。
| 評価 | action agent | memoryなし | memoryあり | 差 |
|---|---|---|---|---|
| Terminal-Bench 2.0（85タスク） | Claude Sonnet 4.5 | 37.6% | 45.9% | +8.3ポイント |
| Terminal-Bench 2.0 | Claude Opus 4.6 | 43.5% | 45.9% | +2.4ポイント |
| τ²-Bench | Claude Sonnet 4.5 | 55.0% | 61.8% | +6.8ポイント |
| τ²-Bench | Claude Opus 4.6 | 66.2% | 68.7% | +2.5ポイント |
さらに、Qwen3.5-122B-A10Bをaction agent、SFTとGRPOで学習させたQwen3.5-27Bをmemory agentとした実験では、Terminal-Bench 2.0で37.6%から41.1%への改善が報告されている。これはmemory agentを必ずしも最大級のモデルで動かさなくてよい可能性を示す初期結果である。
ただし、この研究は2026年7月に公開されたプレプリントであり、対象はコマンドラインと航空・小売・通信のツール利用ベンチマークである。社内の実データ、権限設計、障害時の復旧、利用コストを含む本番運用で同じ改善率が出るとは読めない。評価値は製品選定の結論ではなく、リマインドのタイミングを独立した設計対象として扱う根拠として読むべきだ。
実装では、memory bankを「もう一つの正本」にしない
この発想を業務エージェントへ持ち込むとき、memory bankを何でも保存する会話ログや、業務データのコピーにしてはいけない。保存すべきなのは、次の判断を安全に変える、短く検証可能な実行状態である。
| 設計項目 | 最低限の要件 |
|---|---|
| 根拠 | 元の依頼、正式な規程、ツール結果、承認記録へたどれる |
| 種別 | 要件、環境事実、試行結果、診断、未完了項目を区別する |
| 鮮度 | 作成・更新時刻、有効期限、変更時の失効条件を持つ |
| 確信度 | 観測済みの事実と仮説を混ぜない |
| 削除・訂正 | 古い状態を無効化し、訂正理由を残せる |
| 可視性 | action agentに渡した内容、渡した時刻、渡さなかった判断を追える |
| 権限 | 機密情報を無制限に記憶・再注入しない。実行主体ごとに読める範囲を分ける |
特に危険なのは、推測を「記憶された事実」にしてしまうことだ。たとえば、ツールエラーを見て「API障害だろう」と仮説を保存し、後続のaction agentへ断定的に渡せば、正しい調査経路を狭める。記憶エージェントも、誤った情報をもっともらしく再提示するコンポーネントになり得る。
そのため、memory entryには少なくとも「情報源」「観測時刻」「事実か仮説か」「失効条件」を持たせたい。重要な実行や外部送信の許可は、memory agentのリマインドではなく、モデルの外側にあるポリシー、権限、承認ワークフローで強制する。
先に測るべきは「思い出した回数」ではなく、行動が改善したか
memory agentを入れると、記憶件数や介入回数を見たくなる。しかし、それだけを増やすと、常時リマインドへ逆戻りする。評価は、介入が次の行動を良く変えたかで行う必要がある。
実行ログ
→ 介入候補（根拠・鮮度・対象行動）
→ memory agentの「介入 / 沈黙」
→ action agentの次の操作
→ 業務結果・安全結果・人間レビュー
→ 介入の妥当性を評価してルールを更新
最初の評価セットには、正常系だけでなく次を含める。
- 過去に失敗した操作を再試行しそうになるケース
- 古い規程や失効した状態を参照しそうになるケース
- 未完了の承認・後処理を飛ばして完了扱いしそうになるケース
- 不確実な診断を断定して進みそうになるケース
- リマインドが不要なのに、現在の進行を邪魔するケース
見る指標も、次のように分けるとよい。
| 観点 | 代表指標 |
|---|---|
| 業務品質 | タスク完了率、再作業率、未完了の見落とし率 |
| 安全性 | ポリシー違反、権限逸脱、危険な再試行、誤った介入率 |
| 効率 | 追加トークン、追加遅延、追加モデル費用、手戻り時間 |
| 運用可能性 | 根拠を再現できる割合、失効・訂正の反映時間、停止成功率 |
「memory agentが何度話したか」ではなく、介入しなかったときも含めて、全体の成功率、安全性、コストがどう変わったかを確認する。
まとめ：記憶はストレージではなく、行動を変えるための制御面である
長時間動くAIエージェントでは、コンテキストを増やすだけでなく、過去の要件、失敗、診断、未完了事項をいつ次の判断へ戻すかが重要になる。
Proactive Memory Agentの研究が示したのは、次の分業である。
記憶を残す : 実行状態を構造化して更新する
記憶を見せる : 次の判断に必要なときだけ短く介入する
行動を許可・禁止する: モデル外の権限・ポリシー・承認で強制する
企業での実装では、二つ目だけを真似して「別のAIに助言させる」ことから始めるべきではない。何を事実として保存するか、いつ失効するか、どの介入が業務上の行動を変えたか、誤った介入をどう止めるかまでを設計する必要がある。
AIエージェントの記憶は、便利な会話履歴ではない。過去の実行状態を、現在の行動へ安全に反映するための制御面として扱うとき、初めて長時間タスクの信頼性を上げられる。
作成日: 2026年9月21日