AI音声エージェントを導入しても、すべての問い合わせを電話だけ、あるいはAIだけで処理する設計は現実的ではありません。顧客が急いでいるのか、認証が必要か、文章で残すべきかで、適した導線は変わります。
重要なのはチャネルを増やすことではなく、問い合わせのリスクと完了条件に合わせて、AIが扱う範囲と人へ渡す境界を先に決めることです。
電話・Webチャット・SMS・有人対応は、緊急度、手続きの複雑さ、本人確認、扱う情報のセンシティブさの4軸で振り分けます。AIは受付、状況確認、定型案内、必要情報の収集を担い、高リスクの判断や例外処理は有人確認へ切り替える設計が基本です。
最初に決めるのは「問い合わせの種類」ではなくリスクです
電話向きか、チャット向きかを商品名や部署名で決めると、例外処理が増えます。まずは一件ごとのリスクを共通の物差しで評価します。
近年は、音声・チャットで会社のシステムを使い、承認済みのアクションや人へのエスカレーションを組み合わせる製品も登場しています。一方で、製品機能があることと、自社の全手続きに任せられることは別です。
受付時点で判定する項目を絞ると、チャネル間の振り分けが安定します。回答の難しさより、誤った処理をした際の影響で優先順位を決めてください。
電話・Webチャット・SMS・有人対応の役割を分ける
各チャネルには得意な仕事があります。顧客の希望だけでなく、会話の即時性、記録性、認証の必要性を踏まえて役割を固定します。
電話は緊急の一次受付や、画面操作が難しい顧客との対話に向きます。Webチャットは、選択肢の提示、FAQ参照、リンク案内など、画面を見ながら進める手続きに適しています。
SMSは、予約日時、受付番号、必要書類、ログインページなどを短く送る補助導線です。個別事情の聞き取りや機微情報のやり取りをSMSへ移すのではなく、安全な認証画面や有人窓口へ戻すために使います。
| チャネル | 主に任せる内容 | 有人へ切り替える目安 |
|---|---|---|
| 電話AI | 緊急一次受付、予約変更、定型状況確認 | 認証失敗、強い不満、例外処理 |
| Webチャット | FAQ、画面案内、選択式の受付 | 個別判断、権限外の操作依頼 |
| SMS | 受付後の通知、URL・番号の送付 | 詳細相談、機微情報の送受信 |
| 有人対応 | 判断、説明責任、救済、承認 | 最初から対象に指定する |
AIから有人へ渡す条件は、会話台本より先に定義する
有人転送を「AIが答えられないとき」とだけ書くと、運用担当者によって判断がぶれます。検知条件、引継ぎ先、引継ぎデータをセットで決めます。
エスカレーション条件は、単発のキーワードではなく、業務上のリスクで定義します。たとえば、認証の連続失敗、規約外の要望、返金や契約変更の例外、脅迫や自傷他害の示唆は、あらかじめ転送候補にします。
感情推定やセンチメントは、会話の温度感を拾う補助情報です。それだけで苦情対応の優先度や緊急性を確定せず、明示的な発言、操作履歴、認証状況と組み合わせて扱います。
有人エスカレーションを設計する4ステップ
音声・会話型エージェントまで広げるなら
音声・チャットエージェントの具体的な構成や対応チャネルを比較したい方は、ElevenLabsの公式情報も確認し、自社の地域・契約・連携条件に合うかを検討してください。
編集部の判断軸：完結率より「安全な復帰先」を先に決める
チャネル設計で最初に決めるべきなのは、AIがどこまで完結させるかではありません。AIが迷ったとき、顧客が困ったとき、企業側の責任者が判断すべきときに、誰がどの情報を受け取り、どの時間内に対応するかです。有人復帰の導線と責任分界が曖昧なまま完結率だけを追うと、例外案件が放置されやすくなります。
有人引継ぎで顧客に同じ説明をさせない
転送自体が正しくても、有人担当者が事情を把握できなければ体験は悪化します。会話全文を渡すより、次の判断に必要な情報を整えて渡します。
引継ぎメモには、問い合わせ目的、顧客が求める着地点、AIが確認した事実、未解決の論点、認証の進捗を入れます。担当者が最初に何を確認すべきかまで示すと、対応を始めやすくなります。
電話から有人電話へ渡すとき
顧客には転送理由と、おおよその待ち方を短く伝えます。転送後に顧客情報を再度聞く必要がある項目は、認証上の理由があるものに限定し、その理由も説明できるようにします。
電話やチャットからSMSへ渡すとき
SMSは会話の代替ではなく、次の安全な行動を案内する手段です。URLを送るなら、送信元の表示、リンク先の目的、認証前に表示する情報の範囲を決め、なりすまし対策も別途確認します。
本人確認と個人情報は、AIだけで完結させない
本人確認を伴う手続きは、利便性だけで設計すると誤案内や不正利用のリスクが高まります。認証前後でAIに許す操作を分けることが重要です。
認証前のAIには、一般案内、必要書類の説明、受付の開始までを任せます。契約内容、住所、支払情報、処理履歴の表示や変更は、認証方式と権限を確認した後の処理として分離してください。
日本では、通話内容に含まれる情報は個人情報に該当し得ます。さらに、録音音声から本人認証に使える特徴情報を抽出する運用では、個人識別符号としての扱いも検討が必要です。
生成AIへ会話ログを渡す際は、利用目的、保存期間、委託先での取扱い、学習利用の条件、閲覧権限を確認します。高リスク情報を自由入力させず、必要に応じて別の認証導線や有人確認へ切り替えます。
⚠ 避けたい設計
- 声だけで重要手続きを完結させる
- 感情推定だけで緊急度を確定する
- SMSで機微情報の入力を促す
- 転送後もAIと人の責任者が不明確
導入後はチャネル別ではなく「失敗した流れ」で見直す
チャネルごとの応答数だけでは、設計の弱点は分かりません。転送、離脱、認証失敗、再問い合わせを一連の流れとして確認します。
週次または月次で、有人転送の理由、転送後の解決状況、顧客が同じ説明をした回数、AIの誤案内、営業時間外の未対応を見直します。件数が少なくても影響が大きい案件は、優先して台本と導線を修正します。
既存SOPをAI向けに移す際も、手順をそのまま登録するだけでは足りません。誰が手順を更新し、どの変更をテストし、どの例外を人へ戻すかまで、運用責任を明文化してください。
運用開始前の確認項目
まとめ：AIの対応範囲ではなく、引継ぎの品質で設計する
チャネル設計では、電話・チャット・SMSの便利さを比べる前に、誤処理の影響と本人確認の必要性を整理します。そのうえで、AIが集める情報、人が判断する事項、転送後の対応期限を一本の運用フローにしてください。安全に有人へ復帰できる仕組みがあれば、AIの対応範囲も段階的に広げやすくなります。
自社向けの記事企画・制作に落とし込むなら
AI活用の方針、例外処理、有人引継ぎのルールを分かりやすく発信したい方は、本ブログ編集部に記事制作をご相談ください。
参考情報
- OpenAI「Introducing OpenAI Presence」
https://openai.com/index/introducing-openai-presence/ - ElevenLabs「Introducing Procedures in ElevenAgents」
https://elevenlabs.io/blog/procedures - ElevenLabs「ElevenAgents」
https://elevenlabs.io/agents - ElevenLabs「ElevenAgents Pricing」
https://elevenlabs.io/pricing/agents - 個人情報保護委員会「生成AIサービスの利用に関する注意喚起等について」
https://www.ppc.go.jp/news/careful_information/230602_AI_utilize_alert/ - 個人情報保護委員会「「個人情報の保護に関する法律についてのガイドライン」に関するQ&A」
https://www.ppc.go.jp/personalinfo/faq/APPI_QA/