ZapierのZapが動かないときは、「Zap本体がオフになっている」「アプリの認証が切れている」「トリガーが発火していない」の3系統に切り分けるのが最短ルートです。やみくもに作り直す前に、Zap履歴（Zap history）のステータスを見れば、どこで止まったかは数分で特定できます。本記事は、業務自動化をZapierに任せている中小企業の情シス・バックオフィス担当に向けて、症状別の切り分け手順と復旧のやり方、そして「止まったことに気づかない」事故を防ぐ運用設計までを、公式ヘルプの仕様にもとづいて整理します。
Zapが動かないときに最初に確認する3点
原因は無数にあるように見えて、実務で遭遇するものはほぼ3系統に収まります。順番に潰すのが結局いちばん速い方法です。
1. Zap本体が自動でオフになっていないか
見落としが多いのがこれです。Zapierは直近7日間で95%以上の実行がエラーになったZapを自動的にオフにします（実行回数が過去7日で20回を超えている場合が対象。Teamプランは24時間前、Enterpriseプランは72時間前に通知されます。出典：Zapier公式ヘルプ「Zap is not running」）。つまり「昨日まで動いていたのに今日から無反応」というときは、Zapが壊れたのではなく、エラーが続いた結果として止められている可能性が高いということです。まずZapの一覧画面でトグルがオフになっていないかを確認してください。
2. Zap履歴のステータスで止まった場所を特定する
Zap履歴には実行ごとのステータスが残ります。意味を取り違えると調査が遠回りになるため、最低限この4つは覚えておくと判断が速くなります。
- Errored（エラー）：処理が失敗して完了していない。繰り返すとZapの自動オフにつながる。
- On hold（保留）：アカウント接続の切断、タスク上限、フラッド保護などで一時停止している状態。
- Safely halted（安全に停止）：検索ステップで該当なしなど、意図された停止。Zapはオフにならない。
- Handled error（処理済みエラー）：エラーハンドラーが代替処理を実行した状態。Zapはオフにならない。
「実行履歴そのものが1件もない」場合はトリガーが発火していないため、後述の第4章へ進んでください。履歴があってエラーで止まっているなら、原因はアプリ側の設定かデータの中身です。
3. 「テストは成功するのに本番で動かない」の正体
エディタ上のテストが通るのに実運用で止まる場合、テストは既存の過去データを使っているのに対し、本番は新規データを拾えていない、というズレが典型です。必須項目が空のレコード、想定外の日付書式、権限のないフォルダなど、テストで使ったサンプルには存在しなかった条件が原因になります。Zap履歴で失敗した実行の入力データを開き、テスト時のデータと突き合わせるのが確実です。
原因別の対処法①：認証切れ（アプリ接続の切断）
実務でいちばん多いのがこれです。Zapは正しいのに、つながっている先のアカウントが切れているパターンです。
認証切れが起きる典型パターン
- パスワード変更・多要素認証の再設定：連携用アカウントのパスワードを変えると、そのままトークンが無効になります。
- 担当者の退職・アカウント削除：個人アカウントで連携していると、退職処理と同時に全Zapが止まります。
- トークンの有効期限切れ：一定期間で再認証が必要なサービスでは、放置すると自動的に切断されます。
- アプリ側の権限変更：管理者がOAuthアプリの許可を絞ると、接続だけが残って実行が通らなくなります。
再接続してから「リプレイ」で取りこぼしを回収する
Zapierの「My Apps」で該当アプリを再接続すれば復旧します。ここで重要なのは、再接続しただけでは止まっていた間のデータは流れないという点です。保留・失敗した実行はZap履歴から手動でリプレイ（再実行）でき、これをやらないと申請や通知が欠落したままになります（出典：Zapier公式ヘルプ「How to troubleshoot errors in Zap workflows」）。一時的なAPI障害やタイムアウトが原因の失敗については、Autoreplay（自動再実行）を有効にしておくと自動で拾い直してくれます。
再発を防ぐ設定
連携用アカウントは、個人名義ではなく共有の管理者アカウント（例：system@自社ドメイン）で作るのが鉄則です。退職や異動のたびに自動化が止まる構造を、最初に断ち切っておきます。
原因別の対処法②：タスク上限とフラッド保護（保留）
ステータスが「On hold」なら、Zapの設定ではなくアカウント側の事情で止められています。
タスク上限に達すると全Zapが止まる
月のタスク上限に達すると、そのZapだけでなくアカウント全体のアクションが保留になり、請求サイクルがリセットされるまで解除されません。無料プランは月100タスク・Zap数5つ・2ステップまでが目安のため、業務で本格的に使い始めるとすぐ天井に当たります。無料枠の使い切り方はZapier無料プランで月100タスクを最大活用する初期設定ガイドで詳しく整理しています。最新の枠はZapier公式料金ページで確認してください。
フラッド保護（100ステップ超）で止まる
Zapierが新しいデータを確認したときに100を超えるステップが一度に発生すると、フラッド保護が働いて実行が保留されます。CSVの一括取り込みや大量メールの受信でよく起きる止まり方です。対処は、キュー後の遅延（Delay after queue）アクションを挟んで順番に処理させること。なお、1つのZapが100ステップを超える構成そのものも保留の対象になるため、その場合はZapを分割します。
止まる原因になりやすいプラン要因
- プレミアムアプリ・機能の利用：契約プランに含まれない機能を使うステップは保留されます。
- 支払い情報の期限切れ：カードの有効期限切れでも保留になります。復旧後にリプレイが必要です。
- 管理者によるアプリ制限：Team/Enterpriseでは、管理者が許可していないアプリのステップは実行されません。
原因別の対処法③：トリガーが発火しない
Zap履歴に実行そのものが記録されていないケースです。ここは「壊れている」と「まだ動いていないだけ」の区別が肝心です。
ポーリング間隔による遅延を故障と誤認しない
Zapierのトリガーには、更新を定期的に見に行くポーリング型と、即時に発火するInstant型があります。ポーリング型の確認間隔はプランによって1〜15分の幅があり、Instantと明記されたトリガーだけがプランに関係なく即時実行されます（出典：Zapier公式ヘルプ「Zap trigger and action timing」）。無料・下位プランで「反応が遅い＝壊れた」と判断してZapを作り直すのは、いちばんもったいない失敗です。まず15分待ってから判断してください。
トリガー条件・フィルタの設定ミス
「新規行が追加されたとき」のトリガーは、多くのサービスで最終行への追加のみを検知します。途中行の挿入や、数式で値が入っただけのセルは新規データとみなされません。フィルタステップを入れている場合は、条件が厳しすぎて全件が弾かれていないかをZap履歴の「Filtered」件数で確認します。
アプリ側の仕様変更・共有設定
フォルダの共有解除、スプレッドシートのシート名変更、Webhookの受け口URL変更など、連携先の変更でも発火しなくなります。自動化が止まったタイミングと、その週に社内で行った設定変更を突き合わせると、原因が一発で見つかることが多いです。
【独自】症状別の切り分け早見表と復旧コストの試算
症状×原因×最初にやること 早見表
| 症状 | 疑うべき原因 | 最初にやること |
|---|---|---|
| Zapのトグルがオフになっている | エラー率95%超による自動停止 | 直近のエラー内容を修正してからオンに戻す |
| 履歴が「On hold」だらけ | タスク上限・認証切れ・フラッド保護 | アカウントの請求状況と接続アプリを確認 |
| 履歴が「Errored」で止まる | 必須項目の欠落・データ書式 | 失敗した実行の入力データを開いて突き合わせ |
| 履歴に実行が1件もない | トリガー未発火・ポーリング待ち | 15分待ち、トリガー条件と共有設定を確認 |
| 一部だけ流れない | フィルタ条件が厳しすぎる | Filteredの件数と条件式を確認 |
独自試算：気づくのが遅れたときの手戻りコスト
問い合わせフォームからのChatwork通知を自動化していた会社で、認証切れに5営業日気づかなかったケースを想定します。1日8件の問い合わせなら40件が未通知。1件あたりの掘り起こし・謝罪対応を10分とすると約6.7時間の手戻りで、時給3,000円換算で約2万円の人件費です。上位プランへの月額差額が数千円なら、通知とAutoreplayを整えるほうが安く付く計算になります。止まること自体より、止まったことに気づかない時間の長さがコストを決めると考えるのが実務的です。
現場でよくある失敗3つ
- 失敗1：エラー通知メールが担当者個人にしか届いていない——不在の週にZapが止まり、誰も気づかないまま自動オフ。通知はチーム共有のアドレスかチャットに飛ばします。
- 失敗2：再接続だけして満足する——リプレイをしていないため、止まっていた期間のデータが永久に欠落します。
- 失敗3：作り直して原因を消してしまう——Zapを新規作成すると履歴が追えなくなり、同じ原因で翌月また再発します。まず履歴を読むのが先です。
「止まる前提」で組む再発防止の運用設計
自動化は必ずいつか止まります。復旧の速さを設計に織り込んでおくと、被害はほぼゼロに抑えられます。
通知の宛先をチームにする
Zapierのエラー通知の送信先を、個人メールではなく共有アドレスやチャットのチャネルに向けておきます。Chatworkを使っているなら、通知の自動送信そのものをAPIで組めます。設定手順はChatwork APIの使い方｜トークン取得と通知の自動送信手順にまとめています。
AutoreplayとエラーハンドリングでZapを落とさない
一時的なAPI障害はAutoreplayで自動的に拾い直せます。さらに、エラー時に代替処理を走らせるエラーハンドリングを設定しておけば、ステータスが「Handled error」となり、Zapの自動オフを回避できます。エラー率95%という自動停止の条件を踏まえると、この2つは早めに入れておく価値があります。
「Zap任せにしない」線引きを決める
給与振込データの生成や請求の締めなど、止まった時の影響が大きい処理は、自動化しても人が最終確認するチェックポイントを1つ残すのが安全です。どこまでをZapierで担い、どこからを別ツールや手作業に残すかは、ツール選定の段階から考えておくとブレません。他の自動化ツールとの向き不向きはワークフロー自動化ツール比較｜Zapier・Make・n8nの選び方で比較しています。
まとめ：履歴を読めば原因はほぼ3系統に絞れる
ZapierのZapが動かないときは、(1)Zap本体が95%エラーで自動オフになっていないか、(2)アプリの認証切れ・タスク上限で保留になっていないか、(3)そもそもトリガーが発火しているか——この3点をZap履歴のステータスから切り分ければ、原因の大半は数分で特定できます。復旧後はリプレイで取りこぼしを回収し、通知先をチームに変え、Autoreplayを有効にしておく。この3つを済ませておけば、次に止まったときの復旧時間は大きく短縮できます。まずは今動いているZapの通知先が個人メールになっていないか、確認するところから始めてください。
