n8n vs Make 徹底比較｜料金・自前運用・AI連携で選ぶ正解 (2026年版)

ワークフロー自動化を本気で導入するとき、最後まで残る二択がn8nとMakeだ。Zapierより安く、複雑な分岐にも耐える。ここまでは両者とも同じ土俵に立つ。

違いは「どこで動くか」と「何で課金されるか」に集約される。ここを外すと、後から料金で痛い目を見る。

この記事は機能の羅列ではなく、実際に運用したときに効いてくる差だけを並べた。読み終えたとき、自分の用途でどちらを選ぶべきかが明確になっているはずだ。

結論: n8nとMakeはどちらを選ぶべきか

セルフホストで顧客データや実行ログを社外に出したくない開発者・情シスは n8n 一択。SaaSのキャンバスUIで担当者本人が複雑なシナリオを最短で組みたいマーケ・運用チームは Make が圧倒的に立ち上がりが速い。

n8nは「自前で持つ自由」、Makeは「持たない手軽さ」。この性格の違いがすべての判断軸の根っこにある。

長い処理や大量実行を回すなら、実行単位で課金されるn8nが効く。逆に、繋ぐアプリの数が多くて1本あたりは軽い処理ならMakeが向く。

料金体系: 同じ$10台でも課金単位が真逆

両者とも有料プランは月$10台から始まるが、何を1カウントとするかが正反対だ。下の表で課金の考え方を押さえてほしい。

ここが最大の分かれ目だ。n8nはワークフローが何ステップあっても「1回動いたら1カウント」。20個のノードを通っても1実行だ。

Makeは1シナリオの中で動いたステップ（モジュール）ごとにクレジットを消費する。10ステップ動けば10カウントに近い。

つまり長くて重いワークフローほどn8nが安く、短くてシンプルな連携を数多く回すならMakeが読みやすい。自分の処理が「縦に長い」のか「横に広い」のかで損益分岐点が変わる。

見落としがちな罠: Makeの2025年8月課金変更

2025年8月、Makeは「オペレーション」を「クレジット」へ改名した。単なる呼び名の変更ではない。AI関連モジュールの消費量が固定ではなく変動制になった。

LLM呼び出しのように出力が長くなりやすい処理は、想定よりクレジットを食う。月初に立てた見積もりが月末にズレる、という事態が起きうる。

n8nはこの点でシンプルだ。AIノードを何回叩こうが、ワークフロー全体で1実行は1実行。コスト予測が立てやすい。

AIエージェントを業務に組み込んでヘビーに回す前提なら、課金の予測可能性という一点だけでn8nに分がある。

セルフホストvsクラウド: データ主権で決まる

n8nは自分のサーバーにDockerで立てられる。実行環境もデータの通り道も、すべて自社の管理下に置ける。これがMakeには絶対にできない決定的な差だ。

Makeはクラウド専業のSaaS。実行基盤はMake側にあり、データは一度Makeのインフラを通る。手軽な反面、データの所在を自社で完全制御することはできない。

顧客の個人情報や社内の機密データを跨ぐ基幹自動化では、この差が効く。EUのGDPRや業界規制でデータの保管場所が問われる場面では、n8nのセルフホストが現実的な解になる。

逆に「インフラ運用の人手をかけたくない」「サーバー管理は誰もできない」なら、Makeのフルマネージドが正解だ。自前運用はゼロコストではなく、保守の手間という見えないコストがかかる。

連携数と拡張性: カタログの広さか、踏み込む深さか

繋げるサービスの数ではMakeが圧倒する。3,000以上のアプリ連携を持ち、メジャーなSaaSはほぼ標準で揃う。

n8nは400以上の連携。数では負けるが、HTTPノードと独自コード実行で、既製ノードにないAPIにも自力で踏み込める。

連携の思想の違い
Make → 用意された3,000+のブロックから選んで組む（広く浅く繋ぐ）
n8n  → 400+のノード+コードで何にでも繋ぐ（狭くても深く踏み込む）

業界固有の社内システムや、まだコネクタが存在しないニッチなAPIを叩く必要があるなら、n8nのコード差し込みが効く。一方、ShopifyやStripe、Slack、Notionといった定番SaaSを繋ぐだけなら、Makeの標準コネクタで十分すぎる。

Zapierから移行を検討している場合も、この2本は有力な乗り換え先になる。Zapierより料金が読みやすく、複雑な分岐にも対応できるからだ。

学習コストとUI: 誰が組むのか

MakeはノーコードのキャンバスUIが強みだ。トリガーからアクション、条件分岐、ループまでを視覚的に配置できる。ステップごとの実行結果も画面で確認でき、デバッグが直感的だ。

非エンジニアの運用担当者でも、最初のシナリオを当日中に動かせる。これがMakeの最大の魅力で、no-codeの入り口としては最もなだらかだ。

n8nはノード型のワークフローで、考え方はMakeとよくなじむがUIはやや骨太だ。セルフホストする場合はサーバーの初期構築という技術的なハードルが先に立つ。

要は「誰がこれを組み、誰が保守するのか」だ。エンジニアが主体ならn8nの自由度が活き、ビジネス担当者主体ならMakeの分かりやすさが活きる。

AI連携: エージェント中核ならn8n、要約差し込みならMake

LLMを業務に組み込む使い方が、いまや自動化ツール選びの主戦場になっている。ここでも性格が分かれる。

n8nはAI Agent統合を備え、OpenAIやAnthropicのモデル接続を自前で管理できる。プロンプト・モデル・データ保持ポリシーまで自社制御したい、AIを業務プロセスの中核に据える用途で強い。

Makeは400以上のAIアプリ連携を持ち、既存シナリオにAIによる要約・分類を差し込むのが得意だ。「社内外のデータをAIでさっと処理して既存フローに流す」程度なら立ち上げが速い。

ただし前述のとおり、MakeのAIモジュールは変動クレジット課金だ。ヘビーに回すほどコストが読みにくくなる。AIをガンガン叩く設計なら、実行単位課金のn8nのほうが財布に優しい。

用途別の選び方

社内システムと外部APIを横断する基幹自動化 顧客DB・社内ERP・AIモデルを跨ぐ処理を、データを外に出さずに動かしたいならn8n。セルフホストで実行ログとデータ経路を自社完結でき、HTTPノードや独自コードで業界固有APIにも踏み込める。情シス管理下の運用が前提なら最有力だ。

マーケ・営業のアプリ間連携を素早く立ち上げる CRM、広告管理、フォーム、Slack、スプレッドシートなどSaaSが主戦場ならMake。3,000超の連携とキャンバスUIで、トリガー設計から条件分岐まで担当者本人が組める。ステップ別の実行確認が日々のデバッグで効く。

AIエージェントを業務プロセスに組み込む LLM呼び出しから業務システムへの書き戻しまでを自社制御したいならn8n。コストの予測可能性とデータ主権の両方で有利だ。逆に既存ワークフローにAI処理を軽く差し込む程度ならMakeが早い。

コストをとにかく抑えたい / 大量実行を回す セルフホストで運用できる技術力があるなら、n8nの自前運用がインフラ費用だけで済む。長くて重いワークフローを大量に回すほど、実行単位課金が効いてくる。

n8nを選ぶべきケース / Makeを選ぶべきケース

n8nを選ぶべきケース

• セルフホストでデータの所在と実行環境を社内に置きたい
• 独自コードやHTTPで既製ノードにないAPIを叩く必要がある
• AIエージェントを中核に据え、コストを予測可能に保ちたい
• 長くて重いワークフローを大量に回す

Makeを選ぶべきケース

• ノーコードで担当者自身がシナリオを組みたい
• SaaS中心の業務で、3,000超の連携から素早く繋ぎたい
• インフラ運用の人手をかけたくない
• Zapierの料金や複雑フロー対応に限界を感じている

編集部の評価

率直に言って、この2本に優劣はつかない。性格が真逆だからだ。どちらが優れているかではなく、自分の組織がどちらの「面倒」を引き受けられるかで決まる。

n8nはセルフホストという最強の武器を持つが、サーバー運用の手間は自分で背負う。データ主権とコストの予測可能性は破格だが、エンジニア不在の組織には荷が重い。AIをヘビーに使う前提なら、実行単位課金は圧倒的に有利だ。

Makeはノーコードの入り口としては一択級の手軽さ。3,000超の連携カタログも重宝する。ただし2025年8月のクレジット変更で、AI処理のコスト予測は正直やりにくくなった。ステップ課金なので、複雑で長いフローを多用すると料金が膨らむ点は覚悟がいる。

迷っているなら、まず無料枠で両方を触るのが最短だ。Makeの月1,000オペレーション無料枠で手触りを掴み、n8nはローカルにDockerで立てて実行単位の感覚を確かめる。1週間も触れば、自分の用途がどちらに寄っているか体感で分かる。

なお料金とプラン構成は変動が早い。導入前に必ず両社の公式ページで最新の数字を確認してほしい。

よくある質問（FAQ）

Q. n8nとMake、料金が安いのはどっち?

処理の形による。長くて重いワークフローを回すならn8n（実行単位課金）が安い。短い連携を数多く回すならMakeも競争力がある。セルフホストできるならn8nはインフラ費用のみで運用でき、最安になりうる。

Q. Makeの「クレジット」と「オペレーション」は何が違う?

2025年8月の改名で呼称が変わった。実務上の最大の変化はAIモジュールが固定消費から変動消費になった点だ。AI処理を多用すると消費量が読みにくくなるため、見積もりは余裕をもって組むべきだ。

Q. プログラミング知識がなくても使える?

Makeはノーコードで非エンジニアでも当日から組める。n8nもノード型UIで基本操作は可能だが、セルフホストの初期構築や高度なフローには技術知識が要る。担当者主体ならMake、開発者主体ならn8nが向く。

Q. ZapierからどちらにETすべき?

複雑な分岐や料金を理由に移るなら、SaaS中心の運用はMake、自前運用やコード拡張が必要ならn8n。どちらもZapierより複雑フローに強く、料金が読みやすい。

Q. GDPRなどデータ規制が厳しい場合は?

n8nのセルフホストが現実的だ。データを自社サーバーに完結させられるため、データレジデンシー要件を自前で満たせる。Makeはクラウド専業のため、提供側のポリシーに依存する。