IVRテストの種類とツール、音声エージェントの検証

IVRテストとは、顧客と同じように自社の電話システムへ発信し、すべての通話が正しい場所に着くかを確かめることです。壊れたIVRの多くは、つなぎ目で失敗しています。アナウンスは変わったのにルーティングルールが古いまま、18時に閉まったキューへの転送、「薬局」を「役得」と聞き取る音声モデル。こうした不具合は、実際の電話経路で実際に通話しないと見えません。

このガイドでは、プッシュ式と音声式のIVRで使う標準的なテストの種類を説明し、続いて電話に出るのがAI音声エージェントになると何が変わるかを扱います。要点はこうです。プッシュ式メニューには経路ごとに正しい台本が1つありますが、音声エージェントには許容できる会話がいくつもあり、正しい結果は1つです。テストでは結果を確認する必要があります。

IVRテストの種類

問題の大半は機能テストと回帰テストで見つかります。負荷、ストレス、耐久テストが重要になるのは、IVRの後ろに本当のピークを持つコンタクトセンターがある場合です。たとえば加入受付期間、製品リコール、請求処理の翌週の月曜日などです。

プッシュ式メニューや音声メニューのテスト

従来型のIVRは木構造です。各ノードにアナウンスと決まった入力の集合があるため、すべての経路を書き出して確認できます。

まずコールフローを書き出し、各経路をテストケースにします。経路とは入力の並びと期待する結果の組み合わせです。たとえば2、次に1を押し、口座番号を入力したら、口座情報が付いた状態で請求窓口のキューに着く、という形です。理想的な経路だけでなく、発信者がうっかり通る経路も含めます。

• 何も入力せずにタイムアウトまで待つ
• 無効なキーを押してから有効なキーを押す
• どの階層でも 0 を押す、または「オペレーター」と言う
• 営業時間外に発信する
• 存在しない口座番号を入力する
• アナウンスが終わる前に番号を入力する（メニューを覚えている人はこうします）

音声メニューでは、テスト入力は録音です。話者を変え、スタジオのマイクではなく電話回線を通し、車内や台所のような背景雑音を入れます。使う言葉はメニューの項目名ではなく、通話記録に残っている顧客の実際の言い方にします。発信者は「アカウントサービス」より「請求書のこと」と言うほうがずっと多いのです。

音声だけでなくデータも確認します。通話が請求窓口のキューに着き、オペレーターの画面に正しい口座が表示されて初めて合格です。IVRが番号を受け取ったのに転送で失われたら、発信者はもう一度読み上げることになります。アナウンスがすべて正しく流れても、これは不合格です。

対話型IVRやAI音声エージェントのテスト

AI音声エージェントが電話に出るようになると、台本の照合は使えなくなります。エージェントはある通話では「かしこまりました、変更しますね」と言い、次の通話では「承知しました、その予約を移動できます」と言います。どちらも正解です。文言を完全一致で比べるテストは毎回失敗し、何も教えてくれません。

代わりに、期待する結果を書いたシナリオを用意します。

各シナリオは複数回実行します。音声エージェントは、言い回しが違ったり、モデルが会話の中で別の道筋をたどったりして、4回通ったシナリオに5回目で失敗することがあります。言い回しを変えて1シナリオあたり5〜10回実行すると、その大半を拾えます。人物像の設定も役に立ちます。急いでいる人、混乱している人、地方のなまりが強い人、騒がしい部屋にいる人などです。

各実行は2種類の方法で採点します。事実の確認は自社システムを読みます。予約は動いたか、転送は正しい番号に着いたか、エージェントは通話を終えたか。判断の確認は文字起こしを読みます。エージェントは新しい時間を声に出して確認したか、発信者がいら立っても丁寧さを保ったか。後者には、メトリクスごとに1つの具体的な質問を持つLLMジャッジが向いています。「良い通話でしたか」と聞くと意見が返ってきますが、「通話が終わる前に発信者は新しい予約時間を聞きましたか。はいかいいえで答え、該当する発言を引用してください」と聞けば、数えられる答えが返ってきます。

ルーティングに特化したテストセットは対話型IVRのガイドにあります。ルーティング精度の数字を過信せずに読む方法も載っています。

遅延はログではなく電話口で測る

発信者は、自分が話し終えてからエージェントが話し始めるまでの間を遅延として感じます。その間には、発話の終わりの判定、LLM、音声合成、電話サービスと通信事業者を経由して戻る時間が含まれます。音声合成の最初のバイトまでの時間だけを示すダッシュボードは、その一部しか表していません。

通話そのものの録音から測ってください。双方を録音し、発信者の発話の終わりと各応答の始まりに印を付け、中央値と最も遅い5%を報告します。最も遅い通話こそ「もしもし、聞こえてますか」と言われ、同じ質問を繰り返される通話です。

発信には厳しい上限もあります。米国のTCPAの放棄呼ルールでは、相手が応答してあいさつを言い終えてから2秒以内につながらない通話は放棄呼として数えられます。2X Solutionsは応答遅延を500〜900ミリ秒から100ミリ秒未満に縮め、月に数百万件の通話で放棄呼率を3.4%から1.25%未満に下げました。エージェントが発信する場合は、すべての発信シナリオで「もしもし」からエージェントの最初の一言までの時間を測ってください。

モデルが変わるときの回帰テスト

音声エージェントは、プッシュ式メニューにはなかった形で変化します。新しいプロンプト、新しいLLM、新しい声、新しい音声モデルは、どれも手を付けていない経路の挙動を変えることがあります。どれもリリースとして扱い、すべてのシナリオを再実行してください。

固定できるものは固定します。CartesiaのSonicには sonic-3.6-2026-08-27 のような日付付きスナップショットがあり、一度公開されると変わりません。本番を切り替える前に、新しいスナップショットでシナリオを実行できます。Managed Agentsは設定の変更をすべてバージョンとして保存するので、新しいプロンプトが以前は通ったシナリオで失敗したら、前のバージョンに戻してから原因を調べられます。

失敗は残しておきます。本番でうまくいかなかった通話は、発信者の実際の言い回しのまま新しい回帰シナリオにします。数か月たつと、そのセットは最初に机上で書けるどんなものより役に立つようになります。

Cartesiaでテスト用の発信者を作る

Cartesia Managed Agents自体で、基本的な自動テスト用の発信者を作れます。

1. 1つのシナリオを指示に書いたテスト用エージェントを作ります。誰なのか、何を求めているのか、IVRにどう反応するかを書きます。
2. システムツール send_dtmf を有効にし、電話メニューの中でエージェントがプッシュ操作できるようにします。
3. テスト用エージェントからIVRの番号へ発信します。テスト一式を流すなら、一括発信で最大5,000件の通話をキューに入れ、設定した同時接続数の範囲で発信できます。
4. テスト用エージェントにカスタムメトリクスを割り当てます。それぞれを「通話は薬局のキューに着きましたか」のような具体的なLLMジャッジの質問にします。結果はCSVで書き出せます。

同じメトリクスは本番のエージェントにも使えます。Managed Agentsは完了したすべての通話を2つの組み込みメトリクスで採点します。エージェントの障害なく通話が終わったかどうかと、エージェントの最初の応答で音声の最初のバイトが届くまでの時間です。割り当てたカスタムメトリクスはその後の通話に適用されるので、本番の通話がそのまま監視用のデータになります。

この構成は回帰テストと本番監視に向いています。一括発信はアカウントのエージェント通話の同時接続上限を本番の通話と共有するため、コンタクトセンターのピーク水準で負荷テストを行うには別途キャパシティの計画が必要です。マネージドのテスト一式や、負荷テストを代行するチームが必要なら、専門ベンダーを使ってください。Cekuraは公開前後の音声エージェントに対して模擬の発信者を走らせ、その発信者にCartesiaの声を使えます。Cyaraは従来型のコンタクトセンターIVR向けの定番です。CovalとHammingもAI音声エージェントをテストします。

どこから始めるか

今まったくテストしていないなら、8本の通話から始めてください。最も多い用件4つ、営業時間外の通話、人と話したいと言う発信者、無効な入力、社内システムが止まっているときの通話です。実際の番号で一度手作業で発信し、何が起きたかを記録してから、同じ8本を自動化します。実際の失敗が出るたびにシナリオを追加していきます。

プッシュ式メニューを音声エージェントに置き換えるなら、切り替える前に両方を同じシナリオで実行してください。展開の進め方はコンタクトセンター自動化のガイド、テスト対象の構成要素は音声エージェントのガイドで説明しています。自社のコールフローでエージェントを試すなら、プレイグラウンドで作成して電話をかけてみてください。