Claude Platform Docs
  • メッセージ
  • マネージドエージェント
  • 管理

Search...
⌘K
ユースケース
概要チケットルーティングカスタマーサポートエージェントコンテンツモデレーション法務文書の要約
プロンプトエンジニアリング
概要プロンプトのベストプラクティスClaude Fable 5へのプロンプトClaude Opus 4.8へのプロンプトコンソールのプロンプトツール
テストと評価
成功の定義と評価の構築コンソールでの評価ツールの使用レイテンシの削減
ガードレールの強化
ハルシネーションの削減出力の一貫性向上ジェイルブレイクの軽減プロンプトリークの削減
リファレンス
用語集

Log in
チケットルーティング
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Claude Platform Docs

Solutions

  • AI agents
  • Code modernization
  • Coding
  • Customer support
  • Education
  • Financial services
  • Government
  • Life sciences

Partners

  • Claude on AWS
  • Claude on Google Cloud

Learn

  • Blog
  • Courses
  • Use cases
  • Connectors
  • Customer stories
  • Engineering at Anthropic
  • Events
  • Powered by Claude
  • Service partners
  • Startups program

Company

  • Anthropic
  • Careers
  • Economic Futures
  • Research
  • News
  • Responsible Scaling Policy
  • Security and compliance
  • Transparency

Learn

  • Blog
  • Courses
  • Use cases
  • Connectors
  • Customer stories
  • Engineering at Anthropic
  • Events
  • Powered by Claude
  • Service partners
  • Startups program

Help and security

  • Availability
  • Status
  • Support
  • Discord

Terms and policies

  • Privacy policy
  • Responsible disclosure policy
  • Terms of service: Commercial
  • Terms of service: Consumer
  • Usage policy
ベストプラクティス/ユースケース

チケットルーティング

このガイドでは、Claudeの高度な自然言語理解能力を活用して、顧客の意図、緊急度、優先順位、顧客プロファイルなどに基づいてカスタマーサポートチケットを大規模に分類する方法を説明します。

チケットルーティングにClaudeを使用するかどうかを判断する

分類タスクに従来の機械学習アプローチではなく、ClaudeのようなLLMを使用すべきであることを示す主な指標は以下のとおりです。


LLMサポートワークフローの構築とデプロイ

現在のサポートアプローチを理解する

自動化に取り組む前に、既存のチケットシステムを理解することが重要です。まず、サポートチームが現在どのようにチケットルーティングを処理しているかを調査することから始めます。

以下のような質問を検討してください。

  • どのSLA/サービス提供が適用されるかを決定するために、どのような基準が使用されていますか?
  • チケットルーティングは、チケットがどのサポート層または製品スペシャリストに送られるかを決定するために使用されていますか?
  • すでに自動化されたルールやワークフローはありますか?どのような場合に失敗しますか?
  • エッジケースや曖昧なチケットはどのように処理されていますか?
  • チームはどのようにチケットの優先順位を付けていますか?

人間が特定のケースをどのように処理しているかを知れば知るほど、Claudeと協力してタスクを実行しやすくなります。

ユーザー意図カテゴリを定義する

明確に定義されたユーザー意図カテゴリのリストは、Claudeによる正確なサポートチケット分類に不可欠です。システム内でチケットを効果的にルーティングするClaudeの能力は、システムのカテゴリがどれだけ明確に定義されているかに直接比例します。

以下は、ユーザー意図カテゴリとサブカテゴリの例です。

意図に加えて、チケットルーティングと優先順位付けは、緊急度、顧客タイプ、SLA、言語などの他の要因によっても影響を受ける場合があります。自動ルーティングシステムを構築する際は、他のルーティング基準も考慮してください。

成功基準を確立する

サポートチームと協力して、測定可能なベンチマーク、しきい値、目標を含む明確な成功基準を定義します。

以下は、サポートチケットルーティングにLLMを使用する際の標準的な基準とベンチマークです。

以下は、LLMが使用されているかどうかに関係なく役立つ可能性のある一般的な成功基準です。

適切なClaudeモデルを選択する

モデルの選択は、コスト、精度、応答時間の間のトレードオフに依存します。

多くのお客様は、claude-haiku-4-5-20251001がチケットルーティングに理想的なモデルであると感じています。これはClaude 4ファミリーの中で最も高速かつコスト効率の高いモデルでありながら、優れた結果を提供するためです。分類問題に深い専門知識や大量の意図カテゴリ、複雑な推論が必要な場合は、より大きなSonnetモデルを選択することもできます。

強力なプロンプトを構築する

チケットルーティングは分類タスクの一種です。Claudeはサポートチケットの内容を分析し、問題の種類、緊急度、必要な専門知識、またはその他の関連要因に基づいて、事前定義されたカテゴリに分類します。

チケット分類プロンプトを作成しましょう。初期プロンプトには、ユーザーリクエストの内容を含め、推論と意図の両方を返すようにします。



Claude Consoleのプロンプトジェネレーターを試して、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.
        """

このプロンプトの主要なコンポーネントを分解してみましょう。

  • Pythonのf文字列を使用してプロンプトテンプレートを作成し、ticket_contentsを<request>タグに挿入できるようにしています。
  • Claudeに、チケットの内容を慎重に分析して顧客の核心的な意図とニーズを判断する分類システムとしての明確に定義された役割を与えています。
  • 適切な出力フォーマットについてClaudeに指示しています。この場合、推論と分析を<reasoning>タグ内に提供し、その後に適切な分類ラベルを<intent>タグ内に提供するようにしています。
  • 有効な意図カテゴリを指定しています:「Support, Feedback, Complaint」、「Order Tracking」、「Refund/Exchange」。
  • 出力のフォーマット方法を示すためにいくつかの例(いわゆるfew-shotプロンプティング)を含めており、これにより精度と一貫性が向上します。

Claudeに応答をさまざまなXMLタグセクションに分割させる理由は、正規表現を使用して出力から推論と意図を個別に抽出できるようにするためです。これにより、意図のみを使用してチケットを誰にルーティングするかを決定するなど、チケットルーティングワークフローでターゲットを絞った次のステップを作成できます。

プロンプトをデプロイする

テスト本番環境にデプロイして評価を実行しなければ、プロンプトがどれだけうまく機能するかを知ることは困難です。

デプロイ構造を構築しましょう。まず、Claudeへの呼び出しをラップするメソッドシグネチャを定義します。すでに書き始めたメソッドを使用します。このメソッドはticket_contentsを入力として受け取り、今度はreasoningとintentのタプルを出力として返します。従来の機械学習を使用した既存の自動化がある場合は、代わりにそのメソッドシグネチャに従うことをお勧めします。

Python
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

このコードは以下を行います。

  • APIキーを使用してクライアントインスタンスを作成します。
  • ticket_contents文字列を受け取るclassify_support_request関数を定義します。
  • classification_promptを使用して分類のためにticket_contentsをClaudeに送信します。
  • 応答から抽出されたモデルのreasoningとintentを返します。

解析する前に推論と意図のテキスト全体が生成されるのを待つ必要があるため、stream=False(デフォルト)を設定しています。


プロンプトを評価する

プロンプトを本番環境で使用できるようにするには、多くの場合、テストと最適化が必要です。ソリューションの準備状況を判断するには、以前に確立した成功基準としきい値に基づいてパフォーマンスを評価します。

評価を実行するには、実行するテストケースが必要です。このガイドの残りの部分では、すでにテストケースを開発していることを前提としています。

評価関数を構築する

このガイドの評価例では、3つの主要な指標に沿ってClaudeのパフォーマンスを測定します。

  • 精度
  • 分類あたりのコスト

重要な要因に応じて、他の軸でClaudeを評価する必要がある場合があります。

これを評価するには、まず作成したスクリプトを変更し、予測された意図と実際の意図を比較して正しい予測の割合を計算する関数を追加する必要があります。また、コスト計算と時間測定の機能も追加する必要があります。

Python
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

行った編集を分解してみましょう。

  • テストケースからactual_intentをclassify_support_requestメソッドに追加し、Claudeの意図分類が正解の意図分類と一致するかどうかを評価する比較を設定しました。
  • 使用された入力トークンと出力トークンに基づいてコストを計算するために、API呼び出しの使用統計を抽出しました。

評価を実行する

適切な評価には、何が良い結果であるかを判断するための明確なしきい値とベンチマークが必要です。上記のスクリプトは、精度、応答時間、分類あたりのコストの実行時の値を提供しますが、明確に確立されたしきい値が依然として必要です。例えば:

  • 精度: 95%(100テスト中)
  • 分類あたりのコスト: 現在のルーティング方法から平均50%削減(100テスト全体)

これらのしきい値を持つことで、大規模かつ公平な実証主義により、どの方法が最適か、要件により適合させるためにどのような変更が必要かを迅速かつ容易に判断できます。


パフォーマンスを改善する

複雑なシナリオでは、標準的なプロンプトエンジニアリング手法やガードレール実装戦略を超えて、パフォーマンスを改善するための追加戦略を検討することが役立つ場合があります。以下は一般的なシナリオです。

20以上の意図カテゴリがある場合は分類階層を使用する

クラスの数が増えるにつれて、必要な例の数も増加し、プロンプトが扱いにくくなる可能性があります。代替案として、複数の分類器を組み合わせた階層的分類システムの実装を検討できます。

  1. 意図を分類ツリー構造に整理します。
  2. ツリーの各レベルで一連の分類器を作成し、カスケード型のルーティングアプローチを可能にします。

例えば、チケットを「技術的な問題」、「請求に関する質問」、「一般的な問い合わせ」に大まかに分類するトップレベルの分類器を持つことができます。これらの各カテゴリは、分類をさらに細分化するための独自のサブ分類器を持つことができます。

  • 利点 - より高いニュアンスと精度: 各親パスに対して異なるプロンプトを作成でき、よりターゲットを絞ったコンテキスト固有の分類が可能になります。これにより、精度が向上し、顧客リクエストのよりニュアンスのある処理につながる可能性があります。

  • 欠点 - レイテンシの増加: 複数の分類器は「latency」(レイテンシ)の増加につながる可能性があることに注意してください。このアプローチは、最速のモデルであるHaikuで実装することをお勧めします。

ベクターデータベースと類似性検索を使用して、非常に多様なチケットを処理する

例を提供することがパフォーマンスを改善する最も効果的な方法であるにもかかわらず、サポートリクエストが非常に多様な場合、単一のプロンプトに十分な例を含めることが困難な場合があります。

このシナリオでは、ベクターデータベースを使用して例のデータセットから類似性検索を行い、特定のクエリに最も関連性の高い例を取得できます。

分類レシピで詳しく説明されているこのアプローチは、精度を71%から93%に改善することが示されています。

予想されるエッジケースに特に対応する

以下は、Claudeがチケットを誤分類する可能性のあるシナリオです(状況に固有の他のシナリオもある可能性があります)。これらのシナリオでは、Claudeがエッジケースをどのように処理すべきかについて、プロンプトに明示的な指示または例を提供することを検討してください。


Claudeをより大きなサポートワークフローに統合する

適切な統合には、Claudeベースのチケットルーティングスクリプトがより大きなチケットルーティングシステムのアーキテクチャにどのように適合するかについて、いくつかの決定を行う必要があります。これを行うには2つの方法があります。

  • プッシュベース: 使用しているサポートチケットシステム(例:Zendesk)が、ルーティングサービスにWebhookイベントを送信することでコードをトリガーし、その後意図を分類してルーティングします。
    • このアプローチはよりWebスケーラブルですが、パブリックエンドポイントを公開する必要があります。
  • プルベース: コードが指定されたスケジュールに基づいて最新のチケットを取得し、取得時にルーティングします。
    • このアプローチは実装が容易ですが、プル頻度が高すぎるとサポートチケットシステムへの不要な呼び出しが発生したり、プル頻度が低すぎると過度に遅くなったりする可能性があります。

これらのアプローチのいずれでも、スクリプトをサービスにラップする必要があります。アプローチの選択は、サポートチケットシステムが提供するAPIによって異なります。



分類クックブック


より多くのサンプルコードと詳細な評価ガイダンスについては、分類クックブックをご覧ください。


Claude Console

Claude Consoleでワークフローの構築と評価を開始しましょう。

Was this page helpful?

  • チケットルーティングにClaudeを使用するかどうかを判断する
  • LLMサポートワークフローの構築とデプロイ
  • 現在のサポートアプローチを理解する
  • ユーザー意図カテゴリを定義する
  • 成功基準を確立する
  • 適切なClaudeモデルを選択する
  • 強力なプロンプトを構築する
  • プロンプトをデプロイする
  • プロンプトを評価する
  • 評価関数を構築する
  • 評価を実行する
  • パフォーマンスを改善する
  • 20以上の意図カテゴリがある場合は分類階層を使用する
  • ベクターデータベースと類似性検索を使用して、非常に多様なチケットを処理する
  • 予想されるエッジケースに特に対応する
  • Claudeをより大きなサポートワークフローに統合する