カスタマーサポートにLLMを導入する：最初に壊れるのはどこか

カスタマーサポートは、企業がAIを導入する際に最も人気のある最初のユースケースです。それには理由があります。デモが抗いがたいほど魅力的なのです。モデルをヘルプドキュメントに接続し、質問を投げかければ、流暢に答えが返ってきます。しかし、そのデモと実際に運用できるシステムとのあいだのギャップこそ、多くのプロジェクトが苦戦する場所です。本稿では、チームが実際にぶつかるおおよその順番に沿って、最初に壊れるのはどこかをたどります。そうすれば、本番環境で発見するのではなく、あらかじめ失敗に備えることができます。

デモは簡単、運用は難しい

デモがうまくいくのは、簡単な道筋を見せているからです。明確な質問に対し、ドキュメントに存在するきれいな答えがある。しかし、実際のサポート対応はそうではありません。曖昧な質問、情報の欠落、エッジケース、怒った顧客、そして答えではなく行動を必要とするリクエスト。デモを難なくこなしたモデルは、初日にこれらすべてに直面します。デモに備えるということは、もともと問題ではなかった5パーセントのトラフィックに備えることでしかありません。

故障その1：知らないはずのことに答えてしまう

最初に壊れるのは自信過剰です。サポートモデルは、ドキュメントに答えが存在しない質問にも答えてしまい、もっともらしいポリシーや価格、手順をでっち上げます。顧客には、根拠のある答えとでっち上げられた答えの区別がつきません。どちらも同じくらい流暢に聞こえるからです。返金ポリシーについて自信たっぷりに一つ誤った答えをすれば、システム全体が節約する以上のコストがかかりかねません。

解決策は、根拠づけと誠実さです。実際のドキュメントから情報を取得し、取得したものだけに基づいて答えるようモデルに指示し、わからないときははっきりそう言って引き継ぐようにします。難しいのは指示そのものではありません。「わかりません。担当者におつなぎします」が失敗ではなく良い結果なのだと受け入れることです。

故障その2：検索が関連ドキュメントを取りこぼす

答えをドキュメントに根拠づけると、次の失敗が上流へ移ります。検索が関連ドキュメントを取りこぼしたために、モデルが誤ったドキュメントから、あるいはどのドキュメントにも基づかずに答えてしまうのです。これはあらゆる検索システムが学ぶのと同じ教訓です。失敗の大半は検索の失敗です。正しいヘルプ記事がモデルの目の前になければ、どれほど流暢に生成しても正しい答えは生まれません。

ここで地味な作業が報われます。ナレッジベースを清潔かつ最新に保ち、記事を適切に分割し、実際の質問に対して正しい記事が本当に取得されているかを測定すること。これを最終的な答えの読みやすさとは切り離して測ることが重要です。

故障その3：ナレッジベースが間違っているか古い

サポートモデルの良し悪しは、その背後にあるドキュメントによって決まります。多くの企業はモデルを接続して初めて、自社のヘルプセンターが矛盾していたり、変更された機能を説明していたり、顧客が最も尋ねることをそもそも文書化していなかったりすることに気づきます。AIはこの問題を生み出すわけではありません。顧客の目の前で、規模を伴って表面化させるのです。成功するチームは、ドキュメントの整備をプロジェクトの一部として扱います。誰か他の人が処理してくれる前提条件として扱うことはありません。

故障その4：安全に行動を実行できない

質問に答えることと、何かをすること――返金処理、住所変更、注文キャンセル――は別物です。サポートアシスタントが行動を取れるようになった瞬間、賭け金が変わります。誤った答えは恥ずかしいだけですが、誤った行動はお金やデータを動かします。実際の導入では慎重に線を引きます。低リスクの行動はモデルが直接実行でき、高リスクの行動には確認や人間の介在を求め、そのすべてについて明確な監査証跡を残すのです。こうした文脈に応じたリスク管理こそ、NIST AI Risk Management Frameworkのような枠組みが推奨するものです。結果の重大さに応じて統制を釣り合わせるのです。

故障その5：引き継ぎがぎこちない

サポートAIがすべてを処理できるわけではないので、人間への引き継ぎはプロダクトの一部であり、後付けではありません。壊れる場所はこうです。モデルが文脈を渡さずに引き継ぐため、顧客は同じことを繰り返し説明させられ、いっそう怒る。あるいは引き継ぎを拒否し、顧客をループに閉じ込める。良い引き継ぎはシームレスです。会話、顧客の意図、すでに試したことを引き継ぐので、人間は状況を把握した状態で対応を始められます。

故障その6：正しい指標を誰も測っていない

最後の失敗は静かです。チームは振り分け率（AIが処理したチケットの数）を測って喜びますが、それらの答えが正しかったかどうか、あるいは顧客がより怒って戻ってきたかどうかは測りません。品質を伴わない振り分けは、問題を隠しているだけです。長続きする導入は、解決の品質と顧客の成果を測り、実際の対話記録を定期的に読み、最悪の答えを――平均ではなく――シグナルとして扱います。

生き残る側を分けるもの

うまくいく導入に共通するパターンはこうです。モデルをシステムそのものではなく、システムの一つの構成要素として扱う。答えを根拠づけ、「わかりません」の道筋を意図的に設計し、ナレッジベースを誠実に保ち、リスクの高い行動にゲートを設け、引き継ぎを優雅にし、量ではなく品質を測る。どれも特別なことではありません。デモを出荷することと、運用を回すことの違いなのです。

まとめ

サポートチャットボットは最も手軽なAIデモであり、同時に最もうまく運用しにくいものの一つです。それは順に、自信過剰、検索、古いドキュメント、安全でない行動、ぎこちない引き継ぎ、そして誤った指標で壊れます。そのどれもが予見可能です。あらかじめ備えれば、AIサポート層は本物の資産になります。計画を省いてデモを出荷すれば、顧客があなたの代わりに失敗を見つけてくれるでしょう。