AIエージェントでカスタマーサポートを自動化する方法: 7ステップの導入手順

要点

AIエージェントでカスタマーサポートを自動化するなら、チャネル別ではなくチケットの種類別に自動化します。まずは、ヘルプコンテンツですでに答えられる、件数が多くリスクの低いチケットから始めましょう(注文状況、パスワードのリセット、ポリシーに関する質問)。スパムは完全に対象外にし、お金が動くものは必ず人の承認を挟みます。

うまくいく順序は次のとおりです。先月のチケットを種類別に分類し、エージェントが読むナレッジを整え、既存のヘルプデスクの中に接続し、承認設定つきでいくつかのアクションを与え、お客様が返信を1通も目にする前に過去のチケットを再生して試し、引き継ぎを設計し、1つのトピックずつ本番に出して、解決数だけでなく再オープン数も測ります。

eesel のAIヘルプデスクチームメイトは、まさにこの道筋のために作られています。Zendesk、Freshdesk、Gorgias などに接続し、過去のチケットから学び、本番前にそれらを再生して自分で採点できます。100件の無料チケットで試せます。

AIエージェントでサポートを自動化するとは、実際にどういうことか

サポート向けのAIエージェントは、多くのチームが覚えている定型返信ボットとは別物です。チケットを読み、情報を調べ(ヘルプセンター、過去の返信、Shopify の注文)、自分で対応できるかを判断し、そのうえで返信する、タグ付けや返金といったアクションを実行する、あるいはメモを添えて人に引き継ぎます。マクロやルールベースのサポートワークフローにも出番はありますが、意図を読み取るのはエージェントの役割です。

私は eesel で連携の開発をしています。エージェントをヘルプデスクにつなぎ、注文システムを呼び出せるようにするコードです。どの導入でも最初に思い知らされるのは、自分たちのキューの中身を誰も把握していないということです。eesel は長年、実際のヘルプデスクのキューでAIエージェントを動かしてきました。Zendesk と Shopify を使うドイツのジュエリーECブランド(月約1,000件、8言語)のチケット構成を集計したところ、顧客への直接サポートはわずか38%でした。22%がスパムで、21%が社内のB2Bのやり取りでした。もし「受信トレイ」にAIを向けていたら、労力の5分の1はゴミに費やされていたでしょう。

だからこのガイドは、ソフトウェアではなく分類から始めます。まだツールを選んでいる段階なら、同僚の Riell がAIエージェントの選び方という姉妹記事を書いています。この記事は、1つ動かしたい人向けです。

ステップ1: ツールに触れる前に、キューをチケットの種類別に分類する

直近30〜90日のチケットをエクスポートし、お客様が何を求めていたかでグループ分けします。タグも役立ちますが、タグはずれていくので、念のため100件ほどを目で確認してください。各グループを2つの軸で採点します。どのくらいの頻度で来るか、間違った回答が出たときの影響がどれほど大きいかです。

このパターンは業界を問わず繰り返されます。eesel 自身の営業の場で、1日500件以上のチケットを扱う複数ブランドのEC事業者は、キューの大半が返金依頼、配信停止、注文追跡だと語りました。月に約7,000件の Gorgias チケットを抱えるDTCのサプリメントブランドは、メールの少なくとも半分をAIに任せたいと考え、同じ3つの区分を挙げました。注文はどこか、定期購入の変更、基本的な商品の質問です。

よくある種類を私ならこう採点します。

目立つパターンが2つあります。1つ目は、「最初に自動化する」山のほとんどが、ヘルプコンテンツですでに答えられる質問だということです。だから注文状況チャットボットは定番の最初の成功例になります。2つ目は、スパムは別枠にすべきだということです。ベンダーが示す「自動化率」を水増ししますし、チケット単位の課金ではお金を払いたくありません。きちんとしたチケットのトリアージとAIによるサポートのタグ付けがあれば、この分類は一度きりのスプレッドシートではなく、繰り返せる仕組みになります。

ご自身の数字を入れて、導入の各フェーズで何件をカバーできるか確かめてください。

ステップ2: 接続する前にナレッジを直す

エージェントの正しさは、読む内容の正しさを超えられません。私が見てきた「AIがハルシネーションを起こした」という話の多くは、モデルではなく元の資料に原因がありました。

ほぼすべての設定の打ち合わせで、3つの問題が出てきます。

• AIが読める場所にないナレッジ。 そのDTCのサプリメントブランドは、実際の手順を ClickUp の手順書、文字起こしされていない Loom の動画、古いマクロの山に置いていました。初日のエージェントが学べるものは何もありませんでした。
• 読み手を間違えたヘルプコンテンツ。 あるサポートマネージャーは、ナレッジベース全体が管理者向けに書かれている一方で、チケットはエンドユーザーから来ると話しました。答えは技術的にはそこにあるのに、実際には役に立たない状態です。
• 曖昧な表現が、自信たっぷりの誤答になる。 B2B技術サポートのチームは、ヘルプセンターに「すべての車種に対応」と書かれていたため、データベースにない車種についてもボットが「はい、お客様の車種に対応しています」と答えてしまうことを心配していました。AIは文字どおりに読みます。私でもそうするでしょう。

解決策は地味ですが、効きます。件数の多いチケットの種類の裏にある20本の記事を更新し、ベテランの頭の中にしかないポリシーを書き出し、古いものは削除します。ナレッジベースでの学習のガイドでさらに掘り下げ、AIのハルシネーションのガイドでガードレールの面を扱っています。

ナレッジのもう半分は、過去のチケットです。チームが解決した返信は、トーンや例外、「その手数料はたいてい免除する」といった判断も含め、実際にどう答えているかの最も正確な記録です。すべてのツールがこれを読めるわけではありません。

最良の答えがヘルプセンターではなく過去のチケットにある場合(B2Bや技術サポートでよくあります)、この列を重く見てください。Confluence、Notion、Google Docs をつなげば社内ドキュメントをカバーでき、過去のチケットは誰も文章にしていないことまでカバーします。

ステップ3: チケットがすでにある場所にエージェントをつなぐ

エージェントは、チームがすでに使っているヘルプデスクの中に置いてください。別のAI用受信トレイは、確認する場所が増え、ログインが増え、チームが身につけなければならない習慣が増えるということです。私の経験では、その習慣は定着しません。

大きく分けて2つの選択肢があります。ヘルプデスク内蔵のエージェントは、ナレッジソースと料金に満足できるなら最短の道です。ヘルプデスクの上に載せるレイヤーなら、過去のチケットからの学習が加わり、ツールを乗り換えても一緒に移れます。自社開発か購入かのガイドで、より広いトレードオフを扱っています。

eesel では、エージェントは Zendesk、Freshdesk、Gorgias のほか、HubSpot、Help Scout、Front、Salesforce、Jira Service Management などに接続します。

各ヘルプデスクには2つの接続モードがあります。Quick start は公開ヘルプセンターだけを読み、フル接続では過去のチケット、マクロ、トリガー、アクションが加わります。

見た目以上に大事な点が1つあります。接続することは、本番に出すことではありません。eesel のドキュメントは、接続は "only lets your agent read your helpdesk. It does nothing on tickets until you create an automation." と明言しています。つまり、お客様への影響ゼロで、ナレッジを読み込み、実データでテストできる安全な期間があるということです。接続ボタンを押す前に、お使いのツールも同じ仕組みか確認してください。

ターミナルやコーディングエージェントから設定する

画面をクリックして進めるよりスクリプトで導入したい場合は、eesel CLI が同じ設定をコマンドとして実行します。ダッシュボードと同じエージェントであり、別のコピーではありません。ターミナルで設定したことはダッシュボードに表示され、その逆も同様です。

npm install -g @eesel/cli
eesel login
eesel integrations connect zendesk        # a person approves it inside Zendesk
eesel integrations sources zendesk        # what's there: help center, macros, tickets
eesel integrations download start zendesk # copy those sources into the agent's knowledge
eesel integrations zendesk actions        # every action, with its approval setting
eesel automations                         # what the agent does on its own
eesel approvals                           # held actions waiting on a human
eesel activity                            # what the agent has been doing, newest first

zendesk を freshdesk や gorgias に置き換えれば、流れは同じです。すべてのコマンドはJSONを出力し、書き込み系は --dry-run で実際のサーバー呼び出しを送信せずに表示でき、エラーは代わりに実行すべきことを示す hint つきの1行JSONで返ります。そのため、Claude Code、Cursor、Codex といったコーディングエージェントが設定全体を実行し、自分で結果を読めます。eesel はコーディングエージェントからの設定ガイドで手順を説明しています。CI やサーバーでは、ブラウザログインの代わりに EESEL_API_URL と EESEL_API_TOKEN を使います。すべてのワークスペースはMCPサーバーでもあります(eesel mcp token で、そのまま貼れる claude mcp add の行が出力されます)。

サポートオペレーションのリーダーにとっての実利は、導入手順がレビューでき、再実行でき、同僚に渡せるスクリプトになることです。ターミナルからのカスタマーサポート向けCLIやAIエージェントの管理についても、さらに書いています。

ステップ4: アクションをいくつか与え、お金がかかるものには関門を置く

話すだけのエージェントは、お客様に「返品手続きを始めました」と言っておきながら、実際には始めません。回答を解決に変えるのがアクションです。注文の照会、タグの追加、フィールドの更新、返金、キャンセル。主要なツールはどれも対応していますが、作りは異なります。

• Zendesk は4種類のアクションを挙げています。設定済みアクション、ノーコードの連携ビルダーで作るAPI連携、アクションフロー、カスタムアクションです。注文照会や返金には、自社システムに対してその連携を作る必要があります。
• Gorgias は、Shopify を接続すれば、注文のキャンセルや配送先住所の編集といった Shopify アクションを追加設定なしで使えます。
• Freshdesk はワークフローを使い、注文状況や返金のテンプレートライブラリと、外部システム向けのAPIアクションブロックがあります。
• eesel はアクションを "a permission list, not a workflow" として扱います。各アクションはエージェントごとに、自動、承認が必要、無効のいずれかに設定します。設定は Actions and Approvals で行います。標準連携のないシステムには、Network Access により、許可したドメイン上の自社REST API(GET、POST、PATCH、DELETE)をエージェントが呼び出せます。認証情報はヘッダーとして保存され eesel が付与するので、AIがそれを目にすることはありません。

G2 の Ada のレビュアーは、エージェントが学習範囲外の約束をすることがあると述べ、Reddit の開発者はさらに悪い例を挙げています。どちらも、ステップ5のテストが言葉だけでなくアクションまで対象にすべき理由を示しています。

"...offering actions it isn't actually able to perform (for example, canceling orders). Fortunately, these issues have been easy to correct with additional coaching and updates, and its accuracy has continued to improve over time."

Verified User, Consumer Goods, G2

"the biggest failure i've seen was an agent that kept pulling data from the wrong user's account because the session token wasn't being passed correctly to the api call, the text responses looked perfect so nobody caught it until a customer complained about seeing someone else's balance"

u/properwomanhood_292, r/AI_Agents, Reddit

連携側から見た私のルールはこうです。読み取りのアクションは早い段階から自動で動かしてよいが、お金が動くもの、取り消せないものは人を待つ。eesel のドキュメントも、もっと平易な言葉で同じことを述べています。"Keep refunds, cancellations and anything that costs money behind an approval."

実際には下の画面のようになります。読み取りアクションは自動にまとめ、タグの追加、担当割り当て、チケットのクローズといった書き込みアクションは承認が必要に設定し、社内メモはチームにしか見えないので自由に実行させます。

承認は速くなければ機能しないので、チームがすでにいる場所に置いてください。eesel は、ダッシュボード、メールやヘルプデスクのメモのリンク、ターミナル(eesel approvals)、MCPクライアント、そして Slack に承認を送れます。Slack では、保留中の返信とタグが、承認と却下のボタンつきカードとして表示されます。こうした関門の設計をさらに詳しく知りたい場合は、サポートの承認ワークフローのガイドをご覧ください。

ステップ5: どのお客様も返信を見る前に、過去のチケットを再生する

ベンダーのデモはベンダーの質問を使います。本番ではあなたの質問が使われます。このギャップを埋める最も安価な方法は、すでに解決したチケットにエージェントを走らせ、エージェントが言ったであろうことと、チームが実際に送ったことを比べることです。

各ツールでどこまでできるか。

• Zendesk には会話シミュレーター(早期アクセス、メッセージングのみ)があり、自分で書いたシナリオから会話を生成します。架空のデータ向けに設計されています。
• Gorgias は Playground で既存のチケット1件を再実行できます。注意書きにご注意ください。アクションをオンにしていると、テストが "can affect real customer and order data." とあります。
• Freshdesk は、メールAIエージェントに解決済みの過去チケットをインポートさせられます。評価1回につき最大50件で、回答済み、未回答、エラーで採点されます。
• eesel は、"replays your past tickets and scores its answers against what your team actually sent" というシミュレーションを実行し、優先順位つきの修正案とチケットごとのレポートを出します。ドキュメントの手順例では、サンプルの20件中17件が一致しました。

どのツールを使うにしても、失敗は1つの平均ではなく、トピック別に読んでください。全体で70%でも、注文状況は95%、返品は30%ということがあります。それは、注文状況を先に出し、返品の記事を直すべきだということです。そして再実行します。接続、テスト、修正、再テストのループであり、盛り上がっているチームが最も飛ばしがちなステップです。

再生だけでは拾えないテスト項目がもう2つあります。レイテンシとチャネルの使用感です。eesel のトライアルで、あるバイヤーは67項目の丁寧な評価を行い、回答は堅実だと認めたものの、チャットウィジェットが遅くしばしば固まるために見送りました。実際の会話をいくつか、最初から最後まで時間を計ってみてください。

ステップ6: 引き継ぎを、製品の一部のように設計する

サポート自動化の被害の大半は、回答ではなく引き継ぎで起こります。問題は2つあります。エージェントが引き継ぐのが遅すぎる(あるいは引き継がない)ことと、引き継ぎを受けた人がゼロから始めることです。

1つ目の問題では、キーワードのルールは罠です。

"ours were way too optimistic at first, basically "escalate if it's billing or if they use certain keywords" and that missed like half the situations where a human was actually needed"

u/Salt-Question8632, r/CustomerSuccess, Reddit

モデル自身の確信度だけでも足りません。

"The model sounds surest right before it's wrong, so we hand off on visible states like the same order asked twice."

u/arslannasir128, r/AI_Agents, Reddit

だからトリガーは重ねてください。ツールが検知するシグナル(怒り、人への明示的な要求、センシティブな話題)、平易な言葉で指定するトピック(チャージバック、法務、VIPアカウント)、目に見える状態(同じ質問が2回、再オープンされたチケット)、そして「自信がない」ルートを組み合わせます。たとえば Gorgias は、怒り、明示的な要求、センシティブな話題で必ず引き継ぎます。この動作はオフにできず、そのうえで引き継ぎのトピックを自分で書きます。eesel は、自信が低い、顧客が怒っているといった、あなた自身の指示に従ってルーティングし、自信の低い回答は本番の返信ではなくレビュー用の下書きになります。

バイヤーは、この点を他のどの設定よりも重視します。eesel との打ち合わせで、あるサポートマネージャーは要望のすべてを一文にまとめました。

"create an application that will be able to handle 60% of the incoming zendesk tickets and know when to pull a real person in for better analysis and resolution."

2つ目の問題、ゼロから始める人については、トランスクリプトではなくメモを渡してください。r/customerexperience のある投稿者は、構造化された引き継ぎサマリーを必須にしたら "saved more time than the automation itself." と気づきました。

運用面の細部が2つあります。Zendesk のエスカレーションフローは、エスカレーション前に注文番号、名前、メールアドレスを集めてタグを付けられます。また、対応可能時間のブロックで営業時間外の動作を変えられるので、午前2時のお客様には、誰も守らない約束ではなく、はっきりとした「営業時間外です」が届きます。

これらのパターンは、AIエージェントの引き継ぎのベストプラクティスとAIエスカレーションでさらに詳しく扱っています。Zendesk 向けには、人への引き継ぎの設定方法の手順解説もあります。

ステップ7: 段階的に展開し、お客様の体感を測る

eesel のほぼすべての導入で見られ、創業者の Amogh が営業の場から指摘する導入パターンは、まずコパイロット、その後に完全自動化です。最初はエージェントに返信を下書きさせ、信頼できるようになったトピックから自動に切り替えます。eesel のドキュメントは、これを3つの動きとして示しています。下書きから始める、簡単なものに答えさせる、準備ができたらさらに広げる。

各フェーズの内容と、次に進むための条件は次のとおりです。

小さく始めるほうが、思われている以上にうまくいきます。eesel を使う英国のサポートチームは、同期したわずか9つのマクロからエージェントに56件のタスクを解決させ、トライアル終了から1か月以上たっても毎日使っていました。ドイツのイベント会社は、エージェントに実際のチケット10件を完全オートパイロットで処理させ、すべての返信が文脈に合っているか確認し、その後396件のドイツ語の実チケットを通しました。そして eesel のお客様である Gridwise は、G2 のレビューで、7日間のトライアルのあと最初の月に、eesel がティア1のリクエストの73%を解決していたと書いています。

フェーズ1には、実際に時間をかける覚悟をしてください。この G2 のレビュアーの体験は、特定のツールに限らず、どのツールにも当てはまります。

"The main downside is that it takes some time to set up and fine-tune everything properly. At the beginning, you need to review the responses quite closely to make sure they match your tone and business rules."

Verified User, Logistics, G2

本番稼働後に測るもの

どのベンダーも真っ先に出すダッシュボードの数字は、解決率かデフレクション率のどちらかの形です。追跡はしてください。ただし、そこで止まらないでください。お客様が諦めたことで「解決」になるチケットもあるからです。

"Companies call it "deflection." Customers call it being ignored."

PostHog support team lead, X

"leadership might see metrics showing that the AI service agent successfully helped with 80% of the questions it is asked, but they don't realize how damaging that 20% is."

cortesoft, Hacker News

私が毎週見るスコアカードは次のとおりです。

eesel のレポートは、ナレッジギャップ率をAI評価の品質スコアと並べて表示します。このAI CSATは、モデルが自分の返信を採点したものであり、実際のお客様の評価ではない点は知っておく価値があります。ヘルプデスクのアンケートデータと組み合わせてください。

指標一式についてはAIサポート指標をご覧ください。経理から聞かれたときは、AIサポートのROIのフレームワークが、これらを金額に変えてくれます。

避けたい失敗

• チャネル別に自動化する。 「チャットでAIをオンにする」では、パスワードのリセットとチャージバックが一緒くたになります。チケットの種類別に自動化しましょう。
• スパムを成果として数える。 受信トレイの20%がゴミなら、それを閉じるエージェントは、誰も助けずに大きな自動化の数字を出せます。指標からも請求からも除外してください。
• ベンダーの質問でテストする。 自分たちの解決済みチケットを、見栄えの悪いものも含めて再生してください。
• エージェントに、実行できないアクションを約束させる。 アクションをつなぐか、引き継ぐよう指示し、実際にそうなるかテストしてください。
• すべてを一度に本番化する。 1トピックで、再オープン率がきれいなら、次へ進みます。
• ナレッジベースを放置する。 古い記事はすべて、自信たっぷりの誤答になって、即座に届けられます。

eesel でヘルプデスクを自動化する

Zendesk、Freshdesk、Gorgias、その他のヘルプデスクでこれから始めるなら、eesel のAIヘルプデスクチームメイトは、まさにこの手順のために作られています。既存のヘルプデスクに参加し、ヘルプセンターに加えて過去のチケットからも学び、本番前にそのチケットを再生して自分で採点し、すべてのアクションを、実行、承認待ち、オフのいずれかに設定できます。eesel によると、ほとんどのチームは30分以内に最初のエージェントを本番に出しており、触れたすべてのチケットはアクティビティログで追えます。

料金は、解決数やメッセージ数ではなく、処理したチケット数で決まります。開始時に100クレジットが無料で、その後は500チケットで月額299ドルから。スパムや、無視するよう指示したチケットには課金されません。何かを支払う前に、実際のキューでフェーズ1を試してください。

eesel を試す