LangGraph memory は「全部会話履歴に入れる」雑設計を分解させる
このノートは原文の代替ではありません。読むべきポイントと実装上の意味を整理し、原典への入口を示します。
要点まとめ
- 会話ログに何でも押し込めば memory になる、という雑設計をやめさせる docs である。今回の文脈と、次回以降も残す情報は分けて扱えと言っている。
- その区別を、short-term memory は会話ごとの状態、long-term memory は次回以降も残す情報という形で整理している。同じ「覚える」でも責務が違う。
- さらに本番例では、in-memory より Postgres-backed checkpointer や store を前に出している。つまり memory は prompt 小技ではなく、保存と削除を含む state 管理として扱う前提が強い。
- 日本語圏で起きがちな「messages 配列に全部入れておけばよい」という理解を崩し、thread 状態、user-specific data、要約、削除責任を切り分ける入口になる。
読み終えたら次へ
この1本で終わらせず、同じ目的・同じテーマ・近い原典へ進めます。
何が変わったのか
この page では、short-term memory を agent state の一部として multi-turn conversation に使い、long-term memory を session をまたぐ store として扱っています。これにより、「前の会話の流れ」と「次回も残したい事実」を分離できます。 さらに production 章では、database-backed checkpointer や store を前提にし、PostgresSaver と PostgresStore の例を出しています。つまり memory は prompt 技法ではなく、保存基盤を伴う state management の問題として扱われています。
なぜ重要か
日本の agent 実装では、memory が「何でも覚える便利機能」として語られがちです。しかし本当に必要なのは、どれを thread 内だけで持つか、どれを user-specific data として残すか、いつ削除できるかを分けることです。この docs はその整理を強制します。 PM にも意味があります。保存期間、削除要求、引き継ぎ再開、監査可能性は product 仕様だからです。単なる model quality の話ではありません。
技術的ポイント
- short-term memory は thread-level persistence で、multi-turn conversation の文脈保持に使う。会話単位の状態保存と考えると分かりやすい。
- long-term memory は user-specific または application-level data を cross-session で保存する。次回以降も残す事実の置き場だ。
- production では Postgres-backed checkpointer と store の例が示されている。in-memory のまま本番化しない前提が明確だ。
- memory 運用には trim、delete、summarize、checkpoint history 管理も含まれる。単に保存するだけでは終わらない。
英日キーワード
| 英語 | 日本語 | 補足 |
|---|---|---|
| short-term memory | 短期メモリ | thread 単位で会話文脈を保つ記憶。次回以降も残す情報とは責務が違う。 |
| long-term memory | 長期メモリ | session をまたいで残す情報。profile や設定のような durable data の置き場になる。 |
| checkpointer | チェックポイント保存機構 | thread 状態を途中保存する仕組み。会話継続のための state persistence を担う。 |
| PostgresSaver | PostgresSaver | Postgres に thread 状態を保存する実装。in-memory のまま本番化しない前提を示す。 |
| PostgresStore | PostgresStore | Postgres に長期 store を持つ実装。cross-session memory を durable に保つ。 |
| thread state | スレッド状態 | その会話や実行単位に閉じた状態。user profile などの長期データとは分けて扱う。 |
試すなら
- まず今の agent が保存している情報を、thread 内で消えるものと次回も残すものに二分する。
- messages 配列に全部入れている設計なら、profile 情報や設定を別 store に逃がせないかを見る。
- 本番を考えるなら、in-memory 実装のままにせず durable backend と削除手順を決める。
- `何を要約で残すか` と `何を生データで残すか` を分けて、監査しやすい形にする。
注意点
- memory を増やすほど便利になるとは限らない。古い state を残しすぎると挙動が不安定になる。
- durable backend を入れても、削除要求や retention policy がなければ運用は危うい。
- LangGraph の構成は 1 つの整理法であり、他の stack でも同じ概念分離が必要かを自分で確認したほうがよい。
この記事は役に立ちましたか
公益的に続けるため、役に立った点や読みづらかった点だけを短く送れます。メールアドレスは不要です。