エスカレーションと曖昧さ解消

Claude Certified Architect — Foundations（CCA-F）試験のタスクステートメント5.2「効果的なエスカレーションと曖昧さ解消パターンの設計」は、Domain 5（Context Management & Reliability、試験配点15%）に位置するが、agentic loopを通じてほかのすべてのドメインにも影響を及ぼす。Domain 5は5つのドメインの中で最も配点が低いにもかかわらず、コミュニティの合格レポートではタスク5.2が繰り返し取り上げられる。実力のある受験者でさえ、エスカレーションを失敗と混同したり、リスクの高いシナリオで明確化の代わりに推測を選んだり、人間のレビュアーが実際に必要とするコンテキストを省いたエスカレーションペイロードを設計したりして、2〜3問を落とすことが多いと報告されている。カスタマーサポート解決エージェントのシナリオはこのタスクステートメントを最も厳しく試す。そこでは「尋ねる」「推測して印をつける」「グレースフルに降格する」「エスカレーションする」の4択から、記述されたステークスと信頼状態に照らして唯一の正解を選ぶ問題が繰り返し出題される。

この学習ノートでは、CCA-Fが要求する設計面の全体を順に解説する。タスク仕様が不十分であることを検出する方法、ターゲットを絞った明確化リクエストの形（単一質問型対バッチ型）、実行前に尋ねるか仮定を述べながら試みるかの判断、人間へのエスカレーションの標準的な発動条件、人間のレビューを効率的にするエスカレーションペイロードの組み立て方、階層ルーティングの仕組み（担当者→マネージャー→システムオーナー）、明示的な不確実性フラグを伴うグレースフルデグラデーション出力の生成、人間が明確化を提供した後のエージェント実行再開、マルチエージェントシステムにおける曖昧さの所有権、過剰エスカレーションを避けるための閾値調整、そして同じ曖昧さが二度エスカレーションされないよう CLAUDE.md に解決策をフィードバックする方法。よくある罠、カスタマーサポート解決エージェントシナリオに紐づいた練習アンカー、6問のFAQが締めくくる。

エスカレーションと曖昧さ解消がプロンプト問題ではなくアーキテクチャ問題である理由

タスク5.2を「不確かなときは明確化するよう Claude に指示する」という観点で捉えた受験者は、CCA-Fで一貫して誤答を選ぶ傾向がある。試験では、エスカレーションを4つの具体的な面を持つアーキテクチャ機能として扱う。曖昧さの存在を判定する検出メカニズム、明確化と人間へのルーティングを選択するリクエスト・エスカレーション決定ポリシー、人間のレビュアーが消費するペイロード形状、そして新しい情報でエージェント実行を再開する再開プロトコルだ。4つの面はすべてプログラム的なものである。スキーマが強制されたツール呼び出し、構造化されたエラー応答、人間による一時停止をまたいで持続するセッション状態、設定ファイルに書き戻されるルール更新がそれにあたる。プロンプトレベルの指示（「不確かなら尋ねる」）だけでは、これらの面を確実に実現することはできない。

コミュニティの痛点pp-01——プログラム的強制対プロンプトベースのガイダンス——はここに直接当てはまる。CCA-Fの選択肢で「明確化するよう Claude に指示する強化版システムプロンプトを追加する」と、「エージェントがリスクの高いアクションの前に必ず呼び出す構造化スキーマを持つ request_clarification ツールを定義する」が対になっているとき、構造化ツールの答えがほぼ常に正解である。試験が評価するのは、エスカレーションの経路をアーキテクチャ上の第一級オブジェクトとして設計しているかどうかであって、モデルが正しいことをしてくれるという期待ではない。

曖昧さの検出——タスク仕様が不十分な場合の特定

最初のアーキテクチャ面は検出である。エージェントが質問するかエスカレーションするかの前に、指定されたタスクが許容できる信頼度で実行不可能であることに気づかなければならない。CCA-Fでは、曖昧さの検出を「何かがおかしいとモデルが感じる」という漠然としたものではなく、具体的なシグナルの集合として扱う。

曖昧さ処理を発動すべき6つのシグナル

1. 参照対象の欠如 — タスクが「ユーザー」「アカウント」「レポート」に言及しているが、複数の候補が存在し、コンテキストから正しいものを特定できない。
2. 閾値の未定義 — タスクが「最近の注文」や「高額顧客」を要求しているが、数値カットオフが定義されておらず、そのカットオフが結果を大きく変える。
3. 制約の競合 — 会話、システムプロンプト、または CLAUDE.md 内の2つの指示が現在のケースで互いに矛盾している。
4. 範囲外のリクエスト — ユーザーがエージェントのツール許可リストでは実行できない何かを要求しているか、エージェントのシステムプロンプトに記載されたスコープ外のリクエストをしている。
5. 分類の信頼度が閾値以下 — ツールベースの分類器が設定された信頼度閾値以下のスコアを返した。
6. 新規エッジケース — 現在のケースが提供されたfew-shotの例やrunbookのパターンに一致せず、エージェントが外挿していることを示唆している。

各シグナルは個別のアーキテクチャ的応答にマップされる。参照対象の欠如と閾値の未定義は明確化リクエストで解決される。範囲外のリクエストはグレースフルデグラデーション＋エスカレーションで解決される。信頼度低下シグナルは、ステークスに応じて明確化かエスカレーションかを発動する。新規エッジケースは詳細なペイロードとともにエスカレーションされることが多く、その解決が後日 CLAUDE.md のルールになる。

検出はツール呼び出しであり、直感ではない

最もクリーンなアーキテクチャは、エージェントに構造化された evaluate_task_completeness ツール（または等価の名前のツール）を与えることだ。このツールは ok、missing_field、ambiguous_reference、out_of_scope、low_confidence と、オプションの details オブジェクトを持つ型付きの判定を返す。agentic loopはその判定に基づいて分岐する。ok は続行、missing_field か ambiguous_reference は明確化リクエストを発動、out_of_scope は即座のエスカレーションを発動、low_confidence はステークステーブルを参照してから決定する。

明確化リクエストの設計——ターゲットを絞った単一質問対バッチ質問

エージェントが明確化が必要と判断したら、次の設計上の決定は形状である。1回ずつターゲットを絞った1つの質問をするか、1回のラウンドトリップでいくつかをまとめてバッチにするかだ。CCA-Fはこのトレードオフを直接テストする。

単一質問の明確化——優先すべき場合

単一質問の明確化が適切な形状なのは次の場合だ。

• 最初の質問の答えが、必要なフォローアップ質問を大きく変える場合。
• ユーザーが会話チャンネル（チャット、音声）にいて、長い質問票が尋問的に感じられる場合。
• タスクが段階的に進められる——各回答済みの質問が次の計画されたステップを解放する場合。

単一質問の明確化のコストは会話のラウンドトリップだ。利点は、前の答えによってすでに無関係になった質問を決して尋ねないことだ。

バッチ明確化——優先すべき場合

バッチ明確化が適切な形状なのは次の場合だ。

• ユーザーが1回で構造化されたフォームに答えられる技術的オペレーター（APIクライアント、チケット提出者）の場合。
• 質問が独立している——ある答えが別の質問を無効にしない場合。
• タスクのコンテキストコストが繰り返し再開で高い場合（例：セットアップが高コストな長い調査タスク）。

バッチ明確化は通常、各質問にフィールド名でタグが付けられたJSONフォームか番号付きのyes/no/短答質問リストとして表示される。これにより、エージェントは答えをプログラム的にマップできる。

ハイブリッドパターン

実際には、本番エージェントは交互に使い分ける。チャットチャンネルで動作するカスタマーサポートエージェントは1回に1つの質問をする。同じエージェントが非同期メールチケットを処理するときは、単一の統合質問票を送って応答を待つ。選択はエージェントのチャンネル認識によって制御され、グローバルな優先設定によるものではない。

明確化のタイミング——実行前に尋ねるか、仮定を述べながら試みるか

形状よりも微妙な設計上の選択がタイミングだ。エージェントはアクションを試みる前に明確化を求めるべきか、それとも述べた仮定とともに進み、その仮定を答えの一部として表面化すべきか。

実行前に尋ねる——ステークスが高い場合

次の場合は実行前に尋ねる。

• アクションが破壊的または不可逆的な場合（アカウント削除、返金発行、コンテンツ公開、main へのマージ）。
• アクションが外部への影響を持つ場合（顧客へのメール送信、カードへの課金、有料サードパーティAPIの呼び出し）。
• アクションがコンプライアンスに縛られている場合（GDPRデータ削除、HIPAA管理の開示、金融規制）。

これらのケースでは、未確認の仮定で進めて後から修正することは有効な回復策ではない——メールを「未送信」にしたり、カードを「未課金」にしたりはできない。明確化のための一時停止は安価で、ミスは高コストだ。

仮定を述べながら試みる——ステークスが低く、元に戻しやすい場合

次の場合は仮定を述べながら試みる。

• アクションが読み取り専用の場合（レコードの検索、ドキュメントの取得、ドラフトの生成）。
• 出力が権限を持つものになる前に人間がレビューするドラフトの場合。
• 明確化を待つことが全体のレイテンシを支配し、ユーザーが明示的に速度を重視する場合（例：キー入力中の開発者生産性エージェント）。

このモードでは、エージェントはベストエフォートの出力を生成し、仮定に印をつけるか注釈を付ける（「『先月』は前の暦月を意味すると仮定した。直近30日間を意図していた場合はご確認ください」）。人間は受け入れるかリダイレクトするかを選べる。

ステークス×可逆性マトリクス

2つの次元を組み合わせると、ポリシーが明確になる。

• 高ステークス、低可逆性 → 常に実行前に尋ねる。例外なし。
• 高ステークス、高可逆性 → 初回操作は実行前に尋ねる。パターンが既知の繰り返し操作はフラグ付きの仮定で進める。
• 低ステークス、低可逆性 → 実行前に尋ねる（希な組み合わせ。存在する場合、可逆性が支配する制約）。
• 低ステークス、高可逆性 → 述べた仮定で進める。

エスカレーション発動条件——信頼度閾値以下、権限の欠如、新規エッジケース

エスカレーション——明確化とは異なり——は人間（またはより権限の高いエージェント）への制御の移転だ。CCA-Fでは3つの標準的な発動条件を認識することが求められる。

発動条件1：信頼度が閾値以下

エージェントまたは基盤となる分類器が、現在のアクションのステークス向けに設定された閾値以下の信頼度スコアを返した。返金処理エージェントは「この返金はポリシーに準拠しているか」に対して0.95の信頼度を必要とするかもしれない。それ以下は人間の返金担当者へのエスカレーションを発動する。閾値はステークスに比例してスケールされる——リスクの高いアクションほど、エージェントが自律的に進む前に高い信頼度を要求する。

発動条件2：権限の欠如

エージェントが要求されたアクションを実行するためのツール、パーミッション、またはロールを持っていない。読み取り専用CRMアクセスを持つサポートエージェントは請求先住所を更新できない。正しい応答は拒否でも偽装でも回避策でもなく、その権限を持つエージェント（人間またはそれ以外）へのエスカレーションだ。ツール許可リストが必要なアクションを除外しているシナリオでは、権限欠如によるエスカレーションがほぼ常に正解だ。

発動条件3：新規エッジケース

ケースが既知のrunbook、CLAUDE.md のルール、またはfew-shotの例に一致しない。エージェントの選択肢は（a）外挿して祈る、（b）詳細なペイロードとともにエスカレーションして人間が解決し文書化できるようにする。CCA-Fは一貫して（b）を選ぶ。新規ケースは最も価値の高いエスカレーションだ。なぜなら、その解決が翌日のルールになるからだ。

第4の暗黙の発動条件：明示的なユーザーリクエスト

ユーザーが「人間と話したい」と言ったとき、エージェントはエスカレーションしなければならない。これはアーキテクチャ上の選択というよりも、コンプライアンスの下限だ。

エスカレーションペイロードの設計——効果的な人間レビューに含めるコンテキスト

エスカレーションは、受け取る側の人間が迅速に行動できる場合にのみ有用だ。人間がゼロから事例を再調査することを強いるペイロードは、自律エージェントのそれまでの作業のほとんどの価値を破壊する。CCA-Fでは、エスカレーションペイロードを構造化された自己完結型の引き継ぎとして設計することが求められる。

最小限の有効なエスカレーションペイロード

すべてのエスカレーションペイロードに含めるべきものは次のとおりだ。

1. ケース識別子 — チケットID、セッションID、ユーザーID。レビュアーが関連レコードを取得できるもの。
2. タスクサマリー — ユーザーが何を求めたかを平易な言葉で1〜3文で述べたもの。
3. エージェントの現在の仮説 — エージェントが正しいアクションだと信じているもの（信頼度スコア付き）。
4. 曖昧さまたは発動理由 — エスカレーションを引き起こした具体的なシグナル（どのフィールドが欠けているか、どの権限が欠けているか、どの閾値を下回ったか）。
5. 証拠 — 決定に関連するツール結果、ドキュメント、または過去の会話のサブセット。フィルタリングされていない全履歴は含めない。
6. 提案されたオプション — レビュアーがワンクリックで承認できる2〜3の具体的なアクション。
7. 可逆性に関する注記 — 各提案オプションが可逆かどうか、および影響範囲。

項目1〜5のいずれかが欠けているペイロードは、人間のレビュアーに再作業を強いる。項目6と7は、30秒のトリアージと10分の調査との差だ。

引き継ぎ後もプロベナンスを保持すること

ペイロード内のすべての事実にプロベナンスタグを付けるべきだ——どのツールが生成したか、どのドキュメントから来たか、いつ観察されたか。レビュアーは「ClaudeがCRMからこれを伝えられた」と「Claudeがサポートスレッドからこれを推論した」を区別できなければならない。エスカレーション中のプロベナンスの喪失は、人間レビュアーが不良なエージェントの決定をゴム印押ししてしまうという根本原因だ。

エスカレーション経路ルーティング——階層エスカレーション（担当者→マネージャー→システムオーナー）

すべてのエスカレーションが同じ人間に行くわけではない。CCA-Fでは、エスカレーションの性質を適切なレビュアーに合わせる階層ルーティングを設計することが求められる。

Tier 1：ドメイン担当者

ルーティンの曖昧さに対する一次レビュアー——サポート担当者、オンコールエンジニア、請求アナリスト。担当者はほとんどのケースを解決するためのドメインコンテキストを持ち、行動する権限がある（返金の発行、マージの承認、レコードの修正）。発動条件が信頼度閾値以下か欠落フィールドによる曖昧さの場合、エージェントはデフォルトでここにルーティングすべきだ。

Tier 2：チームリードまたはマネージャー

担当者が解決できないケースに対する二次レビュアー。リードは広い権限を持つ（より大きな返金上限、クロスチームの調整、ポリシー解釈）。エージェントは通常ここに直接ルーティングしない——担当者が一次レビューで解決できない後、担当者がエスカレーションする。

Tier 3：システムオーナーまたはエンジニアリング

ケース固有の問題ではなく、エージェント自体の欠陥を露呈する問題に対する三次レビュアー——一貫性のないデータを返すツール、矛盾を生む CLAUDE.md のルール、誤って調整された信頼度閾値。エージェントは、短い期間に同じパターンで繰り返し新規エッジケースのエスカレーションが発生したとき、自動的にここにルーティングすべきだ——パターン自体が問題であり、個々のケースではない。

ルーティングメタデータ

設計の優れたエスカレーションシステムは、すべてのペイロードに tier とspecificキューをタグ付けする。ルーティングはエージェントが付加するメタデータに基づいて、発動理由、ステークス、負荷の関数であり、ルーティングサービスがそのメタデータに基づいてどの人間キューがケースを受け取るかを決定する。

グレースフルデグラデーション——明示的な不確実性フラグを伴う部分的出力の生成

「自律的に解決する」と「完全にエスカレーションする」の間には中間の道がある。エージェントが確信している出力部分を生成し、不確実な部分に明示的なフラグを立て、下流のコンシューマーが進み方を決定できるようにすることだ。CCA-Fではこれをgraceful degradationと呼ぶ。

グレースフルデグラデーションが正しい選択の場合

• タスクに複数のサブコンポーネントがあり、一部だけが曖昧さによってブロックされている場合。
• ユーザーが部分的な出力を処理できる技術的コンシューマー（パイプラインのステップ、APIクライアント）の場合。
• 完全な解決を待つと下流コンシューマーが何も処理できなくなる場合。

5つのサブ質問のうち4つに自信を持って答え、5つ目について不確かな調査エージェントは、4つの確信ある回答を引用とともに発行し、5つ目に対して {answer: null, reason: "insufficient_evidence", trigger_escalation: true} を返すべきだ——4つの確信ある答えを廃棄したり、5つ目が解決するまでブロックしたりしてはならない。

不確実性フラグの形状

出力の不確実な各コンポーネントには以下を含めるべきだ。

• でっち上げた尤もらしい答えの代わりに、明示的な null またはセンチネル値。
• reason フィールド（insufficient_evidence、ambiguous_reference、out_of_scope、confidence_below_threshold）。
• エージェントが少数の候補に絞り込んだが曖昧さを解消できない場合のオプションの candidates リスト。
• suggested_action フィールド（request_clarification、escalate_to_specialist、retry_with_context）。

構造化された不確実性は、下流コンシューマーが正しく分岐するために必要なシグナルだ。「たぶん正しいと思うが確信はない」のような散文的な修飾語は自動化パイプラインに組み込めない。

グレースフルデグラデーションはエスカレーションの代替ではない

グレースフルデグラデーションはエージェントが確信している出力を処理する。不確実な部分はまだエスカレーションまたは明確化を必要とする。構造化された null を発行して立ち去ることは、デグラデーションではなく放棄だ——フラグは最終的に解決するための経路と対になっていなければならない。

エスカレーション後の再開——人間が提供した明確化でエージェント実行を再開する

クリーンに再開できないエスカレーションは、ユーザーにタスクを最初からやり直すことを強いり、エスカレーション前の自律的な作業の価値を破壊する。CCA-Fでは、再開を第一級のステートマシン遷移として設計することが求められる。再起動ではない。

クリーンな再開の4つのコンポーネント

1. セッション永続性 — エスカレーションが発動したとき、エージェントのセッション状態（メッセージ履歴、ツール結果、部分的なプラン）を保存しなければならない。Agent SDKのセッションAPIがこれを処理する。保存を忘れることは正確性のバグだ。
2. 明確化のバインディング — 人間が提供した答えは、単に新しいユーザーメッセージとして追加するのではなく、上流で提供されたかのようにセッションにバインドしなければならない。構造化された resolution ペイロードが答えを一時停止を引き起こした特定のフィールドにマップバックする。
3. ガードレールの再評価 — 明確化が適用された後、エージェントは曖昧さ検出ステップを再実行しなければならない。明確化が元のトリガーを解消したが新しいトリガーをもたらした場合、エージェントは突き進まず再び一時停止しなければならない。
4. 監査証跡 — 再開レコードには、誰が、いつ、どのように曖昧さを解消したかを含めなければならない。これは高ステークスのアクションに対するコンプライアンスに必要であり、CLAUDE.md を更新するフィードバックループを支える。

フォークと再開

セッションフォーキングにより、エスカレーション前のチェックポイントから再開しながら、エスカレーションレコードをそのまま保持できる——人間が元のコンテキストを失わずに別の解決策を探したい場合に有用だ。フォーキングはタスク1.7のトピックだが、その再開での使用はタスク5.2に属する。

マルチエージェントシステムにおける曖昧さ解消——どのエージェントが明確化を所有するか

コーディネーター-subagentシステムでは、曖昧さはどのレベルでも浮上する可能性がある——subagentのタスク内、コーディネーターの分解ステップ、またはユーザー向けレイヤーで。CCA-Fでは、どのエージェントが明確化を所有するかを知ることが求められる。

ルール1：subagentはコーディネーターにエスカレーションし、ユーザーに直接はしない

自分に割り当てられたサブタスク中に曖昧さに遭遇したsubagentは、エンドユーザーに直接メッセージを送るのではなく、構造化されたエスカレーションをコーディネーターに返す。コーディネーターはタスクの全コンテキストを持っている。subagentは自分のスライスしか持っていない。ユーザー向けコミュニケーションはコーディネーターの責任だ。この境界は、subagentのコンテキスト分離（コミュニティ痛点pp-03）の直接的な結果だ——subagentはユーザーが元々何を求めたかを理解していると仮定できない。

ルール2：コーディネーターは解決するか、委譲するか、エスカレーションする

コーディネーターがsubagentからのエスカレーションを受けたとき、3つの選択肢がある。

1. ローカルで解決 — コーディネーターがsubagentに欠けていたコンテキストを持っている。コーディネーター自身がサブ質問に答え（例えば、コンテキスト内で安全なデフォルトを提供する）、明確化をバインドしてsubagentを再ディスパッチする。
2. ピアに委譲 — 異なるツールやデータを持つ別のsubagentが曖昧さを解消できるかもしれない。コーディネーターはユーザーに行く前にその質問をそのピアにルーティングする。
3. ユーザーまたは人間レビュアーにエスカレーション — ローカル解決もピア委譲も機能しない場合、コーディネーターは統合されたペイロードとともに曖昧さをユーザーまたは人間レビュアーに提示する。

ルール3：複数のエージェントからユーザーへ曖昧さの質問をブロードキャストしない

同じ曖昧さを独立して発見した並列subagentは、それぞれがユーザーに同じ質問をすべきではない。コーディネーターが集約し、重複排除する。連続して3つのほぼ同一の明確化質問を受け取るユーザーは、壊れたマルチエージェント設計の症状だ。

過剰エスカレーションの回避——些細な人間の割り込みを防ぐための閾値設定

エスカレーションが多すぎるシステムは、少なすぎるシステムとほぼ同様に壊れている。過剰エスカレーションは人間の注意を消耗させ、自動化のROIを破壊し、レビュアーを内容を読まずにリクエストをゴム印押しするよう訓練する。CCA-Fでは閾値調整を意図的なアーキテクチャ上の選択としてテストする。

過剰エスカレーションの症状

• タスクの20%を超えるエスカレーション率（正確な閾値は異なる。CCA-Fシナリオではしばしば数値が与えられる）。
• 異なるケースにわたって同じパターン（同じ欠落フィールド、同じ権限ギャップ）での繰り返しエスカレーション。
• レビュアーがクリアできる速度よりも早く蓄積するレビュアーキュー。
• 読まずに承認するレビュアー（「全承認」の振る舞い）。

過剰エスカレーションを減らす3つのレバー

1. 低ステークスのアクションの信頼度閾値を下げる — ルーティンの住所検索に対する0.9の閾値は誤って調整されている。0.7で十分なことが多い。閾値はアクションごとに設定すべきであり、グローバルに設定すべきではない。
2. よくある解決策を CLAUDE.md のルールとしてコード化する — 同じ曖昧さのパターンが繰り返しエスカレーションされる場合、その解決策をルールとして捉えるべきだ。次のインスタンスは自律的に解決される。
3. エスカレーション経路の前に明確化経路を設ける — 曖昧さがユーザーによって解決可能な場合（欠落フィールド）、まず尋ねる。明確化が失敗するかユーザーが利用できない場合、その後エスカレーションする。

過少エスカレーションの症状——もう一つの失敗モード

• 低信頼度の決定に基づいて実行された不可逆的なアクション。
• 顧客向け出力の高い偽陽性率。
• エージェントが正しいとして信頼された悪いデータを生成したため、下流の人間が再作業する。

目標は調整された中間点だ。閾値調整はデータを使う。保守的に始め、エスカレーション率と偽陰性率を一緒に測定し、両方が許容範囲内に入るまで閾値を調整する。

曖昧さ解消の文書化——解決策をCLAUDE.mdまたはルールにフィードバックする

最も価値のあるエスカレーションは、二度と起こらないものだ。人間が曖昧さを解消したとき、その解決策はエージェントの設定にフィードバックされ、同じパターンの次のインスタンスが自律的に処理されるようにすべきだ。CCA-Fでは、CLAUDE.md とルールの更新をフィードバックループとして認識することが求められる。

3段階のフィードバックループ

1. キャプチャ — すべての解決されたエスカレーションが、元のトリガー、人間の決定、および推論を記録する。
2. パターン検出 — 定期的なレビュー（週次または自動）がケースをまたいで繰り返すエスカレーションパターンを探す——同じ発動理由、同じ解決策。
3. コード化 — 繰り返すパターンが CLAUDE.md のルール（またはパス固有のスコープ付きルール）になり、将来の発生時に自律的に処理する方法をエージェントに指示する。

CLAUDE.mdに書くべきもの

コード化された解決ルールには4つの部分がある。

• トリガーパターン — この曖昧さを識別する観察可能なシグナル（例：「ユーザーが日付なしに『最近』と言う」）。
• デフォルトの仮定 — エージェントが自律的に適用すべき解決策（例：「『最近』を直前の30暦日として解釈する」）。
• 安全境界 — デフォルトが適用されず、エスカレーションがまだ必要な条件（例：「ユーザーが規制報告のコンテキストにいる場合、まだ尋ねる」）。
• ソースリンク — ルールを動機付けた元のエスカレーションへのポインター。監査と将来の調整用。

ルールのスコーピング

コード化されたルールは、その適用可能性をカバーする最も狭い CLAUDE.md スコープに配置すべきだ——1つのエージェントに固有のパターンにはプロジェクトレベル、コードベース領域に固有のパターンにはディレクトリレベル、個人的な好みのパターンにはユーザーレベル。グローバルな CLAUDE.md は普遍的に真の解決策のみを持つべきだ。プロジェクト固有の解決策の過剰なグローバル化は、モノリシックCLAUDE.mdの反パターン（コミュニティ痛点pp-08）を生み出す。

やさしい解説: 上記の仕組みは、受験者がすでに知っているシステムに対応付けることで直感的に理解できる。3つの異なる領域からの類比が、タスク5.2の全表面をカバーする。

類比1：フロントデスクの新入社員

あるホテルのフロントデスクで働いている新入社員を想像してほしい。よく訓練されているが、まだエッジケースを学んでいる。ゲストがWi-Fiパスワードという日常的なものを求めた——新入社員は即座に答える（低ステークス、高信頼度、エスカレーションなし）。ゲストが客室のアップグレードを求めた——新入社員はシステムを確認すると曖昧さを発見する（「ゲストはデラックスを予約しているが、メモには『空きがあればアップグレード』とあり、どのグレードかが指定されていない」）。新入社員は推測してプレジデンシャルスイートを渡したりもしないし、メモを無視してデラックスのままにしたりもしない。チャンネルが会話型なので、ターゲットを絞った1つの質問をする——「ジュニアスイートと標準スイートのアップグレード、どちらをご希望ですか？」ゲストが3泊の無料サービスを求めた。これは新入社員の権限を超えている。システムにも許可リストに「3泊を無料にする」ツールがない。新入社員はシフトマネージャーに構造化されたペイロードとともにエスカレーションする。ゲストの名前、クレームのサマリー、すでに提供されたもの、システムが提案した補償範囲、可逆性に関する注記。マネージャーはワンクリックで承認し、ケースは再開される。翌週、マネージャーは同様の補償リクエストが多数あることに気づく。シフトマネージャーは新しいルールを書く（「確認された部屋未準備のクレームに対して2泊まで無料補償可能」）そしてデスクのハンドブックに公開する。新入社員はそれらのケースを自律的に解決できるようになる。そのハンドブックの更新が CLAUDE.md のコード化だ。新入社員がClaudeエージェント、ハンドブックが CLAUDE.md、マネージャーがTier 1担当者、ホテルが本番システムだ。タスク5.2のすべての設計決定に直接対応するものがある。

類比2：空港の管制塔——階層エスカレーションと権限

空港の管制塔は3段階のコントローラーで運営される。地上管制官は誘導路の移動を担当する。タワーコントローラーは離着陸を担当する。アプローチコントローラーは空港上空の空域を担当する。各段階には定義された権限の範囲がある。各段階は状況がその権限を超えると上の段階にエスカレーションする。パイロットが通常とは異なるタクシールートを求めた場合は地上に行く。地上が解決できない場合（ルートがアクティブな滑走路を横断する）、地上はタワーにエスカレーションする。タワーが解決できない場合（通常とは異なるルートが到着機と絡み合う）、タワーはアプローチにエスカレーションする。パイロットがアプローチに直接電話することはない——段階の連鎖が権限の境界を保持し、無線通信を一貫させる。前例のない状況が発生した場合——例えば、通常とは異なるタクシー特性を持つ新しい航空機タイプ——解決策は空港が文書化する新しい手順になる。将来のすべてのインスタンスは地上で処理される。管制塔のアーキテクチャはコーディネーター-subagentのエスカレーションパターンだ。下の段階は常に上にエスカレーションし、横にはエスカレーションしないし、段階を飛ばすこともない。解決策はプロシージャにコード化されるので、時間とともに下の段階での権限が拡大する。

類比3：救急外来のトリアージ——グレースフルデグラデーションと閾値

救急外来のトリアージナースが患者を診て3つの並行する決定をする。確実に結論づけられること、不確実なこと、自分の権限外のこと。ナースはバイタルサインを自信を持って記録できる（確信ある出力）。症状が心臓由来か筋骨格系由来かナースは不確かだ（不確実な出力——フラグが立てられ、でっち上げられない）。ナースはモルヒネを処方する権限がない（権限外——医師にエスカレーション）。ナースは医師に構造化されたカルテを渡す。患者ID、バイタル、観察事項、信頼度スコア付きの疑われるカテゴリー、提案される次のアクション。医師はカルテをレビューして権威ある判断をする。カルテがエスカレーションペイロードで、バイタルが確信を持ってグレースフルデグラデーションされた出力で、疑われるカテゴリーが candidates リストで、カルテの構造化された形状こそが医師が30分ではなく30秒で行動できる理由だ。これがまさにタスク5.2のパターンだ——できることをし、できないことにフラグを立て、構造を持ってエスカレーションし、プロベナンスを保持する。

どの類比がどの試験問題に当てはまるか

• 明確化のタイミングとコード化に関する質問 → 新入社員の類比。
• 階層ルーティングとコーディネーター-subagentのエスカレーションに関する質問 → 管制塔の類比。
• グレースフルデグラデーションとエスカレーションペイロードの形状に関する質問 → 救急外来のトリアージの類比。

よくある試験の罠

コミュニティの合格レポートでは、タスク5.2に関連する5つの繰り返しの罠のパターンを特定しており、それらは尤もらしい選択肢として偽装されている。試験日前にすべて暗記する価値がある。

罠1：エスカレーションをタスクの失敗として扱う

エスカレーションはアーキテクチャ上の成功した成果であり、失敗ではない。低信頼度の返金を担当者にエスカレーションしたエージェントは正しいことをした。選択肢の誤りはエスカレーションを「エージェントがタスクを完了できなかった」とフレームし、エージェントが自律的に進めるよう信頼度閾値を下げるかプロンプトを強化することを代わりに提案する。どちらの提案も高ステークスのアクションには誤りだ。エスカレーションはバグではない。それが機能だ。

罠2：高ステークスタスクに明確化より仮定を選ぶ

高ステークスまたは不可逆的なアクションには、明確化が仮定より優先される——例外なし。選択肢の誤りは、返金、アカウント削除、本番へのパブリッシュのアクションでさえ「ユーザーを遅らせないために述べた仮定で進む」と主張する。これらの答えは誤りだ。速度の最適化は不可逆的な操作で明確化をスキップする有効な理由にはならない。

罠3：エスカレーションペイロードに全会話を注ぎ込む

エスカレーションペイロードは明示的なプロベナンスを持つ構造化されたサマリーでなければならず、生の会話の書き起こしではない。「思考連鎖とツール履歴全体をレビュアーに転送する」ことを提案する答えは誤りだ。意思決定に関連する情報が埋もれ、レビューのスループットが破壊されるからだ。

罠4：subagentがユーザーに直接エスカレーションする

コーディネーター-subagentの設計では、subagentはコーディネーターへ上にエスカレーションし、コーディネーターはユーザーまたは人間レビュアーへ上にエスカレーションする。subagentがエンドユーザーに直接明確化を求めることを述べた答えは誤りだ。境界はアーキテクチャ的なものであり、文体的なものではない。

罠5：常にエスカレーションを安全なデフォルトとする

過剰エスカレーションは過少エスカレーションとは異なる失敗モードだ。「完全な信頼度に満たないすべてのケースをエスカレーションする」ことを提案する答えは、自動化の価値を破壊し、レビュアーを全承認の振る舞いに訓練する。正しい姿勢はステークスに比例してスケールされた閾値だ——高ステークスのアクションは高い閾値を持ち、不確実性に対して必須のエスカレーションがある。低ステークスのアクションは低い閾値を持ち、不確実性に対してグレースフルデグラデーションがある。

練習アンカー

タスク5.2の概念はカスタマーサポート解決エージェントのシナリオで最も多く出題される。マルチエージェント調査システムはコーディネーター-subagentのエスカレーション境界を練習する。以下の2つのシナリオをタスク5.2の質問のアーキテクチャの骨格として扱う。

カスタマーサポート解決エージェントシナリオ

このシナリオでは、カスタマーサポートエージェントがFAQ検索、注文状況照会、返金リクエスト、アカウント変更にまたがるインバウンドチケットを処理する。タスク5.2の質問は次を対象とする。ルーティング前にチケットを分類する曖昧さ検出ステップ。明確化の形（チャットチャンネルでは単一質問、メール受付ではバッチ）。高ステークスのアクションに対する決定ポリシー（返金の承認は仮定ではなく明示的な明確化を必要とする）。エスカレーションペイロードの設計（生のチャットログではなく、構造化されたチケットサマリー＋信頼度スコア＋提案されたアクション）。サポート担当者、チームリード、エンジニアリング間の階層ルーティング。担当者が明確化を提供してエージェントがチケットを再開するときの再開フロー。「エージェントに尋ねるよう指示する強化版システムプロンプト」対「型付きスキーマを持つ構造化された request_clarification ツール」を対比させた質問が出ることを期待する——構造化ツールがほぼ常に正解だ。

マルチエージェント調査システムシナリオ

このシナリオでは、コーディネーターが調査subagentを並列サブトピックにディスパッチし、各subagentはタスクの自分のスライスで曖昧さに遭遇するかもしれない。タスク5.2の質問は次を対象とする。subagentがコーディネーターにエスカレーションするルール（ユーザーに直接ではなく）。コーディネーターのローカル解決、ピア委譲、ユーザーエスカレーションの3択決定。一部のサブトピックが自信を持って回答され、他が明確化を必要とするときのグレースフルデグラデーション。複数のsubagentの曖昧さを3つの別々の質問のブロードキャストではなく、単一の集約されたユーザー向け明確化に統合すること。

FAQ — エスカレーションと曖昧さ上位6問

Claudeエージェントはいつ仮定で進む代わりに明確化を求めるべきか？

アクションが高ステークスまたは不可逆的なとき——返金、アカウント変更、コンテンツのパブリッシュ、本番ブランチへのマージ、カードへの課金、顧客向けコミュニケーションの送信——は明確化を求める。アクションが低ステークスで簡単に元に戻せるとき——ドラフトの生成、読み取り専用クエリの実行、人間がレビューするベストエフォートの検索結果の返却——のみ述べた仮定で進む。ステークス-可逆性マトリクスが決定ルールだ。CCA-Fでは高ステークスのアクションに対して、「実行前に尋ねる」がほぼ常に正解だ。「ユーザーを遅らせないために信頼度の免責を付けて進む」を選んだ受験者は一貫してこのパターンを見落とす。

Claudeエージェントにおける明確化とエスカレーションの違いは何か？

明確化とは、欠落または曖昧な入力を解消するためにエージェントがユーザーに尋ねるユーザー向けの質問だ——ユーザーは答えられると推定され、タスクは答えが届いたらすぐに再開される。エスカレーションとは、トリガーがユーザーによって解決できない何か——権限の欠如、ステークスに比例したアクションでの信頼度閾値以下、または人間の判断を必要とする新規エッジケース——のとき、人間のレビュアー（またはより権限の高いエージェント）への制御の移転だ。明確化はユーザーをループに保つ。エスカレーションはサードパーティを引き込む。設計の優れたエージェントは両方の経路を持ち、それぞれを適合するケースに使用する。

人間のレビュアーが迅速に行動できるようエスカレーションペイロードをどう設計すべきか？

最低7つのフィールドを含める。ケース識別子、平易な言葉でのタスクサマリー、信頼度スコア付きのエージェントの現在の仮説、特定の曖昧さまたは発動理由、プロベナンスタグ付きのフィルタリングされた証拠（全会話ではない）、レビュアーがワンクリックで承認できる2〜3の提案されたアクション、各提案アクションの可逆性に関する注記。レビュアーは約30秒でケースをトリアージできるべきだ。最悪の反パターン——CCA-Fが評価を下げる——は生のエージェント会話履歴をペイロードに注ぎ込んでレビュアーに読み通すよう求めることだ。

エージェントが過剰エスカレーションして人間レビュアーを疲弊させないようにするには？

3つのレバー。（1）信頼度閾値をアクションごとに調整する（グローバルではなく）——ルーティン検索は不可逆的な書き込みより低い閾値を使うべきだ。（2）エスカレーション経路の前に明確化経路を設ける。ユーザーが解決可能な曖昧さは人間レビュアーに届くべきでない。（3）繰り返しの解決パターンを CLAUDE.md ルールにコード化する。同じ曖昧さが2度エスカレーションしないように。過剰エスカレーションは過少エスカレーションとは異なる失敗モードだ。CCA-Fシナリオでは「不確実性があるときは常にエスカレーションする」が尤もらしいが誤った答えとして提示されることが多い。レビュアーを全承認の振る舞いに訓練するからだ。

コーディネーター-subagentシステムでは、どのエージェントがユーザーに明確化を求めるべきか？

subagentではなく、コーディネーター。subagentは構造化されたエスカレーションレコードを通じてコーディネーターへ上にエスカレーションする。コーディネーターは3つの選択肢を持つ——subagentに欠けていたコンテキストを使ってローカルで解決する、曖昧さを解消できるかもしれないピアのsubagentに委譲する、またはユーザーまたは人間レビュアーへ上にエスカレーションする。subagentからユーザーへの直接通信は設計の優れたマルチエージェントシステムでは誤りだ。subagentのコンテキスト分離（コミュニティ痛点pp-03）は、subagentがユーザーが元々何を求めたかを理解していないことを意味するからだ。コーディネーターはまた、複数の並列subagentが同じ曖昧さを発見したとき重複排除もする。

人間がエスカレーションを解消した後、エージェントの実行をクリーンに再開するには？

4つのコンポーネントが必要だ。エスカレーションが発動したとき、エージェントのセッション状態（メッセージ履歴、ツール結果、部分的なプラン）を永続化する。人間の解決策を一時停止を引き起こした特定のフィールドにマップバックする構造化ペイロードとしてバインドする（生の追記されたユーザーメッセージとしてではなく）。明確化が適用された後に曖昧さ検出ステップを再実行し、新しいトリガーがエージェントが進む前に捉えられるようにする。誰が曖昧さをいつどのように解消したかの監査証跡を記録する。セッションフォーキングにより、元のコンテキストを捨てることなく人間が別の解決策を探したいとき、エスカレーション前のチェックポイントから分岐できる。CCA-Fでは「明確化を元のプロンプトの先頭に追加してタスクを再起動する」または「答えを新しいユーザーメッセージとして追加する」ことを提案する答えは、状態を失うため誤りだ。

さらに読む

• Building effective agents — escalation and human-in-the-loop: https://docs.anthropic.com/en/docs/build-with-claude/agentic-loop
• Handle tool calls — tool_result format and error responses: https://docs.anthropic.com/en/docs/agents-and-tools/tool-use/handle-tool-calls
• Subagents in the Agent SDK — error propagation and session re-entry: https://docs.anthropic.com/en/docs/claude-code/sdk/subagents
• CLAUDE.md configuration — codifying resolutions as rules: https://docs.anthropic.com/en/docs/claude-code/claude-md
• Writing tools for agents — Anthropic Engineering Blog: https://www.anthropic.com/engineering/writing-tools-for-agents

関連するExamLabのトピック：Conversation Context Across Long Interactions、Human Review Workflows and Confidence Calibration、Multi-Step Workflows Enforcement and Handoff、Error Propagation in Multi-Agent Systems。