n8nの429エラー対処法のアイキャッチ画像

「n8nのHTTP Requestノードで429エラーが出て、処理が止まってしまった…」と焦っていませんか。原因が分からないまま何度もリトライして、さらに状況が悪化するケースも多いです。

本記事では、n8nで429エラーが発生する仕組みから、原因の切り分け方、そして具体的な設定による解決方法までを、実務目線で解説していきます。読み終える頃には、自分のワークフローのどこを直せばいいかが明確になります。

この記事で分かること

  • n8nで429エラーが起きる仕組みと、OpenAI・Slack・Google SheetsのAPIごとのレート制限の違い
  • Executionsタブやレート制限仕様を使った原因の切り分け方法
  • Retry On Fail・Wait・SplitInBatches・Exponential Backoffによる具体的な解決手順

n8nで429エラーが起きる仕組み

HTTPステータスコードの429は「Too Many Requests」を意味します。これは、API提供元が定めた単位時間あたりのリクエスト数の上限を超えたときに返されるエラーです。n8nのHTTP Requestノードは指定された通りにAPIを呼び出すだけなので、リクエストの送信ペースを制御しないと、簡単にこの上限に達してしまいます。

APIごとにレート制限の考え方は異なります。以下は代表的な3つの例です。

  • OpenAI：利用ティアやモデルごとにRPM（1分あたりのリクエスト数）とTPM（1分あたりのトークン数）の両方で上限が決まっており、どちらか一方でも超えると429になります。無料〜低ティアではRPMが数十件程度に制限されることもあります
  • Slack：呼び出すメソッドごとにTierという段階分けがされており、Tier1のメソッドは1分あたり1リクエストしか送れないなど、非常に厳しい制限がかかるものもあります
  • Google Sheets：1分あたりのリクエスト数（プロジェクト単位・ユーザー単位の両方）に上限があり、これを超えると429が返される仕様です

いずれも具体的な数値はプランやアカウント状況によって変動するため、正確な最新値は公式ドキュメント要確認です。

原因を切り分ける3つのチェックポイント

Executionsタブでのリクエスト頻度確認手順

n8nの管理画面左側メニューからExecutionsタブを開きます。一覧には実行日時とステータス（Success／Error）が並んでいるので、429が発生している実行を開いてみましょう。

実行詳細画面でHTTP Requestノードをクリックすると、右側にInput／Outputが表示されます。Outputに429エラーの詳細が出ていれば、そのノードが何回呼び出されたかを、同じワークフローの実行履歴を数分単位でまとめて見ることで確認できます。短時間（1分以内）に同じAPIへ10件以上のリクエストが飛んでいる場合は、送信頻度そのものが原因である可能性が高いです。トリガーがWebhookなら、外部システムから同時に複数のリクエストが来ていないかも合わせて確認してください。

API提供元のレート制限仕様の確認方法

HTTP RequestノードのOptionsを開き、「Response」欄で「Include Response Headers and Status」をオンにしてください。これでレスポンスヘッダーが出力に含まれるようになります。

再度リクエストを実行し、Outputに含まれるヘッダーを確認します。OpenAIならx-ratelimit-remaining-requestsやx-ratelimit-remaining-tokens、SlackならRetry-Afterというヘッダー名で、残りリクエスト数や再試行までの待機秒数が返ってきます。この値がゼロに近い、またはRetry-Afterが数十秒単位で返っていれば、レート制限に接触していることが確定できます。ヘッダー名や仕様は変更されることがあるため、各APIの公式ドキュメントで最新の項目名を確認してください。

SplitInBatches使用時の並列実行が原因になるケース

SplitInBatchesノード（新バージョンではLoop Over Items）を使っている場合、ワークフロー全体の構成を確認します。SplitInBatchesの後続に接続したHTTP Requestノードを、ループの戻り先（done出力ではなくloop出力）に正しく繋いでいるかをキャンバス上で確認してください。

もし後続ノードをExecute Workflowノードでサブワークフロー化している場合、そのサブワークフロー側でMode設定が「Run Once for All Items」になっていると、バッチ内の複数アイテムが一括で同時送信されてしまいます。この設定を「Run Once for Each Item」に変更すると、アイテムが1件ずつ順番に処理されるようになり、意図しない同時多重リクエストを防げます。

解決する4つの設定方法

「Retry On Fail」の設定手順と入力値目安

HTTP Requestノードをダブルクリックし、右上の三点メニューから「Settings」を開きます。「Retry On Fail」のスイッチをオンにすると、下に「Max Tries」と「Wait Between Tries (ms)」の入力欄が表示されます。

Max Triesには3〜5を入力してください。Wait Between Triesには2000〜5000（2〜5秒）を入力するのが実務上の目安です。バージョンによってはこの欄が5000ms（5秒）を上限としており、それ以上を入力しても自動的に5000に戻される場合があります。設定後は保存し、テスト実行して429がリトライで解消するか確認しましょう。5秒以上の待機が必要な場合は、次に紹介するWaitノードを併用してください。

Waitノードでのリクエスト間隔調整

まずHTTP RequestノードのSettingsで「On Error」を「Continue (using error output)」に変更します。すると、ノードの出力側にSuccess用とError用の2本の接続線が出るようになります。

Error側の出力にWaitノードを新規追加して接続し、Waitノードの「Resume」を「After Time Interval」に設定、待機時間を10〜30秒程度で入力します。Waitノードの出力を、元のHTTP Requestノードの入力側に戻すように接続すれば、429が出た場合だけ待ってから再実行するループが完成します。無限ループを避けるため、Set（Edit Fields）ノードでリトライ回数をカウントする変数を用意し、IFノードで「3回を超えたらループを止めて通知する」という分岐を追加すると安全です。

SplitInBatchesでのバッチサイズ制御

SplitInBatchesノードをダブルクリックし、「Batch Size」の値を確認します。デフォルトは1になっていることが多いですが、他のノードで大きな値に変更されている場合は、1〜5程度まで下げてください。

さらに、SplitInBatchesのloop出力とHTTP Requestノードの間にWaitノードを挟み、待機時間を1〜3秒に設定します。これにより「1件処理して数秒待つ」というペースが作られ、API側の1分あたりの上限に引っかかりにくくなります。API側のRPM上限が分かっている場合は、「60秒 ÷ RPM上限」で1件あたりの最短待機秒数を計算し、それより長めの値をWaitノードに設定するのが確実です。

Code ノードでのExponential Backoff実装

より柔軟に制御したい場合は、Codeノードで指数バックオフ（リトライごとに待機時間を倍にしていく方式）を実装します。HTTP Requestノードの手前にCodeノードを配置し、以下のコードを貼り付けてください。

// Exponential Backoffの待機時間計算例
const maxRetries = 5;
const baseDelayMs = 1000;
const retryCount = $json.retryCount || 0;

if (retryCount >= maxRetries) {
  throw new Error('リトライ回数の上限に達しました');
}

const delayMs = baseDelayMs * Math.pow(2, retryCount);

return { delayMs, retryCount: retryCount + 1 };

このCodeノードの出力（delayMs）を、後続に置いたWaitノードの「Wait Amount」フィールドに{{$json.delayMs}}という式で渡します。Waitノードの後にHTTP Requestノードを接続し、そのノードのOn Errorをこのループの先頭（Codeノード）に戻すように接続すれば、1回目は1秒、2回目は2秒、3回目は4秒…と待機時間が自動的に延びていく仕組みが完成します。retryCountはワークフロー内でSet（Edit Fields）ノードを使って引き継いでください。

未然に防ぐ運用ルール

429エラーは発生後の対処だけでなく、事前の運用ルールでも予防できます。まず、呼び出すAPIの管理画面やダッシュボードで自分のプランのRPM上限を確認し、その8割程度を安全マージンとしてワークフローのバッチサイズと待機時間を逆算して決めておくことが基本です。

複数のワークフローが同じAPIキーを共有している場合は、それぞれの合計リクエスト数が上限を超えないよう、Google スプレッドシートなどにワークフローごとの想定リクエスト数を一覧化して管理する方法が有効です。さらに、Settings画面から「Error Workflow」を設定し、429エラー発生時にSlackやメールへ通知を飛ばす専用ワークフローを1つ作っておくと、問題に早く気づけます。定期的にExecutionsタブでリクエスト頻度を見直す習慣も、再発防止に役立ちます。

よくある質問

Q1. Retry On Failを設定しても429エラーが解消しないのはなぜですか

Wait Between Triesの上限が5000ms程度に固定されているため、APIが要求する待機時間（数十秒単位）に届かず、リトライ中に再度429になることがあります。この場合は、本文で紹介したWaitノードやCodeノードを使った独自のリトライループに切り替えてください。

Q2. SplitInBatchesとRetry On Failはどちらを優先すべきですか

まずSplitInBatchesでリクエストの送信ペースそのものを落とすことが優先です。それでも一時的に429が発生する場合に、Retry On Failを補助的に組み合わせる順序が実務的です。

Q3. Waitノードの待機時間は固定値と動的値のどちらがよいですか

APIがRetry-Afterのようなヘッダーを返す場合は、その値をHTTP Requestノードの出力から取得し、Waitノードに動的に渡す方が無駄な待機や再エラーを減らせます。ヘッダーがない場合は、固定値かExponential Backoffで対応してください。

Q4. 429エラーとタイムアウトエラーは同じ対処法でよいですか

いいえ、原因が異なるため対処法も変わります。429はリクエスト数の超過が原因であり、タイムアウトは応答時間の問題です。それぞれ原因を切り分けたうえで、429にはリトライと間隔調整、タイムアウトにはTimeout設定の見直しで対応してください。

まとめ：429エラーはn8nの設定で防げます

今回は、n8nのHTTP RequestノードでAPIから429エラーが返される仕組みと、その解決方法について解説しました。

原因の切り分けから始め、Retry On FailやWaitノード、SplitInBatchesのバッチサイズ調整、そしてCodeノードによるExponential Backoffまで、状況に応じて組み合わせることで、429エラーは十分に防げます。まずは自分のワークフローのExecutionsタブを確認し、リクエスト頻度から見直してみてください。

参考リンク