Google – HTML5Experts.jp

AIファースト時代のSEOはどうなる？―辻正浩さんに“SEOに効く”Web制作でのポイントを聞いてみた！

馬場美由紀 — Tue, 20 Mar 2018 01:00:51 +0000

連載： Webの未来を語ろう 2018 (3)

HTML5 Experts.jp編集部の馬場です。毎回豪華ゲストをお呼びして、Webの現在と未来について語っていただく公開座談会企画「Webの未来を語ろう」シリーズ第3弾！

今回は検索エンジン最適化（SEO）の第一人者である辻正浩さんをお招きし、2018年のSEOを語る上で欠かせないことやWeb制作で気をつけたいポイント、「AI First」時代のSEOはどうなっていくのかなどを語っていただきました。

今回のゲスト

辻正浩さん（株式会社 so.la 代表取締役SEO）

Search Engine Optimizer。
1974年北海道生まれ。営業、広告制作、Web制作の経験の後、株式会社アイレップでSEOの専門家としての活動を開始。様々な業界・規模のWebサイトのSEOを担当する。 2011年10月に独立の後、株式会社so.laを設立。SEO専門家としてWebサービスやECサイト、企業サイトのSEOに取り組む。特に大規模サイトを得意とし日本有数の大規模サイトのSEOを多数担当している他、各地での講演にてSEOの啓蒙活動を行なっている。

SEOのエキスパート、辻さんの空前絶後な仕事術

白石：日本で検索される約5％は辻さんの顧客のサイトなのだそうですね。現在はお一人で13社のSEO支援をされているとのことですが、どうやってそれだけの仕事をこなされてるのか気になります。1日のスケジュールはどんなかんじで仕事されているんですか？

辻：だいたい規則的ですね。平日は朝8時か9時に起きて、昼くらいまではメールなどをチェックします。午後はお客様とのミーティングに出かけ、夕方帰ってきたらその日のうちの作業やメール対応などをしています。深夜0時くらいから翌日の作業の準備をして、4時か5時くらいに寝ます。

白石：えっ、朝起きる時間はそんなに早くないなと思ったら、夜中の4時とか5時まで起きて仕事してるんですか。遅くまで仕事をしすぎなんじゃ…。

辻：13社のお客様とは、月に1回か2回必ず1～2時間のミーティングを入れているので、平日の午後はほぼ埋まるんですね。そのミーティングのために、各社のSEOの分析や提案の準備で短くても5～6時間はかかります。翌日の準備をしているとどうしても朝5時くらいになっちゃうんですよ。

ツールも使っていますが、マンパワーでなんとかやってしまうので、同業のSEO業界の人に話をしてもまったく参考にならないって言われてます(笑)。

白石：クライアントワークやってる辻さんもすごいんですけど、仕事以外でも辻さんは検索結果を常に広い領域でウォッチしているイメージがあります。

辻：30万キーワードくらいは定期的にウォッチしてます。私が他社に勝っている点があるとすると、全部一人で見ていることですね。日頃の順位や流入の変化からサイト変更による変化を一人で全部見ていれば、傾向が把握できますから。

白石：辻さんを医療系サイト「WELQ」問題（※）で記憶している人も多いと思うのですが、このときの医療業界の動向はたまたま気づいたんですか？

（※「WELQ（ウェルク）」問題：DeNAが運営する医療情報のキュレーションメディア「WELQ」が、クラウドソーシングなどを使って記事を安く大量に作り、その記事が検索結果で上位表示されていた件。医療系の情報にも関わらず信頼度が低い、記事の制作過程で多数の著作権侵害が認められるなど、多くの批判を受けて現在サイトは停止中）

辻：医療・金融・法律関連といった深刻な情報の検索では、特殊なアルゴリズムが動いています。その中でも医療関連は動きが顕著ですので定期的に確認していました。医療を追っていればけば、その後の他業界がどういう動きになるか予想できますので。

例えば医療系なら一般的な薬や病名とか症状などのキーワードを、それぞれ数百づつ定期的に検索しておいて、上位表示されるサイトの傾向を見ていると面白いですね。動きが変わってきたときに、じゃあペットの病気だと同じような動きか？などとずらして比較するといろいろ見えてきて、興味深いです。

白石：すごいな…。そういった動きを調べているときは何かツールも使ってるんですか？

辻：データはツールを使って分析しています。ただちゃんと分析するときは、ツールだけではできないので、力業ですね(笑)。

白石：辻さんの大事にしているポリシーや哲学的な話も聞いてみたいです。WELQのときって「これは許せない！」という社会正義みたいな想いもあったんですか？

辻：あまり社会正義的なことはやりたいくないです(笑)。基本的に楽しい仕事しかしたくないですし、好きなサイトとか面白いサイトの仕事だけを受けています。そういうサイトだけに関わっていれば仕事も大変ではないですから。

ただ、自分の義務として検索に関わる問題提起をしていくべきとも思っています。SEOを行っている会社にとって、検索エンジンが取引先となることが多いので、おおっぴらに文句は言いづらい人が多いんですね。私は利害関係はありませんし、身軽な立場なのでいくつか話していると、いろんな人からの相談やタレコミがどんどん来るようになって、半分義務のようになってしまっているところはあります。

モバイルファーストの流れでSEOはどうなる？

白石：続いては、SEOの過去から現在までの大まかな流れと制作者向けのポイント、SEOの未来を聞いていきたいと思います。まず、モバイルファーストはGoogleのSEOにどういう影響を及ぼしているんでしょうか。

辻：2016年、2017年、2018年の今くらいまででいうと　モバイルファーストの影響は大きいと思います。Googleの仕様として大きな変化は、モバイルファーストインデックス（MFI：Mobile First Indexing）ですね。

（モバイルファーストインデックス：Googleがこれまで検索エンジンがPCサイトの内容をもとにコンテンツの質を評価していたのを、スマートフォンサイトを評価の主軸に評価し、インデックスするという方針転換のこと）

Googleはレスポンシブウェブデザインでやっているサイトについては、PCサイトのページとモバイルページのソースに違いはないので一切影響はないと言っています。レスポンシブ以外のところはどうかというと、同じURLで別のHTMLを出しているダイナミックサービングも、別のURLでPCとモバイルを対応しているサイトも、内容が同じなら影響はないと言っています。

（ダイナミックサービング：URLはPCサイトとスマホサイトで一緒だが、アクセスするデバイスによって見せるページやテンプレートを切り替える方式）

ただ、レスポンシブウェブデザイン以外では、Googleが見るページのデザインや動線が大幅に変わることになるわけですよね。おそらく経験がある方も多いと思いますが、コンテンツを変えずにデザインと導線を全部変える大幅なリニューアルをすると検索順位に大きな影響があるものです。

しかしGoogleはその影響がほぼないようにすると言っているんですよ。今までの経験上そうなるはずはないのですが、そう言い切るからには、Googleはいろいろな今までにない処理をしてくるんだろうなあと思っています。

本当にそうなればいいのですが、やはり大きな変化になるかもしれないとして、ウォッチしていく必要があると考えています。

白石：PCサイトしかないサイトはどうですか？

辻：モバイルファーストインデックスでも大きな変化はないはずです。ただ、昔からモバイル版を用意していないサイト、モバイルフレンドリーではないサイトは、モバイルからの検索では順位が大幅に落ちていますので、どうにかするべきでしょうが。

白石：スマホ用URLがあるサイトやスマホ用コンテンツが違うというサイトはいかがでしょう？

辻：そういうサイトはアノテーションなどを複雑に対応する必要があって難易度が高いですね。Googleはカンファレンスの質問などで「完璧に実装できた場合は問題ない」と回答してします。ただし「そういうサイトはめったにないし、だいたいみんなミスをする」とも言われていたそうですが。私なら早めにコンテンツの整理をお願いしますね。

このPC版とスマホ版という話は、サイトの規模によってはクロールの観点で複雑になることもあります。PC版とスマホ版でソースが違う巨大なサイトでは、PC版しかまともにクロールできていないところが多いです。

毎日数万とかページが増える巨大サイトは毎日数百万何千万とGooglebotがデータを取りに来て、Googleのためにサーバ負荷対応が必要なところも多いのですが、PC版とモバイル版の両方を取得するためには、さらに倍の負荷になってサーバ費用もかなり増えます。

そういう事情への配慮なのか、巨大なサイトではPC版を中心にクロールをかけて、スマホ版ページはパターン認識による推測ですましていることがあります。

巨大なサイトのクロールでは、かなり複雑な処理が行われているんです。モバイルファーストインデックスになるとそのあたりも変わるでしょうから、巨大なサイトではなにか特殊な変化が発生する可能性は十分にあるでしょうね。

白石：今後はモバイルクロールがメインになると？

辻：私がログを見られる巨大サイトの多くでは、PCクローラとモバイルクローラの割合が8：2くらいなんですが、今後は逆転させるそうなんです。巨大サイトではPCページは認識できていてモバイルページは認識できていないようなケースも多いので、データベースの処理も複雑になるんだろうなと。そのタイミングでは何かイレギュラーなことが起こるかもしれません。

Googleは問題ないといいますが、過去にない大規模な仕様変更ですので、どういう影響があるかはやはり分からないですね。

普通の規模のサイトや、レスポンシブウェブデザインのサイトは確かに問題は起きないと思いますが、そうではないところにとってはいろいろイレギュラーがあるかもという想定で注意して監視しておいたほうがいいと思います。

Webコンテンツの「正しさ」への流れ

白石：では、話題を変えて。最近はWebコンテンツの「正しさ」への流れがありますが、どうお考えですか？

辻：WELQ問題が端を発し、Googleは2017年12月6日にウェブマスター向け公式ブログで、日本語検索の結果について「医療や健康に関する検索結果の改善」を発表しました。医療や健康に関する部分はここで非常に大きな変化があったわけですが、この前後にGoogleはいろんなことをやっているんですよね。

明確に違法と言えないけど怪しいサイトや悪質なサイトの順位を露骨に落とした、と思える動きもありました。昨年末に逮捕者も出たようなフィッシングサイトへの対応も進んでいます。大きな社会問題になったことに対して積極的に対応するようになった、と思いますね。フェイクニュースなどインターネットへの信頼性が疑われるようになって、明らかに態度を変えたように思います。

白石：それまでのGoogleは「インターネットの自由」を優先していて、それは面白さでもありましたが…。「正しさ」が大事という方向に舵を切ったと？

辻：はい。情報の正確性を意識するようになったことはいわれています。「Googleは検閲はすべきでない」というポリシーとインターネットの自由を大切していることは確かです。Googleを含めたインターネット全体が自由だけでは問題があるという方向に流れています。いいことかはわかりませんが、どんどん加速化していますね。

白石：でも、人によって「正しさ」が違う情報っていっぱいあるじゃないですか。Googleがその「正しさ」を決めるのは、限られたことにしかできないんじゃないかなって思うんですけど。

辻：難しいですね。最近は癌について検索したら、国の医療機関などしかまともに出なくなりました。ただお医者さんの眉をひそめるような高額だったり、実績に乏しい微妙な治療方法の多くは違法ではないですよね。それらがGoogleの判断によって多くの人に知られづらくなったわけですよね。これはGoogleの検閲ともとれる行為かもしれませんが、それが受け入れられています。難しいことですよね。

個人的には、深刻な病気に悩む人が検索の情報で迷惑をかけられたという話をたくさん聞いてきたので、今の状態が悪いとはまったく思わないんです。インターネットの自由も大事だけど、その自由の中でも規制したほうがいいこともあります。ただ、これがどんどん拡大するようではまずいですよね。

白石：価値中立、道徳的に中立という言葉がありますが、Googleは今まではそこを頑張ってたんでしょうけど、あまりに誤った情報などを出してしまうのはまずいと考えたんでしょうね。ただ、Googleの一存で何が正しくて、何が間違っているのかという思想の部分を決めてしまうのはどうかという問題もありますね。

辻：本当にそう思います。ただこの問題、Googleは本当に慎重に考えていると思います。Googleの考え方は発表される声明だけではなくて、実際の順位の動きなどで大分理解できているつもりですが、今のGoogleでも表現の自由とかインターネットの自由の尊重とかは、過剰なほど慎重だと思います。

ただ、それでも対応を変えていかないと行けないほどインターネットは複雑になったということかなと思います。現状のGoogleには不安はないし、変なことはやらないと信じています。でも今後どう変わるかはわからないので、今後も動向は見ないといけないですね。

全てのサービスとGoogleが競合化する！？

白石：次のテーマ「Googleの競合化」ですが、これはどういう意味でしょうか？

辻：最近、Googleでグルメ関連の検索をすると一番上に地図が出ますよね。ユーザー評価もあるし、ローカルガイドにもなって、とても便利ですよね。あと飛行機の予約ができるGoogleフライトも、ホテルの予約もできるし、ユーザーには便利でいいサービスなんですが、これらによって奪われてしまったサービスも出てきます。

Googleマップではスマホを持ったユーザーの行動がオプトインで記録されていますが、そのあたりの独自データを激しく使い出すと、他のサービスはなかなか太刀打ちできないですよね。

白石：あらゆるサービスにGoogleが競合として参入していくわけですね。

辻：増えていることはたしかです。Googleが持てない価値を考えて作るしかないんですが、情報を集めて出すサービスは勝ち目がなかなかない厳しい状況になると思います。

Web制作におけるSEOのポイントは？

白石：ここからはWeb制作におけるSEOのポイントについて聞いていきたいと思います。マークアップなどで気をつけることとかありますか？

辻：昔は「をつけろ」とかありましたけど、最近は効かなくなりましたね。私もマークアップを変えろという指摘はほぼしなくなりました。普通にミスのないマークアップでWebサイトを作れば評価されるので、SEOのためにマークアップで何かするということが減ってしまったんですよね。

ただ、サイト設計については口を出さなくてはいけないことが、多くなってきました。Googleは公式に認めていませんが、どんなユーザーがどういうページを見ていていて、どこで離脱しているかなど、ユーザー行動を見ているんですね。

白石：まあ、肯定しにくいですよね。

辻：Googleは否定するけど、一般ユーザーがWebページ内でどういう行動をするかが検索結果に影響するようになってきました。その影響力はどんどん大きくなっています。

白石：昔は内部リンクを充実させるために、人間が踏まなさそうなリンクをフッターに大量に仕込んでたじゃないですか。あれはまだ有効ですか？

辻：2012年くらいから一切やらなくなりました。そういう人が使わないリンクをはずして順位がかわるか実験を何度もしてみたのですが、一切変わらなかったんです。それからはSEOだけの目的でリンクを張ることはあまりしなくなりましたね。

白石：クローラーのためにAタグを書いておくのはもう必要ないんですね。

辻：これからはユーザーが使いやすいページを作ることを優先した上で、どうやって検索に強くするかを考えることが有効になってきます。例えば、グローバルメニューとかカテゴリとか本来はユーザ動線として強いはずなのに、ニーズがない情報が並んでるサイトってあるじゃないですか。ユーザが好む動線に検索ニーズもある情報をまとめるとか、マークアップとかよりもユーザーの検索ニーズを意識したサイト作り、などが重要ですね。

白石：ユーザーにとって自然な導線をちゃんと作り込むようにしなさいということですね。

辻：はい、それがSEOの観点として大事になったということです。

白石：一般ユーザーはあまり気にしてないと思いますが、URLは未だに重要ですか？

辻：少なくとも日本国内ではURLの深さとかは、最近は関係なくなくなってきました。パラメータをつけるとどうこうとかありましたが、今のGoogleだけでいうなら認識するようになってきた。ただし、Google以外の検索エンジンは上手く認識できない場合が多いので、やるしかないんですが。

白石：コンテンツづくりについても聞いてみたいと思います。昔、辻さんがGoogleに好かれるための記事を書いてたじゃないですか。検索エンジンには好かれるキーワードを散りばめて、見出しをちゃんと書いて、先に結論があって、見出しの近くに重要キーワード置いてとか。

辻：それは今でもまだガリガリ効きます。SEOを考えたキーワードは大事ですね。ただし、キーワードを書かなくても、テーマによって検索ニーズがあるものはランキングが上がるという流れもあります。

白石：以前流行ったキーワードたくさん入れたSEO用の記事も効くのでしょうか。

辻：そういう何も考えてないSEO記事は大分効かなくなりましたね。Googleはユーザーを見出したということもあり、読み込んでくれる文章じゃないとユーザーは離脱するので効果はなくなっていくと思います。

白石：AMPのSEO観点は何かありますか？

辻：AMPということだけではなく、考えなくてはいけないことがあります。例えば、最近はパーマリンクの重要性がすごく高まっていると思います。3年前くらいはパーマリンクのURLを評価をするサービスは少なかったと思いますが、最近はスマートニュースやグノシーなど、評価付けする存在が増えてきました。

URL単位で評価をするサービスにとって、AMPのURLでシェアなどをされると本来の記事と価値を統合するのに時間がかかったり、されなかったりすることもあります。他にも様々なデメリットはありますが、表示スピードが上がるといったメリットもあるわけで、メリットデメリットを考えて判断するべきですね。

個人的には、ニュースなどAMPに対応すると表示枠が増えるジャンル以外は、まだ様子見をするべきだと思います。先に言いましたパーマネントリンクの問題も今後の仕様改定で解決されるようですし、AMP関連の仕様はまだまだ進化を続けています。対応の工数も大きいですし、大きな利益が見込めないならもう少し仕様が固まってからでいいのではないでしょうか。

パフォーマンス・スピードはSEOに影響しない！？

白石：パフォーマンススピードが高いサイトは評価するとGoogleが言ってますが、実際はどうでしょう？

辻：実はそれ勘違いなんですね。Googleのウェブマスターブログでは、極めて遅い体験を提供しているサイトだけを落とすと言っています。昔行った以前の実験によると、読み込み速度が25秒以上かかるサイトはだいたい順位が落ちました。

白石：辻さん、そんな実験もやってるんですね(笑)。

辻：はい！どれだけ速くしてもランキングが上がることはなく、遅いサイトが落ちます。ただ、スピードを上げることはユーザーの行動が良くなります。結果的に順位が高くなることはあります。

個人的な経験では、サーバーの速度がある程度早ければ、さらにサーバ環境を向上してもユーザー体験は目に見えて変わらないですよね。それだと順位も変わりません。ただ、速度の実測値は変わらなくてもCSSの配慮などでサクサク動いているような感覚にしたほうがランキングが上がるんですよね。

白石：ということは、本当の速度を見ているのではなく、Googleはユーザー体験の方を見ているということですね。

辻：はい、良いユーザー体験を提供すれば順位が上がります。勘違いしてはいけないのは、速度改善でユーザー行動を良くするのは素晴らしいことなんです。

白石：なるほど。ユーザーのためにやるのはいいことなのに、SEOのためにやるのは違うということですね。

白石：最後はネイティブアプリのようなUXをWebページでも提供することができるProgressive Web Apps（PWA）について。プッシュ通知がWebサイトでできたり、ホームスクリーンにアイコンが出てアプリをダウンロードしてもらえたら、以降はアプリで作ってもらえるとか、クロスプラットフォームで対応できるなど便利な機能がいろいろある上に、SEOにもいいということで盛り上がっています。

辻：Googleはアプリ内のユーザの行動はあまり把握できていませんよね。ユーザーが自社アプリに流れた結果、メインサイトのユーザ行動が減って検索順位が落ちる影響は明らかにあります。そういう観点ではPWAはアプリより良いと考えています。

白石：PWAが有望なのであれば、クロスプラットフォームでWebページからアプリ版も作れる。SEO効果もあるし、ゲーム仕様でなければ普通に作れるし、今後は全部PWAでいいんじゃないでしょうか。

辻：PWAのニーズは高まっていくでしょうね。逆に、アプリ開発しかできない開発者はPWAによって活躍の場が減っていくかもしれません。

「AI First」で変わるSEOの未来

白石：「AI First」という言葉をいままで使っていませんでしたが、未来の話もしたいですね。

辻：Googleが公式でも「AI First」と言うようになってきましたね。プロダクトの全てにAIを入れ出しているので、今後AIでいろんな判断がされるようになっていくのが一番影響されるところです。

白石：これまで、Googleがユーザー行動を見ているという話がたくさんありました。結局のところ、今までのクローラーが単純すぎたということで、普通の人間がページを見たときにいい印象を受けるかを判断をするようになる。人間の判断にどんどん近づいているということでしょうか。

辻：その通りだと思います。その状況でSEOを考えると、GoogleのAIに上質な餌をどう与えていくかを意識することが大事になっていきます。

白石：「餌付け」というのはユーザーに有益な情報を提供しようということですね。Googleに情報をあげるとAIが賢くなる。Googleはその先に何を作っていくのか考えちゃいますね。

辻：そうですね。その先に過剰な怖さを感じている話もよく聞きますが、「Google怖い」は「電気怖い」と同じような話かなとも思っています。Googleを恐れるときは正しく恐れるべきだと言っておきたいです。

白石：ただしく恐れろということですね。辻さんに大きな拍手をもって終わりにしたいと思います。ありがとうございました！

Webの過去から現在・未来まで！エバンジェリストたちが語る、最先端Web技術の世界

吉川徹 — Fri, 16 Mar 2018 01:00:13 +0000

連載： Webの未来を語ろう 2018 (1)
HTML5 Experts.jp 副編集長兼エキスパートの吉川です。昨年好評だった「Webの未来を語ろう」企画を2018年もやります！

今回はパネルディスカッション形式で、HTML5 Experts.jp 編集長の白石が、ブラウザベンダーのGoogleのデベロッパーアドボケイトのえーじさん、 Microsoftのエバンジェリスト物江さんをお迎えして、興味深いお話を多数お聞きしました。

会場も交えたトークは、今後のWeb業界の動向を追いかける上で、重要な内容となっているので、ぜひ読んでみてください！

2017年のWebで印象に残ったことは？

白石: まずは簡単な自己紹介と、2017年のWebで印象に残ったことを教えてください。

えーじ: えーじです。Googleでデベロッパーアドボケイトをしています。もともとは、Google Chromeのアドボケイトという位置付けでしたが、最近はもっと広くなって、Web全体のアドボケイトを担当しています。特にChromeだけの話に限らず、Web全般について話をしていますね。これには、我々のチームの理想として、Webすべてに貢献していこうという想いがあります。

2017年で印象に残ったことは、SafariがService WorkerとPayment Requestに対応すると表明したことがすごく意義深いと思っています。

物江: 物江と申します。Microsoftでエバンジェリストをしています。以前はWebに軸足を置いていたんですが、現在はWebだけに限らずISV(Individual Software Vendor)、独立してサービスや製品を提供しているパートナーさん向けに様々な技術の啓発を行なっています。Webについては、個人的なものも含めていろいろ活動しています。

2017年に印象に残ったことは、WebAssemblyやPWA（Progressive Web Apps）などについて、ブラウザベンダーがきちんと足並みを揃えて、仕様を策定するようになったということですね。非常にいい流れになってきていると思います。

▲左から、日本マイクロソフト株式会社物江修さん、Google デベロッパーアドボケイトえーじさん

白石: 皆さん、ありがとうございます。ついでに私の2017年で印象に残ったこともお話ししておくと、個人的にはdev.toや日本経済新聞社の日経電子版が爆速だったという、そういう事例が出てきたのは印象的だったなと思います。裏側でHTML5やWebの最先端技術とか、そういったものを使って1段階上のレベルの速さを実現している。

Webプラットフォームベンダーやコミュニティの皆さんの啓蒙活動などもあって、PWAをはじめとしたWeb技術だとかパフォーマンスだとかが、ビジネス上も重要であるというところも浸透してきている。その結果として、Webプラットフォームの機能がフル活用されつつ、パフォーマンスというところに影響がでた良い例かなと。

今回は、Webの過去・現在・そして未来を語るという構成で進めてみたいと思います。

イントロダクション:HTML5は世界を変えたのか？

白石: 2017年以前のWebを振り返ると、ブラウザ戦争などの分断化があって、そこからHTML5のムーブメントが起こり、Webの様々な仕様が生まれてブラウザに実装されました。

ただ、それら「HTML5」のムーブメントは世界を変えたんでしょうか？ これまであまり、そういう振り返りをしたことがなかったので、一度やってみたいなと思っていたんです。お二人はどうお考えですか？

物江: そうですね、一般ユーザーの目からすると、確かにあまり変わっていないかもしれません。例えば、YouTubeのプレイヤーは、FlashからHTML5になりましたけど、変わったって気がつく人はあまりいませんよね。普通の人は、きっとまったく意識せずに使っている。HTML5でできたことは、とっくにFlashでもできていたわけで。

でも、開発者にとっては大きな変化がありましたよね。結局、開発者はみなHTML5を使っています。これはなぜかというと、HTML5がシンプルだからこそだと思うんですよ。

エキスパートの竹洞さんがいいことを言っていたんですけど、Webが素晴らしく進化したのはKISSの原則(*1)のおかげといっていました。つまり、誰でも簡単に使えるからこそ普及した。わざわざFlashを使わなくても、Web標準技術だけを使えばいろんなことができるようになった。それによって作り手側の裾野が広がって、以前よりもリッチなコンテンツがたくさん出るようになってきたのかなと思います。

*1 … “Keep it simple, stupid” （シンプルにしておけ！この間抜け）、もしくは、”Keep it short and simple” （簡潔に単純にしておけ）という経験的な原則の略語。Wikipedia

えーじ: ぼくも、世界は変わったと思います。やっぱりHTML5でWebを変えようっていうムーブメントがあったこと、それ自体が良かったと思うんですよね。良い意味でのブラウザ間の競争が起きて、どんどん新しい提案がなされて、共通して使えるものがどんどん生まれていった。

ちゃんと数えたことないですが、HTML5の機能でみんな当たり前に使うようになったものっていっぱいあると思うんですよ。例えば、CSS3で角丸を使うっていうのももう当たり前にみんなやっているし、それが動かないブラウザはほぼ、ない。そういうものが当たり前に使えるようになったっていうのは、一昔前からすると全然状況は異なっている。そういう意味では、相当変わったと思います。

白石: そういえば、元Mozilla Japanの浅井智也さんに以前教えてもらったんですが、Web関連技術を全部まとめた図があるんです。これ、曼荼羅図みたいな感じなので、「Web曼荼羅」なんて呼ばれているそうです(笑)。

HTML5とその関連技術（webapi.link）

こうして考えると、HTML5のムーブメントはたくさんのものを生み出しましたねえ。一般のユーザーからはあまり変わってないように見えても、「それは時間をかけて変わっているから」という面もありそうですね。

えーじ: はい、そして、これだけのものがたくさん生み出された結果、Webはアプリケーションプラットフォームになった。それが、HTML5以前との大きな違いだと思いますね。

Webは難しすぎる─Webプラットフォームの現状と課題

白石: では、iOSやAndroidといった他のプラットフォームとWebプラットフォームとを比較すると、Webはどういう立ち位置にあるとお考えですか？

物江: Webプラットフォームは時間をかけてここまで成熟してきました。機能的な面では、他のプラットフォームにもひけをとらないというところまで来たんじゃないかと思います。

そして今、Progressive Web Apps (PWA)が浸透しつつあることが、今後のWebにとってはすごく意義のあることだと思っています。 PWAって、ある意味ひとつの理想の到達点だと思うんですよね。Javaなどが理想に掲げていた「Write Once, Run Anywhere」を、PWAは真の意味で実現するわけです。これ、次のWindowsの大型アップデートでPWAがデスクトップアプリっぽく動いだり、Windowsストアからインストールできるようになるから言っているわけじゃないですよ(笑)。

白石: そこでいつも言われているのが、Webアプリって動作が遅いんじゃないかってことですよね。

物江: ただ、そうした問題についても、Webプラットフォームは長いこと取り組んでいて、もはやあまり問題にならないレベルじゃないかと思います。ブラウザの実装という面でも、仕様の面でも、絶え間ない改善が続けられてきました。

仕様の面でそうした部分について期待できるのは、やはりWebAssemblyですね（筆者注: ブラウザが高速に実行可能な、ポータブルなバイナリ形式）。昨年、モダンブラウザが同時にWebAssemblyのサポートを表明するということがありましたが、これでWebの速度はまた一段階アップすることが期待できます。

あとはやはりハードウェアの進歩が解決するものも多いでしょう。ちなみに、今のWeb技術の素晴らしいところは、ハードの性能に縛られた設計をしていないこと、どこでも同じWeb技術が動作することだとも思います。

例えば昔、貧弱だった携帯電話の機能に合わせた仕様で、HDMLやCHTMLというモバイル専門のタグがありましたが、今はもうほとんど残っていません。結局、性能に関わる問題は時間が解決してしまう部分も大きいんです。いま大切なことは、「いかに人間が作りやすいか、使いやすいか」が重要になってくるかなと思います。

えーじ: ぼくも、パフォーマンス面は既にあまり課題とは考えていません。それよりぼくが課題だと感じているのは、開発者にとってのWeb技術はかなり複雑になってしまっていることです。

例えば「Extensible Web」というのを聞いたことがある方がいらっしゃると思います。これはWebの技術設計に対する、ここ数年における指針のようなもので、具体的には「標準としては、ユースケースを規定しない低レベル（低レイヤー）なAPIを提供する」というものです。

そうすることで、そうしたAPIを使用したハイレベルなライブラリだとかベストプラクティスが、開発者の手によって作られることを期待する。こうすることで、「ハイレベルだけど使われないAPI」が標準で規定されてしまうという問題を解決しようとしています。

ただ今は過渡期なので、低レベルなAPIがどんどん増え、ライブラリも量産されていて、はっきり言って混沌としています。例えばService Workerもすごく低レベルなAPIで、実際に使うとなるとなかなか難しい。

そこにGoogleがWorkboxというライブラリを出していたりするんですが、それを使うと簡単にServiceWorkerを使える一方で、ServiceWorkerもライブラリもどちらも学ばなくてはならない。

これがWeb Componentsなんかだと、仕様そのものがどんどん変わっていて、なかなか安定しない。Polymerというライブラリを使おうにも、Polymerも仕様に合わせてどんどん変わっている。どの時点の仕様が正しいのか、検索したときにどれが最新なのかわかりづらい。そういうところが複雑で、開発者はみな苦労してるんじゃないかなと思います。

個人的には、以前Webpackにやられたことがありまして(笑) 。将来的にはES Modulesが広まれば、そういうビルドプロセスを経なくてもうまく動くようになるんだと思うんですが、今は過渡期として、やっぱりGulpなりWebpackなりRollupなりを使う必要がある。

ビルドツールも次々に生まれるし、フレームワークもそう。フレームワークとビルドツール、様々なライブラリも組み合わせなくちゃならないし、ベストプラクティスが簡単にはわからない。その辺がかなり複雑になっているなと感じています。

各ブラウザベンダーのこれからの動向は？

白石: 皆さんご自身の会社の立場からお聞きしたいなと思うんですけど、ブラウザベンダー各社がどういう想いで、どういう方向を向いて実装しているのかをお聞かせください。

えーじ: 会社（Google）としての方向性はもちろんですが、チーム内でWebに関する課題を共有して、その解決策を探ることは普段から行っています。

例えば、先ほど挙がっていたパフォーマンスを例に挙げましょう。

実はJavaScriptのパフォーマンスって、もうあまり問題にならなくなっているんです。むしろ悪いのはレンダリングの部分で、そこを速くするための努力はずっと続けています。

あと、ネットワークの遅延もすごく大きい要因なので、ServiceWorkerみたいな仕様を提供することで、スピードの課題に開発者自身が取り組みやすくする。

さらに、パフォーマンスに関するベストプラクティスを開発者の皆さんと共有するのも重要です。

このように、課題一つとってもたくさんのアプローチがある。こういう活動を、チーム一丸となって同時に取り組んでいるという状態ですね。

白石: なるほど。ちなみにGoogleの中で、「今のWebはこういう課題があるね」みたいな、そういう話し合いっていうのはよくされるんですか？どんな議論がされてるのか興味があります。

えーじ: はい、常にやってますね。世界中から集ってきた情報を、雑談ベースでやり取りするような感じです。

例えばこれからGoogleがインドでももっと使われるようにするためには、インドの市場を考えなきゃいけない。しかしインドは全然違う世界だと。

例えばネットワークにしても、今われわれが4Gは当たり前に使ってますけど、向こうの世界は2Gなんです。3Gですらない。なのに、何MBっていうファイルをダウンロードしないと見れないサイトっていうのはざらにあるわけですよ。そういったネットワーク環境の悪いところに対して、開発者の皆さんがサービスを提供しようと思った時にどうするのか。そういう課題がインドに進出しようと思っているチームから上がってきたりします。

他には例えば最近は、アクセシビリティにもかなり力を入れていたりもしますね。アクセシビリティに強く関心のある人たちがチームに入ったことで、Webのアクセシビリティをもっと良くするための話し合いや仕様の提案なども活発に行なっています。

物江: Microsoft Edgeは、相互運用性とセキュリティ、アクセシビリティとパフォーマンスの4つが何においても優先されています。

例えば相互運用性でいうと、 -webkit-text-stroke というベンダープリフィックスがあります。これ、以前はWebKit系のブラウザでしか動かなかったんですが、現在はEdgeでも開発中なんです。多くのサイトで使われているような機能については、全部同じように動くようにするというのを優先的にやっています。

アクセシビリティに関しては、画面に表示されるすべてのテキストについて、スクリーンリーダーのような外部のプログラムを呼び出せるような仕組みが、WindowsにはOSレベルで入っています。それを使って、アクセシビリティを強化するような仕組みがEdgeに入っていたりしますね。

パフォーマンスについては、Chakra（EdgeのJavaScriptエンジン）のパフォーマンスアップを継続的に行っています。特に、こないだのアップデートでようやくブラウザ内部のリファクタリングが終わったようで、Edgeが出た頃からのパフォーマンスでいうと、3～4倍速くなってます。

白石: リファクタリングっていうのは、Internet Explorerから引きずっているコードがかなりあるのを書き直すって話ですよね。それが行われているって話はだいぶ前に聞いていましたが、ついに終わったんですね。

物江: はい、ほぼ全部終わったんじゃないかと。もともとEdgeのレンダリングエンジンってTrident（IEのレンダリングエンジン）から派生したものなので、20年以上前のものということで、根っこの部分で仕様が古い部分があったんですよ。その修正がようやく終わったという感じです。これから先は、Edgeの開発はどんどん加速していくんじゃないかと期待しています。

あとは、やはり2000年代と比較すると、ユーザーの意見をより開発に取り入れようという姿勢が顕著になったかと思います。Windowsをお使いの方はわかると思うんですが、フィードバックHubというのがありまして、そこでバグの報告だとか、追加してほしい機能をリクエストできるんですよ。そのリクエストのベット数が多いと優先度があがっていって、対応されるというようになっています。

各種ブラウザのステータスが確認できるサイト

Microsoft Edge

Chrome

Webkit

注目のWeb最新技術を一挙に解説！Web Payments、WebVR、AMP、PWA、WebAssembly…

白石: ではここからは、注目のWeb最新技術についていろいろお聞きしたいと思います。Web Payments、WebVR、AMP、PWA、WebAssemblyなどなど、仕様ごとに概要と現状をお話しください。

Web Payments

えーじ: 今までWebでお金を払うといったら、フォームを使ってクレジットカード番号を入れたりとか、どこかのサイトに飛んで、そこのサイトにあらかじめ保存してある支払い情報を使うといったことがほとんどだったと思います。Web Paymentsを使うと、ブラウザがネイティブで表示してくれるUIを使って支払いができるようになるというのが大きな特徴ですね。ちょっと見てもらうと、PolyCartというWeb Paymentsのデモサイトで確認することができます。

Web Paymentsのデモサイト（PolyCart）

ブラウザネイティブのUIを通じてクレジットカードの情報や、配送先、連絡先などの入力を促すことができます。そうして入力された情報はブラウザが記憶してくれるので、次からはクリックするだけで支払い情報を入力することができます。

もっとすごいのは、将来的には支払い方法を追加できるようになるんです。例えば、Apple PayやGoogle Payで支払うのも可能ですし、仮想通貨なども使えるようになるでしょう。

WebVR

物江: 以前から、「Web上でVRコンテンツを表示する」っていうのは、Three.jsなどを使って実現が可能でした。ではWebVRは何が違うかというとVRデバイスからのフィードバックを受けることができるんです。これによって、VRデバイスと深く連動したWebサイトを作ることができます。

それにWindows10だと、ネイティブでVRの環境をサポートしていて、WebVRに対応したWebサイトにいくと、自動的にVRゴーグル上で全画面表示してくれるようになっています。VRのビデオもそのまま見ることができるので、真の意味でシームレスにVRのコンテンツが提供できるようになっています。

個人的に楽しみなのは、VRをきっかけとして新しいUIが生まれてくることですね。既存のVRゴーグルを使ったことがある人はわかると思うんですけど、キーボードもマウスも何も使えないんです。そうすると新しいUIを考える必要があって、そこに新しい可能性を感じています。

えーじ: ちなみに最近はWebXRっていうらしいですね。VR、AR、MRをコンセプトに入れた仕様を作ろうとしているという動きもありますね。

AMP

白石: 次はAMPですが、これについては既にたくさんの方がご存知でしょうから、簡潔に。主にモバイル環境で、Webページを素早く表示できるようにするための、HTMLのサブセットですね。

えーじ: AMPの仕様自体もさることながら、AMPが基本的にWeb Componentsでできているのは興味深いです。Web Componentsの仕組みを使って独自のエレメントを定義していて、なおかつパフォーマンスも追求しているので、結果としてパフォーマンスのベストプラクティスの塊をWeb Components化したものになっている。大変面白いと思います。

Progressive Web Apps

白石: 次は、恐らく今年最大の注目キーワードProgressive Web Appsですね。これは（ずっと啓蒙してきた）えーじさんに語っていただくしかないでしょう。

えーじ: はい。とはいえPWAという言葉自体は、皆さんに意識してもらいやすくするためのマーケティング用語のようなもので、技術的な観点からはそれ自体意味がないと思っています。実際の中身はService WorkerだったりとかPush Notificationだったりとかそういう具体的な機能やAPIから構成されています。

日本でも、昨年後半くらいからPWAが注目されはじめました。さっきのdev.toとか日経電子版とかも、PWAの構成要素を利用することで高速化が実現できたと。PWAの中のひとつひとつの技術要素をうまく使うとここまで速くできるんだよ、といういい例ができたなと思っています。

白石: ちなみに、個人的にはPWAっていまいち意味がわからないな、と思ってて。なにが「プログレッシブ」なんでしょうか？プログレッシブって、「だんだん（進化する）」って意味ですよね。

えーじ: PWAにおける「プログレッシブ」には2つ意味があります。

1つは昔から言われているプログレッシブ・エンハンスメントです。古いブラウザでも見ることができる基本的なWebサイトをまずは作って、そこに、新しいブラウザで使える機能を足していくという考え方。そうすれば、クライアントの環境を最大限活かすことができます。

白石: では、Service Workerが使えるブラウザだったらオフラインという機能が使えるけど、そういう機能が使えないブラウザにも同等のものを提供する。既存のサイトにあとからその機能を提供することも割と簡単にできますよっていうそういう思いを込めたものということですね。

えーじ: そうです。もう1つが、今あるサイトに機能を付け加えていくことで、徐々にPWAに近づけていけるという意味です。PWAのためにサイトを一から作り直すとか、大幅な改修を行う必要はない。既存のサイトを徐々に拡張していけばいいんです。

白石: なるほど、そういう意味合いだったんですね。ちなみにPWAの中では、Service Workerが代表的なAPIですよね。他にはWeb App Manifestとか、Push Notificationとかでしょうか。

えーじ: そうですね。ちなみに、PWAのウリの一つに、OSのホーム画面にアイコンを追加できるというのがあるんですが、以前はただのWebアプリへのショートカットでした。でも今は違います。PWAをホーム画面に置く際、アプリのパッケージを動的に生成してインストールするので、OS上の扱いはネイティブアプリとほとんど変わりないんです。なので、プッシュ通知のオン／オフをアプリごとに設定できたり、ネイティブアプリでしかできなかったことがPWAでも同様に行えます。

WebAssembly

白石: 次はWebAssembly、物江さんご説明お願いします。

物江: WebAssemblyは、Webブラウザ上で非常に高速に動作させることができる、デバイスに依存しないバイナリ形式です。現在は用途がある程度限られていて、DOMを操作することなどはできませんが、CPU依存の計算処理などは極めて高速に動作させることができます。 Emscriptenなどのツールを使うと、C/C++で作られたものをWebAssemblyに変換できるので、C/C++で書かれたゲームなどをWebAssemblyに移植することも比較的容易です。また現在はまだ開発中ではありますが、MonoがC#からWebAssemblyをコンパイルするmono-wasmであったり、マイクロソフトも実験プロジェクトとしてWebAssemblyを介してWebブラウザー上でC#とRazorを走らせるWeb UI framework Blazorを開発していたりします。

（ここで会場からエキスパートであるあんどうやすしさんから質問）

あんどうやすし: 現在のWebAssemblyって結局計算することしかできないじゃないですか、DOMもいじれないし、JavaScriptのAPI呼び出しも直接は行えない。今後もそれは変わらないんでしょうか。特にデータの渡し方に結構制限があって、使い勝手がいいものにするには難しいなと感じています。SharedArrayBufferという仕組みで一次元配列の共有はありますが、それも使いづらいし…。

物江: それは、今の段階ではまだなんとも言えないですね。

えーじ: ちなみにSharedArrayBufferはこないだのメルトダウンとスペクター(*2)の影響で機能が停止になります。

白石: ありゃ、まさかそんなところにまで影響及ぶとは…(笑)。

*2 … CPUでの投機的実行という高速化プロセスを悪用した脆弱性

Web Share API

白石: 他には、注目のAPIとかはありますか？

えーじ: 最近追加されようとしている新しい機能にWeb Share APIというのがあります。

Androidのインテントをご存知の方だったらすぐ分かる機能ですが、例えばあるサイトを「FacebookやTwitterでシェアしたい」という場合に、Web Share APIを使うと簡単に外部アプリを呼び出すことができます。

逆に、自身のWebアプリを「シェアする先のアプリ」として使ってもらうようにすることもできます。それがWeb Share Target APIというものです。

Web Share APIは既に使えるんですが、Web Share Target APIは、現在限られたサービスにしか開放されていません。このように、Chrome では一部のドメインに先行してWebプラットフォームの機能を試してもらうオリジントライアルというものをやっているのですが、現在TwitterのモバイルサイトがWeb Share Target APIを使えるようになっています。mobile.twitter.comで実際に試すことができますので、TwitterのPWAをまだ試したことがない方は、AndroidのChrome betaチャネルか、devチャネルを使ってインストールしてみてください。何かシェアしようとしたときに、TwitterのPWAが候補として出てきます。

Web Authentication

白石: Web Authenticationというのもあると聞きました。

えーじ: Web Authenticationは、実はEdgeでもう使えるんです。仕様がちょっと古いので、APIが全く異なりますが、Polyfillもあります。Web Authenticationをひとことでいうと、セキュリティキーなどを用いた多要素認証を標準技術で扱えるようにするものです。顔認証や指紋認証と組み合わせれば、安全性の高いログインの敷居はぐっと下がると思います。

物江: FIDO Allianceという標準化団体があるんですけど、そこで生体認証などのもっと広い話をしています。既にWindowsだとWindows Helloという生体認証の仕組みがFIDOの標準で作られていますね。

えーじ: FIDOのWeb版がWeb Authenticationになるわけです。Web Authenticationの実装はこれからどんどん出てくるでしょう。Mozillaさんもこないだ実装を開始しましたし、Chromeもそろそろ入ってくるのかなと思います。

白石: そうすると、もしかしたら今年はWebサイトで指紋認証とか顔認証とかが一般的になってくるという可能性があるってことですかね。

えーじ: そうですね。どの認証方式を使えるようにするかっていうのは、順番に1つずつ入れていくという話らしいので、まずはセキュリティーキーから利用できるようになって、そのうちNFC、指紋認証ができるようになっていくようです。徐々にそういったものが実装されていけば、本当にパスワードを覚えなくてもいい世界っていうのが実現できるかもしれないので、すごく楽しみにしています。

ちなみに、Credential Management APIというIDとパスワード、いわゆる共通鍵認証をする仕様があるんですが、それとAPIのネームスペースが同じになるので、共通のAPIを使うことになります。まったく別々だった仕様が一緒になるというのも個人的には面白いと感じています。

エキスパートたちが見据えるWebの未来について

白石: 最後にWebの今後について感じていることをお聞かせください。

えーじ: ぼくらブラウザベンダーは、「こうなるといいな」というものをいろいろ作ってるんですけど、それはブラウザベンダーが勝手にやってるわけじゃなくて、開発者の皆さんの声とか、こういうWebがいいという声をもとにやっているので、フィードバックをできるだけいただいたほうが、より皆さんの理想としているWebができると思っています。

フィードバック方法にも今はいろいろあって、GitHub上で管理されている仕様にIssueを立てるっていうのも一つの方法ですし、一番簡単な方法です。それすらめんどくさいということであれば、ぼくに直接言っていただくとかでも構いません(笑)。そんな感じで、開発者の皆さんと一緒にWebを盛り上げていけたらいいなと思います。

物江: 個人的な思いとしては、今非常にWebって良い方向に進んでいると思っています。（お互いを傷つけ合うような）ブラウザ戦争は終わりました。今は良い意味でお互いに競争し合ったり、歩調を合わせてWebを良いものにしていこうという動きが主流になりつつ会って、とても好ましく感じています。今後もそれが続いていって、Webのテクノロジーの活用範囲が広がればいいなと思っています。

白石: 皆さん、本日は様々なお話をお聞かせいただき、ありがとうございました！

AMPの気になること全部、Googleの山口さんに聞いてきました！

白石俊平 — Wed, 10 Jan 2018 01:00:36 +0000

連載： HTML5 Conference 2017特集 (15)
こんにちは、編集長の白石です。

この記事は、9月24日に開催されたHTML5 Conference 2017に登壇したエキスパートに、お話されたセッションのトピックを中心に、様々なお話を伺おうというものです。セッションの内容をより深く理解する手助けになるだけでなく、本記事単体でも面白く読んでいただけることを目指しています。

今回お話を伺ったのは、Googleの山口能迪（やまぐち・よしふみ）さんです。

山口さんのセッションは「AMPで加速するモバイルウェブアプリケーション」でした。

スライド資料はこちらで公開されています。

https://docs.google.com/presentation/d/1ZYyHFRMZnD6bfi6fl9yh9G_TIs3roSxvp-Goa1JZv_c/htmlpresent

AMPとは何か？なぜ必要とされたか？

白石: 今日はよろしくお願いします。まずは簡単に自己紹介をお願いできますか？

山口: Googleでパートナー・デベロッパー・リレーションを担当している山口です。私の役目は特定の技術にとらわれず、最新の技術を広めていき、採用事例を増やすことです。

白石: 最新技術って、Googleさんすごい数出すから大変ですね(笑)。

山口: そうなんですよ(笑)。

白石: では、早速本題に入っていきたいと思います。AMPについてご存じない方のために、軽く説明をお願いできますでしょうか？

山口: AMPとはAccelerated Mobile Pagesの略で、高速にWebページを表示するための技術です（参考: AMPの公式サイト）。

現在のWebは、低速なインターネット上で、モバイルデバイスを用いた利用が非常に多くなっています。特に東南アジア、インドやアフリカ、中国、南米などでその傾向は顕著です。

そういう環境でもWebページをストレスなく閲覧できるよう、Web標準に則った形で、出来る限り高速にWebページを表示できるようにするための技術がAMPです。

白石: なぜAMPは速いのですか？

山口: AMPは速いというよりも、「遅くなる要素を排除している」と言ったほうが正しいと思います。AMPは主に静的で文字中心のコンテンツを配信することを主眼に、HTML5でできることを相当絞り込んだ仕様です。その仕様に則ったHTMLページだけが、妥当なAMP対応ページとして扱われます。

そうした制限のおかげでページサイズも小さくなり、ブラウザによるレンダリングも高速に行われるというわけです。

白石: 具体的には、どのような制限がかけられているのでしょうか？

山口: 例えば、標準のimg要素やvideo要素は使用できず、すべてやと言ったカスタムタグに置き換える必要があります。こうした要素を使うことで、全ての画像や動画が遅延表示され、また、画面に表示されない間はダウンロードされなくなります。

CSSは外部CSSもstyle属性も使用することができません。全てHTML内に
Hello AMP World!
白石: カスタムタグにはどのようなものがあるんでしょう？山口: 利用できるタグはすべてドキュメントに記載されていますので、そちらをご覧いただくのが一番です（参考: AMPで利用できるコンポーネント/タグ）。 AMPのタグにはビルトイン（組み込み）とエクステンション（拡張）がありまして、エクステンションのタグを利用するには別途JavaScriptの読み込みが必要です。ビルトインのタグの代表的なものは、先ほど取り上げた、の代わりとなるです。エクステンションは現時点でもかなりの数が用意されていて、Google Analyticsを使用したり、YouTubeやTwitterの埋め込みを行えるタグもあります。白石: そうしたエクステンションは、サードパーティの開発者やベンダーでも開発できるんですか？山口: はい、可能です。ただ、AMPで利用できるタグは、AMP本体のリポジトリに取り込まれているものだけなんです。なので、開発したとしてもそれをリポジトリに取り込んでもらう努力が必要になります（参考: コンポーネントの開発・拡張についてのドキュメント）。白石: なるほど、そういうプロセスを経なければならないようにすることで、カスタムタグのクオリティを担保しているということですね。そういうレビューはGoogleが行っているんでしょうか？山口: AMP自体はオープンソースですし、Google一社のものではありません。リリース前からTwitterやPinterestもコミットしていましたし、オープンソースにしたおかげで、プロセスも透過的です。Google以外のコントリビューターも数多くいますし、そこは一般的な企業発のオープンソースプロダクトとあまり変わりはないと思いますね。 AMPページのアクセス解析は？広告は？白石: AMPはWeb全体に大きな影響を与えている技術だと思いますので、ビジネス面も含めた、もう少し俯瞰的な部分からもお話をお聞きしたいと思います。まず、AMPに対応すると、Google Analyticsなどの計測を正しく行えなくなるというのを聞いたことがあるのですが、これはどういうことですか？山口: まず、タグを入れているAMPページは、Google Analyticsをはじめとしたツールで、統一的に計測を行うことができます。ただそれでも、AMPキャッシュの仕組みの都合上、様々な不都合が生じていたのは事実です。白石: AMPキャッシュというのはなんですか？山口: GoogleのbotはAMPページを見つけると、専用のキャッシュサーバー（Google AMP Cache）にページをキャッシュします。 Googleは世界中にデータセンターやISP各社に協力していただいているエッジサーバーを持っており、ユーザーにとって物理的に最も近い位置のサーバーからページを読み込みますので、AMPページがより高速に表示されるというわけです。（筆者注: Google AMP CacheはAPIを用いて明示的なキャッシュを行わせることもできる）白石: Googleの検索結果から辿れるページとかは、AMPキャッシュからの応答ですね。山口: ただ、AMPキャッシュの問題は、元サイトとは異なるドメインからページが読み込まれるということです。そうなるとCookieが異なるので、Google Analyticsなどで正しく計測が行えないのです。（筆者注: 例えば当サイト（）のAMPページは「.cdn.ampproject.org」から読み込まれました）ただこの問題は、今ではほぼ解決されています。具体的には、Cookieの欠点を補うためのクライアントIDという値を用いることで、AMPキャッシュから配信されたページへのアクセスと、オリジナルサイトへのアクセスを統一して扱えるようになっています。筆者注: こうした問題とそのソリューションについては、以下のページに詳しい。 AMPページの直帰率の高さやユニークユーザー数は全部ウソ!? AMPアクセス解析には潜在的な問題あり – 海外SEO情報ブログ ⚡AMPの不正確なアクセス解析をGoogleアナリティクスが解消 – 海外SEO情報ブログ Google アナリティクス、AMPキャッシュ計測の問題を解決。AMP Client ID APIのオプトインで正確なアクセス解析が可能に – 海外SEO情報ブログ Client IDs in AMP pages – Googleアナリティクスヘルプ（日本語ページもあるのですが内容が古く、「Using a single Client ID across AMP and non-AMP pages」（AMPと非AMPページで同一のクライアントIDを使用する）という重要な節が抜けているようです）白石: なるほど、アクセス解析の問題については、ほぼ解決済みなのですね。知りませんでした。ほかには、AMPに対応することでパブリッシャーの広告収益に影響が出るのではないかという話を聞きましたが、これについてはいかがでしょうか？特に、AMPページに比べて広告の表示速度が遅いことで、広告が表示される前にユーザーが離脱してしまうのではないかと聞いています。山口: 実はAMPは、広告の高速化についても「AMP Ads」（筆者注: 「AMP for Ads (A4A)」とも呼ばれる）という取り組みを既に進めているんです。これは、広告コンテンツについてもAMPフォーマットで記述するというもので、従来よりも素早く表示されるだけでなく、AMPページ以外でも利用できますし、様々な広告ネットワーク上でも利用できる柔軟性があります。参考: AMP Ads の読み込みがさらに高速化 – Google Developers Japan Blog AMP Ads – GitHub (英語) 白石: そんな取り組みがされてたんですねー、全然知りませんでした。 AMPとPWAを組み合わせる白石: 最後に、技術者向けに深いトピックをいろいろお聞かせください。 AMPとPWA (Progressive Web Apps)を共存させる、という話を聞きます（※）が、具体的にはどのように組み合わせることができるのでしょうか？ ※ Combine AMP with Progressive Web Apps 山口: AMPは、言ってみればWebプラットフォーム上のフレームワークの1つに過ぎません。なので、例えばWebアプリマニフェストを書いておいて、AMPページからリンクすれば、モバイルアプリにWebアプリをインストールさせることも可能です。AMPだからと言って、特別なことは何もありません。白石: なるほど。山口: PWAと言うのはマーケティングワードという側面も強いので、「何を持ってPWAと呼ぶか」も難しいところではありますけどね。 AMPにはというタグもあって、AMPページを起点にしてServiceWorkerをインストールさせることもできます。これを応用すれば、まずはAMPページを高速に表示させておいて、裏でPWAに必要なアセットをServiceWorkerを利用してキャッシュしておき、リンクをクリックしたらPWAが高速に起動する…というアプローチも取ることができます。白石: AMPとPWAのいいところ取りができるというわけですね。面白い。あと、「PWAの中でAMPを使う」というアプローチも聞きました。外部のページをAMPで読み込むと言ったような。山口: それも可能ですね。AMPをiframeで開くというのが一つのパターンですが、更にもう一歩進んだアプローチとしては、外部のAMPページを読み込んで、Shadow DOMに突っ込んじゃうっていうパターンもあります。白石: それってどういうメリットがあるんですか？山口: これも高速化のテクニックの一つですね。iframeだと、AMP JSの読み込みがiframeごとに走るので無駄が多いんです。Shadow DOMに埋め込むのであれば、既に元ページでAMP JSが読み込まれていればいいので、それぞれのページで読み込む必要がありません。白石: なるほど、面白い！山口: これはAMPに限った話ではないのですが、従来iframeを使って読み込んでいたコンテンツを、Shadow DOMに埋め込むというテクニックは、広告とかにも応用可能です。広告が元ページに悪影響を及ぼさないようにカプセル化する役割を、Shadow DOMに任せるわけですね。白石: いやあ、最新のWeb技術てんこ盛りで、Webエンジニアとして大変興味深いお話です。AMPそのものも、そしてAMPを支える技術も、最新技術の塊ですね。本日は大変勉強になりました、ありがとうございました！（撮影：刑部友康写真提供：html5j HTML5 Conference 2017事務局）
ブラウザ戦争は終わった！Webの最先端と未来を、ブラウザエバンジェリストたちが語る白石俊平 — Tue, 06 Jun 2017 01:00:55 +0000 連載： de:code 2017 特集 (3) 本記事は、2017/5/23, 24に開催された「de:code 2017」の1セッション、「War is over : ブラウザエバンジェリスト達とWebの未来を語ろう」を聴講したレポートです。 GoogleやMozillaのエバンジェリストたちがマイクロソフトのセッションで仲良くお話、って光景を見るだけでも楽しいセッションでした左からMozilla Japan 技術戦略マネージャ浅井智也氏、Google デベロッパーアドボケート北村英志氏、日本マイクロソフトデベロッパーエヴァンジェリズム統括本部物江修氏 Web Payments, WebVR, Web Assembly, Progressive Web Appsについてエバンジェリストたちが語る Web Payments 物江まず、Web Paymentsについてお聞かせ願いたいのですが、こちら北村さんご説明をお願いできますか？北村まず前提として、インターネットを利用する際に私たちがクレジットカードを利用するようになってから、それなりに時間が経過しましたね。そして現在転換期が訪れているといっていいのではないかと思います。これまでのように、フォームにクレジットカードの情報を生で入れて送信するというので、本当にいいのだろうか。そうした問題を解決すべく提案されているのが、Payment Request APIです。他のサードパーティ製アプリに遷移して戻ってくるなどのUIを通じて、決済に必要な情報を、スムーズにユーザーに対して問い合わせることができます。（筆者注: Payment Request APIの日本語による解説記事）（筆者注: よりシンプルな Web の決済方法 : Payment Request API の紹介） Google デベロッパーアドボケート北村英志氏物江なるほど。このPayment Request APIですが、Edgeではバージョン15からサポートしていまして、Creators Updateを適用したWindows 10上ではすでに利用可能です。Firefoxでのサポートは行われる予定があるんでしょうか？浅井はい、時期はまだ言えないのですが、サポートするのは確定しています。北村 Chromeは現在Android版のみ対応していて、デスクトップ版は開発中です。物江あと、iOS版のChromeについても教えていただけますか？北村 iOS版Chromeは、iOSのWebViewを使っていて、iOSのWebViewはPayment Request APIに対応していません。なので、そのままだとiOS ChromeではPayment Request APIは使えないのですが、実はこれを無理やり使えるようにしてしまおうという計画がありまして。どう実現するかというと、ChromeからWebViewに対して機能を注入してしまうんですね。WebViewで通常使えないJavaScript APIを使えるようにしてしまう。Cordovaとかでは以前から普通に行われていたことです。これまではiOSのWebViewに対してJavaScriptをインジェクトして、新しいAPIを使えるようにするということはしてきませんでした。なので、iOS版のChromeにとっては大きな方針転換でもあります。物江このように、各種のプラットフォームでサポートがすでに始まっていますので、今年中か、もしくは来年の初めくらいには、一般的に使えるAPIになってそうですね。浅井個人的には、（Mozillaの前身である）Netscapeが切り開いた商用インターネットの世界が、ようやくここまで来たか…と感慨深いものがあります。 WebVR 物江では次はWebVRについてお聞きしていきましょう。WebVRについては、先日のCreators Updateから、1.1のAPIをサポートしはじめました。また、Babylon.jsやA-Frameといったライブラリを使うと、WebVRを簡単に扱うことができると。浅井さん、A-Frameについて教えていただけますか？浅井 A-Frameは、Web上で簡単にVRを扱えるようにすることを目指すライブラリです。例えば、HTMLタグを一つぽんと置くだけで360度画像を表示できるようにするとか。 Unityだとアセットストアがあって、アセットを購入したりすることができるのですが、それと同じようなエコシステムがコミュニティ主導で進められているのも特徴です。非常に簡単に3Dコンテンツを作れて、売り買いしながら作っていけるエコシステムができていくだろうと期待しています。 Mozilla Japan技術戦略マネージャ浅井智也氏物江コンテンツで思い出したんですが、意外とWeb上で3Dを扱うような仕事ってまだ少ないらしいんですよね。WebGLがモダンブラウザ全部でサポートされるようになってから結構経つのに、WebGLってどこかゲーム用途のイメージも強いみたいで。ただWebGLって、本来ゲーム以外の用途もたくさんあるはずなんです。例えばGrimoire.jsっていうライブラリがあるんですが、これは様々な3Dコンテンツを、簡単にWeb上で扱えるようにすることを目的としていて、こういう動きが盛り上がると、WebGLってもっと活用されるんじゃないかと思う。浅井その点VRは、コンテンツを中心とした盛り上がりも活発で、結構未来があるんじゃないかな、と思いますね。物江ちなみに、VRではなくてMR (Mixed Reality) でいうとHoloJSっていうのもあって、HoloLens用のアプリを作ることもできます…すごく大変なんですけどね(笑)。ところでChromeも、WebVRには対応済みですよね。何か最近の動きとかを教えていただけますか？北村そうですねー、Daydream上でChromeを立ち上げることができるようにする、というのは聞きましたね（筆者注: VR/AR空間内でChromeを立ち上げられるように、ということだと思われる。参考: Chrome is coming to augmented reality and Google Daydream (TechCrunch)）。 WebAssembly 物江では次は、WebAssemblyのお話を聞かせてください。やはりここは、（WebAssemblyの元になったasm.jsの開発元である） Mozillaの浅井さんにお聞きしようかと。浅井はい、WebAssemblyの元になったのはasm.jsという技術です。もともと、JavaScriptは動的な言語なので、パフォーマンスの向上にも限界がある。そこで、JavaScriptのサブセットとしてasm.jsが提案されたんです。変数の型が厳密に定義されており、さらに実行に先立ってコンパイルが可能なので、相当に速かった。 WebAssemblyは、さらにそれをコンパイル済みのバイナリとして配布できるようにする技術です。そのバイナリフォーマットに関する仕様がWebAssemblyです。実行速度は相当なもので、現在でもC言語の速度まであと20%というところまで迫っています。物江 FirefoxやChromeではすでに対応済みなんですよね。Edgeでも、フラグをONにすると使えるようになります。個人的にはJavaScriptを置き換えるようなものではなく、高機能な計算が必要なところに使うものだと思っていますが、合ってますか？浅井はい、そうだと思います。WebAssemblyに出力するのも、基本的にはC/C++やRust言語で書かれたものになりますし。物江ちなみに、WebAssemblyへのコンパイルって具体的にはどうやるんですか？浅井 EmscriptenとBinaryenというツールを組み合わせて、C/C++のコードをWebAssemblyに変換する…というのが一般的ですね。基本的には、LLVMの中間言語が出力できれば、そこからEmscriptenを使ってasm.jsに変換でき、更にBinaryenでWebAssembly化できます。（筆者注: https://github.com/kripken/emscripten/wiki/WebAssembly も参考のこと） Progressive Web Apps 物江昨今のWebの重要キーワード、Progressive Web Appsですが、これは北村さん説明をお願いできますか？北村はい。その前に、Progressive Web Appsって、ご存じの方どれくらいいます？…思ったより浸透してないですね。まだまだだな。 Progressive Web Appsっていうのは、一言で言うとモバイルウェブの新しい形です。 Webサイトがホーム画面から起動できるプッシュ通知オフラインで動く北村百聞は一見にしかずで、twitter.comをAndroid 版 Chromeで開いてみるというのが一番わかりやすいと思います。これはTwitter Liteと呼ばれていて、動作も素早いし、モバイルアプリと使い勝手はほとんど変わりません。浅井 PWAは、アプリに比べてデータ通信量も抑えめになるそうです。例えばTwitter Liteではアプリに比べて70%データが削減できるとか。なので、ブラジル、インド、インドネシアといった、ネットワークインフラの整っていない新興国では、アプリよりもユーザのコンバージョン率が高く、採用も広まっているようです。物江 Firefoxでの、PWA対応はいかがでしょう？浅井現在でもホーム画面へのインストールなど基本機能は対応していますし、今後フルスクリーン起動なども順次実装を進めていくそうです物江モバイルといえばネイティブアプリ、という印象はいまだに根強いですが、モバイルサイトも同時に構築できてしまうので、環境が整って利点が正しく理解されさえすれば、一気に広まりそうですよね。PWA対応していないブラウザでアクセスしたとしても、通常のWebアプリとして使えますし。ちなみにEdgeでは、今年の夏頃から開発者向けのビルドでPWAを試せるようになります。年末ぐらいまでには、メジャーブラウザでは全体的にPWAが使えるようになりそうですね。北村ちなみにマイクロソフトさんの検索エンジンのBingが、PWAを見つけたらWindows Storeに並べてしまうようになるというのを最近知って、すごい荒業だけどこれは面白いなと思いました。 PWAって捉えどころがないふわっとした用語ではありますが、実際には個々の技術それぞれにもすごく価値があります。オフラインやプッシュ通知がWebアプリで行えるというのは、Ajax以来の技術的な革命じゃないかと思いますね。 Web Components 物江そろそろお時間も迫ってまいりましたので、最後のトピックです。 Web Componentsについて語りたいのですが、北村さん、Web Componentsのご説明をお願いできますか？北村 Web Componentsっていうのは、一言で言うと、自分でHTMLタグを作れるという技術です。そして、自作したタグ（コンポーネント）を配布できる。 Web Componentsは、最近だとSafariに搭載されたのが大きいですね。iOSを含め、割とどこでも使えるメジャーな技術になりました。あともう一つ、AMP (Accellalated Mobile Pages）も実はWeb Componentsを使っています。AMPに対応しているサイトは、現時点でもかなりの数に上りますので、実際にはWeb Componentsはすごい勢いで広まっていると言っていいんじゃないかと思います。物江 Polymerというライブラリもあるそうですが、それとWeb Componentsの関係はどのようなものでしょうか？日本マイクロソフト株式会社デベロッパーエヴァンジェリズム統括本部物江修氏北村 Web Componentsっていうのは、W3Cで標準化が進められている技術なんです。具体的には4つの技術から構成されています。 Custom Elementは、先程申し上げたように独自のタグを作ることのできる技術です。 Shadow DOMは、DOMのカプセル化を行えるようにする技術。 Template Elementっていうのは、「テンプレートである」という意味合い以外持たないHTML要素です。 HTML Importというのは、JSやCSSのように、HTMLもインポート可能にするという技術です。一方でPolymerというのは、Web Componentsの上に構築されたライブラリです。 Web Components標準はそれほど高いレベルのAPIを提供しません。なので、実際にコンポーネントを作ろうとすると、実装の重複が多くなります。その重複を排除して、最小限のコードでコンポーネントを作れるようにするのがPolymerです。物江ちなみにEdgeは、Web Componentsについては長いこと意識しているようですが、まだ詳細は未定です。Polymerを使うと、現在のEdgeでもWeb Componentsが動作したりするんでしょうか？北村はい、PolymerはPolyfill（対応していないブラウザ上でAPIのエミュレーションを行うライブラリ）も含んでいますので、動作しますね。実は、現在のYouTubeサイトはWeb ComponentsベースのHTMLに全て書き換えられているんです。コードを見てみると面白いと思いますよ。あと、Polymerはライブラリだけじゃなくてコンポーネントも提供しているんです。 http://webcomponents.org/ を見てみると、すでにいろんなコンポーネントが利用できるのを確認できると思います。まとめ物江では、このディスカッションの締めくくりとして、Webの今後について一言ずついただけますでしょうか？浅井はい、モバイル時代は長らくネイティブアプリが中心でしたが、ここに来てWebの力が盛り返してきているのを感じています。ネイティブアプリと遜色ない機能を提供できるだけではなく、ユーザーにリーチするのも、アプリストアよりもWebのほうがハードルが低い。リンクを送るだけでプロモーションできますしね。そういう点で、PWAには期待しています。北村 PWAについては、ぼくも同じく期待しています。とりあえずTwitter Liteを触ってみてほしいですね。あとWebの今後という点で思いついたのですが、企業の枠組みを超えた合意形成の方法としては、Webはかなり進んでいるんじゃないかと思います。ディスカッションの場作りとか、標準化を行う上で蓄積されたノウハウはかなり貴重で、他の場面や業界にも活かされていくんじゃないかな…と考えています。物江ではそろそろお時間ですので、本セッションを終わりとしたいと思います。みなさま、本日は大変興味深いお話を、どうもありがとうございました。 Webアプリケーションにおける機械学習活用の基礎──HTML5 Conference 2016セッションレポート中井悦司 — Mon, 14 Nov 2016 01:00:51 +0000 連載： HTML5 Conference 2016 特集 (10) みなさん、こんにちは。Google Cloud Solutions Architectの中井です。 HTML5 Conference 2016では、「Webアプリケーションにおける機械学習活用の基礎」と題して、機械学習の基礎となる仕組み、そして、機械学習を利用したクライアントアプリケーションの例を紹介させていただきました。今回は、この発表の内容を振り返りたいと思います。機械学習とディープラーニング、そして、AIの関係機械学習そのものは古くから利用されている技術であり、過去のデータを元にして、「（まだ見たことのない）未来のデータにもあてはまる一般的なルール」を発見することがその役割となります。つまり、はじめて見るデータに対して、何らかの予測を立てることができるようになります。たとえば、映画のレコメンデーションシステムであれば、新しいユーザーのプロファイルデータから、そのユーザーが高い評価を付けるであろう作品を予測します。ただし、これはあくまでも予測ですので、必ず正解するというわけではありません。予測の精度をいかに上げるかが機械学習の課題となります。そして、近年のディープラーニングの発展により、一部の領域においては、その予測精度が格段に向上しました。プロの棋士と同等、あるいは、それを上回る精度で「勝利につながる一手」を予測する囲碁プログラム、本物の人間であるかのように、あるメッセージに対する「自然な応答メッセージ」を予測するチャットボットなど、中の仕組みを知らない人間からすると、あたかもコンピューターが「知性」を持っているかのように感じられるレベルにまで達しています。ちなみに、最近、各種メディアでは、「AI（人工知能）で◯◯を実現」というタイトルを目にすることがあります。しかしながら、何を指して「AI（人工知能）」と呼んでいるのかが曖昧なことも少なくありません。AI（人工知能）もまた長い歴史を持つ研究分野であり、AI（人工知能）の定義にもいくつかのパターンがあるようですが、現代的な文脈では、「あたかも知性を持っているかのように感じられる製品やサービス」を指して、AI（人工知能）と呼んでいると考えるのが適切かもしれません。そのような製品・サービスを実現する上で、高い精度での予測を実現するディープラーニングは、欠くことのできない中核技術になりつつあるということでしょう。（これは余談ですが、個人的には、「AI（人工知能）で◯◯を実現」というタイトルを見るたびに、心の中でそっと、「AI（知性を持ったかのように見える製品やサービス）を実現するために研究・活用が進んでいる機械学習を基礎とした一連のデータ収集・分析技術で〇〇を実現」と読みかえて納得することにしています）「線形2項分類器」で機械学習の基礎を学ぶこの発表では、まずはじめに、機械学習の基礎となる「線形2項分類器」、そして、それを実現する「ロジスティック回帰」のアルゴリズムを解説しました。下図のように平面ちらばった◯✕の2種類のデータに対して、これらを分類する直線を自動的に見つけ出すという問題です。そして、機械学習の世界では、主に「確率」を用いた予測が行われます。下図のように、求めるべき直線を関数 f で表した後に、ロジスティック・シグモイド関数 σ を用いて、「あるデータが『✕』のタイプである確率」を計算します。この計算式には、未知のパラメーター（w0, w1, w2）が含まれており、既存のデータに対する予測精度が最大化されるように、これらのパラメーターを自動調整するということを行います。自動調整に用いられるアルゴリズムの詳細は、ここでは割愛しますが、たとえば、「Neural Network Playground」を利用すると、実際のチューニングの様子を観察することができます。これは、TensorFlowの動作をJavaScriptでエミュレーションしたもので、機械学習の処理が進む様子をブラウザー上で観察することができます。会場では、参加者の方々にも、実際にリンクを開いて機械学習の動作を体験していただきました。「線形多項分類器」で文字認識に挑戦先ほどの例では、◯✕の2種類のデータを分類しましたが、これをより多数の種類に分類できるように拡張したものが「線形多項分類器」です。たとえば、3種類に分類するのであれば、下図のように、3つの１次関数を用意します。そして、どの１次関数の値が最も大きいかによって、領域を分類します。ちなみに、(x1,x2)平面上で１次関数がとる値を3次元のグラフに表すと、1枚の平面になります。したがって、3枚の平面を配置して、どの平面が一番上に来るかで領域を分類していると考えることができます。ただし、前述のように、機械学習の世界では「確率」で予測を行う必要があります。それぞれの1次関数の値を0〜1の確率に変換するのが、下図の「ソフトマックス関数」です。ここでは、簡単化した1変数の例を図示してありますが、f1, f2, f3の値の大小関係が、きれいに確率の大小関係に変換されていることがわかります。会場では、この仕組みを用いて、画像データの分類を行うデモを紹介しました。ここで使用したのは、MNISTデータセットと呼ばれる手書き数字の画像を集めたデータセットです。それぞれが28✕28=784ピクセルのグレイスケールの画像になっており、1つの画像データは、784個のピクセル値（各ピクセルの濃度の値）からなります。そして、784個のピクセル値からなるデータは、784次元空間の1つの点に対応すると考えることが可能です。いきなり784次元空間が登場して驚くかも知れませんが、それほど難しい話ではありません。3次元空間の点は、(x,y,z)の3つの数値で指定することが可能です。これと同じように、784次元空間の点は、784個の座標値で指定することができます。そして、大量の画像データを784次元空間にばらまくと、下図のように、同じ数字の画像は互いに近くに集まって、クラスターを形成すると想像することができます。仮にこの想像が正しければ、線形多項分類器を用いて、784次元空間を10ヶ所の領域に分割することで、画像の分類が可能になります。新しい画像データが与えられた場合は、それがどの領域に入るかによって、どの数字であるかを予測することができます。下図は、TensorFlowを用いて実装したコードで実際に分類を行った結果です。ここでは、トレーニング用のデータセットで学習した後に、テスト用のデータに対して予測を行っています。正解例だけを見ていると優秀な結果にも見えますが、不正解例を見ると、わりと単純なミスを犯していることもわかります。これは、ピクセルの配置情報だけを用いて分類を行っていることが原因です。たとえば、上図における、上から2段目の右端の例が特徴的です。この縦長の「6」は、ピクセルの並びだけを見ていると「1」に近いため、「1」であると誤分類されています。人間が数字の種類を判別する際は、単純なピクセルの並びだけではなく、「穴が空いている」などの空間的な情報も利用します。この分類の精度を向上するには、このような、ピクセルの並び以外の特徴を取り出す必要があるのです。「畳込みニューラルネットワーク」による性能向上画像認識において、画像の空間的な特徴を取り出すのに役立つのが「畳込みフィルター」です。下図に示す「畳込みニューラルネットワーク(CNN:Convolutional Neural Network）」では、事前に畳込みフィルターを用いて、画像の特徴を抽出した後に、それを用いて多項分類器（ソフトマックス関数）による分類処理を行います。ただし、どのようなフィルターを用いれば、分類に役立つ特徴が抽出できるかを考えるのは簡単ではありません。実は、CNNでは、フィルターを構成するパラメータ値も機械学習の対象としてしまいます。はじめは、乱数で用意したフィルターを用いて判別処理を行います。当然ながら、判別精度はそれほど高くありません。この後、判別精度が向上するように、フィルターのパラメータ値を自動的に調整していきます。会場では、この処理を実行するTensorFlowのコードを紹介した上で、学習結果を用いた簡易的な「手書き文字認識アプリ」をデモで紹介しました。下図は、入力画像に対して、「0」〜「9」のそれぞれの数字である確率を表示している例になります。参考資料当日の発表では、このような機械学習を活用したアプリケーションの例、あるいは、今後想定される利用パターンなども紹介させていただきました。興味のある方は、当日の発表資料を参考にしてください。また、発表の中では、線形多項分類器やCNNのパラメータを自動調整するアルゴリズムの解説までは手が回りませんでした。これらの理論的背景に興味のある方は、下記の書籍も参考にしていただければ幸いです。 ITエンジニアのための機械学習理論入門中井悦司（著）（技術評論社） TensorFlowで学ぶディープラーニング入門中井悦司（著）（マイナビ出版）（撮影・写真提供：HTML5 Conference 2016撮影スタッフ）及川卓也さん、河合良哉さんに聞いた「地方で日本で働く・海外で働くの話」（その２）──HTML5 Conference 2016セッションレポート加藤拓明 — Wed, 02 Nov 2016 01:00:14 +0000 連載： HTML5 Conference 2016 特集 (8) HTML5 Conference 2016の展示ブースでお届けしたカンファレンスラジオコーナー。Increments及川卓也さんとヤマハ河合良哉さんがゲストに来てくれた「地方で日本で働く・海外で働くの話」を完全版テキストの後編をレポートします！日本と海外の違いの話前編に引き続き、ゲストはIncrements及川卓也さんとヤマハ河合良哉さんです。「実際に今年海外に行かれて困ったことや、こういうところが違うの？とか、びっくりしたエピソードがあればお聞きしたいのですけれど、何かギャップとかありますか？日本のカルチャーと（比べて）」「ギャップですか？」「はい。例えば、僕が一番気になるのは食べものとかです。海外の姿は想像ではあるんですが、日本だとそこらへんに自動販売機やらコンビニやらがあって、買いたいジャンルのものがすぐに手が届くところにいっぱいある。たぶん海外というか、今お勤めされているサンフランシスコは土地も広いこともあるし、そういうのはないんじゃないかなって思って。「そうなんです。そこおっしゃる通りで、日本に帰ってきていつも便利だなって思うのがコンビニエンスストアの存在なんですね。アメリカにもコンビニエンスストアはあるんですけど、そこに陳列されているものが全然違ってるんです」「日本だとちょっと小腹がすいたなって思うとおにぎりだったり、サンドイッチや菓子パンは大体100円とか200円くらいで手に入るというのが大体じゃないですか。向こうに行くとおにぎりとか、サンドイッチとか…おにぎりはないにしてもサンドイッチとかは結構な値段しちゃったり。買って食べると、えっこれすごいまずいみたいなのがあったりして。気軽に買えないんですよね、怖くて。逆にがっかりしちゃうことがあるので（笑）」「こっちで買うような気持ちで、サンドイッチ買うっていうことはできないんですね」「やめたほうがいいかなと（笑）。そこは日本に帰ってきてすごい便利だなと思いつつ、便利すぎて日本に帰ってくるといっぱい食べちゃうんで、夜寝るときなんか胃がもたれてるなとか」「なんかアメリカのそういったコンビニにとかで売ってるやつって、見た目からしてまずそうですよね」「そうですね」「見た目あまりこだわらないじゃないですか」「こだわらないですね」「こだわるときはなんかカラフルな感じになっていて、これはこれで食べたらまずそうな感じだなって（笑）」「本当M&M’sの配色の感じですよね。もうすごい赤とか、すごい黄色とか」「なんか脳の奥の方でこれ食ったらダメだよって、自分に語りかけてるようなものしかないんですよね（笑）」「そうですね（笑）」「色に対する感覚が違うんですかね？」「原色が好きなんじゃないですか？知らない（笑）」「原色系本当多いですよね。例えば食べ物の話じゃないですけど、MicrosoftのWordとか開いて、1番最初に図形とかパッと入れるとすごく緑の色が出てきたりするわけですよ。これすごい昔から不自然だなって思ってたんですけど、アメリカのそういう食材とか見ると、なるほどなって逆に納得しちゃって（笑）」「そういうことですか」「おそらく。だから色に対する感覚が、日本人と違うところは間違いなくありますよね」「やっぱり、普段慣れ親しんでいる色がそういう配色のものが多いという環境による要因なのか、人種による気質がそうなっているのかというと、どっちなんでしょうね？それはわからないですね」「どうなんでしょうね」「とりとめのない質問をしてしまって、今は反省しています」年齢が違う人とのコミュニケーション「この後、僕らはどこにいく感じになるんですか？」「えっとですね…」「別に早く終われって言っているわけじゃないですよ。まだ全然話してもいいんだけど、この議論はどこに流れ着くのかなと思って（笑）」「本来僕がここでやらなきゃいけないのは、ゲストのお二方の面白い話を伝えないといけない」「今ね、加藤くんが面白い人になっているから（笑）」「ごめんなさい。では、みんなが聞きたいんじゃないかなって思ったことを及川さんに質問していいですか？」「いいですよ」「去年転職されて大きく環境が変わったと思うんですけど、お若い方が多い会社に入られたじゃないですか。年齢が違うと、共通の話題だったり当時流行っていたものも違うと思うんですけど、年齢が違うことでコミュニケーションが難しい部分があったりするんでしょうか？」「たぶんね、みんなが気使ってくれるんですよ。だからあまりそういうので困ったことはないですね」「なるほど（笑）」「長老が入ってきたという感じで、一生懸命おじいちゃんから聞いた話とかを思い出して話してくれるから」「皆さんとは飲みに行ったり、遊びに行ったりするんですか？」「そうですね。でもね、真面目な話わからないというか、今同じ世代でも趣味が違ったら全然話通じなかったりしません？昔って、視聴率30%取ったようなドラマがあったらみんなそれ見てるとかってあるけど、今は高校の時見てたドラマで全員に絶対通じるものってなかったりすると思う。趣味が違った人とはあまり通じないっていうことは、普通だったりするんじゃないかなって思うんですよね」「なるほど」「あまり困らないし、わからなくても別に気にしないし、そこで教えてもらえればいいかな。それ何？って言って、あーそんなのあったんだ、その頃俺何やってたかなー？みたいな感じで。で、気にせず僕、昔の話ガンガンしますから（笑）」「素直にやり取りできるのってすごく大事ですよね。そういった謙虚さってすごいです」新しい技術に対する取り組み方の違い　「僕は仕事が変わって、学生とやり取りすることが多くなったんですけど、彼らってどんどん新しいことをやろうとするのに物怖じしない子が多いなと思って。新しい言語が出たら、『よしやってみよう！』ってやるんですけど、僕だと『これいつまで使えるのかな？』とか、『実際これ覚えたとして何の役に立つんだろう？』とか考えてからやっちゃうんですよ」「彼らは、『それ面白い使ってみよう、動いた！』って。で、どんどんやっていくっていうので、なんか自分歳をとったなって感じることがあって。一概にそういうわけじゃないですけど、年齢が離れれば離れるほど物事に対する取り組み方って変わってくるのかなって思って」「でも、技術がずっと使われるかどうかなんて全然わかんなくって、僕だって大学時代に使ってたのってFortranですけど、今Fortranなんて全く忘れてる。10年くらい前Web系のやつやっていた時はPerlだったけど、Perlもほとんど覚えてないし、その時にFortranが自分の30年後、40年後も使ってるかなんて考えたこともないし」「Perlの時だって別にそこまで考えたわけじゃなくて。そこはあまり気にしないし、逆に、大きく内容が違うならともかく、技術ってどこかで関連性があるから一つの技術を覚えた時に、ここの応用だとか、これはここでいう何だっただろうってことを考えるだけで飲み込みが早いってことは多いと思うんですよ。プログラム言語じゃない話をすると、僕OSを作ってたわけですよね、Microsoft時代に」「はい」「今Webブラウザって結局はOSなんですよ。中でやっているものっていうのは、普通にスケジュール管理みたいなものもあれば、スレッド管理みたいなものもある。メモリ管理みたいなものもあるし、ガベージコレクションどうしようとかっていうところとかって中で普通にガチガチ入ってたりするわけですね」「そうすると、ブラウザがOS化してくっていう流れになった時に、OSを作っていた時のいろんな知識だとか経験って役に立つんですよね。たぶんそれプログラム言語でも一緒ですし、ネットワークプロトコルでも一緒だし、なんでも同じだと思うんですよ。例えば、ネットワークって昔TCP/IPが流行る前とかっていうのは、普通にシリアルコネクタRS232Cっていうのがあったんですよ」「はい」「その上で、パソコン通信のためのやり取りだとか、ファイル転送のプログラムがあるわけですよ。Kermitって言われているのがあって、僕はKermitをあるプラットフォームに移植したんだけれども、そこでやっているプロトコルのいろんな手順で、結局はその後TCP/IPで見た時に同じ様なことをやっているんですよ」「結局はウインドウ制御みたいな話が出てきたりとかっていうのは、基本は一緒なんですね。ヘッダーがあってトレーラーがあってだとか、あとはチェックサムだかなんかをつけて、ちゃんとそこのところのデータの妥当性をチェックしてますみたいな当たり前のところっていうのは、どんなプロトコルになったってそんな変わらなかったりするんですよね」「なので、一旦覚えたってやつが完全に無駄になることはないと思うんですよ。そのままその技術が使えるかっていうとそれはこの世の中だし、これだけ技術が早いんで、それは期待しないほうがいいとは思うけど、なんかで流用できるし、生きてくるんじゃないかなと思います」「なんかこれエラー発生しましたけど大丈夫ですか？」「これは…よくないエラーですね」「じゃあ、僕らは会場にいる人に語りかけましょう。会場限定！」「YouTubeの配信の方が今壊れてまして」「配信の方は申し訳ないです」「聞こえてないですけどね、配信の人には（笑）」「そうですね（笑）」「河合さんはなんかそういうのないんですか？僕はいいことばっか言っちゃったけど、こういうのを見て、その技術には取り組んだ方がいいかもしれないけど、それはちょっと流石に慎重になった方がいなって思うようなものとか」「まだ僕はおそらく経験が浅すぎていっぱい取り込んでる方だと思っているので、そこまでのところはないですけど、おっしゃった通りです。1つ学んだことっていうのはそこで学んだものが終わったとしても死ぬわけではなくて、必ずどこかで生きてくるっていうことが所々感じるとこはもちろんある。だからやっぱり物怖じしてやらないというよりは、やってしまった方が面白いんじゃないのかなっていう気はします。私事をお話しするんですけど、このWebBluetoothを始めたのは1カ月か2カ月くらい前なんですよ」「そうなんですか」「面白そうだなっては思っていたんですけど、やれる機会があまりなくて、まあちょっとやってみようって始めてみて、もちろんまだGoogleのChromeしかおそらく対応していないので、このあと使える技術かどうかなんてわからないわけなんですよ。なんですけど、やっぱり面白いからやってみよう感じになっているので」　「そうそう！だからその技術がなくなっちゃうっていうことを恐れている人は、会場にもいたんですけど、あんどうやすしさんっていう人がいるんですね。知っていますか？」「はい！」「彼ね、今日ね、引っ張り出したっていうウエーブ(Google Wave※)のTシャツ着てきてましたから。ウエーブ本出したらウエーブがシャットダウンすることになって、シャットダウンのアナウンスがあった数日後に出版になったっていうね（笑）。人生で一番不幸な人みたいな。なんか彼が取り組んだ技術はだいたいdeprecateされるっていうDEATH NOTEの生き証人みたいな人がいるんです。でも全然恐れていないで、いろんなことどんどんやってますよ」「なるほど。これからはそういう姿勢をとっていった方がいいことが多いかもしれませんね。学生のやり方を見て僕がいいなと思ったのが、Webの質問サイトとかに質問をたくさん書いていたんですよ。それが1個2個じゃなくて10個20個とかすごく書いていて、調べて分からなかったらすぐに聞いてどんどんやっているんだって思って」「まとめたものがあったらまさしくQiitaとかに書けばいいし、そうすると最新の技術が出てきた時に、早めにキャッチアップできてQiitaみたいな記事が書けると、みんなに注目されて界隈で目立てるというか、そういうプラス面があるじゃないですか。その姿勢ってすごくいいなって思いました。スモールスタートというか、物怖じするんじゃなくて、面白そう、ちょっとやったらできるんじゃないか、頑張ってやってみよう、わからなかったら周りに聞こう、まとめたらアウトプットしようみたいな、そういうエンジニアになっていくのがいいんじゃないかって」「でも技術者って、基本面白いからその技術に取り組むんじゃないですか？例えばArduinoだとかRaspberry Piとかも、今でこそIoT的に使えるかもしれないけど、最初はただの電子工作じゃないですか」「いわゆるおもちゃみたいな位置付けだったんですよね」「すべての技術はおもちゃから始まるんですよ。僕それもうずっと言っていて、要はイノベーションのジレンマっていう話あるじゃないですか？あの破壊的イノベーションっていうのは、基本的にその時にその業界において、ほとんどおもちゃって思われているやつなんですよ。メインフレームがあった時に、僕がいたDECって会社が作っていたミニコンっていうのは、ほとんどおもちゃみたいなものなんですね。ミニコンとかがある程度出てきてダウンサイズが見えた時にもうワークステーション、さらにそれ飛び越えてパソコンなんておもちゃなんですよ」「当時のNECの98シリーズを作った時に、おそらくNECの98をやれって言われていた技術者の人は、メインフレームをやっていた時に、そこに部隊異動になったら勘弁してくれって思うわけですよ。ほとんどおもちゃって言われていたのが、あっという間にメインストリームの技術を追い越していくっていうのが破壊的イノベーションなんですね。基本おもちゃっていうところで、これ面白いっていうのが実は人が集まってきて育っていくと、それがメインストリームになって、今までの事実を置き換えていくということが起きているんですよ」「みんなが面白いって思っているやつとか、さっき言った生き残るかもっていうのは何かあると。生き残るかもしれないっていうのは、確率論でいうとあるかもしれないですよ」「そこにいろいろ面白い展示がありますけど、WebのMIDI関係今一番面白いなって思っていることってどういうことですか？」「面白いなって思っていることですか？」「さっき及川さんが、空間の？概念がWebで表現できるって、そしたら音もその空間、例えばちょっと動いたらそっちから聞こえるっていうそういう表現ができたりっていう風になっていくんでしょうか？」「この間Chromeの方に実装されたJUMP(※)っていう、Googleの出している専用のプラットホームでしか見られない映像でしたっけ？音響をWebブラウザ上で再現できるようになっていて、そのJUMPでフォーマットで録られた音声は3Dの音響でちゃんと聞けるっていう状態になっていたりします」「もうそういうことができる時代になっていたんですね」「そうですね。だいたい音って、結構最初は取りかからないんですよ。最初は映像が入って、目で見る方が完成し出すと、音ができるみたいな。WebオーディオとかMIDIもそうだったんですけど。Canvasが動くようになって、WebGLが動くようになって、じゃあは次は音だろってみたいな流れになるわけですよ。音ができると、その次は3Dだという話になるわけですよね。CanvasからWebGLになったみたいに。今その流れがきているかなって感はありますけどね」「なるほど」「最近WebVRとか言ってWebブラウザ上でVRができるようなフレームワークができていたりするんですけど、そこは面白いかなっていう気はします」 Google Wave：過去に米グーグルがサービス提供していたコミュニケーション及びコラボレーションツール。2010年5月にはサービスを一般公開したが利用者が増えず、同年8月4日に開発中止を表明。サービス自体は2012年4月末まで継続された。 JUMP：グーグルが提供するVRコンテンツ作成システムまとめ「この後13時からセッションされるんですよね？」「そうですね。13:20ですね、そろそろ」「そちらの方で今のような話とかも？」「そうですね。まさに今頭の中でそこで話す内容ちょっと話しちゃったな、みたいな。どうしようみたいな感じだったんですけど（笑）」「今ここで先にお話ししてしまったかもしれませんが、その話も聞けるということなので、ぜひご興味ある方は河合さんのセッションをご覧になってみてはと思います」「よろしくお願いします」「準備のお時間もありますよね、すみませんでした」「いえいえ、13:20からなんで大丈夫です。おそらくまとめをするとなると、とりあえずやってみろっていうことですよね。口で言う前にとりあえず手を動かしてみろと。それが自分を作るっていう感じなんですかね？」河合さんの講演動画はこちらからどうぞ！「純粋に面白いんじゃないじゃないですか？学生さんもきっと面白いと思ってやっているんで。逆に言うと、なんで加藤さんやんないのかなっていう（笑）」「なんかちょっとひねくれているんでしょうかね？」（笑）「ごめんごめん、いじめたかったわけじゃないから（笑）。元気出そうよ！なんかツラいことあった？」「いえ、大丈夫です」「今日夜行のバスで福島から来てるんですよ。おそらく疲れてらっしゃる」「なるほど」「すみません、多大なフォローをいただきありがとうございます！」「いえ、とんでもない」「すみません、スピーカーを入れていただいた方もどうもありがとうございました。この辺りで、第1回目は終了したいと思います」「ありがとうございました！」ラジオブースで放送した全ての内容を動画で公開！放送1回目だけでなく、ラジオブースで放送した全ての内容を動画でも公開中です。「地方で日本で働く海外で働くの話」は、動画の[3:03:38]-[3:50:50]です。「地方で日本で働く・海外で働くの話」 by DJ KATO [ゲスト：及川卓也さん、河合良哉さん] 「ハードウェア楽しいですよね」 by DJ KATO [ゲスト：中川友紀子さん、羽田野太巳さん] 「ハートブレイクカフェ」 by DJ KATO & 物江修さん（撮影・写真提供：HTML5 Conference 2016撮影スタッフ）及川卓也さん、河合良哉さんに聞いた「地方で日本で働く・海外で働くの話」（その１）──HTML5 Conference 2016☆番外編加藤拓明 — Tue, 01 Nov 2016 00:40:00 +0000 連載： HTML5 Conference 2016 特集 (7) HTML5 Conference 2016の展示ブースでは、私DJ KATOによる特別ラジオをお届けしておりました。すごく面白いので、Increments及川卓也さんとヤマハ河合良哉さんがゲストに来てくれた「地方で日本で働く・海外で働くの話」を完全版テキストで書き起こしてみました。ぜひ、カンファレンスレポートの番外編としてお楽しみください！まずは、自己紹介をお願いします「海外にも地方にも行っていないのに、なぜか呼ばれています。Increments株式会社の及川卓也です」「ヤマハ株式会社の河合良哉です。よろしくお願いします」「地方にも海外にも行っていないというお話がありましたが、環境が大きく変わったという面で共通点があると考え、広い意味での定義としてとらえてほしいです」「はい」「まず、及川さんは…」「ちょっと待って。お前は誰だという感じだから（笑）」「あ！僕ですね！私、会津若松にあるIT系の会社に勤めております、加藤と申します。DJ KATOと名乗って、こういった司会をやらせていただいてます。どうぞよろしくお願いします」「イエーイ！」及川卓也さんの基調講演のお話「先ほど基調講演を終えられたばかりですよね？（基調講演の後で）時間ありました？」「1つセッションを聞いてきましたよ、React.jsの難しいやつを。途中で抜けてきちゃったんだけど」「結構技術的な話を聞いてきたんですね。及川さんはどのようなお話をされたんですか？僕は聞きに行けなかったので…」「聞いてなかったんだ！（笑）」「準備をしていたので…」「そうですか、ご苦労様です。僕は何の話をしたんだっけ？Webの話をしたんですよ。一応Webのカンファレンスなので。なんか飲んでもいないのに酔っ払ってるみたいですみません（笑）」「Webは3つの側面がありますねという話で、アプリケーションの技術としてのWebとメディアとしてのWeb。あとはインフラ技術としてのWebで、それぞれいろんな局面を迎えている。でも今後も投資して、さらに発展させていかなきゃいけないですね、というすごくいい感じの話をした気がします」「なるほど。そういった広い視点でのお話をされたという感じですね」？？？？？？？？？？？？？「ごめんなさい！緊張してしまって、わけのわからないことを言って申し訳ないです」「基調講演を聞いていないのに申し訳ないのですが、プラットホームとしてのWebって、例えばどういう変化が起きてて、これからどうなるということなんでしょうか？」「ずっと起きている話で、要は機能的にもどんどん追加されてきていると。で、ある程度WebのAPIってそこそこ揃ったようには見えるんだけれども、実はWebって古くからコンピューターディスプレイがあって、キーボードがあって、マウスがあるというところから、やっと今スマホみたいなところになってきている。そういった今までのデバイスやメディア系のものを超えたものに、これからはなっていくでしょうという話をしました」「はい」「ちょうど私の前にW3Cで慶応大の中村修先生が、HDRの話をされていました。要は輝度の部分をJavaScriptでWebからコントロールできたならば、映像が大きく変わるだろうって話を少しされてたんです」「それにインスパイアされて、音の部分もaudioタグがあって、Web MIDIがあって、Web Audioもある。そんな状況ですが、実は2009年という早い段階からGoogleは考えていたんです。空間音響みたいなところで、要はVRのサウンド版。どこの位置にいたならばどういうふうに音が聞こえるはずだということを、拡張機能として公開しているのがもうあったりするんですね」「はい」「今までの普通にコンピューターディスプレイやスピーカー、ヘッドホンだけでは想像もつかなかったようなところまで、実はそのアプリケーションとしての可能性もまだまだ可能性がありますねって話」「あとはWebAssemblyの話で、もはやそうなってくるとJavaScriptとHTMLとCSSとは全く違うアプリケーション開発技術も出てくるから、楽しいと同時にいろいろと考えなきゃいけないねっていう話をした感じです」【基調講演】Webはオープンな分散型OS、アプリケーション・メディア・プラットフォームとしてのWeb技術─中村修教授、及川卓也氏が語ったHTML5の未来「大丈夫ですか？これで今回のテーマにだんだん近づいてきます？」「まだ1mmも近づいていないんですが、話の流れを大事に進めていこうと思います」「了解です、任せます。ちょっと不安になりました（笑）」河合さんに聞いたWeb MIDIのお話「河合さんはWebとMIDIに関してお仕事上関わりがあると思うのですが、その方面で、今までできなかったことが今後できるようになるものにはどのようなものがありますか？」「この隣にWeb Music Developers JP(※)というコミュニティーが主催している展示会場があって、そこで缶が鳴っていますけど、実はMIDIで動いていたりするんですよ。今まさに及川さんがおっしゃった、プラットホームとしてのWebのところでMIDIも入ってくるのかなと。外部のExtarnalのデバイスとブラウザが直接つながると、そこで起こったことは僕が言うのもすごく手前味噌なんですけど、楽器業界がWebの業界にどんどん入ってきたと言えるんじゃないかと思います」「楽器が…Webに？」「これも手前味噌なんですけど、ヤマハがrefaceというシンセサイザーを去年出したんですね。そのシンセサイザーは、普通のシンセサイザーだと大体ボイス、音色のパラメーターを保存するのに楽器に載っているメモリに保存するんです。だけど、そのrefaceというモデルに関しては保存する部分がなくて、どうするかというとWeb MIDIで接続をして、ブラウザから直接Cloudの方に保存する。そういうことで少し形が変わったかな。Webをストレージとして使うというような考え方に移ったと」「なるほど」「もう少し話すと、プラットホームとしてのWebという意味で、僕も昔から思っていて、やっぱりブラウザというとディスプレイがあってキーボードが目の前にあって、そこから外にあまり出ないよみたいなイメージがあると思うんですけど、それがまずMIDIで楽器の業界で外に出ましたと」「はい」「今ですね、GoogleのChromeにしか搭載されていないのかもしれないですけど、WebBluetoothっていうのがあって。このWebBluetoothというのを使うと、今度Bluetooth SMARTって呼ばれる世の中でいうBLEというやつですね。BLEの機器に直接接続ができるんですよ」「はい」「あそこにM&M’sが入ったおもちゃみたいなのがあるじゃないですか。あれ実はBluetoothで接続をして、ボタンを押すと中に入っているM&M’sがババババーッと出てくるおもちゃなんですけど、ああいうものが作れるようになるわけです」「なるほど。これたぶんラジオで聞いている人にはちょっと…」「見えないですね（笑）」「見えづらいかなと思うんですけど、このすぐ隣にWeb Music Developers JPさんのブースがありまして、そこにWeb MIDIといろいろなものがあって、PCとMIDI楽器なんでしょうか？あれは？」「そうですね。真ん中に並んでいるのはMIDIを使ったコントローラーで、その次に並んでいるのがライブビーツっていうブラウザを楽器にしてしまうような作品です。で、その隣にあるのがシーケンサー、これFirebaseを使って、いろいろな人と進行しながら音楽を作っていくハッカソンでハックしてもらった作品が展示されています。その隣には、これもWebの技術を使って照明をコントロールしようというもので、照明がコントロールされています」「照明を、MIDIで？」「はいそうですね」「あ、そうなんですね」「MIDIってミュージカルインストゥルメンタルデジタルインターフェイスという名前なんですけど、そのプロトコルを別の用途で使ってしまっているということですね」「つまりMIDIって、タイミングだったり音色だったりという概念があって、それを表示のタイミングだったり、どの色にするかに置き換えて命令を出すという感じなんでしょうか」「そうですね。おっしゃるとおりでございます」「なるほど」「その隣に並んでいるのがMIDIに関係ないですけど、WebBluetoothで接続されているお菓子が出てくるおもちゃです」「さっき河合さんがブースを作っている準備段階をお見かけしたんですけど、M&M’sが勝手に動いてチョコレートをバラバラと吐き出しているのを見ましたけど、あれもMIDIでやっていた？」「いや、あれはMIDIとは関係なくて、Bluetoothで接続をしてBluetoothで動かしています。もう一回出してみます。……あんな感じで」 ※筆者注：↑Bluetoothで動かしているとさっき河合さんが言ってました。話を聞いていない。「今出てる！」「ここから接続しているんですけどね、全然見えないですよね（笑）」「今まではMIDIというと、鍵盤があってそれをUSBでPCに繋ぐと、そのPCのソフトで楽器が鳴る。それは専用のソフトがあってそのソフトが鳴るイメージだったものが、今はWebブラウザがあればそのWebブラウザの表示の機能でMIDIのUSBに繋ぐだけで全部音が鳴ったりだとか、専用ソフトになるようなことが全部出来てしまうという状態になっているということですね」「そうですね。それを楽器以外のもので使うことのも可能なので、そういったとこに応用していくっていうのもありかな」「なるほど」＜参考情報＞ Web Music Developers JP のgoogleグループ reface 河合さんがサンフランシスコに拠点を移されたお話「ちなみに今年サンフランシスコの方に拠点を移されたということで、それはどういった目的で移動されたのですか？」「夢にも思ってもなかったのですが、ありがたいことに駐在の司令を出してもらえ、今年1月下旬からアメリカに住んでます」「日本でのWebのMIDIの普及と、海外でのWebのMIDIの普及には違いがあるんでしょうか？ご自身で決めていったというわけではないという話だったので、そういう依頼があったわけではないと思いますけど、海外に行ったことで日本のWebMIDIの盛り上がりと、海外の盛り上がりの違いがあったらお聞きしたいです」「基本的に僕がまだ全然知らないだけかもしれないですけど、日本で今展示しているのがWeb Music Developers JPなんですけど、ここが異常に盛り上がっている感があるというのが僕の印象です（笑）」「海外にWebでミュージックをする方たちがいるかなというと、あまりいないかなという気がしています。とはいえ、音楽で盛り上がっているというコミュニティはあるみたいで、その方々はいろいろなことをやっているみたいです。例えばWebGLを使って音楽と組み合わせて作品を作ったり、そういうのをアメリカでよく見かけることがありますね」及川さんが海外で仕事をしていた話「及川さんは海外で勤務された経験もおありなんですよね、いつ頃でしたでしょう？以前働いてらっしゃったのは日本DEC(※)にいらした後、Microsoftで働いていた時に海外にいらしたと…」「そうです、よく知っていますね！」「ネットで調べたら出てきました」「その前に加藤さん声ちっちゃくない？」「すみません、気持ちの萎縮が声に出ていたのでちょっと張ります」「あと、マイクは柄の部分を掴んだ方がいい気がするよ（笑）」「はい、こんな感じでよろしいでしょうか？（笑）」「はい、ぜひ元気よくいきましょう！」「私今から20年ちょっと前にまだMicrosoftが小さかった時ですね。Windowsのエンタープライズ版のWindowsNTっていう今のWindowsなんですけど、それの元のバージョンを作った時に1年くらい派遣されました。シアトルというか、郊外のレドモンドにある今Microsoftの本社があるところに行きました」「その時に、日本から海外に行かれたということで、暮らす環境だったり仕事のやり方だったり、すごく違いを感じたのではないかと想像するのですが、その辺りはどうでしたか？」「そうですね、だいぶ違いましたね。しかも当時ってインターネットまだないんですよ。あるんですけど、Webはまだ作られていない時だったんですね。ちょうど私がレドモンドにいた時に、Webっていうものがあるらしいぞというので、NASAの宇宙の写真とかを最初に見たのを覚えているくらいなんですよね。なかったんですよ」「つまりどういうことかというと、行く前に現地の情報とかそんなに分かんなくて、ニフティサーブという今のニフティの原型があり、そこがアメリカのコンピュサーブっていうパソコン通信にゲートウェイで接続きたので、そっちの方のフォーラムに入ったりしていろんな情報を入手したりしていたんですね。また逆に、アメリカ勤務していても、日本の情報がほとんど入ってこないんですよ」「そうなんですね。「なので、どっちがいいかというと正直分からなくて、昔は昔でそういった現地に行かないと分からないものを、現地に行って分かる面白さとか醍醐味があったんですけれども、不便といえば不便でした」＜参考情報＞日本DEC：日本ディジタルイクイップメント株式会社ニフティサーブ：NIFTY-Serve、のちにNIFTY SERVE、1987年から2006年までニフティ株式会社が運営していたパソコン通信サービス。コンピュサーブ：CompuServe、アメリカのパソコン通信会社。インターネットで知ることと、現地に行って知ることの話「なるほど、それは良し悪しあるんですね。今は狙った検索ワードを入れれば、大抵のものはヒットして分かるという状態になっているじゃないですか。それは日本にいても海外にいても見れるので、ネットで繋がっていれば一緒に仕事もできるし、知らなかった情報もすぐネットでキャッチアップできるような環境に今は変わってきている気がする。なので、海外に行って困るというのは前と比べると少なくて済む状況になってきているのではないかと思うのですが」「そうですね。今僕も向こうにいるわけなんですけど、インターネットから大体情報が入ってきますし、すごく変わったかなと思うのが、テレビもすごく変わったと思うんですよ。家にソニーさんが作っているnasne（ナスネ）™というサーバーを、日本の自宅に置いているんですね。そうすると、海外からも日本のテレビ番組が普通に見れるんですよ」「撮りためておいて、普通にそれが見れるという感じなんですか？」「そうですね。撮りためもできるし、リアルタイムで見ることもできたりするので、アメリカにいるのに日本のテレビ番組を見てたりすることもあったりして、その辺は本当に情報がすごく入って来やすい。自分で取りに行こうと思えばいつでも行けるという状態になっているというのは間違いなくあるという気はするんですけど、1つ僕が結構思うのは、情報ってやっぱり情報なんですよ」「はい」「重要なのって情報の周りにある雰囲気だったり、文化的な背景だったり、そういうところが結構重要だということを僕は思っているんです。情報は入ってきやすくなってきたけど、ディテールのところは現地に行かないと分からないかなという気がしているんですけど、及川さんその辺いかがでしょうか？」「そうなんですよね。英語圏でアメリカにいると、インターネットで得られる情報と、現地で得られる情報っていうのはもちろん差はあるけれど、そんなには多くないんですね」「はい」「ただ他の国に行った時に、我々が現地の言葉を知らなかったりすると、どうしても英語の情報に頼るじゃないですか。もしくは日本語の情報に頼ると。例えばヨーロッパに行った時に現地の人から教えてもらったのは、トリップアドバイザーの情報でいい店だって言われて行くわけですよ。それはアメリカ人のテイストにあってる店がレコメンドされるだけだよってはっきり言われたんですね」「なるほど（笑）」「だから、本当に現地の人が行くところで推奨している店が、そこに引っかかるとは限らないということを言われたから、やっぱりインターネットで得られる情報と現地の本当の情報は必ずしも一致していないことは覚えておいたほうがよくて。ただ、今ちょっとトリップアドバイザー、最近元Googleの僕の友人が日本法人の社長になったんですけど」「そうなんですか（笑）」「まあ、それはいいんですが（笑）」「だけれども、逆に言うとそれはそれで便利なんですよ。なぜかというと、トリップアドバイザーでいいって言われているのは確実に英語が通じたりだとか、アメリカ人と日本人のテイストはだいたいあっているんで、そんなに間違いはない」「ただ、やっぱり今言ったみたいに、本当に現地で価値があるって言われているものが英語で情報として流通しているかどうか分からないところはあったりするんで、やっぱりネットの情報で便利になったと思う反面、ネットだけでいろんなところに行こうとしたら、実は現地でしか味わえない醍醐味だとか、本当に大事なものを見失ってしまう可能性はあるかもしれないなって思いますね」「そういう側面もありますね」「例えば、逆にふっていいですか？　地方に東京から移住した加藤くんに聞きたいんですけれども」「はい」「要は、もう日本語で普通に会津若松の情報って分かるじゃないですか。でも現地に行ってみたら全然違ったっていうようなことって、実際に暮らし始めてみてからあるんですか？」「いくつかやっぱりありますね。そもそもあんまり店がないのかなって思っていたら、みんながWebにあげていないだけで、実際に足を運んでみるとすごく美味しい店が近くにたくさんあったりとか、そういうギャップがあったり。あとは食べログとかを見てお店を選ぶんですけど、評価が普通なお店でも行ってみると店員さんがすごく優しくてフレンドリーで、何回か行ったら一品増やしてくれたりとか、これはちょっと分からないだろうなとは思いました。それは現地に行ってこそ分かるものだなって分かりました」「今は逆に検索すればわかるから、ネットがつながってるから、情報共有も簡単にできるだろうと思い込むのは危険なところはありますよね。その辺は会社によってやり方は違うと思うんですけど。Microsoftなんかはレドモンドに社員を皆さん集結させて、なるべく物理的に近くにいてコミュニケーションロスを減らそうとしているとどこかで見たのですが、そういう会社もあれば、Googleは逆にどこにいても仕事はできるからというかたちで、物理的に散らばって要所要所で集まって意思疎通をしていると聞きました」「そういうスタイルや、会社さんごとにいろいろなやり方でやっていると思うんですが、1つ言えるのは以前よりも単純な情報の共有はすごくやりやすくなったので、海外にいきなり行くとなった時も、以前のような準備がそこまでいらなくなってきているのかなと感じました」＜参考情報＞ナスネ：nasne、地上/BS/110度CSに対応したデジタルチューナーと大容量ハードディスクを搭載したネットワークレコーダー＆メディアストレージ ──後編は「日本と海外の違いの話」「年齢が違う人とのコミュニケーション」などの話を紹介します。（撮影・写真提供：HTML5 Conference 2016撮影スタッフ）モバイルWebのUIを速くする基本テクニックがわかる──Google I/O 2016 High Performance Web UI 川田寛 — Fri, 08 Jul 2016 00:00:28 +0000 こんにちは、ふろしきです！私はHTML5 Experts.jpで、過去2年ほどGoogle I/Oの情報を発信し、Web技術の変化についてお伝えしてきました。振り返るとGoogleは、2014年にモバイルWebの提唱と技術要素の拡大を図り、2015年からは「RAIL（モバイルWebが目指すべきパフォーマンス指標）」や「Progressive Web Apps（アプリのように振る舞うWeb）」といった、モバイルとの親和性が高いWebを作り出すための”考え方”を推し進めました。今年2016年は、さらにそれを踏み込んでいったという感じがします。今回のI/Oで取り上げるのもそのひとつ。毎度お馴染みGoogle Developer AdvocateのPaul Lewis氏による「High performance web user interfaces」です。彼は、モバイルにおいて、時にアプリのように振る舞うことが求められる昨今のWeb、すなわち「Progressive Web Apps」について、UIで起こりがちなパフォーマンス問題と、その改善方法について紹介しています。 ※ この講演、動画無しでは説明が難しかったり、前提知識も多かったりするので、私でかなりアレンジ・要約して紹介しています。より詳細に内容を知りたい場合は、ソースをみることをオススメします！ Webは時として、モバイルアプリのような体験が求められるモバイルにおいて、ホームスクリーンは重要な場所だ。人々はホームスクリーンから、目的を達成するためのアプリを起動する。Webは、Add to Homescreenを使うことで、ホームスクリーンからWebサイトへアクセスすることができるようになった。するとどうなるか。このホームスクリーンをよくみてほしい。どれがWebで、どれがネイティブアプリなのかは見分けがつかないだろう。Google Mapsなんかはネイティブにみえるけれど、他はまったく想像がつかない。しかしこれらが、Google Mapsと同様にネイティブアプリにみえるなら、Webはネイティブアプリのように振る舞うことが求められている。パフォーマンスモデル、インタラクションモデルの2つによって、Webはモバイルネイティブアプリのような振る舞いをえることができる。Progressive Web Appsを実現することができる。今日はこの2つのモデルのうち、パフォーマンスモデルの話をしたい。昨年は、Paul IrishやIlya Grigorikなどの私のチームのメンバーが、「RAIL」というパフォーマンスモデルについて話した。RAILとは、Responseは0.1秒、Animationは16ミリ秒、Idleは50ミリ秒、Loadは1秒で動作すべきというもの。ただ、それを聞いた人々は、たまに勘違いをする。この4つの要素は、どれも全て、最も重要なこととして語ってしまうのだ。それは間違っている。例えば、Webサイトにおいて、タップした時に求められるのは、4つの要素のうちLoadが重要になる。Idleが重要になることはそこまでない。そして、ホームスクリーンからタップして起動されるProgressive Web Appsでは、ResponseやAnimationが重要になる。Webサイトをつくるのと、Progressive Web Appsをつくるのでは、求められることが違う。さて、このようにパフォーマンス面で求められることが異なるProgressive Web Apps。そこに、3つのコンポーネントがある。Side Navigation、Swipeable Cards、Expand an Collapse。これらを実現するセオリーを紹介しよう。 1. Side Navigation まずは、このコンポーネント。メニューボタンをタップすると左からスライドインするバー。これは、2つのElementによって構成される。半透明の黒い背景と、サイドメニューを表示する領域だ。このサイドメニューの部分のCSSは非表示の時、CSSにpointer-events: none;を指定する。そして、表示されたタイミングでpointer-events: auto;を指定する。そしてここからが大事な話。左から右、あるいは右から左に移動させる際に、transformを使う。ブラウザがDOMの位置を変更する際に、CPUを使ったレイアウト変更してはいけない。GPUの力を借りて、描画位置を変更することで、最適なパフォーマンスを得ることができる。例えば、一昔前。サイドメニューが左に消えている時にCSSは .side-nav { position: fixed; left: -102%; /* DOMのレイアウト位置を左にずらしてメニューを隠す */ top: 0; width: 100%; height: 100%; over-flow: hidden; pointer-events: none; } と、left: -102%で隠す。これは一般的な方法だった。しかし、描画を高速に処理できるGPUの恩恵を受けたいなら、transformを使って以下のように記述する。 .side-nav { position: fixed; left: 0; /* DOMのレイアウト位置は常に0のまま */ top: 0; width: 100%; height: 100%; over-flow: hidden; pointer-events: none; transform: translateX(-102%); /* 描画の位置を左にずらすことでメニューを隠す */ will-change: none; /* <- これは何！？ */ } サイドメニューのDOMのレイアウト位置としては、x位置のleftもy位置のtopも、0のまま。横幅widthも縦幅heightも、100%ということで、全面を覆っているという扱いになる。しかし、transform: translateX(-102%);で描画の位置自体を、左に寄せている。そして、ここで登場するのがwill-chanage: none；だ。一昔前にtransform: translateZ(0);をCSSプロパティに指定して、パフォーマンスを改善するというハックが出回ったのをご存知だろうか。このCSSが指定されると、描画には必然的にGPUの力が必要になるため、強制的にGPUに描画を依頼することになる。GPUの恩恵を受けるために活用されたこのバッドノウハウは、will-chanage: transform；という新しいCSSプロパティをWeb標準として追加することによって、同様のことを実現できるようにした。(※注:実態はブラウザ対応の問題もあり、今もtransform: translateZ(0);を使うのが一般的) ただ、transform: translateZ(0);やwill-chanage: transform；といったCSS指定は、常時ビデオカード上のRAMメモリーに描画結果をテクスチャーとして保存することになる。モバイル環境では、バッテリー消費などに悪影響を及ぼすことになる。動作するタイミングだけwill-chanage: transform；を指定し、動作しない時は無効化will-chanage: none；するといい。これが、バッテリー消費パフォーマンスと描画速度パフォーマンスのトレードオフ問題に対する、落とし所だ。黒背景については、will-change: opacity;というプロパティがあり、transformと同様の方法で、高いパフォーマンスで描画させることができる。(※ JSの実装については、「2. Swipeable Cards」にノウハウが似ているので割愛) 2. Swipeable Cards CSSを使ったパフォーマンス改善のテクニックの他に、注意しなくてはいけないのが、スワイプ操作時のコンポーネントの移動処理。ユーザーからの指の位置状況を入力し、それをスクリーン上に反映しなくてはいけない。この際、有用なのが「ゲームループ」のノウハウだ。描画のイベントは常に、1/60秒ごとに発生する。対してスワイプのイベントは、常に一定には発生しない。描画のタイミングにはあわせてくれないのだ。そこで、スワイプにより発生するイベントについては、変数に位置情報だけを記録する。そして、描画時のイベントでは、記録された位置情報を元に、CSSを通じて描画位置変更をおこなう。スワイプの開始時・移動時・終了時は以下の通り。this.startX、this.currentX、this.targetXといった変数に、現在の位置や、移動すべき位置を記録している。 /** * スワイプ開始 */ onStart(evt) { // スワイプの開始位置を記録する this.startX = evt.pageX || evt.touches[0].pageX; this.currentX = this.startX; // cardの移動が開始されたことを記録する this.draggingCard = true; // will-change: transform; を有効にする this.target.style.willChange= ‘transform’; // カード上の要素にイベントを伝播させないように evt.preventDefault(); // アニメーションを開始する requestAnimationFrame(this.update); } /** * スワイプ移動時 */ onMove(evt) { // スワイプの現在地点を記録する this.currentX = evt.pageX || evt.touches[0].pageX; } /** * スワイプ終了時 */ onEnd(evt) { // cardを削除すべきかどうか判定する let translateX = this.currentX - this.startX; const threshold = this.cardWidth * 0.35; if( Math.abs(translateX) > threshold ) { // cardの移動先をスクリーンの外へ(※cardは削除) this.targetX = (translateX > 0) ? this.cardWidth : -this.cardWidth; } else { // cardの移動先を最初の位置へ(※cardは削除されない) this.targetX = 0; } // cardの移動が終了されたことを記録する this.draggingCard = false; } 描画のタイミングにrequestAnimationFrameから呼び出されるコールバックで、先ほどの位置情報を元に反映していく。 /** * 描画内容の変更 */ update(evt) { // 次の描画タイミングでも自身を呼び出す requestAnimationFrame(this.update); // スワイプ中の場合 if( this.draggingCard ) { // 現在の位置を描画させる this.translateX = this.currentX - this.startX; // スワイプが完了している場合 } else { // カードを削除するかしないかに応じて指定の場所に能動的に移動する this.translateX += (this.targetX-this.translateX)/4; } // CSSプロパティを経由してGPUに変更を伝える this.target.style.transform = `translateX(${this.translateX}px)`; } (※ この後の処理については、「3. Expand and Collapse」にノウハウが似ているので割愛。) 3. Expand and Collapse タップすると、領域が広がり全体化されるUIコンポーネント。CSSではどうするのか？もちろん、ここまで説明してきた「transform」を活用する！では、JSについてはどうか？実は、「2. Swipeable Cards」とは異なり、スワイプ操作でなくタップによって、自動的にアニメーションする。この点で、より効率的な実装が求められる。まず、アニメーションについて、動作中の状態はJS上で持たない。動作前後の状態だけを、CSSプロパティを通じてGPUに指示する。 // 変化量を計算する invert.x = first.left - last.left; invert.y = first.top - last.top; invert.sx = first.width / last.width; invert.sy = first.height / last.height; // 変化後の状態をCSSプロパティを通じてGPUに指示 card.style.transformOrigin = ‘0 0’; card.style.transform = `translate(${invert.x}px, ${invert.y}px) scale(${invert.sx}, ${invert.sy})`; そのままでは、タップした要素は一瞬にして全体化されてしまう。どのようにして何ミリ秒もかけて徐々に広げていくか？その方法は、CSSで指定する。JSではない。原理的には、従来よく使われているCSSアニメーションだ。 .cards { transition: transform 0.2s cubic-bezier(0,0,0.3.1); // アニメーションさせる } ここまで、Progressive Web Applsのパフォーマンス改善の話をしてきたが、「Google DevelopersのRendering peformance」が役に参考になる。一読するといいだろう。 Progressive Web Appsのパフォーマンス改善。要はこう言いたかったいかがでしたでしょうか？文字数の制限やコンテキストの高さもあり、多くのエンジニアに伝わるようかなりアレンジしてみましたが、ご理解いただけましたでしょうか？ Paul Lewis氏が言いたかったことは単純な話です。先ほどのGoogle Developersの記事にもありますが、Progressive Web AppsにおけるAnimationやReactionの課題は、いかにしてブラウザのレンダリング処理における「レイアウト」を減らすか、という話です。この講演は、そのTIPS集といえます。今日のノウハウ、特に新しいというわけでもなく2年前には既に実践されていたことです。実際のところ多くの現場では、OnsenUIやIonicのようなUIライブラリを活用することになり、このあたりの話を意識することはないのでしょう。ただ、Webのサービスを作っているフロントエンドエンジニアにとっては、ライブラリの有無に関係なく知っておくべき知識のように思えます。サイドメニューについては、Webサイトであっても鉄板のUIコンポーネントなので、Progressive Web Appsか否かはもはや関係ないノウハウだったに違いありません。 Webがモバイルに順応していくことは、今後もさらに求められていきます。これは、フレームワークやライブラリに限った話ではなく、トータルにみたWeb、フロントエンドへの要求に変化を与えるに違いません。今後も、モバイルとWebの関わりに、目が離せませんね。 Google Assistant、Android N、Daydream、Firebase…Google I/O 基調講演で発表された最新機能を一挙紹介！本間咲来 — Wed, 06 Jul 2016 02:04:12 +0000 2016年5月18～20日の3日間、Googleの本社ビルのすぐそばにあるショアライン・アンフィシアターでGoogle I/O 2016が開催されました。例年5千名程の参加者から大幅に増えて、今年は実に約7千人の人々が参加していたようです。屋外イベント施設ということもあり、まるで野外フェスのような雰囲気でした。本レポートではGoogle I/O最初のセッションである、基調講演の内容について紹介します。 Google Assistant まず最初にスンダー・ピチャイ氏に紹介されたのが、Google Assistantです。 Google Assistantは新しい対話型のボイスアシスタント機能です。Google製のアシスタント機能といえばGoogle Nowがありますが、これを進化させ、対話型のシステムとしたのがGoogle Assistantのようです。コンテキストを認識し、ユーザーが質問すると現在地や直近のクエリーなどに応じて、適切に答えを返します。例えば、有名な建築物の前で「これを設計したのは誰？」と質問すると、その場所の情報に応じて回答してくれます。デモでは、ユーザーが「今夜やってる映画は？」と聞くと、Google Assistantは近くの映画館で上映しているタイトルをいくつか提示し、さらにユーザーが「子どもと一緒に行きたい」と言うと、子どもと一緒に鑑賞するのにふさわしいと思われる映画を提案していました。さらに「4枚チケットが必要ですか？」とGoogle Assistantが尋ねてくるので、ユーザが映画のタイトルや枚数を答えると、自動で予約し、チケットの情報を提示する、というデモが行われました。このように、『提案をしてくれる』というのがGoogle Assistantの大きな特徴です。Google Assistantは基調講演の中で発表されたGoogle HomeやGoogle Alloなどの製品にも組み込まれるようです。 Google Home 続いてGoogle Assistantの機能を組み込んだGoogle Homeという製品が紹介されました。 Google Assistantのボイスアシスタント機能の他にWifiスピーカーとしての機能もあり、クラウドから音楽のストリーミング再生もできるようです。プレイリストやアルバムへのアクセスもボイスコントロールでき、Google Castを通して、AndroidやiOSのデバイスから音楽を送信することもできるとのことでした。 Amazon Echoと似たような製品のようです。大きさは手のひらに乗るくらいの小さなデバイスでした。今年の後半から使えるようになるとのことです。 Google Allo 次にAlloというモバイル用のメッセージングアプリが紹介されました。見た目はLineやFacebook messenger等と大差なく見えます。文字や絵文字の大きさを自由に変えることができることが紹介されました。地味だが良い機能、ということで会場が少し盛り上がります。しかし当然のことながら、ただのメッセージングアプリではありません。このAlloにはGoogle Assistantの機能が組み込まれており、なんとチャットのテキストや画像を解析して、返信用のテキストを複数提案してくれます。例えば「Dinner later?」とチャットの相手が送ると、「I’m in!」「I’m busy」という返信用のメッセージが表示されます。ユーザは選んでクリックするだけでメッセージを送信することができます。またチャット内の画像も解析されるので、誰かが犬の写真をアップロードすると、犬種も識別された上で、「Cude dog!」「Aww!」「Nice bernese mountain dog」といった返信メッセージが提示されます。またGoogle Asisstantのbotががチャットの中に存在するようなかたちになっており、店のお店のサジェストや予約、検索等も対話形式でチャットの中で行うことができるようです。さらにChromeのようにIncognito Modeが搭載されており、エンドツーエンドでの暗号化やNotificationの制御、メッセージの期限などを設定できるようになっているとのことです。 Google Duo 続いてDuoというビデオチャットアプリの紹介です。ビデオチャットを実現するアプリは数多く世に出ていますが、このDuoにはビデオコールをかけられた側は、応答する前にそのビデオストリームを見ることができるという特徴があるようです。この機能は『Knock Knock』と呼ばれているそうで、これにより着呼側は誰が、どんな状況でコールしてきたのかを知ることができます。コール先は電話番号に紐づくとのことで、AppleのFaceTimeの競合として考えられそうです。 DuoはWebRTCとQUICを使用したWebプロトコルベースのアプリと紹介されました。 AlloとDuoはAndroidとiOSで2016年夏頃リリースされる予定で、Android版では事前登録が開始されています。 Google Allo Google Duo Android N 続いてAndroid Nについての発表が行われました。 GoogleがAndroidの開発を行うようになってから、10年が経過したようです。今やAndroidはスマートフォンだけではなく、Android Wear、Android TV、Android Autoなど、多くのプラットフォームが登場しています。 Androidの最新バージョンであるAndroid Nは現在プレビュー版(6/28現在Developer Preview 4)が公開中です。こちらで名前の募集も行われていましたが、現在は終了し近日中に公開されるようです。 Android Nでは、新しいOSのアップデートがあると、自動的にソフトウェアをバッググラウンドでダウンロードし、次回Androidの電源を入れた際にシームレスで新しいソフトウェアイメージに切り替わるようです。またマルチウィンドウが正式に採用され、スマートフォンでYoutubeを見ながら他のタスクを行ったり、Android TVでは映像を見ながら検索などの他の作業を行うことができるようになります。現在はAndroid NのDeveloper Preview 4がリリースされており、Nexus 6やNexus 5X等の一部の対応した機種であれば、Android Nを試用することができます。(Android Developers Blog) Daydream 続いてI/O開催前から噂が絶えなかったVRに関する発表です。 Androidスマートフォンで高品質なVR体験を提供可能であるDaydreamというプラットフォームが発表されました。どのようにAndroidスマートフォン上で、高品質なVR体験を可能にするのか、講演では3つの要素が挙げられていました。まずはスマートフォン本体、次にヘッドセットコントローラのリファレンスデザイン、そしてアプリで、ぞれぞれが協調してエンドツーエンドのユーザ体験を提供するために設計されています。ハイパフォーマンスセンサーやヘッドトラッキング、表示のレスポンスの速さなど、VR用に作られた仕様を満たしたスマートフォンは、Daydream-readyと呼ばれ、高いクオリティのVR体験を提供することができます。Daydream-readyなスマートフォンは、SamsungやAlcatel、Asusなどの企業から、2016年秋以降リリースされるようです。発表された中に日本の企業はありませんでした。リファレンスデザインとして紹介されたヘッドセットとコントローラは非常にシンプルなものでした。コントローラはボタンは少なくクリッカブルなタッチパッドがついており、スクロールやスワイプができます。オリエンテーションセンサーも内蔵しており、ユーザがどこをポインティングしているかが分かります。アプリに関しては、VR用のGoogle Playが開発されており、ユーザーがアプリを探し、購入、インストールがVR上で可能になることが発表されました。またGoogle Play MoviesやGoogle Mapsのストリートビュー、Google Photos、YouTubeもVR上で鑑賞できるようになります。 Daydreamが使えるようになるのは2016年秋になるとのことですが、Android NのDeveloper Previewを使用することでアプリなどの開発は今から行うことができます。 Android Wear 2.0 Android Wearは2年前のGoogle I/Oで初めて発表されましたが、今回は初めて大幅なアップデートとなるAndroid Wear 2.0が発表されました。大きな変化としては、今までAndroid Wearのアプリがインターネットにアクセスするためには母艦となるAndroidやiOSスマートフォンが必要であったことに対し、Android Wear 2.0ではスタンドアロンで動作することが可能になることが挙げられます。アプリが直接BluetoothやWi-Fi、LTEなどを通してインターネットにアクセスできるようになり、ペアリングされたスマートフォンが電源を切っている場合でも、アプリは引き続きフル機能を提供できるようになります。その他にもUIの刷新や、手書き入力の対応等も発表されました。 Android Wear 2.0はプレビュー版が公開されおり、秋には正式リリースとなるようです。 Progressive Web AppsとAccelerated Mobile Pages 基調講演も終盤に差しかかり、ここで初めて、わずかですがWebについての発表がありました。モバイルデバイス上でWebをより快適にするための取り組みとして、Progressive Web AppsとAccelerated Mobile Pagesの2つの紹介です。 Progressive Web Apps、略してPWAppsは、オフライン状態でも動作可能、エンゲージメントを高めるための通知、ホームスクリーンにアイコンを登録、といったネイティブアプリのような振る舞いを実現したWebアプリのことを指します。ChromeにはServiceWorkerをはじめとする、Progressive Web Appsを実現するための仕組みが実装されています。 Accelerated Mobile Pagesは、既存のWeb標準に基づいた非常に速いモバイルWebサイトを作るための、オープンソースのプロジェクトです。特に新規発表はなく、基調講演内ではわずか1分程度の紹介でしたが、Google I/O全体では多くのPWAppsやAMPのセッションが行われていました。HTML5 Experts.jpでもGoogleが新たに提唱するProgressive Web Appsの新たな開発パターン「PRPL」とは？という記事を公開していますので、そちらをご覧ください。 Android Studio Android Studio 2.2 Previewが公開されたと発表がありました。 Android Studio 2.2では、ビルドが10倍、エミュレータも3倍速くなっているそうです。また、新しいレイアウトデザイナやAPKアナライザーが搭載されるとのことでした。 Firebase 続いてFirebaseの新バージョンが発表されました。 FirebaseはGoogleが2014年の10月に買収したBaaSサービスです。モバイルアプリに特化した分析ツールである、Firebase Analyticsが発表されました。ユーザがアプリ内で何をしているか、ユーザがどこからきたのかなど分析することが可能です。Android AnalyticsはAndroidでもiOSも扱うことができ、無制限に無料で使用することができると発表されました。 Android Instant Apps 今回の基調講演の後半で一際注目を集めたのがこのAndroid Instant Appsではないでしょうか。 Webアプリの場合、ユーザはリンクをクリックするだけでアプリを使用することができますが、Androidアプリはインストールを必要とするため、ユーザがそこで離脱してしまうことが多くあります。その課題を解決する一手となるのが今回発表されたAndroid Instant Appsのようです。今回発表されたAndroid Instant Appsでは、AndroidアプリがWeb等のリンクからインストールレスで使えるようなるとのことです。講演中のデモの中では、いくつかのAndroidアプリをURLから起動し、実際にアプリを使用できることが示されていました。アプリの中の直近で必要になるモジュールだけをフェッチしているらしく、起動も素早く行われ、アプリを使用してからのインストールも非常にスムーズに行えるようです。これにより、Androidアプリ開発者は、より多くのユーザにリーチできるようになります。AndroidアプリとWebとの親和性が高くなり、Androidアプリのユーザ体験が大きく変わる機能となるのではないでしょうか。おわりに今年はGoogleのAIの技術力を発揮した製品やサービスが多く発表されました。基調講演内でWebやChromeに関する発表は非常に少なかったのですが、Google I/O全体では33ものモバイルWebに関するセッションが行われていました。既に公開されている今、Webの最先端では何が起こっているのか？──最新機能目白押し！Google I/O 2016セッションレポート【前編】 Webの最先端では何が起こっているか、今Googleが取り組んでいることは？──Google I/O 2016セッションレポート【後編】 Googleが新たに提唱するProgressive Web Appsの新たな開発パターン「PRPL」とは？以外にもセッションレポートを公開していく予定です。お楽しみに。 Webの最先端では何が起こっているか、今Googleが取り組んでいることは？──Google I/O 2016セッションレポート【後編】河合良哉 — Wed, 15 Jun 2016 00:00:15 +0000 Google I/O 2016のセッション「What’s new for the web?」についてのレポート後編です。（前編はこちら）前編では、既に導入済みの機能、API、またこれから導入される機能が怒涛のごとく紹介してきました。後編では、Web Platformをより先に進めるためにGoogleが取り組んでいること、そしてWeb BluetoothやPhysical Webについて解説していきます。 Google loves the web ChromeチームWeb Platformをより先に進めるために、ここ1～2年取り組んでいるアプローチの紹介です。まず、前提としてGoogleはWebが大好きです。Googleの同僚は皆、Webが大好きです。そしてChrome Teamには「Webをより先に進める」という重要なMissonがあります。ここで私がWebと言っているのはChrome Webということではなく、全てのWebのことを指していて、それら全てのWebが素晴らしくなってほしいと思っています。よって、Interoperability（相互運用性）を保ちモダンブラウザの全てにShipされるまでが我々の使命です。なぜならInteroperabilityが保たれずShipしてしまったら、誰でも・いつでも・どこでも利用できるというWebの最も大きく重要な利点の1つが失われてしまうからです。Vender Prefixを廃止したのもそういった理由です。 Chromeにおいては、Web Platformをより先に進めるために4つのアプローチをを持ち取り組んでいます。 Chromeチームが取り組んできたこと複数のチャネルを持つ（Stable, Dev, Canary、Beta）実験的な機能にはExperimental flagを設けONにしないと動かなくしている(chrome://flags のことでWeb Bluetoothもこの1つ) Original Trials：実装したAPIをそのままExperimental flagとして提供してしまうと、いつの間にかデファクトになってしまう可能性があります。APIの仕様・実装を吟味してからShipすることがよりよいWebを作るのには必要不可欠です。よって、Feedbackをすることに同意したDeveloperのみ利用を可能にすることで、利用するユーザー数を絞り、さらに期間を区切ることでデファクトすることを防ぎ、実験のIterationのスピードを上げることを目的としています。さらに多くのDeveloperが使い始めた場合は自動的に利用を停止する機能も入っています。 Incubation of substantial new feature(wicg.io)：Web Incubator Community GroupをW3Cでにて行っています。標準化のProposalの議論をライトウェイトに行うグループです。チャーター（W3Cで議論を進める場合には必ず作成します）を作ったりすることに全ての時間は費やさないものの、正しく管理されるし、Contributionも受け付けることが可能です。もし新しい機能を提案したい場合は是非このグループに提案してください。しかし、機能を追加するだけではWeb Platformを健康に保つことはできません。よって、機能の削除も行います。削除の理由には、他のAPIとの入替えや、実験的に作ったが上手くいかなかった、というものがあったりします。3つ前までで削除された機能のリストがこちら(goo.gl/5gq1Im)です。今後、requestAutoCompleteだったり、HTML5 App Cacheのような影響の大きな機能も削除しようとしています。まだ使われている機能、APIをいきなり削除しないというようなポリシーもありますので安心してください。これまでの成功の紹介それでは、ここ数年での成功を紹介します。私がここに立っている、ということは何のことだか分かる方も多いかも知れませんが、そうですWeb MIDIです。 MIDIは知ってる方もそうでない方もいると思います。仕様ができてから30年以上にもなる楽器のキーボード、シンセサイザー等、電子楽器同士、またはコンピュータとを接続する標準化されたプロトコルです。数年前Web Audioで遊んでいたときに「これを楽器のキーボードから操作したい」と思い立ったW3Cにて標準化を始め、Chromeでは去年Shipされました。 ChromeでのShip以降、多くの楽器メーカがユーザー体験を提供するプラットフォームとしてWebを使い始めました。Yamahaはrefaceという新しいシンセサイザーのラインナップに対してSoundmondoという音色のエディタ、ライブラリアンを提供するWeb MIDIを使ったサービスを展開しています。NovationのCircuit Groove BoxはWebに接続して新しいサンプルをダウンロードします。これらの作業においてソフトウェアを新たにインストール必要はないのです。そして、間違いなくスゴイことはフランスのEDMアーティストであるMadeonがWeb Audioで作られたRemixBoardをWebサイトで公開したことです。ファンに向けられて作られたサイトで、彼のアルバムの中の音をRemixして遊ぶことができるのです。もちろんMIDIデバイスも接続してプレイすることができるようになっているのです。（デモ（パフォーマンス？）が始まります。実際の動画を御覧ください）何が起きたかはここまたは画像をクリックして動画を御覧ください！デモアプリのURLはこちらwww.madeon.fr/adventuremachineです。「これスゴイでしょ？！」と言いたいのですが、本質はそこではなくて「ハードウェアがブラウザにアクセスできる」ということが大きな可能性を生んだ、ということを伝えたいのです。ちょうど加速度センサから素晴らしいユーザー体験（UX）が生まれ、モバイル・デバイスが大きな可能性を持ったのと同じようにです。他にも接続できることで大きな可能性が生まれるデバイスはたくさんあると思います。我々は、そこにある可能性を積極的に解き放っていきたいと考えています。（ここでChris氏からFrançois氏に交代）これから何が起こるのか Web Bluetooth Bluetoothの名称の由来の説明から始まります。（詳しくはWikipediaのBluetooth 「名称の由来」をどうぞ） Bluetoothはいろいろなバージョンで20年成長してきた技術で、最新はBluetooth Low Energy（BLE）が導入されたVersion 4でリリースされてから6年経過しています。Wi-Fi、Ethernetのスピードは継続的に上がっていますが、Bluetoothはちょっと様子が違っています。なぜなら、今まで接続されていなかった多くのデバイスに搭載できるようにバッテリの消費量を最小限にできるようにデザインされているからです。例えば小型のデバイスが使うバッテリは、通常CR2032です。（2032の20は直径、32は厚さを表すそうです！）なので、転送速度はとっても遅いのです。ですが、BLEはそもそも転送速度が遅くても大丈夫なデバイスをターゲットにしているので問題はありません。それでは、デモをしてみます。デモはPlaybulb Candleという電球のOn/Off、色をBluetooth通信にて変更できるデバイスをWebアプリから操作します。（映像には全体が映っていませんでしたが、会場ではこんな感じでデモが行われていました） Bluetooth SIG(Bluetoothの規格の策定、技術利用に対する認証を行う団体)は、これから先2年で96%の電話、タブレットにBLEが搭載されると予想している。そこからも、いろいろな場所でBLEが存在するであろうことがお分かりになると思います。 Web BluetoothのAPIを説明する前に、一度BLEの動作を復習してみます。Bletoothには、以下の2つの機能があります。 Central：近隣のデバイスを探索する（電話、ラップトップPCの等） Peripheral：周囲に向けて継続的に自らの情報を格納したアドバタイジング・パケットをBroadcastする。（心拍センサ、ビーコン、冷蔵庫等） PeripheralがCentralに接続（ペアリング）されると、Peripheralはアドバタイジング・パケットのBroadcastを停止し、CentralがPeriferalで動作するGATTサーバと通信を開始する。通信に関しては、デフォルトで用意されているバッテリ、心拍のようなサービスも存在していますが、もちろん独自にサービスを作ることも可能になっています。それぞれのサービスにはそれぞれのCharastristicに属性を持っていて、読込み（バッテリーレベルの取得等）、書込み（設定の変更等）、また更新時に通知（心拍数のリアルタイム監視）してもらうことも可能です。Web Bluetooth APIを使って書いたサンプルを説明していきます。値の読込みコードはラップトップがCentral、何かしらのデバイスがPeripheralとなっていることを想定しています。まず、Centralのラップトップがnavigator.bluetooth.requestDevice(option)をCallして近隣のデバイスを探索します。optionにデバイスが山ほど列挙されないためにどの種類でフィルタするかを記述します。コードではバッテリのサービスは標準化されているので「batttery_service」と文字列で指定していますが、アドバタイジングパケットにはカスタマイズした値も書込むことが可能です。 navigator.bluetooth.requestDevice(option)をCallすることで探索が開始され、それと同時にアドレスバーの直下に該当するデバイスを列挙するポップアップが出てきます。ユーザがリストからデバイスを選択すると、JavaScript側ではそのデバイスのデバイス名、利用可能なサービスが格納されているオブジェクトにアクセスが可能になります。ここでセキュリティに関する注意点。 navigator.bluetooth.requestDevice(option)はユーザのインタラクションにて初めて動作します。デモではボタンクリックで開始していました。Localhost以外のホストでWeb Bluetoothを使う場合は、HTTPSでコンテンツがServeされたことを要求している。 device.get.connect()をCallしてGATTサーバと接続をします。その後に、server.getPrimaryService(‘battery_service’)でバッテリサービスを取得、service.getCharacteristic(‘battery_level’)で読込みたいCharacteristicを指定して取得、最後にcharacteristic.getValue()をCallすることで、バッテリのレベルの読込み（取得）をすることができます。値の書込み先ほどとは違い、心拍センサをPeripheralとしています。その他、ハイライトされた部分が違います。charctristic.writeValue()にUint8Arrayにて、1バイトを引数に渡すことで書込みを行っています。更新の受取りこの例でも、心拍センサをPeripheralとしています。この例でも、ハイライトされた部分が違います。characteristicにcharacteristicvaluechangedのイベント名でEventハンドラを設定し、beepという関数をCallbackとして指定しています。characteristic.startNotifications()で、更新の受け取りを開始します。これで、更新がある度にbeepが実行されます。続いて、心拍センサを動作させるデモです。私（François氏）は心拍センサをつけています。リアルタイムに値を受け取ることができますので、ちょっと見てみましょう。通常私の心拍数は60-80ですが、今はどうでしょう？（普段の倍近くの心拍数が表示されChris氏も会場も爆笑）次に実際にリアルタイムに心拍数を受け取っていることを証明するために腕立て伏せをしてみます。（前編の最後に掲載さいた画像はここでの1シーンです）（が、ペアリングが切断されたのか動作せず……そして、今度はChris氏も会場も大爆笑！失敗するということは、デモがリアルタイムに行われている証拠です！）私以外にも、Web Bluetoothで遊んでいる同僚たちもいます。 Web Bluetoothでラジコンカーをコントロール Web Bluetoothでプリンタをコントロール Web BluetoothでBB-8をコントロール Web BluetoothでLEDをコントロール Web Bluetoothで空飛ぶ猫をコントロール Bluetoothのパケット通信の中身を見るときはAndroidを使うのが最も簡単な方法です。AndroidのDeveloper Optionにある「Bluetooth HCI snoop log」を有効にしてください。（詳しくはこの辺りを参照してみてください）現在Web BluetoothをサポートしているブラウザはOperaとChromeOS、マシュマロ上で動作しているChrome for Android、Chrome for LinuxでChromeでは chrome://flags/#enable-web-bluetooth （アドレスバーにコピー＆ペーストしてください）を有効にすることで利用することが可能です。Mac、WindowsのChromeへは現在実装中です。開発の助けになるであろう以下の2つを紹介します。 Get Start with Web Bluetooth (goo.gl/MLKzj2)：コードジェネレータ Web Bluetooth Developer Studio Plugin (goo.gl/c2ype5)：Bluetooth SIGが提供しているBluetooth Developer Studio向けのPlug-in WebアプリからでもNativeアプリと同じように、Bluetoothでデバイスを操作できるようになりました。また、Webアプリですので、URLをシェアすることで、誰でもスグにアプリを利用できるようになります。当たり前のことかもしれませんが、これがWeb Platformの大きな強みです。 Physical Webとの連携 URLを載せたBluetoothのパケットをビーコンからブロードキャストするPhysical Webですが、これがもしBluetoothのアプリからブロードキャストできたらどうでしょう？ URLをPhysical Web経由で受け取り、そのURLにアクセスするとBluetoothデバイスをコントロールするアプリが表示され、Bluetoothデバイスとのペアリングが完了したら、その直後からBluetoothの利用が可能になりますよね。今までのアプリを検索してインストールする等の作業が一切必要がなくなり、通知エリア(Notification Area)に通知されたURLにアクセスするだけでペアリングも含め、Bluetoothデバイスを利用する準備が整うことになります。今後、Web BluetoothはPhysical Webの機能を組み込み、前述の動作を一気通貫でJavaScriptで実装できるような機能を追加する予定です。 CodelabもControl a PLAYBULB candle with Web BluetoothとInteractive with Bluetooth devices on the web with Polymerもありますので、是非挑戦してみてください。（再びChris氏） Web USB Web USBは現存する全てのUSBデバイスに接続しようと考えているわけではなくて、Firmwareへのアクセスを許可されているような新しい種類のデバイスに適用されます。まとめここではカバーしきれなかった、まだまだ多くの以下の様な機能が進行中です。さらに、まだデザインも始めていないPersistent Storageとか、Web Intents v2もあります。そろそろ時間です。我々がWeb Platformの未来にワクワクしているのと同じくらいに、皆さんもワクワクしていることを期待しています。 developers.google.com/web/updates/ にさらなる情報がありますので、お時間がありましたらご覧ください。（というところで、セッションは終了しました）セッション終了後の素敵な笑みを浮かべるChris氏とガッツポーズのFrançois氏ありがとうございました＆お疲れ様でしたっ！！！