n8nが遅い原因と高速化7手順、レスポンスを3倍速くする設定 (2026年版)

実行ボタンを押してから結果が返るまで、じっと待つ時間が伸びてきた。Webhookを叩いても数秒返ってこない。心当たりがあるなら、疑うべきはワークフローの中身ではありません。

n8nが遅いとは、ノードの計算そのものではなく、実行履歴の保存とデータベースへの書き込み、そして1プロセスでの順番待ちに時間を奪われている状態です。ここを外すと、いくらノードを整理しても体感は変わりません。

順番に潰していきます。

n8nが遅いとは、どんな状態を指すのか

n8nの「遅い」は、画面が重いのと実行が遅いのとで原因がまったく別物です。まずどちらの話をしているのかを決めてください。

遅さが出る場所は、大きく4つに分かれます。

• UIが重い: ワークフロー一覧や実行履歴の画面を開くのに数秒かかる
• 実行が遅い: ノード間で待ちが発生し、全体の完了まで時間がかかる
• Webhookの応答が遅い: 外部から叩いたときにレスポンスが返らない
• たまに固まる: 普段は速いのに、特定のワークフローだけメモリを食い潰す

このうち上3つは、ほぼ同じ根っこから来ています。実行データがデータベースに溜まりすぎている、というだけの話。

n8nは初期設定のまま使うと、成功した実行の入出力データまで全部保存します。ノード1つあたりのデータが数百KBあれば、1日1万回の実行で数GBに育ちます。データベースが太れば、書き込みも読み出しも遅くなる。UIの画面表示が最初に悲鳴を上げるのは、実行履歴の一覧が同じテーブルを引いているからです。

つまり、遅さの正体は処理量ではなく蓄積量。ここを押さえると、対処の優先順位が自然に決まります。

遅い原因はどこにある？症状から切り分ける

症状ごとに疑う場所を決め打ちすると、調査時間が大きく縮みます。下の表を上から順に当てはめてください。

つまり、手間が小さい上2行を先に片付けるのが一番割に合います。ここを飛ばしてワークフローを書き直しても、報われません。

n8nがそもそも動かない、エラーで止まるという段階なら、原因の系統がまるごと変わります。動作不良の切り分けはn8nが動かないときの原因と対処にまとめてあるので、そちらが先です。

実行データの肥大化が一番の重り

最初にやるべきはこれです。設定ファイルに数行足すだけで、環境によっては体感が半分以下の待ち時間になります。

n8nは環境変数で実行データの扱いを制御します。よく使うのは次の5つ。

要は、成功した分は捨てて失敗した分だけ残す。これで書き込み量が桁で減ります。

EXECUTIONS_DATA_SAVE_ON_PROGRESS は見落とされがちですが、地味に効きます。有効だとノードを1つ通過するたびにデータベースへ書きに行くので、長いワークフローほど往復が積み上がる。落ちた場所を特定したい開発中だけ有効にして、本番では切っておくのが正解です。

すでに履歴が溜まっている場合、設定を変えただけでは既存分は消えません。自動削除を有効にした後、テーブルの行数が減っていくかを数日かけて確認してください。減らないなら、削除の上限件数や保持期間の設定が緩すぎます。

なお環境変数の初期値はバージョンごとに変わります。実際の値は必ず公式ドキュメントで現行版を確認してから決めてください。

ここを片付けると、次に効くのはデータベースそのものです。

SQLiteをやめると何が変わる？

n8nをDockerで立ち上げたまま使っている場合、データベースはSQLiteになっています。この状態は、検証用としては正しく、本番用としては誤りです。

SQLiteは書き込みがファイル単位でロックされます。実行が同時に走ると、片方が終わるまでもう片方は待つしかない。ワークフローが1本のうちは気づきませんが、5本、10本と増えた瞬間に待ち行列が伸びます。

PostgreSQLに切り替えると、この待ちが消えます。設定は環境変数で DB_TYPE を postgresdb にし、接続先のホスト・データベース名・ユーザー・パスワードを渡すだけ。難所は移行作業のほうです。

移行の手順はこう進めます。

• 既存の実行履歴は捨てる前提で、ワークフローと認証情報だけをエクスポート
• PostgreSQLを用意し、空のデータベースとユーザーを作成
• n8nの環境変数を書き換えて再起動、初期化が走るのを待つ
• エクスポートしたワークフローと認証情報をインポート

実行履歴を持ち越そうとすると一気に難しくなります。履歴は捨てて構わない、と割り切れるかどうかが分かれ道。ほとんどの現場では捨てて問題ありません。

切り替え後は、同時実行を投げたときの完了時間を比べてみてください。SQLiteで直列に並んでいた処理が重なって走るようになります。

データベースを直しても同時実行が伸びないなら、詰まっているのはプロセスの数です。

キューモードで処理を横に広げる

n8nは初期状態だと、1つのプロセスがWebサーバーもワークフロー実行も両方こなします。ここが構造的な上限。

キューモードは、この役割を分けるしくみです。UIとWebhookを受けるメインプロセスと、実際にワークフローを回すWorkerプロセスを別々に立て、あいだをRedisがつなぎます。Workerを増やせば、その分だけ同時に走る本数が増える。

構成としてはこうなります。

つまり、Workerの数がそのまま処理能力になります。CPUコア数を超えて増やしても頭打ちになるので、コア数の範囲で調整するのが現実的です。

設定は EXECUTIONS_MODE を queue にし、Redisの接続情報を環境変数で渡します。Workerは同じイメージを別プロセスとして起動するだけ。Docker Composeなら、サービスを1つ足して worker コマンドで立てる形になります。

1本あたりの実行を速くする施策ではない点に注意してください。効くのは「詰まらなくなること」です。10本のワークフローが順番待ちしていた状態が、同時に走るようになる。体感では、ここが一番大きく変わります。

Redisを1つ増やす運用負荷は正直それなりにあります。ワークフローが数本しかない個人利用なら、ここまでやる必要はありません。

ワークフローの書き方で削れる待ち時間

インフラ側を直しても残る遅さは、ワークフローの組み方から来ています。効き目が確実な順に並べます。

Webhookの応答を先に返す。 外部サービスからWebhookを受けて長い処理をする場合、処理が終わるまで応答を返さないと相手がタイムアウトします。Respond to Webhookノードを処理の手前に置き、受領だけ即返して残りは裏で流す。これだけで応答時間はミリ秒単位になります。

データを早い段階で絞る。 APIから100件取ってきて最後に3件だけ使う構成は、間のノード全部が100件分を運びます。Filterノードを前に持ってきて、通す量を減らしてください。

ループの中でAPIを叩かない。 1件ごとにHTTPリクエストを飛ばすと、件数×往復時間がまるごと待ち時間になります。まとめて送れるAPIなら、Split In Batchesでまとめてから1回で投げる。

分岐は並列に置く。 依存関係のない処理を直列につないでいるケースは多いです。並べれば、遅いほうの時間だけで済みます。

ただし、この4つは書き直しの手間に対して効果が読みにくい。インフラ側の3点を終えてから着手するのが順序として正しいです。

AIノードを含むワークフローだと、話が少し変わります。生成AIの応答時間そのものが数秒かかるため、n8n側をいくら削っても下限がある。この場合はモデル選択のほうが効きます。詳しくはn8nとClaudeの連携ガイドで扱っています。

Codeノードとメモリはどこで詰まる？

特定のワークフローだけが突然重くなる、あるいはプロセスごと落ちる。この症状はメモリ不足がほぼ確定です。

n8nはノード間のデータをメモリ上で持ち回ります。画像やPDFのようなバイナリデータを扱うと、それがそのまま乗る。数MBのファイルを100件処理すれば、その分がメモリに積まれます。

対処は2段階です。

まずバイナリデータの保存先を変えます。N8N_DEFAULT_BINARY_DATA_MODE をファイルシステムに切り替えると、メモリではなくディスクを使うようになります。S3互換ストレージを指定できる構成なら、そちらのほうが後々楽です。

次にNode.jsのヒープ上限。NODE_OPTIONS で --max-old-space-size を指定し、コンテナに割り当てたメモリの範囲で引き上げます。ただしこれは対症療法。根本はデータ量なので、Split In Batchesで分割して流すほうが安定します。

Codeノードでの重い処理も要注意です。JavaScriptのループで数万件を回すと、その間プロセスが専有されます。n8n 2.0以降はタスクランナーでコード実行を分離できるようになったので、Codeノードを多用する構成では有効化を検討してください。

社内システムの監査ログを扱うような、データ量が読めないワークフローを組む前提なら、設計段階でメモリの見積もりが要ります。この手の要件整理は内部監査に使えるAIツールの考え方が参考になります。

ここまでの整理: 実行データの保存を止める → PostgreSQLへ移す → キューモード化。この3つがインフラ側の全部です。ワークフローの書き直しとメモリ調整は、その後の詰め。順番を逆にすると効果が見えず、時間だけが溶けます。

クラウド版が遅いときに効く手は？

セルフホストなら打ち手が7つあります。クラウド版は2つしかありません。ここは正直に書きます。

n8nクラウドは、データベースもプロセス構成も運営側が管理します。つまり、これまで挙げた設定はほとんど触れません。残るのはワークフロー側の改善と、プランの変更だけ。

n8n公式の料金ページによると、2026年8月時点のクラウド版は無料枠が月5,000実行・稼働ワークフロー2本、Proが月額20ユーロで月1万実行、Powerが月額50ユーロで月5万実行という構成です。Powerでは同時実行数の枠も広がります。

つまり、クラウド版で「同時に走らせると詰まる」症状が出ているなら、上位プランに上げるか、セルフホストへ移るかの二択になります。

判断の目安はシンプルです。月の実行回数が1万を超え、かつ同時実行の詰まりが業務を止めているなら、セルフホスト＋キューモードのほうが安く済みます。サーバー管理を誰も見られない体制なら、素直にPowerへ。

なお2026年のn8nは、クラウド版のほうがAI関連機能を4〜8週間ほど先に受け取る傾向があります。最新機能を早く使いたい事情があるなら、そこも天秤に入れてください。

手間と効果で並べた優先順位と実行順

7つの施策を、効果の大きさと作業時間で並べます。上から順にやれば無駄がありません。

つまり、最初の20分で一番大きい山を越えられます。ここを試さずに構成を書き直すのは、順番として損です。

「3倍」という数字の中身も明かしておきます。これは1と2と3を同時にやったときに狙える上限の目安で、保証された数値ではありません。実行データが数十GB溜まった環境なら3倍を超えることもあるし、そもそも溜まっていない環境なら1.2倍程度で終わります。自分の環境がどちらかは、次の測り方で判断できます。

速くなったかをどう測る？

体感で判断すると必ず失敗します。数字を3つ取ってください。

実行時間の中央値。 n8nの実行履歴画面で、同じワークフローの所要時間を対処前後で比べます。平均ではなく中央値で見るのは、たまに混ざる異常値に引っ張られないためです。

実行履歴テーブルの行数。 PostgreSQLなら execution_entity テーブルの行数を数えます。自動削除が効いていれば、日を追って頭打ちになるはず。増え続けるなら設定が反映されていません。

同時実行時の完了時間。 5本のワークフローを同時に起動し、最後の1本が終わるまでを計ります。キューモードの効果はここにしか出ません。1本だけ測っても変化は見えないので注意。

セルフホストなら N8N_METRICS を有効化してPrometheus形式の指標を出せます。監視基盤があるなら、キューの待ち行列の長さを継続的に見るのが一番早い。待ち行列が伸び続けているならWorkerが足りない、という判断が即座にできます。

計測の前後で条件を揃えるのも忘れずに。外部APIの応答が遅い時間帯に測ると、自分の改善が埋もれます。

乗り換えを考えるライン

n8nを速くする努力が割に合わなくなる線も、はっきりさせておきます。サーバー管理の担当がいないなら、その線は思ったより手前にあります。

つまり、遅さの原因が「サーバーを面倒見きれないこと」なら、チューニングではなくホスト型への移行が正解です。逆に技術者がいるなら、n8nのセルフホストは実行数あたりのコストで他を圧倒します。

3ツールの比較はZapier・Make・n8nの使い分けに詳しくまとめてあります。n8nとMakeで迷っている段階ならn8nとMakeの比較のほうが直接的です。

AI PICKS編集部の判定

n8nが遅い問題は、9割が設定で片付きます。ここは断言します。

理由は単純で、初期設定が「開発しやすさ優先」だからです。成功した実行の入出力を全部保存する、SQLiteで手軽に立ち上がる、1プロセスで完結する。どれも触りはじめには重宝しますが、本番運用ではそのまま重りになります。設計思想の問題であって、n8nの性能が低いわけではありません。

だから最初の一手は、環境変数の3行です。成功時の保存を止め、自動削除を有効にし、途中保存を切る。これで待ち時間が半分になる環境は珍しくありません。ワークフローを書き直すのは、この後で十分。

一方で、サーバーを見られる人が社内にいないなら話は変わります。PostgreSQLとRedisを足した構成を維持できないチームがセルフホストを選ぶのは、正直イマイチです。その場合はクラウド版の上位プランか、運用ゼロのホスト型に寄せるほうが総コストで勝ちます。

技術者が1人でもいるなら、n8nのセルフホストは一択。実行数が増えても課金が跳ねない構造は、他にほぼありません。

よくある質問（FAQ）

Q. 実行データの保存を止めると、エラー調査ができなくなりませんか？

成功時だけ止めて、失敗時は全部残す設定にすれば問題ありません。調査したいのは落ちた実行なので、成功分のデータはほぼ使われずに容量だけ食っています。開発中のワークフローだけ一時的に保存を戻す、という運用も可能です。

Q. PostgreSQLへの移行で、既存のワークフローは消えますか？

エクスポートとインポートを挟めば残せます。ワークフローと認証情報はJSON形式で書き出せるので、切り替え前に必ず取っておいてください。実行履歴だけは持ち越しが難しいので、捨てる前提で計画するのが現実的です。

Q. キューモードにすると、必ず速くなりますか？

1本のワークフローの実行時間は変わりません。効くのは同時に複数本走らせたときだけです。ワークフローが数本しかない環境で導入しても、Redisの運用負荷が増えるだけになります。

Q. n8nクラウドでも高速化の設定はできますか？

環境変数まわりは触れません。できるのはワークフロー側の改善と、プラン変更による同時実行枠の拡張だけです。設定でどうにかしたいなら、セルフホストへの移行が前提になります。

Q. メモリはどれくらい割り当てればいいですか？

扱うデータ量で決まるため、一律の正解はありません。バイナリデータを扱わないワークフローなら小さくても動きます。画像やPDFを大量に処理するなら、保存先をディスクに逃がしたうえでバッチ分割するほうが、メモリを増やすより安定します。

Q. AIノードを使うと必ず遅くなりますか？

生成AIの応答時間そのものが乗るので、下限は上がります。ただしn8n側のチューニングとは独立した話です。AI部分の速さはモデル選択とプロンプト設計で決まるため、ワークフロー全体の改善とは別枠で考えてください。

Q. n8n 2.0にすると速くなりますか？

バージョンアップだけで劇的に変わるものではありません。ただし2.0以降はタスクランナーによるコード実行の分離が入っており、Codeノードを多用する構成では効きます。まず設定を直し、それでも足りないときにバージョンを検討する順序が無駄になりません。

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

n8nの全体像から確認したいなら、n8nの完全ガイドで機能とライセンスを押さえてから戻ってくると理解が早いです。

• n8n — セルフホストで実行数の上限を気にせず回したいときの本命
• Make — サーバー管理を持ちたくないチームの現実解
• Zapier AI — 連携先の数を最優先するならここ
• Windmill — コード中心で組みたい開発者向けの選択肢
• Dify — AIワークフローに寄せた構成を試すとき
• 業務自動化ツールのランキング — 実行数と料金の関係を横並びで確認
• ノーコードAIツール — 開発者を介さずに組みたい場合の入口
• AI自動化カテゴリ — 周辺ツールをまとめて眺めるとき

画像生成をワークフローに組み込んで重くなっているなら、そもそもの生成側を見直すほうが早いことがあります。AIイラストツールの比較とComfyUIとStable Diffusionの違いは、生成コストと速度のバランスを判断する材料になります。リサーチ工程を自動化に組み込むならFeloの使い方、SNS連携まわりの下調べにはMeta AIのガイドが近道です。

次に読むならこれ: 設定を直しても実行が止まる、エラーで落ちるという症状が残っているなら、高速化ではなく不具合の切り分けが先です。n8nが動かないときの原因と対処を先に片付けてから、この記事の設定に戻ってください。

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

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

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