Make・n8n・AI自動化

n8nのエラー処理と例外処理|空欄・重複・失敗時の分け方

n8nで正常入力、空欄、重複、通信失敗を分ける考え方を備品申請の例で解説。再申請を落とさない状態管理、Retry On Fail、Error Triggerの設定と検証を整理します。

通常の作業カードから確認待ちのカードだけを別のトレーへ分けるイメージ
目次
  1. 正常な一件の入力と、期待する結果を見る
  2. 入力不足と、実行失敗を分ける
  3. 空欄を直した再申請まで、重複として捨てない
  4. 通信失敗時の再試行と、Error Triggerを使い分ける
  5. テスト入力と実行履歴を比べて、原因を探す
  6. 基礎から学び直したいときは、DMMの教材も候補になる

n8nで自動化した処理がうまく動かないときは、入力不足・重複・AIの判断不能・実行失敗を分けると、直す場所を探しやすくなります。連絡先の空欄を見つける分岐と、通信に失敗した後のエラー処理は、別に用意するものです。

ここでは、備品申請を受け取り、担当者へ知らせる架空の仕事で考えます。正常入力のテストと、空欄を直して再申請するテストを、別の申請IDで追います。

正常な一件の入力と、期待する結果を見る

最初は、必要な値がそろった申請を一件だけ用意します。以下は説明用のデータで、実際の担当者へは通知しないテスト用の題材です。

{"申請ID":"S000","版":1,"品名":"マウス","連絡先":"test@example.com","数量":1}

正常入力の期待結果

受付・確認

S000を受付済みとして記録。品名・連絡先・数量を確認します。

通知まで進める場合

テスト用保存先へ通知内容を出力。実際の通知では、相手側の結果を確認してから通知済みへ変えます。

フォーム受付、入力確認、分類、記録、通知という順に、ノードへ何が渡るかを見ます。ノードは、n8nで処理をつなぐ部品です。分類結果が空なら、AIへの指示を直す前に、入力の品名が次のノードへ渡っているかを確認してください。

入力不足と、実行失敗を分ける

正常な一件の次に、次の状態を用意すると、どこで止めたいかを考えられます。

試す入力・状態 目指す処理
連絡先が空欄 自動通知せず、入力不足の確認待ちへ
同じ申請IDが二度来る 二件の新規申請にしない
分類の候補が決まらない 人へ判断を戻す
通知先が応答しない 失敗を記録し、完了扱いにしない

連絡先が空欄なら、IFなどの条件分岐で確認待ちへ回せます。AIが分類を決められない場合も、「確認が必要」という結果として人へ渡せます。処理が正常終了していても、業務として先へ進めてよいとは限りません。

一方、通知先との通信失敗やノードの実行エラーは、n8nの実行履歴やエラー処理で追います。「確認待ちへ分けた」と「処理が失敗した」を、同じエラーにまとめないことがポイントです。

空欄を直した再申請まで、重複として捨てない

同じIDが来たら全部捨てる、という条件では、修正された申請まで落ちてしまいます。申請IDだけでなく、前回の状態と、今回の内容を見ます。

ここからは、正常例のS000とは別に、履歴のないS001で空欄と再申請を試します。

前回の状態 今回の申請 処理の考え方
履歴なし S001・版1、連絡先が空欄 受付済みを記録し、確認待ちへ。通知しない
確認待ち S001・版2、連絡先を補った 修正内容を確認して再開。受付履歴があるだけで捨てない
受付済み・処理途中 同じ内容が再到着 進行中の処理と照らし、同時に二重実行しない
通知済み 同じ内容が再到着 通知の記録を確認し、同じ通知を繰り返さない
通知結果が不明 応答を受け取れなかった 相手側の記録を確認してから、再送か完了かを決める

元の空欄例なら、申請ID S001、品名マウス、連絡先空欄を「確認待ち」と記録します。その後の版2で連絡先が入ったら、確認待ちの記録と結び付けて先へ進めます。受付済み、確認待ち、通知済みは、同じ意味の状態ではありません。

Remove Duplicatesには、同じ実行内の重複と、過去の実行で見たデータを比べる使い方があります。ただし、ノードを置くだけで、永続的な二重送信防止まで保証されるわけではありません。履歴をどこへ保存し、修正や同時到着をどう扱うかも設計します。

01受付IDと内容を記録
02入力確認不足なら確認待ち
03再開修正版と前回の状態を照合
04通知確認結果が分かってから通知済みへ

通信失敗時の再試行と、Error Triggerを使い分ける

HTTP Requestなどのノードでは、Settingsの「Retry On Fail」で失敗時の再試行を設定できます。Max Triesで試行回数、Wait Between Triesで待機時間を指定します。相手の制限と処理内容に合わせ、繰り返す回数を選びます。

再試行は、入力間違いや認証設定の不足まで直してくれる機能ではありません。書込みや通知では、応答が届かなくても、相手側では処理済みの場合があるため、無条件に再送しないようにします。

ワークフロー全体の失敗を知らせたいときは、エラーワークフローを使えます。

  1. Error Triggerを先頭に置いた、エラー処理用ワークフローを作成して保存します。
  2. 対象ワークフローのSettingsで、Error workflowにその処理を指定して保存します。
  3. テスト用の接続先とデータを使い、対象が自動実行で失敗したとき、想定した情報がエラー処理へ届くか確かめます。

Error Triggerは自動実行の失敗時に動くため、エディターで手動実行しただけでは、この紐付けの検証になりません。元の失敗ノードや入力も実行履歴で見ます。n8nのエラー処理の説明で、設定と受け取る情報を確認できます。

テスト入力と実行履歴を比べて、原因を探す

正常な申請、空欄、修正版、同じ内容の再到着を、テスト用の保存先へ流す順番を考えます。期待する行き先と実際の履歴が違ったら、その直前のノードの入力と出力を見ます。

質問するときも、「動かない」だけより、次の形で示すと、直す箇所を説明しやすくなります。

質問に添えるもの 架空の記入例
入力 申請S001、品名あり、連絡先は空欄
期待した結果 確認待ちへ分岐し、通知しない
実際の結果 空欄のまま通知処理へ進んだ
聞きたいこと 連絡先の有無を調べる条件を、どこへ置くか

会社の実データを出さず、架空の値で同じ問題を再現できれば、質問する材料にも使えます。読む・分類する・通知するという仕事の選び方は、AIへ任せる仕事の整理で考えられます。

ワークフローの順番と分岐をノートへ書き、確認する担当者

基礎から学び直したいときは、DMMの教材も候補になる

ノードとデータの受け渡しから順に覚えたいなら、DMM 生成AI CAMP 学び放題のn8n教材が候補です。DMMの教材案内によると、基本操作を学び、生成AIを組み込んだワークフローやSNS自動投稿botを作る実践へ進めます。この記事の備品申請は、それを仕事へ応用するための説明例です。

月額プランは税込16,280円で、AIチューターやゼミなどの学習環境があります。自分で作りながら学び、つまずいた箇所を相談するための支援です。個別面談や専任メンター等の追加支援は通常会費と別なので、必要な支援を確認して選びましょう。

学ぶ内容の違いはDMMのDify・n8nコース比較で見られます。処理を動かす環境も考えたい場合は、AIエージェントクラウドとn8n Cloudの比較へ進めます。

参考資料・出典

本文で案内する機能・条件は2026年10月22日に公式資料で確認しました。利用できる機能と契約条件は、ご自身のプランや組織設定でもご確認ください。

  1. n8n Handle errors gracefully(確認日:2026年10月22日)
  2. n8n Error Trigger(確認日:2026年10月22日)
  3. n8n HTTP Request Common Issues(確認日:2026年10月22日)
  4. n8n Remove Duplicates(確認日:2026年10月22日)
  5. DMM 生成AI CAMP 学び放題(確認日:2026年10月22日)