AIコールの同時通話数｜受付が集中するときの上限と待ち行列

AIコールなら、電話が集中しても何件でも同時に受けられるのでしょうか。会話を担当する人の数が減っても、電話サービス、AIの音声処理、顧客情報を調べるシステムには、それぞれ利用上限があります。

企業の担当者が導入前に確認したいのは、何件まで受けられるか、その数に何を含むか、上限に達した電話をどう扱うかです。月間の受付件数だけで判断せず、混み合う時間帯の動きを確認します。

この記事は2026年11月1日に確認したAWSとTwilioの公式資料をもとに、IvyLeapが整理した容量設計の基礎解説です。新機能の発表や当社の導入実績を紹介するものではありません。例に使う件数や業務は説明用の仮定です。

四つの上限を、別の数字として確認する

まず、提案書の「同時対応数」がどの範囲を表すか、提供元に確認します。

• 同時通話数：同じ時点で継続している電話の数。会話中だけでなく、案内や待機中を含むかも確認する。
• 発信開始の速度：一定時間に新しく電話をかけ始められる数。通話が何分続くかとは別の条件。
• 待ち行列の上限：対応開始を待つ電話や折り返し依頼を、どこまで受け付けるか。
• 後段の処理上限：音声認識、AIの回答生成、音声合成、顧客情報の照会などが処理できる量。

例えばTwilioのCalls APIでは、APIで作成する発信をCPS（Calls Per Second）で制御し、その上限を超えた分を発信前の列で待たせると説明しています。一方、着信とTwiMLの「Dial」命令による発信は、このCPSの制限対象外です。これはTwilioの当該APIの仕様で、すべての電話経路に同じ待機動作があるという意味ではありません。Twilio公式資料

発信前の待ち時間と、着信した人が応対を待つ時間も区別します。「毎秒何件かけ始められるか」を、そのまま「同時に何人と話せるか」へ読み替えないようにします。

待っている電話も、同時通話数に含まれるか

Amazon Connect Customerの公式資料では、フローで処理中、キューで待機中、担当者が対応中の電話と発信通話を、同時アクティブ通話数に数えます。折り返しキューで待つ依頼は、対応可能な担当者へ提示されるまではこの数に含めない、と別に説明しています。AWS公式資料：通話の数え方

そのため、「AIが話しているのは少数だから余裕がある」とは限りません。待機中の電話も同じ枠を使う構成では、待ち時間が延びると、新しい着信を受ける余地が減る場合があります。逆に、折り返し依頼へ切り替えた後の数え方は、その仕組みの仕様によります。

容量の確認票には、上限の値に加え、対象アカウント・拠点・リージョン、着信と発信で共有するか、待機や転送中を含むかを書きます。AWSも、資料にある初期値と実際のアカウントへの適用値が異なる場合があると案内しています。カタログ上の数字と、契約・管理画面で確認した適用値を分けて記録してください。AWS公式資料：サービスクォータ

月間件数より、集中する時間帯を調べる

必要な同時通話数を考えるには、実測した着信時刻と通話の開始・終了時刻を並べます。キャンペーン直後、営業開始直後、障害の告知後など、普段と違う集中も確認対象です。

概算の例として、毎分10件の着信が均等に続き、各電話が平均3分間システム内に残るなら、平均的には約30件が同時に存在する計算になります。これは仮定に基づく目安で、必要上限を30件と決める計算ではありません。同じ件数が短時間に集中する場合や、一部の電話が長くなる場合は、この平均から外れます。

ここで用いる時間は、上限に数えられる区間に合わせます。待機を含む上限なのに、AIと会話した時間だけで見積もると、必要な容量を小さく見てしまいます。

最初に用意したい記録は、時間帯ごとの着信数、同時に残っていた電話の最大数、待ち時間、受付できなかった件数、途中で切れた件数です。再度かけ直した電話は、同一顧客と断定せず、確認できる範囲で照合します。

満杯になったときの案内を、入口で決める

待ち行列を大きくすれば、長く待つ人が増える可能性があります。受け付ける数と、現場が対応を完了できる数を合わせて考えます。

AWSのキュー設定ガイドでは、キューが満杯の際に備えた折り返しなどの代替手段がなければ、次の着信は接続できない旨の音を受けると説明しています。また、電話・チャットなどで同じキューの上限を共有する場合もあります。AWS公式資料：キューの上限

自社の構成では、満杯になった時点で次のどれを使えるかを確認します。すでに入口で拒否される電話には、後段のAIが案内できないため、回線側の挙動まで対象にします。

• 待機できる場合は、状況を案内し、待つか別の方法を選べるようにする。
• 折り返しを受け付ける場合は、依頼の保存結果と対応する担当を確認する。
• 人へ転送する場合は、転送先の空き状況や受け入れ時間も照合する。
• 受け付けられない場合は、利用可能な別窓口と再開の条件を決める。

折り返し時刻は、処理能力を確かめずAIが約束しないようにします。転送後に誰が引き受けるかは、AIコールから人への引き継ぎ設計も参考になります。

電話の枠を増やす前に、詰まっている場所を調べる

電話を受けられても、AIの回答生成や顧客照会が追い付かなければ、沈黙や待機が増える場合があります。電話サービスの上限変更と、後段の処理能力の確認を一緒に進めます。

例えば、予約照会の電話が集中する仮想例を考えます。電話の同時受付枠には余裕があっても、予約システムの照会制限に達したら、AIは空き枠を確認できません。このとき、未確認の空きを案内して受付を進めず、確認待ちや担当者への引き継ぎとして扱います。

監視では、同時通話数、待ち行列、AI処理の制限エラー、照会先のエラーを同じ時間軸で見ます。AWSは同時通話数と、その上限を超えた電話を別の指標として提供しています。自社の計測でも、受け付けた電話だけでなく、入口で受け付けられなかった電話を拾えるか確認してください。AWS公式資料：監視指標

一通話の返事が遅い場合の切り分けは、AIコールの応答待ち時間で解説しています。集中時には、その遅れが何件同時に起きているかも合わせて見ます。

導入前に試したい六つの場面

検証は提供元と合意した環境・件数で行い、本番の電話番号に無断で負荷をかけないようにします。

1. 着信が短時間に集中する。 受け付けた数と、拒否・切断された数を分けて確認できるか。
2. 長い通話や待機が重なる。 上限の数え方と、実際の利用数が一致するか。
3. 着信と発信が同時に動く。 共有する枠を把握し、受付に必要な余地を残せるか。
4. 待ち行列が満杯になる。 回線側の応答も含め、決めた案内や代替手段が動くか。
5. AIや照会先が制限に達する。 余分な再試行を増やさず、未確認の内容を確定として案内しないか。
6. 折り返しへ切り替える。 依頼が保存され、担当へ渡り、二重架電せず対応できるか。

試験の結果には、入力した件数、適用されていた上限、各区間の待ち時間、未受付の数、実際の案内を残します。「同時対応できた」という一言だけで合否を決めず、顧客が用件を伝えられ、後続の担当が対応を続けられたかまで確かめます。

IvyLeapのAIコール・AIエージェント関連サービスでは、対象業務に合わせた活用をご相談いただけます。受付が集中する時間帯や、現在困っている電話対応を整理して、お問い合わせください。

※出典と仕様は2026年11月1日に確認。製品・経路・契約ごとに上限と超過時の動作は異なります。本記事の仮定の件数は、当社の実績や処理能力の保証値ではありません。