n8n の AI Agent にツール（メール送信・レコード更新・外部API呼び出しなど）を繋ぐと、エージェントは「必要そうな操作」を自分で選んで実行できる。
便利な一方、不可逆な副作用をプロンプトだけで止めようとすると本番で壊れやすい。
この記事では、n8n 公式の Human-in-the-Loop（HITL）を前提に、本番で止めずに安全に回す設計を初心者向けに整理する。
結論：止めない＝無制限ではなく「待ち方を設計する」
| 設計ポイント | やりがちな失敗 | 本番でやること |
|---|---|---|
| ゲートの場所 | 最終出力だけ人間確認 | 副作用のあるツール呼び出し前に承認を挟む |
| 待ち時間 | 承認待ちを無期限にする | Wait / HITL に 制限時間を付け、タイムアウト後の分岐を決める |
| 拒否時の挙動 | 拒否後にエージェントが黙る／ループする | システムプロンプトで 拒否時の応答方針を明示する |
| 対象ツール | 全部ゲート／全部自動 | 不可逆・対外・高額影響だけゲートし、読み取りは自動のまま |
覚え方：本番の HITL は「人間が全部見る」ではなく、危険なツールだけ機械的に止め、待っても詰まらない運用を先に決めること。
Human-in-the-Loop とは（n8n の意味）
Human-in-the-Loop（HITL）は、自動化の途中で人がレビューし、承認・却下してから次へ進むパターンを指す。
n8n では、AI Agent が特定ツールを使おうとしたときにワークフローを一時停止し、承認チャネル（Slack / Telegram / Chat など）へ依頼を送れる。
- Approve：AI が指定した入力のままツールを実行する
- Deny：ツールは実行されず、拒否がエージェント側に伝わる
公式ドキュメントでは、削除・外部送信・購入など不可逆操作、コンプライアンス要件、ビジネス影響の大きい判断、AI ワークフローへの信頼醸成の段階で HITL が有用だと説明されている。
参考: Human-in-the-loop for tools（n8n Docs）
なぜ「プロンプトで注意する」だけでは足りないか
| 手段 | 何ができるか | 限界 |
|---|---|---|
| システムプロンプト | 「送信前に確認して」と書く | モデルは従わないことがある。強制力がない |
| 最終回答の人手確認 | 文面の品質は見られる | 裏で既にツールが動いていると手遅れ |
| ツール呼び出し前の HITL | 実行そのものを止める | 承認待ち・タイムアウト設計が必要 |
本番で怖いのは「回答が変」より、メールが送られた・レコードが消えた・課金APIが叩かれた側だ。
だからゲートは「会話の最後」ではなく、副作用のあるツールの直前に置く。
n8n での基本セットアップ（ツール単位の人間レビュー）
公式の流れは次のとおり。
- AI Agent の Tools コネクタを開く
- Human review から承認チャネルを選ぶ（Chat / Slack / Discord / Telegram / Teams / Gmail など）
- 承認が必要なツールだけを、そのレビューステップのツール側に接続する
- レビューメッセージに
$tool.name/$tool.parametersを埋め、何を承認するかを明示する
メッセージ例（公式と同趣旨）:
The AI wants to use {{ $tool.name }} with the following parameters:
{{ JSON.stringify($tool.parameters, null, 2) }}
ポイントは「全ツールをゲートする」ことではない。
読み取り専用ツールは自動、書き込み・送信・削除だけゲートにすると、承認疲れを抑えつつ本番リスクを下げられる。
本番で止めないための5つの設計
1. ゲート対象を「副作用」で切る
| ツール種別 | 例 | HITL |
|---|---|---|
| 読み取り | FAQ検索、DB参照、カレンダー確認 | 原則オフ |
| 下書き作成 | 返信ドラフトをシートへ保存 | 任意（初期はオンでも可） |
| 対外送信・状態変更 | メール送信、チケット更新、課金、削除 | オン必須 |
「全部人間確認」は一見安全だが、承認キューが溢れ、結果として人がスキップし始める。
危険な操作だけ機械的に止める方が、長期運用では安全側に寄る。
2. 待ち時間の上限を必ず付ける
承認待ちを無期限にすると、実行が積み上がり、キューが詰まって「止まっているように見える」。
n8n の Wait ノードは、再開条件として時間経過・Webhook・フォーム送信などを持てる。
Webhook 再開では $execution.resumeUrl を使い、制限時間（Limit Wait Time）も設定できる。
HITL でも同様に、何時間待つか／タイムアウト後はどうするかを先に決める。
| タイムアウト後の方針 | 向くケース |
|---|---|
| 安全側で中止（実行しない） | 対外送信・削除・課金 |
| 管理者へエスカレーション | 顧客対応の一次キュー |
| 読み取りのみ続行・書き込みは保留 | 調査系エージェント |
3. 拒否時の振る舞いをシステムプロンプトに書く
公式も、拒否を正しく扱うにはシステムプロンプトへの記載が必要だと警告している。
エージェントは「裏でレビューノードがある」ことを必ずしも理解しないため、次を明示する。
- どのツールが人間承認待ちか
- 拒否されたらツールは実行されないこと
- 拒否後はどう返すか（ユーザーへ理由を伝える／代替案を出す／確認質問に切り替える）
拒否後に同じツールを何度も呼び直すループは、承認者を疲弊させる。
**「拒否されたら別手段を提案し、同じパラメータで再送しない」**を一文入れておく。
4. 承認チャネルと利用者チャネルを分けてよい
公式の重要な注記として、ユーザーとの対話チャネルと承認チャネルは別にできる。
例: 利用者は n8n Chat、承認は特定メンバーの Slack。
本番では「誰が・どのチャネルで・何分以内に」見るかを運用表にしておく。
承認者が休暇のときにタイムアウト→安全中止、が定義されていないと、見かけ上の障害になる。
5. 「提案→承認→実行」の2段に分ける（高リスク操作）
ツール呼び出し直前ゲートでも十分なことが多いが、パラメータが複雑な操作では次の分離が分かりやすい。
エージェント: 実行したい内容を構造化して保存（まだ副作用なし）
→ 人間: ペイロードを見て承認 / 却下 / 修正
→ 別分岐: 承認済みペイロードだけを実行ノードが処理
こうすると、人間が見た内容と実行内容のズレを減らせる。
「Approve したら AI が別パラメータで再計算する」余地を残さないのがコツだ。
最小ワークフロー例（概念）
[Trigger: Chat / Webhook]
→ [AI Agent]
├─ Tool: search_faq （HITLなし）
├─ Tool: draft_reply （任意）
└─ Human review → send_email （HITLあり）
→ [応答をユーザーへ返す]
チェック観点:
[ ] 送信・更新・削除ツールだけが Human review 配下にある
[ ] 承認メッセージに tool名と parameters が出る
[ ] 待ち時間上限とタイムアウト後の分岐がある
[ ] 拒否時の返答方針がシステムプロンプトにある
[ ] 承認者不在時のエスカレーション先が決まっている
実装チェックリスト
- 副作用のあるツール一覧を作り、HITL 対象を文書化した
- AI Agent の Human review に承認チャネルを接続した
-
$tool.name/$tool.parametersで承認文面を具体化した - 待ち時間上限（例: 数時間）とタイムアウト時の安全側動作を設定した
- 拒否時の応答方針をシステムプロンプトに書いた
- 利用者チャネルと承認チャネルの役割分担を決めた
- 承認者不在・連休時の代替承認者を1名以上決めた
- ステージングで Approve / Deny / Timeout の3経路を一度ずつ通した
失敗パターン
パターンA：最終メッセージだけ人手確認 → 対策：副作用ツールの直前に HITL を置く。最終文面確認は別問題。
パターンB：全ツールをゲートして承認疲れ → 対策：読み取りは自動、書き込み・送信だけゲート。
パターンC：待ち時間上限なし → 対策：Limit Wait Time を必須化し、タイムアウトは原則「実行しない」。
パターンD：拒否後の方針が未定義 → 対策：プロンプトに「拒否＝未実行」「再送禁止」「代替提案」を書く。
パターンE：承認文面が「Approve?」だけ → 対策：ツール名とパラメータ JSON を必ず見せる。見えないものは承認できない。
参考リンク
- Human-in-the-loop for tools（n8n Docs）
- AI Agent node（n8n Docs）
- Wait node（n8n Docs）
- Production AI Playbook: Human Oversight（n8n Blog）
- Let AI specify tool parameters with $fromAI()（n8n Docs）
この記事を書いた人✏️@YushiYamamoto
ITPRODX.com代表 / AIアーキテクト
Next.js / TypeScript / n8nを活用した自律型アーキテクチャ設計を専門としています。
日々の自動化の検証結果や、ビジネス側の視点（ROI等）に関するより深い考察は、以下の公式サイトおよびnoteで発信しています。