アプリケーションにチャット(会話)機能をつけるAPI、Dialogflow Enterprise EditionをGoogle Cloudが一般公開

会話ができるための入出力インタフェイスを作ることは、デベロッパーにとって新しい挑戦分野だ。チャットボットはWebサイトやアプリにおけるトラブルを減らし、会話ができるという構造の中では、企業はよく聞かれる質問に簡単迅速に答えることができる。そこで今日(米国時間4/17)Googleは、これまでベータだったDialogflow Enterprise Editionを一般公開した。

この技術は、2016年におけるAPI.AIの買収の成果だ。Googleは賢明にもツールの名前を変え、それが実際にすることにマッチした名前にした。同社によると、現在すでに、数十万のデベロッパーがこのツールを使って会話のためのインタフェイスを構築している。

これは必ずしもGoogleオンリーのツールではなく、Google AssistantやAmazon Alexa、Facebook Messengerなどの音声インタフェイスでも使えるから、デベロッパーが一度チャットアプリを作ったら、それらを、コードを大幅に変えなくてもさまざまなデバイスで使えるようになる。

さらに今日のリリースでは、機能を増やすとともに、エンタープライズエディションへの移行を容易にした。

GoogleのCloud AIのプロダクトマネージャーDan Aharonが、このツールを発表するブログ記事で、こう述べている: “今日からは、一つのAPI呼び出しで複数のAPI呼び出しが必要になるような、バッチ的な処理ができるようになり、コードの行数を減らして開発時間を短縮できる。Dialogflow API V2は今や、すべての新しいエージェントのデフォルトであり、Google Cloud Speech-to-Textを統合、APIからのエージェントの管理が可能になり、gRPCをサポート、そしてコードのマイグレーション不要でEnterprise Editionに容易に移行できる”。

同社は、Dialogflowを使って顧客のためのチャットインタフェイスを構築した企業の例として、KLM Royal Dutch AirlinesやDomino’s、Ticketmasterなどを挙げた。

この新しいツールは今日(米国時間4/17)から可利用になり、30以上の言語をサポートする。一般公開されたエンタープライズプロダクトには、サポートパッケージとサービスレベルアグリーメント(SLA)がつく。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

Googleのテキスト音声変換APIにメジャー・アップデート――音声認識も改善

今日(米国時間4/9)、Googleは数週間前に公開したクラウド・テキスト音声変換サービスのAPIにメジャーアップデートを行ったことをを発表した。Googleは同時に逆方向のサービスである音声テキスト変換のクラウド音声認識APIにも大きな改善を行った。Googleのテストによれば、新しいAPIは認識エラーを全体で54%減らしたという。ただし一部のケースでは改善はこれをはるかに上回った。

アップデートされた音声テキスト変換APIを利用するとデベロッパーは 複数のユースケースをベースにした機械学習モデルから適したものを選ぶことができる。新APIは現在4つのモデルを提供している。そのひとつは検索と命令のための短い発話だ。また電話の音声認識、ビデオファイルの音声認識も提供されており、Googleがすべてのデベロッパーにデフォールトとして推薦するのが4番めの新しいモデルだ。

こうした新しい音声テキスト変換モデルに加え、Googleはパンクチュエーション(句読法)のモデルをアップデートした。Googleの開発チーム自身も認めているとおり、音声認識でこれまで最大の問題となってきたのは正しいパンクチュエーションの生成だった。ことに話者が通常と異なる発話の癖を持っている場合、パンクチュエーションを含めたテキスト起こしはきわめて困難になる

これはトランプ大統領の発言をパンクチュエーションを含めてテキスト起こししようと試みたデベロッパーなら同意するだろう。アップデートされたモデルははるかに読みやすいテキストを生成できるという。センテンスの切れ目を認識することに失敗するケースが減少し、ピリオド、コンマ、クエスチョンマークなどを正しく挿入できるとGoogleは述べている。

今回のAPIのアップデートにより、デベロッパーはテキスト起こしを行うことにより、音声ファイルないしビデオファイルにタグ付けなど基本的なメタデータを付与できるようになった。Googleではユーザーの各種機能の利用状況を総合的に勘案して、次のアップデート開発の優先順位を決めていくという。

Googleはサービスの料金体系も多少変更した。従来どおり、音声ファイルのテキスト変換は15秒ごとに0.006ドルで、ビデオはその2倍の15秒ごとに0.012ドルとなる。ただし5月31日まで新モデルの利用料金は15秒ごとに$0.006ドルに抑えられる。

〔日本版〕上にエンベッドされた例ではセンテンスの切れ目が正しく認識されピリオドが挿入されている。No、That’sなどの冒頭が赤文字で強調表示されている。

[原文へ]

(翻訳:滑川海彦@Facebook Google+

トランプ選挙陣営のデータ分析会社、Facebookユーザー5000万人のデータを不正アクセスか

先週Facebookは、トランプ選挙陣営と密接に関係するデータ分析会社のアカウントを停止したことを発表したが、実際にアクセスされたデータの規模をFacebookが大幅に低く見積もっていた可能性があることがNew York Timesの最新記事でわかった。

New York Timesによると、Campbridge Analyticaはケンブリッジ大学の心理学教授、Dr. Aleksandr Koganと協力して “thisisyourdigitallife” というアプリを開発し、最大5000万ユーザーの個人情報を収拾した。Facebookは27万人のユーザーがそのアプリをダウンロードしたことを認めている。このアプリはFacebookのログイン情報を使ってユーザーの地理的情報をアクセス可能にする —— New York Timesによると5000万人のプロフィール情報を取得したという。しか一人のユーザー(友達が数百人)がこのアプリを通じて個人情報へのアクセスを許可することのの影響は、2014年当時の方がいまよりずっと大きかった可能性がある。

サービス開始当初はどの会社もポリシーが厳格ではなくAPIの保護も十分でなかったためにこの種の情報が流出しやすい。Facebook幹部らは、これを不正行為ではないとTwitterに書いており、実際従来の基準では違反と言えないかもしれない。Facebookのセキュリティー最高責任者、Alex Stamosは次のように書いている。

[Koganが不正侵入やソフトウェアの不備を利用したことはない。彼は収拾したデータの使い方を誤ったが、だからといってデータの取得がさかのぼって「違法」になるものではない。]

アップデート: Stamosはツイートを削除した。上に貼ったのはツイートのスクリーンショットだ。

Stamosは一連のツイートを削除する前、長いスレッドで状況の詳細を説明した。それによると、当時のFacebook APIは今よりずっと広範囲のデータを取得することが可能だった。APIは2015年に改訂され友達データの取得が制限され、当時はアプリ開発者の間で議論を呼んだ。20億人のアクティブユーザーがいるFacebookでは、ポリシーは常に改訂が続きいたちごっこ状態にある。トランプの勝利は僅差だったため、的の絞られた5000万人の情報は大きな違いを生んだ可能性がある。

Facebookは公開企業であり、2014年当時の株主に対して、大失敗をせずこの種の情報を責任をもって厳重に管理する信認義務があった。不正アクセスを防ぐガードレールの欠落はUberやLyftなど他社でも数多く見られる。企業が成長モードにあるとき、この種のガードレールの設置は優先順位が下がることが多い。データが膨大になりそれを管理すること自体に膨大な労力が必要になればなおさらだ。Facebookは2014年Q4末に13.9億人のアクティブユーザーを抱えていた。

米国時間3月16日、FacebookはStrategic Communication Laboratoriesおよび傘下の政治データ分析会社であるCambridge Analyticaのアカウントを停止したと声明で発表した。しかしFacebookは今も問題を軽視している。

本誌はFacebookに追加情報を要求しており、情報が入り次第続報する予定だが、現時点ではFacebook幹部らは、流行にあわせてTwitterで弁明している。

[原文へ]

(翻訳:Nob Takahashi / facebook

毎月4000億回のAPIコールを処理するAPIマーケットプレイスのRapidAPIが900万ドルを調達

APIはいま、テクノロジーの世界で、必要不可欠で成長著しい構築部品である。開発者たちは、APIをサードパーティーのサービスを自分たちのアプリに統合したり、自分たちのアプリを他の開発者たちに使って貰いやすくしたりするために利用している。そして今、アプリケーション開発者たちによる、そうしたAPIの発見、利用、課金、そして呼び出し管理を支援する、あるスタートアップが、その動きを加速するために資金調達ラウンドを発表した。

RapidAPIは、現在8000個に及ぶAPIのディレクトリを提供している。18ヶ月前にはその数はわずかに200だった。同社は今回行った900万ドルの資金調達ラウンドを利用して、より多くのAPIと開発者を取り扱えるようにビジネスを拡大する。

ラウンドを主導したのはAndreessen Horowitzだが(同VCは1年半前に行われたRapidAPIの350万ドルのシードラウンドも主導している)、他にはSV Angel、Green Bay Capital、そしてNexmo(Vonage API Platform)の共同創業者兼CEOであるTony Jamousが参加している。

Andreessen Horowitzは、企業向けスタートアップとソフトウェアを2つの主要成長領域として特に注力してきたことで、よく知られている。

RapidAPIはその2つの領域をカバーし、目覚ましい成長の真っ只中である。現在同社は約50万人の開発者たちと協力している。これもまた18ヶ月前にはわずかに3万人だった。そして最近さらに企業利用への拡大が進んでいる。例えばCiscoや(ホテル業界の雄)Hyattなどが、RapidAPPIを利用して外部からのAPIと内部でのAPI利用の両方を管理している。

RapidAPIによれば同社が処理するAPIの数は、毎月4000億回にのぼるという。そのディレクトリには、Microsoft、Stripe、SendGrid、Slack、Foursquare、Eventbrite、Yelp、Google Translate、Spotify、NASA、ProductHuntなどのAPIが含まれている。現在、最も人気のあるカテゴリーは、今ではほぼすべてのアプリが備える、コミュニケーション(メールやSMSのことを思い出して欲しい)に関するものだ。またAIベースのAPIは最も急成長しているカテゴリーで、特に顔認識やテキスト分析などの分野が中心である。

もともとはイスラエルのハイファが発祥の地だったが、現在はサンフランシスコに拠点を移動している(なおイスラエルとキエフ、ウクライナに事務所がある)。RapidAPIはIddo Gino(写真)によって共同創業され、率いられている。この若い開発者(現在20歳)は、彼が学生だったときにこのアイデアを思いついたのだと言う。多くのハッカソンに参加した彼は、何かをすばやくコーディングする必要がある場合に利用できる、より広い範囲のAPIを発見して使用する効率的な方法がないことに気が付いた。

「何もかもをゼロから構築することはできませんし、APIを使うことで仕事が遥かに効率的になります」と彼は言う。「しかしそれぞれのAPIは、異なるフォーマットと認証戦略を持っています。そしてそれらを使いこなすためには、沢山の異なる言語を使いこなさなければなりません」。

そこで、彼と共同創業者のMickey Haslavsky(現在はGM)は、まずこの面倒な点にアプローチするために、最初のバージョンのRapidAPIを開発した。最初のバージョンは基本的に、APIにアクセスするための標準化されたゲートウェイを提供する一連のAPIラッパーだった。

「Githubに載せた数ヵ月後に、5000人もの開発者がそれを利用していたことを知って驚きました」

RapidAPIの急速な成長は、様々なAPI自体の増加を反映している。現在、約2万5000のAPIが存在していて(ほんの10年前には約800程度だった)、開発者は1つのアプリに対して、平均して10から15個のAPIを利用している。APIは急速にアプリ構築に不可欠な要素となった。アプリ自身の中でサービスに素早く簡単にアクセスすることと、アプリを外部かた使ってもらうことの両方に役立つのだ。アプリケーションの運用がAPIを活用することで行われる「APIエコノミー」(API-powered economy)は、これからの10年で2.2兆ドルを生み出すと予測されている。

収益という点に関しては、現段階でRapidAPIはあまり大きなものは得ていない。Ginoによれば、同社はそのプラットフォームを使って行われるAPIコール(コールの価格はビジネス毎に異なっている)から1パーセントを徴収していると言う。ひとつひとつはとても小さなものだが、規模として考えた場合、ビジネスは長期的には非常に大きなものになる可能性がある。現時点ではGinoはその収益に関しては「数百万ドルです」と述べるだけだ。

これに加えて、創業者たちの強みと、彼らがこれまでにアイデアを開発してきたやり方が、この先のビジネスが上手く行くことを十分に示唆している、と語るのは、AndreessenパートナーのMartin Casadoだ。Martinは今回の投資を機にRapidAPIの取締役会に参加した。

「RapidAPIは、世界のAPIの市場で圧倒的な存在になりました」とCasadoはインタビューで語る。「成長は驚異的です。私たちは優れた創業者から始まり、興味深いステージに辿り着きました。そして『さあ次はどうする?』という段階なのです」。

もちろん、APIにも課題はある。

APIはそれを作成した会社の資産であるために、開発会社がAPIを独占したり利用規約を変更することで、多くの開発者が足元をすくわれて来た。アプリを構築する唯一の方法は、弾力性を持たせて、第三者のサービスに根本的に依存しないようにすることだと主張する人もいる。

その他にも、ますます増殖するAPIのジャングルにいかに取り組むかという問題がある。適切なものを見つけるにはどうすれば良いのか、また自分たちのサービスが発見されるようにするには企業はどうすれば良いのか?(実際に、APIの発見と利用する仕組みの多くは、開発者がその上に構築するアプリケーションの仕組みと似通ったものだ)。

RapidAPIはこの点に関して2つの方法で支援できる可能性がある。1つは似たような目的に利用することのできる沢山のAPIの選択肢を持っているので、ユーザーは1つのAPIを失っても代替品を比較的簡単に見つけることができるということだ、そしてもう1つはそのマーケットプレイスが発見の支援を行ってくれるということだ。

Ginoによれば、現時点ではAPIは使用状況に基づいて「順位」が変わるということだ。もっとも人気のあるAPIが最初に見つかるようになっている。しかし将来的に、RapidAPIが発見メカニズムを調整し洗練してくることは容易に想像できる。

「Rapidは、混沌としたAPIの状況に秩序をもたらします」とCasadoは語る。

RapidAPIの競合相手となる沢山のディレクトリサービスも存在している。その中にはZapierIFTTT(これもまたAndreessenに支援されている)も含まれている。とはいえGinoによればそれらはあまり開発者を意識したものではないと言う。また、ProgrammableWebには長年提供されてきたAPIディレクトリがあり、世界最大規模であることを主張している。とはいえこれにはRapidAPIが提供するような単一ゲートウェイを通したアクセスツールはそれほど取り込まれていない。

想像できる限りの沢山の企業たちが、この世界にビジネスを広げるために進出しようとしている。開発者に焦点を当てたMicrosoftのAzureやAmazonのAWSから、Stripeのように、それ自身支払いAPIの上に構築されながら、統合容易なビジネスサービスとして急速に拡大しているものまで色々だ。(ちなみにGinoは、Stripeと創業者のCollison兄弟を、彼の「インスピレーション」だと言っている)。

これらすべてのプレーヤーたちとアプリケーションやAPIの成長を考慮すると、全体として機会は広がっている。そして私たちは、その機会をものにするための最良のやり方がどのようなものであるかを見出すための、ほんの入口にたどり着いたに過ぎないのだ。

[ 原文へ ]
(翻訳:sako)

人材採用のOpen API構想を掲げるHERPにスタートアップの経営者ら8名がパートナーとして参画

HERP」は複数の求人媒体と自動連動する採用管理システムを軸とした、AIリクルーティングプラットフォームだ。2017年12月に発表された同サービスは、既存の求人媒体と情報を連携して応募を自動で登録し、一括管理できる仕組み。採用担当が行う事務作業の多くを自動化し、戦略的な採用活動に注力できるよう支援することを目的に開発されている。

同サービスを開発するHERPは3月12日、スタートアップの経営や採用戦略に携わる8名がパートナーとして加わり、経営に参画すると発表した。HERP PARTNERとして迎えられたのは、以下の8名。このうちエウレカ共同創業者の赤坂氏と西川氏は、HERPに合計数千万円規模の出資を行っている。

  • 赤坂優氏(エウレカ 共同創業者/エンジェル投資家)
  • 石黒卓弥氏(メルカリ 採用担当)
  • 小澤政生氏(サイバーエージェント採用担当)
  • 河合総一郎氏(ReBoost 代表取締役社長)
  • 桑田友紀氏(サイバーエージェント 採用担当)
  • 小泉文明氏(メルカリ 取締役社長兼COO)
  • 高野秀俊氏(キープレイヤーズ 代表)
  • 西川順氏(エウレカ共同創業者/エンジェル投資家)

HERPは2017年3月創業。代表取締役CEOの庄田一郎氏は、リクルートで新卒エンジニア採用などを担当したあと、採用広報担当としてエウレカに入社。エウレカでは「Couples」の事業担当者も務めていた。

庄田氏は「採用、HRの業界構造は60年ぐらい変わっていない。企業は工数をかけてエージェントや媒体に情報を提供し、採用が決まったらお金を払う。これでは情報は、エージェントや媒体に偏る。また求職者にとっても、企業選びはエージェントの持ってくる情報に限定された状況だ」と言う。

この状況を変えたい、と考えられたのが同社の掲げる「Open Recruiting API構想」だ。これは利用企業が持つ求人データ、応募する候補者データを、API経由で採用媒体やエージェントと適切にやり取りする、というもの。「金融業界ではマネーフォワードが『Open Bank API』を提唱してきた。その後、銀行が更新系APIの提供を始めたが、これは時代の流れ。採用業界でも同じことをやりたい」と庄田氏は語る。

「今後、採用にまつわる情報は複雑化していく。働き方改革で副業が広がり、新卒採用、終身雇用といった制度もなくなっていくだろう。また外国人の雇用も増えていくはずだ。そうなると、人事にかかるコストは膨らんでいく。これを見据えて、データのオープン化への対応を準備していく」(庄田氏)

庄田氏は「これまで変化のなかった採用業界で、既存の媒体がこれを推進するのは難しいだろう。だから僕らが進めたい」と話す。「デジタル業界、ウェブ系企業では、データのオープン化にも理解があるところが多い。今回は、スタートアップ、ベンチャー企業のHRの権威や経営者の方に、この思想に共感し、参画してもらった。今後も、Open Recruiting API構想に協力するパートナーは増やしていきたい」(庄田氏)

庄田氏はまた「直近では採用事務を自動化することを目指す。そのためには、まだまだツールが必要」として、その開発を進めていきたい、と話している。「採用担当者は、媒体の管理画面から手入力で候補者の情報をExcelに入力することも多い。それでは正確な候補者データを担保できない。まずは、正確なデータを企業が入手できるようにしたい」(庄田氏)

手入力やコピーペーストの登録による弊害はほかにもある。応募してきた候補者リストが、企業にデータとして集約されないケースだ。「人事担当者が媒体の管理画面上で確認し、その場で不採用メールを送る、ということはよくある。この場合Excelに転記されないので、面接フローに乗った人だけしか、管理できない。粒度のそろったデータにならないので、採用分析にも支障がある」(庄田氏)

また、パフォーマンスや早期離職の分析など、入社後にも採用時のデータは活用できる。「入口でデータを持っていなければ、そういった活用にはつながらない。HERPは媒体と自動連携することで、企業が手間をかけずにデータを入手できる機能を提供する」と庄田氏は説明する。

さらに将来的には、より深い分析も可能になるだろう、と庄田氏は述べている。「応募者側で言えば、レジュメと自分の情報を登録すれば、希望する企業の合格率が分かる、といったことも考えられる。企業側も、例えば1000万円をかけて財務担当を採用したい、となったときに、媒体ごとにいくらかければよいのか、AIを使って費用を最適化することもできるだろう」(庄田氏)

庄田氏は「広告で人材を獲得するときの効果測定は、マーケティングと一緒」と話す。「1人あたりいくらかかったのか、その後の効果はどうなのか。データがなければ分析、確認はできない」(庄田氏)

昨年12月にサービスの発表と同時に公開されたHERPのティザーサイトでは、ベータ版ユーザーの登録を募集している。庄田氏によると、これまでの3カ月で約400社の登録があったそうだ。「プロモーションを行わずにこの数字だったので、手応えはある」と庄田氏は言う。「ウェブサービスなどの企業のほか、大企業からの登録もあった。意外だったのは、弁護士事務所などの士業からの申し込みも結構あったことだ」(庄田氏)

HERPは現在、クローズドベータの形で数社に公開され、試用が始まっているとのこと。登録企業全体に公開されるのは、今春の予定だ。

Twilioがコンタクトセンター構築のためのビルディングブロック集Flexを近く立ち上げ

デベロッパーが新しい顧客体験を作るための一連のプロダクトをまとめたTwilioのスイート、Engagement Cloudに、新しい機能が加わる。本誌情報筋によれば、今度ベータでローンチするそれは、3月のEnterprise Connectカンファレンスに集まる企業のための、完全なコンタクトセンターソリューションだ。Twilioに確認を求めたが、ノーコメントだった。

われわれが垣間見たTwilioの社内メールによれば、同社は、一部の顧客がエンタープライズに売っているコンタクトセンターソリューションとの競合を避けようとしている。しかしそんな顧客も、Twilioのサービスにとって重要なユーザーだから、気を使うのも当然だ。

これまでのTwilioの立ち位置は、新しいコンタクトセンターソリューションを開発するためのビルディングブロックとなる、さまざまなAPIの提供だ。今度の新しいコンタクトセンターソリューションは、それらをワンセットでまとめて、デベロッパーにとってずっと使いやすくしたものになるのだろう。

Twilio Flexと名前まで漏れている今度のTwilio自身のコンタクトセンター用プロダクトは、これまでのそのほかの同社製品と同じくデベロッパー体験を重視するだろう。たとえばシステムインテグレーターはFlexを利用して、独自にカスタマイズしたコンタクトセンターソリューションを作ったりできるだろう。

Twilio Flexは、そういう人たちが、強力な通信体験と、シングルサインオン、会社のワークフォース管理との統合、ワークフォース最適化スイート(通常のコンタクトセンターの便利機能…通話記録、エージェント指導、談話分析など)を構築するときの、基本的なビルディングブロックを提供する。そしてまた、彼らのバックオフィス社員のスケジューリングシステムとの統合も、サポートするだろう。

Flex(柔軟)という名前が示すように、このサービスはユーザーによるカスタマイズの最大化をねらっている。しかしもちろん、ユーザー企業独特の統合化ニーズについては、顧客の創意と努力が必要だ。企業の、コンタクトセンターの最適化ニーズとは、そういう柔軟なカスタマイズにある、とTwilioは主張しているようだ。

本誌情報筋によると、公式の発表は3月12日だ。それはオーランドで行われるEnterprise Connectカンファレンスの初日で、このカンファレンス自体、コンタクトセンターやコーリングセンターがフォーカスとなる。

画像提供: Twilio/Flickr

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

APIとユーザープロダクトとの統合で機械+人力の翻訳サービスを提供するUnbabelが$23Mを調達

リスボンに本社を置くUnbabelは、彼らの言葉によると“AIを使い、人間の手で精製する”翻訳プラットホームで、ここを利用すると低コストでビジネスをグローバルに展開できる、という。その同社が今日(米国時間1/11)、シリーズBで2300万ドルを調達した。

このラウンドをリードしたのはScale Venture Partners、これにMicrosoft Ventures, Salesforce Ventures, Samsung Next, Notion Capital, Caixa Capital, Funders Clubらが参加した。この前のシリーズAのラウンドは2016年10月で、調達額は500万ドルだった。

Y Combinatorの2014年冬季を卒業したUnbabelは、AI/機械学習を利用し、約55000名の人間翻訳者のネットワークを併用しながら、メールやチャット、Webサイトなどのテキストを翻訳する。ただし翻訳結果ではなくAPIによるユーザープロダクトとの統合という形で提供され、すでにSalesforce, Zendesk, WordPress, Mailchimpなどのエンタープライズソフトウェアで利用されている。

Unbabelの協同ファウンダーでCEOのVasco Pedroによると、今度の資金は主に同社プラットホームのAI/機械学習部分の増強に充てられる。それは同社の成長とともに、重要性が増している。

もうひとつ資金を投じたいのが、営業とマーケティングだ。それは同社がこれまであまり力を入れなかった部分だ。ただし現在あるアメリカのオフィスは主に営業専門、ポルトガルは製品開発とエンジニアリングが主体だ。

課題のひとつは、Unbabelのようなソリューションがあるのだ、という認識の普及。つまりそれは、Google Translateのような機械翻訳か、それとも複数の言語を知ってる人間にやらせるか、という二者択一ではない。

Unbabelのプラットホームは機械を人間が補強し、人間を機械が補強する。その両方向だ。どっちが多くなるかは、コンテンツのタイプや、スピードと精度/ニュアンスのトレードオフで決まる。

たとえばチャットに翻訳機能を持たせたいユーザーは、機械翻訳によるリアルタイムに近いスピードを選ぶだろう。しかしメールは非同期だからやや遅くてもよいので、人間の出番が多くなる。

Unbabelは上で挙げたエンタープライズ向けサービスのほかに、Facebook(Oculus), Buzzfeed, Booking.com, Pinterest, Under Armourなども利用している。Pedroによると、今回の投資家たちがMicrosoftやSalesforce、Samsungなどと関係があるのも、今後のエンタープライズ顧客を獲得していくためだ。

Samsung Nextの社長Nick Nigamが、声明文の中で言っている: “地理的境界をなくしてしまう技術には投資対象としての魅力がある。Unbabelは語数あたりの利用料金が継続的に下がっているので、国境のないコミュニケーションがプロフェッショナルでスケーラブルに、しかも手頃なお値段で可能になる”。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

Twilioなどと競合する専用通信サービスの古顔BandwidthがNasdaqに上場して好調

Bandwidthは、卸売企業やエンタープライズ企業に音声とテキストによる専用の通信サービスを提供するとともに、デベロッパー向けのAPIも公開している。同社は今日(米国時間11/10)Nasdaq に上場し、その初日の商いで6%上げた。IPO価格(一株あたり)は予想値の底値20ドルだったが、終値は21ドル19セントとなった。すなわち、6%高である。

ノースカロライナ州ローリーの同社は、上場により8000万ドルを調達した。これまで自己資本だけでやってきたBandwidthは、その資金を新規雇用と研究開発に充てる予定だ。

協同ファウンダーでCEOのDavid Morkenによると、Bandwidthは“キャッシュフローがプラスでずっと前から黒字”だ。彼が同社を創業したのは1999年で、その後作ったワイヤレス部門は別会社Republic Wirelessとして独立させた。

BandwidthはTwilioやNexmoと競合するが、同社によると彼らは、“APIのカバー範囲が狭い、カスタマーサポートが弱い、そのほかの機能が少ない、そしてサードパーティのネットワークや物理的インフラストラクチャに依存している”、という〔Bandwidthは主に自前のネットワーク〕。

通信企業としてはAT&TやLevel 3、Verizonなどと競合するが、こちらは同社に言わせると、“ネットワークサービスのプロバイダーだが、彼ら自身のネットワークや物理的インフラストラクチャはデベロッパー向けの機能が貧しい”そうだ。

Bandwidthによると、同社は865社の大企業が利用しており、その中にはGoDaddyやZipRecruiterなどもいる。音声ネットワークが自前なので、APIの統合のクオリティが良い。

同社の昨年の売上は1億5210万ドル、2015年には1億3780万ドルだった。

2016年の利益は2240万ドル、2015年は670万ドルの損失だった。

TechCrunchのオーナー企業はVerizonである。同社の事業はBandwidthと同じ分野である。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

GoogleがAndroid 8.1にNeural Networks APIを導入、今日からデベロッパーベータを提供

今日Googleは、Android Oreo(v8.1)のデベロッパー向けベータの配布を開始した。

今回の大きな目玉はNeural Networks APIで、これによりスマートフォン上でハードウェアアクセラレーション〔後述〕によるNNの推論を行い、訓練済みの機械学習モデルを高速に実行する。この種の計算をエッジに持ち込むことによって、ネットワークのレイテンシーと負荷が減り、機密データがデバイス上に留まることによって、エンドユーザーに多大な便宜をもたらす。

このNN APIにより、スマートフォン上で画像分類をしたり、ユーザーの行動パターンから次にやることを予見する、といったアプリが可能になる。Googleによると、このNeural Networks APIはTensorFlow LiteやCaffe2などのフレームワーク使いこなすための“基礎としての層”として設計した、という。

このAPIはデバイス上にAI専用チップがあればそれを利用できるが、なければふつうにCPUを使う。GoogleのスマートフォンPixel 2には専用チップPixel Visual Coreが載っており、Googleは前にも、8.1のプレビューが使えるようになったらそれが実際に動く、と言っていた(つまり今日だ)。

Neural Networks APIはユーザーのデバイスを酷使するが、Googleは8.1でAndroid Go用の最適化を導入し、デベロッパーがもっとベーシックなスマートフォン用にはその軽量バージョンのAndroidを使えるようにした。それは、今年の5月にI/Oカンファレンスで発表された簡易版Androidだ。

Goは、接続性の良くないところで使う低スペックのスマートフォン用だ。今回のアップデートではRAMが1GBに満たないデバイス向けのメモリの最適化が行われ、またそれらが8.1以降で動いている場合には、配布するアップデートを対象デバイスのシステムメモリに応じて選択できる。

そのほか、8.1デベロッパープレビューではAutofillがアップデートされて、パスワードマネージャーがこのフレームワークを使いやすくなった。また、そのほかのバグパッチやセキュリティパッチも、いろいろ行われているはずだ。

Android 8.1が消費者の手に渡るのは12月の予定だが、デベロッパーは今すでに、このベータにアクセスできる。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

デベロッパーでなくても誰でも通信機能のあるアプリケーションを容易に作れるTwilio Studio

Twilioはデベロッパーが自分のアプリケーションに通信機能(オーディオ、ビデオ、テキストなど)を容易に組み込めるためのAPIサービスとして長年有名だが、しかし今日(米国時間9/19)同社が非公開プレビューで立ち上げたTwilio Studioは、デベロッパーでない人びとを対象にしている。

あくまでも通信APIのプロバイダーという同社の本来の土俵にしっかりと立ってはいるのだが、しかし今回のプロダクトは、デベロッパーではなく“だれもが”、音声応答システムやメッセージングボット、通知ワークショップなど顧客のエンゲージメントのあるアプリケーションを、Web上のドラッグ&ドロップ方式で作れる。今のところ、ビデオはまだ使えない。なお、Twilioのマーケティング戦略としては、通信〜コミュニケーションを中心とするユースケースにフォーカスしているけれども、作れるアプリケーションの種類はそれだけではない(もっといろんなアプリケーションを作れる)。

Twilio Studioは特定の種類のアプリケーションを作るための、コーディング不要のサービスだが、実はプロのデベロッパーも対象にしている。Twilioのプロダクト担当VP Pat Malatackはこう語る: “これによって、こういうユーザー体験〔==アプリケーション〕を作れる人の数が大幅に増えるけれども、しかしこんなワークフローを今実際に作っている多くの企業の既存の技術者にとっても、すごく便利なんだ”。

というかTwilio Studioには、同社のサーバーレスプラットホームTwilio Functionsが組み込まれている。StudioでTwilioの既存のAPIのほとんどにGUIでアクセスできるけれども、ドラッグ&ドロップのインタフェイスでは、コードを直接書くことに比べると柔軟性が失われがちだ。しかし機能の呼び出し形式が単純なサーバーレス方式のおかげで、デベロッパーが仕事をした後でも、誰もが容易にアプリケーションに変更を加えることができる*。〔*: サーバーレスでは、アプリケーション側が‘呼び出す’というより、むしろアプリケーションはAPI側がイベント(ここでは主に通信イベント)発生時に呼び出すべき機能を‘指定して’おくだけ。なので、ノンデベロッパープログラミングでも柔軟性が維持される。〕

Twilio Studioの料金は、アプリケーションの利用量がベースだ。やや制限のある無料プランでも、作れるフローの数に制限はないが、プロダクション向けに機能の完備した“Plus”では、月額99ドル+顧客のエンゲージメント一回につき0.5セントだ。今後登場するエンタープライズプランでは、もっと大規模な実装が可能になる。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))

GoogleがTensorFlowによるオブジェクト検出APIをリリース、機械学習のデベロッパー利用がますます簡単に

Googleが今日(米国時間6/16)、TensorFlowのオブジェクト検出APIをリリースする。これによりデベロッパーや研究者は、画像中のオブジェクトを容易に認識できるようになる。Googleは今回とくに、単純性とパフォーマンスを重視している…今日リリースされるモデルはすでにベンチマークの成績も良く、研究用にいつも使われていたものだ。

この検出APIに含まれているひとにぎりほどのモデルは、インセプションに基づくヘビーデューティーな畳み込みニューラルネットワークや、それほど高度でないマシンで使う単純化されたモデルなどだ…そのように最適化されているシングルショットの検出システムMobileNetsは、スマートフォン上でリアルタイムで使用できる。

今週初めにGoogleはそのMobileNetsを、軽量なコンピュータービジョン用のモデルの系統として発表した。これらのモデルは、オブジェクト検出や顔認識、ランドマーク認識などに利用できる。

今のスマートフォンは大型デスクトップやサーバーほどの計算資源がないから、デベロッパーには二つのオプションがある。機械学習のモデルをクラウドで動かすか、または、モデルを単純化することだ。しかし前者にはレイテンシーがありインターネットが必要だから、大衆化は無理だろう。後者は逆に、広範な大衆化のためにパフォーマンスで妥協するのだ。

GoogleとFacebookとAppleは、こういったモバイルのモデルに注力している。昨秋Facebookは、スマートフォン用のモデルを作るためのフレームワークCaffe2Goを発表した。それの最初の大型実装が、FacebookのStyle Transferだった。Googleはこの春のI/Oで、単純化された機械学習フレームワークTensorFlow liteをリリースした。さらにAppleは先日のWWDCで、機械学習のモデルをiOSデバイスで使いやすくするためのシステムCoreMLを打ち出した。

GoogleはFacebookやAppleと違って、パブリッククラウド上でいろんなものを提供しており、コンピュータービジョンもすでに、スケーラビリティのあるコンピュータービジョンサービスとして Cloud Vision APIを提供している。

今日発表されたTensorFlowオブジェクト検出APIはここにある。それを誰でも簡単に試せるし実装できるものにしたいGoogleは、そのキットのパッケージに重みと、Jupyter Notebookを含めている。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))

AWSのRekognition APIはセレブを認識する――Amazonの機械学習がさらに進歩

Amazon RekognitionはAWSが提供する深層学習を利用した画像認識、分析のサービスだ。今日(米国時間6/8)、Rekongnitionがさらに賢くなった。このサービスは政治、スポーツ、ビジネス、エンタテインメント、メディアなどさまざまな分野の著名人の顔を認識できるようになった。

私はGoogle検索で見つけたいくつかの顔写真(コメディアンのコナン・オブライエン、歌手のジャスティン・ビーバー、知名度さまざまな俳優、女優など)をRekognitionに入力してみたが、すべて認識された。GoogleとMicrosoftが提供している同種のサービスと同様、デベロッパーはAPIを通じてRekognitionを利用するが、AWSのアカウントを持っている読者はこちらでデモを体験できる。

Rekognitionはセレブの顔認識に成功すると、可能な限り、IMDBのページにリンクする(IMDBはAmazonの子会社なので当然だ)。

現在のRekognitionは顔認識だけでなくユーザーが提供するデータに基づいて画像の文脈を認識し、被写体の感情、人口動態的分類ができるが、新機能によってサービスがさらに強化された。

ちなみにGoogleのVision APIには現在まだセレブの顔認識機能はないが、MicrosoftのComputer Vision APIにはある。Microsoftによれば20万人の著名人の顔認識ができるということだ。私がテストしたところでは、Microsoftのサービスの顔認識精度はAmazonとほぼ同様だったが、画面に写っている他の対象についても情報が提供され、これに基づいて写真のキャプションを作ることができた(「スーツにネクタイのジャスティン・ティンバーレイクがカメラに向かって笑っている」など)。

〔日本版〕Rekognitionの画像中の物体の認識、表情分析などの例。MicrosoftのComputer Vison APIはDescriptionで内容に関するキーワードを返してくる。

[原文へ]

(翻訳:滑川海彦@Facebook Google+

機械学習による画像認識とAR(拡張現実)を結婚させて企業のツールにしたいBlipparが車の車種年式当て技術を発表

自分は、車をよく知ってる方だ、と思う?

でも、Blipparの今度の機械学習技術は、どんなに車通(つう)の人より、すごいかもしれない。この拡張現実/ビジュアル検索企業が今日、自動車を認識する技術を発表したのだ。

BlipparのAIは、2000年以降に作られたアメリカ車のメーカー、車種、そして年式を当てる。ただしその車の現在の速度が15mph以下である場合。

Blipparは最初、企業やパブリッシャーのためのARプラットホームとしてローンチした。Blippと呼ばれる小さなタグを使って、企業はケチャップの瓶のラベルとか雑誌の中の広告などのコンテンツを指定する。ユーザーがそれをスマートフォンのカメラでスキャンすると、その上に拡張現実のコンテンツが現れる。

その後同社は方向を変えて、ビジュアル検索に注力した。Googleの検索は言葉(その物の名前など)を知らないと検索できないが、ビジュアル検索なら、花やファッションなどをカメラで覗くだけでよい。

同社は昨年まで、テーブル、椅子、コップなどなど一般的な物のビジュアル検索を作っていたが、それによって、もっと特定の物をビジュアル検索できるための技術的基盤を獲得した。

その最初の挑戦が、自動車の認識だ。

車種当てで遊んでみたい人のためには、Blipparアプリにこの技術が導入される。メーカー、車種、年式だけでなく、その車の評判や360度写真も見れる(車内と車外両方)。でも同社としての本格的なビジネスは、同じく今日ローンチしたAPIだ。

中古車販売店や保険屋さんは、この自動車認識技術を自分のアプリに組み込み、ビジネスに利用できる。店員や営業は、自分の脳に大量詳細な車種知識がなくても務まるだろう。

現在の認識精度は97.7%以上で、Blipparの主張では、ほとんどの人間の目視判断能力を超えているそうだ。

来年はBlipparから、もっといろんな商品種や業種用の認識技術/APIが登場するだろう。CEO Rish Mitraによると、次はファッションで、もうすぐ出るそうだ。

Crunchbaseによると、Blipparはこれまでに、Qualcomm VenturesやKhazanah Nasionalなどから総額9900万ドルを調達している。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))

モバイル向けに痩身の機械学習/ディープラーニングモデルを作るTensorFlow LiteがGoogle I/Oで発表

今日(米国時間5/17)のGoogle I/OでAndroidの将来について話す中で、エンジニアリング担当VP Dave Burkeは、モバイル向けに最適化されたTensorFlow、TensorFlow Liteを発表した。デベロッパーはこのライブラリを使って、Androidスマートフォンで動く痩身のディープラーニングモデルを作れる。

Googleはこのところますます多くの、Android上で動くAIを使ったサービスを展開しているから、それ専用の小さくて速いモデルを作れるフレームワークを使うのも当然だ。このAPIも年内にはオープンソースでリリースされる予定だ。

昨年はFacebookが、Caffe2Goを発表した。それもやはり、同社のディープラーニングフレームワークCaffeのモバイル用バージョンで、モバイルデバイスに合ったモデルを作れることがねらいだ。Facebookはこれを使ってリアルタイムの写真整形ツールStyle Transferを作り、それはまた、今後のプロダクトやサービスの基盤にもなるものだ。

ただし、モデルを作るための教育訓練は、あまりにも計算集約的な処理なのでスマートフォン上でやるのはまだ無理だ。いや、訓練済みのモデルですら、従来のものはモバイルには重すぎた。でもモデルがデバイス上で使えれば、状況によってはクラウドとインターネットがまったく要らなくなる。スマートフォン上のディープラーニングのパフォーマンスが、より安定するだろう。

TensorFlow Liteは、AIとモバイルデバイスの結合というGoogleのビジョンをさらに前進させる。そしてその次の段階としては、TensorFlow Liteが活躍する場を増やすための、さまざまな専用ハードウェアの開発ではないだろうか。



[原文へ]
(翻訳:iwatani(a.k.a. hiwa))

必要なHRサービス間でデータ連携、マネーフォワードが「MF クラウド給与」のAPIを公開

採用から労務管理まで、HR領域のクラウドサービスは増えてきている。業務の用途別に複数のサービスを利用している会社も多いだろう。しかし、複数のサービスを利用する場合は、データ連携の課題が発生する。マネーフォワードは、HR領域の他社サービスとAPI連携することで、各企業が自社にとって最適な人事労務サービスを選べる世界を実現したい考えのようだ。マネーフォワードは本日、それを実現する「Connected HR」と銘打ったコンセプトを発表し、クラウド型給与計算ソフト「MF クラウド給与」と連携を希望するサービスにAPIを公開すると発表した。

企業の規模やステージに応じてニーズが異なるとマネフォワードは説明する。例えば、9時から17時が定時の会社と、アルバイトの多い飲食店、あるいは業務委託が多い職場だと勤怠管理や労務管理に求められる機能は違う。マネーフォワードでは、それを1社で全ての機能を賄うことは難しいと考え、各企業が労務管理にはこのサービス、勤怠管理には別のサービスといったように、その会社に最適な組み合わせで利用できるようにしたい考えだという。

これまでにもマネーフォワードは勤怠管理の分野ではKING OF TIMEジョブカンCREW CHECKERTouch On Timeの4サービス、労務管理ではSmartHR労務ステーションの2サービスとAPI連携を行ってきた。ただ、これまでのデータ連携は、勤怠管理サービスから「MF クラウド給与」に勤怠情報を移すといった一方通行に限られていたとマネーフォワードの広報担当者は説明する。今後はHR領域の他のサービスとも連携を進め、双方向でのデータ連携も可能になるという。具体的には、社会保険手続きの簡素化、年末調整の計算や電子申告、人材評価などの分野で、「MFクラウド給与」の給与や賞与データの活用を想定しているという。

HR領域で他社サービスと協力関係を築くというマネーフォワードが掲げる「Connected HR」のコンセプトは、競合となるfreeeの戦略とは正反対のものと言えそうだ。2017年3月、freeeは「給与計算 freee」に機能を追加する形で、新たに人事労務業務のための「人事労務 freee」を2017年初夏頃から提供すると発表した。freeeは従業員データを一元管理することで、企業の人事労務業務の効率化を目指すとしている。

Google AssistantのSDKをデベロッパーに提供、製品のプロトタイプへの使用は自由で無料

Googleは前から、Assistantをさまざまなハードウェア企業やデベロッパーから成る大きなエコシステムへ公開したい、と言っていた。今日(米国時間4/27)同社はその方向へ大きく一歩前進し、Google AssistantのSDKローンチした。デベロッパーはこれを使って、自分のハードウェアにAssistantの知能を組み込める。たとえばスマートミラー(鏡)とか、Google Home的な器具や装置、絶対禁酒を誓った人が秘かに楽しむロボットのバーテンダー(上図)など、何でも好きなものを作れる。

ただしGoogleのAPIを自由に使えるのは、プロトタイプを作るときだけだ。商用製品を作るときには、Googleの正式の許可が要る。

SDKはPythonのコードで提供され、人気のRaspberry Pi 3をはじめ、さまざまなハードウェアプラットホームで使える。GoogleのgRPC APIを使えば、Assistantをそのほかのハードウェアプラットホームにも統合でき、またJava, C#, Node.js, Rubyなどの言語を使える。このSDKを使えば、自分のハードウェア製品が音声コマンドを聞き取り、それらをGoogle Assistantのサービスに送り、適切な応答を受け取ることが容易にできる。

Googleによると、SDKを使っているデバイスはAssistantのすべての能力を利用できる予定だが、現状は違う。リリースノートにはたとえば、アラームとタイマーをセットできない、と書いてある。音楽の再生、ニュース、ポッドキャストもだめだ。ホームオートメーションの機能の多く、および、Uberなどサードパーティサービスの呼び出しは、まだGoogle Homeにしかできない。

Assistantに話しかけるAPIはすでに公開されている。この“Actions on Google” APIは、サードパーティのアプリケーションをGoogle Homeに統合するためのものだ。またPixelスマートフォンや今後のAlloでも、Assistantがサポートされる。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))

Alexaを支える技術Amazon Lexが開発者に開放された

Amazonの仮想アシスタントAlexaを支えているテクノロジーであるAmazon Lexが、今朝(米国時間20日)のロイターの記事によれば、プレビュー段階を終了したということだ。自然言語理解技術を自動音声認識技術を組み合わせたこのシステムが、最初に紹介されたのは11月にラスベガスで開催された、AmazonのAWS re:Invent会議のことだった。

その時Amazonは、例えばチャットボットのような会話型アプリケーションを作りたい開発者たちが、そのようにLexを使うことができるかを説明した。

例として同社がデモしたのは、ユーザーが声だけを使って飛行機の予約を行うことができるツールだった。

とはいえ、このシステムは、Facebook Messengerのような、今日見られる消費者向けメッセージングアプリ内の、チャットボットに使われることだけに縛られているわけではない(もちろんそうしたプラットフォームに統合することは可能だ)。実際にはLexは、モバイルや、ウェブや、SlackやTwilio SMSのようなMessengerを超えたその他のサービスの中で、音声やテキストチャットボットとしてどのようにも利用することが可能だ。

AmazonはLexが、ウェブやモバイルアプリケーションの中で、ユーザーに情報を提供したり、アプリケーションに能力を与えたり、様々な仕事を支援したり、さらにはロボットやドローンやおもちゃを制御するメカニズムを提供したりといった、様々な目的のために利用できることを示唆している

とはいえ、メッセージング内のチャットボット、特にeコマースのボットは、Lexテクノロジーへの確かなエントリーポイントの1つである。不恰好なナビゲーションメニューをもち、ユーザーの問に対して限られた返答しか行うことができない現行のチャットボットに、消費者たちは不満を抱いている。これに対してLexは、音声をテキストに変換し、テキストの意図を認識して、より会話らしくすることができて、現在市場にあるものよりもさらに洗練されたボットを開発することを可能にする。

Amazonによって管理されるLexは、ボットの使用量が増えるに従って自動的にスケールアップする。つまり開発者たちはLexが処理したテキストと音声の量に従って支払いをするだけでよい。

Lexををより広い開発者コミュニティに解放するAmazonの戦略は、GoogleのAsisistantやAppleのSiriなどの、他社の音声技術に対しての競争優位性を確保するために役立つことだろう。本日のレポートには、AmazonがLexを組み込んだアプリから送られるテキストや録音を用いてLexを改善し、より多くの問い合わせを理解する能力に磨きをかけることを計画していることも書かれている。

このオープン性は、Alexaプラットフォームに対する、Amazonの大きな戦略であり続けている。例えば、Amazonは既に、開発者がAlexaをそれぞれのデバイス(スピーカーや、ベッドサイド時計など)に統合することを可能にするAlexa Voice Servicesをロールアウトしていた。

Amazonがオープンエコシステムを推進している分野は、Alexaのソフトウェアだけではない。同社は今月初めには、そのEchoスピーカーを支える技術を、サードパーティデバイスメーカーも利用できるようにすると発表した。これにはAlexaコマンドを聞き取るためのマイクロフォンアレイや、ウェイクワードを認識する独自ソフトウェア、バックグラウンドノイズの低減、そして大きな部屋の中での反響のキャンセルなどが含まれている。

これらをOEM企業に提供することで、他のメーカーたちも自身のスマート音声認識製品を構築することができる。たとえそれがAmazon自身のEchoスピーカーと競合するとしても。

Amazon Lexに興味のある開発者は、ここから始めることができる。

[ 原文へ ]
(翻訳:Sako)

iPhoneのLive Photoを誰もがWebブラウザー上で再生できるJavaScriptをAppleがリリース、まずご自分のWebサイトから

AppleのLive Photosは楽しい。多くの場合、ふつうのスチル写真にない意外な瞬間を捉えることができる。でもそれらは、スマートフォンとそのアプリの中から外には出られない。それらがWeb上に出回ることは、とくにデスクトップのWebブラウザーの場合、ごく稀だ。

Tumblrは昨年、この壁をすこし破り、WebアプリケーションにLive Photosを加え、それをするためのツールも公開した。でも、Apple公認の方法はまだどこにもなかった。

それが今朝(米国時間4/20)秘かに変わり、AppleはデベロッパーポータルのアップデートでLivePhotosKitというツールをリリースした。それは、ユーザーのWebサイトにLive Photoの再生機能を持たせるJavaScriptのAPIだ。

本誌TechCrunchはまだそれを加えていない。GIFよりずっと良いWebMもまだだから、ここではまあまあのGIFをご覧いただこう(上図)。実例は、ここで見られる。

なかなか良くできている、と思うけど、Appleの実例を見るかぎり、Web上でLive Photoを再生する方法が、よく分からない。

単純なクリックとか、画像上のホバリングとか、画面のスクロールで、再生をトリガ(起動)できないかな?

Appleの実例の場合は、画像の右上にある[LIVE]のマークの上をマウスがホバリングすると再生が始まる。分かれば簡単だけど、ぼくなんか最初のしばらくは、Appleのサイトがフリーズしちゃったのか、と思った。

このAPIのAppleのドキュメンテーションは、モバイルも含めて、主なブラウザーのほとんどでうまくいく、と言っている。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))

Slackでステータスの設定が可能になった(ミーティング中、休暇中、移動中、etc)

AFK(Away From Keyboard:ちょっとキーボードの前を離れています)、BRB(Be Right Back:すぐに戻ります)、コーヒーミーティング中、などなど。すぐに流れ去って行くコミュニケーションの中で、Slackへの書き込みは、恐らく離席メッセージや現在ステータスといった、「あなたの状況」を人びとに知らせるための第1の場所ではなかっただろう。

そうした目的にあなたが使うのは、おそらくページの最上位に陣取ったり、簡単に検索のできるようなスレッド付き内部コミュニケーションプロダクトだ。これは、企業がより大きくなって、コミュニケーションチャネルがさらに手を付けられなくなって来たときに、特に当てはまる。しかしSlackは、メッセージ(あるいはチャネルで禁止されていないならGIF)ストリームの中で迷子にならないやり方で、素早くメッセージの混乱の中に割り込むことのできる、その種の従業員間のステータス共有手段を、何らかの方法でプロダクトの中に取り込みたいと思っていた。

そしてこれを実現するために、Slackは独自のステータス表示と離席メッセージを追加した。ユーザーは、名前の横にある絵文字の上にマウスを置くことで、相手が何をしているかを知ることができる。例えば歯医者で歯を削っているとか、退社したといったステータスだ。メッセージに応答できない理由(Wi-Fiが使えない飛行機に搭乗中とか、その他の理由)を100文字以内で絵文字と共に追加することもできる。

おそらくこのアップデートでさらに興味深いのは、Slackがこの機能をサードパーティの開発者にも開放して、自動的にステータスを設定可能にしたことだ。Slackのブログ投稿によれば、人事システムのZenefitsを使って休暇申請を行った場合、Zenefitsが自動的に離席メッセージをセットするということだ。これは開発者たちに、シリコンバレーでは徐々にホットなものになって来ているプラットフォームへの、また別の入口を与えることになるが、従来の社内コミュニケーションチャネルにこだわる大企業の実世界では、まだまだ攻め込んで行く余地がある。

Skackは今年の初めに、ある種の会話に対して、Slackをより永続的で情報保存ができる場所にしようと、スレッド付きメッセージを導入した。ステータス更新は、ある意味、それほど風変わりなものではない。ある従業員の現在の状況を静的な表現で同僚たちに伝えるための、コミュニケーションのための半永久的な場所として存在している。Slackはどうやら、メッセージングクライアントではなくて、より内部コミュニケーションのためのホームページになろうとしているようにも見える。それはこの先、既存のプロダクトから離れようと人びとを引き止めるするためには、重要なことになる。

時折プロダクトの更新に及び腰のように見えることもあるSlackは、ここ数週間の間には相当量の機能追加を行ったようだ。今週の初めにはさらに、Slackボットをドロップダウンメニューでもっとインタラクティブにするためのツールを、開発者に対して公開している。

[ 原文へ ]
(翻訳:Sako)

「誰でもAmazonプラットフォーム」のBringgが、新たに1000万ドルを調達

より速く、より透明性の高い、オンデマンド配送の活用を目指すスタートアップのBringgが、シリーズBで追加の1000万ドルを調達したことを、今朝(米国時間3月14日)発表した。調達はAleph VCによって主導され、コカ・コーラや、前回も投資したPereg Venturesなども参加している。

2013年に設立され、シカゴに本社を置くBringgは、かつてMobileMaxを創業しCEOを務めたRaanan Cohen、そしてGett and Clarizen.comのCTOを務めたLior Sionによって創業された。基本アイデアは、各企業の配送業務に、AmazonやUberレベルの業務可視化を提供することで、そこには配送通知や、運転手の地図上での追跡、運転手から顧客への連絡、スター格付け、その他の機能が含まれている。

Bringgのソリューションを使用する企業は、リアルタイムにルートの最適化と優先度つけを行うことが可能で、配送をより効率的に行うことができるようになる。これにより、企業はAmazonなどのような企業と競うことができるようになる、とSionは説明している。

「AmazonやUberは、顧客の期待レベルを、これまで見たことがない程の高いレベルに押し上げました」とSion、「現在の消費者たちにとっては、もし何かを注文してそれが届くのに1週間もかかり、そして正確にいく届くかが分からないとしたら、とても奇妙な気がします。そうした経験はとても不快なものです」。

そしてUberやAmazonのような企業のオペレーションが、さらに強力で効率の良いものになるにつれて、Bringgの業績も更に伸びてきている。その扱う配送量は前四半期に比べて300パーセント多いものになっているのだ。

「小売店はアマゾンに敗れ、直接顧客との関係を持たないブランドたちは怯えています。彼らは消費者に直接販売し、直接届ける方法を探しているのです」とSion。「私たちは、Amazonが支配しようとしている、全体の配送体験の民主化を目指しているのです」と彼は付け加えた。

現在、Bringgは50以上の国に数百の顧客を抱えている。その中には完全な配送チェーン、小包配送サービス、食品配達サービス、さらには、例えば、ドライクリーニングサービスや、ケーブルTV修理会社、なども含まれている。利用企業は扱い量に応じた金額をBringgに対して支払う。

多くの顧客は、投資もしているコカ・コーラのような大企業であり、Bringgを様々な用途に用いている。例えば企業と最も近くの卸業者を結び在庫切れに対応するとか、修理業者のオペレーションを扱うとか、更には米国外における企業と消費者間の関係までも扱う。

Bringgは顧客名の開示は拒んだが、基本的に相手はスタートアップではないということを指摘した。単に車両をリアルタイムに管理する機能を用いるだけではなく、配送業務のコストを最適化する必要に迫られた企業が顧客となっているということだ。リアルタイムマップ、通知、サービス格付け、コミュニケーションなどを実現するAPIやSDKのセットをアプリやウェブサイトに統合する能力に加えて、コスト最小化に向けて、ルート、運転手、そして配送を最適化することが、Bringgの支援するサービスだ。

さらに同社は、様々な配送モードや配送業者を同時に扱うことができる、例えば社内車両とサードパーティの車両を混合運用したり、より忙しい時間(例えば休日)に、クラウドソーシングで一般ドライバーを使って運送力を拡大することなども実現可能にしている。

「Amazonは消費者がサイトに訪れた瞬間から、在庫、配送の最初そして最後の1マイルに至るまで、徹底した可視化経験を消費者に提供しています。そしてこれこそが、彼らが他の業者をことごとく打ち倒している理由なのです」とSion。「彼らは、その過程の全てを最適化していくことができます…私たちの目標は、同じ能力を私たちの顧客に提供することなのです。これこそが、唯一のAmazon対抗手段だと私たちは考えています」と彼は言う。

50人のチームで構成される彼らの会社は、現在テルアビブ、ニューヨーク、そしてシカゴにオフィスを持っていて、追加の資金により新しい市場、新しいセグメントへの進出を計画している。これにはR&Dチームと運用チーム(セールス、マーケティング、アカウント管理そしてサポートを意味する)の拡大が含まれる。

現在までに、Bringgは1900万ドルを調達している。

[ 原文へ ]
(翻訳:Sako)