【ITニュース解説】Your Chatbot Verified the Price, Then Pasted It Into a Sentence It Wrote

チャットボットが顧客に誤った情報を伝えてしまうという問題は、システム開発において非常に重要な課題である。特に価格のような重要な情報の場合、その影響は大きい。この記事では、チャットボットがデータベースから価格を正確に取得し、それが正しいことも確認したにもかかわらず、顧客には古い価格を提示してしまったという事例を通じて、その原因と対策を解説している。

この問題の核心は、チャットボットが生成した文章に、システムが確認した「数値」を「文字列」として置き換えようとしたことにあった。例えば、システムは1299という数値が正しいと確認したが、チャットボットが生成した文章中の価格表記が$1,299.00だった場合、プログラムのreplace関数は、文字列としてこれらが一致しないと判断する。その結果、置き換えは行われず、顧客は意図せず古い価格を読み取ってしまうことになったのである。

このように、文章中の文字列を直接置き換える方法は、根本的に安全ではない。なぜなら、数値の表記は多種多様だからである。1299と$1,299.00のように形式が異なるだけでなく、小数点以下の有無（例: 849.5と$849.50）や、地域による表記の違い（例: 1299とヨーロッパ式の1.299,00）など、システムが認識する数値と、チャットボットが生成する文章中の文字列が必ずしも一致するとは限らない。また、単に文字列を置き換える場合、文章中に同じ数字が複数回出現すると、意図しない場所まで置き換えてしまう危険性がある。例えば、「500mlのフラスコは在庫が500個あります」という文章で「500」を置き換えようとすると、フラスコの名前まで変わってしまうかもしれない。さらに、チャットボットが複数の商品について会話している場合、ある商品の価格は検証されても、他の商品に関する価格は古いままになる可能性も残る。最も厄介なのは、チャットボットが数字を「約1300ドル」のように単語で表現した場合で、このような表現にはプログラムによる文字列置換は一切適用できない。これらの問題は個々に見れば解決可能に思えるが、すべてを網羅しようとすると非常に複雑になり、最終的にはチャットボットが常に都合の良い表現をしてくれるという「期待」に依存してしまうことになる。

この問題を根本的に解決するためには、「チャットボットに数字を直接書かせない」という方針を採用すべきである。具体的なアプローチとして、チャットボットには完成した回答文ではなく、「テンプレート」を生成させる。このテンプレートには、価格や在庫数などの数値情報が入るべき場所に「スロット」と呼ばれるプレースホルダーが設けられている。例えば、「紺色のレインコートは{price}で、在庫が{stock}個あります」のような形式である。

このテンプレートを受け取った後、システム側のコードが、別途データベースなどから取得し、正確性が確認された数値をそれぞれのスロットに埋め込む。これにより、数字の出所が明確になり、チャットボットが誤った数値を生成するリスクがなくなる。また、通貨記号の有無、小数点以下の桁数、地域に応じた表記（カンマとピリオドの使い分け）といった数値のフォーマットは、コードが顧客のロケール情報などに基づいて適切に処理できる。これにより、チャットボットが文脈から推測して勝手にフォーマットを決定してしまう問題を回避できる。もし、何らかの理由でスロットに埋めるべき数値がシステム側で確認できなかった場合は、不確かな情報を顧客に提示するのを避けるため、回答を拒否するのが賢明である。例えば、在庫数「0」は有効な情報だが、在庫数が不明な場合は拒否すべきである。

しかし、このテンプレート方式を導入しても、チャットボットが必ずしも指示通りにテンプレートだけを生成するとは限らない。「それは1350ドルで、在庫が{stock}個残っています」のように、スロットと同時にチャットボットが勝手に数字を文章中に含めてしまう可能性も考えられる。このような事態を防ぐため、最終的に生成された文章に対して、もう一段の「数字の検査」を行う必要がある。これは、文章中の全ての数字が、プログラムによって埋め込まれた、または既知の安全な出所から来たものであることを確認するプロセスである。

この検査にはいくつかの落とし穴がある。例えば、「Model 3」や「500mlボトル」、「SKU RC-500」のように、製品名や品番自体に数字が含まれる場合がある。単純に文章中の全ての数字を拒否してしまうと、これらの正当な情報まで拒否してしまうことになる。かといって、データベースから取得した全てのデータに含まれる数字を許容すると、「BT-3」という品番から「3日後に出荷されます」といったチャットボットが作り出した誤った数量をすり抜けてしまう可能性もある。より安全な検査方法は、文章中の数字が、元のデータ中で常に一緒に現れる単語に隣接している場合（例: 「500ml」のように単位と結合している、あるいは「Model 3」のように特定の製品名の一部である）のみを許容し、それ以外の「単独で存在する数字」は、プログラムによって埋め込まれた検証済みの数値でなければ拒否するという方法である。この際、$1,299.00や1299、1.299,00といった異なる文字列表記の数字も、数値として比較することで同じものとして扱えるようにすることが重要である。最初の問題と同様に、文字列として比較するのではなく、数値として比較することで、より正確な検証が可能になる。

これらの処理は、厳格な順序で行う必要がある。まず、チャットボットの回答が根拠に基づいているかを確認し、そうでなければ拒否する。次に、チャットボットが生成したテンプレートにプログラムが数値を埋め込み、レンダリングする。この段階で不足している情報があれば拒否する。最後に、レンダリングされた文章中に、プログラムが埋め込んだ以外の「不審な数字」（stray numbers）がないかを検査し、もし見つかれば、これもまた顧客に提示する前に拒否する。ここで重要なのは、不審な数字が見つかった場合に「修正」しようとせず、「拒否」することである。不確かな情報やチャットボットが作り出した誤情報に基づいて顧客に回答するよりも、正直に「情報を提供できない」と伝える方が、はるかに信頼性を保てる。

この設計には他にも注意すべき点がいくつかある。例えば、「a dozen left」のように数字が単語で表現されている場合、数字の検査では見つけられない。これはテンプレート方式でほとんど回避できる。また、ゼロを情報不足と混同して「在庫0個」という重要な情報を拒否してしまうミスも避けるべきである。さらに、システムが提供する数値が「検証済み」であっても、それが「最新」であるとは限らない。キャッシュされた古い価格でも検証は通るため、情報の鮮度を保証するには別途リアルタイム検索などの仕組みが必要である。チャットボットにテンプレートだけでなく自由な文章も生成させるような設計は、最終的に問題を引き起こす可能性が高いため避けるべきである。また、フリーテキストからテンプレートを解析するのではなく、JSONスキーマのような構造化された出力を利用して、チャットボットが常に期待される形式で回答を返すように設計することが極めて重要である。

最終的に、この一連の議論から得られる最も重要な教訓は、ある数字が「正しい（真実である）」ことを検証することと、その正しい数字が「顧客に確実に届く」ことを保証することは、全く異なる二つの問題であり、それぞれに特化した異なるコードと設計で対処しなければならないということである。もし、検証済みの正しい数値が、チャットボットが生成した文章というフィルターを通して顧客に届けられるのであれば、それは単なる「フォーマットの偶然の一致」に過ぎず、顧客への情報提供の確実性を保証するものとは言えないのである。