![]()
Zapierが動かない9つの原因と対処法 2026年チェックリスト
この記事のポイント ・「動かない」の8割は、Zapが止まっている・認証が切れている・タスク上限に達した、のどれかです ・原因の切り分けはZap History(実行履歴)を見るだけで5分で終わります ・履歴に何も出ていないならトリガー側、赤いエラーが出ているならアクション側の問題です ・無料プランの15分間隔を「動かない」と誤解しているケースがかなり多いです ・直したあとは、同じ止まり方を二度と繰り返さないための見張りをセットで作ります
朝メールを開いたら、昨日まで動いていた自動化が丸ごと止まっている。Slackに通知が来ない、スプレッドシートに行が増えない、顧客への自動返信が飛んでいない。しかも画面上のZapは、見た目には何も変わっていません。
このとき最初に開くべき画面は、Zapの編集画面ではありません。Zap History(実行履歴)です。ここに何が記録されているかで、原因は3つのグループにきれいに分かれます。
まずは結論から並べます。
| 症状 | 履歴の見え方 | 疑う原因 |
|---|---|---|
| 何も起きていない | 実行記録がゼロ | Zapがオフ/トリガー未発火/タスク上限 |
| 途中で赤く止まる | errored / halted | 認証切れ/必須項目の欠落/連携先の障害 |
| 動いてはいるが結果が出ない | filtered | フィルター条件が厳しすぎる |
| 反映が遅い | 正常だが時刻がずれる | プランの更新間隔/ポーリング方式 |
つまり、履歴の1行を見た時点で調査範囲は4分の1になります。ここから先は、この分岐に沿って原因を潰していきます。
Zapierが動かないとは、どういう状態か

Zapierが動かないとは、トリガー(きっかけ)が拾われないか、アクション(実行)が完了しないか、そのどちらかで自動化が最後まで走らない状態です。原因は大きく「起動していない」「途中で落ちた」「条件で止められた」の3種類しかありません。
この3分類が頭に入っていないと、動いていないZapの編集画面を延々と眺めることになります。編集画面には「なぜ止まったか」は書かれていません。答えがあるのは履歴側です。
用語だけ先に揃えておきます。Zapは自動化のひとかたまり、トリガーはその引き金になる出来事、アクションは実際に行う処理、タスクはアクションが1回成功したときにカウントされる単位です。課金はこのタスク数で決まります。
ここを混同すると「Zapは3本しかないのにタスクが尽きた」という状況が理解できません。3本のZapでも、1本が1日200回発火すれば600タスクです。
履歴のどこを見れば5分で切り分けられる?

Zap Historyのステータス表示を見れば、原因の所在がトリガー側かアクション側かフィルター側かが一目で分かります。ここを飛ばして設定を触り始めるのが、復旧が長引く最大の理由です。
見るべきは3列だけ。ステータス、実行時刻、そして展開したときのデータ中身です。
| ステータス表示 | 意味 | 次に見る場所 |
|---|---|---|
| 記録なし | そもそも起動していない | Zapのオン/オフ、トリガー元の設定 |
| success | 完走した | 連携先アプリの受け取り側 |
| filtered | 条件で止めた | フィルターステップの設定値 |
| errored | 処理中に失敗 | エラーメッセージ本文、認証状態 |
| halted | 意図的に中断 | 前段のステップのエラー処理設定 |
| delayed / waiting | 待機中 | 遅延ステップ、プランの更新間隔 |
つまり、「successなのに結果が見えない」なら問題はZapierの外側、「errored」なら中身、「記録なし」なら入口です。この3方向を混ぜて調べないこと。
以下、この順番で9つの原因を潰していきます。
原因1:Zapがそもそもオフになっている
実行履歴が完全に空なら、最初に疑うのはZapのオン/オフです。編集後に公開し忘れる、共有ワークスペースで誰かが止める、エラー連発でZapierが自動停止する。この3つで大半が説明できます。
見落としやすいのが3つ目。同じステップで連続してエラーが出ると、Zapierは無駄な処理を防ぐために自動でZapを止め、その通知をメールに送ります。そのメールが迷惑メールに入っていると、「勝手に止まった」ようにしか見えません。
確認すること
- Zap一覧のトグルが青(オン)になっているか
- 編集後に「Publish」を押したか、下書きのままではないか
- Zapierからの自動停止メールが届いていないか
- チーム利用なら、直近に誰が編集したか(Version history)
ここで再度オンにして解決した場合でも、そのまま閉じてはいけません。「なぜ止まったか」が残っているなら、また同じ日数で止まります。
止まった理由がエラー連発だったなら、次の項目が本命です。
原因2:連携アプリの認証が切れている
Zapierが動かない原因として最も多いのが、連携先アプリの認証切れです。パスワード変更、二段階認証の設定変更、管理者によるアクセス権の見直し。どれも自動化とは無関係な操作に見えて、裏で接続を切ります。
Google系、Slack、各種SaaSは定期的にアクセス権の再確認を求めます。ユーザーが再認証しないまま放置すれば、Zapは静かにエラーへ落ちる。
App Connections(接続一覧)の画面で、赤いバッジが付いた接続を探してください。そこに「Reconnect」ボタンが出ていれば、押して再ログインするだけで復旧します。
再認証の順番
- App Connectionsで該当アプリを開く
- Reconnectを押し、正しいアカウントでログインし直す
- 権限スコープの確認画面で、要求された項目をすべて許可する
- Zap Historyから失敗した実行を選び、Replay(再実行)する
4番目が抜けると、止まっていた期間の処理が丸ごと消えます。復旧=再実行までがセット。
ここで気をつけたいのが、複数アカウントを持っている場合の取り違えです。会社用と個人用のGoogleアカウントが両方ログイン状態だと、再認証で別アカウントに繋いでしまい、「エラーは消えたのにデータが来ない」という厄介な状態になります。
原因3:タスク上限に達している
月間タスク数を使い切ると、Zapは順次停止します。これは故障ではなく、プランの上限に触れただけです。
無料プランは月100タスク、Professionalは年払いで月換算$19.99からで月750タスクという段階制です。この数字は2026年7月時点の公式料金ページに基づくもので、タスク数はスライダーで刻みが変わります。
| プラン | 月間タスク数の目安 | 主な内容 |
|---|---|---|
| Free | 100 | 2ステップZapのみ/ユーザー1名/更新間隔15分 |
| Professional | 750〜(段階制) | マルチステップZap/プレミアムアプリ無制限 |
| Team | 2,000〜 | 最大25ユーザー/共有ワークスペース/SAML SSO |
| Enterprise | 要問い合わせ | ユーザー数無制限/高度な管理機能 |
つまり、無料枠の100タスクは「テスト用」と考えるのが現実的です。実運用に入れた瞬間に溶けます。
タスクを食い潰している犯人は、たいてい1本のZapです。使用状況の画面でZapごとの消費量を見れば、上位1〜2本で全体の大半を占めているはずです。
タスク消費を減らす手
- フィルターを1ステップ目に置き、不要な実行を早い段階で切る
- 「新規行が追加されたら」を「特定の列が埋まったら」に絞る
- 通知系を1件ずつではなく、まとめて1日1回に変更する
- 実質使っていない古いZapを止める
タスクを削る作業は、そのまま実行速度の改善にもなります。処理が重くて遅いと感じているなら、Zapierが遅いときの原因と高速化に具体的な削り方をまとめてあります。
無料プランの「動かない」は本当に不具合?
無料プランで「反応が遅い」と感じるケースの多くは不具合ではなく、更新間隔15分という仕様です。トリガーが発火してから最大15分待つ設計なので、押してすぐ確認すると何も起きていないように見えます。
ここを勘違いしたまま設定をいじると、正常なZapを壊すことになります。
判定は簡単です。20分待って動くなら仕様、待っても動かないなら別の原因。
もうひとつ、方式の違いも押さえておくと迷いません。
| トリガーの方式 | 反応の速さ | 挙動 |
|---|---|---|
| Webhook型 | ほぼ即時 | 連携先が変更を押し込んでくる |
| ポーリング型 | 間隔ごと | Zapierが定期的に見に行く |
| 手動実行 | 即時 | テスト時のみ |
つまり、同じアプリでもトリガーの選び方で体感速度が変わります。急ぎの通知系はWebhook型のトリガーが用意されていないか、アプリ側のトリガー一覧を確認する価値があります。
なお、テスト実行では動くのに本番で動かない場合、この方式の違いが絡んでいることが多いです。テストはZapierが直接データを取りに行くため、ポーリング待ちを飛ばしてしまいます。
原因4:トリガーが条件を満たしていない
履歴が空で、Zapもオンで、タスクも残っている。この場合はトリガーが「起きた」と認識されていません。
ありがちなのが、トリガーの範囲がずれているパターンです。
- Googleスプレッドシートで、指定したシート名と実際に書き込んでいるシートが違う
- 「新しいメール」トリガーで、対象ラベルが付く前に処理されている
- フォルダ指定のトリガーで、サブフォルダは監視対象外だった
- 行の追加ではなく、既存行の編集をしていた
4つ目は特に厄介です。「新規行」トリガーは追加のみを拾い、途中の空白行を後から埋める操作は多くの場合カウントされません。運用側の入力手順が変わった途端に止まる、という形で表面化します。
確かめ方
トリガーステップのテストで、実際のデータが1件でも取れるかを見ます。ここで「見つかりません」と出るなら、Zapの設定ではなく、監視している場所そのものが間違っています。
もうひとつ、大量にデータを入れた直後は、古いレコードが拾われないことがあります。トリガーは基本的に「Zapをオンにした以降の新規」を対象にします。過去分を流したいなら、手動での一括処理を別に用意するほうが早いです。
原因5:フィルターが厳しすぎて全部止めている
履歴にfilteredが並んでいるなら、Zapは正常に動いていて、条件で止められているだけです。故障ではないぶん、気づくのが遅れます。
フィルターで多いミスは3つ。
| ミスの型 | 何が起きるか | 直し方 |
|---|---|---|
| 完全一致の指定 | 前後の空白や全角半角で外れる | 「含む」条件に緩める |
| 空欄チェック | 空文字とnullの扱いが違う | 「exists」条件を使う |
| AND条件の重ね過ぎ | どれか1つが常に偽 | 条件を1つずつ外して特定 |
つまり、filteredが出たら条件を1つずつ無効化して、どれが犯人かを機械的に絞るのが速いです。
日本語データを扱うときは、全角スペースと半角スペースの混在が地味に効きます。人が手入力する項目でフィルターをかけるなら、完全一致は避けるのが無難。
原因6:必須項目が空でアクションが落ちる
erroredの中身を開いて「required field」「is required」といった文言が見えたら、送るデータのどこかが空です。
トリガー側のデータは、常に全項目が埋まっているとは限りません。テスト時に使ったサンプルには値が入っていて、本番データでは空欄。この差でアクションが落ちます。
空欄への対処
- Formatterで既定値を入れてから渡す
- Filterで「値が存在する場合のみ進む」条件を置く
- アクション側で必須になっている項目を、任意項目に置き換えられないか見直す
とくに日付・電話番号・金額は、形式の違いでも弾かれます。「2026/08/30」と「2026-08-30」が別物として扱われる連携先は珍しくありません。エラー文に「invalid format」が出ていれば、空欄ではなく形式の問題です。
このあたりを丁寧に組むなら、調達業務をZapierとChatGPTで自動化する設計で扱っているデータ整形の型が参考になります。項目の欠落を前提に組むと、止まらないZapになります。
原因7:連携先アプリのAPI制限に当たっている
短時間に大量の処理を投げると、連携先アプリ側で回数制限に当たります。エラーメッセージに「rate limit」「429」「too many requests」が出ていればこれです。
Zapier側の設定をいくら見直しても直りません。相手側の都合だからです。
逃がし方
- Delayステップを挟んで、処理の間隔を空ける
- 1件ずつではなく、まとめて処理する形に変える
- 実行が集中する時間帯をずらす
- Autoreplay(自動再実行)が使えるプランなら有効にしておく
一括インポートの直後に大量発火して制限に当たる、というのが典型パターンです。データを大量投入する日は、事前にZapを止めておくほうが安全です。
原因8:連携先サービス側で障害が起きている
自分の設定が原因ではないこともあります。連携先アプリの障害、あるいはZapier自体の障害です。
判定は手順が決まっています。
- 同じアプリを使う別のZapも同時に落ちているか
- エラーが特定の1アプリだけに集中しているか
- 連携先アプリの公式ステータスページに障害情報が出ているか
- Zapierの公式ステータスページ(status.zapier.com)に記載があるか
複数のZapが同じアプリで同時刻に落ちていれば、ほぼ相手側です。この場合にやるべきは設定変更ではなく、復旧後の再実行だけ。
障害中に設定を触ると、復旧後に「直したはずの設定が原因で今度は別のエラー」という二次災害になります。障害が疑わしいときは手を止める。これが正解です。
原因9:更新後の仕様変更で組み方が古くなっている
長く動いていたZapが、何もしていないのに止まる。この場合、連携先アプリのAPI仕様変更か、Zapierのアプリ側バージョン更新が原因のことがあります。
Zapierの各アプリ連携にはバージョンがあり、古いバージョンが非推奨になると、新しい版への移行を促す表示が出ます。放置すると、ある時点から動かなくなります。
見分け方
- Zapの編集画面に「新しいバージョンがあります」の案内が出ている
- 以前は選べた項目が、選択肢から消えている
- 出力されるデータの項目名が変わっている
対処は、該当ステップを一度削除して作り直すのが結果的に速いです。古い設定を引きずったまま部分修正すると、見えない項目が残ります。
自動化を長く使うなら、こうした仕様変更に強い構成が要ります。処理の中身を自分の管理下に置きたいなら、n8nの使い方と実践ガイドで扱っている自前ホスティング型の考え方も選択肢になります。
直った後、再発を防ぐには何をすればいい?
復旧させただけで終えると、同じ止まり方をまた繰り返します。止まったことに気づく仕組みを、Zapierの中に作っておくのが確実です。
入れておきたい見張り
| 仕掛け | 何を防ぐか |
|---|---|
| エラー通知をSlack/メールへ | 「止まっていたのに気づかなかった」期間をなくす |
| 月次でタスク使用量を確認 | 上限到達での全停止 |
| 四半期ごとに接続の棚卸し | 認証切れの放置 |
| 重要ZapのみAutoreplay有効 | 一時的な障害での取りこぼし |
つまり、Zapierの運用で本当に痛いのは止まることではなく、止まったことに何日も気づかないことです。
社内の複数部署で自動化を回しているなら、誰が何を持っているかの台帳もあわせて要ります。この設計は経営企画のAIワークフロー構築で扱っている考え方が近いです。
広報・PRのように「送信ミスが即座に外に出る」領域では、見張りの優先度がさらに上がります。PR業務をZapierとChatGPTで自動化する型では、承認を挟む構成を紹介しています。
直らないときはどこに問い合わせる?
チェックリストを一周しても直らないなら、問い合わせ先を間違えていないかを先に確認します。原因の所在で窓口が変わるからです。
| 症状 | 問い合わせ先 |
|---|---|
| 特定アプリだけエラー | そのアプリの提供元 |
| 複数アプリで同時に発生 | Zapierサポート |
| 課金・タスク数の疑問 | Zapierサポート |
| データが相手側に入らない | 受け取り側アプリの提供元 |
問い合わせるときは、Zap Historyの該当実行のURLとエラーメッセージ全文を添えると解決が早いです。「動きません」だけでは、先方も同じ切り分けを最初からやり直すことになります。
なお、公式のヘルプはzapier.comから辿れます。エラーメッセージの文言をそのまま検索窓に入れるのが、いちばん近道です。
AI PICKS編集部の判定
Zapierが動かないという相談の中身は、9割方トラブルではなく運用の穴です。認証切れ、タスク上限、フィルターの締めすぎ。この3つで説明がつくケースが圧倒的に多く、Zapier本体の不具合まで行き着くのは稀です。
だからこそ、真っ先に見るべきはZap History一択です。編集画面から入る癖がついている人は、そこで30分溶かします。履歴のステータス1列を見れば、調べる範囲は4分の1になる。この順番を体に入れるだけで、復旧時間は劇的に短くなります。
一方で、無料プランを本番運用に使い続けるのは正直イマイチです。月100タスクは実務では数日で尽きますし、更新間隔15分は通知系と相性が悪い。業務に組み込むなら有料プランへの移行が前提だと考えたほうが健全です。
そして復旧より重要なのが、止まったことに気づく仕組みです。エラー通知だけは今日中に入れてください。ここが埋まっていないと、次に止まったときもまた同じ日数を失います。地味ですが、いちばん効きます。
よくある質問(FAQ)
Q. Zapが急に止まりました。まず何をすればいいですか?
Zap History(実行履歴)を開いて、直近の実行のステータスを見てください。記録が何もなければトリガー側、erroredなら認証や設定、filteredなら条件の問題です。編集画面から見始めると原因にたどり着けません。
Q. エラーが出ていないのに結果が反映されません。
ステータスがsuccessなら、Zapier側の処理は完了しています。受け取り側のアプリで、書き込み先が想定と違う場所になっていないかを確認してください。スプレッドシートのシート名違い、Slackのチャンネル違いが定番です。
Q. タスクを使い切ったらどうなりますか?
上限に達したZapは順次停止します。プランをアップグレードするか、翌月のリセットを待つかの二択です。停止中に発生した出来事は自動では拾われないため、復旧後に手動での穴埋めが必要になります。
Q. 止まっていた間の処理をあとから流せますか?
Zap Historyから該当の実行を選んでReplay(再実行)できます。ただし、そもそも履歴に記録が残っていない(トリガーが拾われていない)ぶんは再実行できません。この場合は手動で処理するしかありません。
Q. 無料プランでも安定して動きますか?
テストや個人利用なら問題ありませんが、業務で使うには月100タスクと更新間隔15分がきつすぎます。2ステップまでという制限もあり、フィルターを1つ挟むだけで枠を使い切ります。本番運用なら有料プラン前提です。
Q. 同じZapが何度も同じ処理を繰り返します。
トリガー元のデータが更新されるたびに発火している可能性があります。「新規作成時のみ」のトリガーに変更するか、フィルターで重複を弾く条件を追加してください。Storage系のステップで処理済みフラグを持たせる方法もあります。
Q. Zapierを使い続けるべきか、他に移るべきか迷っています。
連携先アプリの数で選ぶならZapierが依然として強いです。ただし、タスク課金が重くなってきた、処理の中身を細かく制御したい、という段階なら他の選択肢を検討する価値があります。判断材料はタスク単価と、必要な連携先が揃っているかの2点です。
Q. エラー通知はどこで設定できますか?
Zapierのアカウント設定で、Zapが自動停止したときのメール通知を有効にできます。それとは別に、エラーを検知して自分のSlackへ流すZapを1本作っておくと、気づくまでの時間が大幅に縮みます。
あわせて見たいツール・カテゴリ
- Zapier — 連携できるアプリ数で選ぶならここ。今回のトラブル対応もこのツール前提です
- Make — 分岐や繰り返しを図で組みたい人向け。処理単価の考え方がZapierと違います
- n8n — 自前サーバーで動かせるタイプ。API制限や課金の悩みを構造から変えたい場合の選択肢
- 業務自動化ツール — 同じ用途のツールを横並びで見たいときの入口
- AIエージェント — 定型処理から一歩進んで、判断まで任せたい場合はこちら
- AI業務効率化ツールの人気カテゴリ — 導入実績の多い順に眺めたいとき
自動化そのものの速度に不満が出てきたなら、次に読むのはZapierが遅いときの原因と高速化です。今回の「止まる」と「遅い」は原因が別物なので、切り分けの型を両方持っておくと迷わなくなります。
