2016年9月27日

会話型UIの未来はハイブリッドインターフェースだ

UIデザイン

The Future of Conversational UI Belongs to Hybrid Interfaces

(2016-3-11)by Tomaž Štolfa

本記事は、原著者の許諾のもとに翻訳・掲載しております。

2016年は何もかもが会話型の年です。世界中でメッセージアプリの会話が飛び交い、アプリストアでの再訪率もエンゲージメント率も信じられないほど高くなっています。全てのコミュニティ、電子マーケット、オンデマンドサービス、デートアプリ、ソーシャルゲーム、eコマースの製品が、現在あるいは近い将来において、再訪、エンゲージメント、使用を急増させるエクスペリエンスの要素としてメッセージングの機能を持つでしょう。

こういう全てのアクティビティにともなって、会話型UIに関して多くの議論が重ねられてきました。また、単純なコマンドと、単純なレスポンス(多くはテキストですが、時には写真と組み合わされることもあります)において、人間とコンピュータのコミュニケーションのパターンでメッセージや音声のやり取りがどのように組み合わされるかを議論しました。私はテキストと写真が好きなことは好きなのですが、リッチでグラフィカルなUIの要素のある会話型インターフェースの組み合わせには、かなり広大で未知の可能性が存在します。

この件に関して面白い皮肉があります。1986年、1996年、2006年も何もかもが会話型の年だったのです。会話型UIが将来どこへ向かうべきかを知るには、この豊かな歴史の中から引き出すべきでしょう。

コマンドライン、別名会話型インターフェースの原型

思うに、我々はすでに会話型インターフェースを目にしたことがあります。コマンドラインは会話型インターフェースの原型です。コマンドをテキストで入力し、エンターキーを押すと、コンピュータは処理を実行し、結果を出力します。入出力が両方ともテキストでした。とても突飛な方へ行って、表を作ったり、色々な文字で描いたアスキーアートが作られたりもしました。テキストを媒介とした非常にクリエイティブな使い方ですが、それでもなお根本的にはテキストです。

Linuxのコマンドライン

考えてみると、コマンドラインは会話のやり取りに非常によく似ています。人間はコンピュータに対して何をするかを命じ、コンピュータは処理を実行し、その結果を返すか、タスクを完遂するために必要な答えを求めて質問を返しました。

コマンドラインのアプローチの欠点は、実際に人間の方が何を入力するかを知っていなければならなかったり、コンピュータにオプションを尋ねなければならないことでした。こういうコマンド全てを記憶するよう多くの人に求めるのは相当難しいことで、そのため、コンピュータをいっそう近寄りがたいものにしました。

こんな初期の頃でさえも、メッセージのアプリケーションがありました。人間は機械との会話だけではなく、人間同士の会話を望んでいたからです。やり取りはテキストに限定されていたのですが。

グラフィカルユーザインターフェース

複写機を本業とするゼロックスPARC の賢い人たちが一連のユーザインターフェースのパラダイムを考え出しました。それによって状況が完全に変わり、全くコマンドを知らないユーザや、コンピュータへの問い合わせに時間をかけたくないユーザが、画面上（のカーソル）で視覚的に表現されたなじみのあるオブジェクトをポイントするだけで済むようになりました。

Xerox Starのユーザインターフェース

これらのオブジェクトは現実世界で人々が慣れ親しんだものに似せてありました。例えばフォルダ、ボタン、ごみ箱です。見慣れたシンボルとは別に、新しいものも導入されました。ウィンドウ、ダイアログボックス、デスクトップなどです。こういったオブジェクトのおかげで、ユーザからコンピュータ・コンピュータからユーザへの対話が、テキストではなく視覚的にできるようになりました。望む動作を直接ポイントしたりクリックしたりすることで対話できるようになったのです。

会話型UIとしてのメッセージング

テキスト入力は、URLを入力したり、文書または電子メールを打ち込んだりするために最もよく使われる手段になりましたが、コンピュータと会話する主要な手段になってはいません。しかし、IRCや高まりを見せるインスタントメッセージのアプリケーションを通し、コンピュータを使う他の人たちと交流するための手段としては、テキスト入力は今も主要なものになっています。

IRC は Slack の原型でした。IRCは明らかに必要最低限の機能しかなく、あまり商品らしくされていませんが、今なお普及している数多くの概念を導入しました。IRCは既に、botや大規模なグループチャットクイズ、投票、そしてopsによってチャネルに有効化されたその他の会話型アプリケーションをサポートしていました。

トリビアIRC bot

インスタントメッセージのアプリケーションは、より本質的に視覚的なものでした。時とともに、会話をよりリッチにするメディア―例えば顔文字、写真、ビデオ、ゲームやクイズのようなミニアプリケーションなど―のサポートを開始しました。ICQやAIM、MSNメッセンジャー、Yahoo!メッセンジャーといった、このようなアプリケーションの第一陣は、1990年代の終わりにもてはやされていました。

MSNメッセンジャーの三目並べ

モバイルコミュニケーションと、スクリーンサイズに制約のあるコンピュータデバイスが登場したことで、デスクトップで使われるリッチなグラフィカルインタフェースを再考することが求められました。初期のモバイルデバイスには、白黒のテキストインタフェースがわずか数行あるだけでした。

ショートメッセージサービス（SMS）は、1994年以降、モバイルデバイス上で利用可能な数少ないアプリケーションのうちの1つでした。SMSはテキストだけで、160文字という制限がありました。SMSは最初から、人から人、コンピュータから人の両方をサポートしていました。SMSはIRCやデスクトップメッセンジャーに欠けていた幾つかの機能を備えていました。それは常時接続であり、いつでも通知が可能というものでした。そして「テキストコマンドで残高照会をする」といった基本的な会話型のサービスが出現しました。テキストベースのゲームや星占いなどのエンターテイメントな内容が一方から、また天気や株式のレポートなどのより重大なアプリケーションがもう一方から、SMSの利用を推し進めていきました。これらのアプリケーションは、主にキャリアまたはそれに近い数社によって提供されていました。IRCやIMベースの会話型のアプリケーションとは異なり、SMSにはビルトインの課金機能があったため、そのプラットフォーム上に実際のビジネスを作ることができました。やがて、 Nexmo や他の多くの企業などのオーバーザトップでサービスを提供する会社により、開発者は容易にグローバルプラットフォームとしてのSMSの利点を用いたアプリケーションを構築できるようになりました。その制約とプラットフォームアクセスのおかげで、モバイルの会話型インターフェースやbot、スマートアシスタントの実験にとって、SMSは良い開始オプションになりました。テキストだけということで、SMSベースのアプリケーションは、コマンドラインのエクスペリエンスとかけはなれたものではありません。

Assist によるSMS botのインターフェース

スマートフォンの台頭で、SMSの真の提供価値を模倣する、ますます多くのオーバーザトップ（OTT）アプリを目にするようになりました。メッセージのアプリケーションはユーザに届く通知がとても多いので、モバイルの使用チャートの最上位にあります。これらのメッセージのアプリケーションが、キャリアの信号網経由ではなくIP上で動作するので、メッセージで送信するコンテンツのタイプに基本的に制限はありません。写真やボイスメッセージ、ビデオ、ステッカー、GIFのようなリッチメディアによって、アプリケーションがメッセージのタイプを広げていくのを私たちは見てきました。WeChatやLINEのようなアジア由来のメッセンジャーは、こういったリッチなメディアメッセージを「ミニアプリケーション」にまで拡大させました。これは、FacebookがMessengerで西洋化した概念です。それぞれのメッセージが、テキストもしくはよりリッチなUIを生成することができる自立型のアプリケーションなのです。

OTTメッセージングアプリによって、サービスを統合するためのAPIの幅が徐々に広がりつつあります。これは、SMSが発展してきた経緯とそっくりで、 Telegram や Slack や kik のbotが何百も存在しています。

???? SlackのKhaledBot ????

それにもかかわらず、これらのbotのほとんどは、アプリ環境のせいでテキストベースであり、メッセージングエクスペリエンスの一部としてリッチなミニアプリにすることがまだできません。リッチなコンテンツが追加されていても、いまだにコマンドラインのようなエクスペリエンスとなっているのです。

SMSはオペレーティングシステムに埋め込まれたアプリケーションだったため、SMS駆動型のプロダクトも全てオペレーティングシステム上に存在していました。こういったSMSとは異なり、多くのプロダクトはアプリ内メッセージング機能を含んでいます。メッセンジャー、ソーシャルコミュニティ、電子マーケット、オンデマンドサービス、デートアプリ、ゲーム、そして企業ツールのどれをとっても、コンテキストとアプリの利用者に合わせた、何らかのメッセージングエクスペリエンスがあるのです。従来、これらのアプリに備わっていたメッセージエクスペリエンスは、OTTメッセージングアプリと比較するとごくわずかなものでした。ビジネスとして唯一重点的に取り組んでいるものではなかったためです。しかし、私たちLayerで構築しているようなサービスが多くのアプリにおいてメッセージング機能を提供しているように、その状況は刻々と変わっています。その変化とは、「従来はメッセージングアプリが占めていたのと同等の機会が各プロダクトにもたらされた」というだけではありません。最も重要なのは、「メッセージングでできることが広がっている」ということです。

それぞれのメッセージはアトミックなアプリになる

以下に示すのは、コマンドラインとGUIのパラダイムの最もよい部分を組み合わせた、融合インターフェースの一例です。会話型寄りの通知や迅速なインプットと、GUI寄りのリッチで直感的なエクスペリエンスを融合することでお互いの良い部分を生かすことができます。そのため、このようなインターフェースは2016年以降、ますます増えていくことでしょう。

各メッセージがアトミックなアプリとなっている

それぞれのメッセージはミニアプリになるポテンシャルがあります。テキストや写真を表示するだけのアプリケーションかもしれませんし、あるいは「メッセージ・セルという制約ある環境において、何か更に複雑なもののためのインターフェースを提供する」というアプリケーションかもしれません。フォト･カルーセル、メディアプレーヤー、ミニゲーム、インベントリ項目、そしてメッセージ内購入など、ひとくちサイズのアプリを作成する機会は無限にあります。

リッチメッセージングの例 – 音楽、写真、モバイルストア、ミニゲーム、クイズ、デリバリ、ホテルの予約

開発者がインフラ構築ではなくエクスペリエンスに集中できるようになると、メッセージエクスペリエンスの一部であるミニアプリの活用が標準になるでしょう。このようなトレンドは、会話型コマースで見られ、 Operator のような企業がリードしています。従来のメッセージングアプリで行っている水平的なメッセージングエクスペリエンスとは一線を画し、単にテキストによる返信を行うだけではなく、クライアントが直接やりとりできるリッチなエクスペリエンスをデザインしています。

Operatorが提供している、アクション可能なメッセージカード

bot（NLPやAI、そしてその他全ての便利なもの）

今まで挙げてきた例の中には、必ずしも人間が作成したり送ったりする必要のないメッセージも含まれていたことに、皆さんはお気づきかもしれません。実際、メッセージがミニアプリになればなるほど、botによる会話が成り立ってくるものです。各メッセージがミニアプリを持つことは、会話型コマースやワークフローを動かすアプリにとって、特に便利です。外向けのメッセージは入力要求であり、外から入ってくるメッセージは、応答だけでなく要求を実現するフルアプリを含みます。例えば、会話型アプリに”オニツカタイガーの情報を教えて”と入力すると、テキストによるアイテムリスト、そして恐らく写真が、応答結果として返されるでしょう。または、結果をスクロールするためのカルーセルがついたリッチなカードで、即座に支払いフローにつながるように購入ボタンがついた結果が返されるかもしれません。リッチなメディアカードは、人間が作ると非常に時間がかかるものですが、何を聞かれているのかというコンテキストを理解したbotにとっては、いとも簡単にできるものです。会話型UIとリッチでグラフィカルなUIを融合することなしに、botエクスペリエンスはそのポテンシャルを満たすことはありません。

音声による入力

AppleのSiriやAmazonのAlexa/Echoによって実現されているとおり、コンピュータの会話型インターフェースにとって、音声は非常にパワフルな入出力手段になり得ます。リッチでグラフィカルなフィードバックループと組み合わせると、更にパワフルになるでしょう。音声による入力機能と視覚的な出力機能を持ったスマートウォッチは、その分野において早い時期に拡大しました。将来は、もっとそのようなデバイスを目にすることになるだろうと、私は確信しているのです。

著者について

Layer の共同設立者。Layerは、 Trunk Club 、 GoButler 、 Hinge など、500以上のアプリにメッセージングサービスを提供している会社です。私は以前からコミュニケーションプロダクトのデザインと構築を行ってきて、2006年にLayerを立ち上げました。興味を持たれた方は、私の Twitter をフォローしてください。

この記事を書くにあたって、グラフィックの面で手伝ってくれた Erc 、記事の初期の草稿をレビューしてくれた Chad 、 Christian 、 Jonathan 、 Shane 、 Rok 、 Alexander 、そして Dom に特別に感謝します。