カスタマーサービスの会話型AI: 2026年に本当に機能するもの

「カスタマーサービス向け会話型AI」が今、実際に意味するもの

裏側に決定木を持つチャットウィジェット、それが以前の定義だった。分岐を作り込み、顧客がそのどれかを選び、質問が木の外にあれば「担当者におつなぎします」と言われてキューに並ぶ。今もそういうものはたくさん稼働している。多くの人がこの言葉を聞いただけで身構えるのはそのためだ。それ以降に登場したものはかなり違っていて、私はAIエージェントとチャットボットの違いについて別途解説記事を用意しているほどだ。

2026年に登場しているものは、具体的に3つの点で異なる。

まず、マッチングではなく検索(リトリーバル)を行う。システムはヘルプセンターや過去のチケット、社内ドキュメントまで読み込み、目の前の質問に対する回答を組み立てる。Zendeskはマルチモデル構成でこれを80言語にわたって実行しており、同じリトリーバル方式は市場に出回っている本格的なAIカスタマーサービスチャットボットすべての土台になっている。

次に、アクションを実行する。最近のエージェントは注文を照会したり返品を開始したり、API呼び出しを通じてクレジットを付与したりできる。これは「回答する」から「解決する」への飛躍であり、返金対応向けAIが単なるデモではなくなるポイントでもある。同じ変化は注文追跡の自動化にも表れている。

そして、すでに使っているヘルプデスクの中で動く。ボットはもはや専用の受信箱を必要としない。内部メモを書き、返信を下書きし、タグ付けやルーティングも行う。こうしてAIによるチケット分類は付加機能から標準機能へと変わった。チケットの感情分析も同じ道をたどっている。

最後の行こそ、じっくり考える価値がある。失敗の形が変わったのだ。決定木ボットは派手に失敗し、顧客もそれに気づく。しかし会話型AIエージェントは、静かに、しかも流暢に失敗する。だからこそ、この後で触れるコントロール層のほうがモデル自体よりも重要になる。お金の話に入る前にカテゴリー全体を俯瞰したいなら、会話型AIプラットフォームのまとめで、誰が何を作っているかを確認してほしい。

ベンダーが料金ページに書かない部分

主要ベンダー6社、それぞれ異なる課金単位、しかもどれも互換性がない。これは2年前の自分に誰かが教えておいてほしかったことだ。

以下は、今週ベンダーの料金ページからすべて確認した公表数値だ。

この表の中で、このセクションの他の部分よりも重要なポイントが4つある。

Gorgiasは「解決」ではなく「インタラクション」に課金する。 見出しの$1.50は中間クラスに見えるが、「自動応答インタラクション」は解決よりも広い単位であることが分かる。つまり、AIが触れただけで解決には至らなかった会話にも課金されうるということだ。Help Scoutは逆の方向で、顧客がエスカレーションもせず「まだ助けが必要」もクリックしなかった場合に限り解決とみなす。価格はほぼ同じでも、売っているものは違う。

Zendeskは金額以外のすべてを説明している。 ヘルプセンターには自動解決の仕組みが詳しく書かれている。エージェント1人あたり月に5〜15件の解決枠が含まれ、どのプランでも年間の割り当て上限は10,000件。それを超えた分は、契約利用量を超えた分として明示的に課金される。しかし、金額そのものはどこにも出てこない。行き着く先はすべて営業への問い合わせで、これは私のZendesk AIの記事で読者がぶつかるのと同じ壁だ。

Salesforce自身の試算例も、計算が合わない。 Agentforceの料金ページにはクレジットあたり$0.005として5つのシナリオが載っており、そのうち4つは内部的に整合している。しかしVoiceの行だけは120クレジットで$0.15と表記されており、同じ計算なら$0.60になるはずだ。これはVoiceが異なる倍率で動いているためで、Salesforceも自社のFAQでその旨を説明し、別のレートカードを参照するよう案内している。それはそれでいいのだが、つまり公表されている例は本当の見積もりではないということでもある。この点は私のAgentforce料金ガイドでより詳しく取り上げている。

成果報酬型を謳うリーダー企業は、価格をまったく公表していない。 Sierraは「Pay for a job well done(良い仕事に対価を)」という見出しで成果ベース課金を打ち出しているが、サイト上に単位も料金もどこにも出てこない。Decagonもホームページで課金モデルを明示していない。どちらも実際に導入実績のある本物のプロダクトで、私のDecagonレビューで詳しく取り上げている。Sierraについても同様の記事がある。ただ、どちらも電話をかけない限り価格を比較検討できない。

自分の数字で計算してみる

この差は、実際の自社の件数を当てはめて初めてはっきり見えてくる。そこで、上記の公表レートをもとにした計算機を以下に用意した。

これは誤差の範囲ではない。月間1,000件の会話における、最安と最高額の差だ。それはもう1人分の人件費に相当する金額であり、しかも完全に「ベンダーがどの名詞に課金することを決めたか」だけで決まる。

買い手がこれに気づくのは、契約する時ではなく、使用量が増えていく途中であることが多い。

"The only thing I'd keep an eye on is the pricing. Once you start using more advanced automations or Lyro AI, costs can climb pretty quickly depending on how many conversations you're handling. It's not a deal-breaker, but it's definitely worth understanding how the limits work before you start scaling everything."

Alamgir H., Senior WordPress Engineer, G2

実際に本番稼働させると、数字はどう見えるか

50%から90%。これがベンダーの事例で示される解決率の幅だ。Decagonは8件の実名ブランドの数字を公表しており、Duolingoは80%のデフレクション、Chimeは70%の解決率となっている。Zendeskのページには、Best Eggの80%、Fortnum & Masonの90%が載っている。これらの企業にとっては実際の数字だ。しかしそれは、チューニングされた導入の「最終形」でもある。導入1か月目はまったく違う姿になる。

以下は、あるDTCアクセサリーブランドの本番Zendeskキューで行われたクロスバリデーション試験の結果だ。284件のAIチャットを、100件の実際のチケットと突き合わせて検証している。

トリアージは優秀だった。スパム検知は、22%がスパムだった受信箱に対して誤検知ゼロの100%を記録。カテゴリーが狭く絞られている場合、ドラフトの質は高く、返品・返金は93.8%が使えるレベル、保証請求は96.4%が使えるレベルだった。商品に関する問い合わせは100%だった。

それでも、無修正で送信されたドラフトはわずか12%だった。

「方向性は正しい」と「そのまま送れる」の間にあるこのギャップこそ、この分野で最も議論されていない数字だ。 これは失敗ではない。スコープを絞っていないエージェントが、雑多なキューの中で実際にどう動くかを正確に映し出した姿であり、だからこそ、正直な1か月目の目標は「全体の何パーセント」ではなく「Tier-1の一部分」であるべきなのだ。私が間近で見てきた、Jira Service Management上のある社内ITデスクは、55%という目標に対して15%のデフレクションにとどまっているが、モデルを入れ替えるのではなく、意図(インテント)を一つずつ広げていくことでその目標に近づいている。

その一方で、これも本物の話だが、スコープが狭ければ件数の多さは問題にならなくなる。あるeeselの顧客は、eesel自身の顧客実績によると、月間10万件を超えるチケットをすべてドイツ語で完全自動化したZendeskエージェントを運用している。また別の、Zendeskを使うギグエコノミー系のドライバー分析アプリの顧客は、7日間のトライアルの後、導入1か月目でTier-1リクエストの73%を解決した。どちらも「狭く、深く」であり、「広く、浅く」ではない。目標を決める前に指標の定義を知りたいなら、まずAI解決率から読み、次にAI CSATと組み合わせて見ることで、速いだけの誤答が「成功」に見えてしまうのを防げる。

数字についてもう一つ。これはあらゆる比較でつまずきの原因になるのだが、デフレクションと解決は同じ指標ではない。Decagonは両方を同じROIの枠の中で報告している。デフレクションとは、顧客が質問をやめたことを意味し、そこには諦めた顧客も含まれる。解決とは、顧客が実際に答えを得たことを意味する。私のチケットデフレクションの解説では両者をきちんと区別しており、解決率のレポーティングについての記事でも同様だ。この区別をしていないベンダーの表は、少なからず読者に不誠実だと言える。

実際に話してみた顧客たちの声

ウィジェットの向こう側にいる人たちの話も、購入前に読む価値がある。2026年の公開されている声は、「AIはダメだ」という漠然としたものではない。もっとずっと具体的だ。

そもそも自動化すべきだという主張は、たいていのベンダーが説明する以上に強力だ。サポート組織で働く親戚が2人いるという人の話を紹介する。

"My brother used to work at tech support for XBox Live.

He said that 80% of his calls were for password resets, something users can easily self-service. There's literally an option on the login form for "Forgot Password", and people would rather spend time calling up support, waiting on hold, and verifying their identity to a support agent than click a button. […] I have an uncle that works tech support for XFinity. Half his calls are resolved by just power cycling the modem/router."

Sohcahtoa82, Hacker News

これこそ、会話型AIが吸収するために存在する量そのものであり、AIヘルプデスクが得意とすることとほぼぴったり重なる。

反対意見は、実のところ回答の質そのものについてではない。回答が間違っていて、しかも抜け道がないときに何が起きるか、という話だ。

"The marketing team has 4 turns with an AI that refuses to escalate to a human and is convinced this is the only entry it needs us to add to our DNS. Dropped the vendor. Someone from their retention team followed up and we linked them the ticket talking to the bot about the obvious bug. Never heard back."

judgardner, Hacker News

4回のやり取りで契約解除。ボットがその契約を失ったのは、間違えたからではなく、逃げ道がなかったからだ。買い手のレビューにも、ツール内部から見た同じ限界が語られている。あるTidioのG2レビュアーは、複数ステップの質問ではボットが「想定より早く人間への引き継ぎが必要になることがある」と指摘している。これがこの技術の正直な姿であり、それを前提に設計することこそが仕事だ。

本当のボトルネックは精度ではなくコントロールだ

毎回、同じ場所で止まる。私が見てきた停滞案件は例外なく同じ場所で止まっており、その理由は決して「AIが賢くない」ではない。サポートリーダーが、「スコープできないものは監督できない」と気づく瞬間だ。

最もわかりやすい例は、GorgiasとShopifyを使う、月間約7,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. 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を通したくないチケットが確かにある」、「@eeselと明示的にメンションしたときだけ反応してほしい。作成時や顧客からのすべてのチケットメッセージには反応しないでほしい」。これはAIを信用していない人たちの声ではない。「つまみ」が欲しい人たちの声だ。Hacker News上の誰かが、私よりもずっと率直に同じ点を言い当てていた。

"The problem is not chatbot customer support, the problem is bird-brained managers that think a system that solves 99% of issues doesn't need a fallback for that 1%."

LorenPechtel, Hacker News

うまくいくパターンは、2段階のゲートを直列に並べることだ。まず除外リスト。請求に関する紛争、法律に関わる質問、一定額を超える返金は、そもそもAIに届かせない。次に確信度しきい値を設け、エージェントが自信を持てない案件は、顧客の受信箱への返信ではなく、担当者のキューにあるドラフトになるようにする。Zendeskもインテント確信度しきい値という形で、これと同種の仕組みを公開している。その周辺の引き継ぎ設計は、しきい値の数値そのものと同じくらい重要だ。

こう設定しておけば、「無修正で送信12%」という数字は不安要素ではなくなる。修正が必要だった88%は、そもそも監督なしで送信されることがなかったからだ。ゲートを設けずに運用すれば、あの7%の事実誤認率がそのまま顧客の目の前に届くことになる。仕組みの詳細は、ハルシネーション防止についての記事でさらに掘り下げている。

私ならこう導入する

4つのステップを、この順番で。この「順番」こそ、みんなが飛ばしがちな部分だ。

1. 何かを本番稼働させる前に、過去のチケットでシミュレーションする。 自社のクローズ済みチケット数百件に対してエージェントを実行し、それがどう答えていたかを読む。これは、自信満々の誤答をまだ無償のうちに見つけられるステップであり、eeselがシミュレーションをアドオンとして売るのではなく、オンボーディングに組み込んでいる理由でもある。これにより、ベンダーの数字ではなく、自分自身で裏付けられる解決率の見積もりも得られる。まず入力(インプット)を正しく整えることが役立ち、それがナレッジベースでのトレーニングの役割だ。

2. 狭くスコープし、それから広げる。 件数が最も多く、影響範囲が最も小さいインテントを2つか3つ選ぶ。注文状況やパスワードリセットなど。配送予定日もいいかもしれない。初日からお金や法律に関わるものには手を出さない。今のスコープでの数字が2週間安定してから、初めて範囲を広げる。AIでFAQをデフレクトするガイドは、最初のリストとして悪くない出発点だ。

3. 確信度しきい値は、最初の悪い返信が出た後ではなく、本番稼働の前に設定する。 まずは保守的に始めよう。狭いスコープに高いしきい値を設定すれば、誰も文句を言わない「退屈な」エージェントになる。それこそが1週目に欲しいものだ。しきい値は後からいつでも緩められる。真似する価値のある引き継ぎのベストプラクティスは、主に「緩めた瞬間に何が起きるか」についてのものだ。

4. 請求書ではなく、課金単位を見る。 どこと契約するにせよ、ベンダーが課金している対象そのものを計測すること。解決単位なら、それを台無しにするエスカレーション率を追う。インタラクション単位なら、AIが触れたのに解決しなかった件数を追う。それにも課金されるからだ。Zendeskは、顧客の沈黙が72時間続いた後にLLMチェックを経て初めて解決を確定させる。つまりその使用状況ダッシュボードは、実態から3日遅れているということであり、月間の上限を管理している場合はこれが重要になる。

今はまだ会話型AIを置かない場所

生き残る導入と、2か月目にスイッチを切られる導入の違いは何か? それは、これについて正直であることだ。

誤答が実際のお金の損失や法的リスクにつながるものは、少なくとも数か月分のデータが蓄積するまでは人間が担当すべきだ。規制対象のアドバイス、紛争、引き止めオファー付きの解約、チャージバックに関わるものすべてがそれにあたる。技術的には会話を成立させられる。問題は、あの7%のコストが非対称だという点にある。

繰り返し発生する件数がほとんどないキューも相性が悪い。すべてのチケットがオーダーメイドなら、リトリーバルする対象そのものがなく、節約できる以上のコストを設定作業に費やすことになる。複雑なエスカレーション経路は自動化する価値があるが、誰も見たことのない問題はそうではない。

公平を期すために、自社側の限界も挙げておく。eeselは、すでに使っているヘルプデスクの上に重ねる形で作られている。つまり、チケッティング、電話対応、ワークフォースマネジメントまで、すべてを1つの請求にまとめたフルスタックのヘルプデスクへの完全な置き換えを望んでいるなら、選択としては弱い。それは十分に理にかなった要望であり、その場合はZendeskのようなフルスタックのヘルプデスクのほうがうまく応えてくれるはずだ。Freshworks AIについても同じことが言える。また、eeselはネイティブのCrispやLiveAgent連携を持っていないため、そうしたスタックの上では「アドオン」ではなく「代替」という位置づけになる。

会話型カスタマーサービスにeeselを試す

まさにその「すでに使っているヘルプデスクの上に重なる会話型レイヤー」こそ、eeselがやっていることだ。Zendeskにそのままつながり、既存のマクロやヘルプセンター、クローズ済みチケットまで読み込む。Freshdesk、Gorgias、Front、Slackも同じ仕組みで動き、ほとんどのチームは30分以内に最初のエージェントを稼働させている。

ここまでの内容を踏まえて、特に2点を挙げておきたい。1つ目は、1人の顧客に返信する前に、自社のクローズ済みチケットに対してエージェントをシミュレーションできること。だから、マネージャーに提示する解決率の数字は、どこかの事例研究のものではなく、自分自身のものになる。2つ目は、eeselの料金では、1チケットまたは1チャットセッションあたり$0.40という単位で課金され、席料金もプラットフォーム料金もなく、返信単位ではなく対応した会話単位で課金されるということ。つまり、おしゃべりな顧客が無口な顧客よりコストがかかるということはない。カード登録不要で試せる$50分の無料利用枠もある。

まず代替案を見てから決めたいなら、私のZendesk AIの代替まとめが正直な出発点になる。より広い範囲のカスタマーサービスAIの比較記事では、その他の選択肢も網羅している。