AIエージェントに「長期記憶」を持たせる2層構造

LLMは設計上ステートレス、つまり「状態を持たない」構造になっています。会話ごとにコンテキストウィンドウが初期化されるため、セッションをまたぐと前回のやり取りは原則リセットされます。

たとえば旅行を計画するエージェントを作ったとします。ユーザーが1日目に「乗り継ぎなしの便だけで」「ホテルは1泊2万円以内」と伝えても、翌日のセッションでは白紙に戻る。観光スポットの話が盛り上がれば、それ以前に確定していたはずの前提条件がコンテキストから押し出される。こういった問題は、旅行エージェントに限らず、営業フォローやコンテンツ制作の補助エージェントでも同様に起きます。

「記憶が続くエージェント」を実現するには、LLMの外側に記憶を保持する仕組みが必要です。それをどう設計するかがここ数か月の実装上の核心テーマになっています。

Googleが公式ブログで公開したアーキテクチャは、役割の異なる2つのストレージを組み合わせたものです。

短期バッファ：Memorystore for Valkey Redis互換の高速インメモリDBで、セッション内の会話履歴や一時的な判断ログを置きます。レイテンシが低く、直近の文脈を素早く読み書きするのに向いています。ただしインメモリなので揮発性があり、長期保存には向きません。

長期ストレージ：AlloyDB AI PostgreSQL互換のフルマネージドDBで、「この人は非停止便しか使わない」「グルテンフリー対応が必要」といったユーザーの根本的な条件や過去の意思決定を永続化します。ベクトル検索にも対応しており、関連する過去情報を意味的に引き出すことができます。

注目すべきはトークン消費が最大70%削減できるという点です。毎回すべての会話履歴をプロンプトに詰め込む代わりに、「今のセッションに関係する情報だけ」を長期ストレージから取り出してコンテキストに加える設計なので、無駄なトークンを積まなくて済む。コスト面での合理性が明確です。

公式ブログにはアーキテクチャ図と実装パターンが記載されており、構成のたたき台として読める内容になっています。

2層メモリが効くのは「複数日にわたって状態が積み上がっていくエージェント」です。具体的には以下のようなケースが当てはまります。

• 営業フォローエージェント：「先方は価格より導入工数を気にしている」「担当者交代があった」などの商談文脈を保持したまま、複数のフォローメールを生成する
• コンテンツ制作補助：「このブランドは丁寧語ベースで、横文字は最小限」といったトーン定義を毎回プロンプトに書かずに済む
• 社内QAエージェント：ユーザーごとの役職や権限、過去の問い合わせ履歴に基づいた回答の出し分け

一方、単発の検索タスクや「会話が1セッションで完結する用途」には、この2層構成はやや重いかもしれません。実装コストとユースケースを照らし合わせて判断するのが現実的です。

なお、先日のGoogleがAIエージェントにクラウド操作を丸投げできる仕組みを公開でも触れたように、Googleはエージェント周辺のインフラを段階的に整備しています。ストレージ・オーケストレーション・実行基盤と、レイヤーごとに選択肢が増えてきているタイミングです。