# エージェントメモリ ## 定義 エージェントメモリとは、LLM ベースのエージェントが過去の対話・行動・環境観測を蓄積し、必要に応じて取り出して活用する機構の総称である。Hu+ (2025) は形態(Forms)・機能(Functions)・動態(Dynamics)の 3 軸から成る統一タクソノミを提案し、エージェントメモリを独立した研究領域として位置づけた初の体系的整理を行った ([[@2025__arXiv__Memory in the Age of AI Agents]])。 エージェントの行動方策は $a_t = \pi_i(o_{it}, m_{it}, Q)$ と形式化される。$o_{it}$ は観測、$m_{it}$ はメモリ由来の信号、$Q$ はクエリであり、メモリ信号が意思決定に明示的に組み込まれる構造になっている。メモリ状態 $M_t \in \mathcal{M}$ は形成演算子 $F$、進化演算子 $E$、検索演算子 $R$ を通じてライフサイクルを辿る。 ## 形態-機能-動態タクソノミ ### 形態(Forms) — メモリの表現形式 | 形態 | 特徴 | 代表システム | |------|------|-------------| | トークンレベル | 記号的・アドレス可能・人間可読。1D フラット・2D グラフ・3D 階層の 3 構造に細分 | MemGPT, Mem0, A-Mem | | パラメトリック | モデルパラメータへの内部化。暗黙的・汎化可能 | Retroformer, RLKF | | 潜在 | KV キャッシュ圧縮やメモリトークン生成。人間可読でない | MemGen, Titans, MEM1 | ### 機能(Functions) — メモリが担う役割 | 機能 | サブカテゴリ | 概要 | |------|------------|------| | 事実メモリ | ユーザー事実 / 環境事実 | ユーザーの嗜好・プロファイル、環境の知識・状態 | | 経験メモリ | 事例ベース / 戦略ベース / スキルベース | 過去の軌跡・洞察・再利用可能な関数やコード | | 作業メモリ | 単一ターン / マルチターン | 入力圧縮・状態統合・階層的折り畳み・認知的計画 | ### 動態(Dynamics) — メモリのライフサイクル 1. **形成(Formation)**: 意味的要約・知識蒸留・構造化構築・潜在表現化・パラメトリック内部化の 5 経路でメモリを生成する。 2. **進化(Evolution)**: 統合（重複除去・マージ）、更新（追加・置換・編集）、忘却（時間減衰・重要度ベース・明示削除）の 3 機構でメモリを維持する。 3. **検索(Retrieval)**: タイミング/意図の決定、クエリ構成、検索戦略（語彙的・意味的・グラフベース・生成的・ハイブリッド）、後処理（再ランキング・集約圧縮）の 4 段階で構成される。 ## 隣接概念との関係 Hu+ (2025) はエージェントメモリと LLM メモリ・RAG・[[コンテキストエンジニアリング]]の包含/排他関係をベン図で明示した最初の試みである（Figure 2）。 - **LLM メモリ**: アテンション KV 管理など、モデル内部のメモリ機構。エージェントメモリはほぼ包含するが、ニューラルスケーリングの議論など一部は独立。 - **RAG**: 外部知識ベースからの検索拡張。エージェントメモリはこれを部分集合として含む一方、RAG はモジュラー RAG・グラフ RAG 等の固有拡張を持つ。 - **[[コンテキストエンジニアリング]]**: プロンプト・ツール出力・状態をまたいだ情報フローの設計。エージェントメモリは自己進化的メモリ、パラメトリックメモリ、潜在メモリなど、コンテキストウィンドウの外に広がる領域をカバーする点で射程が異なる。 ## 代表的システム | システム | 形態 | 機能 | 特徴 | |---------|------|------|------| | MemGPT | トークンレベル (2D) | 事実 + 作業 | OS 的抽象でメイン/外部コンテキストを階層管理 | | Mem0 | トークンレベル (2D) | 事実 + 経験 | グラフ + ベクトルストアの複合アーキテクチャ | | Reflexion | トークンレベル (1D) | 経験 | 言語的フィードバックをエピソード記憶として蓄積 | | Voyager | トークンレベル (1D/3D) | 経験(スキル) | 再利用可能なコードスキルライブラリを逐次拡張 | | MemOS | トークンレベル (3D) | 事実 + 経験 | ツリー構造メモリ + memcube による階層管理 | | MEM1 | 潜在 | 作業 | 単一セッション内で潜在状態としてメモリを圧縮 | | OpsMem | トークンレベル(2D グラフ) | 作業(STM) + 経験(LTM) | 失敗診断ドメイン特化。STM/LTM 双方をグラフ構造で表現し、cross-memory resonance で状態条件付き検索を行う | | ActionNex | トークンレベル(構造化 KCA 三つ組) | 事実(playbook 由来) + 経験(過去 outage 事例) + 作業(ライブ状態) | outage 管理ドメイン特化・本番稼働。Key-Condition-Action の 3 種テキスト構造で長期記憶を索引化し、暗黙の人間フィードバックで自己進化する | ## 横断的知見 - **[[コンテキストエンジニアリング]]との射程の違い**: [[コンテキストエンジニアリング]]（Boris Tane, 2026）が「エージェントに与える情報の品質を設計・管理する」実践者側の視点を主軸とするのに対し、エージェントメモリ（Hu+, 2025）は「エージェント自身がメモリをいかに形成・進化・検索するか」という自律的管理の側面を主軸とする。両者は補完的な関係にあり、エージェントメモリの検索結果がコンテキストの素材となる点で接続するが、射程は明確に異なる。なお Hu+ の分類では[[コンテキストエンジニアリング]]はエージェントメモリに部分的に包含されるとされており、概念の上下関係が逆転している点は注目に値する。(Source: [[@2025__arXiv__Memory in the Age of AI Agents]], [[コンテキストエンジニアリング]]) - **[[エージェント型強化学習]]との接続**: エージェントメモリの動態フロンティアとして「RL フリー → RL 補助 → 完全 RL 駆動」への進化路線が論じられており（RMM, Mem-α, Memory-R1 等）、[[エージェント型強化学習]]の発展と密接に絡み合う。メモリ管理そのものを RL で学習させるアプローチが次のフェーズとして位置づけられている。(Source: [[@2025__arXiv__Memory in the Age of AI Agents]]) - **「検索(Retrieval)」を状態変化のたびに再計算する設計は、Hu+ の 4 段階検索モデルに「トリガー条件」という新しい軸を加える**: Hu+ 2025 の動態タクソノミは検索を「タイミング/意図の決定→クエリ構成→検索戦略→後処理」の 4 段階で構造化するが、いつ検索をトリガーするかの具体的な設計原則までは踏み込まない。OpsMem([[@2026__arXiv__OpsMem - Dual-Memory Reasoning with Cross-Memory Resonance for Failure Diagnosis]])の cross-memory resonance(CMR)は、作業メモリ(STM)が更新されるたび必ず長期記憶(LTM)の活性化を再計算するという明示的なトリガー条件を実装する。これは「一度検索したら固定」という静的 RAG の限界(OpsMem 論文が VectorRAG/GraphRAG/LinearRAG 全てに対して指摘する「進行する診断状態と整合しない」問題)に対する、動態タクソノミの検索段階への具体的な補完である。アブレーション(w/o CMR で Match が 78.33→56.67 に低下)は、この「トリガー条件付き再検索」自体が独立した精度への寄与を持つことを定量的に示した。(Source: [[@2025__arXiv__Memory in the Age of AI Agents]], [[@2026__arXiv__OpsMem - Dual-Memory Reasoning with Cross-Memory Resonance for Failure Diagnosis]] §III-B, §IV-C) - **作業メモリと経験メモリを分離しても、両者を結合する第三の機構(CMR)なしには性能が頭打ちになる**: Hu+ のタクソノミは作業メモリ・経験メモリを別カテゴリとして定義するが、両者の「結合」自体を独立コンポーネントとして扱わない。OpsMem のアブレーションは、STM 単独除去(78.33→45.00)・LTM 単独除去(78.33→30.83)に加えて CMR 単独除去(78.33→56.67)でも大きな低下を示す。これは「STM と LTM を両方持つ」ことと「両者を動的に結合する」ことが独立した設計上の貢献であることを実証しており、単純な形態分類(トークンレベル/パラメトリック/潜在)だけでは捉えきれない、メモリ間の協調機構そのものが精度を左右するという知見を追加する。(Source: [[@2026__arXiv__OpsMem - Dual-Memory Reasoning with Cross-Memory Resonance for Failure Diagnosis]] §IV-C Table II) - **メモリが精度を「改善」ではなく「悪化」させる産業実証例が加わった**: Hu+ のタクソノミや OpsMem は一貫してメモリの追加が性能を改善する方向の知見を示すが、[[@2026__FSE Companion__LLM Agents for AIOps in Kubernetes - An Industrial Experience Report with Red Hat OpenShift]] は Red Hat OpenShift 上の ReAct エージェントで、時間的再計算を要するクエリ(タイムスタンプ計算等、Q-10〜Q-20)に対し明示的メモリを付与すると、古い/誤適用された文脈保持により正答率が悪化することを観測し、精度優先でメモリを無効化する運用判断を下した。これは「常時オンのメモリ」を前提とする形態-機能-動態タクソノミに対し、**メモリを選択的に無効化すべきタスク種別**(状態に依存しない冪等な再計算タスク)という新しい設計軸を加える一次資料であり、本ページの学術的知見(メモリ追加=改善)と産業実装の知見(メモリ追加=時に悪化)の対比として記録に値する。(Source: [[@2026__FSE Companion__LLM Agents for AIOps in Kubernetes - An Industrial Experience Report with Red Hat OpenShift]] §5.1) - **RAGの外部知識ベース(Hu+のタクソノミにおける「事実メモリ」の環境事実)を支える検索インフラ側にも、メモリと同型の「保持/再計算」トレードオフが存在する**: Hu+ (2025) はエージェントメモリと RAG の関係を「エージェントメモリが RAG を部分集合として含む」とベン図で整理するが、RAG が依拠する検索インフラ自体の内部設計までは踏み込まない。[[ベクトル検索インデックス|LEANN]]([[@2025__arXiv__LEANN - A Low-Storage Vector Index]])は、ベクトル検索インデックスにおいて埋め込みを常時保存する代わりにクエリ時に再計算する設計(高頻度アクセスのハブノードだけを厚く保持し、稀にしかアクセスされない要素は都度再構築する)を提案しており、これはエージェントメモリの「忘却(時間減衰・重要度ベース)」機構と構造的に同型の設計原理である。両者はまだ独立した研究系譜だが、「常時保持コストと再計算コストのどちらを払うか」という制約最適化問題を異なる層(エージェントの経験メモリ vs 検索インデックスのベクトル)で解いている点が横断的に見える。(Source: [[@2025__arXiv__Memory in the Age of AI Agents]], [[@2025__arXiv__LEANN - A Low-Storage Vector Index]]) - **経験メモリ(スキルベース)の「正例のみ」設計は、失敗事例を積極的に含めることで診断力を増す**: Hu+ のタクソノミは経験メモリのサブカテゴリとして「事例ベース・戦略ベース・スキルベース」を挙げるが、失敗事例(負例)を明示的に含めるべきかは論じない。[[LLMによるカーネル最適化|AccelOpt]]([[@2026__MLSys2026__AccelOpt - A Self-Improving LLM Agentic System for AI Accelerator Kernel Optimization]])の最適化メモリは、スロー→ファストの成功例(正の書き換え)だけでなくファスト→スローの失敗例(負の書き換え)も速度低下の閾値 $t_{neg}$ で選別して均等に含める設計を採り、「正例だけでは自己生成 in-context 例を繰り返すだけの罠(自己強化バイアス)に陥りやすい」という問題意識に基づいて正負両方のシグナルをバランスさせている。これはカーネル最適化のような、コード変更の効果を数値で直接測定できるドメインに特有の「テスト時学習(test-time learning)」の一形態であり、容量 ExpN・更新積極性 TopK というハイパーパラメータで経験蓄積のトレードオフを制御する具体的な数値実験(Figure 15)を伴う点で、Hu+ の定性的なタクソノミに定量的な設計指針を追加する。(Source: [[@2025__arXiv__Memory in the Age of AI Agents]], [[@2026__MLSys2026__AccelOpt - A Self-Improving LLM Agentic System for AI Accelerator Kernel Optimization]] §2.3, §4.5) - **メモリ容量を増やす方が更新頻度を増やすよりコスト効率が高いという知見は、忘却(時間減衰)機構の設計に示唆を与える**: Hu+ の動態タクソノミは「忘却」を時間減衰・重要度ベース・明示削除の3機構に分類するが、容量と更新頻度のどちらを優先すべきかという定量的比較は行わない。AccelOpt は固定容量キュー(ExpN)の容量を増やす方が、キューへの新規追加数(TopK)を増やすより高速化率の改善が大きいことを実験的に示した(同程度のコスト増加あたりの速度向上デルタを比較、Figure 15)。これは「古い経験を多く保持する」ことが「新しい経験を積極的に取り込む」ことより価値が高い場合があることを示す一次データであり、時間減衰型忘却機構のパラメータ選定(どれだけ保持するか vs どれだけ早く更新するか)に定量的な参考事例を与える。(Source: [[@2025__arXiv__Memory in the Age of AI Agents]], [[@2026__MLSys2026__AccelOpt - A Self-Improving LLM Agentic System for AI Accelerator Kernel Optimization]] §4.5) - **産業実装は Hu+ の「経験メモリ」を『事例ベース』と『戦略ベース』の中間形態(KCA)として具体化し、記憶の監査可能性を明示的な設計目標に格上げする**: Hu+ のタクソノミは経験メモリを事例ベース・戦略ベース・スキルベースに分類するが、いずれも実装上は暗黙的な埋め込みベクトルやコード資産として表現されることが多い。[[ActionNex]]([[@2026__arXiv__ActionNex - A Virtual Outage Manager for Cloud Computing]])の長期記憶は、Key(文脈スコープ)・Condition(一般化症状)・Action(パラメータ化された対応)という 3 要素をすべて**テキストとして格納**し、ドメインエキスパートが直接読み書き・監査・訂正できる設計を明示的な要件とする。これは、OpsMem のグラフ表現や AccelOpt の埋め込みベースの経験蓄積とは異なり、「機械学習が生成した知識を人間が検証可能な形で維持する」という産業運用特有の制約(outage 対応という高リスク領域で、記憶の誤りが実害につながる)がメモリの表現形式そのものを規定した事例である。(Source: [[@2025__arXiv__Memory in the Age of AI Agents]], [[@2026__arXiv__ActionNex - A Virtual Outage Manager for Cloud Computing]]) - **人間実行アクションを暗黙報酬として使う自己進化は、Hu+ の「進化(Evolution)」動態に、RL を介さない産業向けの第 4 の経路を追加する**: Hu+ の動態タクソノミは、エージェントメモリの進化を統合・更新・忘却の 3 機構、および OpsMem 節で触れた「RL フリー→RL 補助→完全 RL 駆動」という進化路線で整理する。ActionNex は、人間が最終的に実行したアクションを明示的な報酬関数もポリシー勾配も使わずに記憶へ書き戻すだけで継続改善を得る、RL 不要かつルールベースでもない「暗黙フィードバックによる自己進化」を採用する。これは人間-エージェントハイブリッドの意思決定ループ(推薦は人間が選別・実行し、その選択が次の学習信号になる)を記憶進化の主要経路とする設計であり、OpsMem や AccelOpt が想定する「エージェントが自律的に試行錯誤する」設定とは異なる、**人間の意思決定を暗黙のラベラーとして使う**という産業運用特有の進化経路を追加する。(Source: [[@2025__arXiv__Memory in the Age of AI Agents]], [[@2026__arXiv__ActionNex - A Virtual Outage Manager for Cloud Computing]]) ## 未解決の問い - 完全 RL 駆動のメモリアーキテクチャは、手作業設計の認知心理学的メタファー（エピソード/意味記憶）を本当に超えられるか？評価ベンチマーク自体も人間の認知モデルに基づく可能性があり、循環論法に陥らないか検討が必要だ。 - マルチモーダルメモリのための統一的な表現形式はどうあるべきか？画像・動画は先行しているが、音声・センサーデータなどを含む真のオムニモーダルメモリは未達成であり、統一表現が存在しない。 - マルチエージェント環境での共有メモリのアクセス制御と信頼性モデルはどう構築するか？孤立ローカルメモリからの移行において、メモリの整合性・プライバシー・幻覚耐性をどう担保するかは未解決である。 - コンテキストエンジニアリング（外部設計者の視点）とエージェントメモリ（内部自律の視点）を統合するアーキテクチャ上の原則はあるか？両者の境界が曖昧になる場面（プロンプトでメモリを明示的に操作する場合など）の扱いが問われる。 - エージェントメモリの評価ベンチマーク（MemBench, LongMemEval 等）は、実際の長期エージェント性能とどの程度相関するか？短期評価から長期性能へのギャップはほとんど定量化されていない。 - OpsMem の signal coupling・pattern activation の閾値(いずれも 0.6)や 2 要因の重み(等重み)は、失敗診断以外のドメイン(コーディングエージェント、カスタマーサポート等)でも同じ値が有効か未検証。CMR の「トリガー条件付き再検索」という設計原則が、失敗診断以外の作業メモリ/経験メモリ結合パターンに一般化するかも未確認。(Source: [[@2026__arXiv__OpsMem - Dual-Memory Reasoning with Cross-Memory Resonance for Failure Diagnosis]]) - メモリを選択的に無効化すべきタスク種別(冪等な再計算タスク等)を自動判別する機構は設計可能か。ReAct のようなツール利用エージェントで、クエリごとにメモリの有効/無効を動的に切り替えるルーティング層は、Hu+ の形態-機能-動態タクソノミのどの段階に位置づけられるか。([[@2026__FSE Companion__LLM Agents for AIOps in Kubernetes - An Industrial Experience Report with Red Hat OpenShift]] §5.1) - ActionNex の KCA の監査可能性(人間が読める形式)は、記憶容量が拡大するにつれ検索精度・維持コストとどうトレードオフするか。AccelOpt の固定容量キュー(ExpN)のような定量的な容量設計は KCA テキスト表現にも適用できるか、あるいはテキスト表現ゆえの独自の忘却メカニズムが必要か。(Source: [[@2026__arXiv__ActionNex - A Virtual Outage Manager for Cloud Computing]]) ## 関連 - [[コンテキストエンジニアリング]], [[エージェント型強化学習]], [[仮説駆動RCA]], [[ReAct]], [[AIOps]], [[ベクトル検索インデックス]], [[LLMによるカーネル最適化]], [[次善アクション推薦]] - [[MemGPT]], [[Mem0]], [[OpsMem]], [[ActionNex]] - 関連 MOC: `structures/` に AIOps・システム ML 等の MOC が存在するが、エージェントメモリ専用 MOC は未作成 ## 出典 - [[@2025__arXiv__Memory in the Age of AI Agents]] — Yuyang Hu ほか 47 名（NUS・人民大学・復旦大学・北京大学・NTU ほか）、arXiv:2512.13564、2025-12-18 - [[@2026__arXiv__OpsMem - Dual-Memory Reasoning with Cross-Memory Resonance for Failure Diagnosis]] — Yongqian Sun ほか(Nankai University・Tsinghua University・Huawei Technologies)、arXiv:2607.11357、2026-07-13 - [[@2026__FSE Companion__LLM Agents for AIOps in Kubernetes - An Industrial Experience Report with Red Hat OpenShift]](§5.1 メモリの有無による正確性の比較) - [[@2025__arXiv__LEANN - A Low-Storage Vector Index]] — Yichuan Wang ほか(UC Berkeley・CUHK・Amazon Web Services・UC Davis)、arXiv:2506.08276、MLSys 2026 Oral - [[@2026__MLSys2026__AccelOpt - A Self-Improving LLM Agentic System for AI Accelerator Kernel Optimization]] — Genghan Zhang ほか(Stanford University・Amazon Web Services・University of Toronto)、arXiv:2511.15915、MLSys 2026 Oral - [[@2026__arXiv__ActionNex - A Virtual Outage Manager for Cloud Computing]] — Zhenfeng Lin ほか13名(Microsoft PRIMO / Microsoft Research / Microsoft Azure Core / Azure CTO Office)、arXiv:2604.03512、2026-04-03