なぜエージェントに「長期記憶」が必要なのか
ReAct 型の短命エージェントは1セッション完結で良かったが、2026年に主流となった「常駐エージェント」（パーソナルアシスタント、営業アシスタント、継続的コード改善ボット等）は、数週間〜数年スパンで文脈を保持する必要がある。コンテキストウィンドウが1Mトークンに拡大しても、それだけでは解決できない問題がある。第一にコスト（毎回全履歴を投入すると破産する）、第二に精度（無関係情報がノイズとなり推論品質が落ちる）、第三にプライバシー（長期に渡る個人情報を安全に管理する）だ。
解決策は「コンテキスト外の永続メモリ」を構造化し、必要な情報のみを毎回プロンプトに射影するアーキテクチャだ。ここでは4層モデルで整理する。作業記憶、エピソディック記憶、意味記憶（エンティティグラフ）、手続き記憶の4階層である。
エピソディックメモリ: ベクトルストアの実装
エピソディック記憶は「いつ何が起きたか」を時系列で保持する層で、pgvector または DuckDB + VSS 拡張で実装するのが2026年の定番だ。小規模（〜100万件）なら DuckDB が圧倒的に速く、単一プロセス内で完結する。中〜大規模では pgvector + HNSW インデックスを使う。
pgvector の実装例は以下のパターンが典型だ。`CREATE TABLE episodes (id uuid, user_id uuid, ts timestamptz, content text, embedding vector(1536), importance float)` というスキーマに、発話ごとにエンベディングを計算して挿入する。検索時は `SELECT * FROM episodes WHERE user_id = $1 ORDER BY embedding <=> $2 LIMIT 20` で意味類似検索し、さらに `importance * exp(-lambda * age)` のフォーゲッティング曲線でリランクする。
importance は LLM に「この発話は後で参照する価値があるか」を0〜1でスコアリングさせて付与する。これにより「コーヒー注文した」のような日常雑事は時間経過で自然消滅し、「年末に引越し予定」のような長期的事実は長く残る。
エンティティグラフ: KùzuDB と Neo4j
「誰がどこに住んでいる」「この会社の CEO は誰」のような意味記憶は、ベクトルストアではなくグラフDBで持つべきだ。KùzuDB は2025年にv0.5に到達し、ノートPCでも100M ノード規模を扱えるエンベッダブルなグラフDBとして定着した。Neo4j は分散運用やエンタープライズ機能が必要な大規模ケースで選ぶ。
エージェントは対話から `(entity1, relation, entity2)` のトリプルを抽出し、グラフに追記する。例えば「田中さんは新宿オフィスの PM」という発話から `(田中, role, PM)`、`(田中, works_at, 新宿オフィス)` を生成する。重要なのは「衝突解決」で、既存トリプルと矛盾する新情報が来た際、タイムスタンプで上書きするか、両方を保持して信頼度で重み付けするかを設計判断する。
本番環境では「エンティティ解決」（同一人物の異なる表記を束ねる）が最難関で、ベクトル類似度＋規則ベース（メールアドレス一致等）のハイブリッドが定石だ。
階層メモリ: MemGPT と Letta の思想
MemGPT（現Letta）はOSレベルの「ページング」概念をLLMに持ち込んだ画期的なフレームワークだ。高速アクセス層（コンテキスト内メモリ）と低速アクセス層（外部ストア）を明示的に分離し、エージェント自身が `page_in` / `page_out` ツールで情報を出し入れする。
実装的には `core_memory`（常駐）、`recall_memory`（過去会話全文）、`archival_memory`（任意のファクト）の3領域を持ち、それぞれに対する CRUD ツールをエージェントに提供する。エージェントは必要に応じて archival_memory を検索し、得た情報を core_memory に書き戻すことで、文脈を自己管理する。
これは「エージェントが自身のメモリを設計する」という発想で、従来の「開発者がRAGパイプラインを作り込む」アプローチとは根本的に異なる。エージェントの自律性は高まるが、メモリ操作に追加のトークンを消費するため、コスト設計を慎重に行う必要がある。
Anthropic Memory Tool: ビルトイン作業記憶
Anthropic は2025年末に「Memory Tool」をベータで公開し、2026年Q1に GA 化した。Claude がセッション間で永続化する小さなスクラッチパッドを提供するツールで、`memory_read`、`memory_write`、`memory_list` の3操作を持つ。
設計思想は明確で、「複雑な長期記憶は外部システムに任せ、Memory Tool は超短期の作業記憶に特化」する。例えば「前回の会話で決めた設定値」「現在処理中のタスクID」のような、セッション跨ぎの軽量状態の保持に向く。容量上限は1ユーザーあたり100KBと意図的に小さく、大量データの保存場所ではない。
Memory Tool は他の長期記憶スタック（pgvector、KùzuDB 等）と併用するのがベストプラクティスで、「すぐに思い出せる作業記憶」と「検索で取り出す長期記憶」という人間の記憶モデルに近い分業を実現する。
圧縮・忘却・プライバシー
長期稼働エージェントは必然的に情報が肥大化する。対策は3段階で、第一に「要約圧縮」：数百発話ごとに LLM で要約を作り、原文は archival にアーカイブ。第二に「忘却曲線」：アクセス頻度×経過時間で優先度を計算し、閾値以下を削除。第三に「プライバシー消去」：GDPR/個人情報保護法対応で、ユーザー要求時に特定ID配下のレコードを全削除。
最後の点は実装が難しい。ベクトルストアから消すだけでなく、それらから派生した要約・グラフ・キャッシュ全てを消す必要があり、`provenance`（出典）を全レコードに記録する設計が必須だ。KGAでは各レコードに `source_episode_ids` 配列を付与し、消去時にバックトラックできる構造にしている。
2026年の実装スタック推奨
小規模プロトタイプ → DuckDB + VSS + Anthropic Memory Tool。中規模本番 → pgvector + KùzuDB + Letta。大規模エンタープライズ → Postgres分散（Citus）+ Neo4j + 独自オーケストレータ。いずれの構成でも「何を覚え、何を忘れ、誰の要求で消すか」のポリシーを事前に明文化することが、技術選定以上に重要だ。