Zapier FilterとPathsの使い分け

この記事はZapier公式ヘルプを照合したLevel A解説です。編集部がアカウントを使って条件分岐や通知をテストした体験談ではありません。

結論：止めるならFilter、行き先を変えるならPaths

Zapierの条件分岐は、「1本のZapを必要なときだけ実行する」のか、「条件に応じて実行する仕事そのものを変える」のかで選びます。

• Filter：条件に合わなければ後続のActionへ進めない。1つのルートを通す/通さないための関門。
• Paths：条件によって複数のルートへ処理を分ける。例えば問い合わせ種別が「販売」なら営業チームへ、「保守」ならサポートへ。

二択ならいつでもPathsというわけではありません。「不要なものを止めたい」だけなら、枝を増やさない方が運用は単純です。条件分岐は道路建設ではありません。必要な道だけ引きましょう。

一次資料：Zapier Conditional logic: Filter and Paths

1. 例：フォーム問い合わせをSlackへ通知する

まず次の架空の業務を考えます。新しい問い合わせが来たら、フォームの種類と緊急度に応じて通知を送るか判断する運用です。

これらは例示用のフィールドと業務ルールであり、Zapierの既存テンプレートを動かした実績ではありません。顧客の個人情報を無制限にSlackへ転送する設計は避けてください。

2. Filterを使う：条件に合わないActionを実行させない

Zapier公式のFilterルールは概ね前段のフィールド／演算子／比較値の3要素から組み立てます。

1. Triggerを選び、対象アカウントを接続します。テスト用のデータを用意してTriggerをテスト。
2. 後続にFilterステップを置きます。
3. 判定したい前段フィールド（例：案件区分）を指定し、比較条件（例：Exactly matches）と値（例：営業）を入力します。
4. まず「営業」テストレコードで通過、「保守」で停止する想定を検証します。
5. 通過後だけ通知Actionを実行するようにします。

公式はFilterを一つの条件セットで後続ステップを実行するか判定するものとして説明しています。実際のフィールド名・利用可能な演算子は選択するアプリやデータ型で異なります。

見逃しやすいのは、停止したこと自体が必ずエラーというわけではない点です。条件に合わない通知を意図的に止めるのがFilterの仕事だからです。

一次資料：Conditional logic / Zap trigger setup

3. Pathsを使う：内容ごとに処理を振り分ける

Pathsを選ぶのは「営業部への通知」と「サポート部への通知」が異なる業務になる場合です。

• Path A：営業問い合わせ → 営業チャンネルへ通知
• Path B：保守問い合わせ → サポート窓口へ通知
• Fallback（必要なら）：いずれにも合わない → 担当者が見る保留箱へ送る

公式ドキュメントによると、PathsにはCustom rules、Always run、Fallbackという考え方があり、Fallbackは該当する他の分岐がないときの最後の経路にできます。FallbackとAlways runを同じ分岐グループへ同時設定できないなどルールにも制約があります。

単に「分岐の数が多いほど高機能」ではありません。AとBの条件が重なると、想定しない複数アクションが走る可能性があります。通知先が2つ必要な業務か、それとも入力条件が曖昧なだけかを先に確認します。

プラン表示の整合性に注意（2026-10-15）：Zapierの公式「Use conditional logic」ページにはFreeを利用可能と読める表記がある一方、Filter個別手順のPrerequisitesはpaid plansと記載し、Paths説明やMulti-step Zap要件にも制約が残っています。したがって、Filter/Pathsを「Freeで全機能を確実に利用可能」「Pathsは必ず有料限定」のどちらとも断定しません。現在の契約画面で、対象機能、Multi-step Zap、Legacy plan差を確認してください。 公式条件分岐の概要 / Filter個別手順 / Multi-step Zap

課金上の注意：Zapier公式の変更案内は現行プランのFilter・Formatter・PathsのTask計数条件が従来と異なることを説明しています。課金の正確な適用条件・契約移行はA15と契約画面で確認してください。 公式Plan変更案内

一次資料：Zapier Conditional logic

4. ANDとORを間違えると「動かない」ように見える

条件を複数指定する場合、AND（両方）／OR（どちらか）を変えるだけで実行結果は変わります。

架空の例：案件区分＝保守、緊急度＝高。

• 案件区分が保守 AND 緊急度が高：緊急の保守だけ送る
• 案件区分が保守 OR 緊急度が高：保守全体に加え、営業の緊急案件も送る

判断をコードのように考えると、ルールに漏れがないか見えやすくなります。初期設計では、通過させたいサンプル2件と、止めたいサンプル2件を用意してテストしてください。これは編集部が推奨する確認法で、実機テストを実施したという意味ではありません。

5. Zapが止まったら、履歴から「意図した停止」を見分ける

Zapier公式HelpはZap runの状態を区別しています。特にSafely haltedのような意図的停止と、Erroredを混同しないことが重要です。Zap Historyの該当実行を開き、どのStepで何が起きたかを確認します。

なお、ZapierのActionテストは接続先へ実データを送信・作成することがあります。テストは本番顧客レコードではなく、ダミーの宛先・非公開チャンネルで行います。

一次資料：Troubleshoot errors / Set up action: live tests

6. Tasksを概算するときは、停止した後を追いかけない

Filterを追加しただけでTaskがどうなるかを、公式確認なしに数字で断定しません。Zapierの課金では、成功したActionやプラン別の仕様が関係するため、前段から実際に実行されるActionを洗い出すことが先です。

例示：問い合わせが月100件でも、営業案件だけ30件通過するなら、通知の対象数は30件です。ただし「30件＝請求30 Tasks」とは断定しません。後続に複数Actionがあれば計量は変わり、失敗・再実行・プラン制約も含めて確認が必要です。

料金や計量単位の詳細は Zapier Tasksの解説 に分けます。この記事の目的は、必要な仕事だけ動かす条件設計です。

7. Filter／Paths、どちらを選ぶ？

• 1つの通知を条件で止めたい → Filterを先に検討
• 通知先や後続の処理が条件で異なる → Pathsを検討
• 入力値の表記揺れが原因 → 条件追加より入力データの正規化や前処理を検討
• 複数ルートを作っても処理が同じ → 本当に複数ルートが必要か再考

「どう設定できるか」より先に「どういう場合は動かしてはいけないか」を決める方が、誤通知を減らせます。

まだ調べますか？

• Zapierとは？ — 基本・接続の選択
• ZapierのTasksとは？ — 条件が料金見積もりへ及ぼす影響
• n8n vs Zapier — より複雑な分岐・運用の比較

判断の出口： まずFilterで足りるか確認し、異なる後続業務が必要なときだけPathsを検討しましょう。

一次資料・区分

• Zapier: Conditional logic
• Zapier: Trigger setup
• Zapier: Action setup and live testing
• Zapier: Troubleshooting

FACT：Filter/Pathsの役割、条件演算・Fallback、Zap testの影響、Run Status。

EDITORIAL：例示データ、条件設計・業務判断、テスト用の4件サンプル。

未確認：アカウント別の有料機能・料金、実運用での成功率。