「AIドリブン」が実際に意味すること
私はeeselのサポートキューで働いている。このフレーズはまったく異なる二つのセットアップを指して使われており、ほとんどの導入がつまずくのはまさにその二つの間の隙間だ。
一つ目はAIアシスト型だ。AIが下書きを書き、タグを提案し、スレッドを要約もするが、最終的な判断は人間が下す。これはヘルプデスクコパイロットのパターンであり、常に人間が最後の関門として残るためリスクが低い。
二つ目はAIドリブン型だ。ここではAI自体が関門となる。四つの判断が一気に移行する。チケットがどのキューに入るか、最初の返信に何を書くか、エスカレーションするかどうか、どうタグ付けするか。その間に誰も承認していない。
日々実際に何が起きるかという点では、この違いは背後にあるモデルが何かよりも重要だ。二つのチームがどちらもAIパワードカスタマーサービスを運用していると言っても、実際にはまったく逆のことをしている場合がある。これはAIエージェントと従来型チャットボットの違いと同じ構図が、一段階下のレベルで現れているだけだ。判断することとスクリプトに従うことの違いである。
人々がドリブン型に手を伸ばす理由は、正直かなり分かりやすい。ティア1の対応量は反復的だ。その上、バックログの処理を手作業でこなすのは苦痛な仕事であり、それこそがヘルプデスク自動化の売り文句そのものだ。退屈な半分は勝手に回る、という。しかし、まだ観察すらしていないシステムに、初日から四つの判断を一度に丸ごと渡してしまうと、下記のようなスレッドに行き着くことになる。
AIの精度に関する主張の読み方を変えた数字
私たちはあるドイツのオンラインジュエリー小売店で、クロスバリデーション付きのトライアルを実施した。ZendeskとShopifyをまたいで月間およそ1,000件のチケットを扱う相手だ。284件のチャットに加え、実際のトラフィックに対する100件のクロスバリデーションを行った。見出しの数字は良好だった。トリアージ精度93%。誤検知ゼロでスパム検出率100%で、しかもこの受信箱は実際には22%がスパムだった。下書きの88%が方向性として正しかった。
そしてここに、実際に重要だった数字が出てくる。**下書きがそのまま送信されたのはわずか12%**で、事実誤認率は7%だった。
88と12の間にあるこのギャップを少し噛み締めてほしい、指摘するだけの価値がある。AIはチケットを理解していた。正しいアプローチも選んでいた。そしてサポート担当者が原則的には同意できる内容の下書きを作成した。それでも、その同じ担当者は8回中7回、結局は書き直した。トーン、ポリシーの細部、リンク、あるいはそのブランドが返品時に使う特定の言い回しなどが理由だ。
このギャップは、私がこれまで読んできたどのベンダーの精度統計にも現れない。「正確」と「そのまま送れる」はまったく同じ基準ではないからだ。これはまた、サポートコミュニティで繰り返し見られるパターンも説明する。チームが機能をオンにし、痛い目に遭い、静かに一段階格下げする、というものだ。
"Auto-replies sounded great in theory, but once real tickets came in, it started giving confident but wrong answers. CSAT dipped quick. What worked better for us was using it as an agent assist, draft replies, summaries, tagging, not full auto mode."
ここで彼らがしたことに注目してほしい。完全に取り外したわけではない。ドリブンからアシストへと一マス後退させただけであり、そもそも最初からそこから始めるべきだったのかもしれない。同じスレッドの投稿者本人は、これのトリアージ版を次のように述べている。
"the ai kept misclassifying things like warranty claims as general inquiries... customers complained the responses felt too robotic and sometimes gave wrong info on returns. we rolled it back partially and now our agents are using it as an assist."
そして同じスレッドのFreshdeskユーザーは、あらゆるサポートマネージャーが不安に思うべき結末にたどり着いた。それは基本的に、実際に買ったものとは正反対の結果だったからだ。
"We tested an ai integration in freshdesk and had almost the exact same experience. it worked for very simple tickets but anything slightly complex got misclassified. agents ended up spending more time fixing errors than before, so we had to rethink our approach."
処理時間は増えた。AIがチケットの分類自体が下手だったからではなく、スイッチを入れる前に誰も修正作業の量を測っていなかったからだ。
誰も同じものに対して請求しているわけではない
ここが、最も厄介な部分になるとは予想していなかったところだ。そして正直に言えば、他の何よりも真っ先に確認すべき点でもある。
このカテゴリーのすべてのベンダーが使用量メーターを運用している。だがそのほとんどが、同じ出来事を計測しているわけではない。私は9社分の公開料金を調べたが、その単位はまったく比較にならない。
| ベンダー | 課金単位 | 公開料金 | メーターが作動する条件 |
|---|---|---|---|
| Zendesk | 自動解決 | 非公開 | エスカレーションなしで解決した場合のみ |
| Freshdesk | Freddyセッション | $0.49(100件あたり$49) | ボットが対応を試みた時点(解決の有無を問わない) |
| Gorgias | 自動対応 | 超過分**$1.50** | 自動対応1件ごと |
| Salesforce | 会話、またはアクション | $2.00、または$0.10 | 会話ごと、またはツール呼び出しごとの定額 |
| Ada | 解決または会話 | 非公開 | ベンダー独自の定義、見積もりのみ |
| Decagon | 会話または解決 | 非公開 | 顧客がモデルを選択 |
| Forethought | 名称不明の「アウトカム」 | 非公開 | ページ上で単位が明記されていない |
| Tidio | Lyro会話 | $0.70~$0.78 | Lyroからの返信1件、前払い |
| eesel | チケットまたはチャットセッション | $0.40 | チケット1件(返信回数は問わない) |
この表から、すぐに三つのことが浮かび上がる。
「セッション」は試みに課金し、「解決」は結果に課金する。ボットの動作は同じでも、請求書は変わる。 Freshdeskはかなり明確で、セッションとは対応のことであり、解決を保証するものではないため、いずれにせよ試みに対して支払うことになる。一方Zendeskは、その単位を「AIエージェントによって、人間への一切のエスカレーションなしに正常に解決されたリクエスト」にのみ課金すると定義している。買い手にとっては明らかに良さそうに聞こえるが、それも料金ページのどこにもその料率が公開されていないことに気づくまでの話だ。結局、安く聞こえる単位こそが、価格の付けようがない単位ということになる。
ベンダーは「解決」と「対応」をほぼ同じ意味で使うが、請求書に載るのはそのうちの一方だけだ。 Gorgiasの料金ページの見出しは「会話を解決したときだけ支払う」と約束しており、聞こえは良い。しかし、どのプランカードにも印刷されている$1.50というメーターは、解決ではなく自動対応に対するものだ。つまりその$1.50を他社の解決単位あたりの料率と比較しているなら、実際にはまったく異なる二つの出来事を比較していることになる。
一つのチケットに対して二つ、三つのメーターが同時に作動することもある。 Gorgiasは同じ月にチケットと自動対応の両方で超過することがある。Tidioは三つのメーターを同時に走らせており、Lyroが単独で対応したチャットはLyro会話を1件消費し、その後人間が介入して返信した瞬間に、課金対象の会話としてもさらに1件消費される。
<div class="adcs-panel adcs-p1">
<div class="adcs-row adcs-best"><div class="adcs-name">eesel<span class="adcs-unit">500チケット、$0.40換算</span></div><div class="adcs-num">$200</div></div>
<div class="adcs-row"><div class="adcs-name">Freshdesk<span class="adcs-unit">500セッション、すべて無料枠内</span></div><div class="adcs-num">$0</div></div>
<div class="adcs-row"><div class="adcs-name">Tidio Lyro<span class="adcs-unit">Lyro会話500件分を前払い</span></div><div class="adcs-num">$350</div></div>
<div class="adcs-row"><div class="adcs-name">Gorgias Advanced<span class="adcs-unit">バンドルされた530件の対応枠内の500件</span></div><div class="adcs-num">$477</div></div>
<div class="adcs-row"><div class="adcs-name">Salesforce Agentforce<span class="adcs-unit">会話500件、$2.00換算</span></div><div class="adcs-num">$1,000</div></div>
<div class="adcs-row"><div class="adcs-name">Zendesk<span class="adcs-unit">自動解決、料金非公開</span></div><div class="adcs-na">非公開</div></div>
</div>
<div class="adcs-panel adcs-p2">
<div class="adcs-row adcs-best"><div class="adcs-name">eesel<span class="adcs-unit">2,000チケット、$0.40換算</span></div><div class="adcs-num">$800</div></div>
<div class="adcs-row"><div class="adcs-name">Freshdesk<span class="adcs-unit">無料枠超過分1,500セッション、100件あたり$49換算</span></div><div class="adcs-num">$735</div></div>
<div class="adcs-row"><div class="adcs-name">Gorgias Advanced<span class="adcs-unit">バンドル$477に加え、1,470件を$1.50換算で追加</span></div><div class="adcs-num">$2,682</div></div>
<div class="adcs-row"><div class="adcs-name">Salesforce Agentforce<span class="adcs-unit">会話2,000件、$2.00換算</span></div><div class="adcs-num">$4,000</div></div>
<div class="adcs-row"><div class="adcs-name">Tidio Lyro<span class="adcs-unit">段階制プランは1,000件までで、それ以上は要問い合わせ</span></div><div class="adcs-na">非公開</div></div>
<div class="adcs-row"><div class="adcs-name">Zendesk<span class="adcs-unit">自動解決、料金非公開</span></div><div class="adcs-na">非公開</div></div>
</div>
<div class="adcs-panel adcs-p3">
<div class="adcs-row adcs-best"><div class="adcs-name">eesel<span class="adcs-unit">5,000チケット、$0.40換算</span></div><div class="adcs-num">$2,000</div></div>
<div class="adcs-row"><div class="adcs-name">Freshdesk<span class="adcs-unit">無料枠超過分4,500セッション、100件あたり$49換算</span></div><div class="adcs-num">$2,205</div></div>
<div class="adcs-row"><div class="adcs-name">Gorgias Advanced<span class="adcs-unit">バンドル$477に加え、4,470件を$1.50換算で追加</span></div><div class="adcs-num">$7,182</div></div>
<div class="adcs-row"><div class="adcs-name">Salesforce Agentforce<span class="adcs-unit">会話5,000件、$2.00換算</span></div><div class="adcs-num">$10,000</div></div>
<div class="adcs-row"><div class="adcs-name">Tidio Lyro<span class="adcs-unit">段階制プランは1,000件までで、それ以上は要問い合わせ</span></div><div class="adcs-na">非公開</div></div>
<div class="adcs-row"><div class="adcs-name">Zendesk<span class="adcs-unit">自動解決、料金非公開</span></div><div class="adcs-na">非公開</div></div>
</div>
</div>
<div class="adcs-foot">料金は各ベンダー自身の料金ページより、2026年7月27日時点で確認。Freshdeskは全プランで最初の500 Freddyセッションを含む。Gorgiasの数値はAdvancedプランのバンドルAIコンポーネントと$1.50の超過料金を使用。Salesforceは1アクションあたり$0.10のFlex Creditsメーターも販売しており、同社自身の計算では同じやり取りで$0.30~$0.60に相当する。シートライセンス料金はすべて含まれていない。</div>
5,000会話の時点で、最も安い公開料金と最も高い料金の差はおよそ5倍に達する。これは丸め誤差の違いではなく、品質の違いでもない。単純に単位の定義の違いだ。
「解決」は判断の産物であり、その判断で得をするのはベンダー自身だ
ここは公の論争にまで発展した部分であり、正直に言えば、ダッシュボードに何か目標値を設定する前に理解しておくべき最も重要な点だと思う。
Adaは自社サイト上でこの線引きを明確にしている。**コンテインメント(封じ込め)**はエスカレーションしなかった会話をカウントし、「諦めてしまったフラストレーションを抱えた顧客も含む」とされる一方、自動解決は関連性・正確性・安全性もクリアしているはずのものだ。二つの数字はまったく異なる意味を持つが、通常引用されるのはより甘い方の数字だ。
Decagonはさらに一歩踏み込んでおり、実際にこれを公表している点は大いに評価したい。彼ら自身の用語集は、解決の定義が「グレーゾーンや請求トラブル」を生むこと、月ごとの請求の予測可能性が下がること、そして会話を解決済みとして過剰に分類するベンダー側のインセンティブが存在することを認めている。これは実質的に、メーターに細工が入っていることをベンダー自身が率直に告白しているようなものだ。
サポートチームはこれを自力で見抜いた。Zendeskが自動解決ベースの料金体系に移行した際、r/Zendeskのスレッドは単刀直入にこう指摘した。
"the subjective part in the resolutions. who knows if the bot is just leaving the customer hanging and marking it as a resolution... the bot just didn't help the customer in anyway. they got agitated and abandoned the chat and it was considered a resolution"
そして、同じ不満をより構造的に表現したものがこちらだ。正直、この調査の中で読んだ中で最も鋭い指摘だった。
"What is defined as a resolution isn't really fair. If it's an abandoned deflection, it shouldn't count. Mechanisms to understand that aren't well-tuned. This creates an incentive misalignment where, theoretically, creating abandonment would make sense as it would maximize 'resolutions' as currently defined."
公平を期して言えば、どのベンダーも意図的に離脱を誘発しているとは思わない。しかしそのインセンティブの構造は現実に存在し、一度気づいてしまうともう見なかったことにはできない。AI解決率を品質指標として読むのをやめることになる。それはたまたま品質指標のように見えるだけの請求指標であり、同じ用心は引用されるあらゆるデフレクションの数字にも当てはまる。
代わりに私が追跡すべきだと思うもの、そして実際に社内で見ている指標はこうだ。
- AI対応チケットの再オープン率。 48時間以内に戻ってきた解決は、そもそも解決ではなかった。すべての数字の中で最も誤魔化しにくいものだ。
- 対応者別に分けたCSAT。 キュー全体のCSATは、優れた人間の仕事の裏にAIの問題を隠してしまう。だから分けて見るべきだ。
- エスカレーションされたチケットの顧客努力度。 最終的に人間にたどり着くまでに、ボットとのやり取りに何往復費やしたか。
- 下書きの編集率。 私たちの12%という数字がこれにあたる。下書きが書き直され続けるなら、AIは担当者の時間を節約するどころか、むしろ奪っていることになる。これを逸話任せにせず、サポートQAレビューに組み込むべきだ。
これらはどれも特別なものではなく、その気になれば大抵のヘルプデスクが今日にでも報告できる数字だ。ただデフレクションほど見栄えが良くないだけであり、だからこそスライドの先頭に来ることは決してない。
AIドリブンなサポートが真価を発揮する場面
ここまで4つのセクションにわたってこのカテゴリーに厳しく当たってきたので、少し公平に見てみよう。ここでの成果は本物であり、具体的でもある。
スパムとトリアージ。 あのジュエリー小売店の受信箱は22%がスパムで、AIはそれを誤検知ゼロで100%捕捉した。これはわずかな改善ではなく、キューのまるまる5分の1を人間がそもそも見る必要がなくなったということだ。93%というトリアージ精度も、正直に言えば金曜午後5時の疲れ切った人間の大半が出せる精度を上回っている。
反復的なティア1の対応量。 Zendesk上で動くギグエコノミー向けドライバー分析アプリのGridwiseは、7日間のトライアルですでに成果を見た後、初月でティア1リクエストの73%をeeselが解決したと報告している。Jira Service Management上のInDebtedの社内ITヘルプデスクは、目標55%に対してデフレクション15%にとどまっているが、これこそが誠実な導入の、より典型的な姿だ。プレスリリースのような話ではなく、地に足のついた、段階的な成果である。
カテゴリー別の下書き作成。 同じトライアルでは、カテゴリー別の下書きの有用性が、商品に関する問い合わせと返金状況で100%、保証請求で96.4%、返品・返金で93.8%という結果になった。AIは範囲が狭く、文書化がしっかりした質問には優れていたが、それ以外はまずまずといったところだった。これは判定というより、対象範囲をどう決めるべきかの指針だ。
そして、実際にうまくいったチームからの、これに対する釣り合いの取れた声はこうだ。
"Ada is able to take on the small stuff. So much of support is made up of monotonous, easy-to-answer inquiries... Ada handles the majority of those inquiries, so our team is able to handle the big stuff... it has cut our teams response time into a third of what it was pre-Ada."
これらの成果はどれも同じ形をしている。範囲が狭く、量が多く、文書化された回答があることだ。「とりあえずキュー全体に向けて様子を見る」というようなものでは、まったくない。
うまくいくかどうかを左右する制御設定
この記事から運用面で一つだけ持ち帰るとしたら、これにしてほしい。決め手となる機能はモデルではまったくない。AIに「判断してはいけないこと」を伝えられるかどうかだ。
これについて私が聞いた中で最も明快な言葉は、GorgiasとShopifyを運用し、月間およそ7,000件のチケットと30,000件の注文を扱うDTCサプリメントブランドのCXリードのものだった。
"The AI will never be able to answer 100% of the questions, but if it tries and just answers 'sorry I don't know this,' I cannot go and check all my 7,000 tickets to see if the AI actually made a good answer, then the point is a little bit gone. I need an AI who is only handling the tickets that it's confident to handle and all the other ones, leave them alone."
まさにそこが、その商談における決定打だった。精度でも、価格でも、連携機能でもない。AIに自分の持ち場を守らせられるかどうか、それだけだった。当時、私たちには十分に精緻な確信度ベースのルーティングがなく、その商談を失った。そしてそれこそが、プロダクトの作られ方を変えることになる類いの出来事なのだ。
要求する価値のあるゲートを、以下の順に挙げる。
- チケットタイプ除外。 請求関連の紛争、法務、セキュリティ、しきい値を超える返金など。当社の管理者の一人はチャットでこう率直に述べていた。「AIを通したくないチケットが確かにある」。これは機能リクエストではなく、当然設定であるべきだ。
- 調整可能な確信度しきい値。 これを下回るとAIは送信せず下書きにする。購入前にそのツールがそもそも意図確信度しきい値を公開しているか確認すること。公開していないツールも数多くある。
- 明示的な呼び出し。 別の評価担当者はまさにこれを求めていた。「@eeselに言及したときだけ応答してほしい。作成時や、すべての顧客チケットメッセージに反応してほしくない」。すべてのチケットに反応するかどうかは選択の問題であり、それはあなた自身が決めるべきことだ。
- きれいな引き継ぎ。 コンテキストを完全に引き継ぎ、顧客が同じことを繰り返さなくて済むようにする。引き継ぎポイントを適切に設定することは、デフレクションの数字を押し上げることよりも重要だ。
- 実際に学習するフィードバックループ。 理由を添えて下書きを却下すれば、次の下書きが変わるべきだ。それが実務におけるAIエージェントのコーチングの意味だ。
上のスクリーンショットは、私が最もよく使うバージョンだ。設定パネルを掘り返す代わりに、ルールを平易な英語でエージェントに伝えるだけで、エージェント自身が指示を書き換える。この例では、Zendeskでタグ付けされたときは、内部メモを残すのではなく、常に顧客向けの返信を下書きするというものだ。
数字を正直に保つための導入順序
これは私自身が実行するであろう手順であり、ほとんどのオンボーディング資料が示すものより意図的に遅いペースになっている。
- まず過去のチケットに対してシミュレーションする。 顧客が一件でも何かを目にする前に、すでにクローズしたチケットに対してエージェントを走らせ、その回答をチームが実際に送った内容と比較する。私たちがこのステップを組み込んだのは、本番環境で自信満々に間違った回答をするボットを目撃してきたからであり、一度でも十分すぎるほどの経験だった。
- 最低2週間は下書きモードで運用する。 精度ではなく編集率を追跡する。担当者がほとんどの下書きを書き直し続けているなら、それはモデルの問題ではなくナレッジの問題であり、自動返信をどれだけ増やしても解決しない。
- 範囲を広げる前にナレッジを整える。 Agentforceに関するG2レビュアーは、この失敗パターンをうまく言い表している。「コンテンツバージョンファイル(ナレッジ記事)が2021年以降更新されていなければ、AIエージェントは自信満々に古い情報を顧客に伝えてしまう」。最新のナレッジベースで学習させること、それが実際の作業の大半を占める。
- ちょうど一つのカテゴリーだけ自動返信にする。 下書きの有用性が最も高いものを選ぶ。ここでは大抵、注文状況が答えになる。その後2週間は再オープンを注視する。
- カテゴリーは一度に一つずつ広げる。 注文追跡、次に返品、その次に保証。チケットルーティングは自動返信より速く範囲を広げてよい。誤ったルーティングは数分のコストで済むが、誤った返信は信頼を失うからだ。
- 初日に支出上限を設定する。 同じAgentforceのレビューは、そうしなかった場合に何が起きるかを説明している。エージェントが「ループに陥ったり、休暇シーズンの予期しないトラフィック急増に対応したりすると、クレジットの『デジタルウォレット』は想定より早く枯渇しかねない」。上限設定は地味だが、週末を救ってくれる。
ステップ2は最もよく飛ばされるステップだが、実際に報われるのもこのステップだ。この記事の中で私が驚いたことはすべて、AIが送ろうとしていた内容を、実際に私たちが送った内容のすぐ隣で読んだことから生まれている。
AIドリブンなカスタマーサービスにeeselを試す
私たちはもう何年もAIエージェントを実際のサポートキューに投入してきた。月間10万件以上のチケットを完全自動化したSmavaのドイツ語Zendeskエージェントや、Zendesk、Slack、ウェブサイトをまたいで月間1万件以上をこなすEcosa(事例紹介)といった導入事例がその例だ。この記事に書かれていることの大半は、まさにこうした導入から得た生傷そのものだ。
eeselは、もし自分が買い手だったら絶対に譲れないと思う二つのことを軸に作られている。第一に、エージェントは満足できるまで下書きモードで動作するため、あなたがその内容を読む前に何かが顧客に届くことはない。第二に、単位は解決ではなくチケットだ。対応したチケットまたはチャットセッション1件あたり$0.40、返信回数は問わない。シート料金もなく、Enterprise以外ではプラットフォーム料金もない。離脱したチャットを課金対象の勝利として再分類する余地は誰にもない。そもそも再分類するものが何もないからだ。
Zendesk、Freshdesk、Gorgias、Front、Jira Service Management、Slackと連携し、すでに手元にあるConfluence、Notion、Googleドキュメント、そして過去のチケットのナレッジも読み込む。ほとんどのチームは約30分で最初のエージェントを稼働させている。クレジットカード不要で$50分の利用枠が無料になり、1チケット$0.40で計算すると、実際のチケット125件分を試して判断できる。
デモ用のキューではなく自分自身のキューで確かめたいなら、無料で始めて先月のチケットに向けてみてほしい。編集率だけでも、どんなベンダーのベンチマークより多くのことを、たった一日の午後で教えてくれる。
よくある質問
AIドリブンなカスタマーサービスとは何か?
AIドリブンなカスタマーサービスは1チケットあたりいくらかかるのか?
解決率はAIカスタマーサービスを測る良い指標か?
AIサポートにおけるデフレクションと解決の違いは何か?
AIドリブンなカスタマーサービスは小規模なサポートチームでも機能するか?
AIカスタマーサービスは最初に自動返信モードと下書きモード、どちらで運用すべきか?
Article by
Riellvriany Indriawan
Riell is a designer and writer at eesel AI with about two years of experience researching CX platforms, AI chatbots, and helpdesk software. She combines her design background with a sharp eye for how these tools actually look and feel in practice — making her comparisons unusually visual and user-focused.
