Zapierの承認ステップで自動化を止める｜公表された設定と制約

自動化を組んでいて最後に残るのは、たいてい同じ一点です。「これを人が見ないまま外に出していいのか」。顧客へのメール、SNSへの投稿、見積書の送付。AIに下書きを作らせるところまでは自動で流せても、送信の手前には判断が残ります。

Zapierは、この「手前で止める」ための部品を Human in the Loop という名前で用意しています。ヘルプセンターの説明は一文です。「Human in the Loop is a built-in tool that lets you pause a Zap at a certain step so a human can review before your workflow continues」。Zapの実行を特定の段で止め、人が確認してから先へ進めるための機能だと書かれています。

この記事では、Zapierのヘルプセンターに載っている記載だけを使って、導入前に確認できることを整理します。何を止められるのか。誰に確認を頼めるのか。却下されたとき、そして誰も見なかったときに実行はどうなるのか。最後に、止める段を入れたことで別の機能が効かなくなる場合があることまで扱います。

金額は扱いません。ヘルプはこの機能を使えるプランの名前を示していますが、各プランの料金を本記事では確認していないためです。ヘルプの記載は改定されるため、採用の前に現在の記載を確認してください。確認日は2026年11月5日です。

止める話の前に、流れの言葉をそろえる

Zapierのヘルプは、自動化の最小単位を3つの語で定義しています。Zapは「A workflow that connects your apps to automate repetitive tasks」、トリガーは「The event that starts your Zap」、アクションは「What the Zap does after it triggers」。開始の合図を1つ決めて、その後に行うことを順に並べたものがZapです。

Human in the Loop は、このアクションの1つとして置きます。独立した承認システムを横に建てるのではなく、流れの途中へ差し込む1段です。ここを押さえると、設計の問いが変わります。「承認の仕組みをどう作るか」ではなく、「どの段の前で止めるか」になります。

止める位置は、取り消せるかどうかで決まります。社内のスプレッドシートへの追記はあとから直せますが、送信したメールと公開した投稿は戻せません。戻せない処理の直前に1か所だけ置く、というのが素直な置き方です。

3つのイベントがあり、役割が違う

ヘルプは、この機能に3つのイベントがあると書いています。名前が似ているため、最初に役割を分けておきます。

イベント	ヘルプの説明	使いどころ
Collect Data（アクション）	「pauses the Zap run so you can ask for more information. You can then map that data to later steps in your Zap」	足りない情報を人に入れてもらい、その値を後続の段で使う
Request Approval（アクション）	「pauses the Zap run and requests that a reviewer approve or change data you submit for review before continuing the Zap」	送信や公開の前に、内容の承認をもらう
New Approval Requested（トリガー）	「triggers when a specific Human in the Loop step runs in another Zap」	依頼が出たことを別のZapで受け、好きなアプリへ通知する

AIを挟んだ流れで要るのは、多くの場合2つめです。ヘルプは用途として「Reviewing AI-generated content」と「Confirming or editing AI data before they’re used in later steps」を挙げ、公開・送信・レポートのような影響の大きい処理を社内の担当者や取引先が確認する場面も挙げています。AIが作ったものを人が見る場面を想定して用意された機能だと読み取れます。

1つめのCollect Dataは、確認とは目的が違います。止めて「見てもらう」のではなく、止めて「書いてもらう」ためのものです。自動化が途中で情報不足になる流れ、たとえば申込みの備考欄が空のときに担当者へ補足を求めるような使い方がここに当たります。

3つめは通知の自由度のための仕掛けです。依頼が出たこと自体をトリガーとして別のZapで受け取れるため、既定の通知先では足りない場合に、自社が使っているアプリへ知らせを回せます。確認を頼む相手が通知に気づかなければ流れは止まったままになるので、止める設計では通知の経路まで含めて決めることになります。

承認者が見る画面と、そこでできること

依頼を受けた側の手順も、ヘルプに書かれています。承認者は通知からリンクをたどり、Zapierにログインして内容を見ます。画面の左側には、通知を送った時刻、承認者の名前、期限、依頼者からのメッセージが表示され、右側に確認する内容が出ます。

できる操作は、イベントによって違います。Request Approvalでは、必要なら「Edit」で値を直したうえで、承認または却下のボタンを押します。ボタンの文言は依頼側が決められます。Collect Dataでは、項目を見て「Skip」か「Submit」を選びます。Skipでは応答が送られず、Submitで依頼者へ返ります。

ここで設計に効く条件が1つあります。承認者にもZapierのアカウントが必要です。持っていない場合は無料アカウントの作成を案内されると書かれており、組織の設定によっては作成できない場合があることにも触れています。また、承認者がその依頼にアクセスできるよう、Zapを共有しておく必要があります。社外の相手に確認を頼む流れを考えるときは、この条件を先に確かめてください。相手の手元に追加の手続きが発生します。

誰に頼めるかは、プランで変わる

ヘルプは、この機能をProfessional・Team・Enterpriseのプランで使えると書いています。無料プランでは使えません。さらに、依頼先の範囲もプランによって違います。Proプランでは依頼を自分自身にだけ送れると書かれ、他の人へ通知できるのはTeamとEnterpriseです。TeamとEnterpriseでは任意のメールアドレスへ通知を送れますが、応答する承認者はZapierの利用者から選ぶ形になります。

なお、プランの呼び方はページによってProfessionalとProの両方の表記が出てきます。本記事はヘルプの表記をそのまま並べており、金額は確認していません。

この条件から、試す順番が決まります。1人で運用しているなら、まず自分宛ての依頼で流れの形を作れます。他部署や取引先に確認を頼む設計へ進むときに、プランと共有の設計が必要になります。機能の有無ではなく、依頼先の範囲が先に壁になるという順序です。

却下されたときと、誰も見なかったとき

止める段を入れるとき、いちばん決め忘れやすいのが応答が「承認」でなかった場合です。ここは2つの別々の設定になっています。

却下されたときの動きは「Action if reviewer declines」で選びます。Continue runなら却下されても次の段へ進み、Stop runならそこで実行を終えます。待つ長さは「Timeout value」と「Timeout unit」で決め、時間が過ぎたときの動きは「On timeout」で選びます。Skip and continueならその段を飛ばして続き、End runなら実行を終えます。承認者の画面には期限が表示され、ヘルプは「The request will time out after this date」と書いています。

危ないのは期限切れの側です。却下は誰かが判断した結果ですが、期限切れは誰も判断しなかった結果です。確認のために入れた段が、設定しだいでは飛ばされて次へ進みます。承認を得るために置いた1段が、忙しい週には「待たずに出す」装置に変わるおそれがある、ということです。

決め方は、止めた理由に戻ると迷いません。取り消せない処理の前に置いた段なら、期限が過ぎたときはEnd runです。確認があったほうが望ましいが、遅れるほうが困る処理なら、Skip and continueを選んだうえで、飛ばされたことが記録と通知で分かるようにします。どちらにしても、期限の長さは承認者の勤務時間に合わせて決めるほうが現実的です。1時間で切れる設定は、昼休みをまたぐと機能しません。

止める段を入れると、再実行の前提が変わる

ここが、この機能でいちばん見落とされやすい点です。Zapierには、失敗した実行をあとから流し直す仕組みがあります。ヘルプは自動の再実行（autoreplay）をProfessional・Team・Enterpriseのプランで使えると書き、対象を「any Zap run with an errored status」としています。同時に「it will not replay safely halted Zap runs」とも明記しています。安全に停止した実行は、自動では流し直されません。

そして同じページに、設計へ直接響く一文があります。「in some configurations, Human in the Loop steps will not autoreplay」。構成によっては、人の確認の段は自動で再実行されません。

つまり、確認を挟んだ流れでは「失敗しても自動で拾われるはず」という前提を置けません。止まった実行に誰が気づくのかを、別に決める必要があります。具体的には、依頼が出たことを通知する経路（3つめのイベントが使えます）と、応答がないまま期限が近い実行を誰が見るか、の2つです。自動化の設計では、処理そのものより止まったことに気づく経路のほうが抜けやすくなります。

ついでに、やり直してよい処理かどうかも整理しておいてください。通信のエラーで止まった読み取りはもう一度動かせますが、メールの送信や決済の確定は同じ実行をもう一度流せば二重になります。この切り分けは、どの自動化ツールを使うかとは無関係に必要です。RPAと生成AIで壊れ方が違う話はRPAと生成AIの使い分け｜MicrosoftとUiPathの公開文書で読むで扱いました。

「人の承認」は、他のツールでも標準の部品

同じ考え方の部品は、Microsoftも用意しています。Power Automateのヘルプは、承認機能で「サインオフ要求を自動化し、ワークフローの人間による意思決定を組み合わせることができます」と説明し、すぐに開始する場合は「開始して承認を待機」アクションを使うと案内しています。このアクションを使うと「フローが開始され、実行が完了する前に承認者の応答を待ちます」と書かれており、待って止めるという形はZapier側と同じです。

違いは、選べるものの置き場所です。Power Automateは承認の型そのものを選びます。ページ本文には「使用できる承認タイプは4つあります」と書かれ、表には5行が並んでいます。表の記載を転記します（太字の記号だけ外しています）。

承認の種類	動作（ヘルプの記載）
承認/拒否 - 全員の承認が必須	「すべての承認者には、承認または拒否の 2 つのオプションがあります。フローの実行が完了する前に各承認者からの応答が必要です。開始して承認を待つ アクションに続くアクションは、全ての承認者が応答するか、単一の拒否が発生した場合に実行します」
承認/拒否 - 最初に応答	「割り当てられた承認者には、承認 か 拒絶 の 2 つのオプションがあります。要求を完了するには、いずれかの承認者が承認または却下する必要があります。開始して承認を待機する アクションに続くアクションは、承認者の誰か 1 人が承認した後で実行されます」
カスタム応答 - すべての応答を待つ	「割り当てられた承認者が選択できるオプションを定義します。すべての承認者は、プロセスを完了するために応答する必要があります」
カスタム応答 - 1 つの応答を待つ	「割り当てられた承認者が選択できるオプションを定義します。いずれかの承認者が応答すると、プロセスが完了します」
順次承認	「承認は特定の順序で一度に 1 つずつ要求されます。リクエストが次の承認者に移動する前に、各承認者が応答する必要があります。開始と承認待ち アクションに続くアクションは、シーケンス内のすべての承認者が応答した後に実行されます」

Zapier側は、1つの承認について編集の可否・期限・却下時の動きを細かく決める形でした。Power Automate側は、何人の応答をどう待つかという型を選ぶ形です。どちらが優れているという話ではなく、決める対象が違います。複数人の合意が要る業務なら後者の型が近く、1人の確認で足りる業務なら前者の設定項目で十分です。

前提条件も違います。Power Automateのヘルプは、初めて承認を使う場合の前提としてMicrosoft Dataverseのデータベースとフローを作成する有効なライセンスを挙げ、承認フローはDataverseに保存されると書いています。既定の環境ではデータベースのプロビジョニングが必要ないという注記もあります。承認の記録がどこに残るのかは、ツールによって前提が違うということです。

確認しやすい形で渡すと、承認が続く

止める段を入れても、承認者が毎回全文を読み直すのでは確認が続きません。確認のしやすさは、AIに何をどんな形で返させるかで決まります。

OpenAIのドキュメントは、Structured Outputsについて「The model will always generate responses that adhere to your supplied JSON Schema, so you don’t need to worry about the model omitting a required key, or hallucinating an invalid enum value」と書いています。渡したスキーマの項目が欠けたり、定義していない値が入ったりしないという説明です。確認する人は、決まった項目だけを同じ順で見ればよくなります。

ただし同じページは例外も書いています。安全上の理由で応答が断られた場合はスキーマに従わず、拒否であることを示す項目で返ります。トークンの上限などで生成が途中で終わった場合も、スキーマどおりにならないことがあります。利用できるモデルの条件もあり、それより前のモデルではJSONモードを使うよう案内されています。

ここから言えるのは、形が安定することと、中身が正しいことは別だということです。項目がそろっていても、分類の判断が妥当かどうかはスキーマでは分かりません。だから人の確認の段は残ります。逆に、形が毎回違う文章をそのまま承認画面へ出すと、確認が「読む作業」になり、続かなくなります。

あわせて、止める位置を固定できる条件にも触れておきます。Anthropicの文書は、あらかじめ定めた経路でモデルと道具を動かすもの（workflows）と、進め方と道具の使い方をモデル自身が決めるもの（agents）を分けて説明し、前者を「workflows offer predictability and consistency for well-defined tasks」と位置づけています。承認の段を決まった位置に置けるのは、経路が固定されている前者です。AIが手順を組み立てる形では、どこで止まるかも実行ごとに変わります。AIに任せる範囲を広げる場合の論点はAIエージェントをマーケティングに活用する方法｜できることと導入で整理しています。どの業務を自動化の対象にするかという手前の判断はAIによる業務自動化とは？導入の判断と進め方を解説にまとめました。

ヘルプで確認できなかったこと

参照したページの記載だけで書いているため、埋まらなかった項目はそのまま残します。

各プランの金額は扱っていません。機能が使えるプランの名前は書かれていますが、料金の数値を本記事では確認していないためです。自動の再実行についても、回数と間隔の記載は参照したページにありません。期限に設定できる長さの上限も、記載を確認できませんでした。

「構成によってはHuman in the Loopの段が自動再実行されない」という注意についても、どの構成が該当するのかの条件は書かれていません。参照したページには別の解説への案内があるだけです。採用する場合は、この点を自分の構成で確かめてください。

Power Automate側については、承認の種類と前提条件のページだけを読んでいます。承認の履歴の保持期間、再試行の既定値、ライセンスごとの上限値は、別のページに分かれており本記事では確認していません。日本語の依頼文や通知の表示についても、記載を確認していません。

導入によって確認の作業が何時間減るか、という効果の数値は示しません。公表された記載にない数値だからです。海外発のツールを公表されている条件で整理した記事は海外マーケティングツールに並べています。Zapier社が自社の業務でAIをどう使っているかを公表した内容はZapierの社内AI普及率は89%・97%・100%。公式3ページの読み方で扱いました。

まとめ

ZapierのHuman in the Loopは、Zapの実行を特定の段で止め、人が確認してから先へ進めるための組み込みの部品です。イベントは3つあり、情報を書いてもらうCollect Data、内容の承認をもらうRequest Approval、依頼が出たことを別のZapで受けるトリガーに分かれています。

導入の前に確認できる条件は、ヘルプに書かれています。無料プランでは使えないこと。Proプランでは依頼先が自分自身に限られること。承認者にもZapierのアカウントが必要なこと。却下されたときと期限が過ぎたときの動きは、それぞれ別の設定項目で決めること。

いちばん効く記載は最後の2つです。期限切れの既定動作を決めないままにすると、確認のために置いた段が飛ばされます。そして、構成によってはこの段が自動の再実行の対象から外れるため、止まったことに気づく経路を別に用意する必要があります。

止める位置そのものは、取り消せるかどうかで決めれば迷いません。戻せない処理の直前に1か所。確認する内容は、毎回同じ項目が同じ順で並ぶ形にしておく。この2つを先に決めてから設定画面を開くほうが、あとから直す回数が減ります。確認日は2026年11月5日です。