高齢顧客が多い通販のボイスボット：音声認識の改善前に確かめるチャネル選択

CC AI Labが公開しているCOCOコンサルティングとの対談記事では、複数の相談を抽象化したモデルケースとして「顧客の大半が高齢で、電話注文を受けるボイスボットが雑音や聞き取りの問題でうまく機能しない通販センター」が取り上げられた。同社の大松祐子氏がまず投げかけたのは、音声認識の直し方ではなく、そのチャネルを顧客が望んでいるのかという問いだった。

この問いは、精度改善の打ち手を探している責任者ほど後回しにしやすい。ここで立てたい問いは、ボイスボットの精度が低いと感じたとき、技術改善に進む前に何を確かめれば、次の施策を取り違えずに済むのかである。私の立場を先に書けば、最初にやるべきは認識エンジンの比較ではなく、「何が起きて受注を取りこぼしているのか」をログで分けることと、顧客側の窓口の選び方を確かめることだ。

なお、本記事の手順・表・判断例は編集部が組み立てた独立の実務案であり、対談の話者の見解ではない。対談での診断の詳細は元記事（会員限定）で読んでほしい。また、モデルケースは特定企業の事例ではなく、本記事でも実在企業の失敗事例として扱わない。

切電と誤認識を同じ問題にしない

「ボイスボットが機能しない」という訴えの中には、性質の違う現象が混ざっている。まとめて「精度が悪い」と呼ぶと、打ち手が全部「認識エンジンを良くする」に寄ってしまう。これは、発熱・咳・腹痛をすべて「体調不良」と書いて同じ薬を出すようなものである。

主要な対話基盤も、この区別を最初から持っている。Google CloudのDialogflow CXのドキュメントは、組み込みイベントとして、入力がどの意図にも合わなかったときの「no-match」と、入力が受け取れなかったときの「no-input」を分けている。後者には、音声に認識できる発話が含まれない場合や、発話が認識される前に無音のタイムアウトが来た場合が含まれる。AWSのコンタクトセンター向けサービスのGet customer inputブロックの説明でも、分岐は「Timeout（入力がない）」「Default（入力が条件に合わない）」「Error」に分かれている。

つまり基盤側のログには、少なくとも「黙った」「言ったが合わなかった」は別々に残る。これに業務側の事実を足して、次のように5つに分けるのが編集部の整理である。

この5つで、打ち手は大きく違う。たとえば無入力が多いなら、エンジンを替える前に待ち時間を見直す余地がある。AWSの同じドキュメントでは、Amazon Lexに渡す設定として、顧客が話し始めないと判断するまでの「Start Silence Threshold」の既定値が3秒、話し終わったと判断するまでの「End Silence Threshold」の既定値が0.6秒と記載され、どちらも調整できる（2026年9月18日時点）。一方、応答直後の切電が多いなら、認識精度をいくら上げても数字は動かない。そもそも発話していないからだ。

誤認識そのものの切り分け方は、音声認識辞書のテスト手順と日本語音声認識の誤りの出方で整理した。本記事はその手前、技術改善に進むべきかどうかを決める段階を扱う。