AI自動化で失敗しやすいポイント｜無限ループ・重複実行を防ぐ

AI自動化は、1回のテストが成功しても本番で安全とは限りません。特に多いのが、同じeventを何度も拾う無限loop、retryによる重複実行、AI出力を無条件で次アクションへ渡す設計です。

確認日 2026年10月12日AIものさし編集部

本番化するときは「happy path」より、再実行・重複・失敗・例外を先に考える必要があります。

先に結論：最初に切り分ける4点

最初に、出力がTriggerへ戻るloopを止め、event IDで重複を識別し、送信・削除などの再実行を止める条件を決めます。AI出力はvalidationを通してからActionへ渡します。以下では状態遷移と事故テストまで順に具体化します。

原因と事故パターンを切り分ける

自分のActionをTriggerが再び拾わないようにする

Sheet更新→Sheet更新、Slack投稿→Slack投稿、メール送信→受信トリガーなど、出力が同じワークフローの入力へ戻る構造はloopを起こしやすくなります。

processed flag、label、sender、event typeなどで自分の処理を除外します。

Event IDを保存して二重処理を防ぐ

Webhookや外部サービスは同じeventを再送することがあります。event ID、message ID、order IDなど一意なkeyを保存し、処理済みならskipする設計にします。

Retry可能なActionと危険なActionを分ける

データ取得は再試行しやすくても、メール送信、決済、削除、外部公開は二重実行の影響が大きくなります。

retry前に「同じアクションをもう一度してよいか」を分けます。

安全策を入れる

AI出力を直接Actionへ渡さない

AI分類が想定外、JSON不正、空response、hallucinationだった場合のルートを用意します。

Filter、schema validation、human approvalなどを挟みます。

Errorを握りつぶさない

失敗してもワークフローを続ける設定は便利ですが、壊れたデータを後段へ流す危険があります。

n8nではエラーワークフローやStop And エラーなど、失敗を明示して別処理へ渡す仕組みがあります。

Dedupeと履歴を持つ

入力データに同一レコードが混じる場合は重複除去を入れます。n8nにはRemove Duplicates ノードも用意されています。

Platformに関係なく、何をいつ処理したか追えるexecution logを残します。

本番前に確認する

Test Dataだけで判断しない

正常caseだけでなく、空欄、長文、duplicate、timeout、API エラー、権限切れなどを試します。

本番では小さく開始する

最初から全顧客・全channelへ適用せず、対象を限定します。問題が出たときに止められるswitchやmanual ルートを残します。

障害を「どの段階で起きたか」で切り分ける

不具合が起きたら、最初に「AIが間違えた」と決めつけず、Trigger、入力の重複、AI処理、外部Action、再実行のどこで増幅したかを分けます。実行履歴に残す最低項目は、受信日時、source event ID、処理対象ID、workflow execution ID、結果、失敗node、retry回数です。本文や個人情報をログへ丸ごと複製する必要はありません。追跡に必要なIDと状態を分けて保存します。

表は横にスクロールできます

症状	最初に確認する箇所	一度止める条件
同じ投稿や更新が連続する	出力先の更新がTrigger条件を満たしていないか	同じevent IDが短時間に反復
同じメール・注文が二重作成される	event ID / order IDを処理済み台帳と照合しているか	外部Actionの結果が不明なままtimeout
失敗後に後続Actionまで進む	error分岐・必須fieldのvalidation	不正データが送信・公開・削除へ届く
Retryのたびに別レコードが増える	retry前に作成済みか確認しているか	Actionが冪等でない
AI分類が空または想定外	schema validationとfallback	required field不足、許可外label

重複しない状態遷移を作る

たとえば問い合わせからCRMタスクを作る処理なら、受信event IDを一意な処理keyにします。処理台帳にkeyがなければ「受付済み」を記録し、分類と入力検証を行い、CRMの作成へ進みます。作成後にCRM側のrecord IDと「完了」を記録します。同じkeyが再度届いたときは、完了済みなら何もしません。処理中なら並列実行を待たせ、失敗なら前回の失敗段階を確認してから再開します。

表は横にスクロールできます

状態	次の処理	再送が来た場合
RECEIVED	event IDと対象IDを保存	同一keyなら新規処理を始めない
VALIDATED	必須項目と許可値を確認	保存済みの検証結果を参照
ACTION_PENDING	外部Actionを開始	結果不明なら照会してから再送
COMPLETED	結果ID・完了日時を記録	完了済みとしてskip
NEEDS_REVIEW	人の確認へ送る	自動実行を再開しない

この台帳は同時実行でも一意性が保てる保存先を選びます。単に実行ログへ残すだけでは、同時に届いた2件が両方「未処理」と読んでActionする競合を防げません。サービス側にidempotency keyがある場合は公式仕様を確認して利用し、ない場合は作成前後の照合と人の確認を設計します。

Retryしてよい処理、止める処理

Retryは「失敗したnodeをもう一度動かす」だけではありません。GETのように状態を変えない取得処理、時間を置いて再試行できる一時的なAPI制限、外部へメール送信したか判定できない処理では、同じ扱いにしないでください。

表は横にスクロールできます

Action	基本方針	再実行前の確認
公開情報の取得	一時エラーなら待って再試行	同じURLへの過剰な連続取得がないか
AI要約・分類	timeout後に再実行可能な場合が多い	同じ入力と同じ結果を二重保存しないか
CRMレコード作成	重複検出keyがある場合だけ再開	同じ外部IDのrecordが存在しないか
メール送信・公開・削除	結果不明なら自動retryしない	送信履歴・公開状態を照会できるか
決済・契約変更	人の承認と照合を必須にする	providerのtransaction statusが確定しているか

n8nのError Workflowは失敗時の通知や共通処理に使えますが、失敗を通知することと安全に自動復旧することは別です。Error Workflowへexecution IDや最後に実行したnodeを渡し、担当者が再開判断できるようにします。

本番前テストを事故シナリオで作る

正常な1件だけでなく、同じevent IDを2回送る、異なるevent IDで同じ注文IDを送る、外部Action成功後に応答だけtimeoutさせる、AIが許可外categoryを返す、必須値が空、Trigger自身が作った更新を再び拾う、の各ケースを用意します。合格条件は「実行が緑色」ではなく、外部Actionが意図した件数だけ発生し、重複時は既存結果を返すか人へ止まり、失敗の場所を後から特定できることです。

最初はテスト用の宛先・データだけで確認し、その後も対象件数を小さくします。停止スイッチ、手動処理先、通知担当、再開条件が決まっていないなら、全件へ有効化しません。

異常が続くときの初動

無限loopの疑いがあるときは、まず対象workflowを止め、既に実行中の処理と外部Actionの結果を確認します。Triggerの一時停止だけで完了したと思わず、queueに残ったevent、途中まで作成されたrecord、予約済みのretryも調べます。再開前には処理済みkeyを照合し、同じActionがもう一度走らない状態か確認します。原因を直した後は、停止期間に届いたデータを一括再処理せず、重複チェックと少量の再開で順に戻します。

1件の再送テストを手順化する

問い合わせevent Aを受け、処理台帳にAが受付済みと記録された後、外部Actionが成功して応答だけ失われたケースを再現します。同じAをもう一度送ったとき、処理台帳や外部recordを照会して新規Actionを増やさず、前回の結果を表示できれば重複防止の確認になります。次にevent BでAI出力を意図的に許可外の値へし、validationで停止することを見ます。最後にTriggerが自分の書いた行を拾う条件を確認し、書込み側のsource markerまたは処理済みfieldを使って除外できるか検証します。各テストは入力、期待状態、実際の外部Action件数、再実行時の結果を記録します。