AI電話は「全部止まる」か「正常」の二択ではありません。電話回線、AI API、Backend、DB、予約、SMS、人間転送は別のFailure Domainです。どの障害でも顧客が次に何をすればよいかを案内できるよう、縮退とFallbackを事前に決めます。
Failure Domainを分離する
一つの障害を全停止として扱うと、不要な受付停止を招きます。逆に依存関係を過小評価すると、保存されない予約や連絡のない折り返しが起きます。
Fallback Matrix
| 障害 | AI受付 | 案件保存 | 予約・案内 | 顧客への次の案内 |
|---|---|---|---|---|
| AI API停止 | × | 別経路 | × | 有人または留守電 |
| DB停止 | ○（縮退） | Temporary Queue | 希望のみ取得 | 後処理の予定を案内 |
| SMS停止 | ○ | ○ | ○ | 別の通知経路 |
| 予約DB停止 | ○ | ○ | △ | 希望日時を仮受付 |
| 人間転送停止 | ○ | ○ | × | 期限付き折り返し |
表は一般的な設計例です。実際の可否は回線・ベンダー・連携方式に合わせて確認します。
BCP Levelを段階化する
| Level | 状態 | 運用 |
|---|---|---|
| 0 | 通常AI | 通常の受付・連携 |
| 1 | AI縮退 | 定型案内・仮受付 |
| 2 | 有人Fallback | 優先用件を人へ |
| 3 | 留守電・Callback | 最小項目と期限 |
| 4 | 完全障害 | 代替番号・障害告知 |
レベルごとの切替権限、連絡先、復旧確認、顧客向け案内文を事前に合意します。復旧後に仮キューを誰が確定処理するかもBCPの一部です。
Failure Injection / DrillはStagingで行う
AI APIのTimeout、DB書込み失敗、SMS送信失敗、担当転送失敗、大量同時着信を、Stagingまたは隔離したテスト環境で再現します。本番の顧客電話を意図的に壊すのではなく、監視で検知できるか、Fallbackが働くか、復旧後の案件照合ができるかを確認します。
復旧の定義まで運用に含める
サービスが応答を再開しただけでは、業務が復旧したとは言えません。仮キューの案件、SMS未送信、予約確認待ち、折り返し期限切れを照合し、誰が通常運用へ戻すかを決めます。障害記録には時刻、影響した経路、顧客案内、Fallbackの実行結果、後処理を残します。次のDrillで同じ手順を試せる状態にすることが、冗長化の価値を高めます。
Failure Domainごとに残る機能を確認する
| Domain | 壊れた時に何が残るか |
|---|---|
| Carrier | 通信事業者側で着信できなければアプリは呼ばれません。代替番号、別Carrier、障害告知の経路を用意します。 |
| Phone number routing | 番号設定や転送先の誤りではAIが正常でも到達しません。設定変更の承認と疎通監視を分けます。 |
| SIP / Voice provider | 音声経路の接続失敗ではFallback URLや別リージョン、有人経路を検討します。 |
| AI API | Timeout、429、5xxでは会話を続けず、定型受付や人へ縮退します。 |
| Application | Webhook処理や状態管理が落ちた場合、冗長Applicationと最小応答を使います。 |
| Database | 書込み失敗時は予約確定を装わず、冪等なTemporary Queueへ仮保存します。 |
| Availability / booking | 空き照会不能なら希望日時だけ受け、復旧後に確定します。 |
| SMS | 送信不能でもCase保存を継続し、管理画面や別通知へ切り替えます。 |
| Notification | 担当通知が失敗したら未通知キューを監視し、期限超過を検出します。 |
| Human transfer | 転送不能では通話を切らず、折り返し期限と連絡先を確認します。 |
RTOとRPOを電話受付へ落とす
RTOは「何分・何時間で通常または許容できる受付へ戻したいか」、RPOは「どの時点までの受付データ損失を許容できるか」です。予約確定と一般問い合わせでは許容範囲が違います。固定値を借りず、用件ごとに顧客影響、後処理可能性、法的・契約上の要件を確認します。
例えばRTO中も代表番号へ定型案内を返し、氏名と折り返し先をTemporary Queueへ保存できれば完全停止を避けられます。RPOをゼロに近づけるには同期保存が必要ですが、依存先が増えるためLatencyと可用性のTrade-offを評価します。
Degraded Modeの具体例
| 停止箇所 | 縮退運転 | 復旧後 |
|---|---|---|
| 予約DB | 希望日時のみ仮受付 | 空き確認後に顧客へ確定連絡 |
| SMS | DB保存を継続 | 未送信通知を再送または別経路 |
| AI Tool | 定型質問と折り返し受付 | 不足項目を担当者が補完 |
| 人間転送 | Case保存と期限案内 | 当番変更後に折り返し |
| 通知 | 未通知キューへ蓄積 | 重複を避けて再送 |
Incident Flow
復旧後はPostmortemで、検知までの時間、Fallback成功率、失われた通知、顧客への約束、再発防止を記録します。単にサービス稼働を確認してIncidentを閉じません。
Failure Injection Test 12ケース
| 注入する障害 | 期待する結果 |
|---|---|
| AI timeout | 応答期限超過で縮退案内へ移る |
| 429 | 再試行を制限し通話内で無限待機しない |
| 5xx | 別経路または定型受付へ切り替える |
| DB write failure | 受付完了を告げず仮キューへ保存する |
| booking API failure | 希望日時受付へ縮退する |
| SMS failure | 送信済みにせず別通知を残す |
| transfer failure | 折り返しCaseを作る |
| connection loss | 途中状態を不完全Caseとして識別する |
| duplicate webhook | 冪等キーで二重予約を防ぐ |
| concurrent calls | ピーク時もキューと通知が欠落しない |
| notification delay | 期限超過を監視が検知する |
| recovery replay | 仮Caseを重複なく再処理する |
試験はStagingまたは隔離環境で行い、本番の顧客通話を故意に壊しません。復旧試験ではTemporary Caseと本DBをIdempotency Keyで照合し、二重予約、二重通知、処理漏れを防ぎます。
実務判断台帳
| 判断点 | 実装・運用の考え方 | 検証方法 |
|---|---|---|
| 検知 | 外形監視、Webhook失敗、Latency、キュー滞留、担当者通報を組み合わせる。 | 一つの監視が同じ障害で停止する共倒れを避ける。 |
| 分類 | Carrier、Voice、AI、Application、DB、業務連携、通知のどこかを切り分ける。 | 原因確定を待たず顧客影響に基づいてFallbackを開始する。 |
| 縮退切替 | 予約確定を止めても希望受付を残すなど、残る機能を明示する。 | 縮退中であることをCaseへ記録する。 |
| 顧客案内 | 障害の技術詳細ではなく、現在できることと次の連絡期限を伝える。 | 復旧時刻を根拠なく約束しない。 |
| 社内連絡 | Incident Owner、業務Owner、顧客連絡担当を分ける。 | 複数チャネルの矛盾した案内を防ぐ。 |
| 復旧確認 | ヘルスチェックだけでなく、実通話、保存、予約、通知、転送を順に試す。 | 一斉復帰でキューを過負荷にしない。 |
| 照合 | Temporary CaseをIdempotency Key、電話番号、受付時刻で本DBと比較する。 | 二重予約と未処理を一覧化する。 |
| 事後検証 | Timeline、影響件数、Fallback成否、顧客約束、検知漏れを記録する。 | 責任追及ではなく再発防止とDrill更新へつなげる。 |
確認した一次情報
- Twilio Voice Failover Best Practices（2026年8月26日確認）
- Twilio Availability and Reliability（2026年8月26日確認）
- AWS Reliability Pillar（2026年8月26日確認）
関連論点を自社の受付へ落とし込む
同時着信、AI電話のセキュリティ、人間への転送、AI電話の失敗例も併せて確認し、入口の会話だけでなく受付後の担当・記録・例外対応をつなげてください。
よくある質問
障害時にAI電話を完全停止すべきですか？
障害領域によります。AIだけ停止なら有人へ、DB停止なら仮キューへなど、顧客案内を含めて設計します。
本番で障害テストをしてよいですか？
顧客影響を避け、Stagingやテスト環境、承認済みの手順でDrillを行います。