GoogleAppsScript
gas
Watson
チャットボット
働き方改革

【失敗事例共有】社内向けチャットボットが利用者数が少なすぎて廃止になった

サマリ

社内における「働き方改革」の一環として、IBMのWatsonを使ったチャットボットを開発し、去年の3月に社内向けに展開していましたが、およそ1年が経った時点での日時利用者数が悲しいくらいに少なかったため、3月中に廃止となりました。

このチャットボットがどのような背景で作られたツールなのかを整理しつつ、なぜこのような結果に終わってしまったのかの反省を述べることによって、これから社内の働き方改革に取り組もうとしている方あるいはWebサービス開発を行おうとしている方が同じような失敗をしないような参考になるようにまとめたいと思います。

ちなみに、「チャットボット 失敗」のようなキーワードで有名(?)な「断言しよう、チャットボットブームは去るし関連ビジネスも失敗するよ」というはてなブログの記事がありますが、私はこのチャットボットを開発する以前に読んでいました。詳細はリンクから実際の記事を読んでいただきたいのですが、タイトルからお分りの通り、「チャットボットなんてうまくいかないよ」との主張が書かれています。開発中やリリース直後はこの記事の内容に反してうまくいっていましたが、最終的にはまんまとこの記事の通りの結末を迎えることになりました。

どんなツールなの?

構成

構成としては、フロント側にはGAS(Google Apps Script)とHTML/CSSを、バック側にはIBMのWatson Conversationを使ったチャットボットです。一般的なチャットボット同様、ユーザーからの入力を受け付け、その内容に応じてなんらかの返答を返します。

チャットボット.001.jpeg

以前、「GAS(GoogleAppsScript)で「社内通貨」を作ってみた話」のような記事も書きましたが、私の所属する会社ではかなりGoogleAppsが浸透し、GASのHTMLServiceを利用したWebツール作りが活発です。このチャットボット開発にあたっては、ユーザーの入力を受け付けてWatsonからの出力を表示するUI部分については、SlackやLINEなどの採用も検討しましたが、コストや柔軟性などの面を考慮してGASが選ばれました。当然、一番大きい理由は「慣れ」です。

また、ユーザーからの問い合わせを解釈して適切な回答をひねり出す、このチャットボットの脳にあたる部分については、最終的に採用されたWatson Conversationの他には、「Natural Language Classifier(NLC)」と「Retrieve and Rank(R&R)」の併用案もありましたが、Conversationの簡単さが評価されました。

期待していた役割

このチャットボットに期待していた役割としては、社内の各部署から管理部門への各種問い合わせに自動回答し、管理部門社員の工数削減を実現することでした。

各種問い合わせとは、例えば
「社内の座席表が見たい」
「拠点間をつなぐシャトルバスの時刻表を見たい」
「遠隔会議システムの利用方法、ログイン方法を知りたい」
「社員証を忘れたらどうすれば良いか」
「弔電、祝電を会社から出してほしいときの手続き方法」
など、社員が日々の業務に携わる中で発生する疑問点や困り事が挙げられます。

これらの問い合わせへに関係する情報については、社内のGoogleサイトなどにおおよそ掲載されており、ほとんどの内容についてはそれらを参照することで解決できると思われますが、実際にはいくつかの要因により、うまく解決に導けていない状態にあるとされていました。例えば、Googleサイトが複数に分かれているために、横断した検索ができないことや、jpgなどの画像の状態で掲載されているためにテキスト検索ではヒットしないなどにより、せっかく用意されているリソースが有効に発揮されず、ユーザーが欲しい情報になかなかたどり着けないことが多いと考えられました。

このような状態を打破するために、社内のあらゆる情報を集約し、かつ自然言語でそれら全てを検索することができるツールとしてチャットボットを選択し、開発がされました。「チャットボット」ないし「AI・人工知能」がホットワードになる中、これらがどれだけ業務で活躍できるのかを確かめたいという好奇心や試験的な意味合いも開発の後押しになりました。また、このように社内にある情報にたどり着けない問題は多くの会社で発生していると想像できるため、世間に先駆けていち早くチャットボットを使ってこのような課題を解決できれば、世にアピールできるような良いモデルケースになれるとの期待もありました。

何が悪かったの?

「使える」ではなく「すごい」を優先してしまった

「目的と手段を取り違えた」とも言えます。

「社内の問い合わせに自動で答えてくれるチャットボット」を開発すると言われれば、多くの人はなんとなく「なんかよくわからないけどすごそう!」となるでしょう。確かに、チャットボットというものは現時点での世界の最先端の技術を利用したソリューションであり、そんなものが社内で開発されるのは「すごい」ことには違いありません。しかし、その「すごい」ものが業務に役立ち、実際のビジネス上の成果に結びつくような「使える」ものであるかどうかは別問題です。

新しくてなんかすごそうな技術やアイデアというものは多くの人が関心を持ちやすく、その分だけ社内での推進をする説得力を持ってしまいがちですが、それらが必ずしも本当に社内の課題を解決する手助けをしてくれるのかはわかりません。そのすごさの輝きに目を奪われ、その背景に広がる暗黒面に意識を向けることが難しくなります。そのすごいものが、今回の私のケースではチャットボットあるいはAIないしWatsonであったわけです。

Watsonが期待はずれだった

Watson Conversationは、大きく"intents""entities""dialog"で構成されます。intentsとentitiesでユーザーからの入力内容を解釈、分類し、それに応じてdialogに定義された会話文を出力します。従って、dialogのパターンをできるだけ大量に用意し、あらゆる入力に対応する出力をできるようにすることが、良いチャットボット作りには大切です。話しかけたチャットボットから期待する返答がなければがっかりしてしまいますし、そのようなことが続けばせっかく興味を持ってくれたユーザーもすぐに離れてしまうことでしょう。

こんなことは開発する以前からわかっていたことですが、実際に行うのは大変に難しいことでした。いくつか理由はありますが、一番大きかったのは、Watsonの日本語理解力のなさによるところです。Watsonは米国企業が開発しているものですので、まずは英語で書かれた文章の読解力の向上を意識されていることでしょう。そのため、日本語のような英語以外の言語に関する読解力の向上は英語と比べれば後回しにされがちだと思われます。その結果、私のように日本語をビジネスレベルで理解し、返答ができることを期待している開発者にとっては不満が残る性能にとどまっていると考えます。このことは、「少なくとも日本語では」ということで、英語だったらビジネスで使えるレベルであるのかどうかはわかりません。(私が英語ができないため)

intentsでは、例えば「あいさつ」カテゴリとして
「おはよう」
「こんにちは」
「こんばんは」
などの文言を登録しておくと、Watsonが学習をしてくれ、これらのキーワードが入力された際には「このユーザーはあいさつをした」と理解するようになります。
また、必ずしも完全一致である必要はなく、例えば
「おはようございます」(後ろに「ございます」が付いた)
「こんにちわ」(「は」が「わ」になった)
くらいの表記揺れであればあいさつであると理解でき、それに応じた返答をすることができます。この辺りが、Watsonの"AI"らしい強みと言えます。

ところが、例えば
「やっほー」
「どうも」
「ちわーっす」
「元気?」
など、人間の目で見れば「あいさつ」であると理解できる文言であっても、上記の方法でそれを教えていなければもうお手上げで、「未分類」と扱われてしまいます。当然、これらのあいさつもWatsonに教えていれば、きちんと分類してくれるようになりますが、開発にかけられる工数には限りがありますので、あらゆるキーワードを教え込むことはできません。

Watsonを利用したチャットボットとして一般顧客向けにリリースされているもので最も有名なのは「マナミさん」でしょうか。
通販サイトのLOHACOで運用されている、お問い合わせチャットボットです。社内外の違いはあるものの、お問い合わせに対する返答をする、という意味では私のチャットボットとは同じミッションを持っていますので、私も開発にあたっては大いに参考にさせていただいていました。「マナミさん」をよくご覧いただくとわかる通り、マナミさんへの問い合わせはテキストボックスへの自由入力だけでなく、あらかじめ用意された項目の中からクリックで選択する方法も用意されています。

スクリーンショット 2018-04-08 9.38.17.png

このことについて、よくある問い合わせについてはわざわざユーザーに入力させず、クリックしてもらった方が親切だという考え方もあるでしょう。もちろん私もそのような面は否定しませんが、おそらくは自由入力させると、回答できない質問が少なくないからということもあるのではないかと思います。自由入力の余地は残しつつも、クリックで入力することをさりげなく誘導することによって、開発側が予期しないキーワードが入力される可能性を減らしたい、という意図があるように感じます。

結論。チャットボットを捨ててFAQを充実させよう

上記の通り、現状ではユーザーの問い合わせに対して期待する返答を返すようなチャットボットを作ろうとすると、膨大な工数が必要となります。また、テキストによる自由入力というものは理論上どのような入力でもされうるものであり、それらのあらゆる入力でも「未分類」とならないように教え込むのは実質的に不可能と言えます。

これまでのことを踏まえて結論めいたことを出すとするならば、「問い合わせへの回答をWeb上で行いたければ、チャットボットではなく FAQの充実をさせるべき」です。すなわち、すでに多くのところで作成されているであろう「FAQ」や「よくあるお問い合わせ」のページを、検索しやすくかつボリュームを充実させることが、開発側にとってもユーザー側にとっても良いことだと考えます。

私が行った解決策

この考えに基づき、私はよくあるお問い合わせを集めたFAQの再構築に取り組んでいます。せっかく開発したチャットボットですが、現在ではアクセスした人をこちらのFAQにリダイレクトさせています。チャットボット開発が完全に無駄になったかと言えばそうではなく、Watsonに教え込んでいた情報を生かし、もともとチャットボットが回答できていたものは基本的に検索できるようにはなっています。

現時点ではまだどのようなUIになるのかは流動的ですが、適切にカテゴリ分けされ、検索もそこそこできる、いわば「普通のFAQ」になると思います。Watsonを使わなくなった分、無料なのもいいですね。

チャットボットに対する過剰な期待

これは個人的なイメージも含みますが、なんらかの疑問点を解決するために
A.チャットボットに問い合わせて「わかりませんでした」と返される
B.FAQを検索して「見つかりませんでした」と返される
の二つを比べると、Aの方が残念な気持ちになるような感じがします。

私が開発をしていたものや「マナミさん」を含め、チャットボットの多くは擬人化され、キャラクター的な回答者がUI上に表示されています。このことは、気軽に話しかけやすいというメリットと引き換えに、回答の精度に対する過剰な期待をユーザーに与えてしまっているのではないでしょうか。チャットボットのテキストボックスに文字を入力するということは、ユーザーにとってはその回答者であるキャラクターに対して話しかけているのに等しく、求めている回答をきっと返してくれるだろうと思わせてしまっていると考えます。

また、前述の通り、回答者のキャラクターがいるということは、それだけFAQでは本来必要のない入力も引き出してしまいます。例えば、「回答者のプロフィール」や、先ほども例に出した「あいさつ」などです。「マナミさん」に関しては、例えば
お誕生日は?
年齢は?
彼氏はいるの?
のような入力であっても、自然な回答をしてくれます。
(「彼氏はいるの?」については若干流され気味に話題を変えられてしまいました)

スクリーンショット 2018-04-08 11.04.10.png

これらのような質問に対しても自然に受け答えしてくれることは、回答者のキャラクターに対するユーザーの好感度を高め、そのチャットボットだけでなくサービス自体のブランドへも好印象を与えることでしょう。

LOHACOのようなBtoCのサービスで、なおかつ「通販・ネットショッピングサイト」という競争の激しい分野においては、何か特徴的な部分を押し出すことで少しでもユーザーに印象を残し、継続して利用してもらうことが肝要なのでしょう。そのような意味では、LOHACOにおいてマナミさんがいることの意義は大きいと考えます。しかし、それはあくまでもマナミさんが「印象的」だからであり、「便利」だからではないはずです。これから新規にFAQのためのチャットボットを開発したところで、結局はマナミさんと比較されるだけで大した印象は残すわけでもなく、ユーザビリティを向上させてくれるわけではないでしょう。

FAQ用途のチャットボットは、開発側にとってもユーザー側にとっても期待の割にそこまでいいものではないと考えます。

まとめ

以上が、私からの失敗事例共有と、チャットボットに関する見解です。
FAQの場面でチャットボットが活躍できなからと言って、ビジネスの場全般でチャットボットが役立たない訳ではありません。詳しくはまた別記事にするとして、チャットボットが適しているであろうシーンはいくつか残っています。私自身も、チャットボットという仕組みは大好きですし、期待もしているため、FAQ以外のところで活躍の幅を広げてもらったら嬉しく思います。