Skip to content
Berktug Berke Ates
Berktug Berke Ates

ソフトウェアエンジニア

ブログ

エージェント向けヒューマンエスカレーションキューの設計

· 7分で読める

一度もエスカレーションしないエージェントは自律的に見えます—ユーザーを静かに失敗させるまで。エスカレーションキューにはトリアージ規則、コンテキストパック、SLA、フィードバックループが必要で、チャットに貼った汎用の「人と話す」ボタンではありません。

感覚ではなくポリシーでエスカレートする

エスカレーショントリガーを明示ポリシーとして定義します:高リスク意図での低信頼度、N回リトライ後のツール失敗、ユーザーの人間要求、規制キーワード、エージェントが越えてはならない支出・権限境界。曖昧な「詰まっている感じ」ヒューリスティックはアラート疲れか静かな行き止まりを生みます。

ソフトアシスト—人間がレビュー中もエージェントが下書きを続ける—とハードストップ—副作用を承認まで凍結—を分けます。プロダクト・リスク・サポートがサーフェスごとにマトリクスに署名する必要があります。

生のトランスクリプトではなくコンテキストパックを送る

人間はエージェントが止まった理由を再構築するために何分も浪費します。ユーザー目標、直近のツール結果、提案する次アクション、信頼シグナル、エージェントが既に約束したことを梱包します。秘密は伏せ、監査に足る証拠は残します。

スキルと権限でルーティングします:請求紛争、セキュリティインシデント、アカウント復旧は未分化の一つの受信箱を共有すべきではありません。優先度と顧客ティアを含め、キュー順序がビジネスポリシーと一致するようにします。

  • プロダクトとリスク署名済みのエスカレーショントリガーマトリクスを公開
  • 目標・ツール・提案アクション付きの構造化コンテキストパックを添付
  • スキル・権限・重大度でルーティング—キャッチオールキューにしない
  • チケット量だけでなく time-to-first-human と解決品質を計測

ハンドオフを双方向にする

人間がケースを解決したら結果を戻します:訂正された事実、承認済みプレイブック、エージェントが再開してよいか。このループがなければ似たケースはまた上がり、コスト曲線は曲がりません。

オペレーターUIにエージェント状態遷移—pending、waiting on human、resumed、closed—を出し、サポートがエージェントがまだ所有していると思っている並行チャットと戦わないようにします。

キューを信頼性業務のように運用する

バックログ年齢、放棄率、誤エスカレーションを追跡します。モデルやプロンプト変更後のスパイクは多くの場合、急に人間が必要になったのではなくキャリブレーション崩れです。エージェント自律性を売り出す前にピーク負荷と時間外カバレッジをリハーサルしてください。

ヒューマンエスカレーションは運用予算付きのプロダクト機能です。供給するエージェントと同じ厳しさで設計してください。


2026年9月15日、Berktug Berke Ates が公開。