会話履歴の保存と再開 — 設計編

学習のねらい

前レッスンでは、コンテキスト圧縮によって会話履歴を効率的に保つ方法を学びました。しかし、会話エージェントがユーザーとのセッションを跨いで記憶を保持したり、システムが再起動しても会話を再開できるようにしたりするためには、その履歴を永続的に保存する仕組みが必要です。 本レッスンでは、会話履歴を永続化する目的と、保存形式の選び方を整理します。実装は次のレッスン(実装編)で扱います。

なぜ会話履歴を永続化するのか?

LLM との会話は通常、API コールごとに独立しています。会話履歴を Python のリスト等メモリ上に保持しているだけでは、以下のような問題が起きます。

• アプリケーションの再起動: メモリ上の会話履歴は失われます
• 複数セッション: ユーザーが中断して後で再開しようとしたとき、過去の文脈が失われます
• 異なるデバイス: スマートフォンとPCなど、別端末からアクセスしても履歴が共有されません

これらの問題を解決するには、会話履歴を永続的なストレージ(ファイルやDB)に保存する必要があります。

会話履歴の保存形式

会話履歴は、LLM の API に渡す messages パラメータと同じ形で保存するのが一般的です。 たとえば {"role": "user", "content": "..."} のような辞書のリストです。 保存先には主に以下の2つの選択肢があります。

JSON か SQLite か - 選び方ガイド

JSON ファイル

• 長所: 人間にも読みやすい、多くの言語で簡単に扱える、サーバ不要、デバッグしやすい
• 短所: 件数が増えると検索が遅い、複数同時書き込みに弱い
• 向いているケース: 1ユーザー1セッション程度、開発初期の試作、ログ目的

SQLite データベース

• 長所: 検索・絞り込みが速い、ユーザーIDなどでインデックスを張れる、整合性がある
• 短所: スキーマ設計が必要、JSON より少しコードが増える
• 向いているケース: 複数ユーザー、検索や統計が必要、本番運用

迷ったら 「まず JSON で動かしてから、必要になったら SQLite に切り替える」 のがおすすめです。要件が見えていない段階で SQLite を選ぶと、設計の無駄になることがあります。

まとめ

会話履歴を永続化する目的は、再起動・再開・デバイス間の文脈維持です。 保存形式は最初は JSON、必要になったら SQLite。次のレッスンでは具体的な実装を扱います。