通信エラーで自動化をやり直しても、同じデータが二重に登録されないようにできますか？
同じ業務依頼を識別する番号と、実行状態を記録し、再実行時に照合する設計が必要です。画面の連打防止だけに頼らず、保存先や連携先を含めて重複を防ぎ、結果が不明な処理は確認へ回します。
失敗の表示でも、登録は終わっているかもしれない
例えば、現場の報告書を読み、社内の対応台帳へ登録する自動化を作ったとします。ある日、処理中の画面で通信エラーが出ました。担当者がもう一度実行すると、同じ報告が二件並んだ。これは架空の場面ですが、自動化で考えておきたい失敗です。
登録そのものに失敗した場合と、登録は成功したのに結果の返事だけ届かなかった場合は、利用者から同じように見えることがあります。『エラーだから最初からやり直す』だけでは、後者を二度実行してしまいます。
クラウドを使っても、重複の可能性は残る
Google Cloud Tasksの公式資料は、重複実行がゼロではなく、処理側で適切に扱う必要があると説明しています。MicrosoftもAzure Functionsの設計資料で、再試行や同じ要求の再送を想定し、重複検知や同時実行の制御を考えるよう案内しています。
同じ依頼を繰り返しても、業務上の結果を一回分に保つ性質を『冪等性（べきとうせい）』と呼びます。難しい言葉ですが、現場にとっての問いは明快です。『同じ報告を二度受け取ったとき、何を一件と数えるか』を決めることです。
受付番号は、やり直しても変えない
報告を受け付けた時点で、一つの業務依頼に対応する番号を付けます。再実行時も同じ番号を引き継ぎます。実行のたびに新しい番号を作ると、同じ依頼なのか、新しい依頼なのかを見分ける材料になりません。
ただし、顧客名やファイル名が同じというだけで重複扱いするのも危険です。同じ顧客から別の報告が届くことも、同じ報告に訂正が入ることもあります。『再送』『内容の訂正』『別件』の違いは業務側で決め、必要なら元の受付番号と改訂番号を組み合わせます。
実行中、完了、不明を分けて残す
台帳には、依頼の番号に加えて処理状態を残します。未処理、実行中、完了、確認が必要、といった区別です。同じ番号の依頼が来たら、完了済みならその結果を返し、実行中なら別の処理を重ねず、結果不明なら登録先を調べる流れにします。
『登録済みか調べて、なければ登録する』だけでは、二つの処理が同時に動いたとき、両方が未登録と判断することがあります。開発担当には、保存先の重複を許さない制約や、一連の更新をまとめて確定する仕組みも含めて検討してもらいます。現場のルールを、データの仕組みでも守るためです。
外部サービスへの送信は、さらに一段分ける
台帳への登録と外部への通知を一度に行うと、登録は完了したが通知だけ失敗した、といった途中状態が生まれます。最初から全部やり直すのではなく、どの段階が完了したかを残します。連携先が重複防止用の番号を受け付ける場合は、その仕様も確認します。
対応していない連携先では、こちらの記録だけで完全に二重送信を防げるとは限りません。送った直後に結果を記録できなくなる場合があるためです。結果不明のものを自動で送り直すか、人へ確認を求めるかを、影響に合わせて決めます。
顧客へのメールや発注、支払いは、一回余計に実行する影響が大きい処理です。重複防止があることを送信や実行の許可と混同せず、会社が定めた承認条件を別に守ります。最初の検証は社内用の架空データだけで十分です。
二回動かす試験を、完成条件に入れる
開発を頼むときは、『一回成功する』に加えて、『同じ受付番号を二回送っても一件になる』『同時に届いても増えない』『登録後に返事が途切れても照合できる』を確認項目に入れてみてください。さらに、別の依頼まで誤って止めていないかも試します。
AIに文章を作り直させる部分と、正式な台帳へ登録する部分は分けると考えやすくなります。文章案は複数あってもよい一方、どの版を正式採用するかは決めてから登録します。AIへ『重複しないで』と伝えるだけで、保存先の制約を省かないことが大切です。
まず、現在の自動化から一つ選び、同じ依頼が再び届いたときの動きを紙に書いてみましょう。再実行できることは、失敗から立て直せることでもあります。小さな試作を現場で使い続けるために、最初から持っておきたい設計の視点です。
出典・参考情報
情報は最終更新時点の内容です。サービスの仕様・料金・利用条件は公式情報をご確認ください。