ボイスボットとは？仕組み・できること・導入の基本

電話が集中してつながりにくい。営業時間外の問い合わせを受けられない。担当者が同じ説明を繰り返している。こうした課題への対応策の一つが、音声で会話する「ボイスボット」です。

検討するときは、会話の自然さとあわせて、どの用件をどこまで任せるかを確認しましょう。希望を聞いて記録する受付と、システム上の変更を終える受付では、必要な準備も評価の方法も変わります。

この記事でわかること

• ボイスボットの仕組みと、IVR・生成AIとの関係
• 活用できる業務と、人への引き継ぎが必要な場面
• 会話・業務処理・引き継ぎを分けた評価の考え方

ボイスボットとは

ボイスボットは、人の発話を受け取り、用件を解釈して、音声で応答する自動対話の仕組みです。 電話窓口では、よくある質問への回答、問い合わせの振り分け、予約情報の聞き取りなどに使われます。

「音声AI」は、文字起こしや通話の要約、応対の分析なども含む広い呼び方です。その中で、利用者と直接、音声でやり取りする役割を持つのがボイスボットです。チャットボットとは、主な接点が文字か音声かという違いがあります。

ボイスボットという名称だけで、できる業務は決まりません。用件を聞いて担当者に渡す製品もあれば、外部システムと連携して照会や登録まで行う構成もあります。製品を比べる際は「自動対応」の中身を確かめることが出発点です。

音声対話は、どのように動くのか

一般的な構成では、まず音声認識で発話を文字などの情報に変換します。次に、対話を制御する仕組みが用件や必要な項目を把握し、回答や追加の質問を決めます。その内容を音声合成で読み上げることで、会話が続きます。

図1：会話から処理結果までの往復。本文の関係や手順を整理した図。

たとえば「明日の予約を夕方に変えたい」という発話には、変更の依頼、対象の予約、変更後の日時といった情報が含まれます。「夕方」が何時なのか、どの予約なのかが曖昧なら、追加で確認する必要があります。

予約を実際に変更するには、本人確認や空き状況の照会、予約システムへの更新も必要です。APIは、こうしたシステム同士の処理をつなぐ窓口です。ボイスボットが「変更しました」と答える前に、システム側で更新が成功したことを確かめる設計が求められます。

近年は音声認識・生成AI・音声合成を統合して扱う基盤や、音声を直接入出力するモデルも登場しています。上の図は理解のための機能の整理であり、内部処理を一つの方式に限定するものではありません。

IVR・生成AIを使う方式との違い

IVRは自動音声応答の仕組みで、広く知られているのは「予約は1番、お問い合わせは2番」のように番号選択で分岐する方式です。音声認識を組み合わせるIVRもあり、IVRとボイスボットの境界は呼称によって重なります。

生成AIは、さまざまな言い方の理解や、文脈に沿った応答の組み立てに活用できます。一方で、予約の確定や契約情報の更新は、許可された手順・権限・入力確認に沿って実行する必要があります。会話の理解と、実際の処理を許可する条件を分けて設計します。

「AI IVR」「音声AIエージェント」といった名称も使われますが、名称だけで機能の優劣は判断できません。プッシュ入力と音声入力を併用できるか、会話の途中で人につなげられるかなど、実際の動作を確認しましょう。

ボイスボットにできること・活用例

導入候補にしやすいのは、答えや処理の手順を整理できる業務です。営業時間や手続きの案内、問い合わせの一次分類、予約希望の受付、配送状況などの照会が挙げられます。確認やリマインドの発信も用途の一つですが、受電とは別に対象者や実施時間、停止方法などの運用を決めます。

図2：予約対応は三つの範囲に分かれる。本文の関係や手順を整理した図。

「予約対応」も、任せる範囲で要件が変わる

図2は予約対応を例にした、説明用の架空の整理です。聞き取りだけなら、必要な項目がそろった時点を受付完了にできます。照会や変更まで任せる場合は、本人確認、データへのアクセス、更新結果の確認が加わります。

導入のメリットは、定型の問い合わせを自動で受けられること、担当者が個別判断の必要な相談に時間を使いやすくなること、受付の内容を一定の項目でそろえられることです。時間外の受付も、システムの稼働条件や、その場で解決できない用件の扱いを整えれば検討できます。

ただし、受付件数が増えても、後で人がすべて聞き直す運用では負担が残ります。自動で受けた件数に加え、顧客の用件がどこまで進んだか、担当者の後処理がどう変わったかを確認しましょう。

苦手なことと、人への引き継ぎ

雑音の多い場所や複数人の同時発話、固有名詞の聞き取り、曖昧な依頼などでは、確認のやり取りが増えることがあります。「日本語対応」という表記だけで判断せず、自社の商品名や住所、電話回線の音質を含めて試すことが必要です。対応する言語や入力方法、認識できなかった場合の案内は、実際の構成で確かめます。

個別の裁量が必要な相談、緊急性のある連絡、強い不満を伴う問い合わせなどは、人が判断する経路を用意します。長い説明や書類の確認が必要な場合は、別の連絡手段を案内する方が進めやすいこともあります。

引き継ぎの際は、用件の要約、確認済みの情報、実行した処理、まだ終わっていない内容を担当者が把握できるようにします。「予約変更を希望。本人確認済み。空き状況の照会中にエラー」と分かれば、対応を再開する場所が明確になります。

同じ質問を何度も繰り返す場合や、利用者が人との会話を希望した場合の動きも、事前に決めておきましょう。有人窓口の営業時間外には、折り返し受付や別の連絡経路が必要です。

導入前に整理すること

最初からすべての電話を対象にするより、問い合わせ理由を棚卸しして、完了条件を説明しやすい業務から試すと、結果を評価しやすくなります。次の5点を、窓口の担当者とシステムの担当者で共有しましょう。

対象の用件と、完了の条件

問い合わせの件数・時間帯・対応時間を調べ、「聞き取りまで」「照会まで」「更新まで」の範囲を決めます。対象外の相談も明記します。

回答の根拠と、更新する担当者

FAQ、料金、営業時間などの正しい情報を整理します。変更時に誰が承認し、いつ反映するかまで決め、根拠がない質問の扱いも用意します。

連携先と、処理できる権限

既存の電話設備、予約・顧客管理システム、本人確認の方法を確認します。登録・変更は入力内容を確認し、二重処理や連携エラー時の動きも試します。

人が対応する条件と、障害時の経路

緊急性、認証失敗、利用者の希望などの転送条件を整理します。転送先が応答しない場合と、システムが停止した場合の案内も必要です。

費用と、試験運用の判定条件

初期設定、システム連携、月額・従量料金に加え、FAQの保守や有人対応にかかる工数も見ます。小さく試し、継続・修正・停止の判断条件を先に決めます。

録音・文字起こしの取り扱いも確認する

個人情報保護委員会のQ&Aでは、個人を識別できる通話内容は個人情報に該当し得ることが示されています。録音や文字起こしの利用目的、保存期間、アクセス権、委託先、学習への利用の有無などを、利用サービスの契約・設定とともに確認します。

また、AIが応答していることや、利用者が困った場合の連絡方法を分かりやすく伝えることは、運用上の配慮になります。自社の業務に応じて安全性やプライバシー、透明性などを点検しましょう。

効果は、会話・完了・顧客体験から測る

自動応答した割合だけでは、導入の成果は分かりません。応答を待つ時間、聞き返し、無音、処理のエラーなど、会話のどこで止まったかを確認します。

たとえば用件完了率を「AIに任せる対象用件のうち、決めた完了条件に到達した件数の割合」と定義すれば、単に電話を受けた件数と区別できます。対象用件、分母、測定期間をそろえ、導入前の状態と比較しましょう。転送が必要な用件を適切に人へ渡したことも、別に評価します。

会話の一往復を分解すると、試す場所が見えてくる

ボイスボットの品質は、声の自然さだけで決まるものではありません。相手が話し始め、言葉を捉え、用件を整理し、必要な情報を調べ、返答するまでの一連の動作で評価します。発音が聞きやすくても、毎回長く待たされたり、説明の途中で応答されたりすると、利用者は話し方を合わせなければならなくなります。

たとえば相手が「来週の予約を、ええと、金曜日に変更したい」と話す場合、「ええと」の前後で考える時間が入ります。途中の間を会話の終了と誤って扱うと、希望日を言い終わる前に次の質問が始まります。反対に、話し終わっているのに待ち続けると、相手は聞こえているか不安になり、同じ内容を繰り返すかもしれません。

このため試験では、短い発話だけでなく、考えながら話す、途中で訂正する、説明を聞いてから答え直す、といった会話も含めます。利用者側の速度や環境を一つに固定しないことが重要です。特定の話し方に合わせたデモだけでは、実際の窓口で起こる困りごとを十分に確認できません。

聞き取った文字と、業務上の意味を別に確かめる

音声を正しい文字へ変換できても、用件の理解が正しいとは限りません。「明日の予約は変更しなくてよくなりました」は、変更の依頼ではなく、変更をしない意思を伝えています。「変更」という言葉が含まれるだけで処理を始めないよう、否定や取り消しを含めて試します。

固有名詞についても、見た目が似た表記をそろえることと、本人や対象の予約を特定することは別です。名前を聞き取れたからといって、同姓同名の別の記録を選んでよいわけではありません。必要な確認方法は業務の管理ルールに従い、候補が複数ある場合は追加確認や有人対応へ進めます。

質問は一度に詰め込まず、処理に必要な単位に分けます。「お名前、電話番号、ご希望の日付をお願いします」とまとめて聞くと、一部だけ回答された際に何が不足したかを判断する必要があります。順に確認する場合も、相手が先に伝えた情報を保持し、同じ項目を機械的に聞き直さないことを確認します。

読み上げる情報を、電話で理解できる形に整える

Webの文章をそのまま読み上げると、括弧書きや長い条件、似た名称が続いて理解しにくくなることがあります。電話では前の文章を目で読み返せないため、結論、必要な条件、次の行動の順で短く区切ります。詳しい説明が必要なら、途中で相手の理解を確かめる構成にします。

日付や金額、受付番号は、聞き間違いが後の仕事に影響しやすい項目です。日付は月日と必要に応じた時間帯を確認し、「来週」「夕方」のまま処理しないようにします。長い番号は区切って読み、どの部分を聞き直したいかを確認できると、すべてを最初から読み直す負担を減らせます。

シナリオと知識を分けて管理する

シナリオは、何をどの順に聞き、条件によってどう進むかを決めるものです。一方、知識は、営業時間、手続き、対象商品など、回答の根拠となる情報です。両方が一つの長い文章に混ざっていると、料金を変えるだけの修正で会話の分岐まで変わってしまうことがあります。

実務では、変わりやすい情報の管理先と、判断のルールの管理先を明らかにしておくと更新しやすくなります。たとえば営業時間の案内文と、営業時間外に折り返し受付へ進む条件を区別します。営業時間が変わった際は、読み上げ内容だけでなく、受付を切り替える条件にも変更が必要かを確認します。

情報が見つからない質問には、推測で埋めるのではなく、回答できる範囲を伝える動作が必要です。「その条件については確認が必要です」と案内して担当者へ渡すことも、設計された正常な経路になります。答えられる質問を増やすときは、新しい根拠を整え、以前の回答と食い違わないかを試してから対象を広げます。

システム連携は、依頼と結果を一件で追えるようにする

ボイスボットから予約や顧客管理のシステムへ処理を依頼する場合、依頼を送ったこと、相手側で受け付けたこと、実際に更新が済んだことを区別します。応答が途切れた場合は、処理が失敗したのか、成功したが返事を受け取れなかったのか、その時点では分からないことがあります。

たとえば予約変更の後で通信が途切れた場合、同じ変更を無条件に繰り返すと、重複や想定外の状態につながる可能性があります。処理の識別情報や照会方法を用意し、現在の状態を確認してから次の行動を決める設計が必要です。具体的な実装は連携先の仕様に合わせます。

お客様への案内も、把握できている事実に合わせます。「変更結果を確認できていないため、担当者が確認します」と伝える状況と、「変更が完了しました」と伝える状況を分けます。分からない状態を曖昧な成功表現で包むと、後から担当者が説明を修正しなければならなくなります。

読み取りだけで始める構成と、書き込みまで許可する構成も分けて検討してください。照会はできても更新は行わない、更新前に人が内容を確認するなど、段階を設ける方法があります。実行できる操作が増えるほど、対象の確認、権限、結果確認、失敗時の再開方法を具体的にする必要があります。

聞き返しを減らすための検証セットを作る

検証用の会話は、実際に多い用件と、間違えると困る用件の両方から選びます。件数が多いものだけでは重要な例外を見落とし、例外だけでは通常の使いやすさを評価できません。たとえば予約変更なら、通常の変更、希望日の訂正、予約を特定できない場合、変更取り消し、有人希望を別のケースにします。

図3：会話が止まったときの出口。本文の関係や手順を整理した図。

各ケースには、相手が伝える情報、期待する確認、行ってはいけない処理、終了時に残るべき記録を用意します。正解の文章を一字一句決める必要はありませんが、意味として欠かせない点を判定できるようにします。自然な言い方でも、未確認の日付を確定したように伝えれば修正が必要です。

一度合格した会話も、質問の順番や知識を変えた後には再確認します。新しく追加した用件だけでなく、既存の主要な用件が引き続き動くかを見るためです。評価に使った会話の条件と設定の版を残すと、どの変更で改善や悪化が起きたかを追いやすくなります。

音声入力と番号入力を組み合わせる場合は、途中で入力方法を変えた際の動作も試します。音声によるメニュー選択とキー入力は、音声対話の標準仕様でも扱われている考え方です。ただし、個別サービスで切り替えられる範囲は別途確認します。W3C VoiceXML 2.0

最終的には、利用者が特別な話し方を覚えなくても用件を伝えられるか、担当者が途中から対応を再開できるかで判断します。会話の完成度と業務の完成度を分けて点検することで、どこを直せば使いやすくなるかが明確になります。

よくある質問

生成AIは必須ですか？

必須ではありません。決めた質問と回答の流れを使うシナリオ型もあります。対象業務の幅や、発話の自由度、運用で管理したい範囲に応じて検討します。

現在のIVRと併用できますか？

プッシュ入力と音声対話を組み合わせる構成があります。既存設備との接続方法や、切り替えられる場面はサービスによって異なるため、実際の構成で確認します。

今の電話番号をそのまま使えますか？

電話番号の契約、転送や接続の方式、利用するサービスの条件で変わります。番号の継続可否とあわせて、転送料金、同時に受けられる通話数、障害時の切り戻しを確認しましょう。

人につながず、すべて完結できますか？

業務や連携の範囲によります。対象外の相談や処理エラーは起こり得るため、有人窓口・折り返し・別チャネルへの経路を含めて設計します。まずは完了条件を明確にできる用件から検討することが現実的です。

まずは、一つの用件の「完了」を決める

ボイスボットの検討は、任せたい電話を具体的にするところから始まります。顧客が何を求め、どの情報や処理が必要で、どの状態になれば対応を終えられるか。その流れと、人が判断する場面を整理すると、必要な機能と検証項目が見えてきます。

Daisybellへのご相談では、対象の問い合わせや現在の運用、連携したいシステムについてお聞かせください。

電話対応の課題を相談する ↗