購入者が本当に置き換えたい音声AIスタック

多くのアウトバウンドチームが置き換えたいと考えている音声AIスタックとは、AIそのものではなく、その周囲に積み重なった回避策の連鎖です。発信用の別建てのダイヤラー、自社開発の留守番電話検出ロジック、そして各通話をシステム間で受け渡す自動化レイヤーがそれにあたります。目的は新しいAI音声ではありません。システムを減らし、受け渡しを減らし、保守対象を減らし、通話が失敗したときに対応する責任者を一本化することです。CRMは置き換えの対象ではありません。

典型的な回避策スタックはどのような構成ですか？

通常は5つのレイヤーで構成され、それぞれ正当な理由があって追加されたものです。問題は、1件のアウトバウンド通話がその5つすべてを経由するようになっていることです。

1件の通話での受け渡しを数えてみましょう。CRMから自動化へ、自動化からダイヤラーへ、ダイヤラーから留守番電話検出ロジックへ、ロジックからAIプロバイダーへ、AIプロバイダーから自動化へ、そして自動化からCRMへ。通話が失敗しうる箇所が6つあり、それが4〜5社のベンダーにまたがっています。

回避策スタックはどこで破綻しますか？

破綻するのは個々のツールの内部ではなく、受け渡しの部分です。各ベンダーのダッシュボードが正常に見えていても、その間の通話経路で障害が起きていることがあります。

通話の状態が2か所に分散する。ダイヤラーが発信しAIが会話を担当する場合、不応答はダイヤラー側に記録され、AIプロバイダーのログには届きません。デバッグには2社のベンダー間で通話IDを突き合わせる必要があります。つまりネイティブ発信はアーキテクチャ上の判断です。どこで発信するかによって、通話記録、切断理由、録音がどこに残るかが決まります。

機械か人間かの判定がエージェントの外で行われる。ダイヤラーが応答を分類してから通話を渡す場合、誤判定があるとエージェントが留守番電話の応答メッセージに話しかけたり、実際の相手が無音を聞かされたりします。IVRメニューは第3のケースですが、多くのダイヤラー構成ではまったく考慮されていません。

自動化レイヤーは静かに失敗する。シナリオがタイムアウトする、CRMのフィールド名が変更される、tokenの有効期限が切れる。通話が止まったり結果が書き込まれなくなったりしても、誰にもアラートが届きません。

あらゆる変更が3つの設定に影響する。新しいキャンペーンを始めるには、ダイヤラーのリスト、自動化の編集、promptの更新が必要になり、この3つは次第に食い違っていきます。

通話全体の責任者がいない。通話が失敗すると、AIベンダーはダイヤラーを、ダイヤラーは通信キャリアを指し、自動化を構築した担当者はすでに別のチームに異動しています。

何を統合し、何を残すべきですか？

1件のAI通話をツール間で受け渡すためだけに存在するレイヤーは統合し、ビジネスの基盤となるシステムは残しましょう。ダイヤラー、留守番電話ロジック、通話レベルのつなぎの大半は音声AIプラットフォームに移行できます。CRM、通信キャリア、人間のオペレーターによるコンタクトセンターは残します。

通信キャリアを維持することは、別建てのダイヤラーを維持することを意味しません。TwilioやTelnyxの番号をSIP経由でインポートすれば、Retellがそのトランクを通じて発信するため、キャリアは残りダイヤラーソフトウェアは不要になります。番号を購入するか持ち込むかの判断については、アウトバウンド用電話番号チェックリストで解説しています。

自動化レイヤーが完全になくなることはまれです。リードのルーティング、データエンリッチメント、ビジネスロジックは残して構いません。なくすべきなのは、通話の開始や文字起こしのコピーだけを担うつなぎです。CRM側のエンドツーエンドの流れについてはCRMから音声AIへのワークフローを、システムごとの連携の詳細については音声AIをCRMおよび電話システムのスタックに組み込む方法をご覧ください。

留守番電話検出をエージェントに移行したら、どのように機能させるべきですか？

留守番電話とIVRを、エージェントの前に置くフィルターではなく、エージェントが対応するよう設計された通話状態として扱いましょう。検出が会話と同じ場所にあれば、結果、アクション、終了理由が1つの通話記録にまとまります。Retellでは次のようになります。

• 検出ウィンドウ。留守番電話とIVRの検出は、アウトバウンド通話の接続後最初の3分間に実行されます。このウィンドウは固定で、着信通話では検出は実行されません。
• 留守番電話時のアクション。切断するか、メッセージを残します。メッセージは生成型のpromptでも、連絡先の名前などの動的変数を含む固定文でも構いません。
• IVRへの対応。IVR Hangupは電話メニューが応答した時点で通話を終了します。特定の部署につなぐことが目的の場合は、Press Digitでエージェントがキーパッドメニューを操作できます。
• レポート。通話はvoicemail_reachedまたはivr_reachedという切断理由で終了するため、レポート上で会話と区別できます。

1つ注意点があります。応答メッセージが留守番電話ではなくIVRとして分類される場合があるため、留守番電話時の切断と併せてIVR Hangupも有効にしてください。

Retellのドキュメントには自動リダイヤルの記載がないため、再試行ルールをどこで管理するかを決めておきましょう。よくあるパターンは、call_ended webhookから切断理由（dial_no_answer、dial_busy、voicemail_reached）を読み取り、CRMやスケジューラーで次回の発信を設定する方法です。メッセージの文言については、AI音声エージェントの留守番電話ベストプラクティスをご覧ください。

統合後、1件の通話はどのように流れますか？

1件の通話は5つではなく2つのシステム、つまり音声AIプラットフォームとCRMだけを経由します。Retellでは次のとおりです。

1. CRMまたはバックエンドがAPI経由で通話を開始するか、一括発信リストをアップロードします。CRMのレコードIDなどのmetadataオブジェクトが通話に保存されます。
2. 通話前の関数が連絡先を検索し、エージェントはアカウントの文脈を把握した状態で会話を始めます。
3. RetellがRetellの番号またはインポートした自社番号から発信します。
4. 留守番電話とIVRの検出が最初の動きを決定します。
5. 会話中、連携ツールやカスタム関数が自社システムの読み書きを行います。
6. 人間の対応が必要な場合はエージェントが通話転送を行い、転送のwebhookイベントが接続の成否を記録します。
7. 通話後、Post Call Extractionが結果を構造化し、通話後の関数がCRMを更新し、call_endedとcall_analyzedのwebhookが関係する他のシステムに通知します。

すべてのステップが1つの通話IDに紐づき、通話記録には文字起こし、録音、切断理由が含まれます。

評価チェックリストには何を含めるべきですか？

各ベンダーには、スライドではなく実際の通話でこれらを示すよう依頼しましょう。

次に、AIの分単位料金だけでなく、すべてのレイヤーのコストを合計しましょう。ダイヤラー料金、キャリアの通話分数、自動化タスク、そしてそれらを同期させ続けるためのエンジニアリング工数です。Retellの料金ページによると、カスタム電話回線とSIPトランキングにはRetellの電話料金がかからず（キャリアからの請求は引き続き発生します）、Retellの番号は月額$2.00、一括発信は1発信あたり$0.005が追加されます。

どこから始めるか

回避策スタック全体を経由しているアウトバウンドキャンペーンを1つ選びます。1件の通話におけるすべての受け渡しを洗い出し、それぞれの責任者を特定し、その通話を受け渡すためだけに存在するレイヤーに印をつけます。それが統合の候補です。次に、自社の番号とCRMを接続した状態で実際の通話でパイロット運用を行い、問題が起きたときに関わるシステムの数を数えてみましょう。アウトバウンドチーム向けに統合を計画している場合は、発信、留守番電話対応、通話転送、CRMへの書き戻しを1つのプラットフォームで実現するRetellによるコンタクトセンター向けアウトバウンド発信をご覧ください。