n8nに人の承認を挟む｜Wait・却下・期限切れ・再開を設計する

n8nへ人の承認を挟むときは、承認する内容の版、判断者、期限、却下時の行き先を一つの記録へまとめます。ボタンを押してもらうことだけでは、変更後の別の内容まで許可したことにはなりません。

承認待ちにする前に、内容を固定する

公開する原稿なら本文と説明、送信するメールなら宛先・件名・本文を確認できる形へまとめます。承認画面を出した後にAIが作り直した内容は、同じ承認で実行しないようにします。

承認記録の設計例
request_id：依頼ID
version：確認する版
reviewer：判断できる担当
expires_at：承認期限
decision：waiting / approved / rejected / expired
result_id：実行後の外部結果ID

表示する要約だけで判断しづらい操作は、実際の対象を確認するリンクや内容の一覧も用意します。

Waitノードでは、時間やWebhookなどの条件を待って再開する構成を作れます。再開URLと認証の扱いはWaitの公式説明を確認してください。

再開リクエストが届いたことだけで、誰が何を承認したかは確定しません。対象ID、版、判断者の権限、期限を照合し、許可済みの処理だけを実行する段階を別に置きます。再開URLは公開記事やログ共有へ貼らないようにします。

判断する人が不在の場合の代行や、確認待ちが積み上がったときの通知先も決めておきます。

承認リンクの再アクセス、遅い応答を見た再クリック、承認直後の停止を試します。同じ依頼を再開しても、外部への送信や投稿が二回にならないかを結果IDで照合します。

まず影響のない試験用対象を一つ選び、却下と期限切れから先に試してください。公開操作へつなぐ場合は、WordPressの下書き登録の後に、確認された版だけを渡す形が出発点になります。