n8n、Make、Zapierを2026年版で徹底比較。料金モデル、AIエージェント機能、セルフホスト可否、LangChain統合の違いを整理し、RAG・マルチエージェント・人間承認の実装パターンとZapierからn8nへの段階移行戦略まで、本番運用の知見をもとに解説します。
最終更新: 2026年6月30日
AIワークフロー自動化ツールとして2026年に第一候補となるのは、技術チームかつLLM処理量が多い場合は n8n、視覚的に複雑な分岐ロジックを設計したいSMB向けには Make、非技術チームが8,000以上のSaaS連携を素早く組みたい場合は Zapier です。3製品とも今やAI Agentノードを備えていますが、課金モデル（実行単位かタスク単位か）、セルフホストの可否、LangChain互換性に大きな差があります。本記事では、私が直近で本番運用した3つのパイプラインを題材に、どの判断軸でツールを選ぶべきかを整理します。
3製品はいずれも「トリガー → 条件分岐 → アクション」というワークフロー自動化の同じプリミティブを提供しますが、設計思想が異なります。Zapier はノーコード民主化路線で、人事担当者がフォーム回答からSlack通知を組むまで5分で済ませることを最優先設計しています。Make（旧Integromat）はビジュアルキャンバスで複雑なフィルタとアグリゲータを扱える「ノーコードのPower User向け」、n8n は2022年以降「Fair-codeのオープンソース＋セルフホスト可能なクラウドサービス」として、Series B 5,500万ドル調達以降エンタープライズに本格対応しました。
私の現場経験で線を引くなら、「JSONを触る抵抗感」が分水嶺です。Make も n8n も値マッピングで JSON パスを書きますが、Zapier は「Step 3 のoutput」をプルダウンで選ぶだけで完結します。AIワークフローの場合、LLM の出力構造を JSON で受けて下流で展開することがほぼ必須になるため、Zapier の抽象は早晩破綻します。逆に Webhook を1日数万回叩く軽量ETL用途では、Zapier のシンプルさが運用負荷を下げます。
もう一つの違いは開発者体験です。n8n は Code ノードで TypeScript/JavaScript を直接書け、npm パッケージも持ち込めます。Make の Custom App は JSON IML 記述、Zapier は Zapier CLI と Node.js の Platform SDK が必要です。CI に乗せられるか、Git で差分管理できるか、という観点では n8n が圧倒的に有利で、私のチームは workflow JSON を GitHub にコミットしてプルリク経由でデプロイしています。
| 項目 | n8n | Make | Zapier |
|---|---|---|---|
| 課金単位 | 実行(workflow run) | オペレーション(モジュール実行) | タスク(アクション) |
| 有料エントリ価格(2026年5月) | $24/月 (Cloud Starter) | $10.59/月 (Core) | $29.99/月 (Professional) |
| セルフホスト | ○ (Community Edition / Docker) | × (クラウドのみ) | × (クラウドのみ) |
| ネイティブ連携数 | 1,000+ | 1,500〜3,000 | 8,000+ |
| AIエージェントノード | AI Agent Tool Node (LangChain) | Make AI Agents + Maia | Zapier Agents + Copilot |
| ベクトルDB連携 | Pinecone, Qdrant, Weaviate, Supabase pgvector ほか | Pinecone, Qdrant (限定) | Pinecone (経由) |
| マルチエージェント | ○ (AI Agent Tool node ネスト可) | △ (サブシナリオで擬似的) | △ (Agent間ハンドオフのみ) |
| 人間承認(HITL) | ○ (Wait + Slack / Telegram / Chat) | ○ (承認モジュール) | ○ (Pause Path) |
| Code ノード | JavaScript / Python (Pyodide) | JavaScript | JavaScript / Python |
| 監査ログ・SSO・SCIM | Enterprise プラン | Enterprise プラン | Team以上 / Company SSO |
2026年に入り、3製品ともに「AIエージェント」を看板機能に掲げています。表面上の用語は似ていますが、実装の深さは大きく異なります。n8n 2.0 の AI Agent node ドキュメント を読むと、v1.82.0 以降は Tools Agent 一本化され、LangChain の Tool Calling インターフェースで OpenAI / Anthropic / Google Vertex AI / Mistral / Ollama のいずれにも切替可能になっています。サブノードとして Window Buffer Memory、Summary Memory、Postgres / Redis 永続メモリが選択でき、Vector Store Retriever Tool で RAG を1ノードで挟めます。
Make の Make AI Agents と Maia は、視覚キャンバス上でエージェントが「どのモジュールをツールとして呼べるか」を宣言する形式です。シンプルなトリアージや要約タスクは数分で組めますが、エージェントの自己反省（reflection）ループや、別エージェントを呼び戻すような循環は、Make のシナリオモデル（基本は有向非巡回）と相性が悪く、サブシナリオで擬似実装することになります。
Zapier Agents は「タスクの指示文を自然言語で書く」体験に振っており、Slack の通知に応じて Hubspot を更新する、といったCRM寄りの単純エージェントには最適です。一方、複数LLMをファンアウトして結果を集約するような構造は、Zapier の Step ベース実行モデルでは表現できません。
エージェントの「賢さ」はランタイムではなくモデルとプロンプト設計で決まるので、ここで気にすべきはEval（評価）が回せるかです。私は AIエージェントのEvals実践 で書いた決定論的チェック＋LLM-as-a-Judgeのパターンを n8n の Execution データから直接回しており、Zapier の Task History からは同等の構造化データが取れません。
AIワークフローでツール選定の決定打になりやすいのが課金モデルです。Zapier の「タスク = アクション1回」モデルでは、LLMノード → JSONパース → ベクトル検索 → 結果整形 → DB書込み → Slack通知の6ステップは、1ワークフロー実行ごとに6タスク消費します。月10,000回動かすと60,000タスク、Professional プランの上限（2,000タスク/月）では到底足りず、Company プラン（$103.50/月で2,000タスクから始まり、Volume Discountで段階課金）が必須になります。
n8n は「ワークフロー1回完走 = 1 execution」のため、同じ6ステップでも月10,000 executions です。n8n Cloud Pro（$60/月、10,000 executions）にちょうど収まる規模で、Zapier 比で1桁安くなります。Make は中間で、各モジュールがオペレーションとしてカウントされますが、ルーターやアグリゲータの内部処理は1オペレーションに圧縮されるため、Zapier ほど膨らみません。
セルフホスト版の n8n には execution 課金そのものが存在しないため、Hetzner や AWS EC2 の t3.medium で月$30程度で無制限実行が可能です。私のチームは本番ワークフローのうちLLM呼び出しが多いものを Community Edition + Postgres で運用し、コストはほぼ「OpenAI / Anthropic への請求」だけに収束しました。
2026年現在、医療・金融・公共セクターを中心に「LLMに渡すデータが第三者クラウドを通過しないこと」を要件にする案件が増えています。n8n の Community Edition は GitHub リポジトリ から Docker Compose 一発で立ち、自社VPCの中で OpenAI 互換 API（Azure OpenAI on Private Endpoint、AWS Bedrock VPC エンドポイント、自社ホストの vLLM など）に閉じた構成が組めます。
Make と Zapier はクラウド専有で、データレジデンシーは Zapier が米国・EU・オーストラリアの3リージョン、Make が EU・米国の2リージョンを選べる程度です。Zapier はエンタープライズプランで「AIモデル学習からの自動オプトアウト」を保証していますが、これは「Zapier のクラウドを経由する」前提が崩せないので、データ越境そのものを禁じる規制下ではどちらも採用できません。
セルフホスト構成では、別途 PostgreSQL（実行履歴の保持）、Redis（キュー）、外部ベクトルDB（Qdrant / Weaviate のセルフホスト版）の管理が必要です。私が運用しているスタックは n8n + Postgres + Qdrant + Caddy(リバースプロキシ) で、Terraform で IaC 化しています。LangGraphで構築するAgentic RAG の記事で扱った自己修正検索ループも、n8n の AI Agent Tool node + Vector Store Retriever でほぼ同じ構造を視覚的に実装できます。
「AIワークフロー」と言っても、求められる要件はユースケースで大きく分かれます。私が現場で使い分けている判断軸を示します。
Slack のメッセージを要約してドキュメントに貼る、CRM のリードを自動分類する、といった用途は Zapier が最速です。Zapier Copilot に自然言語で書けば下書きが完成し、Slack 管理者の承認だけで運用に入れます。タスク量が月数千の範囲なら課金も問題になりません。
カスタマーサポートのチャットボット前段や、ウェブフォーム経由のリード自動応答は Make のシナリオモデルが向いています。視覚的に分岐とエラー処理を見渡せ、Maia によるノーコードAI支援も成熟しました。
社内ナレッジベースの RAG、複数LLMによる多視点要約、ベクトルDB と既存DBの結合、いずれも n8n 一択です。LangChain ネイティブ統合と70+のAIノードで、Python の LangGraph で書く構造をほぼ同等にビジュアル化できます。Claude Agent SDK の本番運用パターン で扱った Hooks やコスト制御も、n8n の Execute Workflow ノード + コスト記録テーブルで似たアーキテクチャに落とせます。
セルフホスト + VPC 内 LLM が必須なので、選択肢は n8n Community Edition もしくは Enterprise のみです。Audit Log、SSO、SAML、SCIM が必要なら Enterprise ライセンスを検討します。
抽象論だけだと判断が難しいので、私が2026年に実際に組んだ3パターンを n8n のワークフロー定義で示します。Make / Zapier に移植する場合の制約もあわせて記載します。
// n8n workflow JSON 抜粋（コア部分のみ）
{
"nodes": [
{ "name": "Webhook", "type": "n8n-nodes-base.webhook",
"parameters": { "path": "ask", "httpMethod": "POST" } },
{ "name": "Embed Query", "type": "n8n-nodes-langchain.embeddingsOpenAi",
"parameters": { "model": "text-embedding-3-large" } },
{ "name": "Qdrant Retriever", "type": "n8n-nodes-langchain.vectorStoreQdrant",
"parameters": { "mode": "load", "topK": 6 } },
{ "name": "AI Agent", "type": "n8n-nodes-langchain.agent",
"parameters": {
"promptType": "define",
"text": "={{ $json.question }}",
"systemMessage": "あなたは社内RAGアシスタント。検索結果に無い情報は\"不明\"と答える。"
} },
{ "name": "Anthropic Chat", "type": "n8n-nodes-langchain.lmChatAnthropic",
"parameters": { "model": "claude-sonnet-4-6", "temperature": 0.2 } }
]
}同じ構造を Make で組むと、Vector Search モジュールが Pinecone のみ対応で Qdrant が使えず、HTTP モジュール経由で自前実装する必要があります。Zapier では Step 数が膨らみ、課金面で割に合いません。
サポートチケットを「請求」「技術」「機能要望」のサブエージェントに振り分けるパターン。n8n の AI Agent Tool node を3つネストするだけで実装できます。
// 親エージェントが3つの子エージェントをTool として呼ぶ
{
"name": "Triage Agent",
"tools": [
{ "type": "aiAgentTool", "name": "billing_agent",
"description": "請求・支払いの質問を処理する" },
{ "type": "aiAgentTool", "name": "technical_agent",
"description": "技術的なバグや障害の質問を処理する" },
{ "type": "aiAgentTool", "name": "feature_agent",
"description": "機能要望をプロダクトチームに転送する" }
]
}Zapier Agents でも同種のハンドオフは可能ですが、子エージェントから親に結果を返す制御がやりにくく、デバッグログも親エージェント側からは見えません。
LLM が請求金額を抽出 → Slack に承認ボタン送信 → 承認後に会計SaaSへ書き込み、という典型的なHITLパターンです。n8n では Wait ノードで Resume URL を発行し、Slack の Interactive Message に埋め込みます。Wait は最大365日まで保持できるため、未承認のまま週末を挟んでも問題ありません。
// Wait ノードの設定
{
"name": "Wait for Approval",
"type": "n8n-nodes-base.wait",
"parameters": {
"resume": "webhook",
"options": { "webhookSuffix": "approve" }
}
}
// Slack へ送るボタンの action_url
// {{ $execution.resumeUrl }}「Zapier が高くなったので n8n に移行したい」という相談を毎月のように受けます。一括移行は事故のもとなので、私は3ステップで進めます。
3製品いずれも「単体で完結する魔法の箱」ではありません。トリガー、メモリ、LLM、リトライ、コスト、コンプライアンスをそれぞれ別の軸として測り、案件ごとにフィットを判断するのがワークフロー設計者の仕事だと考えています。
n8nは「ワークフロー1回完走 = 1 execution」課金、Zapierは「アクション1回 = 1タスク」課金です。10ステップのAIパイプラインを月1万回動かす場合、n8nは1万 execution、Zapierは10万タスクを消費するため、約1桁の差が出ます。さらにn8nはセルフホストすれば execution 課金そのものがゼロになります。
Makeの「オペレーション」はシナリオ内のモジュールが1回データを処理した単位を指します。1ステップ = 1オペレーションですが、ルーターやアグリゲータの内部処理は1つに圧縮されるため、Zapierのタスク課金より膨らみにくい設計です。Coreプランで月10,000オペレーション、$10.59/月から利用できます。
Community Editionは Fair-code ライセンスのオープンソース版で、Docker や Kubernetes に自己ホストできます。SSO・SAML・監査ログ・SCIMといったエンタープライズ機能は含まれません。Cloud は n8n社が運用するマネージドサービスで、Starter $24/月から始まり、SLAとサポートが付きます。
直接的なLangChainノードは2026年時点で n8n のみが提供しています。ZapierとMakeでも、Code ステップから LangChain (JS) や langchain-python を呼ぶことは可能ですが、Vector Store・Retriever・Memory・Output Parser をビジュアルに繋ぐ体験は得られず、運用上の利点は限定的です。
HIPAA、SOC2 Type II、GDPR、日本の改正個人情報保護法のいずれかを完全に満たし、かつデータが国境を越えないことを保証したい場合、セルフホスト可能な n8n 一択になります。Zapier と Make はクラウド専有で、データレジデンシーをリージョン単位でしか指定できません。
プロンプトを変えるたびに本番で炎上していませんか。決定論的アサーション70%＋LLM-as-a-Judge 30%のハイブリッドeval構成を、promptfoo・Python・GitHub Actionsの実コードで解説します。
Claude Agent SDK を本番運用するときに必須となる5つの設計パターン(耐久セッション・ハードコスト上限・最小権限ツール・サーキットブレーカ・評価フック)を、Python と TypeScript の実装例とともに解説します。
LangGraphを使ったAgentic RAG（自律型RAG）の実装方法を解説。Adaptive RAG・Corrective RAG・Self-Reflective RAGの3パターンを統合し、動的クエリルーティング、文書グレーディング、ハルシネーション検出を備えた自己修正型検索パイプラインをPythonで構築する実践ガイドです。