6月18日、RedisのJim Allen Wallaceが「AI Agent Memory vs Retrieval: Why You Need Both」と題した記事を公開した。AIエージェントにおける「検索（Retrieval）」と「メモリ（Memory）」の役割の違いと、両方が必要な理由について詳しく解説している。
「片方だけ」が引き起こす失敗
記事の冒頭に挙げられている例が端的だ。
ユーザーが「今月の請求額が倍になったのはなぜか」とエージェントに問い合わせる。エージェントはユーザーの名前を把握し、先週の請求トラブルも参照できる。しかし、3ヶ月前に廃止された料金プランを自信満々に案内する。
これはモデルの失敗ではない。コンテキスト層の設計ミスだ。エージェントはユーザーの過去を「記憶」していたが、現在の料金体系に関する「知識」が古かった。
多くのチームが陥るのは、ベクトルデータベースによる検索（RAG）だけを実装して「これで十分」と思ってしまうパターンだ。しかし検索とメモリは別の問題を解く。
検索（Retrieval）とメモリ（Memory）の違い
検索はステートレスなルックアップだ。RAG（Retrieval-Augmented Generation）パイプラインでは、クエリをベクトル埋め込みに変換し、事前にインデックス化されたコーパスと照合して関連チャンクを返す。セッション情報もユーザー識別情報も書き込まれない。「このドキュメントには何が書いてあるか」には強いが、「5分前に何が起きたか」は一切知らない。
メモリはステートフルな状態管理だ。インタラクションの履歴から構築され、セッションをまたいで更新・集約・書き換えられる。記事では以下のように整理されている：
- 短期メモリ（Short-term memory）: 1セッション中の作業文脈。コンテキストウィンドウがリセットされると消える
- 長期メモリ（Long-term memory）: セッションをまたいで永続化。さらに以下の3種に分類される：
- エピソードメモリ: 過去のサポート対応履歴など、「何が起きたか」の記録
- セマンティックメモリ: 顧客プロファイルや製品仕様など、文脈によらない事実
- プロシージャルメモリ: コードフォーマットのルールなど、「どうやるか」の知識
なぜ両方を同時に使う必要があるのか
本番環境のエージェントは1ターンの中で「データに何が書いてあるか」と「このユーザーの過去は何か」の両方に答える必要がある。どちらかが欠けると：
- メモリなし → 毎回自己紹介するエージェント（知識はあるが文脈を忘れる）
- 検索なし → 名前は覚えているが口座残高を捏造するエージェント（親しみやすいが不正確）
依存関係はさらに深い。Agentic RAGにおけるクエリ書き換えは、モデルがユーザーの質問を検索しやすい形に言い換えるステップだが、この書き換え自体がセッションの文脈＝メモリを参照して行われる。たとえば「さっきの件はどうなった？」という曖昧な質問を「先週発生した請求エラーの対応状況」のような検索可能な形に変換するには、直前のやりとりや過去の対応履歴が参照できなければならない。メモリがなければ書き換えの質が下がり、結果として検索精度も落ちる。メモリが検索を支え、検索がメモリを補正するという相互依存関係がある。
2システム構成が引き起こす本番の問題
「ではベクトルDBとメモリサービスを別々に用意すればいい」という発想は自然だが、その「継ぎ目」が問題を生む。
レイテンシの積み上がり: 埋め込み生成・ベクトル検索・リランキングと処理が連なる中、外部ベクトルストアへのネットワーク往復は50〜300msのオーバーヘッドを加えることがある。音声エージェントのように厳しいレイテンシ予算を持つシステムでは致命的だ。
サイレントなフレッシュネスドリフト: ベクトル類似度は「鮮度」を表現しない。6ヶ月前と今日の埋め込みは、内容が似ていれば同等にマッチする。記事では実際のインシデントが紹介されている。あるエージェントはドキュメントが3日間更新されていないにもかかわらず、サポートチケット40件を誤回答で自動クローズした。モデルは正しく推論していた。壊れていたのはコンテキストだった。
デュアルライト問題: 2つのストアに同じ更新を一貫して書き込むことは難しく、一方だけ成功した場合に検索ストアとメモリストアが静かに食い違った状態になる。
これらの問題が重なると、「コンテキスト汚染」「コンテキスト混乱」「コンテキスト衝突」といった形でエージェントの動作に現れ、記事はこれを「コンテキストロット（context rot）」と呼んでいる。トークン数が技術的な上限に達していなくても、実効的な想起能力が劣化していく現象だ。
Redisの回答：コンテキスト層の統合
記事の後半はRedisの宣伝色が強まるが、主張は整理されている。検索とメモリを1つのストアに統合することでネットワーク往復・フレッシュネス管理・デュアルライト問題をまとめて解消するというアプローチだ。
Redisが発表したRedis Irisは、ベクトル検索・セマンティックキャッシング・短期／長期メモリを1エンジンに統合した「リアルタイムコンテキストエンジン」と位置付けられている。記事公開時点での提供状況（GAかプレビューか）については元記事に明示がなく、導入を検討する場合はRedis公式サイトで最新の提供状況を確認することを推奨する。既存のキャッシュやセッション管理でRedisを使っているチームにとっては、既存インフラの延長線上に置ける点がメリットとして挙げられている。
まとめ
検索（RAG）はスタートラインとして手軽に実装できるが、「ユーザーとの文脈を積み上げる」という問題は別の設計が必要だ。本番エージェントで「なぜか支離滅裂な回答が出る」「過去のやりとりを無視する」「古い情報を自信を持って話す」といった症状が出ているなら、コンテキスト層の設計を見直す価値がある。
詳細はAI Agent Memory vs Retrieval: Why You Need Bothを参照していただきたい。
