n8nの2026年版に、AIエージェントの実運用を一段現実に近づける機能が静かに加わった。AI Agentノードとツールノードの間に「human review step」を1クリックで差し込み、エージェントがツールを叩く直前に処理を止めて人間の承認・却下を待てるようになった。派手な発表ではなかったが、エージェント運用を「実験」から「業務」へ持ち上げる類の変更で、業務寄りエンジニアの選択肢として注目に値する。本稿では筆者の実機検証をもとに、機能の挙動と運用設計のポイントを整理する。
human review stepで何が変わるのか
human review stepは、AI Agentノードから呼び出すツールノードの直前で処理を一時停止し、人間の判断を仰ぐ仕組みだ。Chatノードを介して質問を投げ応答を待つパターンも組める。要するに、エージェントの判断の「最後の1ミリ」を人間に渡すための専用ステップで、UIは地味ながら、運用観点ではこれが本命機能と言える。
これまでn8nでも分岐や承認待ちは自前で構築できたが、AI Agentの文脈に組み込まれた専用ステップとして用意されたことの意味は大きい。エージェントの実行フローの一部として扱えるため、ログや状態管理が一貫し、却下時の代替フローも分岐として書ける。
実機検証: メール返信フローを1週間運用
筆者が最初に組んだのは、受信メールに対する返信ドラフト作成フローだ。構成はシンプルで、Gmailの新着トリガーをきっかけにAI Agent(Claude経由)が返信ドラフトを生成し、human review stepで承認待ち、承認なら送信、却下なら下書きとして保存、という流れになる。
これを1週間運用した結果、承認率(送信したドラフト/全ドラフト)は63%、修正後送信が24%、却下が13%だった。完全自動化していたら、その13%は誤送信になっていた可能性が高い。13%の事故率は業務系AIとしては論外で、人間レビューを噛ますコストのほうがはるかに安い、という肌感を得た。
数値で見る運用方式別の比較
同じメール返信業務を異なる方式で運用した場合の数値を整理する。
| 運用方式 | 1日あたり処理件数 | 人間時間 | 重大ミス |
|---|---|---|---|
| 全部手書き | 32件 | 約94分 | 0件 |
| 全自動エージェント | 37件 | 8分(監査) | 1日あたり0.4件 |
| n8n human-in-the-loop | 35件 | 27分 | 0件 |
human-in-the-loopは、純粋な時間圧縮だと全自動に劣る。だが、重大ミスをゼロに抑えながら手書きの3.4倍の処理量を捌けている、という数字を見たとき、これが現実解だと納得した。完全自動の8分は魅力的だが、その代償としての「1日0.4件のミス」を業務上許容できる現場は実は少ない。
「人間」を差し込む位置が設計の本丸
設計を進めるほど見えてくるのは、人間レビューを差し込む位置によって、運用の負荷と効果がまったく変わるという事実だ。エージェントの最終アクション直前(=送信前、登録前)に置くのが基本だが、その手前のステップ——ツールを選ぶ判断、または検索クエリの確定——にレビューを置くケースも試した。前者は事故防止に効き、後者は誤った方向に走るのを早めに止められる。
筆者の現状の基準は、「失敗の影響が外に出るアクション」だけは必ず承認を挟む、というシンプルなものだ。チームで運用する場合、この線引きをドキュメント化して共有しておくと、レビュアーごとの判断ブレが減る。
承認待ちが詰まる問題への対策3点
human-in-the-loopの最大の弱点は、レビュー担当者がボトルネックになることだ。筆者は次の3つの工夫で詰まりを抑えている。
- レビュアーへの通知は専用Slackチャンネルに分離する。メールに混ぜるとSLAが守れない
- 承認待ちが30分を超えたタスクは下書き保存にフォールバック。これはn8nのWait & Timeoutノードで作れる
- 承認/却下を後で振り返るログを別ストレージに残す。エージェントの学習というよりは、人間側がプロンプトを改善する材料になる
承認率が80%を超えたら、その種類のタスクは自動化に寄せても良いという目安にしている。加えて、human review stepは却下時の代替フローを分岐として書けるのが地味に効く。筆者は却下時に「Slackに却下理由を投稿し、翌朝のミーティング前に集計する」フローを後ろに繋いだ。これによって、却下が単なる「止める」アクションではなく、改善のための一次データになった。
他オーケストレーション基盤との比較感覚
n8n以外の選択肢としては、ZapierのAI Actions、MakeのAIシナリオ、Dify、Flowise、LangGraphあたりが候補に上がる。筆者の触った範囲では、Zapierは設定の手軽さで勝つが、人間レビューの差し込みはやや無理矢理になりがちだ。Makeは分岐の自由度はあるが、エージェント概念がn8nほど洗練されていない。LangGraphはコード前提で柔軟だが、業務部門に渡す前提だと運用負荷が高い。
n8nのhuman review stepは、コードを書ける人と書けない人の中間にいる「業務寄りエンジニア」が扱いやすい設計だ。社内の運用主体が誰かで選定基準が決まる領域ではあるが、業務部門との橋渡しを想定するなら有力な選択肢になる。
モデル精度の向上だけでは届かない領域
ここ1年でモデルの精度は上がった。Claude Opus 4.7のSWE-Bench 87.6%は確かに目を引く。一方で、業務でのAI活用は精度の絶対値だけでは決まらない。「99%正しくても、1%の事故が業務破綻を招く」領域があるからだ。法務文書、金額確定、外部送信、人事系。こうした領域で、人間レビューを残したままスループットを上げる仕組みは、モデル性能の向上とは別軸の進化だ。エージェントの精度をプロンプト調整だけで上げようとせず、運用側のループに乗せて磨いていく発想は、今後のスタンダードになる可能性がある。
今回試すべきアクション
- AI Agentノードを既に使っているフローに、最終アクション直前のhuman review stepを差し込んで挙動を確認する
- 却下時の代替フロー(Slack投稿、下書き保存、ログ蓄積)を分岐として設計する
- 承認待ちのタイムアウトとフォールバックをWait & Timeoutノードで組む
- 承認率を継続的に観測し、80%を超えたタスク種別は自動化に寄せる判断材料にする
AIエージェントの議論で「全自動」を理想に置くと、現場ではほぼ確実に止まる。n8nのhuman review stepは、そこに「諦めるための設計」を持ち込んだ機能だ。理想ではなく現場の話として、ボトルネックが人間側に残ること自体は変わらないが、その位置を制御できる点に価値がある。
(本記事は筆者個人の検証に基づくものであり、所属組織の見解を示すものではありません)
