6月21日、MarkTechPostが「The 7 Types of Agent Memory: A Technical Guide for AI Engineers」と題した記事を公開した。この記事では、AIエージェントが持つメモリの7つの分類と、それぞれの実装指針について詳しく紹介されている。
LLMはデフォルトでステートレスである
LLMはAPIを呼ぶたびに状態をリセットする。単発の質問応答ならそれで十分だが、複数ステップにまたがるエージェントを構築する瞬間に破綻する。エージェントは計画し、ツールを呼び出し、複数ターンにわたって動作する。その基盤となるのがメモリだ。
メモリには2つの軸がある。形式（パラメトリック／非パラメトリック）と時間（短期／長期）だ。7つの分類はこの2軸に対応する。この分類体系は、Princetonが公開したCoALAフレームワーク（arXiv:2309.02427）に理論的な根拠を置いている。CoALAはエージェントの認知アーキテクチャを体系化した論文であり、メモリをストレージの種類・格納内容・アクセス方式で整理している。以下の7種類はその枠組みに沿って構成されている。
7種類のメモリ分類
1. In-Context / Working Memory（短期）
モデルが現在参照できるコンテキストウィンドウ内の情報すべて。システムプロンプト、直近のメッセージ、ツール出力、推論ステップが含まれる。いわばRAMだ。高速で不可欠だが、容量に上限があり一時的である。他の6種類のメモリは、すべてこのワーキングメモリの空きスペースを奪い合う関係にある。CoALAの枠組みではここが「作業領域（working storage）」に相当し、長期メモリの内容を引き込んで推論を実行する場となる。
2. Semantic Memory（長期）
ユーザーの好みやドメイン知識など、永続的なファクトを格納する。「ユーザーはJavaScriptよりPythonを好む」のようなエントリが典型例だ。いつ学習したかとは切り離された、エージェントの「百科事典」に相当する。実装はベクターDBやプロファイルスキーマが一般的である。CoALAではこれを「宣言的長期メモリ」の一形態と位置づけており、エピソード記憶と合わせて外部ストアで管理するパターンが推奨されている。
3. Episodic Memory（長期）
過去の会話や作業ログを記録する。何がうまくいき、何が失敗したかを蓄積する。ReflexionやExpeLといったシステムは、事後評価（post-mortem）を言語化して保存し、次回の推論に活かす設計を採用している。エージェントが「経験から学ぶ」ための仕組みだ。CoALAの観点では、エピソードメモリは宣言的メモリのもう一方の柱であり、セマンティックメモリと同じ外部ストアに共存させつつ、検索時にメタデータで区別するアプローチが典型的な実装となる。
4. Procedural Memory（長期）
スキル、ツールの使い方、ワークフロー、行動ルールを格納する。パスワードリセット対応を100回こなしたサポートエージェントは、毎回ゼロから推論しない。学習済みの手順を実行するだけだ。システムプロンプトへの記述やファインチューニングで実現する。CoALAではこれを「手続き的長期メモリ」と呼び、エージェントのアクション選択ポリシーそのものを形成するものとして他の種別と区別している。
5. External / Retrieval Memory（短期＋長期）
ベクターDB上に置かれた外部知識を、推論時に類似検索で引き込む。いわゆるRAGをエージェント履歴や文書に適用したものだ。検索品質がボトルネックになりやすい点に注意が必要である。
6. Parametric Memory（長期）
モデルの重みに焼き込まれた知識。言語、推論パターン、一般的な世界知識がここに該当する。何も検索せず、学習済みの関連から生成する。トレードオフは明確で、このメモリはトレーニング時点で凍結される。CoALAにおいてもパラメトリックメモリはエージェントが直接編集できない領域として扱われており、更新にはファインチューニングという高コストな手段が必要になる。
7. Prospective Memory（短期＋長期）
エージェントが「将来やるべきこと」を記憶する仕組みだ。計画済みだがまだ実行していない意図を追跡する。長期・多段階の計画を扱うエージェントにとって不可欠であり、これがなければエージェントは自分のコミットメントを忘れる。タスクキューやスケジューラーで実装する。
比較表
| メモリ種別 | 時間軸 | 格納場所 | 格納内容 | 代表的な実装 |
|---|---|---|---|---|
| Working / In-context | 短期 | コンテキストウィンドウ | プロンプト・メッセージ・ツール出力 | LLMネイティブ |
| Semantic | 長期 | 外部ストア | ファクト・好み・ドメイン知識 | ベクターDB・プロファイルスキーマ |
| Episodic | 長期 | 外部ストア | 過去イベント・タスク結果 | ベクターDB＋イベントログ |
| Procedural | 長期 | プロンプト or 重み | スキル・ワークフロー・行動ルール | システムプロンプト・ファインチューニング |
| Retrieval / External | 両方 | ベクターDB | 文書・履歴チャンク | RAGパイプライン |
| Parametric | 長期 | モデル重み | 世界知識・言語・推論 | 事前学習・ファインチューニング |
| Prospective | 両方 | ステートストア | 将来の意図・スケジュール目標 | タスクキュー・スケジューラー |
最小構成のPython実装
記事はPythonによるスケッチも示している。ワーキング・セマンティック・エピソード・プロシージャルの4種を別々のストアとして表現した最小実装だ。
from datetime import datetime
# Semantic memory: ユーザーに関する永続ファクト
semantic_memory = {"diet": "vegetarian", "language_pref": "Python"}
# Episodic memory: 過去イベントと結果のログ
episodic_memory = [
{"timestamp": datetime.now(),
"event": "recipe_request",
"result": "user liked a 20-minute meal"},
]
# Procedural memory: エージェントが実行できるスキル
def suggest_recipe(diet):
return f"a quick {diet} recipe"
procedural_memory = {"suggest_recipe": suggest_recipe}
# Working memory: 推論呼び出しのたびに組み立てる
def build_context(query):
diet = semantic_memory["diet"]
last = episodic_memory[-1]["result"]
skill = procedural_memory["suggest_recipe"]
return (
f"Query: {query}\n"
f"Semantic: user is {diet}\n"
f"Episodic: last time, {last}\n"
f"Procedural: returning {skill(diet)}"
)
print(build_context("suggest dinner"))
本番環境では長期ストアをベクターDBに移行する。パターン自体は同じで、「長期メモリに書き込み → ワーキングメモリに引き込む → 推論する」というサイクルになる。実装の参考として、記事はLangChainのLangMem、MongoDB、Redis、Neo4jといったエージェントメモリ関連のドキュメントも参照先として挙げている。
実際の導入順序
記事は7種類を一度に構築することを勧めていない。必要性が生じてから追加するという段階的な指針を示している。
- まずワーキングメモリ。モデル標準装備。単純なエージェントはこれだけで足りる。
- セッションをまたいだ記憶が必要になったらセマンティックメモリを追加する。多くのプロダクトが最初に必要とする長期レイヤーだ。
- エピソード・プロシージャル・プロスペクティブは、前もって計画し、失敗から学び、適応する必要が出てきてから導入する。
- パラメトリックメモリはベースモデルそのものであり、リトリーバルメモリはRAGを追加した時点で既に存在している。
この順序はCoALAが示す認知アーキテクチャの優先度とも整合しており、ワーキングメモリを中心に据えて外部の長期ストアを段階的に接続していくという考え方に基づいている。関連するサーベイ論文（arXiv:2512.13564、arXiv:2504.15965）も同様の段階的設計を支持している。
詳細はThe 7 Types of Agent Memory: A Technical Guide for AI Engineersを参照していただきたい。
