Claudeで問い合わせを分類する：保留ラベルと誤分類の重みを決める

ラベルを担当者の行動に結び付ける

「その他」は便利ですが、その後誰が何をするかが不明だと処理が止まります。「情報不足で確認」「複数部署で確認」「対象外」を分けると、次の操作が決まります。分類カテゴリは説明のためだけでなく、後続の運用と一緒に設計します。

一つの文章に請求と障害の二つの話題がある場合、一つだけ選ぶのか分割するのかも決めます。モデルが毎回違う解釈をしないよう、ラベルの排他性を明示します。

全体の正解率に隠れる失敗を見る

件数が多い一般問い合わせを正しく分類するだけで、平均の正解率は高く見えることがあります。緊急対応が必要な分類を見逃すことと、一般の分類を少し間違えることは、影響が同じではありません。カテゴリごとの見逃しと誤検出を分けて確認します。

モデルが自分で出した確信度だけで自動処理の可否を決めないようにします。境界ケースの結果、入力に必要な情報があるか、別の検証条件を満たすかも判断材料になります。

保留が役立っているか確認する

保留を増やせば誤分類は減るかもしれませんが、人の確認負担が増えます。保留件数、保留後の解決率、確認にかかる時間を見て、入力画面やカテゴリ定義の改善へ戻します。保留をモデルの失敗を隠す箱にしないことが重要です。

誤りの重みを業務の後続処理で決める

重要な問い合わせを一般窓口へ送る誤りと、一般問い合わせを専門担当へ回す誤りは、影響が異なるかもしれません。モデルの得点だけで同じ一件として扱わず、対応の遅れ、再割当、確認負担を運用の観点で整理します。重みは一般的な数字を借りず、実際にその結果を受け取る担当者と決めます。評価では件数と影響を分けて提示します。

保留ラベルを導入した後は、保留された入力に何が足りなかったかを分析します。入力フォームへ一つの項目を追加すれば解決するのか、分類定義が重なっているのか、情報が実際に存在しないのかを分けます。モデルの指示を増やす以外の改善を選べるよう、保留を最終状態ではなく業務改善の観測点として扱います。

具体例で考える

架空の入力「請求書も届かず、昨日からシステムにも入れません」を仕分けます。

話題A：請求書未着→請求担当候補。
話題B：ログイン不能→技術担当候補。
運用ルール：二つの確認事項に分け、同じ問い合わせIDへ関連付ける。

一つのラベルを強制すると、どちらかの要件が落ちます。分割に対応できない業務なら、複数部署の調整へ回すラベルが必要です。出力の形式ではなく、顧客の問題が解決へ進むかで評価します。

確認課題と合格の目安

三つの分類に、情報不足と複数話題の入力を追加し、それぞれの処理先を決めてください。

• ラベルごとの後続操作が定義されている。
• 重要なカテゴリの見逃しを別に把握できる。
• 保留による人の負担を評価している。