クライアント先で通知が倍になった朝

先月、コンサル先のスタートアップから「Slackの通知が突然2倍に増えた」と連絡が入った。調べてみたらZapierのフィルターでANDとORを取り違えていた。たった1箇所の条件分岐ミスで、50人のチーム全員に余計な通知が3日間飛び続けていたことになる。

結論。ノーコード自動化ツールのフィルター条件ミスは「AND / ORの取り違え」「データ型の不一致」「トリガー差し替え後の参照切れ」に集約される。本番稼働前にテスト用チャンネルで3日間回せば防げるし、Zapier・Makeの無料プランがどこで限界に当たるかもタスク数で線を引ける。

フィルター条件で起きやすいミスのパターン

AND+ と OR+ の取り違え

最も多い。「件名に『請求書』または『Invoice』を含むメールだけ通知する」という条件を組むとき、AND+を選ぶと「両方を同時に含むメール」しか通過しない。実質ゼロ件だ。逆に、絞りたいのにOR+で書くと片方でも当てはまれば全部通過してしまう。冒頭のクライアントもこのケースで、「優先度：高のみ」にしたかったのに「高 OR 中」で設定した結果、通知量が2倍になった。

Zapierの公式ヘルプでもAND/ORの使い分けは「最もよくある設定ミス」として注意喚起されている。Makeのルーター分岐でも同じ構造の問題が起きるので、ツールに関係なく最初に疑うべきポイントだ。

データ型の不一致

数値フィルターに文字列が流れ込むケース。「金額が10,000以上」で止めたいのに、連携元のアプリが金額を「10,000円」というテキストで渡していると、フィルターが数値として認識できず全件通過する。日付も同じで、「2026/05/26」と「May 26, 2026」ではフォーマットが違うため日付比較のフィルターが効かない。

Zapierの公式ヘルプには「number filters only work with numeric values」と明記されている。フィルターが素通りしているように見えたら、まずDATA INで値の型を確認するのが鉄則だ。

トリガー差し替え後の参照切れ

途中でトリガーのアプリやイベントを変更したとき、フィルターが参照しているフィールドが旧トリガーのまま残っていることがある。Zapierはフィールドが見つからなくてもエラーを出さず、空データとして通過させる場合がある。フィルターが効いていないのに数日気づかない。筆者がクライアント先で何度か遭遇したパターンだ。

実行ログで「何が通過したか」を確認する

条件ミスを見つけるなら実行ログが最速だ。

Zapier：Zap Historyで Filtered 率を計算する

Zap Historyページで各実行のステータスを確認できる。フィルターで止まった実行は「Filtered」と表示される。ここを見るのが基本だ。

筆者が最初に確認するのは直近24時間のFiltered率（止まった件数 ÷ 全実行件数）。たとえば営業リードの通知で「優先度：高のみ通過」なら、全リードの20〜30%しか通過しないはずだ。Filtered率が50%を切っていれば条件が緩すぎると読める。各ステップの「DATA IN / DATA OUT」をクリックすれば、フィルターに入った実データと判定結果が1件ずつ追える。

Make：シナリオ実行履歴でルート別の通過数を見る

MakeではシナリオのHistoryタブに実行ログが残る。各実行をクリックするとモジュール単位でデータフローが視覚的に表示される仕組みだ。フィルターモジュールの入出力バブルを開けば、どのデータがどの条件で通過・遮断されたか一目で把握できる。

Makeは1シナリオ内で複数のルート分岐を組めるのが強みだが、分岐が増えると「どのルートを通ったか」の確認が複雑になる。ルートごとの通過件数を定期的にチェックする運用を入れておくべきだ。

本番稼働前のテスト運用で事故を防ぐ

前職の社内IT推進部でSlackの通知自動化を新しく組むたび、筆者は「テスト用チャンネル」で3日間の試運転を挟んでいた。800名に飛ぶ通知を直接つないで間違えたときのダメージは、50名のスタートアップとは比較にならない。この習慣はZapier・Makeでもそのまま使える。

テスト用の通知先を分離する

本番のSlackチャンネルやメール宛先に直接つながない。テスト用チャンネル（例：#automation-test）を作り、そこに通知を飛ばす設定にする。万が一フィルターが壊れていても被害はテストチャンネルに閉じる。

正例と負例を両方流す

通過すべきデータ（正例）だけテストして「動いた」で終わらせるのが最も危険だ。止まるべきデータ（負例）が本当に止まるかの確認が欠かせない。Zapierの公式トラブルシューティングでも正例・負例の両方を流すよう推奨されている。

エッジケースを意図的に流す

空白フィールド、大文字小文字の混在、数値に「円」が付いた文字列。本番で問題になるのは、たいてい「想定外のデータ形式」が入ってきたときだ。テスト段階で壊れたデータを意図的に流しておく方が、本番で暴走するより遥かにコストが安い。

3日間のFiltered率を計測して判断する

テスト用チャンネルで3日間稼働させたあと、Filtered率を想定値と比較する。5ポイント以上のズレがあれば条件を見直す。問題なければ通知先を本番チャンネルに切り替える。前職でSlackのStandard→Plus移行の見積を3度作り直した経験からも言えるが、「テストで1回動いた」だけで本番に投入すると結局やり直しになる。

無料プランの限界ライン——タスク数とコストの損益分岐

テスト手順と並んで重要なのがプラン選定だ。2026年5月時点のZapier・Makeの主要プランを比較する。

項目Zapier FreeZapier ProfessionalMake FreeMake Core
月額（年払い時）0円約4,500円（$29.99）0円約1,350円（$9）
月間タスク / クレジット100タスク750タスク1,000クレジット10,000クレジット
ステップ数2ステップまでマルチステップ制限なし制限なし
フィルター利用可利用可利用可利用可
実行履歴の保持制限ありより長期間制限ありより長期間

見るべきは「自分の自動化がひと月に何タスク消費するか」だ。Zapierではアクションが1回実行されるたびに1タスク消費する。マルチステップZapでは各アクションがそれぞれ1タスクとしてカウントされる点に注意したい。Makeでは各モジュールの実行が1クレジットに対応する。

具体的に試算してみる。営業リードの通知を1日10件、経費精算のSlack通知を1日5件、週次レポートの自動送信を週1回。この3つの自動化を運用するケースだ。

  • 営業リード通知：10件/日 × 30日 = 300タスク/月
  • 経費精算通知：5件/日 × 20営業日 = 100タスク/月
  • 週次レポート：1件/週 × 4週 = 4タスク/月
  • 合計：404タスク/月

Zapier Freeの100タスクでは最初の自動化だけで月間枠を使い切る。Professional（750タスク、月約4,500円）なら404タスクに余裕がある。一方Makeなら同じ運用がFreeの1,000クレジット内に収まる可能性が高い。

コスト単価で比べると、Make Core（月約1,350円で10,000クレジット）はZapier Professional（月約4,500円で750タスク）の3分の1以下だ。ただしZapierはアプリ連携数が多くUIも直感的なので、導入や運用の人件費まで含めた総コストで判断しないと見誤る。ツール単価だけで選ぶと、結局やり直しになるケースを何度も見てきた。

判断基準はこうなる。月400タスク以下ならMake Freeで回る可能性が高い。400〜1,000タスクの範囲ではMake Core（月1,350円）がコスト効率で有利だ。Zapierを選ぶ合理性があるのは、Make側に対応アプリがない場合か、既存のZapが多すぎて移行コストが見合わないケースに限られる。

FAQ

Zapierのフィルターが効いているか確認する方法は？

Zap Historyページでステータスが「Filtered」になっている件数を確認する。止まるはずのデータが「Success」で通過していたら、条件設定が間違っている。各ステップの「DATA IN / DATA OUT」で実データを1件ずつ確認できる。

Zapierの「タスク」はフィルターで止まった分もカウントされる？

されない。タスクはアクションが実行されたときにだけ消費される。フィルターを正しく設定すれば不要な実行を止めてタスク消費を抑えられるので、フィルター設計はコスト管理にも直結する。

ZapierとMake、どちらを選ぶべき？

月間タスク数が1,000以下でコストを抑えたいならMake。対応アプリの数や設定UIのシンプルさを重視するならZapier。既にどちらかで自動化を複数運用しているなら、移行コストを考慮してそのまま継続する方が合理的だ。

フィルター条件を変更したら既存の自動化はどうなる？

Zapier・Makeともに、フィルター条件の変更は保存した瞬間から新しい実行に適用される。過去の実行には影響しない。変更後は正例・負例を再テストすること。

参考文献