7週間で1 million回｜Zendeskが顧客に作らせたエージェント

顧客対応にAIを入れる話は、ほとんどが「最初の返信」をめぐるものです。チャットの一次応答、よくある質問への自動回答、受付の振り分け。ところが現場で人の時間を食っているのは、たいていその後ろにある処理です。返品条件の例外を認めるかどうか、保証の適用範囲を調べる、請求の内訳を突き合わせる。顧客が最初に書いた一文と、解決の連絡との間に挟まっている仕事です。

Zendeskは、ここを顧客自身に自動化させる仕組みを作りました。管理者が英語の文章で手順を書き、既存のツールにつなぐと、その会社の業務に沿って動くエージェントができる。早期アクセスの最初の seven weeks で、そのエージェントが 1 million 回実行されたと公表されています。

この記事が扱えるのは、Anthropicが公開している導入事例ページと、Zendeskの公式告知2本に書かれている範囲です。確認日は2026年10月13日です。費用、利用している顧客の社数、精度の内訳は公表されていません。先に書いておくと、これは製品を選ぶための記事ではありません。読み取れるのは、業務ごとに違う後工程を機械に渡すとき、どこを顧客に書かせ、どこを提供側が固定したのか、という設計の線引きです。

自動化されていなかったのは、最初の返信ではなく「その後ろ」

導入事例の冒頭が、この製品の出発点を説明しています。Zendeskの基盤は多くの要求を自動で処理できるようになったが、最初のメッセージから解決までの間にある仕事は手作業のまま残っていた、という書き方です。例として挙がっているのは、返品方針の例外、複雑な保証請求、細かい請求の問い合わせの3つです。

規模による違いも書かれています。小さな組織は、その手作業を人が1件ずつ片づけていました。AIの担当者を抱える大きな企業は、自社用の作り切りの自動化を組みましたが、相応の開発資源が必要でした。つまり、やりようはあるが、持てる会社しか持てない状態だったということです。

AI/MLのディレクターであるAbhinay Kathuria氏の言葉として、次の一文が載っています。「Every customer is so unique to what they do. There’s a lot that happens behind-the-scenes, and a lot of this was being handled manually.」顧客ごとに業務があまりに違い、裏側で起きていることが多く、その多くが手作業で処理されていた、という意味です。

この診断は、Zendesk側の告知とも揃っています。早期アクセスの告知には、どの事業にも固有の複雑さがあり、既製の仕組みでは完全に捉えきれない、と書かれています。出来合いの自動化が刺さらない理由を、業務の違いそのものに置いているわけです。

作ったのは、エージェントではなくエージェントを作る場所

Zendeskが出したのは、業種別の完成品ではありません。顧客が自分で組み立てる道具です。公式告知では agent builder と呼ばれ、管理画面に加わる機能として説明されています。早期アクセスの告知の日付は2026年5月18日で、提供の開始は翌5月19日です。使い始めるには、管理者が管理画面で早期アクセスを有効にし、利用条件に同意する必要があると書かれています。

できることの説明は具体的です。導入事例によると、顧客はエージェントへの指示を平易な英語で書き、Zendeskの操作と、Jiraや Google Drive のような外部のツールに数回のクリックでつなぎます。所要時間は約30分とされ、それまで数か月の開発を要した作業と対比されています。告知側では、最初に備わる機能はエージェントの作成と、あらかじめ用意された接続先への連携だとされ、接続先として Salesforce、Slack、Jira、Google Sheets が挙がっています。

書けるのは返信の文面ではなく、手続きそのものです。導入事例に出ている例が分かりやすいので、そのまま引きます。障害の切り分けを任せた場合、エージェントは Jira に課題を起票し、Slack で担当のエンジニアへ通知し、影響を受けた顧客へ知らせ、修正が出た時点で関連するチケットをまとめて閉じます。やっているのは応答ではなく、部署をまたぐ段取りです。

自分で改善する仕掛けも書かれています。エージェントは自分の仕事を振り返り、学んだことを再利用できる skill として保存するとされています。同じ判断を繰り返すたびに手順を書き足すのではなく、動いた結果を部品として残す形です。

層の分け方そのものが、この製品の主張です。業務の違いは上から入れさせ、モデルと実行環境は提供側が決める。顧客に選ばせる範囲を、業務の記述だけに絞っています。どのモデルを使うかを顧客に選ばせる設計にすると、同じ機能でも結果がばらつき、支援する側もどこまで保証できるのか言えなくなります。

単純な要求と複雑な要求を、入口で分ける

もう一つ、運用の設計として書かれているのが振り分けです。導入事例によると、router が要求を見て、単純なものは Claude の呼び出し1回で処理し、複雑なものは多段の計画を立てる側へ回します。

この分岐は、品質のためというより費用のための構造です。Kathuria氏は「You can’t just look at token price in isolation. You have to look at the cost per task.」と述べています。トークン単価だけを切り離して見てはいけない、1件あたりの費用で見る必要がある、という意味です。要求の難しさに関係なく毎回同じ段取りを踏ませると、簡単な1件にも計画の工程ぶんの費用がかかります。

任せたあとの見え方についても記載があります。顧客はエージェントの権限を自分で決められ、どのツールをどう呼んだかの記録を見られます。さらに、会話を模擬して試すことと、A/Bテストを行うことができるとされています。作れることと、本番へ出す判断は別に置かれているという構造です。実行の承認を利用者側に残した設計はQontoが製品に載せたAIエージェントでも扱いましたが、あちらは1件ごとの実行承認、こちらは出す前の検証と権限の設定という違いがあります。

モデルは15の指標で採点して選んだ

選定の進め方も公表されています。Zendeskは自社の製品群で共通に使っている試験の仕組みを持っており、顧客が実際に書くようなエージェントを使って、各モデルを15の指標で採点するとされています。評価の材料を、自分たちの用途に寄せているのが要点です。一般的な指標の高さではなく、顧客が書く指示文で動かしたときにどうなるかを見ています。

選ばれたのは Claude Sonnet 4.6 です。PDFを読むような試行の作業で非常によく動き、判断に至るまでの手数が少なかったと書かれています。Kathuria氏は比較の様子を、別のモデルでも同じ結論に達するかもしれないが、そこへ行くのに計画の往復が四、五回かかることがある、Sonnetはその多くを一度で片づけられた、という言い方で説明しています。

ここは自社で検討するときにそのまま使える観点です。モデルの比較を単価表で行うと、安い方が選ばれます。1件を終えるまでの往復の回数が違えば、単価が安いほうが高くつくことがあります。比べる単位を「1回の呼び出し」から「1件の完了」へ移すだけで、結論が変わり得ます。問い合わせ対応の自動化をどこから始めるかという整理はAIで問い合わせ対応を自動化する方法にまとめています。

審査を増やさないために、既存のAWSの中で動かす

実行環境についても明確な記載があります。ZendeskはClaudeを Amazon Bedrock 経由で動かし、モデルの処理を、同社がすでに使っているAWSのホスティングリージョンの中に収めています。これが顧客のデータの所在と統治の要件を満たす助けになる、という説明です。

Kathuria氏の言葉は端的です。「Our most important security benefit is that Claude runs through the AWS environment we already operate and govern.」最も重要な安全面の利点は、Claudeが自社がすでに運用し統治しているAWS環境を通って動くことだ、という意味になります。導入事例は、これにより顧客が追加のクラウドの委託先を承認したり管理したりする必要がなくなる、と続けています。

機能の説明に見えますが、実際には売りやすさの話です。新しいAI機能を顧客の環境へ入れるとき、技術的な可否より先に、委託先の審査と契約の見直しで止まります。処理の場所を動かさない設計にすると、その審査が発生しません。社内で使うAIの展開でも同じ順序が効きます。先に統治の道筋を敷いてから配った事例はState FarmのCopilot Studio活用にまとめてあります。

なお、今回の仕組みが置かれている土台も動いています。もう一方の公式告知では、AIエージェントの提供区分について Essential と Advanced の区別をなくし、推論・多段の手順・API連携を含む機能を Suite と Support の各プランへ広げると説明されています。高い等級の契約でしか触れなかった機能が、下の等級にも開いた、という流れです。

公表されている値と、その読み方

数値を並べます。いずれも導入事例に書かれている値で、原文の数字列のまま記載します。

実行回数は、早期アクセスの最初の seven weeks で 1 million 回です。カスタムエージェントを動かしている顧客では、人が1件に費やす処理時間が最大80%減り、自動で解決した割合が最大10%増えたとされています。年間 14+ million 件の要求を扱う顧客の1社は、重複したチケットの統合を自動化し、試験運用で99%の正確さに達したと書かれています。

読み方には注意が要ります。まず、これは提供している側が自社の製品について公表した値で、第三者の検証を経ていません。次に、最大という限定が付いている2つは平均ではありません。そして、母数が示されていません。何社が使ってそうなったのか、全体の何割がその水準なのかは書かれていません。

時期についても、確定できない部分があります。早期アクセスの提供開始が2026年5月19日であることは公式告知で分かりますが、1 million 回を数えた seven weeks がいつからいつまでなのかは導入事例に書かれていません。開始日から単純に数えた期間だと読むのは、こちら側の推測になります。

先の見通しも載っています。一般提供は11月のAI Summitに予定され、四、五社の顧客がこのエージェントで年間 20 million 件のチケットを処理する見込みだとされています。長期の構想としては、AIが顧客と従業員の要求の80%以上を扱い、残りを人がAIの助けを借りて扱う Autonomous Service Workforce が掲げられています。製品・エンジニアリング・AIを担当するプレジデントのShashi Upadhyay氏は、万能型のエージェントの時代は終わり、最良のエージェントは業務と業界と事業に深く根ざした専門家だと述べています。顧客対応AIの公表値の読み方という点では、KlarnaのAIアシスタントの記事で扱った数値の扱いと同じ注意が必要です。

記載が見つからなかったこと

推測で埋めないために、探しても確認できなかった項目を残します。

確認したかった項目	記載の状況	どう扱うか
価格、追加の費用	記載がありません	自社の条件は見積もりで確かめる
利用している顧客の社数	記載がありません	公表値の母数として使わない
1 million 回の内訳	要求の種類別・顧客別の内訳なし	全体の傾向として読まない
80%減・10%増の測定方法	期間と比較対象の記載なし	自社の改善見込みに転用しない
振り分けの判断基準	単純と複雑を分ける条件の記載なし	自社の件数構成で見積もれない
人が介入する条件	権限と検証の仕組みの説明まで	無人で回る範囲は確認できない
日本語での対応状況	記載がありません	管理画面と窓口で確認する

記載のない項目が多いのは、導入事例としては普通です。問題になるのは、空いた欄を自社の資料で埋めるときです。社内で共有するときは、公表されている内容と自分たちの見立てを行で分けてください。

日本の実務者が持ち帰れること

第一に、自動化の対象を「返信」から「返信の後ろ」へ移すという見方です。一次応答の自動化はすでに手が入っている会社が多く、効果の伸びも鈍くなっています。この事例が選んだのは、例外の判定、保証の確認、請求の突き合わせといった、人が調べて決めている工程でした。自社で候補を探すなら、返信までの時間ではなく、返信してから解決までの滞留を見るほうが当たります。

第二に、比べる単位を1件の完了に置くことです。モデルやツールの比較を単価で行うと、往復の多さが見えません。同じ1件を終えるまでに必要な手数を含めて比べると、順番が入れ替わることがあります。評価の材料も、一般的な試験ではなく自社の担当者が実際に書く指示文で作るほうが、導入後の体感と一致します。

第三に、処理の場所を動かさないという発想です。顧客や社内の情報統括部門に新しい委託先の審査を求める設計は、技術の可否とは別の理由で止まります。すでに使っている基盤の中で動く形にできるなら、審査の工程が1つ消えます。導入の速さは、たいてい機能ではなくこの種の段取りで決まります。

第四に、作れることと出せることを分けることです。この仕組みは、管理者が約30分で組める一方で、権限の設定、呼び出し記録の確認、模擬会話での試験、A/Bテストを別に用意しています。社内で誰でも作れる状態にするときは、同じ数の歯止めを同時に置かないと、作った数だけ確認されていないものが増えます。エージェントを増やす前に置き場所を決める手順はImpelが候補を6つの原因へ束ねた手順に整理しています。

結局、何が変わったのか

変わったのは、自動化の対象ではなく、自動化を誰が書くかです。従来、業務に固有の処理を自動化できるのは、開発資源を持つ会社だけでした。この仕組みは、その記述を管理者の文章に置き換え、モデルと実行環境は提供側が固定しました。顧客が持ち込むのは業務の知識だけになります。

公表されているのは、早期アクセスの最初の seven weeks で 1 million 回動いたこと、使っている顧客で処理時間が最大80%減り、自動解決が最大10%増えたことまでです。費用も社数も精度の内訳も分かりません。この事例から取れるのは結果の数字ではなく、顧客に書かせる層と提供側が決める層を分けた設計の線引きです。自社で同じことをするなら、まず「誰が業務を書き、誰が環境を固定するのか」を決めるところからになります。