費用の増え方
自動化ツールの料金を、同じ仕事量で比べる
Make Credits、Zapier Tasks、n8n workflow executions、Power AutomateのUser/Process系ライセンスを、公式Factと編集用の仮定計算を分けて整理します。
月額表示より先に、何を1回と数え、使用量とともに何が増えるかを確認します。安さではなく、請求を予測できるかが判断基準です。
この記事で確認する製品
月額を横並びにする前に、各社が何を1単位としているかをそろえる
MakeはCredits、ZapierはTasks、n8n Cloudはworkflow executions、Power AutomateはUser/Capacityのlicense modelを持ちます。数字だけを並べると、同じ『1,000』でも意味が違います。
FineInTheoryでは、まず1つの実業務を定義し、それを各製品の課金単位へ翻訳します。価格そのものとbilling ruleはFACT、月間件数や平均step数などの仮定はEDITORIAL、そこから計算した値はDERIVEDとして分けます。
比較表をきれいにするために違う単位を同じものとして扱うと、表だけ完成して判断が壊れます。先に仕事量をそろえます。
- FACT：公式のbilling unit・Plan条件・価格
- EDITORIAL：月間イベント数、Action/operation数、利用人数等の仮定
- DERIVED：仮定を各billing unitへ換算した値
- 価格改定時はFACTだけ更新し、同じWorkloadで再計算
例：1件の問い合わせを3システムへ流す仕事を基準にする
説明用に『フォーム受信 → CRM登録 → Slack通知 → Spreadsheet記録』を1つの業務イベントとします。月間イベント数を仮定し、Makeでは実際のmodule operationsとcredit rule、Zapierではsuccessful Actions、n8n Cloudではworkflow executions、Power Automateでは利用者・Flow・RPA等のlicense contextへ翻訳します。
この例は各社の月額を断定するものではありません。Branch、retry、AI、RPA、特殊Task/Credit rate、Self-hostが入れば別条件として足します。
重要なのは『1,000 events = 1,000 billing units』と決めないことです。同じ業務でも各社が数えている対象が違います。
- Make：eventごとのoperationsとcredit rule
- Zapier：eventごとのsuccessful Action数
- n8n Cloud：Workflowが何回開始〜終了するか
- Power Automate：誰/どのAutomation/どのMachineに権利が必要か
Automationしない場合も基準値として残す
現在の手作業時間が分からなければ、AutomationのROIも分かりません。少量で例外が多い仕事では、Subscription、構築、監視、障害対応まで含めると、人が処理し続ける方が合理的な場合があります。
逆に、24時間処理、即時応答、大量処理が目的なら、現在の人件費だけで比較するとAutomationのCapability Valueを取り逃します。
人件費や工数は公式価格ではありません。実測できるまではEDITORIALな前提として扱い、測定できた項目から置き換えます。
- 現在の月間件数
- 現在人手時間
- 例外率
- 必要応答時間
- 夜間 / 即時処理要否
- Failure impact
比較用Workloadは6項目だけ先に固定する
製品ごとの価格を調べる前に、月間イベント件数、1イベントの処理数、branch率、利用人数、Desktop/RPA要否、Self-host要否を固定します。
この6項目が決まると、各社の違う課金モデルへ変換できます。逆にここが決まらないなら、どの料金表を見ても『場合による』から先へ進みません。
- 月間events
- 平均operations/actions
- branch/retry率
- 利用ユーザー数
- Desktop/RPA要否
- Self-host要否
Software料金に入っていない運用コストを別列へ出す
Self-host、外部API、monitoring、backup、管理者教育、障害対応などはPlan料金とは別です。特にn8n Self-hostはinfraを自社へ戻すため、Cloud subscriptionだけと比較するとTCOを過小評価します。
managed SaaS側もTask/Credit超過、上位Plan、Team/Governance要件などで増額します。公式月額と運用費を混ぜず、公式費用 + 編集仮定による運用費の二段で表示します。
人件費を公式価格のように見せないことが重要です。測れるようになったら仮定を実測へ置き換えます。
- 公式Subscription/License
- 超過/追加usage
- Self-host infra
- 外部API/AI
- 運用・監視・障害対応
- Team/Governance要件
見積もり前の確認
Make・Zapier・n8nの料金はどれが一番安いですか？
課金単位が異なるため、月額だけでは決められません。同じ実業務をCredits、Tasks、Executionsへ換算し、Self-host等の運用費も分けて比較します。
Power Automateも同じ処理件数で比較できますか？
完全に同じ数え方ではありません。Power AutomateはUser/CapacityやRPA利用形態などLicense contextを整理して、同じ業務を実現するために必要な権利へ換算します。
TCOの人件費は公式料金ですか？
いいえ。運用工数や人件費はFineInTheory側の仮定・編集計算です。公式Plan料金やbilling ruleとは分離します。
価格比較表だけあれば十分ですか？
単純Workflowなら参考になりますが、実行量、step数、RPA、Self-host、Team/Governance要件で差が出るため、自社Workloadへ換算する方が有用です。
条件が合う候補だけ次へ
Automationの料金比較では、違う単位を無理に同じ『月額』へ押し込まず、同じ仕事を各社の課金単位へ翻訳してから比べます。Automationしない場合も基準に残し、先にWorkload、後からPrice。この順序なら価格改定が来ても比較を作り直しやすくなります。
一部の外部リンクは広告リンクになる場合があります。