n8nのWaitは、始まったワークフローを途中で待たせるノードです。一定時間ならAfter Time Interval、日時まで保留するならAt Specified Time、外部からの通知ならOn Webhook Callを選びます。
外部通知で再開させる場合は、その実行の再開URLと認証を使い、受信後に業務ID・段階・期限・未処理状態を照合する流れです。特に、期限で自動再開したことを、承認と扱わない設計が欠かせません。
この記事では、Waitの方式選択から、時間設定、外部再開、再開後の入力確認、停止と再実行までを整理します。導入済みのn8nで対象ワークフローを編集・試験実行でき、必要な実行状態を確認できることが前提です。
n8n自体で何ができるか、導入後にどのような管理が必要かを先に整理したい場合は、次の記事が役立ちます。Waitの設定に進む前に、サービス連携の用途と運用の負担を確認できる内容です。
PR：この記事にはアフィリエイト広告が含まれます。n8nとは、開始条件と処理を「ノード」でつなぎ、サービス間の繰り返し作業を自動化する道具です。ブログ運営なら、情報の転記、原稿の保存、確認担当者への通知などを一つの流れにまと[…]
Waitは「実行の途中で何を待つか」で選ぶ
待ち時間の長さを決める前に、何が起きたら続けるかを選んでください。外部からの合図が不要な処理なら、再開用のWebhook入口を増やさず、時間待ちで組み立てられます。
| したいこと | 選ぶ方式・機能 | 入力と続行条件 | 追加の確認 |
|---|---|---|---|
| 二つの読取りの間を5秒空ける | Wait：After Time Interval | 時間の量と単位。経過後に続行 | 単位、前後の時刻、同じ実行か |
| 始まった処理を特定日時まで保留する | Wait：At Specified Time | 日時。指定の瞬間まで待機 | 時差、UTCとの対応、使用版での保存値 |
| 外部ジョブの通知を受けて続ける | Wait：On Webhook Call | 実行ごとの再開URL。HTTP要求を受信 | 認証、入力内容、期限、既処理か |
| フォームの回答を受けて続ける | Wait：On Form Submitted | フォーム項目と回答。送信を受信 | 必須項目、回答の意味、期限後の行き先 |
| 毎朝決まった時刻に新しく始める | Schedule Trigger | 開始スケジュール | Waitで途中保留する課題と区別 |
| 何件ずつ処理して繰り返すか決める | Loop Over Items | 処理単位、戻り先、終了先 | 待機を置く位置と反復回数 |
| 受け取った値で進路を分ける | IF・Switch・Filter | 判定条件と対象の値 | 再開させるWaitとは役割が別 |
フォーム待ちは、人が回答する画面を用意したい場合の候補です。フォームの見た目や全項目の設計まで必要ない外部システム間の通知なら、On Webhook Callと入力契約を中心に考えましょう。
「APIを1件呼ぶごとに待たせたい」という場合は、Waitを置く場所と反復の単位を一緒に決める必要があります。Wait一つを追加するだけで全item間に一定の間隔が付くわけではないため、バッチの戻り先・終了条件はLoop Over Items側で整理してください。
配列をitemsへ展開したり、まとめ直したりする操作もWaitの担当ではありません。開始・反復・待機・条件判定を先に分けると、直すべき場所を選ぶ助けになるでしょう。
時間待ちは量・単位・日時の対応をそろえる
時間待ちには、「今から何秒」と「この日時まで」の二つがあります。同じ待機でも設定の意味が違うので、最初は短い相対待機で、前後のデータと時刻を確かめると進めやすい手順です。
After Time Intervalは短い無害な例から試す
最初に試す、5秒待機の最小例
例えば、二つの確認処理の間を5秒空ける説明用のフローなら、ResumeでAfter Time Intervalを選び、Wait Amountを5、Wait UnitをSecondsにします。これは未実行の設定例であり、実際に5秒後の処理成功を確認した記録ではありません。
この例の接続順は、検証用の入力→Wait→項目や結果ラベルの確認です。
- 同じ入力を前後で追えるようにする
検証用の業務IDなどを用意し、Wait前の実行ID・入力・時刻を控えましょう。後続にはメール送信や投稿を置かず、項目確認や結果ラベルの付与だけを接続します。
- 量と単位を別々に確認する
5 Secondsと5 Minutesは、同じ数値でも長さの異なる待機です。設定欄を確認し、最初は短時間で終わる試験にしてください。
- 再開後の入力と結果を照合する
同じ業務IDと実行の流れで続いたか、前後の時刻に想定した間隔があるかを見ましょう。待機が終わった時刻と、外部処理まで完了する時刻は分けて記録するのが要点です。
At Specified Timeは時差を含めて確かめる
指定日時まで待つ場合は、日時の文字列がどの瞬間を指すかを明確にします。次は、時差を含むISO日時とUTCの対応を示す未実行の説明例です。
2030-01-01T12:00:00+09:00= 2030-01-01T03:00:00Z二つは同じ瞬間を表しています。実際の予約値ではないので、この未来日時をそのまま試験へ入れるのではなく、検証に適した近い時刻へ置き換えましょう。
Waitの公式Docsはサーバー時刻を使い、ワークフローのタイムゾーン変更はWaitに影響しないと説明する一方、今回確認した公式masterの実装は、指定日時をワークフローのタイムゾーンを渡して解析してからUTCへ変換しています。masterは導入済みの特定版そのものではないため、時差を含まない文字列の解釈を全版共通とは決めつけられません。
使用中の本体版・Waitノード版で、時差付き日時が保存時にも保たれるか、期待するUTCと再開時刻が対応するかを確認してください。サーバー時計、不正な日時、過去日時も別の試験にし、タイムゾーン設定を変えるだけで必ず直るとは考えないことが大切です。
相対待機は現在時刻へ経過時間を足す処理なので、絶対日時の解釈とは分けて扱います。どちらの場合も、指定した瞬間にメール送信などの後続処理まで完了する保証ではありません。
Limit Wait Timeと全体のTimeoutを分ける
外部通知やフォームをいつまでも待たないようにする設定が、Limit Wait Timeです。オンにすると、設定した上限で実行が自動再開されます。
対して、ワークフロー設定のTimeout Workflowは、一定時間が経過したら実行を取り消すための設定です。Cloudではプランごとに利用できる最大timeoutの条件があるため、Waitの上限と同じ機能として扱わないでください。
長く待たせる場合は保存状態、実行を動かすプロセス、呼出先への到達性、期限後の扱いも管理する必要があります。「全体timeoutを伸ばせば解決」「何日でも同じ条件で待てる」と決めず、契約・使用版・運用条件をそろえて判断しましょう。
外部再開は同じ実行のURLと認証を使う
On Webhook Callは、新しい実行を始めるWebhookトリガーとは異なり、待っている既存実行を続ける入口です。固定のWebhook URLをコピーする手順と混ぜず、その実行の$execution.resumeUrlを使います。
再開URLはWaitと同じ実行で渡す
再開URLは実行時に生成されるため、Waitへ入る前に、同じ実行の$execution.resumeUrlを必要な呼出者へ渡す設計が必要です。部分実行で別に作ったURLを、あとから本番の待機へ使い回さないようにしましょう。
このURLは実行ごとに固有ですが、一つの実行に複数のWaitがあると、呼出しによって順番に各Waitを再開できる性質もあります。したがって「各ステップで一度しか使えないURLだから、古い通知を考えなくてよい」という前提にはできません。
メソッド・認証・応答を決めてからつなぐ
主例は、検証用Credentialを使ったPOSTとHeader Authです。呼出側の対応に応じてBasic AuthやJWT Authも選べますが、認証なしのNoneを通常の推奨にはしません。
- ResumeとHTTP Methodを合わせる
WaitでOn Webhook Callを選び、呼出側と同じメソッドへそろえます。JSONを受け取る主例ではPOSTを選び、形式と項目は後述の入力契約で決めておきましょう。
- AuthenticationとCredentialをそろえる
Header Authを選び、呼出側の設定も一致させてください。秘密をURLのクエリや公開可能な本文へ直書きしない形にします。
- 応答のタイミングと返す内容を決める
受付直後に返すか後続の終了後に返すかを、呼出側の要件と合わせましょう。返す本文は必要最小限にし、認証値や受信入力全体をそのまま返す構成は避けてください。
- 後続をラベル付けだけにして試す
同じ実行で渡したURLを使い、正しい認証と不正な認証を別々に確かめます。認証が通った後も、対象の業務や段階を進めてよいかは別判定です。
HTTPの成功応答は、受付または再開の一段階を示すにとどまります。外部ジョブの成功、正しい承認入力、後続処理の完了までを同時に証明するものではないので、実行結果と業務状態を分けて確認しましょう。
複数のWaitでは段階とURLのパスも確認する
Webhook Suffixは、複数のWaitで再開先のパスを区別するための補助になります。ただし、suffixが$execution.resumeUrlへ自動的に含まれるとは仮定せず、相手に渡すURLを明示的に構成してください。
署名などのクエリが付くURLでは、suffixはクエリより前のパスへ入れる必要があります。文字列の一番後ろに何でも付ける方法では壊れる場合があるため、実際のパスとクエリを保てる方法で確認しましょう。
suffixを分けても、古い段階の要求や重複要求を防ぐ業務判定が自動で完成するわけではありません。どの実行のどの段階かを入力と元状態で照合し、二つ目のWaitを旧通知で通過しないかも独立した試験にします。
到達しないときはURL・状態・認証を順に見る
再開しない場合は、正しい実行が待機中かを先に確かめましょう。次に、別の部分実行で得たURLではないか、scheme・host・pathが合うか、メソッド・認証・期限が一致するかを調べます。
セルフホストでは、外部公開URLやプロキシを経由して検証元から到達できることも必要です。認証を切ったりIP制限を解除したりする前に、どの段階で届かないかを分けてください。
Ignore BotsやIPの許可リストは補助策であり、認証と業務入力の検証の代わりにはなりません。新規Webhookの入口やCredentialsの管理を分け、再開先の問題と共通設定の問題を切り分けましょう。
再開した後に、入力・期限・未処理状態を判定する
Waitを抜けた後は、外部の書込みや送信の前に、進めてよい条件を明示します。再開の原因が正しい通知なのか、待機期限なのかを区別しないと、何も承認されていないのに後続へ進む構成になり得るためです。
期限到達を承認にしない条件にする
Limit Wait Timeを20分にした場合、通知がなくても上限で自動再開します。20分はあくまで説明用の値なので、業務に適した期限を別に決めてください。
避けたい判定
decision != rejectだけで許可する。
明示的な否認でない空値まで通るおそれがあるため、期限到達や入力欠落を除外できたことになりません。
条件を明示する設計
decisionが文字列のapproveに一致し、ID・段階・期限・未処理状態もすべて正常な場合だけ、後続候補へ進める。
どれか不明なら、期限切れや不正入力の安全な終了先へ分けます。
これは条件の考え方を示す未実行例です。IFなどの設定欄へ入れる具体的な式は、実際の入力型と出力の階層を確認してから作ってください。
受信入力と元の業務情報を別々に照合する
例えば、次のようなJSONを外部から送る入力契約を決めたとします。実在の通知ではなく、受信する項目を示す仮例です。
{ "job_id": "job_demo_01", "step": "review", "decision": "approve"}| 照合するもの | 元情報の例 | 確認する意味 |
|---|---|---|
| 業務ID | job_id=job_demo_01 | 別の仕事の通知ではないか |
| 段階 | step=review | 現在待っている工程への要求か |
| 判断 | decisionは文字列で許可された値 | 空値・型違い・未知の値を許可にしない |
| 期限 | 元のdeadline | 再開しても業務の有効期限内か |
| 処理状態 | current_state=pending | 完了済みや取消済みを再処理しない |
| 要求の検証状態 | 必要に応じてnonce等を検証した結果 | 同じ段階への古い要求の再利用を見逃さない |
受信したbody.job_idをそのまま元のIDへ上書きして一致させると、照合の意味がなくなります。待機前の必要情報は、対応する元入力や記録から明示的に参照しましょう。
再開後の$jsonが待機前と同じ形・同じ項目であるとは仮定できません。実際のbodyの位置、型、期限到達時の出力を検証し、認証と業務内容の承認を分けて判定してください。
重複・否認・期限切れの行き先を先に決める
正常通知以外の経路も、外部処理を接続する前に決めておきましょう。検証中は次のようなラベルを付けるだけなら、誤判定をメール送信や投稿の実害へつなげず確認できます。
| 受け取った状態 | 仮の結果ラベル | 次の行動 |
|---|---|---|
| 全条件が正常で明示許可 | approved | 検証中はラベル確認。本番接続は別途の重複対策も確認 |
| 明示的な否認 | rejected | 外部作用へ通さず、要件に沿って終了 |
| 期限超過または通知なしで期限到達 | expired | 要確認・期限切れの経路へ。承認扱いにしない |
| 欠落・型違い・IDや段階の不一致 | invalid | 安全な終了先へ分け、入力契約と参照先を修正 |
| 処理済みの業務への要求 | already_processed | 再処理せず、元状態と外部成果を照合 |
ただし、WaitとIFだけで同時要求や二重書込みが消えるわけではありません。未処理かを読んだ直後に別の要求も通る競合などは、下流サービスの冪等キーや、保存先で状態を一度だけ更新する原子的な処理を別途設計する必要があります。
「冪等」とは、同じ要求を繰り返しても外部の結果を重複して作らない性質のことです。単なる重複行の整理とは異なるので、通知の再送や再実行も含めて接続先と照合しましょう。
否認を必ずエラーにする必要はありません。状態を残して正常終了させるか、Stop And Errorで明示的な失敗にするかは、監視や業務要件に合わせて決めてください。
Waitの再開・停止と、外部ジョブ自体の取消しも別操作です。外部処理を取り消す必要があるなら、提供先のAPIや権限を確認する工程を分けます。
小さなテストで再開・停止・再実行を確かめる
最初の試験は一つのWaitと無害な後続処理に絞り、待機前・再開直後・後続結果の三段階を記録しましょう。Waiting表示から消えたことだけで、意図した仕事が完了したとは判定しないでください。
正常だけでなく、進めないケースも試す
短い相対待機はRunningのまま進む場合もあるため、表示名一つより実行IDと前後の記録が重要です。次の表は期待する挙動を決めるための未実行の試験例で、成功結果ではありません。
| 試験 | 変える条件 | 期待する確認 |
|---|---|---|
| 短い相対待機 | 5 Seconds、検証用業務ID | 同じ実行の前後を照合。経過後にラベル確認まで進む |
| 指定日時 | 時差付き日時と期待UTC | 使用版の保存値と再開時刻が意図した瞬間に対応 |
| 正しい外部通知 | 認証・ID・段階・許可・期限・未処理が正常 | approved候補へ分かれる |
| 不正な認証 | 認証だけ不一致 | 要求を受け付けず、後続の外部作用へ進まない |
| 欠落・型違い・否認 | 一項目ずつ変更 | invalidまたはrejectedへ分岐 |
| 通知なしで期限到達 | 説明例では20分 | 自動再開後もexpiredや要確認へ |
| 重複・古い段階・処理済み | 同じ業務を再通知 | 再処理を許可しない経路と下流の重複対策を確認 |
| 部分実行・複数Wait | URL生成の実行範囲や段階を分ける | 正しい実行・Waitだけが再開し、旧通知で次段階を通さない |
- 実行ID、元の業務ID、段階、期待する再開条件を記録したか
- 設定した期間・日時、前後の時刻、受信項目の名前と型を照合したか
- 正常・否認・期限・欠落・重複が期待した経路へ分かれたか
- 共有記録から再開URL本体、認証値、不要な個人情報を除いたか
期待から外れたら、外部作用をつながず、入力・時刻・URL・認証・期限のうち該当する一つを直して再試験してください。複数の設定を同時に変えるより、直した条件と結果を対応させやすくなります。
新規開始と、すでに待っている実行を分けて止める
誤設定を戻すときは、ワークフローの設定復元だけで終わらせず、すでに始まった実行と外部の業務状態の確認も必要です。新しい実行を生む入口の停止と、既存実行の停止を別々に進めます。
- 新しい実行を生むトリガーや呼出元を止める。
- 対象の実行IDを特定し、使用版でのStop・Cancel等の操作と待機中の挙動を確かめて停止する。
- 元の業務状態を取消・要確認などへ整理し、後続が進まないことを確かめる。
- 保存しておいたフローやWait設定へ戻し、無害な検証で確認する。
非公開化や無効化だけで、すでにWaitingのすべての実行が消えたとは扱わないでください。使用版の停止操作を確認し、データベースの直接削除を通常の戻し方にはしません。
再開URLの漏えいが疑われる場合は、該当実行の停止と業務状態を確認し、必要な認証情報の失効・交換も影響先と合わせて判断します。フローを複製しただけで古いURLが無効になった、という前提も置かないようにしましょう。
すでに送ったメールや公開した投稿は、Wait設定を戻しても巻き戻りません。外部の完了結果と取消方法は、接続先で別に確認してください。
Retryと最初からの再実行を区別する
失敗実行のRetryは、トリガーから同じフローをすべてやり直す操作とは異なります。保存された実行状態を使い、完了済みノードの結果を残して失敗ノードへ入力を渡す方式です。
ただし、失敗したノードが複数itemの途中まで送信していた場合、そのノード内で処理済みのitemも再処理され得ます。再試行前に外部成果を照合し、対象サービスの重複対策を確認してください。
Retryは新しい実行となるため、過去の再開URLをそのまま推定して使うことも避けましょう。新たにWaitへ到達する場合は、その実行で生成・共有するURLと段階を確認する流れです。
実行記録をエディターへコピーして最初から動かす方法は、後続の送信なども再度動く可能性があります。結果が不明なまま「もう一度実行」を選ぶより、どのノードがどこまで外部へ作用したかを先に確かめることが重要です。
まとめ｜待つ条件と再開後の判定をそろえる
n8nのWaitは、経過時間・指定日時・外部通知・フォーム回答から、実行途中で待つ条件を選びます。外部再開は同じ実行のURLと認証を使い、受信後に業務ID・段階・入力型・期限・未処理状態を照合する設計です。
Limit Wait Timeによる自動再開は承認や外部ジョブの取消しを意味しません。まず一つのWaitと結果ラベルだけの検証を作り、正常・期限切れ・不正入力・重複が期待した経路へ分かれるかを、実行IDと照らして確認しましょう。
待つ時間を決める前に、「何を受け取ったら進めるか」「進めないときはどこへ終えるか」をそろえるほうが、誤った再開を見つけやすくなります。時刻やURLだけで完了とせず、再開後のデータと業務状態まで見る運用を優先したいところです。