エージェントのメモリ：短期と長期をどう持たせるか

横にスクロール

どんなパターンか

大規模言語モデルそのものは、本質的にステートレスだ。一回の推論は、そのときプロンプトに載っていた情報だけで完結し、応答を返し終えれば直前のやり取りさえ保持しない。それでもチャットが会話として成立して見えるのは、アプリケーション側が過去の発言をまとめて毎回プロンプトへ詰め直しているからにすぎない。エージェントに「覚えている」ように振る舞わせる仕組みは、モデルの外側で人間が設計するものだ。

この記憶の設計は、性質の異なる二層に分けて考えると整理しやすい。ひとつは短期メモリで、直近の会話履歴や、思考の途中経過を書き留めるスクラッチパッドがこれにあたる。いずれもコンテキスト窓、すなわちその回の推論に渡すプロンプトの中に直接載る情報であり、セッションが終われば消える揮発的な記憶だ。もうひとつは長期メモリで、会話の要点や学んだ事実を外部のストアへ書き出しておき、必要になったときに想起してプロンプトへ戻す。こちらはセッションを跨いで持続する。

人間の記憶になぞらえるなら、短期メモリは目の前の作業を支えるワーキングメモリ、長期メモリは経験として蓄えられる長期記憶に近い。容量の限られた作業台の上で今の仕事を回しつつ、そこに載りきらないものは棚へしまい、また要るときに取り出す。エージェントのメモリ設計とは、この作業台と棚の役割分担を決めることだと言ってよい。

仕組み

両者の違いを、置き場所・持続・容量・用途の四つの観点で対比すると輪郭がはっきりする。

短期メモリの実体は、プロンプトに詰め込まれる一連のテキストだ。システムプロンプト、これまでの会話履歴、ツールを呼んだ結果、そして途中の推論を書き留めたスクラッチパッド。これらが積み重なって一回分の入力を構成する。問題は、この入力に上限があることだ。モデルが一度に読めるトークン数、すなわちコンテキスト窓は有限であり、会話が長引くほど履歴は膨らみ、やがて上限に達する（入力がどうトークンへ分割されるかはトークナイザを参照）。

上限を超えた履歴をそのまま切り捨てれば、古い文脈は失われる。そこで要約と圧縮の戦略が要る。よく使われるのは、直近の数ターンは原文のまま残し、それより古い部分を短い要約へ畳んでいくやり方だ。会話が進むたびに要約を更新していく方式もあれば、一定の長さに達したところで履歴全体をまとめて圧縮する方式もある。いずれも狙いは同じで、限られた窓の面積に、できるだけ密度の高い情報を載せることにある。

長期メモリの実体は、コンテキスト窓の外に置かれた永続的なストアだ。埋め込みベクトルで類似検索するベクトルDB、単純なキーバリュー、あるいはファイルやリレーショナルDBが使われる。ここで設計上の勘所は二つある。書き込みと想起だ。書き込みでは、何を、いつ保存するかを決める。会話の終わりに要点を要約して残す、重要なイベントが起きた時点で都度記録する、ユーザーの嗜好を抽出して蓄える、といった判断がここに含まれる。想起では、今の状況に関連する記憶だけをクエリで引き出し、プロンプトへ差し込む。

この想起の仕組みは、RAGと技術的にはほとんど同じだ。関連する情報を外部から検索し、生成の文脈に加える流れは共通する。違いは何を貯めるかにある。RAGが対象とするのは、あらかじめ用意された外部の知識やドキュメントだ。一方でメモリが貯めるのは、エージェント自身が対話や作業を通じて得た経験である。同じ検索技術を、他人の知識を引くために使うのか、自分の過去を思い出すために使うのか、という目的の違いが両者を分ける。

実際のエージェントでは、この二層が一つのループとして回る。セッションの開始時に、長期ストアから関連する記憶を想起して短期メモリの初期状態を組み立て、対話を進めながら短期メモリを更新し、区切りのよいところで新たな要点を長期ストアへ書き戻す。この読み出しと書き込みの往復が、セッションを跨いだ連続性を生む。短期メモリだけでは一度きりの会話に閉じ、長期メモリだけでは今この瞬間の文脈を欠く。両者がループとして噛み合って初めて、エージェントは学び続ける主体のように振る舞える。

使いどころと注意

具体的な場面に当てはめると要点がつかみやすい。継続的にコードを書くエージェントなら、プロジェクトの規約や過去に踏んだ失敗は長期メモリに置き、今開いているファイルや直前のエラー出力は短期メモリに置く。カスタマーサポートのエージェントなら、ユーザーの契約内容や過去の問い合わせ履歴は長期に、今の会話の流れは短期に、と自然に振り分けられる。どちらの層に何を置くかは、その情報が一回の対話で閉じるのか、次以降のセッションにも効くのかで決まる。

メモリを持たせるうえで最初に向き合う問いは、何を覚え、何を忘れるかだ。すべてを保存すれば安心に思えるが、実際は逆効果になりやすい。ストアが肥大化すれば想起のノイズが増え、関連の薄い記憶まで引いてしまう。結果として、肝心の情報が埋もれ、トークンとコストだけが膨らむ。忘れることは失敗ではなく、記憶を有用に保つための積極的な設計判断だと捉えたい。

書き込みのタイミングにも注意が要る。細かく書きすぎればストアは断片で溢れ、古い記憶と新しい事実が矛盾しはじめる。ユーザーの居住地が変わった、以前の決定が覆った、といった更新をどう扱うかは、あらかじめ方針を決めておくべきだ。多くの場合はタイムスタンプを持たせ、矛盾したときは新しい記憶を優先する。想起の側でも、単なる類似度だけでなく、鮮度や重要度を加味して並べ替えると精度が上がる。

要約による情報の損失も見落とせない。圧縮は不可逆であり、いちど畳んだ細部は元に戻らない。そのとき不要に見えた数値や固有名詞が、後の対話で決定的に効いてくることがある。どこまで縮めてよいかは、エージェントの用途しだいで変わる。事実の正確さが問われる場面ほど、要約は慎重にすべきだ。

もう一点、長期メモリはユーザーに関する情報を持続的に蓄えるため、プライバシーへの配慮が欠かせない。何を保存し、いつ消せるようにするかは、機能である以上に責任の問題だ。保存する範囲を必要最小限にとどめる設計は、想起のノイズを減らすうえでも理にかなっている。

まとめ

エージェントのメモリは、揮発的で有限な短期メモリと、永続的で外部にある長期メモリの二層で捉えるのが基本だ。短期メモリはコンテキスト窓に直接載る直近の文脈であり、その有限性ゆえに要約と圧縮が避けられない。長期メモリは経験をストアへ書き出し、必要なときに想起して窓へ戻す。設計の核心は、限られたコンテキスト窓をどう使い、何を外へ逃がし、いつ呼び戻すかという配分にある。関連する設計パターンはエージェント設計パターンから辿れる。