メモリアルデー週末の喧騒に間に合うように、GoogleはGoogleマップに交通警報を追加した。
Googleはしばらく前から交通〈状況〉を表示していたが、今回のアップデートでは、なぜその経路の方が早いかの説明や、通行止めや交通渋滞の警告、そしてもちろん、それぞれの目的地への代替経路が加わった。
走行中に交通渋滞が発生すると、Googleマップはそのまま走り続けた場合の予想待ち時間をその他の選択肢とともに提示する。
シンプルだが役に立つ。
システムはさらに、過去のGoogleマップ検索データから、この週末みんながどこへ行くつもりかも教えてくれる。昨年の検索トップは、海岸、墓地、ガソリンスタンド、レストラン、家具屋、そしてアイスクリームショップだった。
さらにGoogleは、昨年のデータに基づいてサンフランシスコやニューヨークなど大都市でもっとも人気の保養地も紹介しているので、 ここをチェックされたい。
[via SlashGear]
Googleは、Google Mapsサービスの位置検索の結果に、人種差別用語など不適切な言葉の不適切な結果が表示されないための対策を、今講じていることを確認した。この問題は今週、黒人差別を表す“n*****”とか“nigga”などの語句の検索結果として、ホワイトハウスが出てきたことに端を発している。
この不手際を詫びるブログ記事でGoogleは、そんな状況が生じたのはMapsサービスの検索がWebのコンテンツを、未検査のまま使っているために、語句と結果とのおかしなマッチングができてしまうためだ、と説明している。それはGoogle本体の検索エンジンと同じ方式であり、そのために検索エンジンでは2007年に、’failure’（失敗）という語句での検索で、結果のトップに（当時の大統領）George W. Bushが出てきたりしたのだ。ただしGoogle検索におけるその種の不具合は、のちに修復された。
Google本体の検索エンジンは、そうやって、ドカン！とやられる“Google爆弾”(Googlebombing)を防ぐための対策が講じられたが、Mapsの方は古いアルゴリズムのままだった、とGoogleは述べている:
弊社のチームはこの問題の修復に真剣に取り組んできました。Google検索のために行った、アルゴリズムの重要な変更をベースに、結果をランキングするシステムをアップデートし、これらの検索の多くに対策を施しました。これは今後徐々に全世界的に展開し、弊社のシステムを時間をかけて継続的に精製して参ります。簡潔に申し上げますと、Google Mapsでこのような結果を皆様がご覧になることがあってはなりませんから、そのことを確実にするために、わたくし共は努力を続けて参ります。
Google Mapsの検索をハッカーが駄目にしたのかもしれない、という説を、Googleのこの説明は、はっきり否定している。
いずれにしても、ユーザが地図に悪質ないたずらをすることに、この合衆国の企業（Google）は神経をとがらせている。先般は、誰もがGoogle Mapsに寄与貢献できるためのツール、Map Makerサービスを、悪質な改ざんが相次いだために閉鎖せざるをえなくなった。それらの中には、Androidのマスコット人形がAppleのロゴにおしっこをかけているイラストもあった。
Map Makerの閉鎖は恒久的ではないが、サービスの復帰がいつになるかをGoogleはまだ発表していない。
昨年YouTubeは60fpsのビデオストリームを導入し、そして今日（米国時間5/21）同社は、そのなめらかな再生をライブのストリーミングでも提供することになった。
今日の発表でGoogleがいみじくも言っているように、これでゲームのストリーミングやライブのスポーツイベントなどがとくにエキサイティングになり、同社はすでにElgatoやXSplitなどのゲーム実況中継サービスを60fpsでストリーミングしている。
YouTubeのライブストリーミングのAPIを使っているアプリケーションならどれでも、この機能を利用できる。
YouTubeは60fpsでやってくるストリームを、自動的に720p60と1080p60のストリームにコード変換し、今のほとんどのブラウザとデバイスで見られるようにする。そのほかに対しては前と同じ30fpsのストリームを提供するが、それらに対しても数週間後には60fpsに対応できるようにする予定だ。
同時にYouTubeは、すでに通常のビデオでは対応していたHTML5向けの再生をライブストリームでもサポートする。それによって可変速度の再生がサポートされるので、たとえば数分ぶんバックしていたところから、倍速でリアルタイムに追いつく、といった見方ができるようになる。
Appleは、iOS 9の標準マップアプリで乗換案内機能をサポートするようだ。乗換案内は、2012年にiOS 6の標準地図アプリだったGoogle MapsをApple製アプリに代えた時になくなった。当初本機能は昨年リリースしたiOS 8に内蔵される予定だったと9to5Macは報じている。
Appleは、iOS 8の公開直前に乗換案内機能を今年に延期する決定を下したと記事は伝えている。新機能は、バス、鉄道、地下鉄の経路、予想所要時間等を提供する。経路は複数提示され、通常の「標準」「地図＋写真」「航空写真」モードに加えて、地域の路線を含む特別な地図を選べる。
乗換案内は多くの都市ユーザーが歓迎するに違いない機能だが（Apple Watchが経路表示をサポートする可能性もある）、Appleはさらに室内マッピングも手がけていると言われている。主要ランドマークやビルディング内の詳しい案内はAppleが欲しい機能の一つだが、6月のWWDCで紹介されるはずのiOS 9アップデートには含まれず、後日となるようだ。
Appleは、HopStopとEmbarkの2社を買収しており、2社は過去に経路マップと案内のiPhoneアプリを提供していた。買収が発覚したのはいずれも2013年だがこれまではiOSの一般公開機能にもデベロッパー機能にも影響を与えていなかった。Appleは、4月に乗換案内専門エンジニアを雇っているので、これを市場に出す意図は明らかだが、それがiOS 9に入るのかもっと先になるかは待つしかない。
[原文へ]
（翻訳：Nob Takahashi / facebook）
一番好きな食べ物はなんですか? 最初の先生の名前はなんといいましたか? 最初に飼ったペットの名前は? こうした質問をみて「ああ、例のあれね」と思い当たる人が多いことだろう。何かのオンラインサービスに登録するときに、セキュリティ対策のひとつとして定型的な質問と、そしてそれに対する回答を「セキュリティキー」として使うことが多いのだ。ただ、Googleの最近の調査によれば、「秘密の質問」とそれに対する答えは、どうやらセキュリティ目的として有効ではないらしい。
Googleの利用者が、秘密の質問を使ってアカウントの回復をしようとするケースにつき数億件の例につき調査してみたそうだ。調査結果をひとことでまとめれば、「秘密の質問は十分に秘密でもないし、またアカウントリカバリーのための方法としても十分に機能しない」ということのようだ。覚えやすすぎるもので、第三者も簡単に推測できたり、あるいは覚えにくいものは、いざという場面では本人すら忘れているということになりがちだとのこと。望まれる「適度なセキュリティ」を実現する役には立っていない様子。
たとえば、英語国のひとたちが「好きな食べ物」に登録するのは「ピザ」であるケースが多いのだ（Google利用者のうち20%が「ピザ」を指定している）。10回の回答が許されるなら、スペイン語圏の利用者の、父親のミドルネームも21%の確率で正解することができる。また多くの人口が大都市に集中しているような国（たとえば韓国）では、生地を応えるのも簡単なこととなる。
また、回答に嘘の情報を記載する利用者も多い（37%）ようだ。たとえば「電話番号はなんですか」という質問と「マイレージ会員番号はなんですか」という質問の双方に、同じ番号を設定している人もいるらしい。もちろん現実的には、この両者が一致する可能性などあり得ない。
さらに、アメリカの英語利用者のうち40%が、自分の設定した回答を思い出せないでいるようだ。たとえば「マイレージ会員番号はなんですか」という質問に対し、正しく回答する人の率は9%なのだそうだ。
「秘密の質問」が、往々にして簡単すぎるセキュリティ基準となってしまうのであれば、複数の質問をクリアしなければならないようにするというのが考えられる対応策となるだろう。これによりアタックを回避できる確率は確かに上がるはずだ。ただし、正規の利用者が正しい答えを忘れてしまう確率もまた上がってしまうのだ。
Googleは、SMSを介したバックアップコードの利用や、セカンダリーメールアドレスの活用などで、利用者の認証をすべきだろうと結論している。「秘密の質問」方式は、どうしても他の手段を取り得ない場合に使用すべきだとのことだ。
［原文へ］
（翻訳：Maeda, H）
アプリケーション開発ツールは競争がますます激化しているが、その中で、JavaScriptでWebやモバイルのアプリケーションを開発するためのフレームワークやツールを提供しているMeteor Development Groupが、2000万ドルの資金を調達した。
このラウンドはMatrix Partnersがリードし、Andreessen HorowitzとTrinity Venturesが参加した。資金は同社が、従来のオープンソースのフレームワークとツールに加えて、有料のプロダクトを開発するために充てられる。
Meteor Development GroupのCEO Geoff Schmidtが描く大まかなロードマップによれば、最初に予定しているプロダクトはGalaxyだ。それは、Meteorで作ったアプリケーションをGoogleのオープンソースプロジェクトKubernetesの上で動かすためのシステムで、Kubernetes自体は、コンテナに収めたサービスとして動くアプリケーションのためにリソースを管理するシステムだ。
リリースは今年後半を予定しているが、SchmidtによるとGalaxyは、すでにMeteorを使ってアプリケーションを作っている一部の企業を対象に、最初の展開を行う。これらの企業がMeteorと密接に協働して、現用経験に基づくフィードバックを提供する。つまり最初のデリバリは、非公開ベータのようなものだ。一般公開の時点では、Galaxyは、無料、時間制料金、エンタプライズの計3種のプランで提供される。
同社のユーザはAmazonのインフラストラクチャを使っているところが多いので、Galaxy も最初はAWSで使うバージョンが提供される。しかし将来的には、Microsoft AzureやGoogleのCloud Platformにも対応していく。
しかし上述のように、Galaxyはあくまでも同社の最初の有料製品だ。Schmidtによると、アプリケーションの構築やホスティングも重要だが、アプリケーションのパフォーマンス分析やテストも、開発と同じ比重で並行しなければならない。そして、そのためのプロダクトも、彼の脳裏のロードマップにはすでに載っている。
以上のような長期的な取り組みのほかに同社は、同社のユーザ層（デベロッパ）拡大のための喫緊のオープンソースプロジェクトも進めなければならない。すでにUIのライブラリは提供しているが、一部のデベロッパはAngularやReactを好む。Meteorはモジュール構造なので、そういう他のUIフレームワークとの併用も可能だが、しかし今では、それらを直接にサポートするための方法を開発中だ。Windowsのサポートに関しても同様で、こちらはかなり前から開発に着手している。
Googleは検索結果にツイートを加えた。ツイートが表示されるのはAndroidとiOSのGoogle公式アプリ、モバイル・ブラウザとデスクトップだ。検索の際にTwitterというキーワードあるいはハッシュタグを入力するとTwitterが検索される。Twitter上でポピュラーな話題の場合はこうしたキーワードなしでも結果が表示される。当面は英語のみの機能だが、今後他の言語にも拡張される予定だ。
Googleは公式ブログでこの試みを「リアルタイム情報の拡充のため」だとしている。同時にTwitterのユーザーがこれまでより広い範囲のオーディエンスを獲得することになるので、Twitterにとってもネットワーク拡大と新規ユーザー獲得のために大いに有利に働くだろう。
Twitterも自身のブログでGoogleとの新たな取り決めを報告しているが、内容はGoogleブログのものとほぼ同一だ。どちらのブログもこの提携は当面、主要言語に英語を選択しているアメリカのGoogleユーザーがGoogle.comにアクセスした場合が対象となるとしている。ただし数ヶ月で他の言語にも拡張される予定だ。
あらたな取り決めでツイートが公開される範囲が大きく拡大されたことは確かだが、Twitterが新しいユーザーを獲得するためには、自らがそれ自身で価値あるデスティネーションだということを引き続きに証明していく必要があるだろう。Googleの検索結果に現れるというだけでは、平均的な検索ユーザーの目に止まる可能性はやはそれほど高くなさそうだ。
〔日本版〕日本からでも主要言語を英語にすればツイートが検索される。Barack Obama tweetのように入力するとオバマ大統領の最初のツイートがトップに表示される。
[原文へ]
（翻訳：滑川海彦@Facebook Google+）
Googleが今日（米国時間5/18）またまた、同社のクラウドコンピューティングプラットホームの料金を値下げした。また、企業がクラウドコンピューティングの利用でさらに一層の省マネーを図れるための、新しいインスタンスタイプを導入した。
今日の値下げはCompute Engineが中心で、最小のインスタンスで最大30%の下げとなる。その、Google Cloudプラットホーム上のMicroインスタンスは、通常の利用で1時間0.006ドル（0.6セント）になる。そのほかのインスタンスは、これほど激しくはなくて、High CPUインスタンスで5%、Standardインスタンスで20%の値下げとなる。
Googleの主張によると、これでGoogle Cloud Platformの利用料金は多くのワークロードにとって40%安くなるそうだ。例によってこういう数字は、眉に少し唾をつけて見る必要があるが、しかし誰の目にも明らかなのは、Googleがクラウドコンピューティングを継続的に値下げしてAmazonやMicrosoftなどに勝ちたい、というその意志だ。
今日同社は値下げと並行して、preemptible instances（プリエンプティブルインスタンス）と呼ばれる新しいインスタンスタイプのベータをローンチした〔仮訳: （ユーザでなくシステム側に）先買権のあるインスタンス〕。Amazonのspotインスタンスにやや似ているこのインスタンスは、Googleのデータセンターのアイドルリソースを使うので、standardインスタンスよりも70%安くなる。
ただしCloud Platformは、リソースが必要になったらそのインスタンスを、30秒の警告ののちに終了させる。このインスタンスの上では、フォールトトレラントなサービスしか動かすべきでない、ということ。spotの場合と同じく固定料金なので、料金の変動を心配する必要はない。
Googleの自動運転技術が、新たな段階に踏み出すことになるようだ。今年の夏から、Googleの開発した自動運転専用車をマウンテンビューの公道でテストすることになったのだそうだ。
一般車に自動運転機能をもたせた自動運転カーについては、6年間にもおよぶテスト走行の全体で11件しか事故に遭遇していないとアナウンスしている。しかも事故の原因はいずれのケースも人間側にあるそうだ。このような成果も踏まえて、次のステップに進むこととなったようだ。Google謹製自動運転専用車の公道テストは、最高速度が時速25マイルに制限され、かつ操作パネルを使ってハンドル、ブレーキ、アクセルなどの操作を奪取するための操縦者を搭乗させることも条件となっている。
Googleの自動運転カーは既に100万マイル近くの経験を積み重ねており、さらに毎週1万マイルの経験を追加しているところなのであるそうだ。Googleによれば、これは人間に換算して75年の運転経験にも匹敵するものであるそうで、誰にも負けない経験を積み重ねてきていると主張している。
Google曰く、この経験はこれから公道テストを行う自動運転専用車にもそっくり引き継がれるものであるとのこと。
「数年のうちには、私たちの自動運転専用車を使ってどのようなことができるのかを調査する、パイロットプログラムの運用を開始したいとも考えています」とGoogleは言っている。
実用化にはまだまだ超えなければならないハードルがあるのだろう。しかしマウンテンビューでは、日常的にGoogleのロボットカーに遭遇するという時代に突入しそうだ。
［原文へ］
（翻訳：Maeda, H）
Googleは今週、Gmailの新しいログイン画面を静かに公開したが、この変更を喜んでいない人々もいる。
従来、Gmailユーザーはユーザー名とパスワードを同じページで入力していたが、新しいログインフローではこのプロセスが分離される。まずログイン名を入力し、次のページでパスワードを入力する。時間がかかるようになったと苦情を言う人や、様々なパスワードマネージャーを使ったログインができなくなったことを指摘する人もいる。
Googleの説明によると、この変更は「パスワードを補完する将来の認証システム」に備えて実装された。詳細は明らかにされていないが、恐らく二段階／二要素認証かハードウェアドングル、あるいはAndroidの「スマートロック」システムのウェブ版のような、セキュリティーを強化する別の方法を指しているのかもしれない。
スマートロックは、Androidユーザが自分の端末を信頼済みBluetoothデバイスに接続しているか、信頼された場所に置いてあるか、身につけているか （「オンボディー・ディテクション）あるいはデバイスに顔認識させることによってアンロック状態が続くしくみだ。もちろんGoogleは、ウェブ版Gmailで将来何を計画しているかを言ったりしないだろうが、業界の誰とも同じく、ユーザー名／パスワードの組み合わせでアカウントを保護する方法が理想にほど遠いことを彼らは知っている。
Googleは既にAndroidのログインフローをそのしくみをサポートするために分離しているので、同じことをウェブでも行うのかどうかは興味深い。
Googleがサポートを考えているであろう将来のログイン方法に加えて、新システムはSAML SSOユーザー、即ちGoogle以外の認証プロバイダーを使ってログインする企業ユーザーや学生にとっては「体験が改善」され、複数のGoogleアカウントを持つ人々にとって「混乱が緩和」されるだろうと同社は言っている。
しかしその2点は議論を呼ぶところだ。これまでのところGoogleの発表に対する反応はあまり肯定的ではない。ユーザーたちはこの変更について、従来1ページだったものが2ページになって時間の無駄だと不満を漏らしている。あるいは、ユーザーIDを入力した後、フルネーム、時には顔写真まで表示されてからパスワード認証が行われるのはプライバシーの侵害だと言う人々もいる。
そしてもちろん、現在使われている人気のパスワードマネージャーは殆どが新しいGmailログイン画面に対応していないが、これは一時的な現象だろう（例えばLastPassは、修正版を今日公開すると言っている）。
この変更は間違いなく、物事の古いやり方から、Googleがパスワードに別レイヤーを加えるか、パスワードそのものを取り払うことによってログイン方法を補強あるいは改善しようとしている将来へと進むための一段階だ。しかし、この「改善された」システムが完成する前に公開してしまったことは、多くのユーザーを混乱させてしまったようだ。
[原文へ]
（翻訳：Nob Takahashi / facebook）
今週Googleは「われわれはクラウドにオールイン〔ポーカーでチップを残らず賭けること〕する」と発表した。クラウド・サービスのパイオニアとして特に大胆な決断のようには聞こえない。しかし今日（米国時間5/13）のWall Street Journalの記事によると、Googleは社内業務に用いられるほとんどすべてのアプリをインターネット経由のクラウドアプリにしたという。
Googleはわずか2年前の2013年でも社員が外部クラウド上のアプリを使うことをセキュリティー上の理由から禁止していた。大手クラウド事業者が、クラウドを信頼できず、社員に私有デバイスの持ち込みや外部クラウドの利用を禁止するというのは笑うべき矛盾だと批判された。
しかしGoogleもここに来て他の大企業と学んだのと同じ教訓を学んだのだろう。企業のファイアウォールはセキュリティーを保証しない。Googleは社員がどこにいようと、どんなデバイスを用いていようといちいち身元を認証し、会社の建物の外からであろうと中からであろうと一切の通信を暗号化しなければならないことに気づいたようだ。
Sonyの大規模なデータ漏えい事件の直後に、MicrosoftでWindows事業部のプレジデントを務め、現在はBox顧問のスティーブン・シノフスキーは「伝統的なファイアーウォールで守らた企業内データセンターのほとんどよりクラウドの方がずっと安全性が高い」とブログに書いた。
シノフスキーはSonyやTargetが見舞われたようなハッキングによるデータ漏えいがクラウドでは決して起きないと保証はできないとしながらも、クラウド事業者のセキュリティーを破るほうが一般企業のセキュリティーを破るよりはるかに困難だろうと指摘している。
Bessemer Venture Partnersのパートナー、David Cowanは1990年代から企業のセキュリティーを調査しているが、シノフスキーの意見に概ね賛成している。ただし、すべてのクラウド事業者のセキュリテイーレベルが同一ではないと注意を促している。Cowanはわれわれの取材に対してこう語った。
AmazonやGoogleなど有力クラウド事業者のセキュリティーが一般企業が独自に開発したセキュリティーより優れているという点については完全に同意する。
現在われわれが利用するアプリやウェブサイトのバックエンドはさまざまなレベルのクラウド・サービスによって支えられている。しかしデジタル生活をささえるこうしたちょっとしたアプリの背後にあるクラウドが必ずしもGoogleやAmazonなみのセキュリティーを備えているとは限らない[という問題がある]。
急成長したクラウド企業、Boxの場合、しばらく前から社内業務のほとんどをクラウド化している。 CITEworldの2014年3月の記事で当時のCIO、Ben Hainesが「われわれはクラウドにすべてを託している。それによってオンプレミスの処理であったら生じるはずのあらゆるコストをなしですませている」と書いている。
どうやらGoogleも今週になってBoxと同じレベルに達したようだ。現在のビジネス環境では、社員は地理的にどこにいようと、どんなデバイスを用いていようと、企業データにアクセスできなくてはならない。したがって「クラウドにすべてを託す」以外に現実的な方法はないだろう。
しかし問題は多くのIT専門家が伝統的なセキュリティー概念にしがみついて離れようとしないことだ。この1年半ほどの間にわれわれはSony、Target、Anthem、JPMorganその他で起きた大規模なデータ漏えい事件から、いくらファイアーウォールの陰に隠れてもセキュリティーは守られないという教訓を得たはずだ。
Googleもやっとこのことを認めたのだろう。
[原文へ]
（翻訳：滑川海彦@Facebook Google+）
オンラインコミュニケーションの機会は質・量ともに拡大している。しかし、それがために無駄にする時間も増えているのではないかと考える人がいるようだ。すなわち、IMのウィンドウを見ながら無為に過ごす時間が増えているのではないかという意見だ。そして、そういう問題を解決しようとするアプリケーションも生まれてきた。WaitChatterというもので、IM画面前でスタンバイしている時間を、スキル取得のための有効な時間に変えてしまおうというプロダクトだ。Google Chatの利用中、相手が返信してくるまでの空き時間で外国語の単語を覚えることができる。
このアプリケーションはMITのComputer Science and Artificial Intelligence Labの研究から生まれたものだ。調査によるとIMを利用する人は平均して10分ないし15分をアプリケーションの前で無駄に過ごしているのだそうだ。この無駄な時間をボキャブラリービルディングの時間に使おうと考えて作られたわけだ。このWaitChatterは、今のところGoogle Chat（Hangoutsに移行してしまった人は、Google Chatに戻す必要がある。但しこの作業は簡単に行うことができる）用のエクステンションとして提供されている。チャットウィンドウ内に学習用のコンテンツが表示されるようになっている。。
単語学習アプリケーションは数々あれど、意識的に学習時間を作って利用するのは精神的な負担にもなるものだ。空き時間を活用しつつ、そして精神的な負担もなくして学習に役立てようというのが狙いだ。
先行テストの段階では、予め用意された単語リストや、IM中で利用された用語から1日に4つほどの単語が表示させるようになっていたとのこと（訳注：正式リリース版はプライバシーの観点から、チャットメッセージから単語を取得するようなことはしていないようです）。このような方法で外国語がマスターできたり、あるいはネイティブになれたりするわけではない。しかし単語を覚える程度のことにならば、ちょっとした空き時間も有効に活用できるというわけだ。
このWaitChatterを産みだしたリサーチチームは、チャットの場合のみならずメールの読み込み時や、あるいは実生活においてタクシー待ちをしている場合のような「空き時間」を有効に活用する方法を模索しているところだとのこと。
ところでWaitChatterは今のところ、Google Translateが対応しているアルファベット言語に対応している。今後はまず、SkypeやFacebook Messengerなどの他IMプラットフォームにも対応していきたい考えなのだそうだ。
［原文へ］
（翻訳：Maeda, H）
[筆者:Derrick Harris ]
編集者注記: Derrick HarrisはMesosphereのシニアリサーチアナリスト。Harrisは最近GigaOMに、クラウドとビッグデータについて書いた。
インターネットはこれまでの20年間で生活を大きく変えた。Webとモバイルのアプリケーションで、どこからでも、情報の検索と買い物とスムーズなコミュニケーションができ、しかもそのスピードは、これまでありえなかったほどに速い。車のダッシュボードでおすすめの映画を知り、携帯電話でビデオの制作と掲載ができる。温度計を買えば、仕事に出かける時間に暖房を消してくれる。
テクノロジ業界の外にいる人には、これらの技術進歩がマジックのように見えるかもしれないが、実際にこれらのアプリケーションを作っている人たちは、そこにどれだけ多くのものが込められているかを理解している。でも最近ではビジネスの世界にいる人たちみんなが、それを理解していることが重要になりつつある。
その理由は簡単だ: 優秀な企業は、次の10年の企業競争で落伍しないためにはITについてまったく新しい考え方をしなければならないことを理解している。モバイルアプリから冷蔵庫に至るまでのあらゆるものが、さらに一層個人化され、一層インテリジェントになり、より機敏に反応しなければならない。企業は機械学習を行い、センサのデータを取り入れ、ユーザのトラフィックの予期せざる急騰に無事に対応しなければならない。
後戻りはできない。アプリケーションが、ユーザが期待する体験を提供できなければ、彼らは、それを提供できるほかのアプリケーションを見つけるだろう。
アプリケーションとWebサイトのユーザは、過去数年間で百万のオーダーに達し、アプリケーションのそれまでのアーキテクチャは、その膨大な量のトラフィックとユーザデータに対応できなくなっている。さらに最近では、その大量のデジタルデータを有効利用しようという欲求が生まれ、その目的だけに奉仕するまったく新しい種類の技術への関心が芽生えてきた。
それらの技術には多くの場合、サーバの複数のクラスタにまたがって容易にスケールできるように設計された新しいストレージや処理能力、およびデータベースのフレームワークを作ることが含まれている。またさらに、これら各部位間の情報の移動を単純化し、高速化することも求められる。GoogleやLinkedIn、Facebook、Yahoo、Twitterなどの大きなインターネット企業では、この同じ一般的パターンが、何度も何度も繰り返し実装されている。
たとえばデータベースのレイヤでは、ほとんど誰もが関係データベースからスタートし、今になって新しいプランを考えなければならなくなっている。一部の企業は、MySQLデータベースをその自然な限界を超えて酷使するために、秘かに何百万ドルもの費用と人時間を投入し続けている。逆に新しいデータベース技術を作ったところもあるし、新旧の二股をかけているところもある。
またビッグデータの処理でも、新しいパターンが生まれている。具体的な技術はさまざまでも、今の大型Web企業に共通している新しいアーキテクチャは、データ処理のリアルタイム部分と、準リアルタイム部分と、バッチ部分という三層構造だ（下図）。必要に応じて、個人化されたWeb体験やコンテンツ体験をリアルタイムで高速に提供しなければならない。しかしまた同時に、社内のデータアナリストやデータサイエンティストたちが、データの集合に対して彼らの能力を十二分に発揮できなければならない。
今ITに起きているイノベーションは、ものすごいスケールだ。GoogleやFacebook、Amazonなどは日々数十億のユーザに奉仕し、数百万件のユーザ対応処理が並列で行われている。それと同時に、大量のデータが保存される。しかしそれでも、彼らはめったにクラッシュしない。Twitterも、インフラストラクチャに思い切った投資をしてからは、あのfail whale（クジラさん）が現れなくなった。
これらの企業はこれまで、MapReduce、Hadoop、Cassandra、Kafkaなどなど、数々の技術を生み出してきた。また無名のスタートアップやデベロッパたちも、主にオープンソースの世界で、アプリケーションのパフォーマンスをとスケーラビリティを高め、ときにはまったく新しい機能を実現するための新しいツールを作ってきた。それらの中では、Spark、Storm、Elasticsearchなどがとくに有名だ。
また、そのような極端に巨大なスケールでも安定して動くアプリケーションを開発するための、アプリケーションの新しいアーキテクチャも生まれてきた。
たとえば、今いちばんもてはやされているのがマイクロサービスだ。これはアプリケーションを個々のサービスの集合として構成するアーキテクチャで、部品であるサービスは複数のアプリケーションから使われてもよい。これまでの、一枚岩的なアプリケーションアーキテクチャでは、各部位がそのアプリケーションの専用の部品として閉じ込められている。しかし、自立した個々のサービスの集まり、という新しいアーキテクチャでは、各部位間や、部位と特定のアプリケーションとのあいだの依存性がなくなり、サービスのスケールアップをアプリケーションの再構築を必要とせずに実現できる。
また、マイクロサービスと並んでビッグなトレンドになっているのが、コンテナ化だ。コンテナは、Dockerのようなデベロッパフレンドリなフレームワークを利用して作ってもよいし、もっと低レベルにLinux control groupsを使ってもよい。コンテナに収めたアプリケーションは分散サービスに容易にプラグインでき、いつ何をどこで動かすか、などをいちいち気にする必要がなくなる。コンテナがあることによってデベロッパは、自分のアプリケーションの機能や構造の磨き上げに集中できる。
以上のような、分散サービスの集合体とコンテナ化という新しいアーキテクチャ技術を一つの全体として見た場合には、それを“data center application stack”（データセンターアプリケーションスタック==アプリケーションの基本構成要素としてのデータセンター）と呼べる。奉仕すべきユーザが複数のプラットホーム上に何百万もいるようなアプリケーションを作り、それらのアプリケーションが多量かつ多様なデータをハイスピードで利用していくときには、どうしてもそういう、サービスの集合体的なものを使うことになる。したがって高性能なデータセンターが、いわば、アプリケーションの心臓部になる。
これらは、将来そうなるという説ではなくて、今急速に進展しているトレンドだ。巨大な消費者アプリや、Salesforc.comのような巨大なビジネスアプリケーションを志向するスタートアップたちのあいだでは、これらの技術がすでに常備品になっている。
またデベロッパやスタートアップだけでなく、企業も変わりつつある。Fortune 500社だけでなく、ITのイノベーションとは無縁と思われていた中規模の企業ですら、インターネットの時代に対応しようとすると変わらざるをえない。したがって彼らも、今ではデータセンターが提供するサービスに関心を持ち始めている。データセンターのアプリケーションスタック化は、企業の内部にも浸透していく。
“ビッグデータ”と“リアルタイム”と“物のインターネット(IoT)”は、今や単なるバズワードではなく、21世紀の経済において企業の成功を左右する必修科目だ。
しかしこれらはいずれも、実装が難しい。Hadoopをデプロイして管理してスケールする。Cassandraを〜〜〜〜。Kubernetesを〜〜〜〜。等々。使用するフレームワークやサービスごとに、あなたは手を洗って同じことを繰り返す。実装の困難さは、口にしてもしょうがないから、誰も口にしない。だから、世に氾濫する‘かっこいい話’には出てこない。
でもある時点で企業は、それまでのアプリケーションの書き方を反省し、データのパイプラインを築くことで、より強靭なアーキテクチャを確保したくなるだろう。
GoogleやMicrosoftのような、大きくてエンジニアをたくさん抱えている企業は、この問題をBorgやAutopilotなどのシステムを自分で作って解決してきた。こういうシステムがあると、リソースの適正な割り当てを自動的にやってくれるから、何百万台ものサーバにまたがって動くサービスやアプリケーションの高い可用性が確保される。デベロッパやソフトウェアアーキテクトが頑張らなくても、アルゴリズムが、どこで、何を、どれだけのマシンの上で動かすかを決める。
しかし、BorgもAutopilotもすばらしいシステムだが、どちらもプロプライエタリだ。Googleが某論文の中で、Borgというものの存在を認めたのも、ごく最近のことだ。MicrosoftはAutopilotについて、ほとんど何も明らかにしていない。そしてBもAも、一般的なサービスとしては提供されていない。
そこで、Mesosphereだ、というお話になるのだが、それは次の機会のお楽しみに。
〔原文のコメントに、Microsoftの元社員からの反論があります。〕
Apple Watchには、既に数多くのサードパーティーアプリケーションからなるエコシステムが作られている。4月の発売直後には3500種類のアプリが揃い、Facebook、Instagram、Twitter、Evernote等の大物をはじめ数多くが名を連ねた。しかし、Appleの新プラットフォームにアプリのない目立った存在がGoogleだった。今日それが変わった。GoogleはiOS版Googleニュース＆天気情報をアップデートしてApple Watchに対応した。
Apple Watch版Googleマップほど魅力的ではないが、この動きはGoogleが自身のスマートウォッチプラットフォームであるAndroid Wearとライバル関係にあるという理由でApple Watchを無視してはいないことを示している。これはGoogleが今後他の製品もApple Watchに載せるかもしれないことを意味するだけに期待がもてる。
Googleニュース＆天気情報アプリは、Apple Watchの様子を見るには手頃な第一歩であり、既にApple Watchに参入しているNPR、CNN、NYT等の主要ニュースサービスと似ている。
ニュース＆天気情報はiOSアプリとしても比較的新しい。はじめにAndroid版が作られ、その後iOS版が出たのは昨年秋だった。6万5000種類のメディア ― ウェブ版Googleニュースと同じ ― の見出しが「テクノロジー」「スポーツ」「ファッション」等のカテゴリー別に表示される。ユーザーは、ニュースセクションをパーソナライズしたり、地元のニュースと天気を見ることもできる。
今日（米国時間5/12）、アプリはアップデートされ、数あるGoogleのモバイルサービスの中で最初にApple Watchをサポートした。多くの競合アプリと同じく、ユーザーはApple Watchの小さな画面を左右にスワイプしてヘッドラインを見る。現在約10件の見出しをスクロール表示することが可能で、下にスワいプして写真を見ることもできるが、NYTのApple Watchアプリとは異なり、記事の全文はもちろん抜粋すら読むことができない。記事の続きをiPhoneで読むためのHandoffもサポートしていない。
ただし、見出しをフォースタッチ（Apple Watchの画面を強く押し込む）することによってSafariのリーディングリストにニュースを保存できる。
全体的に見てこのアプリはごく基本的なもので、Apple Watchにインストールされた数あるアプリの中から探し出して起動するというより、「グランス」（Apple Watchの簡易アプリ）として使うべきだろう。他のWatchニュースアプリと比べて、あえてこれを推奨することは難しいが、現時点では完成したスマートウォッチニュース閲覧体験というより、一つの実験と見るべきだろう。
本誌はGoogleに、このニュースを踏まえた将来のApple Watch戦略についてコメントを求めており情報が入り次第続報する予定。
[原文へ]
（翻訳：Nob Takahashi / facebook）
世界中の人が、人生で最悪のものは電子メールである、と感じている。たしかにそれは郵便を陳腐化し、テキストによる通信のスピードをそれまでの20万倍速くしたが、その代償として多くの人が広告宣伝やニューズレターの洪水で溺れそうになっている。でも、親愛なる友よ、まだ希望はある。今や人気最高のGIF検索共有サービスGiphyを、Gmailの作成ウィンドウから使えるのだ。
そう、その小さなChromeエクステンションを使えば、Gmailの新規メッセージや返信のウィンドウで直接、Giphyを使える。
“GIFをもっと簡単に使えるようにしてほしい、という要望がいろんな会社からあったのよ”、とGiphyのキラキラ爆弾女王様(queen glitter bomb at Giphy)を自称するNutmegのファウンダ、Julie Loganが説明する。“今回は、InboxのSDKを使って、GiphyをGmailの作成ウィンドウにぶち込んだのよ”。
テキストをフォーマットするための正規のアイコンの横に、おなじみの虹色のGiphyアイコンが出現する。そのアイコンをクリックすると、今人気上位のGIFがいくつか並んだミニウィンドウがポップアップする。そこから検索して、選んで、クリックすると、そのGIFがメールと一緒に送信される。
Giphyはほかにも、いろんなアプリとの統合をやってきた。たとえば、Slackには、メッセージングが手間取る原因の一つである翻訳(Translate)を統合した。
GiphyのGmailエクステンションをダウンロードしたい人は、ここでどうぞ。スラムダンクみたいに、一瞬よ！
Rackspaceの元役員や技術者たちが始めたDevOpsサービスScaleFTが今日（米国時間5/11）、本家Rackspaceからの戦略的投資として80万ドルのシード資金を獲得した、と発表した。この投資ラウンドには、CoreOSのCEO Alex Polviなど、数名のエンジェル投資家も参加した。なお、PolviはRackspaceの出身だ。
前から報じられているように、RackspaceはクラウドサービスとしてAmazon(AWS)やGoogle、Microsoftなどと競合するだけでなく、それらのユーザを顧客とするサービスを提供しようとしている。ScaleFTの協同ファウンダでCEOのJason Luceが言うように、ScaleFTのプロダクトはRackspaceのそういう最近の方向性にもフィットしているのだ。
Luceは今日の声明文の中で、“RackspaceはAWSやGCE、Azureなどのユーザが利用するサービスを積極的に手がけてきたが、ScaleFTはそういうRackspaceのOpsチームが彼らの新しい戦略のために必要とするツールを、より高度化する。Rackspaceが弊社の取り組みを支援するのは、そのためである”、と述べている。
同じく今日ローンチするScaleFTの最初のプロダクトScale Accessは、サーバへのアクセスをより容易に、そしてよりセキュアにする。同社の主張によると、SSHの秘密鍵に基づく認証ソリューションは、面倒であるだけでなく、実はそれほどセキュアではない。“今あるRSAやX.509、SSHなどの技術はあまりにも複雑なので、企業がそれらをもっとも効果的に利用することが難しい”、とLuceは述べている。
それに対してScale Accessは、有効期間が数分と短いキーを使用し、その認証ソリューションはGoogle AppsやSAMLのようなシングルサインオンのソリューションに統合できる。そのためそれは、認証のための第二要素を必要とするツールで利用できる。
つまりSSHをそのまま使えるし、AnsibleなどのIT自動化ツールも従来どおり使える。そしてScaleFTのサービスが、VPNやWebアプリケーションや、そのほかのインフラストラクチャサービスへの証明を発行するのだ。
Googleは、検索の巨人にとって初めてのタイプのChrome拡張機能を公開した。新しいChrome User Experience Surveys拡張機能は、例えば通知やマルウェアの警告等、ブラウザーで普段と違うことが起きた時にポップアップして、ユーザー体験に関する簡単なアンケートを取る。GoogleはユーザーのフィードバックをChromeの改善に活用すると言っている。
Googleは、調査用ポップアップが表示される回数は1日当たり最大2回、1週間あたり最大4回と言っているので、雑音はさほど多くはならないだろう。調査の回答に要する時間は約2分。
もちろんGoogleは、一部のユーザーがこの拡張機能をインストールしたがらないことを知っている。閲覧傾向を追跡されることを心配するからだ。同社は、この拡張機能を通じてユーザーの行動を監視することはないと言っている（もっとも、Googleの様々なプログラムにオプトインしている人なら、Googleはあなたの検索およびブラウジング習慣を既に十分すぎるほど知っている）。「この拡張機能がGoogleに送信するデータは、その稀な現象が起きた日時とユーザーの回答内容だけ」と同社は言っている。フィードバックはすべて匿名。
Googleはこのプログラムを促進するための人参をぶらさげていないが、もし試してみたいなら ― そしておそらくその過程でChromeをより良く使いやすくする手助けをしたいなら ― 拡張機能はChrome Web Storeでインストールできる。
[原文へ]
（翻訳：Nob Takahashi / facebook）
Googleの検索結果から、料理デリバリーのオーダーが直接行えるようになった。まず対応するのはアメリカ国内で、Seamless、Grubhub、Eat24、Delivery.com、BeyondMenu、およびMyPizza.comによる料理デリバリーを申し込むことができる。
利用者が、Googleにてレストランの情報を検索したとする。すると検索結果の中に「配達オーダー」（place an order）が表示されるようになるのだ。オーダーする場合には希望するデリバリーサービスを選ぶことになる。あとはそれぞれのサービスの画面にてオーダーを行う。
ご存知かもしれないが、料理のデリバリーサービスは昨年、6億ドルものベンチャー資金を集めている。2012年に2500万ドルであったことを考えれば尋常ならざる成長であると言って良いだろう。ただし依然としてレストランに直接電話をしてオーダーするという人が多い様子だ。そのような中、Googleの検索結果に料理デリバリーサービスが表示されるようになることで、サービスの知名度も上がっていくことになるのだろう。サービスの市場拡大は「歴史の流れ」といってもよいほどに確実なことであり、そのような中で、Googleはサービスに関連したさまざまなデータを手に入れたいと動いているわけだ。
Googleが検索結果に表示しているSeamlessやGrubhubは、複数レストランのメニューを配達するサービスを手がけている。そうすると、他種類の食べ物を扱っていることで、食べたいものを検索する人の検索結果画面に、自社のデリバリーサービスが表示されることも多くなってくる。
検索結果ページでさまざまなデリバリーサービスを表示することで、Googleとしても人気のデリバリーサービスについての情報を集めることができるようになる。また、人気のメニューやレストランの情報もGoogleに集まってくることとなる。こうした情報は、GoogleにとってもEコマースサービスの展開などに役立つこととなるわけだ。
［原文へ］
（翻訳：Maeda, H）
Googleはウェブサイトの表示を高速化するサービス、PageSpeedを来る8月3日をもってシャットダウンすると発表した。サービスを利用しているデベロッパーはそれまでにDNSやサイトの設定を対応させる必要がある。新規登録はすでに停止されている。
PageSpeedは4年半前にスタートしたサービスで、数多くの最適化テクノロジーを用いてサイトがユーザーに表示されるスピードを向上させていた。これには画像圧縮、キャッシュ最適化、JavaScriptとCSSの処理の高速化、静的データのキャッシュとGoogleのサーバーからの送信などが含まれていた。PageSpeedは後発のCloudFlareに似ているが、CloudFlareのようなセキュリティー向上機能は持っていなかった。
GoogleはPageSpeedで提供してきたテクノロジーの大部分をApacheやNGINXのウェブサーバーツールとしてオープンソースで公開しているので、Googleこれらのツールのホスティングを中止した後もデベロッパーは同様の機能をローカルで実現することができる。また多くのウェブサイトのホスティング・サービスがPageSpeedモジュールをサポートしている。GoogleはPageSpeedを運用しているCDNとしてEdgeCastのEdge Optimizerを挙げている。
それではGoogleがこのサービスを停止する理由は何だろうか？ Googleは「残念ながら別の分野に注力することが必要な時期となった」とだけ述べている。この分野でCloudFlareの存在が優勢になるにつれ、Googleは1、2年前からPageSpeedの改良に熱意を失っていたように思える。
[原文へ]
（翻訳：滑川海彦@Facebook Google+）
Googleが今日（米国時間5/6）、新しいNoSQLデータベースCloud Bigtableをローンチする。名前が示しているように、それは同社のデータストレージシステムBigtableを利用しているが、APIはApache HBaseのそれと互換性があり、というかHBaseもGoogleのBigtableプロジェクトを利用しているのだ。BigtableはGmail（メール）やGoogle Search（検索）、Google Analytics（アクセス分析）も利用しており、いわば実戦で鍛えられたサービスだ。
GoogleはCloud Bigtableのレイテンシがひと桁のミリ秒で、コストパフォーマンスはHBaseやCassandraの二倍、と約束している。HBaseのAPIをサポートしているから、Cloud BigtableをHadoopのエコシステム内の既存のアプリケーションと統合することも可能だが、また同時に、GoogleのCloud Dataflowもサポートしている。
Cloud Bigtableのクラスタはわずか数秒でセットアップでき、ストレージはユーザのニーズに応じて自動的にスケールする。
なお、GoogleがクラウドベースのNoSQLデータベースを提供するのはこれが初めてではない。同社のApp Engineプラットホーム上ではかねてからデベロッパが、高可用性のNoSQLデータストアCloud Datastoreを利用できている。そのサービスもやはり、Bigtableがベースだ。Google Cloud PlatformのプロダクトマネージャCory O’Connerによると、Cloud DatastoreはWebアプリケーションやモバイルアプリに多い、リード主体のワークロードに向いているそうだ。
“Cloud Bigtableはその逆で、大規模なデータ処理を必要とする大企業など向けに設計されており、複雑なワークロードに対応する”、とO’Connerは言っている。“たとえば、企業がデータをストリームでぶち込んだり、データの分析をしたり、一つのデータベースから大量のデータをサーブする、といった用途にCloud Bigtableは向いている。弊社の顧客は今後、Cloud Datastoreでプロトタイプを作り、大規模で複雑なデータ処理を伴う本番の展開ではCloud Bigtableへ移行する、というパターンになるだろう”。
この新しいサービスは当面ベータで提供されるので、誰でも利用できるけどSLAや技術的サポートは提供されない。
