ユースケース

サポートトリアージは、ほとんどのチームが決して構築しない最初のエージェントとして最適です

カスタマーサポートでは、前線では反復的な作業が行われ、後方では高度なスキルを必要とする一連の作業が発生します。エージェントはその最前面に属し、この 2 つの間の境界によって、展開が継続するかどうかが決まります。

Yaju チーム · 2026 年 7 月 18 日

サポートキューは、1 つの名前を持つ 2 つのジョブです。 1 つは収集です。これはどの顧客なのか、何を実行しているのか、最近何が変わったのか、以前に見たものと似ているかどうかを調べます。もう一つは解決中です。

最初の仕事は時間のほとんどがかかり、専門知識はほとんどありません。この非対称性が、トリアージが優れた第一エージェントとなる理由です。

エージェントがやるべきこと

受信した問題を読み、エンジニアが手作業で収集するコンテキスト (顧客の構成、地域、アカウントの最近の変更、同様の過去のチケット、関連するランブックセクションなど) を組み立てます。

提案された分類と開始仮説の草案を作成し、それに基づいた出典を添付します。

そして立ち止まり、記入済みのチケットを人に渡します。

チケットを閉じます。問題は問題ではないと判断します。間に人を介さずに顧客に連絡します。顧客のシステムに基づいて動作します。

これらは機能の制限ではありません。これらは責任を負わなければならない場所であり、それらを横切るエージェントは、エンジニアが発見した失敗ではなく、顧客が直接経験する失敗を引き起こします。

目に見えるメリットは、エンジニアが空のチケットではなく、記入されたチケットから開始できることです。これにより、すべての問題で実際の時間が節約され、キュー全体が複雑になります。

どの解決策が間違っているのか誰も予測できないため、エージェントが準備ではなく解決策を開始した瞬間に、すべての出力を慎重にレビューする必要があります。その時点で時間は消えるのではなく動き、プログラムはひっそりと料金の支払いを停止します。

到着から最初のエンジニアのアクションまでの時間。これはエージェントが実際に移動する時間です。

リワーク率: エンジニアが組み立てられたコンテキストを構築せずに破棄する頻度。それが高い場合は、モデルではなく検索が間違っています。

チケットあたりのコスト。一般的な AI ラインではなくエージェントに起因するため、その値については計画会議で議論の余地があります。

トリアージエージェントが途中で失敗して再起動すると、1 つのチケットに対して 2 回請求されるため、成功とは別に再試行されます。

明らかにコンテキストが間違っています。エージェントは古い構成の詳細を添付し、エンジニアはそれを合理的に信頼し、診断は横向きになります。

軽減策は、エージェントが添付するすべてのものの出所と、エージェントが引用した情報源が実際にその主張を裏付けるかどうかをスコアリングする基準です。不確実性をマークするエージェントは、デモではそれほど印象的ではありませんが、キューではかなり役に立ちます。

キュー全体ではなく、1 つの製品エリア。 IT 部門ではなくサポート側の指名所有者。前四半期の実際のチケットから書かれた評価基準。妨げとなる予算。スコアが面白くなくなったら幅を広げます。通常、これには誰もが計画しているよりも時間がかかり、それが定着する部分です。

エージェントオーケストレーションシステムのページでは、所有権、帰属、ポリシー、評価について説明します。一般的なキューではなく独自のキューに対して議論するには、デモを予約してください。