AIコールセンターの障害対策｜受付の再開と対応履歴の復元を分ける

AIコールセンターの障害対策を考えるとき、「予備の環境に切り替えれば大丈夫」とまとめていないでしょうか。新しい電話を受けられること、すでに話している相手への対応、過去の受付内容を調べられることは、それぞれ別の確認が必要です。

受付を再開できても、直前の依頼や処理結果が分からなければ、業務全体が復旧したとは言い切れません。 本記事では、障害時にも残したい業務を先に決め、切り替え後の確認まで含めた設計を整理します。

最近の動き：別のリージョンで会話を再開する機能

AWSは2026年10月23日付の発表で、Amazon Connect Customer Global Resiliencyが、連携したAWSリージョン間で継続的なチャットを扱えるようになったと案内しました。別のリージョンで会話を再開するときに、会話の文脈やメタデータ、記録などを引き継ぐ機能です。発表は同日時点で利用可能とする案内で、導入にはGlobal routingへの対応が必要としています。AWSの公式発表

ここでいうリージョンは、サービスを動かす地域の単位です。今回の追加機能はチャットについてのもので、通話中の音声やAIの処理状態が、障害時にそのまま別地域へ移ると示した発表ではありません。 公式のGlobal routingの説明でも、着信の振り分け変更と、すでに存在するコンタクトの扱いを区別しています。AWSのGlobal routing解説

この動きから得られる実務上の視点は、「接続先を変える仕組み」と「対応を続けるための情報」を別々に確かめることです。以下はIvyLeapの設計提案であり、特定製品の機能保証や当社の導入実績ではありません。

1．何を継続したいかを四つに分ける

最初に、電話受付のどこまでを障害中も続けたいのかを書き出します。すべてを同じ水準で復旧させる前提にせず、最低限の受付と、後から戻す機能を決めます。

• 新しい問い合わせ：新規着信をどこで受けるかを決め、実際の番号から代替窓口へ到達することを確認します。
• 継続中の対応：通話中・保留中・待ち行列をどう扱うかを確認し、切断した場合の案内と担当を決めます。
• 対応履歴：どの時点までの受付内容を参照できるかを決め、直前の受付番号と確認済み項目を照合します。
• 外部連携：予約や顧客管理への更新を続けるかを決め、接続先・権限・処理結果を別環境でも確認します。

例えば、予約システムの状態を確認できない間は、受付だけを続けて担当者の確認後に回答する運用も選択肢です。その場合は「予約確定」と案内せず、折り返しの予定と受付番号を伝えます。

人へ引き継ぐ会話の条件はAIコールから人へ引き継ぐ条件の作り方で扱っています。本記事で決めたいのは、その担当者や窓口も含めて、基盤の障害時にどこまで業務を続けられるかです。

2．復旧までの時間と、戻せる情報の時点を決める

障害対策の見積もりを比較する際は、次の二つを分けて質問してください。

• 再開までの時間：障害の検知から、対象業務を再開できるまで、どのくらい待てるか。
• 復元できる情報の時点：直前のどの時刻までの履歴が必要で、反映待ちの受付をどう回収するか。

これらは復旧目標時間（RTO）と復旧時点目標（RPO）と呼ばれます。業務側が許容できる条件を示し、提供側がその条件を満たせるか、契約や構成、試験で確かめます。製品名だけで達成できると判断しないことが大切です。

「電話はつながるが、直前の問い合わせが履歴にない」場合に備え、受付時刻、受付番号、保存確認の状態を追えるようにします。まだ同期されていない記録があるなら、担当画面にも確認できる範囲を表示します。AIに不足する履歴を推測させて埋めない設計にしましょう。

3．代替環境から先の接続も確認する

電話の受け口を二つ用意しても、どちらも同じ一つの予約システムに依存していれば、予約処理の停止には別の対応が必要です。AIの実行基盤だけを見ず、次の接続を一覧にします。

• 電話番号・回線と、音声認識・読み上げ・AIモデルへの接続
• FAQや顧客情報の参照先と、その情報の更新時点
• 予約・注文・通知などの更新先
• 認証、接続元の許可、シークレットの取得先
• 履歴・録音・監視通知の保存先と、担当者が使う画面

代替環境で接続できない先がある場合は、機能を限定して続けるか、その業務を停止するかを決めます。例えば、FAQの案内と用件の受付は可能でも、予約確定はできない状態を明示します。

また、複製した履歴を誰が見られるか、保存地域や保存期間が運用条件に合うかも確認してください。アクセスできることと、適切な権限で扱えることは別の条件です。

4．障害が起きた時刻と、結果不明の処理を照合する

次は、架空の修理受付の例です。実際の障害や導入事例を示すものではありません。

AIが顧客から訪問希望を聞き、予約登録を依頼した直後に通信が途切れたとします。新しい受付窓口が動き始めても、その予約が登録済みかは別に確認します。

• 受付も予約番号も保存確認済み：既存番号を参照し、同じ予約を追加しません。
• 用件は残っているが、登録結果が不明：予約先の履歴と照合し、確定まで再登録を保留します。
• 録音や受付の一部だけが残っている：確認できた情報を分け、必要な項目だけ顧客に確認します。
• 記録にアクセスできない：「確認できない」と扱い、担当者へ調査を割り当てます。

予備環境から元の環境へ戻すときも、同じ照合が必要です。戻す時刻だけを決めず、未処理の受付、結果不明の更新、折り返しの担当が残っていないかを確認します。

5．本番の電話を止めずに、復旧手順を試す

AWSの導入ガイドは、切り替え手順を定期的に試験することに加え、全面的な切り替えが難しい場合には本番の通信へ影響しない試験用構成で重要なフローを確認する方法を示しています。AWSの導入・試験ガイド

自社での受入試験も、まず試験用の番号・顧客データ・通知先を用意し、次の場面を確かめるとよいでしょう。本番の回線や依存先を無断で止める試験は行いません。

1. 代替窓口へ新規着信を振り分ける：想定した案内・営業時間・担当へつながることを確認します。
2. 継続中・保留中の対応がある状態で切り替える：仕様どおりの扱いとなり、未対応案件を追跡できることを確認します。
3. 直前の履歴がまだ反映されていない：未確認範囲が分かり、確定した内容として案内しないことを確認します。
4. 予約登録の返答が途中で失われる：結果照合まで二重登録しないことを確認します。
5. 代替側から顧客管理へ接続できない：受付できる範囲を限定し、担当へ通知することを確認します。
6. 元の環境へ切り戻す：両側の未処理案件と結果不明の操作を照合できることを確認します。

試験結果には、使った構成、対象業務、検知・判断・再開の各時刻、復元できた記録、残った手作業を残します。「画面が開いた」だけで完了にしないことが、運用に使える手順書につながります。試験環境の分離はAIエージェントの検証環境も参考にしてください。

導入前に確認したいこと

提供会社へは「冗長化されていますか」だけでなく、新規着信・継続中の通話・履歴・外部更新のそれぞれについて、何が継続し、何が復元待ちになるかを確認しましょう。自社が必要とする範囲と、製品が実際に保証・対応する範囲を合わせることが先です。

IvyLeapへのAIコールに関するご相談やAIエージェント構築のご相談でも、現在の電話業務と接続先を整理し、障害中に残したい業務と確認条件を具体化できます。相談の際は、受付フロー、依存するシステム、許容できる停止時間、履歴が不足した場合の対応を共有してください。

出典・確認日

• AWS：リージョンをまたぐpersistent chat対応の発表（2026年10月23日）
• AWS：Global routingの動作と既存コンタクトの扱い
• AWS：Global Resiliencyの導入と切り替え試験

公式情報の確認日：2026年10月25日。機能の対象、リージョンの組み合わせ、利用条件は、導入時点の公式資料と提供元への確認が必要です。