コーディング不要で誰でもAlexaのスキルを作れるStorylineが今YCで勉強中

【抄訳】
今や3900万人のアメリカ人がスマートスピーカー製品を持っていると言われるが、それらのための音声アプリのエコシステムはまだ発展途上だ。Alexaのスキルは25000種を超えたというけど、まだAlexaのスキルを作っていない企業の方が多いし、スキルがあるといっても、どうでもいいような、ささやかなものばかりだ(企業の製品案内をするとか)。この、未発達なデベロッパー状況の中にやってきたのが、ベラルーシで立ち上がったStorylineだ。同社のサービスは、デベロッパーでない、プログラムを書けない、ふつうの人でも、やさしいドラッグ&ドロップ方式でAlexaのスキルを作らせてくれる。

同じくドラッグ&ドロップでプログラミング不要でWebサイトを作れるサービスにWeeblyがあるが、Storylineは“音声アプリのためのWeebly”を自称している。

【中略】

Storylineの協同ファウンダーでCEOのVasili Shynkarenkaはこう言う: “Alexaのスキルのような、会話型のアプリは、プロのデベロッパーでもまだ作るのに苦労している。デベロッパーでない、クリエイティブに人とかコンテンツの作者たちは、そもそもコードを書けない。そのことが、ぼくたちの大きな着眼点だ”。

今はAlexaオンリーだが、いずれGoogle Homeにも対応する気だ。同社のソフトウェアはとてもシンプルで、一般的なスキルのほかに、Flash Briefingも作れる。簡単なスキルなら5分から7分で作れる、とVasiliは言う。

使い方は簡単で、Storylineのアカウントを取得したら、あとは指示に従っていろんな項目を入力していくだけだ。最後に、Alexaとの会話の流れを作る。

会話の流れをStorylineが画面右に表示してくれるから、それを見ながら必要な編集をしていく。

いろんなボタンを選んでクリックしながら、さまざまなタイプの会話を入力していく。その中には、“ユーザーが想定外のことを言った場合”、というケースもある。

そして出来上がった会話は、ブラウザー上でテストできる。いきなりAlexaにロードしなくてもよい。

会話が完成したら、“Deploy”ボタンを押すとAmazonのアカウントへ行くから、そこで会話の内容をパブリッシュする。Amazonのデベロッパーアカウントを持っていない人は、このときにStorylineのガイドに従って簡単に作れる。

Storylineを使うと、けっこう複雑高度な会話も実装できるから、子どものためのスキル・コンペAlexa Skills Challenge: Kidsでは、決勝に残った内の二人がStorylineを使っている。

2017年の10月にローンチしたStorylineは、今ではユーザーが3000人おり、約3000のスキルが作られている。うち200は、実際にAmazonのSkill Storeから提供されている。

Storylineの競合製品Sayspringも、デザイナーなどがスキルを作れるが、Storylineのように作ったスキルを作者が簡単にパブリッシュできるものではない。その違いは大きいよ、とVasiliは自負を述べる。

“単なるプロトタイピング・ツールじゃ、お客さんがつかないよ”、と彼は競合製品を批判する。

  1. dashboard-page.png

  2. canvas-page.png

  3. canvas-page-2.png

  4. canvas-page-3.png

  5. skill-sharing-page.png

  6. skill-preview-page.png

  7. skills-page.png

  8. landing-page.png

Storylineにはアナリティクスの機能もあるが、アナリティクスの結果と編集(スキルの改良)機能との統合が、今後の課題だ。

今後はいろんな種類のスキルのテンプレートも提供していくから、コーディング不要のスキルづくりがますます簡単になるだろう。雑学クイズ(トリビア)のような、ゲームのテンプレートも提供するそうだ。

そしてもちろん、Google Homeなどそのほかの音声プラットホームにも対応する予定だ。

今StorylineはY Combinatorの2018冬季の生徒で、YC とAdam DraperのBoost VCが投資している。

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

IBMがローコードプラットホームMendixをIBM Cloudに統合、新しいタイプのユーザー獲得をねらう

IBMが今日(米国時間1/25)、ローコード開発プラットホームMendixとのパートナーシップを発表した。これによりMendixは、IBMのWatsonなど多くのIoT/AIサービスとともに、IBM Cloudにネイティブで統合されることになる。IBM CloudはそれまでIBM Bluemixと呼ばれていたが、すでにそのころから同社とMendixとのパートナーシップは存在している。

この、新たに進化したパートナーシップによって、IBMはMendixをIBM Cloudに持ち込み、同社自身のツールとのより深い統合を行う。IBM Cloud PlatformのゼネラルマネージャーDon Bouliaによると、IBMのプラットホーム上の既存のデベロッパーたちは必ずしもMendixのようなローコード/ノーコード方式に積極的なタイプではないが、しかし今回のパートナーシップによってIBMは、これまで同社のクラウドサービスを活用できなかったデベロッパーや、なるべく早くプロトタイプを作りたいと願っている高度なデベロッパーなど、新しいデベロッパー集団に訴求できるようになる。

Mendixを同社のクラウドに加えることによってIBMは明らかに、その多様なサービスにさらに多くのユーザーを惹きつけたいと願っている。まず挙げられるのが、WatsonのAIサービスとのディープな統合であり、それはたとえば、Conversationサービスによるチャットボットの構築や、翻訳サービス、テキストの音声変換など、またWatson Tone Analyzerによるテキスト中の感情理解、そしてWatson Visual Recognitionサービスなどだ。Mendixのコネクターキットを使えば、IBMのIoTやブロックチェーンサービスにもアクセスできる。

IBMのIoTやブロックチェーンのAPIを扱うようになれば、Mendixのビジュアル開発ツールの枠を超えて、これらのツールをフル活用することになるだろう。

Mendixは、他のすべてのローコードプラットホームと同様に、アプリケーション開発を10倍スピードアップすると約束している。またIBMは、同社のサービスによってデベロッパーが自分たちのアプリケーションを、コンテナやCloud FoundryのようなプラットホームからIBM Cloudへ容易にデプロイできる、と訴えている。

〔参考記事: Mendix日本語解説

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

Apple、iOS 11.3プレビュー版発表――アニ文字に新キャラ、電池警告メーター、ARKitサポート他新機能多数

今朝(米国時間1/24)、Appleからビッグ・ニュースが発表された。Appleは最新のモバイルOSのプレビューを公開した。アップデートの目玉は消費電力の管理、拡張現実のプラットフォーム、ARKitのサポート、新しいアニ文字iキャラクターの追加、ヘルス・アプリの拡充などだ。

ARKit 1.5についてはここに詳しいが、 アップデートされたプラットフォームは外界のさまざまな対象、たとえば壁などの垂直の面、円形のテーブルなどを認識する能力を持つ。これまでもテーブルや椅子に仮想物体を配置することができたが、そうした能力が大幅に拡充された。新しいシステムはポスターや掲示など2D画像を認識する能力がある。これらの能力は美術館などの公共施設できわめて広い応用範囲を持つはずだ。

iOS 11.3のリリースに向けて、ドラゴン、クマ、ライオン、ガイコツのアニ文字キャラクターの準備が進んでいる。アニ文字は「動くアバター」で、カメラで撮影したユーザーの表情が反映される。新キャクターの追加で16種類のアニ文字が利用できるようになる。

Appleがモバイル・デバイスのバッテリー問題に対処するにあたって、今回のアップデートではOSのいくつかの重要な部分が改良を受けた。.iOS
11.3 にはバッテリーヘルスメーターが新設された。これは自動車の警告灯に似ており、ユーザーがバッテリーの状態に注意するよう促す。Appleは旧世代のiPhoneのバッテリー駆動時間を延ばすためにパフォーマンスを制限するシステムを導入して激しい議論を引き起こしが、新OSではユーザーはこの機能をオフにできる。

この新機能は今後発表されるiOS 11.3ベータ版以降で実装され、iPhone 6、iPhone 6 Plus、iPhone SE、iPhone 6s、iPhone 6s Plus、iPhone 7、iPhone 7 Plusで利用可能となる。 AppleはiOS 10.2でのバッテリー寿命の取扱いに関して透明性を欠いたとして強く批判されたが、今回のアップデートはこれに配慮したものだろう。

Appleはまたヘルス・アプリの改良も行った。これは主としてAppleのウェアラブル・デバイスの分野で実行され、さらに本格的なヘルス・ツールとなることを目指しているようだ。新しいヘルス情報の記録機能は一箇所で情報を管理することで医師や病院との連携性を高めるものだ。

新しいヘルスアプリで管理される情報は従来の標準的なApple Watchより詳しく、処方薬、検査結果なども含むことになる。これに伴ってAppleはセキュリティー管理もアップグレードしている。われわれが日常メールをやり取りしたりビデオを観たりするデバイスがヘルス情報も管理するのだから当然のことといえる。Appleによれば、こうした情報はすべて暗号化され、パスコードで保護されるという。

Appleの企業向けチャット、Business Chatは興味深い試みだ。店舗や金融機関がこのサービスを利用すればMessageを利用して顧客と直接コミュニケーションができる。これもiOS 11.3の公開と同時にベータ公開されるはずだ。Appleはスタート時点でDiscover、Hilton、Lowe’s、Wells Fargoなど相当数のパートナーを確保している。ユーザーはコールセンターで延々と待たされたりTwitterの公式アカウントにあてにツイートしたりすることなしに、直接企業の担当者と会話ができるようになるという。

これ以外にもいくつか重要なアップデートがある。HomeKitでソフトウェア認証がサポートされ、スマートホーム用ハードウェアのメーカーにセキュリティーに関する選択肢が増えた。Apple Newsにも多数のアップデートがあり、キュレーションされたビデオが追加されトップストーリーも改良された。 Apple Musicではストリーミングで音楽ビデオが配信されるようになった。

一般ユーザー向けにiOS 11.3がリリースされるのはこの春が予定されている。一方、デベロッパー・プログラムに登録しているユーザーは今日からダウンロードしてテストを開始できる。

[原文へ]

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

エンタープライズバージョンコントロールのAssemblaがMacOS用のSubversionクライアントCornerstoneを買収

今や、バージョンコントロールシステムといえばgitだけ、と思われるぐらいその人気は高いが、しかし主にエンタープライズ界隈では、gitと競合するSubversionやMercurialもかなりの数のユーザーを抱えている。そこでSubversionを使って企業にバージョンコントロールサービスを提供しているAssemblaが今日(米国時間1/18)、MacOS用のSubversionクライアントとして人気の高いCornerstoneの買収を発表したのも意外ではない。

Assemblaは、Cornerstoneとそれを作ったZennawareを買収した。Zennawareが最初にCornerstoneをローンチしたのは2008年で、今後はAssemblaがこのクライアントの販売と開発を継続する。数か月後にはバージョン4.0をリリースする予定だ。買収の財務的詳細は、公表されていない。

AssemblaのCEO Paul Lynchはこう声明している: “われわれはCornerstoneの未来に投資している。現状維持を願うのではなく、われわれがこれまでSubversionとAssemblaのWebアプリケーションに対して行ってきた重要な改良を、今すでに優れたソフトウェアであるCornerstoneのデスクトップアプリケーションに適用したい。それにより、ユーザーのリポジトリとデータまわりの対話とワークフローを、さらに良くしていきたい”。

Assembla自身は、2016年にScaleworksに買収されたScaleworksはVCとプライベート・エクイティのハイブリッドのような企業で、それ自身では成長の限界に達しているような企業に投資、ないし買収をして、その能力と価値を次のレベルへと高め、それにより投資企業としてのリターンを得ている。Scaleworksに買収される前のAssemblaも、成長が横ばい状態になっていた。そして買収後は、エンタープライズへの新たなフォーカスによって売上が倍増し、今回Cornerstoneを買収したのも、さらにその成長カーブを先へ伸ばしていくためだ。

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

Amazon AWSのサーバーレス・サービス、LambdaがGo言語のサポート開始

Amazo AWSのサーバーレス・プラットフォーム、LambdaGoのプログラムのサポートを開始した。GoはGoogleが開発したプログラミング言語で、最近人気を高めつつある。

AWSがGoをサポートすること自体は大きな驚きではない。AWSは昨年のre:InventカンファレンスでGoをサポートする予定だと明らかにしていた。しかしデベロッパーがGoで書いた関数を実際にLambdaで実行できるのは今日(米国時間1/16)からだ。

これでAWS LambdaはJavaScript、Node.js、Java、C#、Pythonに加えてGoをサポートすることになった。Lambdaのライバルを目指すGoogleのサーバーレス・プラットフォーム、Cloud Functionsは依然としてベータで、言語としてはまだNode.jsしか使えない。一方MicrosoftのAzure FunctionsはC#、JavaScript、F#、Javaをサポートし、Python、PHP、TypeScript、Batch、Bash、Powershellをそれぞれ実験的にサポートしている。

サーバーレス・プラットフォームの価値はサポートする言語の種類だけで測れるものではないが、 Lambdaのように多数の言語がサポートされればそれだけ広い範囲のデベロッパーが利用できるようになる。スタートしたばかりのサーバーレス・サービスという分野にとって、これは大きな意味を持つだろう。

LambdaにアップされたGoのコードは標準的なgo1.xランタイムで実行される。デベロッパーはGoプログラムをZIPファイルとしてAWSにアップし、コマンドライン・ツールまたはLambdaコンソールから実行する。またAWSの分散型アプリ向けデバッグとモニターのツール、AWS X-RayもLambda上のGo をサポートする。AWS CodeStarもGo関数によるデリバリー・ツールチェインの設定を助ける。

[原文へ]

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

暗号通貨バブルはイノベーションを絞め殺している

以前からバブルかもしれない、バブルっぽい、と言われてきたが、いや間違いなくバブルだ。しかしこれは良いことでもあると擁護する声もある。これまでバブルは必要な分野に注目と資金を集めるために役だってきた。バブル投資がインフラを作り、それが結局イノベーションの基礎となった、というのだ。

たとえばドットコムバブルだ。大勢の投資家が金を失ったが、これによって全世界がファイバー回線で結ばれ、安価なデジタル通信が可能になった。AmazonやGoogleが登場したのも結局はドットコムバブルの遺産だ。最近の暗号通貨バブルも同じようなものだ…というのだが。

しかし私の意見ではこうした合理化の試みは脆いものだ。なるほど部分的には正しいが、それ以上のものではない。暗号通貨の現状をみると、投機的利用法が他のあらゆる利用法を押しのけてスポットライトを浴びている。現在の暗号通貨の価値上昇はもっぱら投機によるものだ。

ほとんどの「暗号通貨トークン」は大げさに飾りたてられているものの、Ethereumのブロックチェーンに格納されたハッシュ値にすぎない。実際の内容は「アドレスA:10,000、アドレスB: 20,000」といった数字の列で、標準的な規格( ファンジブル・トークンならERC20、非ファンジブル・トークンならERC721)でコード化されて取引の容易化が図られている。

つまりEthereumブロックチェーンで実行されるあらゆる取引はその時価に比例した手数料がかかる。時価がロケットのように急上昇しているので(この記事を書いている時点で1000ドル)、これに歩調を合わせてEthereum上の取引の手数料は平均して2.50ドルにまでアップしている。

ハッシュ値生成に必要な計算量に比例してgas(手数料)を決定するメカニズムも実際にはあまり助けにならない。手数料は需要と供給によって決定される。これはEthereumだけではなく、BlockstackのDNSもBitcoinブロックチェーンに依存している。Bitcoinの取引に必要なコストもBitcoin価格と共に青天井で上昇中だ。

ともかく相場で一儲けを狙って何千ドルか何万ドルかの価値のトークンを取引しているなら手数料が高騰しても構わないかもしれない。しかしブロックチェーンのメカニズムを使って投機以外の目的のアプリケーションを書こうとすると事情は変わってくる。

もしブロックチェーンを利用して分散的な身元認証のようなサービスを作ろうとしても、そのコストは禁止的に高くなる。業者からブラウザが自動的に処理してくれるインターネット・ドメインを買うよりはるかに高いものになる。ユーザーが何らかのバーチャル資産を保有していることを証明するサービス、あるいは分散的ストレージへのアクセス・サービス等々を考えてみよう。トークンの取引はおろか、トークンを利用するという点だけで、そのコストは懲罰的から不可能までのさまざまな価格となるだろう。

つまりEthereumトークンを使って少しでも処理件数が多いサービスを作るという考えは忘れたほうがいい。そんなビジネスモデルはトークン価格の高騰により破滅的な結果をもたらす。Ethereumの場合、コストは常に送り手が負担するモデルであることもことをいっそう困難にする(ただしこの点については近く変更があるかもしれない)。逆に処理件数は極めて少なく、1件ごとの価値が極めて高いようなサービスなら可能だ。つまり現在のような投機だ。

Ethereumがトークン化のコストを劇的に下げる方法を考え出せば別だ。もちろん実験的サービスは多数作られてはいる。しかしほどんど誰も利用しない。こうしたサービスには好奇心の強いユーザーが近づいてみるものの、一回限りの実験にしても高すぎる手数料に驚かされている。まして日常利用するようなことにはならない。結果として、暗号通貨テクノロジーを利用する実験もイノベーションも投機バブルが破裂するまでは一時停止状態だ。

デベロッパーはブロックチェーン・テクノロジーを使ってアプリを書いても現実のユーザーが得られず、したがって現実のフィードバックも得られない。したがって新しい有望な応用分野を発見することもできない。ブロックチェーン・エコシステムの大陸は厚い氷河に覆われて活動を停止しているのが実情だ。

長期的にみて現状より桁違いに低い手数料が可能かどうかということも不明だ。 たとえばマイクロペイメント場合、普及にあたって最大の障害は手数料やインフラそのものより、むしろマイクロペイメント・サービスを利用しようというインセンティブの不足にある。AngelListのParker Thompsonはマス市場で成功する唯一の方法は手数料ゼロの分散的アプリが登場することだと論じている。この主張は正しいと思うが、手数料がゼロになった場合、ブロックチェーンを利用したスパム取引を判別したり防止したりできるのかという別の疑問が生じる。

しかし現状ではこれはあまり現実的な意味が議論だ。誤解しないでいただきたいが、私は手数料アポカリプスによって暗号通貨テクノロジーは永遠に呪われているなどと主張しているわけではない。現に、sharding, Raiden, PlasmaなどEthereumをスケールさせるための興味深い研究や開発が数多く行われている。こうした研究に対する期待は十分に高い。

しかしそうした新しいEthereumがロールアウトするまでは、暗号通貨に対してはきわめて注意深くあるべきだろう。株の値動きについて「市場は最初は投票だが最後は秤りになる」という言葉がある。つまり最初は人気投票のように動くがやがって実質を見るようになるという意味だ。現在、投機以外の暗号通貨トークン・プロジェクトは無期限の冬眠を強制されている。 本当にイノベーティブなサービスを作ろうとしているチームにとって、現在の暗号通貨バブルが弾けることは冬ではなく、むしろ春の到来を告げるものだ。

画像: Bitterbug/Wikimedia Commons UNDER A CC BY 2.0 LICENSE

[原文へ]

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

スペクター! メルトダウン! カーネル・パニック!――今回の脆弱性はほぼ全員に影響が及ぶ

新たななコンピューター脆弱性をめぐって昨日(米国時間1/3)から発生している記事、声明、論文の雪崩に当惑している読者も多いだろう。これらには相互に矛盾する主張も多い。ほぼあらゆるコンピューターとOSに影響するMeltdownとSpectreという2つの欠陥は一体どんなどんなものなのか? 昨日の記事に引き続き、さらに詳しく現在判明している情報を紹介する。

どんな欠陥なのか?

要約:コンピューター・アーキテクチャーの本質的な欠陥により、プロセッサーのもっとも深いレベルに位置する重要情報へのアクセスが可能になる。


セキュリティー専門家は公式文書を発表して問題を確認している。 深刻な2つの脆弱性にはそれぞれ名前とロゴが与えられている(上の図で左がMeltdown、右がSpectre)。この欠陥は現在利用されているほとんどあらゆる中央演算処理装置―CPUに影響を与えている。

これらはCPUの物理的機能に関連する問題ではないし、WordやChromeにもときおり見られるようなプログラミングのミスによるソフトウェアのバグでもない。これは現代のCPUのアーキテクチャーそのものに内在する問題だ。

現代のCPUアーキテクチャーにはあらゆるデータが生で、つまり暗号化されずに処理される部分が存在する。このスペースは当然不可侵の領域でなければならない。CPUのアーキテクチャーの根本をなす部分、カーネルがそうした領域だ。またシステム・メモリー中にも他のアプリケーションからアクセスできないよう慎重に隔離された領域が存在する。これらの領域内のデータは機密であり、他のアプリケーションやプロセスからアクセスできないよう強力な保護壁が設けられている。

MeltdownとSpectreは セキュリティー専門家が発見した2つの攻撃手法。これらはデータ保護機能を回避してコンピューターが処理するほとんどあらゆるデータへのアクセスを可能にする。つまりパスワード、暗号化データ等の決定的に重要な情報もすべて他のプロセスからアクセス可能となる。

MeltdownはIntel CPUに固有の弱点で、カーネル・メモリー中のデータを保護する機能を迂回する。Intelプロセッサーではカーネル中のあるプロセスが偶然他のプロセスに干渉したり、悪意あるソフトウェアが権限のないデータにアクセスすることを防ぐため、アプリケーション領域とOS領域の間に障壁が設けられている。Meltdownはこの障壁を迂回して保護を無効化する。

SpectreはIntel、AMD、ARM各社のプロセッサーに影響する。つまりデスクトップ・コンピューターだけでなく、各種のモバイル・デバイスその他なんであれCPUが内蔵されているすべてのデバイスが対象となる。つまりスマート・サーモスタットや赤ちゃん見守り用ウェブ・カメラも含まれる。

SpectreはMeltdownとは異なり、アプリケーション間に設けられている障壁を迂回するためにある種の巧妙な罠を仕掛ける。これにより通常であれば他のプロセスからアクセスすることが不可能な領域にあるデータをアプリケーションに暴露させる。現代のコンピューターに多く見られるマルチコア・アーキテクチャーをベースにしているため実行はMeltdownより困難だが、同時にこの脆弱性を取り除くことを一層困難にもしている。

誰が影響されるのか?

要約: コンピューターのユーザーほぼ全員。


2011年に製造されたチップもテストされ、これらの脆弱性を持っていることが確認された。理論的には1995年以降に製造されたCPUすべてが影響を受けているとされる。

繰り返すがMeltdownとSpectreはCPUアーキテクチャー上の弱点であり、チップ・メーカー側の人為的ミスによるバグではない。またWindows、OS X、AndroidはじめあらゆるOSプラットフォームが等しく対象となる。

理論的にはデスクトップ、ノート、サーバー、スマートフォン、組み込みデバイスその他あらゆるデバイスが影響される。簡単にいえば、テストの結果安全だと確認されたプラットフォーム以外はすべてこれらの脆弱性を持つと考えるべきだろう。

Meltdownはまたクラウド・プラットフォームにも影響する点で深刻だ。ただしMeltdown攻撃をリモートで実行するのは非常に困難だという。これはクラウド・サービスにとってグッドニュースだ。

対策はあるのか?

要約:: 完全にではないが修正できる。ただし時間がかかる。


上述のように影響されるデバイスの数は膨大だが、だからといってこうしたデバイスが無防備だというわけではない。またIntel、AMD、ARMその他のチップ・メーカーは数か月にわたって「緩和策」(簡単にいえば絆創膏)を開発してきた。

カーネルのメモリ間の障壁を強化することがMeltdown対策となる。技術用語では「カーネル・ページ・アイソレーション」という。ただしこれには副作用もある。現代のCPUアーキテクチャーはカーネルの動作にある前提を設けている。この前提を変えることはCPUの処理効率を落とすことになる。

Meltdown脆弱性の修正策がチップのパフォーマンスに与える影響は少ない場合で5%、最大で30%に上るものとみられている。いずれにせよなにがしかのパフォーマンス低下は避けられない。しかし脆弱性を取り除くことができるのであればやむを得ない代償だろう。

これと違って、Spectreには当分の間根本的な解決策は得られそうにない。Spectre攻撃はCPUの物理的特性に極めて密接に関連するため、セキュリティー専門家もソフト的にこれを完全に避ける方策を発見することはできなかった。いくつかの回避策が提案されているものの、結論はこうだ。

前節で紹介した一時的回避策は現実の攻撃を短期間防止する役に立つはずだ。しかし今後書かれるコードについてはもちろん現に存在するコードについても、どんな構成であればCPUにとって安全であるか(それとも危険であるか)を判断する方法は知られていない。

今後どのような対策が取られるか予測することは難しいが、もっとも大きな被害をもたらしそうな攻撃を防止するためのソフトウェアのアップデートが相次ぐだろう。MicrosoftはすでにWindows OSに対してアップデートをリリースしている。ARMも一連の緩和策を用意している。Amazonはクラウド・サービスの膨大なサーバー群をアップデート中だ。【略】

ひとつはっきりしているのはデバイスのリコールはないということだ。Samsungのスマートフォンのバッテリー問題のように、問題が特定のハードウェアの特定の部品にある場合、リコールはあり得る。しかし今回の問題で影響されるのは何億ないし何十億にも上る膨大なデバイス群なのでリコールはあり得ない。

なぜ今突然報道されたのか?

要約: チップ・メーカーは来週合同で発表を予定していたがメディアに先回りされた。


実はチップメーカーは数か月前にMeltdownとSpectreという脆弱性について報告を受けていた。セキュリティー専門家は以前からこの問題に注目し研究を続けていた。脆弱性の内容自体は秘密にされていが、理由不明のアップデートが相次いだことで、外部にも少しずつ情報が漏れ始めていた。

仮にセキュリティー専門家が脆弱性を発見すると同時に、たとえばTwitterでそれを公開したとすれば、CPUメーカーよりむしろ悪意あるハッカーを利するだけに終わっただろう。セキュリティー上の問題では情報は「責任ある公開」が求められる。つまりまずそのプロダクトを提供しているメーカー、ベンダーに秘密に通知し、必要なら対応策の開発に協力するわけだ。

今回のケースではGoogleは数か月前にIntelにコンタクトを取っている。もちろん程度の差はあれ、問題の存在を知っていたメーカーは多いはずだ。Microsoftが理由を明かさずにパッチをリリースしていたのもその一例だろう。Linuxの各種ディストリビューションも、脆弱性については詳細を示さないまま、アップデートを行っていた。

セキュリティー問題ではメーカーやベンダーが対応策を得て密かにアップデートを完了して初めて脆弱性の存在が告知されるのが通例だ。今回もその方式を取ることが予定されていた。

しかしThe Registerがいくつかの情報をつなぎ合わせスクープ記事を出した。そのためIntelは来週に予定していた共同発表の前に急きょ「報道は不正確だ」という反論の声明を発表するなどの対応に追われることになったわけだ。

The Registerはセキュリティー問題に関する通例を守るべきだったという声もたしかにある。しかし一方でIntelなどの巨大企業が情報を全面的にコントロールするという状況も好ましくないだろう。もしスクープがなければこの問題に対する関心も現在のように高まることはなかったはずだ。

いずれにせよ、セキュリティー専門家はSpectreを説明した論文の結論として次のように述べている。

この論文で検討した脆弱性は、他の多くの脆弱性と同様、パフォーマンス向上を至上命令として開発を行ってきたテクノロジー業界の長い伝統に根ざすものだ。この結果、CPU、コンパイラ、ドライバー、OS、その他すべての重要な要素が最適化のために複雑にレイヤー化され、セキュリティー・リスクを生じさせることとなっている。パフォーマンス向上の代償としてセキュリティーを犠牲にするこのようなデザイン手法は見直しの時期に来ている。多くの場面でセキュリティーの最大化を目的とする実装が求められるている。

[原文へ]

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

Appleがアプリ開発支援サービスBuddybuildを買収、デベロッパー環境の一層の充実へ

【抄訳】
Appleは、同社プラットホームのためのアプリの制作と改良過程をより容易にするためのデベロッパーへの奉仕努力を、継続的に強化している。この、iPhoneを抱える巨大企業が、今度はバンクーバーに拠を置くアプリツールの開発企業Buddybuildを買収した。“モバイルのイテレーションプラットホーム”を自称するBuddybuildは、継続的インテグレーションとデバッグのためのツールが主製品で、それらによりアプリの開発チームに、シンプルなワークフローによるイテレーションと、GitHubやBitBucket, GitLabなどによるグローバルなコラボレーションを可能にする。

Appleは本誌TechCrunchに対してこの買収を確認し、またBuddybuildは今日(米国時間1/2)の午後同社のブログで発表した。

買収の財務的条件は公開されていない。Appleによると、現在約40名のエンジニアチームはそのままバンクーバーに残る。このことをBuddybuildは、“カナダの企業であり続けることを誇りに思う”、と自画自賛している。

今回の買収により、BuddybuildはAppleのiOS, macOS, watchOS, tvOS用開発ツールXcodeに統合される。ただしその具体的なタイムラインは、両社ともに明らかにしていない。

既存の顧客はBuddybuildのサービスを同社のサイト上のスタンドアロンのプロダクトとして利用継続できるが、新規の顧客は今日から同ポータル上で受け付けられない。

また今回の買収によって、Buddybuildが昨年2月に加えた、Androidアプリ開発のサポートは終了する。その正式終了は、3月である。Appleは、TestFlightを買収したときもAndroidの互換性を中断し、Googleのエコシステムから継承していた重要な開発ツールを実質的に取り去った。

BuddybuildのシステムはAppleの既存のツール集合に、モバイルアプリのプロプライエタリなチャネルからの試験、デバッグ、およびデプロイのための方法を加えることになる。

さらに加えて、iOSのための開発とイテレーションが、前よりもずっと容易になるだろう。

マーケットシェアではAndroidに負けているiPhoneも、アプリの売上では勝っている。App Annieによると、2017Q3のモバイルアプリの(中国を除く)グローバルな売上は170億ドルだが、そのうちの約110億ドルをAppleが占める。

ただしアプリのダウンロード総数ではGoogleに負けているので、Appleとしては、もっとデベロッパーフレンドリーな開発環境を充実整備していく必要性を痛感しているだろう。

【中略】

Buddybuildは2015年に元Amazon社員Dennis PilarinosとChristopher Stottが創業した。同社はその後3年間でおよそ880万ドルを調達し、その中にはKleiner Perkins Caufieldがリードした2016年のシリーズA 760万ドルも含まれる。

FlickrとSlackを創ったことで有名なStewart ButterfieldがしばらくBuddybuildのアドバイザーだったし、Slackは同社の著名な顧客のひとつだ。ほかにもMozilla, Hootsuite, Reddit, SoundCloud, FourSquare, The New York Timesなどの著名企業が同社の顧客リストに名を連ねる。

Buddybuildは同社のブログ記事で、バンクーバーは今やソフトウェア開発の温床であり、今回のAppleからの新たなキャッシュにより、成長のための人材確保もやりやすくなった、と言っている。

この記事は本誌ライターIngrid Lundenとの共作である。

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

アナリティクスダッシュボード作成プラットホームKeen IOがScaleworksの傘下に

非上場企業に主に買収という形で投資をしている、テキサス州サンアントニオのプライベート・エクイティ企業Scaleworksが、休日明けを待ちかねたかのように、同社の最新の買収のニュースを共有した。同社は昨日(米国時間12/22)のMediumのブログ記事で発表したのはKeen IOの買収だ。

買収価額などはは公表されていないし、両社からコメントも得られていないが、Keenは2011年に創業されてからこれまでに3000万ドル近くを調達している。

Keen IOは、デベロッパーがカスタムなアナリティクスダッシュボードを(自分のアプリケーションのために)作るためのツールを作っている。ScaleworksのゼネラルパートナーEd Byrneは、買収の発表声明でもあるブログ記事の中で、Keen IOについて次のように説明している:

“Keen.ioは2011年に創業され、デベロッパーがカスタムなアナリティクスバックエンドを作るための便宜を提供している。同社を利用して企業は、チームや顧客のためのあらゆる種類のアナリティクスを容易に構築して自分のアプリケーションに埋め込むことができ、またお気に入りのSaaSツールにアナリティクスダッシュボードをつけることもできる”。

Byrneはさらに、これまで同社が扱ってきた企業の多くがKeen IOを使ってダッシュボードを作っていることを、長年見てきたので、かねてから同社に着目していた、と述べている。しかしもちろん、Scaleworks傘下の企業ばかりではない。Keen IOのWebサイトによると、今、3500社、約50000名のデベロッパーが、Keen IOのツールを使ってダッシュボードを作っている。その中には、EMC, Adobe, Kik, Pandora, Ticketmaster, Freshdeskなどの著名企業もいる。

同社は2015年に、その中心的なツールData Explorerをオープンソース化し、ユーザーがこのデータ探究ツールを自由に改良できるようにした。同社の最新の資金調達は、2016年の、Pelion Venture Partners率いる1470万ドルだった(CrunchBaseによる)。

ScaleworksはB2BやSaaS企業に的を絞ったプライベート・エクイティ企業¶で、これまでChargify, Earth Class Mail, Assembla*, Filestack, Followup, Qualarooなどに投資/買収してきた。〔*: Assembla日本語記事

〔¶: private equity firm: 非上場企業を対象とする投資会社、主に買収という形が多い。〕

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

Apple、批判の的のテンプレート・アプリ禁止条項を修正――実質はほぼ変化なし

Appleは昨日(米国時間12/20)、App Storeにおけるアプリ・レビューのガイドラインを修正した。このガイドラインはテンプレートその他を用いるアプリ・ジェネレーション・サービスによって作成されたアプリの登録を禁止するもので、大きな議論を引き起こしていた。

Appleが今年に入ってApp Storeの利用規約を改正したのは低品質のアプリやスパム・アプリが登録されるのを防ぐ狙いがあった。しかしこの方針は 当初の目的を超えてはるかにおおきなマーケットに影響を与えることになった。つまりレストラン、NPO、クラブ、その他、オリジナルかつ高品質のアプリをインハウスで開発する専門知識、資金その他のリソースを持たない各種スモールビジネスがネガティブな影響を受けている。

Appleの新しいガイドラインは「App Storeで受け入れられないアプリ」の定義をさらに詳しく述べている。

改正前のガイドラインの当該部分、4.2.6 App Store guidelineは以下のとおりだった。

4.2.6 商用のテンプレートによって作成されたアプリ、またはアプリ・ジェネレーション・サービスによって作成されたアプリは受け入れられない。

これに対して、今回改正された文言は以下のとおり。

4.2.6 商用のテンプレートによって作成されたアプリ、またはアプリ・ジェネレーション・サービスによって作成されたアプリは受け入れられない。ただし、アプリの登録がアプリのコンテンツ提供者自身によって直接申請される場合はこの限りではない。〔アプリ・ジェネレーション・〕サービス等はクライアントを代理して登録の申請を行ってはならない。また〔これらのサービスは〕クライアントがカスタマイズしてイノベーティブかつ独自のユーザー体験を提供するアプリを作成できるツールの提供に努めなければならない。

テンプレートのプロバイダーはクライアントのコンテンツを一つのバイナリーに統合するいわゆる“picker”モデルを利用することもできる。たとえばレストランの情報アプリであれば、それぞれのクライアントのレストランがが独立のカスタマイズされたページを持つ単一のアプリを登録申請することは可能であり、イベント情報アプリであれば、それぞれのクライアント・イベントが独立のページとして表示されるような単一のアプリを登録することはできる。

これによってAppleがテンプレート・アプリについてどう考えているかがよく分かる。

根本にある考え方は、スモールビジネスがテンプレートや仲介者(アプリ作成サービス事業者)を通じてアプリを作成するのはかまわないが、テンプレートのプロバイダーが実際のビジネスに代わってアプリを登録することをは許されない、というものだ。

AppleはApp Storeに登録されるアプリはコンテンツの元となるビジネス自身が登録申請すべきだと考えている(この考え方は以前も述べられていた)。つまり、地域のピザショップであれ教会であれフィットネス・ジムであれ、アプリを登録しようとする組織はApp Storeのガイドライン、規約その他の文書を熟読し、登録プロセスに積極的に関与しなければならないということだ。

Appleでは2018年早々にもアメリカ政府・自治体諸機関およびNPOについて99ドルのデベロッパー手数料を免除してこの新方針を受け入れやすいものにするという。

またテンプレート・サービスのような仲介者もすべて排除されるわけではない。テンプレート・サービスがアプリを作成する手助けをするのはけっこうなことだ―Appleはアプリが「どのようにして」作成されたかにはさして興味を抱いていない(ウェブページを単にアプリ化したものでないかぎり)。Appleが審査するのは「その結果」だ。

App Storeに登録されるためには、アプリは高品質で優れたユーザー体験をもたらさねばならないというのがAppleの考え方だ。つまりアプリにはそれぞれ独自性が必要であり、多数のアプリがそっくりな外見を呈してはならない。つまり互いにクローンであってはならない。また、されに重要な点は、ウェブページやFaceookページをそのままアプリ化したものであってはならないということだ。

Appleは「アプリは単なるウェブページ以上の深く豊かな体験をユーザーに与えるものでなければならない」と信じている。

上図:AppMakrで作成されたThe Official Lumineersアプリ

ただし、このルールが適用されるべき範囲を巡っては見解の相違が残る。

たとえば、現在多くのユーザーが「テンプレート・アプリ」を使っている。お気に入りのタコショップ、所属する教会、地元の音楽クラブ、学校、その他のアプリだ。ユーザーはこれらのアプリが単一のテンプレートから作成され、相互にそっくりだと知らないし、知ったところでそもそもそんなことは気にかけないだろう。

またある種のアプリが互いにそっくりであることはユーザーにとってかえって使いやすくなっているという議論もある。たとえば「モバイルから注文」がそれぞれ独自のデザインで独自のプロセスだったら使いにくいだる。どこからメニュー表示をさせればいいのかアプリごとに探す必要があるのがユーザー体験の向上だろうか?

しかしAppleはApp Storeに無数のコピーキャット、クローン・メーカーがはびこっっているのを強く嫌っている。クローン・アプリが優勢になれば、わざわざ高品質のアプリを作成するデベロッパーが不利になる。テンプレート・プロバイダーが単一のデベロッパー・アカウントで一挙に2万件ものアプリを登録するといった事態はApp Storeを窒息させかねない、と考えている。

しかし低品質のアプリの大群を規制する必要があるにせよ、App Storeにおけるテンプレート・アプリ全般の禁止は行き過ぎでありエコシステムにネガティブな影響を与えるとする意見も強い。

この問題はTed W. Lieu下院議員( カリフォルニア、33選挙区) の注目を引いた。Liew議員はAppleについて「〔規制の〕網を広げ過ぎている」と述べた。スパム・アプリ、違法アプリの排除の必要は認めるものの、「App Storeに対しなんら危害を加えておらず、これまで長年にわたって役立ってきた正規のデベロッパーを排除するものだ」とLiew議員は批判している。

しかし一方でAppleはネット中立性を支持して、何人も平等かつ自由なインターネットへのアクセスの権利を持つと主張している。にもかかわらずApp Storeレビューの新しい方針はスモールビジネスや小規模なNPOに対して不利に働く。しかもモバイル・デバイスからウェブへのアクセスは次第にモバイル・アプリを経由する傾向を強めている(上記グラフ参照。ブラウザは時代遅れになりつつある)。【略】

なるほど、ピザショップはUber Eatsを使うこともできる(高額な手数料を払えばだが)。ネールサロンは店をYelpに掲載できるし、パパママ・ストアもFacebookページを作れる。また事実作っているだろう。しかし全体としてこれはスモールビジネスが巨大アグレゲーターの支配下に置かれるるという傾向をますます強めるトレンドだ。

最近、TechCrunchはApp Storeにアプリを登録している多くの会社が 2018年1月1日という締め切りを言い渡されたことを報じた。この期限までにアプリを新しいガイドラインに対応させないかぎり、レビュー・チームはアプリをApp Storeから排除するという。一部のアプリはすでにこの禁止条項を適用され、登録申請を却下されている(すでにライブであるアプリは次のアップデートまで適用を除外されているが、この状態がいつまで続くのかは不明だ)。

Appleの新方針のために一部の会社は運営停止に追い込まれている。

今回修正された後の字句をみても、影響を受けた会社が以前のとおり運営を続けられるようになったとは思えない。 こうしたサービスはやはり「クライアントがカスタマイズしてイノベーティブかつ独自のユーザー体験を提供するアプリを作成できるツール」を新たに提供する必要がある。

言い換えれば、Google Sites のようなシンプルな構成ではなく、Squarespaceのような凝った構成にせよ(ただしアプリだが)ということだ。

テンプレート・ベースのアプリの例。 一般ユーザーはテンプレートだと気づくだろうか?

しかし今回影響を受けた会社は、すべてがスパム・メーカーというわけではない。一部はウェブページをラップしてアプリにするだけのツールを提供していたものの、一部はグレーゾーンだった。

これにはChowNowのような、特定のバーティカルに属するスモールビジネスがApp Storeを利用することを助けようとするものが含まれる。CowNowは近隣のレストランがモバイル経由で注文を受けるためのアプリだが、同様のアプリはフィットネス・ジムや教会、スパ、コンサート、政治家など非常に幅広い分野に存在する。

こうしたビジネスはApp Storeガイドラインの4.2.6(ときおり4.3)項によって登録を拒絶されつつある。こうしたアプリの申請者によれば、Appleに対し電話などで直接説明を求めようとしても困難だという。

修正以前の4.2.6項は、テンプレート・ベースのアプリ全般を禁止し、4.3項はスパム・アプリ全般を禁じる網羅的条項だった。4.3項はAppleがあるアプリを排除したいが、アプリ作成ウィザードやドラグ・アンド・ドロップなどによって一挙に作成されたものだということを証明できない場合に用いられることを意図したものだということだ。

  1. screen-shot-2017-12-20-at-3-41-33-pm.png

  2. screen-shot-2017-12-20-at-3-41-42-pm.png

Appleがこの方針をWWDCで発表したとき、テンプレート・プロバイダーの多くは自分たちに影響が及ぶとは考えていなかった。この禁止方針はクローン・アプリ、スパム・アプリを締め出すためのものだと考えたからだ。そのため、App Storeのレビュー・ガイドラインがテンプレート・プロバイダー自身もApp Storeから締め出されれることを明らかにしたためパニックが広がった。これらのテンプレート・プロバイダーは自分たちがスパマーだとは考えていなかった。

修正後のApp Storeのガイドラインは、字句の訂正により明確化されているものの、本質的なAppleの意図は変わっていない。

ともあれアプリが実質的にはウェブページそのものである場合、あるいは他のアプリとデザインがそっくりである場合、申請の手間をかけるには及ばない。App Storeがそういうアプリを排除することは動かない。

[原文へ]

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

外出先などでモバイルからVCSのリポジトリを管理できるAssemblaのiOSアプリ

ソフトウェア開発は必ずしも、モバイルに向いている仕事とは言えない。仮想キーボードと小さな画面で誰が一体、コードを書きたいだろうか。でも、コードを管理したり、出先でファイルの更新履歴を確認したいとき、デスクトップやラップトップがなければだめ、では困る。そこで、クラウドベースのエンタープライズ向けバージョンコントロールサービスで、GitHubのコンペティターでもあるAssemblaが今日(米国時間12/14)、iOS用のモバイルアプリ発表した

Assemblaのユーザーはこのアプリを使って、GitやSubversion、PerforceなどのリポジトリをiPhoneやiPadから容易に管理できる。いろんなファイルのリビジョンを比較したり、コード中のテキスト文字列でファイルを検索したり、ファイルの詳細なリビジョン履歴(誰が何をしたか)を調べたりできる。

とくに便利なのは、ファイルがリポジトリに加わったり削除されたり変更されたとき、プッシュ通知が来る設定ができることだろう。SVN(Subversion)のロック操作もモニタできる。

このアプリを利用してコードを書きたいとは誰も思わないだろうが、ざっとコードレビューをしたり、簡単なコミットぐらいなら十分できるだろう。ただしこのアプリは現状ではAssemblaのリポジトリしか管理できないよう、ロックされている。しかし自分のGitHubアカウントをモバイルから管理したければ、そのためのモバイルアプリはいくつかすでにある。でも、Assemblaのプロダクト担当VP Laith Dahiyatが、“ユーザーの要望が多ければ、それを無視することはない”、と言っているから脈はあるね。

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

Amazon、AWS Cloud9をリリース――デベロッパーはブラウザからクラウドソフトの開発ができる

今日(米国時間11/30)、ラスベガスで開催されている恒例のre:Inventカンファレンスで、ブラウザ版のIDE、AWS Cloud9をリリースしたと発表した。Cloud9はAmazonが去年買収した IDEで、Ace Editorをベースとしている。Cloud9での作業はc9.io IDEを使う。

TechCrunchがAWSによるCloud9の買収を最初に報じたとき、Amazonは確認を避けた。しかし今や確認できたといっていいだろう。

Cloud9そのものは、Sublime Textなどこの種の他のIDEと根本的に異なるわけではない。しかし今日のイベントのキーノートでAWSは複数のデベロッパーによる共同作業に適していること、AWSのエコシステムに深いレベルで統合されていることをCloud9のメリットとして強調した。このツールには JavaScript、Python、PHPを始めとする言語のサポートがビルトインされている。またデバッグ・ツールもプレインストールされている。

AWSはこのツールは「最初のクラウド・ネーティブのIDEだ」と主張したが、この点についてはやや疑念が残る。既存のライバルにもクラウド対応機能を持つものはある。しかしCloud9がAWS環境に統合されていることは事実だろう。「デベロッパーはCloud9を用いてクラウドベースのソフトウェアを開発できるだけでなく、そのソフトをCloud9内からAWSのインスタンスとして動かすことができる」とAWSのCTO、ヴァーナー・ヴォーゲルズは強調した。Cloud9はラムダ関数のデバッグをサポートしているので全面的にサーバーレスを目指すデベロッパーにとっては好都合だろう。

いずれにせよCloud9の最大のセールスポイントはAWS自身の製品であることだろう。MicrosoftやGoogleなどAWSのライバルがやはりクラウドやモバイルのデベロッパー向けにそれぞれ自社のIDEを提供しているのも全く同じ理由だ(ただし、たとえばMicrosoftのVisual Studioには多数のサードパーティーのサービスが統合されている)。

〔日本版〕Cloud9は現在US West (Oregon)、US East (Ohio)、US East (N.Virginia)、EU (Ireland)、Asia Pacific (Singapore)の各リージョンで利用できるという。AWSにアカウントがある場合、サイインインしてこちらからダウンロードできる。



[原文へ]

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

Amazon、re:inventカンファレンスでグラフDB、Neptune発表

Amazonは開催中のAWS Re:INVENTカンファレンスで次々の新しいサービスを発表している。さきほど紹介された新しいデータベース、Amazon Neptuneは特にグラフ関係の処理を目的としたサービスだ。もしサービスにソーシャルネットワーク的要素を組み込もうとしているならこのデータベースは役に立つかもしれない。

伝統的なリレーショナルDBの問題点は、もともと複雑なソーシャルグラフを扱うようにデザインされていないことだ。RDBでは友達関係やフォロー関係のリストを扱うのが難しい。たとえばソーシャルグラフから共通の友達を抽出しようとすると、そのたびにきわめて複雑なクエリーを発行する必要があった。

これまでのやり方でこの問題を解決するにはコンピューティング能力をアップするしかなかったが、Amazon Neptuneはソーシャルグラフ処理に特化したデータベースの提供で応えようとするものだ。
Neptuneは数十億に上るソーシャル関係を処理するために最適化されており、一つのクエリーを処理するのに1000分の1秒単位の時間しかかからない。Neptuneは問題発生時の高速切替、過去の一定の時点へのリカバリー、異なるアベイラビリティー・ゾーンへのバックアップを作成などをサポートする。現在使用されていないデータの暗号化も可能だ。

Amazonでは既存のテクノロジーとNeptuneの互換性に配慮している。Neptune DBサービスはグラフモデルとしてProperty GraphとW3CのRDF(Resource Description Framework)、これに準拠したクエリー言語のApache TinkerPop GremlinとSPARQLをサポートする。

グラフデータベースがソーシャルネットワークやデートアプリで有用なのはもちろんだが、商品などを推薦するレコメンデーションエンジン、ロジスティクス、DNAのシークェンシングなどそれ以外にも多数の応用場面があるはずだ。この数か月、有力企業がNeptune採用に踏み切るか動向に注意する必要がある。さらに詳しい情報はこちら

〔日本版〕AWS は現在限定プレビュー中。上のリンク先から試用の申し込みができる。

Featured Image: Hoxton/Tom Merton/Getty Images


[原文へ]

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

ソフトウェアの複雑さを「意図指向プログラミング」で管理する

【編集部注】著者のUri SaridはMuleSoftのCTOである。(この著者による他の記事:The last thing the API economy needs is copyright friction

ソフトウェアの魔法は失われつつある。私たちが単に現在のアプローチから多くを望みすぎているのだ。結果として、ソフトウェア開発者たちは複雑さとの戦いに敗れつつある。そしてそれはしばしば自覚されていない。しばしば、小さな失敗が他の小さな失敗の上に積み重なり、消費者の生活だけでなくビジネスシーンも、簡単になるというよりも不満が募るものとなる。

たとえば、Appleの製品はバギーなものになりつつあり、旅行は今だに悪夢であり、コールセンターでの経験は、私たちに人工知能と人間知能の両方を疑わせるものになっている。

魔法をソフトウェアに取り戻すためには、開発たちは、望ましい結果を得るためにシステムの中を一歩一歩歩き回ることを、やめる必要がある。その代わりに、システムが分刻みで大規模かつ複雑になる中で、開発者たちは、レイヤーの利用、意図指向(intent-oriented)アルゴリズム、そして人工知能(AI)を利用して、ソフトウェア自体をより自律的なものにする必要があるのだ。

1歩下がって眺めてみるならば、魔法の一部が失われているのはさほど驚くべきことではない。私たちはソフトウェアへの期待を大きく高めたが、その一方で誰がそれに命じることができるのかについての期待も同時に広げてきた。これまで以上に多くのことが自動的に「ただ上手く動く」ことを期待され、ますます多くの人びとが、デジタルライフとデジタルワークの自動制御をコントロールできるようになる筈だと期待している。

ソフトウェアが対処しようとしている課題が、静的なものである場合でさえ、そうした期待に応えることは相当に難しい。しかし、この自動制御は、リアルタイムの要求に応えることも期待されているのだ――それは自動制御が実行されている最中にも、パラメーターたちが急速に変化する世界である。

交通状況、天候状況、工事状況に対応しながら、A地点からB地点へと車をナビゲーションすることは十分に難しい課題なのだ。あるいは、通勤途中の車の中で行われる電話会議、あるいは物理的およびデジタル商取引などの最適化はどうだろう?同じ道路を同時に利用している何百万台もの車でこれを行うにはどうすれば良いのだろう?車、電車、飛行機、ホテル、レストランなどを組み合わせた旅行のためにこれを行なうためには、どうすれば良いのだろう?

こうした要素たちは、これまでとは異なるプログラミングモデルを要求しているのだ。すなわち宣言的プログラミングモデルである。この代替モデルでは、私たちは手続きではなく「意図」(目標または最終状態)を宣言する。そしてソフトウェアシステムが自律的にその意図を「実現する」方法を見出すのだ。人間は境界と制約を設定するが、目標に到達するためのソリューションを、人間がいつでも発見できるとは期待できない。そこに、コンピューターが登場しその作業を行うのだ。

新しいプログラミングモデルは、コンピュータを活用してそれ自身の複雑さの課題を解決する。

この説明に便利なアナロジーは産業界ではお馴染みのものだ。目標による管理(MBO:management by objectives)である。強力なMBOとは、従業員たちに測定対象となる目標だけを与えることであり、その目標達成する手段を事細かに与えることはしない。目標は販売成績、顧客獲得数、あるいは製品の採用数などを中心に設定されるだろう。その目標を達成するための手段は、従業員たちに任される。予想外の条件変化が起きるために、それはしばしば柔軟な対応を必要とする。またそうした対応の過程で学習が行われて、時間とともに実行が容易になって行くのだ。したがって、ある意味では、この代替プログラミングモデルは、目標でソフトウェアを管理する手法なのだ。すなわち機械のためのMBOである。

この必要性の例はどこにでも見出すことができる。現在最もホットな分野の1つは、ボットや、音声ならびにテキストコマンドを受け付けるインターフェイスだ。現在のボットの多くはコマンド指向だが(例えば「LinkedInでJane Doeを探して下さい」といった命令)、それらは意図指向(intent-oriented)になる必要がある(例えば「適切な求職者を探して下さい」といった指示)。

新しい営業担当者、エンジニア、あるいはCIOを雇う必要があるとしよう。コンピューターの前に座って人材を探し出すためにウェブを眺め回す努力をするのではなく、その代わりにインテリジェントなチャットボットに対して肝心な仕事をして貰うように依頼するのだ。その依頼の裏側では、チャットボットはLinkedInとGlassdoorからの候補者たちを選び出すAPIにリンクし、候補者たちの情報をGitHubやMeetupを使って補足し、候補者たちに接触してその関心や適合性を測る。適切な候補が見つかると、チャットボットは、依頼側と候補者を結びつけて話を進める。経験を重ねるに連れて、チャットボットはどの候補者が良い候補者であるかを学び、探索する作業に熟達して行くのだ。未来の話に聞こえるかもしれないが、この採用方法は現在でも、既存のソフトウェアの適切な協調により実施することが可能だ。

ソフトウェアが、どのようにして複雑なシナリオを大規模な状況でも解決できるようになるのかを理解するために、私たち自身のビルトインコンピュータ(頭脳)が映像を処理する方法を参考にすることができる。

  • 第1レイヤーでは光は光受容体細胞によって吸収される。ここでは最小の処理のみが行われ、網膜の第2および第3の層に信号が渡される。

  • 第2および第3のレイヤーでは、ニューロンとガングリオン細胞が一緒に働いて、エッジまたは影を検出する目標を果たし、視神経を介して脳内に結果を送る。

  • 視覚野には、さらに多くのレイヤーがある。1つのレイヤーはオブジェクトがどこにあるかを計算する。別のレイヤーがエッジを検出し処理して形として取り出す。別のレイヤーはそれらの形を認識可能な物――例えば顔や物体など――に変換する。各レイヤーは時間が経つにつれて学習し、そのパフォーマンスを向上させる。

  • そして最後のレイヤーでは、そうした顔や物体を個人の記憶バンクの内容とマッチングを行い、その結果人間や物体が認識されたりされなかったりすることになる。

このようなアプローチ、すなわち「各レイヤーがただ1つのゴールだけを担当し、抽象度が高くなるにつれてゴールが段々と洗練されていくアプローチ」を使うことによって、ソフトウェアを意図に基づいたものとして構成し、複雑なシナリオを大規模に解決させることができる。マシンの世界で、各レイヤーは、重要なデータを提供するAPI、異なるシステムからのデータを統合する組み合わせサービス、そして各レイヤーでスマートな決定を行なうための人工知能といった形で提供される。

これがソフトウェアの未来だ。そしてその未来は既に始まっている。モダンで大規模に分散したクラウドシステム(例えばGoogleのKubernetesとそのエコシステム)や、自動運転車と自動飛行機、そしてもちろん私たちの増え続けるデジタルワールドの全てのレイヤーに浸透する人工知能や機械学習といった形で。

お互いに依存するシステム数や動的データ量の爆発、そして中核で解決されることが求められる期待の増加などによって積み上げられる複雑さのため、パラダイムシフトは避けることができない。新しいプログラミングモデルは、コンピュータを活用してそれ自身の複雑さの課題を解決し、人間が最も得意とすることに集中させる。すなわち「意図/目標は何か」を考えることだ。

[原文へ]
(翻訳:Sako)

Googleのチャットボット・ビルダーDialogflowに企業ユーザー向け有料バージョン登場

Googleが今日(米国時間11/16)、チャットボットやそのほかの会話的アプリケーションを作るツールDialogflowの、エンタープライズエディションの、ベータローンチを発表した

そして無料版も含めてDialogflowには、今や音声認識機能が内蔵されている。これまでデベロッパーは、その機能が欲しければGoogle CloudのSpeech APIや同様のサービスを使わざるをえなかった。当然ながら、内蔵化によって、一つのAPIを呼び出すだけになったので、スピードも(Google説では30%)向上した。

今のDialogflowにはさらに、GoogleのChatbaseサービスを呼び出すことによる、ベーシックなアナリティクスとモニタリングの能力もある。

Dialogflowは、Googleが昨年買収したときAPI.AIという名前だったけど、その後名前を変えた。でも変わったのは名前だけで、その基本的な考え方はなにしろ、会話的なエージェント(自律プログラム)やそのほかの、テキストや音声による対話を、使いやすい形で作りたい、と思ったときに使えるビルディングブロックを提供することだ。

このサービスはこれまでずっと、ユーザー獲得のために無料(ただし量制限あり)だったが、企業ユーザーは有料でもいいから24/7のサポートやSLA、企業向けのサービス規約、データ保護の約束、などがほしい。

そこで今度のDialogflow Enterprise Editionでは、これらすべてが得られる。Google Cloud AIのプロダクトマネージャーDan Aharonによると、このバージョンのDialogflowはGoogle Cloudの一員なので、前からGoogle Cloudを使っているユーザー企業なら、契約も使用開始も簡単だ。“もしもあなたがSpotifyなら、Google Cloudのプロダクトであるための要件をすべて、すでに満たしているから、Dialogflowをかなり容易に使える”、とAharonは語る。たとえばDialogflow Enterprise Editionのサインアップは、Google Cloud Platform Consoleのコンソールからできる。

有料とはいえ、テキストの対話一回につきわずか0.2セント、音声の対話リクエストは一回につき0.65セントだ。1セントにも満たない(量制限なし)。

これまでの無料バージョンのDialogflowは、どこにも行かない。エンタープライズエディションと同様、新たに音声認識も統合されており、14の言語をサポート、MicrosoftやAmazonなど、主なチャットや音声アシスタントのほとんどを統合している。その量制限は、1日に最大1000対話、1か月累計では15000対話までだ。

GoogleがAPI.AIを買収したとき、それはすでに、チャットボット作成ツールとして相当人気が高かった。そしてGoogleによると、その勢いは今だに衰えていない。GoogleのPRはAharonに、人気第一位のツールとは言うな、と釘をさしたらしいが、実際に人気一位であっても意外ではない。彼によると、無料バージョンだけの現状で登録ユーザー数(デベロッパー数)は“数十万”、今年のCloud Nextイベントを共有したデベロッパー数が15万だから、それよりずっと多いのは確実だ。

“顧客から何度も何度も聞く言葉によると、自然言語理解のクォリティーが高いので、Dialogflowはそのほかのチャットボットツールに大きく差をつけているそうだ”、とAharonは言う。“最良のツールでなければ、本番用(プロダクション用)には使えないからね”。(そうでない企業もあるみたいだが…。)

自然言語の理解以外にも、Cloud Functionsを利用してサーバーレスのスクリプトを簡単に書けるなど、Dialogflowはデベロッパーの自由度が大きい。ほかのアプリケーションへの接続も容易だ…それらがどこでホストされていても。だからたとえば、既存の受発注システムや発送システムと、これから作る会話的アプリケーションを統合することも可能だ。

Aharonによると、API.AIの機能をGoogle Cloudにポートするのに約1年かかった。そしてそれが完了した今では、このサービスはGoogleのAIや機械学習の機能をフルに利用できる。一方、今のGoogleはエンタープライズの顧客獲得が最重要の課題だから、Dialogflowをそのためのメニューの一員にするのも、当然なのだ。

[原文へ]
(翻訳: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

ソフトウェアのサプライチェーンを監視するためのAPI集合GrafeasをGoogleやIBMなど8社が共同開発

コンテナとマイクロサービスによって、ソフトウェアの作り方が急速に変わりつつある。しかし、どんな変化にも問題はつきものだ。コンテナが目の前にあるとき、それを誰が作ったのか、その中で何が動くのかを知りたいだろう。この基本的な問題を解決するために、Google, JFrog, Red Hat, IBM, Black Duck, Twistlock, Aqua Security, そしてCoreOSの計8社が今日(米国時間10/12)、共同のオープンソースプロジェクトGrafeas※を発表した(※: ギリシア語で“scribe, 書記官”の意味)。その目的は、ソフトウェアのサプライチェーンを検査し統轄するための標準的な方法を確立することだ。

併せてGoogleは、もうひとつの新しいプロジェクト、Kritis※を立ち上げた(※: ギリシア語で“judge, 鑑定人”の意味…Kubernetesの成功以来、Googleの新しいオープンソースプロジェクトにはほかの言葉を使えなくなったのだ!)。Kritisは、Kubernetesのクラスターをデプロイするとき、コンテナに一定のプロパティを強制する。

Grafeasは、コードのデプロイとビルドのパイプラインに関するすべてのメタデータを集めるための、APIの集合だ。そしてそのために、コードの原作者や出所、各コード片のデプロイ履歴〜デプロイ時の記録、どのようなセキュリティスキャンをパスしたか、どんなコンポーネントを使っているか(そして各コンポーネントの既知の脆弱性)、QAからの承認の有無、などの記録をキープする。そうすると、新しいコードをデプロイする前にGrafeasのAPIを使ってこれらの情報をすべてチェックでき、それが(得られた情報の範囲内で)脆弱性なしと認定されていたら、プロダクションに放り込める。

一見するとこれは、平凡すぎる感じがしないでもないが、でもこんなプロジェクトのニーズは確かにある。継続的インテグレーションや分散化、マイクロサービス、どんどん増えるツールセット、そして各種バズワードの奔流、といった動向の中でエンタープライズは、自分たちのデータセンターで実際に何が起きているのかを知ることに苦労している。今動かしているソフトウェアの本性を知らずに、セキュリティやガバナンスを云々しても空しい。そしてデベロッパーが使うツールは統一されていないから、そこから得られるデータもまちまちだ。そこでGrafeasは、どんなツールでも一定の標準化された、業界全員が合意しているデータ集合が得られるようにする。

Googleのオープンソースプロジェクトの多くがそうであるように、Grafeasも、この問題のGoogle自身の対処方法を模倣している。規模が大きくて、しかもコンテナやマイクロサービスを早くから採用しているGoogleは、業界全体の問題になる前にこれらの問題を数多く体験している。Googleによる本日の発表によると、Grafeasの基本的な内容は、Google自身がそのビルドシステムのために開発したベストプラクティスを反映している。

そのほかのパートナーたちも全員が、このプロジェクトにいろんなおみやげを持参している。しかしたとえばJFrogは、同社のXray APIにこのシステムを実装するつもりだ。Red Hatは、同社のコンテナプラットホームOpenShiftのセキュリティとオートメーションを強化するためにこれを導入し、CoreOSは同社のKubernetesプラットホームTectonicにこれを統合する。

Grafeasの初期のテスターの中には、Shopifyがいる。同社は現在、一日に約6000のコンテナをビルドし、それらが33万点の画像を同社のメインのコンテナレジストリに保存する。Grafeasがあると、たとえば、今どのコンテナがプロダクションで使われているか、それはいつレジストリからダウンロードされたか、その中ではどのパッケージが動いているのか、そして、コンテナの中のコンポーネントのどれかに既知の脆弱性はないか、などが分かる。

Shopifyは、今日の発表声明の中でこう言っている: “Grafeasによってコンテナの正確なメタデータが得られるので、セキュリティチームがこれらの質問に答えられるようになり、またShopifyでわれわれがユーザーに届けるソフトウェアの検査やライフサイクル管理に、適切な肉付けがなされるようになった〔形式だけではなくなった〕”。

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

GitHubがユーザーコードの安全でない依存性を警告、コードの見つけやすさも改善

オンラインのコードリポジトリGitHubが今週、例年のカンファレンスを開催している。テクノロジー業界の長年のやり方に倣って同社は、このイベントを利用してサービスの新しい機能をいくつか発表した。今回の大きなテーマは二つ、セキュリティと発見性(discoverability, コードの見つけやすさ)だ。

近年はハッキングの被害がますます増えているから、ユーザーから預かったコードのセキュリティをGitHubが重視するのも当然だ。同社がとくに問題にするのは、最近のプロジェクトの多くが非常に多様なサードパーティのライブラリなど、外部資源に依存していることだ。

そこで今回GitHubがローンチしたのが、“依存性グラフ”(dependency graph)だ。これによりデベロッパーは、自分のコードが利用しているほかのパッケージやアプリケーションを一望にできる。当面RubyとJavaScriptのコードだけだが、近くPythonもサポートされる。すべての依存性が一望的に分かれば、それを標準的な脆弱性データベースと対照して、やばいものが使われていたらデベロッパーたちに通知できる。GitHub自身の通知警報機能は“もうすぐ提供”だそうだから、それまでは各自の取り組みが必要だ。

GitHubのチームによると、同サービス上のプロジェクトの75%以上に何らかの依存性があり、その半分以上に10以上の依存性がある。そして依存性が100を超えるプロジェクトも、昨今では珍しくない。

発見性に関しては、GitHub上には今や2500万あまりのアクティブなレポジトリーがあり、デベロッパーが関心を持ったコードをその中に見つけるのが容易ではない。この状況を改善するために同社は、ニューズフィードを一新してリコメンデーションを含めることにした。リコメンデーションは、ユーザーが誰々をフォローし、どのリポジトリーをスターし、また今GitHub上で何に人気があるか、といった情報に基づいて作成される。また“Explore”と呼ばれる人間が編集するセクションでは、機械学習やゲーム開発など、分野別のプロジェクトやリソースをまとめて紹介する。

また、有料のGitHub Enterpriseでは、30分以内のお返事を約束するプレミアムサポートと、コミュニティフォーラム、Marketplace機能のトライアル、チームディスカッションツールなどが提供される。そこではもちろん、どのコードがどこにあるか、ということも話題になる。

GitHubのデータサイエンティストMiju Hanはこう言う: “GitHubの上で人間がやってることを、明日になれば人工知能がやってくれるなんて、ありえないからね。GitHubでは基本がいちばん重要。基本を良くしていけば、長期的には最良のデータが得られるようになる”。

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

一般企業とデベロッパーの機械学習導入を助けるPetuumがSoftbankらから$93Mを調達

機械学習のデベロッパーの不足が産業界の足かせになっている今、スタートアップも大手テクノロジー企業も人工知能を商用化するために必要なツールの民主化に取り組もうとしている。その方面の最新のスタートアップPetuumは今朝(米国時間10/10)、Softbankおよび Advantech Capitalからの、9300万ドルのシリーズBを発表した。

昨年カーネギーメロン大学の機械学習の教授Dr. Eric XingとDr. Qirong Ho、そしてDr. Ning Liが立ち上げたPetuuは、機械学習の開発を支える二つの部位のためのソフトウェアを作っている。ひとつは、データの準備と機械学習のモデルの選択を自動化することだ。機械学習の初心者である一般企業は、このようなツールの助けがなければ、TensorFlowやCaffeのような、広く使われている機械学習のフレームワークすら、使いこなすことができない。

そしてモデルが決まったら、今度はPetuumは、ユーザーが使用するハードウェアの特性や制約に合わせた最適化を、デベロッパーをアシストしながら行う。こちらが、二つめ。その主な工程は、ハードウェアを仮想化して障害を取り除き、分散GPUクラスターの管理という余計なステップをなくすことだ。

Dr. Xingはこう語る: “私たちのAIの扱い方は、職人芸ではない。私たちはきわめて標準化されたビルディングブロックを作って、それらをLegoのように組み立てたり、組み立てなおしたりする”。

PetuumのファウンダーEric Xing博士とピッツバーグの同社オフィス

つまり同社のサービスは、さまざまな機械学習の問題を解くことではなく、ユーザー企業とそのデベロッパーたちが、0の段階から1の段階へ踏み出せるために、そのプロセスを自動化することだ。ただしPetuumはそれと同時に、エキスパートたちが十分に使えるシステムも目指している。この両立が、かなり難しい。

Dr. Xingは曰く、“Excelの使い方は誰でも知ってる。一般社員はExcelを使って表を作るだろう。それと同時に、高度な技能を持ってる統計家が何かの現象のモデルを作るときも、Excelを使うことがある”。

また、市場戦略も難しい。テクノロジー業界がいくら大金を投じてAIを称揚しても、投資家たちの多くはヒューリスティックスで不確実性を管理する方向へ向かおうとする。そこでは、AIが得意とする水平的な〔業種業態の違いを問わない〕プラットホームが、役に立たない。

それに、機能の開発と支出の均衡が必要なスタートアップが、MLaaSやMLプラットホームでGoogleやAmazonに対抗するのは難しい。Dr. Xingは自分のチームのスキルを高く評価しているが、Softbankらからの資金はありがたいはずだ。H2O.aiAlgorithmiaなどの競合他社にはまだ、これほどの資金源はないだろう。

なお、同社はヘルスケアやフィンテック分野の顧客を開拓中だ。しかし長期的には、あらゆる業種業態に対応する気はない。ベータテストにはさまざまな業界から参加しているが、しかし今後は、他の業種業界に対して、このプラットホームをベースとするソリューションを同社以外のスタートアップが構築できるだろう。

今日の投資はSoftbank本体からで、930億ドルのSoftbank Vision Fundからではない。将来このファンドから投資されるのかは、不明だ。Petuumの現在の社員は70名で、今後は製品開発と営業とマーケティングを同時に増員したい、と言っている。

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

GitLabがGVのリードするシリーズCで$20Mを調達、ソフトウェア開発〜リリースの総合ソリューションを目指す

デベロッパーのためのコラボレーションとDevOpsのプラットホームGitLabは現在、10万あまりの企業が利用している。同社は今日(米国時間10/9)、GV(元Google Ventures)がリードするシリーズCのラウンドにより2000万ドルを調達したことを発表した。これでGitLabの総調達額は4550万ドルあまりとなる。

新たな資金調達に加えて同社は今日、WordPressの協同ファウンダーMatt Mullenwegが同社の取締役会に加わったことを発表した。

GitLabは、その名が示すように、gitをベースとし、デベロッパーがコードのリポジトリーをセルフホスティングしていくためのオープンソースのツールだ。しかし2014年のローンチ以来同社は、そのほかのDevOps向けサービスをいくつも新設してきた。それらの中にはワークフローツールがいくつかあり、またコードのレビューやリリースを容易にできるためや、アプリケーションのモニタリングのための機能すらある。

そこで同社は、自己のミッションを次のように定義している: “現代のソフトウェアデベロッパーのためのシームレスで総合的なプロダクトを開発し、またKubernetesによるソフトウェア開発のためのアプリケーションになること”

そう。今やGitLabですら、Kubernetesというゲームに深く関わりたいのだ。

GVのゼネラルパートナーDave Munichielloは、今日の声明文の中で次のように述べている: “Fortune 500社は今、互いに競ってワールドクラスのソフトウェア開発組織を作ろうとしており、またそれらに、世界最大のテクノロジー企業なみのスピードと生産性とクォリティを持たせようとしている。これらの組織は高品質で大規模なコードを作るべく努力しているので、最高クラスのツールとプラットホームを必要とする。GitLabのプラットホームは、コラボレーションとオートメーションを強調することにより開発プロセスを加速する。GitLabのハイブリッドでマルチクラウドのソリューションはデベロッパーに好まれており、その分野で巨大なファン層を形成している”。

GitLabの現在のユーザーには、Ticketmaster, ING, NASDAQ, Sony, Intelなどもいる。

新たな資金の使途について同社は、“ソフトウェアのパッケージングとリリース方式と構成とモニタリングに関して新たな機能性を加えたい”、と言っている。

同社の競合サービスはGitHubやAtlassianのBitBucketなどだが、GitLabによると、セルフホスティング型のgit市場では同社が2/3のシェアを占めるそうだ。

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