- 講演資料：Waterfall cafeで働くBot
LINE Botならユーザーは「新しい使い方」を覚える必要がない
中嶋氏はLINEの画面をスクリーンに映し、Botのデモをスタート。まず「今日のメニューは何ですか？」とメッセージを送ると、Botは「Plate Aは『かつ重』、Plate Bは……」などと当日のメニューを答えてきた。次に「本日の献立を教えてください」と別の言葉で試しても、Botの答えは同様だ。メッセージの表現を変えても同じように適切な答えが返ってくるのは、Botが「意図」を読み取っているからだという。
続けて「明日は？」と問いかけると、Botはきちんと翌日のメニューを返答。さらに「カロリーを教えてください」と送ると、「どのプレートですか？」と聞き返してきた。これらは「文脈を把握しているからこそ可能なこと」だと中嶋氏は説明する。つまり、Botは前の会話を文脈として覚えているので、「明日は？」だけでも「明日のメニュー」のことだと理解する。そのあとのカロリーについても「明日のメニューのカロリー」だと理解し、追加で確認すべき情報はプレートの種類だけ（いつのメニューかは不要）と判断しているのだ。
このBotはメニューとカロリーを教えてくれるだけでなく、カフェにまつわるFAQの窓口としても機能している。例えば「カフェで外部のお客様を招いてセミナーを開催するには？」（※カフェは実際にセミナー用のスペースとして利用可）といった質問に対して、申請手順などをFAQから見つけて答えてくれる。FAQは聞かれる内容を予測しきれないため、メニューやカロリーに比べて実装が難しいのだが、中嶋氏はこの機能の将来的な可能性を重視しているという。それは、社内のさまざまなFAQをカバーする「社内ポータル」としての活用だ。
「既存の社内ポータルは必要な情報が見つけにくいなど、使い勝手が悪いものが多い。面倒な社内申請手続きなどは、ポータルで探すよりも“長老”のような社員に聞いたほうが早かったりする。その役割は、人ではなくBotに集約したほうがよい」（中嶋氏）
さらにもう1つの機能として、このBotはカフェの照明のコントロール（オン／オフ、照明色切り替え）というIoTの要素も取り入れている。中嶋氏は会場に小型のライトを持ち込み、この機能についても実演。「ライトの色を変えてください」→「何色にしますか？」→「青」→「了解しましたー」といったように、Botとの会話を通じて実際に照明をコントロールできる様子を紹介した。
ひととおり機能を紹介すると、中嶋氏はこのBotをLINEの友だちに追加できるQRコードをスクリーンに投影。参加者はそれぞれ手元のスマートフォンでBotと会話しながら、照明色の変更などデモで紹介された機能をセッション終了まで自由に試していた。
「友だちに追加するだけですぐに使える。この手軽さこそが、LINE Botの大きなメリット」と中嶋氏は強調。LINEならほとんどの人は自分のスマートフォンに入っており、使い方も知っている。Botの操作もLINE上で「会話」すればよいだけだ。ユーザーは何か新しい使い方を覚える必要もなく、導入障壁は限りなく低いといえるだろう。
なお、このBot本体のプログラムはNode.jsで作成され、PaaSの「Oracle Application Container Cloud」上で稼働。API連携により、さまざまな外部サービスを利用している。例えば、ユーザーのメッセージから意図を解釈する自然言語解析エンジンには「api.ai」のサービスを利用。献立（メニュー）データのデータベースは、ExcelなどあらゆるデータをAPI化できる「Oracle Database Cloud」。FAQの機能は、AIを搭載するFAQのSaaS「Oracle Service Cloud」を使っている。そして、IoT対応照明器具の「Hue」を連携サービスの「IFTTT」を介してBotからクラウド経由でコントロールできるようしているという。
“カフェで働くBot”の機能を実現
この構成が示すように、Bot開発においては「すでにあるものは作らずに、それを使うこと」が重要だと中嶋氏は指摘。
「単体ですべての機能を満たすのは不可能で、いろいろな外部サービスからベストなものを選択してプラグインを追加していく。そのためには、マイクロサービスアーキテクチャが必須。『まずSaaS、なければPaaS』と、できるだけ上のレイヤーから使える外部サービスがないか検討し、自分が作る範囲を狭めていくべき」
柔軟にBotの機能を拡張できるように5つのフローを定義
続いて中嶋氏は、Bot本体の開発メソッドについて解説。「Bot開発は発展途上で、まだまだ改善の余地がある」としながらも、現時点で中嶋氏が特に重視している要素として「スキル」と「フロー」の2つを挙げた。
スキルとは「Botが対応できる仕事」のことだ。今回のBotの場合、「メニューを回答」「カロリーを回答」「照明色を変更」「FAQに回答」という4つのスキルがある。中嶋氏によれば、どれくらいBotが楽しいものになるかは、このスキルの多様さや精度の高さで決まり、これをいかに簡単に追加できるようにするかがBot開発の鍵だという。そこで重要となるのがフローだ。
フローとは「文脈に応じてどういう順番で何を実行するかのパターン」を意味する。中嶋氏は「これがきれいにフレームワーク化できれば、Botのスキル追加が圧倒的にやりやすくなる」と考え、今回のBot開発において5種類のフローを定義した。
- Start Conversation Flow
- Reply Flow
- Change Intent Flow
- Change Parameter Flow
- No Way Flow
Botがメッセージを受け取ると、メッセージ（イベント）に対して5つのフローのうちいずれかが適用され、返信までの処理が行われる。大まかな処理の流れは各フロー共通で、メッセージから意図を解釈してスキルを特定し、必要なパラメータを収集、情報がそろったら最終的にユーザーへ返答……となる。必要なパラメータとしては、例えばメニューなら「年月日」、カロリーなら「年月日」「プレートの種類」が挙げられる。
5つのフローの内容は次のとおりだ。
Start Conversation Flow
会話の始まりを意味するフローで、Botがユーザーとの会話を記憶していない場合に適用される。このBotでは60秒間記憶を保持する設定で、LINEのIDごとに記憶を管理している（Botが文脈を把握して回答できるのは、この会話を記憶する仕組みがあるため）。メッセージを受け取るとIDをたどり、該当する記憶がなければBotは「新しい会話」と判断する。
Reply Flow
ユーザーからのメッセージが「今日のメニューを教えて」ならすぐに返答できるが、「メニューを教えて」だけの場合は年月日のパラメータを収集しなければならない。具体的には、ユーザーに「いつのメニューですか？」などと質問し、「今日」のような返答を得る必要がある。このように、Botが該当ユーザーとの会話を記憶しており、ユーザーに確認中の質問がある場合にはこのフローが適用される。
Change Intent Flow
Botが該当ユーザーとの会話を記憶しているが確認中の質問はなく、メッセージから意図が解釈できた場合に適用される。例えば「今日のメニューを教えて」→「（Botがメニューを回答）」→「カロリーも教えてくれる？」といったように、ユーザーが会話の途中で意図を変えた場合、このフローではそれまでに収集したパラメータ（年月日＝今日）を継承するので、あらためて「いつの～？」と聞き返すことはない。
Change Parameter Flow
Botが該当ユーザーとの会話を記憶しているが確認中の質問はなく、さらにメッセージから意図は解釈できないがパラメーターが抽出できた場合に適用される。「今日のメニューを教えて」→「（Botがメニューを回答）」→「明日は？」のようなケースでは「明日は？」から意図は解釈できないが、パラメータは抽出できる。この場合、それまでの会話から意図は同じと判断し、パラメータのみ変更して「明日のメニュー」を返答する。
No Way Flow
「今日のメニューを教えて」→「（Botがメニューを回答）」→「関係ないけど、個室ってどうすれば利用できるんだっけ？」のように、ユーザーがまったく関係ないことを聞いてきた際に適用されるフローで、最終手段として設定されたアクションを実行する。このBotでは、FAQのデータベースから該当するものを検索して答える設定（見つからなければ「わかりません」と返答）となっている。
現状は、この5つのフローを回すことによって、スムーズにBotのスキルを追加できるようになっているそうだ。
なお、中嶋氏はセッションで紹介したBotのソースコードをGitHubで公開している。また、有志によるBot開発の勉強会を主催し、チュートリアルなどもQiitaに寄稿。勉強会は今後も定期的に開催していく予定だという。
「Bot開発を考えている方に参考情報として活用いただきたい。皆様のアイデアや成果物も見てみたいので、勉強会にもぜひご参加を！」と呼びかけ、中嶋氏はセッションを締めくくった。
お問い合わせ
日本オラクル株式会社
- TEL: 0120-155-096（Oracle Direct）
- コーポレートサイト
- Oracle Database Cloud Service
