コンサル先の50名規模のスタートアップから「Slackの通知が突然2倍に増えた」と連絡が入ったのは、Zapierのフィルター条件を変更した3日後だった。営業リードの自動通知を運用していたZapで、フィルターの条件が「優先度：高のみ（AND）」ではなく「高 OR 中」に設定されていたことが原因だ。筆者がZap HistoryのFiltered率を確認して原因を特定するまで、わずか3分。修正自体は1分で終わった。
結論。Zapierのフィルター条件でANDとORを取り違えるミスは、ノーコード自動化における最頻出トラブルの1つだ。通知が急に増減したら、まずZap HistoryのFiltered率を確認すれば原因の切り分けは数分で済む。
コンサル先でSlack通知が3日間倍増した原因はフィルター1行のミスだった
Zapierのフィルターステップでは、複数条件を組み合わせるときに「AND」か「OR」を選ぶ。この選択を間違えるだけで、通知量が劇的に変わる。
AND条件は「すべての条件を同時に満たすデータだけ通す」。OR条件は「どれか1つでも満たせば通す」。言葉にすると単純だが、実際の設定画面では条件の間に小さく表示される「and」「or」の切り替えを見落としやすい。Zapier公式ヘルプにもAND/ORの違いは記載されているが、設定画面上のUIは控えめで、慣れた管理者でも変更時に見逃す。
| 設定 | 通す条件 | 通知量の変化 |
|---|---|---|
| 優先度 = 高 AND ステータス = 新規 | 高かつ新規のリードのみ | 絞り込まれる |
| 優先度 = 高 OR ステータス = 新規 | 高いリード、または新規のリード | 和集合で増加する |
筆者のコンサル先で起きたケースでは、「優先度：高」だけに絞るはずのフィルターが「高 OR 中」になっていた。中優先度のリードまで全部Slackに流れ、50名のチーム全員に届く通知が約2倍に膨れた。3日間、誰も設定変更に気づかなかったのは、通知が「増えた」ことよりも「減ってないから問題ない」と判断されたからだ。
ノーコードツールのフィルターは、コードを書かない分だけ設定画面の小さな切り替えに意味が集中する。ANDとORの取り違えは、Zapierに限らずMakeやPower Automateでも同じ構造で発生するミスだと考えるべきだ。
Zap HistoryのFiltered率で原因を特定する
フィルター条件のミスを見つける最速の手段は、Zap Historyだ。
Filtered率とは、フィルターステップで止められた実行件数を全実行件数で割った値。正常な運用であれば、フィルターの目的に応じた想定値がある。「優先度：高のリードだけ通す」設計で全リードのうち高優先度が20%なら、Filtered率は約80%になるはずだ。この想定値と実績値のズレが、条件ミス発見の最も確実な手がかりになる。
確認手順（2026年6月時点）：
- Zapierにログインし、左メニューから「Zap History」を開く
- 対象のZapをフィルターで選択する
- 「Task usage」タブで期間を指定し、Filtered（止まった件数）とSuccess（通過した件数）の比率を確認する
- Filtered率を計算する：Filtered ÷（Filtered + Success）× 100
- 想定値と比較する。想定80%のはずが20%なら、フィルターが緩すぎる
筆者のケースでは、変更前のFiltered率が約75%だったのに対し、変更後は30%まで下がっていた。4件中3件を止めていたフィルターが、10件中3件しか止めなくなっていた。この数字を見れば、フィルター条件が意図どおりに動いていないことは一目で分かる。
Zap Historyのデータ保持は最大60日間、表示件数は10,000件まで。フィルター変更を行った日付が分かっていれば、その前後のFiltered率を比較するのが確実だ。変更日が不明な場合でも、Filtered率が急変したタイミングをグラフで探せば特定できる。
テスト用チャンネルで試運転を挟む
フィルター条件を修正したら、いきなり本番チャンネルに戻さない。テスト用のSlackチャンネルを1つ作り、そこに3日間だけ通知を流して正例と負例の両方を検証する。
正例とは「通知が届くべきデータが届いているか」、負例とは「通知が届くべきでないデータが止まっているか」の確認だ。フィルターのテストでは、通す側だけでなく止める側の検証を忘れると再発する。
テスト運用の進め方：
- Slackに「#test-zapier-notification」のような名前でチャンネルを作成する
- ZapのSlack送信先をテストチャンネルに一時的に変更する
- 3日間運用し、通過した通知の内容を目視で確認する
- Zap HistoryでFiltered率が想定値と一致しているか再確認する
- 問題なければ本番チャンネルに戻す
3日間という期間は、営業リードや問い合わせなど一般的な業務通知であれば十分なサンプル数が集まる目安だ。日次バッチ系の通知なら5日間に延ばすほうが安全だと判断する。テストチャンネルの作成と送信先の切り替えは合わせて5分程度。再発防止の効果と比べれば、極めて合理的な投資だ。
フィルターが複雑化したらツール選択を再検討する
フィルター条件が3段階以上のAND/OR組み合わせになったら、Zapierで運用し続けるべきか立ち止まるタイミングだ。
Zapierは設定画面がシンプルな分、条件分岐の可視性が低い。フィルター→Paths→さらにフィルターと重ねると、全体のロジックを俯瞰しにくくなる。Make（旧Integromat）はビジュアルキャンバス上にフローを描くため、条件分岐が複雑になるほど視認性で差が出る。
| 比較項目 | Zapier Professional | Make Core |
|---|---|---|
| 月額（年払い） | 29.99ドル / 750タスク | 10.59ドル / 10,000オペレーション |
| フィルター条件の可視性 | ステップ内テキスト表示 | キャンバス上にノードで表示 |
| 連携アプリ数 | 7,000以上 | 3,000以上 |
| 条件分岐が3段以上 | Pathsで対応可能だが視認性低下 | ルーターで分岐を視覚化 |
| チーム利用（複数ユーザー） | Team 年払い69ドル/月〜 | Teams 年払い18.82ドル/月〜 |
コスト面ではMakeが大幅に安い。ただし連携アプリの数はZapierが約2倍あるため、使いたいアプリがMakeに対応しているかを事前に確認する必要がある。
筆者の判断基準は明快だ。フィルター条件が2段階以下で、連携先がZapier固有のアプリを含むならZapierを続ける。条件分岐が3段階以上、またはループ処理が必要ならMakeへの移行を検討する。50名規模のチームでZapier Teamを使っている場合、Make Teamsに切り替えるだけで年間約600ドルの差額が出る。ただし移行工数（Zap→Scenarioの作り直し）を管理者の時給で換算してから判断すべきだ。移行対象のZapが5本以内なら、管理者1名の半日作業で終わるケースが多い。
FAQ
Zapierのフィルターで「Filtered」になった実行はタスク消費にカウントされるか
フィルターステップ自体はタスクを消費しない。ただしフィルターの前に実行されたアクションステップがあれば、そのステップ分のタスクは消費される。トリガーで起動し、2ステップ目のフィルターで止まった場合はタスク消費1件だ。Zapier公式ヘルプに計測ルールの詳細がある。
AND/ORの設定ミスを防ぐためにフィルター条件をドキュメント化すべきか
50名以上のチームであれば、Zapの名前にフィルターの意図を書き込むのが最もコストの低い方法だ。例:「営業リード通知（高優先のみ・AND条件）」。別途ドキュメントを作ると更新が追いつかなくなるため、Zap名に集約するほうが合理的だと判断する。
Make（旧Integromat）でも同じAND/ORミスは起きるか
構造は同じなので起きる。ただしMakeはフィルター条件がキャンバス上のノード間にテキスト表示されるため、ANDかORかが視覚的に分かりやすい。複雑な条件分岐を多用するチームがMakeを選ぶ理由の1つだ。
Zap Historyのデータは何日間保持されるか
2026年6月時点で最大60日間、10,000件まで表示される。フィルター変更の影響を検証するには変更前後のFiltered率比較が必要なため、変更日から60日以内に確認すること。Zapier公式: Zap Historyを参照。
参考文献
- Add conditions to Zap workflows with filters — Zapier Help, 2026年
- What's the difference between "and" and "or" logic in filters and paths? — Zapier Help, 2026年
- View and manage your Zap history — Zapier Help, 2026年
- How is task usage measured in Zapier? — Zapier Help, 2026年
- Plans & Pricing — Zapier, 2026年6月確認
