2017年は、スマートスピーカーや、チャットボットなど、会話型UIが日本でも非常に注目された1年となりました。例によって ガートナーのハイプ・サイクルでもトレンドとして取り上げられました。会話型UIがエンジニアにとって、より一般的になってきた1年ともいえるのではないでしょうか。
会話型UIの裏側の仕組みとして、シゴトで頼れるボットを考えてみることにします。
タスク指向ボットと非タスク指向ボット
ボットはその目的によって大きく２つに分けられます。タスク指向ボットと、非タスク指向ボットです。今回はシゴトを頼みたいので、前者のタスク指向ボットを考えます。
人間の役に立つタスク指向ボット
シゴトにおいて、タスク指向ボットに期待されるのは、会話を通じて期待される目的を達成してくれることです。
ボットに頼んだほうがいいシゴト
世の中の各地ではAIが人のシゴトを奪うということが議論されています。たしかに、ボットがやったほうが明らかにいいと思われるシゴトはあります。しかしながら、AIやボットに奪われるということを議論するより、ボットにやれるシゴトを見つけてやらせるにはどうすればいいかという議論をした方が建設的だと思います。
例えば、ユーザーとしては滅多に遭遇しないシゴトだとしても、その業務を専門としている担当者にとっては「またか」と思われるシゴトが世の中にはたくさんあります。そんなシゴトこそボットにやってもらいましょう。
例えば、ボットにもまかせられそうなシゴトとして、よく言われることとして以下があります。
よくある問い合わせへの応対
ユーザーからの質問に答える。
いわゆるFAQというものですが、問い合わせ頻度が高ければ高いほど、また、人間ではなくシステム化するのがよいでしょう。システムであれば、必ずしもボットでなくてもいいとは思いますが、ボット化することでいくつか、人間に問い合わせるのと同等のメリットを受けられる可能性があると考えています。
- いろいろな言い回しで問い合わせられる
- 一つのUIから膨大な情報へアクセスできる
- 膨大な情報の中で、逐次的に情報を取得、応対できる
- テキスト入力できない場合でも音声で問い合わせられる
よくある業務への応対
ユーザーが何かをやって欲しい。
例えば、ホテルや病院における予約受付業務や、アンケートの収集など、会員入会受付など、ユーザーから必要最低限の情報を聞き出した上で、簡単な処理を行うことも、人間が応対するよりも、ボットが向いているでしょう。
- 一括で情報を伝えることも、小出しにすることもできる
- 目的達成に必要な情報を漏れなく聞き出せる
- わからないことは都度聞ける
人ではなく、ボットにやらせるべき理由
前述のメリットはもちろん、人間へ問い合わせれば得られますが、ボットの方が融通が聞くケースは多いでしょう。
人間と違ってスケールする
ボットというより、システム化のメリットになりますが、人間と違って必要なときに必要なだけ対応することができます。結果、ユーザーを待たせることもないので、機会損失を防げます。
あと、ボットは疲れを知らないので、休憩をとらせる義務もありません。しっかり24時間365日働かせましょう。
会話記録が人間の負担なく正確に残せる
ボットと人間の会話は、システムをかならず経由するので、テキストなり、音声なり、システム内で会話ログとして蓄積することができます。このデータをうまく活用すればボットの成長につなげることができます。ほったらかしはやめましょう。
さまざまなプラットフォームに展開できる
こちらはボットが注目されている大きな理由の一つですが、さまざまなボットをユーザーへ届けられるプラットフォームが出揃ってきました。
LINE／Facebook／Slackなど、多くのメッセージサービスは、ボットプラットフォームでもあります。また、スマートスピーカーなども、Amazon Echo／Google Homeにむけてボットを配布できる環境が整い始めてきています。
みなさんが作成したボットは、世界に向けて爆発的に拡散できる無限の可能性を秘めています。
実際にボットを作ってみる
会話型UIでは話し言葉、つまり、自然言語を入力として扱います。自然言語をあつかうシステムを考えるためまだ開発方法が浸透しておらず、かつ、考慮すべきことが膨大にあり、全てをいきなり一から作りはじめるのは得策ではありません。
今回はTISのDialogPlayというクラウドサービスでボットを作ってみました。DialogPlayは有償のサービスですが、トライアルプランもあります。もちろん、GoogleのDialogflowとは別物になります。
DialogPlay作ったボットはLINEやSlackやWeb埋め込みアプリとして配布することができます。
実際に作成するボットは以下のcodepenのURLで動作確認できるようにしています。
- よくある質問ボット https://codepen.io/shiraco/full/mprmwd/
- よくある業務ボット https://codepen.io/shiraco/full/ypabgo/
よくある質問をボットに答えさせる
社内にあるような社内ヘルプデスク業務をボットにお願いすることにします。想定問答、いわゆるFAQをQAのペアの形で事前に用意しておきます。
用意としては、思いつく範囲でQAのペアを幾つか用意しておきます。そしてQuestionについては、少し広がりを持たせて複数定義しておきます。QAの件数にもよりますが、だいたい、1つのAnswerに対して5件以上のQuestionを用意していくことにしましょう。Answer:Question=1:5以上の関係になります。
基本的な仕組みは、ユーザーの質問（発話クエリ）が、あらかじめ用意したQuestionの中で一番類似しているQuestionの回答を返すことになります。
①-1 実際にボットにお願いする質問をシナリオとして登録
1つのQAのペア(=シナリオ)を登録します。前述の通り1つのAnswerに対して5件以上のQuestionを例文として登録します。Answerは一言でいいでしょう。画面のアクションとして実現しています。
①-2 想定できる範囲のQAを増やす
あらかじめ想定できるQAが多いほど、ボットとして多くのことができます。QAを増やすことにしましょう。①-1 で作成したQAのペアを複数件登録させます。なお、QAはCSVで一括アップロードもできます。
上記の作業で前述のボットができ上がりました。作ったボットはボットアプリケーションとして公開する方法を選んで、自分以外のユーザーにも利用してもらうことができます。
続いて、よくある業務もおまかせしてみましょう。
よくある業務をボットにおまかせする
単純な業務であれば、ボットに任せられます。例えば、ここでは病院の問診受付をボットで自動化してみます。以下のイメージです。
よくある問い合わせほど種類はないとは思いますが、ある程度複数回のやり取りが発生するような業務を定義します。
②-1 シナリオの流れを作る
シナリオの流れはアクションという処理の定義を、順番に並べていきます。
アクションには以下のようなものがあります。
- 〔テキスト発言〕: ボットからユーザーに話しかける内容を定義
- 〔ヒアリング〕 : ボットがユーザーから聞き出す項目とその項目の型を定義
- 〔Yes/No確認〕 : ボットがユーザーにYes/Noで聞く
など、詳しくはこちらをごらんください。
②-2 ヒアリングアクションで聞き出す内容を定義する
ヒアリングアクションはWebアプリケーションでいうと、入力フォームに似ています。入力フォームであれば、ユーザーに項目ごとに入力させられて、項目ごとにバリデーションを掛けられることができます。しかし、会話型UIだと少し事情がことなります。システムへの入力は五月雨的に発生します。なるべく、ボットが主導でユーザーの発話を限定する必要があるでしょう。
また、会話型UIではユーザーの入力単位は単語単位ではなく文単位になることもあるでしょう。その分の中から複数の項目を抽出することもできます。
上記の作業でアクションをつなげていくことで、ボットができ上がります。作ったボットはボットアプリケーションとして公開できます。
さいごに
今回DialogPlayというサービスを使ってノンプログラミングでボットを作ってみました。ボットの可能性を少しでも感じていただくことはできたでしょうか。
今回2種類のシゴトをボットにまかせてみましたが、状況に応じて両方の観点でボットを設計することで、より役に立つボットを作る事ができるのではないでしょうか。ボットに任せられることはドンドンまかせて、人間はもっとエキサイティングなシゴトの割合を増やしていきましょう。