Difyの「質問分類器」ノードを触ってわかった、n8nとの設計思想の決定的な違い

ノーコードでAIを組みたいとき、選択肢は1つじゃありません。

n8n、Zapier、Make、Power Automate、そしてDify。どれも「コードを書かずに自動化を組める」と謳います。じゃあAI処理を中心にしたワークフローはどれで組むのが正解か？

僕は先月、n8nとGeminiで問い合わせメールを自動仕分けする仕組みを作ったばかりです。同じ題材を今回はDifyで組んでみて、両者のクセが正反対であることに気づきました。

この記事は「Difyの質問分類器という専用ノードを使うと、AI分類タスクが本当にノード3つで終わる」という体験記であり、同時に「じゃあn8nじゃダメなの？」の答えでもあります。

結論：「AI処理が主役」ならDify、「データ前後処理が主役」ならn8n

先に結論。

※1 n8n版で詰まった「Text フィールドが Fixed モードのまま {{ $json.本文 }} を文字列として送ってた」件はこちらに書きました。

「AI分類器」だけ作りたいならDifyの方が速い。3ノードで終わる。

ただし、本番運用で「Gmail → AI仕分け → Sheets転記 → Slack通知」まで一気通貫でやりたいなら、n8nの方が連携の幅で勝ちます。

以下、Difyで実際に組んだ手順と、n8nと比べての所感を順に書きます。

ノードたった3つで完成するAI分類器

Difyのワークフローエディタで完成形はこれです。

スタートノード → 質問分類器ノード → 出力ノード。これだけ。

n8n版は「手動トリガー → Edit Fields → Information Extractor → Google Sheets → Slack」の5ノード構成で、しかも Information Extractor のText フィールドを Expression モードに切り替えるという「初心者が必ず詰まる落とし穴」がありました。

Difyの質問分類器は専用ノード。設定画面でクラス（カテゴリ）を入れて、入力変数を1個指定すれば終わります。

モデル欄に「Gemini 3.1 Pro Preview」が初期表示されています（Difyにあらかじめ登録してあるモデルから自動選択）。入力変数欄でスタートノードの inquiry_body を選ぶだけ。「テキストを文字列としてではなくExpressionとして渡す」みたいな概念がそもそも存在しません。

ここが今回いちばん感心したポイント。n8nの汎用ノード哲学とは違う、Dify特有の「AIタスク専用ノード」設計思想です。

4分類するなら、クラス欄に日本語で書くだけでいい

質問分類器の設定パネルで「クラスを追加」を2回押して、4つのトピック名を入れました。

プロンプトを書く必要が一切ない。 トピック名そのものが分類軸になります。

n8nのInformation Extractorで同じことをやろうとすると、System Promptで「以下のいずれかに分類してください: 見積依頼…」みたいなプロンプト設計が必要でした。Difyは「クラス名＝分類軸」が前提になってる。

ここでもDifyの方が圧倒的に早い。

試してみる：見積依頼の本文を入れたら一発で当たった

テスト実行パネルに、こういう本文を貼ります。

御社サイトを拝見しました、株式会社サンプルの田中と申します。弊社サイトのLP制作をお願いしたいと考えております。ページ数は1ページ、納期は来月末を希望しています。お見積もりをいただけますでしょうか？

「実行開始」を押して7秒。

結果タブに「見積依頼・料金に関する質問」と表示されました。詳細情報を見るとステータスSUCCESS、処理時間 12.171秒、トークン総数 1549 tokens、出力JSON は {"category": "見積依頼・料金に関する質問"}。

「コードを1文字も書かずに、本物のAI分類器が動いた」。これがDify。

ここからが本題：Dify固有の「静かな事故」を踏む

n8nとは違うDifyならではの地雷に、ここで突き当たります。

同じワークフローに技術質問の本文を入れて実行してみました。

いつもお世話になっております。先週導入したシステムですが、ファイルをアップロードしようとすると毎回エラーが出てしまいます。Chromeのバージョンは最新、画像ファイル(.png、2MB)です。何か設定が必要でしょうか？

7.5秒待って結果を見たら——

• ステータス：SUCCESS（緑チェック）
• 出力JSON：{} 完全に空っぽ

ワークフロー図上ではスタート・質問分類器・出力ノードすべて緑チェック。一見、全部成功したように見えるのに、出力は無い。

n8nだったら「次のノードに何が来てるか」が線で明示的に追えるので、こういう謎の空出力は起きにくいです。Difyは設計上、各分岐先（CLASS 1〜4）を全部別々に後段ノードへ繋がないといけない。そして繋ぎ忘れた分岐に分類された場合、Difyは「分類はできた、後段が無かった、終わり」という扱いでSUCCESSを返す。

これ、n8n慣れしていると逆に踏みます。「分岐ノードが落ちなかったらSUCCESS」というのは、僕の知ってるノーコードの常識とは違いました。

真犯人と直し方：「分岐先は全部繋いで初めて完成」というDifyの作法

質問分類器のCLASS 1の右にだけ青い「+」から出力ノードを繋いでいて、CLASS 2/3/4 は宙ぶらりんでした。CLASS 2に分類された瞬間、流れる先がない。

直し方は単純で、CLASS 2・3・4 のそれぞれの「+」から出力ノードを繋ぎます。最小構成なら同じ「出力ノード」に4本まとめて流すだけでもOK。カテゴリ別に違うアクション（Slack通知先を分ける、Sheetsの転記タブを分ける）にしたければ、そこから先で IF/ELSE で分岐する設計にします。

n8nだと「条件分岐ノードのTrue側だけ繋いでFalse側が宙に浮く」と、デバッグ時に明示的に「false出口に何も繋がってません」みたいな警告が出やすい印象でした。Difyは出てくれない。ここはn8n経験者ほど踏みやすい罠です。

Difyとn8nを「使い分ける」基準

両方触ってみて、僕なりの使い分けは以下になりました。

Difyが向くケース

• AIタスクが主役のワークフロー（分類・要約・抽出・翻訳など）
• プロンプトを書きたくない人
• チャットボット型のUIをそのまま外部公開したい
• 「AIに何かやらせる」だけで完結する小型ワークフロー

n8nが向くケース

• データの前後処理が主役（Gmail/Slack/Sheets/Notion等の連携が肝）
• AI処理は途中の1工程にすぎないワークフロー
• 同じ処理をスケジュール実行したい（毎朝9時にGmailをチェック等）
• セルフホスト・OSS文化が好きな人

両方使うのが正解なケース（おそらく一番多い）

実務だと、「Gmail受信 → Dify APIで分類 → Sheets転記 → Slack通知」のようにn8nを土台にして、AI処理だけDifyに切り出す構成が現実解だと感じます。

DifyのワークフローはAPI公開できるので、n8nのHTTP Requestノードから呼ぶ形にすれば、両方のいいとこ取りができます。

本番運用に乗せるなら：人検証を最初から設計に入れる

n8n版でも書いたことですが、AI分類器を実業務に組み込むなら「AIが分類したカテゴリ」列と「人が確認したカテゴリ」列を分ける設計が鉄則です。

具体的には：

1. Difyの出力をスプレッドシートに書き込む
2. AI分類列と人検証列を別カラムにする
3. 担当者にSlackで通知を飛ばす
4. 月次で「AI分類と人検証の一致率」を計測 → 外れの多いクラスはトピック名を見直す

「95点AI＋5点人＝100点運用」という設計思想は、ツールが何であっても変わりません。

Dify版「つまずき早見表」

まとめ

• Difyの質問分類器は、n8nのInformation Extractorとは思想が違う「AI処理専用ノード」で、3ノード・コードゼロで分類器が完成する
• ただし全分岐先を後段に繋がないと「成功なのに出力空」という静かな事故を起こす（n8n経験者ほど踏みやすい）
• AI処理が主役ならDify、データ連携が主役ならn8n、本番運用は両方を組み合わせるのが現実解
• どちらを使うにしても、AI分類は人検証列を最初から組み込んだ設計に寄せておく

n8n版を読んでくれた人にこそ、Difyの質問分類器は一度触ってみてほしいです。「AI処理ノード」の設計思想が違うと、こんなにスピード感が変わるのか、を体感できます。