2020年のコロナ禍をきっかけとしてボイスボットの導入や検討が進んでいます。
コールセンターで”人”が対応する業務を”自動”で応答するという大きな転換、DXであるため、チャットボットが導入され始めた2016年頃の勢いほどスピード感はないものの着実に広がりを見せています。
本記事ではボイスボットのシステムとしての基本的な仕組みや、あまり語られない細かなポイントを整理します。
ボイスボットの基本的な仕組み
ボイスボットは音声認識や音声合成エンジンといった音声系のエンジンと、AIシナリオを活用した自動応答ソリューションです。
業界全体での統一見解、定義のようなものは存在しませんが、当社が考えるボイスボットがどのような仕組みであるかを一つの例として解説していきたいと思います。
ボイスボットは「電話による消費者からの問合せ」を自動応答することを目的としていますが、同じ”ボイスボット”と呼ばれるものでも細かい仕様で異なる点があります。
チャットボットと似たような技術として捉えられる事も多いのですが、音声基盤との連携や転送に関する電話回線の仕様など音声系の知識も必要になることから、これらの仕組みを網羅的に理解するのは非常に難しいと言えます。
基本的な応答の仕組みについて順を追って解説します。
ボイスボットでは電話として着信した「音声」をリアルタイムでキャプチャするところから始まります。この音声をストリーミングし、まず初めに音声認識エンジンを通じて「テキスト」の情報に起こします。一度テキストになってしまえば後は自然言語AIや、キーワードによる条件一致などを踏まえてシナリオに沿った判定をしていきます。
ここで言う自然言語AIは汎用型人工知能のようなものが自然と洞察を行って回答を考える、というような事は行っておらず、あくまで”言葉のゆらぎ”をとらえる事に使われます。次の会話に進んでいく際は条件分岐が基本となりこれはいわゆる”ルールベース型”での会話の進展を指します。
- ルールベース＝古くてイケてない
- 汎用型人工知能＝新しくてすばらしい
というようなイメージを持たれる方も多いのですが、実際のコールセンターでも人間のオペレータは教育された「トークフロー」「トークスクリプト」に沿って電話応対を行います。
学習済みの汎用人工知能がシナリオ不要で回答を行うボイスボットと聞くと大変聞こえはいいのですが、裏を返せばまったく未経験の業務を研修無しに電話応対するようなもので、これがAIではなく人間だったとしても非常に難しい事だと感じてもらえるのではないでしょうか。
人間の場合も業務上のルールやトークスクリプトがある以上、あくまでルールに則って対応しているという事であり、お客様の発話を認識し何を意図しているかを解釈する部分（＝言葉のゆらぎの認識）に知能を使っている事を意味します。
そういった視点ではボイスボットもコールセンターのオペレータも同じようにルールベースでの会話の進展を行うわけです。
音声認識エンジンで音声をテキスト化した以降に行なっている処理はチャットボットに近いのですが、選択肢の提示やボタン表示、画像による説明が出来ないため「言葉」としてどのような会話が発生するかを綿密に組み立てる必要があります。選択肢であれば2択、3択のような条件を組めば問題ないですが、言葉による言い回しは言い方のバリエーションが非常に多くなり、言い回しの揺らぎを吸収するAIが力を発揮します。
ボイスボットが応答を行う際は、シナリオ上で発話するテキストを音声合成エンジンを用いて再び音声の世界に変換して電話回線上に流します。
ボイスボットにおいては音声認識の精度ももちろん重要な要素なのですが、実装するシナリオの適正さ、エンドユーザーの会話を企業が期待する方向に持って行くための流れや、想定する言い回しが非常に重要な要素となります。
ボイスボットから流すガイダンスを以下のように分けて考えてみると分かりやすいかもしれません。
- 本日のお問い合わせはどのような内容でしょうか
- 本日のお問い合わせは「解約」についてでよろしいでしょうか
①の場合、「解約」というフレーズ以外にも「サービスを中止したい」「契約を止めたい」というような発話が混じってきやすくなります。「解約」以外の問合せについて申告頂くことも想定して網羅的なシナリオを形成する必要があります。
②の場合、多くの回答は「はい」または「いいえ」というフレーズに収束しやすくなります。ボイスボットの全体的な精度やシナリオコントロールはこのようなユーザーの発話を誘導し、適切な問合せとして捉える事にあります。これらのシナリオ設計はコールセンターでの知見やノウハウが大いに活用できる部分でありベルシステム２４のようなアウトソーサーが得意とする領域になります。
関連動画のご紹介
ボイスボットに使われる代表的な技術
ボイスボットでは様々な技術的な要素が取り込まれており、音声認識や音声合成といった分かりやすい要素技術だけでなく、実は細かな点で使い勝手や精度があがるような仕組みとして工夫されています。まずは主な技術要素についてをお話します。
①自然言語AI
自然言語AIによるシナリオ遷移、分岐ができないタイプのボイスボットでは「発話内容」を元にした分岐を実装することができないため、最初から固定化されたシナリオ、またはヒアリング項目を聴取していくことにしか活用することができません。
例えば「解約」と「新規申込」という2つのシナリオを共存させ、発話によってシナリオを変えたいというケースは非常に多いのですがこのような分岐が難しいという事になります。
ボイスボットに応答させたい範囲、用途が狭い場合には全く問題ありませんが、より高度化を目指していく場合には自然言語AIによる分岐は不可欠な要素と考えています。
②音声認識エンジン
音声認識エンジンは、自社エンジンを採用しているベンダーとサードパーティ製品を利用しているベンダーとで分かれてきます。
自社製のエンジンをボイスボットに組み込んでいる場合、案件別に細かいチューニングやモデルの入れ替えなどができるため精度を細かいところまで上げられる点が良いのですが、GoogleやAmazon、Micorosoftといった膨大なデータを持っている企業が提供しているエンジンとは根本的な学習量が異なるためベースの認識精度は後者の方が高いと考えられます。
専門的なフレーズが複数登場するようなボイスボットではよりチューニングができる製品が望ましいですが、カスタマーとの会話等で利用するシーンでは後者のようなサードパーティ製のエンジンのほうが精度が高いこともあります。
これらは認識させたいフレーズや利用者の属性によって最適解が異なってくると考えます。
当社がこれまで行ってきた検証の一部をご紹介すると以下のような傾向がありました。
Google・・・
住所の認識精度が非常に高く、マンション名等も綺麗に認識が可能なケースが多い短文のフレーズよりも長文のフレーズの方が精度が高い傾向
MicroSoft Azure・・・
全体的な認識精度が高く、特に短いフレーズに強い。数字の認識などをした際に余計な句読点や漢数字での出力になる場合がある
このようにエンジン毎の強みや得意なフレーズを理解しているとボイスボットの精度をさらに向上することが可能になります。
またこれらの傾向、強み、全体的な精度は毎年変化しており定常的な検証が必要です。
③音声合成エンジン
音声合成エンジンについても自社製のエンジンとサードパーティ製品を利用しているベンダーとで分かれますが、当社の見解ではサードパーティ製の製品を活用しているケースの方が多いように思います。
当社でも音声合成エンジンを提供している企業の製品をいくつか検証しましたが、人が喋っている声にかなり近いレベルまで到達しており、人間そのままとまでは言えないものの、非常にクオリティは上がってきているのが現状です。声の種類、性別や方言などに対応しているエンジンも多く、芸能人やアナウンサーなど多様な声を使う事が可能になってきています。
然しながら音声合成の目的はテキストデータをユーザーに声として届ける事であり、声の種類や声の独立性、ユニークさにこだわる導入企業は少なく「伝わること」が重要になります。
「伝わる」という観点では音声合成エンジンはどれもクオリティが高く、全く問題がないレベルだと感じています。
④PBX（電話交換機）との接続
ボイスボットではＰＢＸと直接的に接続する内線型タイプのものと、外線転送によって応答させる外線型タイプのものが存在します。
これらはボイスボットそのものが電話回線を収容する仕組みをもっているか、いないかによって異なってきます。
PBXとの接続方式を” 内線型”とする場合、ボイスボットは電話収容の仕組みを持たず、あくまでアプリケーションとして動くイメージになります。この際に大きく影響を受けるのはオペレータ転送時の際の挙動になります。内線型のボイスボットではPBXと直接連携をするためボイスボットをオペレータの一人のようなイメージで構築することができ、ボイスボットからオペレータに転送しその情報を引き継いだり、オペレータからボイスボットに再度転送したりといった柔軟な活用方法が可能です。
また、内線網を通じてやりとりを行うため、転送費用が抑えられるといったメリットもあります。
外線型のボイスボットでは一度ボイスボットが電話回線として呼を収容し、そこからまた物理的に全く異なる電話基盤への転送を行うことになります。この場合は外部への電話転送となるため転送料がかかったり、オペレータ転送時にボイスボットの応答内容がシームレス、リアルタイムに引き継げない等のデメリットがあります。然しながらこれらのデメリットは「オペレータへの転送」を行わない業務でのボイスボットの導入においてはあまり影響がない為、完全に自動化したい業務をスコープとしている場合には外線型のボイスボットでも十分に検討する余地があります。
PBX（電話交換機）とボイスボットアプリケーションを連携させるという点は、各企業の情報システム部やPBXベンダーとの連携が必須になり、社内調整プロセスや責任分界点が複雑化する点や、PBXの更改時期などの兼ね合いから多少コストがかかっても外線型のボイスボットを検討されるケースも多いのが現状です。
ボイスボットとして実装した場合の細かな技術介入ポイント
ボイスボットの製品では前述した基本的な要素技術以外にも同じように見えて少しずつ仕様やできる事、操作感が異なっているのが現状です。具体的に上げられる細かい点を記載していきます。
・音声認識の開始時の挙動
ボイスボットでの自動応答は、ユーザーに対してボイスボットが「どのようなお問い合わせですか？」「電話番号をお話しください」というように話しかける事からスタートします。
この際、音声認識を行いユーザーの発話内容を解析する事になるのですが、音声認識のスタート時にbeep音などを流して発話タイミングを通知する製品と、何も通知をしない製品とが存在しています。
どちらが優れているという事ではないのですが、ボイスボットの使用になれている場合はどちらでも特に問題なく操作を開始できるものの、あまり慣れていない方の場合は「どのタイミングで話したらよいか分からない」といったユーザークレームに繋がってしまいます。
当社でも以前に発話開始のbeep音無しでボイスボットの導入をしていたところ、エンドユーザーから「発話タイミングが分からない」というご意見を頂き、急遽beep音を追加したという経緯があります。
より幅広いユーザーがボイスボットを体験・経験するまでの間は、beep音などによる認識開始時の通知があったほうが消費者に優しいボイスボットであると考えています。
・発話終了検知方法
ユーザーがボイスボットへの発話を終えたかどうかを、どのような方法で検知するかはボイスボットによって様々です。
①プッシュ操作による発話終了検知
発話終了の度に＃ボタンを押すなどで発話が終わった事をボイスボットにしらせる方式です。この場合ユーザーは発話の度にボタンを押す必要があり、ユーザビリティとしては使いにくい印象を与えてしまう恐れがあります。
②秒数による発話終了
例えば5秒間認識をして判定する、というような仕組みになります。
この方式の場合、1秒でお客様が言い終わった場合は4秒の待機時間が発生したり、発話に6秒かかったばあいは5秒分の発話で次のシナリオ遷移へ進むかどうかが判定されるため、利用する顧客によってはうまくかみ合わないことが想定されます。
「はい」「いいえ」のように非常に短いフレーズや、発話する内容のバリエーションが非常に少ないシーンではこのような発話終了を実装したほうが良い場合もありえます。
③無音検知による発話終了
お客様が発話終了した後、何も喋っていない状態（＝音声来ていない状態）を検知し、無音が〇秒経過したら発話を終えたと判定する方式です。
この方式はお客様の話すスピードが速くても遅くても認識終了を的確にとらえることが可能ですが、以下のようなデメリットもあります。
- 周囲の雑音が多い場合、発話終了を検知できない
- 発話途中で一旦喋るのを止めてしまうと発話終了として検知されてしまう
契約者IDのような手元の資料を確認しないと回答ができないフレーズの場合は、一度発話が止まってしまうことも想定されます。これらを加味して検知終了の仕組みを検討する必要があります。
④単語取得による発話終了
例えば電話番号などが分かりやすいのですが、10桁、11桁の数字を認識できるまで認識を継続するという方式になります。必要な情報が聴取でき次第、発話終了と判定するため後続の処理にスムーズに移行することができますが、「住所」や「問合せ内容」のようなより複雑な内容になってくると、聴取ができているかどうかの判定ロジックが難しくなってしまい、単語取得の判定ができないものもあります。
このように顧客が発話を終えた事を認識する方法も様々ですが、実際のボイスボット構築の際にはそれぞれの長所と短所を理解し、顧客の利用シーンと紐づけつつ組み合わせていくことが重要になります。
・同時接続回線数
ボイスボットは自動応答という仕組みから無限に応答が可能な印象がありますが、実際にはシステム的な応答には物理的な限界があります。
同時にどのくらいまでの電話応答が必要となるかを事前に算出するのはなかなか難しい面もありますが、ある程度の呼量を想定し応答計画を立てる必要があります。
ボイスボットの中では電話回線としてどのくらいを着信、応答させるかという観点と、その際にアプリケーション側で発生する処理にどのくらいのインフラが必要か、という2つの観点で試算する事が求められます。
当社がこれまでに実装してきたボイスボットでは０～５ch程度の入電が大半で、呼量の非常に多い案件（月数万件レベル）でも10～20chの同時接続で十分応答が可能と試算しています。
選定するボイスボットのキャパシティもこれらを加味していく必要があります。
・シナリオの編集
ボイスボットに応答させるシナリオは一度リリースして終わりになる事はほとんどありません。
構築後に見直し、改善を行い離脱しやすいポイントがどこなのか？どのように改善したら良いのかを試行錯誤し、全体の完結率を高めていく活動が必要となります。
この際にシナリオの編集がどの程度の難易度、工数となるかも重要な観点の一つとなります。
ノーコードのGUI上で編集ができるシナリオであれば比較的操作スキルが無い方でもシナリオを構築・編集する事ができるためシナリオ編集の難易度は下がりますが、その分複雑な条件分岐やロジックをもってシナリオ遷移を判定するような事は難しくなります。
ローコードベースでのシナリオ作成の場合は、編集に必要なスキルが一段と高まってしまう反面、より柔軟にシナリオを編集する事が可能となり、より細かい条件でのシナリオ制御が可能となります。
- シナリオ編集を今後行っていくのか
- 誰がシナリオ編集する必要があるのか
というような観点でリリース後の運用体制を考慮し、最適なシナリオ編集方法を実装したボイスボットを選定する必要があります。
まとめ
本記事でご紹介したボイスボットの仕組みやポイントはあくまで一部となり、実際にはさらに細かな点で技術仕様や機能に違いがあります。
実際の製品比較などの際にはより慎重にできる事、できない事を考慮し比較する必要が出てきます。
ベルシステム２４では、これらの判断が難しいお客様向けに導入前のコンサルティングやPOCの設計など、お客様のニーズやご予算感に合わせた知見の提供も行っていますので、実際の比較検討で悩まれている際にはぜひ一度ご相談いただけるとお力になれるのではないかと考えています。
ベルシステム24が提供する自動応答プロダクトはこちら
コールセンター自動化 AIチャットボット・AIボイスボット ekubot
