チケット解決率、節約額、応答時間に関する目を引く主張は、特定のベンダー事例を表している場合があります。しかし、自社のキューでどこまで自動化できるかを示すものではありません。結果は、対象範囲、ポリシー、知識の品質、ツールへのアクセス、エスカレーション、「解決」の測定方法によって決まります。
「一般的なSaaSのサポートキュー」に当てはまる、根拠ある一律の自動化率はありません。パスワードのリセット、請求への異議、障害、製品の不具合では、処理できる範囲が異なり、ベンダーごとに「解決」の数え方も違います。エージェントは、自信のある文章でも、根拠のない回答やポリシーに違反する回答を生成する場合があります。目を引く割合より、アーキテクチャと測定設計が重要です。
この記事では、自社キューからラベル付けした標本に対して試すための参照設計を示します。分類、期間、しきい値、プロンプト、ワークフローの各段階は例であり、標準設定や性能の主張ではありません。自社のポリシー、セキュリティレビュー、評価基準に合格した部分だけを採用してください。
サポートエージェントの4つの仕事
実用的なAIサポートエージェントは、次の4つを順番に行います。
- チケットを理解する。 顧客が実際に尋ねていることは何か。どのような感情を抱いているか。問題はどのカテゴリーに属するか。
- 適切な背景情報を検索する。 顧客のアカウント、これまでの対応履歴、関連ドキュメント、類似する解決済みチケットを調べます。
- 何をするか決める。 回答する、確認の質問をする、人に振り分ける、アカウントに対してアクションを実行する、のいずれかを決めます。
- 承認された判断を実行する。 返信の送信、質問、エスカレーション、または承認済みのアカウント操作を行い、運用と監査に必要な根拠、認可、結果を記録します。
サポートエージェントの失敗の多くは、背景情報の不足や不明確な振り分けに起因します。ただし、モデルの能力と評価も重要です。システム全体として扱ってください。
アーキテクチャ
参照ワークフローの一例は次のとおりです。
受信チケット
↓
[選別エージェント：分類、優先順位付け、振り分け]
↓
[背景情報の収集：顧客データ、履歴、ナレッジベースのRAG]
↓
[判断エージェント：返信またはアクションを提案]
↓
[ポリシーゲート：認可、確認、拒否、または振り分け]
↓
[返信作成／制御されたアクション実行]
↓
[返信品質の確認、送信、またはエスカレーション]
各枠は責務を表し、必要なモデルやサービスの数を定めるものではありません。認可の境界をモデルの外に保つ限り、n8n、エージェントフレームワーク、自社サービス内で統合または分割できます。この流れは、顧客サービスの振り分けを例に含むAnthropicによる効果的なエージェント構築ガイドのroutingパターンに似ていますが、プラットフォームを問わず成果を保証するものではありません。
各ステップを順番に見ていきましょう。
ステップ1：選別
選別エージェントは、受信した未加工のチケットを受け取って分類します。
次は選別プロンプトの一例です。自社キューに合わせてラベルとしきい値を調整し、実際のチケットを振り分ける前に分類ごとの偽陽性と偽陰性をテストしてください。
あなたは[Company]のカスタマーサポート選別エージェントです。受信した各チケットを次の3つの観点で分類してください。
1. CATEGORY：次のいずれか
- account_access（ログイン、パスワード、MFA、アカウントのロック）
- billing（請求、返金、プラン変更、請求書）
- product_question（操作方法、機能に関する質問、設定）
- bug_report（故障または想定外の動作）
- feature_request（当社にない機能の要望）
- complaint（具体的な技術的問題ではなく、不満を抱いている顧客）
- other
2. URGENCY："critical"（本番環境の停止、請求に関する異議）、"normal"、"low"（情報提供のみ）のいずれか。
3. EMOTIONAL_TONE："calm"、"frustrated"、"very_angry"のいずれか。率直に判断すること。
`category`、`urgency`、`emotional_tone`、`confidence`、`needs_review`を含むJSONを出力する。根拠が不足している場合、または結果がそのカテゴリーで検証済みのしきい値を満たさない場合は、`needs_review`をtrueにする。
分類と振り分けの評価に合格するモデルのうち、最も低コストで低遅延のものを選別に使います。曖昧な問い合わせや多言語のキューでは、より高性能なモデルが必要になる場合もあります。固定したモデル名ではなく、実測した誤りから判断してください。
選別の出力は、次の二つのポリシー判断に利用できます。
- あるポリシーでは、緊急度が高いチケットや非常に怒っている顧客のチケットを人へ直接送ります。別のキューでは異なる指標を使うか、決定論的なインシデント規則を求める場合があります。
- カテゴリーによって、後続処理で利用できる情報源やツールを制限できます。ただし、カテゴリー自体が権限を与えてはいけません。
ステップ2：背景情報の収集
背景情報の品質は、サポート品質を左右する大きな変数です。関連性があり、利用を認可された根拠がなければ、モデルは不足部分を裏付けのない推測で埋める可能性があります。
取得すべき背景情報源は3つあります。
顧客データ。 この顧客は誰か。プラン、アカウントの利用期間、最近の活動、支払い状況、未解決の問題を調べます。通常はAPI呼び出しを通じて、CRMまたは製品データベースから取得します。
会話履歴。 この顧客は以前に問い合わせたことがあるか。何について問い合わせ、どのように解決したか。「昨日伝えたばかりなのに」という失敗を避けます。
ナレッジベース。 ドキュメント、ヘルプセンターの記事、社内手順書です。検索には、フィルター、キーワード検索、dense retrieval、hybrid search、reranking、または製品固有の組み合わせを利用できます。方法と件数は「RAG」という一般名からではなく、検索評価に基づいて選びます。（個人用RAGの構築と本番環境のRAGも参照してください。）
次の期間と取得件数は説明用の仮置きです。自社キューの履歴、プライバシーと保持規則、待ち時間の予算、検索評価に基づいて設定してください。
チケット[content]をもとに、背景情報を収集してください。
1. メールアドレスで顧客を検索する。見つかった場合は、plan、account_age_days、recent_actions（過去7日間）、open_ticketsを取得する。
2. 顧客のチケット履歴（過去90日間）を検索する。直近のチケットを最大5件、その解決内容とともに取得する。
3. 関連記事をナレッジベースで検索する。セマンティック類似度の上位3件を取得する。記事のタイトル、要約、URLを含める。
4. 類似する問題について、データベース内の解決済みチケットを検索する。上位2件を解決内容とともに取得する。
1つの背景情報オブジェクトにまとめる。
このステップはエージェントが利用する根拠を提供しますが、網羅性と待ち時間は接続先システム、検索設計、検証済みのサービス水準目標によって異なります。レビュー担当者が当時利用可能だった根拠を再現できるよう、文書IDと版を記録してください。
プライバシー境界。 顧客の背景情報は権限管理されたデータであり、プロンプト作成の都合で自由に使えるものではありません。チケットに必要な項目だけを取得し、取得前にテナントと役割のアクセス権を適用し、秘密情報と不要な個人データをマスキングしてください。プロンプト、ツール結果、トレース、下書きには、承認済みの保持ルールを適用します。どのレコードを見る権限があるかをモデルに判断させてはいけません。
ステップ3：推論エージェント
次に、エージェントが対応案を提示します。以下は判断ポリシーの例であり、アクション実行の認可ではありません。固定された金額、確信度、感情のしきい値は、チケット分類と法域ごとに承認された値へ置き換えてください。
あなたは[Company]のカスタマーサポート担当者です。あなたの仕事は、顧客の問題を解決することです。
各チケットについて、次の処理を行ってください。
1. チケットと背景情報を注意深く読む。背景情報には、顧客のアカウント、当社との対応履歴、関連ドキュメントが含まれる。
2. 次のいずれかのアクションを決定する。
- RESOLVE：確信を持てる回答または解決策がある。返信案を作成する。
- CLARIFY：追加情報が必要。確認の質問案を作成する。
- ESCALATE：人による対応が必要。理由を説明する。
- ACT_AND_RESOLVE：アカウントに対するアクション（返金、パスワードのリセット、プラン変更など）を提案し、実行後に送る返信案を作成する。実行はしない。下流のポリシーゲートが実行可否を判断する。
3. 率直で、温かみがあり、有能な印象を与える口調を使う。顧客の言葉遣いに合わせる。決して見下した態度を取らない。謝罪は2回以上しない。「お待ちいただきありがとうございます」は決して使わない。
4. ドキュメントを引用するときは、該当する記事へリンクする。記憶から言い換えない。
5. 顧客が不満を抱いている場合は、そのことを簡潔かつ明確に受け止めてから、解決策へ進む。
6. 次の場合は必ずエスカレーションする。
- 顧客が人との会話を求めている。
- €100 / $100を超える金銭的な異議が関係している。
- そのカテゴリーで検証済みの確信度またはポリシーのしきい値を満たさない。
- 顧客の口調が怒っており、問題が単純な1ステップの解決ではない。
- セキュリティまたはプライバシーに関する懸念がある。
- 当社チームの人物に対する苦情が関係している。
7. 出力は次のJSON形式にする。
{
"action": "<resolve|clarify|escalate|act_and_resolve>",
"confidence": <0.0-1.0>,
"reasoning": "<brief explanation>",
"response_draft": "<the email body>",
"escalation_reason": "<if applicable>",
"action_to_take": "<if act_and_resolve, the specific action and arguments>"
}
これがエージェントの中心です。代表的なチケットについて、処理方針、回答品質、安全性、エスカレーションのしきい値を満たすモデルのうち、最も低コストのものを選んでください。モデル、プロンプト、ツール、キューが変わったら再評価します。この例のreasoning項目には、オペレーター向けの簡潔な根拠とポリシー上の理由を入れます。非公開の思考の連鎖でも、アクションが承認された証明でもありません。
ステップ4：アクションの実行
RESOLVEとCLARIFYでは、提案された返信を送信する前に、回答品質とポリシーの確認を通します。
ESCALATEでは、顧客のメッセージ、検索した根拠、関連するポリシー規則、試した手順、エスカレーション理由を添えて人のキューへ送ります。このオペレーター向け記録を、モデルの隠れた推論で置き換えないでください。
ACT_AND_RESOLVEでは、モデルがアクションを提案し、別の制御経路が実行可否を決めます。OWASPの過剰な自律性に関するガイダンスは、機能と権限の最小化、利用者のセキュリティコンテキストでの実行、下流での認可、影響の大きい操作への人による承認を推奨しています。これらをサポートワークフローに適用します。
- 最小権限の許可リスト。 狭く限定した操作だけを公開します。ポリシーでは例として€50までの返金を許可し、それを超える場合にレビューを求めることもできますが、実際の境界はこの記事やプロンプトではなく、承認済みポリシーから得ます。
- 本人確認と認可。 実行前に、認証済みの顧客、テナント、オペレーター、付与された範囲を特定します。各呼び出しで下流サービスがアクセスを強制します。モデルの分類や確信度はアクセス権を与えません。
- 検証済み引数。 スキーマでアクション名と引数を制限し、予期しない項目を拒否し、副作用の直前にアカウント、通貨、金額、送信先、ポリシーを再確認します。提供元がスキーマ制約付きツール呼び出しに対応している場合は有効にします。たとえばOpenAIの
strictfunction-calling modeはスキーマへの準拠を強制しますが、認可や事実の正しさは確立しません。 - 確認と承認。 リスク、ポリシー、法律、曖昧さに応じ、顧客の明示的な確認または人による承認を求めます。セキュリティに関わる回復は、一般的なリセット操作ではなく、検証済みの本人確認回復手順に従います。
- べき等性と並行処理。 各操作にidempotency keyを付け、再試行時の重複を防ぎ、古いアカウント状態や競合する更新を処理します。
- 可逆性と失敗処理。 段階的または元に戻せる操作を優先し、部分的失敗のロールバックまたは照合を定義し、不確実な結果を無条件に再試行せず人へ回します。
- セキュリティ制御。 モデルとは独立して、rate limit、ツールのtimeout、テナント分離、機密情報処理、不正利用監視を適用します。
- 監査記録。 リクエストID、実行者と顧客のID、秘匿化した入力、根拠IDと版、ポリシーと認可の結果、確認または承認者、正確なアクション引数、ツール結果、ロールバックまたはエラー状態を記録します。モデル生成の理由はレビューに役立つ場合がありますが、監査証跡ではありません。
ステップ5：品質確認
二つの異なる制御を使います。副作用の前に、決定論的なポリシーと認可の確認によって、提案されたアクションを拒否、承認、または振り分けます。これとは別に、モデルまたはルールに基づく回答レビューで、送信前に回答品質の問題を検出できます。このレビューは、誤検知率と見逃し率が分かっている評価済みの検出器として扱い、絶対的な裁定者や認可サービスとは考えません。
あなたは、AIが生成したカスタマーサポート返信の品質確認担当者です。
元のチケットと返信案をもとに、次の点を確認してください。
1. 返信は顧客の質問に実際に答えているか。
2. 提供された背景情報に基づいて正確か（創作された事実がないか）。
3. 口調は適切か（温かみがあり、率直で、見下した印象や過剰な謝罪がないか）。
4. リンク切れや誤ったリンクがないか。
5. 次の危険な兆候が含まれていないか。
- 提供できないものを約束している
- 当社に責任がないことを謝罪している
- 怒りや皮肉を感じさせる
- 社内用語を使っている
- 内部情報を開示している
出力：APPROVEまたはREVISE（具体的な修正案を添える）。
品質確認がAPPROVEを返し、ポリシー確認にも合格した場合は送信できます。REVISEの場合は、範囲を限定して修正したうえで再確認するか、人へ回します。失敗した検出器がループを作らないよう、自動修正には再試行上限を設けます。
この品質ゲートが費用に見合うかは、実測で判断します。処理方針を変えた頻度、不適切な返信を検出した数、適切な返信を誤って止めた数を記録し、追加の待ち時間とモデル呼び出しを測定結果が正当化する場合だけ維持してください。
ナレッジベースをテスト可能にする
ナレッジベースは、エージェント品質を左右する重要な要因の一つです。ヘルプセンターの情報が古い、矛盾している、または不完全であれば、エージェントは自信に満ちていても裏付けのない回答を作る可能性があります。
実践的な原則を示します。
導入前に監査する。 件数が多いチケットとリスクが高いチケットを抽出し、それぞれについてナレッジベースに正しい回答があるか検証します。不足を補い、矛盾を解消し、古い記事を更新します。自社キューの根拠が受け入れ基準を裏付けるまで、サンプルを広げてください。
選択した検索方法に合わせて構成する。 焦点を絞った節、明確な見出し、安定した識別子、明示的な適用条件は検索に役立ちますが、分割方法と記事の長さは実装上の選択です。代表的な質問で、必要な箇所とその適用範囲が検索されるかをテストしてください。
明示的な「してはいけないこと」のセクションを含める。 サポートチケットの多くは、顧客が行うべきでない操作について尋ねるものです。ナレッジベースの記事では、「Xをしようとしているなら、それを推奨しない理由と、代わりの方法」を明記する必要があります。
適用条件を表現する。 「無料プランのみ」「EUの顧客のみ」「iOSアプリのみ」といったメタデータはフィルターに使えます。検索層で制限を強制し、矛盾する資料や範囲外の資料が除かれることをテストしてください。
担当者と変更を契機にレビューする。 各知識領域に担当者を置き、リスクと変更頻度に適したレビュー間隔を設定します。製品、ポリシー、インシデント、規制が変わったら、影響する内容を再レビューしてください。
ポリシーと評価に基づいてエスカレーションを調整する
エスカレーションが広すぎればキューの負担が増え、狭すぎれば顧客やセキュリティに害を及ぼします。分類、影響、根拠の品質、顧客の選択、実測したエラー率に基づいて規則を定義します。開始時のポリシーには次を含められます。
人または専門キューへ送るもの：
- 人による対応を明示的に求めている
- しきい値を超える怒り（特にエージェントが一度不適切に応答した後）
- 実際の金銭に関する異議
- セキュリティまたはプライバシーに関する懸念
- 健康、安全、法律に関する影響
- 同じ問題について、同じ顧客から繰り返し届くチケット
- そのカテゴリーで検証済みの確信度またはポリシーのしきい値を満たさないケース
関連する評価に合格した後の自動化候補：
- ナレッジベースに明確な回答がある単純な質問
- アカウントの基本的な管理（パスワードのリセット、基本的なプロフィール変更）
- 状況の問い合わせ（「返金処理は完了しましたか？」）
- 機能要望（人によるサポートではなく、製品チームへ送る）
これは一律の一覧ではありません。パスワードのリセット、返金状況、アカウント変更は、ある製品では高リスクで、別の製品では日常的な処理になり得ます。自動化するのは、返信または操作がポリシーの範囲内にあり、呼び出し元の本人性と権限を確認し、ツールが狭く制限され、ケースがその分類で測定済みの受け入れ規則を満たす場合だけです。
中間領域では、エージェントの判断が重要です。次の点を確認できる計測機能を構築してください。エージェントがエスカレーションできたのにしなかった全ケースのうち、顧客から再度問い合わせがあった割合はどれくらいか。エージェントがエスカレーションした全ケースのうち、人が簡単に解決できたものはいくつあったか。
自社のキューから自動化目標を導く
ベンダーが示す解決率を目標にしないでください。自社の直近キューから代表的なサンプルを抽出し、たとえば次のように分類します。
- 単純で、明確に文書化された質問
- アカウントの背景情報または制御されたツールを必要とする質問
- 複雑なトラブルシューティング、感情的な状況、ポリシー上の判断
- 製品またはエンジニアリング部門が扱うべきバグ報告と機能要望
各分類について、実際のポリシーに従ってエージェントが正しい処理方針と回答を出せるかをテストします。受け入れ基準を満たした分類の合計が、最初の自動化上限です。ナレッジベース、ツール、ポリシーが変わったら再計算し、約束した割合に達するようラベルを逆算してはいけません。
顧客への結果を測定する
顧客が重視するものは、自社のキューで測定してください。候補となる一般的な指標は次のとおりです。
- 正しい解決に至るまでの時間
- 回答の正確性とポリシー準拠
- 再問い合わせ率、顧客の負担、満足度
- 自動化が失敗した際に人へ連絡できること
速度だけから顧客の好みを推測してはいけません。速くても誤った回答や、人への経路を隠すbotは、待ち時間を明示するキューより体験を悪化させる可能性があります。
利用できる人への経路がないまま自動対応を繰り返す状態は、予見可能な失敗です。再問い合わせと途中離脱を測定し、自動再試行に上限を設け、エスカレーション先を見つけやすくしてください。
具体的なパターン
個別対応が役立つ場合があります。 「Annaさん、Proプランをご利用で、2023年からお付き合いいただいていることを確認しました」は、「お客様、こんにちは」とは異なる印象を与えます。問題解決に役立つ、利用を許可された情報だけを使い、監視されていると感じさせる詳細は避けてください。
必要な場合は確認済みの待ち時間に言及する。 チケットシステムの時刻と実際のサービス水準ポリシーを使い、顧客が待った時間を推測したり、目標を逸脱したと暗示したりしないでください。
関連する詳細を確認する。 「企業名に特殊文字を含むレコードで、インポートが失敗するとお知らせいただきました」と伝えます。チケットを正確に反映する場合だけ使ってください。繰り返すだけでは、システムが理解した証拠にはなりません。
確認済みの次のステップで締めくくる。 「返金は[time]に[payment system]で受け付けられました。現在の決済期間は[verified policy or provider window]です」とします。モデルの返信案だけを根拠に、処理が成功したと述べたり、入金時期を作り上げたりしないでください。
理由なく謝罪しない。 何が起きたか分かる前に「ご不便をおかけして大変申し訳ございません」と言うと、不誠実に聞こえます。必要な場合に、具体的な内容について一度だけ謝罪してください。
実例
顧客から次のようなメッセージが届きます。
こんにちは。3日間ログインを試していますが、パスワードが間違っていると表示され続けます。2年間使ってきたパスワードなので、正しいはずです。ハッキングされたのではないかと思い始めています。
システムがアカウントと承認済みの回復経路を確認した後の、より安全な返信案は次のとおりです。
Annaさん、こんにちは。
3日間もログインできなければ、不安になるのは当然です。サポートが参照できるログイン記録には、複数回の失敗が残っています。ただし、その記録だけでは誰が試したのか、アカウントにアクセスされたのかは分かりません。私はパスワードも多要素認証の設定も変更していません。
当社の確認済みログインページにあるアカウント回復リンクをお使いください：[approved recovery URL]。リセットを完了する前に、回復手順で本人確認を行います。パスワード、ワンタイムコード、回復コード、リセットリンクをサポート担当者へ知らせないでください。
失敗した試行に心当たりがない、確認済みの回復手順を完了できない、または不明なセッションやアカウント変更がある場合は、このメールにご返信ください。アカウントセキュリティチームへ引き継ぎます。同チームの応答目標は[verified security-queue SLA]です。
— AI Expertサポート
この返信案は、観察した根拠と推測を区別し、侵害がなかったとは断言せず、回復先のメールアドレスを開示も選択もしていません。セキュリティへの引き継ぎと応答時間は明示的な仮置きです。最終版には、会社が確認したURL、本人確認手順、現在のサービス水準目標が必要です。
最初に構築するもの
解決率の目標は、この記事やベンダー事例ではなく、ラベル付けした基準データと試験導入の結果から設定します。モデルはシステムの一部にすぎません。重要な四つの要素は次のとおりです。
- ガバナンスと評価を備えたナレッジベース。
- 堅実な背景情報の収集（顧客データ、履歴、ナレッジベースの検索、類似する解決済みチケット）。
- 明確な判断基準とエスカレーションルールを備えた推論エージェント。
- 制御ゲート（認可、許可リスト、確認、回答確認、監査ログ）。
これらの制御は有用な試行を支えられますが、サポート品質の向上や人の作業量の削減を保証するものではありません。
まず、範囲が狭く元に戻せる試行から始めます。処理方針の正確性、根拠に基づく回答の正確性、ポリシー準拠、未認可アクションの試行、重複または失敗した操作、再問い合わせ率、正しい解決までの時間、顧客の負担、エスカレーションの適合率と再現率、誤検知で人のキューに加わる負荷を測定してください。集計値が危険な一部を隠さないよう、チケット分類、言語、必要に応じた顧客層、ツール操作ごとに結果を分けます。
試行後にも残るリスクがあります。検索で根拠を見落とす、または古い情報を返す、本人性の信号を誤る、ポリシーに不足がある、レビューが危険な返信案を見逃す、承認と実行の間に連携が失敗する、顧客が自動応答を誤解するといった可能性です。分かりやすい人への経路、インシデント時の停止制御、監視されたロールバックまたは照合手順を維持し、ポリシー、知識、ツール、評価の責任者を決めてください。測定された利点と残余リスクが次の分類への拡大を裏付ける場合だけ、範囲を広げます。
