業務自動化を本番へ移す前の確認項目

自動で始まることと、完了することを区別する

この記事は公式情報＋設計例です。稼働率や導入効果を測定したチェックリストではありません。処理が起動しただけでは、業務が完了したとはいえません。『対象の受付番号が台帳に一件あり、必要な列がそろっている』など、完了をデータで判断できる状態にします。

日々の記録は、受信件数、完了件数、例外件数、未処理件数に分けます。再試行による実行回数を受付件数へ足さないよう、同じ業務の識別子を引き継ぎます。成功率の分母が変わらないことは、改善の効果を比べるうえでも大切です。

初回に確認する五つの入力

本番で想定する範囲から、以下のテスト入力を用意します。結果は『動いた』ではなく、期待した保存件数や状態と照合します。テスト中は架空のデータと専用の保存先を使い、通知や公開の動作も検証対象として明示します。

• 正常：一件の入力から、一件の完了記録が残る。
• 重複：同じ識別子を再送しても、書き込みが増えない。
• 不足：必須情報が欠けた入力を、完了扱いにしない。
• 大量：想定を超える入力を、上限なく処理し続けない。
• 途中失敗：保存後の障害から、同じ内容を重ねず復旧する。

再試行する失敗と、止める失敗を決める

一時的な通信障害は、回数と間隔を決めた再試行の候補です。権限切れや必須情報の不足は、同じ処理を繰り返しても直らない場合があります。失敗した場所と理由を記録し、自動復旧の対象外は例外一覧へ移す設計にします。

Makeにはエラーハンドラーや未完了実行の保存、n8nには失敗時のエラーワークフローがあります。いずれも、機能が存在するだけで自社の復旧条件が整うわけではありません。何を保存し、どこから再開し、何回で打ち切るかを業務ごとに決めて設定します。

費用と外部への操作に境界を設ける

一日当たりの入力件数、再試行回数、API使用量に上限を設けます。外部サービスの課金を完全に止められない構成なら、どこまで制御できるかを明記します。月額費用だけでなく、追加購入、外部AI、保存容量なども費用表へ入れます。

外部への書き込みは、対象と許される内容を事前に限定します。更新してよい列、配信対象、公開先などが変わった場合は、処理の条件も見直します。自由な文章から直接重要な操作を決める構成より、明確な入力項目と許容値を用意した方が、異常を検出しやすくなります。

止めた後の再開まで準備する

停止方法、未処理データの所在、最後に正常終了した位置を記録します。設定を変更する前には現在の構成を保存し、再開後は未処理と完了済みを照合します。定時処理ではタイムゾーンと対象期間も確認してください。毎回すべてを見直す運用ではなく、通常時は自動で処理し、決めた例外だけを拾える状態を目指します。