「AIチャットボットの作り方」を解説する記事は、どれも同じ終わり方をします。サンドボックス上で動くデモ、テスト会話のスクリーンショット、そして「おめでとうございます」。ところが実際の顧客との電話に載せた瞬間、すべてが崩れます。
本記事はサンドボックスを飛ばします。チュートリアルが終わるところ、つまりボットが、口ごもる発話者、ナレッジベースがカバーしていない質問、規制の厳しい業種、そしてAIが限界に達したときにきれいな引き継ぎを必要とする有人オペレーターのチームに向き合う瞬間から始めます。
出来上がるのは、おもちゃのボットではなく本番運用に耐えるボイスエージェントです。その作り方を見ていきましょう。
「ノーコードAIエージェント」の解説記事が本番で崩れる理由
ノーコードプラットフォームは、本来の設計目的においては非常に優秀です。エンジニアでなくても、単純でリスクの低いユースケース向けにチャットボットを素早く立ち上げられます。ヘルプセンターのページに置くテキストウィジェット。よくある数十件の質問の自己解決。会話型UXを備えたリード獲得フォーム。
それが本番で崩れる理由は5つあります。
-
テキストを前提にしている。 音声はまったく別のモダリティです。バージイン（ボットが話している最中に相手が割り込む）、環境ノイズ、ASRの誤認識、地域なまり、1秒未満のレイテンシ要件は、ノーコードのチャットビルダーには存在しません。ビルダー自体がチャット向けに設計されているからです。
-
回答をグラウンディングできない。 「グラウンディング」とは、すべての応答を自社の実データ、つまり顧客レコード、規程文書、リアルタイム在庫に紐づけることです。ノーコードのテンプレートが参照するのは静的なナレッジベースです。顧客が自分の口座や注文、契約内容について問い合わせると、ボットはハルシネーションを起こすか、話をはぐらかします。
-
エスカレーションの設計がない。 実際の通話はエスカレーションします。ノーコードのボットはたいてい通話を終了するか、メールを送るか、保留キューに回すだけで、文脈は一切引き継がれません。電話を取った担当者はゼロから始めることになります。
-
規制業種に対応できない。 保険、医療、金融には、ノーコードプラットフォームが満たせるようには設計されていない規制要件（HIPAA、SOC 2、TCPA、州ごとの開示義務）があります。ドラッグ＆ドロップのビルダーからPCI準拠を有効にすることはできません。
-
評価の仕組みがない。 ナレッジベースを更新したあと、ボットの品質が落ちたことをどうやって知るのでしょうか。ノーコードプラットフォームにリグレッションテストは付属しません。本番環境はそれを要求します。
正直に整理するとこうです。低リスクのテキスト対応で完結するユースケースなら、ノーコードで十分です。 しかし音声、規制対象データ、実際の口座照会、有人エージェントのキューが絡むなら、本番向けのアーキテクチャが必要になります。
本番ボイスエージェントの本当の構造
本番のボイスエージェントはモノリスではなくパイプラインです。各段階に固有のレイテンシ予算、障害モード、そしてベンダー選定のトレードオフがあります。
よくある質問
チャットボットを本番投入したとき、最初に壊れるのはどこですか。
誰も台本を用意していない入力への対応です。誤字、複数の論点が混ざった質問、尋ねられたのとは別の質問に答えてしまう人。デモのフローは協力的なユーザーを前提にしています。
リトリーバルは必要ですか。それともすべてプロンプトに入れてしまえますか。
リトリーバルが効いてくるのは、回答の対象が、再デプロイしたい頻度よりも速く変わるようになった時点です。プロンプトは安定した知識には向きますが、バージョン番号が付くものには不向きです。
チャットボットから人間への引き継ぎはどうあるべきですか。
会話の書き起こしと意図を添えて渡すことです。会話を最初からやり直させる引き継ぎは、引き継がないよりむしろ悪い。顧客は同じ説明を二度させられたことになるからです。
