第2回 東京公共交通オープンデータチャレンジに応募した「まよワン！じっこくん」の連載記事の第4回です。
今回はRecast.AI（現SAP Conversational AI）でチャットボットを作ってみる回です。
「まよワン！じっこくん」の機能について第1～3回で触れていますが、LINEで時刻表情報を教えるチャットボットを作るにあたり、機能を「会話」と「検索」に分割して開発することになりました。
「検索」パートではNode.jsを使って、ユーザーが求めている情報を検索・取得します（詳細は連載5,6をどうぞ）。
「会話」パートではRecast.ai（現SAP Conversational AI）というチャットボットを使って、ユーザーからのインプットを認識、適切な返事をしつつ、後続の「検索」パートで必要になる情報をユーザーから引き出します。
本記事では、「会話パート」でのチャットボット作成の流れと気にするべきポイントを紹介します。
思い通りの柔軟な作り込みが可能なツールではないけれど、30分もあれば簡単なおしゃべりができるBotが作れるし、無償でも実用に耐えうる、すごい！ さっとプロトタイプ作るのにも使えるなと思いました。
チャットボットを作るときはざっくり以下の流れで進め、時刻表検索以外の機能を足したいときには、機能ごとに1～7を繰り返しました。もしかしたらもっと効率の良い作り方があるかもしれない＋場合によって多少前後しましたが、我々は大体この流れで最後までやりました。
じっこくんの場合は、Node側で時刻表を検索するために乗車駅や出発時刻などの情報が必要でした。2以降を作り始める前に「どんな項目を」取得して「どんなパラメーター名で」Nodeに渡すのか考えます。Botを作り始める前に、バックエンドチームとしっかり相談しましょう。（RecastよりNodeのほうが自由度が高いため、うまく動かない時にはNode側でのコーディングで吸収してもらうことが多々あります。Node側の人とは仲良くしましょう）
設計イメージができたら、インテントをつくります。
インテントとは、「文脈を読み取る基準」で、ユーザーの入力から「つまり何についてしゃべっているのか」を判断するためのものです。なので、基本的には実装したい機能ごとに1つのインテントを作ることになります。
インテントは、Recast内で @xxxxx のように表されます。名前の付け方はなんでもいいのですが、じっこくんのメイン機能である時刻表には @timetable という名前をつけました。
インテントができたら、そのインテントに紐づくエンティティを作ります。エンティティは、ユーザーが入力した単語を識別するためのラベルです。#YYYYYY で表されます。
例えばユーザーが
と入力した場合、以下のようにエンティティを割り当てることができます。
各インテントには、その文脈で必要な種類だけエンティティのラベルを作ります。ラベルができたら、「ユーザーが入力しそうな例文（エクスプレッション）」と「例文中のどの単語がどのエンティティとして認識されるべきか」を入力していきます。Botの機能の壮大さにもよりますが、じっこくんでは時刻表検索のために8個のエンティティと約130の例文を入力しました。
※気をつけよう※
ここでは、「ユーザーが実際に使う時どのように入力してくるだろうか？」を一番に考えましょう。ユーザーは親しみやすいBotに対して堅苦しい物言いもしなければ、誰もが同じような入力をするわけでもありません。例文にはバリエーションをもたせて、実際のユーザーの入力を正しく認識できるように育てたいです。
いまいちな例文の入れ方：
「有楽町線です」「永田町駅です」「新木場駅です」「麹町駅です」…
というように、「特定路線の駅名＋です」をひたすらインプット
→これだと以下のような理由からちょっと時間がもったいないので、下の良い例文を参考にバリエーション豊かなエクスプレッションをBotに教えてあげましょう
・「飯田橋から目黒」などの「駅」や「です」がついていない文章を認識できない
・「特定路線の駅名＋です」パターンの例文は2～3個あれば十分
・サクッと時刻表が知りたいのに「です」まで入力する人は少ない（自分でテストしてみればわかる）
よい例文の入れ方：
「都営大江戸線、東新宿から六本木一丁目、15時40分」
「早稲田駅から高田馬場」「１９時」「平日」
「南北線 赤羽岩淵 東大前 0830」「きゅうじつ」
というように、想定されうるパターンをなるべく網羅する
→駅名をつけるのかつけないのか、ひらがなかカタカナか、全角半角…などなど数人でテストするとみんな入力方法がばらつくので、そこで出てきた入力スタイルを加えてあげると対応力の高いBotになります。
一通り例文が出揃ったらスキルを作成して「どのような機能（会話の流れ）を用意するか」を定義します。
タブのBuildから新しいスキルを作ると、以下のように箱で表示されます。編集したいときは箱をクリック、新しい機能を増やしたいときはスキルを追加していきます。
スキルの「fallback」はデフォルトで用意されているもので、ユーザーの入力した文章が作成したどのスキルにも当てはまらない＝処理できないときに起動します。Siriでいう「すみません、よくわかりませんでした」にあたる内容がfallbackです。
スキルを編集する形で「どのようにユーザーと会話して情報を集めるか」を作り込んでいきます。チャットボット作成で一番やりがいのあるパートです。流れやこなれ感含む会話の自然さが使いやすさに直結するのでユーザーの気持ちになって会話を組み立てていきましょう。
まずはTriggersタブから「スキルを開始するきっかけ」となるトリガを作成します。
Requirementsタブでは「今の機能を完了するためにどの順番でどんな情報をどんな聞き方で取得するか」を決定します。システム的には「条件（ここでは必要な情報の充足）が満たされている場合に、アクションを実行するか」を決めるためのステップです。
じっこくんの時刻表検索機能では乗車路線・乗車駅名・降車駅名・乗車時刻・曜日タイプ（平日／休日）の情報が必要だったので、これらをどのようにゲットするか考えた結果以下のようになりました。会話は基本は上から順に流れていきますが、ユーザーがBotの質問を待たずに情報を提供してくれた場合には、そのブロックはスキップされて、足りていない情報をゲットするための質問が上から流れます。
じっこくんは基本 路線＞乗る駅＞降りる駅＞乗りたい時間＞曜日タイプ の順番で質問を投げるようデザインしました。この順番がめちゃくちゃになってしまうと使いづらさにつながるので、どう聞かれたら答えやすいかを考えて作りましょう。
Requirementsで要求する条件には、「特定のエンティティの有無」「時刻情報」「感情のポジティブ／ネガティブ情報」などなどさまざまな情報を指定することができますが、一部条件では日本語非対応の可能性があるので注意が必要です。じっこくんでは、シンプルにエンティティの有無を判断基準としました。また、情報の取得条件はANDやORなどを指定することで少し幅をもたせることができます。
会話の流れが決まったら、一つ一つの条件が足りない／満たされた場合などについてBotからの返信やアクションを指定していきます。これがないとBotがずっと無言になってしまい、Botの体をなさなくなります。
Botは人間味があるほど親しみやすくなり、親しみやすいほど継続して利用してもらうことができます。口調がラフになりすぎてユーザーを怒らせてしまうのはもちろん避けるべきですが、過剰にかしこまった態度もユーザーからBotのエラーが許容されにくい雰囲気ができてしまいます。良きコンシェルジュであろうとすることは素晴らしいですが、機械の下僕にならないよう気をつけましょう。
あなたのBotが目指したい存在はユーザーとどのような関係で、どういった性格なのかイメージできるようにしておきましょう。ユーザーのインプットに対して「おっけー！」「はい。ちょっと待っててください！」「承知しました。しばらくお待ち下さい」どのように返答するかでユーザーがBotにどれだけ親しみを持つか変わってくるでしょう。
Botが必要な情報をすべて集めることができたら、スキルを発動します。具体的にどのようなイベントが発生してほしいのかを、"Action" タブで指定します。
じっこくんは、ユーザーが入力した条件をもとにNode側でデータを取得する、という作りになっているので時刻表検索スキルのアクションではNodeへのPOST用URLを指定しています。
アクションをすべて記載したら、最後に "Reset all memory" を追加します。メモリーをここで一度リセットしないと、スキル発動後にもその時点までの入力情報が残ってしまい、新しい会話でも情報が上書きできなくなってしまいます。例えば、朝に入力した stationOff = 永田町 の情報が時刻表表示後にも消えずに残ってしまうと、夕方帰宅するタイミングで再度じっこくんに話しかけても stationOff = 永田町 の情報はすでに持っていると認識されてしまい stationOn = stationOff = 永田町 としてエラーが返ってきたりすることになります。基本的には、アクションが終了したらメモリは消しましょう。遊び終わったおもちゃをおもちゃ箱にしまうように。
Bot 編集画面の右下から "CHAT WITH YOUR BOT" のボタンを押すと、その時点でのBotとおしゃべりすることができます。想定している機能が正しく動いているか確認しましょう。Botからの返信が想定と違う場合には、Botの吹き出しについている i のマークを選択することでユーザーからの入力をどうBotが解釈したかについての情報が確認できます。
ただし、WEB上での動きと、実際にユーザーがBotと触れ合うインターフェースでの動きが異なる場合があるので実際のインターフェースでも早い段階から動作確認しましょう。じっこくんでは、LINEーRecast間のやりとりになにかの問題があったようでうまく動かない部分がありましたが、仕様情報が公開されていないため調査不可能→Botの動きを変更する、という対策をとる箇所もありました。
タブ "Monitor" からは、外部インターフェースからの入力をどう解釈したかの履歴を確認できます。ここで意図せぬ解釈が発生していた場合には、直接エンティティの割当を変更→学習させることができます。
ある程度Botが正しい会話ができるところまで成長したら、入力に不自然・不便な箇所はないか、説明はわかりやすいか、エラー発生時にユーザーをネクストアクションへガイドできるかどうか… 等様々な角度からテストを続けましょう。質問が冗長だったり、ユーザーに考えさせる作りになっていると、チャットボットならではのテンポの良い会話ができなくなるので改善が必要かもしれません。
構築とテストを繰り返しながら徐々にBotの完成度を高めていってください！
公式のガイドももちろん非常に有益ですが、それでも解決しないような事象や、バグなどを発見した場合には、 https://sapcai-community.slack.com/ に参加→ #help_support チャンネルから開発チームや詳しいユーザーたちに直接質問することができます！（しかも返答率が割と高い） メールアドレスがあれば誰でも参加できるのでおすすめです。
いかがでしたでしょうか？ 長くなってしまいましたが、Recastの日本語のマニュアル代わりになればと思い作成した本記事が、みなさんの助けになれば幸いです。
ハッピーBOTライフ！
- 東京公共交通オープンデータチャレンジに応募してみた
- 「まよワン！じっこくん」とは？(アプリケーション説明とアーキテクチャ概要)
- デザインシンキングでアプリ要件を考えてみる(デザインシンキング)
- チャットボットの開発（SAP Conversational AI） ←ここ
- SAP CP上でのバックエンド開発(Node.jsとSAP HANA)
- SAP CPで開発したアプリをJenkinsでDevOps
今回はRecast.AI（現SAP Conversational AI）でチャットボットを作ってみる回です。
「まよワン！じっこくん」の機能について第1～3回で触れていますが、LINEで時刻表情報を教えるチャットボットを作るにあたり、機能を「会話」と「検索」に分割して開発することになりました。
「検索」パートではNode.jsを使って、ユーザーが求めている情報を検索・取得します（詳細は連載5,6をどうぞ）。
「会話」パートではRecast.ai（現SAP Conversational AI）というチャットボットを使って、ユーザーからのインプットを認識、適切な返事をしつつ、後続の「検索」パートで必要になる情報をユーザーから引き出します。
本記事では、「会話パート」でのチャットボット作成の流れと気にするべきポイントを紹介します。
はじめに
Recast わりと便利
思い通りの柔軟な作り込みが可能なツールではないけれど、30分もあれば簡単なおしゃべりができるBotが作れるし、無償でも実用に耐えうる、すごい！ さっとプロトタイプ作るのにも使えるなと思いました。
チャットボットを作る時に大事だなと思ったポイント3点
発言一つ一つや動線がUXにダイレクトに影響する
どんなに優れた機能やロジックを用意しても、ユーザーが使いづらい・使い方がわからないような機能は結局使われることがありませんでした。
ユーザーだったらどう使うかを考える
チャットボットがユーザーの発言を正しく認識するには、予め想定されうる会話集をインプットしておく必要がありますが、開発者目線でのみインプットして作ってしまうと、実際のユーザーの発言を理解できない事態になります。悲しい。
「ロボットではなく実際に誰かと会話してる感じ」をどう出すか
主機能には直接関係ありませんが、Botに親しみを持ってもらうために非常に重要です。
チャットボットつくりかた
チャットボットを作るときはざっくり以下の流れで進め、時刻表検索以外の機能を足したいときには、機能ごとに1～7を繰り返しました。もしかしたらもっと効率の良い作り方があるかもしれない＋場合によって多少前後しましたが、我々は大体この流れで最後までやりました。
- どんな情報が必要か洗い出す
- インテントをつくる
- エンティティを増やす
- スキルをつくる
- 会話の流れを組み立てる
- テストする
- トレーニングする
1. どんな情報が必要か洗い出す
じっこくんの場合は、Node側で時刻表を検索するために乗車駅や出発時刻などの情報が必要でした。2以降を作り始める前に「どんな項目を」取得して「どんなパラメーター名で」Nodeに渡すのか考えます。Botを作り始める前に、バックエンドチームとしっかり相談しましょう。（RecastよりNodeのほうが自由度が高いため、うまく動かない時にはNode側でのコーディングで吸収してもらうことが多々あります。Node側の人とは仲良くしましょう）
ちなみに：
じっこくんで検索時に必要な項目は以下です。
乗車路線
乗車駅名
降車駅名
乗車時刻
曜日タイプ（平日／休日）2. インテントをつくる
設計イメージができたら、インテントをつくります。
インテントとは、「文脈を読み取る基準」で、ユーザーの入力から「つまり何についてしゃべっているのか」を判断するためのものです。なので、基本的には実装したい機能ごとに1つのインテントを作ることになります。
インテントは、Recast内で @xxxxx のように表されます。名前の付け方はなんでもいいのですが、じっこくんのメイン機能である時刻表には @timetable という名前をつけました。
ちなみに：
じっこくんのインテントは最終的にこんなかんじになりました。
各インテントの右側のラベルが次に説明する「エンティティ」です。3. エンティティを増やす
インテントができたら、そのインテントに紐づくエンティティを作ります。エンティティは、ユーザーが入力した単語を識別するためのラベルです。#YYYYYY で表されます。
例えばユーザーが
「半蔵門線で半蔵門駅から渋谷駅まで」と入力した場合、以下のようにエンティティを割り当てることができます。
半蔵門線 ＝ 路線名 ＝ #LINE
半蔵門 ＝ 乗る駅 ＝ #DEPERTURE
渋谷 ＝ 降りる駅 ＝ #ARRIVAL各インテントには、その文脈で必要な種類だけエンティティのラベルを作ります。ラベルができたら、「ユーザーが入力しそうな例文（エクスプレッション）」と「例文中のどの単語がどのエンティティとして認識されるべきか」を入力していきます。Botの機能の壮大さにもよりますが、じっこくんでは時刻表検索のために8個のエンティティと約130の例文を入力しました。
※気をつけよう※
ここでは、「ユーザーが実際に使う時どのように入力してくるだろうか？」を一番に考えましょう。ユーザーは親しみやすいBotに対して堅苦しい物言いもしなければ、誰もが同じような入力をするわけでもありません。例文にはバリエーションをもたせて、実際のユーザーの入力を正しく認識できるように育てたいです。
いまいちな例文の入れ方：
「有楽町線です」「永田町駅です」「新木場駅です」「麹町駅です」…
というように、「特定路線の駅名＋です」をひたすらインプット
→これだと以下のような理由からちょっと時間がもったいないので、下の良い例文を参考にバリエーション豊かなエクスプレッションをBotに教えてあげましょう
・「飯田橋から目黒」などの「駅」や「です」がついていない文章を認識できない
・「特定路線の駅名＋です」パターンの例文は2～3個あれば十分
・サクッと時刻表が知りたいのに「です」まで入力する人は少ない（自分でテストしてみればわかる）
よい例文の入れ方：
「都営大江戸線、東新宿から六本木一丁目、15時40分」
「早稲田駅から高田馬場」「１９時」「平日」
「南北線 赤羽岩淵 東大前 0830」「きゅうじつ」
というように、想定されうるパターンをなるべく網羅する
→駅名をつけるのかつけないのか、ひらがなかカタカナか、全角半角…などなど数人でテストするとみんな入力方法がばらつくので、そこで出てきた入力スタイルを加えてあげると対応力の高いBotになります。
4. スキルをつくる
一通り例文が出揃ったらスキルを作成して「どのような機能（会話の流れ）を用意するか」を定義します。
タブのBuildから新しいスキルを作ると、以下のように箱で表示されます。編集したいときは箱をクリック、新しい機能を増やしたいときはスキルを追加していきます。
スキルの「fallback」はデフォルトで用意されているもので、ユーザーの入力した文章が作成したどのスキルにも当てはまらない＝処理できないときに起動します。Siriでいう「すみません、よくわかりませんでした」にあたる内容がfallbackです。
ちなみに：
じっこくんでは主機能の時刻表検索以外に、
・入力した内容の取り消し
・お気に入り検索
・使い方を教える
・免責事項を表示する（大会規定により）
…等の副機能を用意したのでそれぞれに対してスキルを作成しました。5. 会話の流れを組み立てる
スキルを編集する形で「どのようにユーザーと会話して情報を集めるか」を作り込んでいきます。チャットボット作成で一番やりがいのあるパートです。流れやこなれ感含む会話の自然さが使いやすさに直結するのでユーザーの気持ちになって会話を組み立てていきましょう。
5.1 トリガを決める
まずはTriggersタブから「スキルを開始するきっかけ」となるトリガを作成します。
ちなみに：
じっこくんでは、@timetable のインテントに合致する文章が検出されたら
時刻表検索スキル「train_info」を発動するようにしました。5.2 会話の流れを決める
Requirementsタブでは「今の機能を完了するためにどの順番でどんな情報をどんな聞き方で取得するか」を決定します。システム的には「条件（ここでは必要な情報の充足）が満たされている場合に、アクションを実行するか」を決めるためのステップです。
じっこくんの時刻表検索機能では乗車路線・乗車駅名・降車駅名・乗車時刻・曜日タイプ（平日／休日）の情報が必要だったので、これらをどのようにゲットするか考えた結果以下のようになりました。会話は基本は上から順に流れていきますが、ユーザーがBotの質問を待たずに情報を提供してくれた場合には、そのブロックはスキップされて、足りていない情報をゲットするための質問が上から流れます。
じっこくんは基本 路線＞乗る駅＞降りる駅＞乗りたい時間＞曜日タイプ の順番で質問を投げるようデザインしました。この順番がめちゃくちゃになってしまうと使いづらさにつながるので、どう聞かれたら答えやすいかを考えて作りましょう。
Requirementsで要求する条件には、「特定のエンティティの有無」「時刻情報」「感情のポジティブ／ネガティブ情報」などなどさまざまな情報を指定することができますが、一部条件では日本語非対応の可能性があるので注意が必要です。じっこくんでは、シンプルにエンティティの有無を判断基準としました。また、情報の取得条件はANDやORなどを指定することで少し幅をもたせることができます。
5.3 会話の内容を決める
会話の流れが決まったら、一つ一つの条件が足りない／満たされた場合などについてBotからの返信やアクションを指定していきます。これがないとBotがずっと無言になってしまい、Botの体をなさなくなります。
Botは人間味があるほど親しみやすくなり、親しみやすいほど継続して利用してもらうことができます。口調がラフになりすぎてユーザーを怒らせてしまうのはもちろん避けるべきですが、過剰にかしこまった態度もユーザーからBotのエラーが許容されにくい雰囲気ができてしまいます。良きコンシェルジュであろうとすることは素晴らしいですが、機械の下僕にならないよう気をつけましょう。
あなたのBotが目指したい存在はユーザーとどのような関係で、どういった性格なのかイメージできるようにしておきましょう。ユーザーのインプットに対して「おっけー！」「はい。ちょっと待っててください！」「承知しました。しばらくお待ち下さい」どのように返答するかでユーザーがBotにどれだけ親しみを持つか変わってくるでしょう。
5.4 アクションを設定する
Botが必要な情報をすべて集めることができたら、スキルを発動します。具体的にどのようなイベントが発生してほしいのかを、"Action" タブで指定します。
じっこくんは、ユーザーが入力した条件をもとにNode側でデータを取得する、という作りになっているので時刻表検索スキルのアクションではNodeへのPOST用URLを指定しています。
アクションをすべて記載したら、最後に "Reset all memory" を追加します。メモリーをここで一度リセットしないと、スキル発動後にもその時点までの入力情報が残ってしまい、新しい会話でも情報が上書きできなくなってしまいます。例えば、朝に入力した stationOff = 永田町 の情報が時刻表表示後にも消えずに残ってしまうと、夕方帰宅するタイミングで再度じっこくんに話しかけても stationOff = 永田町 の情報はすでに持っていると認識されてしまい stationOn = stationOff = 永田町 としてエラーが返ってきたりすることになります。基本的には、アクションが終了したらメモリは消しましょう。遊び終わったおもちゃをおもちゃ箱にしまうように。
ちなみに：
「ほめて」機能のように、ユーザーに対して複数通りの返信を投げたい場合は、
アクションで指定する返信を複数用意し、条件をORにすることで実装できます。6. テストする
Bot 編集画面の右下から "CHAT WITH YOUR BOT" のボタンを押すと、その時点でのBotとおしゃべりすることができます。想定している機能が正しく動いているか確認しましょう。Botからの返信が想定と違う場合には、Botの吹き出しについている i のマークを選択することでユーザーからの入力をどうBotが解釈したかについての情報が確認できます。
ただし、WEB上での動きと、実際にユーザーがBotと触れ合うインターフェースでの動きが異なる場合があるので実際のインターフェースでも早い段階から動作確認しましょう。じっこくんでは、LINEーRecast間のやりとりになにかの問題があったようでうまく動かない部分がありましたが、仕様情報が公開されていないため調査不可能→Botの動きを変更する、という対策をとる箇所もありました。
タブ "Monitor" からは、外部インターフェースからの入力をどう解釈したかの履歴を確認できます。ここで意図せぬ解釈が発生していた場合には、直接エンティティの割当を変更→学習させることができます。
ある程度Botが正しい会話ができるところまで成長したら、入力に不自然・不便な箇所はないか、説明はわかりやすいか、エラー発生時にユーザーをネクストアクションへガイドできるかどうか… 等様々な角度からテストを続けましょう。質問が冗長だったり、ユーザーに考えさせる作りになっていると、チャットボットならではのテンポの良い会話ができなくなるので改善が必要かもしれません。
構築とテストを繰り返しながら徐々にBotの完成度を高めていってください！
X. 困ったときは
公式のガイドももちろん非常に有益ですが、それでも解決しないような事象や、バグなどを発見した場合には、 https://sapcai-community.slack.com/ に参加→ #help_support チャンネルから開発チームや詳しいユーザーたちに直接質問することができます！（しかも返答率が割と高い） メールアドレスがあれば誰でも参加できるのでおすすめです。
さいごに
いかがでしたでしょうか？ 長くなってしまいましたが、Recastの日本語のマニュアル代わりになればと思い作成した本記事が、みなさんの助けになれば幸いです。
ハッピーBOTライフ！
- SAP Managed Tags:
