Make・n8nが失敗したときの再試行：二重転記を防ぐ記録と確認手順

Make・n8nで失敗した処理を再試行する前の確認を解説。認証・上限・通信エラーを分け、処理IDと実行記録で二重転記を防ぐ手順を紹介します。

Makeやn8nの自動化が失敗したときは、すぐ最初から実行し直す前に、どこまで処理できたかを確認します。途中で止まっていても、顧客台帳への追加やメール送信だけは完了している場合があるためです。

小さな事業の運用では、すべての例外を自動で直すより、失敗した案件を見つけ、重複させずに再開できる状態を作ることが先です。この記事は設計・確認手順であり、すべての接続先で重複が起きないことを保証するものではありません。

認証・上限・入力・通信の失敗を分ける

エラーを一つの「失敗」として扱うと、待てば直るものと、設定を直すまで動かないものが混ざります。最初に原因の種類を記録します。

同じエラーを何度も自動再試行しても、認証や必須項目が直っていなければ成功しません。通知に処理IDと原因を含めると、担当者が確認を始めやすくなります。

問い合わせ受付を台帳へ転記する例なら、元の問い合わせIDを保存先にも記録します。自動化の実行IDだけでは、同じ問い合わせを別の実行として処理したときに重複を見つけにくいためです。

記録する状態は、「受付済み」「入力検証済み」「転記済み」「通知済み」のように業務の段階へ対応させます。転記先のレコードIDや送信結果も保存すると、途中停止時に確認できます。

ただし、実行前に表を検索して重複がなければ書く、という二段階の処理だけでは、同時実行の競合を防げない場合があります。実行先が一意キーや重複を防ぐ仕組みを持つかを確認し、必要なら専門知識のある担当者に設計を確認してもらいます。

MakeのIncomplete executionsは、未完了の実行を保存する機能です。公式ヘルプでは初期状態で無効と案内されており、保存するなら設定が必要です。未完了実行の設定

一時的な通信エラーなどは再試行の対象になりますが、モジュール設定や入力の修正が必要なものは手動対応が必要です。未完了実行の再試行は失敗したモジュールから始まり、エラー時の設定を使うという説明もあるため、現在の設定だけを見て判断しないようにします。未完了実行の処理方法

元の実行を再開するのか、入力を取り直して新規実行するのかを区別してください。新規実行は前段も再び通る可能性があるため、転記や送信の重複を別に確認します。

n8nでは、Error Triggerから始まるエラーワークフローを設定し、実行失敗時の通知などを行う方法が案内されています。実行ログから失敗した段階を調べることもできます。n8nのエラー処理

ただし、ワークフローの成功表示だけで業務結果が正しいとは限りません。入力が0件のまま終わった、違う台帳へ保存した、必須項目が欠けたまま登録したなど、技術的なエラーにならない問題もあります。

そのため、毎日の入力件数と保存件数、処理IDの対応、未処理の残数を確認します。通知は大量のログを送るより、「影響する案件」「現在止まっている段階」「最初の確認先」を示す形にすると対応しやすくなります。

テストでは、入力欠損、認証の無効、利用上限、保存後の通信失敗、同じ入力の再受付を扱います。実顧客への送信や本番データ削除を試験のために起こすのではなく、許可されたテスト接続と保存先で確認してください。

各ケースで期待する結果を先に書きます。たとえば保存後に結果を受け取れなかった場合は、保存先のIDを照合するまで再登録を止める、といった扱いです。自動再開できない場合も、手動で重複を調べられるなら運用できます。

月末には失敗件数だけでなく、確認時間、再試行による利用量、同じ原因の繰り返しを見ます。最も多い原因を一つ直すことが、小規模な自動化を安定して続けるための次の改善になります。