LangGraphのCheckpointerとStoreは保存する範囲を分ける
Checkpointerは同じスレッドの実行状態、Storeはスレッドをまたぐアプリの情報を扱う。両方を「会話の保存」とまとめず、保存対象と利用者ごとのアクセス範囲を設計する。
用語
- Checkpointer
- 同じスレッドのグラフ状態を再開用に保存する仕組み。
- Store
- グラフの状態の外に、アプリが定める情報を保存する仕組み。
- thread_id
- 保存したグラフ状態とスレッドを対応させる識別子。認証情報ではない。
図と例
スレッドの所有者を確認 → Checkpointerに実行状態を保存 → Storeに会話外の情報を保存 → それぞれ再開・検索・削除
仮定の例：サポート案件ごとにスレッドを作る。案件の承認待ちはCheckpointerに保持し、説明の好みは顧客・ユーザーを区別したStoreへ保存する。別案件の承認待ちを引き継がない。
実際のサービス・製品では
LangGraph persistence
LangGraphの公式資料はCheckpointerをスレッド内、Storeをスレッド外の情報に対応させている。Agent Serverによる保存管理と自前の保存構成も区別する。
資料を読む
解説
会話の再開と、別の会話での記憶の検索を分けて確認する。バックアップ復元後や利用者の削除後にも、どのデータが残るかを検証する。
Checkpointerはグラフの状態をチェックポイントとして残し、thread_idを使った会話継続や再開に使う。Storeはユーザーの好みなど、アプリが定める情報をスレッドの外に保持する。本番の自前ホスティングでは永続的な実装を選び、プロセス内のInMemorySaverだけで再起動を越せるとは考えない。Agent Serverなど保存を管理するサービスでは、管理される範囲を確認する。thread_idは認証情報ではなく、API側で利用者の所有権を照合する。削除時にはチェックポイントとStoreのデータをそれぞれ対象にする。
トレードオフ
- Checkpointerに案件の実行状態を保存する
- 得るもの：同じ案件の停止・再開を扱える
- 払うもの：状態の互換性・保持期間・所有者を管理する
- Storeに会話をまたぐ情報を保存する
- 得るもの：別スレッドでも必要な情報を利用できる
- 払うもの：情報の範囲・鮮度・削除を別に設計する
さらに学ぶ
チェック
別の案件でも使う説明の好みと、今の案件の承認待ちを保持したい。適切な分担は？
- 両方を無条件に全ユーザー共通のStoreへ保存する
- 好みをStore、案件の実行状態をCheckpointerに分けて所有者を検証する
- thread_idを知っている人には全データを返す
解答と解説
好みをStore、案件の実行状態をCheckpointerに分けて所有者を検証する
用途が異なるので保存範囲を分ける。IDを知っていることはアクセス権の証明にならず、両方で利用者との対応を管理する。