AIは、チケットの各ステップから作業を取り除くことで処理時間を短縮します。担当者がスレッドを読み直さなくて済む要約、タブを切り替えなくて済むナレッジ検索と注文の確認、ゼロから書かなくて済む返信の下書き、そして数秒で終わる後処理のためのタグとメモの自動入力です。多くの場合、最大の効果が出るのは検索のステップですが、ほとんどの「AI返信」ツールはここを飛ばしています。
ただし注意点があります。AIが簡単なチケットを完全に解決するようになると、人に残るチケットは長いものになるため、エージェントの総稼働時間が減っても平均処理時間は上がることがあります。エージェントの稼働時間とチケット種別ごとのAHTを測り、再オープン、初回解決率、CSAT、担当者が書き直した下書きの割合も見てください。
eeselのようなAIチームメイトは、Zendesk、Freshdesk、Gorgiasの中でこれを行います。STIL Classicsでは、1か月で約320件のGorgiasチケットを準備し、1文字も書く前に約230件のShopify注文を確認しました。プランは毎月固定のクレジット枠で、1チケットが1クレジット、月額$299からです。
平均処理時間の「分」は実際どこに消えているのか？
平均処理時間（AHT）とは、担当者がチケットを開いてから、返信とメモを終えるまでに実際に作業している時間のことです。最初の応答時間や解決時間とは別物で、この2つは顧客が待つ時間を測ります。チケットが2日待たされても、処理時間は4分ということがあります。
私はeeselでAIエージェントを作っており、新しいチームと最初にやるのは、数件のチケットをステップごとに見ていくことです。時間の内訳は、ほぼいつも同じ形になります。
- 読む。 スレッドをスクロールし、顧客の要望を把握し、同僚がすでに試したことを確認する。
- 調べる。 注文、アカウント、ヘルプ記事、ポリシーを探す。別のタブで行われるため、見えにくいステップです。
- 書く。 返信を打つか、適切なマクロを探して修正する。
- 後処理。 タグ、チケットのフィールド、社内メモ、ステータスの変更。
最初に確認する価値があるのは、調べるステップです。Freshdeskのドキュメントによると、その処理時間ストップウォッチは、返金ポリシーを別の場所で調べるようなチケットの外での時間を含みません。つまり、最も遅い時間の一部がレポートにまったく表れていない可能性があります。Redditのサポートリーダーも、電話対応の側で同じことに気づきました。
"Agents could copy/paste the phone number into the search and pull up 90% of accounts immediately. ... changing that look-up process shaved 2+ minutes off our AHT."
後処理も、目立たない時間の消費先です。大規模なコールセンターを運営する企業で社内AIエンジニアリングチームを率いるHacker Newsのコメント投稿者は、AIが書く要約に切り替える前は、各通話の後に3〜5分を手作業の要約に費やしていたと書いています。Help Scoutも自社の処理時間指標を同じように読み解いており、メールレポートのドキュメントによれば、数値が高い場合は返信が長いか、担当者側の「a lack of resources or knowledge」を示します。
どのAIの仕事が処理時間を短縮するのか、ステップごとに
チケットを短くする仕事は6つあり、さらにキューからチケットを丸ごと取り除く7つ目があります。それぞれ狙うステップが違うため、最初の一手は時間がどこに消えているかによって変わります。
1. チケットを開いたときの要約
長いスレッドや引き継ぎは読む時間がかかり、再オープンされたチケットも同じです。チケットの上部にあるAI要約は、誰が、何を、どこまで進んでいるかを数行で担当者に伝えます。Freshdeskを使うクラウドERP企業のQontroでは、どのチームメイトもチケット上で「summarise」という言葉でeeselをメンションすると、顧客は誰か、問題、試したこと、現在の状況をまとめた短いメモが返ってきます。うまくいく形式については、AIチケット要約の記事で解説しています。
2. 答えを先に見つけるナレッジ検索
答えがヘルプセンターや過去のチケット、どこかのGoogle Docにあると、担当者の仕事は検索になります。Qontroのエージェントは1か月に約190件のチケットで約400回のナレッジ検索を行いました。1件あたりおよそ2回で、約9,800件の過去チケットとヘルプ記事を参照し、下書きに記事へのリンクを入れます。CartonCloudのサービスデスクリーダーは、その効果を導入事例でこう語っています。
"We've seen a reduction in the time spent on rudimentary queries, allowing our agents to spend more time focused on more complex queries."
Eddie Stephens, Service Desk Lead, CartonCloud
ナレッジが散らばっている場合は、AIのせいにする前にサポートのためのナレッジ管理から始めてください。
3. チケットの裏側にあるシステムでの検索
ほとんどのAI返信ツールが飛ばすのがこれで、ECでは通常いちばん大きな効果があります。GorgiasとShopifyを使うプランナーブランドのSTIL Classicsは、下書きを作る前に、注文、出荷状況、商品、配送先住所を取得するようeeselを設定しました。1か月で、約320件のチケットにわたり約230件のShopify注文を確認した計算です。確認していない事実は決して書きません。情報が足りない場合、下書きは推測せず、担当者のために角括弧で空欄を残します。Gorgias側の設定については、Gorgiasの注文データガイドをご覧ください。
4. チケット内で待っている返信の下書き
社内メモとしての下書きは、「書く」を「確認して送る」に変えます。Zendeskを使うドイツのローン比較サイトsmavaでは、下書きエージェントが約820件のマクロとヘルプ記事を検索し、該当するマクロを一字一句そのまま、プレースホルダーを埋めた状態で下書きし、チケット上に承認と却下のボタンを表示します。1か月で約27,000件のチケットのうち約15,300件の下書きを準備しました。規制のある金融では文言がとても重要なので、下書きは自由な文章ではなく承認済みのテキストから始まります。このパターンはAIマクロのガイドで扱っています。
ただし、下書きの質については自分に正直になってください。Qontroでは、現在およそ10件に1件の下書きが、ほとんどまたはまったく修正されずに送られており、残りはヘルプセンターの不足を見つけるために使われています。これは確かな成果ですが、担当者がゼロから書き直す下書きは読む時間を増やすだけで、書く時間は節約できません。
5. 誰かが触れる前のトリアージとルーティング
引き継ぎのたびに、新しい担当者の読むステップがやり直しになります。届いた時点で、意図、言語、そして緊急度でチケットを振り分ければ、最初にチケットを開く人が適任になります。smavaの分類エージェントは、言語にタグを付け、チケットに自動返信してよいかを確認し、smava独自のマッピング文書から1つのカテゴリを選んでZendeskのフィールドに書き込みます。1か月で約14,600件のチケットで稼働しました。設定についてはチケットトリアージの自動化をご覧ください。
6. 対応後の作業を代わりに入力
タグ、チケットのフィールド、完了メモ。AIがすでにチケットを読んでいるなら、作業の流れの中でこれらを入力できます。Redditのコールセンター担当者は、うまくいっている例をこう説明しています。
"...at my current job they have an AI listening to our calls and it generates a summary of the call that we use as our disposition so we don't type it manually."
レポートに使えるほどタグの一貫性を保つ方法は、AIによるサポートタグ付けの記事で解説しています。
7. 一部のチケットをキューから外す
最速のチケットは、どの担当者も開かないチケットです。AIだけで完結できる一部（注文状況、使い方の質問、ポリシーの質問）を選び、直接返信させます。Freshdeskを使うアウトドアフィットネス企業のOriginal Bootcampは、ウェブサイトと過去のチケットから答えられるチケットだけを通す、ドイツ語で書かれたフィルターでこれを実現しています。予約やアカウントに関するものは、すべて人に直行します。AHTに関するアドバイスの多くは担当者の支援で止まり、これを省いていますが、総稼働時間に最も大きく効くのはこれです。線引きの位置については、ティア1サポートのデフレクションをご覧ください。
どこから始めるべきか？
最も多いチケット種別で、いちばん時間を食っているステップから始めてください。5件のチケットを手作業で計測して4つのステップに分ければ、答えはたいてい見えてきます。
| 担当者が主に... | ボトルネックは | 最初に導入するもの | 1週間後の最初の確認 |
|---|---|---|---|
| 長いスレッドや引き継ぎをスクロールしている | 読む | 開いたときの要約 | 担当者はまだ上にスクロールしているか？ |
| Shopify、請求、CRMに切り替えている | 調べる | 下書きの中でのシステム検索 | すでに注文が入っている下書きの割合 |
| ヘルプセンターを検索したり、同僚に聞いたりしている | 調べる | リンク付きナレッジ検索 | 下書きが引用している記事 |
| 同じ回答を打ち直している | 書く | マクロや過去のチケットからの返信下書き | 下書きの修正率 |
| チーム間でチケットを回している | 読む（再度） | トリアージとルーティング | 1チケットあたりの引き継ぎ回数 |
| タグとメモに時間をかけている | 後処理 | 自動タグとフィールド | サンプルでのタグの正確さ |
| 一日中「注文はどこ？」に答えている | チケット全体 | その部分の完全自動化 | AI返信の再オープン率 |
AIでどれだけ処理時間を節約できるか？
下に自社の数字を入力してください。初期値は例としてのチケットで、ベンチマークではありません。4つのステップに分けた11分が、AIの支援で5分になり、チケットの4分の1がAIで完全に解決される想定です。解決されるチケットは、1件5分の簡単なものと仮定しています。
ステップごとの分数、月間のチケット数、AIが解決する割合を変えて、AHTとエージェントの稼働時間を確認してください。解決されるチケットは簡単なものと仮定しているため、真ん中のカードは上がります。
まず何よりも、真ん中のカードを見てください。初期値では、自動化だけでAHTが11分から13分に上がります。5分のチケットが平均から抜けるためです。残りのチケットにAIの支援を加えると約6分まで下がり、エージェントの稼働時間は月550時間から約220時間に減ります。この節約の大部分は調べるステップと書くステップから生まれており、だからこそ私はほとんどのチームでそこから始めます。
AIを導入すると平均処理時間が上がることがあるのはなぜか？
AIが簡単なチケットを引き受け、難しいものをチームに残すからです。処理時間は平均なので、短いチケットが平均から消えれば、誰も遅くなっておらず、チームがキューに使う時間が減っていても、平均は上がります。
担当者は、ダッシュボードに数字が出る前からそれを感じます。Redditのコールセンター担当者は、会社が電話回線の前にAI音声エージェントを置いた後の様子を、こう説明しています。
"At this point, it's handling a lot of "routine" calls. Which means the calls that come through to us humans are more complicated, or people who are upset about the AI messing something up."
一部のヘルプデスクは、すでにこれを仕組みに組み込んでいます。Gorgiasは、人が対応したチケットだけでチケット処理時間を計算し、AI Agentが解決したチケットを除外します。パフォーマンス概要では、エージェントの種類別に結果を分けることもできます。
そこで、1つではなく3つの数字を報告してください。キューにかかったエージェントの総稼働時間、チケット種別（注文状況、返品、技術的な問い合わせ）ごとのAHT、そしてAIが解決したチケットの割合です。エージェントの稼働時間と種別ごとのAHTが下がっていれば、混ざった平均がどう動こうと、うまくいっています。AI側についてはAI解決率の記事で扱っています。引き継ぎ側については、コンテインメントとエスカレーションの質をお読みください。
もうひとつ、備えておくべきことがあります。難しいチケットだけのキューは消耗します。サポート歴30年近いRedditのコメント投稿者は、率直にこう述べています。
"Except now imagine an eight-hour shift where practically EVERY conversation you receive is an escalation, an angry customer, an unusual problem or something the AI already couldn't solve."
AIが加わったら、AHTの目標を個々の担当者に課さない理由になります。チケットが難しくなるにつれて、サポート向けAIコーチングにも目を向けましょう。
ヘルプデスクは処理時間をどう測っているのか？
それぞれ違います。だから、自社のAHTを他社のものと比べるべきではありません。各社の定義を、ベンダー自身のドキュメントをもとに、2026年10月29日時点で確認した内容でまとめます。
| ヘルプデスク | 指標 | 何を数えるか | 場所 | プラン |
|---|---|---|---|---|
| Zendesk | Handle time | メッセージングチケットでの担当者の時間。割り当てから、Pending、On-hold、Solvedに設定されるまで | Explore、メッセージングチケットのデータセット | Suite Professional以上 |
| Zendesk | Time Trackingアプリ | チケットごとに費やした時間を2つのカスタムフィールドに保存 | Marketplaceアプリ、Exploreでレポート | Suite Growth以上 |
| Freshdesk | Average Handling Time | 割り当てられたチケットを担当者が開いている間のストップウォッチ。訪問ごとに合算 | Analytics > Curated Reports | ProとEnterprise |
| Gorgias | Ticket handle time | 人が対応したクローズ済みチケットでの、下書き、作業、電話の時間 | Analytics > Helpdesk performance > Overview | すべてのヘルプデスクプラン |
| Help Scout | Handle Time | 会話を開いてから送信を押すまで。最後の訪問のみ | Reports > Email | Standard（2年分のデータ）、PlusとPro |
| Front | Handle time | 会話を表示してから返信を送信するまで。上限60分 | Analyticsレポート | プランの記載なし |
| HubSpot | 処理時間の指標は見つからず | 最初の返信までの時間とクローズまでの時間のみ | Service > Help Desk > Analyze | Service Hub Professional以上 |
このうち2つは、AIを直接測るのに役立ちます。Frontは提案された返信の処理時間を手書きの返信とは別に報告するため、同じレポートの中で両者を比較できます。FreshdeskのAHTレポートは、時間を担当者、グループ、製品、チケットごとに分解するため、1つのチケット種別でビフォーアフターを行うには十分です。
Zendeskでは、メッセージングの指標はメールをカバーしないため、メールのチームにはエンゲージメント期間かTime Trackingアプリが必要です。Zendesk自身のドキュメントにも、担当者がアプリの読み込みを回避する方法を見つけられると書かれているため、これらの数字は下限として扱ってください。Zendeskを使っていて、設定のAI側をひととおり知りたい場合は、ZendeskのAIコパイロットガイドで順を追って解説しています。
処理時間とあわせて何を追うべきか？
最低でも4つです。AHTだけでは、急ぐことに報酬を与えてしまうからです。2回戻ってくる短いチケットは、きちんと終わった長いチケットよりコストがかかります。
- 再オープン率。 クローズ後に顧客が再度連絡してくるチケットの割合。急いだ回答はまずここに現れます。
- 初回解決率。 1回の返信で解決した割合。AIと初回解決率をご覧ください。
- CSAT。 ヘルプデスクでタグ付けできるなら、AIが下書きした返信と手書きの返信で分けてください。アンケート側についてはAIとCSATのガイドで扱っています。
- 下書きの修正率。 担当者が大幅に書き直したAI下書きの割合。これが高いままなら、下書きは書く時間を節約するどころか、読む時間を増やしています。
最初の3つは、AIより何十年も古い、AHTの最も古い問題を防ぎます。Redditのある担当者は、その兼ね合いを内側から説明しました。
"Not ideal for someone like me who prefers to take that extra 5 minutes now to save the customer and one of my colleagues 10-20 minutes later."
4つ目はAI特有のものです。調整が不十分なAIはチケットを長くすることがあり、担当者はすぐにそれに気づきます。
"Calls were actually taking longer because we had to review and edit notes before saving them."
だからSTIL Classicsでのeeselの下書きは推測ではなく角括弧の空欄を残し、Qontroは書き直された下書きを、記事が足りないサインとして読み取ります。指標の全体像については、カスタマーサービスKPIと、私がまとめたAI導入の失敗例をご覧ください。
30日で処理時間を減らすAIをどう導入するか？
週ごとの4つのステップで、まず下書きから始め、数字が安全だと示してからAIに単独で返信させます。私は長年、eeselが実際のサポートキューにAIエージェントを導入するのを見てきましたが、うまくいかない導入は、1週目にすべてをオンにしたものです。
| 週 | AIがすること | 測るもの |
|---|---|---|
| 開始前 | 本番では何もしない。20件のチケットを4つのステップで手作業計測し、過去のチケットにAIを走らせる | チケット種別ごとのAHTのベースラインとエージェントの稼働時間 |
| 1週目 | 1つのチケット種別で、要約と下書きを社内メモとして出す | 下書きの修正率、その種別のAHT |
| 2週目 | 下書きに検索（注文、アカウント）とナレッジリンクを追加 | 正しい注文と記事が入った下書きの割合 |
| 3週目 | キュー全体にトリアージと自動タグを追加 | 1チケットあたりの引き継ぎ回数、タグの正確さ |
| 4週目 | 最も下書きの質が高い一部のチケットに単独で返信 | AI返信の再オープン率、エージェントの総稼働時間 |
先に過去のチケットでAIを走らせることは、AIの語り口より重要です。eeselのすべての導入では、本番前にチームの実際の履歴に対してシミュレーションを実行します。自信ありげな誤答は、顧客が目にする前にそこで見つかるからです。「run a simulation on my recent tickets」のように普通の言葉で依頼でき、AIの回答がチームが実際に送った内容と照らして採点されます。すでに使っているヘルプデスクにAIを追加する場合は、既存ヘルプデスクへのAI導入のガイドで接続側を扱っています。
処理時間を短縮するAIの費用は？
多くのチームでは、節約できるエージェントの稼働時間より少ない額です。eeselのプランは毎月固定のクレジット枠で、eeselの料金ページによると、500クレジットが$299、1,000クレジットが$499、3,000クレジットが$1,149、5,000クレジットが$1,749です。1チケットは、返信が何回になっても、下書き、注文確認、解決のどれをしても1クレジットです。超過分は有効にした場合に1クレジット$0.80で、無料プランには実際のチケットで試せる100クレジットがあります。
見積もりツールの初期値では、月3,000件のチケットは$1,149の3,000クレジットプランに収まり、節約できるエージェントの稼働時間は約330時間です。料金モデルをより広く見るには、AIカスタマーサービスのコストの内訳とチケットあたりコストのベンチマークが、事業上の根拠づくりに役立ちます。
eeselが適さない場合：処理時間の大半がライブの電話対応なら、まず電話システムの通話要約から始めてください。eeselはヘルプデスクのチケットとチャットで動作するためです。また、お使いのヘルプデスクが連携一覧にない場合は、まずそれを確認してください。
処理時間の短縮にeeselを試す
担当者が時間を別のタブで使っているなら、eeselは、チケットを開く前に下調べをしてくれる新しいチームメイトのように働きます。Zendesk、Freshdesk、Gorgias、Help Scoutのキューに参加し、スレッドを読み、Shopifyで注文を確認し、ヘルプ記事を見つけ、空欄に印を付けた下書きを残します。担当者は確認して送るだけです。単独で完結できる一部のチケットには直接返信し、すべての操作はアクティビティログに表示されるので、承認、却下、監査ができます。
これは、STIL ClassicsがGorgias連携と注文確認で運用している構成であり、smavaが月27,000件のチケットでZendesk上で運用している構成です。ヘルプデスクを接続して、100の無料クレジットで自社のチケットに対する実際の下書きを確認できます。カードは不要です。
今週のキューでeeselを試すか、まず私がまとめたベストAIエージェント支援ツールの比較で全体を見てください。