音声AIの負荷テストが実際の通話経路に沿う必要がある理由

コンタクトセンタープラットフォームがすべての電話に最初に応答し、その後発信者をAI音声エージェントへ転送する構成の場合、AIに直接発信する負荷テストからわかることはほとんどありません。それで証明できるのは、AIが大量の通話を処理できることだけです。キャリア、通話制御プラットフォーム、エージェントへの転送、そしてエージェントからの転送が、ピーク時の通話量に耐えられることは証明できません。この種のデプロイにおける障害の大半はシステム間の接続部分で発生し、その接続部分にトラフィックが流れるのは、通話が本番環境と同じ経路をたどる場合に限られます。

一般的な手法（同時接続数の段階的な引き上げ、レイテンシのパーセンタイル、回帰テストスイート）については、音声エージェントの負荷テストに関するガイドをご覧ください。本記事では、UCaaSまたはCCaaSプラットフォームが通話制御を担うデプロイを扱います。

SIPやAPIへの直接負荷テストでデプロイの動作を証明できないのはなぜですか？

発信者が通過するすべてのホップを飛ばしてしまうからです。直接テストでは、AIプロバイダーのSIP endpointまたはAPIに通話を直接送ります。本番の通話はもっと長い経路をたどります。キャリアから着信し、コンタクトセンターまたはUCaaSプラットフォームに到達し、IVRまたはルーティングロジックを経て、音声AIのエントリーポイントへブラインド転送され、そこで終了するか、人間のオペレーターのキューへ転送し戻されます。

各ホップには、それぞれ固有の容量制限、SIPの挙動、設定の担当者があります。直接テストでは、そのいずれも検証されません。Retellのドキュメントから3つの例を挙げます。

• 容量は複数の場所で設定されています。Retellの同時接続数の上限はワークスペースごとに適用されます（従量課金のワークスペースは同時通話20件から開始）。RetellのFive9ガイドでは、Five9が独自のトランク容量制限を適用すると記載されており、Avayaガイドでは、管理対象のSIPトランク数が想定される同時通話数をカバーしているか確認するよう指示しています。プラットフォームを迂回するテストでは、その上限に達することはありません。
• 接続方式によってAIでできることが変わります。Retellは、Elastic SIPトランキング（推奨方式）とSIP URIへの発信をサポートしています。SIP URI方式では、Retellの組み込み転送機能が利用できないため、転送と通話終了は独自のロジックで処理する必要があります。直接テストでは、このギャップが明らかになることはありません。
• 転送は相手側に依存します。Retellのコールド転送はデフォルトでSIP INVITEを使用し、テレフォニープロバイダーが対応していればSIP REFERを使用します。REFERが機能するかどうか、またカスタムヘッダーがREFER後も保持されるかどうかは、AIではなくプロバイダーに依存します。

コンタクトセンタープラットフォームが通話制御を担う場合、実際の通話経路はどのようになりますか？

5つのホップの連鎖であり、すべてのテスト通話がこの5つすべてを通過する必要があります。

ここではRetellのドキュメントにある2つの詳細が重要です。SIP URI方式では、各通話でまずRegister Phone Callリクエストが必要で、通話は5分以内にそのURIに到達しなければregistered_call_timeoutで終了します。そのため、登録サービスも負荷に耐えられる必要があります。終了側では、RetellのGenesys Cloudガイドに、Genesysがさらに転送する通話はSiteの番号プランと発信ルートからトランクを選択すると記載されています。これは直接テストでは決して到達しないプラットフォーム設定です。

経路特有の障害は、ピーク時にどこで発生しますか？

2つのシステムが接する部分で、通常はどちらかがキューイングを始めたときに発生します。段階的な負荷引き上げ中は、次の点を監視してください。

1. 最も厳しい容量制限が全体を決めます。プラットフォームのトランクで許容される同時通話数がAIワークスペースより少ない場合、発信者はプラットフォーム内で滞留しますが、AIのダッシュボードは正常に見えます。キャリア、プラットフォームのトランク、AIの同時接続数上限は、まとめてサイジングしてください。
2. AI側での着信キューイング。着信がRetellの同時接続数上限に達すると、Retellは新しい通話を約40秒間保留します。空きが出なければ、設定されたfallback_numberに発信者を転送し、未設定の場合はconcurrency_limit_reachedで通話を終了します。フォールバック先（多くの場合、プラットフォームの人間のキュー）を事前に決め、負荷時にも機能することをテストしてください。
3. 発信トラフィックによる着信の圧迫。ワークスペース内のすべての音声通話は、1つの同時接続プールを共有します。同じワークスペースで発信キャンペーンも実行している場合、着信用に同時接続数を予約しておくことで、転送されてくる通話のための枠を確保できます。
4. 通話セットアップレート。Retellはテレフォニー経路ごとにCPS（1秒あたりの通話数）を設定しており、ドキュメントにはCustom TelephonyのCPSが同時接続数に応じてスケールすると記載されています。毎正時に転送が集中すると、同時接続数上限より先にレート制限に達する可能性があります。
5. ネットワークとメディアの設定。Retellは、許可リストに追加すべき複数のIPブロック（一部は特定の米国トラフィックにのみ適用）、トランスポート（TCP推奨、UDP、TLS、mTLS）、コーデック（PCMU、PCMA、G.722）を公開しています。これらのブロックの一部しかカバーしていない許可リストは、小規模なテストには合格しても、大量の通話では失敗する可能性があります。
6. 通話中のSIP変更。プラットフォームは、セッションの更新、メディアの移動、通話の保留のためにre-INVITEを送信することがあります。Retellは、セッション更新、メディアの再アンカー、コーデック変更、SRTPの鍵再設定、保留・保留解除のためのダイアログ内re-INVITEに応答します。プラットフォームのre-INVITEが大量の通話でも同様に動作することを確認してください。

実際の経路を通してテストトラフィックを生成するにはどうすればよいですか？

テスト通話は自社ネットワークの外から発信し、発信者が使うのと同じ公開番号にかけてください。それが、すべてのホップに負荷をかける唯一の方法です。

• 公開番号に発信できる通話ジェネレーターを選びます。Retellの一括発信（バッチコール）はRetellから発信を行い、Retellのシミュレーションテストはテキストベースの会話を実行するため、どちらもプラットフォームから転送されてくる着信を再現できません。実際に電話をかけるテストパートナーもあります。たとえばHammingは、自社の音声エージェントがお客様のエージェントに電話をかける仕組みを紹介しています。テストベンダーには、通話が公衆電話網を経由するのか、エージェントに直接接続するのかを確認してください。
• すべてのテスト通話にタグを付けます。転送時に、プラットフォームでカスタムのX- SIPヘッダー（テスト実行IDなど）を付与します。Retellは着信のX-ヘッダーを通話のcustom_sip_headersフィールドと動的変数に抽出するため、各AI通話をプラットフォームの記録と紐付けられます。
• 段階的に負荷を上げます。想定ピークを下回る水準から始め、ピークを超えるまで段階的に引き上げた後、トラフィックを減らしてシステムがアイドル状態に戻ることを確認します。
• すべての担当者を招集します。キャリア、プラットフォーム管理者、音声AIベンダーの全員が参加すべきです。RetellのFive9ガイドでは、最終的な統合テストを合同セッションとして実施します。
• 上限はテスト中ではなく、テスト前に引き上げます。LimitsページでAIの同時接続数とCPSの上限を確認し（組み込みの計算ツールが繁忙時間帯のトラフィックから推奨値を提示します）、プラットフォームのトランク容量が一致していることを確認してください。

テスト中に監視すべきSIPシグナルは何ですか？

転送の両側で、最初のINVITEから最後のBYEまで、すべての通話のシグナリングを監視します。Retellの通話詳細には、通話のSIPシグナリングを表示するPacket Captureタブが含まれる場合があり、PCAPデバッグガイドではWiresharkでの読み方を解説しています。独自のトランクを運用している場合、RetellのドキュメントではSIPを終端するサーバーまたはゲートウェイ（通常はSBC）でキャプチャすることを推奨しています。

確認すべき点：

• 転送レッグでの正常なセットアップ：INVITE、100 Trying、180 Ringing、200 OK、ACK。
• エラーレスポンス：403（許可リストまたは権限）、404（SIP URIまたはルーティングの誤り）、408または477（到達不能なendpointまたはトランスポートエラー）、486（ビジー）、503（サービス利用不可）。
• 送出側の転送：転送方式に応じたREFERまたは新しいINVITE、そしてX-ヘッダーが保持されているかどうか。Retellのドキュメントでは、転送先がSIP endpointではなくPSTN番号の場合、カスタムヘッダーが削除される可能性があると注意喚起しています。
• 誰がいつBYEを送信したか：すべての通話は、想定どおりの当事者からのBYEで終了する必要があります。

Retellのwebhookイベント（call_started、call_ended、transfer_*イベント）により、キャプチャと照合できる通話ごとのタイムラインが得られます。

何をもって合格とすべきですか？

合格とは、AIが稼働し続けたことだけでなく、すべてのシステム間で数値が一致することを意味します。次のチェックリストを使用してください。

• テスト期間中の通話件数が、キャリアの記録、プラットフォームのレポート、AIの通話ログで一致している。
• すべてのAI通話が想定どおりの切断理由（user_hangup、agent_hangup、call_transfer）で終了し、concurrency_limit_reachedやerror_*の理由がない。
• 人間への転送がすべて、想定どおりの発信者番号とヘッダーで正しいキューに到達した。
• 意図的に発生させたものを除き、転送レッグでSIP 4xxまたは5xxレスポンスがない。
• サンプリングした通話で、双方向に音声が流れていた。
• ピーク時の同時接続数が、チェーン内のすべての上限を余裕をもって下回っていた。
• トラフィック停止後、AI側の同時接続数がゼロに戻り、プラットフォームに残存セッションがなかった。

最後のチェックは、独立したテスト計画を立てる価値があります。転送後に完全に終了しない通話は、ピーク時に同時接続数を消費する可能性があるためです。通話終了については別のガイドで解説しています。

テスト前に音声AIベンダーに何を確認すべきですか？

AIだけでなく、経路全体をベンダーに示してもらうための質問をしましょう。

1. 当社のプラットフォームに推奨される接続方式はどれですか？また、それによって転送と通話終了に関して何が変わりますか？
2. どのSIP転送方式（INVITE、REFER）をサポートしていますか？また、それぞれ当社のプラットフォームに何が求められますか？
3. カスタムSIPヘッダーを双方向で受け渡し、読み取るにはどうすればよいですか？
4. 同時接続数とCPSの上限はどこで設定されていますか？上限に達した通話はどうなりますか？また、テストのために上限を引き上げることはできますか？
5. 通話ごとのSIPシグナリングと切断理由を確認できますか？また、テレフォニーチームがキャプチャを一緒に確認してくれますか？

Retellのドキュメントには、Genesys Cloud、Five9、Avaya、Amazon Connectのセットアップガイド、一般的なカスタムテレフォニーガイド、各上限を解説した同時接続数ガイドが含まれています。エージェントからの転送については、通話転送とAIから人間への引き継ぎの仕組みをご覧ください。

プラットフォームが通話制御を担っており、その背後に組み込めるAI音声エージェントが必要な場合は、Retellのエンタープライズ向け会話型AIプラットフォームをご覧いただき、実際の通話経路での負荷テストの計画についてチームにご相談ください。

関連記事：通話終了の負荷テスト、CRMから音声AIへのワークフロー、その他のガイドはRetell Learnハブでご覧いただけます。