ボイスボットは、音声でやり取りしながら、問い合わせへの回答や必要事項の聞き取りを進める自動対話システムです。電話窓口で使われるものは、AI電話自動応答、音声AI、AIオペレーターなどとも呼ばれます。

実用性を左右するのは、声の自然さだけではありません。聞いた内容を正しく保持し、必要な確認を行い、処理の結果を確かめ、人が対応すべき場面を取りこぼさないことが重要です。本記事では、電話が入ってから後続業務へ渡るまでを、仕組みと運用の両面から説明します。

ボイスボット・IVR・チャットボットの違い

呼び方は製品によって重なります。AI-IVRという名称でも複数項目を聞き取る製品があり、ボイスボットでも定めた手順に沿って動く構成があります。IVRを含む全体の選び分けはIVRの仕組みと導入設計も参考にしてください。

電話では画面を見せられず、利用者が内容を覚えながら会話を進めます。長い説明を一度に読み上げず、一つずつ確認し、必要ならSMSやWeb、有人窓口へつなぐ設計が向いています。

ボイスボットが動く6つの工程

一般的な構成では、次の処理を組み合わせます。音声を直接扱うモデルなど構成の違いはありますが、運用を確認するときは、この6つに分けると問題箇所を見つけやすくなります。

会話の情報を項目として保持する考え方は、Google CloudのDialogflow CX Parametersでも説明されています。必須項目の収集や、入力が得られなかった際の聞き直しを設定する機能です。これは一般的な技術構成の参考であり、Bellが同製品を使用していることを示すものではありません。

「よく聞き取れる」と「業務が終わる」は別

日付を正しく聞き取れても、該当する枠がすでに埋まっていれば予約はできません。また、台帳への登録を依頼しただけでは、保存に成功したかはわかりません。

Google CloudのDialogflow CX Fulfillmentsには、Webhookで外部サービスへ処理を依頼し、その結果で応答や会話の状態を変える仕組みが示されています。実際の業務では、処理成功、失敗、結果不明を区別し、それぞれで案内を変える必要があります。

シナリオ型と生成AI型をどう組み合わせる？

シナリオ型は、質問と分岐を明確に設計する方式です。必要項目を順番に集め、決まった処理を行う業務に適しています。一方、生成AIを使う方式では、言い換えや複数の情報を含む発話を扱いやすくする設計が可能です。ただし、利用するモデルや設定によって結果は変わります。

生成AIを使っても、回答資料にない条件を作らない、本人確認前に個別情報を明かさない、必要な確認なしで登録しない、といった制御は必要です。「自然に話すこと」と「処理を自由に決めること」を混同しない設計が重要です。

会話例：予約変更を安全に進めるには

以下は仕組みを説明するための架空の会話です。実際の顧客との通話記録やBellの導入実績ではありません。

途中で連携先から応答がなければ、「変更を確認できないため、担当者が確認して連絡します」と案内し、要確認として残します。変更できたか不明なまま同じ登録を繰り返すと、重複処理が生じる可能性があるため、登録先の状態を確かめてから再試行します。

また、利用者が途中で電話を切った場合も、「最終確認前」「処理中」「処理成功後」では必要な対応が異なります。通話終了という一つの状態にまとめないことがポイントです。

ボイスボットのメリットと、成立する条件

定型対応を分担し、担当者の中断を減らせる

毎回同じ案内や聞き取りをAIへ任せると、担当者は個別判断や対面業務に時間を使いやすくなります。ただし、AIが集めた情報を全件聞き直すなら、その負担が残ります。取得項目と担当者の業務を合わせて設計します。

営業時間外の受付を用意できる

夜間に希望を受け付け、翌営業日に担当者が確認する運用が可能です。「電話を受け付ける時間」と「人が判断・折り返しする時間」は分けて案内します。24時間の受付を、24時間の有人解決と同じ意味で表示しないようにします。

回答と記録の手順をそろえられる

承認済みのFAQや必須項目を使えば、聞き取り手順を統一しやすくなります。ただし、資料自体が古ければ、同じ誤りを繰り返すおそれがあります。統一と正確性の両方を見る必要があります。

繁忙時の対応能力を増やしやすい

複数回線を扱う構成では、電話が集中する時間帯を支えられます。ただし、同時通話数は契約・回線・システム・連携先の上限に依存します。月間の総件数だけでなく、ピーク時に何件重なるかを確認してください。

苦手な場面は、会話の出口から設計する

聞き直しは無制限に繰り返さず、例えば「同じ項目を2回確認しても取れなければ有人へ」という運用ルールを決めます。この回数は設計例であり、共通の正解ではありません。利用者の負担と情報の重要度に合わせて調整します。

有人連携は「切り替える条件・渡す情報・担当者」の3点で決める

1. 人へ切り替える条件

• 利用者が担当者との会話を希望した
• 回答資料に根拠がない、または情報が矛盾している
• 確認が必要な氏名・番号・日時を取得できない
• 返金、契約条件の変更、個別配慮など判断が必要になった
• 緊急連絡に当たると組織のルールで定めた
• 外部システムの処理に失敗した、または結果を確認できない

2. その場の転送と折り返しを分ける

転送を試みただけで引き継ぎ成功にせず、担当者が応答したかまで確認します。折り返し時間も、担当者の体制がないのに「すぐに連絡します」と約束しないようにします。

3. 要約だけでなく、未完了の作業を渡す

担当者が知りたいのは「何を話したか」に加え、「何が済み、何をする必要があるか」です。次の項目を渡せるか確認します。

要約に誤りがあっても確認できるよう、必要な権限を持つ担当者が元の文字起こしや録音を確認できる運用を用意します。Bellの通話履歴・AI要約と転送・CTIでは、こうした引き継ぎに関わる公開機能を確認できます。

導入後の運用を誰が担うか

導入支援がある場合でも、自社しか判断できない情報は残ります。営業時間、料金、例外条件、担当部署などの決定者を明確にしておくと、改善を進めやすくなります。

例えば導入直後は未完了・転送失敗を毎営業日確認し、会話の改善は週次、費用と業務負担は月次で振り返る運用が考えられます。これは頻度の例です。高い即時性が必要な窓口では、より早く異常を把握できる体制を設けます。

品質を見るときは、失敗を工程別に分ける

自動完結率だけでは、どこを直せばよいかわかりません。例えば「予約変更に失敗した」通話を、日付の認識、本人確認、空き照会、変更処理、結果案内のどこで止まったかに分けます。

会話の応答時間も平均だけで判断しないようにします。普段は短くても、外部照会時だけ長い無言が発生する場合があるためです。用件別の応答時間に加え、遅い側の値や、待っている間の案内を確認します。

改善した後は、新しいケースだけでなく以前成功した会話も再試験します。質問文の変更で、別の用件の聞き取りが悪くなる可能性があるためです。比較・受入試験の具体的な項目はボイスボット選定チェックリストにまとめています。

録音と会話データを安全に扱う

名前、電話番号、予約内容などを取得するボイスボットでは、何を保存し、誰が利用し、いつ削除するかを設計します。テストには架空の情報を用い、実際の通話を改善に使う場合は、社内の取扱い方針と契約条件を確認してください。

個人情報保護委員会のQ&A 1-10は、通話から特定の個人を識別できる場合の個人情報該当性と、利用目的の通知・公表を説明しています。認証マークの有無だけで判断せず、実際の閲覧権限、委託先の扱い、データの出力・削除方法を確認します。

ボイスボットは、会話と後続業務を一緒に設計する

導入のゴールはAIに長く話させることではありません。利用者の用件が正しく処理されること、または必要な情報とともに人へ届くことです。

Bellでは、シナリオ設計、CRM/API連携、通話記録、有人転送の公開機能があります。自社の用件を使って、成功する会話と失敗時の経路の両方を確認しましょう。ボイスボットの運用設計を相談する

参照情報

• Google Cloud：Dialogflow CX Parameters：必須項目と聞き直し
• Google Cloud：Dialogflow CX Fulfillments：外部処理と応答の制御
• Bell 機能一覧：シナリオ・連携・記録・転送の公開機能
• 個人情報保護委員会 Q&A 1-10：通話情報の取扱い

公式情報の確認日：2026年10月7日。会話例、失敗時の対応例、運用頻度は説明用の設計例です。利用するサービスの実装と契約条件に合わせて検証してください。