n8nとMakeの選び方：問い合わせの分類・人の確認・記録を両方で設計して比べる

2026-10-08 改訂のお知らせ 旧版には事実の誤りと、根拠を示せない記述がありました。旧版ではn8nのシリーズB（資金調達）を「$20M」と書いていましたが、公式発表では2025年3月25日、5500万ユーロ（€55M）です。また、旧版ではn8nを「OSS（オープンソース）」として扱っていました。実際は、セルフホスト版はSustainable Use Licenseという、使い方に条件が付いたライセンスで提供されています。テンプレート数、検索トレンド、「将来性ではn8nが一歩リード」といった勝敗の判定は、出典を示せないため削除しました。料金の数え方は現在の公式の用語に直しています。本文は、比較表で勝敗を付ける形から、同じ業務を両方のツールで設計して見比べる形に書き直しました。

この記事の確認範囲：2026年10月8日時点で、n8nとMakeの公式ドキュメント、公式ヘルプ、公式ブログを確認しました。後半の設計例は、どちらのツールでも実行して確かめてはいません。ノード名やモジュール名は公式ドキュメントで存在を確認しています。ただし、画面上の細かな設定項目は、お使いの版で必ず確かめてください。

はじめに：「どちらが上か」より「自分の業務で組めるか」
題材にする架空の業務
n8nでの設計例：1本のワークフローで「待つ」
Makeでの設計例：2本のシナリオと「表に残す状態」
何を確認して選ぶか
つまずきやすい点
まとめ
参考リソース

はじめに：「どちらが上か」より「自分の業務で組めるか」

n8nとMakeは、どちらもSaaS（クラウドで提供されるサービス）やAPIを画面上でつなぎ、業務を自動化するツールです。比較記事では「初心者ならMake、本格派ならn8n」のように結論が一言で書かれがちです。しかし実際に困るのは、選んだ後の場面です。たとえば「AIの判定を人が確認してから記録したい」と思った途端、両者で組み方が大きく変わります。

そこでこの記事では、架空の問い合わせ対応フローを1つ決め、n8nとMakeでそれぞれどう設計するかを並べます。読み終えると、次の3つを自分で判断できるようになります。

ライセンスや動かす場所の面で、自分の使い方がそのツールの条件に合うか
「人の確認待ち」という状態を、どちらの組み方なら無理なく保てるか
課金の単位から、自分の件数でどれくらい消費するかを見積もる方法

想定読者は、ノーコード自動化を少し触ったことがあり、AIを業務フローに組み込みたい人です。

題材にする架空の業務

題材は、小さなオンラインショップに届く問い合わせです。フォームから届いた文章をAIが「返品・交換／配送／請求／その他」に分類します。次に担当者が分類の正しさを確認し、確定した内容をスプレッドシートの台帳に記録します。

この業務には、自動化でつまずきやすい要素が3つ含まれています。1つ目は、AIの判定が外れることを前提にする必要がある点です。2つ目は、人が確認するまで数時間待つことがある点です。3つ目は、途中で失敗しても台帳に跡を残したい点です。

まず、同じ業務を2つのツールでどう組み立てるかの全体像を見てください。左右の列で、どこから流れが分かれるかに注目してください。

図1：同じ業務でも、n8nは「1本の流れの中で待つ」、Makeは「2本の流れに分けて状態を表に持たせる」設計になります。（静止画版）

両方の設計で、台帳には同じ列を使います。最初に表を用意しておくと、どちらのツールでも記録先を迷わずに済みます。

inquiry_id,received_at,channel,body,category,status,approval_token,reviewer,decided_at,note

status 列には pending（確認待ち）、approved（承認）、rejected（差し戻し）のいずれかを入れます。approval_token 列はMake版でだけ使います（後述）。

分類カテゴリには、AIに渡す説明文も用意します。カテゴリ名だけでは、境界があいまいなときにAIの判断がぶれやすくなります。説明文があれば、人が確認するときの基準としても使えます。

返品・交換: 商品到着後の返品、サイズや色の交換、初期不良の相談
配送: 発送時期、追跡番号、届け先住所の変更
請求: 支払い方法、領収書、請求額の誤りの疑い
その他: 上のどれにも当てはまらない、または複数にまたがるもの

n8nでの設計例：1本のワークフローで「待つ」

n8nでは、承認待ちをワークフローの一時停止として表現できます。以下は実行していない設計例です。

順番	使うノード	設定のポイント
1	Webhook（またはForm Trigger）	問い合わせのJSONを受け取る
2	Text Classifier	前述の4カテゴリと説明文を登録する
3	Google Sheets（Append Row）	`status=pending` で先に記録する
4	Slack（Send and Wait for Response）	Response TypeをApprovalにする
5	IF → Google Sheets（Update Row）	`inquiry_id` で行を特定し、結果と承認者を書き込む

Text Classifierは、言語モデルを使って入力を指定したカテゴリに振り分けるノードです。公式ドキュメントによると、どのカテゴリにもはっきり当てはまらない場合の扱いを選べます。初期設定では、その項目を捨てます。もう1つの設定では、「Other」という別の出力に流します（Text Classifier）。問い合わせを黙って捨てるのは避けたいので、この設計ではOtherに流す設定を選びます。Otherに流れたものも台帳に記録し、人の確認に回します。

手順3で「確認の前に記録する」のは、承認待ちの間に何か起きても台帳に跡を残すためです。Google Sheetsノードには「Append Row」と「Update Row」があり、更新時は照合に使う列を指定できます（Google Sheets sheet operations）。

手順4のSlackの承認機能では、Slack上のボタンで承認・却下でき、出力には誰が応答したかが記録されると公式ドキュメントに書かれています（Slack approvals）。ただし前提条件があります。n8nがHTTPSでインターネットから到達できること、Slack側でSigning SecretとInteractivityを設定することです。自宅PCの localhost で試している段階では、Slackからの応答を受け取れません。

独自の待機フローを組む場合に使えるのがWaitノードです。待機が65秒以上になると実行データをデータベースへ退避し、再開条件を満たした時点で読み込み直して続きを実行します（Wait）。担当者が翌朝に承認しても、流れはそこから再開します。

失敗時の通知には、Error Triggerノードで始まる「エラーワークフロー」を別に作ります。そのうえで、本体のワークフローの設定から紐づけます（Error Trigger）。

Makeでの設計例：2本のシナリオと「表に残す状態」

Makeでは、自動化の単位をシナリオと呼びます。この設計例では、承認待ちを1本のシナリオの中で表さず、台帳の行に状態を持たせて2本に分けます。これも実行していない設計例です。

シナリオ1（受付と分類）

Webhooks の Custom webhook で問い合わせを受け取る
Make AI Tools の Categorize text で分類する。このモジュールは、あらかじめ決めたカテゴリ一覧から当てはまるものを選びます。理由の説明を返すかどうかと、カテゴリを1つに絞るかどうかも指定できます（Make AI Tools）
Routerで分岐する。各ルートにはフィルターで条件を付けます。どの条件にも当てはまらないデータはフォールバックルートに流れます（Router）。ここに「その他」の処理を置きます
Google Sheetsに status=pending と、推測されにくいランダムな文字列（UUIDなど）を approval_token として記録する
Slackに、認証付きの確認画面へのリンクを投稿する。画面を開くだけでは状態を変えない

シナリオ2（承認の反映）

ログイン済みの確認画面で、担当者が承認または差し戻しを選ぶ
確認画面のサーバーが、ログイン情報から承認者のIDと権限を確認する。画面の表示やリンクのプレビューでは更新せず、明示的なPOSTで送る
サーバーからMakeのCustom webhookへ判断結果を送る。受信側でも署名などで送信元を検証し、問い合わせID、期限、使い捨てトークンを照合する
pending の申請だけを一度更新し、承認者・判断日時を保存する。外部台帳への反映に失敗したら再試行できる記録を残す

この部分には、確認用アプリと状態を管理する保存先の実装が別途必要です。以下は送信データの設計例で、実行済みの設定ではありません。

{"inquiry_id":"Q-0001","decision":"approve","reviewer_id":"authenticated-user-id","request_id":"unique-decision-id"}

承認者の名前をフォームに入力するだけでは、本人確認にはなりません。また、URLのクリックで状態を更新すると、Slackのリンクプレビューやセキュリティスキャナーによって意図せず承認されることがあります。トークンをURLに載せず、認証済みの画面で判断を確定させます。

スプレッドシートで pending を読み、その後に書き込むだけでは、同時に届いた2件の判断を防げません。本番で二重処理を防ぐには、データベース側で「pendingの場合だけ更新する」条件付き更新と、一意なrequest_idの管理を行います。表は閲覧用の台帳として同期する構成が考えられます。これは本稿の設計提案で、Makeの機能だけで自動的に保証されるものではありません。

次の図で、承認を待つ間にデータがどこにあるかを2つのツールで比べてください。

図2：n8nは「止まった実行」を保存して待ちます。Makeの設計例では「表の1行」が待っている状態そのものを表します。（静止画版）

Makeの公式ヘルプにはWebhookの制限も書かれています。受け取ったリクエストはWebhookごとのキューに入り、キューの上限は契約クレジット数に応じて決まります。受信できるのは10秒あたり300件までです（Webhooks）。失敗時の扱いは、モジュールにエラーハンドラーを付けて決めます。未完了の実行を保存して再試行することもできます（Error handlers）。

動作の確認は、どちらのツールでも同じように始められます。テスト用の問い合わせを1件送るコマンドは次のとおりです。

# 受付用WebhookのURLにテスト用の問い合わせを1件送る（URLは各ツールの画面で確認する）
curl -X POST "<YOUR_INTAKE_WEBHOOK_URL>" \
  -H "Content-Type: application/json" \
  -d '{"inquiry_id":"Q-0001","channel":"form","body":"届いた靴のサイズが合わないので交換したいです"}'

分類が明らかな文章のほかに、「交換したいけど送料は誰が払う？」のような2つのカテゴリにまたがる文章も用意して送ってみてください。Otherの出力やフォールバックルートが、意図したとおりに働くかを確かめられます。

何を確認して選ぶか

設計を並べると、比べるべき点が見えてきます。ここからは、選ぶ前に確かめる順番を整理します。

1. ライセンスと提供形態は、自分の使い方に合うか

n8nを最初に確かめるべき点はライセンスです。n8nは無料で自由に使えるOSSではありません。セルフホスト版はSustainable Use Licenseで提供されています。公式FAQによると、自社内の人だけがワークフローを作る・編集する使い方や、顧客向けに自社で自動化を構築・保守する使い方は、無料の範囲に含まれます。一方、n8nをサービスとして提供して顧客にワークフローを作らせることは禁じられています。独自の画面やAPI、AIエージェント経由で外部の利用者にワークフローを構成させることも同様です。n8nのコードをフォークして自社の自動化製品を出すこともできません（License FAQ）。こうした使い方をするには、Enterpriseライセンスが必要です。

Makeは、Make社が運用するクラウド上でシナリオを動かすサービスです。社内ネットワークにあるシステムへファイアウォールの設定を変えずに接続したい場合は、On-premise agentを使います。ただし、公式ヘルプでは利用できるのはEnterpriseの顧客とされています（On-premise agent）。On-premise agentは社内システムへの接続手段であり、Make全体を社内だけで動かす機能ではありません。データを外部に出せない要件は、シナリオ・実行ログ・外部AIへの送信まで含めて別途確認します。n8nのセルフホストも、外部AIを呼べばデータが外へ出ます。

2. 課金の単位で、自分の件数を見積もる

料金の金額はプランや時期によって変わるため、この記事では載せません。代わりに、何が1回と数えられるかを押さえてください。

項目	n8n（公式の料金ページのFAQ）	Make（公式ヘルプ）
数える単位	execution（実行）	credit（クレジット）
数え方	ワークフロー全体の1回の実行を1回と数え、ステップ数やデータ量は問わない	2025年8月27日から、operation（モジュールの実行）に代わって課金単位になった。多くの機能は1 operationにつき1クレジット
注意点	無料のCommunity版にも運用費はかかる。有料セルフホストプランもあるため、契約区分とライセンスを確認する	AIモジュールなどは使用量に応じて消費が変わる。MakeのAIプロバイダーはトークン量に応じて消費する

出典は、n8nがn8n Pricing、MakeがCredits as new billing unitとMake AI Toolsです。

この記事の設計例に当てはめて見積もる場合、n8nでは「月の問い合わせ件数」が出発点になります。Makeでは「シナリオ1と2のモジュール数 × 件数」に、AIモジュール分を別に足して考えます。旧版にあった「フローが長いほどn8nが割安」という結論は、件数、AIの使い方、セルフホストの運用費によって変わるため、一般論としては書けません。自分の数字で見積もってください。

3. 確認待ちの状態を、どちらで持つほうが管理しやすいか

最後に、運用を担当する人にとって分かりやすいかを考えます。n8nは、待っている実行がツールの中に残ります。一方、外部から届く承認の応答を受けるために、サーバーをHTTPSで公開する準備が必要です。Makeの設計例は、待っている状態がすべて台帳に見えます。表計算に慣れたチームには分かりやすい反面、本人確認や二重処理を自分で設計する必要があります。

ここまでの確認を、順番にたどれる形にまとめました。

ツールを選ぶ確認順。On-premise agentだけで「社内完結」と判断しない

図3：ライセンス → 動かす場所 → 課金の単位 → 状態の持ち方、の順に確認すると、選べない理由を先に見つけられます。（静止画版）

つまずきやすい点

設計例を実際に組むときに、引っかかりやすい点を表にまとめました。いずれも公式ドキュメントの記述に基づく注意点で、実際に起きた結果を報告するものではありません。

症状	確認すること
n8nでSlackの承認ボタンを押しても流れが再開しない	n8nがHTTPSで外部から到達できるか。Slack側のInteractivity、Signing Secret、必要な権限（scope）の設定
n8nで分類できなかった問い合わせが台帳に残らない	Text Classifierの「当てはまらない場合」の設定が、初期値の「捨てる」のままになっていないか
Makeで「その他」の処理が動かない	Routerにフォールバックルートを設定したか
Makeで承認が二重に記録される	認証に加え、保存先での条件付き更新とrequest_idの重複防止を実装したか
Makeで大量の問い合わせを受けると、一部がエラーになる	Webhookの受信件数の上限（10秒あたり300件）とキューの上限

まとめ

n8nとMakeは、どちらが上という関係ではありません。待つ状態をどこに持つかという設計の考え方が違います。本稿のn8n設計例は、1本のワークフローの中で一時停止して待ちます。Makeの設計例では、状態を台帳に書いてシナリオを分けます。選ぶ前には、①ライセンスと提供形態、②動かす場所、③課金の単位、④状態の持ち方、の順で確認してください。

次の一歩としておすすめするのは、この記事の台帳とカテゴリの定義をそのまま使い、両方の無料の範囲で同じ10件のテスト用問い合わせを流してみることです。設計図を読み比べるよりも、どちらが自分のチームに合うかがはっきり分かるはずです。