カスタマーサポート向け生成AIチャットボット:仕組みを解説

生成AIチャットボットの正体

私は仕事としてAIエージェントを作っているので、この用語からマーケティング的な誇張を取り除かせてください。

「生成(Generative)」はエンジンを指しています。大規模言語モデル(LLM)であり、ChatGPTやClaudeの背後にあるのと同じクラスのモデルです。あるテキストを与えると、LLMは新しいテキストを予測して書きます。サポート向けの生成AIチャットボットは、このエンジンに1つの仕事をさせます。顧客のメッセージを受け取り、返答を作り出すことです。

重要な言葉は作り出すです。リストから既製の回答を取り出しているわけではありません。それぞれの返答は、顧客が実際に使った言葉遣いへの反応として、その都度新しく組み立てられます。だからこそ同じボットが「注文はどこですか」と「もう8日経ったのに荷物がまだ届かないんですけど??」に、根底にある知識は同じでも、自然で異なる言い回しで答えられるのです。

これは数年前の会話型AIからの飛躍です。しかもそれは名前の付け替えではなく本物の飛躍であり、それが最初にはっきりさせておく価値のある点です。

生成型と旧来のルールベースチャットボット

2023年より前に「チャットボット」を導入して嫌な思いをしたなら、それはほぼ確実にルールベースのものでした。誰かが決定木を描きます。顧客が「返品」をクリックしたらこのメニューを表示する、「返金」と入力したらこの既成の返答を発火させる、というものです。これは顧客がその木が想定していなかったことを言うまでは機能しますが、そうなると悪名高い「申し訳ありません、理解できませんでした」が出てきます。

生成ボットは決定木そのものを捨て去ります。転げ落ちるメニューがそもそも存在しません。生のメッセージから意図を読み取り、それに対して回答を書くからです。実際上の利点は次のとおりです。

• 想定していなかった言い回しにも対応できる。 誤字、長々と続く文、1つのメッセージに含まれる2つの質問、まったく異なる言語。意味を読み取っているのであってキーワードを照合しているわけではないため対応できます。
• 人間らしく、自社のトーンで話す。 トーンを調整でき、どの返答も硬いテンプレートではなく文章として読めます。
• 履歴から学習して向上する。 解決済みチケットを与えれば、ヘルプセンターに書かれていることだけでなく、実際にチームがどう答えているかを学習します。

正直な言い方をすればトレードオフがあります。ルールベースのボットはあなたが教えたことしか言えず、それは制限が多い一方で完全に予測可能でもあります。生成ボットははるかに有能ですが、放置すれば予測しにくくなります。この緊張関係こそが、これをうまくやるための本質のすべてであり、詳しいバージョンが知りたい方向けにルールベースチャットボットとAIエージェントの比較という、より詳しい記事も書きました。

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

ここは、多くの解説記事が省略している部分です。サポート用途に耐える生成ボットは「ロゴを貼り替えただけのChatGPT」ではありません。素のLLMは世の中について多くを知っている一方で自社の返金ポリシーについては何も知らないため、そのままでは拒否するか、でっち上げるかのどちらかになります。この問題を解決するアーキテクチャが、検索拡張生成、いわゆるRAGです。

左から右へ順に見ていきましょう。

1. 顧客が質問する。 自分の言葉で、どんなチャネルでも、どんな言語でも。
2. ボットが検索する。 根拠となる知識、ヘルプセンター、過去のチケット、マクロ、社内ドキュメントを検索し、その質問に関連する箇所を抜き出します。
3. LLMが書く。 検索して得たものだけを使って回答を組み立てるため、回答はインターネットの平均的な推測ではなく、自社の実際のポリシーを反映します。
4. 確信度チェックが走る。 システムがどれだけ自信があるかを採点します。
5. 送信するかエスカレーションする。 確信度の高い回答は送信され、あやふやなものは人間向けの下書き、あるいはきれいな引き継ぎになります。

この検索ステップこそが根拠付けがこれほど重要である理由であり、RAGと素のLLMの違いが、自社ドキュメントを引用するボットと、ハルシネーションを起こすボットの違いになる理由です。ツールを評価しているなら、最も鋭い質問の1つは正確には何から学習しているのかです。ヘルプセンターだけなのか、それともヘルプセンターに加えて解決済みチケットからも学習するのか。自社のナレッジベースとチケット履歴から学習するツールは、はるかに自社の最も優れたエージェントに近い答え方をします。

うまくいっている点

根拠付けとルーティングが適切に設定されていれば、数字こそがチームが手間をかける理由になります。

Zendesk上で稼働するギグエコノミー向けドライバー分析アプリ(約1,300件のやり取り)は、初月にティア1リクエストの73%を解決し、その結果は7日間のトライアル期間内に現れました。これが成功の典型的な形です。「注文はどこですか」「これをどうリセットすればいいですか」「返品期限はいつまでですか」といった繰り返しの多いティア1の質問は、まさに生成ボットが得意とするものであり、ほとんどのキューの大部分を占めるものでもあります。

「初月で、eeselは弊社のティア1リクエストの73%を解決しています……弊社チームは7日間のトライアル中に導入し、すぐに結果を出しました。」

Kim Simpson氏、Gridwise(G2レビュー)

これは単なる対応件数の削減だけの話ではありません。最終的な返信を人間が送る場合であっても、生成ボットは受信したチケットのトリアージ、タグ付け、提案返信の下書き作成を行い、エージェントに幸先の良いスタートを与えられます。私が調べた実トラフィックのトライアル(ZendeskとShopifyで月間約1,000件のチケットを処理するドイツのジュエリー小売業者)では、エージェントが最終送信を握ったままでも、ボットは93%のトリアージ精度を達成し、誤検知ゼロでスパムを100%捕捉しました。この「コパイロット」モードは、慎重なチームがよく最初に始める場所であり、始める場所として十分に良い選択です。

規模感をつかむために言うと、同じエンジンが規模の両端で稼働しています。ある貸金業者は完全自動化されたZendeskエージェントを通じて月間10万件以上のドイツ語チケットを処理する一方、小規模なチームでも初日から最も繰り返しの多い質問を対応させることができます。誰がこれを行っているかをもっと広く知りたい場合は、カスタマーサービスにAIチャットボットを使っている企業のリストを継続的に更新しています。

難しい部分:信頼できるものにすること

ここからは正直な部分、つまりこうしたプロジェクトの多くがうまくいかなくなる理由です。

生成モデルは常に回答を試みようとします。それがその本質です。すべてに答えさせてしまうと、時折自信満々に間違った回答をすることになり、請求に関する質問への1件の悪い自動返信は、10件の良い返信が積み上げる信頼よりも多くの信頼を損ないます。導入検討者からよく聞く最大の懸念は「機能するかどうか」ではなく、「すべてを任せきりにはできない」というものです。Gorgias上で運用するDTCサプリメントブランド(月間約7,000件のチケット)のあるCXリーダーは、これを的確に言い表しました。

「AIが質問の100%に答えられるようになることは決してありません……対応できると確信しているチケットだけを扱い、それ以外は放っておいてくれるAIが必要なんです。」

あるDTCサプリメントブランドのCXリーダー、eeselの営業電話での発言より

これは正しい直感であり、優れたツールがまさに与えてくれるものです。その仕組みが確信度に基づくルーティングです。ボットは各チケットを採点し、あなたが設定した範囲内でのみ行動します。

実際の顧客を任せる前に、あらゆる生成ボットに求めるべきことは次のとおりです。

• 自分でコントロールできる確信度のしきい値。 高確信度は自動解決、中程度は下書き、低確信度はそのまま手をつけない。「すべてに答えるか、まったく答えないか」であってはいけません。
• トピックの除外設定。 「X円を超える返金には絶対に触れない」「解約に言及するものはすべて人間に任せる」と指定できるべきです。多くの導入検討者がまさにこれを求めています。
• 人間へのきれいな引き継ぎ。 ボットが手を引くとき、顧客がそれを感じ取らないようにし、エージェントには完全なコンテキストが渡されるべきです。
• 目に見える学習ループ。 エージェントが下書きを編集または却下したら、その修正が今後の回答を改善すべきであり、実際に改善されたことを確認できるべきです。

これらを正しく整えれば、ハルシネーションは怖い抽象概念であることをやめ、自分で設定できるダイヤルになります。失敗パターンを詳しく知りたい方向けに、AIチャットボットが誤った回答をする理由を深掘りした記事も書きました。

失敗せずに導入する方法

私が最もよく目にする間違いは、初日に「全員に自動返信する」設定にボットを切り替えてしまうことです。実際に私が従うであろう手順は次のとおりです。

1. すでにサポートが行われている場所に接続する。 優れた生成チャットボットは、移行を求めるのではなく、既存のヘルプデスクやウェブサイトチャットに連携します。ツールがスタックの作り直しを求めてくるなら、それは危険信号です。
2. 実際の知識を与える。 ヘルプセンター、解決済みチケット、社内ドキュメント。ナレッジベースが回答品質の上限を決めるため、このステップは省略できません。
3. 本番稼働前に自社の履歴でシミュレーションする。 これはほぼ全員が省略してしまうのに、省略すべきではないステップです。ボットを何千件もの過去チケットに対して実行し、実際にどう返答したであろうか、そしてトピックごとの解決率がどうなるかを具体的に確認します。これによって「うまくいくといいな」が、実際に見て確認できる数字に変わります。

4. 狭く始めて、徐々に広げる。 まずは安全で件数の多い少数のトピックについて自律動作を有効にします。指標を観察し、信頼が積み上がるにつれて確信度の範囲を広げていきます。
5. レビューして育てる。 最初の数週間は下書きと却下に目を配りましょう。修正から学習することで、ボットは目に見えて向上します。

自信満々に見えるボットが静かに間違った回答をするのを、私はこれまで何度も見てきました。だからこそ、最初に過去チケットに対してシミュレーションすることは、私にとって譲れない条件なのです。これは存在する中で最も安い保険です。

生成AIチャットボットの費用

料金体系は細かい条件が効いてくる部分です。ベンダーは解決件数、会話数、シート数、あるいはチケット数のいずれかで課金しますが、これらの単位は同じではないため、会話数あたりの「安い」プランでも、実際のボリュームになるとチケットあたりのプランより高くつくことがあります。表示価格よりも先に課金単位を確認してください。チャットボットのコストとAIエージェントと人間のエージェントのコスト比較の記事で、その計算を詳しく解説しています。

もう1つの落とし穴は、成功を罰する解決件数課金です。ボットが多く解決するほど請求額が膨らみ、予算立てが当て推量のゲームになってしまいます。私は予測可能なモデルを好みます。eeselはチケットあたり0.40ドルの定額制で、シート課金もプラットフォーム最低料金もないため、コストは予測できる形でボリュームに応じてスケールします。詳細はすべて料金ページに記載しています。

eesel AIを試す

ここまで読んだなら、もう何を探すべきか分かっているはずです。自社の知識に根拠を置いて回答し、確信度に応じてルーティングし、本番稼働前に機能することを証明させてくれる生成ボットです。それがまさにeesel AIの設計思想そのものです。

eeselは、あなたがすでに使っているヘルプデスク、Zendesk、Freshdesk、Gorgias、HubSpot、Jiraなど100以上のアプリと連携し、初日から解決済みチケットとドキュメントから学習し、過去のチケットでシミュレーションできるため、1人の顧客にも影響が及ぶ前に解決率を確認できます。確信度に基づくルーティングにより、確信があるものだけに回答し、それ以外はすべてあなたのチームに引き継ぎます。

無料で始めて、ヘルプデスクを接続し、午後のうちにシミュレーションを実行できます。自分自身のワークフローの中で実際に動く様子を見たいなら、最も手っ取り早い方法は、実際のチケットでeeselを試すことです。