n8nが動かない12の原因と対処法 症状別チェックリスト (2026年版)

エラーメッセージが出ないまま何も起きない。この「静かに動かない」状態が、n8nでいちばん時間を溶かします。

犯人はたいてい派手なバグではありません。設定が1つ抜けているだけ。

復旧を早くするコツは、原因を推理する前に「どこまでは動いているか」を確定させることです。トリガーは発火したのか。実行履歴に記録は残っているのか。ノードは赤くなっているのか。この3点を見るだけで、候補は10分の1に絞れます。

まずは症状から入口を決めます。下の表で自分の状況に近い行を探してください。

つまり、履歴が空なら原因はトリガー側、履歴があるならノード側。この分岐だけ覚えておけば迷いません。

そもそもn8nとは？動かなくなる原因はどこに集中する？

n8nとは、アプリやAPIを線でつないで業務を自動化する、ソースコード公開型のワークフロー自動化ツールです。クラウド版とセルフホスト版の両方があり、後者は無料で使えます。

自由度が高いぶん、壊れ方も自由です。ZapierやMakeのような完全ホスト型と違い、サーバー設定・環境変数・バージョン管理まで利用者の責任範囲に入ります。

2025年12月に公開された2.0系からは「セキュアバイデフォルト」の設計に変わりました。安全側に倒れた結果、以前は通っていた設定が弾かれるケースも出ています。

不具合の入口を大きく分けると、次の4つです。

要するに、クラウド版なら設定と認証と上限の3つ、セルフホスト版はそこにインフラが1つ乗る構図です。

自動化ツール全体の選択肢を整理したい場合は、AI自動化カテゴリに主要ツールをまとめてあります。

Webhookが反応しないときは何を疑う？

Webhookトラブルの原因は、9割がURLの取り違えです。n8nはテスト用と本番用で別々のURLを発行します。

/webhook-test/ が付いたURLは、エディタ上で「Test workflow」を押している間の数十秒しか生きていません。連携先のサービスにこれを登録したまま放置すると、翌日から無反応になります。

本番で使うのは /webhook/ のURLです。そしてワークフローが有効化されていなければ、本番URLも404を返します。

この表の1行目を外部サービスに貼っていないか、まず確認してください。ほとんどの「昨日は動いたのに」はここで解決します。

URLが正しいのに届かない場合、外側を疑います。セルフホストでリバースプロキシを挟んでいるなら、WEBHOOK_URL 環境変数に外部から見えるHTTPSのアドレスを設定しないと、n8nは自分のローカルアドレスをURLとして発行してしまいます。

送信元の仕様も要注意。GitHubやStripeのようにPOSTのボディに署名を付けるサービスは、n8n側で Raw body を受け取る設定にしないと検証に失敗します。

ここまでの整理: 履歴が空なら「トリガーまで届いていない」。届いていないなら、URLの種類・有効化状態・外部からの到達性の順で潰していきます。

タイマーで動かしているワークフローなら、疑う場所がまた変わります。

スケジュール実行だけ止まるのはなぜ？

指定した時刻に動かない場合、時差が原因のことが多いです。n8nの初期設定はUTCで、日本時間とは9時間ずれます。

セルフホストなら GENERIC_TIMEZONE=Asia/Tokyo を環境変数に入れ、加えてワークフロー設定のタイムゾーンも同じ値に合わせてください。片方だけ直しても直りません。

もう1つの定番は、単純な有効化忘れ。エディタで保存しただけではスケジュールは動きません。

• 右上のトグルがActiveになっているか
• 保存後にトグルを切り替えていないか（切り替えでスケジュールは再登録される）
• Cron式の分と時間を逆に書いていないか
• サーバーの時計自体がずれていないか（NTP停止）

4つ目は見落とされがちです。長期間再起動していないVPSでは、時刻が数分ずれて発火条件を跨ぐことがあります。

セルフホストで実行数が増えてきた環境では、キュー方式（Queue mode）に切り替えていないと、重い処理が走っている間に別のスケジュールが押し出されます。実行履歴に「予定より数分遅れて開始」が並んでいたら、その兆候です。

トリガーが正しく動いても、その先で赤く止まるなら話は認証に移ります。

認証エラー（401 / 403）が出たときの直し方

赤いノードに数字が出ていれば、対処はほぼ機械的に決まります。エラーコードは犯人の名札です。

対処が1列で決まるので、まずコードを控えてから手を動かすのが近道です。

OAuthでつないだGoogle系サービスは、期限切れが定期的に起きます。テスト状態のGoogle Cloudプロジェクトでは、リフレッシュトークンが一定期間で無効化される仕様があるためです。本番運用するなら、プロジェクトを公開済みステータスに変えておくと再認証の頻度が下がります。

429が出ているのに気づかないケースも多いです。ループの中でAPIを叩いていると、成功と失敗がまだらに混ざり「たまに動かない」という厄介な症状になります。

複数のAIサービスをまとめて呼び出す構成なら、APIキーの管理をn8nの外に出す設計も選択肢です。DifyのようなAIアプリ基盤に生成部分を寄せると、キー更新のたびにワークフローを触らずに済みます。

ここまではクラウド版でも起きる話。ここからはセルフホスト特有の詰まりです。

セルフホスト版が起動しない・画面が開かない

管理画面そのものが開かないなら、n8nの中ではなく足元が壊れています。確認は外側から順に。

コンテナが立ち上がっているか、ポート5678が他のプロセスと衝突していないか、ボリュームの権限は正しいか。Dockerで動かしている場合、docker logs の最後の20行にほぼ答えが書いてあります。

起動はするのに認証情報だけ全滅している場合、原因は暗号化キーです。n8nはCredentialを N8N_ENCRYPTION_KEY で暗号化して保存します。

このキーはコンテナ初回起動時に自動生成され、ボリューム内に保存されます。ボリュームを消して作り直すとキーが変わり、既存の認証情報は復号できません。移行のたびに全アカウント再接続、という事故の正体はこれです。

• キーは環境変数で明示的に固定しておく
• バックアップは「ワークフローのJSON」と「キー」をセットで保管
• DBをSQLiteのまま本番運用しない（実行履歴が増えると重くなる）
• アップグレード前にボリュームのスナップショットを取る

4つ目を習慣にしておくと、後述するバージョン起因の不具合から数分で戻れます。

DB接続エラーで落ちる場合は、PostgreSQLの接続数上限も見ておいてください。Queue modeでワーカーを増やすと、1プロセスずつ接続を掴むため、想定より早く上限に当たります。

サーバーは生きているのにワークフローが完走しない、という段階になったら次の話です。

途中まで動いて止まる・タイムアウトする

途中停止の犯人は、たいていデータ量です。n8nはノード間でデータをメモリに持つため、数万件を一度に流すとプロセスごと落ちます。

症状は分かりやすく出ます。実行履歴が「Unknown error」で終わる、あるいは履歴に何も残らずコンテナだけ再起動している。これはメモリ不足の典型です。

対処は3段階で考えます。

上から順に試すのが定石です。増強から入ると、コストだけ上がって同じ壁に当たります。

PDFや画像などのバイナリを扱うワークフローでは、ファイルをメモリではなくディスクに逃がす設定が効きます。あわせて、HTTPリクエストで受け取るデータのサイズ上限も確認してください。初期値のままだと大きめのファイルで弾かれます。

処理時間そのものが長い場合は、実行時間の上限にも当たります。長時間かかる処理は、ワークフローを2本に割ってWebhookで受け渡す構成に変えると安定します。

画像生成を組み込んでいるなら、生成待ちの間ずっと接続を保持するのは分が悪い選択です。生成系ツールの特性はAIイラスト生成ツールの比較記事に整理してあるので、待ち時間の相場感を掴んでから設計すると失敗が減ります。ローカルGPUで回す構成を検討中なら、ComfyUIとStable Diffusionの違いも先に読んでおくと、n8nから叩くAPIの選び方が決まります。

データ量の問題を片付けても、AI系ノードだけは別の壊れ方をします。

AIエージェント系ノードが空回りするのはなぜ？

AI Agentノードは、n8nの中でもっとも不安定な部類です。デモでは魔法のように動き、本番では止まる。

理由は2つあります。1つは、AIが返すツール呼び出しがあいまいだったときに、同じ手順を延々と繰り返す挙動。2つ目は、メモリが初期状態では保持されないため、実行のたびに文脈がリセットされることです。

対策は防御的に組むこと。

• 最大反復回数を必ず設定する（無限ループの保険）
• ツールの説明文を短く具体的に書く（あいまいさが暴走の原燃料）
• 会話を続けるならメモリノードを明示的に接続する
• 出力形式を固定し、後段でパースに失敗したら止める

2つ目が地味に効きます。ツールの説明が長く曖昧だと、AIがどれを呼ぶか決めきれず、試行を繰り返します。

そもそも自動化の前段にある「調べる」工程をAIに任せているなら、リサーチ用のツールを分離したほうが安定します。検索特化型の使い分けはFeloの解説記事が参考になります。

エージェント構成そのものを見直すなら、AIエージェントカテゴリに選択肢がまとまっています。

昨日まで安定していたものが急に壊れた場合は、原因が自分の設定ではないこともあります。

アップデート後に急に動かなくなったときの戻し方

n8nは更新が速いプロダクトです。速いということは、壊れる機会も多いということ。

latest タグでDockerイメージを引いている環境は要注意です。再起動しただけで意図せずメジャーバージョンが上がり、ノードの仕様変更を踏みます。

復旧の手順はシンプルです。

1. 直前まで動いていたバージョンをタグ指定で立て直す
2. 実行履歴のエラーメッセージを控える
3. 公式のリリースノートで該当ノードの変更点を探す
4. 検証環境で新バージョンに上げ直し、直してから本番へ

1で止血してから調べる。この順番を守るだけで、業務停止時間が桁で変わります。

再発防止として、イメージのタグは必ず固定してください。n8n:latest ではなく n8n:1.x.x の形にするだけで、意図しない更新は消えます。

自動化が業務の中枢に入っているなら、変更履歴を誰が追うのかも決めておく必要があります。運用ルールの整備という観点では、社内監査向けAIツールの記事に、ログと承認の残し方の考え方をまとめてあります。

セルフホストの話が続きましたが、クラウド版には別種の「動かない」があります。

クラウド版で「使えない」と感じるのは上限のせい？

クラウド版で全部が一斉に止まったなら、故障ではなく上限です。n8nのクラウドは実行回数で課金するモデルのため、月の途中で枠を使い切ると新しい実行が受け付けられなくなります。

2026年4月時点の情報では、無料枠は実行回数もアクティブなワークフロー数もかなり絞られています。有料のProが月€20前後で1万回、上位のPowerが月€50前後で5万回という水準。数字は改定されるので、契約前に公式の料金ページで確認してください。

つまり、実行回数が読めない業務ほどセルフホストが有利になります。ここが判断の分岐点です。

見落としがちなのが、実行回数の数え方。1分おきに動くポーリング型のトリガーは、何も処理しなくても1回として数えられます。ここを15分おきに変えるだけで、消費が大幅に減ります。

料金や上限の考え方でつまずいているなら、完全ホスト型のZapierやMake、Microsoft 365環境ならPower Automateと横並びで見ておくと、自分の使い方に合う課金軸が見えてきます。

再発を防ぐ運用と、乗り換えを考えるライン

同じ場所で二度詰まるのは、記録がないからです。復旧したら設定を1行残す。それだけで次回は5分で終わります。

月に1回、次の4点を見るだけで事故はかなり減ります。

• エラー終了した実行の件数と、その内訳
• 認証情報の有効期限（特にOAuth系）
• ディスクとメモリの空き
• 動かしているバージョンと、公開されている最新版の差

加えて、失敗したときに気づける仕組みを必ず入れてください。Error Triggerワークフローを1本作り、SlackやDiscordに通知を飛ばすだけで十分です。気づかないまま3日止まっていた、が最悪のパターン。

では、どこからが「n8nを使い続けないほうがいい」ラインか。判断軸は3つです。

1つ目、社内にサーバーを触れる人が誰もいない。この状態でセルフホストを続けるのは無理があります。クラウド版に移すか、完全ホスト型に切り替えるのが正解です。

2つ目、使っている機能が「アプリAからBへデータを移す」だけ。分岐もコードも使っていないなら、n8nの自由度は持て余しです。設定が単純なぶん壊れにくいツールに移ったほうが安定します。

3つ目、復旧に月8時間以上使っている。人件費で考えれば、上位プランや別ツールの料金はすぐ回収できます。

逆に、条件分岐が多い・APIを直接叩く・データを外に出したくない、のどれかに当てはまるならn8nが一択です。この3つを満たす選択肢は他にほとんどありません。

SNS運用の自動化のように、プラットフォーム側のAPI制限に振り回されやすい領域では、公式機能でできる範囲も併せて確認しておくと無駄な作り込みを避けられます。Meta AIの解説で、各プラットフォームが公式に提供している機能の輪郭を掴んでおくのがおすすめです。

AI PICKS編集部の判定

n8nは、壊れやすいのではなく「壊れたことが見えやすい」ツールです。ZapierやMakeが内部で吸収している部分を、利用者の手元に出しているだけ。だから初回のつまずきは確実に増えますが、原因の場所は必ず特定できます。ここは圧倒的な強みです。

正直イマイチなのは、エラーメッセージの不親切さ。「Unknown error」で終わる実行履歴を前に、何も分からず手が止まる場面が今も残ります。日本語の情報も英語圏に比べて薄く、検索で解決しづらいのが実情です。

それでも、条件分岐が3つ以上あるワークフローを組むならn8nが一択です。実行回数課金の設計はシナリオが複雑になるほど効いてきますし、セルフホストなら回数の心配自体が消えます。

逆に、自動化したい処理が「フォーム送信をスプレッドシートに転記する」程度で止まるなら、n8nは過剰です。その規模で毎月トラブル対応に時間を取られるのは、明確に損。ツールの実力ではなく、自分の要件と釣り合っているかで選んでください。

よくある質問（FAQ）

Q. n8nが動かないとき、最初に見るべき画面はどこですか。

左メニューのExecutions（実行履歴）です。ここに記録が残っていなければトリガーまで届いていない、記録があってエラーで止まっていればノード側の問題、と原因の範囲が半分に絞れます。エラーの詳細は該当実行を開いて、赤いノードをクリックすると確認できます。

Q. Webhookのテスト用URLと本番用URLは何が違いますか。

テスト用は /webhook-test/ から始まり、エディタで実行ボタンを押している間だけ有効です。本番用は /webhook/ から始まり、ワークフローが有効化されている間ずっと受け付けます。外部サービスに登録するのは必ず本番用のほうです。

Q. 認証情報が全部エラーになりました。復旧できますか。

暗号化キーが変わった場合、既存の認証情報は復号できないため再接続が必要です。元のキーがバックアップに残っていれば、環境変数で戻すことで復旧できます。残っていない場合は各サービスで接続をやり直すしかありません。今後のために、キーは環境変数で固定しておいてください。

Q. 大量のデータを処理するとn8nが落ちます。

メモリ上にデータを保持する仕組みのため、件数が多いと限界に当たります。Loop Over Itemsノードで100件程度ずつ分割し、不要な項目を早い段階で削るのが基本です。メモリを増やす対応は一時しのぎで、件数がさらに増えれば同じ壁に当たります。

Q. クラウド版で急に全部のワークフローが止まりました。

プランの実行回数上限に達している可能性が高いです。管理画面の使用量を確認してください。ポーリング型トリガーは処理がなくても回数を消費するため、実行間隔を延ばすだけで消費量が大きく下がります。

Q. AIエージェントのノードが同じ処理を繰り返します。

AIが返すツール呼び出しがあいまいなときに起きる挙動です。最大反復回数を設定して強制的に止め、各ツールの説明文を短く具体的な文言に書き直してください。会話の文脈を保ちたい場合は、メモリノードの接続も忘れずに。

Q. アップデートしたら動かなくなりました。戻せますか。

Dockerであれば、以前のバージョンをタグ指定で立て直せば戻ります。復旧を優先し、原因調査は後回しで構いません。再発防止として、イメージのタグを latest から具体的なバージョン番号に固定しておいてください。

Q. セルフホストとクラウド、トラブルが少ないのはどちらですか。

クラウド版です。サーバー・DB・証明書まわりの問題が丸ごと消えます。ただし実行回数の上限という別の制約が付くため、月の実行回数が多い業務ではセルフホストのほうが結果的に安定します。

あわせて見たいツール・カテゴリ

n8nで詰まったときに、比較対象を持っておくと判断が早くなります。

• n8n — 機能と料金の全体像をあらためて確認したいとき
• Make — 分岐の多いシナリオを画面上で組みたい人向けの代替
• Zapier — サーバー管理を一切したくないなら第一候補
• Power Automate — Microsoft 365中心の社内業務との相性が良い
• Dify — AI呼び出し部分だけ切り出して安定させたいとき
• AI自動化ツールのランキング — 同カテゴリの評価を横並びで確認
• ノーコードAIカテゴリ — 開発者以外でも運用できる選択肢を探す

次に読むなら、AI呼び出しの安定化に直結するFeloの解説記事がおすすめです。ワークフローの前段にある「調べる」工程を切り離せると、n8n側のエラーは目に見えて減ります。

各ツールの公式サイト（一次情報）

料金・機能・対応範囲は各社公式が一次情報です。本記事は公開時点の検証に基づきますが、最新かつ正確な条件は必ず各公式ページで確認してください。

• n8n — 公式サイト（AI PICKSの詳細）
• Make — 公式サイト（AI PICKSの詳細）
• Zapier AI — 公式サイト（AI PICKSの詳細）
• Dify — 公式サイト（AI PICKSの詳細）
• Power Automate — 公式サイト（AI PICKSの詳細）