Elastic（Elasticsearch開発元）は、AIエージェントに本物の長期記憶を持たせるための永続メモリ層をElasticsearchで構築し、その設計思想と実装の詳細を公開した。168問のQA評価でR@10が平均0.89に達し、かつユーザー間のデータ漏洩ゼロを達成したこのアーキテクチャは、エージェント開発者が直面する「記憶問題」に対して実践的な解を示している。

コンテキストウィンドウは「記憶」ではない

多くのAIエージェント実装では、過去の会話履歴をそのままコンテキストウィンドウに詰め込む手法が採られている。しかしこのアプローチには3つの根本的な問題がある。

まずコスト——長い履歴はそのままトークンコストに直結する。次にレイテンシ——大量のコンテキストは推論速度を落とす。そして「中間消失（Lost in the Middle）」効果——研究で示されているように、モデルはプロンプトの端（冒頭・末尾）に近い情報は拾うが、中間に埋もれた情報は無視しがちだ。

100万トークンのコンテキストウィンドウは「作業メモ」であって「記憶」ではない。セッションをまたいで生き残り、年単位でスケールし、内容・時刻・ユーザーで検索できる永続ストアこそが本物の長期記憶だ、というのが本実装の出発点である。

3種類の記憶：認知科学からの借用

Elasticのチームは認知科学の知見（COALAフレームワーク）を参照し、記憶をエピソード・意味・手続きの3種類に分類。それぞれをElasticsearchの独立したインデックスにマッピングした。

エピソード記憶（Episodic Memory）: タイムスタンプ付きの生イベント。各ユーザーターンをそのまま蓄積する。短命なものが多く、後で重要な事実を抽出するための素材となる。

意味記憶（Semantic Memory）: ユーザーに関する安定した事実。「Sarah は Lumio Hub v2 を所有している」「Sarah の iOS バージョンは 17.4」のような蒸留済みのアサーション。セッションをまたいで永続し、エージェントが推論の根拠とする情報がここに入る。

手続き記憶（Procedural Memory）: 複数ステップのプレイブック。「Zigbee接続切断のトラブルシュート手順」のような、事実ではなくプロセスを保存する。

この分類の重要な点は、書き込み頻度とエイジング（鮮度の扱い）がタイプごとに異なることだ。単一の記憶モデルで混在させるとハイスタック化する。タイプ別管理により、検索精度と更新コストを両立させている。

ハイブリッド想起・上書き処理・ユーザー分離

想起クエリにはRRF（Reciprocal Rank Fusion）とクロスエンコーダー再ランカーを組み合わせたハイブリッド検索を採用している。ベクター検索によるセマンティックマッチと全文検索によるキーワードマッチを融合させ、どちらか一方に頼るより精度を高めている。

矛盾する事実が生じた場合は「削除」ではなく「上書き（Supersession）」で処理する。旧バージョンを残しつつステータスを変更するため、監査証跡が完全に保たれる。

マルチユーザー展開では、ElasticsearchのDLS（Document Level Security）をユーザーID単位で適用することでテナント間のデータ漏洩を防ぐ。168問の評価でクロステナント漏洩ゼロという結果は、本実装が単なるプロトタイプではないことを示している。

また、このメモリ層はMCP（Model Context Protocol）対応クライアントであれば何でも接続できる設計になっており、特定のエージェントフレームワークに依存しない。

実務への影響

日本のエンジニアにとって、このアーキテクチャが示す教訓はいくつかある。

「専用ベクターDBでなくてよい」という選択肢: Elasticsearch（またはOpenSearch）がすでに自社インフラにあるなら、それをエージェントメモリとして転用できる。新たなマネージドサービスを増やさずにアーキテクチャをシンプルに保てる点は、運用コストの観点からも現実的だ。

エイジングと鮮度管理の設計思想: 記憶が古くなれば重みを下げ、よく参照される記憶は沈まないようにする——時間とアクセス頻度に基づくスコアリングは、RAGシステム設計全般に応用できる考え方だ。

DLSによるマルチテナント分離: 企業向けSaaSやB2B SaaSを構築する際に即座に参考にできるパターンだ。エージェントが複数ユーザーの記憶を混同するリスクは、セキュリティインシデントとして深刻なものになりうる。

実装はGitHubで公開されており、Agent BuilderとしてElastic CloudでもGA（一般提供）済みだ。

筆者の見解

今回のElasticのアーキテクチャは、「エージェントに本物の記憶を持たせる」という課題に対して、認知科学の分類を実装レベルで具体化した点で評価できる。

私が特に注目するのは「上書き（Supersession）」と「エイジング」の組み合わせだ。記憶は単に保存するだけでは意味がない。矛盾を処理し、鮮度を管理し、重要度の下がった情報を静かに沈め、必要なものを浮かび上がらせる——この仕組みなしに、エージェントは長期間使うほど「ゴミ屋敷化」する。

エージェントが自律的にループで動き続ける「ハーネスループ」の設計においても、セッションをまたぐ文脈保持は最大のボトルネックのひとつだ。毎回コンテキストをゼロから渡し直すモデルでは、エージェントが真の意味で「学習する」ことができない。ループが本当に賢くなるには、今回のような永続記憶層が前提条件になる。

Elasticsearchをすでに使っていない環境では導入コストも無視できないが、「新しいベクターDBを追加するか、既存の検索インフラを転用するか」という問いに後者で答えられる可能性を示したことは実践的だ。3つのインデックス構造・ハイブリッド検索・DLSは、それぞれ単独では枯れた技術。組み合わせ方にこそノウハウがある。エージェントに「セッションをまたいだ文脈」を持たせたいすべての開発者に一読を勧めたい内容だ。

出典: この記事は We built a persistent agent memory layer on Elasticsearch with 0.89 recall の内容をもとに、筆者の見解を加えて独自に執筆したものです。