再送すると受注や請求が二重になる。その問題を防ぐには、通信の成功だけでなく業務処理の状態を設計する必要があります。依頼時に決めたい識別子、再試行、例外対応を整理します。
業務連携を依頼するときは、「同じ処理を再送したら何が起きるか」を最初に確認してください。送信側でエラーになっても、受信側では処理が完了している場合があります。同じ依頼を識別し、完了済みか確認できる設計が重要です。
公式資料で確認できること
Pub/Subの公式資料では、exactly-once deliveryを有効にしても、送信側で重複して発行したメッセージが複数届く可能性を説明しています。通信基盤の機能と業務上の重複判定は、分けて確認する必要があります。
Google Cloud：Exactly-once delivery
以下はFor fによる設計・検討の提案です。導入実績や効果の保証ではなく、依頼範囲を整理するための確認事項です。
通信IDと業務IDを分けて考える
送信のたびに新しくなるIDだけでは、同じ受注の再送か新しい受注かを区別できないことがあります。業務上の依頼単位を定義し、同じ依頼には同じ識別子を使うルールを決めます。更新、取消、再計上は新しい処理なのかも、業務側と合わせて確認します。
処理途中の失敗を、状態として記録する
受付、処理中、完了、要確認などの状態と、状態を変える条件を決めます。例えば登録は成功したが通知だけ失敗した場合、登録を最初から実行し直すのではなく、何を再試行すべきか判断できる情報を残します。複数システムにまたがる処理では、部分的に完了した内容も見えるようにします。
再試行できない例外も、受入テストに含める
連携先の停止、認証期限切れ、入力仕様変更、応答だけが失われるケースを試します。自動再試行の回数や間隔、諦めて担当者へ渡す条件、手動操作の権限を合意します。二重実行防止だけでなく、処理が永久に止まるケースを発見できることも受入条件です。
具体例：受注登録の応答だけが失われたら
受注は登録できたのに送信元がタイムアウトした場面を想定します。そのまま新しい受注として再送すると二重登録になるため、最初の業務IDで登録結果を確認できるようにします。同じIDで内容が変わって届いた場合は、黙って上書きせず確認対象とします。登録済み、未登録、結果不明を区別し、結果不明の処理を担当者が調べる画面や手順も依頼範囲に入れます。
試験では、同時送信、順番が逆になった更新と取消、再試行中の手動操作も確認します。合格条件は「エラーが出ない」ではなく、業務記録が意図した件数・状態になり、残った例外を追跡できることです。連携先で結果を参照できない制約があれば、その条件で保証できる範囲と照合作業を合意します。
依頼時に合意したい成果物
| 観点 | 確認すること | 残す成果物 |
|---|---|---|
| 識別 | 同じ依頼を何で判別するか | 業務IDと再送ルール |
| 復旧 | 途中まで完了した処理の扱い | 状態一覧・再試行・手動対応 |
| 照合 | 送信元と連携先の結果の差 | 未処理・重複・不一致の確認表 |
相談前に準備すること
- 実際の業務単位と、更新・取消の扱いを整理する
- 相手システムのAPI仕様と再試行条件を確認する
- 失敗時の調査ログと手動復旧画面の範囲を決める
連携先が重複防止に対応していない場合は？
送信前後の照合や状態管理で補える範囲を調査します。ただし、受信側の結果が確認できない場合など、完全な判定が難しい条件もあります。その制約と手動対応を提案段階で明記することが重要です。
For fに相談する
関連サービスの支援内容を見る / 進め方と依頼範囲を確認する
参考資料・情報確認日
公式ページの更新日：2026-09-18。情報確認日：2026年9月21日。製品の機能・条件は変更されることがあるため、導入時に公式資料と利用環境で再確認してください。
サムネイルはAI生成による概念イメージです。実際のシステム画面や測定結果ではありません。