7月17日、Redisが「Best databases for AI agent memory: a 2026 comparison」と題した記事を公開した。Redis公式ブログによる比較記事であり、自社製品を含む4製品を評価している点は念頭に置く必要があるが、AIエージェントのメモリ要件を3層に分類して整理するフレームワーク自体は実用的だ。結論を先に示すと、「どれを使えばいいか」はエージェントが必要とするメモリ層の数で決まる。長期記憶だけで足りるユースケースならPineconeやWeaviateで完結するが、短期記憶・操作状態まで必要になった時点で複数DBの組み合わせか、Redisの単一構成かという選択に迫られる。
AIエージェントのメモリは「3層構造」である
記事の核心は冒頭のこの一文に集約される。
Agent memory isn't a single workload.
AIエージェントがデータ層に要求するアクセスパターンは、実は3種類に分かれる：
- 短期記憶（Short-term recall）：現在のセッションの作業コンテキスト。会話の履歴、ツールの実行結果、推論の中間状態がこれにあたる。エージェントループの各ステップで読み込まれるため、レイテンシが積み重なる
- 長期記憶（Long-term retrieval）：セッションをまたいで永続化される知識。ベクトル埋め込みとして保存され、意味的類似度で検索される
- 操作状態（Operational state）：タスクキュー、ロック、レート制限、サブエージェント間の協調処理など。ベクトル検索ではなく、構造化された操作が必要
この3層を1つのデータベースでカバーできるかどうかが、各製品の評価軸となる。多くのチームはベクトルDBを選んだ後に「短期記憶用のキャッシュ」と「状態管理用のDBが別途必要だ」と気づき、3システムの同期・障害管理・レイテンシという追加コストを負うことになる。
4製品の比較：カバー範囲が全て違う
Redis：3層すべてをカバー
Redisはデータをすべてオンメモリで保持するため、読み書きがサブミリ秒で完了する。短期記憶はハッシュやソート済みセットで、操作状態はStreamsで、サブエージェント間の協調はPub/Subで処理できる。
長期記憶はRedis Query Engineが担い、HNSW・FLAT・SVS-VAMANAの3種のベクトルインデックスをサポート。10億ベクトルのベンチマークでは、50並列クエリ時に中央値約200msで90%の精度を達成したと報告されている。
現在パブリックプレビュー中の**Redis Agent Memory**は、セッションメモリと長期メモリの2層をマネージドサービスとして提供する。会話イベントがセッションメモリに書き込まれると、バックグラウンドで重要情報を抽出して自動的に長期メモリに昇格させる。TTLはメモリ種別ごとに設定可能で、作業コンテキストは数分で失効し、ユーザー設定は長期間保持できる。
コスト面では、Redis LangCache（セマンティックキャッシング）によりLLM推論コストをベンチマーク上で最大73%削減したとされる。またRedis FlexでRAMとSSDを組み合わせることで、ストレージコストを最大80%削減できる。
Pinecone：長期記憶に特化、それ以外は別システムが必要
フルマネージドのベクトルDBとして、長期記憶のセマンティック検索は完結している。ネームスペースによるエージェント・テナントごとの分離、メタデータフィルタリングもサポート。ただしセッション状態やキュー・ロックといった操作状態の機能は持たない。Pineconeだけでエージェントを構築すると「過去に学習したことは思い出せるが、今自分が何をしているかはわからない」状態になる。
MongoDB：ドキュメント管理に強いが速度に限界
会話ログやツール呼び出しのメタデータはJSONドキュメントとして自然にマッピングできる。$rankFusionによるハイブリッド検索も追加された。ただしデータはディスクに保存されるため、エージェントループの各ステップでデータ層を叩くユースケースではレイテンシが積み重なる。コンプライアンス要件のある会話履歴アーカイブには適しているが、結局キャッシュを前段に置くことになる。
Weaviate：オープンソースのベクトルDB、運用はセルフ
ベクトル検索にキーワードマッチとメタデータフィルタリングを組み合わせたハイブリッド検索が特徴で、エラーコードや製品名など固有名詞を含む検索に強い。埋め込み生成のモジュールも内蔵している。ただし操作状態レイヤーがなく、Pineconeと同様にキャッシュと状態管理ストアを別途用意する必要がある。
比較表
| 機能 | Redis | Pinecone | MongoDB | Weaviate |
|---|---|---|---|---|
| ベクトル検索 | ✓ (HNSW, FLAT, SVS-VAMANA) | ✓ | ✓ | ✓ |
| ハイブリッド検索 | ✓ | ✓ | ✓ ($rankFusion) | ✓ |
| セッション・作業メモリ | ✓ (オンメモリ) | ✗ | ドキュメントベース | ✗ |
| 操作状態（キュー・ロック等） | ✓ (ネイティブ) | ✗ | 限定的 | ✗ |
| リアルタイム協調 | ✓ (Pub/Sub, Streams) | ✗ | Change Streams | ✗ |
| マネージドエージェントメモリ | ✓ (Redis Agent Memory) | ✗ | ✗ | ✗ |
| セマンティックキャッシング | ✓ (LangCache) | ✗ | ✗ | ✗ |
既存のRedisユーザーには追加コストが低い
記事が指摘する実践的なポイントとして、「これらを評価している多くのチームはすでにキャッシュやセッション管理でRedisを稼働させている」という点がある。その場合、新たなデータベースを立ち上げるのではなく、既存のRedisインスタンスに新機能を追加するだけでエージェントメモリの基盤が整う。
LangChain・LangGraphを含む30以上のエージェントフレームワークとの統合と、Redisコマンドを意識せずに使えるPythonクライアント**RedisVL**も提供されている。
まとめ：ユースケース別の選定指針
この比較をユースケース別に整理すると、判断軸が明確になる。
- RAGパイプラインや知識ベース検索のみ：セッション状態を持たない静的な検索用途であれば、PineconeやWeaviateで十分に完結する
- マルチターン会話エージェント：セッションをまたぐ記憶と会話履歴の永続化が必要になる。MongoDBは履歴アーカイブに向くが、応答速度が求められるループ処理には前段キャッシュが別途必要になる
- マルチエージェント・タスク分散型の構成：キュー・ロック・サブエージェント間協調など操作状態レイヤーが必須となり、この要件が加わった時点でRedis以外の単一構成では対応できなくなる
記事の主張を一言で言えば、「必要なメモリ層が増えるほど、Redisの単一構成という選択肢の合理性が高まる」ということだ。ただし繰り返しになるが、本記事はRedis公式ブログの掲載であり、Pinecone・MongoDB・Weaviateの最新動向については各公式ドキュメントも合わせて確認することを推奨する。
詳細はBest databases for AI agent memory: a 2026 comparisonを参照していただきたい。
