コールセンターの音声認識が通じないとき　プッシュ入力へ切り替える設計

Twilioが公式ブログで公開している音声ボット設計の実践集には、はっきりこう書かれている。音声認識は英数字が混ざった入力（ABC123のような文字列）にはまだ最適化されておらず、同じ音に聞こえる候補が多いため認識が難しい。だから認識に失敗したときの代替として、電話のキーで入力するDTMFを用意せよ、と。ボイスボットを入れたのに会員番号の聞き取りで詰まり、怒った顧客がオペレーターに回ってくる。この光景は珍しくない。ではその番号は、そもそも声で聞くべき項目だったのだろうか。

本稿の立場を先に書く。桁数が決まった番号の入力でボイスボットが詰まるなら、音声認識の改善を待つより、その一項目だけプッシュ入力に切り替えるほうが早いと見ている。認識辞書の改善やIVRメニュー全体の作り直しは別の論点であり、本稿は「入力の一項目の入力モードをどう切り替えるか」に絞る。以下の4つの手順は編集部（相原ことは）の実務設計案である。

前提の用語を押さえておく。DTMFとは、電話機のキーを押したときに流れる「ピ、ポ、パ」という音で数字や記号を伝える仕組みで、プッシュホンの時代から使われてきた。IVR（自動音声応答）の説明をまとめたWikipediaの項目にあるとおり、電話の自動応答はもともとこのキー入力と音声認識の2つを入力手段としてきた。ボイスボットが広がって音声だけの設計が増えたが、製品側の部品は今も両対応である。たとえばAmazon Connectの顧客の入力を取得するブロックは、電話キーの入力とボットによる音声対話の両方を受け付ける。その会話エンジン側でも、Lex V2の入力タイムアウト設定は既定で音声とDTMFの両方の入力を受け付け、どちらか一方だけに絞る設定も用意している。使える部品は揃っている。問題は会話設計がそれを使っていないことだ。

音声が苦手な入力項目を選ぶ

最初の手順は、対話フローの中で顧客に何かを「入力」させている箇所を全部書き出し、音声向きとキー向きに仕分けることである。

仕分けの軸は2つある。1つは候補の数で、「はい・いいえ」や数個のメニューから選ぶ発話は音声で問題ない。もう1つは文字列の構造で、桁数が長い番号、英字と数字が混ざる識別子、同音の多い入力は音声認識の弱点に当たる。前述のTwilioの実践集が英数字混在を名指しで挙げているのはこのためだ。会員番号、郵便番号、電話番号の確認、生年月日。この辺りが切替候補の筆頭になる。

一方で、キー入力に向かない情報もある。用件の説明のような自由な発話はキーでは入力できないし、住所のような文字情報も無理だ。だから全面切替ではなく、一項目ごとの仕分けになる。漢字を口頭で説明するより紙に書いて見せたほうが早いのと同じで、情報の種類ごとに合った伝え方がある。

なお、製品側の仕様確認もこの段階で行う。同じDTMFでもブロックごとに扱いが違うことがあり、たとえばAmazon Connectでは、前述の入力取得ブロック単体で受けられるキー入力は1桁（0-9、#、*）で、複数桁の番号は顧客の入力を保存するブロックで受ける構成がAWSの設計ガイダンスで示されている。自社の製品で「何桁まで・どのブロックで・終了キーは何か」を先に確かめておくと、設計の手戻りが減る。