再送処理

外部連携失敗時に、条件を確認して再実行できる導線を用意します。

再送処理は、外部API送信、Webhook送信、決済後処理、通知送信、ファイル連携などが失敗したときに、原因と条件を確認してから再実行するための機能です。Roundtableでは「何を再送できるか」「誰が実行できるか」「二重処理をどう防ぐか」を先にそろえると、発注者、実装者、AIに指示する人が同じ前提で復旧導線を設計できます。

この機能でできること

連携ログや通知ログから失敗した処理を抽出し、失敗理由、対象レコード、前回payload、現在の業務データ、再送可否、実行者、再送回数を確認してから再実行できます。再送結果は新しいログとして残し、成功、再失敗、対象外、手動対応済みなどの状態へ更新できます。

「失敗したからもう一度送る」を、確認可能な業務操作にします。 再送ボタンだけを置くのではなく、再送してよい条件、使うデータ、重複防止キー、実行後の記録まで決めておくと、外部連携の一時障害から復旧しやすくなります。

よくある利用場面

外部API送信の失敗を復旧する 予約、注文、在庫、会員更新などの送信がタイムアウトや認証切れで失敗したとき、対象と内容を確認して再送します。

Webhook送信や通知を送り直す 外部CRM、チャット、メール、LINEなどへ届かなかったイベントを、失敗ログから選び直して再実行します。

決済後処理を手動で再実行する 決済自体は完了しているがDB更新、帳票発行、通知だけが失敗した場合に、支払い状態を確認して後続処理だけを再実行します。

プロンプト例

対象にする連携処理、再送できる条件、確認画面、実行権限、重複防止、再送後ログをまとめて伝えると、運用で使いやすい復旧導線を設計できます。

プロンプト 外部連携ログに再送処理を追加してください。予約API送信、Webhook送信、通知送信で失敗したログを対象に、管理画面から失敗理由、対象レコード、前回送信内容、現在のステータス、再送可否を確認してから再送できるようにしてください。再送前には確認モーダルを出し、実行者、実行日時、再送元ログID、再送結果、エラー理由を新しいログとして保存してください。決済済みデータや外部IDが既に付いているデータは二重処理にならないよう、処理ごとに再送可否を判定してください。

この機能を使うときのポイント

再送対象を絞る失敗、再送待ち、保留など、再実行してよい状態だけを対象にします。

二重処理を防ぐ外部ID、決済状態、イベントID、冪等性キーを確認し、同じ注文や決済を重複処理しないようにします。

使うデータを決める前回payloadをそのまま送るのか、現在の業務データから作り直すのかを処理種別ごとに分けます。

結果を必ず残す再送が成功したか、再び失敗したか、誰がいつ実行したかをログに残します。

この機能を実装するときのコツ

実装では、一覧の行ボタンから直接再送せず、対象ログの詳細、現在の対象レコード、再送条件を確認する段階を挟みます。再送処理本体は、外部API送信や通知送信の通常処理を再利用しつつ、再送元ログID、実行者、再送回数、結果を保存できる薄い入口を用意します。決済や在庫更新のように二重実行の影響が大きい処理では、再送前に外部IDや現在ステータスを再取得して、後続処理だけを実行する分岐を作ると安全です。