AIが生成した業務用スクリプトをそのまま本番データに実行するのは避けます。正しい出力が一度出たことよりも、「変更する範囲」「失敗した時の被害」「元に戻せるか」を先に確かめることが重要です。削除・メール送信・決済・ファイル更新を含む場合は、まず隔離したテスト環境を用意します。
削除・送信・上書きなど副作用を洗い出す
コードを読み、ファイル削除・上書き・移動・外部通信・メール送信・API更新・DBのINSERT/UPDATE/DELETE・課金処理を一覧にします。例：CSVを読み込む処理に見えて、最後に元ファイルを削除する処理が含まれているかもしれません。入力フォルダ・出力先・資格情報・対象件数・例外時の動き・ログ内容を事前に確認します。AIの説明文と実際のコードが一致するか、人または独立ツールで検査します。
少数のテストデータで試運転
本番の顧客情報を使わず、件数の少ない架空データで正常系・空欄・重複・不正な形式・権限不足を試します。ファイル操作なら原本コピーを別ディレクトリに置き、出力先も隔離します。削除処理にPowerShellのWhatIfが使える場合は補助として使えますが、すべての外部プログラムに同じ保護があるわけではありません。メールや決済はテスト先・サンドボックスが用意できない限り本番送信しません。
入力と出力の件数・差分を検査する
入力件数Nに対して出力が何件になるのが正しいか、成功条件を事前に表で決めます。例：20行の入力を重複除去すると19行、重複1行のIDをログへ記録する、という期待値です。処理前後の行数・変更対象ID・ファイルSHA・差分一覧を見ます。「エラーが出なかった」は内容正当性の証明ではありません。異常データが1件でもある場合は、残りを続行するか安全停止するかを仕様で決めてください。
中断時に元に戻せる状態を確保する
実行前に復元可能なバックアップを作り、復元手順も小さなテストデータで確かめます。ログにいつ・どの版・何件・どの対象を処理したか残し、再実行で二重処理を起こさない仕組みを用意します。停止した時に元データを壊したまま再開しないよう、コミット単位と失敗時ロールバックを設計します。本番実行の承認者と停止基準を明文化し、未検証のコードには「テスト済み」の表示を付けないでください。
参考資料
