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

- 媒体: 知能圏（CHINOUKEN）
- 公開日: 2026-09-05
- カテゴリー: エージェント・ソフトウェア
- タグ: AIサービス比較、公式情報の比較、自動化の選定手順
- 想定読了時間: 約14分
- 調査基準日: 2026年9月5日
- 出典: 24件（末尾の「参照リンク」に番号順で記載）
- ページ: https://www.chinouken.com/articles/choose-automation-by-workflow
- このMarkdown: https://www.chinouken.com/articles/choose-automation-by-workflow.md
- 利用条件: 引用する場合は出典として「知能圏（chinouken.com）」と該当ページのURLを明記してください。本文の再配布は行わず、要約や引用の範囲で使ってください。

転記と通知の自動化は、Zapier、Make、n8nを「必要な操作を組めるか」「月に何回分を使うか」「通知だけ失敗したら誰が直すか」で比べられます。申込フォームからGoogle Sheetsへの転記とSlack通知を月1,000件行う例で、無料枠で組める手順、課金の数え方、復旧方法まで条件を揃えて比較します。

![Zapierのタスク、Makeの処理クレジット、n8n Cloudのワークフロー実行という課金単位の違いを示す図](https://www.chinouken.com/images/articles/choose-automation-by-workflow/hero.png)

*処理の数と実行の回数を、編集部が選定のための図にまとめました。実測結果ではありません。*

## 申込1件から転記と通知までを揃える

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

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

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

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

![申込フォームから回答を受信し、受付台帳へ1行追加して担当者へ通知する四つの段階](https://www.chinouken.com/images/articles/choose-automation-by-workflow/figure-intake.png)

*比較する業務は回答1件から転記と通知まで。利用量の計算では、この正常系を基準にします。*

## 最初に試す候補を分ける運用条件

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

| 比べる条件 | Zapier | Make | n8n Cloud |
| --- | --- | --- | --- |
| 最初に試す理由 | 使っているアプリの既成操作をつないで、受付を完成させたい | 参加回ごとの通知先など、分岐した経路を画面で追いたい | 独自の変換やAPI呼び出しも含め、技術担当者が保守したい |
| 処理の組み方 | 開始のきっかけと操作を並べるZap | 部品をつなぐシナリオ。RouterとFilterで経路を分ける | 部品をつなぐワークフロー。条件分岐やコードを加える |
| アプリ接続で試すこと | 追加・検索・更新が必要な項目まで扱えるか | 1回に何件のデータが返り、後続が何回動くか | 接続部品で足りるか、HTTP Requestやコードが必要か |
| 通知先を増やしたとき | 実行した課金対象の操作が増える | 条件に合って実行した経路の処理が増える | 一つの実行内なら、部品数だけで実行枠は増えない |
| 復旧の設計で見ること | 失敗部分の再実行とZap全体の再実行を区別する | 途中状態の保存と、再開する経路を設定する | 部品の再試行、障害通知、過去実行のやり直しを分ける |
| サーバーの管理 | 提供元が担当 | 提供元が担当 | Cloudは提供元が担当。自己運用版は別に選ぶ |

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

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

## 無料枠と有料プランで組める手順

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

| 確認項目 | Zapier | Make | n8n Cloud |
| --- | --- | --- | --- |
| 無料で始める枠 | Freeは月100タスク、2段階のZap | Freeは月1,000クレジット、アクティブなシナリオ2本 | 期間限定のCloud試用。継続無料のCloudプランとは別 |
| 転記と通知を一つにつなぐ | 複数操作にはProfessional以上を検討 | Freeでも複数の処理をつなげられる。消費量の上限は残る | 試用で組み、継続時は有料Cloudか自己運用を選ぶ |
| 有料の入口の例 | Professional、月750タスク | Core、月10,000クレジット | Starter、月2,500実行 |
| 年払い時の月額換算 | USD 19.99から | USD 9 | EUR 20 |
| 新着を定期確認する間隔 | Freeは15分、Professionalは2分。即時型は別 | Freeは最短15分、Coreは最短1分。即時型は別 | 選んだ開始用の部品で設定。定期起動とアプリの新着確認は課金上も別 |
| 契約前の注意 | 試用中の有料機能がFree移行後も使えるとは限らない | クレジット以外に転送量や実行時間の上限もある | Starterは同時実行5。月間実行数が収まっても集中時の条件は別 |

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

## 月1000件の転記と通知は何回分か

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

| サービスと単位 | 1件の内訳 | 月100件 | 月1,000件 |
| --- | --- | ---: | ---: |
| Zapierのタスク | 受信0 ＋ 行追加1 ＋ 通知1 | 200 | 2,000 |
| Makeのクレジット | 受信1 ＋ 行追加1 ＋ 通知1 | 300 | 3,000 |
| n8n Cloudの実行 | 受信から通知までの一連の実行1 | 100 | 1,000 |

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

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

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

| 月1,000件の構成 | Zapierのタスク | Makeのクレジット | n8n Cloudの実行 |
| --- | ---: | ---: | ---: |
| 受信＋外部操作2個 | 2,000 | 3,000 | 1,000 |
| 受信＋外部操作6個 | 6,000 | 7,000 | 1,000 |

ここから分かるのは、受付件数が同じでも、処理の追加が契約枠へ与える影響は違うということです。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クレジット」です。追加の検索や再試行などは含めていません。

| 待ち方・設定 | 新着がない確認の扱い | 月1,000件を見積もるとき |
| --- | --- | --- |
| Zapierのポーリング型トリガー | 確認そのものはタスク対象外 | 成功した転記と通知の2,000タスクを起点に数える |
| MakeのWatch New Rows | 確認でもクレジットを使う | 15分ごと・30日なら上記構成で4,880クレジット |
| n8nのSchedule Triggerで定期起動 | 新着がなくても起動を数える | 15分ごと・30日で2,880実行。各回で対象データをまとめて処理する条件 |
| n8nのアプリ用Polling Trigger | 新着がない確認は実行枠の対象外 | 新着により実際にワークフローを起動した回数を確認する |

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

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

![左は時刻ごとに新着を確認し、0件なら次回まで待つ経路。右は回答の到着通知を受けて転記と通知へ進む経路](https://www.chinouken.com/images/articles/choose-automation-by-workflow/figure-triggers.png)

*定期確認と到着通知の違いを示す概念図です。確認が利用枠に数えられるかは、製品と開始用の部品で異なります。*

## 通知だけ失敗したときの戻し方

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

| 復旧で比べること | Zapier | Make | n8n |
| --- | --- | --- | --- |
| 一時的なエラーへの備え | 有料プランのAutoreplayを有効にすると、失敗部分を自動再試行 | 不完全な実行の保存を有効にし、対象エラーの自動再試行やRetryを設定 | 部品ごとのRetry On Failを設定 |
| 途中で止まった処理を扱う | Zap Historyからエラー部分を再実行。成功済みの操作は繰り返さない | Incomplete executionsから途中状態を解決・再開する。保存は初期状態では無効 | 実行履歴で失敗を特定。障害通知用の処理を別途設定 |
| 履歴からの再実行範囲 | Entire Zapは成功済みの操作も再実行し、成功分は再びタスク対象 | Replay runは過去の受信データを全経路へ流し、クレジットも消費 | 過去実行のRetryは通常、保存済みデータで失敗ノードから再開。分岐・ループでは範囲を確認 |
| 担当者へ渡す情報 | 回答ID、失敗した操作、再実行の範囲 | 回答ID、失敗したデータ、途中状態の保存先 | 回答ID、失敗した部品、実行URL、再開方法 |

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

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

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

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

![転記成功後に通知エラーが起きたら履歴と通知先を照合し、未送信なら通知を再実行、送信済みなら完了を確認する流れ](https://www.chinouken.com/images/articles/choose-automation-by-workflow/figure-recovery.png)

*編集部による復旧の設計例です。送信結果が不明なら自動再送せず、人の確認へ回します。製品の自動保証や実測結果を示す図ではありません。*

## 採用前に残す試用記録

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

| 試す入力・状況 | 台帳と通知で確かめること | 残す記録 |
| --- | --- | --- |
| 正常な申込を1件 | 項目、行数、通知先が正しい | 回答ID、実行URL、実際の消費量 |
| 同じ回答IDを再送 | 二重行・二重通知がないか | 追加・更新・停止のどれになったか |
| 転記後に通知先を利用不可にする | 転記が残り、失敗した通知を特定できるか | 検知時刻、再開箇所、担当者への連絡 |
| 送信結果が不明な場合を想定する | 送信先で照合し、判断できなければ止められるか | 自動で再送しない条件、手動確認先 |
| 同じIDを短時間に2件送る | 同時実行でも重複対策が働くか | 実行順序、保存先の一意性、待ち時間 |
| 別の担当者へ引き継ぐ | 履歴を開き、接続の再認証と復旧ができるか | 必要権限、手順、実際にかかった時間 |

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

[転記と通知の比較メモをダウンロード](https://www.chinouken.com/downloads/tool-selection/choose-automation-by-workflow.md)して、想定値と観測値を分けて残せます。[本文の利用量計算をCSVで確認](https://www.chinouken.com/downloads/tool-selection/automation-usage-estimates.csv)したい場合も、単純な正常系の見積もりとして使ってください。サービスの基本情報は[3サービスの比較ページ](https://www.chinouken.com/tools/compare?tools=zapier,make,n8n)にまとめています。

## 参照リンク

1. [Zapierの料金とプラン: Zapierの料金とプラン](https://zapier.com/pricing)
2. [Zapierの料金体系とタスク枠: Zapierの料金体系とタスク枠](https://zapier.com/blog/zapier-pricing/)
3. [Zapier: Zapier Freeの機能と初回試用](https://help.zapier.com/hc/en-us/articles/32337438839565-What-s-included-in-Zapier-s-Free-plan)
4. [Zapierのタスク消費と対象外の処理: Zapierのタスク消費と対象外の処理](https://help.zapier.com/hc/en-us/articles/8496196837261-How-is-task-usage-measured-in-Zapier)
5. [ZapierのReplayとAutoreplay: ZapierのReplayとAutoreplay](https://help.zapier.com/hc/en-us/articles/19220226086797-What-is-replay)
6. [Zapierの新着確認間隔: Zapierの新着確認間隔](https://help.zapier.com/hc/en-us/articles/8495924437005-Control-when-your-Zap-runs)
7. [Makeの料金とプラン別の制限: Makeの料金とプラン別の制限](https://www.make.com/en/pricing)
8. [Makeのクレジットの仕組み: Makeのクレジットの仕組み](https://help.make.com/credits)
9. [Makeの通常処理とデータ件数: Makeの通常処理とデータ件数](https://help.make.com/operations)
10. [MakeのRouterとクレジット: MakeのRouterとクレジット](https://help.make.com/step-2-add-a-router)
11. [Makeの定期確認と消費量の例: Makeの定期確認と消費量の例](https://help.make.com/step-10-schedule-your-scenario)
12. [MakeのWebhookと実行順序: MakeのWebhookと実行順序](https://help.make.com/webhooks)
13. [Makeの不完全な実行の保存: Makeの不完全な実行の保存](https://help.make.com/incomplete-executions)
14. [MakeのRetryエラーハンドラー: MakeのRetryエラーハンドラー](https://help.make.com/retry-error-handler)
15. [Makeの過去実行のReplay: Makeの過去実行のReplay](https://help.make.com/scenario-run-replay)
16. [n8nの料金と実行数: n8nの料金と実行数](https://n8n.io/pricing/)
17. [n8nの開始方法別の実行カウント: n8nの開始方法別の実行カウント](https://docs.n8n.io/build/understand-workflows/understand-executions)
18. [n8nの無料試用と利用方式: n8nの無料試用と利用方式](https://docs.n8n.io/choose-how-to-use-n8n)
19. [n8nの自己運用版とプランの違い: n8nの自己運用版とプランの違い](https://docs.n8n.io/deploy/host-n8n/community-edition-features)
20. [n8nのエラー処理と障害通知: n8nのエラー処理と障害通知](https://docs.n8n.io/build/flow-logic/handle-errors-gracefully)
21. [n8nの過去実行のRetry: n8nの過去実行のRetry](https://docs.n8n.io/build/understand-workflows/understand-executions/view-all-executions)
22. [n8nの部品設定とRetry: n8nの部品設定とRetry On Fail](https://docs.n8n.io/connect/connect-to-n8n-mcp-server/mcp-server-tools-reference)
23. [n8n: n8n 過去実行の再試行実装](https://github.com/n8n-io/n8n/blob/master/packages/cli/src/executions/execution.service.ts)
24. [n8n: n8n 失敗後の実行スタック処理](https://github.com/n8n-io/n8n/blob/master/packages/core/src/execution-engine/workflow-execute.ts)

2026年9月5日時点の公式資料を確認しています。仕様は更新される可能性があります。

---

© 知能圏 https://www.chinouken.com/articles/choose-automation-by-workflow