Dify質問分類器の分岐がずれる｜class_nameとclass_labelを確認

質問分類器の分類がずれるときは、入力文、クラスの説明、接続先、後続で参照する出力を分けて確認します。 現行公式では、分類の説明がclass_name、キャンバス上の短い表示名がclass_labelです。表示名だけを変えたのに、分類基準まで変えたつもりになっていないかも調べてください。

対象は、Difyで質問分類器から複数の回答経路へつなげたものの、「その他」に入りすぎる、説明を直しても分岐が変わらない、後続の文字列比較が合わないといった問題がある人です。架空の業務ツールへの問い合わせ十二件を使い、期待する分類を先に定義する方法を説明します。

公式情報の確認日：2026年10月28日。Question Classifier、If-Else、Variable Aggregatorを参照しています。画面名と出力は利用中の版で確認してください。本稿の十二件は編集部が設計した期待結果の教材です。Dify Cloudや外部LLMを実行して精度を測定した結果ではありません。

質問分類器の入力・説明・出力を、別々に点検する

意図の分類と、決まった条件の判定を分ける

質問分類器では、文章の意味をもとに、設定したクラスのどれに当てはまるかをLLMが判断します。例えば「CSVを保存する場所を知りたい」は操作の案内、「請求が重複している」は請求窓口の案内というように、自然文から入口を選ぶ用途に向きます。

一方、金額が一万円以上か、承認済みというフラグがtrueか、配列が空かといった条件は、すでに定義した値を比較する処理です。文章分類の指示へ全部を詰め込むより、IF/ELSEなどで明示した条件を判定し、その結果で経路を選ぶ設計を検討します。

この二つを混ぜると、「解約の問い合わせだと分類されたから、解約してよい」といった飛躍が起こります。分類は担当窓口を選ぶ段階であり、本人確認、契約状況、手続の承認を代行するものではありません。問い合わせの意図と、実行できる操作の条件は別に扱いましょう。

条件の型や空欄で分岐がずれている場合は、IF/ELSEの境界と空欄の確認を先に点検してください。分類器のモデルを変えても、別ノードへ渡している変数が違う問題や、文字列と数値を取り違えた条件は解決しません。

class_nameは説明、class_labelは表示名として確認する

現行の公式ページでは、一つのクラスに二つの独立したテキストがあると説明されています。エディター本文の説明はLLMが分類を選ぶために読み、下流ではclass_nameとして公開されます。クラス上部の短い見出しはキャンバスに表示する名前で、class_labelとして公開されます。

例えば表示名を「操作案内」とし、説明へ「画面操作や設定手順の質問。契約変更や返金の依頼は含めない」と書く設計ができます。二つは独立して編集するため、見出しを分かりやすく変えただけでは、LLMに渡す説明文が同じまま残ることがあります。

反対に、後続ノードでclass_nameを短い表示名と文字列比較していると、説明文の変更で一致しなくなる可能性があります。変数名から値を推測せず、利用中の画面で出力を実際に開き、どの値が入っているかを確認してください。旧版や古い記事と表示が違う場合も、現環境の実出力を基準にします。

分岐は質問分類器の各クラスから目的のノードへ接続できるため、短い表示名を比較するIF/ELSEを追加しないと分岐できない、というわけではありません。後続で比較が必要な事情がある場合に、どの出力を何と比べるかを明記します。不要な比較を増やす前に接続線を確認しましょう。

運用上の集計用には、各経路の後ろで自分たちの固定コードを付ける方法も考えられます。例えばusage、billing、reviewを自分の記録用項目として使い、表示名や長い説明文と分離します。これらは本稿の教材用コードで、Difyが標準で自動出力する変数名ではありません。

三つの分類に、含む内容と除外する内容を書く

教材では、社内向け業務ツールの問い合わせを「操作案内」「契約・請求」「確認が必要」に分けます。「ツールに関する質問」のような広い説明だけでは、操作も契約も両方に当てはまります。何を含めるかに加えて、似たクラスから何を除外するかを書きます。

操作案内の説明例は、「画面の使い方、設定、保存方法、通知設定の手順を求める質問。契約変更、請求の異議、返金や解約の依頼を含む場合は契約・請求へ回す」です。この説明なら、同じ通知という語を含んでも、解約依頼まで含む場合は別の経路を優先すると示せます。

契約・請求の説明例は、「契約変更、解約、返金、請求内容や料金に関する確認を求める質問。操作の質問と混在してもこちらを優先する。ただし分類は手続の承認や本人確認の完了を意味しない」です。窓口へ回す基準と、後続が実行してよい範囲を分けておきます。

確認が必要の説明例は、「対象や目的が分からず追加確認が必要な質問、二分類の範囲外の話題、外部サービスの話題」です。「その他」と一語だけにするより、何を受け止める経路かを説明します。ここへ入った場合の返答も、無関係な知識ベースから推測せず、何を確認するかを決めます。

これは教材の分類方針です。部署の実際の窓口が違えば、その窓口へ合わせて変更してください。分類数を増やす前に、同じ問い合わせが複数の窓口へ当てはまらないか、どちらにも入らない問い合わせをどこで扱うかを確認すると設計しやすくなります。

入力文が合っているかを、前段の変数から確かめる

分類の説明が適切でも、入力へ前の質問や空欄を渡していれば、期待した経路になりません。Chatflowでは現在の質問としてsys.queryを選ぶ例がありますが、前段で取り出した文章を分類する設計もあります。自分のフローで何を分類したいかに合わせて、対象の変数を確認します。

実行履歴では、ユーザーが入力した文と、質問分類器が受け取った文を照合します。画面へ表示された回答だけを見て「分類が間違った」と判断せず、まず同じ文を分類したかを調べます。文書の全文を渡すつもりでタイトルだけを渡した例では、分類基準より入力の接続を直す必要があります。

会話履歴や前段の要約を使う場合は、今回の文以外の情報が入っていないかも記録します。「前の件をお願いします」は、前の会話があるかどうかで判断できる範囲が変わります。同じ短文だけで結果を比較したつもりでも、履歴が異なれば同じ入力条件ではありません。

未入力や空白だけの文は、分類器へ送る前に検出する設計が考えられます。本稿の十二件でも一件は未入力として、追加確認の案内へ返す期待にしています。LLMへ分類を頼む回数を増やす前に、入力が存在するかを確かめるだけで切り分けられる問題があります。

業務上の問い合わせ文には個人情報や契約情報が入ることがあります。検証用に実データを外へ送らず、以下のように架空の短文で経路を確認してください。実運用で何をモデルへ渡せるかは、組織の取扱いルールと利用するサービスの条件に従って決めます。

分類先と、各経路の回答・合流を別に確認する

実行履歴で正しいクラスが選ばれていても、その先に別の知識検索や回答が接続されていれば、利用者には違う窓口の回答が届きます。クラス名だけを直すのではなく、操作案内の経路が操作向けの情報へつながっているか、契約・請求の経路が所定の案内へつながっているかを見ます。

各経路の返答は、最初は違いが分かる短い教材文で確認すると切り分けやすくなります。「操作の案内へ進みます」「契約窓口の確認事項を案内します」「対象を確認させてください」のように、経路ごとの役割だけを明示します。長い生成回答の内容を採点するのは、その接続が確認できてからです。

合流する場合も、実行されなかった分岐の出力を無条件に参照していないかを確かめます。変数集約と分岐出力の確認を使い、型の違い、存在しない出力、別経路の変数を混ぜていないかを点検できます。

回答がないという症状でも、分類器で失敗したのか、分岐先が未接続なのか、合流後の変数が空なのかで対処が変わります。実行したノードを順番にたどり、「どこまで想定どおりだったか」を残します。最終回答だけの比較より、原因となる箇所を狭められます。

今回の三経路では、自動で契約を変更したり、支払いを実行したりする処理をつなぎません。特に「返金して」という入力がbillingへ分類された場合も、返金が認められたと回答せず、案内と確認事項を返す設計です。分類器の役割を越える約束を、回答文にも入れないようにしましょう。

十二件の期待経路を使い、ずれた原因を一つずつ修正する

通常の質問だけでなく、混在・曖昧・範囲外を入れる

最初のテストに分かりやすい二件だけを入れると、分類の説明が重なる問題を見逃します。操作の質問だけ、請求の質問だけに加え、二つの意図が混じる文、対象が不明な文、対応範囲外の文、否定を含む文を用意します。期待経路は結果を見る前に決めてください。

以下の十二件は、本稿の三分類と優先方針から作った期待結果です。モデルの実測ではありません。番号を付けておくと、説明文を更新した後も同じ入力を比較でき、問題のある文だけに合わせて他の分類を壊していないか確認できます。

T12では、返金に関する問い合わせとして窓口へ回す設計にしていますが、入力の命令に従って返金完了と回答することを期待していません。経路の確認と、回答や実行権限の確認を分けるための例です。分類が想定どおりでも、下流が手続を実行してしまえば別の問題です。

クラスを三つから五つへ増やす場合も、既存の十二件を残して期待経路を更新します。新しい分類に合う文だけを試すと、従来の正常な問い合わせが別経路へ移ったことを見落としやすくなります。変更前後で何を維持したいかを先に示しましょう。

期待と実出力を、件数だけでなく入力ごとに並べる

利用中のDifyでは、各IDについて入力、クラスの説明、表示名、実際に通った経路、最終回答の種類を記録します。class_nameとclass_labelは文字数が違う可能性もあるため、画面の短い名前だけを写して済ませず、出力にどの値が入っているかを確認してください。

比較用には、経路ごとの固定コードを別に持つと、説明文の編集と結果の集計を分けやすくなります。以下のusage・billing・review・input_requiredは教材の記録用コードです。Dify標準の出力項目ではないので、自分のフローの実出力を記録する際は対応関係を明示します。

# 教材用の期待表。外部LLMやDifyは呼び出しません。
expected = {
    "T01": "usage", "T02": "usage", "T03": "billing",
    "T04": "billing", "T05": "billing", "T06": "review",
    "T07": "review", "T08": "billing", "T09": "review",
    "T10": "input_required", "T11": "usage", "T12": "billing",
}
assert len(expected) == 12
assert list(expected.values()).count("input_required") == 1
assert sum(v != "input_required" for v in expected.values()) == 11

T10は分類器に入る前の確認なので、分類器へ渡す十一件と、入力チェック一件を分けます。これを全部まとめて「分類の正解率」と呼ぶと、違う仕組みの成否を混ぜます。全体のフロー確認では十二件を扱い、分類ノードだけの確認では対象を区別してください。

実結果が集まっていない段階で、期待表をそのままobservedという列へコピーしないようにします。期待した結果と実際に得た結果が同じ表にあっても、列の由来が違います。未実行は空欄または未確認と明記し、正常という値を埋めないことが大切です。

一致しない文を分類し、変える箇所を一つに絞る

T02だけが契約へ回るなら、停止という語が解約と重なっていないか、操作説明で通知設定を含めたかを調べます。T05が操作へ回るなら、複数意図のときは契約・請求を優先すると書いたかを確認します。すべてのずれをモデルの性能だけで説明しないようにしましょう。

次のコードは、比較する仕組みを確認するために、二件を意図的に変えた架空の実出力を作ります。Difyで二件間違ったという実測ではありません。自分で取得した結果を同じ形へ入れたとき、どのIDが違うかを取り出せることを確認します。

observed_fixture = dict(expected)  # 比較処理の説明用データ
observed_fixture["T02"] = "billing"
observed_fixture["T05"] = "usage"
differences = [
    {"id": key, "expected": value, "observed": observed_fixture[key]}
    for key, value in expected.items() if value != observed_fixture[key]
]
assert [row["id"] for row in differences] == ["T02", "T05"]
print(differences)

説明文を変えるときは、まず一つの方針を明確にし、同じ十二件を再確認します。モデル、説明、入力、接続先を同時に変えると、どの変更が結果へ影響したか判断しにくくなります。記録には変更前の説明も残し、何を改善しようとしたかを書いてください。

一度の結果だけで安定したと判断しないことも必要です。LLMによる分類では、同じ条件でも出力が揺れる可能性を前提に、用途に応じて繰り返し確認します。何回試すかは必要な品質と費用に合わせて決め、実行していない回数や精度を記事や報告へ記載しないでください。

取れた値が正しくても後続の判定に渡らない場合は、コードノードの出力名と型の確認も役立ちます。分類の説明を直す作業と、参照している変数を直す作業は分けて調べると、修正する範囲を小さくできます。

「確認が必要」の経路にも、使える回答を用意する

三つ目の経路を作るだけでは、曖昧な質問への対応は完成しません。T06なら「どの画面で、何をしようとして、どの表示が出たか」、T09なら「どの件についての依頼か」を短く尋ねる案内を用意します。一度に大量の情報を求めず、分類に必要な不足分へ絞ります。

範囲外のT07では、業務ツールの操作や契約に関する窓口であることを示します。関連しない知識ベースを検索してもっともらしい天気を回答させる必要はありません。対応範囲を明確にすることで、利用者が次に何を入力すればよいかを示せます。

知識検索をつなぐ場合は、分類が適切でも情報が見つからないケースを別に試します。質問の種別を決められたことと、回答の根拠があることは違います。知識検索が空のときの確認に沿って、見つからない状態から推測で回答しない経路を用意します。

実行記録には、確認へ回した理由も残すと改善に使いやすくなります。入力不足が多いなら質問フォームや最初の案内、説明の重なりが多いなら分類定義、情報がないならナレッジの範囲を見直します。「その他が多い」という一つの数字だけでは、直す対象を決められません。

本稿の教材で期待どおりに分かれても、会社の問い合わせ全体を評価したことにはなりません。新しい商品名、社内用語、複数言語、長文、連続した会話など、自分の用途に必要な例を追加します。架空の短文から始め、実運用で扱える情報の範囲を守って段階的に確認しましょう。

よくある質問と、公開前に残す確認メモ

質問と回答

Q. class_nameは短いクラス名ですか？

A.

2026年10月28日に確認した現行公式では、分類説明の本文がclass_name、キャンバス上の短い見出しがclass_labelです。利用中の版でも実出力を開いて照合してください。

Q. 表示名を変えれば分類基準も変わりますか？

A.

現行公式では見出しと説明は独立して編集します。LLMが読む説明本文に、含む内容、除外する内容、重なる場合の方針を記述したかを確認してください。

Q. 質問分類器の後にIF/ELSEは必要ですか？

A.

各クラスから下流のノードへ接続できます。別の確定条件を判定したい場合にIF/ELSEを使い、分類名を比較するためだけに不要な判定を増やしていないか確認します。

Q. その他へ分類される文が多いときは？

A.

入力不足、範囲外、説明の重なりなどへ分けて記録します。対象不明の質問には追加確認を返し、分類の定義が重なっている場合は含む内容と除外内容を見直します。

Q. 契約・請求へ分類されたら解約処理をしてよいですか？

A.

分類は窓口を選ぶ判断であり、本人確認や承認の完了ではありません。教材では手続を実行せず、確認事項を案内します。実行条件は別に定義して検証してください。

Q. 十二件の表はDifyでの実測結果ですか？

A.

実測ではなく、架空の問い合わせと設計上の期待経路です。Pythonも期待表と意図的な比較用データを扱うだけです。自分の環境の実出力を別の列へ記録して照合してください。

公開前の確認メモには、分類対象の入力変数、モデルと設定、三つの説明と表示名、接続先、十二件の期待と実出力を残します。未確認の欄を埋めることが目的ではなく、どの条件でどの経路を確認できたかを共有する資料にします。モデル利用料やDifyの提供範囲も、自分の契約と環境で確認してください。

学習を進めるときは、Dify独学ロードマップのように、一つの入力から回答までの流れを先に完成させます。クラスを増やす前に、短い見出しと説明の違い、未入力、複数意図、確認経路を説明できる状態にすると、次のフローでも同じ確認を使えます。

質問分類器だけで業務判断をすべて済ませようとせず、意図を分ける段階、根拠を探す段階、条件を確かめる段階を分けます。T02とT05のような似た言葉を含む例を見比べ、接続まで含めて確認することが、見た目は完成しているのに回答がずれる問題の切り分けにつながります。

問い合わせ分類からDifyを使った業務フローの構築へ学習を広げたい人には、バイテックのDifyマスターコースも比較先になります。公式では申請フローや顧客管理、レポート自動化などの簡易システム構築を学ぶ内容を案内しています。今回の分類説明や出力変数の相談が可能か、サポート範囲、Dify・モデルの利用料を含めた必要費用、受講総額を無料説明会で確認してください。まず十二件の期待表を自分の用途へ置き換えてから、支援が必要な範囲を整理すると比較しやすくなります。（公式情報確認日：2026年10月28日、バイテック公式）。

広告：バイテックのDify学習・無料説明会を確認する