成功するチャットボット・プロジェクトはこれらの間違いを避ける

チャットボットとは？ チャットボットとは、ユーザーと人間のような会話をすることができるソフトウェアです。ユーザーはチャットアプリケーションを通してチャットボットに話しかけたり、メッセージを送ったりすることができ、チャットボットは話したり、何かをタイプしたり、グラフィカルなものを見せたりして、適切に応答します。現在、chatbots の主なユースケースはカスタマーサポートで、簡単で繰り返しの多い質問に答えたり、より複雑な質問を人間のエージェントにエスカレーションしたりするのに使われています。

アマゾン・アレクサが商品を注文したり、他のいくつかの例を超えて）顧客対応に広く使われるようになるには、解決すべき問題がいくつかあるが、会話型インターフェースは顧客サポート機能に急速に採用されつつある。

ビジネスの観点から、チャットボットプロジェクトは、他のプロジェクトと同様に、リスクとリターンの観点から評価される必要がある。

本稿では、チャットボット導入の際に起こりうる課題と、それを回避する方法を検討する。

ここで強調されたリスクの多くは回避可能なものであり、アーリーアダプターが直面した問題の多くは現在ではよく知られている。

chatbots 多くの場合、チャットボットのROIは1,000％を超えており、それは単にコスト削減によるものではなく、同様に顧客エンゲージメントと満足度の向上、そしてそこから派生する収益機会によるものである。

ボット・プラットフォームは成熟しており、企業にとって、ボット・プラットフォームは低空飛行の果実となっている。chatbots 、カスタマー・サポートに広く使われるようになるだけでなく、ユースケースはカスタマー・イネーブルメントへと急速に拡大し、最終的にはカスタマー・サポートが主なユースケースを独占することになるだろう。

‍

誇大広告を超えて

新しいテクノロジーを評価するのは難しい。テクノロジー企業は、そのテクノロジーを導入すれば何が起こるかについて、あらゆる種類の大胆な約束をしているが、もちろん、そう簡単ではないこと、保証されているものは何もないこと、デメリットを強調していないことは知っているはずだ。同じことがchatbots にも当てはまる。

Chatbots この誇大広告は、多くの段階を経てきた。この誇大広告の多くは、chatbots 。

ここ数年、チャットボットに関連するAIにおいて、いくつかの真のブレークスルーがあったことは事実である。chatbots に何を期待するかについて真のイメージを持つためには、これらのブレークスルーを理解する必要がある。

主なブレークスルーは、自然言語処理（NLP）、大規模音声認識（音声アシスタント用）、自然言語生成の3つの主要技術である。

NLPは、チャットボットが同じ意味を持つ異なる自然言語フレーズの背後にある共通の意図を識別することを可能にします。例えば、"book a flight "や "I want to fly to Paris "は、"book a flight "と同じ意図を持っている。ソフトウェア開発者は、その意図が特定されれば、何をすべきかをコーディングすることができる。

音声認識は、話し言葉をテキストに変換する技術を使用する。音声認識の歴史は古いが、コンピュータの性能が向上し、cloud に仕事を任せることができるようになったからこそ、これらのシステムが何百万もの単語を識別できるようになったのである。

自然言語生成は、パラメータのセットを取り込み、自然言語で文法的に正しい文章を生成する。

これらの技術はすべて、かなり最近のコンピューティング・パワーの進歩によって、ある程度は進歩した。

極端な誇大広告は、chatbots がすぐに人間のエージェントに完全に取って代わるというものだ。現実には、chatbots は、文脈が限定された狭い領域で非常に優れたパフォーマンスを発揮し、文脈のない単発の質問に答えるときに最高のパフォーマンスを発揮する。

だからといって、その根底にある技術がパワフルで有用ではないという意味ではない。そうだ。だからといって、chatbots 、莫大な投資収益率（ROI）を生み出すことができないという意味ではない。できる。

ただし、チャットボットの体験は、制限を念頭に置いて作られる必要があるということだ。

‍

チャットボットプロジェクトにありがちな失敗

誤った目的

チャットボットを実装する際に選択した目的が間違っている可能性はたくさんあります。例えば、存在しない問題を解決する、つまりグラフィカル・インターフェースで行う方が良いことをチャットボットで行うなど、目的設定には多くの問題があり得ます。

最大の間違いは、誇大広告を鵜呑みにして、ほとんど人間レベルで顧客と会話する人間そっくりのチャットボットを導入しようとすることだ。多くの企業がこれを試みて失敗している。チャットボットが得意とする範囲外でチャットボットを構築しようとすることは、常に問題となります。

最高のチャットボット体験は、オープンエンドの会話体験ではなく、ガイド付きの会話体験である。例えば、Botpress ソフトウェアはハッピーパスを定義しており、これはソフトウェアがユーザーを維持するために必要なガイド付きパスである。もしユーザーがこのパスから逸脱した場合、ソフトウェアはユーザーをハッピーパスに戻そうとするか、別のパスを開始するチャンスを提供しますが、逸脱することは許しません。

設計と開発の問題

設計が不十分なチャットボットは、ユーザーが意図しない使い方をする原因になります。これは明らかにフラストレーションを引き起こし、様々な悪影響を及ぼします。

Chatbots 保守的に設計し、スコープを明確にし、会話を人間にエスカレーションする頻度を高くする必要がある。

ボットに携わる開発者がこの分野のベストプラクティスに精通し、有能でなければならないことは言うまでもない。

‍

誤った技術的アプローチ

Chatbots 今日では、NLPと決定木が混在している。NLPは、ユーザーが非常に狭い領域でオープンエンドの質問をすることを可能にし、決定木は、問題を解決したりタスクを完了したりするために、決定木（ハッピーパス）を通してユーザーを連れて行く。回り道について前述したように、ユーザーがハッピー・パスから逸脱できる範囲は限られている。

会話にブラックボックス的なアプローチを選ぶのは間違いだ。ブラックボックス・ソリューションとは、基本的にロジックがAIアルゴリズムに保持されているデータ駆動型のソリューションである。これの問題点は、AIソリューションが何をするのか誰にもわからないこと、デバッグが非常に難しいこと、包括的なテストができないこと、そして新しい情報がその挙動を変える可能性があることだ。

Botpress 、この技術の一部は使われているが、この「ブラックボックス」AIが活動できる領域は、ハッピーパス周辺の狭い範囲に限定されている。したがって、AIの目標は、ユーザーを常にハッピー・パスに戻すか、新しいパスに移行させることである。この方が理解しやすく、デバッグしやすい。

この "ブラックボックス "AIは、境界があり、目の前のタスクを取り巻く膨大な量の関連データがある領域で、非常にうまく機能する。これが、AIがゲームをうまくこなせる理由だ。言語の問題は、どのような発言も、以前になされた発言や会話エージェントが知っておくべきその他の関連情報を含む文脈によって異なる意味を持つため、無限の次元を持つということだ。

現在のテクノロジーを使って会話用のブラックボックスAIを実装することは、オープンエンドのチャットボットを実装しようとする過ちに似ている。

加えて、上記のような欠点があるにもかかわらず、この種のブラックボックス・アプローチは極めてデータ集約的であるため、導入には莫大なコストがかかる。また、ブラックボックスであるということは、ベンダーの切り替えが非常に困難であることを意味する。

シンプルなNLPと決定木の技術を使ってボットを構築し、ユーザーを目の前のタスクの完了に戻すために、限られた範囲のAIを端から使う方が良い。私たちは、この技術がいかに身近で簡単に使えるかに、企業が実際に驚いていることを発見した。有能な開発者であれば、わずか数時間でNLPと決定木を使ったボットの構築方法を学ぶことができる。

また、chatbots との会話は、人間との会話を再現すべきではないことを理解することも重要だ。例えば、グラフィカル・インターフェースは、多くの場合、テキストや音声よりもはるかに効率的に使用できる。オプションボタンをクリックする方が、返事をタイプしたり話したりするよりも早い。これは、たとえ人間レベルのチャットボットを作ることができたとしても同じことだ。この現実は、ブラックボックスや主に単語ベースのAIアプローチを使用する際に見落とされがちです。

‍

プラットフォームが違う

誤ったボットフレームワークを選択した場合の問題は、すぐには明らかにならないかもしれないが、時間の経過とともに明らかになるだろう。

チャットボットを構築する最も速い方法は、ドラッグ＆ドロップのプラットフォームを使用することです。しかし、ほとんどの場合、開発者はすぐに難しい制限にぶつかります。さらに、一般的なアプローチを使用すると、単純な機能であるべきものがシステムにハックされ、管理者がボットを使用するのが不便で難しくなります。

もう一方は、開発者がゼロからボットをコーディングできるコードベースの独自プラットフォームだ。このアプローチの問題点は、単純なボットでさえ構築するのに非常に時間がかかることだ。

最適なアプローチは、必要なコンポーネントと、ドラッグ＆ドロップ・インターフェースを含むビジュアル・インターフェースをすべて箱から出してすぐに提供し、同時にこれらのコンポーネントとインターフェースをすべて、目の前のタスクに合わせて簡単にカスタマイズできるフレームワークである。

ボットスポンサーは通常、ボットがエンドユーザーにとってどのように機能するかにほとんどの注意を向けるため、これは特に重要です。この問題は、管理者（チャットボットのアナリティクスを監視し、バックエンドのアクセスを管理したい人）、技術的および非技術的なクリエイター（ボットの動作やコンテンツを変更したい人）、人間のエージェント（ボットによってエスカレーションされた会話に応答する人）など、ボットの他のユーザーにとって重要な他のコンポーネントやインターフェースが多数存在することです。

これらのコンポーネントをゼロから構築するのは、非常に時間のかかる作業だ。もちろん、シンプルなドラッグ＆ドロップ・フレームワークは、この機能を非常に汎用的かつ限定的に備えており、簡単にカスタマイズすることはできない。

カスタマイズする能力は、たとえそれが前もって明らかでなくても、エンドユーザーボット自体にとって不可欠である。例えば、ドラッグ・アンド・ドロップのフロー・ビルダーを使ってフローを構築する場合、会社のシステムでユーザーを認証したり、支払いを処理したりするなど、異なるフローで何度も繰り返す必要があるタスクがあるかもしれません。

フレームワークは、これらのコンポーネントをフロー・ビルダーにビジュアル・コンポーネントとして追加できるようにすべきであり、そうすることで、技術力の低いコンテンツ制作者でも簡単にこれらの機能をプロセスに追加できるようになる。

簡単にカスタマイズできないプラットフォームでは、技術者でないユーザーにコンテンツを更新する方法を提供することが難しくなる。すべてのカスタマイズが可能なフレームワークであれば、非技術系ユーザー向けに、簡単で直感的に使える目的別の画面を簡単に作成できるはずだ。

さらに、開発者がシステムの基礎となるソースコードにアクセスできることも、非常に有益です。そうすることで、開発者は物事の進め方をより迅速に理解することができ、問題が発生した場合にも迅速に特定することができる。

フレームワークにとって極めて重要なことは、データを制御し、移行する能力である。プラットフォームは、企業がボットをプライベートなcloud 、またはオンプレム（社内サーバー上）など、好きな場所にデプロイできるようにする必要がある。

プラットフォームに関しては、ROIも重要な考慮事項である。つまり、あるボットの機能を構築することで、次のボットの構築が容易になる。これにより、1つのボットから多数のボットへの拡張が段階的に安くなり、全体的なROIを向上させる効果がある。

その一例として、設計が不十分なプラットフォームでは、同じコンテンツを異なる言語で提供するだけでなく、新しい言語を追加するたびに新しいボットを作成することになる。フロー設計をコンテンツから分離していない場合でさえ、技術者でないスタッフが単にコンテンツを更新するのではなく、実際のフローを編集する必要があるため、コンテンツの管理がより難しくなり、ミスが発生しやすくなる。

管理者やその他のバックエンドユーザーが効率的で簡単な方法で作業を行えるようにすることで、時間を節約し、ミスを減らし、ROIを向上させることができる。

‍

ベンダー・ロックイン

ベンダーのロックインはいろいろな意味で問題だ。

サードパーティのコンポーネントを使用できないプラットフォームなど、サードパーティのテクノロジーを使用せざるを得ない場合、サードパーティのコンポーネントが永遠にクラス最高であることに賭けることになる。もしそうでなければ、他の市場が進歩する間、あるいは非常にコストのかかる乗り換えを行う間、時代遅れのテクノロジーを使わざるを得なくなる。

足りないコンポーネントがある場合、あるいは動作方法を変更する必要がある場合、カスタム開発に頼る必要があるが、これは遅延を引き起こすだけでなく、高価な作業になりかねない。

最後に、もしあなたが固定客であれば、彼らは非常に高価な価格設定をすることができる。特に、データやコードの他のプラットフォームへの移行を困難にする場合、彼らは、完全な負荷の切り替えコストが非常に高くなる可能性があることを知っている。

オープン・システムではなくプロプライエタリ・システムを使うことは、ロックインの可能性を高め、スイッチング・コストを高くする。さらに、chatbots 、データの専門家しか実装できないような複雑なアプローチを選択することは、ロックインから逃れることがさらに難しくなり、ロックインのコストが高くなることを意味する。

‍

利害関係者の不参加

これは、既存の行動の変更を伴うソフトウェア・プロジェクトではよくある明らかな間違いであり、解決策はよく知られている。もちろん、カスタマーサービス担当者は、ボットの世界では特に重要である。ボットが提供するサービスを補完する一連のサービスを提供するために、特にボットでは解決できない複雑なニーズを持つ顧客により深いサービスを提供するために、彼らは再教育される必要がある。

‍

ROIを無視する

ROIを無視することが失敗につながる可能性は2つある。1つ目は、説得力のあるROIの数字がなければ、たとえテクノロジーを証明するためのPOCにスポンサーがついたとしても、プロジェクトはスポンサーを得られないということだ。もう1つは、プロジェクトの利害関係者が、プロジェクトが稼働してしまえばROIがないことに気づくことである。

期待されるROI（投資収益率）を前もって計算し、ユースケースとコンテキストに関する情報が増えるにつれて、この数字を更新しない理由はない。ROIが極めて高いユースケースはたくさんあるので、ユースケースを見つけるのは難しくないはずだ。

‍

ロボットを段階的に構築しない

もちろん、上記のリスクの多くは、段階的にボットを導入していくアプローチによって回避することができる。

段階的にテストできるソリューションを構築するのは非常に簡単だ。まず1つのユースケースのPOCから始め、数人のエンドユーザーをボットにルーティングしてパフォーマンスを評価する。こうすることで、ユーザーの反応を含め、ソリューションの有効性を安価にテストし、各段階で改良することができる。

もちろん、この演習でユースケースを選択する際には、最も「リスクのある」仮定に挑戦するユースケースを選択することが重要であり、これにより最も不確実で重要な仮定が前もってテストされる。

多くのベンダーは、POCであっても動くボットをユーザーに提示する前に、前もって多大な作業と労力を費やすビッグバン・アプローチに取り組ませようとする。それだけでなく、ベンダーは、ボットを管理・監視できるのは高額のコンサルタントだけだと主張する。これは大きな赤信号だ。

‍

結論

チャットボットを構築する際に留意すべき点はたくさんあります。主なリスクを認識し、段階的な実装アプローチを取る限り、成功するチャットボットを構築し、それに伴う驚異的なROIを達成する大きなチャンスがあります。

‍