Peter Yared氏はSaphoの設立者でCTOである。以前はCBS InteractiveでCTO／CIOを務めていた。

テック業界でボットがあっという間に大人気になっている。ボットは、メッセージングアプリ上でUberのようなサービスにシンプルなテキストで依頼を出せる機能を提供している。ユーザインターフェースは友人にテキストメッセージを送るのとそっくりで、重いネイティブアプリをダウンロードして使うよりもずっと簡単にメッセージを入力できる。

多くのボットやSlackのようなボットプラットフォームが現れると、テキスト検索でクエリの結果を返す方法を完成させるまでGoogleがほぼ20年を費やしたという話が余計に興味深く感じられる。現在のボットは、自然言語の解釈、人工知能、そしてユーザインターフェースについてGoogleの教訓から学べることが多くある。

ボットの典型的な例としては、Slack上でUberを依頼する、というものがある。モバイル上のSlackではユーザの居場所がわかっているため、これはどちらかといえば簡単な使い方である。しかし、最新のボットはすぐ行ったり来たりを永遠に繰り返し始めてしまう。例えば、飛行機のフライトをテキスト経由で探そうとすると、航空会社の自動音声サービスを使う場合と同じくらい長々と面倒な時間を強いられることになる。

ボットでのメッセージのやり取りはつまらない

きっといつの日にか、ユーザーがサンフランシスコからニューヨークへのフライトについて尋ねるとそれを完璧に理解できるまでにボットは賢くなるだろう。しかし、ビジネスなのか観光なのかといったことや、今回はミーティングがあるから前回とは違う空港に行かないとか、マイレージを使いたいから特別な航空会社を使いたいといったようなことをわかってもらうにはまだまだ長い時間がかかる。

Googleがいかにより少ないテキストでのやり取りを可能にしたか

Googleはもう長い間、検索したテキストに対して最も関連のある回答を返すことにかけては名人の座についている。7年前、Googleの検索システムはクエリの意図を解釈したり、クエリに対する検索結果の上に回答を書いたカードを返してきたりし始めた。その後、Googleのこのカードは高度なインタラクティブアプリに進化し、天気から音楽、歌詞、それに飛行機のフライトまで、何でもカバーするようになった。

Googleは英語の簡略表記、例えば「SFからLAへのフライト」などを理解するし、インタラクティブカードを検索結果で返してくる。インタラクティブカードはボットによるメッセージのやり取りよりもずっと効率的なユーザインターフェースだ。私たちはテキストメッセージを送りたがるが、より長文のテキストメッセージが返信されることはできるかぎり避けたいと思っているのだから。

Googleのインタラクティブカードアプリ

カードの中の「フライトを表示」のボタンか「フライト」タブをクリックすると、ユーザが航空券を購入できるよう導いてくれる完全に双方向型のマイクロアプリがフルスクリーンで表示される。ボットだったら、このフルスクリーンのマイクロアプリを使った方法を、より複雑な対話方式に変えてしまいそうだ。

テキストのみで双方向型のやり取りをしてもどうしようもない、という点をはっきりさせるために、Googleは数年前、インタラクティブカードとマイクロアプリをスマートフォンに対応させた後に、自身のSMS検索プロダクトを一つ終了させている。

メッセージにふさわしい方法を選択すること

人々は書類を書くためにには、電話ではなくコンピュータを使う。それと同じように、自然言語ボットは異なるコンテキストにおける異なるタスクに向いている。音声のみのインターフェースを使用する場合、対話は一般的に単純な質問と回答に限られる。だがスマートフォンに入力する場合は、より複雑なクエリによって精巧なインタラクティブカードやマイクロアプリを回答として得られる。

各対話オプションをここに簡単に例示しておこう。

新興ボットプラットフォームはマイクロアプリプラットフォームになるべきか

ボットをサポートしているSlackやFacebook Messengerなどのメッセージングプラットフォームにとって、これはなにを意味しているのだろう？ Googleの辿った道を見てみると、これらはすぐにAPIを拡張してカードアプリやマイクロアプリがそのプラットフォーム上で活躍できるようにする必要がありそうだ。

カードアプリやマイクロアプリへの対応は、GoogleのカードAPIのような新世代のライトウェイトHTML APIが必要となる。皮肉なことに、FacebookはFBML（Facebook Markup Language）プラットフォームを終了させてしまっているが、React.jsがその後を継ぐ可能性がある。ユーザは過剰な機能を積んだ膨大なネイティブアプリにうんざりしているから、これは実時間でダイナミックにロードできる軽いなHTML関連アプリにとっていい機会である。

Googleはまた、単純なクエリならクエリ入力が終わる前に回答を出してくれる。これはメッセージングプラットフォームがもうすぐ取り入れそうなもう一つの機能だ。

Google検索は今、一部のクエリに対してクエリ入力中に回答を表示する

そして一部のクエリに対しては、ボットは質問全てが送信される前に回答を出している。これはGoogleが、Chromeでの天気や株価の情報などのクエリに対して行っていることだ。

もし、ユーザに対して特別な何かが起こった場合は、ボットはもっと長い間メッセージを送ってくるだろう。今現在のボットは非常に冗長で、SalesforceやGithubのようなソースシステムで起こる全てのことを吐き出してくる。

ここでもまた、Googleから学ぶことができる。Google Nowなら、プッシュ通知やインタラクティブカードアプリなどをコンテキストやユーザの興味に合わせて先に送ってくれるのだ。

Googleは同じようなエクスペリエンスをメッセンジャーのGoogleハングアウトにも統合しようとする可能性がある。また、O’ReillyのAlistair Croll氏が言及したように、インテリジェントカードアプリとマイクロアプリをメール製品のInboxに統合しようとしている。

デベロッパープラットフォーム戦争が起きつつある

iOS／Androidアプリからもうすぐ10年が経つ。アプリらしい機能性をどうやって実装するか、クエリとユーザーコンテキストに基いたアプリのスリム化をどうするか、といったところに立ち返る素晴らしい機会だ。企業向けアプリにおいては、ユーザーはすべてのエンタープライズツールでクエリが利用でき、主導的でインタラクティブなカードとマイクロアプリが使えるようになることを期待するだろう。

法人ユーザーにとってのボットの価値はようやく明らかになり始めたばかりだ。法人向けボットは、会話の文脈に知能を加え、従業員に関連情報を送り、ワークフローを最適化するために使われるようになる可能性が高い。

Googleはテキストクエリに回答するという点で他を引き離している。しかし、MicrosoftはすでにSkype用のボットAPIについて発表しているし、Slackのような新顔もいる。全体を見れば、これはきっと面白い展開になるだろう。ここ10年ほどの間、デベロッパープラットフォーム戦争なんてなかったのだから。

【via VentureBeat】 @VentureBeat
【原文】