音声AIはAIを見抜くコールセンターに対応できるか？まず拒否と引き継ぎの経路を設計する

AI電話エージェントの拒否とは、アウトバウンドの音声エージェントが電話をかけた先の組織（医療保険プラン、運送会社、他社のコールセンターなど）が、担当者が相手をAIだと気づいた時点で会話の継続を断ることを指します。拒否は、アウトバウンド通話のごく普通の結果の一つとして想定しておきましょう。こうした通話をうまく運用しているチームは、ローンチ前に拒否時の経路を設計しています。エージェントが拒否をどう認識し、何を話し、誰が通話を引き継ぎ、その後タスクをどう扱うかです。

この記事では、他の企業へのアウトバウンド通話を扱います。自社の顧客が電話をかけてきて人間の対応を求める場合はインバウンドのエスカレーションであり、音声ボットが通話を人間のエージェントにエスカレーションする方法とAI音声エージェントによるウォームトランスファー（事前取次）の対応方法で解説しています。仕組みには重なる部分がありますが、違うのは電話の向こうにいる相手です。拒否する人は他社のために働いており、こちらに対して何の義務もなく、自分たちの対応待ちの列を抱えています。

なぜ一部のコールセンターはAI電話エージェントを拒否するのか？

多くの場合、担当者は平均処理時間の目標に追われており、担当者の時間を無駄にする自動発信は直接的なコストになるからです。質問を繰り返したり識別番号を読み間違えたりするAI電話エージェントに付き合わされた経験のある担当者には、次の通話を早めに切り上げる理由があります。ヘルスケア向けAIベンダーのInfinitusは、汎用的なエージェントが通話を長引かせ、大量になると電話回線を圧迫するため、保険者が反発していると主張しています。同社によれば、大手保険者の多くは同社のAIエージェント向けに専用回線やコールセンターを設けているとのことで、代表回線での拒否が必ずしもタスクそのものの拒否ではないことを示しています。

自動発信に関する公開ルールが見つかるとは期待しないでください。回答は相手先や部署によって異なると考えておきましょう。設計上の問いはどこでも同じです。誰かが「ノー」と言った直後に、エージェントは何をするのか？

拒否はどのような形で現れるのか？

拒否には4つの種類があり、それぞれ異なる対応が必要です。

1行目はまだ拒否ではありません。その答え方次第で、拒否になるかどうかが決まります。短く正直に答え、続けて通話の目的と担当者が必要とする参照番号を伝えれば、会話はタスクに戻ります。はぐらかせば、担当者に電話を切る理由を与えてしまいます。

エージェントはAIであることを伝えるべきか？

伝える前提で計画し、尋ねられたら毎回正直に答えるようにしましょう。AI音声の開示に関するルールは法域や通話の種類によって異なりますが、いくつかは同じ方向を示しています。

• 2024年2月の宣言的裁定で、FCCはTCPAの「人工音声または録音済み音声」に関する規制が、人間の声を生成する現在のAI技術にも適用されることを確認しました。この裁定では、FCCの規則により、人工音声または録音済み音声のメッセージには、通話の責任主体についての識別情報と開示情報を含める必要があることにも触れています。
• ユタ州法は、消費者取引において個人に対して生成AIを使用する事業者に対し、その個人が明確に尋ねた場合には、相手が人間ではなく生成AIとやり取りしていることを開示するよう求めています。
• EU AI法第50条は、人と直接やり取りするAIシステムについて、文脈から明らかな場合を除き、相手がAIシステムとやり取りしていることを知らされるよう設計することをプロバイダーに求めています。

自社のエージェントから他社の担当者への通話にこれらのどれが適用されるかは、双方の所在地、通話の目的、つながる回線によって異なります。これは説明であり、法的助言ではありません。開示の文言や同意に関する問題はローンチ前に弁護士と確定し、承認された文言をpromptに書き込んで、エージェントがすべての通話で同じように伝えるようにしましょう。

エージェントはどのように拒否を認識するのか？

4つの種類をpromptに書き込み、それぞれに1つの対応を割り当てたうえで、すべての通話でどれが起きたかを記録します。

• promptで。種類ごとにフレーズの例と望ましい対応を列挙し、エージェントが「ノー」に反論したり、拒否された後も話し続けたりしないようにします。
• 通話後に。`refusal_type`（none、question、soft、policy）のような選択式フィールドを通話後の抽出に追加します。Retellは通話終了後にLLMで文字起こしを読み取り、その結果を通話記録に書き込みます。
• 通話切断の場合。会話が行われなかった場合、Retellはカスタム抽出フィールドを埋めないため、代わりに通話の切断理由を使います。`user_hangup`は相手側が通話を終了したことを意味し、この理由で非常に短い通話であれば、それが早期の通話切断です。

これらを組み合わせると、相手先ごとの拒否率がわかります。これが、設計の残りすべての前提となる数値です。

拒否の後に何をすべきか？

可能であれば担当者がまだ回線にいる間に人間につなぎ、できなければタスクを人間による折り返しに切り替えます。図に全体の経路を示します。

自社チームへのウォームトランスファー。RetellのTransfer Call toolを使うと、エージェントは自社スタッフの回線に発信し、担当者が保留している間も通話に残ります。その回線が通話をキューに入れる場合、エージェントは設定した待機時間（デフォルトは30秒）を上限に、実際の人間が話すまで待ちます。その後、同僚だけに聞こえるウィスパーメッセージ（タスクの参照番号や担当者がそれまでに話した内容など）を再生し、双方を紹介してから退出できます。同僚はタスクの途中から引き継ぎ、担当者は最初からやり直す必要がありません。AIから人間への引き継ぎガイドでは、コールド、ウォーム、エージェンティック・ウォームトランスファーを詳しく比較しています。

トランスファー失敗時の分岐。時間内に誰も応答しない可能性があります。会話フローでは、通話転送ノードに転送失敗時のエッジが用意されています。これを短い締めくくりにつなげましょう。謝罪し、人間から折り返すことを伝え、参照番号を確認して通話を終了します。

パイロット中のスーパーバイザーによる引き継ぎ。ライブモニタリングを使うと、スーパーバイザーは進行中の通話を聞き、エージェントから通話を引き継ぐことができます。各相手先の反応を把握するまでの手動のセーフティネットとして活用しましょう。人員計画については後述します。

人間による折り返しタスク。エージェントのワークフロー上の通話後関数で、CRMにタスクを作成できます。条件が満たされた場合にのみ実行されるよう設定でき、たとえば`refusal_type`がsoftまたはpolicyの場合に限定できます。タスクには通話の要約を含められるため、折り返す人はすでに話された内容を把握できます。

エージェントはその相手先に再度電話すべきか？

自動任せにすべきではありません。電話に出られなかった人向けに作られた再試行スケジュールは、たった今「ノー」と言った組織に対するデフォルトとしては不適切です。

ダイヤラーが早期の通話切断をどう扱うかを確認しましょう。RetellのDialer sequencesでは、会話が始まらなかった通話は未応答として扱われ、コンタクトは次に予定された試行に進みます。代わりに、応答があった拒否には専用の結果を設定します。Dialerの結果は`needs_human_call`のような値をコンタクトに書き込んでシーケンスを終了できるため、それ以上AIによる試行は行われません。パイロットでは、短い拒否がどのように分類されるかを確認してください。「AIとは話しません」という短い返答が未応答として扱われると結果の処理は実行されないため、`refusal_type`フィールドを条件とする通話後関数も併用しましょう。

相手先ごとに3つの設定を管理します。そもそもAIが電話するかどうか、どの回線やチャネルを使うか、一定期間に何回拒否されたらその相手先を人間のみの発信に切り替えるかです。相手側のルールは予告なく変わるため、定期的にリストを見直しましょう。

拒否時の経路には何人必要か？

エージェントが発信する時間帯に、設定した待機時間内にウォームトランスファーに応答できるだけの人数です。誰も出ないまま鳴り続けるトランスファーは、ないほうがましです。担当者を無駄に待たせることになるからです。

パイロットの結果から規模を見積もりましょう。1時間あたりの拒否された通話数（1時間あたりのアウトバウンド通話数×測定した拒否率）に、1件を完了するのに人が要する分数を掛けると、1時間あたりに必要なスタッフの時間がわかります。通話量は発信スケジュールに連動するため、日単位ではなく時間単位で計算し、営業時間ではなくエージェントが発信する時間帯に人員を配置します。ある相手先について数値上ライブのキューを維持できない場合は、その相手先ではウォームトランスファーを省略し、すぐに折り返しタスクに回しましょう。

拒否時の経路の担当者は誰か？

エージェントの担当者です。拒否への対応は、RetellのCXオートメーションエンジニアの仕事に関する記事で説明している改善ループの一部です。エージェントがうまく対応できなかった通話を見つけ、原因を突き止め、修正し、確認してリリースします。拒否については、相手先ごとの拒否率の確認、拒否された通話のサンプルの聴取、弁護士が承認した文言の範囲内での冒頭部分の調整、トランスファーを受けるチームのリーダーとの人員配置の合意がこれにあたります。エスカレーションマトリクスに「相手先がAIを拒否」の行を追加し、各レベルで誰が対応するかを全員が把握できるようにしましょう。アラートルールを使えば、成功率などの指標が設定したしきい値を超えたときに、メールまたはwebhookで担当者に通知できます。

最初のアウトバウンド通話の前に、以下を確定させましょう。

ローンチ前に拒否時の経路をどう確認するか？

意図的に試してみましょう。シミュレーションテストでは、AIが通話の相手側を演じ、各実行が合格か不合格で評価されます。そこで、シミュレーション上の担当者がボットかどうかを尋ねる、拒否する、ポリシーを理由に断るといったケースを作成しましょう。シミュレーションではトランスファーは常に模擬で行われ、模擬トランスファーの成功・失敗を選べるため、両方の分岐を実行します。次に、実際の電話でのテスト通話を行い、ウォームトランスファーが自社スタッフの回線に届くことを確認します。電話番号へのトランスファーはWeb通話では確認できないためです。リリース面については音声エージェントの変更をテストしてリリースする方法で解説しています。また、音声エージェントの失敗パターンは、それでも失敗した通話で何が起きたかを特定するのに役立ちます。

よくある質問

コールセンターはAI電話エージェントとの会話を拒否できますか？

はい。担当者はどの通話でも終了でき、組織は自動発信に関する独自のルールを設定できます。拒否を例外的なケースとして扱うのではなく、すべての相手先で想定しておき、自動化された依頼のための別の回線やチャネルがあるか尋ねましょう。

AI電話エージェントの拒否とエスカレーションの違いは何ですか？

エスカレーションは、通常インバウンド通話で、自社の顧客がエージェントに人間の対応を求めることから始まります。拒否は、他の組織の誰かが自社のアウトバウンドエージェントとの会話の継続を断ることから始まります。どちらもウォームトランスファーで終わることが多いですが、その組織には再び電話をかけることになるため、拒否には相手先ごとの再試行ルールと記録も必要です。

アウトバウンドのAIエージェントはAIであることを隠すべきですか？

隠さないことをおすすめします。はぐらかしに気づいた担当者には電話を切る十分な理由があります。また、AI音声は複数の地域で規制されており、たとえば2024年のFCCの裁定では、AI生成音声がTCPAの同意および識別に関するルールの対象となりました。正確な文言は弁護士と合意してください。

エージェントが名乗った直後に相手側が電話を切った場合、エージェントはどうすべきですか？

その通話では何もしません。通話後、切断理由と通話時間から早期の通話切断がわかり、次の試行をAIが行うか、人間が行うか、誰も行わないかを再試行ルールで決定します。デフォルトで同じエージェントによる再発信をダイヤラーに行わせないでください。

拒否時の経路が機能していることはどうすればわかりますか？

相手先ごとの拒否率、待機時間内に人間が応答したウォームトランスファーの割合、拒否されたタスクのうち後で人間が完了した件数を追跡します。特定の相手先で拒否率が上昇している場合は、その相手先のプロバイダーリレーション担当や業務担当の窓口に何が変わったかを確認するきっかけになります。

Retellで拒否時の経路を設計する

Retellは、コンタクトセンター向けのAI音声エージェントプラットフォームです。この記事で紹介した拒否時の経路の要素（ウィスパーメッセージ付きのウォームトランスファー、トランスファー失敗時の分岐、通話後の抽出、条件付きの通話後タスク、Dialerの結果）は、いずれもチームで設定できるドキュメント化された機能です。保険者関連の業務については、AIによる事前承認の電話、AIによる請求状況確認の電話、保険者との通話ループにおける音声の役割をご覧ください。音声エージェントは1分あたり$0.07からの従量課金です。詳細は料金ページをご覧ください。