AI自動化で人の確認を挟む設計はどう作る？

AI自動化では、すべてを無人化するより「どこだけ人が確認すべきか」を先に決めた方が安全に広げやすくなります。

Human-in-the-loopは、AIの前後すべてを手作業に戻すことではありません。誤実行の影響が大きいpointだけワークフローをpauseし、人のapprove / rejectで次へ進める設計です。

先に結論：最小構成で見る4点

人の確認は、誤実行の影響が大きいActionの直前に置きます。承認者には元入力・提案・変更対象・リスクをまとめ、Approve / Edit / Rejectを別々の結果として記録します。後半では期限切れ・対象更新・二重回答まで設計します。

最小構成を作る

まず人の確認が必要なActionを洗い出す

外部メール送信、契約・価格変更、削除、公開、決済、顧客データ更新など、間違えたときに戻しにくいアクションを挙げます。

「AI判断」と「実行」を分離する

AIには分類・要約・下書き作成まで任せ、実際のsend / update / deleteは別ステップにします。

この分離だけでも、人が確認を挟む場所が明確になります。

Approval画面には判断材料をまとめる

Approveボタンだけでなく、元入力、AIの提案、変更予定内容、対象レコード、リスク情報を見せます。

人が元systemまで探しに行かなくても判断できる形にします。

Approve / Reject / Editを分ける

承認だけではなく、「却下」「修正して実行」「人が処理」などのルートを用意します。

運用条件を詰める

Timeout時の処理を決める

承認されないまま止まり続けるワークフローを防ぐため、一定時間後にexpire、remind、escalateするruleを決めます。

PlatformのApproval機能を使う

n8nではGmail ノードにSend and Wait for Approvalがあり、simple approval processでワークフローを一時停止できます。より複雑な承認ではWait ノードの利用が案内されています。

またAI Agentのツール call前にhuman 確認を挟む仕組みもn8n Docsで案内されています。

低Risk処理は自動承認へ寄せる

すべてを人へ返すと自動化の意味が薄れます。confidence、金額、顧客種別などでthresholdを決め、低リスクだけ自動通過させる方法があります。

Approval結果を改善材料にする

何がapprove / rejectされたかを残し、プロンプト、rule、thresholdの改善に使います。

どのActionで止めるかをリスクで決める

Human-in-the-loopを入れる場所は、AIが文章を生成するたびではなく、誤った場合の影響と後から戻せるかで選びます。影響が小さく取り消せる分類や下書き作成は自動で進め、顧客への送信、公開、削除、金額変更などは実行直前に止めるのが基本です。「confidenceが高いから承認不要」と短絡せず、金額・顧客区分・対象件数など、業務上確認できる条件を組み合わせます。

表は横にスクロールできます

Action	影響 / 可逆性	推奨する確認
社内タグ付け	低〜中、戻せる	少量で誤分類を測り、閾値外だけ確認
CRMの担当候補表示	中、未確定	候補と根拠を提示し、確定は人が行う
顧客への返信送信	高、取り消しにくい	下書き、宛先、引用元、送信内容を全件確認
レコード削除・契約変更	高、復旧困難	対象ID・変更差分を表示し、明示承認を必須にする
複数顧客への一括実行	高、影響範囲が広い	件数上限、サンプル確認、実行責任者を追加

Approval requestに必要な情報

承認者に「Approve」だけを見せても、判断できるとは限りません。元の依頼、AIが抽出した事実、AIの提案、実行される変更、対象レコード、実行後に戻せるか、期限、拒否時の担当先を同じ画面にまとめます。大きな入力をそのまま転送するのではなく、判断に必要な範囲だけを見せ、原文へ戻れる権限付きリンクを使います。

例示用の承認request:

request_id: approval_2026_001

action: send_customer_reply

target_id: case_123

source_summary: 納期の確認依頼

proposed_change:

recipient: 登録済み顧客

subject: 納期について

body_preview: 確認中のため回答予定日を案内する下書き

evidence_refs: case_123, order_456

risk: external_message

expires_at: 業務側で定めた期限

decision: approve | edit | reject

これは例示用のデータ形であり、実在するサービスや顧客の情報ではありません。実装では宛先や個人情報を通知本文に埋め込まず、承認者の認証、リンクの有効期限、監査ログを別に設計してください。承認リンクを転送できる形にすると、意図しない人が実行できる恐れがあります。

承認後も「実行前チェック」を残す

人が承認した後に元データが変わることがあります。承認対象のversion、record ID、提案内容のhash、承認者、時刻を記録し、実行直前に対象が同じか確かめます。内容が変わっていれば古い承認を流用せず、再承認へ戻します。二重クリックやWebhook再送もあるため、approval request IDを一意に扱い、同じ承認からActionを一度だけ実行する設計が必要です。

表は横にスクロールできます

結果	状態遷移	次の処理
Approve	APPROVED	version一致を検証してActionを一度実行
Edit	NEEDS_REVISION	修正後の差分を再提示
Reject	REJECTED	Actionせず、理由と担当先を記録
期限切れ	EXPIRED	自動実行せず再申請または手動処理
対象更新	STALE_APPROVAL	旧承認を無効化し新しい内容を提示
通知失敗	PENDING_NOTIFICATION	承認済みとみなさず、通知経路を確認

Timeoutと滞留を運用できる形にする

承認待ちを無期限に残すと、古い提案が後日実行される危険があります。期限、reminder、escalation、expire後の扱いを業務側で決めます。返信がない場合に「承認」と扱うのは避け、期限切れは停止を既定にします。承認者の休暇や担当変更も想定し、代行者と最終判断者を明確にしてください。

n8nでは、Gmailの「Send and Wait for Approval」は簡単な承認に使え、より複雑な待機にはWait nodeが案内されています。またAI Agentのtool call単位で人の承認を要求する機能もあります。どのchannel・機能が利用可能かは、導入中のn8n版とcredential設定で実画面を確認してください。記事では機能の存在を説明していますが、特定環境での動作確認はしていません。

小さく測って自動化範囲を広げる

最初のpilotでは、全処理件数、承認待ち時間、編集・拒否・期限切れの割合、承認後の取消件数、誤送信などの事故を記録します。目的は承認率を上げることではなく、どの種類のActionが人の判断を必要とするかを見つけることです。低リスクの定型処理だけを自動通過させる場合も、どのデータで境界を決めたか、誤判定時に戻す方法、誰が閾値を変更できるかを残します。

承認権限と監査記録

承認できる人とworkflowを変更できる人を分けると、提案した本人だけで承認が完結する状態を避けやすくなります。権限は必要最小限にし、approve・reject・editの操作主体と対象、提案version、最終Actionの結果を記録します。Slackやメールで承認を受ける場合も、返信文だけで対象を決めず、request IDと承認対象versionを照合してください。監査用ログには判断に必要な情報だけを残し、顧客本文や機密値を無期限に保存しない保存期間を定めます。

直列承認と非同期承認を使い分ける

処理の流れの中で担当者がすぐ判断できるなら、workflowを一時停止して返答後に続ける形が単純です。承認に数時間かかる、別部署へ回す、複数段階で確認する場合は、workflowを長時間占有するのではなくrequest IDを保存し、承認callbackを別の起点として受ける設計も検討できます。どちらでも、同じrequestへの二重回答、期限切れ後の承認、元データ更新後の古い承認を無効化できる必要があります。

実装前に「誰が、何を見て、どの操作をできるか」を1枚にまとめます。元入力へのアクセス権がない承認者へ個人情報を転送してはいけません。共有channelに承認依頼を出す場合は、全員が対象情報を閲覧できるか、通知から表示される内容が最小限か、誤送信時に停止・取消できるかも確認します。

AIものさしの判断

Human-in-the-loopは「AIを信用しないための仕組み」ではなく、リスクに応じてautomation boundaryを決める設計です。

リスク classification→AI 下書き/judgment→approval context→human decision→アクション→auditの順にすると、人の確認をボトルネックではなく安全装置として置けます。

AIものさしでは、承認ステップを入れたことではなく、高リスク アクションだけが適切に止まり、人が根拠を見て判断し、その結果を追跡できる状態をこのワークフロー設計の完了条件にします。