「新しい電話システムは動いた。でも、繁忙日の電話も受けきれるだろうか」。コンタクトセンターの導入や更改では、そんな疑問が残ることがあります。
負荷試験は、混雑した日の電話の流れを事前に再現し、予定したサービスを提供できるか確かめる試験です。電話が何本つながるかだけでなく、案内、取り次ぎ、会話までを、決めた範囲で確認します。
この記事は、負荷試験に初めて関わる方に向けた入門ガイドです。Genesys CloudやAmazon Connectなど特定の製品に限らず、音声を中心としたコンタクトセンターに共通する考え方を説明します。
この記事でわかること
- 負荷試験では何を確認するのか
- 試験方法と電話の量をどう決めるのか
- 結果の見方と、相談前に用意したい情報
1．なぜ必要？少数の電話では見えない問題がある
1本の電話で音声案内と転送を確認するのは、大切な機能試験です。ただし、多くの電話が同時に入ったときも同じように動くかは、別に確認する必要があります。
例えば、受付開始直後に顧客情報の照会が集中すると、照会先の応答が遅くなるかもしれません。担当者が全員対応中なら、順番待ちの案内や別窓口への振り分けが必要になることもあります。
負荷試験では、こうした状況を計画的に再現します。新規導入、クラウドへの移行、音声案内の改修、回線・接続機器の変更、繁忙期の前などが検討のタイミングです。
システムの試験と人員計画は分けて考えましょう。担当者が足りずに電話が待ち状態になることと、システムが処理できずに電話が切れることは、対策が異なります。負荷試験で確認するのは、用意した受話条件のもとで、受付・待ち呼・振り分けなどが設計どおり動くかです。
2．図で理解：電話の4つの場面を確認する
お客様の電話の流れに沿って考えると、試験項目を整理しやすくなります。自動案内で用件が完了する場合など、担当者につながないシナリオもあります。
① つながる：受付まで到達できるか
対象番号に電話がつながるか、接続までに時間がかかりすぎないか、途中で切れないかを確認します。発信した件数、接続できた件数、失敗の理由を分けて記録します。
② 案内される：聞いて操作できるか
「ご用件に合わせて番号を押してください」という自動音声案内をIVRと呼びます。案内が再生されるか、番号を押すと正しい分岐に進むかを確認します。音声認識を利用する場合は、その入力と応答も対象に含めます。
③ 取り次がれる：待って、正しい窓口へ進めるか
電話を適切な窓口へ振り分ける処理をルーティング、担当者につながるまでの待ち行列をキューと呼びます。行き先、待ち時間の案内、転送、混雑時の代替処理などを確認します。
④ 会話できる：音声が届いているか
接続していても、無音、片側しか聞こえない状態、音声の途切れがあれば会話になりません。必要な範囲で音声を取得し、低負荷時と比較します。担当者の端末まで測定するには、その端末で応答・音声取得を行う準備が必要です。
このほか、顧客情報の照会、録音、電話終了後の処理なども、業務上必要な範囲で確認します。
聞き取りやすさまで確認するには、混雑時の音声品質を測る方法を参考に、音声を取得する位置と評価条件を決めます。
3．どんな方法で試験する？まず「確かめたい範囲」を選ぶ
試験にはいくつかの方法があります。便利そうなツールから選ぶより、どの経路を確認したいかを先に決めることが大切です。
実際の電話番号へ、自動で発信する
自動発信ツールから回線を経由して電話をかけ、案内や番号入力、転送などを再現します。お客様の外線着信に近い経路を確認したい場合の方法です。発信側の回線容量や、担当者の代わりとなる受話先も設計します。
Cyara Cruncherは、テスト呼などを自動生成し、顧客接点の負荷・性能を検証する製品の一例です。利用できる機能と測定範囲は構成・契約によって確認します。
システムの一部分へ、直接負荷をかける
機器の接続部分や、システム間で情報をやり取りするAPIなどを個別に試験する方法です。特定箇所の性能や原因を調べるのに役立ちます。ただし、外線回線を通っていなければ、外線着信全体を確認したことにはなりません。
少量の手動確認と、自動試験を組み合わせる
手作業の電話は、案内内容や操作の確認に向いています。一方、多数の電話を同じ条件で繰り返すには、自動化が役立ちます。先に少量で手順を確かめ、その手順を自動試験に使うと、設定不備と混雑による問題を分けやすくなります。
試験で通っていない経路は、結果の対象外です。どの方法でも、試験範囲と対象外の範囲を図や一覧に残しましょう。
4．具体例：電話の量は「速さ・数・時間」で決める
CPSはCalls Per Secondの略です。ここでは、1秒間に発信を試みる電話の数を指します。同時通話数は、ある瞬間につながっている電話の数です。音声案内中や待機中の呼を含めるかも、集計条件としてそろえます。
さらに重要なのが、1本の電話を維持する時間です。同じ速さで電話がつながり続けても、長く続く電話が多ければ、同時につながる数は増えます。
例えば「短い案内で終わる問い合わせ窓口」と「長い相談が多い窓口」では、1時間の着信件数が同じでも、必要な試験条件は異なります。また、1時間に均等に入る電話と、最初の数分に集中する電話も、別の負荷になります。
計画では、繁忙時の着信記録、電話の長さ、案内の分岐、待ち呼の状況などから、現実的な条件を作ります。平均値だけでなく、短い時間に集中する山も確認しましょう。
通常のピーク、急な増加、長時間の継続では、見たい問題が違います。最初からすべてを実施するのではなく、業務上の懸念と許可された条件に合わせて選びます。
数値条件の作り方は、CPSと同時通話数から試験条件を決める方法で詳しく説明しています。
5．試験は5つのステップで進める
STEP 1 目的と合格条件を決める
「移行後も繁忙時の受付を継続できるか」などの目的を決めます。接続できた割合だけでなく、案内の完了率、取り次ぎ結果、処理時間、音声品質などから、目的に合う合格条件を選びます。
STEP 2 範囲と実施条件を調整する
対象番号、回線、音声案内、受話先、外部連携を整理します。サービス事業者・通信事業者・運用担当者と、必要な承認、時間帯、負荷上限、中止条件、緊急連絡先を確認します。
STEP 3 シナリオと記録方法を用意する
「電話する → 案内を聞く → 番号を押す → 照会する → 担当者へつなぐ」のような操作の手順を作ります。この手順がテストシナリオです。複数の用件がある場合は、実際の利用割合に近づけます。
試験用の顧客データ、録音やログの取得方法、時刻の合わせ方も準備します。結果を照合できるよう、呼の識別情報をどの範囲で取得できるか確認しておきます。
STEP 4 小さく始め、段階的に増やす
少量の呼で正常動作を確かめ、比較の基準を取ります。そのあと、承認された条件で負荷を上げ、各段階の結果を記録します。急増・継続・負荷を下げたあとの回復も、計画した範囲で確認します。
STEP 5 結果を照合し、改善後に再試験する
発信ツール、回線・接続機器、コンタクトセンター、連携先の記録を照合します。原因に対応したあとは同じ条件で再試験し、改善したかを確認します。
目的・シナリオ・測定・改善を一連で扱う考え方は、AWS Well-Architectedの負荷試験ガイドでも示されています。コンタクトセンターでは、これを電話の経路と業務の流れに合わせて具体化します。
6．結果を見るときに間違えやすい3つのポイント
「発信できた件数」と「相手へ届いた件数」を混同しない
ツールに指定した負荷が、すべて対象へ届くとは限りません。発信側や回線側で制限を受けている場合もあります。予定した負荷、実際に発信した呼、接続した呼、業務が完了した呼を分けます。
「成功」の意味をそろえる
例えば100回の発信試行のうち98回が接続し、そのうち95回が案内を完了したとします。接続成功率は98％ですが、発信試行を基準にした案内完了率は95％です。どちらも「成功率」とだけ書くと、結果を読み違えます。これは集計方法の説明例で、合格基準ではありません。
平均値と全体の割合だけで判断しない
全体の平均が良好でも、特定の案内や特定の時間帯だけ遅くなることがあります。シナリオ別・負荷段階別に見ると、問題が起きた条件を探しやすくなります。
担当者不足による待ち時間、機器の処理遅延、外部システムの応答待ちは分けて調べます。原因が違えば、増員、設定変更、連携先の改善など、必要な対策も変わります。
7．実施前の注意点：事業者のルールと本番影響を確認する
クラウドサービスの負荷試験は、自由に大量発信してよいというものではありません。利用するサービスの最新ルールと、個別に承認された条件に従います。
- Genesys Cloud：公式FAQで、自動試験の事前承認と、少なくとも2週間前までの申請が案内されています。公式の試験方針を確認する
- Amazon Connect：AWS公式では、負荷試験の少なくとも2週間前までに承認を得ることが必要とされています。申請と承認は同じではないため、余裕を持って調整します。AWS公式の試験方針を確認する
上記は2026年9月16日時点の確認内容です。具体的な時間帯や手続き、対象環境は、各社の最新情報を確認してください。
通話料、外部サービスの従量課金、誤って実際のお客様へ接続しないための設定、試験データ、録音の保存範囲も準備します。負荷試験に合格しても、未試験の経路や将来の変更まで保証されるわけではありません。
8．何を用意して相談すればよい？
最初から試験条件をすべて決める必要はありません。次の情報を分かる範囲で用意すると、計画の相談を進めやすくなります。
- 利用している電話システムと回線の構成
- 導入・更改・繁忙期などの予定日
- 普段と繁忙時の着信件数、電話の長さ
- 音声案内から担当者へつながるまでの流れ
- 特に不安な点と、変更する予定の箇所
CCアーキテクトでは、コンタクトセンターの構成と業務に合わせて、試験計画、実行、結果整理、改善ポイントの提示を支援します。
Amazon Connectを利用する場合は、Amazon Connect負荷試験の方法と注意点で、承認・クォータ・外部連携の準備もご確認ください。
自社の構成に合わせて、Genesys Cloud負荷試験サービス、Amazon Connect負荷試験サービスの試験内容をご確認ください。SIP／SBCなどを含む構成では、Cruncherを用いた負荷試験の設計・実施支援もご覧いただけます。その他の構成も含めて試験範囲を相談することもできます。
まとめ：電話の本数より、混雑時の業務の完了を見る
コンタクトセンターの負荷試験は、忙しいときにも「つながる・案内される・取り次がれる・会話できる」を確認する取り組みです。
目的と試験範囲を決め、実際の利用に近い電話の量と操作を再現し、結果をもとに改善します。まずは、自社で一番気になる場面を一つ挙げるところから始めましょう。