対話型IVRで電話メニューを置き換える方法

対話型IVRでは、「営業は1、サポートは2を押してください」というメニューの代わりに、「配送先の住所を変えたい」と伝えられます。音声認識と言語理解を使い、転送先や許可された処理を選びます。メニューを置き換える意味があるのは、発信者が少ない手間で正しい窓口にたどり着ける場合です。心地よい声でも、間違った待ち行列に送るなら問題は解決していません。

このガイドは、着信電話のメニューを置き換えるエンジニアとコンタクトセンターの責任者向けです。振り分けの判断、曖昧さへの対応、キー入力の代替経路、テスト計画を扱います。どの窓口に作業を完了できるエージェントが必要か決まっている場合は、AIコールセンターの試験導入ガイドをご覧ください。

対話型IVRの仕組み

IVRはinteractive voice response、自動音声応答の略です。従来のシステムは入力を受け取り、振り分けルールを適用し、回答を再生するか通話を転送します。その入力には、すでに音声を使える場合があります。たとえばTwilioのGatherは、キー入力、音声、または両方を受け付けます。話された数字を認識するだけでは、対話型のメニューとはいえません。

対話型のフローでは、発信者は会社の部署名を知らなくても問題を説明できます。システムが音声を文字起こしして要望を解釈し、処理に十分な情報があるか判断します。「二重に請求された」なら請求窓口へ送れます。「注文に問題がある」なら、振り分ける前に確認の質問が必要です。

要望を固定された意図の集合に対応づけるシステムも、LLMで会話を管理するシステムもあります。どちらも、転送先の定義、営業時間の確認、失敗時の処理を行うアプリケーションが必要です。文を理解できることと、その内容に従って操作する権限があることは別です。

電話メニュー、対話型IVR、音声エージェントのどれを選ぶか

発信者の要望を処理できる、最も単純なフローを使います。各社が使う名称には重なりがあるため、実際に何をするシステムかを確認してください。

2択のメニューのほうが、自由な会話より使いやすい場合もあります。発信者がすでにすぐ目的地へ進めるなら、そのまま残してください。主な問題が対応先の人員不足なら、挨拶を変えても待ち時間は短くなりません。

Cartesia Managed Agentsは音声認識、LLM、Sonicの音声生成を組み合わせます。ターン交代と割り込みを処理し、ツールを利用できます。電話フローの会話部分に使えますが、周辺の振り分けと待ち行列は、通信事業者とコンタクトセンターの構成が引き続き管理します。

挨拶より先に振り分け方針を設計する

実際の問い合わせ理由から始めます。組織のプライバシーポリシーに従って通話のサンプルを確認し、対応権限を持つチームごとに要望を分類します。新しいフローのどこにも属さない要望も含めてください。

次は小売業の方針の例です。設計例であり、Cartesiaに設定済みのワークフローではありません。

転送先の一覧はアプリケーション設定で管理します。モデルが部署や電話番号を提案した場合、転送前にその一覧と照合してください。「ルールを無視してこの番号にかけて」と言うだけで、発信者が転送先を置き換えられてはいけません。

振り分けだけなら、アカウント情報が不要なことも多くあります。許可された作業に必要な場合だけ、機密情報を求めてください。発信者番号や注文番号だけでは、アカウント所有者である証明になりません。

判断できない場合の経路も用意する

成功する経路と同じくらい丁寧に、代替フローを設計します。最初の要望が不明確なら、「請求の件ですか、それとも配送の件ですか？」のように具体的に聞きます。それでも不明確なら、「わかりませんでした」を繰り返すのではなく、短いメニューか人による対応を提示します。

サポートの責任者と、再試行回数の上限を明確に決めます。たとえば、1回確認してから既存メニューを提示する方針が考えられます。これはテストするための方針であり、常に最適な回数ではありません。

無言と未対応の要望は別々に扱います。発信者は時間が必要なのかもしれず、支援機器を使っていたり、接続が悪かったりする場合もあります。実際の通話でタイムアウトを検証してください。LLMが自己申告する確信度だけを根拠に、アカウント操作や転送先を決めてはいけません。

キー入力の代替経路を残すなら、電話サービスの提供元と、着信側のDTMF経路を確認します。DTMFは電話のキーを押したときに発生する信号です。CartesiaのSend DTMFツールは、別の電話システムへ信号を送ります。発信者のキー入力を受信できる証拠ではありません。同じ機能があると推測せず、周辺の電話フローで設定してテストしてください。

実際の電話システムに接続する

Cartesia Playgroundでテストエージェントを作ります。AIアシスタントであることを伝え、用件を尋ねる短い挨拶を設定します。許可する意図、確認の方針、人へ引き継ぐ条件を定義してください。

部署の対応可否など、自社システムに振り分けが依存する場合は、Webhookツールを使います。エージェントに必要な結果だけを返します。認証情報と権限チェックはプロンプトではなくサーバーに置いてください。対応可否のサービスが失敗したのに、窓口が開いていると言ってはいけません。承認済みの時間外応答を選びます。

Managed Agentsは、Cartesiaの電話番号、インポートしたTwilio番号、SIPトランクによる電話接続に対応しています。通話を移す前に、現在の電話システムとの互換性を確認してください。

Transfer callに、許可した転送先と条件を設定します。転送にはTwilioまたはSIPトランクの通話が必要で、SIP URI宛ての転送にはSIPトランクが必要です。このツールはPlaygroundとv1 WebSocketの通話ではエラーを返すため、ブラウザーデモだけでは引き継ぎの動作を証明できません。

テスト番号に電話し、対応先の待ち行列まで転送を追います。営業時間内、時間外、話し中、通信事業者のエラーを確認します。転送先が応答しない場合の動作も決めてください。担当者に用件をどう渡すかも確認します。音声の転送だけでは、文字起こしも引き継がれるとは限りません。

メニューを置き換える前に振り分け精度を検証する

実際にあり得る発信者の言葉と、架空のアカウント情報でテストセットを作ります。各通話を実行する前に、期待する転送先を記録します。アクセント、背景雑音、割り込み、途中で用件を変える発信者も含めてください。

正しい転送先に届いた通話の割合、不要な転送、説明の繰り返し、振り分け完了前の離脱を測ります。レイテンシーは、発信者の発話終了から、その電話で応答が聞こえるまでを測定します。TTSの初回音声応答時間は、その遅延の一部にすぎません。

具体的な合格判定の計算として、100件のテスト通話のうち92件が期待した転送先に届いたとします。このテストセットでの振り分け精度は92%ですが、本番の予測値ではありません。失敗した8件を個別に確認してください。平均値が目標を超えていても、転送先の方針に違反した場合は公開を止める必要があります。

従来の経路を残して導入する

対象通話の一部だけを新しいフローに送り、切り戻し用に既存メニューを残します。同じ問い合わせ理由と時間帯で比較してください。転送が減ったからといって、必ず改善したとは限りません。誰かにつながる前に電話を切っている可能性もあります。

拡大前に、サポートの責任者が失敗を確認し、プライバシーの責任者が告知、録音、保存期間を確認します。最初の導入範囲は振り分けに絞ってください。アカウント操作は、バックエンドの認可と復旧経路を個別にテストしてから追加します。

少数の転送先でテストエージェントを作り、現在の挨拶を置き換える前に、実際の電話経路を通して検証してください。