n8n vs Make:料金・AI機能・セルフホストの徹底比較

n8nとMakeのどちらを選ぶべきかを徹底比較します。非エンジニアによるSaaS連携ならMake、カスタムAIやセルフホスト重視ならn8nが最適です。最新料金プランから損益分岐点となるアクション数、移行手順まで詳しく解説します。自社の運用体制に最適な自動化ツールを見極めましょう。

Friday, September 4, 2026Omid Saffari
Tools
n8n vs Make:料金・AI機能・セルフホストの徹底比較

非エンジニアの運用担当者が標準的なSaaSワークフローを管理する場合はMakeを、エンジニアがカスタムコード、AIループ、またはセルフホスト環境を必要とする場合はn8nを選択してください。最新の年払い料金では、Make Coreが月額$9(10,000クレジット)、n8n Proが月額$50(10,000実行)からとなっていますが、1回の実行あたり約5.6回の通常課金アクションを境にコストの優位性が逆転します。

結論:運用担当者にはMake、開発者にはn8n

使い慣れたアプリを連携させ、ビジュアルキャンバス上でデータの流れを確認し、運用担当者にメンテナンスを任せたいビジネスチームにはMakeが適しています。一方で、開発者やテクニカルオペレーターがシステムを管理し、カスタムAPI、PythonやJavaScript、AIツールのループ処理、セルフホスト、またはGitベースのバージョン管理を求めるなら、長期的な選択肢としてはn8nが優れています。

機能一覧よりも「誰が管理するのか」が重要です。

  • フォーム、CRM、メール、SMSを連携する現場の運用担当者はMakeを選ぶべきです。 ビジュアル化されたシナリオは確認が容易で、標準アプリの対応範囲も広く、フルマネージドクラウドのためサーバー運用の手間がありません。
  • AIサポートエージェントを構築するスタートアップの創業者はn8nを選ぶべきです。 条件分岐、反復的なツール呼び出し、コードステップ、モデル連携を1回のワークフロー実行内に収めることができ、アクション単位でクレジットが加算され続ける心配がありません。
  • 部門横断での可視性が必須となる中堅企業の自動化責任者はMakeを選ぶべきです。 Make Teamsプランではチームロールや共有テンプレートが利用できます。逆に、環境分離、Git、データの保管場所、カスタムノードが必須要件である場合はn8nを選択してください。
  • 将来的にワークフローをソフトウェア化する予定の個人エンジニアはn8nを選ぶべきです。 初期の学習コストをかけることで、コード、カスタムAPI、ローカルモデル、セルフホストへの移行がスムーズになります。

Community Editionにソフトウェア費用がかからないという理由だけで、安易にn8nをセルフホストするべきではありません。アップデート、バックアップ、監視、障害対応、ライセンス制限の管理などを誰かが担う必要があります。適切に管理されたMakeのサブスクリプション料金は、回避できたはずのシステム障害による損失よりも安価です。

n8n vs Make:主な特徴と機能の比較一覧

判断の軸n8nMake勝者
クラウド版の開始料金Starter: 年払いで月額$20(2,500回の完全実行)Core: 年払い表示で月額$9、月払いで月額$12(10,000クレジット)シンプルな導入ならMake
複雑なロジックとAIJavaScript/Pythonステップ、カスタムAPI、1回の実行完了につき1課金ユニットビジュアルAIエージェント、3,000以上のアプリ、実行時間課金のコードn8n
デプロイと制御クラウドまたはセルフホスト、BusinessプランでGitおよび環境分離に対応クラウド実行、プライベートシステムへの接続にはEnterpriseオンプレミスエージェントを使用n8n
主な導入障壁技術的な管理コストとFair-codeライセンスの制限クレジット消費の増加、動的なAI利用コスト、セルフホスト実行の非対応運用負荷を下げたいチームにはMake

料金および機能制限は、2026年8月5日時点の公式なn8n料金ページおよびMake料金ページで確認された情報に基づいています。どちらを選ぶかは、課金単位、システムの運用責任者、デプロイ環境によって決まります。連携コネクタの多さは便利ですが、ワークフローが業務に不可欠なものになった段階では決定的な要因にはなりにくいのが実情です。

料金体系:同一ワークロードでの比較と「5.6アクション」の分岐点

小規模でシンプルなワークロードではMakeが有利ですが、1つの処理を完了するために多くのステップを必要とする場合はn8nが優位に立ちます。

その理由は課金単位の違いにあります。**n8nの「実行(Execution)」**は、ステップ数やデータ処理量に関係なく、ワークフロー全体の1回の完全な実行を指します。一方、**Makeの「クレジット(Credit)」**は、モジュールのアクションやその他の計測機能によって消費される単位です。AIを使用しない通常の操作の多くは1クレジットを消費しますが、AI機能、ファイル処理、カスタムコードなどは異なる消費レートが適用されます。

月間2,000件のリードを処理し、1件あたり5回の通常アクションを実行するリード振り分けワークフローを両プラットフォームで試算してみましょう。

  • Makeは10,000クレジットを消費します。Coreプランでは、年払い表示で月額$9、月払いで月額$12でこのワークロードをカバーできます。
  • n8nは2,000実行を消費します。Starterプラン(年払いで月額$20)でカバーでき、上限の2,500回実行にも余裕があります。

年払いのn8nと比較した場合、Makeは月額$11安く、月払いのMakeと比較しても月額$8安くなります。ワークフローがこれほどシンプルなままであれば、コスト削減を目的にn8nを導入するのは誤った判断です。

しかし、処理が複雑になるとこの関係は逆転します。Make Coreの年払い料金を換算すると、1,000クレジットあたり$0.90です。一方、n8n Proは10,000回の実行枠で1,000回の完全実行あたり$5となります。したがって、1,000回のワークフロー実行を行う場合、Makeのコストは1実行あたり通常1アクションなら$0.90、3アクションなら$2.70、6アクションなら$5.40となります。対照的に、n8nはステップ数によって課金メーターが変わらないため、いずれの場合も$5のままです。

1回、3回、6回のアクションにおけるワークフロー1,000回あたりのMakeとn8nの標準化コストを比較した棒グラフ
1回の実行あたり通常の6アクションに達すると、n8n ProのユニットコストはMake Coreの年払い基本レートを下回ります。

損益分岐点は1回の実行あたり5.56回の通常課金アクションです。これ以下であればMakeの年払い基本料金の方が安く抑えられます。6アクションになると、Makeの換算コストが$5.40になるのに対し、n8nは$5となります。

コードの実行時間課金にも注意が必要です。MakeのCode Appは有料プランでJavaScriptとPythonをサポートしていますが、コード実行1秒あたり2クレジットを消費します。5秒かかるコード処理があると、前後のモジュールを計算する前にそれだけで1回の実行ごとに10クレジットが加算されます。対してn8nは、JavaScriptやPythonのコードステップを含んでいても、ワークフロー全体を1回の実行として計測します。

Makeの未使用クレジットは契約期間の終了時に失効します。クレジットを使い切ると、追加クレジットを購入するかプランを変更するまでシナリオは停止します(受信Webフックはアカウントの上限内でキューに保持されます)。n8nの実行履歴には保持期間やストレージの上限がありますが、これらの履歴上限に達してもワークフロー自体の実行が停止することはありません。

料金面の勝者: 短いワークフローや最低利用料金を抑えたい場合はMake。ステップ数が多いワークフロー、反復的なAIツールの呼び出し、Make上で実行時間クレジットを多く消費するコード処理を行う場合はn8n。

導入スピードとアプリ対応数ではMakeが優位

自動化システムの管理者がエンジニアではなく運用担当者である場合、Makeが最適です。Makeのシナリオキャンバス(シナリオは1つの自動化ワークフローを意味します)では、コードを読まなくてもフィルター、ルーティング、マッピング、データバンドルの流れを一目で把握できます。

Free、Core、Pro、Teams、Enterpriseプランが並ぶMakeの料金ページ
Makeの料金プラン

現在のカタログでは3,000以上のアプリへの対応が謳われており、n8nの1,000以上の連携数を大きく上回っています。連携アプリの総数は必要なコネクタが揃っていることを保証するものではありませんが、ニッチなSaaSツールでも既製のモジュールが用意されている可能性はMakeの方が高くなります。フォームからデータ補完ツール、CRM、メール、Slackへとリードを連携させるB2Bの業務チームにとって、アプリ対応数の多さはカスタムHTTPリクエストの手間を減らし、引き継ぎ作業を円滑にします。

Make Freeプランは小規模なワークフローの検証に適しています。月額$0で1,000クレジットが利用でき、最小実行間隔は15分です。Coreプランに移行すると、アクティブなシナリオ数の制限がなくなり、実行間隔を1分に短縮でき、Make APIも利用可能になります。Proプランでは優先実行、カスタム変数、実行ログの全文検索が追加され、Teamsプランではチームロールと共有テンプレートが利用可能になります。

Makeの限界は、ワークフローの分岐処理そのものにあるわけではありません。高度なルーター、イテレーター、アグリゲーター、サブシナリオ、AIエージェントの構築も可能です。課題となるのはコストと運用の側面です。多数のモジュールで構成されたシナリオをデータが通過するたびにクレジットが乗算され、高度なAI機能の消費量は動的に変動します。さらに、すべての本番シナリオはMakeのクラウド上で実行されます。Enterprise向けのオンプレミスエージェントはプライベートネットワーク内のシステムにアクセスするためのものであり、Make自体をセルフホスト型のランタイムにするものではありません。

また、Makeの有料プランではシナリオ1回の最大実行時間が40分に制限されており、月間10,000クレジットごとに5 GBのデータ転送量が割り当てられています。実行時間の長いデータ補完、大容量ファイルの処理、大量レコードのループ処理などは、クレジット警告が出てからではなく、運用開始前に入念な見積もりを行う必要があります。

セットアップと対応アプリ数の勝者:Make。 インフラ管理者を置かずに、非エンジニアチームが標準的な業務自動化を把握・維持する必要がある場合、最も安全な選択肢となります。

カスタムロジック、AIエージェント、デプロイ制御ではn8nが優位

自動化の仕組みが単なるSaaS連携の枠を超え、社内アプリケーションに近い挙動を求める場合はn8nが真価を発揮します。JavaScriptやPythonのコードステップ、カスタムHTTPおよびGraphQLリクエスト、Webフック、キュー処理、セルフホスト機能により、ビジュアルビルダーで直面しがちな「別の外部サービスを構築せざるを得ない壁」を回避できます。

Starter、Pro、Business、Enterprise、Communityプランが記載されたn8nの料金ページ
n8nの料金プラン

顧客データを取得し、ベクターデータベースを検索し、モデルを呼び出し、レスポンスを検証し、失敗したツールを再試行して結果をCRMに書き込むようなサポートエージェントを構築する場合、n8nの実行単位課金は構造的な強みとなります。ツールの呼び出し回数が増えるほどワークフローの構築は複雑になりますが、通常ノードの数が増えてもn8nの実行課金メーターは増えません。

少人数のエンジニアチームにとって実用的なマネージドプランはn8n Proです。年払いで月額$50、10,000回の実行、3つの共有プロジェクト、20の同時実行、7日間のインサイト保持、管理者ロール、グローバル変数、ワークフロー履歴、実行ログ検索が含まれます。より大規模な容量やガバナンスプランについては、2ツールの比較枠を超えて解説しているn8n料金プランの完全ガイドをご確認ください。

セルフホストによりデータの保管場所を完全に制御でき、カスタムノードを自由に作成できますが、Community EditionはOSI認定のオープンソースではない点に留意してください。n8nはそのSustainable Use LicenseをFair-codeおよびSource-availableと定義しています。社内業務、個人利用、非商用利用は認められていますが、n8nをホスティングして第三者に有料で利用させることは禁止されています。顧客自身のサードパーティ認証情報を収集するようなプロダクト機能を組み込む場合も、個別の商用契約が必要になる場合があります。SaaSの創業者は、Community Editionを無料の組み込みバックエンドとして利用する前に、このライセンス境界を確認しておく必要があります。

有料のセルフホスト版にも見落とされがちな条件があります。米国向けページにおいて、n8n Businessは40,000回の本番実行枠で年払いで月額$800と案内されています。そのライセンスキーはn8nのライセンスサーバーと毎日通信し、ライセンス対象インスタンス全体の使用状況を報告します。合意されたアップグレードなしに上限を超過した場合、追加の300,000実行枠あたり4,000ユーロの超過料金が発生することが公表されています。Businessのガバナンス機能が必要になった場合、セルフホストだからといって自動的に無制限実行になるわけではありません。

技術的な最大の壁は運用責任の所在です。インスタンスへのパッチ適用、バックアップ、ワーカーやキューの監視、アップグレードのテスト、認証情報の保護、障害復旧などを誰かが担当しなければなりません。その担当者を明確に指名できない個人創業者は、Community Editionではなく、n8n CloudまたはMakeを選ぶべきです。

カスタムロジックとデプロイの勝者:n8n。 エンジニアチーム、カスタムAIワークフロー、社内API、データやランタイムを外部のクラウドサービスに預けられないワークロードにとって、極めて強力なシステムです。

信頼性と実測パフォーマンス

ある第三者機関による速度テストではn8nが優れた結果を示しましたが、これは特定条件下での測定結果であり、すべてのケースに当てはまるわけではありません。Mopshyは、Webフック受信からデータ補完、LLM処理、CRMへのアップサートに至る同じ4ノードのワークフローを、各プラットフォームで3日間にわたり1,000回実行した結果を報告しています。

Mopshyが公表したベンチマークによると、CX22サーバー上でセルフホストされたn8nのレイテンシは中央値(p50)で420ミリ秒、95パーセンタイル(p95)で910ミリ秒、エラー率は0.2%を記録しました。n8n Cloud Proはp50で560ミリ秒、p95で1,180ミリ秒、エラー率0.3%でした。一方、Make Proはp50で790ミリ秒、p95で1,640ミリ秒、エラー率0.4%でした。

これらの数値はMopshy独自のものであり、再現可能なテスト構成、リージョンの配置、プロバイダの応答分布、未加工の実行ログデータなどは公開されていません。ネットワークの物理的距離や外部のLLMおよびCRMの応答速度が、4ノードのテスト結果の大半を左右することもあります。この結果は「直接的な処理速度の検証が必要である」という判断材料として捉え、確定的なSLAとして扱うべきではありません。

ユーザー満足度の評価はほぼ互角です。G2の最新比較スナップショットでは、Makeが334件のレビューで5点中4.6点、n8nが297件のレビューで4.7点となっています。レーティングは多様な利用者の声を1つの数字に集約したものですが、レビュー内容には明確な傾向が見られます。Makeは使いやすさが高く評価され、n8nは柔軟性が絶賛される一方で学習コストの高さが指摘されています。

パフォーマンス実測値の勝者:Mopshyのテスト環境下ではn8n。 わずか数秒のレイテンシが問題となるワークフローの場合は、本格導入前に同一の外部サービスおよびリージョンで実際のペイロードを用いたテストを行ってください。

チームのガバナンス:運用の透明性か、エンジニアリングの制御性か

部門横断的なガバナンスではMakeが優れ、エンジニアリング視点のガバナンスではn8nが優れています。調達チェックシート上では似たように見えるかもしれませんが、運用開始後の使い勝手は大きく異なります。

Make Teamsは10,000クレジット付きで年払い表示で月額$29、月払いで月額$38です。チーム管理、チームごとのロール、共有シナリオテンプレート機能が追加されます。Make Enterpriseでは、カスタム関数、エンタープライズ向けアプリ、24時間365日のサポート、超過保護、高度なセキュリティが提供されます。グロース担当、財務担当、自動化スペシャリストが、ランタイムインフラを意識することなく1つの管理環境を共有できます。

n8n Proは年払いで月額$50で、無制限のユーザー数、管理者ロール、3つの共有プロジェクト、20の同時実行が含まれます。Businessプランでは、環境分離、Gitバージョン管理、SSO/SAML/LDAP、セルフホストでの制御が追加されます。ワークフローの変更をソフトウェア開発のようにコードレビューやデプロイフローに乗せたい場合、極めて優れたガバナンスモデルとなります。

どちらの比較価格もシートごとの課金体系ではありません。5人のチームで社内コストを按分した場合、Make Teamsは年払い換算で1シートあたり月額$5.80、n8n Proは1シートあたり月額$10となります。ただし、Makeの枠には10,000クレジットしか含まれておらず、n8nには10,000回の完全実行枠が含まれています。この試算は予算管理の目安にはなりますが、1実行あたりのアクション数を考慮しない限り、処理できるワークロードが同等であるとは言えません。

ガバナンスの勝者:多様な職種が混在するチームならMake。 Git、環境分離、独自のデプロイパイプライン、データ保管場所の厳密な管理が「好み」ではなく「必須要件」である場合はn8nを選択してください。

移行コスト:再構築、リプレイテスト、ロールバック手段の確保

プラットフォームの移行は単なるファイル変換ではなく、実質的な再構築作業となります。どちらのプラットフォームもJSONエクスポートに対応していますが、そのスキーマは全く異なるエンジン向けに設計されています。

Makeのブループリントにはシナリオのモジュール、モジュール設定、マッピングされた値が含まれています。インポート後も、各アカウントの接続設定は再作成する必要があります。n8nのエクスポートファイルは独自仕様のJSON形式であり、ファイルやURLからインポートできますが、Makeのモジュールが自動的にn8nのノードに変換されるわけではありません。また、n8nのエクスポートファイルには認証情報の名前やIDが含まれる場合があり、cURLからインポートしたHTTP Requestノードには認証ヘッダーが含まれている可能性があるため、共有前に削除するよう警告されています。

移植可能な資産とは、ワークフローの「ロジック」そのものです。具体的には、トリガー、データ変換、条件分岐、エラーハンドリング、副作用、期待される出力値などが該当します。コネクション、認証情報、実行履歴、データストア、WebフックURL、スケジュール設定、キューの挙動、プラットフォーム固有のAI設定などは、すべて移行作業として手動で設定し直す必要があります。

  1. 既存のワークフロー資産を棚卸しする

    稼働中のすべてのシナリオまたはワークフローについて、トリガー、月間実行数、1実行あたりの通常アクション数、AIやコードの利用状況、連携アカウント、エラーハンドラー、ダウンストリームの担当者を洗い出します。実行量が多く、リスクの高いフローから優先的に着手してください。

  2. エクスポートと機密情報のサニタイズを行う

    Makeのブループリントまたはn8nのワークフローJSONをエクスポートします。これらはそのままインポートするためのファイルではなく、移行設計のリファレンスとして保存してください。チケット管理ツールやリポジトリにコミットする前に、認証情報名、ID、ヘッダー、サンプルの個人データ、APIキーを必ず削除してください。

  3. モジュールを配置する前に入出力の挙動を整理する

    各ブランチで想定される入力と出力をドキュメント化します。その上で、ページネーション、データバンドル、リトライ処理、タイムアウト、エラーハンドリングを含めて、Makeのモジュールをn8nのノード(またはn8nからMake)へと対応付けていきます。データのセマンティクスを理解せずに見た目のブロックだけを再構築すると、潜在的な不整合の原因になります。

  4. 本番環境に近い実データでリプレイ検証を行う

    両方のシステムをステージング環境の認証情報で動かし、最終的な出力結果、副作用、エラー時の挙動を突き合わせて検証します。Mopshyの移行プラクティスでは直近50件の本番ペイロードをリプレイすることが推奨されています。季節要因や発生頻度の低い分岐がある場合は、より多くのサンプルデータを使用してください。

  5. ロールバック期間を設けて切り替える

    出力結果が完全に一致することを確認した後にのみ、トリガーとなるWebフックの送信先やスケジュールを切り替えます。切り替え後も一定期間は旧ワークフローを停止状態(接続情報は維持)で残し、アラートを監視できる体制を維持してください。Mopshyは14日間のロールバック期間を推奨していますが、規制要件のある業務や実行頻度の低いワークフローではさらに長い期間が必要になる場合があります。

サーバーや技術的なワークフローの管理者がいない状況で、シンプルな処理の費用を月$8〜$11節約するためだけにMakeからn8nへ乗り換えるのは避けるべきです。移行にかかる人件費の方がはるかに高くつきます。また、セルフホスト、カスタムノード、ローカルモデル、Gitでのコードレビュー、データの国内保持が必須要件である場合に、n8nからMakeへ安易に移行するのも避けてください。検証用の実データとロールバックの責任者が決まっていない段階での移行は、どちらの方向であっても実施するべきではありません。

運用の境界線が明確であれば、両方を組み合わせたハイブリッド運用も合理的です。運用担当者が管理する顧客向けSaaS連携にはMakeを使い、エンジニアが管理するAIエージェント、社内API、ステップ数の多いバックオフィス処理にはn8nを採用します。両者を認証付きのWebフックで接続し、双方でログと実行状況を監視できるようにしておきましょう。どちらのプラットフォームも要件に合致しない場合は、より広範なAI自動化ツールの徹底比較も参考にしてください。

マネージドワークフローをMakeに、カスタムロジックをn8nに振り分け、混合環境ではハイブリッド構成をとる判断フロー図
運用の担当者を最優先に考え、次にカスタムロジックの必要性を検討します。ハイブリッド構成は責任の境界が明確な場合にのみ採用してください。

次回の料金改定にも左右されない選定基準

「運用担当者がワークフローを管理する」「標準コネクタで完結する」「クラウド実行で問題ない」「1回の実行あたりの通常アクション数がコスト分岐点を下回る」という4つの条件がすべて満たされている場合は、Makeを選択してください。

「セルフホスト」「ローカルモデル」「カスタムノード」「Gitによるデプロイ管理」「複雑なコード処理」「ステップ数の多いAIループ処理」のいずれか1つでも必須要件に含まれる場合は、n8nを選択してください。Community Editionを安全に運用できる専任のエンジニアを確保できるまでは、n8n Cloudの利用を推奨します。

両方を併用するのは、各プラットフォームに明確な担当者とワークロードの境界線が存在する場合のみにしてください。責任の所在が曖昧なハイブリッド運用は、障害発生ポイントを倍増させ、認証情報の管理をいたずらに複雑化させるだけです。

もし比較対象にZapierも残っているなら、n8n vs Zapier vs Makeの比較もご覧ください。最も簡単に導入できる反面、1アクションあたりのコストが最も高くなりやすい選択肢について詳しく解説しています。

n8nとMakeのどちらが学習しやすいですか?

多くの非エンジニアの運用担当者にとってはMakeの方が容易です。ビジュアルシナリオビルダー、幅広いアプリ対応、フルマネージドのクラウド環境により、初期構築やメンテナンスの手間が少なくなります。n8nは学習難易度がやや高いものの、コード、カスタムAPI、セルフホストを駆使することで、開発者に高度な制御性を提供します。

AIエージェントの構築にはn8nとMakeのどちらが優れていますか?

ツールの反復呼び出し、カスタムコード、ローカルモデル、セルフホストを伴う複雑なAIエージェントの構築にはn8nが優れています。一連の完全な処理が「1回の実行」として課金されるためです。一方で、ビジネスの運用担当者がビジュアル環境で管理しやすいエージェントを作成し、トークンや操作クレジットの消費量が予測可能な範囲に収まる場合はMakeが適しています。

Makeはn8nのようにワークフローをセルフホストできますか?

いいえ、できません。MakeはEUまたは北米のAWSクラウド上でシナリオを実行します。Enterpriseプランの契約者はオンプレミスエージェントを使用してプライベートネットワーク内のシステムにアクセスできますが、シナリオの実行ランタイム自体はMakeのクラウド上に留まります。n8nはn8n Cloudのほか、自社で管理するインフラ上でも実行可能です。

n8nとMakeの料金の違いは何ですか?

月間2,000回、各5アクションのワークフローを実行する場合、Make Core(10,000クレジット)は年払い表示で月額$9、月払いで月額$12です。対してn8n Starter(2,000実行)は年払いで月額$20となります。ただし、1回の実行あたり通常の課金アクションが6回になると、n8n Proの換算コスト(1,000回あたり$5)がMake Coreの年払い相当額($5.40)を下回り、n8nの方が割安になります。

AIビジネスワークフロー監査チェックリストと運用者向けニュースレターを受け取る

最終更新

2026年9月4日

カテゴリーBuild

Googleでこのサイトを優先する

omidsaffari.comをGoogle検索の優先ソースに追加

omidsaffari.comを優先ソースに設定すると、GoogleがTop Stories・AI Overviews・AI Modeであなたのために優先表示します。

ニュースレター

毎週日曜、一通の手紙。 動くシステムの話。感想戦ではなく。

AIベンチャーのポートフォリオ運営から生まれるビルドログ、稼働中のシステム、現場ノート。

週刊。スパムなし。いつでも解除できます。