PowerShell処理が途中で止まった後に安全に再開するには、完了済みと未完了の処理を記録したジャーナルが必要です。単にスクリプトを最初から再実行すると、重複書込みや二重請求などにつながるおそれがあります。
エラー後の状態を成功・失敗・不明に分ける
- 前回の処理がどの段階まで成功したかをログで確認します。
- 外部APIやファイル書込みが成功した直後に、応答だけ失われた可能性も考えます。
- 各処理に一意のIDがあるかを確認します。
- 同じ入力を2度実行しても結果が変わらない冪等性が必要か判断します。
処理済みだけを安全にスキップする
- 各処理単位にIDと状態（未処理、開始、完了、保留）を付けます。
- 開始前にジャーナルへ予定操作を記録します。
- 処理後、実際の書込結果を読み戻して成功を確認した行だけ完了にします。
- 中断した行は成功・失敗不明として分離し、外部状態を読み取り確認してから再処理します。
- 再開時は未完了行だけを対象にし、完了済み行はスキップします。
処理結果が不明なファイルを無条件再実行しない
- 応答がない処理を無条件に再実行すると、二重作成になる可能性があります。
- ジャーナルを処理中に上書きし続けるだけだと、破損時に復旧できない場合があります。
- ユーザーへ毎回細かな確認を求めるのではなく、必要な診断を一括で集められる設計にします。
実データとジャーナルを照合して再開する
- 途中停止、二度目の再実行、通信応答不明の3シナリオをテストします。
- 最終的に処理数・対象ID・実際のファイル/レコード数が一致することを確認します。
途中までコピーした処理の再開例
100ファイルを処理中に通信エラーが出た場合、「70個処理したから71個目から再開」と決め打ちするのは危険です。70個目の書き込みが完了した直後に結果の記録だけ失敗していることもあります。各ファイルの処理状態を成功・失敗・結果不明に分け、結果不明はコピー先の実体やハッシュで調べます。
再実行時は、既存ファイルを無条件に上書きせず、台帳・保存先・元ファイルの内容を照合してから次の操作を決めます。特に削除・移動・請求書送信など取り消しにくい処理では、同じ処理を二重実行していないことを確かめるまで止める設計が必要です。
中断した処理の扱いを状態表で決める
コピー処理であれば、PLANNED（未着手）、IN_PROGRESS（処理中）、VERIFIED（元と先のハッシュ一致）、UNKNOWN（応答不明）などに分けます。UNKNOWNではコピー先を読み取りだけで照合し、一致すればVERIFIEDへ変更します。存在しない・一致しない場合も、同名上書きや原本更新が起きていないか確認するまで無条件再実行しません。
この状態管理はPowerShellのCopy-Item単体が自動保証するものではなく、独自の再実行安全性の設計例です。支払や外部メール送信ではハッシュだけでは足りず、相手側の処理IDや受理状態が必要です。
参考資料
