エージェントの記憶設計 — 短期・長期・エピソード

LLMは何も覚えていません。会話が続いて見えるのは毎ターン全履歴を読み直させているからです。短期・エピソード・長期の3層に分ける設計、想起を決める式、そして最も設計されていない「忘れる」まで、前提知識ゼロから組み立てます。

MemGPT: Towards LLMs as Operating Systems

毎朝、記憶を失って出勤してくる同僚

夜勤明けの引き継ぎを想像してください。交代要員はきわめて優秀で、機械の扱いも手順書も完璧に頭に入っています。ただ一点だけ問題があって、前の晩に何が起きたかをまったく覚えていない。彼が知っているのは、机の上の引き継ぎノートに書いてあることだけです。

LLMエージェントはこれと同じ状況にあります。モデルの重みには膨大な一般知識が焼き込まれていますが、それは訓練が終わった時点で凍結されていて、昨日あなたと話した内容は入っていません。会話が続いているように見えるのは、毎ターン、それまでのやりとりを丸ごともう一度読ませているからです。覚えているのではなく、毎回読み直している。

だとすると「記憶を設計する」という仕事の正体は、モデルを賢くすることではなく、あのノートに何を書き、何を書かず、いつ書き換え、いつ捨てるかを決めることになります。この記事はその3つの判断——書く・選ぶ・忘れる——を順に組み立てます。エージェントのループそのもの（考える→道具を使う→結果を見て考え直す）はLLMエージェントを1から解説にあるので、ここでは「そのループが何を持ち歩くか」だけを扱います。

記憶を3つに分ける

人間の記憶学で使われる分類を借りると、設計の見通しが一気によくなります。エージェントの記憶は、性質の違う3つに分けて別々に扱うのが基本形です。

• 短期記憶（作業記憶） — いま机の上に広げてある紙。直近のやりとりを、要約も加工もせず生のまま持つ。寿命は数ターン。
• エピソード記憶 — 「いつ、何が起きたか」という出来事の記録。〈8月3日、このユーザーは請求書のPDFが開けないと言い、こちらは再発行を提案して解決した〉。時刻と文脈がセットで残る。
• 意味記憶（長期記憶） — 出来事から抽出された、時刻から切り離された安定した事実。〈このユーザーの請求先はA社〉〈設定ファイルは YAML ではなく TOML〉。

この3つを混ぜると必ず破綻します。理由は書き込みの頻度と、正しさの寿命が桁で違うからです。短期記憶は毎ターン書き換わりますが、意味記憶は月に一度更新されるかどうか。逆に意味記憶へ間違いが1つ混ざると、それはすべての会話に効き続けます。同じ場所に置いて同じ規則で扱う理由がありません。

「4つ目」として手続き記憶——〈このユーザーのデプロイは必ずステージングを経由する〉のような、やり方についての知識——を足すこともあります。これも書き換わる速度が違うので、システムプロンプトや専用の指示ファイルに置いて別管理にするのが普通です。

なぜ「全部載せる」ではいけないのか

素朴な実装は「毎ターン、全履歴をそのまま送る」です。文脈長が十分に長ければこれで済みそうに見えます。しかし2つの壁にぶつかります。

1つ目はコストの壁です。毎ターン全履歴を送り直すという操作は、見た目より高くつきます。1ターンあたりの追加分（あなたの発言＋エージェントの返答）を $m$ トークン、システムプロンプトなど固定部分を $b$ トークンとすると、$T$ ターン目までに送った入力トークンの累計は次のようになります。

読み方はこうです。ターン数が2倍になると、支払うトークン量は約4倍になる。$t$ ターン目に送る量が $t$ に比例して増え、それを $T$ 回足し合わせるので、合計は $T$ の2乗で伸びます。会話が2倍長くなっただけで請求が4倍になるのは直感に反しますが、式(1)右辺の $T(T+1)/2$ がそう言っています。

2つ目は注意の壁です。文脈に入れさえすればモデルが使ってくれる、という前提は成立しません。Liu らの "Lost in the Middle"（arXiv:2307.03172）は、必要な情報を長い文脈の先頭・末尾に置いたときと中央に置いたときで正答率が変わることを測り、中央の情報が使われにくいというU字型の傾向を報告しています。履歴を全部詰め込んだ結果として大事な事実が中央に埋もれれば、入っているのに参照されない事故が起きます。記憶設計の側から見た結論は一行です。文脈は貯蔵庫ではなく、作業机である。

要約という圧縮 — 何を捨てるかの設計

短期記憶が机からあふれたら、どこかで圧縮します。定番はローリング要約です。古い方から $k$ ターンを1つの要約に畳み、要約＋直近ターンだけを持ち歩く。

ここで気づきにくい事故が1つあります。要約の要約を繰り返すと、劣化が累積することです。JPEGを保存し直すたびに画質が落ちるのと同じ構図で、圧縮は不可逆なので、2回目の要約は「元の会話」ではなく「1回目の要約」を入力にしています。細かく詰めた仕様が、5回の畳み込みを経て「ユーザーは設定について話した」まで痩せる。そして痩せたことは、痩せた側からは見えません。