n8nのHuman-in-the-loopを承認フローとして実務に組み込んで2週間使った。結論から先に書く。「使える場面に絞れば便利。ただし範囲を広げようとすると手動作業が増えて自動化の意味がなくなる」。
この機能を試す前は「自動化にひと手間加えるだけで安全な承認フローが作れる」と期待していた。実際には、2週間で3回タイムアウトを起こし、最初に組んだ6つの承認フローのうち4つを廃止した。残った2つだけが今でも動いている。
この記事では、実際に組んで使ってわかったことを書く。「使える場面」「やめた方がいい場面」「実務で機能させるための設計原則」を具体的に伝える。
この記事でわかること：
- n8n Human-in-the-loopの仕組みと実装方法の整理
- Waitノードの信頼性問題と設計上の注意点
- 「使える場面・やめた方がいい場面」の実体験ベースの判断基準
- 実務で機能させるための設計原則3つ
なお、n8nの基本的な使い方については別途記事を書いているので、そちらも参照してほしい。また、n8nの設定に関する情報はQiitaのn8nタグでも日本語の記事が増えている。日本語の情報がまだ少ないツールなので、実際に使って感じた点を中心に書いていく。
n8n Human-in-the-loopとは何か、先に整理する
「Human-in-the-loop」とは、ワークフローの途中に人間の判断ポイントを挟む設計のことだ。n8nではWaitノードまたはSend and Waitノードを使って実現する。
ワークフローが指定の処理まで進むと一時停止し、Slack・Gmail・Telegram等の通知チャネルに「承認しますか？」という通知を送る。担当者がApprove（承認）またはDeny（却下）のボタンを押すまでワークフローが待機し、その応答に応じて次の処理に進む。
このアプローチは「AIが全部やってしまう完全自動化」と「全部手動でやる」の間の選択肢として位置づけられる。完全自動化はリスクが高い処理に、Human-in-the-loopは「AIに任せたいが最後の確認だけ人間がやりたい」処理に使う。
「ワークフローが途中で止まって人間の判断を待つ」という仕組み
内部的には以下のように動く：
- ワークフローが承認ポイントに到達する
- Waitノードがワークフローを一時停止状態にする
- 指定の通知チャネルにメッセージを送信（「この処理を実行しますか？」）
- 担当者がApproveボタンを押す → ワークフローが再起動して次の処理へ
- Denyまたはタイムアウトになるとワークフローはキャンセルまたは別のルートへ
この仕組みにより、「完全自動実行は怖いけど、毎回手動でやるのも面倒」という中間の運用が可能になる。
n8nには「Waitノード」と「Send and Waitノード」の2種類がある。Waitノードは単純に処理を止めるだけで、別途通知の仕組みを用意する必要がある。Send and Waitノードはその名の通り「通知を送ってから待つ」を1ノードでまとめて行う。実務では後者を使う場面がほとんどだ。
どんな処理に使うべきか——取り消しできないアクションを基準にする
n8n公式でも書かれているが、Human-in-the-loopを使うべき処理の基準は「取り消しができないアクションかどうか」だ。
- 使うべき場面：外部へのメール送信、ブログ記事の公開、顧客データの削除・変更、決済処理
- 使わなくていい場面：データの収集・分析、ログの記録、内部ファイルのコピー・変換
取り消しできる処理にわざわざ承認フローを挟んでも、毎回承認作業が発生するだけで効率が下がる。この判断基準を最初から持っていれば、最初の失敗の半分は防げた。
実際に組んだ承認フローの構成
最初に組んだのは「AI生成のメールを送信する前に内容を確認する」承認フローだ。
構成：
- Webhook受信（メール送信トリガー）
- AI Agentノード（メール本文を生成）
- Send and Waitノード（Slack）（生成した本文を送信して承認を求める）
- IF分岐（承認→メール送信 / 却下→終了）
- Gmail Send（承認された場合のみ送信）
この構成は動いた。AI生成のメールを誤って送信するリスクを防ぎながら、承認作業はSlackで2〜3クリックで済む。
SlackのApprove/Denyボタンで承認するシンプルな構成
Send and Waitノードを使うと、Slackにインタラクティブボタン付きのメッセージが送信される。承認者がSlack上で「Approve」または「Deny」を押すと、その結果がn8nに送り返されてワークフローが再開する。
設定で必要なのは：
- Slackの認証設定（OAuth App必須）
- 承認タイムアウト時間の設定（デフォルトは無制限だが必ず設定すべき）
- タイムアウト時の挙動（キャンセルにするか、デフォルト承認にするかの選択）
Slackのインタラクティブメッセージ機能はn8nが自動的に使ってくれるため、自前でSlack Appを用意してBlock Kitを設定する必要はない。Slackクレデンシャルを設定してSend and Waitノードに紐付けるだけで動く。
実際の通知メッセージには、ワークフローのコンテキスト情報（今回は「送信予定のメール本文」「宛先」「件名」）を含めることが重要だ。情報がないまま「承認しますか？」だけ来ても判断できない。Send and Waitノードのメッセージ欄に、前ノードの出力（メール本文など）を式で動的に挿入する設計にする。
最初にハマったのはWaitノードのタイムアウト設定だった
最初の設定でタイムアウトを「無制限」にしたまま運用したら、土日を挟んで気づかないまま3日間ワークフローが待機状態になっていた。メール送信がそのまま保留になっていて月曜日にクライアントから「メールが来ない」という連絡がきた。
次にタイムアウトを「1時間」に設定したら、今度はランチ中に承認通知が来て気づかなくてタイムアウト。その後は「営業時間中（9〜18時）に来た通知のみ処理する」という追加ロジックを組んだ。
もう一つのはまりどころは、セルフホスト環境でのSlack Webhook問題だ。Send and WaitノードのWebhook URLにランダムなUUIDが追加されてしまい、Slackからの応答が届かなくなるケースがあった（2026年4月時点でコミュニティで報告あり）。クラウド版では発生しなかった問題なので、セルフホストの場合はこの点を注意する必要がある。
2週間使ってわかった「使える場面」と「やめた方がいい場面」
最初に6つの承認フローを組んで2週間使った。最終的に残った2つ、廃止した4つについて書く。
使える場面：外部送信・公開・決済前レビュー
残した承認フロー①：WP記事の自動公開前確認
AIが記事を生成してWordPressの下書きに保存した後、「公開してもいいか確認」の通知をSlackに送る。自分の場合はAI生成記事の品質が一定でないため、必ず目視確認を入れる。これは今でも動いている。
なぜこれが機能するかというと、「公開は取り消しができないアクション（少なくともSEO的には公開済みURLが存在し始める）」という性質がある。かつ、確認の頻度が1日1〜2回程度で、承認ボタンを押すだけなので負担が低い。
残した承認フロー②：外部メール送信前の内容確認
クライアントへの連絡メールをAIが下書きし、送信前にSlack通知で確認する構成。取り消しできないアクション（外部メール送信）なので承認フローが機能している。誤送信を1回防いだ実績があり、投資対効果は明確だった。
防いだ誤送信の内容は「AI生成のメールが宛先名を間違えて「山田様」に送ろうとしていたが、実際の宛先は「田中様」だった」というもの。Slack通知を見た瞬間に気づいてDenyした。この1回だけで承認フローを組んだ価値があった。
やめた方がいい場面：頻度が高い・担当者が承認を忘れる処理
廃止した承認フロー①〜④（共通の理由）：頻度が高すぎた
Slack通知の受信→ファイル保存の確認、ログ取得の確認、内部スプレッドシート更新前の確認、データ分析レポートの送信前確認——これら4つを承認フローで管理しようとした。
結果：1日3〜5回の承認通知が来るようになった。最初の3日は見ていたが、4日目から無視し始めた。タイムアウトが連発し、ワークフローが実行されない日が続いた。
「自動化したはずなのに毎日承認作業がある」という状況は、自動化の効率化効果を完全に打ち消す。頻度が高い処理には承認フローを使わないという判断が正解だった。
4つを廃止した後の反省点として、「そもそもこれらの処理に承認が必要だったのか？」を問い直した。ファイル保存の確認は必要ない（取り消せる）、ログ取得の確認も不要（リードオンリー操作）、内部スプレッドシート更新は元データが残るので取り消し可能、データ分析レポートは内部向けなので誤送信リスクが低い——全部「取り消せる・影響が限定的」だった。
承認フローを組む前に「これは取り消せるか？」と一問自答するだけで、この4つの無駄は防げた。
「承認通知を無視する」という問題の本質
承認通知を無視するようになったのは、怠惰の問題ではない。「通知の重要度が低い」と脳が判断したからだ。
1日に何回も「スプレッドシートを更新していいですか？」という通知が来ても、それは実質「見なくていい通知」になる。Slackの通知は全て同じ見た目なので、重要な承認（外部メール送信）と重要でない承認（内部ログ取得）の区別がつかなくなる。
重要な通知だけに絞る、つまり「承認フローを使う処理を本当に重要なものだけにする」ことが、結果的に全ての承認を確認できる状態につながる。
Waitノードとv2.0での信頼性改善について整理する
v1でのWaitノードバグ——サブワークフロー連携で発生した問題
n8n v1系では、サブワークフロー内でWaitノードを使うと、子ワークフローの待機中に親ワークフローが誤って先に進んでしまうバグがあった。承認を待っているはずの処理が承認なしに進んでしまうというもので、Human-in-the-loopの意味がなくなる深刻な問題だった。
nocodecreative.ioの技術ブログでもこの問題が詳しく記録されており、v1時代のWaitノードのサブワークフロー連携は信頼できないとされていた。
v2.0での修正内容
n8n v2.0でこのバグは修正された。サブワークフローとWaitノードの組み合わせが安全に使えるようになった。
現在使っているn8n（v2.x系）ではこの問題は発生していない。ただし、以前からv1で組んでいたワークフローをそのまま移行した場合は、動作確認を改めて実施することを推奨する。
セルフホストでのSlack問題（2026年4月現在）
一方で現在も残っている問題がある。セルフホスト環境でSend and Waitノードを使うと、SlackのWebhook URLにランダムなUUIDが追加されてしまい、Slackからの承認応答がn8nに届かないケースが報告されている。
クラウド版n8nでは発生しない（n8n側でWebhook URLが固定管理されるため）。セルフホスト環境で使う場合は、設定後に必ず実際にSlackから承認ボタンを押してワークフローが再開するか確認するテストを行うこと。
Human-in-the-loopを実務で機能させるための3つの設計原則
2週間の試行錯誤から導いた設計原則をまとめる。
原則1：取り消しできないアクションだけに使う
データの収集・変換・内部処理には使わない。「外部送信・公開・削除・決済」という4種類のアクションだけに限定する。これだけで承認フローの数を適切な水準に保てる。
具体的には：外部メール送信（Gmail・Outlook経由）、SNS投稿（X・LinkedIn等）、ブログ記事の公開（WordPress）、顧客データの削除・変更、決済API呼び出し、外部SaaS（HubSpotなど）へのデータ書き込み——これらが対象になる。
原則2：1日の承認回数が3回以内になるように設計する
それを超えると確認疲れが起きて通知を無視し始める。週5〜10回程度なら問題なく機能する。毎日・複数回の処理には別の安全弁（ログ記録・ロールバック機能）を使う方がいい。
フリーランスやソロワーカーの場合、承認担当者は自分1人であることが多い。1日3回を超えると、仕事の邪魔になって通知を切りたくなる。このラインを守るために、承認フローを追加したい場合は「既存のどれかを廃止できないか」を先に考える。
原則3：タイムアウトと「承認なし時の挙動」を必ず設定する
タイムアウトなしで運用すると、見落とした通知がいつまでも待機し続ける。タイムアウトは「通常の業務時間 × 2」程度（例：8時間稼働なら16時間）が現実的だ。タイムアウト時の挙動は「安全側（キャンセル）」に設定しておく。
タイムアウト後の処理として以下を設定しておくと安心だ：
- タイムアウトフラグをSlackに通知（「承認待ちワークフローがタイムアウトしました」という別通知を送る）
- ワークフロー実行ログにエラーを記録（後で確認できるようにする）
- 処理はキャンセル扱い（デフォルト承認よりキャンセルの方が安全側）
営業時間外のトリガーには承認フローを使わないか、「翌営業日9時に再トリガー」する設計を組み合わせるとタイムアウト問題を減らせる。
参考設定例：メール送信前承認フローの実際の設定値
- タイムアウト：8時間
- タイムアウト後の挙動：キャンセル + Slack別通知
- メッセージ内容：件名・宛先・本文全文
- 承認担当者：自分のSlack DM（1人運用のため）
- 稼働時間フィルター：9〜18時のトリガーのみ承認フローを通す（それ以外は翌9時まで待機）
この設定で2週間、タイムアウトは0回になった。
まとめ：「人間が判断すべきポイント」を明確にして使うと価値がある
Human-in-the-loopは、使い方を絞れば確かに便利だった。AI生成コンテンツの公開前確認・外部メールの誤送信防止という2つの用途では今でも動き続けている。
ただ「とりあえず全部承認フローにすれば安全」という発想で組み始めると、毎日確認作業が発生して自動化の効率化効果が消える。
実務での教訓を一言でまとめると、「取り消しできないアクションかつ1日3回以内」という条件を満たす処理だけに使うこと。それ以外は別の安全設計（ログ記録・ロールバック）で対処する方が現実的だ。
Waitノードの信頼性はv2.0で大幅に改善された。ただしセルフホスト環境でのSlack Webhook問題は2026年4月時点でも報告があるため、セルフホストで組む場合は動作確認を念入りにやること。
承認フローを設計する際の最後のチェックとして：「この通知が毎日来ても確認を続けられるか？」と自問してみる。答えが「たぶん無視する」なら、承認フローを使うべき処理ではない。
n8n Human-in-the-loopと他ツールの承認フロー比較
ZapierやMakeと何が違うか
n8n以外のノーコード自動化ツールにも承認フロー機能はある。Zapierにも「Approval step」（Paths機能）があり、Makeにも同様のルーティングが可能だ。比較すると以下のような差がある：
- n8n（Send and Waitノード）：Slackのインタラクティブボタンが使える。無料プラン（セルフホスト）でも利用可能。カスタマイズの自由度が高い
- Zapier（Paths + Filter）：承認ボタンのUIは持たない。メールリンクで代替する形になり、UXが劣る
- Make（Router + Stop）：Routerで分岐はできるが、承認待ち（ワークフローを一時停止して再開）はネイティブには対応していない
日本のノーコードコミュニティでも、Zennなどでn8nとMakeの機能比較を扱った記事が増えている。承認フローという観点では、n8nのSend and Waitノードはかなり実用的なレベルにある。
企業の承認フローに使う場合の注意点
個人・フリーランスの運用とは別に、チームや企業で使う場合にはいくつか考慮点がある。
まず、承認担当者が複数いる場合の設計だ。Send and Waitノードは1人の承認者にメッセージを送る設計が基本で、「AさんまたはBさんが承認すれば通過」のような柔軟な承認ルーティングを実現するには追加ロジックが必要になる。Slackのチャンネル通知で複数人に見せて最初に押した人の応答を採用する、という設計は可能だ。
次に、監査ログの問題がある。誰がいつ承認したかの記録はn8nのワークフロー実行履歴に残るが、標準のUIで見やすいわけではない。承認記録を別途Notionや Googleスプレッドシートに書き出す処理を承認後に追加しておくと、後から確認しやすい。
合わせて読みたい
- n8n AI Agentノードを自腹で試した：LLMと繋ぐだけで何ができて何ができないか正直に書く
- n8nの使い方入門：ワークフローの基本をゼロから理解する
コメント