保存は成功、処理は未完了——その状態を確かめず、業務を自動確定させるな

AIで受注登録と出荷依頼をつないだ。数秒後、画面に「完了」と出る。試験は何度も成功したので、次は毎日の注文をそのまま流そうとしている。けれども、作った画面の外で、在庫と出荷がどうなったかまでは見ていない。

ここで画面を閉じてはいけない。登録、在庫引当て、外部サービスへの出荷依頼は、本当に同じ一回の仕事として終わったのか。通信が途切れたとき、相手には届いたのか。もう一度実行してよいのか。その答えがないまま「完了」を信じると、状態の分からない仕事を次の工程へ送ることになる。

途中の状態を説明できない連携を、「完了」という表示だけで実業務の自動確定へつないではいけない。

「成功」を、工程ごとの状態へほどく

一件の仕事を「受注登録→在庫引当て→出荷依頼」と並べてみる。最初の登録だけが済み、引当ては失敗し、出荷先の応答は戻っていない。このように、一連の工程の一部だけが成立した状態を部分成功という。業務では、成功か失敗かの二択ではなく、「どこまで成立したか」が問題になる。

画面の完了表示が示す範囲も確認したい。受注レコードを書き込めたことを示すのか、三工程すべての結果を照合したことを示すのかで意味はまるで違う。状態を「受付済み」「引当て済み」「出荷先で受付済み」「要調査」のように工程ごとに持ち、一件の識別番号から追えることが、自動確定を検討する入口になる。

ここで止める対象は、連携機能の試験ではない。成立済みと未完了を見分けられないまま、次の工程まで無人で確定する判断だ。読み取りや下書き、担当者が状態を照合した後の処理は、範囲を明記して続けられる。

トランザクションが守る範囲を越えて考えない

トランザクションは、複数のデータ変更を一つのまとまりとして扱い、途中で失敗したときに確定前の変更を取り消せる仕組みである。業務の言葉にすれば、「同じ台帳の中で、片方だけを書き換えた状態を残さない」ための境界だ。

PostgreSQLの公式文書 は、BEGINからCOMMITまでの更新を一つにまとめ、必要ならROLLBACKで取り消す考え方を説明している。ここから確認できるのは、データベース内の変更をまとめる仕組みである。

メール、配送会社、決済サービスなど、別の仕組みへ送った依頼まで同じ方法で一括して取り消せるとは、この資料からは言えない。外部サービスには、こちらとは別の受付状態と記録がある。送信直後に応答が途切れれば、「届かなかった」のではなく、「届いたか分からない」が残り得る。そこで必要なのは、トランザクションという言葉の有無より、どの工程まで同じ境界で守られ、どこから外部の状態になるかを示した図と記録だ。

データベース内で戻せることを、外部連携を含む業務全体の保証へ広げてはいけない。

外部連携では「応答なし」を未成立と決めつけない

外部連携は、自社の処理から別のサービスへ依頼を渡し、その結果を受け取る接続である。業務では、接続先の画面や記録を自社だけで直接確定できない区間になる。

問題が見えやすいのは、明確なエラーより応答が戻らないときだ。自社側は失敗と表示していても、相手側では受付が済んでいるかもしれない。そのまま再送すれば重複する可能性があり、待つだけなら取り残す可能性がある。これは実在事故の説明ではなく、利用開始前に試すべき条件である。

工程ごとに三つを決めると、曖昧さを業務へ戻せる。成立を示す記録は何か。応答がないときは、誰がどこを照合するか。一定時間を過ぎても判定できないとき、誰が保留や訂正を決めるか。外部サービスの仕様が未確認なら、「おそらく届いていない」を運用ルールにしてはならない。

再処理では、成立済みの仕事を重ねない

エラー画面で「再実行」を押すことと、業務を正しい状態へ戻すことは同じではない。成立状態が分からず、重複を防ぐ条件も確認できない場合は、識別番号で自社と接続先の記録を照合する。すでに成立している工程を分けてから、どの工程を再処理するかを選ぶ。

すでに出荷先で受付済みなら、同じ依頼を送らず、自社側の状態を合わせる判断があり得る。重複が見つかれば、元の操作を繰り返すのではなく、取消しや訂正で整合を取り直す。このような補償処理は、外部で成立した仕事を業務上の別操作で打ち消す考え方であり、すべてを自動的に過去へ戻す機能という意味ではない。具体的な方法は接続先の仕様と自社の手順で確認する必要がある。

接続先に同じ依頼を重複登録しない仕組みがあり、その有効な期間や条件を確認できるなら、決めた回数まで自動で再試行する設計もできる。すべての再試行を人が一件ずつ承認する、という話ではない。重複を防げる条件、再試行を打ち切る条件、判定できないときの確認先までを先に決める。

再処理を安全にする鍵は、「何回押しても大丈夫」という期待ではなく、同じ依頼を識別できること、成立状態を照合できること、実施と承認の担当が決まっていることだ。再処理はエラーへの反射動作ではなく、重複を防ぐ条件と、判定できない場合の扱いを決めた業務処理である。

作った連携を動かす前に、状態と確認先を残す

作った連携を実業務の自動確定へ進める前に、少なくとも四つの証拠を確認する。

一つ目は、一件の識別番号から各工程の状態と更新時刻を追える記録。二つ目は、通信切断、応答なし、途中失敗を起こし、重複と取り残しの扱いを確認した試験結果。三つ目は、照合、再処理、訂正、問い合わせを引き受ける担当と連絡経路。四つ目は、どの利用者、注文、操作まで自動化するかを記した承認記録である。

そろわない場合は、業務担当と相談し、最後の確認を残す、外部連携の前で止める、対象となる注文を絞る、といった形で進め直す。すでに成立した出荷や計上を、作成者の判断だけで取り消してはいけない。状態を調べる仕事と、訂正・取消しを認める仕事を分ける。

途中で止まった一件を、どこから再開できるか説明できる状態にする

保存、トランザクション、外部連携、再処理は、それぞれ別の問いである。保存できたか。どの変更を一括で守れるか。接続先で何が成立したか。どこからやり直してよいか。この四つを一つの「成功」に畳まない。

正常に通った一件の次に、途中で止まる一件を、許可された試験環境とデータで確かめる。どの工程まで成立し、誰が何を照合すれば次へ進めるかを記録する。分からない結果は「失敗だから再実行」で片付けず、保留して確認先へ渡す。その一件を説明できる範囲から、連携を使う仕事を広げていく。

参考資料

• PostgreSQL Documentation: Transactions