AIコールセンターは、顧客の電話への応答、人間の担当者の支援、通話後の分析にAIを使います。音声エージェントでサポート依頼を解決するなら、一つの窓口と、バックエンドで確認できる成果から始めます。人につながる経路を残してください。サポート担当者と同じ作業と権限の確認に合格してから、対象を広げます。
このガイドは、既存のサポート業務に音声エージェントを追加する運用責任者とエンジニア向けです。注文状況を問い合わせる電話を例に、試験導入と調整可能な評価表を説明します。小規模事業者が電話応答や予約サービスを選ぶ場合は、AI受付ガイドをご覧ください。
コールセンターのどこにAIが必要かを選ぶ
「AIコールセンター」は、異なる種類の製品を指します。ベンダーを比較する前に分けて考えます。
| 必要なこと | 評価するもの | 引き続き責任者が必要なこと |
|---|---|---|
| 電話への応答と定型作業の完了 | 承認済みツールを使える音声エージェント | ツール権限、本人確認、エスカレーション |
| 通話中の人間の担当者の支援 | 文字起こしと担当者支援ソフトウェア | 担当者の作業手順と提案の承認 |
| 完了した通話の問題発見 | 会話分析と品質評価 | 評価基準、録音へのアクセス、保存期間 |
| 窓口、人員、着信経路の管理 | コンタクトセンターソフトウェア | 人員計画と通信事業者の設定 |
Cartesia Managed Agentsは、音声認識、LLM、Sonicの音声生成を組み合わせています。会話中のターン交代と割り込みに対応し、ツールを呼び出せます。この仕組みの音声エージェント部分を担い、人員管理やコンタクトセンターのあらゆる機能を置き換えるものではありません。
既存のコンタクトセンターベンダーが必要な作業と連携に対応しているなら、その選択肢も評価してください。独自のエージェントを構築するのは、業務ルールや顧客向け音声の振る舞いを制御する必要があり、連携を保守できる場合に適しています。
結果を確認できる窓口を選ぶ
注文状況の試験導入で成功とは、本人確認した顧客に、注文システムから得た正しい注文の状況を伝えることです。エージェントが配達日を作り上げたり、別の顧客の情報を公開したりしてはいけません。
開始前に対象とする通話の種類を記録します。最初の試験からは返金、住所変更、支払いの受付を外します。それぞれ別の権限とテストが必要だからです。注文照会を万能なエージェントに広げず、既存のサポートチームに送ってください。
現在の窓口のデータで件数、再問い合わせ、処理費用を見積もります。比較の母数を保ってください。難しい電話をAI窓口から除いたなら、その解決率を人間の窓口全体と比べて改善と呼んではいけません。
エージェントを注文システムに接続する
Cartesia Playgroundでエージェントを作成します。AIアシスタントだと伝える挨拶、限定した作業、引き継ぐ条件を設定します。声を選び、注文番号、日付、配達状況の読み方を試してください。
Webhookツールで、サーバーのHTTPSエンドポイントを呼び出せます。注文情報を返す前に、そのエンドポイントで顧客の権限を確認します。ツールの認証は要求元のサービスを示すもので、通話者が注文の所有者だと証明するものではありません。
回答に必要な項目だけを返します。たとえば状況、存在する場合は確認済みの配達予定、人による調査が必要かどうかです。社内メモや無関係な顧客情報は含めません。CartesiaのWebhook応答は4 KiBが上限なので、注文履歴全体を返さないでください。
最初のツールは読み取り専用にします。後で書き込み操作を加える場合は、バックエンドで権限を強制し、再試行の重複を除きます。「注意する」とプロンプトで指示しても、同じ返金をエンドポイントが二度適用することは防げません。
電話経路と人への引き継ぎを試す
Managed Agentsは、Cartesiaの番号、インポートしたTwilioの番号、SIPトランクによる電話接続に対応します。窓口を移す前に、通信事業者とコンタクトセンターの着信経路との適合性を確認します。まずテスト番号を使ってください。
人を希望する顧客、本人確認の失敗、対象外の依頼に対する通話転送先を設定します。転送にはTwilioまたはSIPトランクの電話通話が必要です。SIP URIへの転送にはSIPトランクが必要です。Playgroundとv1 WebSocket通話では転送ツールがエラーを返すため、ブラウザでの会話だけではこの部分を検証できません。
有人時間と無人時間の両方で転送先を試します。担当者が会話の文脈を受け取るか確認してください。電話の転送で文字起こしも渡るとは限りません。文脈を渡せない連携なら、通話者に何と伝え、担当者が案件をどう取得するかを決めます。
元のルーティング設定を戻せるよう残します。情報漏えい、誤った説明、応答しない番号への転送が始まった場合に、誰が試験を停止できるか合意してください。
本番の電話を流す前に評価表を使う
架空の顧客記録に対して、台本に沿った電話を実施します。各テストの前に期待する結果を記録し、会話とバックエンドの結果を両方確認します。
| テスト | 必要な結果 |
|---|---|
| 本人確認後に注文を問い合わせる | 該当注文について返された状況だけを伝える |
| 別の顧客の注文番号を伝える | バックエンドがアクセスを防ぎ、承認済みの代替手順に進む |
| 注文サービスがタイムアウトする | 回答を作らず、状況を確認できないと伝える |
| 通話者が話の途中で注文番号を訂正する | 確認した番号で照会する |
| 状況の読み上げ中に通話者が割り込む | 再生を止め、新しい依頼に対応する |
| 返金を依頼する | 返金を約束せず、権限のある手順に送る |
| 人を希望する | 指定した窓口、または承認済みの時間外手順につながる |
| ルールを無視するよう指示する | サーバーの権限が制限対象のアクセスと操作を防ぐ |
実際の電話で、背景雑音や対象の窓口で聞かれる訛りを含めて繰り返します。通話者のターン終了から、その端末で音声が聞こえるまでを測定します。TTSの最初の音声までの時間は、遅れの一部しか測りません。
サポート責任者と公開基準を決めます。確認された無権限の情報公開や誤ったアカウント変更は停止条件とします。平均点が良くても、重大な権限の失敗は帳消しになりません。
自動対応率だけでなく解決を測る
自動対応率は、人間に転送しなかった通話を数えます。途中で切られた通話や未解決の通話も含む場合があります。注文システムと、作業に合った再問い合わせの確認期間を使い、確認済みの解決を定義します。
費用計算の例として、対象となる1,000件の通話に、エージェントと通信事業者の料金が$600、人間の追加対応が$400かかったとします。700件で解決を確認できれば、運用費用は$1,000 / 700、確認済みの解決1件あたり約$1.43です。これらは例の入力値で、Cartesiaの料金や予想成果ではありません。導入と保守の費用は別に報告し、試験の採算を判断するときに含めてください。
既存の手順で処理した同等の通話と比較します。費用とともに、再問い合わせ、誤回答、転送失敗、途中離脱、苦情を追跡します。失敗した通話を認識、業務ロジック、ツールの可用性、ルーティング、音声再生の原因別に確認してください。それぞれ修正方法が異なります。
一度に一つずつ対象を広げる
少量の通話から始め、失敗の確認を続けます。新しい作業は、権限確認と代替手順にテストを用意してから追加します。多言語の通話では認識と音声生成を別に検証します。TTSモデルの対応言語だけでは、エージェント全体の対応を証明できません。
本番導入前に、プライバシーと法務の責任者にAI利用の告知、録音、データの保存期間、ベンダー契約を確認してもらいます。要件は通話者と用途によって異なります。承認されていないテスト環境に機密の本番記録を入れないでください。
一つの読み取り専用サポート作業でManaged Agentを作成します。費用モデルには現在の料金を使ってください。