チャットボットを作って、試してみた。最初の質問には答えてくれる。でも、2回目の質問で「さっき言ったじゃないですか」が通じない。
しりとりをやらせてみたら、「りんご」と言ったあとに「ごりら」と返ってきた。次は「らっぱ」。前の言葉を引き継いでいるように見えた。でも実際は引き継いでいなかった。たまたま流れが成立しただけで、関係のないところで詰まって初めて気づく。
会話IDという見えない糸
チャットボットにAIを組み込む場合、ユーザーが送ったメッセージをAPIに渡して返答を受け取る、という動作を1往復ずつこなします。このとき、単純に「メッセージを投げる→受け取る」を繰り返すだけだと、APIから見れば毎回初対面です。前の会話は存在しないことになる。
これを防ぐのが会話IDです。AIツールのAPIは、最初の応答に会話IDを含めて返してくれます。「この会話はこの番号で識別する」という印のようなもの。次のリクエストでこのIDを一緒に送ると、APIはその番号の会話の続きとして認識して答えます。
逆に言えば、このIDを送らないと、毎回新しい会話が始まる。前の発言は消えた状態です。
詰まるのは設計じゃなく保存
最初にAIに作らせたコードは、会話IDを返してはいました。でも、それを次のリクエストに渡すところが抜けていた。
こういうことはよくあります。「IDを取得する」処理と「IDを使う」処理は別なので、片方だけできていて動いている気になる。しりとりで気づいたのは偶然で、普通の業務用途だと「なんか回答がズレてる気がする」という感覚で終わってしまいます。
保存する先はどこでも構いません。Slackのチャットボットを作った案件では、スクリプトのプロパティ（実行環境が持つ小さなメモ領域）に「スレッドID×会話ID」の形で保存しました。Slackはスレッド単位でやり取りするので、同じスレッドのメッセージが来たら同じ会話IDを使う、という構造です。
Webのチャットウィジェットを作った案件では、ブラウザ側で会話IDを変数として持つ構成にしました。ページをリロードすると会話は切れますが、その案件では用途上それで十分だったので。
後から困ったこと
スクリプトのプロパティに会話IDを保存していくと、時間が経つにつれて古いIDが溜まっていきます。自動では消えません。プロパティの容量には上限があるので、放っておくと詰まります。
古いIDは30日で自動削除するクリーンアップを後から追加しました。最初に作るとき、こういう「動き続けると発生する問題」は見落としがちです。システムが正常に動いている間は誰も気づかない。ある日突然うまく動かなくなって調べると、プロパティが詰まっていた、というパターン。
削除の間隔はケースバイケースですが、30日使っていないスレッドの会話IDは概ね不要です。
本番環境に余計な情報を残さない
もう一つ詰まったのが、デバッグ用のUIが本番環境に残ってしまったこと。
開発中は「この会話IDは何番か」「何ターン目か」が見えていると便利です。AIに頼むと親切にそういう表示を付けてきます。でも本番では不要どころか邪魔で、ユーザーには見えないほうがいい。
コードを修正しても「消えてないよ」と気づいたのは動かしてみてから。どのファイルのどのコードに対応しているのかが分からなくなっていたのが原因でした。ファイルが複数に分かれているとき、AIに「この部分を消して」と頼んでも、対象ファイルが噛み合っていないとそのままになります。「消した」というのが別ファイルの話だったりする。
ここは自分で確認するしかない箇所です。AIはファイル構造を正確に把握しているとは限らない。
やることはシンプル
整理すると、チャットボットに文脈を持たせるためにやることは2つです。
1つ目は、最初の応答から会話IDを取り出して、どこかに保存する。2つ目は、次のリクエストを送るとき、そのIDを一緒に渡す。
これだけです。難しいことではないけれど、最初に作るとき抜けているとチャットボットが毎回初対面になる。設計としては地味な部分なので、後回しにして「なんか変だな」と気づいたころに修正する、というパターンが多いです。
保存先とクリーンアップの方針は最初に決めておいたほうが楽です。後から追加するのは手間がかかる。