Make vs Zapier: 両方で同じオートメーションを実行しました

同じ週に、両方のツールで同じ 3 ステップの自動化を構築しました。フォームの送信を監視し、AI 呼び出しでそれを強化し、結果をスプレッドシートと Slack チャネルにプッシュします。 Zapier バージョンでは 20 分かかりました。 Make バージョンは 3 時間かかり、スパゲッティのように見えました。興味深いのは、その後、両方を 1 か月間実行したときに何が起こったかです。

Zapier が勝てるのはセットアップですが、それには及ばないです。トリガーとアクションのモデルでは、ソース アプリを選択し、宛先を選択し、フィールドをマップするだけで機能します。 Make はビジュアル プログラミング ツールです。モジュール、分岐、変換を含むキャンバスを構築します。その力は本物であり、私の最初の Make オートメーションにマッピングのバグがあり、それを見つけるのに午後かかったのもそれが理由です。

それから請求書が届きました。 Zapier はタスクごとに料金を請求します。タスクとは、自動化が実行するほぼ任意のステップであるため、3 ステップのフローでは、実行ごとに 3 つのタスクが書き込まれます。はるかに細かい粒度でカウント操作を行いますが、寛大な操作許容量を販売しており、数ステップを超えるものについては、その差はわずかなものではありません。同じロジックを移行するだけで、毎月の自動化コストが約 3 分の 2 減少しました。

予想外だったのは、逆に信頼性です。 Zapier の障害メッセージは明確で、アプリ接続のライブラリは膨大です。私が手動で統合したことのないツール用のネイティブ コネクタを見つけました。 2 つのアプリに必要な Webhook とフォーマッタ ステップを作成します。これは、Zapier ユーザーが無料で入手できるコードを維持することを意味します。

したがって、正直な答えは、誰がそれを実行しているかによって異なります。非技術者がワークフローを所有し、それが主流のアプリに触れる場合、コネクタ ライブラリとエラー メッセージの点で Zapier をプレミアムにする価値があります。技術者が所有している場合、ワークフローに分岐やループがある場合、またはボリュームによってタスクごとの価格設定が困難になる場合は、コストと機能の点で Make が勝ちます。オーバーラップゾーンは小さいです。

移行に関するアドバイスは誰も書いていませんが、安価なツールを使用するために動作中の Zapier を移行しないでください。実際のお金がかかり始めたとき、またはフローに Zapier が表現できないロジックが必要になったときに、それを移動します。それまでは、節約したお金よりも再建に費やす時間の方が価値があります。

よくある質問:

Q: Make は本当に Zapier より安いのですか?

A: 複数ステップの自動化の場合はその通りですが、複雑になるにつれてギャップは拡大します。 Zapier はタスクごと、つまりステップごとに請求するのに対し、はるかに大きな手当を含めて操作ごとに請求します。単純な 2 ステップのフローの場合、違いはわずかです。分岐ワークフローの場合はそうではありません。

Q: 技術に詳しくないユーザーにとってはどちらの方が簡単ですか?

A: ザピア、明らかに。トリガーとアクションのビルダーにはシステムのメンタル モデルは必要なく、エラー メッセージによって何が壊れたのかがわかります。 Make は、ユーザーがデータ マッピングを理解していることを前提としており、文句を言わずに午後 11 時にデバッグできるようにします。

Q: Zapier を Make に移行できますか?

A: はい、ただしエクスポートではなく再構築です。トリガー名はマップされますが、フィールドはマップされません。一度に 1 つのワークフローを移行し、古いワークフローを 1 か月間並行して実行し続け、新しいワークフローが実際に同等であるかどうかをログから確認します。