はじめに
私はチャットボットを作るお手伝いを何件かしていますが、トラフィックのあるチャットボットを運用したことがありません。よって運用経験のある方からの生優しいご指摘をいただけると励みになります。と、最近またお手伝いが増えてきたので、繰り返しお伝えしている内容をメモしていこうと思い立ちました。
前提
チャットボットの中でもコンテキストを保持する対話式のものではなく、主に1問1答の簡易なもの、FAQ的なユースケースが対象になります。私は仕事でIBM WatsonのNatural Language Classifierを扱うことが多いですが、ツールによらず本質は似通っていると思います。なお継続的に使って愛されるチャットボットは目指しておらず、必要なときにきちんと目的を達成する実用性に主眼を置いています。
総論
作ってみることに目的を置く練習用でなければ、課題特化型の、限られた利用用途での企画をおすすめします。目的ごとにたくさん生まれればよいと思います。現在の商用技術を鑑みれば、これは共通認識ではないかと考えています。市場/技術両面から考えて、あまり長い時間をかけず、企画から数週間程度でリリースまで到達したいですね。
開発前にすること
ペルソナを設定する
具体的に、チャットボットに人格を与えます。性別や年齢、バックグラウンドや口癖などですね。擬人化なんて言われ方もしますが、ロボットや動物などのキャラクターでもよいです。お馬鹿キャラが徐々に賢くなる感を出せれば、後述のTipに繋がるのでベストです。
また、利用者に関しても想定しましょう。問い合わせの既存ワークフローにおいて、どのポイントに挟めば最も効果が高いと想定できるか、が分かり易い観点に思います。それと、小学生男子と60代女子では、同じ質問でも回答が変わることがあります。言わずもがな、ユーザーの興味も大きく違い整備するQ&Aが180度変わってしまうことがあるため、具体的に仮定することはとても重要です。
UIを設計する
インターフェースがスマートスピーカーなのか、メールなのか、チャットなのか。ほぼチャットだと思いますが、同じチャットでも、スマホで見るLINEとデスクトップで開くWebチャットでは、表現できる量と質が違うので、デバイスやアプリを仮にでも決めてから進みます。表示するアイコンや注記、ウェルカムメッセージもUIで考えてください。こちらが相手によって答え方が変わるように、相手もこちらの見た目で聞き方を変えてきます。あとは、スマホでソフトウェアキーボードが出ている時の見え方も重要です。
回答スコープを定義する
欲張りすぎず、本当に回答すべきことに的を絞ること。業務への適用であれば挨拶やネタの仕込みはほどほどに、ユーザーへ提供する価値について真剣に考えてください。そしてスコープから外れた場合の挙動についても、考えておきます。『わかりません』の表現も、前段のペルソナやUIに沿うように定めますし、雑談や冷やかしへの対応も、それとは別に定めます。別のチャットボットに任せるという考え方もありますので、またの機会に紹介しようと思います。
想像しすぎない
整備しているのはFAQ(よくある問い合わせ)です。滅多にこない質問は『ごめんなさい』でよいのです。少ないFAQ、少ないユーザー数でトライアルをおこない、過度な精度検証よりも、実際に問われた質問への対応整備(≒運用設計)に時間を費やすべきです。FAQなので、高々数十にしておいた方がよいと思いますので、ひとりの担当者でFAQの有無を把握できなくなってきたら、すでに多すぎです。
FAQを厳選、結合する
分類先(≒回答)の数は、少ないほうが良い(簡単)です。ただ統合しすぎると、およそ回答が機械的になってきますし、UIの制限(文字数等)や視認性を損ねるなどの問題が出てきますので、バランスが大事です。ユースケース次第で十ボット十色なので、確かなことは言えません。企画時に熟考し、後述のテストフェーズで見極めます。
ドメインを意識し、応答を揃える
大別するなら、エンタメなのかミッションクリティカルな業務なのかで大きく異なります。間違っても何となく応えることが価値なのか、間違うくらいなら応えない方がマシなのかで、回答自体の中身も変えていきます。
余談
アイコンによるユーザー動向への影響はかなり大きいそうです。女性の写真やキャラクターを使うとセクハラが急増するそうですが、真面目な技術者が男性に口説かれ続けて、鬱になりかけたという話も聞いたことがあります。
開発
気軽に行きましょう。どんなに準備しても受け入れられないことはあります。だめならすばやい改善、退く勇気もときには必要です。関連の道具も記事もそこかしこに落ちていますので、とにかく簡単そうなやつを選び、やってみることです。本来企画段階でツールなどの調査や検証をはさみますが、残念なほどにどのツールもよくできていますので、だめなら乗り換えよう。な軽さで。
リリース
前のテスト導入
Closed Beta Test、Open Beta Testなんてカッコ良く言ってみたいものです。フレンドリーなユーザーを選んで試してみてもらいましょう。できたら目の前で試してもらい、目線や間の取り方などから、戸惑った箇所を推察しそこを中心にインタビューしてみます。
改善
ユーザーテストで判明した問題によって、どこまで戻らなきゃいけないかが違いますが、致命的でなければ順次直すと心に誓い、割り切ります。
本番リリース
インターネットの恐ろしさを知る段階にきました。口説かれるのも怖いが、誰もこないのはもっと怖い。なので、リリース前の企画段階で、適用先をよーく考えましょう。
リリース後の仕事
改善活動
何よりも大事なのがココなのですが、ツールや環境によって大きく違うので、割愛しちゃいます。ただ、リリース後に考慮漏れが判明しどうしようもないということは普通にあり得るので、開発前に十分に考え準備するべきですが、その反面、開発前の仮定に拘らず、やはり気軽に戻って再定義することが、より重要と言えます。言うは易しですね、簡単なことじゃないですが、腹を決めて取り組み、ひとりでも多くのユーザーが、価値を享受できることを切に願います。