ZapierとChatGPTを連携して定型業務を自動化する方法

ZapierとChatGPT（OpenAI）を連携すると、フォーム送信や新着メールなどをtriggerに、要約・分類・返信案の作成を挟み、別appへ渡せます。手順を探すときは、古いChatGPT action名だけを前提にしないでください。Zapierの案内では、Assistants APIを使う旧actionは2026年8月26日に停止し、現行のConversation actionはResponses APIを使うとされています。既存Zapを移行する場合は、公開中のZapier Helpで現在のactionと入力項目を確認してから変更します。

この記事では、問い合わせ受付を担当者reviewへつなぐ「trigger → ChatGPT処理 → validation → 保存/通知」を作る考え方を示します。これは実accountを操作した手順ではなく、公式helpに沿った設計例です。画面表示や利用可能actionは更新されるため、作業時はlink先の現行UIを優先してください。

ChatGPT subscriptionとAPI connectionを分けて考える

ZapierのChatGPT（OpenAI）appを使うとき、接続するOpenAI accountとAPI利用条件を確認します。ChatGPTの有料subscriptionとAPI利用は別のbillingとして扱われるため、ChatGPTへ加入しているだけでAPI利用費が含まれるとは限りません。workflowを有効化する前に、OpenAI側のAPI billing、Zapier側のtask/plan消費、実行頻度を分けて見積もります。

「無料で試す」場合も、Zapier taskや接続できるapp・実行回数にplan条件があることがあります。料金を断定せず、実際に使うaccountのplan画面と公式pricingを確認してください。API keyはZapierのconnection管理へ登録し、ZapのpromptやGoogle Sheetsへ貼り付けないようにします。

例：新しい問い合わせを要約して担当者へ回す

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

ステップ	入力・処理	成功条件	失敗時
Trigger	form/CRM/emailの新規record	一意IDと本文がある	空本文はreview queue
ChatGPT action	件名・本文から要約と分類候補	必須fieldと許可値が返る	retryまたはreviewへ
Formatter / Filter	出力schema、文字数、categoryを検査	条件を満たす	後段actionへ進めない
Action	Sheet/CRMへ保存、Slackで通知	record_idでduplicateしない	error通知、再実行対象を記録
人の確認	原文と要約を照合	担当者が承認	顧客へ自動送信しない

Zapierのworkflow単位はZapです。triggerは「何が起きたら開始するか」、actionは「その後に何をするか」を表します。AIを一つのactionとして間に置けば、入力元と出力先を切り離して考えられます。いきなり自動返信を有効にせず、最初は下書き作成や社内通知へ限定してください。

現行ChatGPT actionを選ぶ

ZapierのHelpはChatGPT（OpenAI）app内の利用可能actionや用途を案内しています。旧Assistants API系actionは2026年8月26日の終了案内があるため、過去記事や古いZapの設定画面と同じ項目が見えるとは限りません。新規作成時は、現行Zapier画面と公式の「適切なChatGPT actionの選び方」を確認し、記事や動画の古い手順をそのまま再現しないでください。

action選択の軸は、どの種類のOpenAI処理をしたいか、必要な入力・出力項目は何か、後続nodeが扱える形式かです。画面に表示されるaction名、model選択肢、必須fieldは更新されるため、古い名称を覚えて設定するより、Zapierの現行action helpを見て照合します。Assistantsからの移行が必要な場合は、既存Zapの各step、thread/file/tool依存、出力形式を棚卸しし、Conversation等への置き換え後にtest Zapで同じ入力・期待出力を比較します。単純な要約と、過去会話やfileを伴う処理では移行の手間が異なるため、単純置換できると決めつけません。

Promptへ渡す値を最小化する

入力fieldをすべて無条件で渡さず、処理に必要なものを選びます。例えば要約に必要なのは件名と本文であり、顧客IDや住所が不要なら送らない設計にします。本文内に命令文が含まれても、これは処理対象の文章です。AIへ与える指示とdataを区切り、本文中の指示に従って外部送信や削除をしないようにします。

出力は後続で検証しやすい形にします。categoryが billing / account / bug / other の許可値か、要約が空欄でないか、長さ上限を超えないかをFilter等で確認します。自由文しか返らない場合、後続の条件分岐を正規表現や曖昧なkeywordに依存させず、出力構造を先に見直します。

二重実行と途中失敗

Zapは外部app、OpenAI API、Zapierのいずれかで失敗し得ます。「AI処理は成功したが、次の保存先は失敗した」場合、再実行で同じ課金・通知が発生することがあります。record_idを保存先に持たせ、同一IDがすでにdoneなら更新かskipを行います。Zapierの再試行設定が利用可能でも、外部actionが二重に実行されないかを別に確認します。

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

異常	確認すること	運用上の扱い
Triggerが0件	connection権限、polling/webhook、test data	Triggerだけを単独確認
ChatGPT actionの失敗	connection、billing、入力長、rate limit	errorとretry条件を区別
出力が不正	必須field、JSON、許可値	downstreamを止め、担当者へ通知
Sheet/CRMが停止	record_id、保存先の権限	duplicateを避けて再実行
古いactionが停止	Zap内のstepと警告	migration後に代表dataで比較

実行履歴やtask historyは復旧に役立つ一方、顧客文面や個人情報をどこまで残すかは別途決めます。Zapierと接続先appで閲覧できる担当者、保存されるfield、logの保持を確認し、必要以上に本文を通知やtask noteへ複製しません。

作成から公開までのチェックリスト

• 自動化する処理が1つに絞られている

• triggerとactionのaccount connectionが正しい

• ChatGPTの入力fieldを最小化した

• API billingとZapier planを別々に確認した

• AI出力にschemaとvalidationを設けた

• 顧客向け送信の前に人の承認がある

• 同じrecordを二重処理しない識別子がある

• connection切れ、API制限、保存失敗をtestした

• 現行actionの公式Helpを参照した

• 旧Assistants API actionへの依存が残っていない

• 実行履歴に残る個人情報を確認した

• 有効化後、最初の実行を担当者が監視する

AIものさしの判断

ZapierとChatGPTの連携では、Zapが止まらず動くことだけでなく、どのactionが現行仕様か、再実行しても重複処理しないかが重要です。まず社内向けの小さな処理で、旧actionに依存しない現行構成をtestします。分類や要約の出力を人が確認できる形にし、定型業務の誤分類率や修正時間を見てから、自動処理の範囲を広げてください。料金、task上限、action availabilityは変わるため、導入判断の直前にZapierとOpenAIの公式情報を再確認します。

旧Zapを移行するときの確認表

Assistants API actionが停止した後は、Zap全体を一括で作り直す前に、どのstepが旧機能へ依存しているかを棚卸しします。

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

確認対象	記録すること	移行時の比較
Trigger	app、event、取得field	同じrecordが開始条件になるか
ChatGPT action	旧action、threadやfile利用、model設定	現行actionで同じ入力が使えるか
Prompt / instructions	固定指示、動的field、空欄処理	指示と本文dataが分離されているか
Output mapping	参照している戻り値field	field名・型が変わっても後続が動くか
Downstream action	保存、通知、外部送信	二重実行や意図しない送信がないか
Billing / permissions	OpenAI APIとZapier plan	接続アカウントと費用負担が明確か

移行のテストでは、過去に使った実データをそのまま共有環境へ再送せず、機密を除いた固定サンプルを作ります。旧版・新版へ同一サンプルを入れて、期待するsummary、分類、後続fieldが一致するかを比べます。モデルの文章が完全一致する必要はありませんが、分類値、重要な事実の保持、レビュー必須条件は比較可能にしておきます。

変更を有効化する前の停止条件

切替前にZapを複製または下書きにし、triggerを実データへ接続する前にテストします。既存Zapの停止時刻、移行版の有効化時刻、重複稼働の有無を記録します。両方を同時に動かす期間があるなら、同じ問い合わせを二重送信しないようtest用の出力先や識別子を使ってください。出力を顧客へ送るstepがある場合、まず無効化した状態で分類・要約・保存だけを検証し、承認後に送信経路を戻します。