チャットボットのためのサービス設計・開発入門

チャットボットのための
サービス設計・開発⼊⾨
株式会社アポロ岡野健三

【本講義の目的】
チャットボットの
開発、運⽤、リリース、そして改善まで
出来るようになること

• ⾃⼰紹介
• チャットボットとは？
• 主なユースケース・アンチケース
• チャットボットの開発フロー
• 俺みたいになるな〜実体験を基にしたしくじり話〜
• チャットボットの今後の⽅向性
• 最後に→チャットボット関連企業・サービス⼀覧を配布
今日お話すること

株式会社アポロ
代表取締役社⻑岡野健三(@OKenzo22)
2013年4⽉: 早稲⽥⼤学法学部⼊学
2016年7⽉: 早稲⽥アプリケーションコンテスト準優勝
2017年3⽉: LINEBOTAWRADS 企業賞受賞
2017年7⽉: 「新たな繋がりを創出する」ことをビジョンに、
株式会社アポロを設⽴。代表取締役社⻑に就任。

株式会社アポロとは
チャットボットに関連したサービスを提供する会社

実現したい世界
まだ繋がっていない情報・物・⼈を繋げる

【チャットボットとは？】
メッセンジャーサービス上で利⽤可能な
主に対話型のUIを⽤いたアプリケーションのこと

【主に？例外はあるの？】
徐々にGUIと混合して使うものに
⽤いるコンポネントの例
→ボタン・ファイル・画像・動画・⾳声・・・

【⼈⼯知能・AIを使うんでしょ？？】
⼈⼯知能APIは必要ないこともある
「A Bot is a app !」by Christopher Harrison@Microsoft

【メッセンジャーサービスってどんな物があるの？】
・Facebook Messenger (全世界MAU12億⼈。C向け)
・Wechat(中国。MAU9億⼈弱。チャットボットというよりもミニアプリ)
・LINE (⽇本・タイ・台湾・インドネシアのみ。MAU2億強)
・Kik(北⽶・若者向け。C向け)
・Viber (欧州。C向け)
・Slack (B向け)
→利⽤者にあったメッセンジャープラットフォームを選択する必要がある

【主なユースケース】
すべての課題を解決してくれるものではない
「私の仕事は、ボットを作るなと、⼈に⾔うこと」
by Christopher Harrison@Microsoft
「それチャットボットにする必要ありますか？」
By 及川卓也

【主なユースケース~アンチパターン~】
①検索対象の数がとても多いもの
→WEB/アプリのほうが視認性・閲覧しやすさという点で勝つ
→僕が作成したチャットボットのAPOLOもアンチパターンだった
②チューリングテストを合格しようとするもの
Ex.りんなちゃん・Siri・Cortana (よほどのデータ・技術⼒がない限り、サードパーティーは戦ってはいけない領
域)
③アプリ・WEBで出来ること
1.天気確認
2.メール通知
3.バイト探し
→これ本当チャットボットでやる必要ありますか？？

【主なユースケース~議論が分かれるもの~】
①強みの通知機能を活かした物
Ex.メディア配信(メールの代替となるもの)
→開封率がいいと⾔われているけど、増えてくると嫌な感じがするのでは？
②何か本体アプリケーションに対して操作するクライアントとして利⽤
Ex. IoTデバイスのクライアントとして利⽤
→本当にユーザーが満⾜する機能が全て網羅できるか？開発側のリソース不⾜解消
に繋がるのは理解できるが・・・
→アプリのほうが使える機能のでは？？

【主なユースケース〜グッドパターン〜】
①Knowledge Base Bots→何かすでに知識・ノウハウが⽤意されているもの
柔軟な検索が必要な場合 Ex 使い⽅説明書、ヘルプデスクなど
→アスクル
①ʼ 専⾨家を代替するもの
医者、弁護⼠、税理⼠、社労⼠・・・
→定形作業をリプレイス
・医療チャットボット Docsapp(https://www.docsapp.in/)
「インドの医療アプリ」が安⼼便利で何もかも⾰新的だった | ホウドウキョク](https://www.houdoukyoku.jp/posts/15647)
・ 20歳のスタンフォード⼤学⽣が開発した法律チャットボット DoNotPay
⼩銭稼ぎは興味ないとのこと。Evernote創業者フィル・リービンから出資を受けている。
弁護⼠事務所のアルバイトの代替 or C向け課⾦(罰⾦減額の成果報酬型。特に過払い請求とか)が将来的にありえるかも
1,000個のボットを作成して、適切なものをユーザーに提⽰する
https://japan.cnet.com/article/35085120/
・法律業務⽀援チャットボット? 未踏事業でも⼀つ採択されてる
http://www.ipa.go.jp/jinzai/advanced/2017/gaiyou_m-1.html

【主なユースケース〜グッドパターン〜】
②Handoff to Human →⼈間へのバトンタッチ
よくカスタマーサービスで使われている。簡単なものは⼈⼯知能で・・・難しいのは⼈で
→ヤマト運輸
③Backchannel→裏ルート
裏では⼈間が操作しているけど、側はボットという場合
Facebookのボットは、標準搭載で使⽤できる
④ソーシャル性
メッセンジャーサービス上で既につながっているので、再び繋がる必要性が無い
→グループでみんなで同時にアプリを使うという新しい体験
→⼈狼Bot(LINE BOT AWRADS決勝進出) 20万⼈強の登録者
⑤LINE Beaconを利⽤した位置情報を利⽤した物
→ユニクロ。販促に使える。株式会社アポロでもイベント系で1件進めている
⑥タスク⾃動化(主にSlack。つまりB向け)
→GoogleAnalyticsなどマーケティングツールの通知、サーバーの状態監視とか
(個⼈的予想)チャット型⼩説ボットは流⾏る。(北⽶ではティーンに流⾏ってきている)
→⾃分のテキストで、展開が変わったらより没⼊感が⾼まる

【主なユースケース〜未知なるキラーボット〜】
「ただスマホのときは誰もUberを予想できなかった。
限られた数個のBotが世界を変えるだろう」
by Amir Shevat(slackのエンジニアリレーショントップ)

【チャットボットの開発フロー】
①構想
②ユーザー
ストーリーを
すべて書きだす
③ビジュアル
＆コピー
ブランディング
⑥リリース・改善⑤テスト④開発・デザイン

【①構想】
・MVP(Minimum Viable Product)を⽬指して、解決する課題とそれ
を解決する最低限の⼿段(機能)を決める (チャットボットだけで完結す
るサービスは特に気をつける)
→過剰に機能を追加して、様々な課題を解決しようとするとあまりうまくいかないことが多い。
Ex.法律チャットボットDonotpayは、「徐々に新しい機能を加えていくにつれて、何のためにどう
やって使うのかわからない」という課題意識を持ち始めたそう。結局機能ごとに切り分ける⽅向に
⽅向転換した。
→その機能はチャットボット以外で本当にできないのか？を⾃問⾃答した⽅が良い(チャットボット
はあくまで⼿段)

[①ターゲットユーザーの特定の満たしたいニーズその1]たい、
[①ターゲットユーザーの特定の満たしたいニーズその2]たい、
[②ターゲットユーザー]向けの、
[③サービス名]というプロダクトは、
[④30⽂字ぐらいのサービスの簡単な説明]である。
これは[⑤サービスの最も⼤きな特徴]ができ、
[⑥ニーズを満たしたいユーザーが利⽤している既存の⼿段]とは違って、
[⑦サービスの機能その１]や
[⑦サービスの機能その２]や
[⑦サービスの機能その３]が
備わっている。
【①構想の例∼利用すると良い例文∼】

[新しい⾳楽と出会い]たい、
[共通の⾳楽の趣味を持った⼈と⾳楽の話題で盛り上がり]たい、
[⾳楽好きな⾼校⽣]向けの、
[APOLO]というプロダクトは、
[架空のキャラクターとチャットをしながら⾳楽が聴けたり、他の⼈と
⾳楽について盛り上がれるサービス]である。
これは[いつ、どこでも、すぐに⾃分にあった⾳楽を聞くこと]ができ、
[既存の⾳楽視聴サービス(YouTubeやApple Musicなど)]とは違って、
[毎⽇決まった時間に新しい⾳楽ランキングが届く機能]や
[会話の中から⽂脈を読み取って⾳楽をレコメンドする機能]や
[グループでチャットをしながら、⾳楽が聴ける機能]が
備わっている。
【①構想の例∼APOLOの場合∼】
公式キャラクターポアルン

【②ユーザーストーリーを全て書き出す】
◯ユーザーストーリーとは？
ユーザーがたどる状態・遷移・動作を全て図⽰する
→オートマトンのようなものを描く(あとで例をお⾒せします)
◯ユーザーストーリーを図⽰すること⽬的
チャットボットの全体図を把握して、スムーズな開発・デザインを⽬
指す

【 ②ユーザーストーリーを全て書き出す】
(1)イントロについて
・まずはボットによって得られるメリットを伝えよう。それからユー
ザーに操作を要求しよう。
・このボットは何ができるのかを具体的に説明してあげよう。ユー
ザーはボットを利⽤する体験は初と思っておいたほうが良い。
<使える技>
・GIFを最初の説明に⽤いる→天気ボットPoncho
・選択肢を使った説明→スライドさせながら、教える

(2)実際の利⽤シーンについて
①Task-Led Conversation(あるタスク・仕事をやってもらうもの Ex. ⾶⾏機の予約など)②Topic-Led
Discussion(多くの選択肢から選択すもの Ex. 漠然としたものをレコメンドしてもらうもの。服を探すなど)
という⼤きく分けて2種類のBotが存在する。⾃分のボットが何を⽬指しているかを意識しよう。
→②Topic-Led Discussionの場合はユーザーが間違ったり・希望する答えが存在しない場合は、別の話題に
する or⼈間が代替するようにしても良い
<ユーザーストーリーをまとめるときに、気をつける点>
①【ユーザーストーリーの基本的な流れ】
[1]Understand intent(ユーザーの意図を読み取る) [2] Extract entities (ユーザーの⼊⼒したテキストから主
要な単語・⽂章を読み取る)[3]Execute Task(必要なタスクを完遂する)
この3つをぐるぐる回すことになるので、ユーザーがこの状態の時にどういった発⾔をするだろうかと予測
する
→基本的にはif⽂か、⾃然⾔語処理技術・⾃然⾔語処理APIを⽤いる
（詳しくは、僕のQiitaの記事(http://qiita.com/kenzo0202/items/582e3a5e06b64ab24964)で)

②【全てのユーザーの⼊⼒に対応する必要がある】
・ユーザーの感謝や愛に対する返答も必ず⽤意する
<使える技>
単純な⽂字に加えて、絵⽂字👍、GIF、写真を使うのも重要
同じ返答を繰り返さず、バリエーションをもたせるように
・エラーハンドリングを必ず⾏う
前提として、ユーザーは適当な⽂章を送ってくる。(これはAPOLOでもめちゃくちゃありました。罵詈雑⾔を浴びせられ
ました（笑）)
<使える技>
→理解できないユーザーの⼊⼒に対しては、①理解できないことを伝える②前の同趣旨の⽂⾔を繰り返す③ユーザーに
フィードバックをもらう。最悪の場合は、最初に戻ろう。
→⾃分の提供するボットができないことは、ほかのボットを紹介しよう。
<やってはいけないこと>
世間話・雑談はほどほどにしておこう。ユーザーのニーズを満たすことがより重要。
→雑談対話APIは極⼒使わないようにしよう

③【適切な質問が出来ているか必ずチェックする】
・Yes/Noなのか、特定の答えを聞き出すかで、質問は異なる。⼈間の会話と考え⽅を前提にして、そこか
らより意図する答えを引き出せるようにしよう！
Ex.「いつ⾶⾏機を使いますか？」→「何⽉何⽇何時に⾶⾏機をつかいますか？」
<使える技>
→答えられる選択肢を制限する(ボタン・記⼊例を書く)
④【エンゲージメントを⾼める施策を実施しよう】
ユーザーが使いこなせるように、細かな配慮をしよう。
＜使える技＞
①helpコマンド(⽂脈に即したhelpコマンドの対応を⽤意すると尚良い)→いつでも使い⽅を確認できるよう
に
②helloコマンド→会話の始め、最初のシナリオに⾏けるコマンドを⽤意
③プラットフォーム専⽤のもの
→Ex: ヤマトの「にゃ」って返してくれるもの

・Botが持つ個性を規定してあげる必要がある
①名前②写真(選択肢など)③ロゴ④コマンド(/weather ◯◯など)→サービス名を前に付けること
を要求するとよい(エンゲージメントに繋がる)⑤キャラクター(必要であれば)といった項⽬を決定
する。
→⼀度個性を極めたら、その個性をユーザーの体験を通じて⼀貫させる必要がある
【配慮するべき項⽬】
①環境(toBかtoCか、ラフかシビアか)②ユーザー③やるタスク④⽂脈⑤⽂化⑥既存のサービスの
ブランド⑦サービスの届ける価値のいくつかで決まってくる
【 ③ビジュアル＆コピーブランディング】

(例えばAPOLO/ポアルンの場合・・・)
まずはブランドパーソナリティーを決めた。
→ブランドパーソナリティーとは、ブランドから連想される⼈間の⼼理的特性のこと。
[ブランドパーソナリティ]
活発、元気、まとめ役、コミュニケーション能⼒が⾼い、楽しい、若い、頼れる、⾃由、賑やか、分別があ
る
[嫌いなもの]
⾃⼰中⼼的な⼈、⼈の悪⼝を⾔う⼈、周りが⾒えない⼈
[好きなもの]
学校の教室、体育祭、学園祭、放課後、⾳楽
[好きな⾷事]
ピザ、ハンバーガー
[好きな飲み物]
コーラ
【 ③ビジュアル＆コピーブランディングの例】

(例えばAPOLO/ポアルンの場合・・・)
①名前
サービス名 : APOLO
キャラクター名: ポアルン
→アポロンがギリシャ神話で芸術・⾳楽の神様だった事と宇宙船のアポロが⼈類未踏の偉業を成し遂げたと
⾔う意味でチームで偉業に挑戦しようとしたことが由来。そこからアポロ→ポアロ→ポアロン→ポアルン
②ロゴ③キャラクター(必要であれば)
アイコンは、チャットボットのコミュニケーションという⽂脈で吹き出しを採⽤。（画像左）
キャラクターは、アポロから宇宙⾶⾏⼠を着想。⾳楽好きな若い宇宙⾶⾏⼠というイメージ。(画像右)
【 ③ビジュアル＆コピーブランディングの例】

【④開発・デザイン】
【開発⾯で気を付けること】
メッセージが同時に⼤量に送られた場合を想定して、同トラフィックを裁くか考える
→⾮同期な処理を⼼がける
・例えばNode.jsで開発する場合、promiseなどは必須
・ Queue（RabbitMQとか）やメモリDB（Redisなど）を利⽤して、LINEのサーバーからメッ
セージが来たら、すぐに200を返してメッセージをとにかくLINEのサーバーに貯めないようにす
る
【参考】
⼤量メッセージが来ても安⼼なLINE BOTサーバのアーキテクチャ
(http://qiita.com/yoichiro6642/items/6d4c7309210af20a5c8f)

⾳楽情報DB
各種楽曲API APOLOサーバー
Docomo会話API
FB,LINEサーバー
Webhook
ユーザー
楽曲情報リクエスト
API Gateway lambda DynamoDB
メッセージ
整形された
メッセージ
楽曲
ユーザー情報
会話情報
プレイリスト情報
楽曲情報
メッセージ整形された
メッセージ
楽曲
S3
画像
感情分析API 感情別⾳楽API
感情別⾳楽情報Route53 ELB

【デザイン⾯で気を付けること】
基本的には選択肢の画像や以前説明したビジュアル・コピーブランディングの部分が⼤きい
→アプリやWEBのように柔軟性は少ないため、デザイナーの負担は少ない。
リッチメニュー
選択肢のサムネイル

【⑤テスト】
【テストについて】
ターゲットユーザーとなる⼈に実際に触ってもらおう
→ユーザーには特定のタスク(例えば天気ボットであれば、明⽇の天気がどうか知るなど)を遂⾏
してもらいましょう。あくまで前提条件のみ伝えて、使い⽅は説明しないでおきましょう。
(チェックポイント)
①最初の登録時の説明は過不⾜ないか？
②ユーザーのテキスト⼊⼒に対して、適切は応答が出来ているのか？
③ユーザーが次のアクションを困ること、また間違うことがないか？あれば、どんなときか？
→APOLOの際、ボタンの押せる部分がわかりにくいと⾔われることがありました

【⑥リリース・改善】
【リリース・改善について】
・リリースは出来るだけ最⼩限の機能でしよう
→機能の追加は使いにくさに繋がる
・改善する際の重要な情報源は、会話のログ
→アプリ・WEBと違い、ユーザーの⽣のアクション・印象が明確にわかる
<チェックポイント>
①⾃前のDB or アナリティクスツール(https://botanalytics.co/とか
https://www.dashbot.io/→LINE未対応とか)をリリース前に過不⾜なく設定できているのか？
②喜怒哀楽を表す感情表現はいつ出ているのか？それに対してどうすれば改善できるのか？

チャットボットのためのサービス設計・開発入門

More Related Content

More from KENZO OKANO

チャットボットのためのサービス設計・開発入門