【CCA Foundations対策 / Claude API編 #13】エスカレーションと反復改善——自律解決の判断設計
Anthropic Academyの「Agents and Workflows」コースおよびCCA Foundations試験ガイドをもとに解説しています。
エージェントを本番運用すると「なぜここでエスカレーションした？」「なぜここで止まらなかった？」という問題が必ず出てくる。今回は自律解決とエスカレーションの判断設計、そして出力品質を上げる反復改善パターンを整理する。
この記事でわかること：
- エスカレーションすべき唯一の確実な基準（ポリシーギャップ）
- エスカレーションしなくていいケースの判断
- declarativeルールよりfew-shot examplesが有効な理由
- evaluator-optimizerパターンによる自己評価
- 複数懸念事項を並列処理して統合する設計
エスカレーションの判断基準
エージェントが「escalate_to_human」を呼ぶタイミングを設計するとき、最も重要な原則は一つ。
エージェントが答えを作れない状況のみエスカレーションする。
確実にエスカレーションすべきケース：ポリシーギャップ
方針が存在しない、またはその場面をカバーしていない——これがエスカレーションの唯一の確実な基準。
例：
顧客が競合他社との価格マッチを要求してきた。
自社のポリシーには「自社サイトでの値下げから14日以内なら対応する」と書いてある。
競合との価格差については方針が存在しない。
→ エスカレーション。ポリシーが存在しないケースに答えを創作してはいけない。
エージェントはポリシーを解釈する存在ではなく、ポリシーに従う存在。方針が沈黙している問題は、人間の判断に委ねる。
エスカレーションしなくていいケース
これが設計で判断を誤りやすい部分。
矛盾する情報がある場合
顧客が「商品が届いていない」と言っているが、
配送追跡では3日前に署名で受け取ったと記録されている。
→ エスカレーション不要。
エージェントはトラッキング情報を顧客に提示できる。
感情的な摩擦を避けたいという理由はエスカレーション基準にならない。
複数の懸念事項が混在する場合
顧客が「返金と配送先住所の変更を同時にお願いしたい」と言っている。
→ エスカレーション不要。
懸念事項を分解して、それぞれに対応すればよい。
「複数あるから人間に任せる」は誤った判断。
顧客が気が変わるかもしれない場合
昨日出荷した商品のキャンセルを求めている。
「届いたら気が変わるかもしれない」
→ エスカレーション不要。
推測に基づくエスカレーションはアンチパターン。
現在の要求を処理すればよい。
エスカレーション基準の伝え方
「複雑なケースはエスカレーションしてください」というシステムプロンプトでは機能しない。
declarativeルールの限界：
# NG
- 複雑なリクエストはエスカレーションする
- ポリシーが不明確な場合はエスカレーションする
- 顧客が不満そうな場合はエスカレーションする
Claudeはルールを読んでも「このケースが複雑かどうか」の判断がつかない。境界が曖昧なルールは機能しない。
few-shot examplesが有効な理由：
# OK：境界ケースを例示する
例1：顧客が写真付きで破損品の交換を求めている
→ 自律解決。標準手順に従って交換処理する。
例2：顧客が競合他社の価格でマッチを求めている
→ エスカレーション。自社ポリシーは自社サイトの値下げのみカバー。
競合との価格差については方針が存在しない。
例3：注文が届いていないと言っているが追跡では配達済み
→ 自律解決。トラッキング情報を顧客に提示して確認を求める。
examplesは「どちらになるか曖昧なケース」に対して機能する。典型的なケースではなく、境界線上のケースを選ぶことがポイント。
📋 試験ガイドより
公式試験ガイドのIn-Scope Topicsに「Escalation decision-making: Explicit criteria, honoring customer preferences, policy gap identification」が明記されている。エスカレーション基準はdeclarativeルールではなくfew-shot examplesで伝える。ポリシーギャップ（方針が存在しないケース）が唯一の確実なエスカレーション基準であり、矛盾情報や複数懸念事項は自律解決できる。
evaluator-optimizer：出力前に自己評価させる
エージェントが回答を出す前に、別のClaudeインスタンス（または同じClaudeの追加ステップ）が品質を評価する。
# 1. 初回の回答を生成
draft_response = generate_draft(customer_request, context)
# 2. 評価ステップ
evaluation_prompt = f"""
以下の回答案を評価して：
顧客の問い合わせ：{customer_request}
回答案：{draft_response}
確認項目：
- すべての懸念事項に対応しているか
- 関連する背景情報（ポリシー・期限）が含まれているか
- 次のアクションが明確か
不足があれば具体的に指摘して。
"""
evaluation = claude.call(evaluation_prompt)
# 3. 不足があれば改善
if evaluation.has_gaps:
final_response = improve_draft(draft_response, evaluation.feedback)
else:
final_response = draft_response
このパターンをevaluator-optimizerと呼ぶ。#11のワークフロー設計でも触れたが、カスタマーサポートでは特に有効——ケースごとに必要な情報が異なり、一律のチェックリストでは対応できないため、Claudeに評価基準を判断させる。
大事な点：評価ステップは追加の確認を顧客に求めるのではなく、回答を顧客に送る前に内部で行う。顧客への余計なやり取りを増やさずに品質を上げる。
複数懸念事項の並列処理
顧客が1つのメッセージに複数の問題を含める場合（「返金して、かつ住所も変えたい」）、順番に処理すると：
- 共通する顧客情報（アカウント・注文）を複数回取得する無駄
- 処理が遅くなる
- 一方の問題が解決しても他方を忘れることがある
並列処理の設計：
# 懸念事項を分解
concerns = decompose_request(customer_message)
# → ["注文1234の返金", "注文5678の住所変更"]
# 共通コンテキストを一度取得
customer_context = get_customer(customer_id)
# 各懸念事項を並列で処理
results = await asyncio.gather(*[
handle_concern(concern, customer_context)
for concern in concerns
])
# 結果を統合して1つの回答を生成
final_response = synthesize_results(results)
懸念事項ごとに独立して処理し、最後に統合する。共通コンテキスト（顧客情報）は一度だけ取得して再利用する。ツール呼び出し回数が減り、レスポンスが速くなる。
よくある誤解まとめ
| 誤解 | 実際 |
|---|---|
| 複数の問題が来たらエスカレーションすべき | 分解して並列に処理すればよい。複数あることはエスカレーション理由にならない |
| 矛盾する情報があれば人間に任せる | エージェントがデータを提示して確認を求めればよい |
| エスカレーション基準はルールで書ける | 境界ケースの判断はfew-shot examplesでしか伝わらない |
| evaluator-optimizerは顧客に追加質問する | 内部の自己評価ステップ。顧客への余計なやり取りを増やさない |
| 感情的な摩擦を避けるためにエスカレーションする | エスカレーション基準は業務上の必要性に基づく。感情的理由は基準にならない |
設計の判断基準
| 場面 | やりがちな選択 | 正しい選択 | 判断の根拠 |
|---|---|---|---|
| エスカレーション基準を設定したい | 「複雑なケースはエスカレーション」とルールで書く | 境界線上のケースをfew-shot examplesで示す | Claudeは境界が曖昧なルールを正しく適用できない。例で示すほうが効果的 |
| ポリシーに書いていないケースが来た | エージェントが推測して回答する | escalate_to_humanを呼ぶ | ポリシーが存在しない問題に答えを創作してはいけない |
| 顧客が複数の問題を1メッセージで送ってきた | 1つずつ順番に解決する | 分解して並列に処理して統合する | 並列処理で共通情報の重複取得をなくし、処理を効率化できる |
| 回答の完全性にばらつきがある | 顧客に「他に何かありますか？」と確認する | evaluator-optimizerで送信前に自己評価する | 顧客の負担を増やさずに品質を上げられる |
まとめ
- エスカレーションの唯一の確実な基準はポリシーギャップ——方針が存在しないケース
- 矛盾情報・複数懸念事項・推測はエスカレーション理由にならない
- エスカレーション基準はdeclarativeルールではなく境界ケースのfew-shot examplesで伝える
- evaluator-optimizerは回答を顧客に送る前に内部で品質を評価するパターン
- 複数懸念事項は分解→並列処理→統合の設計で効率化する
次回（#14）はコンテキスト最適化とprovenance管理——マルチエージェントシステムの信頼性設計を解説する。