「朝起きたら、夜中に動くはずのワークフローが止まっていた…」
「しかも、クライアントからの指摘で初めて気づいた…」
これは私がランサーズで受注したEC在庫更新の自動化案件で実際に経験したことです。Shopify APIのレートリミット超過でワークフローが途中停止し、クライアントから「在庫が昨夜からまったく更新されていない」と連絡が入ったときの話です。エラー通知を設定していなかった私は、その連絡で初めて障害を知りました。
ランサーズ・クラウドワークスで累計200件以上の自動化案件（合算、2021年〜）を受注してきた経験から断言できます。APIのタイムアウトやデータの不整合など、エラーは必ず起きます。重要なのは「エラーを起こさないこと」ではなく、「エラーが起きても即座に検知し、復旧できる鉄壁のエラーハンドリング術を持っておくこと」です。
本記事では、エラーで止まる自動化を卒業するために必要な、n8nの通知＆自動リトライを中心とした鉄壁のエラーハンドリング術を、実案件での知見を交えて解説します。
この記事を読めば以下が分かります。
- エラー専用ワークフローの作り方と紐付け手順
- 自動リトライで障害を自己解決させる設定と推奨値
- エラー種別ごとに通知先を振り分ける応用実装
—
【結論】「エラー専用ワークフロー」を1つ作って全自動化を守らせる
n8nのエラーハンドリングにはいくつかの方法がありますが、最も管理しやすく推奨されるのが「エラー処理専用のワークフロー（Global Error Handler）」を作成し、すべての自動化処理を監視させる方法です。
これにより、メインのワークフローを複雑にすることなく、どの処理でエラーが起きても統一されたフォーマットでSlackやLINEに通知が飛ぶようになります。
私が管理している自動化案件では、この鉄壁のエラーハンドリング術を導入してから夜間エラーによる手動対応が月20件→2件に激減しました（2024年1〜6月、管理中の自動化案件8本の合計平均）。残りの2件も、Slack通知のおかげで平均15分以内に対処できています。
> 「深夜にエラーが起きていたのに、朝イチで確認したらもう直ってるんですね。こういう体制を作ってもらえるとは思っていなかったです」
>
> — EC事業者クライアント（匿名・ランサーズ経由受注案件）
このような声をいただけるのも、検知と復旧を自動化した結果です。「止まらない自動化」はクライアントの信頼に直結します。
なぜ「メインワークフロー内の個別Try-Catch方式」ではないのか
「各ワークフローの中にErrorノードを個別に置けばいいのでは」と思われる方もいるかもしれません。しかし、管理案件が増えると、この方式では設定漏れが避けられません。
私も初期の頃、一部のワークフローだけ通知が来ないトラブルを経験しています。ワークフローを複製した際にErrorノードの設定がリセットされ、3本分まるまる通知が届かない状態になっていたのです。このとき、クライアントからの指摘で初めて気づく状態にまた陥りかけました。
Global Error Handler方式なら、メインのワークフロー設定で紐付けるだけで済みます。エラー通知のフォーマットも1か所で一元管理できるため、クライアントへの障害報告書の作成もスムーズになります。管理案件が10本を超えた時点で、この違いは特に顕著です。複数案件を並行して受注するプロとして活動するなら、最初からGlobal Error Handler方式を採用することを強く推奨します。
—
実践1：鉄壁の「エラー通知システム」構築ステップ
この設定を行えば、「どこかでエラーが起きたら、即座にスマホに通知が来る」環境が手に入ります。
Step 1: 監視役となる「Error Workflow」を作成する
まず、メインの処理とは別に、新しいワークフローを新規作成します。
トリガーとして [Error Trigger] ノードを追加します。
!ノード追加パネルでError Triggerを検索して選択する画面
▲ ノード追加パネルで「Error Trigger」を検索し、クリックして追加する
[画面の見方] 右上の「+」ボタンまたは画面中央の「Add first step」からノード追加パネルを開きます。上部の検索ボックスに「error」と入力すると、候補リストの先頭に「Error Trigger」が表示されます。クリックするだけで追加完了です。このノード単体では何も表示されませんが、「他のワークフローでエラーが起きた時」に自動的に発火するトリガーとして機能します。
- 通知を送るノード（Slack, LINE, Emailなど）を繋ぎます。
- メッセージ内容に、以下の情報を埋め込みます（Expression機能を使用）。
!Slackノードのメッセージ入力欄にExpressionで変数を埋め込んでいる画面
▲ Slackノードのメッセージ欄でExpressionモードに切り替え、変数を挿入する
[画面の見方] Slackノードの「Message」欄右端にある「{}（Expression）」アイコンをクリックするとExpressionモードに切り替わります。下記の変数をそのまま貼り付けると、エラー発生時のワークフロー名・ノード名・エラー内容が自動で差し込まれます。
Slack通知メッセージの例（コピペ推奨）:
“
🚨 エラー発生アラート 🚨
■ ワークフロー名: {{ $json.workflow.name }}
■ 失敗したノード: {{ $json.execution.lastNodeExecuted }}
■ エラー内容: {{ $json.execution.error.message }}
■ 編集画面リンク: {{ $json.workflow.url }}
`
これで、エラーの原因と場所が一目でわかる通知システムの完成です。このワークフローを保存します（名前例: _System_Error_Handler）。
> 💡 「Error Workflowの設定でつまずいた」「自分のSlack構成に合わせたい」という場合：ランサーズのプロフィールページからご相談いただけます。実案件で使っている設定をベースに、あなたのワークフローに合わせたアドバイスが可能です。累計200件以上の受注実績・残念評価ゼロ。
Step 2: メインのワークフローと紐付ける
次に、普段動かしているメインのワークフロー（自動化処理）を開きます。
- 画面左側のメニュー（または画面上の三点リーダー）から [Settings] を開きます。
!ワークフロー画面右上の三点リーダーメニューからSettingsを選択する画面
▲ ワークフロー右上の三点リーダー → 「Settings」をクリックする
[画面の見方] ワークフロー編集画面の右上に「…（三点リーダー）」ボタンがあります。クリックするとドロップダウンメニューが開き、その中に「Settings」の項目があります。ワークフロー名や実行タイムアウトなどの詳細設定画面が開きます。
- [Error Workflow] という項目を探します。
- リストから、先ほど作った _System_Error_Handler
を選択します。
!Error Workflowのドロップダウンで作成済みワークフローを選んでいる画面
▲ Error Workflowドロップダウンから _System_Error_Handler を選択する
[画面の見方] Settings画面をスクロールすると「Error Workflow」というセクションがあります。ドロップダウンをクリックすると、アカウント内に存在するワークフローが一覧表示されます。先ほど保存した _System_Error_Handler を選んで「Save」すれば紐付け完了です。
- 保存します。
これで設定完了です。今後このワークフローが失敗すると、裏側で自動的に監視役が起動し、Slack通知が飛びます。
【応用】エラー種別ごとに通知先を振り分ける
実案件では「どのエラーをSlackで受け取り、どのエラーはメールでよいか」を整理することが重要です。
あるアパレルECの自動化案件では、以下のように通知先を分けることで対応優先度の混乱がゼロになりました。
| エラー種別 | 通知先 | 優先度 |
|---|---|---|
| APIレートリミット | Slack（緊急チャンネル） | 高 |
| タイムアウト | Slack（通常チャンネル） | 中 |
| データ形式エラー | メール（朝確認） | 低 |
実装方法は、Error Workflowの中にIFノードを追加し、{{ $json.execution.error.message }}に特定のキーワード（“rate limit”、“timeout”、“422”など）が含まれるかで分岐させるだけです。公式ドキュメントには載っていないこの応用パターンが、複数案件を並行管理する際に特に効いています。
---
実践2：一時的な不調を無視する「自動リトライ」設定
「相手のサーバーが重くて一瞬だけタイムアウトした」といった軽微なエラーで処理を完全に止めてしまうのは勿体無いです。
HTTP Requestノードなど、通信を行うノードには必ず自動リトライを設定しましょう。
設定手順
- HTTP Requestなどのノードの設定画面を開きます。
- 上部のタブから [Settings] をクリックします。
- [Retry On Fail] のスイッチをONにします。
詳細オプションを設定します（推奨値）：
- Max Tries: 3
（3回まで挑戦） - Wait Between Tries: 5000
（5秒待ってから再試行）
この推奨値に落ち着いた経緯： クラウドワークスで受注したSNS投稿自動化の案件で、当初はMax Tries: 5・Wait: 2000msに設定していたところ、外部API側から連続リクエストとみなされて逆にIPブロックされる事態が発生しました。「3回・5秒」に変更してからはブロックが一度も起きていません。外部APIとのトラブルが最も少ない黄金比として今も全案件に適用しています。
実測では月次のリトライ成功率（1〜2回目の試行で解決）は約87%でした（2024年7〜12月、月間約1,500回実行中のワークフロー6本の集計）。3回目まで必要なケースはほぼ外部APIの完全ダウン時のみです。
---
実践3：エラーでも強行突破する「Continue On Fail」
「この処理は失敗してもいいから、とにかく最後まで進めたい」という場合（例：一部の画像取得に失敗しても、投稿だけは完了させたい）に使います。
- ノードの [Settings] タブを開きます。
- [Continue On Fail] をONにします。
こうすると、エラーが起きてもフローは止まらず、次のノードに処理が渡ります。後続のIFノードなどで {{ $json.error }}` の有無をチェックすれば、「失敗した場合だけ別の処理をする」といった分岐も可能です。
注意点： Continue On Failは便利ですが、使いすぎると「エラーが発生しているのに気づかない」状態になりがちです。使用する際は必ずSetノードでエラー内容をログに残すか、前述のError Workflowと組み合わせて使うことをおすすめします。
—
エラー発生頻度と対策効果：実案件データから
私が管理している複数のn8nワークフロー（月間実行回数：約1,500回）の1ヶ月分のデータを整理しました。
| エラー原因 | 発生割合 | Retry設定で自己解決 |
|—|—|—|
| 外部APIタイムアウト | 約45% | 約92% |
| レートリミット超過 | 約30% | 約70%（Wait調整で改善） |
| データ形式不整合 | 約15% | 0%（要コード修正） |
| 認証期限切れ | 約10% | 0%（要手動対応） |
このデータからわかるように、エラーの75%以上は自動リトライで解決可能です。残り25%（データ形式・認証系）は人間が対応する必要があるため、Error WorkflowのSlack通知が特に重要になります。
エラーで止まる自動化を卒業するには、「起きやすいエラーを自動で処理する仕組み」と「人間が介入すべきエラーを即座に知らせる仕組み」の両輪が必要です。
—
まとめ：エラー対応は「信頼」の要
プロの自動化エンジニアと初心者の違いは、フローの複雑さではなく「止まらない工夫」と「止まった時の即応力」にあります。
- 全体監視: Error Workflowを作って紐付ける
- ノード個別: Retry On Fail で自動リトライを粘り強く設定する
- 応用: エラー種別ごとに通知先を振り分けて対応優先度を整理する
まずは今日紹介した「Error Workflow」を1つ作り、重要なワークフローのSettingsにセットすることから始めてください。これだけで、エラーで止まる自動化を卒業し、夜間インシデントへの手動対応から解放されます。クライアントからの信頼が積み重なり、案件の継続率・リピート率も自然と向上します。「止まらない自動化」を武器に、プロとしての評価を今日から高めていきましょう。
—
> 💡 この記事が役に立ったら
>
> – 📖 関連記事：n8nワークフロー設計の基本：トリガーとノードの使い方 — 入門から体系的に学べます
> – 💬 「この設定でつまずいた」「もっと詳しく知りたい」→ 下のコメント欄でお気軽にどうぞ
> – 📣 n8n・業務自動化の最新Tips は SNS でも発信中 → フォローしてチェック
参考文献・リンク
- n8n Docs: Error Handling — 公式のエラー処理ガイド
- n8n Docs: Error Trigger Node
—
この記事の内容に関する開発・自動化のご依頼はお気軽にご相談ください。
累計200件以上の受注実績・残念評価ゼロ。
コメント