10月2日、Google Cloudが「Implementing long-term AI agent memory in AlloyDB and Memorystore」と題した記事を公開した。45ターンの会話でプロンプトサイズが74万7,033トークンに膨れ上がり、レスポンスに33秒超を要する——これがコンテキストスタッフィングの現実だ。AlloyDB AIとMemorystore for Valkeyを組み合わせた2層メモリアーキテクチャはこの問題をどう解決するか。記事では設計思想からベンチマーク数値、実装コードまでを詳述している。

なぜAIエージェントに「長期メモリ」が必要なのか

LLMはセッションをまたぐと状態を保持しない。ユーザーが数日後にエージェントへ戻ってきたとき、モデルは空のコンテキストウィンドウから再スタートする。これを回避するためによく使われる手法が「コンテキストスタッフィング」——過去の会話履歴やツール実行ログをプロンプトに詰め込む方法だ。

しかし、この手法は規模が大きくなると破綻する。記事のベンチマーク結果では、45ターン以上の会話でコンテキストスタッフィングを用いた場合、45ターン目のプロンプトサイズが74万7,033トークンに達し、レスポンスに33.5秒かかっている。さらに、"lost in the middle"と呼ばれる現象——プロンプト中央付近の重要な指示をモデルが見落とす問題——も発生する。

ローリングサマリー（古いメッセージをLLMに要約させる手法）も代替策として使われるが、圧縮を繰り返すたびに細かい制約が削ぎ落とされ、数ターン後にはエージェントが設定済みの条件を静かに破るという問題が起きる。

2層メモリアーキテクチャの設計

Google Cloudが提案するのは、短期バッファと長期永続メモリを分離する2層構成だ。

Memorystore for Valkeyは2024年にRedisがライセンスを変更した際にGoogle CloudがValkey（Redisのオープンソースフォーク）をベースに提供を開始したインメモリキャッシュサービスだ。サブミリ秒の応答速度が必要な短期バッファを担い、AlloyDB AIはトランザクション整合性と複合ベクトル検索が必要な長期メモリを担う。

短期セッションデータをリレーショナルDBに直接書くことも技術的には可能だが、毎ターン発生する高頻度の書き込みはwrite amplificationとテーブルの肥大化を招く。インメモリキャッシュを前段に置くことで、AlloyDBは本来の役割——トランザクション一貫性、ベクトル検索、長期的な分析クエリ——に集中できる。

ベンチマーク：コンテキストスタッフィングとの比較

45ターン以上・大量ツール実行を伴う開発ダイアログでの内部ベンチマーク結果は以下の通りだ。

プロンプトサイズが会話ターン数に比例して膨らむコスト構造から脱却し、一定範囲内に抑えられることが最大のポイントだ。

AlloyDB AIの技術的な実装ポイント

これだけの改善が実現できる背景には、AlloyDB AIがDBエンジン内部にAI処理を取り込んでいることがある。アプリケーション層とDBの間のラウンドトリップを削減し、埋め込み生成・検索・LLM呼び出しをSQLトランザクションと同一文脈で実行できる点が核心だ。

自動ベクトル埋め込み（ai.initialize_embeddings）

AlloyDBはテキストカラムに対してLLMサービスと連携した自動ベクトル生成を行い、毎秒最大3,000件の埋め込みを生成できる。incremental_refresh_mode => 'transactional'を指定すると、ソースデータが変更された同一トランザクション内でベクトルを更新する。外部スケジューラや独自パイプラインが不要になる。

なお、記事中では連携先LLMサービスを「Agent Platform（旧Vertex AI）」と表記している箇所があるが、2026年10月時点での正式な名称変更経緯は元記事には明記されていない。※編集部の補足：Google CloudはVertex AI Agentに関連するサービスの名称を段階的に改称しており、最新の正式名称は公式ドキュメントで確認することを推奨する。

インデータベースでのハイブリッド検索（ai.hybrid_search）

AlloyDBが提供するネイティブSQL関数で、Reciprocal Rank Fusion（RRF） をDBエンジン内部で直接実行する。ベクトルコサイン類似度（HNSWまたはScaNN索引）とPostgreSQLの全文検索（BM25、RUM、GINを利用）を単一のDBクエリで組み合わせ、セマンティック検索とキーワード検索の結果を同時にリランキングする。

インデータベースでのAI関数（ai.generate）

GeminiなどのファンデーションモデルをSQLクエリから直接呼び出せる。複合的なユーザー質問を単一サブクエリに分解したり、「前回のセッション」といった相対的な時間表現を具体的な識別子に解決したりする処理を、アプリケーション側の追加ラウンドトリップなしに実行できる。

ADKエージェントへの接続とエンタープライズ対応

コアとなる2層メモリ構成を設定したうえで、Agent Development Kit（ADK）のデフォルトMemoryプロバイダを拡張して接続する。具体的にはADKTieredMemoryProviderとして実装し、長期メモリをlongterm_memory_toolというツールとして提供するかたちでエージェントにアタッチする。完全なPythonおよびSQLのサンプルコードはAlloyDB Agent Memory Codelabで公開されている。

エンタープライズ環境での利用を想定した内容も元記事には含まれており、マルチテナントセキュリティ・Row Level Security・IAM連携といったガードレールをAlloyDBのPostgreSQL互換レイヤーで実現する方法が解説されている。複数ユーザーのメモリを同一DBに格納しながら、テナント間の読み書きを行レベルで分離できる点は、SaaSエージェント基盤の設計において実用的な要件に直結する。

詳細はImplementing long-term AI agent memory in AlloyDB and Memorystoreを参照していただきたい。