分類タスクに従来のMLアプローチではなく、ClaudeのようなLLMを使用すべき主な指標は次のとおりです。
自動化する前に、既存のチケットシステムを理解することが重要です。まず、サポートチームが現在どのようにチケットルーティングを処理しているかを調査することから始めましょう。
次のような質問を検討してください。
人間が特定のケースをどのように処理するかについて知れば知るほど、Claudeとより良く連携してタスクを実行できます。
明確に定義されたユーザー意図カテゴリのリストは、Claudeによる正確なサポートチケット分類に不可欠です。Claudeがシステム内でチケットを効果的にルーティングする能力は、システムのカテゴリがどれだけ明確に定義されているかに直接比例します。
以下は、ユーザー意図カテゴリとサブカテゴリの例です。
意図に加えて、チケットのルーティングと優先順位付けは、緊急度、顧客タイプ、SLA、言語などの他の要因によっても影響を受ける可能性があります。自動ルーティングシステムを構築する際には、他のルーティング基準も必ず考慮してください。
サポートチームと協力して、測定可能なベンチマーク、しきい値、目標を持つ明確な成功基準を定義します。
以下は、サポートチケットルーティングにLLMを使用する際の標準的な基準とベンチマークです。
以下は、LLMを使用するかどうかに関係なく役立つ可能性のある一般的な成功基準です。
モデルの選択は、コスト、精度、応答時間のトレードオフによって決まります。
多くのお客様は、claude-haiku-4-5-20251001がチケットルーティングに理想的なモデルであると感じています。これはClaude 4ファミリーの中で最も高速でコスト効率の高いモデルでありながら、優れた結果を提供するためです。分類問題に深い専門知識、大量の意図カテゴリ、または複雑な推論が必要な場合は、より大きなSonnetモデルを選択することもできます。
チケットルーティングは分類タスクの一種です。Claudeはサポートチケットの内容を分析し、問題の種類、緊急度、必要な専門知識、その他の関連要因に基づいて、事前定義されたカテゴリに分類します。
チケット分類プロンプトを作成します。初期プロンプトには、ユーザーリクエストの内容を含め、推論と意図の両方を返すようにします。
Claude Cookbookのメタプロンプトレシピを試して、Claudeに最初のドラフトを書いてもらいましょう。
以下は、チケットルーティング分類プロンプトの例です。
def classify_support_request(ticket_contents):
# 分類タスク用のプロンプトを定義します
classification_prompt = f"""You will be acting as a customer support ticket classification system. Your task is to analyze customer support requests and output the appropriate classification intent for each request, along with your reasoning.
Here is the customer support request you need to classify:
<request>{ticket_contents}</request>
Please carefully analyze the above request to determine the customer's core intent and needs. Consider what the customer is asking for has concerns about.
First, write out your reasoning and analysis of how to classify this request inside <reasoning> tags.
Then, output the appropriate classification label for the request inside a <intent> tag. The valid intents are:
<intents>
<intent>Support, Feedback, Complaint</intent>
<intent>Order Tracking</intent>
<intent>Refund/Exchange</intent>
</intents>
A request may have ONLY ONE applicable intent. Only include the intent that is most applicable to the request.
As an example, consider the following request:
<request>Hello! I had high-speed fiber internet installed on Saturday and my installer, Kevin, was absolutely fantastic! Where can I send my positive review? Thanks for your help!</request>
Here is an example of how your output should be formatted (for the above example request):
<reasoning>The user seeks information in order to leave positive feedback.</reasoning>
<intent>Support, Feedback, Complaint</intent>
Here are a few more examples:
<examples>
<example 2>
Example 2 Input:
<request>I wanted to write and personally thank you for the compassion you showed towards my family during my father's funeral this past weekend. Your staff was so considerate and helpful throughout this whole process; it really took a load off our shoulders. The visitation brochures were beautiful. We'll never forget the kindness you showed us and we are so appreciative of how smoothly the proceedings went. Thank you, again, Amarantha Hill on behalf of the Hill Family.</request>
Example 2 Output:
<reasoning>User leaves a positive review of their experience.</reasoning>
<intent>Support, Feedback, Complaint</intent>
</example 2>
<example 3>
...
</example 8>
<example 9>
Example 9 Input:
<request>Your website keeps sending ad-popups that block the entire screen. It took me twenty minutes just to finally find the phone number to call and complain. How can I possibly access my account information with all of these popups? Can you access my account for me, since your website is broken? I need to know what the address is on file.</request>
Example 9 Output:
<reasoning>The user requests help accessing their web account information.</reasoning>
<intent>Support, Feedback, Complaint</intent>
</example 9>
Remember to always include your classification reasoning before your actual intent output. The reasoning should be enclosed in <reasoning> tags and the intent in <intent> tags. Return only the reasoning and the intent.
"""このプロンプトの主要なコンポーネントは次のとおりです。
ticket_contentsを<request>タグに挿入できます。<reasoning>タグ内に提供し、その後に適切な分類ラベルを<intent>タグ内に提供します。Claudeに応答を個別のXMLタグセクションに分割させることで、正規表現を使用して出力から推論と意図を独立して抽出できます。これにより、意図のみを使用してチケットをどの担当者にルーティングするかを決定するなど、チケットルーティングワークフローで的を絞った次のステップを作成できます。
テスト本番環境にデプロイして評価を実行しないと、プロンプトがどれだけうまく機能するかを知ることは困難です。
デプロイ構造を構築します。まず、Claudeへの呼び出しをラップするメソッドシグネチャを定義することから始めます。先ほど書き始めたticket_contentsを入力として受け取るメソッドを拡張し、出力としてreasoningとintentのタプルを返すようにします。従来のMLを使用した既存の自動化がある場合は、代わりにそのメソッドシグネチャに従うことをお勧めします。
import re
# Claude APIクライアントのインスタンスを作成します
client = anthropic.Anthropic()
# デフォルトのモデルを設定します
DEFAULT_MODEL = "claude-haiku-4-5-20251001"
def classify_support_request(ticket_contents):
# 分類タスク用のプロンプトを定義します
classification_prompt = f"""You will be acting as a customer support ticket classification system.
...
... The reasoning should be enclosed in <reasoning> tags and the intent in <intent> tags. Return only the reasoning and the intent.
"""
# プロンプトをAPIに送信してサポートリクエストを分類します。
message = client.messages.create(
model=DEFAULT_MODEL,
max_tokens=500,
temperature=0,
messages=[{"role": "user", "content": classification_prompt}],
stream=False,
)
reasoning_and_intent = message.content[0].text
# Pythonの正規表現ライブラリを使用して`reasoning`を抽出します。
reasoning_match = re.search(
r"<reasoning>(.*?)</reasoning>", reasoning_and_intent, re.DOTALL
)
reasoning = reasoning_match.group(1).strip() if reasoning_match else ""
# 同様に、`intent`も抽出します。
intent_match = re.search(r"<intent>(.*?)</intent>", reasoning_and_intent, re.DOTALL)
intent = intent_match.group(1).strip() if intent_match else ""
return reasoning, intentこのコードは次のことを行います。
ticket_contents文字列を受け取るclassify_support_request関数を定義します。classification_promptを使用して、分類のためにticket_contentsをClaudeに送信します。reasoningとintentを返します。推論と意図のテキスト全体を解析前に生成する必要があるため、この例ではstream=False(デフォルト)を設定しています。
プロンプティングは、本番環境に対応できるようにするために、多くの場合テストと最適化が必要です。ソリューションの準備状況を判断するには、先に確立した成功基準としきい値に基づいてパフォーマンスを評価します。
評価を実行するには、実行するテストケースが必要です。このガイドの残りの部分では、すでにテストケースを開発済みであることを前提としています。
このガイドの評価例では、3つの主要な指標に沿ってClaudeのパフォーマンスを測定します。
重要な要因に応じて、他の軸でClaudeを評価する必要がある場合があります。
これを評価するには、まずスクリプトを変更して、予測された意図と実際の意図を比較し、正しい予測の割合を計算する関数を追加します。次に、コスト計算と時間測定の機能を追加します。
import re
# Claude APIクライアントのインスタンスを作成します
client = anthropic.Anthropic()
# デフォルトのモデルを設定します
DEFAULT_MODEL = "claude-haiku-4-5-20251001"
def classify_support_request(request, actual_intent):
# 分類タスク用のプロンプトを定義します
classification_prompt = f"""You will be acting as a customer support ticket classification system.
...
...The reasoning should be enclosed in <reasoning> tags and the intent in <intent> tags. Return only the reasoning and the intent.
"""
message = client.messages.create(
model=DEFAULT_MODEL,
max_tokens=500,
temperature=0,
messages=[{"role": "user", "content": classification_prompt}],
)
usage = message.usage # Get the usage statistics for the API call for how many input and output tokens were used.
reasoning_and_intent = message.content[0].text
# Pythonの正規表現ライブラリを使用して`reasoning`を抽出します。
reasoning_match = re.search(
r"<reasoning>(.*?)</reasoning>", reasoning_and_intent, re.DOTALL
)
reasoning = reasoning_match.group(1).strip() if reasoning_match else ""
# 同様に、`intent`も抽出します。
intent_match = re.search(r"<intent>(.*?)</intent>", reasoning_and_intent, re.DOTALL)
intent = intent_match.group(1).strip() if intent_match else ""
# モデルの予測が正しいかどうかを確認します。
correct = actual_intent.strip() == intent.strip()
# reasoning、intent、correct、usageを返します。
return reasoning, intent, correct, usage編集内容の内訳は次のとおりです。
classify_support_requestメソッドは、テストケースからactual_intentを受け取り、Claudeの意図分類と比較して一致するかどうかを評価するようになりました。適切な評価には、何が良い結果であるかを判断するための明確なしきい値とベンチマークが必要です。前述のスクリプトは、精度、応答時間、分類あたりのコストの実行時の値を返しますが、明確に確立されたしきい値が依然として必要です。例えば:
これらのしきい値を持つことで、どの方法が最適か、要件により適合させるためにどのような変更が必要かを、大規模かつ公平な実証主義で迅速かつ容易に判断できます。
複雑なシナリオでは、標準的なプロンプトエンジニアリング手法やガードレール実装戦略を超えて、パフォーマンスを向上させるための追加戦略を検討することが役立つ場合があります。以下は一般的なシナリオです。
クラスの数が増えると、必要な例の数も増え、プロンプトが扱いにくくなる可能性があります。代替案として、複数の分類器を組み合わせた階層的分類システムの実装を検討できます。
例えば、チケットを「技術的な問題」、「請求に関する質問」、「一般的な問い合わせ」に大まかに分類するトップレベルの分類器を用意できます。これらの各カテゴリには、分類をさらに細分化するための独自のサブ分類器を持たせることができます。

長所 - より高いニュアンスと精度: 各親パスに対して異なるプロンプトを作成でき、より的を絞ったコンテキスト固有の分類が可能になります。これにより、精度が向上し、顧客リクエストをよりニュアンスを持って処理できるようになります。
短所 - レイテンシの増加: 複数の分類器はレイテンシの増加につながる可能性があることに注意してください。Anthropicは、最も高速なモデルであるHaikuでこのアプローチを実装することを推奨しています。
例を提供することがパフォーマンスを向上させる最も効果的な方法であるにもかかわらず、サポートリクエストの変動性が高い場合、単一のプロンプトに十分な例を含めることが難しい場合があります。
このシナリオでは、ベクトルデータベースを使用して例のデータセットから類似性検索を行い、特定のクエリに最も関連性の高い例を取得できます。
このアプローチは、分類レシピで詳しく説明されており、精度を71%から93%に向上させることが示されています。
以下は、Claudeがチケットを誤分類する可能性のあるシナリオです(あなたの状況に固有の他のシナリオもあるかもしれません)。これらのシナリオでは、Claudeがエッジケースをどのように処理すべきかについて、プロンプトに明示的な指示や例を提供することを検討してください。
適切な統合には、Claudeベースのチケットルーティングスクリプトがより大きなチケットルーティングシステムのアーキテクチャにどのように適合するかについて、いくつかの決定を行う必要があります。これには2つの方法があります。
これらのアプローチのいずれの場合も、スクリプトをサービスでラップする必要があります。アプローチの選択は、サポートチケットシステムが提供するAPIによって異なります。
より多くのサンプルコードと詳細な評価ガイダンスについては、分類クックブックをご覧ください。
Claude Consoleでワークフローの構築と評価を始めましょう。
Was this page helpful?