自動化が止まったら誰が直す？担当者が困らない運用と保守の作り方

エラーがないのに、仕事が終わっていない日がある

説明用の例として、毎朝の受注転記を考えます。スケジュールが無効になっていれば、処理が始まらないため途中のエラーも発生しません。取得条件を誤ってゼロ件で終了した場合も、実行結果だけを見ると成功に見えることがあります。サーバーが動いている、処理が実行された、必要な受注が揃った、という三つを分けて考えます。

業務に役立つ確認項目は、最後に完了した時刻、どの期間まで取得したか、残っている受注があるかなどです。ただし毎日同じ件数を期待すると、休日や注文の少ない日まで異常になります。営業日と対象期間を含めて、「注文がない」と「取得できていない」を区別します。通知がなくても担当者が完了状況を確かめられる場所があると、未実行を見つけやすくなります。

通知には、次に何をするかまで入れる

n8nには失敗時のエラーワークフローがあります。これを使う場合も、長いエラー文をチャットへ貼るだけでは業務担当者は動けません。どの業務の、いつからの、どのデータが未完了かを示し、履歴を見る場所と担当窓口を添えます。顧客の詳細や認証情報まで通知に載せる必要はなく、調査に必要な識別情報を選びます。

一時的な再試行中まで通知が続くと、重要なものが埋もれます。自動で回復を待てる状態と、締め切りへの影響、誤更新の疑いを分けます。連携と通知が同じ認証に依存していれば、同時に止まる可能性もあります。重要な業務ほど通知経路の試験も行い、担当者が不在のときに誰が判断するかを決めておきます。

表が収まらない場合は横にスクロールできます。

参考：n8n：Handle errors gracefully

急いで手入力した仕事を、もう一度送らない

説明用の例で、夜間に倉庫への受注送信が止まったとします。現場が出荷に間に合わせるため手入力し、開発者がその事情を知らず全件再実行すれば、同じ指示が重なるおそれがあります。復旧で最初に確認したいのは、誰が何を補い、どの注文まで相手へ届いているかです。再起動する前に、追加更新を止める範囲を決めます。

成功、未処理、結果不明を分け、手入力済みの注文には倉庫側の指示番号を対応させます。認証を直せても、停止中の全データが自動で戻るとは限りません。取得できる期間と最新データの順序を確認し、未処理を絞って再開します。最後に元の受注と倉庫の結果をIDで照合し、余分な登録と取りこぼしがないかを業務担当者が確かめます。

フローのファイルだけでは、元に戻せないことがある

復旧には、処理の定義だけでなく、接続設定、実行済みの記録、基盤の設定も必要です。セルフホストのn8nは認証情報を暗号化してデータベースへ保存し、そのための暗号鍵を使います。データベースが戻っても鍵を失えば接続を再現できないため、必要な情報を洗い出し、管理者と保管方法を決めます。共有の手順書に秘密情報を直接貼り付ける方法は避けます。

復元を試す際は、本番への書き込みや通知を止めた環境を使います。保存時点が古いと、外部では完了済みの仕事が内部では未処理に戻ることがあります。復元した直後に定期実行を有効にせず、外部の結果と照合する工程を挟みます。データを戻すだけでなく、必要な権限を持つ後任が接続して確認できるかまで試しておくと、担当不在時の制約が分かります。

参考：n8n：Set a custom encryption key

外部サービスと業務が変われば、自動化も手を入れる

倉庫の追加や締め切りの変更は、通知先だけでなく分岐や取得範囲に影響します。外部APIにも変更があります。ShopifyはAPIの版にサポート方針を設け、利用できない版を指定した要求を、利用可能な別の安定版で処理する仕組みを説明しています。URLに版を固定しただけで、その動作を永久に維持できるとは考えないようにします。

利用中のAPIと版、変更情報を確認する人、試験する業務を一覧にします。変更のたびに代表的な入力と例外を試せれば、気付かないまま結果が変わることを防ぎやすくなります。設定を以前に戻すことと、外部へ既に書いたデータを訂正することは別です。業務責任者が訂正内容を判断する手順も用意し、更新作業を障害発生後だけの対応にしないようにします。

参考：Shopify：About Shopify API versioning

保守契約は、後任が困らず使える範囲で考える

契約では、異常の検知、一次調査、復旧、原因修正、仕様変更への追随、業務変更の追加開発を分けます。監視ありという表現だけでは、自動通知なのか、人が常に確認するのか分かりません。受付時間、対応する作業量、追加見積もりの条件とともに、社内で行う認可操作や業務判断を確かめます。

ダンドリの保守・継続開発は月5万円〜で、当社が開発・納品したシステムが対象です。他社システムの保守のみは受けておらず、実行基盤の有人常時監視も公開範囲に含みません。自動化の開発時に必要な運用を共有し、対応範囲を決めます。引き継ぎの最後は、後任が通知から対象を探し、模擬障害に対処してみましょう。資料を渡しただけでは見つからない権限や説明の不足を確認できます。

検討・発注前のチェックリスト

担当者と確認状況を添えて、社内の検討メモや打ち合わせの議題にご活用ください。

確認日：________________ / 担当者：________________

• □各自動化の業務責任者と技術窓口を決める。確認状況・メモ：
• □予定した仕事が終わったかを確認する場所を用意する。確認状況・メモ：
• □通知後の最初の行動と不在時の連絡先を決める。確認状況・メモ：
• □手作業で補った結果を復旧時に照合する。確認状況・メモ：
• □暗号鍵・接続設定・実行済み記録の復元を試す。確認状況・メモ：
• □APIと業務ルールの変更を確認する担当を置く。確認状況・メモ：
• □後任が模擬障害を調べて再開できるか試す。確認状況・メモ：

よくある質問

参考資料

製品の仕様・提供条件は変更されることがあります。採用時には公式資料と契約内容をご確認ください。

• Handle errors gracefullyn8n
• Set a custom encryption keyn8n
• About Shopify API versioningShopify