西山です。
Amazon Connect Advent Calendar 2025 の22日目の記事です。
re:Inventで大量のアップデートが来る前に、Persistent Agent Connection（永続的なエージェント接続）が提供されるというアップデートがありました。
通話処理を高速化するための機能として紹介されていますが、実際にどういった挙動になるのかというものを調査してみました。
ちなみに、アップデート記事に記載されている”アウトバウンドキャンペーンの通話において米国の電話消費者保護法 (TCPA) などのテレマーケティングの法律に関するコンプライアンス要件”というのは以下を指しているようです。
システムが自動で電話をかけ、顧客が受話器を取ったにもかかわらず、「2秒以内」にオペレーターに繋がらないコールを「放棄呼（Abandoned Call）」と呼び、 TCPAではこの放棄率をキャンペーン全体の 3%未満 に抑えることが義務付けられている。
アウトバウンドキャンペーンでは顧客が応答してからエージェントにルーティングされ、通話を接続するという流れになるため、Persistent Agent Connectionは2秒という短い時間の中でそれを可能にしてくれているようです。
目次
改めてPersistent Agent Connectionとは
エージェント設定のオプションで、有効化すると通話切断後も数分間Amazon Connectのメディア通信のWebSocketコネクションを維持するようになるという機能です。
これにより、メディア通信のコネクションが使い回されるようになり、通話ごとにWebSocketコネクションを新規で接続を確立する必要がなくなるため処理が高速化されます。
数分間通話がない場合、端末やネットワークのリソースを節約するために自動的にコネクションは切断され、再度通話が発生した際に新規で接続を確立するようです。
おなじみのネットワーク図で言うと以下の部分の通信の話です。
Amazon Connect 問い合わせコントロールパネル (CCP) を使用するようにネットワークをセットアップする
設定を有効化するには？
デフォルトで有効化されています。
新規エージェント作成画面では有効化にチェックが付いた状態となっており、既存のエージェントもすべて有効化された状態になっています。
有効化したケースと無効化したケースの動作の違い
Persistent Agent Connectionを有効化したケースと無効化したケースの動作を実際に見てみます。
テストシナリオは1回目の着信通話後にすぐに2回目の着信通話が来るシンプルなものです。
受付可→通話着信→通話（10秒）→切断→後処理（10秒）→受付可→すぐ通話着信→通話（10秒）→切断→後処理（10秒）→受付可
CCPのログ内のTelemetryCallReportから比較をしてみます。
TelemetryCallReportは通話統計データですが、その中から関連する情報だけを抜粋しました。
1回目の通話
| メトリクス | 無効時 | 有効時 | 差分 |
|---|---|---|---|
| callStartTime | 2025-12-20T00:20:21.166Z | 2025-12-20T00:17:12.399Z | – |
| callEndTime | 2025-12-20T00:20:36.625Z | 2025-12-20T00:17:28.559Z | – |
| gumTimeMillis | 79ms | 80ms | +1ms |
| initializationTimeMillis | 87ms | 91ms | +4ms |
| iceCollectionTimeMillis | 1ms | 0ms | -1ms |
| signallingConnectTimeMillis | 1ms | 0ms | -1ms |
| handshakingTimeMillis | 67ms | 64ms | -3ms |
| preTalkingTimeMillis | 185ms | 181ms | -4ms |
| firstRTPTimeMillis | 378ms | 336ms | -42ms |
2回目の通話
| メトリクス | 無効時 | 有効時 | 差分 | 削減率 |
|---|---|---|---|---|
| callStartTime | 2025-12-20T00:20:55.811Z | 2025-12-20T00:17:49.087Z | – | – |
| callEndTime | 2025-12-20T00:21:11.172Z | 2025-12-20T00:18:04.860Z | – | – |
| gumTimeMillis | 95ms | null (スキップ) | -95ms | 100% |
| initializationTimeMillis | 99ms | null (スキップ) | -99ms | 100% |
| iceCollectionTimeMillis | 55ms | null (スキップ) | -55ms | 100% |
| signallingConnectTimeMillis | 0ms | null (スキップ) | 0ms | – |
| handshakingTimeMillis | 128ms | null (スキップ) | -128ms | 100% |
| preTalkingTimeMillis | 230ms | 3ms | -227ms | 98.7% |
| firstRTPTimeMillis | 492ms | 157ms | -335ms | 68.1% |
サマリー
1回目の通話
1回目の通話では無効時/有効時いずれも新規接続を確立するため、パフォーマンスに差はありませんでした。
| 項目 | 無効時 | 有効時 | 差分 |
|---|---|---|---|
| 接続確立時間 | ~420ms | ~416ms | -4ms |
| 最初の RTP | 378ms | 336ms | -42ms |
2回目の通話
2回目の通話では無効時は新規接続を確立するのに対し、有効時は既存の接続を再利用するため初期化処理がスキップされ大幅に通話開始までの時間が短縮されています。
| 項目 | 無効時 | 有効時 | 差分 | 削減率 |
|---|---|---|---|---|
| 接続確立時間 | ~607ms | ~3ms | -604ms | 99.5%削減 |
| 最初の RTP | 492ms | 157ms | -335ms | 68.1%削減 |
無効化したほうがよいケースはあるか？
基本的には無効化したほうがよいケースはないですが、ゼロトラストネットワークサービスを導入しており通信経路上に存在する場合は影響が発生する場合がありそうです。
例えば以下のようなPersistent Agent Connectionは接続を維持しようとしても、ゼロトラストサービスが接続を切断するケースが考えられます。
1. エージェントが通話を終了
2. Persistent Connectionがメディア接続を維持しようとする
3. ゼロトラストサービスがが2分後にUDPセッションをタイムアウト
4. 次の通話時に接続が確立されていない
5. 接続再確立に時間がかかる（通常より遅い）
ただし、Amazon Connectのベストプラクティスとして直接接続すべきというものがあるため、Persistent Agent Connectionは有効化してネットワーク経路を直接通信できるものに変更するというのが根本的にとるべき対策になります。
最も信頼性が高く最高の音声エクスペリエンスを実現するために、エージェントワークステーションと AWS の間のメディアトラフィックが、VPN やその他のネットワークアクセラレーターホップを経由せずに直接交換されるようにすることを強くお勧めします。
コンタクトコントロールパネル (CCP) で使用される WebRTC の仕組み
まとめ
Amazon ConnectのPersistent Agent Connectionについて調査をしてみました。
利用者視点ではほとんど意識せずに有効化して良い機能ということがわかり、超ニッチなブログ記事となりました。
ただ、Amazon Connectの音声品質、通信遅延という観点でネットワークまわりを調査することは多く、その中でPersistent Agent Connectionを調べる必要がでてくるケースもあるかもしれません。
そういった際の助けになれば幸いです。
- Amazon ConnectのPersistent Agent Connectionを調査してみた - 2025-12-22
- 組織内のIPv4アドレス（EIP）を自動通知してコスト削減する - 2024-12-03
- 組織内のAWSコスト最適化のためにやっている7つのこと - 2024-12-01
- Amazon Connect Contact Lens + iPaaSで生成AI活用＆他サービス連携を簡単に実現！– Amazon Connect アドベントカレンダー 2024 - 2024-12-01
- AWS Step Functionsの基本を再学習しました - 2024-09-23
【採用情報】一緒に働く仲間を募集しています
