LASSIC Media らしくメディア
ボイスボットの選び方｜電話応対をAIで自動化する外注
LASSIC IT事業部｜元請（プライムベンダー）として業務システムの開発・運用を受託
この記事のポイント
- ボイスボットは、電話の音声を音声認識(ASR)でテキスト化し、対話管理で意図を解釈し、音声合成(TTS)で応答を返すという流れで、電話応対の一次対応を自動化する仕組みです。テキストで完結するチャットボットとは接点が異なります。
- 従来のIVRが番号のプッシュ操作(DTMF)で分岐するのに対し、ボイスボットは自然な発話を受け付ける点に違いがあります。CTIが担う着信制御とも役割が分かれます。
- 外注時は、音声認識の精度と対象語彙、有人オペレーターへの切替設計、CRM・基幹システムとの連携と発話ログの扱い、そして個人情報を含む音声データの管理が確認の軸になります。
目次
電話応対の一次対応がオペレーターを圧迫しやすい理由
コールセンターや代表電話の窓口では、営業時間内に着信が集中すると、一次対応だけでオペレーターの手がふさがってしまいがちです。「営業時間の確認」「住所変更の受付」「配送状況の問い合わせ」といった定型的な用件が全体の一定割合を占め、そのたびに人が同じ説明を繰り返すことになります。定型対応に人手が取られると、本来は人が丁寧に向き合うべき込み入った相談への対応が後回しになりかねません。
電話という接点には、時間の制約もついて回ります。夜間や休日の着信は取りこぼしやすく、着信の集中する時間帯には待ち時間が延びて、機会損失につながる場合もあるでしょう。従来のプッシュ操作型の自動音声応答(IVR)を入れている窓口もありますが、「番号を何度も押させる」「目的のメニューにたどり着けない」といった使いにくさが残りがちです。
こうした課題への打ち手として関心を集めているのが、電話の音声をそのままAIで受け止めて応答する「ボイスボット」です。話し言葉で用件を伝えれば、システムが内容を解釈して回答したり、必要な情報を聞き取ったりします。本稿では、ボイスボットの仕組みと構成要素を、クラウド各社の公式ドキュメントに基づいて整理し、チャットボットや従来IVR・CTIとの違い、開発を外注する際の確認点までを解説します。読者として想定しているのは、電話窓口の自動化を検討するIT・事業部門の担当者です。
ボイスボットとは、電話の音声をAIで自動応答する仕組み
ボイスボットとは、電話でかかってきた音声を受け取り、AIによって内容を理解して音声で応答する仕組みを指します。中心にあるのは大きく3つの技術です。話された音声を文字に起こす音声認識(ASR)、文字になった用件から意図をくみ取って応答を決める対話管理、そして応答文を人の声に近い音声へ変える音声合成(TTS)です。これらを電話網とつなぐことで、人が出るのと同じように電話越しのやり取りが成立します。
入口となる音声認識について、クラウド各社は音声をテキストへ変換する機能を提供しています。たとえばあるクラウドの音声認識サービスは、音声認識技術をアプリケーションに組み込むためのAPIとして位置づけられており、マイクやファイルから入力された音声を認識してテキスト化します*3。別のクラウドの音声認識は、リアルタイムの文字起こしに加えて、通話録音のような大量音声を一括処理するバッチ文字起こしにも対応するとされています*1。同サービスの解説では、対話型音声応答システムがユーザーの問い合わせやコマンドを文字起こしする用途が例として挙げられています*1。電話応対の自動化は、まさにこの用途に重なる領域だといえるでしょう。
応答を返す出口では、音声合成が使われます。あるクラウドの音声合成は、テキストを人間に近い合成音声へ変換する機能で、深層学習を用いたニューラル音声によって、明瞭な発音と自然な抑揚を実現するとされています*2。別のクラウドの音声合成でも、テキストやマークアップを自然な合成音声として生成できると説明されています*4。ボイスボットは、この入口(認識)と出口(合成)の間に対話管理を挟み、電話という一本の通話のなかで対話を成立させる点に特徴があります。
チャットボット・従来IVR・CTIとの違い——音声で対話を完結させるか
ボイスボットは、AIチャットボットや従来型のIVR、CTIと機能が一部重なるため、混同されやすい存在です。しかし、担う接点と中核となる技術はそれぞれ異なります。ここで整理しておくと、自社に必要なのがどれかを見極めやすくなります。
まずAIチャットボットは、Webサイトやチャットアプリ上でテキストの問い合わせに応答する仕組みで、接点はあくまで文字によるやり取りです。一方のボイスボットは、電話の音声を接点とし、話し言葉で対話を完結させます。両者は意図理解の考え方に共通点がある一方で、音声認識と音声合成という音声固有の処理を前後に必要とする点でボイスボットは異なります*1*2。
従来のIVRは、「ご用件が○○の方は1番を押してください」といった音声ガイダンスに対し、利用者が電話機の番号を押すDTMFで分岐する方式が中心でした。あらかじめ用意したメニューツリーをたどらせるため、選択肢が増えるほど操作が煩雑になりがちです。ボイスボットは、番号操作ではなく自然な発話を受け付け、用件そのものを解釈して応答する点で、従来IVRを自然言語で置き換える位置づけになります。既存のIVRを土台にしつつ、入口だけを音声対話に置き換える構成も考えられるでしょう。
CTIは、電話交換機とコンピューターを連携させる技術で、着信の振り分けや、着信時に顧客情報を担当者の画面へ表示するといった制御を担います。CTIそのものは対話の中身を扱うわけではなく、通話をどう捌くかという制御が主な役割です。ボイスボットはこのCTIと競合するものではなく、CTIが担う着信制御の先で、実際の応対を自動化する役割分担になります。整理すると次の通りです。
| 項目 | AIチャットボット | 従来IVR | CTI | ボイスボット |
|---|---|---|---|---|
| 主な接点 | Web・チャットのテキスト | 電話（音声ガイダンス） | 電話（着信制御） | 電話（音声対話） |
| 利用者の入力 | テキスト入力 | 番号のプッシュ操作（DTMF） | 発着信そのもの | 自然な発話（音声） |
| 中核となる技術 | 意図理解（テキスト） | 音声ガイダンス＋DTMF分岐 | 電話交換機とPCの連携 | 音声認識＋対話管理＋音声合成*1*2 |
| 自然言語への対応 | 対応（テキスト） | 原則メニュー選択のみ | 役割の対象外 | 対応（音声）*3 |
| 主な役割 | テキストでの自己解決 | メニューでの振り分け | 着信制御・情報表示 | 電話応対の一次対応の自動化 |
どれか一つを選ぶという話ではなく、実際には組み合わせて使う構成が現実的です。CTIで着信を制御し、ボイスボットが一次対応を担い、複雑な用件はチャットボットではなく有人オペレーターへ引き継ぐ、といった役割分担が考えられます。要件を決める前に、自社の窓口で自動化したいのが電話なのかテキストなのか、その接点をはっきりさせておくと、選択がぶれずに済むでしょう。
ボイスボットの構成要素——音声認識(ASR)・対話管理・音声合成(TTS)
ボイスボットの品質は、3つの構成要素の作り込みと、それらをつなぐ設計で決まります。ここでは各要素の役割を、公式ドキュメントに沿って整理します。
音声認識(ASR)——話し言葉を精度よくテキストにする
音声認識(ASR)は、通話の音声をテキストに変換する入口の処理です。あるクラウドの音声認識は、リアルタイムの文字起こし、予測可能な低遅延を狙う高速文字起こし、大量音声を扱うバッチ文字起こしといった複数の方式を備えています*1。同サービスには、会話中の話者を区別する話者分離の機能があり、解説では1つの録音のなかで35人までの話者を識別できると説明されています*1。加えて、業界特有の用語や固有名詞をあらかじめ登録して認識精度を高めるフレーズリストや、用途に合わせて認識モデルを調整するカスタム音声にも触れられています*1。別のクラウドの音声認識では、1分以内の音声を扱う同期認識と、長時間の音声を扱う非同期認識があり、音源を選べる場合は16000Hzのサンプルレートでの取得が推奨されています*3。言語はBCP-47の識別子で指定します*3。自社の業務で使う専門用語や商品名が多い場合は、この認識精度をどこまで作り込めるかが実用性を左右します。
対話管理——意図を解釈し、次の応答を決める
対話管理は、テキスト化された発話から利用者の意図をくみ取り、次に何を返すか、何を聞き返すかを決める頭脳にあたる部分です。あるクラウドの対話プラットフォームでは、エージェントを自然言語理解(NLU)のモジュールとして位置づけ、会話中の利用者のテキストや音声を、アプリケーションが扱える構造化データへ変換すると説明されています*5。同ドキュメントは、このエージェントを人間のコールセンターのオペレーターにたとえ、想定される会話シナリオを学習させて対応させる、と表現しています*5。対話の流れはフローやページ、状態ハンドラといった構成要素で組み立てられます*5。用件が単純な確認で終わるのか、複数の情報を順に聞き取る必要があるのかによって、設計の作り込み度合いは変わってきます。
音声合成(TTS)——応答文を自然な音声にする
音声合成(TTS)は、対話管理が決めた応答文を、電話越しに聞きやすい音声へ変える出口の処理です。あるクラウドの音声合成は、深層学習によるニューラル音声で自然な抑揚を実現し、SSMLと呼ばれるマークアップで、話す速さや間の取り方、抑揚、音量、発音などを細かく調整できるとしています*2。同サービスは、10分を超える長文の音声化には非同期のバッチ合成を、対話のような即時応答にはリアルタイム合成を用いると使い分けを示しています*2。別のクラウドの音声合成でも、言語・性別・アクセントで音声を選べ、話す速さやピッチ、音量を設定できると説明されています*4。電話では聞き取りやすさが体験を大きく左右するため、読み上げの自然さと、間や速度の調整が要点になります。
有人切替とCRM連携——自動と人手をつなぐ設計
ボイスボットを実運用するうえで欠かせないのが、自動応答で解決できない用件を有人オペレーターへ引き継ぐ切替の設計です。認識がうまくいかない、想定外の相談が来た、あるいは利用者が「担当者と話したい」と求めた場合に、どの条件で、どのタイミングで人へつなぐかを決めておく必要があります。切替の際に、それまでの発話内容や聞き取った情報をオペレーターへ引き渡せると、利用者が最初から用件を話し直す手間を避けられます。
あわせて、CRMや基幹システムとの連携も設計の要になります。顧客の登録情報を参照して本人確認を補助したり、聞き取った内容を応対履歴として書き戻したりする連携があると、電話応対が後続の業務とつながります。通話の音声認識結果である発話ログは、応対品質の振り返りや、認識精度・対話フローの改善にも役立つ資産です。一方で発話ログには個人情報が含まれ得るため、保存範囲やマスキング、保持期間といった管理方針を、後述の外注時の確認点として押さえておく必要があります。
ボイスボットの開発を外注する際に確認したいこと
ボイスボットは、音声認識の精度と既存業務との連携が使い勝手を大きく左右します。開発を外注する際は、次の点を委託先とすり合わせておくと、後戻りを抑えやすくなります。
音声認識の精度と対象範囲を具体化する
まず、どんな用件を、どの程度の精度で自動化したいのかを具体化します。自社の業務で頻出する専門用語や商品名、地名などをフレーズリストやカスタムモデルでどこまで作り込むか、対象とする言語や方言をどう指定するかを、委託先と早い段階で共有しておきましょう*1*3。電話回線ごしの音声は品質にばらつきが出るため、想定する通話環境での認識精度をどう検証するかも決めておきたいところです。「すべてを完全に自動化する」ではなく、確度高く自動化できる用件から段階的に広げる前提で範囲を切り分けると、見積りと期待値のずれを抑えられます。
有人切替と通話フローの設計をすり合わせる
次に、自動応答と有人対応の境目をどう設計するかを確認します。認識できなかったときの聞き返しの回数、有人へ切り替える条件、切替時に引き継ぐ情報の範囲を、具体的なシナリオに落として合意しておくことが大切です。既存のIVRやCTI、コールセンターの運用を残す場合は、それらとの接続点も論点になります。実際の通話を想定したテストで、利用者がストレスなく用件を伝えられるかを確かめる工程を、あらかじめ計画に含めておきましょう。
CRM・基幹システムとの連携方式を設計する
ボイスボットは、顧客情報や応対履歴を扱うCRM・基幹システムと連携してこそ、応対が業務につながります。連携の方式や、書き戻すデータの項目、リアルタイム連携が必要な範囲を早めに設計しておくと、二重入力や転記の手間を減らせます。既存システムの改修が必要になる範囲も、あわせて見積りに含めておきたいところでしょう。
音声データと個人情報の管理を確認する
通話音声や発話ログには、氏名・連絡先・問い合わせ内容といった個人情報が含まれ得ます。録音と発話ログの保存範囲、マスキングの要否、保持期間、アクセス権限の管理を、自社のルールや関連法令に沿ってどう実装するかを委託先と確認しておく必要があります。あわせて、利用する音声認識・音声合成サービスのデータの取り扱い方針も、公式ドキュメントで一次情報をたどれる体制かどうかを見ておきたい点です。稼働後の運用や改善を内製へ移すことも見据えるなら、対話フローや連携仕様のドキュメント整備状況も確かめておくとよいでしょう。
まとめ：ボイスボット導入で押さえる判断の軸
本稿では、ボイスボットの仕組みと構成要素を、クラウド各社の公式ドキュメントに沿って整理しました。要点は3つに集約できます。第一に、ボイスボットは電話の音声を音声認識(ASR)でテキスト化し、対話管理で意図を解釈し、音声合成(TTS)で応答を返すという流れで、電話応対の一次対応を自動化する仕組みです*1*2*3。第二に、テキストで完結するチャットボット、番号操作で分岐する従来IVR、着信を制御するCTIとは接点も役割も異なり、実際には組み合わせて使う構成が現実的です。第三に、外注時は音声認識の精度と対象範囲、有人切替と通話フロー、CRM・基幹システムとの連携、そして音声データと個人情報の管理が確認の軸になります。自社の窓口でどの用件から自動化するかを見極め、確度の高い範囲から段階的に広げることが、導入の出発点になるといえるでしょう。
よくある質問
ボイスボットとチャットボットは何が違いますか。
チャットボットはWebサイトやチャットアプリ上のテキストを接点に応答します。ボイスボットは電話の音声を接点とし、話し言葉で対話を完結させる点が異なります。そのため、音声をテキスト化する音声認識(ASR)と、応答文を音声に変える音声合成(TTS)という、音声固有の処理を前後に必要とします*1*2。
従来のIVRとどう違うのですか。
従来のIVRは、音声ガイダンスに対して電話機の番号を押すDTMFでメニューを分岐させる方式が中心でした。ボイスボットは番号操作ではなく自然な発話を受け付け、用件そのものを解釈して応答するため、従来IVRを自然言語で置き換える位置づけになります*3。既存のIVRを土台に、入口だけを音声対話へ置き換える構成も考えられます。
ボイスボットで対応できない用件はどうなりますか。
自動応答で解決できない用件は、有人オペレーターへ引き継ぐ設計にしておくのが一般的です。認識がうまくいかない場合や、利用者が担当者との会話を求めた場合など、切り替える条件とタイミングをあらかじめ決めておきます。切替時にそれまでの発話内容を引き渡せると、利用者が用件を話し直す手間を避けられます。
音声認識の精度はどこまで期待できますか。
精度は通話環境や扱う用語によって変わります。クラウドの音声認識では、業界特有の用語や固有名詞を登録するフレーズリストや、用途に合わせた認識モデルの調整といった仕組みが用意されています*1。自社の専門用語や商品名が多い場合は、これらをどこまで作り込むか、想定する通話環境でどう検証するかを委託先とすり合わせておくことが大切です。
ボイスボットの開発を外注する場合、何を確認すればよいですか。
自動化する用件の範囲と音声認識の精度、有人オペレーターへの切替と通話フロー、CRM・基幹システムとの連携方式が、まず確認したい項目です*1*3。加えて、通話音声や発話ログに含まれる個人情報の保存範囲・マスキング・保持期間といった管理方針もすり合わせておくと、後戻りを抑えやすくなります。確度の高い用件から段階的に広げる前提で範囲を切り分けることが出発点です。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：Microsoft「Speech to Text Overview（音声テキスト変換の概要）」（Azure AI Speech ドキュメント）（https://learn.microsoft.com/en-us/azure/ai-services/speech-service/speech-to-text）
- *2 出典：Microsoft「Text to speech overview（テキスト読み上げの概要）」（Azure AI Speech ドキュメント）（https://learn.microsoft.com/en-us/azure/ai-services/speech-service/text-to-speech）
- *3 出典：Google Cloud「Cloud Speech-to-Text overview」（Cloud Speech-to-Text ドキュメント）（https://docs.cloud.google.com/speech-to-text/docs/overview ）
- *4 出典：Google Cloud「Cloud Text-to-Speech basics」（Cloud Text-to-Speech ドキュメント）（https://docs.cloud.google.com/text-to-speech/docs/basics ）
- *5 出典：Google Cloud「Dialogflow CX agents」（Conversational Agents / Dialogflow CX ドキュメント）（https://docs.cloud.google.com/dialogflow/cx/docs/concept/agent ）
