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

長い会話や複数セッションをまたぐ AI エージェントでは、単にコンテキストウィンドウを広げるだけでは足りません。必要なのは、過去のやり取りを「あとで検索できるログ」として残すことではなく、将来の判断に使える形へ再構成することです。

A-MEM は、そのための設計を提案した論文です。Zettelkasten の発想を取り入れ、各やり取りをノート化し、関連する記憶どうしをリンクし、新しい経験が入るたびに古い記憶の表現まで更新します。

本記事では、引用数や「最新エコシステム」のランキングではなく、A-MEM 論文そのものが何を提案し、どこが実務で再利用しやすいのかに絞って整理します。

“

関連記事: 本記事は「AIエージェント論文おすすめ11選」の詳細解説記事です。他の論文も合わせてご覧ください。

この記事でわかること

1. A-MEM が解こうとしている問題: 長期対話で、なぜ「保存」だけでは足りないのか
2. 論文の中核設計: Note Construction / Link Generation / Memory Evolution の役割
3. RAG との違い: 静的知識の検索と、エージェントの経験記憶をどう分けるか
4. 実装時の見どころ: どこから試し、どこにガードレールを置くべきか

基本情報

なぜエージェントに「記憶」が必要なのか

長いコンテキストと長期記憶は同じではない

長いコンテキストを扱えるモデルが増えても、それだけで長期対話の問題が解けるわけではありません。A-MEM 論文が立脚しているのは、エージェントは過去のやり取りをそのまま抱え込むのではなく、再利用しやすい単位に整理し直す必要があるという考え方です。

背景としてよく参照されるのが、長い入力の中ほどにある情報が扱いにくくなる Lost in the Middle 問題です。モデルが長文を読めても、

• どの情報を残すべきか
• 何と何を関連づけるべきか
• 新しい事実が入ったときに古い理解をどう更新するか

までは自動では解けません。

A-MEM が批判しているのは「固定されたメモリ操作」

論文の問題設定は明確です。従来のメモリ層は、

• どのタイミングで保存するか
• どの形式で保存するか
• いつ検索するか
• どの構造で関連づけるか

を開発者が先に決め打ちしがちでした。

このやり方は、FAQ 検索や会話ログ保管には有効です。ただし、長期プロジェクトの意思決定履歴、ユーザー嗜好、複数セッションをまたぐ関係性のように、あとから意味づけが変わる情報には弱いです。

向いているのは「経験があとから意味を持つ」タスク

A-MEM 的な記憶設計が効きやすいのは、たとえば次のような場面です。

• 顧客対応で、以前の要望や不満点を会話の文脈ごと覚えておきたい
• プロジェクト支援で、過去の意思決定とその理由をあとから参照したい
• パーソナルアシスタントで、ユーザーの好みを単なる属性ではなく行動履歴として扱いたい

逆に、製品マニュアルや法令のような正本が別にある静的知識は、まず RAG で扱う方が自然です。

A-MEM の仕組みを図解で理解

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

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

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

1. Note Construction

論文では、各インタラクションを原文のまま保存するだけでなく、LLM を使って複数の属性を持つノートへ変換します。主に含まれるのは次の要素です。

• 元の内容
• タイムスタンプ
• キーワード
• タグ
• 文脈説明
• 他ノートとのリンク

概念的には、以下のような形です。

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

重要なのは、ノートが raw log より情報量の少ない要約ではなく、再利用しやすい意味単位へ変換された表現である点です。

2. Link Generation

次に A-MEM は、新しいノートと既存ノートのつながりを作ります。論文ではまず埋め込みで近い候補を取り出し、そのうえで LLM に

• 本当に関連があるか
• どの属性が共通しているか
• どんな関係として結びつけるべきか

を見させています。

この段階があるため、記憶は単なる「似ている文章の一覧」ではなく、あとでたどれる知識ネットワークになります。

3. Memory Evolution

A-MEM がいちばん特徴的なのはここです。新しいノートを追加したら終わりではなく、関連する既存ノートの

• 文脈説明
• キーワード
• タグ

も更新対象になります。

つまり、「古い記憶は不変で、新しい記憶だけ後ろに足す」という append-only 型ではありません。新しい経験が、過去の経験の意味づけそのものを変える設計です。

この考え方は、人間があとから「前の出来事は実はこういう意味だった」と理解を更新するのに近いです。

概念コードで見るとこうなる

以下は、論文の考え方を実装の責務に分解した概念コードです。

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

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

RAG との違い

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

RAG と A-MEM は競合というより役割分担が異なります。

実務では併用が自然

たとえば営業支援エージェントなら、

• RAG: 製品仕様、料金表、契約条件を引く
• A-MEM 型記憶: 顧客ごとの優先条件、過去の懸念、稟議の経緯を残す

という分担が自然です。

重要なのは、「何を覚えるか」と「何を引くか」を分けることです。全部をメモリに寄せると出典管理が崩れ、全部を RAG に寄せると長期文脈が死にます。

論文ではどう評価したのか

評価設定

A-MEM 論文は、長期対話向けデータセット LoCoMo を用いて評価しています。論文によると LoCoMo は、

• 平均約 9K トークンの長い会話
• 最大 35 セッション
• 合計 7,512 の QA ペア

を含み、単発 QA よりも長期記憶の扱いを見やすい構成になっています。

また、論文は 6 つの foundation model に対して比較を行い、複数の指標で既存手法より改善したと報告しています。

この論文から読み取れるポイント

論文を読むうえで重要なのは、単一の派手な数値より次の 3 点です。

1. A-MEM は会話長よりも記憶操作を改善している
2. Link Generation と Memory Evolution の両方が効いている
3. 評価対象は長期会話であり、すべての業務エージェントにそのまま一般化できるとは限らない

特にアブレーションでは、リンク生成と記憶進化を外すと性能が落ちます。つまり、A-MEM の価値は「ベクトル検索を付けた」ことではなく、書き込み後に記憶構造が変わることにあります。

読むときの注意

一方で、この結果だけで「どの SaaS エージェントでもすぐ 2 倍強くなる」とは言えません。論文の評価は主に長期会話ベンチマークであり、

• CRM の商談管理
• コーディングエージェント
• 法務や医療のような高監査領域

では、別の評価軸が必要です。

実装に落とすときの見方

まず見るべき公式リソース

論文が直接リンクしているコードは 2 系統あります。

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

実装責務は 3 つに分けて考える

本番導入を考えるなら、A-MEM のアイデアは次の 3 つの責務に分解すると扱いやすいです。

1. Note Construction

どのイベントを記憶対象にするかを決めます。すべての会話を保存するのではなく、

• 意思決定
• ユーザー嗜好
• 例外処理
• 後続タスクに影響する事実

のような「あとで効く情報」だけをノート化するのが現実的です。

2. Link Generation

近いノートを集めるだけでは不十分です。リンクの粒度を決める必要があります。

• 同じ顧客に関する記憶なのか
• 同じ問題パターンなのか
• 因果関係なのか
• 時系列上の連続性なのか

ここを曖昧にすると、検索結果は増えても「使える記憶」になりません。

3. Memory Evolution

過去ノートを書き換える機能は強力ですが、同時に危険でもあります。特に実務では、

• 元ログを immutable に残す
• 派生ノートの更新履歴を持つ
• 自動更新してよい属性と、人手承認が必要な属性を分ける

という設計が重要です。

まずは狭い業務領域で試す

A-MEM は全社ナレッジ基盤のような巨大領域より、

• 営業の継続商談
• CS の長期サポート
• PM の意思決定履歴

のように、関係性が長く続き、かつ正本が別に分かれている領域から入る方が失敗しにくいです。

実運用で見るべき注意点

1. 監査のために raw log は別保管にする

A-MEM 型の記憶は、あとから文脈説明やタグが更新されます。これは便利ですが、監査上は「元の発話」と「後から作った解釈」を分けて残す必要があります。

2. 記憶の書き込みコストを見積もる

Note Construction、Link Generation、Memory Evolution はすべて追加処理です。単に prompt に履歴を足す方式より、書き込みコストとレイテンシが増えます。

したがって、頻繁に変わるが再利用価値の低い情報までノート化すると割に合いません。

3. 忘却ルールを業務側で決める

論文は「進化する記憶」を示していますが、何をいつ忘れるかはユースケース依存です。

• 一時的な作業メモ
• 長期保持すべき顧客特性
• 期限付きのプロジェクト事情

を同じ扱いにすると、記憶層がすぐ濁ります。

4. 正本知識は RAG に残す

製品仕様、料金、契約条件、法令などは、記憶層ではなく current docs 側を引くべきです。A-MEM は「経験の整理」には強いですが、正本の置き換えには向いていません。

FAQ

Q1. A-MEM は RAG の上位互換ですか？

いいえ。A-MEM は、静的文書検索の代わりではありません。RAG が得意なのは「正本がある知識を引くこと」、A-MEM が得意なのは「経験を記憶として育てること」です。

Q2. どんなタスクに向いていますか？

複数セッションをまたぎ、以前のやり取りの意味があとから変わるタスクに向いています。営業、CS、秘書、長期プロジェクト支援などが典型です。

Q3. 実装は公開されていますか？

はい。論文からは WujiangXu/AgenticMemory と agiresearch/A-mem が案内されています。前者は評価再現、後者はメモリシステム実装を見るのに向いています。

Q4. 既存のエージェントに後付けできますか？

可能です。ただし、単にベクトル DB を足すだけでは A-MEM にはなりません。最低でも

• ノート化
• リンク生成
• 既存ノートの進化

の 3 責務をどこで持つかを決める必要があります。

Q5. 導入前に何を評価すべきですか？

少なくとも次を見てください。

• 長期文脈が本当に成果に効くか
• 記憶更新の誤りを検知できるか
• 元ログと派生ノートを分離保存できるか
• RAG と役割分担できているか

まとめ

A-MEM の新しさは、「履歴を保存する」ことではなく、履歴をノートとして再構成し、関連づけ、あとから進化させることにあります。

主要ポイント

1. A-MEM は記憶の書き込み側を重視する
2. RAG と競合するのではなく、経験記憶を補完する
3. 論文の価値は派手なランキングではなく、Note / Link / Evolution という設計分解にある
4. 実務では raw log 保持、更新履歴、忘却ルールが重要になる

次のステップ

• まずは論文と公式リポジトリで、Note Construction / Link Generation / Memory Evolution の責務を確認する
• 自社エージェントでは、営業や CS など長期文脈が効く狭い領域から試す
• 正本知識は RAG、経験記憶は A-MEM 型という役割分担で設計する

次に読むべき論文

参考リソース

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

本記事はネクサフローの AI 研究シリーズの一部です。