【論文解説】A-MEM: エージェントに長期記憶を持たせる設計

会話ログを全部保存し、ベクトル検索で引けるようにすれば長期記憶になる。多くのエージェント実装は、この前提から出発します。A-MEM論文が指摘するのは、この前提がなぜ壊れるかです。必要なのは、過去のやり取りを「あとで検索できるログ」として残すことではなく、将来の判断に使える形へ再構成することです。保存量を増やしても、どの情報を残すべきか、何と何を結びつけるべきか、新しい事実が入ったときに古い理解をどう書き換えるかは、自動では解決しません。

私はこの論点を、以前「Self-Evolving AI Agents」を読んだときにも扱っています。そこで私は、エージェントの自動更新を許すのはExperience（記憶・振り返り）だけに絞り、Agent（プロンプト/ポリシー）とTool（実行アクション）の変更は人間承認に留めるべきだという立場を取りました。A-MEM（arXiv 2502.12110、2025年2月公開）は、そのExperience Evolutionの具体的な実装例に当たります。今回はその立場の根拠側、つまり「なぜ記憶というレイヤーは、書き込み時に構造を変えることで承認境界を作りやすいのか」を、A-MEMの設計を精読することで確かめます。

追記型の記憶運用、つまり古いメモを書き換えずに新しい気づきを後ろへ積み増していく方式には、私は懐疑的です。「Self-Evolving AI Agents」を扱った際にも述べた通り、記憶汚染、つまり誤った経験や一時的なノイズを長期知識として固定してしまうリスクは、事後にログを見返して気づける性質のものではなく、書き込み時にどう構造化するかという設計でしか防げないと考えています。追記型の運用は、この「書き込み時に構造を変える」という発想を持たないぶん、状況が変わっても古い記述がそのまま長期知識として居座り続けやすい、というのが私の見立てです。

“

関連記事: 本記事は「AIエージェント論文おすすめ11選」の詳細解説記事です。

前提: 2つの区別を先に固定する

論文の主張を追う前に、本記事で使う2つの言葉を定義します。定義があるからこそ、後の主張は「違う」と反証できるものになります。

経験記憶と正本知識: 正本知識とは、正しい版が別に管理されている情報です。製品仕様、料金表、契約条件、法令などが典型で、間違えれば「古い版を見た」という事故になります。経験記憶とは、やり取りの中で意味が後から変わる情報です。ある意思決定をした理由や、顧客が本当に優先している条件は、その場では正しくても、後続の事実によって解釈が変わります。この区別があるからこそ、「A-MEMはRAGの代替か」という問いは、「どちらの情報を扱っているか」という反証可能な形に変わります。

追記型と再解釈型: 追記型の記憶は、古い記憶を不変のまま残し、新しい記憶を後ろに足していく方式です。多くのメモリ実装やチャット履歴の保存は、これに当たります。再解釈型の記憶は、新しい経験が既存の記憶の文脈説明やタグまで書き換える方式です。A-MEMの新しさとリスクは、どちらもこの一語、再解釈型であることに由来します。

A-MEMの3操作: 追記型との差分

A-MEM（エージェンティックメモリ）概念図

論文の中核は、記憶を構造化ノートの集合として扱うことです。単なるチャットログの蓄積とは扱いが異なります。新しいやり取りが入るたびに、A-MEMは次の3段階を走らせます。

1. Note Construction: やり取りをノート化する
2. Link Generation: 既存ノートとの意味的なつながりを作る
3. Memory Evolution: 新しい経験を受けて既存ノートの表現も更新する

追記型の記憶なら、ここで終わりです。A-MEMが追記型と分かれるのは3番目のMemory Evolutionにあります。

Note Construction: 意味単位への変換

論文では、各インタラクションをLLMで処理し、複数の属性を持つノートへ変換します。含まれるのは、元の内容、タイムスタンプ、キーワード、タグ、文脈説明、他ノートとのリンクです。概念的には次のような形になります。

{
  "content": "顧客Aは価格よりも導入スピードを重視している",
  "timestamp": "2026-04-15T09:30:00Z",
  "keywords": ["顧客A", "導入スピード"],
  "tags": ["商談", "優先条件"],
  "context": "初回提案後のフォローアップ会話で判明した意思決定条件",
  "links": ["mem_021", "mem_087"]
}

重要なのは、ノートが再利用しやすい意味単位へと変換された表現だという点です。raw logをそのまま縮めた要約より情報の作られ方が異なり、後続のLink GenerationやMemory Evolutionが機能する土台になります。

Link Generation: 「似ている」から「たどれる」へ

次にA-MEMは、新しいノートと既存ノートのつながりを作ります。論文ではまず埋め込みで近い候補を取り出し、そのうえでLLMに、本当に関連があるか、どの属性が共通しているか、どんな関係として結びつけるべきかを判断させています。この段階があるため、記憶はあとでたどれる知識ネットワークとして機能します。

Memory Evolution: 過去の意味づけを書き換える

新しいノートを追加すると、関連する既存ノートの文脈説明・キーワード・タグも更新対象になります。新しい経験が、過去の経験の意味づけそのものを変える設計です。人間があとから「前の出来事は実はこういう意味だった」と理解を更新するのに近い動きだと考えると分かりやすいです。

概念コードで見る責務分解

以下は論文の考え方を実装の責務に分解した概念コードです。公式実装そのものではありません。

from dataclasses import dataclass, field
from datetime import datetime


@dataclass
class MemoryNote:
    content: str
    timestamp: datetime
    keywords: list[str]
    tags: list[str]
    context: str
    links: list[str] = field(default_factory=list)


class AgenticMemory:
    def __init__(self, llm, vector_index):
        self.llm = llm
        self.vector_index = vector_index
        self.notes: dict[str, MemoryNote] = {}

    def add_interaction(self, raw_text: str, ts: datetime) -> str:
        note = self._construct_note(raw_text, ts)
        related_ids = self._retrieve_neighbors(note)
        note.links = self._generate_links(note, related_ids)
        self._evolve_related_notes(note, related_ids)
        note_id = f"mem_{len(self.notes)}"
        self.notes[note_id] = note
        self.vector_index.upsert(note_id, self._serialize(note))
        return note_id

この設計で重要なのは検索ロジックよりも、書き込み時にノートをどう構造化し、どの範囲まで過去ノートを再解釈するかです。

評価の読み方: 何が言えて、何が言えないか

論文（arXiv 2502.12110）は、長期対話向けデータセットLoCoMoを使って評価しています。LoCoMoは平均約9Kトークンの会話、最大35セッション、合計7,512のQAペアで構成され、単発QAより長期記憶の扱いを見やすい構成になっています。論文は6つのfoundation modelに対して比較を行い、複数の指標で既存手法より改善したと報告しています。

アブレーションでは、Link GenerationとMemory Evolutionの両方を外した条件でも、Memory Evolutionだけを外した条件でも、性能が下がると報告されています。ここから読み取れるのは、書き込み後に記憶の構造が変わることがA-MEMの性能に効いている、という点です。ベンチマーク上の強さは、検索手段を足したことよりも、この構造変化に由来すると読めます。

一方で、この評価だけから言えないこともあります。評価はLoCoMoという長期対話ベンチマークに閉じており、CRMの商談管理、コーディングエージェント、法務や医療のような高監査領域で同じ改善が出るかは、この論文だけからは分かりません。「保存量を増やせば長期記憶になる」という前提が壊れることは論文から言えますが、「だからどの業務エージェントでも導入すべきだ」とまでは、この論文は主張していません。

RAGとの役割分担

従来のメモリ vs A-MEM比較

前提で置いた区別を使うと、RAGとA-MEMの役割分担は単純になります。RAGが引くのは正本知識、A-MEMが育てるのは経験記憶です。

営業支援エージェントであれば、製品仕様や料金表はRAGで引き、顧客ごとの優先条件や過去の懸念、稟議の経緯はA-MEM型の記憶に残す、という分担になります。全部を記憶に寄せると出典管理が崩れ、全部をRAGに寄せると長期文脈が死にます。「何を覚えるか」と「何を引くか」を分けることが、この役割分担の要です。

著者の立場: Memory Evolutionは価値の中心だが、無条件では有効化しない

私は、Memory Evolution、つまり新しい経験が過去の記憶の意味づけを書き換える設計こそが、A-MEMの価値の中心だと読んでいます。検索精度の向上はその副産物にすぎません。根拠は前節のアブレーション結果です。

ただし、この価値をそのまま法人業務のエージェントで有効化してよいとは考えていません。私は、Memory Evolutionを本番で有効にする前に、少なくとも次の3条件を満たすべきだという立場を取ります。

1. 元ログをimmutableに保つ: 元の発話と、あとから作った解釈を分離して残す
2. 派生ノートの更新履歴を持つ: いつ・何が・なぜ書き換わったかを追跡できるようにする
3. 自動更新してよい属性を限定する: タグや文脈説明の更新は自動に任せてよいが、意思決定の根拠のような属性は人手承認を挟む

Note Construction、Link Generation、Memory Evolutionは、いずれもインタラクションごとに追加のLLM呼び出しを伴います。単にプロンプトへ履歴を足す方式より、書き込みのレイテンシとコストは増えるはずです。頻繁に変わるが再利用価値の低い情報までノート化すると、この追加コストは割に合いません。

この境界線は、「Self-Evolving AI Agents」の論文を読んだときに私が取った立場、つまり自動更新はExperience（記憶）だけに許し、Agent（プロンプト/ポリシー）とTool（実行アクション）は人間承認に留めるべきだという立場と一致します（Self-Evolving AI Agents: 自己進化型エージェントの設計原則）。A-MEMは、その立場を裏付ける実装例だと私は読んでいます。ノート単位で閉じて更新できるという構造そのものが、承認境界を設計しやすくしている理由です。

なお、前節で触れた通り、この評価はLoCoMoという長期対話ベンチマークに閉じています。高監査領域でも同じ設計が有効かどうかは、まだ分かりません。

実装を覗くと何が起きているか

論文が直接リンクしているコードは2系統あります。WujiangXu/AgenticMemoryは評価実験の再現寄りで、論文の比較条件を追いたいときに向いています。agiresearch/A-memは、Agentic Memory systemとしてパッケージ化された実装で、READMEではChromaDBを使ったノート管理、リンク生成、進化処理の流れが説明されています。

両リポジトリのREADMEを突き合わせると、責務の切り方の違いが見えてきます。agiresearch/A-memはadd_note / read / update / delete / search_agenticという利用者向けAPIを公開しており、READMEは「メモリを追加・更新するたびに、ChromaDBによる意味的関連の発見、メタデータと文脈の更新、関連メモリ間のリンク生成が自動的に走る」と説明しています。つまりノート化の単位は呼び出し側がadd_noteに渡すコンテンツそのものであり、どこまでを1ノートにするかの判断はシステムではなく利用側に委ねられていることが、この説明から読み取れます。一方WujiangXu/AgenticMemoryは論文のLoCoMo評価を再現するためのコードで、--retrieve_kによって1クエリあたりの検索件数を変え、run_k_sweep.shでモデルごとに最適なkを探すという評価向けの構成になっています。ノート生成やリンクの「粒度」を実質的に左右するのは、A-memのAPI設計そのものよりも呼び出し側の入力単位である、というのが両READMEを読み比べたうえでの整理です。ここまではあくまで公開されているREADMEと評価コードの記述を突き合わせた読解であり、実際に動かして観察したノート生成・リンク生成の挙動ではありません。

本番導入を考えるなら、営業の継続商談、CSの長期サポート、PMの意思決定履歴のように、関係性が長く続き、正本が別に分かれている領域から試す方が失敗しにくいはずです。全社ナレッジ基盤のような巨大な領域は、後回しにする方が安全だと考えています。

結び: 何を再解釈させるかを先に決める

ここまでの整理から引き出せる、導入判断のためのレバーは1つです。会話や業務ログを保存する前に、まずその情報が正本知識か経験記憶かを分け、経験記憶については、タグや文脈説明のような表層属性から再解釈を許すのか、意思決定の理由のような核の属性まで自動更新させるのかを決めることです。この線引きこそが、Memory Evolutionを安全に使えるかどうかを分ける最初の判断だと私は考えています。

この判断は、「Self-Evolving AI Agents」で扱った承認境界の議論と地続きです。Agent（プロンプト/ポリシー）やTool（実行アクション）の自動更新にも、ロールバックと監査の経路が当たり前に付く日が来れば、記憶だけを特別扱いする理由は薄れます。今のところ、そこまでの環境は整っていないというのが私の見立てです。この見立ても、状況が変われば書き直します。

関連記事

• Self-Evolving AI Agents: 自己進化型エージェントの設計原則: 「自動更新を許すのはExperienceだけ」という承認境界の立場を扱った記事です。本記事はその根拠側、つまり記憶がノート単位で閉じているから境界を作りやすいという機構を掘り下げています。
• ReActとは？AIエージェントの基礎フレームワークを図解: ReActはエピソード内の接地（観察による推論の検証）を扱い、A-MEMはセッションを横断する記憶の書き込み側を扱います。エージェントが壊れる場所の、別の断面です。
• AIエージェント開発に役立つ一次文献11選: A-MEMを「保存量ではなく整理・検索・更新方針の問題」と位置づけたハブ記事です。本記事はその一行を、3操作とアブレーションのレベルまで展開しています。

“

AIエージェント論文おすすめ11選に戻る

参考リソース

• A-MEM arXiv論文
• A-MEM 評価コード（WujiangXu/AgenticMemory）
• A-MEM システム実装（agiresearch/A-mem）
• Lost in the Middle: How Language Models Use Long Contexts