Difyの質問分類器とは？チャットフローとワークフローで使う分岐の要
室谷今回は質問分類器の話をしましょう。.AI（ドットエーアイ）コミュニティでも「チャットボットを作ったけど、答えがバラバラになる」という相談、毎週来るんですよね。
テキトー教師そうなんですよね。講座でもDifyの基本を覚えた後の次のステップとして「じゃあ実際の業務に使おう」としたとき、まずぶつかる壁がそこです。
単純なLLMノード1個では対応しきれない、という。
単純なLLMノード1個では対応しきれない、という。
室谷で、その解決策が質問分類器（Question Classifier）なんですよ。一言で言うと「ユーザーの質問を意図で仕分けするノード」です。
LLMがセマンティック理解をしてくれるので、キーワードが一致してなくても正確に振り分けられる。
LLMがセマンティック理解をしてくれるので、キーワードが一致してなくても正確に振り分けられる。
テキトー教師「返品したい」でも「この商品壊れてるんだけど」でも、どちらもアフターサービス系と判定してくれる。キーワードマッチングじゃなくて意味で分類するのが本質ですよね。
室谷まさに。MYUUUでも社内FAQ botを作るとき、最初は条件分岐（If-Else）で「返品という文字が含まれていたら」みたいな実装をしたんですが・・・カバーしきれないパターンが無限に出てきて（笑）。
質問分類器に切り替えてから、ほぼメンテナンス不要になりました。
質問分類器に切り替えてから、ほぼメンテナンス不要になりました。
テキトー教師If-Elseだとルールが増え続けるんですよね。コミュニティのメンバーさんから「条件分岐が50個になって管理しきれない」という話を聞いたことがあります。
そういうときこそ質問分類器の出番です。
そういうときこそ質問分類器の出番です。
質問分類器と条件分岐（If-Else）の違い
室谷ここ、整理しておきましょうか。質問分類器とIf-Elseの使い分けは、Difyを使い込んでいくと必ず迷うポイントです。
テキトー教師教える立場から言うと、ここの判断基準をひとつ持っておくと迷いがなくなります。「条件がルールで書けるかどうか」です。
数値の比較や特定フラグの有無みたいな機械的な判定はIf-Else、人間の意図や文脈の読み取りが必要なら質問分類器。
数値の比較や特定フラグの有無みたいな機械的な判定はIf-Else、人間の意図や文脈の読み取りが必要なら質問分類器。
室谷そのとおりで。「ステータスがpendingかどうか」はIf-Else。
「この問い合わせが技術系かビジネス系か」は質問分類器、という感じですね。
「この問い合わせが技術系かビジネス系か」は質問分類器、という感じですね。
| 比較項目 | 質問分類器 | If-Else |
|---|---|---|
| 判定方式 | LLMがセマンティック理解 | 条件式・ルールベース |
| 向いている用途 | 自然言語の意図分類 | 数値比較、フラグ判定 |
| 曖昧な入力への対応 | 得意 | 苦手（ルールでカバーしきれない） |
| メンテナンスコスト | カテゴリ定義を更新するだけ | ルールが増えると複雑化 |
| LLMコスト | 発生する | 発生しない |
テキトー教師LLMコストが発生するのは要注意ですね。分類のたびにLLMを呼ぶので、高頻度のシステムでは軽量モデルを選ぶのが定石です。
室谷コストと精度のバランスですよね。単純な2択分類なら速くて安いモデルで十分。
複雑な多カテゴリ分類は賢いモデルの方が精度が出る、という実感があります。
複雑な多カテゴリ分類は賢いモデルの方が精度が出る、という実感があります。
質問分類器ノードの基本設定：入力・モデル・カテゴリの3点セット
室谷では具体的な設定の話に入りましょう。質問分類器ノードを配置したとき、最初に設定するのはたった3つです。
テキトー教師「3つだけ」というのが重要で、ここをきちんと押さえれば動くものが作れます。入力変数、モデル選択、カテゴリ定義ですね。
入力変数の設定
室谷まず入力変数。分類したい文章を指定します。
チャットフローで使う場合はほぼ
チャットフローで使う場合はほぼ
sys.query（ユーザーの発言テキスト）一択です。テキトー教師ただ、ワークフローの中間で使う場合は前のノードからの出力変数を指定することもあります。たとえばLLMノードで要約したテキストを分類にかける、という設計もありますね。
室谷そのあたりがDifyの面白いところで。質問分類器は「入り口に置く」だけじゃなくて、ワークフローの途中に埋め込むこともできる。
モデル選択のポイント
テキトー教師モデル選択は、公式ドキュメントにも書かれていますが「分類の複雑さに合わせて選ぶ」が基本です。
室谷MYUUUでの実感では、2〜3カテゴリの単純な分類ならgemini-flash系やclaude-haiku系で十分。カテゴリが10個を超えてきたり、境界が曖昧なものが増えてきたら、claude-sonnet系やgpt-4o系の方が精度が安定しますね。
テキトー教師講座で教えていて気づいたのは、モデルの差よりカテゴリの定義文の差の方が精度に影響することが多いんですよ。モデルをグレードアップする前に、まずカテゴリ説明を詳しく書き直してみる、というのが先です。
室谷それは本当にそうで。「製品の質問」だけじゃなくて「製品の価格・仕様・在庫に関する質問」と書くだけで精度が上がる、というのはよくある話です・・・
カテゴリ（クラス）の定義
テキトー教師カテゴリ定義が一番重要なんですが、ここで一つ注意点があります。DifyのUIでは「クラス」と表記されているんですが、実態はカテゴリのことです。
これがわからなくて混乱するメンバーさんが多いので。
これがわからなくて混乱するメンバーさんが多いので。
室谷確かに。クラスという言葉だとプログラミングのクラスを思い浮かべてしまいますよね（笑）。
カテゴリ名とその説明を書くだけです。説明は自然言語でOKなので、プログラミングの知識は不要です。
カテゴリ名とその説明を書くだけです。説明は自然言語でOKなので、プログラミングの知識は不要です。
テキトー教師カテゴリを追加していくと、各カテゴリが「出力パス」になります。それぞれを後続のノードにつなぐ、という設計です。
整理すると、こうなります。
整理すると、こうなります。
- カテゴリ名を入力（例：「アフターサービス」）
- 説明文を記述（例：「保証・返品・修理・購入後のサポートに関する問い合わせ」）
- 追加ボタンでカテゴリを増やす
- 各カテゴリの出力パスを後続ノードに接続
室谷ポイントはカテゴリ間の境界線を明確にすることですね。説明文が曖昧だとLLMも迷います。
「価格に関する質問」と「料金プランに関する質問」は別のカテゴリにするのか統合するのか、自分たちで決めておく必要があります。
「価格に関する質問」と「料金プランに関する質問」は別のカテゴリにするのか統合するのか、自分たちで決めておく必要があります。
高度な設定：指示フィールドとメモリ統合で精度を上げる
テキトー教師基本設定だけでも動きますが、精度をさらに上げたいときは「高度な設定」に手を入れます。大きく2つあって、指示フィールドとメモリ統合です。
室谷指示フィールドは、分類ルールを細かく補足できるところです。たとえば「返金という言葉が入っていても、感謝の文脈で使われていたらアフターサービスには分類しない」みたいなエッジケースの指示を書けます。
テキトー教師エッジケースのハンドリングって、最初は軽視されがちなんですが、実際に本番で動かすと必ず出てくるんですよね。「そんな聞き方する人いるの？」という質問が必ず来る（笑）。
指示フィールドの活用
室谷指示フィールドの書き方のコツとして、実際の誤分類パターンを観察してから書くのがおすすめです。最初からあれこれ指示を詰め込まない。
動かしてみて、分類がずれたケースを1つずつ解決していく。
動かしてみて、分類がずれたケースを1つずつ解決していく。
テキトー教師それが実践的ですよね。コミュニティのメンバーさんでも「指示フィールドを先に完璧に書こうとしてハマる」というパターンをよく見かけます。
まずシンプルなカテゴリ定義で動かして、問題が出たら指示を追加していく、という反復が効率的です。
まずシンプルなカテゴリ定義で動かして、問題が出たら指示を追加していく、という反復が効率的です。
室谷具体的な例を出すと、「質問がどのカテゴリにも当てはまらない場合は、必ず『その他』に分類すること」みたいな安全弁を指示に書いておくのはいいプラクティスです。
メモリ統合で会話の文脈を読む
テキトー教師メモリ統合は、チャットフローで使うときに特に重要です。会話の文脈を踏まえた分類ができるようになります。
室谷「前の会話で価格の話をしていたユーザーが『比較してほしい』と言った」場合、単独では「比較」だと分類が難しいんですが、メモリがあると直前の文脈から価格比較の質問として正確に分類できる。
テキトー教師メモリウィンドウサイズというパラメータで、何ターン分の会話を参照するかを設定できます。大きくすると精度は上がりますが、トークン消費も増えるので、バランスを取る必要がありますね。
室谷コスト管理の観点から言うと、メモリウィンドウは「3〜5」くらいから始めて、様子を見ながら調整するのがいいと思います。短い会話が主体のBotなら3で十分ですし、長い相談系のBotなら5〜8くらい確保した方がいい。
質問分類器の出力変数（class_name）と下流ノードへの接続
室谷質問分類器が分類結果を出力するとき、
class_nameという変数に「一致したカテゴリのラベル」が入ります。これを使いこなすと、後続ノードの設計の幅が広がるんですよね。テキトー教師class_name変数は、直接後続ノードへのルーティングとして使うだけでなく、他の用途にも使えます。ログ記録や分析、条件分岐との組み合わせなど。下流ノードへの接続パターン
室谷一番シンプルなのは、各カテゴリの出力パスを直接後続ノードに繋ぐやり方。「アフターサービス」カテゴリ → アフターサービス専用のナレッジ検索ノード、という具合ですね。
テキトー教師もう少し複雑な設計だと、質問分類器の出力を受け取った後にさらにIf-Elseで細分化する、という組み合わせも使えます。大カテゴリを質問分類器で決めて、小カテゴリはIf-Elseで振り分ける、というイメージ。
室谷ハイブリッドな設計ですね。その方が実は読みやすくて管理しやすかったりします。
質問分類器のカテゴリを増やしすぎると、出力パスが多くなってワークフローが読みにくくなるので。
質問分類器のカテゴリを増やしすぎると、出力パスが多くなってワークフローが読みにくくなるので。
テキトー教師カテゴリ数の目安として、1つの質問分類器には3〜7カテゴリが扱いやすいと感じます。それ以上になるなら、2段階の分類（大→小）を検討した方がいいですね。
室谷出力変数の
」みたいなシステムプロンプトに渡して、動的にペルソナを変える設計です。
class_nameを後続のLLMノードのプロンプトに埋め込む使い方もあります。「あなたは{class_name}の専門家です。」みたいなシステムプロンプトに渡して、動的にペルソナを変える設計です。
テキトー教師それ面白いですね。1つのLLMノードでも分類結果に応じてペルソナを変えられるので、シンプルな構成でも賢い動作を実現できる。
ワークフローのノード数を増やさずに対応できるのはメリットですよね。
ワークフローのノード数を増やさずに対応できるのはメリットですよね。
知識ベースとの組み合わせ
室谷質問分類器とRAG（知識検索ノード）の組み合わせは、Difyの真骨頂だと思っています。カテゴリごとに専用のナレッジベースを用意して、ルーティングする設計です。
テキトー教師講座でよく紹介するのが「部門別FAQ Bot」の事例です。営業部門のFAQ、技術部門のFAQ、人事部門のFAQをそれぞれのナレッジベースに入れておいて、質問分類器で振り分ける。
これだけで、1つのBotで3部門に対応できます。
これだけで、1つのBotで3部門に対応できます。
室谷汎用のナレッジベース1個に全部入れるより、専門化したナレッジベースで検索した方が精度が出るんですよね・・・RAGの検索ノイズが減る、というか。
テキトー教師そうなんですよ。「1万件の全社FAQから検索」よりも「200件の営業専用FAQから検索」の方が関連度の高い回答が返ってくる。
質問分類器による前段の振り分けが、RAGの精度を上げる構造ですね。
質問分類器による前段の振り分けが、RAGの精度を上げる構造ですね。
チャットフローでの質問分類器の使い方：会話型AIを作る
室谷Difyには大きく「ワークフロー」と「チャットフロー」があって、質問分類器の使われ方が少し違います。チャットフローでの活用について整理しましょう。
テキトー教師チャットフローは会話のやり取りが連続するので、メモリを有効にした方が精度が出やすいです。この違いは最初に押さえておきたいですね。
チャットフローにおける質問分類器の位置
室谷チャットフローの場合、質問分類器は会話の入り口（スタートノードの直後）に置くのが基本です。ユーザーの発言をまず意図で分類して、それぞれの処理フローに流す。
テキトー教師「いらっしゃいませ、何かご用でしょうか」に対して「価格を聞きたい」「操作方法がわからない」「クレームがある」と来たら、それぞれ別の専門AIに引き渡す、というイメージですね。
室谷そこにメモリを組み合わせると、「さっきの件でもう一つ聞きたいんですが」という続きの会話でも、前のコンテキストを踏まえた分類ができる。
テキトー教師実際の業務チャットボットでは、会話の途中でユーザーの意図が変わることもよくあるんですよね。「価格の話をしていたけど、急にクレームに切り替わる」みたいな。
メモリ統合がないと、それを拾いきれない。
メモリ統合がないと、それを拾いきれない。
室谷チャットフローで質問分類器を使うときのもう一つのポイントが、「どのカテゴリにも当てはまらなかった場合の処理」をきちんと設計することですね。
テキトー教師ここをサボると、ユーザーが変な質問をしたときに何も返ってこない、または変なレスポンスが返る、という問題が起きます。「その他」「不明」カテゴリを必ず用意して、「申し訳ありませんが、その件については専門外です」という案内を返す設計にしておくのが基本です。
ワークフローでの質問分類器の使い方：自動化パイプラインに組み込む
室谷ワークフローでの使い方も話しましょう。チャットフローとは少し文脈が違って、バッチ処理やパイプライン自動化での使い方が中心になります。
テキトー教師ワークフローでの活用例として多いのは、大量のテキストデータを自動分類してルーティングするケースですね。メール、問い合わせ、レビューなどを自動で振り分けて処理する。
入力データの自動分類
室谷MYUUUで実際にやったのは、毎日大量に届く問い合わせメールをDifyのワークフローで自動分類する仕組みです。質問分類器で「緊急対応が必要なクレーム」「一般的な問い合わせ」「機能要望」の3つに振り分けて、それぞれSlack通知の宛先を変える、というシンプルな設計。
テキトー教師それは実用的ですね。人間が分類する手間がなくなるのと、分類漏れがなくなる。
コミュニティのメンバーさんでも、カスタマーサポートの工数削減にDifyを使っている人が増えています。
コミュニティのメンバーさんでも、カスタマーサポートの工数削減にDifyを使っている人が増えています。
室谷ポイントはワークフローの入力として「文書テキスト」を受け取って、それを質問分類器の入力変数に設定すること。チャットフローの
sys.queryではなく、ワークフローの入力変数（例: input_text）を使います。テキトー教師変数の設定をミスすると「分類してるのに結果が変」という事態になるので、デバッグモードで入力変数が正しく渡されているか確認するのが大事ですね。
ワークフロー内での多段分類
室谷ワークフローでは「質問分類器を2回使う」設計も有効です。第1段階で大まかに5カテゴリに振り分けて、各カテゴリのパスに入ったら第2段階でさらに細かく分類する。
テキトー教師階層的な分類ですね。ECサイトの問い合わせ対応だと、第1段階：「商品」「配送」「支払い」「アカウント」「その他」、第2段階：「商品」内をさらに「品質クレーム」「サイズ相談」「在庫確認」に分ける、みたいな設計です。
室谷一気に10個のカテゴリを作るより、2段階で5×5の25カテゴリをカバーする方が精度が安定するんですよね。LLMの1回の分類で扱うカテゴリ数を絞った方が、迷いが減る。
質問分類器のエラーと対処法：よくある問題を解決する
テキトー教師「dify 質問分類器 エラー」で調べている人が多いのをコミュニティで見かけるので、ここはしっかり扱いましょう。よくある問題を一通り整理します。
室谷確かに、最初うまく動かなくて詰まる人は多いですね。ほとんどのケースは設定の問題で解決できるので、順番に確認していきましょう。
よくある問題と解決策
テキトー教師まず一番多いのが「カテゴリに正しく振り分けられない」問題です。分類がでたらめになる、または全部同じカテゴリに入ってしまう。
室谷これはカテゴリの説明文が不十分なことがほとんどです。「その他」に何でも入ってしまう場合は、他のカテゴリの説明が曖昧で、LLMが判断できていない可能性が高い。
テキトー教師解決策は説明文を具体的に書き直すことですね。「製品に関する質問」ではなく「製品の価格、仕様、在庫状況、品質、比較に関する問い合わせ」のように、具体的なキーワードや事例を含める。
| よくあるエラー | 原因 | 解決策 |
|---|---|---|
| 全部「その他」に入る | カテゴリ説明が曖昧 | 各カテゴリの説明を具体的に書く |
| 分類結果がランダムになる | カテゴリ間の境界が重複している | カテゴリを統合または境界を明確化 |
| 「接続エラー」が出る | LLMプロバイダーのAPIキー問題 | APIキーと利用制限を確認 |
| タイムアウトが多発する | モデルの応答が遅い | より軽量なモデルに変更 |
| 出力パスに何も繋がっていない | カテゴリが増えたが接続し忘れ | 全カテゴリの出力パスを確認 |
室谷「接続エラー」の系統は、Difyの設定>モデルプロバイダーでAPIキーが正しく設定されているか確認するのが先です。質問分類器はLLMを使うので、LLMプロバイダーが設定されていないと動かない。
デバッグモードを活用する
テキトー教師エラー調査には、Difyのプレビュー（デバッグモード）が非常に役立ちます。各ノードの入出力をリアルタイムで確認できるので、どこで問題が起きているかが一目でわかります。
室谷質問分類器の場合、デバッグモードで確認すべきポイントは「入力変数に値が入っているか」「質問分類器の出力のclass_nameに想定のカテゴリが入っているか」の2点です。
テキトー教師入力変数が空になっていると分類できないのは当然なので、まずそこから確認します。
sys.queryを設定したつもりが別の変数を参照していた、というミスはよくあります。室谷あとは「指示フィールドのプロンプトが長すぎて処理が遅くなる」というケースも。指示フィールドはコンパクトにまとめた方がいい。
長くすれば精度が上がるわけじゃないので。
長くすれば精度が上がるわけじゃないので。
精度チェックの実践方法
テキトー教師本番リリース前に精度を確認する方法として、テストケースを用意して一気に流すやり方が有効です。各カテゴリに対して10〜20件の代表的な質問パターンを用意して、正しく分類されるか検証する。
室谷旧サイトの記事でも紹介されていましたが、実際に精度を測ってみると68%くらいから始まることが多くて・・・それをカテゴリ定義の改善と指示フィールドの調整で80〜90%に持っていく、という反復作業がリアルな開発フローですね。
テキトー教師100%は難しいし、目指さなくていいんですよ。95%以上の精度で正しく動いて、残り5%は「その他」として丁寧に案内する、という設計の方がユーザー体験は良かったりします。
実践事例：カスタマーサービスBotを質問分類器で作る
室谷ここからは具体的な実装例を見ていきましょう。前回はDifyのチャットフローの基本を扱いましたが、今回はその応用として質問分類器を使ったカスタマーサービスBotの設計を解説します。
テキトー教師これが一番わかりやすい事例なので、講座でもまずこれを作ります。実際に手を動かして作れるので、ぜひ試してみてください。
設計の全体像
室谷まずワークフロー（またはチャットフロー）の全体設計から。シンプルに3カテゴリで設計します。
テキトー教師3カテゴリの構成をまとめると、こうなります。
- アフターサービス: 返品、修理、保証、購入後トラブルに関する問い合わせ
- 製品使用方法: セットアップ、操作方法、機能説明、トラブルシューティング
- その他: 上記に当てはまらない一般的な問い合わせ
室谷それぞれのカテゴリに対して、専用のナレッジベースをDifyのナレッジ機能で作っておきます。アフターサービスには保証規定や返品ポリシーのドキュメント、製品使用方法にはマニュアルやFAQを登録する。
テキトー教師ナレッジベースを用意したら、ワークフローの設計は以下の流れになります。
開始ノード（sys.query）
↓
質問分類器ノード
（モデル: 任意のLLM、カテゴリ: 上記3つ）
↓
アフターサービス → 知識検索（アフターサービスナレッジ）→ LLM → 回答
製品使用方法 → 知識検索（製品マニュアルナレッジ）→ LLM → 回答
その他 → LLM（汎用対応）→ 回答
このシンプルな設計だけで、「何でも答えようとして的外れな回答をする汎用Bot」から「カテゴリごとに専門回答をする高品質Bot」に変わります。
テキトー教師実際に受講生さんがこれを作ったとき、「前より明らかに回答が正確になった」という反応が多いんですよね。カテゴリの設計に時間がかかっても、それに見合う効果があります。
Difyのサンプルアプリを参考にする
室谷Difyには「探索」メニューにサンプルアプリが用意されていて、カスタマーサービス系のものには質問分類器が使われているものがあります。
テキトー教師サンプルアプリのDSLをダウンロードして中身を確認するのも、学習になりますよね。自分で組み立てる前に、先人の設計を参考にする。
室谷Difyのエクスプロア（Explore）で「customer service」などで検索すると見つかります。英語のアプリが多いですが、ノードの設計は参考になります。
質問分類器のベストプラクティス：精度を上げる実践的ヒント
テキトー教師ここまで設定方法と事例を解説してきました。最後にベストプラクティスをまとめます。
これを押さえておくと、初期設計の段階で多くの問題を回避できます。
これを押さえておくと、初期設計の段階で多くの問題を回避できます。
室谷公式ドキュメントのベストプラクティスも参考にしつつ、MYUUUでの実践を交えてお伝えします。
カテゴリ設計の原則
テキトー教師最初の原則は「カテゴリの境界を明確にする」です。2つのカテゴリが重複する領域があると、そこに入る質問の分類が不安定になります。
室谷実際の設計で役立つのは「この質問はどのカテゴリに入れるか」を自分で答えられるかテストすることです。答えに迷ったら、カテゴリの説明文が不十分です。
テキトー教師2つ目の原則は「まず動かして、観察して、改善する」です。完璧なカテゴリ設計を机上で作ろうとするより、シンプルな設計で動かして実際の誤分類パターンを見た方が、改善点が具体的にわかります。
室谷3つ目として、「『その他』カテゴリを恐れない」というのを加えたいですね。「全部の質問を専門カテゴリに振り分けようとする」のは過設計になりがちです。
どうしても分類できない質問は「その他」で受け取って、丁寧に案内する設計が現実的です。
どうしても分類できない質問は「その他」で受け取って、丁寧に案内する設計が現実的です。
| ベストプラクティス | 具体的な方法 |
|---|---|
| カテゴリ境界を明確化 | 各カテゴリにOK/NG例を説明文に含める |
| まず動かして観察 | 最初は3〜5カテゴリのシンプル設計でテスト |
| エッジケースは指示フィールドで | 誤分類パターンを発見したら指示に追加 |
| モデルは目的に合わせて | シンプルな分類は軽量モデル、複雑は高性能モデル |
| メモリは会話型のみ | ワークフローではメモリ不要、チャットフローで有効化 |
| 監視と反復 | 本番後も分類結果をモニタリングして改善を続ける |
テキトー教師監視と反復の点は、特に強調したいですね。最初に設計して終わりじゃなくて、実際にユーザーが使い始めると想定外の質問パターンが出てくる。
それを観察して改善し続けるのが、精度の高いBotに育てる道です。
それを観察して改善し続けるのが、精度の高いBotに育てる道です。
室谷Difyのモニタリング機能を使うと、どのカテゴリにどれくらい振り分けられたか、履歴が確認できます。特定のカテゴリへの集中や、「その他」が多すぎる場合は設計の見直しサインですね。
質問分類器を使った社内FAQ Botの構築：RAGとの連携実践
室谷質問分類器×RAGの組み合わせで作る社内FAQ Botは、実用度が高いのでもう少し詳しく解説します。これは.AI（ドットエーアイ）コミュニティのメンバーからも「これ使えます」と反響が多い構成です。
テキトー教師社内FAQはドキュメントが複数部門にまたがることが多くて、全部一つのナレッジベースに突っ込むと検索精度が落ちるんですよ。質問分類器で前段に振り分けることで、それを解決できます。
構築の流れ
室谷実際の構築手順を整理すると、こうなります。
- 各部門のFAQドキュメントをDifyのナレッジ機能に登録（部門ごとに別々のナレッジベース）
- チャットフロー（またはワークフロー）を作成
- スタートノードの直後に質問分類器を配置
- 各カテゴリのパスに部門別のナレッジ検索ノードを接続
- ナレッジ検索の後にLLMノードを接続して回答を生成
- 各LLMノードの出力を「回答」ノードに繋ぐ
テキトー教師このとき、各LLMノードのシステムプロンプトを部門に合わせてカスタマイズするとさらに精度が上がります。営業部門向けなら「あなたはXX株式会社の営業担当の専門家です」、技術部門向けなら「あなたはXX株式会社の技術サポート担当です」と設定する。
室谷部門ごとにキャラクターを変えるのは効果があります。同じ基盤モデルでも、プロンプトで役割を与えるだけで回答のトーンや専門性が変わりますからね。
ナレッジベースの設計ポイント
テキトー教師ナレッジベースの中身の設計も重要です。ドキュメントをそのままアップロードするだけでなく、FAQ形式に整理した方が検索精度が上がります。
室谷「Q: ○○はどうすればいいですか？ A: ○○の手順は以下の通りです」という形式で書かれたドキュメントは、RAGとの相性がいいんですよね。曖昧な文章より、明確な質問と回答のペアの方が検索しやすい。
テキトー教師Difyのナレッジ機能についてより詳しく知りたい方は、別記事「」も参考にしてください。
質問分類器の仕組みを深掘り：LLMがどう分類するか
テキトー教師ここで少し立ち止まって、質問分類器がどのような仕組みで動いているか解説します。仕組みを理解すると、カテゴリ設計や精度改善の判断が格段にしやすくなります。
室谷これ、意外と知らないまま使っている人が多いんですよね。「なんとなく動いている」から「なぜ動くのか」に理解が深まると、設計力が上がります。
内部的な動作
テキトー教師質問分類器は、内部でLLMにプロンプトを送って分類させています。大まかには「以下のカテゴリ定義を読んで、ユーザーの質問がどのカテゴリに最も近いか答えてください」というプロンプトが自動生成されてLLMに渡ります。
室谷つまり、カテゴリ定義がそのままLLMへの指示になっているわけですね。だから「説明文が曖昧だと精度が落ちる」という話が本質的に正しいんですよ。
LLMが判断できない情報しか渡していないから。
LLMが判断できない情報しか渡していないから。
テキトー教師そう考えると、カテゴリ説明を書くのは「LLMへの指示書を書く」作業と同じです。プロンプトエンジニアリングの観点が使えます。
具体的な例、除外条件、境界ケースの記述——これらはプロンプトに書くのと同じ要領です。
具体的な例、除外条件、境界ケースの記述——これらはプロンプトに書くのと同じ要領です。
室谷その視点は面白いですね。「このカテゴリには〇〇が含まれる」だけでなく「このカテゴリには〇〇は含まれない」という否定形の記述も有効なんです。
テキトー教師出力のclass_nameに入るのは、定義したカテゴリラベルそのものです。LLMが分類結果をそのラベルの文字列で返す。
だからカテゴリ名は日本語でも英語でも自由に設定できますし、コードに依存しません。
だからカテゴリ名は日本語でも英語でも自由に設定できますし、コードに依存しません。
Few-shot的なアプローチ
室谷精度を高めるテクニックとして、カテゴリ説明に「例：」として実際の質問例を書く方法があります。機械学習のFew-shotに近い考え方です。
テキトー教師例えば、「アフターサービス」カテゴリの説明に「例：返品したい、保証期間は？、商品が壊れていた、修理を依頼したい」のように代表的な質問を書くと、LLMの判断基準が具体的になります。
室谷これ、やるとやらないとで精度がかなり変わります。MYUUUでもこのアプローチを取り入れてから誤分類が明らかに減りました。
特に曖昧な境界線の質問で。
特に曖昧な境界線の質問で。
テキトー教師ただし書きすぎるのも逆効果なので、各カテゴリ3〜5件の代表例があれば十分です。多すぎるとコンテキストが長くなってコストが上がります。
質問分類器とパラメータ抽出器の使い分け
室谷質問分類器と似た役割のノードに「パラメータ抽出器」があります。ここの使い分けも、理解しておくと設計力が上がります。
テキトー教師混乱するポイントですよね。両方ともLLMを使って入力テキストを処理するノードなんですが、目的が違います。
室谷端的に言うと、「質問の種類を判定する」なら質問分類器、「質問から特定の情報を取り出す」ならパラメータ抽出器です。
テキトー教師具体例で言うと——「この問い合わせはクレームですか、問い合わせですか？」を判定するなら質問分類器。「この問い合わせから商品名と注文番号を取り出す」ならパラメータ抽出器。
室谷組み合わせて使うのも有効です。質問分類器でカテゴリを判定して、各パスでパラメータ抽出器を使って必要情報を取り出してから処理する、という設計です。
テキトー教師例えば「返品依頼のカテゴリに分類されたら、その質問から注文番号と理由をパラメータ抽出器で取り出す」という流れです。カテゴリが決まってからパラメータを抽出することで、より正確に必要情報が取れます。
| ノード | 何をするか | 出力 | 使うシーン |
|---|---|---|---|
| 質問分類器 | 入力をカテゴリに分類 | class_name（カテゴリ名） | 分岐・ルーティング |
| パラメータ抽出器 | 入力から情報を抜き出す | 指定した変数（注文番号等） | データ抽出・フォーム入力 |
室谷この2つを組み合わせると、「意図を理解して、必要情報を抽出して、専門処理に流す」という洗練されたフローが作れます。
複数の質問分類器を組み合わせる：高度なワークフロー設計
テキトー教師少し上級の話をすると、1つのワークフローの中に複数の質問分類器を配置する設計があります。これを使うと、より複雑な分岐ロジックを自然言語で実現できます。
室谷前に少し触れた「2段階分類」の詳細版ですね。これは大規模なBotを作るときに真価を発揮します。
2段階分類の実装例
テキトー教師ECサイトのカスタマーサービスBotを例にすると、こうなります。
1段階目（大カテゴリの質問分類器）：
- 「商品について」
- 「注文・配送について」
- 「アカウント・支払いについて」
- 「その他」
2段階目（各大カテゴリ内の小カテゴリの質問分類器）：
- 「商品について」 → 「品質」「仕様」「在庫」「おすすめ」
- 「注文・配送について」 → 「注文変更」「配送確認」「返品・交換」
室谷これで4×4=16カテゴリを精度高く分類できます。1段階で16カテゴリを分類するよりずっと安定します。
テキトー教師ただし、ノードが増えるのでワークフローが複雑になります。シンプルさとのバランスを取って、本当に必要なときだけ使うのがいいですね。
室谷判断基準としては「誤分類率が5%を超えていて、カテゴリ定義の改善でも解決しない」場合に2段階を検討する、くらいのイメージでいいと思います。
質問分類器とIf-Elseを組み合わせる実践設計
室谷質問分類器とIf-Elseは「どちらかを選ぶ」というより、「両方使う」設計が実は多いんですよね。
テキトー教師そうなんですよ。意図の分類はLLM（質問分類器）に任せて、機械的な条件判定はIf-Elseに任せる。
役割分担です。
役割分担です。
室谷実際の例を出すと、「ユーザーのプラン種別（BasicかPremiumか）によって処理を変える」という条件はIf-Elseで設定して、「質問の種類（サポート系かセールス系か）による振り分け」は質問分類器で処理する、という設計です。
テキトー教師If-Elseで「ログイン済みかどうか」を判定してから、質問分類器でユーザーの意図を分類する、という組み合わせも実用的です。ログイン済みユーザーとゲストで対応できる質問の種類が違う場合に有効ですね。
室谷こういう複合的な設計ができるようになると、Difyのワークフロー設計が本格的になってきます。.AI（ドットエーアイ）の講座でもこのあたりが「中級〜上級」の内容ですね。
テキトー教師実際に手を動かして設計してみると、「こっちの方が管理しやすい」「このパターンは再利用できる」という感覚が身についていきます。理論より実践が大事なジャンルです。
質問分類器でマルチ言語対応Botを作る
室谷少し応用的な話として、質問分類器を使った多言語対応の設計について触れておきます。グローバルな製品やサービスでDifyを使っている場合に関係してくる話です。
テキトー教師意外と見落とされがちなポイントですね。質問分類器のLLMはセマンティック理解をするので、日本語のカテゴリ定義でも英語の質問を正しく分類できることが多いんです。
室谷Claudeやgpt-4o系のモデルは多言語対応が優秀なので、カテゴリ定義が日本語でも「I want to return this product」という英語の質問を「アフターサービス」に正しく分類してくれます。
テキトー教師ただし、精度を最大化したいなら各言語でカテゴリ説明を書いた方が良い場合もあります。特に専門用語が多い分野では、言語ごとに違う表現を使うことがあるので。
室谷実用上は「まず日本語で設計して試してみる、英語の質問で精度が落ちるようなら対応する」という流れで問題ないと思います。過設計より、動かして改善する方が効率的です。
言語検出との組み合わせ
テキトー教師より高度な設計として、最初に「言語検出」を行って、日本語/英語/中国語などのパスに分岐してから各言語専用の質問分類器を使う、という設計もあります。
室谷ここまで来るとかなり本格的なシステムになりますが、国際向けのサポートシステムを作るなら検討する価値があります。言語ごとにLLMのプロンプトを最適化できますし。
テキトー教師ただ、これはDifyの質問分類器を2段階使う設計と組み合わせると複雑になりすぎる場合もあるので、本当に多言語が必要かどうかを最初に確認してから設計するのが大事ですね。
質問分類器のモニタリングと改善サイクル
室谷本番運用に入ってからの話として、モニタリングと改善サイクルを押さえておきましょう。「作って終わり」ではなく、「作ってからが本番」という意識が大切です。
テキトー教師講座でも「作ることが目的じゃなくて、使われるものを作ることが目的」と伝えています。使い始めてから出てくる問題の方が、設計段階では想定できないことが多い。
分類ログの確認
室谷Difyには「ログ」機能があって、過去の入力と分類結果を振り返ることができます。ここを定期的に確認することが、精度改善の一番の近道です。
テキトー教師確認すべきポイントは2つ。「その他」に分類された質問が多すぎないか（多い場合はカテゴリ追加や定義改善が必要）と、「特定のカテゴリに偏りすぎていないか」（偏りがある場合はカテゴリの粒度を見直す）。
室谷MYUUUのケースでは、月1回くらいのペースでログを確認して、誤分類パターンを指示フィールドに追加する作業をしています。これだけで精度が継続的に改善されていく。
テキトー教師小さな改善を積み重ねる地道な作業ですが、これをやっている事業者とやっていない事業者では半年後に大きな差がつきます。AIシステムのメンテナンスは筋トレみたいなもので、続けることが大事です。
A/Bテストの考え方
室谷少し高度な話ですが、カテゴリ定義のA/Bテストをやると、どの表現が精度が高いか客観的に比較できます。
テキトー教師実際には、同じワークフローを「定義パターンA版」と「定義パターンB版」で2つ作って、一定期間それぞれに流してみて、誤分類率や「その他」率を比較する。手間はかかりますが、大きなシステムでは効果があります。
室谷ここまでやるのはヘビーユーザー向けですが、考え方として「カテゴリ定義はいつでも改善できる」という意識を持っておくことが大切ですね。固定されたものじゃなくて、育てていくものです。
無料でDifyを試す：質問分類器の動作確認方法
テキトー教師Difyは無料プランでも質問分類器を使えます。まだ試したことがない方向けに、始め方を整理しておきます。
室谷Difyは からアカウントを作成するだけで始められます。クラウド版なら環境構築が不要なので、すぐに試せます。
テキトー教師無料プランの制限としては、LLMの使用量に上限があります。実験用途なら十分ですが、本番環境には有料プランが必要になります。
Difyのプラン詳細は別記事「」を参考にしてください。
Difyのプラン詳細は別記事「」を参考にしてください。
室谷質問分類器の動作確認だけなら、無料の範囲で十分できます。まず試してみることが大事で、試してみないと「自分のユースケースに合うかどうか」の判断ができないですから。
テキトー教師始め方のステップとしては：
- dify.ai でアカウント作成
- ダッシュボードから「スタジオ」→「チャットフロー」を選択
- スタートノードの後に「質問分類器」ノードを追加
- カテゴリを2〜3個設定して「デバッグとプレビュー」で動作確認
室谷この4ステップで、15〜30分もあれば最初の質問分類器が動きます。まず動かしてみることが大事です。
室谷最初から完璧を目指さず、まず動かして体感することがDifyを覚える一番の近道です。ここが本質なんですよね・・・何でもそうですが、手を動かして作ったものの経験は、読んだだけとは全然違います。
質問分類器を使った業種別活用事例
室谷ここからは業種別の具体的な活用事例を見ていきます。「自分の業種でどう使えるか」のイメージを持ってもらいたいので。
テキトー教師実際に使われているケースを整理すると、業種ごとに「よくある質問の種類」が違うので、カテゴリ設計のパターンも変わってきます。
EC・小売業
室谷EC系で一番多い使われ方は、カスタマーサポートBotへの応用です。Difyの著書でも紹介しましたが、質問分類器×RAGの組み合わせでカスタマーサポートが自動化できます。
テキトー教師EC向けのカテゴリ設計の典型例を挙げると：
- 注文状況・追跡：注文番号、発送状況、到着予定日
- 返品・交換：返品手続き、交換申請、返金期間
- 商品情報：仕様、サイズ、在庫、おすすめ
- 支払い：支払い方法、領収書、請求エラー
- その他：上記に当てはまらない問い合わせ
室谷このカテゴリで質問分類器を組んで、各カテゴリに対応するナレッジベース（注文FAQ、返品規定、商品データ、支払い規約）を接続するだけで、かなり実用的なBotができます。
テキトー教師受講生さんの実装例で印象的だったのが、「返品・交換」カテゴリに入ったときだけパラメータ抽出器で「注文番号」と「返品理由」を取り出して、自動でCRMに記録するワークフローです。人間の手入力を完全に省いていました。
医療・ヘルスケア
室谷医療系のBotは慎重な設計が必要ですが、「一般的な情報提供」と「医師への相談が必要な内容」の分類に質問分類器が使われています。
テキトー教師特に重要なのが「緊急性の高い症状」カテゴリを最初に設けることです。「胸が痛い」「呼吸が苦しい」などの緊急性を示すキーワードを含む質問を、優先度高で医療機関への案内をするパスに流す設計です。
室谷このカテゴリ設計では「その他の症状相談」「薬の副作用確認」「予防・生活習慣」「緊急性の高い症状」という4分類が基本になりますね。
テキトー教師医療系の情報は精度と安全性が特に重要なので、質問分類器だけでなく「医療情報の提供であることの免責事項」を全パスに入れるのも重要です。設計上の倫理的な配慮が必要な分野です。
SaaS・テクニカルサポート
室谷テック企業のサポートBotで質問分類器を使う場合、技術的な専門性の高い内容が多いので、モデル選択が重要になります。
テキトー教師SaaS向けのカテゴリとしては：
- セットアップ・初期設定：インストール、アカウント設定、初回設定
- バグ・エラー：エラーメッセージ、動作不具合、クラッシュ
- 機能の使い方：操作方法、応用的な使い方、ショートカット
- プラン・課金：アップグレード、ダウングレード、請求確認
- API・連携：API仕様、Webhook、外部ツール連携
室谷SaaSサポートの場合、「バグ・エラー」カテゴリに入ったら、エラーメッセージをパラメータ抽出器で取り出して既知のエラーデータベースを参照する、という設計が実用的です。
テキトー教師それに加えて「解決できなかった場合は人間のサポートにエスカレーション」という出口を設計しておくことも重要ですね。Botで全部解決しようとするより、Botで解決できるものを処理して、難しいものを人間に渡す設計の方が現実的です。
教育・学習サービス
室谷.AI（ドットエーアイ）でも、コミュニティ内の学習支援にDifyを活用しています。質問分類器を使って「学習上の疑問」「課題の相談」「キャリアについて」「技術的な質問」に振り分ける設計です。
テキトー教師教育系のBotは「正確な情報を返すこと」と「モチベーションを維持すること」のバランスが難しいんですよね。回答の正確性だけでなく、声がけや励ましのトーンも大事です。
室谷そのあたりは質問分類器でカテゴリを判定してから、各カテゴリのLLMノードでシステムプロンプトを変える、という設計で対応できます。「学習上の疑問」には詳細な説明プロンプト、「キャリアについて」には共感と背中押しのプロンプト、という具合に。
「dify チャットフロー 質問分類器」の組み合わせ：設計パターン集
テキトー教師チャットフローで質問分類器を使う設計パターンを整理しておきます。これは「パターン集」として手元に置いておくと設計時に役立ちます。
室谷Difyの公式にも類似の内容がありますが、実際の現場で使われているパターンを中心に整理します。
パターン1：シンプルな分類×ナレッジ検索
テキトー教師最も基本的なパターンです。入り口で質問を分類して、専門ナレッジに直結する。
まずここから始めましょう。
まずここから始めましょう。
[開始] → [質問分類器]
├── カテゴリA → [知識検索A] → [LLM] → [回答]
├── カテゴリB → [知識検索B] → [LLM] → [回答]
└── その他 → [LLM（汎用）] → [回答]
このパターンは「ナレッジベースが2〜3個あって、質問の種類によって参照先を変えたい」という場合に使います。最初に覚えるべき基本形です。
パターン2：分類→情報抽出→処理
テキトー教師質問を分類した後に、必要な情報を抽出してから処理する設計です。
[開始] → [質問分類器]
├── 注文照会 → [パラメータ抽出] → [注文DB照会] → [LLM] → [回答]
├── 返品申請 → [パラメータ抽出] → [フォーム処理] → [回答]
└── その他 → [LLM] → [回答]
このパターンは業務システムとの連携が必要な場合に使います。「何の処理をするか（質問分類器）」と「何のデータが必要か（パラメータ抽出器）」を分けて設計するのがポイントです。
パターン3：条件判定→質問分類器の組み合わせ
テキトー教師ユーザー属性などで先に条件分岐してから、質問分類器を使う設計です。
[開始] → [If-Else（会員種別）]
├── プレミアム会員 → [質問分類器（拡張版）] → ...
└── 一般会員 → [質問分類器（基本版）] → ...
このパターンは「プレミアム会員には追加のカテゴリや専用ナレッジを使いたい」という場合に有効です。同じ質問でも、ユーザー属性によって提供できる情報が変わる場合に使います。
室谷これらのパターンを組み合わせると、かなり複雑なBotも設計できます。大事なのは、まず一番シンプルなパターン1から始めて、必要に応じてパターン2、3を追加していく段階的な設計アプローチです。
テキトー教師複雑なシステムも、シンプルなパターンの積み重ねです。一度に全部作ろうとするより、動くものを段階的に育てていく方が、最終的に良いものができます。
質問分類器の精度向上：プロンプトエンジニアリングの視点から
室谷ここで少し踏み込んで、質問分類器の精度向上をプロンプトエンジニアリングの観点から整理します。カテゴリ定義と指示フィールドの書き方を体系的に理解することで、精度が安定しやすくなります。
テキトー教師「プロンプトエンジニアリング」と聞くと難しそうに聞こえますが、本質は「LLMに正確に伝わる言葉を書く」ということです。
カテゴリ定義の書き方の型
室谷精度の高いカテゴリ定義には、書き方の「型」があります。以下の要素を含めると、LLMの判断が安定します。
テキトー教師効果的なカテゴリ定義の型をまとめると、こうなります。
- 対象の範囲：このカテゴリに「含まれるもの」を具体的に列挙
- 除外の明示：紛らわしいものの「含まれないもの」を明示
- 具体例：実際の質問例を2〜3件含める
- 境界ケース：他のカテゴリとの境界が曖昧な場合の判断基準
室谷実際のカテゴリ定義例を書いてみると：
NG（曖昧）:
製品の使い方に関する質問
OK（具体的）:
製品の操作方法・セットアップ・機能説明・トラブルシューティングに関する質問。
例：「この機能の使い方は？」「初期設定の手順を教えて」「〇〇エラーの対処法は？」
※価格や在庫に関する質問は「製品情報」カテゴリへ。
※購入後の不良品は「アフターサービス」カテゴリへ。
「含まれないもの」と「具体例」を追加するだけで、同じカテゴリでも精度が明らかに変わります。これはLLMがプロンプトを読んで判断するときと同じ原理です。
プロンプトが詳細であるほど、判断がブレない。
プロンプトが詳細であるほど、判断がブレない。
指示フィールドの活用テクニック
室谷指示フィールドに書くべき内容は、主に「エッジケース」と「優先順位」の2種類です。
テキトー教師エッジケースの例としては：
- 「返品したいが、まだ商品が届いていない」→「配送追跡」と「返品」の2つのカテゴリに跨ぐ場合の判断基準
- 「急いで教えてください」→「緊急」という言葉があっても緊急カテゴリに分類しない（内容で判断する）
- 感情的な言葉を含む文（「最悪だ」「最高に使いやすい」）→感情ではなく内容で分類する
室谷優先順位の例としては「複数のカテゴリに当てはまる場合は〇〇を優先する」という記述です。例えば「セキュリティ関連の問い合わせは、他のカテゴリとの境界が曖昧な場合でもセキュリティカテゴリを優先する」みたいな指示。
テキトー教師指示フィールドは「問題が起きたら足す」のが基本ですが、最初から入れておくと良い汎用指示もあります。「日本語以外で書かれた質問も同じカテゴリ基準で判断すること」「質問者の感情的なトーンは分類に影響させないこと」あたりは汎用性が高いです。
モデルごとの特性を把握する
室谷同じカテゴリ定義でも、モデルによって分類の傾向が変わります。
テキトー教師経験則として、GPT-4o系は指示に従いやすく、Claude系はセマンティックな理解が得意、Gemini系は多言語での性能が安定している、という印象があります。
室谷ただしこれはあくまで傾向で、バージョンアップによって変わることもあります。実際には候補のモデルでテストケースを流して、自分のユースケースに合ったモデルを選ぶのが確実ですね。
テキトー教師コストも考慮すると、「まずgemini-flash-2.0系でテストして、精度が不満なら上位モデルに切り替える」という段階的なアプローチが費用対効果が高いです。
質問分類器の実装でよく聞かれること
室谷実装を進めていると「これってどうすればいいの？」という細かい疑問が出てきます。よく聞かれる技術的な質問に答えておきます。
テキトー教師これはコミュニティのメンバーさんの質問をベースにまとめました。
出力パスに後続ノードを繋がないとエラーになりますか？
テキトー教師なりません。質問分類器の出力パスは、接続されていないものは単純にそこで終了します。
ただし、接続されていないパスに分類された場合、ユーザーに何も返らないので実用上は全パスを接続するべきです。
ただし、接続されていないパスに分類された場合、ユーザーに何も返らないので実用上は全パスを接続するべきです。
室谷「その他」カテゴリを設けても後続ノードを繋がないままリリースする、という実装ミスがたまにあります。ワークフローを本番リリースする前に「全カテゴリのパスに後続ノードが繋がっているか」のチェックを習慣にしておくといいです。
質問分類器ノードを削除せずに一時的に無効化できますか？
室谷Difyのノードには「無効化」機能があります。ノードを右クリック（またはノードの設定メニュー）から無効化できます。
無効化したノードはフロー上に残りますが、実行時にスキップされます。
無効化したノードはフロー上に残りますが、実行時にスキップされます。
テキトー教師テスト中に一時的に質問分類器をバイパスして後続ノードだけテストしたい場合に使えます。ノードを丸ごと削除して後で再設定するより効率的です。
質問分類器の結果をログDBに記録するにはどうすればいいですか？
テキトー教師各カテゴリのパスから分岐して、HTTPリクエストノードでAPIを呼んでDBに書き込む、という設計が一般的です。
室谷または、DifyのLoggingやMonitoring機能を使えば、ある程度のログは自動で記録されます。詳細なカスタムログが必要な場合はHTTPリクエストノード経由でのDB記録が確実です。
HTTPリクエストノードの使い方は「」を参照してください。
HTTPリクエストノードの使い方は「」を参照してください。
質問分類器は英語の公式ドキュメントで「Question Classifier」と表記されていますが、機能は同じですか？
室谷完全に同じノードです。日本語UIでは「質問分類器」、英語UIでは「Question Classifier」と表記されています。
設定項目、動作、出力変数（class_name）も同一です。
設定項目、動作、出力変数（class_name）も同一です。
テキトー教師DifyのUIを英語設定にしていて「質問分類器がどこにあるか」で迷った場合は、「Question Classifier」を探せば見つかります。
質問分類器とDifyの他ノードとの連携チートシート
室谷質問分類器がどのノードと連携しやすいか、チートシートとしてまとめておきます。Difyのワークフロー設計の全体像を把握する意味でも有用です。
テキトー教師「どのノードを質問分類器の後に置くか」は設計のキモなので、よく使う組み合わせを整理しておくと判断が速くなります。
| 後続ノード | 用途 | 組み合わせが有効なシーン |
|---|---|---|
| 知識検索（RAG） | カテゴリ専用ナレッジの検索 | FAQ Bot、社内ナレッジ検索 |
| LLM | 分類結果に基づいた回答生成 | ペルソナ変更、専門対応 |
| パラメータ抽出器 | 質問から特定情報を取り出す | 注文番号抽出、フォーム入力 |
| HTTPリクエスト | 外部API・DBへのアクセス | CRM連携、在庫照会 |
| If-Else | 機械的な条件でさらに分岐 | 会員種別、プランによる分岐 |
| コードノード | カスタム処理ロジック | 複雑なビジネスルール |
| 変数アサイナー | 変数に値を設定 | フラグ管理、ステータス記録 |
室谷この表を見ると、質問分類器が「ハブ」として機能していることがわかりますね。分類して、それぞれのパスで適切な処理をする。
これがDifyのワークフロー設計の基本思想です。
これがDifyのワークフロー設計の基本思想です。
テキトー教師「知識検索 → LLM」の組み合わせが最も多いパターンで、RAGベースのBotの基本構成です。この後にHTTPリクエストを加えると、外部システムとの連携が加わり、より実用的なシステムに発展します。
さらに学ぶためのリソース
室谷質問分類器についてさらに深く学びたい方向けに、参考になるリソースを紹介します。
テキトー教師公式リソースからコミュニティまで、幅広く活用できます。
公式ドキュメント
室谷最も信頼できる情報源は です。設定項目の最新情報や仕様変更は必ずここを確認してください。
.AI（ドットエーアイ）コミュニティ
テキトー教師日本最大級のAIコミュニティ「.AI（ドットエーアイ）」では、Difyの実践的な活用事例やワークショップが定期的に開催されています。コミュニティメンバーの実装事例を参考にできる環境は、学習速度を格段に上げてくれます。
室谷.AIでは質問分類器を使った実際のワークフローのレビューや、設計相談もできます。書籍「お金を使わず、AIを働かせる『Dify』活用」（ぱる出版）も合わせて読むと、全体像がよりクリアになります。
関連記事
テキトー教師このシリーズの関連記事として、以下も合わせてお読みください。
- Difyのチャットフロー完全ガイド：質問分類器の土台となるチャットフローの設計を詳しく解説
- Difyのナレッジベース完全攻略：質問分類器と連携するRAGの設定方法
- DifyのHTTPリクエストノードの使い方：質問分類器の後に外部APIを呼ぶ実装方法
- Difyのワークフロー作り方完全ガイド：ワークフロー全体の設計指針
よくある質問（FAQ）
室谷ここまでで質問分類器の設定方法から実践事例まで一通り解説しました。最後にコミュニティで多く寄せられる質問に答えておきます。
テキトー教師講座でもよく聞かれる質問を集めました。
質問分類器はチャットフローとワークフロー、どちらで使うべきですか？
室谷どちらでも使えますが、目的で使い分けます。会話型のBotを作りたい場合はチャットフロー、バッチ処理や自動化パイプラインを作りたい場合はワークフローです。
メモリ統合が使えるのはチャットフローのみなので、会話の文脈を踏まえた分類が必要な場合はチャットフロー一択です。
メモリ統合が使えるのはチャットフローのみなので、会話の文脈を踏まえた分類が必要な場合はチャットフロー一択です。
カテゴリは最大いくつまで設定できますか？
テキトー教師公式ドキュメントには上限の明記はありませんが、実用上は5〜10カテゴリが精度・管理のバランスが良い範囲です。それ以上必要な場合は2段階の階層分類（大カテゴリ→小カテゴリ）を検討するのがおすすめです。
質問分類器と知識検索ノードを直接繋ぐべきですか？LLMを挟むべきですか？
室谷基本的には「質問分類器 → 知識検索 → LLM → 回答」の順が推奨です。知識検索の結果をそのままユーザーに返すのではなく、LLMで整形・補足してから返す方が品質が高くなります。
分類精度が低い場合、まず何を確認すればいいですか？
テキトー教師チェックすべき順番はこうです。
- カテゴリの説明文が具体的かどうか（最初に確認）
- カテゴリ間の境界が重複していないか
- 指示フィールドで誤分類のエッジケースを補足できているか
- モデルがタスクの複雑さに対して十分なグレードか（最後に確認）
室谷モデルのグレードアップは最後の手段です。まずカテゴリ定義と指示フィールドの改善を優先しましょう。
まとめ：Dify質問分類器で「賢いBot」を作る
室谷今回は質問分類器について一通り解説しました。改めて要点を整理すると、質問分類器はLLMのセマンティック理解で自然言語の意図を分類する、ルールベースのIf-Elseでは限界があるシナリオで真価を発揮するノードです。
テキトー教師設定のポイントは3つ——入力変数（何を分類するか）、モデル選択（複雑さに合わせて）、カテゴリ定義（具体的な説明文で境界を明確に）。これだけ押さえれば基本は動きます。
室谷精度を上げたいなら指示フィールドとメモリ統合を活用して、実際に動かしながら反復改善していく。完璧な設計は机上では作れないので、まず動くものを作って観察するのが最速ルートです。
テキトー教師質問分類器の応用先は広くて、カスタマーサービスBot、社内FAQシステム、メール自動分類、バッチ処理のルーティングなど、「種類の異なる質問やデータを処理する」シナリオ全般に使えます。
室谷公式ドキュメントは にあります。今回の記事と合わせて読むと、理解が深まります。
テキトー教師次回はDifyの別のノードについて深掘りしていきます。このシリーズを通じて、Difyのワークフロー設計力が着実に上がっていくと思います。
出典
- Dify公式ドキュメント - 質問分類器ノード
- Dify公式サイト
- 旧サイト記事（myuuu.co.jp/media/600/）