生成AIによるカスタマーサービス:実際の仕組みを解説

「カスタマーサービス向け生成AI」が実際に意味すること

この言葉はまるで一つの決まった意味を持つかのように使われがちなので、ここで正確に定義しておきます。これまでのサポート自動化はルールベースでした。誰かが手作業で決定木を作り(「メッセージに『返金』という単語が含まれていればフローBを表示する」など)、ボットはそれに従っていました。これは、顧客が人間らしい自然な言い回しで話すまでは機能していましたが、そうなった瞬間に崩壊しました。

生成AIはこの構造を根本から覆します。大規模言語モデルは、キーワードをスクリプトに一致させるのではありません。顧客のメッセージを読み取り、自社で管理するナレッジソースから関連する事実を取得し、新しい返信を生成します。同じエージェントが、「注文はどこにありますか」という質問にも、「ノルウェーへの発送は可能ですか、関税はどうなりますか」という質問にも、どちらのフローも事前に構築することなく答えられます。

もう一つ見落とされがちな点があります。生成エージェントの品質は、ほぼ完全に何を与えるかによって決まるということです。一般公開されているインターネットで学習したモデルは、自社の返品ポリシーや「この車種にはまだ対応していません」といった注意事項については何も知りません。優れたエージェントは、解決済みのチケット、ヘルプセンター、そして回答が存在するツールから学習するため、何年分ものサポート履歴が初日から使えるナレッジになります。このグラウンディングこそが、もっともらしく聞こえるだけのカスタマーサービスにおけるAIと、実際に正しいAIとの違いを生みます。

生成AIが実際にチケットに回答する仕組み

裏側では、1件のチケットが短いパイプラインを通過します。この仕組みを理解することで、どこで問題が起きるのかを判断できるようになります。

1. チケットが届きます。 ヘルプデスク、チャットウィジェット、メールなど、現在チケットが届いている場所そのままです。
2. エージェントがコンテキストを取得します。 接続されている情報源、ヘルプドキュメント、過去のチケット、そして連携先からの注文状況などのライブデータを検索し、この特定の質問に関連する事実を探します。このステップは「検索拡張生成(RAG)」と呼ばれ、グラウンディングがこれほど重要である理由です。
3. 返信を作成します。 モデルを使い、自社のトーンで、取得した事実を裏付けとして返信を作成します。
4. 自らの確信度を採点します。 確かな情報源を実際に見つけたのか、それとも無理に答えようとしているのか。これはもっとも過小評価されているステップであり、安価なツールが省略してしまう部分です。
5. 振り分けます。 確信度が高ければ自動解決できます。少しでも不確かなものは、人間のエージェント向けの返信案になるか、顧客に触れることなく静かにエスカレーションされます。

このAIカスタマーサービスのワークフローは、Eコマースのチャットバブルを運用している場合でも、社内ITのAIチケッティングシステムであっても、ほぼ同じです。ベンダーによって異なるのは、ステップ2とステップ4をどれだけ自分でコントロールできるかという点です。

実際に得意なこと

多くの実際のキューでこの仕組みを見てきた結果、生成AIが一貫して力を発揮する領域は以下の通りです。

繰り返しの多いティア1業務を減らす。 「注文はどこにありますか」「パスワードのリセット方法は」「返金の期限はいつまでですか」といった質問は、件数が多く、判断の難易度は低いものの、人間が何百回も答えるのは苦痛です。ここがまさに得意分野です。あるギグエコノミー系の分析チームはZendeskを使っており、eeselにより初月でティア1リクエストの73%を解決し、その成果は7日間のトライアル期間内に現れました。

エージェント向けに返信案を作成する(コパイロット方式)。 AIが顧客と直接やり取りする準備がまだ整っていないチームも多く、それは問題ありません。コパイロットとして運用すればよいのです。AIが返信案を作成し、人間が確認して送信します。リスクを負うことなくスピードだけを得られ、エージェントは編集のたびに学習します。EcosaのCTOであるWesley Wang氏は、まさにこの複数ソースを使った返信案作成を活用していました。

「eesel AIを選んだ理由は、マルチチャネルでのデータ入力オプションを提供していたからです……CSV、Zendesk、Google Docsをソースとして連携することで、たとえ情報が分散していても、膨大なドキュメントを最大限に活用できています。」

Wesley Wang, CTO, Ecosa(導入事例)

トリアージとタグ付け。 回答をしない場合でも、生成エージェントは受信したチケットを読み取り、タグを付け、優先度を設定し、提案する返信を内部メモとして残すことができます。これにより、人間は何もない状態のチケットではなく、半分解決された状態のチケットを引き継げます。これだけでも、チームのAIチケット分類業務のかなりの部分を削減できます。

採用不要の多言語対応。 モデルは翻訳済みの文字列を検索するのではなく生成するため、同じナレッジベースをもとに顧客の言語で回答できます。以前は本格的な多言語対応サポートエージェントといえば、各タイムゾーンごとにネイティブスピーカーを採用することを意味していました。

オンボーディングと社内ナレッジ。 Confluenceや社内wikiに向けて活用すれば、サポート担当者向けのカスタマーサービス向けAIコパイロットになります。ある決済会社はドキュメントにこれを導入し、回答を探す時間と新入社員のオンボーディングにかかる時間を最大80%削減できたと報告しています。

「eeselのおかげで、質問に対する具体的な回答を非常に速く見つけられるようになりました。新入社員のオンボーディングも非常に速くなり、最大80%の時間削減を実現しています。」

Alex Capurro, Chief Innovation Officer, Global Pay(導入事例)

どこで失敗するのか、そしてそれを防ぐ方法

このセクションはほとんどのベンダーサイトが避ける部分なので、ここでは正直に書きます。自信満々に聞こえるボットが、静かに間違った回答をしているのを何度も見てきました。だからこそ、うまくいくケースだけを見せるデモは信用していません。

根本的な失敗はハルシネーションです。モデルが実際には根拠のない質問に対して、流暢でもっともらしい回答を生成してしまう現象です。ある車両テレマティクス企業のチームはこれに直面しました。ボットが、データベースに存在しない車種に対しても「はい、その車種には対応しています」と気軽に答えてしまったのです。ナレッジベースに「すべての車種に対応しています」と書かれていたためです。モデルが壊れていたわけではありません。誰も埋めていなかったナレッジのギャップの中で、指示された通りに動作していただけです。

解決策は2つあり、両方とも必要です。1つ目は引用によるグラウンディングです。エージェントは自社の情報源からのみ回答し、どのドキュメントを使用したかを示すべきです。そうすることで、間違った回答が原因不明のままではなく、追跡可能になります。あるリーガルテック企業の創業者が言うように、間違いのコストが高い場合には「情報源に関する正確なガードレール」と透明性のある引用が必要です。

2つ目、そしてこれが購入担当者が最も気にする点ですが、確信度に基づくルーティングです。この分野を検討しているCXリーダーから最もよく聞くのは、次のような声です。「AIは100%の質問に答えられるわけではないし、7,000件のチケットを遡って、AIが回答を試みたものが本当に良かったのかを一つひとつ監査することはできない。だから、確信が持てるものだけを処理し、それ以外には手を出さないでほしい。」まさにこれがすべてです。

優れたエージェントであれば、このしきい値を設定し、特定のチケット種別を自動化の対象から完全に除外し、人間への明確な引き継ぎを定義できます。劣ったエージェントは、すべてに自動返信して、うまくいくことを祈るだけです。この違いこそが信頼を左右するすべてであり、何かを本番稼働させる前にサポートにおけるAIハルシネーションを防ぐ方法を読んでおく価値があります。

実際にかかる費用

料金体系は、生成AIによるカスタマーサービスにおいてもっとも分かりにくい部分です。ベンダーによって課金の単位がまったく異なり、その単位のほうが見出しの金額よりも重要だからです。

解決件数課金の落とし穴は微妙なところにあります。AIの性能が上がるほど支払いは増え、コントロールできない量の急増は、コントロールできない請求額を意味します。月間1,000件のチケットを解決率80%で処理しているチームは、約792ドルを支払うことになるかもしれません。同じチームがブラックフライデーで4,000件に急増した場合、何も変えていないのに請求額は3,000ドルを超えてしまう可能性があります。

eeselはチケット1件あたり0.40ドルの利用量課金により、この問題を回避しています。席数課金もプラットフォーム料金も最低利用料金もありません。1,000件のチケットを処理するチームの月額は約400ドルで、静かな月は安い月になります。自分の数字でシミュレーションしたい場合は、AIサポートエージェントの費用の内訳で計算方法を解説しています。また、支出だけでなく価値を測るために、AIカスタマーサービスの指標も合わせて確認する価値があります。

信頼を損なわずに導入する方法

ここが、成功するチームと1か月後にひっそりとオフにしてしまうチームを分ける部分です。技術そのものが単独で失敗することはほとんどありません。失敗するのは導入の進め方であり、たいていは誰かが初日から本番の顧客に対して未検証のエージェントを向けてしまい、痛い目にあうというパターンです。

実際に私が従う手順は次の通りです。

1. 本番前にシミュレーションする。 過去の数千件のチケットに対してエージェントを実行し、どのような回答をしたかを確認します。顧客に一切触れることなく、カバー率の見積もりとギャップのリストを得られます。ベンダーがこれを見せられない場合は、警戒すべきサインです。
2. まずはコパイロットとして導入する。 返信案のみを作成し、送信は人間が行います。チームはアウトプットへの信頼を築きながら、エージェントは修正のたびに学習していきます。
3. 自律性は限定的に付与する。 シミュレーションですでに精度が高いと確認できたチケット種別、つまり注文状況やパスワードリセットのようなものについてのみ自動返信をオンにします。判断が必要な事案は人間に任せます。
4. ループを観察する。 承認、却下、そして人間が介入せざるを得なかった箇所を追跡し、フィードバックとして反映します。ここが、1か月後に何かが漏れていたと気づくのではなく、カスタマーサービスKPIを守る部分でもあります。

この段階的な進め方こそが、価値が積み上がっていくAIと、チーム全員から信用されなくなるAIとの違いを生みます。AIナレッジベースチャットボットを立ち上げる場合でも、完全な自動チケット解決を目指す場合でも、この流れは同じです。詳しくはカスタマーサポートにおけるAIと自動化の実践ガイドで一通り解説しています。

自社構築か購入かは、最後に触れておくべき分岐点です。自分でモデルをドキュメントに接続することはできますが、グラウンディング、ルーティング、そしてナレッジを最新に保つ手間を考慮すると、多くのチームはメンテナンスに見合わないと感じています。GENERAL BYTESのKarel氏は次のように述べています。

「自分たちでLLMアプリケーションを開発することもできましたが、そこに時間を投資したくありませんでした。メンテナンスの必要がないものが欲しかったのです。」

Karel, GENERAL BYTES(導入事例)

生成AIによるカスタマーサービスにeeselを試す

ここまで読んでいただければ、私が何を選ぶかはもうお分かりかと思います。eesel AIは、Zendesk、Freshdesk、Gorgias、HubSpot、Frontなど、すでに利用しているヘルプデスクにそのまま接続できる生成AIサポートエージェントです。初日から過去のチケットやヘルプドキュメントから学習し、この記事全体で解説してきたコントロール、つまり情報源の引用、確信度に基づくルーティング、チケット種別の除外、そして実際の顧客が一人も見る前に、実際の履歴に対してどのように機能するかを正確に示すシミュレーションモードを使って、ティア1業務を処理します。

約183,000件のやり取りと160以上の稼働中アカウントを見ても、成り立つパターンは地味なものです。まずシミュレーションを行い、コパイロットとして開始し、段階的に自律性を付与したチームは、ティア1解決率73%という数字を手にします。一方、すべてを一気にオンにしたチームは、悲惨な体験談を語ることになります。クレジットカード不要で50ドル分の利用枠から無料で始められ、その後は1件あたり0.40ドルの従量課金です。試してみるコストはコーヒー1杯分程度です。以下は、Zendesk内で実際に稼働しているeeselです。

もう少し読み進めたい場合は、カスタマーサービス向けAIの概要や、AIカスタマーサービスソフトウェアのまとめが次に読むのに適しています。あわせて、サポートチーム向けの会話型AIのメリットについての詳しい解説もご覧ください。