ほとんどの「AI サポート」のロールアウトは同じ形で失敗します。bot がすべてに自信を持って回答し、その中には間違えると返金・churn・compliance インシデントを引き起こす 8% のチケットも含まれてしまうのです。この agent template はそれを逆転させます。これは Zendesk に接続された Decagon の AI エージェントで、厳密に定義された tier-1 チケットのスライスを完全に解決するようスコープされ、チケットがそのスライスから外れた瞬間にクリーンにエスカレーションするよう設計されています。成果物は「試みるエージェント」ではありません。解決可能インテントの明示的な allowlist、confidence ゲート、tool-call の境界、そしてコールドスタートではなく文脈を持った状態で人間に引き継ぐ handoff payload を備えたエージェントです。deflection 率は虚栄の指標です。この template が最適化する指標は、allowlist のインテントにおける再オープンなしでの解決であり、その一方でエスカレーションは人間がルーティングしたチケットよりも準備が整った状態で届きます。
artifact の bundle はここでは散文で説明され、4 つのパートとして提供されます。agent-instructions.md（system prompt とペルソナ）、intent-allowlist.yaml（インテントごとの guardrail を備えた解決可能インテント）、escalation-schema.json（handoff payload の契約）、_README.md（Decagon + Zendesk の配線と 12 ケースの受け入れスイート）です。エージェントを本番トラフィックに向ける前に、4 つすべてを読んでください。
いつ使うか
Zendesk インスタンスを持ち、意味のある反復的な tier-1 ボリューム（注文ステータス、パスワードとログインのリセット、プランと請求サイクルの質問、「請求書はどこ」、基本的な how-to、既知の問題の確認応答）を抱えるサポート組織を運営しているときに使ってください。このパターンは月あたりおおよそ 2,000 チケットを超えると元が取れます。そこでは allowlist のスライスが十分に大きく、そこで 30-50% の containment でも測定可能な量のエージェント時間を解放するからです。本物のナレッジベースも必要です。Decagon の解決品質は、回答の根拠とできる help center の記事とマクロの直接的な関数です。KB がゴミなら、エージェントもゴミです。
tier-1 のミックスが本当に deflection 可能（決定論的に正しい答えを持つ情報系・取引系インテント）で、allowlist を所有しエスカレーションのトランスクリプトを毎週レビューする support lead がいるときに最も適合します。これは運用されるシステムであり、設定して放置するトグルではありません。
いつ使わないか
間違った回答が高くつき不可逆なインテントにはデプロイしないでください。キャンセル、些細な閾値を超える返金、セキュリティと account-takeover の報告、データ削除（GDPR/CCPA）リクエスト、請求書ステータスの読み取りを超えて支払いに触れるもの、法務や契約に関わるものすべてです。これらは初日からエスカレーション経路に属します。allowlist には入りません、以上です。template はこれらを intent-allowlist.yaml で事前に除外しており、containment が dashboard で見栄えがするからといってこれらを追加する圧力には抵抗すべきです。
help center が薄かったり古かったりするならデプロイしないでください。40 件の古い記事を根拠にしたエージェントは、古い返金ポリシーを自信を持って引用します。まず KB を直してください。エージェントはその下にある品質を増幅します。
人間に到達するのを難しくする deflection の壁として使わないでください。CSAT を破壊する最速の方法は、苛立った顧客をループに閉じ込めることです。この template のエスカレーションロジックは意図的に積極的です。containment ポイントを獲得するより、境界線上のチケットを handoff することを好みます。あなたの使命が「どんな犠牲を払ってもチケットボリュームを減らす」ことなら、これは間違った template です。もっと悪いものが欲しいということになり、後悔します。
月あたり ~500 チケット未満ではデプロイしないでください。setup と毎週のレビューのコストは節約される時間を上回ります。そのスケールでは、いくつかの良いマクロとルーティングルールのほうがエージェントに勝ります。
Setup
1 週間から 2 週間を見込んでください。その大半は allowlist のキュレーションと受け入れスイートの実行に費やされます。Decagon と Zendesk の配線自体は半日です。
- Decagon を Zendesk に接続する。 Decagon で Zendesk チャネルを追加し、専用の API ユーザー（個人の seat ではない）に対して認可します。これはチケットと KB の読み取り、および公開返信・内部ノート・タグの書き込みにスコープされます。Decagon のナレッジソースを Zendesk Help Center に向けて再インデックスします。先に進む前に、エージェントがテストチケットを読み回答ドラフトを投稿できることを確認してください。
- インテントの allowlist をロードする。
intent-allowlist.yamlをインポートします。各エントリはインテント（例order_status）、それを根拠づける KB 記事、呼び出せる tool（例 注文ステータスの webhook 経由で注文を読む）、そしてインテントごとの guardrail（order_statusはステータスと ETA を述べてよいが、返金や expedite を約束してはならない）を指定します。allowlist にないものは定義上、人間にルーティングされます。default のアクションは試みることではなくエスカレーションです。 - confidence ゲートを設定する。
agent-instructions.mdでは、エージェントは回答前に自身の retrieval の根拠を自己評価することが求められます。回答について具体的な KB 記事や tool の結果を引用できないなら、一般化せずにエスカレーションしなければなりません。根拠が欠けているときにエスカレーションするようゲートを設定します。パラメトリック記憶から回答させてはいけません。 - エスカレーション payload を配線する。
escalation-schema.jsonは Decagon が handoff 時に書く内部ノートを定義します。検出されたインテント、顧客が尋ねたことを 1 行で、エージェントがすでに試して除外したこと、関連する KB リンク、顧客のセンチメント、エスカレーションの理由です。これらを Zendesk のフィールドと triage view にマッピングし、受け取る人間がすでに triage 済みのチケットを開くようにします。 - 12 ケースの受け入れスイートを実行する。
_README.mdは 12 件の canary チケットを提供します。解決されるべき 6 件（クリーンな注文ステータス、パスワードリセット、請求書リンク）と、エスカレーションされるべき 6 件（返金の要求、セキュリティ報告、怒ったキャンセル、曖昧なマルチインテントのメッセージ、allowlist 外の how-to、英語以外の言語のエッジケース）です。6 件すべてがクリーンに解決され、6 件すべてが完全な payload でエスカレーションされた場合のみ、エージェントは合格です。スイートが green になるまで本番トラフィックで自動返信を有効にしないでください。 - シャドウ、その後本番へ。 エージェントを 3 から 5 営業日、ドラフトのみモードで実行します。返信とエスカレーションノートを作成しますが、人間がすべての送信を承認します。ドラフトをレビューし、allowlist と guardrail を引き締め、その後 allowlist のインテントを自動解決に切り替え、それ以外はすべて人間のままにします。
エージェントが実際に行うこと
受信チケットごとに、エージェントはまずインテントを allowlist に対して分類します。インテントが allowlist にない場合、即座に停止してエスカレーションします。回答の試みも、部分的な返信もありません。allowlist にある場合は、根拠（KB 記事に加え、インテントが許可する tool の結果）を取得し、その根拠が実際に質問に答えているかを自己評価します。分類が先、根拠づけが後という順序が重要です。ドラフトの後に分類すると、モデルはすでに書いた回答を正当化しようと誘惑されます。これがまさに、自信を持って間違える返信が起きる仕組みです。
根拠がある場合、インテントの guardrail によって制約された返信を作成して投稿します。根拠がない場合（記事がエッジケースをカバーしていない、tool がエラーを返した、顧客のメッセージが 2 つのインテントにまたがる）は、部分的に回答するのではなく、escalation-schema.json の完全な payload とともにエスカレーションします。マルチインテントのメッセージは常にエスカレーションします。template は意図的に、チケットを分割して半分だけ解決することを拒否します。解決した半分が、保留した半分を顧客が信頼しないよう仕向けるからです。
handoff は内部で信頼を勝ち取る部分です。エスカレーションされたチケットを引き受ける人間は、検出されたインテント、1 行の要約、エージェントがすでに除外したステップ、参照した KB、センチメントの読み取りを見ます。これは、人間がコールドでルーティングしたチケットよりも厳密に多くの文脈です。これが support lead の buy-in を勝ち取る論拠です。エスカレーションは失敗ではなく、事前 triage 済みのチケットなのです。
コストの現実
Decagon は解決ボリュームで課金します（custom、通常は platform fee に解決ごとのレートを加えたもの。見積もりを取ってください。公開された単価は発表されていないので、見積もりが出るまでどの数字も推定として扱ってください）。business case のための誠実な枠組みは、containment されたチケットあたりのコストを、チケットあたりの fully-loaded な人間コストと比較してモデル化することです。ほとんどのサポート組織は後者を地域と複雑さに応じておおよそ $5-15 に置いています。containment は、その containment されたチケットがそうでなければ人間を消費したであろう場合にのみ金を節約します。顧客がいずれにせよ自己解決していたであろうチケットは節約ではありません。
setup コストは support lead の 1 から 2 週間の時間で、allowlist のキュレーションと KB のクリーンアップに前倒しでかかります。継続コストは最初の 2 か月間、トランスクリプトレビューに週あたりおおよそ 2 から 4 時間で、allowlist が安定するにつれて先細りになります。レビューを飛ばさないでください。レビューされないエージェントは、製品とポリシーがその下で変化するにつれてドリフトします。
成功の姿
4 つの数字を監視してください。1 つ目、allowlist のインテントにおける再オープンなしでの解決率。生の deflection ではなく、本物の containment 指標です。週 6 までに allowlist スライス内で 85% 超を目指してください。再オープンは、エージェントがエスカレーションすべきものに回答していることを意味します。2 つ目、エージェントが解決したチケットの CSAT と人間が解決したものの CSAT の比較。数ポイント以内であるべきで、低くなってはいけません。gap は guardrail が緩すぎるか KB が薄いことを意味します。3 つ目、エスカレーション payload の完全性。エスカレーションされたチケットを毎週サンプリングし、受け取る人間が、エージェントがすでに持っていた文脈を顧客に聞き直す必要がなかったことを確認します。4 つ目、誤エスカレーション率。人間が allowlist の情報だけを使って 1 回のタッチで解決したエスカレーション、つまりエージェントが処理できたはずのものです。これが上がるなら、confidence ゲートが保守的すぎるので、特定のインテントを広げられます。
代替案との比較
Zendesk のネイティブ bot と Advanced AI（エージェント copilot、intelligent triage）との比較。 Zendesk の組み込み AI は、すでにそれに支払っていて、ニーズが完全な自律解決ではなく提案と triage であるなら、最も摩擦の少ない選択肢です。ルーティングとエージェント向けの提案ドラフト作成に優れています。代わりに Decagon に手を伸ばす理由は、自律解決の深さとインテントごとの guardrail モデルです。Zendesk のネイティブ AI は急速に改善していますが、この template が依存する allowlist プラス confidence ゲートの規律は、専用に作られた解決エージェントのほうがより制御可能です。triage と返信提案だけが必要ならネイティブのままで。定義されたスライスで監査された自律解決が必要なら、専用エージェントが統合に値します。
Forethought との比較。 Forethought は ticketing のバックボーン上での自律解決における最も近い直接の競合であり、選択は本当に拮抗しています。Forethought は、優先事項がその discovery/triage 分析であり、緊密な Zendesk ネイティブのパッケージングが欲しいときに選ばれる傾向があります。Decagon は、会話的な解決品質とエージェント設計の制御が優先事項のときに勝つ傾向があります。同じ 12 ケースのスイートで、あなた自身の allowlist に対して両方を評価してください。差別化要因は、demo ではなく、どちらがあなたのインテントをクリーンに解決するかです。
生の LLM API に Zendesk API を加えた DIY エージェントとの比較。 自前のエージェントは完全な制御と最も低い解決あたりの限界コストを与えますが、Decagon が提供するもの、すなわち retrieval による根拠づけ、会話状態、分析、guardrail の enforcement、そして support lead がエンジニアリングの付き添いなしに使う運用コンソールを再構築することになります。恒久的なプラットフォームチームがあり、解決が所有するに足るほど中核的である場合にのみ DIY を選んでください。さもなければ、構築と維持のコストがライセンスを矮小化します。template の allowlist とエスカレーション schema はポータブルです。後で DIY に進んでも、設計は保持してエンジンを差し替えます。
Stack
- Decagon —自律解決エージェント。インテント分類、retrieval による根拠づけ、guardrail の enforcement、会話状態、分析
- Zendesk —記録の ticketing システム、ナレッジソースとしての Help Center、公開返信・内部エスカレーションノート・タグの宛先
- Forethought —あなた自身の allowlist に対して bake-off する、名前を挙げた代替の解決エージェント
- 注文/請求の webhook —allowlist のインテントが行うことを許可された読み取り専用の tool call（ステータスと請求書の参照、書き込みは決してしない）