自動化の再試行で、同じ登録を2回作らないために

通信エラーを見て再実行したら、同じ登録が2件できることがあります。この記事では、失敗と結果不明を分け、相手側の仕様に合わせた再試行の判断表を作ります。

公式資料から分かること：キーには条件がある

Stripeは、同じ冪等性キーによる再要求へ保存済みの結果を返す仕組みを説明しています。成功だけでなくエラーの結果も対象で、同じキーでパラメーターが異なるとエラーになります。キーは少なくとも24時間経過後に削除され得るため、削除後の再利用は新しい要求として処理されます。

これはStripeの仕様例です。別のAPIにも同じ保持期間や仕組みがあるとは仮定できません。また、キーにメールアドレスなどの機密情報を使わないよう公式資料は案内しています。

仕事の具体例：保存は成功、応答だけ失われた

架空のCMSへの下書き登録で、保存直後に通信が切れたとします。登録済みかもしれないので、無条件の再投稿は避けます。業務上の処理ID、送った内容、相手側の記録を照合できるようにする案です。手元の台帳にIDを付けただけでは、相手側の重複登録を防げません。

1. 送信前に処理IDと対象を記録する。同じ意図の再試行では、相手の仕様に従って同じキーを使う。
2. 応答がなければ「結果不明」とする。相手側のIDや検索・照会機能で既存結果を確認する。
3. 登録済みなら新規作成しない。照合できなければ人へ戻し、再試行の可否を判断する。
4. 回数・間隔・停止条件を決める。連携ツールやSDKの内部再試行も確認する。

コピーして使える再試行判断メモ

対象API／操作／公式仕様URL／確認日：
業務処理ID／対象ID：
重複防止キーの対応／保持期間／再利用条件：
送信内容の記録場所（秘密は除く）：
状態 | 根拠 | 次の対応
成功 | 相手側の結果を確認 | 結果IDを記録
失敗 | 未実行などが確認できた | 仕様に従って判断
結果不明 | 応答なし・照合未完了 | 照合／人へ戻す
再試行回数／間隔／停止条件：
内部の自動再試行：
同時実行を防ぐ方法／判断担当：

結果の確認ポイント

同じ要求を2回送る、同時に送る、送信後に応答がなくなる、保持期間を超える、というケースの期待結果を先に決めます。キー対応だけでなく、対象業務が二重に作られていないか出力先で確認します。内容を変えた新しい操作と、同じ操作の再試行も区別してください。

試験は許可されたテスト環境とダミーデータで行い、本番の送金・送信・登録を試験のために繰り返さないでください。結果不明を新しいキーで再送して解決しようとすると、重複防止を迂回する場合があります。

今日試すこと

登録を行う自動化1つで、応答がない場合の照合方法を書いてください。照合手段が見つからなければ、結果不明を人へ戻す条件を先に決めます。

参考資料

• Stripe｜Idempotent requests：キーの再利用、結果保存、保持期間の条件。

記事一覧へ戻る