【ITニュース解説】What Actually Breaks When You Put a Language Model in a Customer-Facing Flow

システムエンジニアを目指す皆さんにとって、顧客向けサービスに言語モデル、つまりAIチャットボットなどを導入することは、これから関わる機会が増える技術分野だ。この技術は大きな期待をもたらす一方で、予期せぬ課題も内在している。一般的には、言語モデルを本番環境で使うと「幻覚（ハルシネーション）」「性能の変化（ドリフト）」「応答遅延（レイテンシ）」「コスト増」「監視の難しさ」といった問題が挙げられがちだ。これらは確かに存在する問題だが、多くは監視ツールを販売する企業が提唱するものであり、問題の本質が顧客の行動にどう影響するかという視点に欠けることがある。

実際に言語モデルを顧客向けサービスに導入した際に、どのような問題が具体的に発生し、どう対処すべきかを解説する。

まず最初に発生する問題は、モデルが自社のポリシーについて誤った情報を自信満々に顧客に伝えてしまうことだ。例えば、顧客が返金条件やプランの詳細について具体的な質問をした際、モデルの学習データには企業の正確な規約が含まれていないことが多い。企業のポリシーは社内文書や顧客管理システム、あるいは熟練した担当者の知識に依存するため、モデルはそれらしいもっともらしい回答を生成してしまう。この問題は、チャットボットの発言が企業の公式な見解とみなされるリスクがある点で重要だ。実際に航空会社の事例では、チャットボットが誤った情報を伝えたことで企業が賠償責任を負う判決が出ている。この判例は、チャットボットが第三者ではなく、企業自身の公式な窓口として扱われることを示している。このリスクを避けるためには、モデルに「説明させること」と「断言させること」を厳しく区別する必要がある。「大まかな料金体系を説明する」ことは安全だが、「あなたの返金は処理されます」といった具体的な断言は危険だ。断言が必要な場合は、モデルに言葉の生成を任せるものの、最終的な決定や情報は正確なデータを保持する別のシステムから引き出す設計にすべきだ。

サービスを立ち上げた後、時間が経つにつれて問題が悪化する傾向がある。これは、モデル自体の性能が低下するのではなく、顧客からの質問のパターンが変わるためだ。開発段階のテストでは、製品を熟知した開発者が丁寧な質問をするが、実際の顧客は「返金???」のように短く、曖昧な質問をすることが多い。これにより、モデルは顧客の意図を推測する必要が生じ、誤った情報を生成しやすくなる。また、テストでは想定していなかった、稀だが深刻なエッジケース（例えば、特定の状況下でのポリシーの適用外など）が増加し、対応コストが高まる。さらに、製品の価格変更やサービス内容の改定があっても、モデルに指示を与える「プロンプト」（AIへの命令文）が更新されないまま放置され、モデルが古い情報を伝え続ける問題も発生する。これらの問題への対策として、プロンプトを単なる文章としてではなく、アプリケーションの「本番設定」の一部として扱うべきだ。バージョン管理システムで管理し、担当者を明確にし、製品の変更に伴ってプロンプトも更新する作業を、リリース時のチェックリストに必ず含める必要がある。

また、言語モデルの提供元がモデルを更新した場合も問題が発生する可能性がある。自社がコードを変更していないにもかかわらず、プロバイダ側の更新によってモデルの話し方や応答の傾向、出力フォーマットなどが予期せず変化することがあり、監視ツールでは検知しにくい場合がある。これを回避するためには、常に最新版を使用するのではなく、特定のバージョンを固定（ピン留め）することが有効だ。これにより、モデルの変更が自社の管理下でスケジュールされたものとなる。加えて、「ゴールデンセット」と呼ばれる、実際にあった質問とそれに対する正しい回答のリストを数十件作成し、モデルが更新されるたびにこのリストでテストし、人間が目視で結果を確認することが非常に重要だ。これは非科学的に見えるかもしれないが、自動評価では見落とされがちな微妙な変化や、意図していなかった問題を発見するのに役立つ。

利用費用が急増する問題も頻繁に発生する。言語モデルの利用コストは、顧客数よりも、会話の長さやリトライ（再試行）の回数に大きく依存する。多くの場合、予算は1回のリクエストあたりの費用で見積もられるが、チャットでの会話では過去の履歴を毎回モデルに送るため、会話が長くなるほどコストは指数関数的に増大する。さらに、エラーが発生した際に何度もリトライを繰り返す「リトライループ」も、高単価なモデルの呼び出しにおいては、あっという間に高額な請求につながる可能性がある。これらの費用を管理するためには、1会話あたりの発言回数に上限を設ける、リトライ回数を制限し、失敗し続ける場合は処理を停止する、1日あたりの利用上限を設定してアラートを発する、古い会話履歴を要約または削除してモデルに送る情報を減らす、といった対策が有効だ。特に効果が高いのは、顧客と直接対話する部分には高性能なモデルを使いつつ、顧客の質問の分類やルーティングといった裏側の処理には、より安価で性能が控えめなモデルを使用することだ。

顧客がモデルを騙したり、意図しない行動をさせたりするセキュリティリスクも存在する。これは「プロンプトインジェクション」と呼ばれ、ユーザーが入力した文章やモデルが読み込んだ文書の中に、開発者が意図しない指示が紛れ込み、モデルがそれに従って動いてしまう問題だ。データと指示が同じ入力経路（コンテキストウィンドウ）を共有するため、完全に防ぐことは非常に難しい。また、「過剰な自律性」も問題で、モデルに必要以上のツールや権限を与えていると、プロンプトインジェクションによって不正な指示が成功した場合に、モデルが単に間違ったことを言うだけでなく、返金処理や住所変更、注文キャンセルといった実害のある行動を実行してしまう可能性がある。これらのリスクへの対策は、AI特有のものではなく、一般的な情報セキュリティの原則が適用される。「最小権限の原則」に基づき、モデルに与える権限を必要最小限にすること、そして顧客に与える影響が大きい行動については、モデルに直接実行させず、一度「提案」として提示し、人間の承認を得てから実行する「提案と確認」の仕組みを導入することが極めて重要だ。

顧客向け言語モデルの導入は、企業のブランドイメージにも深く関わる問題となる。顧客は通常、困っているときや不満を抱えているときにサポートチャットを利用するため、すでにストレスを抱えている状態にある。そのような状況でモデルが間違った回答をすれば、顧客のブランドに対する不信感は決定的なものとなりかねない。たとえモデルが95%の時間で完璧な対応をしたとしても、残りの5%で怒っている顧客に間違った回答をすれば、その顧客の記憶に残るのは「最悪の体験」だ。この非対称性を理解し、二つの設計原則を導入すべきである。一つは、最初から人間へのエスカレーションパスを明確に提示することだ。顧客が人間と話したいのに、チャットボットと何ターンもやり取りさせられると、不満はさらに高まる。もう一つは、モデルが「分からない」と明示的に言えるようにすることだ。モデルは訓練の性質上、常に回答しようとする傾向があるが、「申し訳ありませんが、私には確実な情報がありません。担当者にお繋ぎします」といった正直な回答は、多くの顧客にとって、的外れな自信満々の回答よりもはるかに受け入れられやすい。

実際にシステムを運用する際には、以下の体制を整える必要がある。まず、すべての会話履歴（入力、出力、モデルバージョン、プロンプトバージョン、使用ツール、タイムスタンプ）を完全に記録することだ。これがなければ、問題発生時の原因調査は不可能となる。次に、サポート担当者が間違った回答を簡単に報告できる「ワンクリック」のフィードバック機能を設けること。実際に問題に気づくのは現場の担当者だからだ。また、ローンチ後の最初の1ヶ月間は、毎日20件程度の会話を手動で読み、モデルの挙動を人間が直接確認する「日次レビュー」は非常に価値が高い。これは、自動評価では見つけられない予期せぬ問題を発見するのに役立つ。さらに、エラーだけでなく、人間へのエスカレーション率、平均会話ターン数、1日あたりの費用、拒否率など、トラフィックの傾向を示す指標に異常がないかアラートを設定する。そして最も重要なのは、エンジニアでなくても操作できる「緊急停止スイッチ」を用意することだ。これは、何か重大な問題が発生した際に、システム全体を既存の人間によるサポート経路に切り替えるための最終手段であり、いつでもすぐに実行できる状態にしておくべきだ。

万が一、モデルが間違ったことを発言してしまった場合の初動対応も決めておくべきだ。まず、そのモデルが与えた回答を「企業からの約束」と見なし、それが軽微なものであれば、顧客の要求を受け入れるべきだ。次に、ログを調べて、同じ間違いが他にどれくらい発生しているかを迅速に確認する。そして、システム全体を停止するのではなく、問題の原因となっている特定の機能だけを一時的に停止し、被害の拡大を防ぐ。根本原因を修正することも重要だ。プロンプトに一時的な対処を加えるのではなく、なぜモデルが間違ったポリシーを生成したのか、そのポリシー情報がモデルに正確に提供されているか、情報を取得する仕組みに問題はないか、といった根本的な原因を調査し、改善する。最後に、今回発生した失敗を「ゴールデンセット」に追加し、今後のテストケースとして活用することで、同じ間違いの再発を防ぐ。

顧客向け言語モデルの導入は、ベンダーが言うよりもはるかに大きな責任とコミットメントを企業に求める技術だ。リスクは技術そのものよりも、流暢で自信過剰でありながら非決定的なシステムを、顧客が企業に対して意見を形成する最も重要なチャネルに接続し、それを単純な「問題解決率」といった指標だけで評価してしまうことにある。成功のために必要なのは、地味で基本的な運用原則だ。モデルができることの範囲を厳密に定め、正確な事実を提供し、モデルが実行できる行動を制限し、会話記録を定期的に確認し、緊急時には停止できる手段を確保すること。導入を検討する際には、「このモデルが生成しうる最悪の文章は何で、我々はそれに責任を持つ覚悟があるか？」という問いに真摯に答えることが肝心だ。その覚悟がないのであれば、モデルの役割設定（スコープ）自体が間違っており、どんなにプロンプトを工夫してもその根本的な問題は解決しないだろう。