保存できたのに、通知がない

フォームの受付は保存されている。でも担当者には通知が届いていない。気付かずにフォームを送り直すと、今度は同じ受付が2件になる。複数のサービスをつなぐ自動化では、こうした途中までの成功が起こり得ます。

受付が存在することと、通知が完了したことを別の状態として残します。この記事は架空の問い合わせ受付の設計例です。状態欄を追加するだけで、外部送信の重複を完全に防げるという意味ではありません。

1つの「完了」では、やり直す場所が分からない

保存と通知をまとめて成功・失敗だけで記録すると、通知エラーからの再実行で受付まで作り直すことになります。受付IDを決め、保存済みの受付に対する通知として記録すれば、どちらを再処理すべきか区別できます。

送信前に入力チェックで止まった場合と、送信した直後に応答が途切れた場合は違います。後者は外部側で送信済みの可能性があります。失敗という表示だけで再送せず、外部側の記録や配信状態を確認できるようにします。

外部サービスが重複を防ぐキーに対応しているなら、その仕様に従って同じ通知IDを使います。対応していない場合、送信と記録の間の中断で重複が残り得ます。「送信済みと記録したから絶対に1回」にはなりません。

AWSのTransactional outboxの解説は、データ更新と通知予定を同じトランザクションで保存し、送信を別に進める方法を説明しています。トランザクションとは、複数の変更をひとまとまりで確定・取消する仕組みです。単にスプレッドシートへ状態列を追加しても、同じ保証にはなりません。

小さな自動化でも、「受付が保存されたら通知待ちが残る」「送信処理が待ちを拾う」という役割分担は参考になります。実装方法は保存先の機能や同時実行の条件で選び、通知側でも重複時の扱いを決めます。

確認する一覧
・保存済みで通知待ちの受付
・送信中のまま一定時間が経過した通知
・結果不明で人の確認が必要な通知

再送前の記録
受付ID／通知ID／外部側の確認結果
再送する理由／実行者／日時／再送後の結果

通知待ちが増えていることに気付けなければ、再送できても運用は止まります。担当者が確認する頻度と、誰が代わりに見られるかを決めます。処理記録に本文や個人情報を丸ごと残すより、必要なIDと結果へ絞ります。

検証用の通知先で、保存後に送信を失敗させる、送信後の記録を失敗させる、同じ受付を再処理する、という条件を試します。何件保存され、何回通知され、どの状態が残るかを並べます。この記事はその確認観点を示すもので、特定環境での配信保証を検証した結果ではありません。

受付そのものの重複対策は、同じ注文を増やさないキーとロックと合わせて考えられます。保存と通知を分けると、失敗した仕事だけを見つけて戻せるようになります。

2026年11月2日確認。本文の例・図・ひな型は本記事用に作成したものです。以下は、設計や事例の背景として参照した一次資料です。