転記と通知の自動化はどれを選ぶかMake・n8n・Zapierを運用と課金で比較

対象は、少人数で申込受付を担当し、毎回のコピーや通知の漏れを減らしたいチームです。フォームから届く回答ID、氏名、連絡先、参加回を受付台帳へ1行追加し、担当者のSlackへ1通送ります。3製品とも、このようにアプリの間でデータを渡し、次の操作を動かす自動化サービスです。

選定では、フォーム、Google Sheets、Slackというアプリ名があるかに加え、必要な操作まで確かめます。新しい回答を受け取る、行を追加する、回答IDで既存行を探す、指定チャンネルへ投稿する操作は、それぞれ別の接続設定です。アプリ側の契約や管理者の許可が必要な場合もあります。

まずは「1件受信、1行追加、1通知」を共通の比較条件にします。AIを加えるのは、自由記述を要約する、問い合わせを分類するなど、内容の判断が必要になった段階です。氏名や日付の転記は、項目をそのまま対応させれば済みます。

以下の機能・料金は2026年9月5日に確認した公式資料にもとづきます。利用量の表は、条件を固定して計算した見積もりです。3製品を実際に接続した実測や、操作の速さを競う評価ではありません。

最初の候補は、担当者が翌月も変更と復旧を続けられるかで絞れます。下表の「試す理由」は、各社の仕様を申込受付へ当てはめた編集部の判断です。三つとも分岐やAPI接続を扱えるため、一つの機能だけで向き不向きを決めないようにします。

独自のAPI処理があるから必ずn8n、分岐があるから必ずMake、という選び方にはしません。既成の接続で必要な項目を扱えれば、独自コードを保守する仕事は減ります。一方、担当者がコードとデータの流れを確認できるなら、n8nで変換処理までまとめる選択肢があります。

n8nのCommunity Editionは、利用条件のある無料の自己運用版です。サーバーの更新、認証情報、バックアップ、障害復旧は自分たちで管理します。Cloudと比較するときは、ライセンス料に加えてその費用と担当者を見積もります。外部AIやSlackへ接続すればデータはその接続先にも渡るので、自己運用だけで社外送信を防げるわけではありません。

無料枠は「何件までか」と「どこまでつなげるか」を分けて読みます。特にZapier Freeの2段階は、開始のきっかけと、その後の操作一つです。受信した後に転記と通知を続ける今回の手順を、一つのZapでそのまま組める枠ではありません。

金額は各社公開ページの年払い条件で、月払いの請求額ではありません。USDとEURを円換算して順位は付けていません。税、外部アプリ代、AI API代はこの表に含めず、契約画面で確認します。Zapierはタスク枠に応じて価格が変わるため、上の入口価格を月1,000件の受付費用として使うこともできません。

フォームが回答の到着を知らせるWebhookに対応していると仮定します。Webhookは、新しい回答が来たときに、自動化サービスの受信先へデータを送る仕組みです。1件ごとに起動し、Google Sheetsへの追加とSlackへの通知が各1回成功する場合、数え方は次のようになります。

これは正常系だけの机上計算です。Makeでは1件が一つのデータ単位として後続へ渡り、通常の処理を各1回行う条件です。再送、失敗後の再試行、重複確認、AI、追加の応答処理は含めていません。フォーム側がWebhookを送れない場合は、次節の定期確認型などへ見積もりを変えます。

この条件の月1,000件なら、MakeはCoreの10,000クレジット枠内、n8n CloudはStarterの2,500実行枠内です。Zapierは入口の750タスク枠では足りず、2,000タスク以上を扱える条件で見積もり直します。他の自動化も同じ契約枠を使う場合は、その消費を足してください。

次に、CRM登録、確認メール、別台帳への保存、監査記録を各1回足し、外部アプリの操作を2個から6個へ増やすとします。いずれも通常の課金対象操作で、毎回すべて動くという条件です。

ここから分かるのは、受付件数が同じでも、処理の追加が契約枠へ与える影響は違うということです。n8nも実行時間や外部APIの利用は増えます。実行数が一定だから、どこまでも無料で処理を増やせるという意味ではありません。

また、画面上の部品をすべて同じ料金で数えるのも不正確です。ZapierのFilter、Paths、Formatterなどはタスクを消費しません。Makeも、経路を分けるRouter自体はクレジットを消費せず、その先の処理が消費します。AIを追加する場合は、通常の操作数とは別に、AI提供元への支払いや機能ごとの利用量を確認します。

月額の見積もりで見落としやすいのが、回答を待つ間の動作です。回答の到着時に起動する方式に対し、定期確認型は新着がなくても確認へ行きます。15分ごとに30日間、休みなく確認すると、回数は「4回×24時間×30日＝2,880回」です。

Makeの公式チュートリアルでは、Google Sheetsの「Watch New Rows」が定期的に新しい行を確認し、その確認にもクレジットを使います。そこで、フォームの回答が入る表を監視し、別の受付台帳へ転記して通知する構成なら、見積もりは「確認2,880＋転記1,000＋通知1,000＝4,880クレジット」です。追加の検索や再試行などは含めていません。

Makeのこの設定では、確認だけでFreeの1,000クレジットを超えます。n8n Cloudでも、Schedule Triggerを使うとStarterの2,500実行を超えます。一方、n8nのアプリ用Polling Triggerは空の確認を数えません。同じ「15分ごと」でも、どの部品から始めたかまで揃える必要があります。

Webhookへ変える場合は、フォーム側がその送信に対応するかを先に確かめます。定期確認を続けるなら、通知を何分まで待てるか、営業時間外も確認するかを決めると、必要な回数に近づけられます。

受付台帳への追加は成功し、Slackへの通知だけがエラーになった状態です。ここで最初から流し直すと、台帳へ同じ申込を追加する可能性があります。選定時には、履歴を見る機能と、失敗した部分を戻す機能を別々に確かめます。

n8nの過去実行のRetryを、常に先頭からすべてやり直す操作とは扱いません。公式の説明と公開実装では、保存された実行データを使って再開します。分岐やループ、異常終了では再実行範囲を履歴で確認してください。

通知の再試行にも注意が必要です。タイムアウトは、通知先へ届かなかった場合だけでなく、届いた後に応答が戻らなかった場合にも起き得ます。実行履歴に加え、回答IDを手掛かりにSlack側の投稿を照合します。送信済みなら重ねて送らず、未送信なら通知をやり直してください。届いたか判断できなければ担当者の確認へ回します。図はこの復旧方針の設計例で、各製品が同じ手順を自動で保証するものではありません。

台帳には回答IDを残し、追加前に既存行を探すか、同じIDの行を更新する設計を検討します。ただし、二つの実行が同時に「未登録」と判断すれば、検索だけでは重複を防げません。厳密な一意性が必要なら、IDの重複を受け付けないデータベースや、実行順序の制御まで比較対象です。これらの追加処理は、先ほどの単純な利用量の表へ加算します。

障害に気付く速さも採用条件になります。ZapierはAutoreplayを有効にした場合、最後の再試行が失敗するまでエラーメールを送らないと説明しています。n8nの障害通知用ワークフロー（画面上の Error Workflow）も、担当者へ知らせる経路を用意する機能であり、転記済みの行を取り消す機能ではありません。「通知が1時間遅れると困る」なら、再試行の設定と障害連絡のタイミングを一緒に試してください。

試用の合格条件は、処理が緑色で終わったことだけでは決まりません。台帳と通知先が正しく、同じ申込をやり直せて、担当者が原因を追えるところまでを一組にします。次はテスト用フォーム、台帳、通知先で行う試験の提案です。実行済みの検証結果ではありません。

月間費用は、この記録から「自動化サービスの料金＋外部アプリ・AIの料金＋保守と復旧の工数」で見直せます。短い転記・通知で既成接続が揃うならZapier、分岐経路とデータ件数を画面で管理するならMake、処理の追加と独自変換を技術担当者が引き受けるならn8nを最初の試用候補にする、というのが本記事の選び方です。最後は、必要な復旧を担当者ができた記録で決めます。

転記と通知の比較メモをダウンロードして、想定値と観測値を分けて残せます。本文の利用量計算をCSVで確認したい場合も、単純な正常系の見積もりとして使ってください。サービスの基本情報は3サービスの比較ページにまとめています。