会話式チャットボットの設計課題

ユーザーはチャットボットが大好きです。それは、チャットボットが、スレッド・テキストを使用して会話できるほど、シンプルで一切の無駄がないからです。ユーザーはお気に入りのメッセージング・アプリから離れずに済むことも好みます。複数のアプリや Web の URL、そしてメニューやボタン、広告、飾りだけの機能などといった要素をナビゲートすることなく、すぐに要点に入りたいためです。けれどもこのシンプルさは、大きな設計課題を突き付けます。チャットボットでこのシンプルさを実現するには、ユーザーの発言の意図を正確に理解して、それに応じて動作しなければなりません。けれどもそれは、現在最高レベルの自然言語人工知能 (AI) にとってさえ難しい注文です。

現状の AI でのスレッド・テキストによる会話や会話型 UI (CUI) は、ほとんどの場合、巧みに設計されたグラフィカル UI (GUI) より劣っています。GUI と比べると、CUI はまだ初期段階にあると言えるでしょう。コミュニティーは未だに CUI のデザイン・パターンとベスト・プラクティスを模索している最中です。そこで、このチュートリアルではチャットボットがなぜ失敗するのか、そして成功させるためには何が必要なのかを説明します。

: Robert Kosara 博士が最近公開した「 The Personified User Interface Trap 」というブログ投稿の中で、1997 年に Shneiderman 氏と Maes 氏の「インターフェース・エージェント」スタイルの UI と比較した「直接操作」スタイルの UI に関する議論を取り上げています。博士は 20 年前に学んだ教訓が現在にも当てはまると結論し、「エージェント」がユーザーのニーズを完全に予測できる (完璧な AI である) のでなければ、GUI ウィンドウを提示するほうが、ユーザーが情報を見つけやすく、対話操作に「構文」も必要にならないため賢明だとしています。そうは言っても、お気に入りのメッセージング・アプリケーションに組み込まれた必要最小限の UI に対するユーザーの強い嗜好を無視することはできません。

チャットボットはなぜ失敗するのか

2016年 4月に Facebook がチャットボットのプラットフォームを公開した後、呼び物とされていた「ローンチ・パートナー」を多くの人々が試して、 物足りないという 結論に達しました。これらのチャットボットは、その固有のアプリケーション・ドメイン (天気の確認や花の配達など) 内での 基本的な質問さえ理解することができなかった のです。特に、チャットボットが期待するロボット的な質問から逸脱した「自然な」会話をユーザーが試みると、 チャットボットは内部破綻していまいます

Facebook Messenger のプロダクト・マネージャーを務める Mikhail Larionnov 氏は、Facebook プラットフォーム上の多くのチャットボットをレビューして、ユーザーを引き付ける力がチャットボットに欠けている理由として、以下の 3 つを特定しました。

  • オンボーティングする際にチャットボットの役目をほとんど説明していないこと。
  • 1 つのチャットボット内であまりにも多くの目的を達成しようとして、その価値が明確にされていないこと。
  • 自然言語処理に頼り切っていること。

どのようにしてチャットボットを成功させるのか

Larionnov 氏は、上述の問題を解決するための具体的なアドバイスも提供しています。

第 1 に、チャットボットの適用範囲を絞り込むことです。範囲を限った話題において価値をもたらし、その狭い範囲の中で力を発揮する必要があります。さらに重要なこととして、チャットボットの役割を 1 つや 2 つの文によって簡潔に説明できなければなりません。

第 2 に、ユーザーのオンボーティング・プロセス中に、各メッセージング・プラットフォームの組み込み機能を利用して、チャットボットの特徴を伝えることです。Facebook Messenger の場合、精巧に作成されたグリーティング・ウィンドウという形でアクションを呼び掛けています。Slack の場合は、ボット・ストア内でその特徴を説明しています。

第 3 に、できる限り構造化されたボタンを使用することです。フリー・フォームのユーザー入力を受け入れなければならないとしたら、AI が入力を理解できない場合に対処するために、構文の正しい使い方に関するヘルプ・メッセージを表示する必要があります。チャットボットの場合、構文はアクションをトリガーするコマンドとキーワードです。

私は 4 つ目のアドバイスとして、スパムを送信しないようにすることを提言します。そのためには、停止、サブスクライブ解除、キャンセルなどのコマンドをチャットボットが理解する必要があります。しかも、これらのコマンドに応答して、メッセージの送信を直ちに停止することが重要です。ボットがユーザーに不要なメッセージを送信しすぎると、ユーザーにはチャットボットをブロックするという選択肢しか残されません。Facebook は、ユーザーの 4% がブロックしたチャットボットをオフラインにすることで知られています。

コマンドとコントロール CUI の設計

CUI は人々に、懐かしい DOS や UNIX のコンピューター・コマンド・ラインを思い起こさせることがよくあります。実際、人気が出始めた頃のチャットボットは、開発者が技術的な専門性の高いタスクを行うために広く使われていました。例えば、GitHub の HUBOT は、内部で多数の処理を管理するためのコマンドを使用していました。そのような事例での「会話」は、通常、開発者がチャット・ウィンドウに直接コマンドを入力し、ボットがそれらのコマンドを実行するという形で行われます。ということは、事前定義されたコマンドに応答するようにチャットボットを作成し、それらのコマンドをユーザーに記憶させるという方法は許されるのでしょうか?多くの場合、その答えは「イエス」です。

いくつかの事例を見ていきましょう。

  • 作業と生産性を目的としたチャットボットは、コマンドをより広く使用できるようにしてかまいません。このようなチャットボットのユーザーは、一般にコンピューターに精通した専門家であり、コマンドを使用して作業するのに慣れています。実際、繰り返しのタスクには速度が物足りない GUI を使わなくても済むように、コマンド・ラインのプロンプトとキーボート・ショートカットをマスターしているパワー・ユーザーは少なくありません。このシナリオでは、おしゃべりなボットよりも、極めて効率的な「コマンド・ライン」ボットのほうが好まれるでしょう。
  • コンピューターと一緒に成長してきた若い世代のユーザーは、全生涯を通してテキスト・メッセージングを使っています。そのようなユーザーは、速度に劣る GUI よりもコマンドの効率性に価値を置きがちです。

コマンドとコントロール CUI を設計する場合は、以下の具体的な考慮事項があります。

  • ユーザーがコマンドを正しいスペルで入力できるように、自動補完機能や別の形の支援機能を提供すること。とりわけ、iOS 端末と Android 端末の自動補完機能には注意してください。従来とは異なるスペルのコマンドを採用している場合に、これらの端末の自動補完機能によって、ユーザー入力が改変されることがあるためです。組み込みコマンド・ヘルプの好例は、Slack の Slash コマンドです。Slash アプリケーション UI は、ユーザーの入力と合わせて正しいスペル候補とコマンドの説明を表示します。
  • よくあるスペルミスや同義語に対処できるようにチャットボットをプログラミングしてください。例えば、「help (ヘルプ)」は「How do I do this? (これをするにはどうすればよいか?)」という意味にも解釈できます。このシナリオでは、同義語のリスト (おそらく、その大半は正規表現) を作成し、実行時にそれらの同義語のすべてをユーザー入力と突き合わせることが必要になります。

スロットを埋めるための短い会話の設計

コマンド・ラインとは対照的なチャットボットは、ユーザーと自然な会話をすることができるチャットボットです。けれども、自然言語 AI の現状を考えると、話題を制限せずにユーザーと会話することはおよそ不可能です。また、その必要もありません。会話を高度にスクリプト化するだけで、有用なチャットボットに変身させられることはよくあります。例えば、チャットボットに天気について質問するとしたら、以下のような問い方をするでしょう。

What's the weather in Austin, Texas, tomorrow? (テキサス州オースティンの明日の天気はどうですか?)

この文には、以下の要素があります。

  • 目的: 天気予報
  • 場所: テキサス州オースティン
  • 時間: 明日

これらの要素が揃っていれば、チャットボットは天気を照会することができます。ただし、場合によってはユーザーがすべての情報を一度に提供しないこともあります。ユーザーが最初に目的しか伝えなかったとしたら、チャットボットが他の必要なパラメーター (「スロット」と呼ばれます) を埋めるためにユーザーに質問できるようにする必要があります。その場合、以下のような会話になります。

Human: What is the weather?

Bot: I will look up weather for you. Do you want to check your local weather or somewhere else?

Human: Somewhere else

Bot: Okay, where is it?

Human: Austin Texas

Bot: Thanks. Do you want to know the weather right now or do you want a forecast?

Human: Forecast

Bot: Okay, when?

Human: Tomorrow

Bot: The weather tomorrow at Austin, Texas, is sunny with a high of 80 degrees and low of 75 degrees.

このような趣旨で高度にスクリプト化された会話は、さまざまなシナリオで使用することができます。一般に、ユーザーがボットに何らかのタスクを指示する際は、短い会話によって必要なすべてのスロットを埋めるスロット・フィリングに対応したボットでなければなりません。

このような会話を行うために利用できるツールはあります。例えば、IBM Watson Conversation サービスでは、会話のスクリプト内でスロット・フィリングをサポートすることができます。

インタラクティブな会話を目的とした設計

真の会話型 AI ではないために生じる不足を埋めるには、コマンドおよびスロット・フィリングのための会話が効果的な方法になります。けれどもそれとは別に、メッセージの後に具体的な応答を必要とするボタンを表示するといった、より直接的な方法はどうでしょうか?この方法は、ユーザーにどのような応答が予期されているかを明確に伝えることになります。一例として、以下に Facebook Messenger のチャット・セッション内で使われているボタンを示します。

次に行う動作を選択するボタンを備えたチャット・セッション画面のスクリーンショット

上記のようなボタンを使わないとしたら、通常はチャットボットで番号を振った選択項目やキーワードの選択項目を表示します (例えば、「詳細を読むには 1 を、すべてのストーリーを表示するには 2 を選択」などと表示します)。このような対話はロボットのような印象を与えがちですが、印象はともかく、ユーザーに番号付きリストから項目を選択するように促すとしたら、チャットボットがユーザー入力 (1、いち、最初、最初の項目、あるいはその他の同義語) を処理できなければなりません。

表示されたボタンや番号付きリストをユーザーが使わない可能性があることにも注意してください。つまり、ユーザーがボタンを押さないで、別の内容を入力することも考えられます。その一般的な例は、ユーザーが一連のボタンを見て、どのように応答すべきかわからずに、ヘルプやメニューを入力するという場合です。このシナリオに備えるために、チャットボットはフリー・フォームの応答を解析して、ユーザーがこちらの要求に応じて選択を行ったのか、まったく新しいタスクを開始しようとしているのかを判断する必要があります。

当然、ボタンだけでなく、他の対話式要素を使用することもできます。例えば、Facebook Messenger では、水平にスクロールできるカルーセルをサポートしています。長々としたリストを使用してウィンドウ全体を占めることなく項目のリストを提示するには、カルーセルが最適な手段になります。

さまざまな手法を示す画面のスクリーンショットを並べた図

マルチモーダル・ユーザー入力の利用

最近のメッセージング・アプリケーションに備わっている素晴らしい機能は、画像、音声、動画、絵文字、位置情報など、さまざまな入力を送信できることです。その好例として、Facebook Messenger にはリッチなチャット機能が備わっています。

Facebook のメッセージ下部に表示されるメッセージ入力フィールドのスクリーンショット

もちろん、音声を使ったコミュニケーションを好むユーザーもいれば、写真を送るのを好むユーザーもいます。また、「どこにいるのか」という質問に対する最良の答えは、位置情報を送ることです。Facebook Messenger は、このようなユーザーが生成するすべてのアセットを、皆さんが作成するチャットボットに提供します。ただし、それぞれのチャットボットが持つ意味 (例えば、音声テキスト変換、画像認識、OCR、位置情報 (緯度と経度) と住所のマッピング、およびその他の入力) を明らかにするのは、チャットボットの責務です。

: さまざまなメッセージング・アプリケーションが、それぞれに異なるタイプのユーザー生成のマルチメディア入力をサポートしています。また、そのデータをどのようにしてチャットボットに送信するのかもアプリケーションによって異なります。したがって、あらゆるメッセージング・アプリケーションにまたがって一貫して機能する汎用のクロスプラットフォーム・チャットボットを作成するのは非常に困難です。

粗野なユーザーと、UI デザイナーとしてのライター

チャットボットをプログラミングする際は、ユーザーが使う可能性のある、あらゆる類の言葉や表現を予期してください。時には、チャットボットの限界を試すためだけに、ユーザーがわざとチャットボットに対して粗野にふるまうこともあります。粗野なコメントに対処するために、いくつもの機転の利いた応答を準備しておいてください。

一般に、あらゆる応答では、最初にユーザーの目的を突き止めた後は、その同じ目的に対する応答をさまざまに変えるようにする必要があります。チャットボットが何度も繰り返し、まったく同じ応答を返すことほど、ロボット的な印象を与える状況はありません。それぞれのシナリオで準備された応答のリストからランダムに応答を選択するには、API.ai や IBM Watson Assistant サービスなどの会話管理ツールを利用できます。

チャットボットに機転の利いた応答と個性を発揮させるニーズから、「UI デザイナーとしてのライター」という傾向が生まれています。 報告によると、シリコンバレーの複数の企業が、初期段階のチャットボットを改善するために、英文学を専攻した人材や詩人を採用しているということです

事例研究: WeChat から学んだ教訓

WeChat は、毎月 7 億人を超えるユーザーが利用している中国最大のメッセージング・プラットフォームです。2013 年、WeChat は「パブリック・アカウント」と呼ばれる先駆的ボット・プログラムを開発して大きな成功を収めました。チャットボットとの対話という意味で、WeChat 上で効果を発揮したもの (または効果がなかったもの) は何だったのでしょうか?

WeChat では現在、サブスクリプション・アカウントとサービス・アカウントという 2 つのタイプのパブリック・アカウントをサポートしています。この 2 つは両方ともチャットボットとして誕生しましたが、進化を経ていくうちに徐々に「人工知能チャット」の部分は重視されなくなり、いずれのタイプのパブリック・アカウントでも CUI がサポートされるようになっています。

サブスクリプション・アカウントは、コンテンツ・パブリッシャーが新しいコンテンツに関するメッセージをサブスクライバーに送るために使用されます。一般に、パブリッシャーは 1 日 1 回、その日の新着コンテンツに関する記事のリストをすべてのサブスライバーに送信します。

ユーザーは特定の記事を取得するためにテキストを返信したり、以下のような特定のアクションを実行したりすることもできます。

  • 例えば、「この記事内で取り上げている PowerPoint のスライドをダウンロードするには 42 と入力してください」と記事内に書かれていたりします。
  • ユーザーは例えば「toc」と入力して、最近公開された記事のリストを取得できます。
  • ユーザーが例えば「contact」と入力すると、アカウント・マネージャーに連絡するための Web リンクを取得できます。

これらはすべて、非常に単純なコマンドやトリガー・キーワードであることに注目してください。それは、ユーザーが迅速に Web ページにアクセスしたりダウンロードしたりできるように設計されているためです。ユーザーと長々とした自然言語による会話をしようとするサブスクリプション・アカウントは、まったくないとまでは言わないまでも、極めて数が限られています。

サービス・アカウントは、カスタマー・サービス組織が WeChat 上で顧客と対話するために使用されます。例えば航空会社やホテル、e-コマース・ショップなどがこのタイプのパブリック・アカウントを使用しています。WeChat は早い段階で、AI による自動チャットボットは、人間によるカスタマー・サポートには匹敵しないことを認識しました。そのため、Facebook ページと同じように、各サービス・アカウントでは、人間のユーザー・アカウントを 1 つ以上指定して、「サポート担当者」として利用できるようになっています。

以下のスクリーン・キャプチャーには、航空会社とクレジット・カード会社のカスタマー・サービスでの実際のチャット・セッションが示されています。テキストは中国語ですが、チャットの流れは想像できるはずです。この場合も、単純なトリガー・ワードとコマンドを使用してチャットが進められています。

画面のスクリーンショットを並べて、カスタマー・サービスのチャットの流れを示す図

カスタマー・サービス・アカウントによっては、アカウントの所有者がユーザーとあえて長く会話しようとすることがあります。その場合、会話が自動化されるのは最初のうちだけで、ボットがユーザーの目的を突き止めるとすぐに、チャットは関連する Web ページ (例えば、飛行機のチケットの予約を変更するためのページ) やアカウントに関連付けられた人間のエージェントに渡されます。

WeChat の高度に進化したボット・システムから学べる要点は、以下のとおりです。

  • ボット・アプリケーションによって、必要となる会話型 UI のスタイルは異なります。ほとんどのボットには、適切な Web ビューにユーザーを導くための単純なコマンドやトリガー・ワードで十分です。
  • 特定の製品のカスタマー・サポートなど、高度にスクリプト化された使用事例では、ボットとの会話を長くするほうが適切ですが、その後は必要に応じてユーザーを Web アプリケーションや人間のエージェントに転送することが賢明です。
  • メッセージング・ボットの価値は、プラットフォームと統合して、ボットがシームレスにユーザーの ID、支払い情報、その他の情報にシームレスにアクセスできるようにすることによって生まれます。

まとめ

このチュートリアルでは、チャットボットによる会話を設計する際に直面する主な問題について説明し、チャットボットを成功させるための方法を列挙しました。そして成功に必要となる要点を明らかにするために、WeChat メッセージング・プラットフォームについて見て行きました。私が推奨する対話のタイプは、コマンドとコントロール、スロット・フィリング、インタラクティブな会話の 3 つです。また、このチュートリアルではマルチモーダル・ユーザー入力についてと、創造的に応答するにはどのようにするのかについても簡単に触れました。