AIエージェントのエスカレーション判断はどう設計すればよいですか？

「顧客が明示的に人間を求めた」「ポリシーに定めがない例外ケース」「自律解決が見込めない状況」という3つの判断基準を明示的にシステムプロンプトに定義します。感情分析や自己信頼スコアはエスカレーション判断の基準として機能しません。

AIが対応できるのに顧客が人間を求めた場合はどうすべきですか？

AIが解決可能と判断しても、顧客が明示的に人間を求めた場合は即座にエスカレーションします。一度でも「自分で解決できます」と返してしまうと、顧客の不信感が高まります。

人間への引き継ぎ時に伝えるべき情報は何ですか？

顧客ID・問い合わせの根本原因・AIが試みた対応・推奨アクション・対応が必要な金額や期限といった情報を構造化して伝えます。担当者が会話履歴を最初から読まなくても即座に対応できる状態にします。

エスカレーション設計：AIが人間に引き継ぐタイミングと判断基準

結論

AIエージェントのエスカレーション判断は、感情分析や自己信頼スコアでは機能しません。「顧客が明示的に人間を求めた」「ポリシーで定められていない例外ケース」「自律的な前進が見込めない」という3つの明示的な判断基準を設計し、それ以外の場合は自律解決を試みるのが正しい設計です。

引き継ぎ時の構造化サマリーも重要です。担当者が最初から会話を読まずとも即座に対応できる情報を渡すことで、顧客の不満をさらに悪化させるリスクを防げます。

なぜエスカレーション設計が難しいのか

AIエージェントが顧客サポートを担う場合、最初のハードルは「いつ人間に引き継ぐか」の判断です。エスカレーションが多すぎると自動化の価値がなくなり、少なすぎると複雑なケースで顧客の不満が高まります。

実際によく観察される失敗パターンは、エスカレーションの判断基準が曖昧なケースです。例えば「難しいケースはエスカレーションする」という指示では、AIが「難しい」と判断できないことがあります。あるいは逆に、シンプルなケースでもエスカレーションして解決率が55%にとどまったり、本来エスカレーションすべき例外ケースを自律処理しようとして失敗したりします。

機能しない2つのアプローチ

アプローチ1: 感情分析によるエスカレーション

「顧客がネガティブな感情を示したらエスカレーション」という設計は直感的に見えますが、問題があります。

顧客の怒りと問題の複雑さは必ずしも一致しません。シンプルな返金を求めて強く怒っている顧客は、AIで簡単に解決できるかもしれません。一方、丁寧に問い合わせてくる顧客でも、ポリシーに定めのない例外対応が必要なケースは人間の判断が必要です。

感情でエスカレーション判断をすると、「感情が高ぶっているが簡単なケース」を不必要にエスカレーションし、「冷静だが複雑なケース」を自律処理しようとして失敗します。

アプローチ2: 自己申告の信頼スコア

「信頼度スコアが7以下ならエスカレーション」という設計も問題があります。AIが「自信がある」と申告するスコアは、実際の正確さとの相関が低いことが多いです。

特に問題になるのは、AIが「よくわからない複雑なケース」でも自信あるように見える信頼スコアを返すことがある点です。判断が難しいからこそスコアが信頼できない、という皮肉な状況が生まれます。

機能する3つのエスカレーション判断基準

基準1: 顧客が明示的に人間を求めたとき

「人間と話したい」「担当者につないでほしい」「スーパーバイザーを呼んでほしい」という明確な要求があった場合は、AIが解決できると判断しても即座にエスカレーションします。

一度「自分で対応できます」と返してしまうと、顧客の不信感が急速に高まります。「なぜ要望を聞いてくれないのか」という2次的な不満が生まれます。

ただし、実際に解決可能な問題を持つ顧客が感情的になって「人間を呼べ」と言った場合、次のような応答が有効です。

「担当者におつなぎすることもできますが、
 ご注文#45678の件でしたら、このまま私が返金処理をお手伝いできます。
 どちらがよろしいですか？」

解決策を提案しながら顧客の選択に委ねます。この後も顧客が「人間を呼んでほしい」と繰り返した場合は、迷わずエスカレーションします。

基準2: ポリシーの定めがない、または矛盾するケース

「競合他社の価格に合わせた値引き」「過去に遡った割引適用」「通常ルールの例外対応」のように、明確なポリシーが存在しない、またはポリシーが矛盾しているケースは人間の判断が必要です。

AIがポリシーの隙間を自律的に判断して対応すると、意図しない前例を作ってしまうリスクがあります。「AIが対応してくれた」という顧客の証言が他の顧客へのサービスにも影響する可能性があります。

基準3: 自律的な前進が見込めない状況

問い合わせに必要な情報が取得できない・必要なシステムがダウンしている・AIの権限範囲では対処できないという状況では、同じことを繰り返すのではなくエスカレーションします。

「できる限り頑張って対応しよう」とするほど、解決できないのに時間がかかって顧客を待たせる最悪の結果になります。

明示的な判断基準をプロンプトに定義する

エスカレーション判断の精度を上げるには、システムプロンプトに具体的な基準を書きます。抽象的な指示ではなく、判断事例を含めることが重要です。

## エスカレーション基準

次の場合は即座にescalate_to_human()を呼ぶ:
1. 顧客が「担当者」「スーパーバイザー」「人間」と明示的に要求したとき
2. 競合価格マッチング・通常期間外の返品など、標準ポリシーに定めがないとき
3. 3回以上試みても問題が解決しないとき

次の場合は自律処理を続ける:
- 感情的な言葉があっても、標準ポリシーで対応できるとき（まず解決策を提案）
- 複数の問題が混在していても、それぞれがポリシー内で対処できるとき

エスカレーション不要の例:
- 「なんで届かないんだ！」→ 注文を確認して配送状況を説明する
- 「もう解約したい」→ アカウント解約を標準フローで処理する

エスカレーション必要の例:
- 「あなたでは話にならない、上の人を出して」→ 即座に引き継ぐ
- 「Amazonより高かったから差額を返してほしい」→ 競合価格マッチングポリシーがないため引き継ぐ

この形式で書くことで、Claudeが新しいケースを見たときに「これは既定の事例と同じカテゴリか」を判断できるようになります。

複数顧客が一致する場合の設計

顧客情報を検索したときに複数の顧客がヒットした場合、AIが独自の判断でどちらかを選んではいけません。

「鈴木さんからの問い合わせ」で鈴木一郎・鈴木二郎の2名がヒットした場合、AIが「どちらか確率が高そうな方」を選んで対応してしまうと、間違った顧客の注文情報を参照・変更するリスクがあります。

正しい設計は、追加情報を求めることです。

「鈴木様のアカウントが2件見つかりました。
 確認のため、ご登録のメールアドレスまたは電話番号の下4桁を教えてください。」

感情分析やヒューリスティックで「こちらの鈴木さんの方が確率が高そう」という推測に基づく選択はしません。

構造化引き継ぎプロトコル

エスカレーション時に最も重要なのが、担当者への引き継ぎの質です。担当者がゼロから会話を読み直す必要があると、顧客を再び待たせてしまいます。

推奨する構造化引き継ぎ形式：

[エスカレーションサマリー]
顧客ID: CUS-23456
顧客名: 田中健太
問い合わせチャネル: チャット（2026-06-05 14:23開始）

■ 問題の概要
注文#45678（2026-05-28、4,800円）が6月5日時点で未着。
配送業者の追跡では「配達完了」になっているが、顧客は受け取っていない。

■ AIが試みた対応
1. 配送ステータス確認 → 「配達完了」（5/31 16:42）
2. 配送業者に調査依頼 → 調査中ステータスを確認
3. 再配送の提案 → 顧客は「現金返金を希望」と要求

■ エスカレーション理由
「人間の担当者と話したい」と明示的に要求あり

■ 推奨アクション
返金処理（4,800円）を承認するか、調査完了（最大5営業日）まで待つかを判断してください。
顧客は強い返金希望を示しています。

■ 顧客の感情状態
最初から冷静。問題が解決しないことへの落胆が徐々に見られる。

この形式を標準化することで、担当者は30秒で状況を把握して即座に対応できます。

信頼度スコアを活用した段階的レビュー

全てのケースを人間がレビューするリソースはありません。限られたリソースを効率的に使うには、AIがフィールドごとの信頼度スコアを出力し、低スコアのケースだけを人間が確認する設計が有効です。

{
  "refund_amount": { "value": 4800, "confidence": 0.99, "source": "order_lookup_result" },
  "root_cause": { "value": "配送業者の配達確認が誤り", "confidence": 0.72, "source": "customer_statement_only" },
  "recommended_action": { "value": "full_refund", "confidence": 0.68, "review_recommended": true }
}

confidenceが0.85以下のフィールド・review_recommended: trueのケースを優先的にレビューキューに入れます。全体の97%が高信頼度で自動処理でき、3%が人間レビューに回ったとしても、その3%の中にリスクの高いケースが集中しているはずです。

ただし、「全体97%の精度」という集計値には注意が必要です。文書タイプAでは99%・文書タイプBでは70%という内訳がある場合、集計値は良く見えても特定領域での失敗が隠れています。精度はケースの種類ごとに計測します。

エスカレーションから学ぶ改善サイクル

エスカレーションのパターンを記録・分析することで、AIの自律解決範囲を広げられます。

エスカレーション理由の記録

エスカレーション記録:
- 日時: 2026-06-05 14:45
- エスカレーション理由: policy_gap（競合価格マッチング）
- 担当者の対応: 承認（1,200円の差額を返金）
- 解決時間: 8分

この記録を集計すると「競合価格マッチングが月に30件発生」のようなパターンが見えます。このパターンが多い場合、競合価格マッチングのポリシーを新設してAIが自律対応できるようにする判断材料になります。

エスカレーション分析で分かること：

どのポリシーの穴が頻繁に問題になるか
AIが誤ってエスカレーションしている「実は簡単なケース」
人間が対応するより価値の高い「高複雑度ケース」の特徴

まとめ

エスカレーション設計の実践ポイントをまとめます。

判断基準は「顧客が明示要求・ポリシー外ケース・前進不可能」の3つを明文化する
感情分析・自己申告信頼スコアをエスカレーション判断に使わない
顧客が人間を求めたら即座に引き継ぐ（AIが解決できると思っても例外なし）
複数顧客ヒット時は推測で選ばず追加情報を求める
引き継ぎには構造化サマリーを用意して担当者の時間を節約する
フィールドごとの信頼度スコアで人間レビューが必要なケースを絞り込む
エスカレーションパターンを記録してAIの対応範囲を広げる材料にする

この設計を整えることで、「人間が必要なケースを確実に人間へ、AIで解決できるケースは自律処理する」という最適な分担が実現できます。エージェントの自律実行設計についてはClaudeエージェントループ入門、複数エージェントの協調設計はマルチエージェント設計の実践パターンで詳しく解説しています。