n8nのWaitノードや承認待ちで「確認してから先へ進む」流れを作る

2つの方法の使い分け

• Slack/メールで承認ボタンを送り、押されたら続ける、向く方法：Send and Wait for Response
• 独自の画面やフォーム、他システムからの呼び出しで再開したい、向く方法：Waitノード(Webhook / フォーム)
• 一定時間だけ置いて続ける、向く方法：Waitノード(時間経過・指定時刻)

Waitノードの公式ドキュメントによると、再開条件は「時間経過」「指定時刻」「Webhook呼び出し」「フォーム送信」の4種類です。Webhook再開では実行ごとに固有のURLが作られ、$execution.resumeUrl で参照できます。この変数をメール本文などに入れて相手に渡す仕組みです。

注意点が2つあります。待機が65秒未満ならデータベースに退避せずプロセス内で続行し、それ以上ならデータベースに保存されて再開時に読み込まれます。また、Webhook再開では、再開URLを送る処理をWaitノードと同じ実行内に置く必要があります。送信ノードだけを単独で再実行すると、URLが変わってしまうためです。

一方、Slackの承認機能のページとSend Emailノードのページには、Response Typeとして承認(Approval)、自由記述(Free Text)、カスタムフォームなどが載っています。以降は、最も単純な「承認/却下ボタン」の構成で進めます。

承認待ちワークフローの構成図

説明用の例として、「AIが下書きした顧客向け返信を、担当者が確認してから送る」流れを置きます。

[トリガー]
   ↓
[AIで返信を下書き]
   ↓
[Slack: Send and Wait for Response]
  (Response Type: Approval / 承認+却下の2ボタン / Limit Wait Time あり)
   ↓
[IF: approved が true か]
   ├─ true  → [返信を送信] → [送信ログを記録]
   └─ false → [Switch/IFで「却下」か「時間切れ」かを判定]
                 ├─ 却下   → [下書きを破棄・理由を記録] → [依頼者に通知]
                 └─ 時間切れ → [上長または別担当に再通知] → [送信はしない]

ポイントは、IFの条件を「approved が true のときだけ進む」にすることです。それ以外はすべて送信しない側に倒れるので、想定外の出力が来ても誤送信になりません。これは公式の仕様ではなく、私の提案する設計方針です。

手順:Slackで承認待ちを作る

1. Slackの認証情報を用意します。公式ドキュメントでは、スコープに users:read と users:read.email が必要で、認証情報に Signature Secret の設定が必要とされています。また、n8nのインスタンスがSlackから公開HTTPSで到達できることも前提です。社内ネットワーク内だけで動かしている場合は、ここで詰まりやすい箇所です。
2. Slackノードで Resource を Message、Operation を Send and Wait for Response にします。
3. Response Type を Approval にし、承認のみか、承認と却下の両方かを選びます。本記事の構成では両方にします。
4. Message に、判断に必要な材料を入れます(下記の例を参照)。
5. Limit Wait Time を設定します。「放置」の扱いを後ろの分岐で決めるために必須です。
6. 後ろにIFノードを置き、承認の判定結果で分岐します。

Slackの公式ページによると、Advanced Interactivity で「誰が応答したかを記録する」「承認できる人を限定する」「権限のない人がクリックしたときのメッセージ」「判断後にボタンを消すか」を設定できます。応答時の出力には approved(true/false)、respondedAt、responder(ID・名前・メールなど)が含まれると記載されています。承認者を限定し、誰が押したかを残しておくと、後で経緯を追えます。

承認依頼メッセージの例(説明用)

【返信案の確認】案件ID: DEMO-0001(架空)
宛先: 株式会社サンプル 御中
返信案: {{ $json.draft }}
確認してほしい点: 金額・納期の記載が元の見積と一致しているか
対応期限: 4時間以内(過ぎると送信せず上長に回します)

承認者が「何を見て、何を基準に、いつまでに」判断するのかを書いておくと、ボタンを押すだけで済みます。

却下・放置時の扱いを決めるメモ

構成図を作る前に、次の表を埋めてください。例の列は説明用の仮の値で、n8nの既定値ではありません。

• 却下されたら何をするか、例(説明用)：下書きを破棄し、依頼者に通知する、あなたの業務の答え：
• 却下理由を残すか、例(説明用)：残す(別途フォームで受ける)、あなたの業務の答え：
• 待つ時間の上限、例(説明用)：4時間、あなたの業務の答え：
• 時間切れのとき送るか、例(説明用)：送らない、あなたの業務の答え：
• 時間切れの通知先、例(説明用)：上長のSlackチャンネル、あなたの業務の答え：
• 再依頼は何回までか、例(説明用)：1回まで、あなたの業務の答え：
• 誰が承認できるか、例(説明用)：担当者2名のみ、あなたの業務の答え：
• 記録する項目、例(説明用)：判断、時刻、押した人、案件ID、あなたの業務の答え：

n8n公式ブログの人による監督に関する記事では、Limit Wait Time を有効にして永久に止まるのを避けること、承認・却下・時間切れの3方向に分けること、社内処理では「送らない」を安全側の既定にすること、判断を時刻と確認者つきで記録することが勧められています。運用承認の目安として4時間、戦略的な判断で24時間という例も挙がっていますが、これはあくまで同記事の目安で、業務ごとに決めるものです。

時間切れの出力は必ず実際に確認する

私が読んだ公式ページでは、Limit Wait Time で時間切れになったとき、approved がどう出力されるか(false になるのか、別の形か)を確認できませんでした。却下と時間切れを1つの false 側にまとめたままだと、通知先を分けられません。

そこで次の手順でテストしてください。

1. Limit Wait Time を1〜2分など短くして、テスト用チャンネルに送ります。
2. 何も押さずに放置し、Slackノードの出力をそのまま確認します。
3. 別の実行で「却下」を押し、出力を見比べます。
4. 差が出ているフィールドを使って、却下と時間切れを分ける条件を作ります。
5. 承認を押す場合も試し、3方向すべてが想定どおり動くのを確認してから本番に切り替えます。

セルフホストの場合の留意点

セルフホストでは、実行データの環境変数に、過去の実行データを自動で削除する設定(既定で有効)があり、経過時間による削除基準の既定は336時間と記載されています。実行データの管理では、この時間は実行完了後から数えられ、new・running・waiting 状態の実行は自動削除の対象外とされています。承認待ちを何日も持たせたい場合は、自分の環境で動作を確かめてください。

最後に確認するチェックリスト

• [ ] 「approved が true のときだけ進む」条件になっている
• [ ] Limit Wait Time を設定し、時間切れの分岐先がある
• [ ] 承認できる人を限定し、誰が押したかを記録している
• [ ] 却下と時間切れでテスト実行し、出力の違いを確認した
• [ ] 送信ノードはWaitと同じ実行内にある(Webhook再開の場合)
• [ ] 依頼メッセージに、案件、確認点、期限を入れた

機密性のある実データでテストする前に、案件IDや宛先を架空の値に置き換えたデータで一度通しておくと安全です。