音声エージェントの負荷テスト:Retellで自分の音声エージェントを大規模にテストする方法

音声エージェントの負荷テスト:Retellで自分の音声エージェントを大規模にテストする方法
ブログ一覧へ戻る
このページの目次
トップへ戻る

音声エージェントの負荷テストとは、デモで1件のクリーンな通話を実行するときだけでなく、200人の発信者が一斉にアクセスしたときにも、AI音声エージェントが正常に動作するかどうかを確かめる方法です。

これは、ステージ上では素晴らしく見えるエージェントと、ローンチ当日に耐えられるエージェントとの違いです。

多くの音声AI開発者が見落としているのがこの点です。この種のテストは、エージェントを出荷するのに使うのと同じプラットフォームであるRetell上で、大規模に実行できます。

このガイドはAIエンジニアとプラットフォームチーム向けに書かれています。音声エージェントの負荷テストとは何か、大規模にテストすると通常のQAがなぜ破綻するのか、そしてRetellで大規模なテスト実行をどう設定するかを扱います。

TL;DR

  • 音声エージェントの負荷テストは、1件ずつではなく、多数の同時通話の下でエージェントがどう動作するかを確認します。

  • 大規模にテストすると、単一通話では決して現れない障害が表面化します。レート制限、レイテンシ(遅延)の急増、コンテキストの喪失、負荷の下で品質が低下する応答などです。

  • 隠れたユースケース:Retellは一括発信(バッチコール)、組み込みのQA、通話後分析を使って、これらのテストをあなたの代わりに実行できます。

  • 大規模に4つの点をテストしましょう。機能カバレッジ、負荷と同時実行数、あらゆる変更に対する回帰、そして敵対的な入力です。

  • 平均値ではなく、レイテンシのパーセンタイル(P50、P90、P99)、単語誤り率、タスク完了率、封じ込め率を追跡しましょう。

  • Retellで始め、自分のテレフォニーを持ち込み、公開された分単位のレートからコストを予測できます。

音声エージェントの負荷テストとは

音声エージェントの負荷テストは、AI音声エージェント向けに構築された負荷テストの一形態です。多数の発信者が同時にエージェントと話す様子をシミュレートし、負荷が高まるにつれてエージェントが高速で、正確で、一貫性を保てるかどうかを測定します。

これは、システムが所定のワークロードの下でどう動作するかを確認する、より広範なソフトウェアパフォーマンステストの実践に含まれます。音声エージェントの特徴は、ワークロードがトラフィックだけではないという点です。それは計算処理です。

従来の電話システムには予測可能な負荷があります。回線に応答し、メニューを再生し、通話をルーティングします。AI音声エージェントは、各ターンで音声認識、言語モデル、音声合成を実行するため、各同時通話は電話回線だけでなく、tokenとGPU時間を消費します。

だからこそ、大規模にテストすることは別の問題なのです。10件の通話なら問題なく動くかもしれません。200件になると、モデルプロバイダーがレート制限エラーを返し始め、レイテンシが上昇し、鋭く聞こえていたエージェントが今や不自然に間を空けたり、発信者を途中で切ったりします。

音声エージェントを大規模にテストすると通常のQAがなぜ破綻するのか

多くの音声エージェントのQAは1件ずつ通話を確認します。それは文言やロジックのバグを捕捉しますが、プレッシャーの下でのみ現れる障害を隠してしまいます。ローンチ時にチームを悩ませるものをいくつか挙げます。

  • レート制限とクォータエラー:負荷の下では、言語モデルや音声プロバイダーがリクエストをスロットリングすることがあり、一部の通話が会話の途中で停止したり失敗したりします。

  • 負荷の下でのレイテンシ:単独テストでは300ミリ秒で返る応答が、スタックが混雑すると1秒を超えて延びることがあり、通話のリズムを崩します。

  • コンテキストの喪失または劣化:同時実行数が増えると、一部のシステムは計算処理を節約するために会話履歴を切り詰めるため、エージェントは発信者が2ターン前に言ったことを忘れます。

  • ひそかに低下する品質:低負荷では忍耐強いエージェントが、サーバーが最大限に使われると簡潔で誤りがちになることがあります。1件の通話をテストしても、それは決して見えません。

  • テレフォニーの制限:キャリアやプラットフォームの同時実行数の上限が、AIがボトルネックになる前に通話をブロックすることがあります。

これらのどれも、単一のハッピーパスの通話では現れません。それらすべては、本番トラフィックが到来したときに現れます。負荷テストは、顧客のスケジュールではなく、あなたのスケジュールでそれらに対処する方法です。

音声エージェントを大規模に実行するときに何をテストすべきか

大規模にテストすることは、量だけの問題ではありません。実行を4つの点に向けましょう。

  • 機能カバレッジ:コアとなる通話タイプと、割り込み、アクセント、背景ノイズ、スクリプト外の質問といった厄介なエッジケースを、5件ではなく多数の通話にわたって実行しましょう。

  • 負荷と同時実行数:ベースラインから予想されるピーク、そしてそれを超えるところまで段階的に上げ、どこでレイテンシとエラー率が破綻するかを注視しましょう。

  • 回帰:あらゆるprompt、モデル、音声の変更のたびに全スイートを再実行し、ある箇所の修正が別の箇所を壊さないようにします。これは音声に適用された標準的な回帰テストです。

  • 敵対的とセーフティ:誰かが先にやる前に、ジェイルブレイク、prompt漏洩、ポリシー外の応答を探ります。

パフォーマンステストからの有用なパターン:低い同時実行数でベースラインを設定し、段階的に上げ、破綻点を注視し、その後負荷が下がった後にシステムが回復することを確認します。

隠れたユースケース:Retellを使って自分の音声エージェントをテストする

ここで種明かしです。Retell AI はAI音声エージェントを構築・出荷するためのプラットフォームとして知られていますが、同じプラットフォームがテストを実行します。

一括発信(バッチコール)を使って大規模なテスト実行を駆動できます。これはリストから多数の通話を一斉に発信します。テスト用の番号とペルソナに向ければ、オンデマンドで同時負荷を生成する方法が手に入ります。

これらの各通話は、組み込みのAI品質保証でスコアリングできるため、障害を見つけるために何百もの録音を手作業で聞く必要はありません。

通話後分析は、テストであれライブであれ各通話をログに記録するため、文字起こしを読み、結果を確認し、実行全体を通じてフローがどこで破綻したかを見ることができます。

RetellはTwilioVonageを通じて自分のテレフォニーに接続するため、上乗せされたパススルー料金を支払う代わりに、テストのキャリア側を自分で管理できます。

エンジニア向けには、開発者向けドキュメントが、これらすべてを自分のパイプラインにスクリプト化するためのAPIを扱っています。

テスト通話は完全なスタックを通じて実行されるため、通話と同じように課金されます。料金は分単位で公開されているため、実行する前に負荷テストの予算を予測できます。

Retellで音声エージェントの負荷テストを設定する方法

実際の設定は次のようになります。

  1. シナリオとペルソナを定義します。上位の通話タイプから始め、次に懸念されるエッジケースを追加します。割り込み、アクセント、スクリプト外の依頼などです。

  2. Retell上でエージェント、またはそのテスト用のコピーを構築し、ナレッジベースと本番で使うツールに接続します。

  3. 自分のテレフォニーを接続し、テストトラフィックが実際に使うキャリア経路を通るようにします。

  4. 一括発信(バッチコール)を使って多数の通話を一斉に開始し、同時実行数をベースラインから予想されるピークを超えるところまで上げていきます。

  5. AI QAで結果をスコアリングし、次に通話後分析でそれらをレビューし、失敗した通話や低品質の通話をフィルタリングします。

  6. 修正し、その後スイートを再実行します。結果でリリースをゲートし、数値が持ちこたえるまで何も出荷しないようにします。

ステップ4から6をCIパイプラインに組み込めば、負荷テストはローンチ週の慌ただしい作業ではなくなり、あらゆる変更のたびに実行されるものになります。

負荷の下で重要となる指標

平均値は信頼を損なう通話を隠します。代わりに分布を追跡しましょう。

  • レイテンシのパーセンタイル(P50、P90、P99):P99は、他の全員が問題ない中で待たされている発信者です。予想されるピークの2倍から3倍でも目標を維持することを目指しましょう。

  • 単語誤り率:音声認識が発信者を聞き間違える頻度で、アクセント、ノイズ、負荷とともに上昇します。

  • タスク完了率:エージェントは発信者が求めてきたことを解決したか?

  • 封じ込め率:エージェントが人間への通話転送なしに処理した通話の数。

  • エラー率とドロップ率:同時実行の下で失敗、停止、または音声を失った通話。

シナリオごとに閾値を設定しましょう。銀行のエージェントとフード注文の回線は許容できるエラー率が異なるからです。数値はスタック、モデル、トラフィックによって変わるため、これらを普遍的な目標ではなく、自分自身のベースラインとして扱いましょう。

大規模にテストするためのベストプラクティス

  • 発信者に合った音声でテストする。自分の通話ログにあるアクセントと言語をカバーし、車内や混雑したオフィスのノイズを加えます。

  • 段階的にスケールする。まずベースライン、その後同時実行数を段階的に上げ、パフォーマンスが破綻する前に、どこで曲がるかを見られるようにします。

  • 本番の障害を再生する。ライブ通話が失敗したときは、それを捕捉してスイートに追加し、二度とひそかに回帰しないようにします。

  • 通話完了だけでなく品質を測定する。AIが負荷の下で愚かになってしまっていたら、電話回線が開いていても成功ではありません。

  • スイートを自動化する。手動QAはわずかな数の通話をカバーしますが、自動化はあらゆる変更のたびに何百もの通話をカバーします。

  • ニュアンスのある通話には人間を関与させ続ける。自動スコアリングとスポット的な人間のレビューを組み合わせると、どちらか一方だけでは見逃すものを捕捉できます。

よくある質問

音声エージェントの負荷テストとは何ですか?

それはAI音声エージェント向けのパフォーマンステストです。多数の同時発信者をシミュレートし、負荷が高まるにつれてエージェントが高速で、正確で、一貫性を保てるかどうかを測定します。単一通話のテストでは決して表面化しない、レート制限やレイテンシの急増といった障害を対象とします。

Retellを使って音声エージェントを大規模にテストできますか?

はい。Retell上でエージェントを構築またはコピーし、一括発信(バッチコール)を使って多数の通話を一斉に発信し、組み込みのQAでスコアリングし、通話後分析で結果をレビューできます。それにより、1つのプラットフォームで同時負荷と自動評価が得られます。

負荷テストは通常の音声エージェントのテストとどう違いますか?

通常のテストは、1件の通話について正しい文言とロジックを確認します。負荷テストは、多数の通話を同時に、プレッシャーの下での動作について確認します。同時実行の下でのレイテンシ、スロットリング、コンテキストの喪失、サーバーが混雑したときに低下する品質などです。

何件の同時通話をテストすべきですか?

10件から50件のベースラインで始め、その後予想されるピークとそれを超えるところまで段階的に上げ、どこでレイテンシとエラーが破綻するかを注視します。目標は、実際のトラフィックが破綻させる前に、意図的に破綻点を見つけることです。

負荷テストは分単位のプラットフォームで追加コストがかかりますか?

テスト通話はライブ通話と同じスタックを通じて実行されるため、分単位で課金されます。公開されたレートと自分のテレフォニーを持ち込めるプラットフォームを選び、コストを予測してキャリア回線を管理下に置けるようにしましょう。

発信者が確かめる前に、エージェントがどれだけ耐えられるかを確認しましょう。

Retellは、一括発信(バッチコール)、組み込みのQA、公開された分単位の料金とともに、1つのプラットフォームでAI音声エージェントを構築、テスト、監視できるようにします。Retellを無料で試すか、営業に問い合わせる

ROI計算ツール
通話の自動化によるROIを試算

AI搭載の音声エージェントに切り替えることで、あなたのビジネスがどれだけ節約できるかをご確認ください。

完了しました! 
送信内容がメールに届いています
エラーが発生しました。フォームの送信中に問題が起きました。
   1
   8
20
エラーが発生しました。フォームの送信中に問題が起きました。

ROI結果

2,000

Total Human Agent Cost

$5,000
/month

AI Agent Cost

$3,000
/month

Estimated Savings

$2,000
/month
ライブデモ
ライブデモを試す

Retell クリニックオフィスのデモ電話番号

ありがとうございます!送信が完了しました!
エラーが発生しました。フォームの送信中に問題が起きました。

Read Other Blogs

No items found.

Revolutionize your call operation with Retell