AI即架電のWebhookが失敗したときは、同じイベントをすぐ送り直してはいけません。まず「送信されていない」「受信したが保存できていない」「保存したが架電指示の結果が分からない」を分けます。結果が分からない状態で再送すると、同じ相手へ二度電話するおそれがあるためです。

復旧の基準は、WebhookのHTTP応答ではなく一件の受付状態です。受付IDごとに「受信」「架電待ち」「指示中」「受付済み」「開始済み」「要確認」のいずれかを残します。自動再送と手動復旧は、同じ状態を見て一回だけ次へ進める設計にしてください。

配信成功と架電開始を分ける

Webhookの成功は、受信側がイベントを保存できたことを示します。AI電話サービスが架電指示を受け付けたことや、実際に発信を始めたこととは別です。この三つを一つの「成功」にすると、障害箇所を特定できません。

送信元には配信ID、受信側には受付ID、AI電話サービスには架電指示IDを持たせます。三つのIDを関連付けます。受信時刻と指示時刻、開始時刻も残すと、どこまで処理が進んだか確認できます。

受信後はイベント本文を保存してから成功応答を返します。保存後の検証や架電指示は別の処理へ渡してください。StripeのWebhookガイドは、受信処理を非同期キューへ渡す方法を案内しています。これは決済固有の要件をAI即架電へ流用するのではなく、受信確認と後続処理を分ける実装例です。

受付状態は上書きせず、変化した時刻を残します。「受付済み」から「開始済み」へ進まない場合でも、どのIDまで発行されているか分かれば、再送と状況確認を選べます。

再送しても一件の架電にする

Webhookは同じイベントが複数回届く前提で設計します。通信が切れた場合、送信元は成功応答を受け取れず、受信側が保存済みでも再送することがあります。

重複判定には電話番号ではなく配信IDまたは受付IDを使います。同じ人が別の資料を請求した場合は別件です。一方で、同じ受付の通信再送は一件として扱います。IDが同じなら、すでに作成した受付状態を返し、新しい架電指示を作りません。

Stripeの公式資料は、同じイベントを複数回受け取る可能性を示し、処理済みのイベントIDを記録するよう案内しています。AWS Lambdaの設計ガイドも、同じイベントが複数回届く可能性を前提に、処理を冪等にするよう求めています。

架電指示APIの応答が途中で切れた場合は「失敗」ではなく「結果不明」にします。AI電話サービス側で架電指示IDを検索できるなら、同じIDの受付有無を確認します。確認できない場合は自動再送せず、要確認へ移してください。

HTTP応答と再試行ルールを決める

Webhookの再試行条件は送信元によって異なります。HubSpotは接続失敗と5秒を超える応答、4xxまたは5xxを再送対象にしています。失敗通知は最大10回、24時間に分散して再送されます。HubSpotのエラー処理で現在の条件を確認できます。

送信元が自動再送するなら、受信側で別の再送処理を重ねない方が安全です。自動再送の回数と間隔を確認します。対象となる応答コードと配信履歴の保存期間も必要です。自動再送がない場合は、失敗した配信を取得し直せるAPIまたは管理画面があるか確認してください。

4xxと5xxも同じ扱いにしません。署名不一致や必要項目の欠落は、同じ内容を繰り返しても直らない可能性があります。受信側の一時停止や過負荷は、時間を空けた再試行で回復する場合があります。エラー理由を「恒久」「一時」「結果不明」に分け、再送可否を決めます。

再試行の上限を超えたイベントは消さず、隔離します。Amazon SQSのデッドレターキューは、繰り返し処理できないメッセージを分け、原因調査と再処理へ使う仕組みです。利用基盤がAWSでなくても、失敗イベントを通常処理から分離する考え方は使えます。

失敗を発見できる監視項目を置く

エラー通知だけでは取りこぼしを見つけられません。Webhookが一件も来ていない状態は、正常に問い合わせがなかったのか、送信が止まったのか判断できないためです。

監視では受信件数と受付作成件数を同じ時間帯で比べます。架電指示件数と開始件数も対にします。受信から架電指示までの最長待ち時間も必要です。要確認件数と失敗イベントの最古時刻を加え、件数の差と滞留時間の両方を見ます。

通知条件は業務の許容時間から決めます。たとえば営業時間中に5分以内の初回連絡を約束するなら、未処理の最古時刻が3分を超えた段階で担当者へ通知します。復旧までの時間を残せない障害は、後から改善できません。

失敗イベントを隔離する場合は、件数が一件以上になった時点で通知します。Amazon SNSのデッドレターキュー監視は、キュー内の可視メッセージ数を監視する例を示しています。通知先にはシステム担当だけでなく、顧客対応を切り替えられる業務責任者も含めます。

手動復旧で二重架電を防ぐ

手動復旧は、失敗イベントを選んで再送するだけの画面にしません。受付IDと現在状態を示します。最後の処理時刻と顧客への連絡有無も確認してから操作できるようにします。

復旧担当者は最初にAI電話サービス側の架電履歴を確認します。履歴があれば元の受付へ架電指示IDを関連付けます。履歴がなく、停止希望や営業時間の条件も満たす場合だけ再送します。判断できなければ電話ではなく、社内担当者への確認へ回してください。

Stripeの未配信イベント処理は、手動処理と自動再送が同時に走る場合を想定しています。処理中または処理済みを記録し、既処理のイベントには成功応答を返す方法です。AI即架電でも、自動処理と人の操作が同じ受付を同時に進めない排他制御が必要です。

手動操作には実行者、理由、実行前後の状態を残します。一括復旧を行う場合も、最初に少数件を処理し、架電開始と結果記録を確認してから範囲を広げます。

顧客への連絡ルールを受け入れテストする

障害後に優先すべきなのは、Webhookをすべて再送することではありません。問い合わせから時間がたった相手へ、当初の想定どおり即時架電することが適切かを判断します。

復旧時は受付時刻と現在時刻を比べます。発信可能時間と、すでに行った連絡も確認します。即時性が失われた受付は、自動架電ではなく有人の折り返しやメールへ切り替えます。停止希望が反映された受付は、障害前に作られたイベントでも再送しません。

本番前には次の六つを同じ受付IDで試してください。

  1. 受信前に通信が切れ、送信元の自動再送で一回だけ架電する
  2. 保存後に成功応答が届かず、同じイベントが再送される
  3. 架電指示APIの応答が切れ、結果不明から履歴照合で復旧する
  4. 失敗イベントが隔離され、許容時間内に担当者へ通知される
  5. 手動復旧中に自動再送が届いても、二重架電しない
  6. 復旧時点で発信可能時間を過ぎた受付を、有人対応へ切り替える

六つを通した後、障害時の責任者と代替連絡手段を一枚にします。復旧操作ができても、顧客対応の判断者が不明なら運用は止まります。候補サービスには配信履歴の保存期間と再送方法を確認します。次に架電指示IDの検索と停止反映を確かめてください。