Amazon Connectの負荷試験では、電話の受付からフロー、外部連携、受話先まで、必要な業務が混雑時にも完了するかを確認します。AWSの事前承認と実際の利用クォータを確認し、自社で作ったフローや接続先も試験範囲に含めます。
試験の許可と利用上限の引き上げは別の準備です。呼量、対象経路、受話の仕組み、合格・中止条件をそろえ、少量での確認から段階的に進めます。
この記事でわかること
- AWSへの事前承認とクォータ確認の違い
- フロー・受話先・外部連携までの試験範囲
- 段階的な実施と失敗原因の切り分け
1．図で理解する、試験対象の全体像
外線着信の試験では、自動発信ツールから対象の電話番号へ電話をかけます。Amazon Connectのフローが案内や分岐を処理し、キューと呼ばれる待ち行列や、用意した受話先へ進めます。
例えば「顧客番号を入力 → Lambdaで契約情報を調べる → 契約に応じた窓口へ送る」という構成なら、照会処理も試験範囲に含めます。Amazon Lexを使う場合は、音声入力に対して意図した分岐に進むかも確認対象です。すべての構成にLambdaやLexが必要なわけではありません。
IVRだけで終了する試験と、担当者の端末までつなぐ試験は別です。後者には受話・応答の準備が必要で、エージェント側の音声を測る場合は測定方法も設計します。
2．最初に確認するのは、AWSの承認と利用上限
負荷試験の承認を、少なくとも2週間前までに得る
AWS公式ポリシーでは、試験日の少なくとも2週間前までに承認を得ることが必要です。「2週間前に申請すれば必ず間に合う」という意味ではありません。計画の確認や調整期間を見込み、早めにAWSのアカウント担当者と相談します。
実施は対象リージョンの現地時間で18時〜翌6時、試験中に連絡できる緊急担当者と詳細な計画書が必要です。申請窓口や最新条件はAWS公式の負荷試験ポリシーで確認してください。
クォータは、試験の許可とは別に確認する
クォータとは、利用できる処理量やリソース数の上限です。試験が承認されても、必要な上限が自動的に増えるわけではありません。実際のインスタンスに適用されている値を確認し、必要に応じて引き上げを相談します。
AWS公式では、同時アクティブ通話数に、フロー処理中・キューで待機中・担当者対応中・アウトバウンドの呼が含まれると説明されています。担当者が会話している本数だけではありません。詳細はサービスクォータと呼の数え方を参照してください。
| 準備するもの | 何を確定するか | 別途必要な確認 |
|---|---|---|
| 負荷試験の承認 | 対象・日時・負荷量・計画に対する実施許可 | 試験日2週間前までの承認取得。申請だけで完了ではない |
| サービスクォータ | 対象インスタンス等で利用できる上限と必要な変更 | 試験の承認だけでクォータが増えるわけではない |
| 連携先と受話側 | Lambda・照会先・回線・受話先が扱う量と条件 | 連携先の担当者、容量、試験データ、取得する証跡 |
| 当日の実施体制 | 地域の時間帯、緊急連絡先、停止の判断者と条件 | 承認済み計画と実際の設定を開始前に照合 |
3．試験条件は「電話の速さ・長さ・用件」で作る
1秒あたりの発信試行数をCPS、ある時点で維持される呼の数を同時通話数として区別します。同じCPSでも、案内や待ち時間が長ければ、同時に維持される呼は増えます。
例えば、案内だけで終了する電話と、照会して担当者へつなぐ電話を分け、実績に近い割合で組み合わせます。全呼が同じ番号を同時に押すシナリオだけでは、実際の繁忙時とは違う処理の集中が起きることがあります。
着信履歴から、時間帯別の件数、短い時間に集中するピーク、平均呼保持時間、代表的な分岐を整理します。記録がない場合は業務担当者と仮説を置き、仮定した条件として計画書に残しましょう。
呼量の定義をそろえるには、CPSと同時通話数の違いをご覧ください。フロー処理中や待ち呼を含め、どの範囲の呼を数えるかが重要です。
4．確認したい項目と、その見方
- 接続：発信した電話のうち、接続できた数と接続までの時間を確認する。
- フロー：案内、番号入力、分岐、エラー時の案内が正しく動くかを確認する。
- キューと受話：予定したキュー・受話先に届くか、待ち呼や混雑時の処理が成立するかを確認する。
- 連携：Lambdaや照会先の遅延、失敗、呼び出し制限を確認する。
- 音声：測定対象の区間で、無音や途切れが増えていないかを確認する。
Lambdaを利用している場合、呼び出しが終わるまでフローが待つ同期方式と、待たずに進む非同期方式では、確認すべき動作が違います。現在の公式資料ではブロックのタイムアウト上限は同期8秒、非同期60秒です。これはLambda関数自体の実行時間上限とは別です。AWS Lambdaフローブロックの仕様を確認し、設定した期限までに応答しない場合の分岐も試験します。
混雑時の無音や途切れも評価する場合は、負荷試験と音声品質評価を組み合わせる方法で、測定する区間と方向を整理できます。
Salesforce Service Cloud Voiceを組み合わせる構成では、着信から画面ポップ・通話記録までの検証ポイントも参考に、連携先までの確認範囲を決めます。
5．少量で確認してから、段階的に増やす
- 目的と合格条件を決定：接続、案内完了、処理時間など、業務上必要な基準を決めます。
- 計画と承認を確定：対象環境、負荷上限、受話先、連携先、中止条件を共有します。
- 少量で動作確認：テストデータとシナリオ、ログの取得方法が正しいことを確認します。
- 承認範囲で負荷を増加：各段階で結果を記録し、負荷を下げたあとの回復も確認します。
- 照合と再試験：発信側、Amazon Connect、連携先の時刻・識別情報を照合し、改善後に同じ条件で比較します。
1本の試験呼と連携処理の記録を結び付ける
以下は証跡の整理例で、実際の障害記録ではありません。取得できる項目とログ設定は事前に確認し、すべてのシステムで同じIDが使われるとは考えないようにします。
| 段階 | 残す情報 | 照合の考え方 |
|---|---|---|
| 発信ツール | 試験実行ID、シナリオ、発着信先、時刻とタイムゾーン | 対象通話へ対応付ける。時刻だけで断定しない |
| Amazon Connect | ContactId、対象フローと版、処理区間・結果 | 転送などで複数のコンタクトになる場合は関連付けも記録 |
| Lambda・外部照会 | 呼出しの識別情報、要求・応答時刻、結果 | 再試行を分けて数え、対応する呼・処理との関係を残す |
| 結果判定 | 失敗した最初の段階、正常だった範囲、未確認の範囲 | 採取していない証跡から原因を確定しない |
6．結果を読むときの注意点
「つながらなかった」だけでは原因は決まりません。発信元の回線で止まったのか、クォータに達したのか、フロー途中で失敗したのかを分けます。大量発信ができたことと、対象までその量が届いたことも別です。
平均応答時間だけでなく、遅い処理が起きた時間帯・分岐も調べます。再試行がある処理では、電話1本につき外部システムへのアクセスが1回とは限りません。
試験中の通話料や連携先の課金、テスト用顧客データ、録音・ログの保存範囲も準備します。本番環境で実施できるかは一律に判断せず、承認条件と運用上の影響を確認してください。
7．相談前に用意したい情報
対象リージョンとインスタンス、希望時期、想定する着信量、フロー図、Lambda・Lexなどの連携、受話先の構成が分かると、試験計画を具体化できます。未確定の項目は、分かっている範囲から整理できます。
フロー図、想定する呼量、Lambda・Lexなどの連携先と希望時期を整理し、試験範囲を具体化します。Amazon Connect負荷試験サービスの試験内容・相談窓口をご覧ください。
試験呼の量とシナリオを再現する製品として、Cyara Cruncherを用いたコンタクトセンター負荷試験をご確認ください。Amazon Connectのクォータや回線・外部連携の条件を確認したうえで、Amazon Connectの負荷試験シナリオと実施条件を相談することができます。
まとめ：承認・上限・業務フローをセットで準備する
Amazon Connectの負荷試験では、AWSの承認、現在のクォータ、フローと連携先の動作を合わせて確認します。電話の本数だけでなく、お客様の用件が混雑時にも完了するかを基準に計画しましょう。
あわせて読みたい記事
公式資料の確認日：2026年9月18日。利用条件や仕様は、実施前に最新の情報をご確認ください。