自動化が止まった朝、何から戻す？二重処理を避ける手動復旧メモ

朝の転記が止まっている。急いで「もう一度実行」を押したい。でも、途中まで処理されたデータがあるかもしれません。全部を最初から流すと、重複した登録や通知が増えることがあります。

再実行の前に、処理済み・未処理・結果不明を分けます。この記事では架空の受注転記を例に、担当者が残す復旧メモを作ります。本番環境で実施した障害訓練の報告ではありません。

まず止めるのは、次の自動実行

調査中も同じ処理が動き続けると、記録と実際の状態が変わってしまいます。どの処理を一時停止するかを決め、承認された担当者が対象を確認して止めます。関連する別の仕事までまとめて停止しないよう、処理名と起動条件を残します。

実行履歴の成功時刻は手がかりですが、その実行で対象を何件処理したかは別です。元データのIDと転記先を照合し、業務上のどの1件が終わったかを確認します。処理開始のログがあることを、保存完了の証拠にはしません。

処理名：受注データの日次転記
異常に気付いた日時：
一時停止した対象・実行者：
最後に保存を確認できたID：
未処理と確認したID：
結果不明のID・確認先：
再処理する対象と順番：
二重登録・二重通知の防ぎ方：
再開する条件・判断者：
再開後に照合する件数とID：

件数だけ合っていても、同じ1件が重複し、別の1件が抜けている場合があります。可能ならIDの集合を照合します。先頭0がある番号など、表計算で形式が変わる値も、元の文字列と一致しているか確かめます。

保存済みで通知だけ未送信なら、受付を作り直す必要はありません。通知の応答が途切れただけなら、すでに届いている可能性もあります。外部側の記録を確認してから再送します。詳しくは「受付済み」と「通知済み」を分ける設計へつながる論点です。

GASを使っている場合、実行履歴やログは調査の入口になります。ただし、ログに残る情報や保持期間は設定と仕組みによって異なります。障害が起きてから記録が足りないと分かる前に、必要なID・結果が確認できるか平常時に見ます。

コピー環境で、数件を処理した後に失敗する条件を作ります。別の担当者がメモを読み、終わった分を増やさず未処理から再開できるか確かめます。通知や更新は検証用の宛先に限定し、本番データを意図的に壊して試さないようにします。

復旧後は、元データと保存先、必要なら通知先を照合し、再開時刻と判断者を残します。その場で復旧できても、原因が未解決なら次の実行でも繰り返す可能性があります。暫定対応と恒久対応を分けて担当を付けます。

止まらない仕組みだけを目指すと、止まったときの判断が残りません。自動化する仕事には、手動で対象を確認し直せる道も用意しておくと、担当者の交代や外部サービスの障害に対応しやすくなります。

2026年11月2日確認。本文の例・図・ひな型は本記事用に作成したものです。以下は、設計や事例の背景として参照した一次資料です。