フランスのビッグデータ分析サービスOpenDataSoftがこのほど、シリーズAで500万ドルを調達した。Aster CapitalとSalesforce Venturesがこのラウンドをリードし、既存の投資家AurinvestとAder Financeが参加した。

OpenDataSoftは企業や団体などがデータをより有益に利用するためのサービスを提供するSaaSだ。今、多くの企業や自治体などは大量のデータを抱えているが、その有効利用はほとんどやっていない。OpenDataSoftは、それらの団体や組織がデータの分析と処理と視覚化に取り組むとき、その第一歩を助ける。

社名に‘OpenData’とあるように、同社がとくにねらうのは、データをオープンにして外部者や第三者が、独自の用途やサービスに利用できるようにすることだ。たとえば鉄道企業がすべての時刻表データをAPIとして公開したら、デベロッパーは乗り換え案内のアプリを作れるだろう。

ぼく個人的には、自治体がOpenDataSoftのようなものを利用して、もっとデータドリブンになってほしい。いろんなサービスや自治体、公共団体等のあいだに、デジタルのコミュニケーションがない。なさすぎる。ひとつの都市と、その周辺（関連団体等）の可動部品がすべて統合されたら、あらゆることをもっと効率化できるだろう。ぼく自身は、“スマートシティ”という、もっともらしくて空疎な言葉が大嫌いだ。

同社は、これまでのヨーロッパに加えて、今度ボストンにオフィスを構え、アメリカ進出をねらう。ヨーロッパも今後は、フランスだけでなくドイツ、イタリア、スペイン、イギリスなどにも顧客を開拓していく。

これらの国にオフィスを置く、という意味では必ずしもないが、これらの国々からの人材起用は十分にありうるだろう。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa））

Googleが今年前半に立ち上げたCloud Machine Learningサービスは、Google自身によれば、早くも“急成長プロダクト”の一つになっている。今日同社は、このサービスの新しい機能をいくつか発表し、機械学習のワークロードを動かしたいと思っているユーザーとデベロッパーの両方にとって、さらにサービスの利用価値を増そうとしている。

これまでGoogleは、競合するAWSやAzureのように、ハイエンドのGPUを使う仮想マシンをデベロッパーに提供してこなかった。しかし、機械学習など、科学の分野に多い特殊でヘビーなワークロード、とくにそれらのアルゴリズムは、GPUのパワーを借りないとうまく動かないことが多い。

デベロッパーたちが一般的にGoogle Cloud Platform上で機械学習のワークロードを動かせる、そのために仮想マシンのGPUインスタンスが提供されるのは、Googleの発表によると、2017年の前半だそうだ。料金は、そのときに発表される。

なぜGoogleは、もっと前からこのタイプのマシンを提供しなかったのだろうか？　Google自身、機械学習に非常に熱心だし、競合相手のAzureやAWSはとっくに提供しているというのに（Azureは今日（米国時間11/15）、OpenAIとパートナーシップを結んだ）。

しかしデベロッパーは、Googleの既存のCloud Machine Learningサービスを使って自分の機械学習ワークロードを動かすことはできる。そのための構築部材TensorFlowも利用できる。でもCloud Machine Learningが提供しているような高い処理能力と柔軟性を、Google既存のプラットホームで利用することが、まだできない。

今のGoogleはデベロッパーに、カスタムの機械学習モデルを構築するためのサービスと、機械学習を利用した、すでに教育訓練済みのモデルをいくつか提供している（マシンビジョン(機械視覚)、音声→テキスト変換、翻訳、テキストの情報取り出しなど）。Google自身が機械学習で高度に進歩しているし、独自のチップまで作っている。そこで今日のGoogleの発表では、Cloud Vision APIの使用料が約80％値下げされた。またこのサービスは、企業のロゴや、ランドマークなどのオブジェクトも見分けられるようになった。

そしてテキストから情報を取り出すCloud Natural Language APIは、今日（米国時間11/15）、ベータを終えた。このサービスは、構文分析機能が改良され、数値、性、人称、時制なども見分けられる。Googleによると、Natural Language APIは前よりも多くのエンティティを高い精度で認識でき、また感情分析も改善されている。

消費者向けのGoogle翻訳サービスは、今ではカスタムチップを使っている。またデベロッパー向けにはCloud Translation APIのプレミアム版が提供され、8つの言語の16のペアがサポートされる（英語から中国語、フランス語、ドイツ語、日本語、韓国語、スペイン語、トルコ語、など）。サポート言語は、今後さらに増える。プレミアム版では、これらの言語に関しエラーが55から85％減少した。

この新しいAPIは主に長文の翻訳用で、100言語をサポートする“標準版”は、短い、リアルタイムな会話テキスト用だ。

さらに、まったく新しいプラットホームとしてCloud Jobs APIがある。この、あまりにも専門的で奇異とすら思えるAPIは、求職者と仕事の最良のマッチを見つける。つまり、仕事のタイトル、スキル、などのシグナルを求職者とマッチングして、正しいポジションに当てはめる。Dice やCareerBuilderなどのサイトはすでにこのAPIを実験的に使って、従来の、ほとんど検索だけに頼っていたサービスを改良している。このAPIは、現在、特定ユーザーを対象とするアルファだ。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa））

あなたがこれから作るアプリには、ユーザーがビデオをアップロードしたり、保存したり、再生する機能が必要だ。しかしビデオコンテンツの管理システムを自分で作るのも、既存のシステムのライセンスを買うのも、ちょっとたいへんすぎる。そんなときは、Synqに第三のオプションがある。同社は、“デベロッパーのためのビデオAPI”をクラウドから提供するサービスを、今日（米国時間11/29）立ち上げた。ビデオのための完全なインフラストラクチャを、ワンセットで提供することをねらっている。

特殊なニーズがないかぎり、デベロッパーが自分で作らずに済むための、補助的機能のサービスは、今やいろいろある。電話機能ならTwilioだし、支払い決済はStripeやPayPal、Squareなどを使える。アプリ内のアナリティクスともなると、APIプロバイダーは枚挙に暇（いとま）がない。

同社は自分のことを、ビデオのためのTwilioだ、と言う。今ではTwilioにもビデオはあるけど、でもそれは、Synqが考えているようなのとは、違う。

デベロッパーが自分のアプリにビデオを容易に実装できるようにする

SynqのCEOでファウンダーのStian Haugeは、デベロッパーが自分のアプリケーションの中でビデオを使うのが難しすぎる、と嘆き、“ビデオってヘンなやつだからね”、と言う。“だからうちのプラットホームは、デベロッパーが今相手にしている既存のインフラストラクチャが何であっても、その上で高度なビデオ機能を実装できるための、十分な柔軟性を提供する。またそれと同時に彼らが、ARやVR、機械学習などにも取り組めるようにしていく”、とサービスの概要と抱負を語る。

そのプロダクトには複数のコンテンツ・デリバリ・ネットワーク(CDN)が含まれ、Haugeは、ビデオのデリバリのスピードと料金ではAkamaiやCloudFrontなどとも十分競合できる、と言う。

でも、VimeoやBrightcove、Kalturaのようなプラットホームが今やたくさんあるから、それらを利用する方が簡単では？

“たしかに既存のビデオプラットホームはストレージとトランスコードと配布は面倒見てくれる”、とHaugeも認める。しかしアプリケーションが必要とするビデオ機能が、それだけでは済まない場合も多い。“たとえば彼らには、十分なカスタマイズの機能がない。データ構造にも柔軟性がない。標準的なワークフローと限定的なAPIを提供しているだけだ”。

“Synqは逆に、デベロッパーがやりたいことをあくまでも優先する。だからうちのAPIなら、プログラマブルなクェリやWebhookも実装できる”。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa））

顔に絵を描きたい？　電話会議でピンポンする？　でもそんなアプリケーションはもう書けない。Googleが今日ひっそりと、HangoutsのAPIを閉鎖することを明かしたのだ。もう新しいアプリケーションを作ることはできないし、既存のアプリケーションは4月25日をもって、使えなくなる。それはGoogleのブログで発表されたのではなく、FAQのアップデートと、そのAPIを使っているデベロッパーへのメールによる通知で知らされた。本誌はデベロッパーの一人から、その話を聞いた。

このAPIでできることは、自撮り写真（セルフィー）に拡張現実(AR)でマスクをつけたり、あるいはScoot & Doodleアプリのようにポーリングや共同お絵かきをやること、などだ。でもGoogleが消費者向けビデオチャットにはDuoを推し、Hangoutsをエンタープライズ向けと位置づけたため、デベロッパーがいろんなことをできる自由度もなくなった。

メールはこう述べている:

“弊社のさらなる合理化努力の一環として、Google+ HangoutsのAPIを撤収し、今後デベロッパーは、Hangoutsを利用するビデオ会議を実装できなくなります。最初このAPIは、Google+の一部として、消費者向けソーシャル機能のサポートを意図していましたが、今ではHangoutsはエンタープライズのユースケースがメインになりつつあります。

弊社のプラットホームに開発努力を投資されたデベロッパーのみなさまにご迷惑をおかけすることは、十分理解しております。この変更については、慎重に検討いたしました。そして今回の措置によって、よりターゲットの絞られたHangoutsデスクトップビデオ体験を、今後ユーザーにご提供できるものと信じております。”

〔“よりターゲットの絞られた”とは、企業用、ということ。〕

FAQによると、例外として残るAPIは、DialPadやRingCentralからHangoutにダイヤルできる能力、Slackなどのエンタープライズチャットツールとの統合、そしてGoogle自身のHangouts on Airのツール(Toolbox, Control Room, Cameraman)だ。

Google Hangouts APIは、メッセージングアプリに関するGoogleの方針に一貫性がなかったことと、Hangoutsそのものをほったらかしにしていたことの、犠牲者だ。それは初めての完全なビデオチャットアプリのひとつであり、Snapchatがティーンの人気をさらったARによるセルフィーマスクも、Hangoutsが元祖だ。でも次々と、ばらばらに立ち上げるメッセージングアプリはすべてサイロ（silo, 孤立・閉鎖系）と化し、お互いの会話の行き来もできず、かくしてHangoutsが提供するGoogle+のソーシャルレイヤ（ソーシャル層）は、忘れられた存在になった。

こんどAPIが閉鎖されたことによって、それは、企業向けのビデオつき電話会議にすぎないものへと、さらに一歩近づいた。それはGoogleにとっては“合理化”かもしれないが、ユーザーはますます、Hangoutsに見向きもしなくなるだろう。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa））

Twilioが四半期決算報告で、スウェーデンのSMSメッセージングサービスBeepsendを買収した、と発表している。買収の目的は、Twilioのグローバル複数キャリア接続サービス/API、Twilio Super Networkの機能拡充のためだ。

買収の価額等は、公表されていない。

Beepsendの基本コンセプトは、“テキストメッセージはどれも同じではない”だ。そこでSMSメッセージのトラフィックを複数のセグメントに分割し、それらをプライオリティで分類することによって、費用効率を高める。たとえばテキストによるアラートは即対応を要するが、それほど時間条件が厳しくないトラフィックもある。そうやってメッセージの要求タイプを分類できることは、Twilioにとっても通信を効率化し、同社プラットホームの費用効率を上げることにつながる。

6月にTwilioのCEO Jeff Lawsonは、AmazonのAmazon Simple Notification ServiceによるSMSメッセージングは、Twilioが支えている、と発表した。つまりAmazonも、TwilioのメッセージングAPIのユーザーなのだ。

同社のブログ記事で、プロダクト担当のディレクターBenjamin Steinが、BeepsendのチームはTwilioに加わり、Twilioのプラットホーム上で、“SMSメッセージングトラフィックのセグメンテーションやルートモニタリング、アナリティクス”などの機能を強化していく、と述べている。

この買収によってわれわれは、われわれのネットワークリーチの幅と深さの両方を拡大し、顧客のメッセージングニーズにさらに多くのデリバリオプションを提供していく。さらにまた、これによって、グローバルな通信ネットワーク〔Twilio Super Network〕に、さらなる冗長性と強靭な自己回復力が加わる。この買収は、Twilioが毎日のように、顧客のための改良改善を継続していることの、ほんの一例にすぎない。

Beepsendの40名の社員はそのまま残り、会社そのものも従来どおり操業を続ける、とVentureBeatは報じている。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa））

デベロッパーが自分のアプリケーションに利用できるAPIのプロバイダ、支払い決済ならStripeがあり、アナリティクス（アクセス分析）ならMixpanel、通信ならTwilioがある。でも、位置はどうだろう？

大丈夫。これからはRadarがある。

RadarのファウンダーNick PatrickとCoby BermanはともにFoursquare出身で、彼らは、人びとがFoursquareを必要としている以上に、いろんなアプリケーションが位置サービスを必要としていることを悟った。もちろんそれを、各デベロッパーがゼロから実装するのはたいへんすぎる。

Patrickは、お掃除のオンデマンドサービスHandyにいたときに、同社のお掃除スタッフが今どこにいるか、顧客に分かるようにいしたい、と思った。そういうバックエンドサービスがあれば実装は簡単なのだが、意外と、そんなAPIプロバイダがなかった。

そこでPatrickとBermanはRadar社を作り、そして同社は今日、インキュベータのExpa Labsを巣立った。

Radarのユーザーとなったデベロッパーは、Radar SDKを簡単に統合して、ジオフェンス（仮想領域機能）や、場所への出・入りイベントの追跡など、位置関連の機能を実装できる。そして最終的には、彼/彼女のアプリケーションに位置機能があることによって、エンドユーザーの体験をより快適にできる。

Patrickによると、デベロッパーはRadarを使うことによって三つのプラスを手に入れる: ユーザーエンゲージメントの増加、売上〜収益の増加、そしてアプリケーションの操作性の向上。

たとえばTinderに位置機能があれば、お互い意気投合した同士が、相手がすぐ近くにいることを分かる。小売店がeコマースの機能を持ったとき、位置機能があれば、お店の近くのお客さん限定の売り出しを企画できる。またHandyやPostmatesのようなオンデマンド・サービスは、位置追跡機能を自分で作らなくても、Radarを統合すれば、サービスマン/ウーマンが今どこにいるかを、待っている顧客にリアルタイムで伝えられる。

“APIを作るときの最大の課題は、ありとあらゆるユースケースを想定して、それらすべてにエレガントに対応できるようにすることだ”、とPatrickは語る。

今日一般公開されたRadarには、試してみたいデベロッパーのための無料プランもある。またエンタープライズ向けのプランには、手取り足取りのサポートがつく。こちらの料金は、APIの使用量で決まる。

Radarに保存される位置データには、その位置の帰属者情報がもちろんつくが、前者と後者は物理的には別の場所にある。両者の対応関係は、ハッカーには分からない。したがって個人情報や企業の機密情報などが外部に漏れるおそれがない。

Radarは巣立ちにあたってExpa Labsから50万ドルの支度金をもらった。

Radarをここでチェックしてみよう。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa））

【抄訳】
音声による人工知能は、売上増や顧客体験の向上に寄与すると分かっていても、そのセットアップは容易ではない。そんな状況を変えようとするVoysisは、自然言語の入力を解析するAIプラットホームを提供し、eコマースやエンターテインメントなどさまざまな専門分野で効果的に音声入力を利用できるようにする。Voysis自身がSiriやAlexaになるのではなく、デベロッパーがユーザー企業のお店の優秀なアシスタントや、ビデオ店の頭の良い販売員を作る手助けをするのだ。

VoysisのファウンダーでCEOのPeter Cahillは次のように語る: “Voysisは完全な音声AIのプラットホーム〔それを構築するためのプラットホーム〕だ。それを利用すれば、企業やそのさまざまな事業部門が、顧客が音声やテキストでクェリできる独自の人工知能を、迅速に立ち上げることができる”。

つまり同社が目指すのは、浅くて汎用的な音声アシスタントではなくて、ユーザーが属する業界のドメインスペシフィックな（その分野固有の）知識を持った音声AIプラットホームだ。ユーザー企業やデベロッパーはそれを、同社が提供するAPIから利用し、セットアップ時間の短縮を図れる。音声AIを、ユーザー企業がそれをわざわざ訓練しなくても、単純に短時間でセットアップできることを、同社はあくまでも目指している。最初はとくに、eコマースの顧客対応インタフェイスの提供を目指しているが、今後はいろいろな業界や業態の業務知識や音声応答パターンを集積していくつもりだ。

【中略】

IBMのWatsonなどもドメインスペシフィックなAIを提供しようとしているが、PhDのCahillには大学の研究室でニューラルネットワークや音声認識と深くつき合った15年の履歴がある。Voysisは今回、 Polaris PartnersがリードするシリーズAのラウンドで800万ドルを調達したが、その主な用途は技術チームの増員（15名から倍の30名へ）と、ボストン支社の開設だ。ユーザー企業にとって、AIの訓練を自分でやらなくてよい、という敷居の低さも、Cahillの長年のAIに関するキャリアと相まって、同社の魅力になるだろう。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa））

より速く、より透明性の高い、オンデマンド配送の活用を目指すスタートアップの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）

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））

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）

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））

今日（米国時間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））

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

でも、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））

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））

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は、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）

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）

リスボンに本社を置く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のスイート、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）

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

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

• 赤坂優氏（エウレカ 共同創業者／エンジェル投資家）
• 石黒卓弥氏（メルカリ HRグループ）
• 小澤政生氏（サイバーエージェント採用責任者）
• 河合聡一郎氏（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は現在、クローズドベータの形で数社に公開され、試用が始まっているとのこと。登録企業全体に公開されるのは、今春の予定だ。