【ITニュース解説】Building a Production-Ready AI Chatbot with Memory and Context

AIチャットボットがまるで人間と会話しているかのように、過去の発言を覚えていて、文脈に沿った自然なやり取りを続けるのは、実は非常に高度な技術が支えている。一見すると簡単そうに見えるこの「記憶」や「文脈」をチャットボットに持たせることは、システム構築において重要な課題である。

その根本的な理由は、現在の高性能な言語モデル（LLM）が「ステートレス」な設計になっているためである。ステートレスとは、簡単に言えば、一度の処理が終われば、それまでの情報を一切記憶しないという意味である。私たちがチャットボットに質問を投げかけるたびに、言語モデルにとっては毎回が「初めての対話」となる。ユーザーが以前に「Go言語の例が好きだ」と発言していたとしても、次の質問の際にその情報を言語モデルに伝えなければ、モデルはそれを覚えていない。そのため、私たちが普段利用しているような「記憶力のある」チャットボットは、言語モデルそのものではなく、その言語モデルを動かす「アプリケーション」の側で、会話の記憶を管理する仕組みが必要になるのだ。そして、この記憶管理の設計は、システムが大きくなるにつれて重要性が増していく、根本的なアーキテクチャ上の決定となる。

言語モデルに記憶を持たせるための最も素朴なアプローチは、「全会話履歴の再送」である。これは、ユーザーとの過去の全ての会話を、新しいメッセージと一緒に毎回言語モデルに送り直すという方法だ。例えば、Pythonで書かれた簡単なチャット関数では、過去のメッセージ履歴（history）に新しいユーザーのメッセージを追加し、それを丸ごと言語モデルに送る。応答が得られれば、それも履歴に追加する。この方法は確かに会話の連続性を保つことができるが、会話が長く続くとすぐに問題が発生する。言語モデルが一度に処理できるテキストの量には上限（コンテキストウィンドウ）があり、それを超えるとエラーになったり、最悪の場合は途中で会話が途切れてしまう。さらに、この方法では、過去のメッセージ全てを毎回送信するため、言語モデルの利用料金の計算基準となる「トークン」の消費量が爆発的に増え、非常に高額なコストがかかることになる。例えば、1回あたり200トークンのやり取りが50回続くと、次のリクエストでは合計10,000トークンもの入力が必要となり、そのほとんどは言語モデルが既に処理済みの重複情報となってしまうのだ。

この問題を解決するための最初の戦略として、「スライディングウィンドウ」が挙げられる。これは最もシンプルで効果的な解決策の一つで、直近の一定数の会話ターン（例えば、最新の20ターン）だけを保持し、それより古い会話は破棄するというものだ。言語モデルへのリクエスト前に、会話履歴をこの設定された最大ターン数に収まるように「トリミング（切り詰める）」することで、入力トークン数を会話の長さに関わらず一定の範囲内に保つことができる。この方法の利点は、実装が簡単で、トークンコストを効果的に抑制できることにある。しかし、欠点として、保持期間を過ぎた古い情報は完全に失われるため、まるでモデルが突然「記憶喪失」になったかのように、それ以前の文脈を忘れてしまうという問題がある。例えば、サポート対応や簡単なQ&Aのように、一回限りのセッションで完結するようなチャットボットであれば問題ないが、より複雑で長期的な連続性が求められる会話では、ユーザー体験を損ねる可能性がある。

スライディングウィンドウの「突然の記憶喪失」という問題を改善するために、「要約ベースの記憶」という戦略が考えられた。これは、古い会話をただ捨てるのではなく、その内容を「要約」して保持するという方法だ。具体的には、会話履歴が一定の閾値（例えば、直近10ターンを超えた部分）を超えた場合、古い部分の会話内容を別の言語モデルに送り、そこから「重要な事実、好み、決定事項」などを簡潔にまとめた要約文を生成させる。そして、この要約文を、次に言語モデルに送るシステムプロンプト（チャットボットの役割や指示を設定する冒頭のメッセージ）の一部として含めることで、モデルが会話の全体像を把握できるようにする。この要約のプロセスには、通常、メインのチャットモデルよりも高速で安価な言語モデルが使われる。これは要約が「新しいテキストを生成する」のではなく、「既存のテキストを圧縮する」タスクだからだ。このアプローチにより、会話の主要な意味合いを失うことなく、プロンプトのサイズを管理可能な範囲に抑えることが可能になる。

さらに高度な記憶戦略として、「セマンティック記憶とベクトル検索」がある。これは、数日後にユーザーが戻ってきても会話の連続性を保ちたい、といった永続的なセッションに対応するための強力な方法である。この戦略では、過去の会話や重要な情報をテキストの「意味」を表す数値の並び（ベクトル）に変換し、「ベクトルデータベース」と呼ばれる特殊なデータベースに保存する。ユーザーから新しいメッセージが送られてきたとき、そのメッセージもベクトル化され、データベースに保存された過去のベクトルの中から、意味的に最も関連性の高い情報が検索・取得される。これにより、会話全体を再送する代わりに、現在の会話に「関連する」過去の事実や文脈だけを効率的に引き出すことができる。実際のシステムでは、取得した関連情報を言語モデルへのプロンプトに含めて、より賢い応答を生成させる。この方法では、全ての会話履歴ではなく、重要なやり取りや事実を絞って保存することが効率的だ。

本番環境で実際に稼働する高性能なAIチャットボットでは、これらの記憶戦略を単独で使うのではなく、組み合わせて利用することが一般的である。これは「ホット・ウォーム・コールドメモリ」という階層的なアーキテクチャとして表現される。

• 「ホットメモリ」は、最も頻繁に利用される記憶であり、直近の数ターン（例えば、最後の数メッセージ）を指す。これは常に言語モデルへのプロンプトに含められ、直接的な会話の流れを維持する。
• 「ウォームメモリ」は、ホットメモリより少し古い会話の記憶で、要約ベースの記憶戦略によって管理される。会話履歴が長くなると、古い部分が要約され、システムプロンプトの一部として注入される。
• 「コールドメモリ」は、永続的な長期記憶で、セマンティック記憶とベクトル検索によって管理される。ユーザーが長期間離れていた後でも、そのユーザーに関する過去の重要な情報や設定を保持し、必要に応じて動的に検索して利用する。 新しいユーザーメッセージが来るたびに、まずコールドメモリから関連性の高い情報を取得し、次にウォームメモリの要約を追加し、最後にホットメモリの直近の会話履歴を付加して、ユーザーのメッセージとともに言語モデルに送る。この多層的なアプローチにより、会話の長さやユーザーの利用期間に関わらず、言語モデルへの入力トークン数を効率的かつ予測可能な範囲に維持しつつ、高い会話品質を実現する。

システムを構築する上では、いくつかの運用上の詳細にも注意が必要である。特に、要約の生成やベクトル埋め込みの作成といった処理は、ユーザーがメッセージを送信するたびに同期的に（リアルタイムで）実行されると、ユーザーが応答を待つ時間が長くなり、遅延を感じてしまう可能性がある。そのため、これらの処理は「非同期」に、つまりバックグラウンドで別のタスクとして実行し、結果をキャッシュして利用する設計が望ましい。また、チャットボットの記憶にはユーザーの個人情報や企業の機密情報が含まれる可能性があるため、セキュリティ対策は極めて重要である。データが保存されているデータベース（リレーショナルデータベースやベクトルデータベース）に対して、暗号化や適切なアクセス制御を施し、情報の漏洩や不正利用を防ぐためのセキュリティ hardening（強化）が不可欠となる。

結論として、記憶管理を持たないチャットボットは、あくまで技術的な試作段階に過ぎない。言語モデル自体は記憶を持たないため、ユーザーとの一貫した会話体験を提供するためには、アプリケーション層で記憶を賢く管理する責任がある。スライディングウィンドウ、要約、セマンティック検索という三つの戦略は、互いに代替し合うものではなく、成熟したチャットボットシステムではこれら全てを段階的に組み合わせて利用するのが一般的だ。まずはシンプルにスライディングウィンドウから始め、会話の文脈が失われて応答品質が低下し始めたら要約機能を追加する。そして、セッションを跨いだ記憶や永続的な記憶が必要になった段階で、セマンティック検索を導入するのが賢明なアプローチである。最初から全ての複雑性を導入するのではなく、実際の課題が生じたときに段階的に解決策を追加していくべきだが、将来的な拡張性を考慮して、インターフェース設計は最初から柔軟にしておくことが望ましい。