バッチ全体をやり直さずに、不足している要素だけを再開する。

1. 再実行をクリックする前に状況を確定する

作業の追加をやめ、同じバッチの実行がまだ動いていないか確認しましょう。接続が切れたからといって、必ずしもソフトウェアが停止したわけではありません。可能であればその状態を確認しましょう。2つ目のコピーを起動すると、重複が生まれたり、同じ出力先に書き込んだりする可能性があります。

ジャーナル、入力ファイルの一覧、設定、エラーメッセージを保管しておきましょう。追跡用の表を修正する前に、コピーを取ってください。疑わしい出力は別の場所に保管し、元のファイルやすでに承認済みの結果を上書きしないようにします。保存先が満杯の場合は、そのまま残すべきものを特定したうえで、空き容量を確保するか別の保存先を用意してください。

2. 各要素に安定した識別子を付けましょう

1行は1つの期待されるタスクを表すようにします。たとえば IMG-017 を catalogue/chaise-face.png に対応付ける、といった具合です。移動後はパスだけでは曖昧になることがあります。photo.png のような短い名前は複数のフォルダに存在し得ます。一意の識別子と、元の入力との対応関係を保っておきましょう。

設定の識別子、出力パス、状態、試行回数、短い理由を追加しましょう。このジャーナルは普通の表でも、プロジェクトの CSV でもかまいません。画像やパスワード、マシンの技術ログ全体を含める必要はありません。担当者が正しいエントリを見つけ、なぜそれが再開対象に含まれているのかを説明できるようにしておくことが大切です。

すでに承認されたIDの背後にある元のデータは変更しないでください。新しい入力や異なる変換には、明確に記録された新しいバージョンが必要です。そうしないと、同じIDが最終的に2つの相容れない作業を指すことになり、ログでどれが完了しているかを判断できなくなります。

3. ジャーナルと実際のファイルを突き合わせましょう

予定されている各識別子について、期待される出力を探しましょう。用途に必要な形式、寸法、内容を確認し、そのファイルを目的のツールで開いてみてください。すでに承認済みで今も存在する出力は、再開リストから除外します。ジャーナルが「承認済み」としているのに出力が見つからない場合は、まず保管されたコピーがないか探してから、再計算するかどうかを判断しましょう。

停止した時点で「進行中」だった要素は、要確認のグループに入れましょう。完了しているものもあれば、一部だけのものもあります。ファイルの日付やサイズは手がかりにはなりますが、検証にはなりません。識別子が分からない余分なファイルは、その出所が分かるまで別扱いにしておきましょう。

画像の場合、Pillow はファイルの識別、ピクセルの読み込み、構造の検証を区別します。したがって、ヘッダーを開くだけのプログラムはすべてを確認しているわけではありません。自動チェックは一部の破損を検出できますが、テキストが読めるかどうかや、色が納品物に合っているかどうかまでは判断できません。

4. 未完成の要素と却下された結果を区別しましょう

部分的な出力は、やり直すか、完全なコピーから復元する必要があります。完全だが受け入れられない出力は、まずその欠陥を理解することが求められます。読み取れない入力や、必ずメモリ不足になるケースに対して同じ設定で再実行しても、おそらく同じ問題が繰り返されます。この識別子を再びキューに戻す前に、修正内容を記録しておきましょう。

状態は少なく保ちましょう。やること、進行中、要確認、承認済み、失敗です。「承認済み」への移行は、計算の起動時ではなく確認の後に行います。入力を除外することにした場合は、理由とプロジェクトに必要な承認を添えて「除外」という状態を追加しましょう。期待される総数から黙って消えてはなりません。

新しい試行を新しいタスクとして数えないでください。IMG-019は3回の試行があっても、採用された出力は1つだけかもしれません。この区別により、60回の実行を60個の異なる成果物と混同するのを避けられます。

例：まだ必要な19項目を洗い出す

この例示的なシナリオは60枚の独立した画像に関するものです。中断と確認の後、41個の出力が承認され、4個が部分的、6個が失敗、9個が欠落しています。ログは41 + 4 + 6 + 9 = 60個のIDを適切にカバーしています。再開は19項目が対象ですが、6個の失敗の原因に対処することが条件です。

担当者は十九個の識別子のリストを再構成し、その後、四つの部分ファイル、六つのエラー、九つの出力のないタスクを区別します。まず修正済みのエントリと存在しないエントリを一つずつ取り上げます。また、すでに承認された画像が選択に含まれていないことも確認します。この小さなチェックにより、残りの処理の前にリストが検証されます。

その後さらに18項目が承認され、1つのソースファイルが読めないままだった場合、結果は承認済み59個と説明済みの失敗1個です。バッチは60個で完了とは宣言されません。次の選択は、正しい入力を見つけるか、その除外を承認してもらうことであり、その行を隠すことではありません。

5. やり直しは別の場所で行う

選別した識別子のみを含むやり直し用フォルダを用意するか、ソフトウェアの明示的な選択機能を使います。開始前にリストを再確認してください。ツールに「既存のファイルを無視する」というオプションがある場合は、その意味を確認してください。部分的なファイルが存在すると、それが誤って無視される可能性があります。検証済みのログが基準となります。

新しい出力は、その設定と試行とともに別のフォルダに生成させます。以前のバージョンを置き換える前に検証してください。スクリプトによっては、確認なしで既存のファイルを上書きすることがあります。Python は特に os.replace についてこれを文書化しています。命名規則だけでは置き換えを防げません。

不具合を修正するために設定を変更した場合は、その変更を記録に残してください。同じ基準を満たし、混在がプロジェクトにとって許容できるなら、2つの設定による出力を保持してもかまいません。見た目が均一なシリーズにする場合は、フォルダを統合する前に新しい出力と古い出力を比較してください。

6. 数量だけでなく、識別子ごとに結果を確認する

最後には、期待される各識別子に説明可能な状態がなければなりません。IMG-017 が2つあっても IMG-020 の欠落を補うことはできません。名前の一意性、入力との対応、採用した出力の設定を確認してください。やり直したファイルを開き、やり直しの理由となった点をチェックします。

完成したフォルダには、承認された出力、更新されたログ、設定、および除外またはまだブロックされている要素のリストが含まれます。この一式を検証済みのコピーとともに保存してください。「承認済み」の1行は、ファイルやそのバックアップの代わりにはなりません。

この方法は、独立したタスクをその入力からやり直すものです。シミュレーション、レンダリング、学習を停止時の正確な命令から自動的に再開することはできません。これらの作業にはソフトウェア固有の再開状態が必要です。また、レンタル環境に残ったフォルダが期間終了後に保持されるとは考えないでください。ご自身のコピーを用意してください。