Webhookと定期確認：更新を受け取る2つの方法
通知が来る仕組みでも、重複や取りこぼしへの備えを設計します。
更新を受け取る仕組みがあっても、仕事が一度だけ正しく完了するとは限りません。この記事では、Webhookと定期確認を比べ、重複・失敗・取りこぼしを管理する状態表を作ります。
公式資料から分かること：通知の保証を個別に確認する
定期確認（ポーリング）は一定間隔で更新を調べ、Webhookは提供者からのイベント通知を受け取る仕組みです。Stripeの公式Webhook資料は、重複イベントへの対応、到着順に依存しない設計、署名検証、キューを使った非同期処理を説明しています。これはStripeの具体例で、別のサービスの配送条件は個別に確認します。
Stripeは署名検証に加工前のリクエスト本文が必要と説明しています。受信形式や検証方法を自己流で決めず、対象サービスの公式手順に従ってください。
仕事の具体例：問い合わせ通知から担当者への割り当て
架空の問い合わせサービスを考えます。定期確認なら取得間隔と対象条件、Webhookなら対象イベントと受信失敗時の扱いを決めます。早く届くことだけでなく、問い合わせIDと処理結果を照合できることが必要です。以下は運用設計の案です。
- 通知の送信元と形式を検証する。検証できない通知から業務処理を始めない。
- 必要な通知を失わない形で保存し、処理待ちとして管理する。受領応答と業務の完了を分ける。
- 担当者の割り当てを行い、問い合わせIDと結果を記録する。同じ通知や同じ業務の同時実行も考慮する。
- 失敗した処理を記録し、再実行の可否と連絡先を決める。結果が不明なら、元サービスや出力先を照合してから判断する。
コピーして使える状態・照合メモ
元サービス／対象イベント／公式仕様URL／確認日：
更新取得：Webhook／定期確認／併用
通知ID／業務対象ID：
状態 | 意味 | 次の処理・担当
受領済み | 検証して保存できた | 処理待ちへ
処理中 | 作業を開始した | 結果を記録
完了 | 業務の出力を確認した | 再通知では重複実行しない
失敗 | 原因・結果が確認できた | 条件に応じて再実行
結果不明 | 応答などがなく成否不明 | 照合してから判断
重複・同時実行を防ぐ方法：
取りこぼし照合：期間／元データ／処理記録／担当
定期確認：取得条件／ページ分割／前回の確定位置
再実行の承認・停止条件：結果の確認ポイント
同じ通知が2回届く、同時に届く、順序が逆になる、処理途中で停止する、通知が来ない、というケースの期待結果を先に決めます。通知IDの記録だけで、同時実行や異なる通知IDによる同じ業務の重複まで必ず防げるわけではありません。業務対象の識別と出力側の重複防止も設計します。
重要な処理では、一定期間の元データと完了記録を照合する案を検討します。ポーリングでもページ分割や途中失敗を考慮し、未取得のまま次の期間へ進めないようにします。併用する場合は同じ業務を二重実行しない共通ルールが必要です。
今日試すこと
1つの更新について、受領済み・処理中・完了・失敗・結果不明の意味を書いてください。実装後の確認はテスト環境とダミーデータで行い、受領応答の成功だけを業務完了の証拠にしないことがポイントです。
参考資料
- Stripe｜Webhooks：重複・順序・署名検証・非同期処理。利用するサービスの配送保証と再試行条件は個別に確認してください。