iOS 13.5へのアップデートで新型コロナ接触通知設定が利用可能に

Apple(アップル)は、Google(グーグル)と共同で開発した「接触通知API」のサポートを含むiOS 13.5をリリースした。新型コロナウイルスの感染拡大と戦う公衆衛生機関による接触の追跡をサポートする。このAPIを利用するには、公衆衛生機関が開発するサードパーティアプリが必要となる。アプリは、まだ1つもリリースされていないが、iOSデバイスのユーザーは、すでに「COVID-19接触のログ記録」という設定にアクセスできるようになっている。

ベータ版でも確認されていたように、接触記録の設定にアクセスするには「設定」アプリを使う。まず「プライバシー」セクションを開き、そこから「ヘルスケア」のサブメニューを選ぶと「COVID-19接触のログ記録」という設定が出てくる。これはデフォルトではオフになっている。承認済みのアプリを入手してインストールするまで、この機能をオンにすることはできない。そうしたアプリを利用する場合には、接触通知へのアクセスを承認するよう求めるポップアップが表示される。いったん承認しても、ここに戻れば通知機能をオフに切り替えることも可能だ。また、オプトアウトを選択した場合には、デバイスに記録されたの接触ログを手動で削除することもできる。

アップルとグーグルは、接触通知APIに対して、ユーザーによってコントロール可能な部分をできるだけ多くし、可視性を高めたいと考えていることを強調してきた。接触通知を実現するために、ランダムに生成した一時的なIDを使用し、それもサーバー側には保存しない。また、1つのアプリ内で位置情報サービスと接触通知APIを同時に使用することも禁止している。このように接触記録機能を手動でオンオフできるようにしたことは、このシステムに参加するユーザーが、どのような情報を、いつ共有するかということを、完全にコントロールできるようにするための1つの重要なステップとなる。

接触を追跡することは、感染症の蔓延と戦うための実績のある戦略だ。これまでは、感染した個人から聞き取ったり、感染期間の行動をできるだけ詳しく調査することで、潜在的な接触を追跡しようとしてきた。通信機能を備えた近年のデバイスを利用することで、こうしたことをずっと効率的かつ正確にできる可能性が生まれた。それでもグーグルとアップルは、プライバシーの専門家と協力し、ユーザーのプライバシーをリスクにさらすことなく、こうしたことを実現する手段を見つけ出そうとしてきた。その結果、照合処理も、サーバー側のデータベースではなく、ユーザーのデバイスでローカルに実行するものとなっている。

アップルとグーグルは、このAPIを利用するアプリを開発中の公衆衛生機関に協力している。また両社は、これはあくまでも暫定的な措置であって、いったん新型コロナウイルスの脅威が去れば、この機能自体を無効にするという前提で、最初から設計していることを明らかにしている。

新型コロナウイルス 関連アップデート

原文へ

(翻訳:Fumihiko Shibata)

アップルとグーグルが新型コロナ感染警告向け通知APIのベータ版をリリース

新型コロナウイルス(COVID-19)の流行の抑制に取り組んでいるApple(アップル)とGoogle(グーグル)は共同で、感染者との接触をモニタするアプリを開発している。両社が感染追跡APIと呼んでいた感染リスク通知APIの最初のバージョンがリリースされた。これはデベロッパー向けAPIのシード版であり、フィードバックを得るのが主たる目的だという。公衆衛生機関と契約して感染者との接触を追跡しリスクがある人々にこれを通知するアプリを開発するデベロッパーが対象だ。

先週、アップルのCEOであるTim Cook(ティム・クック)氏はEU委員会のThierry Breton(ティエリー・ブルトン)氏に「APIはまもなくリリースされる」と述べている。これが事実リリースされたわけだ。ただし、現在利用できるのは「世界中の公衆衛生当局の依頼を受けてアプリを開発しているデベロッパー」だと両社は述べている。

シード版という意味は、5月中旬に一般に公開されるAPIに先駆け、デベロッパーから利用上の問題点などのフィードバックを得ることを目的としたテストだという。正式に公開されれば、デベロッパーはAPIを利用したアプリを開発してiOSとGoogleのストアから公開できる。

両社は「今週の金曜にAPIのリリースに関する詳細を発表する」と述べた。ここでサンプルコードに加えて実際にどのように作動するのかがが明らかにされるようだ。両社は一般公開された時点でマニュアルなどのドキュメンテーションのアップデート版も提供する。またテスト期間中、アクセスできるデベロッパーを随時追加する。ただし両社はAPIへのアクセスを公衆衛生当局のために活動するデベロッパーに限定している。

両社はデベロッパー向けサイトでスペックの詳細を記述した文書を公開しており、機能の改良についてのアップデートもすで行われている。先週の電話記者会見でも述べられていたが、ユーザーのプライバシー保護と利用の容易さには特に重点が置かれ、デベロッパーがこれをアプリ内で実装する方法に特に努力が払われた。

最新版では、公衆衛生当局がそれぞれの実情に基づいて独自の基準を作成しユーザーの感染リスクを判定できる機能が追加された。変数には新型コロナウイルス感染確認者と接触した距離や時間の長さなどが含まれる。デベロッパーはどのレベルのリスクがあった場合にユーザーに警告を通知するか容易にカスタマイズすることができる。

ベータアップデートでは、下のスクリーンショットにあるように、ユーザーが個々のアプリの新型コロナウイルスの感染警告の通知の有効、無効を簡単にトグルできる機能が追加されている。

両社は4月10日にAPIと、最終的には、OSレベルに感染リスク追跡機能を組み込むアプリを共同開発していることを発表した。APIの一般公開は5月中旬、その後数カ月の間にOSレベルでへの統合を行う予定だ。 このテクノロジーはプライバシー保護に留意してデザインされている。特定個人が識別されることがないよう、ランダムに生成したユーザーIDが割り当てられ、2週間で破棄されて新しいIDが付与されるという。

画像:Bryce Durbin/TechCrunch
新型コロナウイルス 関連アップデート
原文へ

(翻訳:滑川海彦@Facebook

DevOpsのためのモニタリングと試験プラットフォームのChecklyがシードで2.4億円相当を調達

DevOpsチームのためのモニタリングと試験のプラットホームを開発しているベルリンのChecklyが米国時間4月28日、Accelがリードしたシードラウンドで225万ドル(約2億4000万円)を調達したことを発表した。エンジェル投資家でInstanaのCEOであるMirko Novakovic(ミルコ・ノバコビッチ)氏やZeitのCEOであるGuillermo Rauch(ギジェルモ・ラウフ)氏、Twilioの元CTOであるOtt Kaukver(オット・カウクバー)氏らも、この投資に参加した。

同社のSaaSプラットホームを利用することでデベロッパーは、彼らのAPIエンドポイントとウェブアプリケーションをモニタし、異変の警告を受けることができる。そのトランザクションモニタリングツールを使えば、フロントエンドのウェブサイトの試験を定期的に繰り返し行うことが容易になり、コードは一行も書く必要がない。この試験ソフトウェアはGoogleのオープンソースのPuppeteerフレームワークを使っており、そしてその商用のプラットフォームを開発するためにChecklyはさらに、Puppeteer Recorderというものを開発して、エンドツーエンドの試験スクリプトをローコードツールの中に作り込んでいる。デベロッパーはそれに、Chromeのエクステンションからアクセスする。

モニタリングツールの市場は混み合っているが、Checklyのチームはエンドツーエンドの試験とアクティブモニタリングの組み合わせ、およびモダンなDevOpsチームへのフォーカスが自分たちの強みだと考えている。

創業者のTim Nolet(ティム・ノレット)氏は 「モニタリングの市場の1人の顧客として、それらのツールは90年代にずっと行き詰まりになっていて、チームをJavaScriptでサポートし、DevOpsのチームの中のいろんな役割で使えるツールが必要だと感じていた。自分で作り始めてみてすぐに気づいたのは、モニタリングと同様に試験も重要だということだ。Checklyで開発したのは、顧客が以前からずっと求めていたような新しいタイプのツールだ。評価は口コミですでに相当広がっている。DevOpsのチームに信頼されるプラットフォームというビジョンの今後の構築に向けて、Accelをパートナーにできたことは非常にうれしい」と語っている。

Noletの共同創業者は、TestObject(後にSauce Labsが買収)を創ったHannes Lenke(ハネス・レンケ)氏と、Saucd LabsのEMEA担当営業部長だったTimo Euteneuer(ティモ・オイチューニア)氏だ。

同社によると現在の顧客は約125社で、同社のプラットフォーム上で1日に100万回のチェックを行なっているとのこと。料金は個人デベロッパーなら月額7ドル(約750円)から、小さなチームのためのプランは月額29ドル(約3090円)となっている。

[原文へ]

(翻訳:iwatani、a.k.a. hiwa

SaaSアプリケーションとAWSサービスをデータフローで統合するAmazon AppFlowがローンチ

AWSが今日(米国時間4/22)、Amazon AppFlowローンチした。それはAWSとGoogle AnalyticsやMarketo、Salesforce、ServiceNow、Slack、Snowflake、ZendeskなどなどSaaSアプリケーションとの間の、データの移送を容易にするサービスだ。同様のサービスとしてMicrosoft AzureのPower Automateなどがあり、いずれも何らかのイベントをトリガーとして、一定の時間に、またはオンデマンドでデータの伝送を開始する。

しかし競合製品とやや違ってAWSはこのサービスを、ワークフローを自動化する方法としてよりもむしろ、データ伝送サービスと位置づけている。そしてデータフローは双方向が可能だが、AWSの発表は主に、SaaSアプリケーションからそのほかのAWSサービスにデータを送ってさらに分析する、という使い方にフォーカスしている。そのためにAppFlowには、伝送時にデータを変換するさまざまなツールがある。

AWSの主席アドボケイト(advocate, 製品推奨係)Martin Beeby氏が、今日の発表で次のように述べている: 「デベロッパーはSaaSアプリケーションとAWSのサービスの間でデータを受け渡して分析するために、大量の時間を費やして両者の統合のためのコードを書いている。それはとても高くつく仕事であり、数か月かかることもある。データの要求が変われば、そうやって書いた統合に、さらに高くつく複雑な変更を加えなければならない。技術的リソースが十分にない企業は、アプリケーションのデータを手作業でインポートしエクスポートしているかもしれない。それもまた時間がかかるし、データ遺漏のリスクがあり、人的エラーも入り込む」。

データのフローは、ソースのアプリケーションを呼び出してデスティネーションのAWSサービスに送る場合、AppFlowの料金体系では1フローにつき0.001ドルだ。しかし通常のAWSの使い方では、データ処理のコストもある。それは、1GBあたり0.02ドルからだ。

AWSの副社長Kurt Kufeld氏は次のように言う: 「弊社の顧客は、データの保存や処理や分析はAWSでやりたい、と言う。彼らはまた、サードパーティのさまざまなSaaSアプリケーションも使っていて、AWSとそれらのアプリケーション間のデータフローを管理するのが難しい、とも言っている。Amazon AppFlowは、AWSとSaaSアプリケーションのデータを、オープンで公共的ネットワークであるインターネット上で移動せずに、直感的なわかりやすいやり方で結びつける。Amazon AppFlowを使えば、企業のすべてのアプリケーションに散在する数ペタバイト、ときには数エクサバイトものデータをAWSに持ち込むことができ、しかもそのためにカスタムのコネクターを開発したり、APIとネットワークの接続性を管理する必要もない」。

サポートされているサービスはまだ比較的少なく、ソースが14、デスティネーションが4(Amazon RedshiftとS3、Salesforce、Snowflake)だ。デスティネーションとして、AmazonのストレージサービスS3しかサポートされていないソースもある。

もちろん、統合の数は今後増えるだろうが、今のところはサポートされるサービスがもっと多くなることを、AppFlowのチームの努力に期待したい。

AWSは長年、この市場を競合他社に譲ってきたが、しかしそれでも、AWSの複数のサービス間のサーバーレスのワークフローを作るツールAWS Step Functionsや、複数のアプリケーションをこれもサーバーレスで接続するEventBridgeなどがある。サポートされているサードパーティのソースは、今のところEventBridgeの方が多い。でも名前にEventがあるように、これはAWSでイベントをトリガーすることが主で、アプリケーション間のデータ伝送がメインではない。

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

AppleとGoogleが新型コロナ感染チェック用モバイルアプリを共同開発、プライバシー保護も確約

AppleとGoogleは協力して個人が新型コロナウイルス(COVID-19)の感染リスクにさらされたかどうかをチェックできる分散型モニターツールを開発中だ。

濃厚接触を知らせるツールは、公衆衛生当局が新型コロナウイルスの感染を追跡し、人々に感染のリスクがあることを知らせて検査を受けるよう推奨することに役立つ。このアプリはBluetoothテクノロジーを利用し、新型コロナ感染者との接触を発見し、適切なフォローアップを送信する。

プロジェクトの最初のステップは、公衆衛生機関がそれぞれのアプリにこのツールを組み込むAPI の開発だ。次のステップではモバイルデバイスのOS、すわなちiOSおよびAndroid のレベルに機能を組み込み、ユーザーがオプトインするだけで別のアプリをインストールせずに接触追跡が可能がシステムが開発される。

このシステムは、デバイスに搭載されたBluetoothチップを使用し、短時間で変化する匿名化されたIDを発信する。 サーバーは過去14日間のIDについて他のデバイスのIDとの一致の有無を検索する。一致は2つのデバイス間の接触時間および距離をしきい値として判断を行う。

新型コロナウイルスに感染していたことが確認されたユーザーとの接触があったと判断された場合、ユーザーには「感染テストを受け、その間自主隔離を行う」よう通知される。

位置情報を利用した接触追跡はプライバシーの侵害の懸念をめぐって議論を呼び起こしているものの、多数の公衆衛生機関や大学の研究組織が採用しているテクノロジーだ。例えばAppleの「探す(Find My)」にヒントを得たMITのBluetoothツールがそうした例の1つだ。「探す」は従来の「iPhoneを探す」などと異なり、プライバシーを強く意識しており、位置情報を利用した追跡ツールでありながらユーザー以外は個人情報を知りえない。AppleとGoogleはプライバシー問題の困難の解決にあたってMITなどの組織が支援を求めたと述べている。

【略】

開発は2段階

AppleとGoogleは2週間前にこの共同プロジェクトをスタートさせた。まずAPIの互換性を確保し、できるかぎり多数のユーザーが同一のアプリを利用できるようにするのが最初の目標だ。

4月10日の説明によれば、ユーザー同士の接近をモニターするAPIは5月中旬にiOSとAndroidに導入される予定だ。AppleとGoogleによれば、これは比較的シンプルなタスクで、既存または開発中のアプリに組み込むことも比較的簡単なはずだとと述べている。APIを使う場合、アプリはユーザーに対して位置の追跡機能にオプトインするよう求める(このシステムは全体としてオプトインベースだ)。これによりデバイスに付与される短時間で変化する匿名の識別子をBluetooth機能を利用してブロードキャストする。同種のアプリをインストールしているユーザーはこのブロードキャストを受信し、これによって、誰とどのような接触があったかが特定可能となる。

プロジェクトの次の段階は効率のアップだ。つまり位置追跡機能をモバイルOSそのものに組み込むことにより、個別アプリをダウンロードする必要をなくすのが目標となる。ユーザーはOSから機能にオプトインすればよい。第1段階の感染警告アプリも引き続きサポートされるが、OSへの組み込みはさらに広範囲のユーザーに対応できる。このレベルは数カ月以内に実現できるという。

【略】

アプリの動作例

このシステムがどのように動作するのか、ひとつの例を図示してみよう。

  1. アプリのユーザー2人が一定時間、例えば10分間近くにいたとする。ユーザーのデバイスはBluetooth無線により識別子(15分ごとに変化し匿名化されている)を交換する。
  2. その後、ユーザーの1人が新型コロナウイルスに感染していると診断された場合、感染者はAPIを組み込んだ公衆衛生当局のアプリに知らせる。
  3. システムは感染が診断されたユーザーから過去14日間の識別子(匿名)をシステムに送信することを許可するよう追加の同意を求めることができる。
  4. 公衆衛生アプリには(同意を得て)感染者の識別子をダウンロードすることができ、アプリは感染リスクを伴う接触があったかどうか判断する。
  5. 接触があったと判定された場合、アプリはユーザーに今後どうすべきかさらに情報を提供する。

プライバシーと透明性

Apple、Googleはともに「プライバシーと透明性が公衆衛生アプリにおいて最重要」だと述べ、 リリースされるアプリは今後とも決してプライバシーを侵害しないと確約している。この点は、以前からACLU(米国自由人権協会)が提起してきた問題だ。

【略】

しかしACLUはこのアプリに対しては慎重ながら楽観的な見方をしている。

ACLUの監視、サイバーセキュリティ担当弁護士、Jennifer Granick(ジェニファー・グラニック)氏は次のようにコメントしている。

「位置情報を利用するこの種の追跡アプリは無料かつ迅速な検査と各種医療への公平なアクセスが広く保証されないかぎり効果がない。 またユーザーがシステム(の匿名性)を信頼できなければやはり効果的ではない。AppleとGoogleが、プライバシーの悪質な侵害と中央集権化のリスクを軽減するであろうアプローチを発表したことは事実だ。 しかしまだ改善の余地がある。位置追跡アプリがオプトインであり匿名性を確保した分散型であることを確認するため我々は今後も厳しく監視を続ける。このような機能は現在のパンデミックの期間に限り、公衆衛生の確保の目的でのみ使用されるべきだ」。

【略】

感染チェックのためのはAPIについて、Googleの ブログ記事はこちら 、Appleのスペックなどへのリンクはこちら日本語版解説はこちら)。

ACLUからのコメントによりアップデート済み。

新型コロナウイルス 関連アップデート

原文へ

(翻訳:滑川海彦@Facebook

不況を生き延びたいならプラットフォームフォーマーを目指せ!

世界で最も成功している企業たちを眺めてみると、それらは皆1つの単純なサービスではない。その代わりに、彼らは様々なサービスを持つプラットフォームを提供しており、外部のパートナーや開発者が、それに接続して、提供されているベース機能を拡張できるようにしている。

プラットフォームを目指すことと、実際にプラットフォームの構築に成功することは同じではない。すべてのスタートアップは、おそらく最終的にはプラットフォームとして振る舞いたいと思っているだろうが、実際それを実現することは困難だ。しかし、もしあなたが成功して、提供する一連のサービスが誰かのビジネスワークフローの不可欠な一部となったとしたら、あなたの会社は、最も楽観的な創業者でさえも想像できなかったほどに大きくなり、成功する可能性がある。

Microsoft(マイクロソフト)、Oracle(オラクル)、Facebook(フェイスブック)、Google(グーグル)、そして Amazon(アマゾン)を見て欲しい。どれもみな、リッチで複雑なサービスプラットフォームを提供している。それらはみな、例えサードパーティが宣伝のためにその会社の人気を利用するにしても、サードパーティがプラグインしてプラットフォームのサービスを使う方法を提供する。

The Business of Platforms』(プラットフォームのビジネス)という本を書いたMichael A. Cusumano(マイケル・A・クスマノ)氏、David B. Yoffie(デビッド・B・ヨフィー)氏、そしてAnnabelle Gawer(アナベル・ガワー)氏たちは、MIT Sloan Reviewに「The Future of Platforms(プラットフォームの未来)」という記事を書いた。その中で彼らは単にプラットフォームになるだけではスタートアップの成功は約束されていないと述べている。

「すべての企業と同様に、プラットフォームは最終的に競合他社よりも優れたパフォーマンスを発揮する必要があるためです。さらに、プラットフォームを長期的に存続させるには、政治的および社会的にタフである必要があります。そうでない場合には、プラットフォームは政府の規制や社会的反対運動、および発生する可能性のある大規模な債務によって押しつぶされるリスクがあるのです」と彼らは記している。

つまり、成功するプラットフォームを構築するのは安上がりでも簡単でもないが、成功したときに得られる報酬は莫大だということだ。クスマノ、ヨフィそしてガワーらは彼らの研究が次のことを見出したと指摘している。「……プラットフォーム企業は、(成功した非プラットフォーム企業の)半分の従業員数で同じ売上を達成しています。さらに従来の競合相手よりも、プラットフォーム企業の利益率は2倍、成長速度も2倍そして2倍以上の価値を達成しています」。

企業の観点から、Salesforceのような企業を見てみよう。同社は(特に初期の段階の)比較的少数のエンジニアチームでは、顧客の要求に応じたすべてのサービスを構築することが不可能であることを、ずっと以前から知っていた。

最終的にSalesforceはAPIを開発し、次に一連の開発ツール全体を開発し、API上に構築されるアドオンを共有するための市場を開設した。FinancialForce、VlocityそしてVeevaのような、Salesforceが提供するサービス上で企業全体を構築するスタートアップも存在している。

2014年にBoxWorksのベンチャーキャピタリストのパネルディスカッションで講演した、Scale Venture PartnersのパートナーであるRory O’Driscoll(ロリー・オドリスコル)氏は、多くのスタートアップがプラットフォームを目指しているが、それは傍目で見るよりも難しいと語っている。「狙ってプラットフォームを作れるわけではありません。サードパーティの開発者が関与してくるのは、十分なユーザー数を獲得した場合のみです。そのためには何か他のことをしなければならず、それからプラットフォームになる必要があるのです。プラットフォームとして最初から完成形で登場できるわけではありません」と彼はそのときに語っている。

もし深刻な経済危機の最中にそのような会社を設立する方法を考えているなら、Microsoftが不況の真っ只中である1975年に立ち上げられたことを考えて欲しい。GoogleとSalesforceはどちらも、ドットコムクラッシュの直前の1990年代後半に起業し、Facebookは2008年の大不況の4年前となる2008年に開始した。すべてが途方もなく成功した企業になった。

こうした成功には多くの場合、莫大な支出と販売とマーケティングへの取り組みが必要だが、成功した場合の見返りは莫大なものだ。成功への道が簡単であることを期待してはいけない。

関連記事:How Salesforce paved the way for the SaaS platform approach(未訳)

画像クレジット:Jon Feingersh Photography Inc/Getty Images

原文へ

(翻訳:sako)

アプリ内チャット提供のSendBirdがアップデート、モデレーションや全文検索など新機能追加

アプリにチャット機能を提供しているSendBirdがウェブ版、モバイル版の双方でメジャーアップデートを発表した。これには新しいAPIやサービスの新機能が多数含まれる。ユーザーがニーズに合わせてカスタム管理ツールを構築するのが簡単になった。またチャットに対するリアクションや配送確認などを追加する機能も改善された。

SendBirdは韓国のソウルで設立されたスタートアップで、現在世界で9000万人のアクティブユーザーにサービスを提供し、月間約15億のメッセージを処理しているという。SendBird CEOであるJohn Kim(ジョン・キム)氏は、インタビューに対して「我々のサービスはオンデマンドアプリに強く、この分野のユーザーにはGojek、iFood、Delivery Heroなどがある。またCarousell、Paytm、Traveoka、SSGなどのマーケットプレイス、Reddit、Dream 11、(US)Yahoo Fantasy Sportsなどのコミュニティサイト上のビジネスにも適している」と述べた。(情報開示:US Yahooの親会社はTechCrunchと同じくVerizon Media Group)。

またキム氏は「最近は、ヘルスケア分野での医療サービスの提供者と対象者間のチャットや福利厚生ビジネスでのチャットで大きく成長している。ユーザーはデジタルファーストのサービスに多く、Accolde、Livongo、Grand Roundsなどが利用している。 ゲーム、デート、ライブストリーミングの分野にも顧客が多い」と述べた。

今日のアップデートでは、特にサービスのモデレート機能の強化に力を入れているという。画像のモデレートでは不適切な画像を削除できる。また特定の単語を指定してそれらを含むメッセージが出ないようカスタマイズできるRegExフィルターも提供される。新しいGDPR(一般データ保護規則)に準拠したAPIやモデレーションAPIが提供されるため、ユーザーは自社でカスタマイズした機能を組み込んでアプリのオプションを拡張できる。

また何らかの理由でサービスが中断されたときにメッセージをローカルにキャッシュするオフライン同期機能、メッセージの機械翻訳を強化するオンデマンド翻訳機能、プッシュ通知を翻訳する機能も追加された。

機械翻訳への注力には理由がある。SendBirdのユーザーベースはグローバルであり、以前からアジア太平洋地域では強みがあった。しかしキム氏によれば(機械翻訳機能の強化は)ユーザーベースがアジア太平洋地域に加えて、アメリカ、ヨーロッパ、中東、アフリカにも急速に拡大していることに対処するものだという。

もっともユーザーにとっての最も大きな変化は、ユーザーがメッセージにリアクションを追加できるようになったことだろう。これによりSendBirdのサービスはスマートフォンを利用する他のメッセージアプリの機能に追いついた。また配送確認と全文検索機能も追加されている。

インタビューで「なぜアプリ内チャット市場が離陸しつつあると考えたのか?」と質問すると、キム氏は次のように答えた。

「結局、電話やファックスもチャット、メッセージのテクノロジーだった。インターネットで最初に人気を得た使い方もチャットルーム、IRC、ICQなどだった。デスクトップ時代にチャットはモデムへのアクセスが必要だったため、利用は固定回線がある場所に制限されていた。しかしモバイル時代になり3G/4GネットワークとWi-Fiへのアクセスが手軽になると、チャットが民主的なメッセージングサービスとしてグローバルに普及した。スマートフォンが(中国やインドなど)人口の多い国に普及し、こうした地域ではデスクトップのテクノロジーを飛び越してモバイルチャットの時代となった」

キム氏は、チャットの分野はネットワーク効果で市場がごく少数(WhatsApp、WeChat、Facebook Messengerなど)のサービスに集中し、すべてがよく似たものになってきたと考えている。つまりユーザーは、メジャープレイヤーのチャットと同様の機能を備えているサービスでなければ日常利用しようとしない。

「モバイルアプリの提供者はこうしたトレンドに追いつき、チャットという新しい標準的機能をアプリに追加する必要がある。しかしほとんどのアプリ提供者にはこれを実現して競争に役立てる能力やノウハウがない。そこでチャットAPIにニーズが強く集まることになる」とキム氏は述べた。

[原文へ]

滑川海彦@Facebook

Googleクラウドに小売業向けに特化した新サービス

Googleは小売業向けの大規模なカンファレンス、NRF 2020でeコマース市場向けのプロダクトを発表した。Googlクラウドプラットフォームはヘルスケアやライフサイエンス、製造業、金融サービス、エネルギー産業など各種のバーティカルな分野に特化したプロダクトに力を入れてきた。

AWSのライバルとしては当然だが、以前から小売業もこうしたターゲットの1つだった。現在、Googleクラウドの小売業のカスタマーにはアパレルチェーンのKohl’s、DIYやリフォームのLowe’s、フランスのスーパーであるカルフールなどがある。

今回、Apigee APIプラットフォームを利用した小売業向けAPIであるAPI Management for RetailやAnthos for Retailといった既存プロダクトに対する新機能の追加などのアップデートなどが発表された。Anthos for RetailはAnthosプラットフォームを利用してストアの運営やロジスティクスの効率化、現代化を図ろうとする企業をターゲットにしている。またGoogle検索をベースにしたリテール向け検索プラットフォームであるSearch for Retailは、通販アプリに組み込むことによりユーザーの製品検索ヒット率を大きく向上させるという。

さらに Googleはまた新たな顧客を獲得するためにRetail Accelerationプログラムなどをスタートさせた。これは例の入念な信頼性確保のプラットフォーム、Customer Reliability Engineeringサービスに基づくものだ。ショッピングは特定の日に集中する傾向があるが、このサービスはピーク時を予測し企業側で事前に対処することを可能とすると同時にオンライン処理の負荷を分散してダウンを防ぐ。

ただし最も興味深いプロダクトはGoogle Cloud 1:1 Engagement for Retailだろう。Googleはこのプロダクトは「多額の初期投資を必要とせず、効率的なデータ駆動型オンラインショッピングを構築するための設計図でありベストユースケース集」だとしている。その狙いは小売企業を助けることだ。Googleのビッグデータプラットフォームを利用して、小売企業が顧客をより深く理解しエンゲージメントするために、顧客からのニーズを理解するためにパーソナライズされ、レコメンドされたオンラインショッピング・サービスを作成する手助けをすることだ。

また、ショッピングニーズの事前予測により仕入れの最適化を図り、通販企業のロジスティクスを改善する機能も新しく発表された。

今回、重点が置かれたのリテール向けサービスだが、これが成功すれば他のバーティカルにも同様のソリューションが導入されるはずだ。われわれはGoogleがクラウドビジネスでも数年以内にAWSに次ぐナンバー2の地位を得ること目指して注力していると考えている。そのためには大企業、特にまだクラウド戦略を確立していない通販企業をユーザーとして獲得することが強く求められるだろう。

画像:Getty Images

原文へ

滑川海彦@Facebook

Visaが5800億円でPlaid買収、最終的な評価額は倍に

Visa(ビザ)は米国時間1月13日、金融サービスAPIスタートアップであるPlaid(プレイド)を53億ドル(約5800億円)で買収すると発表した。

Plaidは金融サービスAPIを開発している。Stripe(ストライプ)が支払いのために提供しているサービスと似ているが、こちらのサービスは支払いを容易にする代わりに、開発者が銀行やその他の金融情報をより簡単に共有できるようにする。Visaのような会社にとっては意味のあるサービスだ。

このスタートアップは、銀行業務だけでなくより広範な金融サービスと投資に移行するために、2年前にQuovoを買収している。もともとのアイデアは、金融サービスプロバイダーたちに対して、より包括的なプラットフォームを提供することだった。創業者たちは、その買収時にブログ記事に以下のように書いている。「これまで様々な金融アプリケーション群が、Plaidを主に当座預金口座と普通預金口座とのやり取りに使用してきました。Quovoを買収することにより、私たちはより幅広いクラスの資産に対して機能を拡張することになります」。

買収は規制当局の承認待ちで、今後3〜6ヵ月で完了する予定だ。

買収価格

今回のPlaidの出口価格は、これまで合計で3億1000万ドル(約341億円)を投じてきた投資家たちにとって大勝利となるものだった。これまでのラウンドで最も重要だったのは、2018年後半に行われた2億5000万ドル(約275億円)の投入だった。IndexKleinerがそのラウンドを主導し、Plaidを26億5000万ドル(約2920億円)、すなわち今回の最終買収価格の50%だと評価していた(この比率が偶然だとは思えない)。

後に明らかになったが、そのときにはMastercardとVisaもラウンドに参加していた。TechCrunchは2019年に、2つのペイメントの巨人たちが「ラウンドに静かに参加した」と報告している。

これらの投資が、Visaに十分な情報取得権を与えられるほど十分な金額だったのかは、はっきりしない。だがクレジットカードの巨人である両社は、投資を行う前に比べて、Plaidが何をしていたかについてより多くの情報を得ている。ともあれ、Plaidは未公開会社として上手くやっているのだと推測することはできる。なにしろ自らのコアビジネスと競合させないために、あるいは主要な競合他社から遠ざけるために買収する場合を除いて、ある企業に対して数十億ドルにも及ぶ評価額のさらに倍額を支払う者はいないからだ。

今回のPlaidは、その両方かもしれない。

Twilioとの比較

Plaidはしばしば、縁の下の力持ちとして活動し、他のプレーヤーのビジネスを支援するAPI提供企業であるTwilioと比較される。アーリーステージにいるNoyoは、ヘルスケア情報と保険のためのAPIで同様のことを行っている。前述のとおり、Stripeは似ているサービスを提供しているが、彼らがカバーするのはペイメントだ。こうしたモデルは、公開会社として急騰したTwilioにとって有利だ。Plaidの巨大なエグジットは、この種のスタートアップにさらなる輝きを与えることだろう。

ただし、Twilioとは異なり、Plaidはまだプライベートな状態で購入されたため、その数字を詳細に見ることができなかった。利益率の高い収益が、この先伸びて行くと予想される。それは公開、未公開を問わず、すべての企業が切望していることだ。

しかしながらVisaは、この取引に対してさらに何かを求めている可能性がある。つまり、現在Visaが事業を展開している世界を再発明しようとする成長率の高い非公開企業たちの視点を、同社は手に入れたということだ。Plaidの買収は、Visaの危機に対する保険であり、またどの企業を買収すれば良いかを知る方法でもある。

しかし現段階においては、この買収はPlaidの株主(や従業員)たちにとっての勝利だ。

原文へ
(翻訳:sako)

Twitterは研究者をより丁重にサポートする戦略

Twitter(ツイッター)は新年に当たって、学術的な研究者が情報にアクセスしたり、APIについてのサポートを得るのが簡単になるよう、専用の新しいハブを用意した。この動きは、研究者コミュニティからのフィードバックに応えるものだと言う。

画像クレジット:Bryce Durbin/TechCrunch

新しいページは、「Twitter data for academic research」(学術的研究のためのTwitterデータ)と呼ばれ、ここからアクセスできる。

そこには、開発者アカウントを申請するページへのリンクが含まれている。開発者アカウントからは、TwitterのAPIへのアクセス、提供されるさまざまなAPIの詳細情報、さらに研究者向けのツールが利用可能となる。ツールには、データの統合とアクセス機能、分析、視覚化、インフラストラクチャとホスティング機能などが含まれる。

「この1年間、私たちは学術的な研究コミュニティの多くの人々と協力してきました。それにより、研究者が直面している課題について学ぶことができました。そして、どうしたらTwitterが研究者をもっとサポートして、この公の場での会話について深く理解することを手助けできるのか、についても学びました」と、Twitterは記している。また、「公の会話からさらに簡単に学べるようにしたい」とも考えているのだという。

さらにTwitterは、今年も、研究者に対して「さらなる機能強化とリソースの提供」を約束している。

2020年は、米国にとって重要な選挙の年であり、新たに選挙に干渉してしまうリスクに対する懸念が高まっていることを考えると、このタイミングでTwitterが学者向けに提供する機能を化粧直ししてきたのもうなずける。

Twitterでの会話の流れを追跡する際には、どうしても「ボットか、そうではないか」という判断を迫られることになる。これは、民主主義の健全性に大きな影響を与えるもの。またヨーロッパでは、Twitterは、他のいくつかの大手プラットフォームと並んで、偽情報に対する自発的な行動規範に2018年に署名した。それにより、偽アカウントやオンラインボットに対処することにコミットしたことになる。さらに、研究コミュニティによるプラットフォームデータへの「プライバシー準拠」アクセスを可能にし、オンラインの偽情報を監視する権限を与えることにもなった。

「Twitterでは、学術的な研究者の貢献を高く評価しています。私たちのプラットフォームをよりよく理解し、何がどうなっているのかを把握し、発見と革新によって新たな課題に取り組むのを助けてくれるだけの潜在能力あると見ています」と、研究者向けの新たなランディングページに記している。また、自らのプラットフォームの価値を持ち上げることも忘れずに、「この世に存在するものは、たいていTwitter上で話題になるものです」とも書いている。

もしTwitterが、研究者と、そのニーズに積極的に関与するという約束を守ることができれば、学術的な利用をサポートすることに失敗しているライバルのFacebookを、うまく出し抜くことができるかもしれない。

昨年Facebookは、自らのAPIにおいて、研究者に対する「透明性の洗浄」を行ったとして非難された。そして60人の学者グループは、広告アーカイブAPIを、役立つどころか害になると非難した。

それから数カ月経つが、FacebookはAPIを改善するために、ほとんど何もしていないと報告されている

原文へ

(翻訳:Fumihiko Shibata)

AWSがスループット保証付きマネージドCassandraサービスをローンチ

米国時間12月3日に開催されたAWS re:InventでAmazonは、AWS上でCassandra(カサンドラ)データベースを管理できる機能を発表した。

このAmazon Managed Apache Cassandra Service(Amazon MCS)と呼ばれるマネージドサービスは、サードパーティのベンダーからではなくCassandraを直接デベロッパーに提供しようとするAWSの意図の現れであり、すでにGrubhub.com、Netflix、Ooyala、Openwave、Reddit、Uberなどさまざまな企業が使っている。

同社によると、Amazon MCSはサーバーレスなので、ユーザーは自分が実際に使うリソースにだけ料金を払い、アプリケーションのトラフィックに応じてスケールアップとダウンは自動的に行われる。アプリケーションは毎秒数千のリクエストに応じられ、そのスループットとストレージに上限はない。IoTにとっては、とびきり魅力的な特性だ。

デベロッパーは、Cassandraの既存のアプリケーションをそのままAWS上で動かせるし、これまで使っていたデベロッパーツールを使える。アプリケーションのアップデートはAmazon MCSのサービステーブル中のエンドポイントを変えるだけだ

データはデフォルトで暗号化されて保存される。暗号化にはAWS Key Management Service(KMS)に保存されている暗号鍵が使われる。同社によると、Amazon MCSAWS Identity and Access Management(IAM)と統合されているので、デベロッパーはテーブルデータの管理やアクセスが容易とのこと。

Amazonによると、同社はCassandraのAPIライブラリにも協力しており、またオープンソースのApache Cassandraプロジェクトにバグフィックスで貢献している。プレビュー期間中はオンデマンドのキャパシティに課金され、一般公開時にはある程度予測できるワークロードに対して一定のスループットを確保・提供する。

今このプロダクトはAmazonの無料ティアに含まれている。企業は、最初の3か月はライトリクエスト3000万、リードリクエスト3000万、ストレージ1GBの無料ティアを使用できる。

画像クレジット: Ron Miller

[原文へ]

(翻訳:iwatani、a.k.a. hiwa

バックアップした写真の中から目的の顔を見つけ出せる顔認識APIをIDriveがローンチ

この発表を初めて見たときには、思わず二度見してしまった。クラウド上でストレージとバックアップのサービスを提供しているIDriveは米国時間8月23日、AWSRekognitionなどと競合する顔認識APIを立ち上げた。

しかし、バックアップサービスと顔認識なんて、どんな関係があるのだろうか。実際のところ、IDriveはここしばらく顔認識技術に首を突っ込んでいた。昨年同社はIDrive Peopleというサービスを立ち上げており、バックアップしている写真に写っている自分や友人の顔をユーザーが見つけられるようにした。しかし今回のサービスでIDriveは、APIビジネスという新しいビジネスの分野に踏み込んだ。

そのAPIサービスはIDrive Faceと呼ばれ、静止画像の中に複数の顔を見つけたり分析したりする標準的なツールが含まれている。顔認識APIなら必ずあるような機能だ。そのためにAPIは、通常のバウンディングボックス(境界ボックス)とすべての顔のメタデータを提供している。また顔や性や年齢や顔に表れている気分などで人を特定するための、比較や検証の機能もある。気分の検出は、このAPIの独自の機能だ。APIへのリクエストはすべて暗号化され、またAPIの使い方はかなり単純明快なようだ。

IDriveは、そのツールの精度と性能がAWS Rekognition並みであるが安くなると約束している。料金はデベロッパープランでは月額49.5ドル。1トランザクションあたり0.0001ドル、最大毎分75トランザクションまで、ストレージ容量は無制限だ。ビジネスプランは月額124.5ドル。1トランザクションあたり0.0001ドル最大毎分500トランザクションまでだ。オーダー規格のエンタープライズプランもあり、また無料で試用もできる。

AWSの料金体系は例によって複雑だが、月額料金はない。また、人の顔しか認識できないIDriveと違って、テキストやオブジェクト、風景、セレブの人たちなど、いろんなものを認識するRekognitionのほうを、高くても使うユーザーもいるだろう。

GenderAge Detection

[原文へ]

(翻訳:iwatani、a.k.a. hiwa

TezLabアプリはテスラ車のためのFitbitだ

Tesla(テスラ)とその世界中の電気自動車群に対する、最も優れたリアルタイムの洞察が、シリコンバレーのテスラ本社以外で得られるとすれば、それはブルックリンの小さなスタートアップ、TezLabのレンズを通してかもしれない。

創業から2年余りが経ったTezLabは、創業者たちがユーザーの転換点であると考えている地点、すなわちついに収益化へと向かうことができるマイルストーンにたどり着こうとしている。そして同社は、その計画を加速することを助けるために、多くの新機能を追加している。

テスラ車を所有していない人にとっては、TezLabという名前はおそらくなじみのないものだろう。だが特定のコミュニティでは、すなわち自分の電気自動車がどのように振る舞っているかを知ることに夢中なテスラ車のオーナーたちの間では、TezLabはおなじみのものだ。

TezLabはテスラ車用の、Fitbitのような無料アプリ。アプリをダウンロードしたテスラ車のオーナーは、自分の車の効率性や総移動距離を追跡することが可能であり、またアプリを使って車両のいくつかの機能を制御することが可能である。例えばドアの施錠や解錠、エアコンの動作などを制御できる。さらにユーザーがマイルストーンを達成したり、タスクを完了すると、バッジを獲得できるといった、ゲーミフィケーションの要素さえ備えている。

同社は、収益化を目的とした長期計画の一環として、新しい機能を追加し始めた

そうした機能の1つとして、Wazeのようにデータをクラウドソーシングを行い、地図上でテスラ・スーパーチャージャーステーション(テスラ車のための充電ステーション)の状況とレーティングを提供するサービスが提供され始めた。以下のビデオは、このスーパーチャージャー機能がどのように機能するかを示したものだ。

スーパーチャージャーのWaze的機能は、同社のより広いクラウドソーシングとソーシャルコミュニティの計画の中では「第1段階」とみなされているものだ。

創業物語

TezLabを開発する6人のチームはHappyFunCorp(HFC)から生まれた。HFCは、モバイル、ウェブ、ウェアラブル、そしてIoTデバイスのためのアプリケーションを顧客から委託されて開発するソフトウェアエンジニアリング企業である。顧客には一連のスタートアップと並んでAmazonやFacebook、そしてTwitterも含まれている。

共同創業者のベン・シッパース(Ben Schippers)氏とウィリアム・シェンク(William Schenk)氏を含むHFCのエンジニアたちは、テスラの技術中心のアプローチと、1つの重要な点に引きつけられた。それはテスラのAPIエンドポイントが外部からアクセス可能だったということだ。

テスラのAPIは技術的には公開されていない。しかしそれは存在していて、テスラ自身が直接提供するアプリケーションが、車と通信して、バッテリ残量を読み取ったり、ドアのロックを行ったりするために使われている。これをリバースエンジニアリングすることで、サードパーティのアプリがこのAPIと直接通信することが可能になる。最近テスラのCEO、イーロン・マスク(Elon Musk)氏が、APIをサードパーティに公開する件に関して発言を行っている。

「基本的に、サーバーに接続するための配管は既に設置済なのです」とシッパース氏はTechCrunchに語っている。「これが私たちに行動を促すきっかけでした」。

テスラの購入ブームがHFC内で巻き起こった。シッパース氏、シェンク氏そしてたくさんのHFCのエンジニアたちや職員たちがModel 3のようなテスラ車を購入して、今でも所有している。そして最初のTezLabを開発するために35万ドル(約3800万円)の初期資金をHFCは用意した。

データリポジトリ

TezLabはすべてのテスラ車オーナーに使われているわけではない。だがシッパース氏は、アプリはユーザー数のクリティカルマスに近付いていると信じている。毎週200人以上のテスラ車オーナーがこのアプリをダウンロードしており、その割合は加速している、と彼は語った。

Sensor Towerによれば、TezLabはApple App StoreとGoogle Play上で、合計1万6000回インストールされている。この数字はユニークで新しいインストール数を示したものだ。同社は同じユーザーが再インストールした場合や、所有する複数のデバイスにインストールした場合には、重複したカウントは行わない。とは言えそのインストール数は1万8000に近い可能性がある。なぜならアプリのテストを行うオンラインサービスであるTestFlightでも多数登録されているからだ。

比較のために数字を挙げると、テスラは2018年に全世界で24万5506台の車両を出荷している。TezLabはすべてのテスラオーナーが彼らのアプリをダウンロードすることは期待していない。その代わりに、シッパース氏はまずオーナーの10%を狙っている(彼はそれが手の届く目標だと考えているのだ)。そして最終的にはより高いシェアを狙おうとしている。

現在の数でさえ、TezLabはテスラデータの大規模なリポジトリ(貯蔵所)となっている。同社は1日に85万から100万個のイベントを保存していて、その量は増え続けている。シッパース氏によれば、これは1日あたり1 GBを超えるデータに相当する。

「私たちは、車両群が何をしていて、何故それをしているのかに対する大規模な予想を始められる位に、十分なデータ量をシステム内に収集しています」と、HappyFunCorpのCEOであり、TezLabの製品責任者であるシッパース氏は語っている。

tezlab

データは集約され、匿名化されていて、そして公開されていない。また、それらのデータを販売する計画は存在しない。

「データを販売するというビジネスに参入することなく、本当に意味のあるものを開発できると考えています」とシッパース氏はTechCrunchに語った。

もちろん、理論的には、もしテスラがアクセス方法を変えてしまったら、シッパース氏と他のメンバーがTezLabで開発したものは、一夜にして使えなくなってしまう可能性がある。

「テスラは、FacebookZyngaに対して行った仕打ちを、私たちに対して行うことが可能です。もちろん私たちはそれを望んでいませんが」とシッパース氏は語った。

テスラはこの件に関するコメントは拒否している。

TezLabがそのウェブサイト上で公に提供しているのは、その処理データに基づく知見である。例えば、サイトにアクセスした人はだれでも、所有されているモデルの内訳や、平均走行時間、および充電間の平均時間などを知ることができる。

同社がアプリに機能を追加するにつれて、オーナーたちがどのように自分のテスラ車を使用しているかについての理解が深まるに違いない。

舞台裏ではもちろん、TezLabは自社のウェブサイトに表示されるもの以上のものを知っている。それはファントムドレイン問題(人間が使用していないのに充電残量が早く減っていく現象)や、テスラAPIがオフラインになっているかどうか、もしくは充電量が急増しているのかといった状況を素早く検出することができる。また例えばTezLabは、テスラのスーパーチャージャーステーションへの訪問が、メモリアルデー(戦没将兵追悼記念日。5月の最終月曜日)には、2019年の他の日の平均に比べて84%多かったということを発見することができる。

Stravaモデル

データを補足して保存することが、収益化を目指すTezLabの計画の中核だ。より多くの機能が追加されても、アプリは無料のまま提供される。

同社は、ソーシャルフィットネスネットワークであるStravaのビジネスモデルにならうことを計画している。それは機能ではなく容量に対して課金するモデルだ。新しい機能が追加されるにつれて、オーナーたちにとってデータは遥かに価値のあるものになる可能性がある。TezLabはオートパイロット走行の追跡を検討していて、その他にもテスラ車に現在搭載されているセキュリティ機能であるSentry mode(監視モード)で「面白いこと」を行うことも検討中だ。

この夏には、アプリはコミュニティを形成するためのクラブ(これはシッパース氏が特に望んでいる)機能を導入する予定だ。この機能を使うことで、テスラ車のオーナーたちは、例えばノルウェー、ブルックリン、あるいはサンフランシスコといった特定のクラブに参加することができる。それはオーナーが他のオーナーたちを簡単に見つけて会話を行うことができるようにデザインされる。ただしこのクラブに入ることができるのは、テスラ車を所有する人だけだ、とシッパース氏は付け加えた。

テスラに対しては、TezLabのスタッフは自らを「王国の守護者」と位置付けている。結局、彼らの活動すべてが、テスラの成功を助けることになるのだ、とシッパース氏は語っている。

「私たちが参考にしているのは、Fitbitがウォーキングとエクササイズとモチベーションのために行ったことなのです」と彼は言った。「私たちはそれを電気自動車の分野に持ち込みたいのです」。

画像クレジットBryce Durbin

[原文へ]

(翻訳:sako)

TwitterのDeveloper Labsは設計し直されたAPIへのベータアクセスを提供

ついにTwitterは、7年間も放置状態だったコアAPIをモダンなものにするために動き出した。デベロッパーからの早期のフィードバックを求めている。

米国時間の5月14日、Twitter Developer Labsを立ち上げたのもそのためだ。アプリのデベロッパーは、サインアップすることでプレリリース版のベータAPIを使った実験が可能となる。中でも真っ先に挙げられるのは、設計し直されたGET /TwittsとGET /UsersのAPIだ。

それに続くのが、初めての機能的な変更で、そこにはTwitter Firehoseへのリアルタイムのストリーミングアクセスも含まれている。以前には、高額なエンタープライズ向けのAPI契約によってのみ利用可能だったもので、ツイートのフィルタリングに加え、インプレッションとエンゲージメントの計測機能も備えている。また、Polls(投票)のような新しい機能も、APIとして追加される予定となっている。

APIの再設計に際して、デベロッパーに十分に長い準備期間と発言権を与えることで、より多くのアプリメーカーがTwitter社とプレミアムAPI(たった1つのAPIで月額339ドル=約3万7000円から2899ドル=約31万8000円)やエンタープライズ向けAPI(さらに高価)の契約を結んでくれるようになる可能性がある。

それはまた、デベロッパーの手による分析、計測、広告ビジネスの創設を刺激する可能性もある。そうなれば、さまざまなブランドがTwitterを利用したマーケティングにより積極的に出費しやすくなるだろう。今回のDevelper Labsプログラムと、APIエンドポイントの最初の変更は、今後数週間以内に公開される予定だ。

このプログラムに参加するには、デベロッパーアカウントにサインアップし、最新情報を受け取るためにDebeloper Labsサイトでメーリングリストに参加する。また、TwitterDevアカウントをフォローして、フィードバックを返すこともできる。

Twitterの、データおよびエンタープライズソリューション部門のプロダクトマネージャであるIan Cairns氏は、Twitterが過去にデベロッパーにひどい仕打ちをしてきたことを認めている。突然に方針を変更したり、デベロッパーのビジネスの持続性を阻害するようなレート制限をかけたりといったことだ。

例えば昨年には、APIの変更により、多くのサードパーティ製のTwitterクライアントアプリが動かなくなった。「ここ数年の間に、たしかに何度か、私たちがAPIを管理し、変更してきたことによって、デベロッパーに対して破壊的な影響を与えてしまったこともあるでしょう。私たちがTwitter Developer Labsプログラムでやろうとしているのは、信頼関係を築き、双方向の会話を実現するためのしくみを作ることです。私たちのプラットフォームをいちばん使ってくれているデベロッパーの声が、将来を動かすようにしたいのです」。

TwitterのメインAPIは、2012年8月にリリースされて以降、手が加えられていなかった。その間にも、エンタープライズ用と、広告用APIには、多くの進展があった。もちろん手が加わらなかったことによる利点はある。古いAPIは下位互換性を保つという点では優位性があった。デベロッパーは、頻繁にアップデートする必要もなく、古いユーティリティがずっと動作し続けるからだ。

しかし、例えば「投票」のように、新しい機能をAPIとして実現することを阻んできたのも確かだ。Twitterは、より規則的なバージョン付けができるシステムに移行しようと計画している。その際、何らかの破壊的な変更を伴う場合には、デベロッパーが適応できるよう、前もって通達できるようにするつもりだ。

比較的最近のことだが、TwitterはAPIの合理化を発表し、2017年には有料のAPIも制定した。しかし昨年になって、Twitterのクライアントアプリを動かなくしたり、デベロッパー用ツールFabricをGoogleに売却した。それもこれも、コスト削減の一環であり、過去にはVineを終焉に追いやった実績もある。

そして今年になって、Twitterはスパムを生み出すAPIの悪用と、フォロワーを購入するサービスを取り締まる動きに出た。その伏線となったのは、Cambridge Analyticaのスキャンダルがデベロッパー向けプラットフォームの信頼を揺るがせ、安全性とプライバシーを保護するために機能を制限することを、プラットフォームのオーナーに強いたことだ。

Developer Labsは、この3月にリリースされた新しいアプリ「twttr」のベータ版と同じような、マニアックな路線を行くものとして、返信やフィードの動作がどのように変わるのかをデベロッパーが試せる場になるだろう。Twitterは以下のように述べている。「私たちがDeveloper Labsで最初に注力するのは、対話的なデータを扱うデベロッパーです。そこにはTwitterで何が起きているのかを研究、調査している学者や研究者も含まれます。また、異なる分野のビジネス向けに、ソーシャルリスニングや分析機能を開発しているような会社も対象となります」。

Twitterとデベロッパーとの関係は、これまでずっと不安定なものだった。その大部分は、コミュニケーションの不足が原因だった。デベロッパーが何かを開発しても、TwitterがAPIを変更して動かなくしてしまったり、Twitter自身が同じような機能を開発したりすれば、膨大なエンジニアリングの労力が無駄になってしまう。もし、Developer Labsによってデベロッパーとの透明な対話の道が開かれれば、Twitterはデベロッパーを広報活動にとっての重荷どころか、味方につけることができるはずだ。

原文へ

(翻訳:Fumihiko Shibata)

自動車データ活用のSmartcarがライバルのOtonomoをAPIの盗用で提訴

手段を選ばないコピーは、テック業界ではありふれている。Snapchatに聞いてみるといいだろう。とはいえ通常は文字通りのコピーではなく、より概念的なものである。しかし自動車のAPIスタートアップであるSmartcarは、ライバルのOtonomoがSmartcarのAPI文書を、コピー&ペーストでパクったと主張している。申し立てによれば元の文書のタイポ(ミススペル)やコード中でランダムに生成された文字列などが一致するほど広範囲に盗用が行われているという。その知的財産に対する盗用を詳細に述べた、一連のスクリーンショットが公開されている

SmartcarのCEOであるサハス・カッタ(Sahas Katta)氏は、「彼らの従業員の何人かが、私たちの製品を、体系的に使用しているという証拠を握っています。それによれば私たちの製品をフォーマットと機能の両面からコピーしようとしているようです」。スタートアップの広報担当車は筆者に対してこのように述べた「知的財産侵害行為停止通知書を、今朝Otonomoに対して送付したばかりです。その中にはさまざまな違反行為や違法行為に関する点が明記されています」。

Otonomoが取るに足らないスタートアップではないことを考えると、この告発は厄介なものだ。イスラエルを本拠地とするOtonomoは、2015年の創業以来5000万ドル以上を調達しており、その投資家には自動車部品大手のAptiv(以前のDelphi)や一流のVC企業Bessemer Ventures Partnersなどが含まれている。OtonomoのCMOであるリサ・ジョイ(Lisa Joy)氏は、この申し立てに応えて、調査は行うがやましい行動はとっていないことを確信しているという、以下のような声明を発表した。

Otonomoは、自身の知的財産と特許に裏打ちされた、完全にユニークな製品を提供していることに誇りを持っています。私たちはSmartcarからの質問を真剣に受け止め調査を行っていますが、私たちは現時点では厳格で誠実な、私たちの行動基準が破られていないことを確信しています。調査により問題が明らかになった場合には、直ちにそれに対処するための必要な措置を講じます。

どちらのスタートアップも、車のデータをアプリ開発者と結び付けるAPIレイヤーを開発しようとしているため、両社とも車のデータを検索、アンロック、または利用するための製品を開発することができる。マウンテンビューを拠点とする従業員20人のSmartcarは、Andreessen HorowitzNEAから1200万ドルを調達している。誰がこの市場を勝ち取るかを決定する主な要因は、どちらのプラットフォームが、開発者がAPIを統合するのを最も簡単にする最高のドキュメンテーションを提供できるかというものだ。

「数日前、私たちはOtonomoの公に入手可能なAPIドキュメントに、たまたま出会いました。それを読み進めるにつれて、私たちはすぐに何かがおかしいことに気が付きました。見慣れたもののような気がしたのです。それは奇妙な感覚でした。それもその筈、私たちが書いたものだったからです」とSmartcarはそのブログポストの中で説明している。「Smartcarのドキュメントと、何となく似ている点がいくつか見つかっただけではありません。Otonomoのドキュメントは私たちのものを体系的に書き写したものなのです、全体構造からコードサンプル、そしてタイポに至るまで」。

上の方の図では、比較のために、左にSmartcar、右にOtonomoのAPIドキュメントが示されている。これを見るとOtonomoはほぼ同様のフォーマットを使い、サンプルの中でランダムに生成されたID(ハイライト済み)もSmartcarと全く同じものである。その他の例では、見かけ上同一のコード文字列やスニペットが示されている。

Smartcarの創業者兼CEOのサハス・カッタ氏

Otonomoは、彼らのドキュメントのウェブサイト(docs.otonomo.io)を閉鎖したが、TechCrunchがArchive.orgWayback Machineを使って参照したところ、2019年4月5日におけるOtonomoサイトの該当部分の内容は、20188Smartcarが公開したドキュメントとまったく同じものだった。

ここにはSmartcarの「it will returned here」というタイポと、ランダムに生成されたサンプルコードのプレースホルダー「4a1b01e5-0497-417c-a30e-6df6ba33ba46」が含まれているが、どちらもOtonomoのドキュメントのWayback Machineから引き出したコピーの中に含まれていた。このタイポは、今でも公開されているこのバージョンのOtonomoのドキュメントでは修正されているが、コード中の文字列は残されたままである。

「彼らが偶然にランダムに生成された同じ文字列に到達するのは、おそらく100京分の1位の確率でしょう」とSmartcarのカッタ氏はTechCrunchに語る。

にもかかわららず奇妙なことに、OtonomoのCMOはTechCrunchに対して「Smartcarがブログに投稿した資料はすべて公にアクセス可能な文書なので、すべてパブリックドメインの内容なのです」と述べている。だがそれは真実ではない、とカッタ氏は主張する。世に言う「パブリックドメイン」の定義とは、著作権対象外の公開されたコンテンツのことである。「もちろん私たちはそれをパブリックドメインのものとは考えていません…一番下には正しい著作権表示が行われています。私たちの製品は私たちの知的財産です。TwilioやStripeのAPIドキュメントのように、それは公開されていて誰でもアクセス可能ですが、それは権利保護されているのです」。

Otonomoのリサ・ジョイ氏は、彼女のスタートアップが現在シリーズCの資金調達中であると述べている。伝えられるところでは、既に韓国のエネルギーならびにテレコムホールディングスの巨人SKから1000万ドルを調達しているらしい。「私たちは現在資金調達ラウンドの最中です。ラウンドはまだ終了していません」と彼女は私に語った。だがもし、OtonomoがどうやらそのAPIドキュメントをコピーしたらしいということになった場合には、それは開発者に対する名声を傷付け、おそらく資金調達ラウンドを危険に晒しかねないことになるだろう。

[原文へ]

(翻訳:sako)

FacebookがChromeブラウザのAPIに初めて貢献

Facebookは米国時間4月22日、GoogleのChromeブラウザのAPIに対して、初めて大きな貢献を果たしたことを発表した。

Facebookのチームは、Googleと共同で、ブラウザにコードを提供するためのAPIプロポーザルを作成した。これはFacebookとしては初めてのこと。このコードは、ウェブ上のツールや標準に関するFacebookの他の多くの仕事と同様に、ユーザー体験をスムーズかつ高速にすることを目指したもの。このAPIの場合、ユーザーがクリック、またはキーを操作してから、ブラウザが応答するまでの時間を短縮する。

この新しいシステムの最初の試験的な実装はChrome 74とともにリリースされる予定だ。

一般的に、ブラウザのJavaScriptエンジンは、コードの実行を制御している。そして、応答しなければならない入力が保留になっていないかどうかを確認するため、一瞬コードの実行を停止することもある。マルチコアのマシンで動作する最新のJavaScriptエンジンも、基本的にはシングルスレッドで動作する。そのため、実際にはエンジンは1度に1つのことしか実行できない。そこで、入力イベントを確認しつつ、コードの実行をどのように組み合わせるかということがカギとなる。

「他の多くのサイトと同様に、私たちもJavaScriptを小さなブロックに分割することでこの問題に対処しています。ページがロードされている間も、若干のJavaScriptを実行し、その後にブラウザに制御を戻すのです」と、Facebookチームは発表の中で説明している。「ブラウザは、そこで入力イベントのキューをチェックして、ページに通知する必要のあるものがあるかどうかを確認できます。その後ブラウザは、JavaScriptのブロックが読み込まれる都度、それらを実行する動作に戻ります」。

ブラウザがこのようなサイクルで動作している際に、新しいイベントをチェックして、その処理に入ると、わずかながら余計な時間がかかる。それが何度も積み重なると、ページのロードが遅くなる。とはいえ、入力のチェックのインターバルを長くすると、こんどはブラウザの応答が鈍くなるので、ユーザー体験が劣化してしまう。

これを解決するため、FacebookのエンジニアはisInputPendingというAPIを作成した。これにより、上のようなトレードオフをする必要がなくなる。Facebookは、このAPIを、W3Cのウェブパフォーマンスのワーキンググループにも提案した。これを利用すれば、デベロッパーは保留中の入力があるかどうかを、コードの実行中に確認できる。

これにより、コードは応答すべきものがあるかどうかを自分でチェックできるようになる。ブラウザに完全に制御を戻さなくてもよく、さらにそこからJavaScriptエンジンに入力を引き渡す必要もない。

現時点ではこれはまだ試験的なもの。デベロッパーは、このAPIを自分のコードに組み込む必要があるため、Chrome 74のリリース後に、自動的にブラウザの動作が速くなるというわけではない。この試行が成功すれば、もちろんデベロッパーはこのAPIを利用するようになるだろうし(もちろんFacebookは自ら利用するだろう)、他のブラウザベンダーもそれぞれのエンジンにこのAPIを実装するようになるはずだ。

「ChromeにisInputPendingを導入するプロセスは、Facebookにおいてウェブ標準を開発する新しい方法を象徴するものです」とチームは言う。「私たちは今後も新しいAPIに取り組み続け、オープンソースのウェブブラウザへの貢献を増強したいと考えています。将来的には、このAPIをReactのコンカレントモードに直接組み込むことも可能となるでしょう。そうすれば、デベロッパーはこのAPIのメリットを、自動的に享受できるようになります。さらに、isInputPendingは、スケジューリングに関するプリミティブをウェブに導入するという大きな流れの一環なのです」。

画像クレジット:Getty Images上のAlexander Koerner/Getty Images

原文へ

(翻訳:Fumihiko Shibata)

スパム防止にTwitterが1日の新規フォロー数を400件に制限、セキュリティー強化の一環

Twitterはスパマーをエコシステムから追い出すためにさらに大きな一歩を踏み出した。 ユーザーが1日に新しくフォローできるTwitterアカウント数の上限がこれまでの1000件から400件に大きく減らされた。スパマーはネットワークの規模を急激に拡大するために新しいアカウントを大量にフォローし、すぐにアンフォローするというテクニックを用いてきた。これは往々にしてTwitterの利用約款に違反する「不当ないし犯罪的方法」となっていた。

フォロー、アンフォロー、フォロー、アンフォロー。こういうことを繰り返すのはスパマーだ。そこでわれわれは1日にフォローできるアカウント数を1000から400に減らす。一般ユーザーには影響ないはず。ご安心あれ。.

こういうことをしていた多数のサービスがTwitterAPIの利用を禁止されている。簡単に大量のアカウントをフォローできるアプリが売られていた。こうしたツールがネットワークの規模拡大のツールとして便利だったのはフォローされると深く考えずにフォローバックしてしまうユーザーがいるためだ。実はフォローしてくるのは人間ではなくボットなのだが。

こうしたボットを売る会社は、すぐにフォローバックしてこないユーザーを自動的にアンフォローするツールも提供している。また不愉快なDMツイートをばらまくツールも多数販売されている。

今年に入ってTwitterはこうした「フォロー即アンフォロー」 ツールのTwitterへのアクセスを排除した。しかしローカルで作動するツールを排除してもスパムの自動化を提供するサービスを儲けさせるだけに終わっていた。

この種のスパム防止にはTwitterのAPIレベルでの本質的な対策が必要だった。しかし今回の対策ではまだ不十分だ、そもそも1日で400アカウントもフォローできるというのは手ぬるい、と考えると考えるセキュリティー専門家も多い。

言わせてもらうが、私の場合400人もフォローするのに7年かかっている。

中小ビジネスは一般の関心を惹くために「フォロー即アンフォロー」テクニックを使い続けるかもしれないが、規模は小さくなるだろう。

Twitterの広報担当者はTechCrunchの取材に対して、400件という数字の根拠をこう説明した。

われわれはしきい値をどこに設定するか各種検討した。その結果、大部分のスパムを防止できると同時に正当な利用に影響を及ぼさない値として1日あたり400件と決定した。

Twitterはまた報告ツールをアップデートし、Twitterアプリ内からユーザーがスマムやフェイクアカウントを通報できるようにした。またアカウントの本人確認やログイン認証にも新しいセキュリティー対策を導入している。昨年夏、Twitterはスパムアカウントを大量に削除したため、ユーザーのフォロワー数に大きな変動が生じたことがあった。(略)

こうした対策はスパマーにとってTwitterが住みにくいエコシステムとなることを狙っている。ただし短期的にはTwitterのユーザー数の伸びを低下させるかもしれない(Twitterは最近、この数字の公表を中止している)が、中長期的にはプラットフォームの健全性を維持するのに役立つだろう。

原文へ

(翻訳:滑川海彦@Facebook

ML/AIプラットホームのVizion.aiがマネージドElasticsearchサービスを立ち上げ

オープンソースの分散検索エンジンのElasticsearchは、今や大小さまざまな多くの企業が自社の分散検索とアナリティクスを実装するために利用している。そのセットアップはそれほど困難ではないが、難しいのはリソースの最適プロビジョニングだ。特にユーザーの要求にスパイクがあるアプリケーションでは無駄のないリソース確保が難しい。そこで、Elasticsearchを管理を伴うクラウドサービスElasticsearch Serviceとして提供するVizion.aiは、その心配を解消し、ユーザーが実際に使ったインフラストラクチャにのみ課金する。

Vizion.aiのサービスは、必要に応じて自動的にスケールアップ・ダウンする。そのマネージドサービスとして提供されるSaaSプラットホームはプライベートとパブリック両様のクラウドデプロイをサポートし、Elasticの標準的スタックとの完全なAPI互換性がある。また標準のツールとして、データ視覚化のKibanaや、データをサービスに送るBeats、入力データを変換してデータパイプラインをセットアップするLogstashなど、Elasticsearchの標準のツールも含まれている。例えばーザーは、テスト用や開発用に複数のスタックを容易に作ることができる。

Vizion.aiのGeoff Tudor氏

Vision.aiのバイスプレジデントでゼネラルマネージャーのGeoff Tudor氏は、次のように語る。「AWSのElacticsearchサービスを使おうとすると、選択肢の数が多すぎて途方に暮れてしまう。インスタンスのサイズはどれにするか?、インスタンスはいくつ必要か?、地理的冗長性は必要か?、どんなネットワーキングを使うのか?、セキュリティはどうか?、などなど。選択を間違えると全体的なパフォーマンスに影響が及ぶ。弊社では、インフラストラクチャのレイヤの背後でリソースの均衡化を動的に行う」。

そのためにこのサービスはユーザーの利用パターンを見て、そのユースケースに合った最適なリソース割り当てを行う。実はVizion.aiの親会社Panzuraはエンタープライズ向けのマルチクラウドストレージサービスで、データのキャッシングに関する多くのパテントを持っている。今度の新しいElasticsearchサービスは、それらの技術を利用してリソースの最適割り当てを行う。

Tudor氏も認めるように、Elasticsearchの商用サービスはほかにもある。それらと、Vizion.aiの新しいサービスとの差別化要因は、事前にメタデータ用のストレージのサイズを決めなくてもよいこと、そして高価なSSDを大量に使わないことだ。PanzuraのIPを利用できるVision.aiは、最近のデータだけをSSDにキャッシュし、そのほかは安価なオブジェクトストレージのプールに収める。

さらに彼によると、Vizion.aiはAIやMLのワークロードを動かす総合的なサービスであり、Elasticsearchサービスはその構成成分のひとつだ。TensorFlowやPredictionIOのサポートも、目下準備中だ。とくにPredictionIOは、Elasticsearchと併用しやすい。「今後これを、マルチクラウドによる使いやすいサーバーレスのML/AIサービスにしていきたい。しかもうちでは、提供するのはコンピュート(計算処理)だけではなく、レコードのストレージも非常に高いコスパで利用できる」。

[原文へ]

(翻訳:iwatani、a.k.a. hiwa

自動車用アラームの欠陥で300万台の車がカージャックの危機に

一般的に使われている2種類の自動車用アラームシステムが、セキュリティの脆弱性を修正した。それらのシステムの以前の状態では、研究者が車両を遠隔操作で追跡し、乗っ取って、その車をコントロールすることができた。

英国のサイバーセキュリティ会社のPen Test Partnersの研究者によると、ロシアのアラームメーカーのPandoraと、米国カリフォルニアに拠点を置くViper(英国でのブランド名はClifford)によって開発されたシステムは、簡単なサーバー側のAPIの操作に脆さを露呈した。米国時間の3月8日に投稿されたところによれば、APIを悪用して、アラームシステムのユーザーアカウントと、その車両の制御を獲得することができたという。

その脆弱なアラームシステムのAPIは、リクエストが正当なものであるかどうかを確認することを怠るため、そのアカウントのパスワードをリセットするよう騙すことができ、研究者がログインできた。

研究者はテストのためにアラームを購入したが、「だれでも」本物のアカウントにアクセスするためのユーザーアカウントを作成したり、その会社のすべてのユーザーデータを引き出すことができる状態だったという。

研究者によると、全世界でおよそ300万台の車がこの欠陥の影響を受ける状態にあったはずとのこと。

このハッキングの実証実験では、研究者はターゲット車両の地理的位置を特定し、それをリアルタイムで追跡し、実際に追尾して、遠隔操作でエンジンを切り、車を停止させ、ドアのロックを解除した。研究者は、脆弱な車両を乗っ取るのは「取るに足らない」ことだったと述べた。さらに悪いことに、車のモデルを特定できる場合もあり、高価な車を見定めて乗っ取ることを容易にする。

さらに研究者は、車載マイクロフォンの音声を聞くことができることまで発見した。それは、緊急サービスへの電話や、ロードサービスのために、Pandora社のアラームシステムが備えているものだ。

Pen Test Partnersの創立者であるKen Munro氏は、これは彼らとして「最大の」プロジェクトだったと、TechCrunchに語った。

こうした脆弱性の深刻さを考慮して、研究者は7日間の開示期間を設け、PandoraとViperの両社に連絡を取った。両社とも即座に応答し、この欠陥に対処した。

問い合わせに対し、ViperのChris Pearsonは、その脆弱性が修正されたことを認めた。「悪意によって使われた場合、その欠陥によって承認なしに顧客のアカウントにアクセスされる可能性がありました」。

Viperによれば、サービスプロバイダによる最近のシステムアップデートのせいで発生したバグであり、問題は「すみやかに修正された」ということだ。

「Directed社(Viperの親会社)は、この脆弱性が存在した短期間の間に、顧客データが露出されることもなく、承認なしにアカウントがアクセスされたこともなかったと確信しています」と、Pearson氏は述べた。しかし、会社がどうやってそういう結論に達したのかという証拠は明らかにしなかった。

一方、PandoraのAntony Noto氏は、長いメールで研究者の指摘に反論した。要約すると、「システムの暗号化は破られず、リモートコントロールはハッキングされず、タグは複製されていません」ということ。「ソフトウェアの不具合により、一時的に短期間だけデバイスにアクセスすることができましたが、現在は対処されています」。

今回の調査は、CalAmp社に対して昨年行われたVangelis Stykasによる研究に続くもの。同社はViperのモバイルアプリの基盤となっているテレマティックスを提供している。Stykasは、後にPen Test Partnersに入社し、カーアラームの調査プロジェクトにも携わった人物。Viperのアプリが、アプリ内にハードコーディングされた認証情報を利用して中央のデータベースにログインしていることを発見した。それにより、ログインしている人は誰でも、接続された車をリモートコントロールすることができる状態になっていた。

(関連記事:Outdoor Tech’s Chips ski helmet speakers are a hot mess of security flaws

原文へ

(翻訳:Fumihiko Shibata)

人材採用のOpen API構想を掲げるHERPが「doda」と連携開始へ

(写真左から)パーソルキャリア 転職メディア事業部プロダクト開発統括部転職メディアBITA部プロダクトBITAグループマネジャー 松岡諭史氏、ビジネス開発部DODA Recruitersビジネス開発グループ 原田歩美氏、プロダクト企画統括部ビジネス開発部ゼネラルマネジャー 福島直人氏、HERP代表取締役CEO 庄⽥⼀郎氏

求人媒体連動型の採用管理システム「HERP ATS」を開発・運営するスタートアップ、HERP。TechCrunch Tokyo 2018スタートアップバトルのファイナリストでもある同社は、人材採用業界版のOpen API構想、「Open Recruiting API構想」を掲げている。

企業の採用業務に関連するあらゆる情報をオープン化する、というこの構想でHERPが目指すのは、エージェントや媒体に偏りがちな求職者の情報、企業の情報のオープン化による、採用業務の合理化だ。企業・候補者・採用媒体それぞれにとって、よりメリットある形に採用を進化させることを目的としている。

Open Recruiting API構想のもと、同社は2018年7月には第1弾として「Find Job!」「SCOUTER」とのAPI連携を発表。今年1月には、第2弾として「bosyu」「Findy」「YOUTRUST」とのAPI連携を発表していた。

そして今日2月26日には構想の第3弾として、パーソルキャリアの中途採用管理システム「doda Assist(デューダ アシスト)」が保有する応募者データとの連携を4月から開始することを明らかにした。

doda Assistはパーソルキャリアが運営する「doda」ブランドの転職サービス、「doda求⼈情報サービス」、「doda⼈材紹介サービス」、「doda Recruiters」を利用する企業が、中途採用業務全般を一元管理できるシステム。選考・応募者情報・⼈材紹介会社の管理機能や、メール連絡、doda Recruitersを使ったスカウト機能などで、採⽤業務の効率アップを支援している。

パーソルキャリアではHERPとの業務連携、Open Recruiting API構想への参加により、「dodaを利用する顧客の採用事務工数を削減し、より価値が高い採用業務に注力できるよう、取り組んでいく」としている。

HERPは2017年3月、リクルートとエウレカで採用に携わっていた代表取締役CEOの庄田一郎氏により設立された。実際に採用現場に携わった経験から庄田氏は、Open Recruiting API構想を表明。構想発表時の取材でも庄田氏は「採用、HRの業界構造を変えたい」「今後、採用にまつわる情報は複雑化する。これを見据えて、データオープン化への対応を準備していく」と語っていた。

HERPでは引き続き、企業の採⽤活動で合理的な意思決定をサポートするとともに、HR業界のより良い未来を実現すべく、プロダクト開発に取り組む、としている。