チケットルーティングにClaudeを使用するかどうかを決定する
分類タスクに従来のMLアプローチではなく、Claudeのような大規模言語モデルを使用すべき主要な指標をいくつか示します:利用可能なラベル付きトレーニングデータが限られている
利用可能なラベル付きトレーニングデータが限られている
従来のMLプロセスには大量のラベル付きデータセットが必要です。Claudeの事前トレーニング済みモデルは、わずか数十のラベル付き例でチケットを効果的に分類でき、データ準備時間とコストを大幅に削減できます。
分類カテゴリが時間の経過とともに変更または進化する可能性が高い
分類カテゴリが時間の経過とともに変更または進化する可能性が高い
従来のMLアプローチが確立されると、それを変更することは労力とデータ集約的な作業になります。一方、製品や顧客のニーズが進化するにつれて、Claudeはクラス定義の変更や新しいクラスに、トレーニングデータの大規模な再ラベル付けなしに簡単に適応できます。
複雑で非構造化されたテキスト入力を処理する必要がある
複雑で非構造化されたテキスト入力を処理する必要がある
従来のMLモデルは非構造化データに苦労することが多く、広範囲な特徴エンジニアリングが必要です。Claudeの高度な言語理解により、厳密な存在論的構造に依存するのではなく、内容と文脈に基づいた正確な分類が可能になります。
分類ルールが意味的理解に基づいている
分類ルールが意味的理解に基づいている
従来のMLアプローチは、しばしばbag-of-wordsモデルや単純なパターンマッチングに依存しています。Claudeは、クラスが例ではなく条件によって定義される場合に、基礎となるルールを理解し適用することに優れています。
分類決定に対する解釈可能な推論が必要
分類決定に対する解釈可能な推論が必要
多くの従来のMLモデルは、その意思決定プロセスについてほとんど洞察を提供しません。Claudeは分類決定に対して人間が読める説明を提供でき、自動化システムへの信頼を構築し、必要に応じて簡単な適応を促進します。
エッジケースや曖昧なチケットをより効果的に処理したい
エッジケースや曖昧なチケットをより効果的に処理したい
従来のMLシステムは外れ値や曖昧な入力に苦労することが多く、しばしばそれらを誤分類したり、包括的なカテゴリにデフォルト設定したりします。Claudeの自然言語処理機能により、サポートチケットの文脈とニュアンスをより良く解釈でき、手動介入が必要な誤ルーティングや未分類チケットの数を潜在的に削減できます。
別々のモデルを維持することなく多言語サポートが必要
別々のモデルを維持することなく多言語サポートが必要
従来のMLアプローチは通常、サポートされる各言語に対して別々のモデルまたは広範囲な翻訳プロセスが必要です。Claudeの多言語機能により、別々のモデルや広範囲な翻訳プロセスを必要とすることなく、様々な言語でチケットを分類でき、グローバルな顧客ベースのサポートを合理化できます。
LLMサポートワークフローの構築とデプロイ
現在のサポートアプローチを理解する
自動化に飛び込む前に、既存のチケットシステムを理解することが重要です。サポートチームが現在どのようにチケットルーティングを処理しているかを調査することから始めましょう。 次のような質問を考慮してください:- どのSLA/サービス提供が適用されるかを決定するためにどのような基準が使用されますか?
- チケットルーティングは、チケットがどのサポート層や製品スペシャリストに送られるかを決定するために使用されますか?
- すでに自動化されたルールやワークフローはありますか?どのような場合に失敗しますか?
- エッジケースや曖昧なチケットはどのように処理されますか?
- チームはどのようにチケットを優先順位付けしますか?
ユーザー意図カテゴリを定義する
明確に定義されたユーザー意図カテゴリのリストは、Claudeによる正確なサポートチケット分類にとって重要です。Claudeがシステム内でチケットを効果的にルーティングする能力は、システムのカテゴリがどれだけ明確に定義されているかに直接比例します。 以下は、ユーザー意図カテゴリとサブカテゴリの例です。技術的問題
技術的問題
- ハードウェアの問題
- ソフトウェアのバグ
- 互換性の問題
- パフォーマンスの問題
アカウント管理
アカウント管理
- パスワードリセット
- アカウントアクセスの問題
- 請求に関する問い合わせ
- サブスクリプションの変更
製品情報
製品情報
- 機能に関する問い合わせ
- 製品互換性の質問
- 価格情報
- 在庫に関する問い合わせ
ユーザーガイダンス
ユーザーガイダンス
- ハウツーの質問
- 機能使用のサポート
- ベストプラクティスのアドバイス
- トラブルシューティングガイダンス
フィードバック
フィードバック
- バグレポート
- 機能リクエスト
- 一般的なフィードバックや提案
- 苦情
注文関連
注文関連
- 注文状況の問い合わせ
- 配送情報
- 返品・交換
- 注文の変更
サービスリクエスト
サービスリクエスト
- インストールサポート
- アップグレードリクエスト
- メンテナンススケジューリング
- サービスキャンセル
セキュリティの懸念
セキュリティの懸念
- データプライバシーに関する問い合わせ
- 不審な活動の報告
- セキュリティ機能のサポート
コンプライアンスと法的事項
コンプライアンスと法的事項
- 規制コンプライアンスの質問
- 利用規約に関する問い合わせ
- 法的文書のリクエスト
緊急サポート
緊急サポート
- 重要なシステム障害
- 緊急のセキュリティ問題
- 時間に敏感な問題
トレーニングと教育
トレーニングと教育
- 製品トレーニングリクエスト
- ドキュメントに関する問い合わせ
- ウェビナーやワークショップの情報
統合とAPI
統合とAPI
- 統合サポート
- API使用に関する質問
- サードパーティ互換性の問い合わせ
成功基準を確立する
サポートチームと協力して、測定可能なベンチマーク、閾値、目標を持つ明確な成功基準を定義してください。 サポートチケットルーティングにLLMを使用する際の標準的な基準とベンチマークをいくつか示します:分類の一貫性
分類の一貫性
この指標は、Claudeが時間の経過とともに類似のチケットをどれだけ一貫して分類するかを評価します。これはルーティングの信頼性を維持するために重要です。標準化された入力セットでモデルを定期的にテストし、95%以上の一貫性率を目指すことで測定します。
適応速度
適応速度
これは、Claudeが新しいカテゴリや変化するチケットパターンにどれだけ迅速に適応できるかを測定します。新しいチケットタイプを導入し、これらの新しいカテゴリで満足のいく精度(例:90%以上)を達成するまでにかかる時間を測定することでテストします。50-100のサンプルチケット内での適応を目指します。
多言語処理
多言語処理
これは、Claudeが複数の言語でチケットを正確にルーティングする能力を評価します。異なる言語間でのルーティング精度を測定し、非主要言語での精度低下を5-10%以内に抑えることを目指します。
エッジケース処理
エッジケース処理
これは、異常または複雑なチケットに対するClaudeのパフォーマンスを評価します。エッジケースのテストセットを作成し、ルーティング精度を測定し、これらの困難な入力で少なくとも80%の精度を目指します。
バイアス軽減
バイアス軽減
これは、異なる顧客層にわたるルーティングにおけるClaudeの公平性を測定します。潜在的なバイアスについてルーティング決定を定期的に監査し、すべての顧客グループにわたって一貫したルーティング精度(2-3%以内)を目指します。
プロンプト効率
プロンプト効率
トークン数の最小化が重要な状況では、この基準はClaudeが最小限のコンテキストでどれだけうまく実行するかを評価します。提供されるコンテキストの量を変えてルーティング精度を測定し、チケットタイトルと簡潔な説明だけで90%以上の精度を目指します。
説明可能性スコア
説明可能性スコア
これは、Claudeのルーティング決定に対する説明の質と関連性を評価します。人間の評価者が説明をスケール(例:1-5)で評価でき、平均スコア4以上の達成を目標とします。
ルーティング精度
ルーティング精度
ルーティング精度は、チケットが最初の試行で適切なチームまたは個人に正しく割り当てられる頻度を測定します。これは通常、総チケット数に対する正しくルーティングされたチケットの割合として測定されます。業界ベンチマークは多くの場合90-95%の精度を目指しますが、これはサポート構造の複雑さによって異なる場合があります。
割り当てまでの時間
割り当てまでの時間
この指標は、チケットが提出された後、どれだけ迅速に割り当てられるかを追跡します。より速い割り当て時間は一般的により迅速な解決と顧客満足度の向上につながります。最高クラスのシステムは多くの場合5分未満の平均割り当て時間を達成し、多くがほぼ瞬時のルーティング(LLM実装で可能)を目指しています。
再ルーティング率
再ルーティング率
再ルーティング率は、初期ルーティング後にチケットが再割り当てされる頻度を示します。低い率はより正確な初期ルーティングを示唆します。10%未満の再ルーティング率を目指し、トップパフォーマンスシステムは5%以下の率を達成しています。
初回接触解決率
初回接触解決率
これは、顧客との最初のやり取りで解決されるチケットの割合を測定します。高い率は効率的なルーティングと十分に準備されたサポートチームを示します。業界ベンチマークは通常70-75%の範囲で、トップパフォーマーは80%以上の率を達成しています。
平均処理時間
平均処理時間
平均処理時間は、チケットが開始から終了まで解決されるのにかかる時間を測定します。効率的なルーティングはこの時間を大幅に短縮できます。ベンチマークは業界と複雑さによって大きく異なりますが、多くの組織は重要でない問題について平均処理時間を24時間未満に保つことを目指しています。
顧客満足度スコア
顧客満足度スコア
多くの場合、やり取り後の調査で測定され、これらのスコアはサポートプロセス全体に対する顧客の総合的な満足度を反映します。効果的なルーティングはより高い満足度に貢献します。90%以上のCSATスコアを目指し、トップパフォーマーは多くの場合95%以上の満足率を達成しています。
エスカレーション率
エスカレーション率
これは、チケットがより高いサポート層にエスカレーションされる頻度を測定します。低いエスカレーション率は多くの場合、より正確な初期ルーティングを示します。20%未満のエスカレーション率を目指し、最高クラスのシステムは10%以下の率を達成しています。
エージェント生産性
エージェント生産性
この指標は、ルーティングソリューション実装後にエージェントがどれだけ多くのチケットを効果的に処理できるかを見ます。改善されたルーティングは生産性を向上させるはずです。エージェント1人当たり1日または1時間当たりの解決チケット数を追跡することで測定し、新しいルーティングシステム実装後10-20%の改善を目指します。
セルフサービス転換率
セルフサービス転換率
これは、ルーティングシステムに入る前にセルフサービスオプションで解決される潜在的チケットの割合を測定します。高い率は効果的なルーティング前トリアージを示します。20-30%の転換率を目指し、トップパフォーマーは40%以上の率を達成しています。
チケット当たりのコスト
チケット当たりのコスト
この指標は、各サポートチケットを解決するための平均コストを計算します。効率的なルーティングは時間の経過とともにこのコストを削減するのに役立つはずです。ベンチマークは大きく異なりますが、多くの組織は改善されたルーティングシステム実装後にチケット当たりのコストを10-15%削減することを目指しています。
適切なClaudeモデルを選択する
モデルの選択は、コスト、精度、応答時間の間のトレードオフによって決まります。 多くの顧客は、claude-3-5-haiku-20241022がチケットルーティングに理想的なモデルであることを発見しています。これはClaude 3ファミリーで最も高速で費用対効果の高いモデルでありながら、優れた結果を提供するためです。分類問題が深い専門知識や大量の意図カテゴリの複雑な推論を必要とする場合は、より大きなSonnetモデルを選択することもできます。
強力なプロンプトを構築する
チケットルーティングは分類タスクの一種です。Claudeはサポートチケットの内容を分析し、問題タイプ、緊急度、必要な専門知識、またはその他の関連要因に基づいて事前定義されたカテゴリに分類します。 チケット分類プロンプトを書いてみましょう。初期プロンプトには、ユーザーリクエストの内容を含み、推論と意図の両方を返すべきです。Claude Consoleのプロンプトジェネレーターを試して、Claudeに最初のドラフトを書いてもらいましょう。
- Python f-stringsを使用してプロンプトテンプレートを作成し、
ticket_contentsを<request>タグに挿入できるようにしています。 - Claudeに、チケット内容を注意深く分析して顧客の核となる意図とニーズを決定する分類システムとしての明確に定義された役割を与えています。
- 適切な出力フォーマットについてClaudeに指示し、この場合は
<reasoning>タグ内に推論と分析を提供し、続いて<intent>タグ内に適切な分類ラベルを提供するよう指示しています。 - 有効な意図カテゴリを指定しています:「サポート、フィードバック、苦情」、「注文追跡」、「返金・交換」。
- 出力がどのようにフォーマットされるべきかを説明するためにいくつかの例(いわゆるfew-shotプロンプティング)を含めており、これにより精度と一貫性が向上します。
プロンプトをデプロイする
テスト本番環境でプロンプトをデプロイし、評価を実行することなしに、プロンプトがどれだけうまく機能するかを知ることは困難です。 デプロイ構造を構築しましょう。Claudeへの呼び出しをラップするメソッドシグネチャを定義することから始めます。すでに書き始めたメソッドを取り、ticket_contentsを入力とし、出力としてreasoningとintentのタプルを返すようにします。従来のMLを使用した既存の自動化がある場合は、代わりにそのメソッドシグネチャに従う必要があります。
- AnthropicライブラリをインポートしAPIキーを使用してクライアントインスタンスを作成します。
ticket_contents文字列を受け取るclassify_support_request関数を定義します。classification_promptを使用して分類のためにticket_contentsをClaudeに送信します- 応答から抽出されたモデルの
reasoningとintentを返します。
stream=False(デフォルト)に設定します。
プロンプトを評価する
プロンプティングは本番環境に対応するために、多くの場合テストと最適化が必要です。ソリューションの準備状況を判断するために、先ほど確立した成功基準と閾値に基づいてパフォーマンスを評価します。 評価を実行するには、実行するテストケースが必要です。このガイドの残りの部分では、すでにテストケースを開発していることを前提としています。評価関数を構築する
このガイドの例の評価では、3つの主要な指標に沿ってClaudeのパフォーマンスを測定します:- 精度
- 分類あたりのコスト
- テストケースから
actual_intentをclassify_support_requestメソッドに追加し、Claudeの意図分類が私たちのゴールデン意図分類と一致するかどうかを評価するための比較を設定しました。 - 使用された入力と出力トークンに基づいてコストを計算するために、API呼び出しの使用統計を抽出しました
評価を実行する
適切な評価には、何が良い結果かを判断するための明確な閾値とベンチマークが必要です。上記のスクリプトは精度、応答時間、分類あたりのコストのランタイム値を提供しますが、明確に確立された閾値が必要です。例えば:- 精度: 95%(100テスト中)
- 分類あたりのコスト: 現在のルーティング方法から平均50%削減(100テスト全体で)
パフォーマンスを向上させる
複雑なシナリオでは、標準的なプロンプトエンジニアリング技術とガードレール実装戦略を超えて、パフォーマンスを向上させるための追加戦略を検討することが有用な場合があります。以下は一般的なシナリオです:20以上の意図カテゴリがある場合は分類階層を使用する
クラス数が増加するにつれて、必要な例の数も拡大し、プロンプトが扱いにくくなる可能性があります。代替として、分類器の混合を使用した階層分類システムの実装を検討できます。- 意図を分類学的ツリー構造で整理します。
- ツリーのすべてのレベルで一連の分類器を作成し、カスケードルーティングアプローチを可能にします。

- 長所 - より大きなニュアンスと精度: 各親パスに対して異なるプロンプトを作成でき、より対象を絞った文脈固有の分類が可能になります。これにより精度が向上し、顧客リクエストのより細かい処理が可能になります。
- 短所 - 遅延の増加: 複数の分類器は遅延の増加につながる可能性があることに注意してください。最速のモデルであるHaikuでこのアプローチを実装することをお勧めします。
高度に可変なチケットを処理するためにベクトルデータベースと類似性検索取得を使用する
例を提供することがパフォーマンスを向上させる最も効果的な方法であるにもかかわらず、サポートリクエストが高度に可変である場合、単一のプロンプトに十分な例を含めることが困難な場合があります。 このシナリオでは、ベクトルデータベースを使用して例のデータセットから類似性検索を行い、特定のクエリに最も関連する例を取得することができます。 分類レシピで詳しく説明されているこのアプローチは、パフォーマンスを71%の精度から93%の精度に向上させることが示されています。予想されるエッジケースを具体的に考慮する
Claudeがチケットを誤分類する可能性があるシナリオをいくつか示します(あなたの状況に固有の他のものもあるかもしれません)。これらのシナリオでは、Claudeがエッジケースをどのように処理すべきかについて、プロンプトで明示的な指示や例を提供することを検討してください:顧客が暗黙的なリクエストを行う
顧客が暗黙的なリクエストを行う
顧客はしばしば間接的にニーズを表現します。例えば、「パッケージを2週間以上待っています」は注文状況の間接的なリクエストかもしれません。
- 解決策: Claudeにこの種のリクエストの実際の顧客例と、基礎となる意図が何であるかを提供してください。特に微妙なチケット意図について分類根拠を含めると、Claudeが他のチケットにロジックをより良く一般化できるため、さらに良い結果を得ることができます。
Claudeが意図よりも感情を優先する
Claudeが意図よりも感情を優先する
顧客が不満を表現する際、Claudeは基礎となる問題を解決することよりも感情に対処することを優先する場合があります。
- 解決策: 顧客の感情を優先するかどうかについてClaudeに指示を提供してください。「すべての顧客の感情を無視してください。顧客のリクエストの意図と顧客が求めている可能性のある情報の分析にのみ焦点を当ててください。」のような簡単なものでも構いません。
複数の問題が問題優先順位付けの混乱を引き起こす
複数の問題が問題優先順位付けの混乱を引き起こす
顧客が単一のやり取りで複数の問題を提示する場合、Claudeは主要な懸念を特定するのに困難を感じる場合があります。
- 解決策: Claudeが抽出された意図をより良くランク付けし、主要な懸念を特定できるように、意図の優先順位付けを明確にしてください。
Claudeをより大きなサポートワークフローに統合する
適切な統合には、Claudeベースのチケットルーティングスクリプトがより大きなチケットルーティングシステムのアーキテクチャにどのように適合するかについていくつかの決定を行う必要があります。これを行う方法は2つあります:- プッシュベース: 使用しているサポートチケットシステム(例:Zendesk)がWebhookイベントをルーティングサービスに送信することでコードをトリガーし、その後意図を分類してルーティングします。
- このアプローチはよりWebスケーラブルですが、パブリックエンドポイントを公開する必要があります。
- プルベース: コードが指定されたスケジュールに基づいて最新のチケットをプルし、プル時にルーティングします。
- このアプローチは実装が簡単ですが、プル頻度が高すぎる場合はサポートチケットシステムへの不要な呼び出しを行う可能性があり、プル頻度が低すぎる場合は過度に遅くなる可能性があります。