PerplexityかNotebookLMか、探す前と資料が揃った後で使い分ける
AI・自動化 1
ZapierかMakeか、料金差は実行回数より「数え方」で逆転する
ZapierとMakeの料金を比べるときは、月間枠の数字を業務の処理件数に直す必要がある。Zapierの料金表は無料枠を月100タスク、Professionalの開始価格を月19.99ドルと示す。一方、Makeの料金表は無料枠を月1,000クレジット、Coreの10,000クレジット枠を月9ドルと表示する。枠の大きさも価格も、そのまま「何件の注文を処理できるか」は表していない。
単純な通知ではMakeの大きなクレジット枠が有利に見え、整形を重ねた分岐ではZapierのタスク枠で処理できる件数が上回る場合がある。これは必要な枠を比べた結果であり、実際の支払額の順位を保証するものではない。対応アプリの操作、途中で増えるデータ、枠を使い切った後の扱いまで含めて選ぶのが妥当だ。
同じ実行でも、数える工程が違う
ZapierはZapを起動するトリガーをタスクに数えず、成功したアクションを基本単位とする。Makeはシナリオ内で実際に動いたモジュールをクレジットで数え、データの読み取り、検索、作成、変換も対象になる。したがって「自動化を月に何回動かすか」だけでは、どちらの消費量も決まらない。
両社とも例外がある。ZapierのFormatter、Filter、Pathsは通常のタスクに数えられない一方、AIやコードなどの処理には別のタスク率が適用されることがある。MakeのRouterはクレジットを消費しないが、一部のAI機能や高度な処理はモジュールの動作ごとに一定の1クレジットとは限らない。以下の試算は、通常のアクションまたはモジュールがそれぞれ1単位を使う、明示した条件に限る。
受注通知の3工程では、1件が2タスクと3クレジットになる
条件付きの例として、受注を検知し、担当者へ通知し、一覧に記録する3工程を考える。注文ごとに各工程が1回動き、通知と記録が成功するなら、Zapierではトリガーを除く2アクションで2タスク。Makeでは受注を受け取る入口、通知、記録の各モジュールが動き、計3クレジットとなる。
月1,000件を処理するには、この構成でZapierは2,000タスク、Makeは3,000クレジットを要する。逆に1,000単位の枠を仮定すれば、Zapierは500件、Makeは端数を切り捨てて333件を処理できる。この比較は同じ大きさの仮の枠で数え方の違いを示したもので、実在するプラン同士の月額比較ではない。
無料プランに当てはめると、Zapierの月100タスクは計算上50件分だが、無料プランで作れるZapはトリガーとアクションの2工程までなので、この受注通知をそのまま組めない。Makeの月1,000クレジットは、ほかのシナリオで使わず、想定どおり注文ごとに3クレジットだけ消費するなら最大333件分となる。枠に収まる計算でも、必要な工程をプラン上で作れるかは別の条件だ。
顧客登録は、重複確認の有無で消費量が変わる
フォームの送信を受けて顧客を登録し、担当者へ通知する条件付きの3工程も、すべて成功するならZapierで2タスク、Makeで3クレジットと数えられる。ここに既存顧客の検索を足すと、検索結果によって後続の登録が動くかどうかが変わる。新規と既存の割合を無視して全件に同じ単位数を掛けると、見積もりがずれる。
Zapierのタスク計測ルールでは、検索アクションは「見つからなくても続行する」設定なら1タスク、続行しない設定ならタスクを使わない。トリガー、Filter、Paths、条件により動かなかった工程もタスクに含まれない。検索を加えたら必ず全件が1タスク増える、という計算にはできない。
Makeで検索モジュールが顧客ごとに1回動く構成なら、その検索にも通常は1クレジットを見込む。たとえば検索後に新規顧客だけを登録し、通知まで進める場合、新規分は入口、検索、登録、通知で計4クレジットになる。既存分は登録を通らないため、実際に動いた入口、検索、通知などの経路だけを数える。通知を既存顧客にも送るかによって、月間合計はさらに変わる。
10工程の分岐では、通らない箱を足さない
もう一つの条件付き例として、入口のトリガー1工程、共通の整形6工程、分岐1工程、各分岐先のアクションが1工程ずつある、図面上は計10工程の自動化を考える。各案件は片方の分岐だけを通り、共通の整形はそれぞれ1回、選ばれたアクションも1回成功すると仮定する。図に描かれた全工程を毎回実行するわけではない。
Zapierで6つの整形をタスク対象外のFormatter、分岐をPathsとして実装できるなら、1件当たりの計測対象は選ばれたアクションの1タスクとなる。Makeで同じ整形をそれぞれ動くモジュールとして実装するなら、入口1、整形6、分岐先のアクション1で計8クレジットだ。Routerと通らなかった分岐先のアクションは、この条件では加算しない。
仮にZapierの2,000タスク枠とMakeの10,000クレジット枠を処理能力だけで比べると、先の受注通知はそれぞれ1,000件と3,333件、この分岐例はそれぞれ2,000件と1,250件となる。月間枠の数字だけならMakeが大きいが、分岐例では処理可能件数の順序が入れ替わる。ただし、両枠の価格は同じではなく、この計算だけで支払額の優劣は決められない。
整形をMakeの各モジュールではなく値の割り当てなどで処理できれば、想定した8クレジットより消費は少なくなる。反対に、1件から複数の明細が生まれて後続モジュールを繰り返し動かす設計なら、入口の件数以上に消費が増える。工程図では、置かれた箱の総数と、注文1件が実際に通る回数を分けて見る必要がある。
日本向けSaaSはアプリ名より操作を照合する
国内で使うSaaSとの接続では、対応アプリの総数より、必要なトリガーやアクションがあるかが重要になる。StartLinkの比較は、Zapierで連携を検討できる日本向けサービスの例にfreee、kintone、Chatworkを挙げている。ただし、アプリ名が載っているだけでは、想定する受注検知や顧客検索をそのまま実現できるとは限らない。
MakeのKintone連携には、レコードの作成、更新、検索を行うモジュールが掲載されている。顧客登録の試算で検索と作成を別工程にしたのは、こうした操作を別々に動かす構成を想定したためだ。Zapier側でも、使いたいアプリに必要な操作があるか、検索と登録をどの工程に分けるかによってタスク数は変わる。
運用のしやすさも、画面の好みだけでは決まらない。担当者が通知先を変えるだけなら工程の少ない構成が扱いやすいが、顧客種別ごとに登録先や通知内容を変えるなら、分岐と実行履歴を追える設計が効いてくる。料金の見積もりと同じ工程図を使えば、誰がどの条件を変更するのかも具体的に判断できる。
月額は経路別の必要量から選ぶ
必要な月間枠は、受注や顧客登録の総件数に一律の単位数を掛けるのではなく、実際に通る経路ごとに計算して合算する。通知だけの注文、検索後に登録する新規顧客、登録せず終わる既存顧客、分岐先が異なる案件は、それぞれ消費量が違う。その合計を各社の枠へ当てはめて初めて、表示価格が業務量に合うかを比べられる。
上限後の扱いも費用と処理継続に直結する。Zapierは設定に応じて従量課金へ移るか、枠に達した実行を保留する。Makeはクレジットが尽きるとシナリオが止まり、上位枠への変更や追加クレジットの購入が選択肢になる。注文や顧客登録を止められない業務では、通常月の平均件数だけでなく、集中した月の必要量まで含めて枠を決めたい。
関連記事：
関連記事
ニュースレターを購読
Web3、AI、暗号資産の最新ニュースを受信箱にお届けします。
0