n8nのワークフローが突然止まった。そのとき何をすべきか

Slackへの通知が来ない。Notionにデータが入っていない。スプレッドシートが更新されていない。n8nを運用していれば、必ずこういう場面に直面する。

正直、最初は「再実行すれば直るだろう」と思ってポチっていた。でもそれが二重投稿や重複データの原因になっていたことに、後で気づいた。

この記事では、エラーの原因特定→安全な再実行までの一連の手順を解説する。n8n v1系の現行UIに対応した内容で、古い記事のコードをコピーしても動かない、という状況も防げるようにした。

💡 関連教材: n8nノーコード自動化 実践ワークフロー集（¥1,980） — Gmail/Slack/Notion/Claude連携の動くワークフロー10本を実装込みで完全解説（全35ページ）

結論：エラー対処は「見る→絞る→確認してから直す」の3ステップ

焦って再実行するのが一番危険。まず実行ログでエラー種別を確認し、Debug in Editorでデータを固定して原因を絞り込む。副作用リスクを確認してから、初めて再実行する。この順番を守るだけでトラブルの9割は解決できる。

H2-1｜n8nのエラー画面の見方と原因の特定手順

実行ログの開き方

左サイドバーの「Executions」をクリックすると、過去の実行履歴が一覧で表示される。失敗した実行は赤い「Error」バッジが付いているので一目でわかる。

該当行をクリックすると実行詳細が開く。ここで確認すべきは次の3つだ。

  • エラー種別：NodeOperationError / NodeApiError / WorkflowOperationError のどれか
  • HTTPステータスコード：401・403・429・500・503など。番号だけで原因の方向性がわかる
  • スタックトレース：エラーパネル下部に表示される。どのノードの何行目で止まったか確認できる

n8n v1系ではノード単位のエラーパネルが刷新されており、以前より詳細なメッセージが出るようになった。v0.x時代の画面しか知らない人は、UIが別物に見えるはず。

エラー種別早見表

エラー種別 代表的な原因 第一確認先
401 Unauthorized 認証情報の期限切れ・設定ミス n8n Credentials設定
403 Forbidden 権限不足・スコープ不足 外部サービスのAPIキー設定
429 Too Many Requests レート制限超過 外部API側のクォータ確認
500 / 503 外部サービス側の一時障害 各サービスのステータスページ
JSONパースエラー レスポンス形式の変更・空レスポンス ノードの出力パネルで生データ確認
タイムアウト 処理が300秒を超えた（v1系デフォルト） データ量・ループ処理を見直し

「n8n側の問題とは限らない」という視点

これ、意外と見落とされがちなんですが、GitHubのIssue傾向（2025年）を見ると、報告数の約40%がAPI連携時の認証・タイムアウトエラー、約25%がJSONパースエラーだ。つまり、n8n本体の問題より外部サービス側の変化が原因のケースが圧倒的に多い。

エラーを見たらまず外部サービスのステータスページを確認する習慣をつけてほしい。

  • Slack：https://status.slack.com
  • Google Workspace：https://workspace.google.com/status
  • Notion：https://www.notion.so/ja-jp/status

ステータスページがグリーンなのにエラーが出るなら、そこで初めてn8n側の設定を疑う流れが正しい。

よくある失敗：エラーメッセージをGoogle検索しない

エラーパネルに表示されるメッセージをそのままコピーしてコミュニティフォーラム（community.n8n.io）で検索すると、同じ問題が解決済みスレッドとして見つかることが多い。エラー関連スレッドはフォーラム全体の約30〜35%を占めているので、まず先人の知恵を探すのが早い。

H2-2｜Debug in Editorでデータをピン留めして原因を絞り込む

Debug in Editorとは何か

v1.30以降に実用レベルまで強化された機能だ。失敗した実行のデータをそのままEditor上に引き込んで、本番環境を止めずにテスト実行できる。

何が便利かというと、「このデータが来たときにこのノードが落ちた」という状況を完全再現できる点。手動でテストデータを作る必要がない。

Copy to Editor → Pin Dataの手順

Step 1：Executionsページで失敗した実行を開く

Step 2：右上の「Copy to Editor」ボタンをクリック。これで失敗時の入力データがEditorに引き込まれる

Step 3：問題のあるノードを右クリック→「Pin Data」を選択。これで入力データが固定される

Step 4：ワークフローをテスト実行。固定されたデータで再現するかどうかが確認できる

Step 5：エラーが再現されたら、ノードの設定や式（Expression）を修正して再度テスト実行

Pin Dataはあくまでデバッグ用の仮固定なので、本番保存前に必ず外すこと。固定したまま保存すると、常にそのデータで動き続けてしまう。

データ構造の問題か、認証の問題かを切り分ける

Pin Dataで固定した状態でテスト実行し、エラーが出るかどうかで判断できる。

  • Pin Dataでもエラーが出る→データ構造・Expressionの記述が問題
  • Pin Dataでは通る→認証情報か外部サービス側の問題

この切り分けだけで、調査範囲が一気に絞れる。

console.logを仕込む一時デバッグ

データの中身が掴めないときは、Codeノードに以下を仕込む方法が効く。

// Codeノードに一時的に仕込むデバッグ用コード
console.log(JSON.stringify($input.all(), null, 2));

// そのままデータを流す
return $input.all();

実行後、「Execution Log」パネルにJSONの中身が出力される。「なぜかデータが空になる」「想定と違う構造で来ている」というケースで絶大な効果がある。

デバッグが終わったら必ず削除すること。本番ワークフローにconsole.logを残すと、大量データ処理時にメモリを圧迫する原因になる。

v0.x時代の古い記法に注意

これは正直なところ、自分も引っかかった。ネット上にある古い記事では次のような記法が使われている。

// ❌ v0.x時代の古い記法（v1系で動かないケースあり）
$node["NodeName"].error
$node["NodeName"].json

v1系では以下の記法が正しい。

// ✅ v1系の正しい記法
$('NodeName').item.json
$('NodeName').error

// 複数アイテムの場合
$('NodeName').all()
$('NodeName').first()
$('NodeName').last()

2023年以前の記事を参考にしている場合、コードが動かない原因はここにある可能性が高い。

H2-3｜安全に再実行する手順と副作用を防ぐチェックリスト

再実行前に必ず確認すること

原因を特定する前に再実行するのは、ブレーキが壊れた原因を調べずに車を走らせるようなものだ。特に外部サービスにデータを書き込むワークフローは、副作用リスクが高い。

再実行前のチェックリストはこの2点に絞れる。

  1. 原因は特定できているか：「なぜ失敗したか」が分かっていない状態で再実行しない
  2. ワークフローは冪等か：同じ処理を2回実行しても副作用が出ない設計かどうか

副作用リスクの具体例

  • Notionへの重複ページ作成：「ページが作られていない」と思って再実行→実は作成されていてページが2件できる
  • Slackの二重通知：同じメッセージが2回投稿される
  • Googleスプレッドシートの行重複：Appendモードで動いているワークフローが同じデータを2行追加する
  • 決済系API：最悪の場合、二重請求が発生する

冪等性を確保する設計パターン

冪等性（何度実行しても結果が変わらないこと）を担保するには、書き込み前にレコードの存在チェックを入れるのが基本だ。

// Codeノードで重複チェックの例（Notion APIへのUpsert的な処理）
const items = $input.all();
const results = [];

for (const item of items) {
  const uniqueId = item.json.id; // 一意のIDフィールド
  
  // 既存レコードの検索条件を設定
  results.push({
    json: {
      ...item.json,
      filter: {
        property: 'ExternalID',
        rich_text: { equals: uniqueId }
      }
    }
  });
}

return results;

NotionやGoogle Sheetsとの連携記事でも触れているが、「Createではなく、Upsert（あれば更新、なければ作成）」のロジックにしておくだけで再実行リスクが大きく下がる。

Executionsページからの再実行手順

原因特定と副作用チェックが完了したら、以下の手順で再実行する。

Step 1：左サイドバー「Executions」を開く

Step 2：対象の失敗実行にカーソルを当てる→右側に「Retry」アイコンが表示される

Step 3：「Retry with current workflow」を選択。修正後のワークフローで再実行できる

※「Retry with original workflow」は修正前の状態で再実行する。間違えやすいので注意。

n8n Cloud v3系では「Retry Failed Executions」のバルク操作UIが追加された。複数の失敗実行をまとめて再実行できるが、副作用リスクがある場合は1件ずつ確認してから実行するほうが安全だ。

H2-4｜Error Workflowで失敗を即時キャッチする仕組みを作る

Error Workflowとは何か

n8nには、あるワークフローが失敗したときに別のワークフローを自動起動する「Error Workflow」という仕組みがある。Slack通知・メール通知と組み合わせることで、エラーが起きた瞬間に気づける体制が作れる。

よくある誤解として「自動で設定される」と思っている人がいるが、明示的に設定しないと機能しない。設定場所は「ワークフロー設定（右上の歯車アイコン）→ Error Workflow」だ。

Error Workflow + Slack通知の構成例

Error Trigger
    ↓
Set（エラー情報を整形）
    ↓
Slack（#alertチャンネルに投稿）

Slackに送るメッセージに {{ $execution.id }} を含めると、エラー発生元の実行に直リンクできる。通知を見て即座にExecutionsページに飛べるので、対応が格段に速くなる。

Setノードでの整形例：

// Setノード（Expressionモード）での設定例
{
  "message": "⚠️ ワークフロー失敗\n名前: {{ $workflow.name }}\n実行ID: {{ $execution.id }}\nエラー: {{ $json.error.message }}\nURL: https://あなたのn8nドメイン/execution/{{ $execution.id }}"
}

セルフホスト環境でのError Workflow注意点

セルフホスト版を使っている場合、実行ログの保持期間がデフォルトで無期限になっていることがある。ディスクが圧迫される前に、環境変数で保持期間を設定しておくべきだ。

# docker-compose.yml または .env ファイルに追加
EXECUTIONS_DATA_MAX_AGE=30  # 30日で古い実行データを削除
EXECUTIONS_DATA_PRUNE=true  # 自動削除を有効化

クラウド版では失敗実行のログが最大30日保持されるが、セルフホスト版はこの設定をしないと溜まり続ける。

H2-5｜外部API系エラーへのリトライ実装と「Continue on Fail」の限界

n8n標準のRetry on Failと、その限界

各ノードの設定には「Retry on Fail」オプションがある。シンプルなAPIエラーならこれで対応できる。ただし設定できるのは「最大試行回数」と「試行間隔（ミリ秒）」だけで、指数バックオフのような柔軟な設定はできない。

レート制限（429エラー）が頻発するようなAPIに対しては、Waitノード+ループの組み合わせが有効だ。

WaitノードとIFノードで柔軟なリトライを実装

HTTP Requestノード（APIコール）
    ↓
IFノード（ステータスコードが429かチェック）
    ├── 429の場合 → Waitノード（30秒待機）→ HTTP Requestノードに戻る
    └── 成功の場合 → 次の処理へ

Waitノードの待機時間は固定でも良いが、リトライ回数に応じて伸ばす（指数バックオフ）ことでAPIサーバーへの負荷を下げられる。

「Continue on Fail」の誤解と正しい使い方

「Continue on Fail」をONにすれば全エラーを吸収できると思っている人がいるが、これは間違い。ノード実行前段階で起きるエラー（Credentialが設定されていない、接続エラーなど）は吸収されない。

Continue on Failが有効なのは、「処理対象の一部アイテムでエラーが出ても、残りのアイテムの処理を続けたい」というケースだ。100件のデータを処理していて、1件だけ形式が違ってもワークフロー全体を止めない、という使い方が正しい。

対処方法 有効なシーン 限界
Retry on Fail 一時的なAPI障害 指数バックオフ不可
Continue on Fail 一部アイテムのエラー許容 接続系エラーは吸収不可
Wait+ループ レート制限対策 実装がやや複雑
Error Workflow 全体的なエラー監視 設定を明示的に行う必要あり

よくある質問

Q1. 失敗した実行のデータはどのくらい保持されるか

n8n Cloud版では最大30日（2025年の仕様変更後）。セルフホスト版はデフォルト無期限だが、EXECUTIONS_DATA_MAX_AGEとEXECUTIONS_DATA_PRUNE=trueを設定して管理するのが推奨だ。ディスク容量が逼迫してn8n自体が不安定になるケースをコミュニティで複数見ている。

Q2. エラーが出ていないのにデータが入っていない。これはバグか

「成功」と表示されているのにデータが期待どおりに入っていないケースは、エラーではなくデータの流れの問題であることが多い。チェックすべきは次の2点だ。①IFノードや条件分岐で意図せず処理がスキップされていないか ②ノードの出力パネルで実際に何のデータが流れているかを確認する。このケースではDebug in Editorのピン留めが特に役立つ。

Q3. v0.xから移行したらワークフローが動かなくなった

v1系への移行時にエラーが増えた場合、記法の変化が原因であることが多い。特に$node["NodeName"].jsonや$node["NodeName"].errorはv1系で動かないケースがある。$('NodeName').item.jsonや$('NodeName').all()に書き換えること。また、Expressionの書き方が一部変更されているので、エラーパネルのメッセージを見ながら一つひとつ確認するしかない。

締め：次にやるべき1つのアクション

まず自分の既存ワークフローにError Workflowを1つ設定することから始めてほしい。エラーが起きても気づかない状態が一番危険だ。Slack通知と組み合わせるだけで、「ワークフローが止まっていた」という状況をゼロに近づけられる。

Debug in EditorやPin Dataは、次にエラーが出たときに実際に使ってみるのが一番の学習になる。手順を頭に入れておくだけで、焦りが格段に減る。

Slack通知ワークフローの作り方・NotionやGoogle Sheetsとの連携記事も参考にしながら、エラーに強いワークフロー設計を整えていこう。

関連記事

📘 もっと深く学びたい方へ

この記事で紹介した内容を、さらに体系的に・実務レベルで習得できる教材を販売中です。

n8nノーコード自動化 実践ワークフロー集（¥1,980）

Gmail/Slack/Notion/Claude連携の動くワークフロー10本を実装込みで完全解説（全35ページ）

  • Cloud版前提・2026年最新のn8n v1系UI完全対応
  • 動くノード設定値・JSON・OAuth設定まで全部入り
  • 10ワークフロー（Gmail/Slack/Notion/Discord/Webhook/RSS）はコピペで即実務投入

👉 今すぐ購入する

ChatGPT＆Claude AIプロンプト集50選（¥980）

コピペで即使える実践プロンプト50種を全24ページに凝縮

  • ビジネスメール・企画書・分析・コーディング等 8カテゴリ網羅
  • ChatGPT / Claude / Gemini 全対応
  • 変数を埋めるだけで即実務投入

👉 今すぐ購入する

関連ツール紹介

AIスキルを収益化するなら → ココナラでサービスを出品できる。AIライティング・画像生成・データ分析など、AIスキルを活かした案件の需要は増えている。

おすすめツールの一覧はこちらにまとめている。