AIで問い合わせの担当部署を振り分ける方法

AIで問い合わせを担当部署へ振り分けるには、AIに組織図を推測させるのではなく、問い合わせ内容を分類する工程と、承認済みのRouting Ruleで担当先へ割り当てる工程を分けます。まず組織が受け付けるTopicやLanguageを定義し、分類結果をGroupやQueueへ変換します。分類に自信がない、分類語が未知、担当が不在といったケースには人が確認するFallbackを必ず用意してください。

部署名を直接予測させる方式では、部署改称や担当範囲の変更がモデル出力に混ざり、理由を追いにくくなります。分類層は「何の問い合わせか」を返し、Routing層は「どの条件なら誰が受け取るか」を明示します。これにより、誤分類は分類例やラベルを、誤配はRouting Ruleや担当Groupを、それぞれ別に調べられます。

最初に決める分類単位

Taxonomyを作るときは、現行組織名をそのままCategoryにしないでください。部署名やチーム名が変わっても、問い合わせの意味が同じなら分類は維持できるからです。最初は、問い合わせの目的に近いTopicを少数定義し、各Topicの説明、含める例、含めない例、境界例を一緒に書きます。BillingとAccountのように重なりやすい組み合わせは、どちらを優先するかではなく、どの追加情報で区別するかを決めます。

表は横にスクロールできます

分類項目	例	ラベルの定義	不明なとき
Topic	請求、技術、アカウント、営業	問い合わせの主な目的	Unknown
Language	日本語、英語など	対応言語の判定	言語確認Queue
Entity	製品名、契約種別	本文中で明示された対象	未抽出
Urgency	緊急、安全関連など	組織が承認した基準	人手確認
Confidence	分類根拠の確かさ	運用で検証して決める状態	自動割当しない

この表は設計例です。実際の組織の問い合わせ記録、担当体制、契約上の受付範囲に合わせて定義してください。分類軸を増やしすぎると、ラベル間の境界が複雑になり、学習・評価に必要な例や運用レビューが増えます。最初はRoutingに必要な最低限の項目を選び、実際に処理できない細かさをTaxonomyへ持ち込まないことが重要です。

AI分類とRouting Ruleを分ける

分類結果には、ラベルだけでなく、根拠となる問い合わせ文の範囲や未確定項目を含めるとレビューしやすくなります。AIは「Topic=Billing」「Entity=Invoice」と分類しても、請求額の正しさや返金可否を決定するわけではありません。分類が不確かな場合はUnknownやReviewにし、勝手にもっともらしい値へ補完しないようにします。

Routing Ruleは分類結果を使って担当GroupやQueueへ写像します。Ruleには優先順位、適用条件、担当が利用可能でない場合のFallback、二重実行防止、更新責任者を記録します。安全・不正アクセス・個人情報など特別な受付ルールがある場合は、通常のTopic分類より先に適用するかを組織の運用責任者が決めます。AIによる分類と、運用Ruleで行う優先処理を一つの曖昧なPromptにまとめないでください。

Routing Contractの例

表は横にスクロールできます

優先	条件	担当先	Fallback	記録する理由
1	安全・不正アクセスの明示条件	承認済みの専用窓口	人が即時確認	安全Rule
2	Topic=Billing、Language対応可	請求担当Group	共通Queue	TopicとRule ID
3	Topic=Technical、対象Product判明	対応Skillの担当	技術共通Queue	ProductとSkill
4	Unknown、境界ラベル、低信頼	トリアージQueue	人手確認	保留理由
5	対応者が不在・割当失敗	共通Queue	管理者へ通知	再割当状態

条件の順番は組織の合意が必要です。上表は動作例であり、実際の緊急度や責任範囲を定めるものではありません。個別製品の機能やプラン条件に依存する場合は、Zendesk等の公式資料と契約中の環境で確認してください。外部資料の機能説明を、そのまま自社の権限・運用設定の根拠にしないことが大切です。

導入前に作る境界例

代表的な問い合わせだけでテストすると、Routingは簡単に見えても本番で境界例を誤配します。BillingとAccountの両方に関係する相談、本文に複数の製品名がある相談、言語が混ざる相談、依頼ではなく質問だけの投稿、対象が不明な問い合わせをテストセットへ入れます。実際の顧客データを使う場合は、利用権限、最小化、匿名化、保存期間を先に確認してください。テスト用の架空例を使うときは、実際の顧客問い合わせと混同しないよう明記します。

各テストには正解Topicだけでなく、期待する担当先、許容するFallback、誤配が起きた場合の重大度を記録します。複数の担当者が独立に分類し、意見が割れるケースはラベル定義の見直し候補にします。合意できないラベルをモデルへ無理に学習させても、運用者間の判断差は解消しません。境界例を追加・変更した日と理由を残すと、結果の変化をあとで追えます。

小さく試す導入手順

1. 現在の問い合わせを個人情報を除いた形で確認し、頻出Topicと境界例を整理する。

2. Topic・Language・Entityの定義と、Unknownになる条件を決める。

3. AIに分類ラベル、根拠箇所、Unknown状態を返させる。

4. Routing Ruleを固定し、ラベルごとの担当Group・Fallbackを設定する。

5. 過去または架空のテスト例を用いて、分類とRoutingを別々に採点する。

6. 誤分類と誤配の重大度を確認し、人手Queueへ戻る条件を試す。

7. 小さな対象範囲で運用を始め、担当変更・Taxonomy変更の手順を決める。

いきなり全問い合わせの自動割当を有効にせず、最初はAI分類だけを記録して担当者が最終Routingを確認する方法があります。人の判定とAI分類の差、Unknown率、誤配、再割当、未処理Queueの滞留を観察します。十分な運用実績がない時点で、一律の精度目標や自動化率を約束しないでください。自動割当に進む条件は、問い合わせのリスクや誤配時の影響を踏まえて組織が決めます。

架空例：請求と技術質問が混在する場合

「請求書の金額が違うように見える。管理画面にもログインできない」という架空問い合わせを考えます。単純な分類器はBillingとAccountまたはTechnicalの複数ラベルを返すかもしれません。ここでTopicを一つに決めるルールがなければ、最初の担当者が誤っても次工程で戻せません。

まず、複数Topicを許すか、主TopicとSecondary Topicを分けるか決めます。次に、ログインできない状態が請求確認を妨げているのか、請求の疑問と独立した問題なのかを追加質問で確認します。判別できなければ、二つの窓口へ同時送信して顧客に重複対応させるより、共通Queueで担当者が切り分ける方法を選べます。これは例示のための設計案で、特定の会社の運用規則ではありません。

テスト時には、分類結果、適用Rule ID、割当先、Fallback理由、最終的に担当者が選んだTopicを別々に記録します。最終割当だけを見ると、分類ミスとRuleの設定ミスを区別できないからです。人がTopicを修正した場合は、正解ラベル、修正理由、対応したRuleのどちらを直すべきかを残します。

AIへ分類を依頼するPrompt

「以下の問い合わせを、提示されたTaxonomyだけを使って分類してください。出力はTopic、Language、明示されたEntity、根拠となる原文の短い箇所、Unknown項目、confidence状態に分けてください。記載されていない製品名、契約状態、緊急度、顧客属性を推測しないでください。複数Topicが関係する場合は候補を併記し、どの追加情報で区別できるかを示してください。分類だけを行い、担当部署の決定、返金可否、契約上の判断、顧客への返信文の確定は行わないでください。根拠が不足する場合はUnknownとして人手確認へ回してください。」

Promptへ顧客情報を入力する前に、利用するAIサービスのデータ取扱い、アクセス権、保存、学習利用、委託先、組織の承認範囲を確認します。個人情報を取り除けないときは、認可された環境を使うか、AI処理を行わず人が確認します。Promptの文面だけで機密情報の取扱いが安全になるわけではありません。入力を最小化し、ログへ残す項目も運用担当者と定めてください。

Failure Pathと運用レビュー

表は横にスクロールできます

症状	まず確認する層	対応
正しいTopicだが担当先が違う	Routing Rule	条件、優先順位、担当Groupを確認
Topic自体が違う	Taxonomy / 分類例	定義・境界例・入力品質を見直す
Unknownが増えた	分類軸・受付内容	新分類を急増させず原因を確認
低信頼でも自動割当	Fallback条件	閾値または停止条件を再確認
同じ問い合わせが複数Queueへ行く	Rule順序・二重実行	一度だけ適用する状態を追加
担当不在で滞留	Queue監視・代替担当	通知・再割当・期限を定義

変更後は既存のテストセットを再実行し、正しいTopicでも違うQueueへ行っていないかを確認します。Ruleを変える際は、変更日、変更者、対象条件、テスト結果、戻す方法を記録します。運用中の担当変更をAIの分類指示へ埋め込むのではなく、承認済みRouting Rule側で保守すると責任箇所が明確です。

次にすること

最初に、直近の問い合わせから個人情報を適切に除いた少数サンプルを選び、Topicの定義、境界例、Unknown条件を書き出してください。その後、AI分類だけを行うオフラインテストを作り、人の判定との差を記録します。誤配時の影響が大きい問い合わせは自動割当の対象にせず、担当責任者とFallbackが明確になってから範囲を広げます。

AIものさしの判断

AIは問い合わせ文を整理し、Topic候補や明示Entityを抽出する補助に使えます。担当先の確定は、組織が承認したRouting Ruleと担当可能状態で決め、曖昧なケースは人へ戻します。最初の実装では「分類結果を記録する」段階から始め、誤配の影響、修正担当、運用レビューを確認した後に自動割当の対象を検討してください。