AI導入はなぜうまくいかなくなるのか
私は毎日eeselのサポートキューを担当しているので、チームがAIエージェントをオンにした後に何が起きるかを見ています。最も心配なパターンは、壊れたモデルではありません。情報の空白に対して自信満々に答えるモデルです。
実際の例です。ZendeskでBtoBの技術サポートを行うチームが、ボットに「このお客様の車種に対応していますか」と尋ねました。ボットは、データベースにないブランドについても「はい」と答えました。ヘルプ記事に「全車種に対応しています」と書かれていたからです。モデルに壊れたところはありませんでした。壊れていたのは記事です。別の有料顧客のボットは、ナレッジベースが何も返さないと一般的な学習データから回答し、ある顧客には周期表から拾った「Oxygen」と返信したこともありました。
だからこそeeselは現在、AIが1通でも返信を送る前に、すべての導入を過去のチケットでシミュレートします。自社の過去チケットを再生すれば、顧客より先にナレッジベースの穴が見つかります。
以下のミスは、そのキュー、サポートリーダーが前のツールで何がまずかったかを語ってくれる営業の電話、そしてベンダーのドキュメントから拾ったものです。ゼロからのセットアップ手順はAI導入ガイドにあります。この記事は、ローンチ日までに整えておくべきことのリストです。
ミス1:ディフレクションを解決として数える
ディフレクションとは、その会話で顧客が人間に到達しなかったことを意味します。問題が解決したかどうかは何も語りません。諦めた顧客も、翌日に再度連絡してきた顧客も、実際に返金を受けた顧客も、ディフレクションのグラフ上では同じに見えます。
ベンダーのレポートもこれをぼかすことがあり、ダッシュボードを作る前にその仕組みを知っておく価値があります。Zendeskは、メッセージング用AIエージェントがエスカレーションを試みたものの対応可能なエージェントがおらず、フォローアップ用のチケットを作成して自ら会話を終了させたケースを文書化しています。この場合、会話ステータスはAutomated resolutionと表示され、カスタムフィールドはEscalated to agentと表示されます。Zendesk自身の説明によるものです。顧客はまだ待っているのに、ラベルの1つは解決済みと言っています。
Zendeskの課金は、この線引きを慎重に行っています。2026年5月18日に導入された解決の階層では、「assisted escalation」と「contained resolution」は利用枠に数えられません。数えられるのは「verified resolution」のみで、LLMがトランスクリプトを確認し、依頼が解決されたことを裏付けた場合に限られます。これは公正な課金モデルです。大事なのは、自社の成功指標にも同じ厳密さが必要だという点です。
r/customerexperienceの実務者が、この違いを的確に表現しました。
"Silence alone is a dangerous proxy for resolution. It's useful operationally, but it's not an experience signal. A bot answer + 72 hours of no follow-up mostly tells you the customer gave up or moved on, not that the problem was fixed."
対策: ローンチ前に「解決」の意味を決めましょう。私の実務上の定義は、示せる結果(返金が行われた、住所が変更された、回答が確認された)があること、または30日以内に同じ問題での再問い合わせがないことです。計算式が必要なら、同僚がAI解決率とディフレクション率を詳しく解説しています。
ミス2:AIに推測で穴を埋めさせる
AIエージェントが答えを見つけられないとき、選択肢は2つあります。そう伝えて引き継ぐか、それらしく聞こえるものを作り出すかです。どちらにするか指示していなければ、後者だと考えてください。
公になっている例はよく知られています。Hacker Newsでは、Cursorのサポートボットが存在しないログインポリシーをユーザーに伝えた後の、同社開発者の返信が引用されました。
"Hey! We have no such policy. You're of course free to use Cursor on multiple machines. Unfortunately, this is an incorrect response from a front-line AI support bot."
また、カナダの審判所がAir Canadaに、チャットボットが作り出した返金ポリシーを守るよう命じたとき、あるコメント投稿者は、サポートリーダーが考えるべき形でそのコストを捉えました。
"In this case this could have just been a $650 'bug bounty' had Air Canada issued a quick refund. A reasonable QA expense to find out that your AI agent is misleading your customers."
私が信頼する構成は、ルールを書き出しています。英国のナンバープレート販売会社Swiftregは、チーム自身が書いたルールのもとでZendesk上でeeselを運用しています。ライブの照会はナレッジベース、過去チケット、顧客の発言のいずれよりも優先されます。eeselは、照会で確認できていない返金、発送、DVLAへの提出を報告することはなく、検証ツールが送信前にすべての返信を照会結果と突き合わせ、公開返信の末尾には、AIが書いたものであり誤りを含む可能性がある旨のフッターが付きます。
対策: 「回答が見つからない」場合の明確なフォールバック(引き継ぐ、または担当者が確認すると伝える)、ライブデータが文書に優先するというルール、そして絶対に約束してはいけないことの短いリストをエージェントに与えてください。設定はハルシネーション防止のガイドに、情報の空白がなぜ大半の原因になるかはこちらの解説にまとめています。
ミス3:人間に連絡しにくくする
逼迫したキューを守るために「担当者と話す」という選択肢を隠すチームがあります。その事情は理解できます。それでも裏目に出ます。ボットのループから抜け出せない顧客は消えません。もっと怒って、別のチャネルから戻ってきます。
この設定はどの主要ヘルプデスクにもあるため、これは事故ではなく選択です。ZendeskのAIエージェントでは、メッセージングの動作タブに「Add option to talk to a human」というチェックボックスがあり、会話の開始時、役に立った返信・立たなかった返信の後、そしてAIが答えられないときに表示されます。Zendeskの引き継ぎ設定の記事によるものです。Gorgiasは、AI Agentが自信を持って返信できないとき、センシティブな話題に当たったとき、苛立ちを検知したときに引き継ぐと説明しており、引き継ぎルールはAI Agentの設定で自分で追加できます。
r/CustomerSuccessのスレッドで、「talk to a human」と入力された場合にボットは転送すべきかという質問がありました。最上位の回答は、私も引くであろう線を引いていました。
"Deflection is the bot solving the issue so well the person never needs a human. Obstruction is hiding the exit to protect the queue. The first reduces volume sustainably, the second just moves the pain (and usually amplifies it, like you described)."
対策: 明確な依頼があればすべて引き継ぎ、依頼のたびにシグナルとして記録し、「担当者がほしい」から実際に担当者が返信するまでの時間を見てください。同じコメント投稿者が指摘するように、チャットの40%が人間への依頼で終わるなら、問題はボットではなく、その背後にあるコンテンツや製品の摩擦です。Zendesk側の手順は人間への転送の解説に、一般的なパターンはチャットボットのエスカレーションにあります。
ミス4:散らかった、または古いナレッジベースを与える
AIエージェントの鮮度は、誰かが最後にヘルプセンターを直した時点で決まります。冒頭の車種ボットはナレッジベースの問題でした。マーケティング向けに書かれた大雑把な一文を、機械が文字通りに読んだのです。
よくある原因は、互いに矛盾する重複記事、Slackでは変わったのにヘルプセンターでは変わっていないポリシー、エージェント向けに書かれた記事(「管理画面を確認してください」)が顧客に引用されることです。Gorgias自身のゴーライブガイドには、AI Agentを有効にする前に少なくとも1つのナレッジソースが必要だとあり、ゼロから始めるなら書かれたガイダンスから始めるよう勧めています。それだけコンテンツが重要だということです。
過去のチケットはここで大いに役立ちます。ヘルプセンターがどう答えるべきと言っているかではなく、チームが実際にどう答えているかが分かるからです。eeselはヘルプデスクに接続すると、記事に加えて過去のチケットも読み込みます。Freshdeskを使うドイツのアウトドアフィットネス企業Original Bootcampは、約1,700のWebサイトページと1,100件のFreshdeskのチケットと記事をもとにeeselに回答させています。
対策: ローンチ前に、上位20のチケットトピックで短いナレッジベース監査を行い、重複を削除または統合し、ポリシーが変わったときに誰がAIの情報源を更新するかを決めてください。最後の点はポリシー変更管理のガイドで、情報源についてはAIの学習にどんなデータが必要かで扱っています。
ミス5:話せるが何もできないAI
サポートチケットの多くは質問ではなく依頼です。この注文をキャンセルしたい、この住所を変更したい、この請求書を再送してほしい、といったものです。ヘルプセンターを引用することしかできないAIは、返金を求めた人に「返金の依頼方法はこちらです」と答えてしまいます。
この穴は、再生テストが最も早く見つけてくれます。解決済みのZendeskチケット20件で実行したeesel Simulationの結果です。20件中17件がチームの返信品質に一致し、主要な発見は文面とはまったく関係ありませんでした。
「本当の課題は言葉ではなく、アクションです。」一致したチケットの約半数は、返金、ログインのリセット、メールアドレスの修正に、依然として人間が必要でした。3か月目ではなく1週目に分かることは貴重です。
逆のミスも同じくらい現実的です。信頼する前に、お金やアカウントへの書き込み権限をAIに与えてしまうことです。Redditの個人SaaS創業者は、エージェントにサポートチケットを自動返信させたところ、初日に承認していない返金が2件出たため、その夜に権限を外し、シンプルなルールにたどり着きました。「If money moves, a human clicks the button」(r/SaaS)。Gorgiasもテスト会話のドキュメントで、テスト中にAI Agentがアクションを使うと実際の顧客データや注文データに影響しうると警告しており、テストには架空の顧客プロファイルを使うよう促しています。
Original Bootcampは中間の道を示しています。予約、支払い、会員のアカウントに触れるものは、eeselがまだそのシステムを参照できないため、現時点では担当者に回されます。会社の新しいAPIが接続されれば、そのフィルターは開放される予定です。
対策: キューで最も多い5つの依頼を挙げ、AIが読み取ってよいもの、変更してよいもの、常に担当者に回すものを決めてください。まずは読み取り専用の照会から始めましょう。アクションの接続方法は、Gorgias AI AgentのアクションとAIエージェントのAPI連携の記事で扱っています。
ミス6:実際のチケットではなく作り物の質問でテストする
多くのチームは、答えをすでに知っている質問を10個打ち込んでAIエージェントをテストします。AIは合格します。それはヘルプセンターが想定している質問だからです。実際の顧客は、スクリーンショットだけを付けて注文番号なしで「hi my thing broke again??」と書いてきます。
ベンダーは便利なテストツールを提供しており、それぞれテスト対象が違います。
| ツール | 何に対してテストするか | 知っておきたい点 |
|---|---|---|
| Zendesk 会話シミュレーター | 顧客プロファイルと、自分で書く(またはプロンプトからAIが書く)シナリオから生成されるマルチターンの会話 | アーリーアクセスプログラム、メッセージング用AIエージェントのみ、架空データ向けに設計 |
| Gorgias Playground | 入力した任意のメッセージ(新規顧客、既存顧客、既存チケットとして) | 無料でレポートに影響しない。「既存チケット」を選ぶと、設定変更後に実際の会話を再実行できる |
| eesel Simulation | 実際の過去チケットまたは生成したテストケースのまとまり | チームが送った返信と照らして各回答を採点し、指示の変更を提案する |
Gorgiasの「既存チケット」オプションは優れていますが、あまり使われていません。完全な再生との違いはカバー範囲です。自分で書いたシナリオは、すでに予想していたことをテストします。先月のチケットのまとまりは、顧客が実際に送ってきたことをテストします。どちらも実行する価値があります。ただし、誰も書き留めようと思わなかった質問について教えてくれるのは後者だけです。
優れた再生結果は、AIが何を正しく答えたかだけでなく、何を引き継ぐべきかも示します。上の実行では、人間が必要だった2件(学年が誤った200人の生徒のインポートと、学校からのパイロット依頼)が正しくエスカレーションされました。これは合格です。
対策: 解決済みチケットを少なくとも数週間分再生し、スコアをトピック別に分け、最も弱いトピックをローンチ前に直してください。敵対的なエッジケースは敵対的テストで扱っており、Freshdeskのチームは設定変更にサンドボックス設定も使えます。
ミス7:顧客を最初からやり直させる引き継ぎ
「顧客が担当者を希望」としか書かれていない引き継ぎは、ほとんど引き継ぎとは呼べません。顧客はすべてをもう一度説明し、エージェントはAIがすでに確認したことを再確認し、会話全体はAIがいなかった場合より長くなります。
Zendeskのエスカレーションガイドは、エスカレーション前にAIが、注文番号、氏名またはメールアドレスなどの情報を集め、タグを追加し、フィールドを更新し、適切なエージェントを特定することを勧めています。これは正しいリストです。
"If someone explicitly asks for a human, blocking the transfer usually hurts more than it helps. The real challenge isn't deflection, it's routing with context so the human doesn't start from zero."
Swiftregの構成は、内部ノートでこれを実現しています。チケットの一部がスタッフの担当になる場合、eeselは残りに返信し、担当者が持つ部分には内部ノートを残します。ある月には、約2,100件のZendeskチケットに対して1,494件の公開返信と1,055件の内部ノートを残しました。Original Bootcampは私の気に入っているルールを加えています。メッセージにケガや病気への言及があれば、予約の質問に答えられる場合でも担当者に回すというものです。
対策: 4つの項目(誰か、何を尋ねたか、AIが何を確認したか、担当者が何をすべきか)を持つ引き継ぎテンプレートを作り、再生用のチケットでテストしてください。文言の例はAIエージェントの引き継ぎのガイドに、フロー全体は会話デザインの例にあります。
ミス8:初日から完全な自律運用をオンにする
営業の電話で最もよく聞く懸念は、価格ではなくコントロールです。サポートリーダーはたいてい一度痛い目を見ており、AIには対応できるチケットだけを引き受けてほしいと考えています。月に約7,000件を扱うGorgias上の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."
Gorgias + ShopifyのDTCサプリメントブランドのCXリーダー、eesel営業電話より
これが段階的な導入の根拠です。まずAIが書いて人が送るドラフトモード、次に限定したトピックでの自動返信、そして次のトピックへと進みます。
smavaは、私が挙げられる最も分かりやすい例です。2024年12月からZendesk上でeeselを運用しており、2つのブランドにまたがって月に約27,000件のチケットを扱っています。2026年8月8日から9月8日の間、出力が人の承認を待つドラフト作成エージェントは約12,200件のチケットで稼働しました。顧客向けにそのまま使える回答を用意する返信エージェントが引き受けるのは、顧客に担当アドバイザーが割り当てられていないチケットのみで、約1,100件でした。対象となるチケットのルールは1つのフィールドで決まるため、範囲を広げるのはプロジェクトではなくテキストの編集で済みます。
Gorgias自身のゴーライブのチェックリストも、より小さな規模で同じ方向を指しています。最初の週に、AI Agentが対応したチケットを少なくとも10件レビューし、外れたものにフィードバックを返しましょう。
対策: ドラフトを2週間運用し、エージェントがドラフトを無修正で送る頻度を追跡してください。自動返信は、無修正率が最も高いトピックだけでオンにします。ドラフトモードはカスタマーサービス向けAIコパイロットで、Freshdeskでの使い方はFreshdeskのAIドラフト返信で解説しています。
ミス9:ローンチをゴールだと考える
返品ポリシーは変わります。新製品が出ます。配送業者が追跡ページを変えます。これらはどれも、AIの回答の一部を一夜にして誤りにし、再問い合わせが積み上がるまで誰も気づきません。
Gorgiasは、AI Agentの改善を、会話タイプを1つずつ回すトレーニング、テスト、デプロイ、分析のループとして説明しており、引き継ぎ率30%の返品スキルが次のループの目標になるという例を挙げています。Swiftregはさらに踏み込んでいます。eeselの指示は番号付きのリリースとして管理され、次のバージョンは候補ビルドとラベル付けされ、本番で直接編集するのではなく、Swiftreg自身の手順でロールアウトされます。
プライバシーも、契約前のセキュリティレビューだけでなく、この継続的な作業に含まれます。Zendeskは、会話シミュレーターが架空データ向けに設計されており、テストプロファイルに実名やメールアドレスを使わないよう求めていると述べています。自社のチェックでも、AIが何を読めるか、チケットに何を書き戻すか、ログを誰が見られるかを確認してください。Zendesk固有の事情はZendeskのAIエージェントとデータプライバシーの記事で扱っています。
対策: 毎月のレビューをカレンダーに入れましょう。先月のチケットで再生テストをやり直し、同じ問題で戻ってきたチケットをすべて読み、AIの指示に手を付ける前にナレッジベースを更新してください。何が悪かったかを仕分ける方法はカスタマーサポートのエラー分析にあります。
AIエージェントはローンチの準備ができていますか?
正直に「はい」と答えられるゲートにチェックを入れてください。未チェックのゲートごとに、ローンチ前に行う修正が表示されます。
最初の30日間で測るべきこと
AIが稼働を始めたら、私なら次の数字を1ページにまとめます。どれもディフレクション単独ではありません。
| 指標 | 何を捉えるか | 読み方 |
|---|---|---|
| 結果に裏付けられた解決 | 勝利として数えられた静かな諦め | 返金が行われた、注文が変更された、または顧客が確認した |
| 同じ問題での再問い合わせ(7日・30日) | 誤った、または不完全な回答 | 特定のトピックで増えているなら、古い記事か欠けているアクションがある |
| トピック別の引き継ぎ率 | AIの準備ができていないトピック | 高いトピックは失敗ではなく、次に直すべきもの |
| 人間への依頼から人間の返信までの時間 | 隠された、または人手不足の出口 | ここの数字が悪いと、どんなボットの回答よりも信頼を損なう |
| ドラフトの無修正率 | そのトピックが自動返信に進める状態か | 率の高いトピックは昇格させ、残りはドラフトのままにする |
| AIのみの会話と人間対応の会話のCSAT | トーンや品質の差 | 平均を混ぜず、2つを比較する |
r/CustomerSuccessのあるコメント投稿者が、私ならすべてのローンチ用ダッシュボードに加える指標を挙げました。
"The metric I'd watch is request-for-human to human-response time. If that number is bad, or people keep reopening on another channel after the bot, you're not deflecting demand, you're just hiding queue pain."
ベンダーが何に対して課金するかを知っておくことも役立ちます。経理部門が最初に見るのは課金単位だからです。
| ベンダー | AIの課金単位 | 公表価格 |
|---|---|---|
| Zendesk | Automated resolution(2026年5月18日以降は検証済みの階層のみ) | コミット時$1.50、従量課金$2.00(Zendeskの料金による) |
| Gorgias | Automated interaction(AI Agentが引き継ぎなしで解決した場合) | プランにより$0.85~$1.00(Gorgiasの料金による) |
| Freshdesk | Freddy AI Agentセッション(メールのセッションは72時間の枠) | 最初の500セッションは1回のみ含まれ、以降は100件ごとに$49(Freshdeskの料金による) |
| eesel | クレジット:返信や照会の回数にかかわらず、チケット1件またはチャット1件 | 500クレジットで月額$299から(eeselの料金による) |
各指標の詳しい定義はAIカスタマーサービス指標のガイドに、アンケート面はAIのCSATに、お金の面は解決あたりのコストにあります。
30日間の導入計画
一般的なメールとチャットのキューで私が進める順番は次のとおりです。ヘルプデスクの接続は数分で済み、1か月の大半は、トピックごとに信頼を積み上げることに使います。
- 1~5日目:接続と整理。 ヘルプデスクとナレッジソースを接続し、上位20トピックを監査し、フォールバックルール、約束禁止リスト、引き継ぎテンプレートを書きます。
- 6~8日目:再生。 解決済みチケット数週間分でAIを実行します。最も弱いトピックを直し、もう一度再生します。
- 9~22日目:ドラフト。 AIが対象となるすべてのチケットでドラフトを作成し、エージェントが承認、編集、却下します。トピック別の無修正率と、エージェントが何を変えるかを追跡します。
- 23~30日目:1トピックを本番化。 無修正率が最も高いトピックで自動返信をオンにします。人間への選択肢は見える状態を保ち、再問い合わせを毎日確認します。
- 30日目以降:ループ。 トピックを1つずつ追加し、毎月再生をやり直し、ポリシーが変わったトピックはドラフトに戻します。
各ステップの詳細はAIでサポートを自動化するガイドにあります。まだツールを選んでいる段階なら、購入面はAIエージェントの選び方とAIヘルプデスクの購入基準で扱っています。
ミスなくeeselを導入する
eeselは、すでに運用中のZendesk、Freshdesk、Gorgiasのキューに加わるAIヘルプデスクチームメイトで、その導入は上記の順序に沿って設計されています。何かを送る前に、Simulationスキルが過去のチケットを再生し、チームが実際に送った返信と照らして各回答を採点します。その後ドラフトを作成し、エージェントが承認し、自動返信は実績を積んだトピックに限ってオンになります。ルールは平易な言葉で自分で書けます。
これが、smavaが人にドラフトを承認してもらいながら月に約27,000件のZendeskチケットを運用している方法であり、Swiftregがライブの照会だけでナンバープレートの注文に回答している方法です。ヘルプデスクを接続し、料金を支払う前に自社のチケットで実際のドラフトを確認できる100クレジットが無料で付いてきます。eeselを試して、今週中に最初の再生を実行してください。