AI音声受付は、自然に話せるだけでは業務で使えません。名前や日時を聞き間違えたとき、本人確認ができないとき、担当者へ渡すべきときに、どう会話を終わらせるかまで決めて初めて受付になります。
設計の中心は、認識精度を過信しないことです。聞き返しの回数、復唱する情報、別チャネルへの切替、有人転送の条件、通話後に見直す指標を、業務ごとに先に定義しましょう。
最初に決めるべきは「受付が完了」の定義
会話文を作る前に、AIが受け付けてよい依頼と、人に渡す依頼を分けます。ここが曖昧だと、丁寧な話し方でも業務事故を防げません。
受付完了は、単に用件を聞いた状態ではありません。予約なら日時・人数・連絡先の確定、問い合わせなら必要情報の取得と受付番号の案内など、業務で次の処理へ渡せる状態を定義します。
反対に、金額の確約、契約変更、緊急性の判断、例外対応などは、最初から有人対応へ回す対象にします。判断に必要な情報が不足したまま、もっともらしい回答を続けないルールが必要です。
受付フローを作る4ステップ
聞き返しは「回数」と「確認対象」を分けて設計する
聞き返しを丁寧に繰り返しても、顧客は解決に近づきません。情報の重要度ごとに、再質問、復唱確認、代替導線を使い分けます。
聞き取りにくいときは、同じ質問を言い直す前に、答え方を変えます。たとえば日時は「何月何日ですか」ではなく、「9月6日、午前と午後のどちらですか」のように選択肢を小さくします。
聞き取れたように見えても、予約日時、電話番号、住所、製品番号、金額に関わる情報は復唱確認します。確認の目的は会話を長くすることではなく、後工程で修正しにくい誤りを止めることです。
再質問は原則2回で出口を出す
同じ項目で聞き取りに失敗したら、再質問は原則2回までを目安にします。3回目も曖昧なら、SMSで入力用ページを案内する、受付フォームへ切り替える、有人へつなぐなどの出口を提示します。
ただし、医療・金融・緊急連絡のように、誤った入力の影響が大きい業務では、回数より安全な中断・有人対応を優先します。
復唱するのは後で戻せない情報
復唱対象は、日時、人数、連絡先、受付内容の要約、変更・取消の対象などです。氏名の表記まで電話で確定する必要がある業務では、口頭だけで完結させず、SMSやログイン済み画面で本人に入力・確認してもらう設計が有効です。
復唱は一度に詰め込まず、「日時」「人数」「連絡先」の単位で区切ります。顧客の返答は、はい・いいえだけで済む形に整えます。
| 状況 | AIの次の行動 | 受付の扱い |
|---|---|---|
| 言い直しで特定できそう | 選択肢を示して再質問 | 保留のまま続行 |
| 重要情報が不明確 | 対象項目だけを復唱確認 | 確認できるまで未確定 |
| 2回聞いても不明 | SMS・Web・有人対応を案内 | 別導線へ切替 |
| 緊急・高リスクの相談 | 安全案内後に有人対応へ | AIで判断しない |
本人確認は「受付確認」と「本人認証」を混同しない
氏名や予約番号を聞くことと、本人であると認証することは別です。扱う手続のリスクに合わせ、確認方法と確認不能時の処理を決めます。
予約の照会や来店確認のような低リスクの受付では、予約番号、生年月日の一部、登録済み電話番号へのワンタイムコードなどを組み合わせます。どの情報が一致すれば何を案内できるかを、業務単位で分けてください。
音声だけ、特に声紋比較だけで高リスクな本人認証を完結させる前提は避けるべきです。NISTのデジタルアイデンティティ指針でも、音声による生体比較は認証に用いないこと、非生体による代替手段を提供することが示されています。
不一致や確認不能では、AIが理由を深掘りしすぎないことも重要です。「安全のため、このお電話では手続きを続けられません」と伝え、ログイン画面、SMS、折り返し、有人窓口のいずれかへ誘導します。
⚠ 本人確認で避けたい設計
- 声だけで高リスクな本人認証を完結させる
- 不一致の理由や登録情報を電話で詳しく漏らす
- 確認不能でも変更・取消・開示を実行する
- 本人確認の代替手段を用意しない
編集部の判断：自動化率より「迷子にしない率」を先に見る
受付AIの初期設計では、何件を自動完結できるかだけを目標にすると、曖昧な内容まで処理して誤案内につながりがちです。まずは、聞き取れない相談や例外的な依頼を、顧客が迷わず次の手段へ進める状態を作るべきです。その上で、転送理由や未完了理由を記録し、自動化できる範囲を段階的に広げる判断をおすすめします。
有人転送は条件・顧客案内・引継ぎ情報を一組で作る
「必要に応じて担当者へ転送する」だけでは、現場は回りません。誰に、いつ、何を渡すかを会話フローとして決めます。
転送条件は、顧客が人を希望したとき、再質問の上限に達したとき、規約外の依頼、苦情、緊急性の可能性、本人確認不能などに分けます。担当者の負荷を避けるためではなく、AIが決めてはいけない境界を明確にするためです。
電話通話向けに外部番号やSIP URIへ転送できる製品もあります。ElevenLabsでは、電話通話に限って条件付きの番号転送を設定でき、電話基盤によっては顧客向けの待機案内や担当者向けの要約メッセージも構成できます。
実装条件は利用する電話基盤と契約内容を確認してください。
音声・会話型エージェントまで広げるなら
電話・Web・アプリをまたぐ会話エージェントや、電話転送を含む実装の選択肢を確認したい方は、ElevenLabsの公式情報をチェックしてください。
通話ログを「改善できる評価項目」に変える
録音や文字起こしを保存するだけでは改善につながりません。受付の目的に沿って、成功・失敗・判断不能を分けられる評価基準を作ります。
評価は、予約完了率だけでは不十分です。復唱確認の実施、誤転送、有人希望への応答、別導線への切替、確認不能での不適切な処理といった、安全性に関わる項目を含めます。
対応製品では、通話トランスクリプトを基に成功・失敗・不明を判定する評価基準を設定できるものがあります。不明が多い基準は、会話ログに必要な情報が残っていないか、判定ルールが曖昧なサインです。
録音、文字起こし、CRM連携で個人情報を扱うなら、取得目的、保存期間、閲覧権限、委託先、国外での取扱い、削除手順を確認します。日本の個人情報保護委員会の案内も参照し、法務・個人情報保護担当と運用をすり合わせてください。
週次で見る評価項目
公開前テストは「失敗する話し方」を先に集める
通常の会話だけを試しても、受付の弱点は見つかりません。現場で起きる曖昧さ、割込み、情報不足をテストケースに入れます。
テストでは、早口、方言、聞き直し、途中変更、予約番号の桁違い、同姓の顧客、担当者を強く希望する依頼を用意します。成功する会話より、AIが誤って確定しそうな会話を優先して確認してください。
結果は、認識精度だけで採点しません。誤ったまま進めずに確認できたか、適切な導線へ移れたか、担当者が引継ぎだけで対応を始められたかを見ます。小さな受付範囲で公開し、ログを基に毎週見直す運用が現実的です。
まとめ：AI受付は「正答率」より安全な次の一手を設計する
AI音声受付の導入では、対応範囲を狭く定め、聞き取れない情報を安全に止める分岐を先に作ることが重要です。本人確認のリスク、有人への引継ぎ、ログの評価方法まで決めてから、小さな業務範囲でテストを始めましょう。
自社向けの記事企画・制作に落とし込むなら
自社の受付フローを読者や顧客に伝わる形へ整理したい方、AI活用の発信記事を制作したい方は、本ブログ編集部にご相談ください。
参考情報
- ElevenLabs「Introducing ElevenLabs Agents」
https://elevenlabs.io/blog/introducing-elevenlabs-agents - ElevenLabs Documentation「Transfer to number」
https://elevenlabs.io/docs/eleven-agents/customization/tools/system-tools/transfer-to-number - ElevenLabs Documentation「Success evaluation」
https://elevenlabs.io/docs/eleven-agents/customization/agent-analysis/success-evaluation - ElevenLabs「ElevenAgents Pricing」
https://elevenlabs.io/pricing/agents - NIST「Digital Identity Guidelines: Authentication and Authenticator Management」
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63b-4.pdf - 経済産業省「AI事業者ガイドライン（第1.2版）」
https://www.meti.go.jp/shingikai/mono_info_service/ai_shakai_jisso/20260331_report.html - 個人情報保護委員会「個人情報の保護に関する法律についてのガイドラインに関するQ&A」
https://www.ppc.go.jp/personalinfo/faq/APPI_QA/
コメント