【編集部注】著者のTom Hadfieldは、Khosla Ventures、Eniac Ventures、そしてY Combinatorの支援を受けているボットクロス配信サービスMessage.ioのCEOである。
2016年、ボットはしばしば大きな話題になった。それらは商業の未来や顧客サービスの革命として様々な賞賛を受けてきた。Webや携帯電話がかつてそうしたように、メッセージング・インターフェースは、私たちが周りの世界と対話する方法を変えて行くのかもしれない。
しかし、そうなるためには、ボットのコミュニティは、Webおよび携帯電話業界の黎明期を悩ませた、インターオペラビリティ（相互運用性）とクロスプラットフォーム標準という、共通の課題に真正面から取り組まなければならない。
私たちは任意のウェブサイトをどんなブラウザでも見ることができることを当然だと思っているし、電話会社に関係なく友人にSMSメッセージを送ることができる。でもそれはかつては当たり前のことではなかったし、それほど昔の話でもない。20年前、Netscapeユーザーが「Internet Explorer用に最適化」のアイコンによってブロックされることは日常茶飯事だった。
同様に、Verizonの顧客とAT＆Tの顧客はそれぞれのキャリアの中の友人だけにメッセージを送ることができて、キャリアをまたいでメッセージを送ることができなかった時代もあった。テレビ番組American Idolでさえ、メッセージによる視聴者投票のために2つの番号を表示する必要があったのだ、1つはVerizon向け、そしてもう1つはAT&T向け。
20年が過ぎて、こうした「壁に囲まれた庭園」（当初CompuServeやAOLなどを指して表現するために使われたフレーズ）は、歴史書の中に書かれたものだと思いたくなる。
だが、そうではない。
2016年の今日、あなたがドミノピザとコミュニケーションできるのは、Facebookメッセンジャーを使うときだけだ。H&MとチャットするためにはKikを使わなければならない。Troopsを使えるのはSlackだけで、HipChatではだめ。壁に囲まれた庭園が舞い戻ったのだ。
「Facebookボット」または「Slackアプリ」といった概念は、ウェブサイトが「Internet Explorer用に最適化」または「Netscape用に最適化」されているといった以上の意味はない。
なぜこれが問題なのだろう？HipChat、Flowdock、あるいはMicrosoft Teamsなどのエンタープライズメッセージングプラットフォームの数千万人のユーザーたちは、Slackの豊富なサードパーティエコシステム統合を活用することができないのだ。同様に、大勢の企業ボットの開発者たちが、Cisco SparkあるいはSalesforce Chatter上の新しい顧客を獲得したいならば、ボットを再構築する必要がある。消費者の世界でも事情は同じだ。
ここで「1度のビルドで、どこにでもデプロイ」を願う開発者たちには、楽観的になって良い理由がある。壁に囲まれた庭園の中で、互いを繋ぐ門がAPIの形で現れ始めているからだ。 SlackとMicrosoftが支援するBotnessのような業界団体が、共通規格を議論するワーキンググループを始めている。その結果、プラットフォーム間のAPIとUIの差異が収束し始めている。SameroomやSlacklineといった企業は、これらのAPIを接続してより統一的なメッセージングシステムを構築し始めている。
希望の持てる話をしよう：人類の歴史を振り返ってみると、生き残った通信技術（郵便、電話、電子メール、ウェブなど）は皆相互運用性を指向していた。ボット/メッセージングがまったく異なると考える理由はない。
[ 原文へ ]
（翻訳：Sako）
