ZapierでAI自動化を始める方法|入力・出力項目・Previewを確認する

ZapierにAI by Zapierを追加し、問い合わせの分類候補を担当者へ渡す設計例。入力、出力項目、確認待ち、後続処理、モデルtierとtask消費を分けて確認します。

AIものさし編集部

ZapierでAI処理を始めるときは、入力を受け取るトリガー、AIで返す項目、その結果を渡す後続アクションを一つずつ確認します。最初の目標は、問い合わせの分類候補を担当者へ渡すような、結果を確かめられる小さな流れです。

ここではAI by Zapierを使う構成を例にします。入力、依頼文、分類結果は架空の設計例です。Zapierへの接続、Preview、実行、通知、料金消費を実測した結果ではありません。AI by Zapierと、別のAIアプリを使うアクションの設定は区別してください。

まず、入力と出口を一枚で決める

Zapは、開始のきっかけになるトリガーと、一つ以上のアクションを組み合わせます。Zapierの公式ガイドでは、エディター、Copilot、テンプレートなどから構築する方法が案内されています。Zapier公式:基本手順(新しいタブで開く)

最初に「どの問い合わせを何へ渡すか」を決めます。下の例では、AIに顧客への返信や担当者の確定を行わせず、分類候補を確認するための流れを設計します。

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

工程架空例での役割確認する値
トリガー問い合わせが届いたことを受け取る元の問い合わせID、本文
入力確認本文が空でないか、必要な情報だけかを確かめる対象範囲、不要な個人情報
AI by Zapier分類候補と根拠を返すcategory、reason、needs_review
後続処理結果を検査し、確認用の宛先へ渡す許可値、型、宛先、元IDとの対応

同じメールや行を受け取るトリガーでも、アプリやイベントごとに条件が違います。実際の接続先で利用できるイベントと入力項目を確認し、架空の項目名をそのまま設定名として探さないでください。

トリガーのサンプルと、AIへ渡す本文を確認する

使用するアプリ、イベント、接続アカウントを選び、サンプルが対象のデータかを確かめます。本文のつもりで件名だけを渡したり、最新の返信ではなく過去の引用全体を渡したりすると、後の分類が変わります。

元の問い合わせIDは、AIの出力から作り直さず、トリガーの値と対応させて持ち回ります。本文が空の場合はAIへ送る前の確認対象にします。どの機能で入力確認や分岐を組めるかは、契約と対象ステップで確認してください。

サンプルには架空の問い合わせを使います。接続、テスト用の宛先、権限が実データの運用先を指していないかを確認してから試します。テストのボタンでも、選んだアクションによっては宛先へデータを作るため、通知文の確認だけと決めつけないでください。

AI by Zapierを追加し、出力項目を先に決める

公式ヘルプでは、AI by ZapierのConfigureで依頼文、モデル、出力項目などを設定し、Previewで結果を確認する流れを説明しています。前のステップの値を依頼文へ挿入し、Output Fieldsでは名前と型などを設定できます。Zapier公式:AI by Zapier(新しいタブで開く)

この例では、次の三項目を使います。これは設定方針の例で、自分のステップで利用できる型と必須設定を確認します。

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

項目この例での扱い後続での確認
categorysales/support/otherの分類候補許可した三つの値か
reason入力のどこから判断したかを短く示す本文に対応する根拠か
needs_review判断を人へ戻す必要があるか真偽値として扱えるか、欠落していないか

項目名を付けただけで、分類の正しさや値の制約が保証されるわけではありません。モデルの返す値と、後続ステップが受け取る実際の型を確認します。文字列の「false」を真偽値のfalseと同じ条件で扱えると、確認せず決めないでください。

依頼文に、境界例と確認待ちを入れる

問い合わせ本文だけを使って分類候補を返してください。
sales:新規導入や利用契約の相談。
support:現在利用中の製品の操作や不具合の相談。
other:上のどちらにも該当しない内容。
出力項目:category、reason、needs_review。
categoryはsales、support、otherのいずれかにしてください。
reasonには入力中の判断根拠を短く示してください。
複数の相談が混在する、または情報が足りず判断できない場合は、needs_reviewをtrueにしてください。
otherを、判断できない内容の自動処理先として使わないでください。
入力にない顧客情報、契約状態、担当者、返信内容を補わないでください。
入力:[前のステップの問い合わせ本文を対応付ける]

この依頼文は、AIの結果を検査する代わりにはなりません。確認待ちの印が返ること自体も保証されないため、許可値以外、項目欠落、型の不一致は別に検出する設計にします。

まずは使ってみる

記事の文脈に合うToolへ進めます。報酬の有無で見た目は変えていません。

後続ステップへ渡す前に、結果を検査する

まずneeds_reviewがtrueなら人の確認へ戻します。値や型が不足・不正な場合も、通常の分類先へ流さず確認対象にします。そのうえで、確認待ちではないsales、support、otherを、それぞれ決めた宛先へ対応させます。

FilterやPathsなどの利用条件は契約によって異なります。公式ガイドはPathsをProfessional以上の機能として案内しています。以下は分岐の考え方で、すべてのプランに同じ構成を設定できるという説明ではありません。

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

架空の入力・出力期待する扱い
新規導入の相談、sales、確認待ちfalse営業候補を確認用の宛先へ
操作の質問、support、確認待ちfalseサポート候補を確認用の宛先へ
導入相談と不具合が混在、確認待ちtruecategoryにかかわらず人へ戻す
本文なしAI処理前の入力確認へ戻す
categoryがbillingなど許可値以外分類先を作らず、出力確認へ戻す
needs_reviewが欠落、または型が不正falseと見なさず、出力確認へ戻す

単に「other以外なら処理する」とすると、未知の値まで通す場合があります。また、otherをすべて人へ戻す設計にするなら、その業務上の意味を明示してください。分類語、確認待ち、処理先は別の条件です。

モデルとtask消費を確認する

AI by Zapierの公式料金説明では、Standardは1倍、Advancedは3倍、Premiumは5倍のtask倍率です。有料プランの新しいステップはPremiumが初期選択と案内されているため、意図する選択かを確認します。Freeでは未公開ZapのStandardをPreviewでき、公開運用と上位tierの利用にはアップグレードが必要という説明です。Zapier公式:モデルtierとtask(新しいタブで開く)

同資料の計算式は「AIステップの倍率+ツール呼出数×倍率」です。例えばAdvancedでツールを2回使うなら、3+2×3=9 tasksという計算です。これはAIステップの説明で、後続アクションを含むZap全体や月額料金を9 tasksだけで見積もるものではありません。自分の契約、実行数、別のAI提供元の料金がある場合はそれも確認します。

今回の例はツールを追加しない分類から始めます。上位tierなら分類が正確になる、低いtierなら必ず安く運用できるという実測比較ではありません。期待した出力と実際の使用量を分けて確認してください。

Previewから、確認対象を一つずつ追う

Previewでは分類結果、根拠、確認待ち、項目の型を見ます。空欄、複数意図、未知の値、項目欠落も確認例へ含め、正常な問い合わせ一件だけで終えません。後続処理へは確認済みの項目を対応付け、元ID、出力、通った経路、宛先を一緒に記録します。

AI by Zapierへツールを追加した場合、公式ヘルプではPreviewのTools usedで使用したツールや結果を確認できます。ツールごとのRequire approval before runningは初期状態で無効と案内されているため、更新・削除などを追加するときは必要な設定を明示的に確認します。Zapier公式:ツール追加と確認(新しいタブで開く)

このツール用の承認設定が、後に置く通常の送信アクションすべてを自動で止めるとは考えないでください。どのステップが何を実行するかを個別に確認します。実際の運用へ移す判断は、接続先、入力、経路、使用量、失敗時の対応を確認してから行います。

再実行で書き込みが重複する問題は、Zapierの再実行と重複レコードの切り分けで、宛先の状態を確認してください。Gmail固有の対象条件はZapierでGmailを自動化する方法、分類基準自体の設計は問い合わせ内容を分類する方法へ進めます。

参考資料

公式資料の確認日:2026年10月20日。入力、出力、分岐は架空の設計例です。アカウント接続、AI生成、Preview、通知、製品上の分岐、task消費、公開運用は実測していません。

次の一手

記事の内容を踏まえて、公式とTool詳細から続けられます。

次に読む・使う

この記事の次に必要な情報へ進めます。