Alphabet傘下のChronicleがマルウェアスキャンVirusTotalのエンタープライズバージョンを立ち上げ

Googleの持株会社Alphabet傘下のセキュリティ企業Chronicleの、ウィルスやマルウェアをスキャンするサービスVirusTotalが今日(米国時間9/27)、エンタープライズ向けのバージョンを立ち上げた

VirusTotal Enterpriseと名付けられたその新サービスは、より高速でよりカスタマイズ性に富むマルウェア検索と、Private Graphと呼ばれる新しい機能を提供する。Private Graphは、企業のインフラストラクチャと、彼らのマシンに悪影響を及ぼすマルウェアの、プライベートな視覚化を作りだす。

企業はPrivate Graphを使って社内のインフラストラクチャやそのユーザーの明細を容易に作れるので、セキュリティチームはインシデントとその起点を調べやすくなる。上図のようなグラフを作る過程でVirtusTotalは、複数のノードの共通性を見つけ、問題の発見を助ける。

当然ながらこれらのグラフはプライベートに維持される。VirusTotalはすでにその有料ユーザーにVirusTotal Graphという機能を提供しているが、しかしその情報はすべて、パブリックだ。

VirusTotalの主張によると、このサービスはAlphabetの大きなインフラストラクチャと検索の専門的能力を利用できるので、高速で高度な検索ができる。VirusTotal EnterpriseのスピードはこれまでのVirusTotalの100倍で、検索の精度も高い。その高度な検索機能により、企業のセキュリティチームは、偽アプリケーションからアイコンを取り出したり、同じファイルに取り付いているすべてのマルウェアを見つけたりできる。

さらにVirusTotalによれば、同サービスは今後も引き続きGoogleの強力なインフラストラクチャを利用する前提で、そのエンタープライズサービスを徐々に拡張していく。

GoogleがVirusTotalを買収したのは2012年で、その後長年このサービスに変化はなかったが、今年の初めにGoogleの親会社AlphabetがVirusTotalを新設のChronicleブランドへ移し、それ以降、開発が活発になったようだ。

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

Chefの標準ツールと最新ツールがMicrosoft Azureへ深く統合、安心のマイグレーションを担保

DevOpsオートメーションサービスChefが今日(米国時間9/25)、Microsoft Azureとの新しい統合をいくつか発表した。その発表は、フロリダ州オーランドで行われているMicrosoft Igniteカンファレンスで行われ、企業がレガシーアプリケーションをAzureへ移行する際の支援に焦点が絞られた。それに伴い、Chef Automate Managed Service for Azureのパブリックプレビューや、ChefのコンプライアンスプロダクトInSpecをMicrosoftのクラウドプラットホームに統合する例などが提示された。

Azure上のマネージドサービスとなるChef Automateは、コンプライアンスとインフラの構成の、管理とモニタリングを単一のツールでできる能力をopsのチームに与え、またデベロッパーは、Chef AutomateとChef ServerをAzure Portalから容易にデプロイし管理できる。それは完全なマネージドサービスであり、初めてのユーザー企業でも30分で使えるようになる、と同社は主張している。この数字には、やや宣伝臭があるかもしれないが。

構成を変えるときにはAzure上のChefユーザーは、AzureのコマンドラインインタフェイスであるAzure Cloud ShellでChef Workstationを使える。WorkstationはChefの最新の製品のひとつで、構成の変更を即席でできる。また、Chefが管理していないノードでも、対応できる。

コンプライアンス堅持のために、ChefはセキュリティとコンプライアンスツールInSpecのAzureとの統合をローンチした。InSpecは、MicrosoftのAzure Policy Guest Configuration(誰だ?こんな名前をつけたやつは!)と協働し、それによりユーザーはAzure上のすべてのアプリケーションを自動的に監査できる。

Chefのプロダクト担当SVP Corey Scobieはこう語る: “Chefは企業に、彼らが確信を持ってMicrosoft Azureに移行できるためのツールを提供する。ユーザーは単純に自分たちの問題をクラウドへそっくり移すのではなく、状態や状況をよく理解したうえで移行を行なう。事前に構成やセキュリティの問題を検出できるから、移行後の成功が確実になり、正しい、そして着実なペースで、移行できる実力を企業に与える”。

more Microsoft Ignite 2018 coverage

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

GoogleのCloud Memorystore for Redisが一般公開、ミリ秒以下のレスポンスを約束

Googleは今日(米国時間9/19)、5か月の公開ベータを経たCloud Memorystore for Redisを一般公開した。それは、完全な管理を伴うインメモリのデータストアだ。

このサービスはRedisプロトコルに完全に準拠していて、インメモリのキャッシングを必要とするアプリケーションにミリ秒以下のレスポンスを約束する。そしてRedis準拠なので、デベロッパーは自分のアプリケーションをコードをどこも変えずにこのサービスへマイグレートできる。

Cloud Memorystoreには二つのサービスティアがある。シンプルなキャッシング用のベーシックと、高可用性のRedisインスタンスを必要とするユーザーのためのスタンダードだ。スタンダードではGoogleは、99.9%可用性のSLAを提供している。

最初にベータでローンチして以来Googleは、このサービスにできることを徐々に増やしてきた。たとえば今ではさまざまな性能数値をStackdriverで見ることができる。また、カスタムのIAMロールや、改良されたログ機能も加わった。

課金は時間と容量の従量制で、サービスのレベルや使用するキャパシティによって異なる。完全な料金表がここにある。

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

G Suiteによる企業のデジタルトランスフォーメーションの進捗を測るツールWork Insights

東京で行われたイベントでGoogleが今日(米国時間9/18)、社員たちのG Suite生産性ツールの使用状況や、それらのツールをコラボレーションに利用している状況を知るためのツールWork Insightsのローンチを発表した。

さらにGoogleは、G Suiteのデータのセキュリティを向上させるための調査ツールを一般公開した。

G SuiteのグループプロダクトマネージャーReena Nadkarniはこう説明する: “Work Insightsは、G Suiteの利用で企業のデジタルトランスフォーメーションがどれぐらいうまくいっているかを測るツールだ”。…そのデータは10名以上のチームごとに集められ、それぞれのチームのG Suiteアプリケーションの利用状況が分かる。

企業がいろいろなベンダーの製品を使っているときは、デジタルトランスフォーメーションの進捗にもチームごとの格差が生じやすい。でもそれらのツールの多くは、全社一斉採用でないと目に見える効果の得られないものが多い。このことは、Slack, Hangouts Chat/Meet, Microsoft Teamsなどのコミュニケーションツールにおいてとくに顕著だが、G Suiteのような生産性ツールにも言える。

もっとおもしろいユースケースとして、Work Insightsでは複数のチーム間の対話の状況を知ることができる(マーケティングと営業、とか)。たとえば複数のチームがドキュメントを一緒に作っているなら、その協働関係はうまくいくだろう。そうでないと、営業がマーケティングのプレゼンテーションを酷評するだけで終わったりするかもしれない。

“これらの結果を見て役員たちは、企業内の、コラボレーションを強化しサイロ化(孤立・閉所化)の危険性を防ぐべき部分を同定できる”、とNadkarniは書いている。コラボレーションの活発化よりもサイロ化の蔓延を好む役員はたぶんいないから、このツールを利用する企業は今後結構多いのではないか。

画像クレジット: TOSHIFUMI KITAMURA/AFP / Getty Images

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

Microsoft、Dynamics 365の機械学習を強化――カスタマーサービス、顧客管理など3分野のアプリを発表

有力テクノロジー企業はみなそうだが、Microsoftもあらゆるプロダクトに機械学習を取り入れようと全力を挙げている。 当然ながら、大きなビジネスとなっている顧客管理システム、Dynamics 365 CRMにもAIを適用した。Microsoftが最初にDynamics 365 AIを発表したのは1年前になる。今日(米国時間9/18)は、Dynamics 365 AI for Sales、Customer Service、Market Insightsという3つのAIプロダクトをリリースした。これによりAIプロダクトのポートォリオはセールス、カスタマー・サービス、市場分析の分野に拡大された。

Microsoftのビジネス・アプリケーションとインダストリー担当コーポレート・バイスプレジデント、Alysa Taylorはこう述べている。

現在多くの人々はCRM(顧客管理)やERP(基幹業務管理)などを抑圧的なシステムだと感じている。データを貯め込むだけで、実際にエンドユーザーの業務に役立つ情報を何ひとつ返してよこさない。しかしユーザーが求めているのは抑圧では解放だ。

Dreamforceカンファレンスの熱狂的参加者は別として各種のCRMが好きな人間はいない。抑圧のシステムというのはずいぶん過激な表現だが、初期のCRMは隔絶したデータのサイロになりがちだったという点でTaylorの言うことには理がある。もちろんMicrosoftはDynamics 365に格納されたデータは機械学習によってさまざまなタスクに容易に利用できるのでそういった抑圧的システムとは全く異なると主張する。

Dynamics 365 AI for Salesは名前のとおり、セールス部門に対して、顧客から得たデータにセンチメント分析を適用して的確な将来予測を与えようとするシステムだ。現在、この分野への機械学習の適用は標準的なものとなっているが、AI for Salesは同時にセールス・チームが次にどんな手を打つのが効果的か、どの行動が優先順位が高いかなどを教えるという。またセールス部門の管理職による担当者の教育・訓練も手助けする。

Customer ServiceアプリもAIによって自然言語処理を行い、言語によってカスタマー・サポートを行うことを可能にする。バーチャル担当者を創出することによりコストの削減が図れる。TaylorによればこのアプリはライバルのSalesforceに対抗するものだという。Talorは「多くのベンダーがそういうことができると主張しているものの、企業が実際に採用するには手間がかかりすぎるものが多い。またこうしたサービスは非常に大規模であることが必要なのでSalesforceはIBM Watsonと提携している。われわれのサービスもいよいよ実用化される」と述べている。

Dynamics 365 AI for Market Insightsも市場動向の分野で同様の機能を示し、ソーシャルメディアの書き込みを対象としたセンチメント分析を行う。ただしセールス部門におけるものよりも詳細な分析となる。「これにより企業はプロダクトやブランドに対する好き・嫌いなどの感情を分析し、続いてその結果をベースに顧客忠実度をアップするために効果的な手段を検討する。またどういうイベントが口コミで広がりをみせ、ブランドの認知度や親近感を高めるかを示唆する」という。つまり企業が口コミでニュースを拡散しようと何か始めるのを見たら、Office 365 AI for Market Insightsの助言に従ってそうしている可能性があるわけだ。

原文へ

滑川海彦@Facebook Google+

NvidiaがローンチしたTesla T4は最速のデータセンター用推論プラットホームだ

Nvidiaが今日(米国時間9/1)、データセンターにおける機械学習と推論のための新しいGPUを発表した。そのTesla T4 GPUs(TはNvidiaの新しいアーキテクチャTuringを指す)は、クラウドコンピューティングのメジャーなプロバイダーのほとんどが現在提供しているP4 GPUsの後継機種だ。Nvidiaによると、GoogleはT4 GPUsをクラウドプラットホームで採用する最初の企業のひとつだ。

Nvidiaによると、T4はP4よりも相当に速い。たとえば言語の推論では、T4はCPUを使うよりも34倍速く、P4より3.5倍速い。T4のピーク時性能は4ビットの整数演算で260TOPS、浮動小数点演算で65TOPSだ。T4は、標準的な75ワットのLow Profile PCI-eカードに載っている。〔関連記事

しかしもっとも重要なのは、Nvidiaがこれらのチップを、AIの推論専用に設計したことだ。NvidiaのVPで同社のTeslaデータセンター事業部のGM Ian Buckはこう語る: “Tesla T4が推論用としてこれほど効率的なGPUであるのは、Turingアーキテクチャの新しいテンソル・コアのせいだ。CEOのJensen Huangがすでに述べたように、そのTensorコアはゲームやレンダリングやAIにも有効に利用できるが、設計の前提は推論だ。トータルでこのチップには、320のTuting Tensorコアと2560のCUDAコアがある”。

Nvidiaは今回、新しいチップのほかに、同社のソフトウェアTensorRTの、ディープラーニングのモデルを最適化するアップデートをローンチした。この新しいバージョンには、TensorRT推論サーバーも含まれており、それはデータセンターの推論のための完全にコンテナ化されたマイクロサービスとして、既存のKubernetesインフラストラクチャにシームレスに接続する。

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

Anaxiはソフトウェア開発の工程を見える化する…GitHubの巧みな利用で

Anaxiのミッションは、ソフトウェア開発の工程にもっと透明性をもたらすことだ。そのツールは、今はiOSのみで近くWebとAndroidバージョンも出す予定だが、デベロッパーにGitHubからプロジェクトの現状に関する知見とそれらに対する対策を示唆し、プロジェクトとイッシュー(問題)を管理できるようにする。近く、AtlassianのJira もサポートする。

ファウンダーは、Appleで技術部門のマネージャー、そしてDockerで製品開発担当EVPだったMarc Verstaenと、CodinGameのCEOだったJohn Lafleurだ。当然ながらAnaxiのツールは、二人がデベロッパーとして過ごした日々に見たり体験したりした問題の解決を志向している。

Verstaenは語る: “ソフトウェアを40年やってるが、問題はいつも同じだ。小さなチームでプロジェクトをスタートする。そこまでは良い。しかしそれが大きくなると、何がどうなってるのか分からなくなる。まるでブラックボックスだ”。

今は、多くの企業がデータと分析に力を入れようとしているが、ソフトウェア開発はそこまで行ってない。Verstaenによると、10年か15年前なら、ソフトウェアはソフトウェア企業が作るものだったから、それでも良かったが、今ではすべての企業がソフトウェア企業になりつつある。だから、古いやり方はもう通用しない。

Anaxiを使うと、すべてのイッシューレポートとプルリクエストをGitHubの…パブリック/プライベート両様の…リポジトリから見ることができる。また、視覚的なステータスインジケーターにより、プロジェクトにブロッカーが多すぎることなどが分かり、独自のラベルを定義することもできる。イッシューの期限を定義することもできる。

Anaxiのおもしろいところは、情報を手元ローカルにも会社のサーバーにも置かずに、すべての情報をGitHubから取り出すことだ。ただし自分のハンドルなど必要な少量の情報をキャッシュすることはある。スマートフォンなどの上のキャッシュは暗号化されるが、でもほとんどの場合、AnaxiはGitHubのAPIを使って必要な情報を取り出す。スピードに関しては、Verstaenによると、GitHubのAPIは十分に速いし使いやすい。しかもGitHubからなら、つねに最新のデータが得られる。

このサービスは、現在無料だ。将来は、顧客企業の中でAnaxiを使っているデベロッパーの頭数で課金したい、と考えている。

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

GoogleのAndroid Enterprise Recommendedに堅牢なスマートフォンが加わる

堅牢なスマートフォン(rugged smartphones)は、厳しい環境で働く社員に企業が与えるデバイスであり、やや特殊な市場だ。スマートフォンを選ぶとき、6フィート(180センチメートル)の高さから落としても壊れないことを条件にする消費者はあまりいない。でも、市場があることは確かで、調査会社のIDCは、Androidベースの堅牢デバイスが今後5年間、年率23%で伸びる、と予想している。

Googleが、企業向けに製品を推薦するAndroid Enterprise Recommended事業を拡大して、堅牢デバイスを含めるようにしたのも、当然だろう。でも、そこに載っているメーカーの名前をご存知だった方は、あまりいないと思う: Zebra, Honeywell, Sonim, Point Mobile, Datalogic…社名はご存知でも、スマートフォンとは結びつかない企業もあるだろう。Panasonicも長年、堅牢デバイスを作っているから、そのうちこの事業に当然入るだろう。

これらのデバイスの最低条件は、かなり単純明快だ: Android 7以上をサポート; Googleがリリースしてから90日以内にセキュリティアップデートを行なう; 堅牢デバイスであるために侵入保護があり落下試験合格であること。そして、ほかにも、少なくとも一つ以上のメジャーなOSをサポートできること。

Googleは今日の発表でこう言っている: “今日のローンチは、顧客のエンタープライズ体験の改善にコミットする私たちの姿勢が変わらないことを表している。これらのデバイスが、既存のユースケースに奉仕し、また企業の新たなモバイルのユースケースの追求を可能にして、企業の目標の実現に寄与することを期待する”。

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

Atlassianがopsチームのためのインシデント管理ツールJira Opsをベータでローンチ

Atlassianが今日(米国時間9/3)、同社の旗艦製品であるJiraの新しいエディションの最初のベータと、opsのチームがインシデントを迅速効率的に処理できるための問題追跡ツールを発表した。

そのツールJira Opsは、OpsGenie, PagerDuty, xMatters, Statuspage, Slackなど他のツールをいろいろ統合している。多くのチームがすでに、自分たちのサービスがダウンするとこれらのツールを使っているが、Atlassianによると、現状では、その場しのぎ的な使われ方が多い。Jira Opsは、同じページ上の全員をまとめる糊になり、現在進行中のインシデントを可視化することをねらっている。

AtlassianがJiraを使って、その中核的なオーディエンスであるデベロッパーから逸れた方向へ脇道するのは、これが初めてではない。たとえばJira Service DeskとJira Coreは、もっと広いオーディエンスを対象としている。しかしOpsは、きわめて限定された層が対象だ。

Atlassianでソフトウェアのチームを率いるJens Schumacherはこう述べる: “Service Deskが、最初の一歩だった。そして、Jiraで対応できるそのほかの特定層を、探していた”。Schumacherによると、同社は社内のopsチームのためにこれまでたくさんのツールを作ってきたが、それらは主に、インシデントを追跡し管理するために必要な、いろんなピースを糊のようにまとめることが目的だった。Jira Opsはそんな糊的ツールを、正規のプロダクトにしたものだ。

しかし、Jira Opsを使うことはある意味で、パズルのピースがまた一つ増えることだ。でもSchumacherの主張では、プロセスを管理する単一の場所を作ることがねらいだった。“インシデントが起きたら、そのインシデントに関係のあるものをすべて見つけられる、センター的な場所へ行けばよい、…それがねらいだ”、と彼は語る。“そのページに誰がいて、誰がアラートされているかが分かる。必要と思えば、さらにもっと多くの人にアラートできる。Slackのどのチャネルでそのインシデントが議論されているか、も分かる”。

Atlassianの他のプロダクトと違うのは、Jira Opsのセルフホスティングバージョンを出す計画は今のところないことだ。その理由は、単純明快だ: ユーザーのインフラがダウンしたら、Jira Opsもダウンするかもしれない。…そうなると、そのダウンタイムを管理するツールがない。

Jira Opsは今、アーリーアクセスのベータとして無料で利用できる。バージョン1.0の立ち上げは、2019年の初期の予定だ。もちろんそのときには、料金体系も明確になっているだろう。

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

Dropboxのコラボレーション層Paperがメジャーアップデートで多様なコンテンツに対応

Dropboxのようなストレージサービスが企業ユーザーの獲得を目指すときは、単純なファイル共有を超えた機能の提供が必要になる。Dropboxが、これまで欠けていたコラボレーションの層としてPaperを作ったのも、そのためだ。今日(米国時間9/3)同社は、プログラムを切り替えたりせずにコラボレーションツールの中だけで仕事ができるための、拡張機能をPaperに導入した。

“Paperは、チームのためのDropboxのコラボレーションの場だ。複数のユーザーが一緒に仕事をできるための機能がいろいろあり、締め切りを決めてオーナーにタスクを割り当てたり、YouTubeやSoundCloudやPinterestなどのマルチメディアコンテンツを埋め込むこともできる”、とDropboxは説明している。

今日発表された拡張機能で、Paperの中にさらにほかの要素を取り込めるようになった。たとえばPaperの中でDropboxのフォルダーへリンクして、ファイルの中身を見たり、サブフォルダーへ降りて行ったりもできる。リンクはフォルダーそのものへのリンクなので(コピーではないので)、ファイルへのアップデートはPaperの中のビューにもすぐ反映する。これはDropboxのような企業にとって、かなり思い切った機能だ。

画像提供: Dropbox

今のDropboxは、スプレッドシートをパワーアップしたような機能Airtableをサポートしているが、今回のPaperのアップデートで、Airtableを埋め込みコードでPaperに取り込めるようになった。これも、Airtable本体のアップデートが即、Paperのビューに反映される。

さらにこれからのPaperは、Googleのコラボレーション機能のように、図表を作れるLucidchartをサポートする。これも、フォルダーやAirtableと同じく、ライブのビューをPaperの中で見られる。つまり図表本体が変わればPaper上の図表も変わる。

Paperの中で、これだけいろいろなことができるから、プログラムをあちこち切り替える必要がない。最近BoxがActivity StreamとRecommended Appsを発表したのも、同じような理由からだ。Slackが企業で人気が高いのも、同じ理由だ。つまり、ひとつのコラボレーションツールの中で、いろんなアプリケーションのコンテンツをシェアできる。そのために大量のタブや、別のアプリケーションを開かなくてもよい。

Dropbox Paperではさらに、ユーザーがあちこちのアプリケーションのコンテンツサイロを訪ねなくても、一箇所でいろんなプレビューを見ながら、最後まで中断なく仕事ができる。Dropboxはこの機能を、企業顧客獲得の決め手にしたいのだ。

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

GoogleがKubernetesの開発インフラの自社負担から降りてすべてをCNCFに委ねる

Googleが今日(米国時間8/29)、同社がCloud Native Computing Foundation(CNCF)に、Google Cloudのクレジット900万ドルを提供して、Kubernetesコンテナオーケストレータの同団体による今後の開発を支援し、プロジェクトの運用に関わるコントロールを同団体に委ねる、と発表した。このクレジットは3年分割で提供され、Kubernetesソフトウェアの構築や試験、配布などに要する費用に充当される。

これまではGoogleが、このプロジェクトを支えるクラウドリソースのほとんどすべてをホストしていた。その中にはたとえばCI/CDによるテストのためのインフラストラクチャや、コンテナのダウンロード、同社クラウド上のDNSサービスなども含まれている。しかしGoogleは今回、一歩後退することになった。Kubernetesコミュニティの成熟に伴い、GoogleはKubernetesのすべてのサポートワークをコミュニティに移そうとしている。

テストのためのインフラストラクチャからコンテナダウンロードのホスティングまで、すべてを合わせるとKubernetesプロジェクトは常時、15万あまりのコンテナを5000基の仮想マシン上で動かしている。その費用は、相当に大きい。Kubernetesのコンテナレジストリはこれまで、1億3000万回近いダウンロードに応じてきた。

それにまた現在のCNCFは、互いに競合する多様なメンバーを抱えている。Alibaba Cloud, AWS, Microsoft Azure, Google Cloud, IBM Cloud, Oracle, SAP, VMwareなどがその例だ。全員がCNCFの仕事やKubernetesのコミュニティから利益を得ている。Googleはこれまで黙っていたが、そろそろKubernetesのインフラストラクチャを動かす重荷を、それにふさわしい者に担わせるべきだろう。それにコミュニティのメンバーの一部は、KubernetesがGoogleのインフラストラクチャにあまりにも密接に結びついていることを、嫌っていた。

GoogleのKubernetes EngineのプロダクトマネージャーWilliam Denissが、今日の発表声明でこう書いている: “Kubernetesの運用責任をプロジェクトのコントリビューターが共有することによって、彼ら全員が持ち寄る新しいアイデアや効率性を生かせるようになるだろう。それが楽しみである”。彼によると今後も、Kubernetesのインフラストラクチャの運用には、Googleの意思が適宜反映されていく、という。

CNCFの事務局長Dan Kohnはこう述べる: “KubernetesのコミュニティにGoogleの大きな財政支援があることによって、このプロジェクトのイノベーションと採用の安定的なペースが今後も減衰することなく維持されるだろう。Google CloudがKubernetesのテストとインフラストラクチャに関わるプロジェクトをコントリビューターの手に渡したことによって、プロジェクトはオープンソースであるだけでなく、オープンなコミュニティによってオープンに管理されるものになる”。

今後長期的には、インフラストラクチャがGoogleのクラウドから離れることになるのか、そのへんはまだ分からないが、3年後に他のクラウドプロバイダーが同様のクレジットを提供することは、大いにありえるだろう。

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

Slack、またもダウン(現在は復帰)

ノー。Slackにつながらなくなったのはあなただけではない。Slackがまたもやダウンした。ただし今回のダウンは前回ほど全面的なものではなかったようだ。TechCrunchでも特定のチャンネルが消えるなどの問題が断続的に起きた。それでも全体としてコミュニケーションがまったくできなくなるという状態にはならずにすんだ。なので「今日はSlackが使えないので仕事はお休みです」と言って上司を納得させるのは難しいだろう。残念。

Slackも問題が起きていることを認識し、ステータス・ページで「ワークスペースにつながりにくくなっています。私たちは原因を調査しています。わかり次第アップデートします」と述べた。Slackでは今月始めと7月にも似たような問題が起きている。

アップデート:現在は正常に戻っている。Slackでは原因を公表し「設定エラーにより、44分間にわたって新規の接続が不可能になった」としている。将来、同様のエラーが起きないようにする対策を検討中とのこと。

原文へ

滑川海彦@Facebook Google+

VMwareがマルチクラウド管理のCloudHealth Technologiesを買収

VMwareは今週ラスベガスで、顧客のためのカンファレンスVMworldを開催しており、その席で同社は、ボストンのCloudHealth Technologiesを買収したことを発表した。買収の条件は公表されていないが、ロイターの報道では買収価額は5億ドルとされている。

CloudHealthはVMwareに、重要なマルチクラウド管理プラットホームを提供する。そのツールはAWS, Microsoft Azure, Google Cloud Platformなどをサポートし、ユーザーは、クラウドのコストや利用、セキュリティ、パフォーマンスなどを一つのインタフェイスから管理できる。

クラウド市場はAWSが大きくリードしているが、それは広大で急成長中の市場であり、多くの企業が複数のプラットホームを使い分けている。それぞれの目的にもっとも合ったクラウドサービスを使いたいからだ。

このマルチクラウドのアプローチには単一のプロバイダーに縛られないという利点はあるが、一方、その管理がたいへんになる。そこでCloudHealthはマルチクラウドのユーザーに、単一のツールでそれらの環境を管理する方法を提供する。

CloudHealthのマルチクラウド管理。写真提供: CloudHealth Technologies

VMwareでプロダクト管理とクラウドサービスを統括しているCOOのRaghu Raghuramによると、CloudHealthはマルチクラウドのオペレーションに伴うジレンマを解決する。彼曰く、“CloudHealth Technologiesが加わったことによって、複数のクラウドにまたがるコストとリソースや、アプリケーションのセキュリティとパフォーマンスを一元管理し、問題に迅速に対応できるようになった”。

つい先月、CloudHealthがサポートするクラウドプラットホームにGoogle Cloud Platformが加わった。CTOのJoe Kinsellaは、GCPのサポートを加えたことについて、こう述べている: “GCPでは、2015年にDiane Greeneが来て以来、いろんな企画が動き出し、エンタープライズへの適性が強化されている。その結果、われわれの顧客の間にも、急激に関心が高まっている”。

これによりCloudHealthの顧客も、大手プラットホーム三社のクラウドを安心して併用できるようになる。そして、かねてから顧客のハイブリッド環境や、マルチクラウド環境の管理を目指してきたVMwareにとっても、CloudHealthがいわば“買い時”になってきた。

これまで同社は、パブリッククラウドだけでなくプライベートクラウドやデータセンターも含めたすべての環境の一元管理を目指していた。それに対しVMwareもまた、さまざまなVMを使っている企業の、ハイブリッド環境の支援を、近年は志向してきた。

CloudHealthは、マルチクラウド管理のソリューションだけでなく、Yelp, Dow Jones, Zendesk, Pinterestなど、3000社の顧客をVMwareに連れてくる。

CloudHealthは2012年に創業され、これまで8700万ドルを調達している。最近では2017年6月のシリーズDで、Kleiner Perkins率いるラウンドにより4600万ドルを調達した。それよりも前のリード投資家は、Sapphire Ventures, Scale Venture Partners, そして.406 Venturesだ。

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

暗号化コラボアプリのWickrがPsiphonとパートナーして通信の確実到達を確保

あらゆるメッセージが暗号化されるコラボレーションアプリWickr(製品説明)が、スマートVPNツールのPsiphonとパートナーを結んだ。WickrはPsiphonの技術を利用して、どこから送られる通信パケットでも確実に目的地に届くようにする。自宅からでも、粗悪なWi-Fiのカフェでも、あるいは中国の粗悪なWi-Fiのカフェからでも。

そのねらいは、ユーザーがいちいち自分で自分の接続を監査して、自分のアプリケーションが正しく動いていることを確認しなくても、よいようにすることだ。セキュリティの貧弱なアクセスポイントを使ったりすると、それは本人の安全の問題にもなる。また、特定のポートやアプリが使えないなど、接続性の問題もあり、あるいは、その国で禁じられているサービスからデータをリクエストするなど、検閲の問題もある。

Wickrはすでに、すべてのトラフィックを暗号化しているので、その点では心配ないが、しかし今使っている接続がビデオ通話や特定のトラフィックパターンをブロックしていたら、暗号化は何の助けにもならない。

しかしPsiphonの仕事は、意図的、ないし事故的なブロックを、迂回することだ。そのためにネットワークを分析するツールを使い、応急的な方法を見つける。それは、トラフィックを匿名化することであったり、ブロックされてないサーバーにぶつけて跳ね返りさせたり、自動的なポートフォワーディングをやるなど、さまざまだ。何であれとにかく、パケットが通ることが目的だ。

これにはもちろん、レイテンシーやスループットのコストが伴うが、ビデオやゲームでもないかぎり、問題にならないだろう。画像のアップロードや、同僚とのチャットなど、そのほかのWickrの機能なら、それでも十分だ。いずれにしても、機能はいつでもon/offできる。

有料プランでは当然お金を払う。エンタープライズの顧客がまず最初に、Psiphonが処理したトラフィックを受け取るだろう。それは、まさに今日(米国時間8/23)だ。そして徐々に、そのほかの有料ユーザー、さらに数週間後には、無料のユーザーにも行き渡るだろう。

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

CI/CDを末端企業にも普及させたいArmoryはY Combinator出身で$10Mを調達

オープンソースのSpinnakerプロジェクトをベースとするCI/CDプラットホームArmoryが今日(米国時間8/22)、シリーズAのラウンドにより1000万ドルの資金を調達したことを発表した。このラウンドはCrosslink Capitalがリードし、Bain Capital Ventures, Javelin Venture Partners, Y Combinator, そしてRobin Vasanらが参加した。

ソフトウェア開発は、ここ数年で確かに変わった。間隔の長いアップデート・サイクルに代わり、継続的デリバリが主流になってきた。このコンセプトは今では、継続的インテグレーション/継続的デリバリ(continuous integration/continuous delivery)を表すCI/CDと呼ばれている。Armoryのプロダクトは、このタイプのソリューションをデプロイするときに伴う複雑性を、軽減しようとする。

同社を創業したときファウンダーたちは、CI/CD技術のバックエンドのベースとしてSpinnakerを使う、と決めた。それは、GoogleやNetflixなど業界の大物たちが支持しているプロジェクトだからだ。ArmoryのCEOで協同ファウンダーのDaniel R. Odioが、今回の資金調達を発表するブログ記事でこう述べている: “Spinnakerは大規模で本格的なマルチクラウドのデプロイを支えるスタンダードになるだろう。自分たちで新たに継続的デリバリのプラットホームを内製で構築する、そんな車輪の再発明を避けて、SpinnakerをArmoryプラットホームのコアにするという、大きな賭をした”。

同社によると、その賭は報われ、Spinnakerの同社バージョンはエンタープライズのソリューションで広くデプロイされている。同社の目標は、Fortune 2000社がソフトウェアのデプロイを今よりずっと速くできるようになることだ。そしてそのためには、CI/CDのアクセスと理解が欠かせない。

今企業は、どんな企業でもソフトウェア企業になりつつあるから、どの企業もこれまでとは異質な部分を抱え込むことになる。GoogleやNetflixのような超大物は、最先端の方法により、ソフトウェアを驚異的なスピードでデプロイする方法を経験から学び構築しているが、製品の製造技術=ソフトウェア開発技術ではない、そこらのふつうの企業は、ソフトウェア技術者もそんなに多くないから、Googleなどに追随することは難しい。

その空隙を補ってくれるのが、Armoryのような企業だ。同社は、オープンソースの技術を核として、その複雑性を包み隠すパッケージにより、高度なソフトウェアデプロイ技術を持たない普通の企業でもCI/CDを導入できるようにする。

中でもとくに同社が強調するマルチクラウドでクラウドネイティブなソフトウェア開発方式は、ユーザーのアプリケーションやインフラストラクチャを、オンプレミスも含む複数のクラウドに分散可能にする。そのようなデプロイ技術の重要な部分が、継続的デプロイを管理する技術だ。

Armoryは2016年にローンチし、ベイエリアに拠を構える。これまで1400万ドルを調達したが、そのうちの400万ドルのシードラウンドは昨年行った。同社はY Combinator 2017冬季の卒業生であり、Y Combinatorは今回の投資に参加している。

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

ブロックチェーンを破壊するハッカーの手口をシミュレーションしてデベロッパーの事前対策を可能にするIncentivai

暗号通貨のプロジェクトは、人間がそのブロックチェーンを悪用すると破綻する。しかも分散デジタル経済が実際に動き出し、コインが離陸すると、それらを統治するスマートコントラクトの修復は難しい。あくまでも、デベロッパーによる事前対策が必要である。そこで、今日(米国時間8/17)ステルスを脱したIncentivaiは、その人工知能によるシミュレーションで、セキュリティホールを調べるだけでなく、ブロックチェーンのコミュニティを構成している人間たちの貪欲や非論理性にメスを入れる。暗号通貨分野のデベロッパーはIncentivaiのサービスを利用して、自分たちのシステムが動き出す前に、その欠陥を修復できる。

Incentivaiの単独のファウンダーPiotr Grudzieńはこう言う: “スマートコントラクトのコードをチェックする方法はいろいろあるが、新たに作った経済が期待通りに動くことを確認する方法はない。そこで私が考えたのは、機械学習のエージェントを利用するシミュレーションを作り、それが人間のように振る舞うことによって、システムの未来の振る舞いを予見する方法だ”。

Incentivaiは来週Y Combinatorを卒業するが、すでに数社の顧客がいる。顧客(ユーザー)は、Incentivaiの有料サービスにより自分たちのプロジェクトを監査してレポートを作るか、または自分でそのAIによるシミュレーションツールをホストしてSaaSのように利用する。同社がチェックしたブロックチェーンのデプロイは数か月後になるが、そのとき同社はすでに、そのプロダクトの有意義性を実証するための、いくつかのケーススタディーをリリースしているだろう。

Grudzieńは説明する: “理論的にあるいは論理としては、一定の条件下ではこれこれがユーザーにとって最適の戦略だ、と言うことはできる。しかしユーザーは、合理的でも理性的でもない。モデルを作ることが困難な、予想外の行動がたくさんある”。Incentivaiはそれらの理不尽な取引戦略を探求して、デベロッパーがそれらを想像しようと努力して髪をかきむしらなくてもよいようにする。

人間という未知数から暗号通貨を守る

ブロックチェーンの世界には巻き戻しボタンがない。この分散技術の不可変かつ不可逆的な性質が、良かれ悪しかれ、一度でもそれを使ったことのある投資家を遠ざける。ユーザーが偽りの請求をしたり、贈賄によりそれらを認めさせようとしたり、システムを食い物にする行動を取ったりすることを、デベロッパーが予見しなければ、彼らは攻撃を阻止できないだろう。しかし、正しくてオープンエンドな〔固定しない〕(AIに対する)インセンティブがあれば…これが社名の由来だが…AIエージェントはなるべく多くの収益を得るために自分にできることをすべてやってみて、プロジェクトのアーキテクチャにあるコンセプトの欠陥を明らかにするだろう。

Grudzieńはさらに説明する: “この〔すべてをやってみるという〕やり方は、DeepMindがAlphaGoでやったものと同じで、さまざまな戦略をテストするのだ”。彼はケンブリッジの修士課程でAIの技能を究め、その後Microsoftで自然言語処理の研究を担当した。

Incentivaiの仕組みはこうだ。まず、デベロッパーは、ブロックチェーンの上で保険を売るなどの、自分がテストしたいスマートコントラクトを書く。IncentivaiはそのAIエージェントに、何を最適化するのかを告げ、彼らが取りうるすべての可能なアクションを羅列する。エージェントの役柄はさまざまで、大金を手にしたいと思っているハッカーだったり、嘘をばらまく詐欺師だったり、コインの機能性を無視してその価格の最大化だけに関心のある投機家だったりする。

そしてIncentivaiはこれらのエージェントにさらに手を加え、彼らを、ある程度リスク忌避型だったり、ブロックチェーンのシステム全体を混乱させることに関心があったり、といったタイプにする。それから、それらのエージェントをモニターして、システムをどう変えればよいかというインサイトを得る。

たとえば、トークンの不均一な分布がパンプ・アンド・ダンプ(pump and dump, 偽情報メールによる価格操作詐欺)を招く、とIncentivaiが学習したら、デベロッパーはトークンを均一に分割して、初期のユーザーには少なめにする。あるいはIncentivaiは、認められるべき支払請求をユーザーが票決する保険製品は、投票者が偽の請求を偽と立証するために支払う債権価格を上げて、詐欺師から収賄しても投票者の利益にならないようにする必要があることを、学ぶかもしれない。

Grudzieńは、自分のスタートアップIncentivaiについても予測をしている。彼の考えによると、分散アプリケーションの利用が上昇すれば、彼のセキュリティサービスのやり方を真似るスタートアップが続出するだろう。彼によると、すでに一部のスタートアップは、トークンエンジニアリングの監査や、インセンティブの設計、コンサルタント活動などをやっているが、ケーススタディーを作る機能的シミュレーションプロダクトは誰もやっていない。彼曰く、“この業界が成熟するに伴い、そういうシミュレーションを必要とする、ますます複雑な経済システムが登場するだろう”。

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

Tesla、時価総額で今週80億ドルを失う――責任は取締役会にもある

Teslaの株主は過去5日間に株価が16%も下落するのを眺める羽目に陥った。セレブCEO、イーロン・マスクの奇妙な行動が広く知られるようになるのにつれてTeslaの時価総額から80億ドル近くが消えた。

しかしTesla株の暴落に関して責任があるのはマスクだけではない。Teslaの株価をさらに下落させたニューヨーク・タイムズのマスクのインタビュー記事にあるように、取締役会の責任も明らかだ

ここ数ヶ月、マスクは緊張による疲労(控えめに表現して)の兆候を示していた。特にマスクが創立した電気自動車会社の今後の針路に関する決断が当を得ていないと強い批判を浴びた。

この時点で、BloombergのShira Ovideのツイートが指摘しているように、Teslaの取締役会(ほぼマスクの友人、親類、初期投資家で占められている)はマスクの決定を押し留めたり修正したりする努力をなんら払わなかった。

Teslaの取締役の一部はマスクが過労ぎみでAmbien(睡眠導入剤)を服用していることに懸念を抱いていたという。それならこう言いたい:取締役は仕事をしろ。 

内輪の席であるいはオフレコで取締役の一部はマスクの最近の言動(薬物の使用やツイート)を心配していた。

取締役にこうした懸念があったなら、取締役会で正式に問題にすべきだった。マスクの公の言動が手に負えないものになる前に取締役会は与えられた権限に基づいて防止のための措置を取る義務があった。

四半期決算の惨憺たる電話記者会見の前後に奇妙な出来事が続いたい。 マスクはテロリストに狙われているとして警察の助けを求めたが誇大な主張だったと判明した。この主張はTeslaの内部告発者、Martin Tripに対するものだった。さらにマスクはタイの洞窟に閉じ込められた少年サッカーチームの救出に成功した洞窟ダイビングの専門家に対してペド野郎という根拠のない罵倒をツイートしている。

こうした事件ではTeslaの取締役会はマスクに対して説明を求め、こうした行動の結果、会社に何十億ドルもの損害を与えるならその責任を取るようはっきり要求すべきだった。 しかし取締役会は無為に過ごし、Teslaを巡る状況ははるかに危険なものとなっている。

SEC(証券取引委員会)はTeslaを非公開化するというツイートがなんらかの事実に基づくものだったのかどうか調査を開始している。

この時期、マスクはModel 3の量産をスケジュールに合わせるというさらに過酷なストレスを抱えていた(量産はスケジュールどおり達成された)。

マスクという個人のカルト的アイデンティティーがTeslaという会社の性格と分かちがたく結びついている点に問題の根本がある。マスクが行くところへTeslaも行く。これはビジネスを運営する正しい方法ではない。公開企業であろうと非公開企業であろうと、株主に会社の価値を長期にわたって保証する方法でもない。

Teslaの取締役会は会社の運営にあたってもっと積極的な役割を果たさねばならない時期に来ている。間違った決定が続くようなら取締役会の次の議題は会社の精算ということになりかねない。

画像:Joshua Lott / Getty Images

〔日本版〕Ambienはゾルピデムを主成分とする睡眠導入剤で、日本でも処方されている

原文へ

滑川海彦@Facebook Google+

機械学習のモデルのデプロイを標準化するツールGraphpipeをOracleがオープンソース化

オープンソースのコミュニティと仲が良いとは必ずしも言えないOracleが今日、Graphpipeと呼ばれる新しいオープンソースのツールをリリースした。それは、機械学習のモデルのデプロイを単純化し標準化するツールだ。

そのツールは、ライブラリの集合と、スタンダードに従うためのツールを合わせたものだ。

このプロジェクトは、NASAでOpenStackの開発に関わり、その後2011年にOpenStackのスタートアップNebulaの創業に加わったVish Abramsがリードした。彼によると、彼のチームが機械学習のワークフローを手がけたとき、あるギャップに気づいた。一般的に機械学習のチームはモデルの開発には大量のエネルギーを注ぎ込むが、そのモデルを顧客が使えるようにデプロイすることが苦手だ。そのことが、Graphpipe誕生のきっかけになった。

彼曰く、機械学習のような新しい技術は、誇大宣伝に踊らされてしまう部分がある。開発プロセスは改良を続けていても、デプロイに頭が向かわない人が多い。

“Graphpipeは、機械学習のモデルのデプロイを改良する努力の中から生まれた。また、この機械学習の分野全体を改良するためには、デプロイのためのオープンなスタンダードがぜひ必要だ、と考えた”、そうAbramsは語る。

これがOracleのプロジェクトになったとき、彼らは三つの問題に気づいた。まず最初に、機械学習のAPIをサーブするための標準的な方法がない。各フレームワークが提供しているものを、そのまま使うしかない。次に、デプロイのメカニズムにもスタンダードがないので、デベロッパーは毎度カスタムでそれを作らなければならない。そして第三に、既存の方法はパフォーマンスの向上に真剣に取り組んでいない。パフォーマンスが、‘ついでの問題’でしかない。機械学習にとっては、それは重大な問題だ。

“Graphpipeを作ったのは、これら三つの課題を解決するためだ。それは、ネットワーク上でテンソルデータを送信するための標準的でパフォーマンスの高いスタンダードを提供する。またどんなフレームワークを使っても、機械学習のモデルのデプロイとクエリーが簡単にできるための、クライアントとサーバーのシンプルな実装も作った”、…AbramsはGraphpipeのリリースを発表するブログ記事で、そう書いている。

同社は、これをスタンダードとしてオープンソースにすることによって、機械学習のモデルのデプロイを前進させたい、と決意した。“Graphpipeは、ビジネスの問題解決と、技術の高度化の推進という、二つの方向性が交差するところに座っている。そしてそれを進めていくためのベストの方法が、オープンソース化だと考えている。何かを標準化しようとするとき、それをオープンソースで進めなかったら、最終的にはいろんな競合技術の混乱状態になってしまう”、と彼は語る。

Oracleとオープンソースのコミュニティの間には長年の緊張があることをAbramsも認めるが、最近ではKuberenetesや、オープンソースのサーバーレス・ファンクション・プラットホームOracle FNへのコントリビューションなどを通じて、そんなイメージを変える努力をしてきた。そして彼によると究極的には、技術が十分におもしろいものであれば、誰がそれを提出したかとは関係なく、人びとはそれにチャンスを与えるだろう。そしてそのまわりにコミュニティができれば、オープンソースのプロジェクトとして自然に適応されたり、変えられたりしていく。それを、Abramsは望んでいる。

“このスタンダードが、今後幅広く採用されてほしい。実装は誰がやっても易しいから、Oracle独自の実装を広めたいとは思わない。人気の実装は、そのうちコミュニティが決めるだろう”。

GraphpipeはOracleのGitHubアカウントのGraphpipeのページで入手できる。

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

クラウドネィティブ環境のためのセキュリティベンダーTwistlockがシリーズCで$33Mを調達

世界がクラウドネイティブなアプローチへ移行していくに伴い、アプリケーションとそのデプロイのセキュリティを確保する方法も変わりつつある。クラウドネイティブ環境のセキュリティを提供するTwistlockが今日、Iconiq CapitalがリードするシリーズCのラウンドで3300万ドルを調達したことを発表した。

これまでの投資家YL Ventures, TenEleven, Rally Ventures, Polaris Partners, およびDell Technologies Capitalも、このラウンドに参加した。これで同社の資金調達総額は6300万ドルになる。

Twistlockは、コンテナとサーバーレスのセキュリティという、困難な問題を解決する。両者はいずれも、本質的に短命な存在だ。それらは寿命が1秒の数分の一と短いので、問題が起きたときその追跡が難しい。同社のCEOで協同ファウンダーのBen Bernsteinによると、彼の会社は最初から、コンテナとサーバーレスコンピューティングがどれだけ短命でも、依然としてエクスプロイトされうる、という前提に立って、クラウドネイティブ環境を保護するためのセキュリティプロダクトを作っている。

Bernsteinは曰く、“寿命の長短は関係ない。むしろ重要なのは、それらの生き方が従来のコンピューターに比べて予測可能であることだ。従来のコンピューターは非常に長時間動くし、しかも多くの場合人間が使っているから、予測は簡単ではない”。

スクリーンショット提供: Twistlock

企業がクラウドネイティブな環境へ移行して、Dockerによるコンテナを使ったり、それらをKubernetesなどのツールで管理するようになると、デプロイ量の大きい、高度に自動化されたシステムを作ることになる。デプロイは自動化で簡単になるが、いろんな問題に対する脆弱性はそのまま放置される。たとえば悪者がコード注入攻撃でプロセスのコントロールを握ったりすると、誰も知らない間に大量の問題が起きていたりする。

Twistlockはそれを防ぐとともに、エクスプロイトがいつ起きたのかを顧客に認識させ、診断分析によりその原因を調べる。

それはサービスであるとはいえ、従来型のSaaSとは様子が違う。すなわちそれは同社のサーバーから提供されるサービスではなくて、顧客が使っているクラウド(パブリックまたはプライベート)にインストールされるサービスだ。今同社の顧客は200社あまりで、その中にはWalgreensやAetnaなど、誰もが知っている企業も含まれているが、顧客リストを公開することはできない。

2015年に創業された同社はオレゴン州ポートランドに本社があり、R&D部門はイスラエルにある。現在の社員数は80名だ。他社との競合についてBernsteinは、従来のセキュリティベンダーはクラウドネィティブをまだうまく扱えない、と言う。そして最近登場してきた若手スタートアップに比べると、少なくとも現状では、成熟度では自分たちが上だ、とも言っている。

“今はまだ、競争が激しくはないが、今後徐々にそうなるだろう”、と彼は述べる。今回得られた資金は、主にマーケティングと営業の拡充に充当して顧客ベースの拡大を図りたい。またクラウドネィティブのセキュリティも競合とともに技術が進化していくので、技術でもつねに先頭を走っているようにしたい、とBernsteinは言っている。

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

イーロン・マスク、Tesla非公開化の資金はサウジの政府系ファンドと発表

昨日の記事で、Teslaの非公開化にあたってイーロン・マスクがサウジの政府系ファンドの資金を使える可能性は十分あると私は推測した。今日(米国時間8/13)、マスクは声明を発表し、Teslaの非公開化に関してサウジアラビアの政府系ファンド、PIF(Public Investment Fund)と2年近く前から話し合いを続けてきたと明らかにした。

実際、提案してきたのはサウジ側だったようだ。マスクは「Teslaの非公開化に関して(PIFから)複数回の接触があった」と述べている。

マスクによれば、Teslaに関してサウジのPIFと最初に会談したのは2017年初頭で、PIFが「脱石油を図る必要を感じた」ことがその原因だったという。その後1年でさらに数回の会談を重ねた。「サウジの政府系ファンドは(Teslaの非公開化に必要な)資金を十分持っている」とマスクは述べている。前回の記事で指摘したとおり、PIFの資金は2兆ドルに近づいている。

PIFが株式市場でTesla株の5%を買ったとき、PIFはマスクとさらに話し合いを求めてきた。マスクによれば、この会談は今年の7月31日に行われ、マスクは「もっと早くPIFと協力して非公開化に取り組むべきだった」と述べたという。このときPIFの責任者はTeslaの非公開化にあたって「資金協力の意思を強く表明した」ということだ。

マスクは「サウジ政府系ファンドの協力が疑いなく得られることとなり、あとは実行あるのみとなった」と述べた。マスクが8月7日のツイートで「資金は確保してある」と書いたのはこれを指していたという。

マスクによれば「(PIFとの)契約はほぼ完了しており、ロジスティクスを含めた若干の詳細を詰めるだけだ」という。

もちろんこの声明は多少割引して聞く必要がある。 SEC(証券取引委員会)はTeslaの非公開化に関するツイートについてマスクに質問をしたみられている。質問は必ずしも正式な調査の開始を意味しないが、万一、非公開化の意図をツイートで公開したことがなんらかの違反に問われることになれば、数億ドルの罰金から刑事訴追までの可能性が考えらえる。

この声明を「面子を保つための虚勢だ」とする声も一部にありそうだが、そうではないだろうと思っている。私自身、この地域のビジネス文化には直接の経験があるが、それからしてもPIFがTeslaの非公開化にあたってマスクと協力していくことは間違いはずだ。【マスクの声明は原文参照】

画像:Chris Saucedo/Getty Images for SXSW / Getty Images

原文へ


滑川海彦@Facebook Google+