ボイスボットとは？AI電話受付との違い・仕組み・導入方法を解説

ボイスボットは「音声で動く業務窓口」

ボイスボット（Voicebot）は、人の声を入力として受け、案内や質問、処理を行う仕組みを指します。Voice Agent、音声AI、AI電話、電話自動応答という語も近い場面で使われますが、サービスごとに範囲が異なります。本記事では、電話での会話を通じて業務を進める用途を中心に説明します。単に音声を読み上げる仕組みと違い、用件を理解し、確認し、予約DBやCRMなどの処理へ渡せるかが実務上の分かれ目です。

電話ボイスボットのArchitecture

従来型・一般的な構成では、電話から届く音声をSpeech to Textで扱える情報に変換し、対話LogicまたはLLMが質問・回答・Tool呼び出しを判断した後、Text to Speechで音声を返します。一方で、現在はaudio-in/audio-outを直接扱うspeech-to-speechのRealtimeモデルを使う構成もあります。どちらが適するかは、音声品質、遅延、連携、監査方法、利用するサービスにより異なり、本図は唯一の構成を示すものではありません。

用語比較Matrix

名称だけで機能を判断せず、会話方式、登録できる業務Rule、外部連携、データ保管、転送失敗時の処理を仕様として比較します。

会話が成立しても、業務が完了するとは限らない

電話の聞き取りが自然でも、予約枠を二重に確定したり、担当者へ情報が渡らなかったりすれば受付は失敗です。ボイスボットの設計では、Speech to Textの精度だけでなく、氏名・住所・日時・型番などの確認方法、Tool Callingの権限、DB更新の重複防止、回答してよい範囲を決めます。外部システムへ渡す前に復唱確認を入れる情報と、すぐに人へエスカレーションする情報を分けると安全です。

着信から応答までのFlow

導入は「会話台本」ではなく業務境界から始める

最初から全問い合わせを対象にすると、例外が増え品質を判定できません。着信ログを用件別に分け、頻度が高く、回答・受付項目・次の担当が決まっている一種類を選びます。次に、発話例ではなく、受付で取得する項目、未取得時の扱い、禁止回答、人へ渡す条件を定義します。通話テストでは、早口、騒音、言い直し、複数用件、無音、途中切断を混ぜて確認します。

AI CALL HUBで検討できる範囲

AI CALL HUBでは、電話受付、受付項目の構造化、通知や予約業務との連携を、個別の業務設計に合わせて構成します。特定のCRM・回線・多言語や高度な連携を標準搭載とみなさず、必要な運用と既存システムを確認したうえで可否を整理します。まずは実際の電話受付を体験し、会話と業務処理の両方を検証してください。

会話の設計は、質問を増やすことではない

ボイスボットの会話設計では、最初に発信者が自分の言葉で用件を話せる余地を作り、その後に業務処理に必要な項目だけを補います。例えば予約なら、機械的に十項目を聞く前に、予約か変更かキャンセルかを把握し、日時・人数・連絡先の順番を状況に合わせます。聞き取れない時は同じ質問を三回繰り返すのではなく、短い復唱、選択肢、SMSや有人対応への切替など、別の入口を用意します。

設計者は、発話例よりも状態遷移を管理します。未確定の氏名、確認済みの希望日時、外部DB照会中、担当者への転送待ちといった状態が分かれば、会話が途中で切れても、何を復元し何を聞き直すかを決められます。会話モデルの能力に期待しすぎず、業務で必要な確認をシステム側のRuleに落とすことが品質を安定させます。

Tool Callingと権限の境界

ボイスボットが予約DB、CRM、配送状況、FAQなどを呼び出す場合、何でも実行できる権限を与えません。照会だけ可能なTool、仮受付を作るTool、担当者承認後に確定するToolを分け、引数には顧客ID、日時、対象サービスなどの検証を入れます。外部APIがTimeoutした時は、成功とみなして会話を進めず、受付番号を伝えて確認中へ移す手順が必要です。

通話の品質レビューでは、モデルの回答だけでなく、Toolが呼ばれた理由、渡した値、結果、失敗時の案内を追えるようにします。電話番号や個人情報を扱う場合は、録音・要約・ログを誰が閲覧できるか、どの期間保持するか、委託先へ渡るかを先に定めます。これにより、音声AIを単体の会話機能ではなく、監査可能な業務窓口として運用できます。

品質を評価する時の会話ログの読み方

ボイスボットの評価で「応答率が高い」だけを追うと、分からないことまで話し続ける会話が見逃されます。会話ログを、用件識別成功、必須項目取得、確認漏れ、Tool成功、Human Escalation、途中離脱に分解します。音声認識が誤ったのか、質問順が悪かったのか、業務Ruleがなかったのかを切り分けると、改善対象が明確になります。

改善はモデルを変えることから始める必要はありません。受付項目の名称を発信者の言葉に合わせる、住所や日時を復唱する、回答できない質問を認めて人へ渡す、といった業務設計の変更で品質が上がることがあります。週次で数十件を目視し、数値と実際の会話を並べる運用が、ボイスボットを長く使うための土台になります。

導入後に必要な運用担当

ボイスボットは公開後も、音声案内、業務Rule、連携先、転送先を更新する役割が必要です。業務担当がFAQを承認し、IT担当が接続と権限を確認し、現場の受付担当が実通話をレビューするという分担にすると、問い合わせ内容の変化を会話へ反映できます。問い合わせ件数が少ない期間でも、変更履歴とテスト通話を残せば、なぜ案内が変わったかを追跡できます。

概念を業務へつなげる関連記事

電話の入口から受付票までの全体像はAI電話の基礎、実際の受電業務の設計はAI電話受付の仕組みを参照してください。番号選択型との使い分けはAI電話とIVRの違い、例外を人へ渡す条件はAI電話から人間への転送、繁忙時の設計はAI電話の同時着信対応で扱っています。

よくある質問