タイムアウトは未登録とは限らない：書込み結果不明を設計する

まず考えたい問い

APIがタイムアウトしたので、もう一度作成する。この自然な判断が二重登録を生みます。サーバーで保存が済んだ後、応答だけが届かなかった可能性を、呼出し側は区別できません。

対象は、この領域を実装・運用する技術者と、仕組みを学びたい方です。

設計の要点

成功・失敗に加えて「結果不明」を状態として持ちます。不明な書込みは、同じ業務キーによる再照合を経てから次の操作を決めます。

*図は処理と検証の関係を示す模式図です。実測値や性能比較ではありません。*

仕組みと判断の分かれ目

失敗の位置を分ける

入力検証で拒否された場合と、要求送信後に接続が切れた場合では再実行の条件が違います。後者には、作成されていない、作成された、まだ処理中、の可能性があります。応答のない操作を即座に失敗へ確定しない設計が必要です。

再照合にも上限を設ける

保存先の整合性や検索の反映時間を踏まえ、回数・期限を決めて同一キーを調べます。1件あり内容一致なら成功、複数件や内容相違なら人へ引き継ぎ、見つからなくても条件がそろうまで再作成を保留します。再試行ポリシーが自動作成を重ねないか、コネクターごとに確認してください。

コード・データで表すと

次は設計を読み解くための例です。疑似コードや概念表記を含み、環境へそのまま貼り付けるための完成コードではありません。

PENDING → REQUESTED → SUCCEEDED
                    ↘ UNKNOWN → RECONCILED
                              ↘ HOLD
# UNKNOWNから無条件にCREATEへ戻さない

ここまで試してから、動いたと判断する

正常系の確認だけでなく、失敗時に残るデータ、外部への副作用、再実行の可否も記録します。確認した対象・版・日時を残すと、後から同じ条件で追試できます。

小さな演習

ローカルの模擬APIで、保存してから応答だけを失敗させてください。呼出し回数と保存件数が違うことを、ログから説明する練習になります。

試験結果を「観測した事実」「そこからの判断」「まだ確かめていない条件」に分けて書いてみてください。実装を説明する力は、動く理由と止まる理由を言葉にすることで磨かれます。

適用範囲と確認事項

設計例です。自社環境での適用前に、権限・製品仕様・既存データへの影響を検証してください。 本記事は2026年10月時点の対応・設計検討を一般化した解説です。内部環境の識別子や実データは掲載していません。

参考資料

• 公式・技術資料 1