こんにちは、編集長の白石です。

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

今回お話を伺ったのは、Googleのえーじさんです。

えーじさんのセッションは「ウェブのための次世代決済法」でした。

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

Web Paymentsは（モバイル）Webの決済体験を変える

白石: 本日は、Web Paymentsについてお聞かせください。 Web Paymentsというのは、その名の通りWeb上での支払い体験を改善するものだと思いますが、そもそもなぜWeb Paymentsが重要なのでしょうか？

えーじ: それについては面白いデータがあります。

モバイルデバイス上で買い物が行われるのはもう一般的ですが、その3分の2はアプリじゃなくて（モバイル）Webサイトで行われているんですよ。

白石: へえ！スマートフォンだと、Webよりもアプリのほうが長い時間使われていそうですが、意外です。

えーじ: それだけじゃありません。今度はデスクトップWebとモバイルWebで支払いのコンバージョン率を比較すると、デスクトップのほうが2倍も高いんです。

これはつまり、モバイルWebサイトにユーザーはたくさんアクセスしているけど、買い物はデスクトップのほうがしやすいということです。

白石: 逆に言えば、モバイルWebサイトだと決済がしにくいってことですね。

えーじ: そうです。Amazonとか日頃から自分が使っているサイトであれば、クレジットカードの決済情報をあらかじめサービスが記憶しているので、決済はしやすい。

しかし、初めて訪れるサイトで買い物するとなると大変です。 クレジットカード番号や期限、3桁のセキュリティコードまで入力しなくてはならない。さらに、配送が必要な商品となると住所まで入力する必要が出てくる。

これだとめんどくさくて、途中で諦めてしまいますよね。個人的にも、モバイルで見つけた商品はとりあえずブックマークしておいて、デスクトップで決済するようなこともよくあります。

白石: 確かに。ではWeb Paymentsは、そういう決済に関する体験を改善するものだということですね。

えーじ: とりあえずはそうです。ただ、Web Paymentsが目指す世界はさらに先なんですよ。

クレジットカードは近い将来使われなくなるかもしれない

白石: というのは？

えーじ: そもそも、クレジットカードっていうシステムそのものが非常に脆弱なんですよね。プラスチックのカードそのものに、すべての情報が記載されているわけですよ。情報を盗むのも簡単だし、紛失したらおおごとです。

白石: 確かに…。

えーじ: そこで最近は、Apple PayやAndroid Payなど、スマートフォンにクレジットカード情報を搭載しようという動きが出てきました。

スマートフォンの端末には、指紋認証や顔認証を含めた認証機能があり、情報は端末内で安全に格納されるので、コピーができません。決済を行うには、端末が物理的に手元にある必要がある。しかも保存される番号も、クレジットカード番号そのものではなく、トークンと呼ばれる仮の番号です。仮に盗まれたとしてもリモートで無効化できるし、再発行の必要もないわけです。

このように、クレジットカードに比べてメリットが非常に大きいんです。近い将来物理的なクレジットカードは使われなくなると予想している人もいます。

白石: なるほど、ぼくはまだApple Payなどを使ったことがないんですが、そんなにメリットのある仕組みだったんですね。知りませんでした。

えーじ: 決済方法の進化は、これだけにとどまりません。仮想通貨や銀行間送金など、新しい支払い方法も次々に登場していて、「お金を右から左に移動する」ような取引のすべてで革新が起きようとしています。

Web Paymentsはこうした状況において、様々なプレイヤーをつなぐ「接着剤」のような働きになりつつある仕様なんです。

言ってみれば、新しいペイメントエコシステムを構築する上で欠かせないピースになると考えています。

白石: 現在の決済システムが抱える問題点を解決しようとする、壮大な話なわけですね。聞いていてワクワクします。

えーじ: なので、Web Paymentsはすごくたくさんの仕様から成り立っています。そのうち、現在でも実装が広く進んでいて、Web技術者が簡単に試せるのはPayment Request APIです。

Payment Request APIとは

白石: Payment Request APIとはなんですか？

えーじ: これが、最初に申し上げたWeb上の決済を手軽に行えるようにする仕組みです。

単純に言えば、クレジットカードや住所など、決済に必要な情報の入力をユーザーが簡単に行えるようになります。決済情報はブラウザが記憶してくれていて、ユーザーは事前に入力してある値から選ぶだけで、Webサイトに情報を渡すことができます。

基本的なコードは簡単で、以下のようにPaymentRequestのインスタンスを作ってshow()メソッドを呼び出すだけで、支払い情報を選択できるUIをブラウザが表示します。

var request = new PaymentRequest(methods, details, options);

request.show().then(response => {
  // 支払い処理を行う
  // PSP（決済代行業者）に送るなどして決済を完了
  response.complete('success');
});

ここで、ダイアログの中ほどに「Android Pay」や「Visa」など、支払い方法を選択できる項目があります。これは、PaymentRequestのコンストラクタの第一引数として、支払方法の情報を渡すことで指定できます。

また、ダイアログに表示される情報は、PaymentRequestのコンストラクタの第二引数で指定することができます。購入商品の情報を渡すだけでなく、配送オプションを指定することも可能です。

コンストラクタの最後の引数は支払いに関するオプションです。配送先住所を必要とするかや名前、メールアドレス、電話番号の情報を要求するかどうかなどを指定できます。

これらを指定して表示されたダイアログ上でユーザーが入力を終えると、プログラムにユーザーが入力した情報が渡ってきます。 プログラムはこれらの情報をサーバーに送信するなどして、決済を完了するわけですね。

白石: なるほど、Payment Request APIそのものは、使うのは全然難しくなさそうですね。先ほど、実装が進んでいると仰ってましたが、現在どのブラウザで利用できるんでしょうか？

えーじ: Chromeは、iOSを含む全プラットフォームで利用できます。他にもChromiumをベースに開発されているSamsung Internet BrowserやMicrosoft Edgeでも利用できます。Firefoxでは開発中ですね。あと、Safari上ではApple Pay JSという、Apple Payを利用するためのAPIが存在するのですが、それをPayment Request APIでラップしたライブラリも存在します。嬉しいニュースとしては、Safariも現在Payment Request APIを実装中ということです。

白石: おお、もうかなりのブラウザ上で動作するんですね。

えーじ: あと、Payment Request APIがどういう動作をするかを試してみたかったら、polykart.storeというデモサイトがあるのでアクセスしてみてください。商品を選んで「BUY NOW」を選択すれば、Payment Request APIを使用した支払い用ダイアログが表示されます。もちろん、実際に決済が行われるわけではありませんのでご安心ください。

Web Paymentsが目指す世界——新しいペイメントエコシステム

白石: しかし先ほどのコードでちょっと気になったのは、結局クレジットカード番号とかをプログラムが直接受け取るという点です。 セキュリティコードも含め、決済に必要な情報を全部Webサイトに渡してしまうのは何か怖いというか。まあ、現在でも一般的に行われていることではあるんですが。

えーじ: PaymentRequestに渡すペイメントメソッドに’basic-card’を指定した場合、クレジットカードの情報を生で受け取るように動作するんですよね。

‘basic-card’の仕組みはわかりやすく、どんな決済代行業者でも扱えるという点ではいいのですが、おっしゃるとおりセキュリティ面での懸念があります。ペイメントの未来はそこにはありません。

そこで登場するのが、生のクレジットカード情報ではなく、使い捨てのトークンを利用するという方法、つまり先程お話したApple PayやAndroid Payで利用できるトークンのことです。こちらの方法なら安全性も高まりますし、ECサイト側も、クレジットカード情報に触れる必要がないので助かるんです（※）。

※ ECサイト側も助かる…経済産業省が取りまとめたクレジットカード取引におけるセキュリティ対策の強化に向けた実行計画2017により、ECサイトはクレジットカード情報の非保持化、もしくはカード情報を扱う場合はPCI DSS（※）に対応しなくてはならない。

※ PCI DSS（Payment Card Industry Data Security Standard）…カード会員情報の保護を目的として、国際ペイメントブランド5社（アメリカンエキスプレス、Discover、JCB、マスターカード、VISA）が共同で策定したカード情報セキュリティの国際統一基準

白石: これは素晴らしい。ぼくらWeb技術者がこの仕組みを利用するとしたら、どうしたらいいんですか？

えーじ: PaymentRequestに渡すペイメントメソッドには、URLを渡すというもう一つの方法があるんです。こちらの方法を用いると、支払いを行うにあたって、外部のペイメントアプリケーションを呼び出すことができます。

白石: 先ほどのコード例でも、https://android.com/payというURLを渡して、Android Payが表示されていましたね。

えーじ: こちらの方法を用いると、トークン化の処理を含め、複雑な処理は全て裏で行われ、Webアプリは戻ってきたトークンを使って決済処理を完了させるだけで済みます。

白石: セッションスライドの、ペイメントアプリを通じてトークンをやり取りする図を見て、複雑なので怖気づいてたところでした(笑)。

えーじ: この図の、企業間の提携などについては企業間で行われることですし、Web技術者の手をわずらわせることはありませんのでご安心ください。

ちなみに、ペイメントアプリケーションは技術的には誰でも作ることができます。なので、クレジットカードに限らない支払い方法、例えば仮想通貨やキャリア決済なども将来的にはPayment Request APIから扱えるようになるというわけです。

ペイメントアプリケーションを指定するのには、先ほども申し上げたようにURLを使用するので、基本的にはWebアプリです。ですが、Web Manifestの仕組みに対応していれば、ネイティブのAndroidアプリを呼び出すことも可能です。

BobPayという、ネイティブ、Webどちらにも対応したペイメントアプリのサンプルがありますので、よければ試してみてください。Web版はAndroid版Chrome Dev、ネイティブ版はChrome 60以降がインストールされたAndroidであれば試すことができます。

白石: 支払い方法はよりセキュアに、多様化するということですね。そのために、業界全体が変化しようとしている。まさに新しいペイメントエコシステムですね。

本日は、大変勉強になるお話をありがとうございました！

こんにちは、編集長の白石です。

この記事は、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要素は使用できず、すべて<amp-img>や<amp-video>と言ったカスタムタグに置き換える必要があります。こうした要素を使うことで、全ての画像や動画が遅延表示され、また、画面に表示されない間はダウンロードされなくなります。

CSSは外部CSSもstyle属性も使用することができません。全てHTML内に<style>を用いてインラインで記述しなくてはなりませんし、そのサイズも50kbに制限されています。

JavaScriptに至っては、独自のコードを記述することはできません。AMPページでは、動的な振る舞いはすべてカスタムタグを使用して実現することになります。

<!-- AMPページの例 -->
<!doctype html>
<!-- html要素に⚡を付けるとAMP HTMLとして扱われる -->
<html ⚡>
  <head>
    <meta charset="utf-8">
    <!-- AMP用JSの読み込み -->
    <script async src="https://cdn.ampproject.org/v0.js"></script>
    <title>Hello AMP world</title>
    <!--
      このAMPページの元となる、通常のHTMLページがある場合はcanonicalで指定
      そういうページがない場合はこのページ自体のURLをcanonicalで指定
    -->
    <link rel="canonical" href="hello-world.html">
    <!-- viewport指定は必須 -->
    <meta name="viewport" content="width=device-width,minimum-scale=1,initial-scale=1">
    <!-- 以下のCSSは必須 -->
    <style amp-boilerplate>body{-webkit-animation:-amp-start 8s steps(1,end) 0s 1 normal both;-moz-animation:-amp-start 8s steps(1,end) 0s 1 normal both;-ms-animation:-amp-start 8s steps(1,end) 0s 1 normal both;animation:-amp-start 8s steps(1,end) 0s 1 normal both}@-webkit-keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}@-moz-keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}@-ms-keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}@-o-keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}@keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}</style><noscript><style amp-boilerplate>body{-webkit-animation:none;-moz-animation:none;-ms-animation:none;animation:none}</style></noscript>
  </head>
  <body>
    <h1>Hello AMP World!</h1>
    <!-- imgの代わりにamp-imgを使用 -->
    <amp-img src=sample.jpg width=300 height=300></amp-img>
  </body>
</html>

白石: カスタムタグにはどのようなものがあるんでしょう？

山口: 利用できるタグはすべてドキュメントに記載されていますので、そちらをご覧いただくのが一番です（参考: AMPで利用できるコンポーネント/タグ）。

AMPのタグにはビルトイン（組み込み）とエクステンション（拡張）がありまして、エクステンションのタグを利用するには別途JavaScriptの読み込みが必要です。

ビルトインのタグの代表的なものは、先ほど取り上げた、<img>の代わりとなる<amp-img>です。エクステンションは現時点でもかなりの数が用意されていて、Google Analyticsを使用したり、YouTubeやTwitterの埋め込みを行えるタグもあります。

白石: そうしたエクステンションは、サードパーティの開発者やベンダーでも開発できるんですか？

山口: はい、可能です。ただ、AMPで利用できるタグは、AMP本体のリポジトリに取り込まれているものだけなんです。なので、開発したとしてもそれをリポジトリに取り込んでもらう努力が必要になります（参考: コンポーネントの開発・拡張についてのドキュメント）。

白石: なるほど、そういうプロセスを経なければならないようにすることで、カスタムタグのクオリティを担保しているということですね。そういうレビューはGoogleが行っているんでしょうか？

山口: AMP自体はオープンソースですし、Google一社のものではありません。リリース前からTwitterやPinterestもコミットしていましたし、オープンソースにしたおかげで、プロセスも透過的です。Google以外のコントリビューターも数多くいますし、そこは一般的な企業発のオープンソースプロダクトとあまり変わりはないと思いますね。

AMPページのアクセス解析は？広告は？

白石: AMPはWeb全体に大きな影響を与えている技術だと思いますので、ビジネス面も含めた、もう少し俯瞰的な部分からもお話をお聞きしたいと思います。

まず、AMPに対応すると、Google Analyticsなどの計測を正しく行えなくなるというのを聞いたことがあるのですが、これはどういうことですか？

山口: まず、<amp-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ページを起点にして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を支える技術も、最新技術の塊ですね。本日は大変勉強になりました、ありがとうございました！

白石: 今日は取材お受けいただきありがとうございます。簡単に自己紹介からお願いします。

芦村: W3C/Keioで働いている芦村です。Webの標準化を仕事にしていまして、アクセシビリティやコンピューターを使いやすくすることに興味を持って取り組んでいます。

白石: W3Cの方に直接お話を伺う機会なんてそうはないので楽しみにしてきました。芦村さんから見て、今のWebの現状はいかがですか？

芦村: HTML5のムーブメントを経て、アプリケーションやシステム構築のための共通プラットフォームになってきました。 WebDINO Japan（元Mozilla Japan）の浅井智也さんが作った「Web曼荼羅」という図ですが、凄まじい数の仕様が、様々な団体をまたがって策定されているのがおわかりかと思います。

とはいえ、まだまだ道半ばではあります。プラットフォームであるからには、便利で安定していなくてはなりません。 そのためにはプラットフォームとしての機能をより高めていくだけでなく、既存の仕様に対するテストももっと充実させていかなくてはなりません。

白石: まだ成長中のプラットフォームであると。

芦村: はい、そして更に、人にフォーカスしなくてはなりません。

開発者にとって、開発が楽なプラットフォームかどうか？Google ChromeやFirefoxには開発者ツールが付属していますが、ああいったツールを含め、開発全体の環境を良くしていく必要があります。

また、開発者の教育も重要です。特に若い人に対して、Webの知識を広めていかなくてはなりません。 そういう意味では、W3Cの日本における事務局が慶応大学にあるのはいいことだと思います。学生との接点を持ちやすいですし。

白石: Webのユニークなところは、数多くの企業が協同で標準化に努めているアプリケーションプラットフォームだと言うところだと思います。 しかもその企業の中には、グーグル、アップル、マイクロソフトと言った巨大なベンダーが含まれている。

芦村: 現在、400社くらいの企業がW3Cに協賛してくださっています。標準化における主役はそうした会員企業の皆様で、私たちはそのサポート役です。 私は時々「ホテルのコンシェルジュみたいな仕事だ」と言ったりしますけどね(笑)。

白石: そうした企業を繋いでいく標準化のお仕事というのは、具体的にはどのようなものなのでしょうか？

芦村: 標準化の作業は、結局のところ「仕様書をみんなで作っていく」ということに尽きます。

仕様書はW3C Process Documentという文書に書かれたルールに則り、ワーキングドラフトという状態から始まって、最終的な「勧告」という状態を目指して作業が行われます。

仕様書を策定するのはワーキンググループの役割で、その間のコミュニケーションを円滑にするのが私たちの重要な仕事の一つです。 電話会議を実施して議事録を取ったり、メーリングリストやGitHubで行われる議論をウォッチしたり。ちなみに私の電話会議のスケジュールはこんな感じです。

白石: うわぁ…夜8時以降がギッシリ。海外との電話会議だから時差があって大変ですね。

芦村: そうなんです(笑)。

白石: 様々な仕様が同時並行で標準化されていくのを、横断してサポートする感じなんですね。お仕事の雰囲気がなんとなくつかめました。

Webとテレビ…メディアプラットフォームとしてのHTML5の現状

白石: 今は、どういった分野の標準化を強く推進しているのでしょうか？

芦村: テレビ、IoT、自動車と言った産業分野での応用に力を入れています。

まずテレビの分野では、今までの一方向のブロードキャストを超えて、インタラクティブなテレビ放送の実現が望まれています。 日本では、NHKさんが主導してハイブリッドキャストの標準化などを進めていらっしゃいますね。

HTML5を（動画の）メディアプラットフォームとして使って頂くためには、標準のvideo要素に不足している機能がいくつかあります。例えばストリーミング配信だったり、コンテンツ保護の機能だったりですね。

それらを補うために、Media Source Extensions (MSE)やEncrypted Media Extensions (EME) といった仕様も既にありますし、字幕などを実現するためのフォーマットであるTTMLやWebVTT、セカンドスクリーン制御用のPresentation APIなどもあります。

白石: メディア配信のための機能はかなり充実していると言えそうですね。

今後のクルマはWebSocketサーバーに？

芦村: Webとクルマについても、最近活発に議論されています。

近年「コネクテッド・カー」というコンセプトで、インターネットに常時接続する自動車が開発されています。そうした中、Webの自動車における利用も具体的に検討されています。

白石: カーナビとかで使われる、センタースクリーンのUIがWebブラウザになる、って感じでしょうか？

芦村: それは一つのユースケースですね。ほかにも、クラウドにデータをアップロードする「Webクライアント」としての利用や、自動車固有のデータを扱うためのJavaScript APIなども整備されています。

芦村: で、実際の車載システムとのコミュニケーションは、WebSocketを利用する仕様が提案されています。Vehicle Signal Architectureの図を見ると全体像が把握できるかと思います。

白石: WebSocketで車とコミュニケートできるんですか、なんか胸熱ですね…！

芦村: 自動車技術とWeb技術の融合に関心のある方は、Webとクルマのハッカソンというイベントもあるので、申し込んでいただくといいかと思います。

「つながなきゃもったいない」…Web of Things (WoT)の狙い

芦村: IoT分野に対しては、Web of Things (WoT) という取り組みを通じて、IoT機器やプラットフォーム間の相互接続を促進しようとしています。

白石: しかし、IoTデバイスって、Webブラウザを搭載するには非力なものも多そうだし、そもそもスクリーンを持たないデバイスも沢山ありますよね。そこでWebが果たせる役割とは何なのでしょうか？

芦村: 確かに「Webブラウザ」という観点からでは、仰る通りです。ただ、ここで言っているWebとはもっと広い意味、「インターネット上の情報空間」という性格のWebを差しています。

芦村: いろんなものがインターネットに繋がって、集められたデータが、既にWeb上に蓄積していますし、その蓄積する速度はこれからも増すばかりでしょう。 だから、率直に言ってそれらのデータを連携させないのはもったいないぞ、もったいないおばけが出るぞ、なんて思っているんです(笑)。

IoTデバイスは、既にWebに接続しています。しかし今はそれらの実装がバラバラ。 ただ実際に、それらを連携させたいというニーズは、ユーザーからも企業側からも出てきています。

白石: 錚々たる企業が参加してますね。

芦村: そこでW3Cには業界におけるユニバーサル・ジョイント・アダプター的な役割が求められているんです。

白石: WoTとは具体的にどのような技術セットなのですか？

芦村: 全体像としては「W3C WoT Framework」というものになります。そのフレームワークでは、WebサーバーとWebクライアントのどちらも備えた「Servient (Server + Client)」と呼ばれるデバイス同士が相互接続するというのが基本的なモデルです。

そして、機器を公開したり発見したりアクセスしたり…という事を行うためのJavaScript APIも規定されています。

白石: Servientですか、デバイスにサーバーもクライアントも突っ込むとは。大胆で面白いアイデアですね〜。

Webを継続的に発展させていくために

白石: では、最後にWebの今後とW3Cが果たす役割についてお話いただけますでしょうか？

芦村: Webの本質は、自律分散協調システムであるというところにあると思うんです。あらゆる主体が自律的に、分散して活動するのですが、更にそれらが協調することでより大きな価値を生んでいく。

W3Cが注力しているのは、こうした自律分散協調システムが、より活性化するように後押ししていくことです。

自律と分散により、それぞれの主体が競争しながら個別の実装を行っていく。しかしそれらの実装は、「Webと繋がっている」という点では共通です。Webはインターネット上のグローバルな情報プラットフォームですから。 そうしてWebに繋がっている個々の主体を、今度は相互接続して協調できるように働きかけていく。

白石: なるほど、そういう観点から見ると、Webブラウザも「Webと繋がっている」アプリケーションですし、HTMLやCSSの標準化とかもまた違った捉えかたができそうですね。

しかし個人的には、HTMLやCSSの標準化を見ても、活発に進めているのはごく少数の企業のみ…というふうにも思えます。 これは、標準化から利益を得られる企業が限られているからとも思えるのですが、そこはどうお考えですか？

芦村: 確かにそういう見方は否定できません。Webは基本的にオープンであることを指向しますから、既存の企業も、オープンウェブの上にビジネスを再構築する必要が生じるという面もあるためです。

そしてやはり、標準化が企業の利益に貢献するというモデルを後押しする必要はあると思っています。そうでない企業にとっては、標準化って「趣味」みたいなものになってしまいますから。

そういう意味では、WoTは良いテストケースだと思っています。たくさんのモノを、そして企業をつなぎ、さらにそれら企業の利益に貢献する。そして、Webがオープンな場所として健全に発展していくことを、継続的に後押しするのがW3Cの役割だと思います。

白石: 本日は、W3Cという立ち位置からの貴重なお話、大変面白かったです。どうもありがとうございました！

2013年12月からトライアルサービスとして提供されてきたWebRTC Platform SkyWayのビジョンとミッション、基本的な使い方からハックな使い方などが紹介された同イベントの模様を紹介する。

SkyWayのビジョン＆ミッション

2013年12月から、無償のトライアルサービスとして提供されてきたWebRTC Platform SkyWay（以下、SkyWay）。

一部では「WebRTCでサービス開発を行うならSkyWayが必須」と認識されつつある昨今、ついに2017年9月7日、商用サービスとして新たなスタートを切った。

本記事では、SkyWay初の開発者向けミートアップ「SkyWay Developer Meetup#1」の模様をお伝えする。

まず最初に登壇したのは、SkyWayプロダクトマネージャーの水嶋彬貴氏。

▲SkyWayプロダクトマネージャー 水嶋 彬貴氏

6,000人以上の開発者、10,000近くのサービス、300近くの企業に既に利用されているSkyWayは、現在なんと1日あたり50万近くのWebRTC接続を捌いているという。

こうした実績は、「WebRTCを使うとこんなにもたくさんのことができる、と開発者の皆さんに証明していただいた」ことの現れであると水嶋氏は強調。

その上で、新たなスタートを切ったSkyWayのビジョンとミッションを以下のように定義した。

「リアルタイムコミュニケーションを身近な技術に変え、世界中のソフトウェアエンジニアと共に世の中に革新を起こす」

リアルタイムコミュニケーションを身近な技術に変える

ミッションの前半「身近な技術に変える」という部分においてはまず、SkyWayの様々なAPIやSDK、日本語を含めたドキュメントが、WebRTCの難しさを中和してエンジニアの負担を減らすことができるとする。

それによりエンジニアは「WebRTCをどう使うか」ではなく、WebRTCを使ったイノベーションやアイデアに集中することができるようになる。

もうひとつ、身近な技術に変えるというミッションに基づいて提供されているのが、無償の「コミュニティエディション」だ。

無償で利用できる月に500ギガバイトという帯域量は、ボイスチャットであれば5,787日分、ビデオチャットであっても462日分に相当する。

これだけの無料枠を手軽に試せるならば、スタートアップや新規事業に採用するのにためらう必要はない。まさに「リアルタイムコミュニケーションを身近にする」を体現した形だといえる。

──そしてイノベーションを世界に広げる

しかし、と水嶋氏は言う。SkyWayがいくらWebRTCを身近にしたところで、それだけでは世界中に広がるものではない。

ミッションステートメントの後半部分「世界中のソフトウェアエンジニアと共に世の中に革新を起こす」を達成するには、SkyWayを利用する開発者の助けが必要なのだと。

そこで水嶋氏は「（開発者への）お願い」と題して、以下の4つを挙げていた。

• 横のつながり
• イノベーションのアイデア共有
• ノウハウの共有や相互支援
• 事業の成功と後続の支援

水嶋氏のプレゼン資料はこちらから参照できる。

WebRTC開発者にはたまらない！基本からハック、生Q/A大会まで！

その後は開発者向けにたっぷりと時間が割かれ、SkyWay / WebRTCに関する熱い議論が繰り広げられた。

SkyWayテックリードの岩瀬 義昌氏による「SkyWayを使いこなすために」というセッションは、SkyWayに関する基本から応用、ハックから内部関係者しか知らない情報まで盛りだくさんの内容だった。

▲SkyWayテックリード 岩瀬 義昌氏

あまりの情報量に、とてもではないがここでは内容を紹介しきれないため、詳しくは岩瀬氏のスライドをご覧いただきたい。

以下に、筆者として気になったポイントをいくつか書き記しておく。

*SkyWayは、現在開発が停止したPeerJSをベースに開発されていたが、内部はフルスクラッチで書き直しており、継続的なメンテナンスや機能追加を行っている。「古いのではないか」という心配はあたらない

*SkyWayでは、通常のP2P接続に加えSFU（Selective Forwarding Unit）もサポートしており、しかも無償から利用できる。

SFUとは複数のメディアストリームをサーバ側で一本にまとめてクライアントに配信する仕組みであり、多人数のビデオチャットを行う場合などに、P2Pのフルメッシュ型に比べてネットワーク全体の負荷を大きく低減することができる。

SkyWayが提供するRoom APIでは、フルメッシュとSFUを簡単に切り替えることができる。（SFUについてはSkyWayのドキュメントにある説明がわかりやすい）

*APIドキュメントに書かれていない機能もいくつかあり、統計情報の取得なども行える。気になる方は岩瀬さんのスライドを参照のこと。

*安定性やスケーラビリティについては万全の体制を敷いている。 （後のQ/Aセッションによると、開発チームの人員が5人以上の体制で監視しているほか、運営企業であるNTTコミュニケーションズの監視部隊とも連携しており、24時間365日稼働を保証しているとのこと）

SkyWay開発者によるライトニングトーク大会

以降も、ミートアップはまだまだ続く。

ライトニングトーク大会では4人の登壇者がSkyWay開発に関する実際から「やってみた」まで幅広いトピックでプレゼンテーションを行った。

@jumboOrNot氏による「iOSでのSkyWay開発の勘所とTips」

レアジョブ英会話というサービスで、SkyWayを利用したiOSアプリを開発した際の生々しい話。

Skypeで行っていたサービスをWebRTC化することで開けた展望、そしてiOSアプリ開発で直面した問題に対してGoogle Firebaseを用いて対処したことを紹介していた。

▼講演資料はこちら

@massie_g氏による「SkyWayのビデオチャットを録画しよう。そう、ブラウザでね」

現在のWebブラウザが備えるAPIのみを用いて、ビデオチャットの録画を行う方法を紹介。

▼講演資料はこちら

@leader22氏による「SkyWay JS SDKの歩き方」

SkyWayのJavaScript SDK開発をサポートしたPixelGridの杉浦氏による、JavaScript SDKの読み解きガイド。

講演資料: SkyWay JS SDKの歩き方

@lz650sss氏による「SkyWay×Cognitive Service」

SkyWayで受信したビデオチャットの画像をMicrosoft AzureのCognitive Serviceに送信し、表情を読み取るデモ

講演資料: SkyWay × Cognitive Service

フランクなQ/Aセッション、そして開発者だらけの懇親会。これぞデベロッパーファーストなミートアップだ

アジェンダの最後はQ/Aセッション。事前アンケートで集めた質問に対して、開発チームが自らフランクに答えるセッションで、非常に和気あいあいとした雰囲気の中盛り上がった。

そして（無料の）懇親会。会場の至る所で、Web(RTC)開発者同士のハイコンテクストな会話が繰り広げられていた。

最後に、イベントを通じて筆者が感じたことを述べておく。

SkyWayはもちろんプラットフォームであるが、このイベントを通じてSkyWayチームが実現したかったことは、「開発者コミュニティ」というプラットフォームづくりなのだろうと思う。

SkyWayというプラットフォームを提供してリアルタイムコミュニケーション開発の敷居を下げるだけが彼らの役割ではない。

同時に、開発者基盤としてのコミュニティ構築も図ることで、WebRTCを活用したイノベーションが生まれやすくすることも、また彼らの役割なのだと。

SkyWay開発チームのこうした挑戦が実を結び、日本発のプラットフォームが世界を席巻する日を、筆者は見たい。

※本記事はITエンジニアのためのキャリア応援サイト「CodeIQ MAGAZINE」（※2017年11月18日掲載）からの提供記事です。

こんにちは、編集長の白石です。

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

今回お話を伺ったのは、html5j パフォーマンス部を運営していらっしゃる竹洞 陽一郎さんです。

▲HTML5 Conference 2017セッション風景 （写真提供：html5j　撮影：刑部友康）

竹洞さんのセッション「テクニックではなく、今、本気で取り組むべきWebパフォーマンス」に関するスライド資料は、こちらで公開されています。

民法（債権法）が改正されて、何が変わる？

白石: 民法（債権法）が改正された、ということに注目なさってるそうですね。

竹洞: はい、民法の大規模な改正法案が今年5月に成立しました。3年以内に施行されることになっており、備えが必要です。様々な改正項目がありますが、中でも品質の担保を行う義務が明文化されたことで、ソフトウェア業界にも大きな影響が及ぶものと考えています。

白石: 具体的にはどういうことなのでしょうか？

竹洞: 「瑕疵担保」っていう概念がなくなるんです（参考: 改正民法が成立、「瑕疵担保責任」などシステム開発契約に影響大 (ITpro)。

今までは「瑕疵担保」という概念があったおかげで、とりあえずは品質を担保しない状態で納品を行い、その後の瑕疵期間で問題を修正していく…というのが一般的に行われていました。ですが今後は、納品時に一定の品質を保証することが開発側に求められるようになります。

白石: そのことが、どういう影響をおよぼすと考えられますか？

竹洞: 私としては、ソフトウェア品質が全般的に向上することで、市場が健全化すると考えています。

品質への理解が低い市場は、必ずと言っていいほど衰退するんです。 消費者が品質の善し悪しが判断できない状態だと、価格が一番の判断材料になります。 そうなると結局、品質を犠牲にした価格競争にならざるを得ない。

白石: 「安かろう悪かろう」が当たり前になってしまうわけですね。

竹洞: そう。そういうスパイラルに陥らないためには、品質への意識を高く保つ必要があるんです。

例として適切かはわかりませんが、たとえば麻薬の売人って、品質にものすごく気を使うんです。 質の悪い麻薬が出回るようになると、価格に対する期待と同程度の「ハイ」の状態を得られず、その結果、価格の下落を招き、結局市場が衰退してしまうからです。こうした現象を、アメリカの中古車市場の分析から「情報の非対称性」として研究したジョージ・アカロフ博士は、2001年にノーベル経済学賞を受賞しています。

「品質保証」がウェブ業界を変える

白石: しかし、品質保証が義務付けられるとなると、開発のコストが上がるということになりませんか？

竹洞: それはあり得ます。そのことが、受託開発のビジネスなどをより難しくしてしまうことも考えられます。

例えばウェブ制作会社は、一般的には納品後に入金が入るという仕組みになっていますよね。 だから、まずは品質がそこそこの状態で納品してしまう…ということも起きるわけです。 パフォーマンスはその悪い例で、まずはチューニングしていない状態で納品する。すると、後でパフォーマンス・チューニングの依頼が来てまた売上につながる…なんて事情も実際にはあるわけです。

こうしたこれまでの商慣行が崩れてしまう可能性はありますね。 品質保証が義務付けられるせいで、納品までにより時間がかかるようになるとすると、入金が遅くなるということに繋がる。しかし、民法債権法改正では、部分単位やステージ毎の請負金額の要求ができるようになっています。

白石: それだけ聞くと、受託開発や制作を行っている企業にとっては、ただただ厳しくなるようにも聞こえますね。 そもそも、「品質を保証して納品」ってどういうことなんでしょう？ 完璧なソフトウェアを作らねばならない…なんてそもそも無理だとも思うのですが。

竹洞: その点については安心していいと思います。 「品質を保証する」というのは、「完璧な製品」を意味しているわけじゃないんです。 テスト項目について顧客と合意し、その結果を提出すればいい。実は、ソフトウェア品質には、V&Vといって、Verification(検証)とValidation(妥当性確認)という二つの概念があります。

検証(Verification)とは、仕様・設計・計画などの要求事項を満たしているかどうかの確認です。妥当性確認(Validation)とは、機能や性能が本来意図された用途や目的に適っているか、実用上の有効性があるかの確認です。Webパフォーマンスは、品質においては、妥当性確認にあたります。

従来、ソフトウェア開発における「品質」、特に受託開発においては、検証確認が主体でした。もちろん、応答速度の遅延などで使いものにならないという妥当性確認もあったものの、それはハードウェア性能であったり、データベース設計の問題であったりと、「表示」そのもののロジックに原因はあまりなかったのです。

要求仕様の実現という意味での検証については、仰るとおり「完璧な製品」というのは、ほぼ存在し得ない。それは、ソフトウェアが、論理記述であって、物理法則の縛りがなく、かつ、連続性の保証がないためです。

連続性の保証とは、物理法則であれば、100Kgの重さまで耐えられるテーブルであれば、当然ながら、80Kgや10Kgなど、100Kg以下の重量に耐えられることです。しかし、ソフトウェアは二値論理がベースであるために、100という値で大丈夫であっても、80や10という値で大丈夫であるという保証がない世界です。

2002年に亡くなられた、オランダの著名な計算機科学者で、構造化プログラミングの提唱者でチューリング賞を受賞しているエドガー・ダイクストラ博士が「テストは誤謬を見つけることはできるが、それがないことを証明することはできない」と指摘しています。

ですから、バグや欠陥がないことを保証するというのは無理なんです。

白石: なるほど、それなら少し安心です。バグや欠陥のないソフトウェアなんて不可能ですし。

竹洞: 品質についても顧客との合意内容に盛り込む必要が生じる、ってことですよね。 そうした合意があるのとないのとでは、品質に対する意識が全然違ってきます。品質については、検証として従来もやってきたことです。ところが、WebがソフトウェアのUIの主体となることによって、今まで問題にならなかった「表示」に関するロジックが突如、問題となり始めた。突如といっても、もう20年ぐらいになるわけですが…

その部分は、検証ではなくて、妥当性確認なんですが、妥当性確認のテストのノウハウが日本では普及していなかった。今、そこが問われているわけです。

白石: なるほど。「完璧な製品を作る」ことが品質保証なのではなく、「妥当性品質に対してどこまで保証するかを明確にする」ということなんですね。

竹洞: そうです。そうして、妥当性品質についての期待値を高く保つことは、Webに関する業界として必要なことだと思いますよ。

例えば日本の住宅市場は、品質保証がうまくいっていない例だと思うんです。 日本の住宅って、非常に寿命が短いじゃないですか。その理由は様々ですが、一つに中古住宅に対する品質の期待値が低いことがあると思っています。 品質保証がない空き家を買うくらいなら、新築のほうがいいって心理です。

白石: 確かにそういう一面はある気がしますね。ぼくは安さに釣られて中古住宅を買ったクチですが(笑)、一生住めるなんて少しも期待してませんし。

竹洞: それって、結局その家はいつか捨てることになるってことで、財の蓄積が進んでいないとも言えると思うんです。 社会的に見ると、将来世代に引き継ぐ財が形成されていないとも言える。財の蓄積が期待できないと、そこの投資は進まない。お金が集まってこないのです。

ウェブのように技術がどんどん進歩していく世界に財の蓄積は有り得るのか？システム構築費用は5年で償却されるのであれば、5年持てばいいじゃないか？という考えられるのは、仰るとおりです。

しかし、プレゼンテーションとしてのUIデザインと、データとしてのコンテンツやユーザのデータは分けて考えるべきで、だからこそ、HTMLとCSS、JavaScriptで役割分担をしているわけじゃないですか。システムの永続性というものを考慮してWebサイトの設計を行うことは非常に重要なのです。

減価償却期間の5年も持たない、3年程度で捨てざるを得ないとなれば、企業財務的にはそこはできるだけ安く済ませるべきなのです。しかし、品質が保証されて、減価償却の5年を超えて使えるとなると、将来価値が上がる。企業財務的にはおいしいお話なのです。そこに気付いてほしい。メンテナンス費用は当然発生するでしょうけど、新規で作るより安いですし、何より「継承」できることが大きなメリットなんです。

UIデザインや技術力だけで勝負しているWeb制作会社さんは、その点に、早く気づかれた方が良いと思います。お金を握っている経営者や財務担当者は、別のロジックで判断しているわけですから。

ですから、ウェブサイトも、いつか捨てるものとなれば、そこに予算を掛けようとは思わない。品質が保証されないのであれば、なおさらのことです。

「お客様からあまり予算をいただけない」と嘆くことがあるかと思いますが、その背景には、品質が保証されていないので修正するより作り直した方がいいと考えられていること、いつかWebサイトは捨てて新しく作るものと考えられている背景は認識しておくべきだと思います。

ウェブサイトの品質を決める3つの要素

白石: では具体的に、ウェブサイトにおける品質を保証するというのは、何をすればいいんでしょうか？

竹洞: ウェブサイトの品質は主に3つの要素から成っていると言っていいでしょう。

一つはアクセシビリティ。 一つはセキュリティ。 最後がパフォーマンスです。

Webサイトの三大品質

これらはそれぞれJISで規定されてもいる重要な指標です。これらをしっかり担保していく体制づくり、それがウェブサイトの品質保証に繋がります。

白石: ウェブサイト制作にも、これらを担保するワークフローを確立していくべきということですね。

竹洞: そうです。そしてこれらは、運用と一体になって改善していくべきものでもありますので、DevOpsの観点から考えるのも重要です。

ただ一つ不思議なのが、日本でDevOpsに関して述べている文献や書籍って、ほとんどの場合品質保証のことが抜けてしまっているんですよね。 品質に対する意識が高まらない原因は、こういうところにもあると思います。

DevOps

ウェブサイトの品質を高めるための心構え

白石: 品質を向上させるためのコストが低く見積もられがちというところもあるんでしょうか。

竹洞: というよりは、そのコストが認識されていないというのが正しい気がします。 「品質、費用、期間の3要素を同時に満たすことはできず、トレードオフの関係にある」といった、プロジェクトマネジメントやソフトウェア開発見積りの基本もあまり浸透していない感覚がある。

白石: なるほど。当たり前の話ですが、品質を高めようとすれば、時間的、金銭的なコストを支払う必要があるということですね。

竹洞: はい。そして品質保証が当たり前になれば、品質保証のためのコストがかかるのも当たり前になる。今は、その当たり前のコストを払っていないだけとも言えるのです。

白石: では、そうした品質保証、特にパフォーマンスについて、状況を改善していくにはどんな知識が必要になるんでしょう？

竹洞: そうですね、小手先のテクニックはたくさんありますし、いろんなところで語られてもいますので、もう少し根源的なところから考えると、結局「基礎」と「長期的な視野」が重要になると思うんです。

基礎というのは、コンピューターやネットワークに関する基本的な知識。 長期的な視野と言うのは、数年後にインターネットがどうなっているか、といった話です。

白石: なるほど。

竹洞: 例えば、パフォーマンスに関する話を突き詰めていくと、意外なほどハードウェアに関する知識って大事なんです。 パフォーマンスって、最終的には絶対にハードウェアに依存するわけですからね。

例えば、とある大規模サイトで遅延が発生していたんですが、その原因を追求するのすごく大変だったんです。 アプリケーションをいくら調べても、データベースのクエリをいくら見直しても、ネットワークの状態を見ても、原因がわからなかった。

白石: 結局、どんな原因だったんですか？

竹洞: そのサーバはVMWareで仮想化されていて、サーバ負荷に応じてCPUリソースが動的に割り当てられるようになっていました。ただ、あらかじめ割り当てられているCPUリソースが足りなかったせいで、CPUの動的割り当てが頻繁に発生してしまっていたんです。 その割り当てが行われる際に、サーバの処理が遅延してしまっていたんですね。

白石: それは深い原因ですね…

竹洞: ここまで奥深くに原因がある場合って、ハードウェアを含めたアーキテクチャ全般の知識が必要になります。 だから結局、コンピューター全般の知識って必要だなと。だから私の会社では、入社したら最初の一歩として、まずPCを自作してもらうようにしています(笑)。

全てを変える、5Gネットワーク

白石: 数年後にインターネットがどうなっているか、というお話も聞かせていただけますか？

竹洞: はい、具体的には5Gネットワークの話になりますね。5Gはアプリケーションの作り方を含め、全てを変える可能性がある技術だと思っています。

白石: 5Gネットワークって全然知らないのですが、どんな感じなんでしょう？

竹洞: 大きく3つのトピックがあると考えています。

一つはネットワークスライス。インターネットを「輪切り」にするイメージで、用途に応じて別々のネットワークを提供していくようになります。

電波には周波数によって特性があり、サービスの特性に応じて周波数を割り当てて異なるネットワークを構成できるので、ネットワーク全体の利用効率が大きく向上すると考えられています。

ネットワークスライス

次に指向性アンテナです。今までは、基地局といういわば「傘」を中心として、そこから広がるように無線ネットワークが構築されていました。

しかしこれからは、パネル型のアンテナがビルの壁面に貼られるようになり、そこから端末と直接「ビーム」をやり取りするように通信を行います。通信の受信強度が高まるだけでなく、他の電波との干渉も減らせます。

指向性アンテナ

最後にモバイル・エッジ・コンピューティングです。これは、4Gですと、地域の基地局をまとめているRNC(Radio Network Controller)配下に、仮想サーバー（エッジサーバー）を設置できるようになるのです。 今まで携帯の会社はコアネットワークを公開していなかったので、これは大きな変化です。

モバイルエッジコンピューティング

これは分散コンピューティングの新たな可能性を示しているといえます。インターネットより手前でトラフィックを捌けるわけですから、サーバーの応答性も大きく向上します。

白石: へえ、知りませんでした！世界中のエッジサーバー上に、静的リソースのキャッシュを置けたりしたら、すごく速くなりそうですね。

竹洞: それだけではありません。エッジサーバーで可能な限り処理を行い、必要な処理だけインターネット上のサーバーに送るようにすることもできます。アプリケーションの処理を、エッジサーバーとインターネット上のサーバーで分担するというわけです。

もしくは、全てエッジサーバー上で処理を行うような、非インターネットのローカルなサービスを行うことも可能です。

白石: そうなると、アプリケーションの作り方も大きく変わってきそうですね。夢が拡がりますね…。5Gネットワークって、具体的にはいつ頃普及が見込まれているのでしょうか？

竹洞: 2020年の東京オリンピックまでには使えるようになるだろうと言われています。

10月12日に、NTTドコモ、富士通、富士通研究所がモバイル・エッジ・コンピューティングを使った高画質動画配信や映像解析を活用した人物検知システムの実証実験を行って成功した旨のプレスリリースを発表してています。

また10月13日には三菱商事が、この分野のリーディングカンパニーであるJIG-SAWと、モバイル・エッジ・コンピューティングの実証実験成功のプレスリリースを発表しています。

白石: ワクワクしますね。本日は民法から5Gネットワークまで、幅広いお話を聞かせていただき、ありがとうございました！

こんにちは、編集長の白石です。

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

今回お話を伺ったのは、株式会社ACCESSの梅田雅士さんです。

梅田さんのセッション「TV・車・ゲームに搭載されているブラウザってどうなってるの？」に関するスライド資料は、こちらで公開されています。

組み込みブラウザって…なに？

白石:では、まずは簡単に自己紹介をお願いできますか？

梅田:株式会社ACCESS IoT事業本部課長の梅田 雅士です。 もともとはエンジニアでして、ブラウザ開発からWebサービスまで、組み込みからフロントエンドまで開発していました。

白石:すごく幅広い経歴をお持ちですね！今回はPCやスマートフォン「以外」の環境におけるブラウザのお話を伺えると聞いています。

梅田:はい、今やブラウザはテレビにも、自動車にも、ゲームにも搭載されています。それらを総じて「組み込みブラウザ」と呼んでいます。

白石:組み込みブラウザと言うのは、PCやスマートフォンのブラウザとどう違うんでしょうか？

梅田:Webを閲覧できると言うのは、ブラウザの基本的な機能ですので、組み込みブラウザであっても変わりません。違うのはまず動作環境ですね。例えばOSも、LinuxからiTronまで、様々な環境があります。中にはタッチ操作やマウス操作が存在しない環境でも動作することが求められることもあります。

白石:ACCESSさんの組み込みブラウザは、今は主にChromiumやWebKitをベースにして開発してらっしゃるんですよね。組み込み向けに機能を追加したり、ということもあるんでしょうか？

梅田:はい、例えばテレビのリモコンとか、ゲームのコントローラーとかでブラウジングを可能にすると言った機能の追加は一般的にありますね。ブラウザの操作に関しては、「組み込みならでは」という部分は多いです。

テレビとブラウザ

白石:では、テレビ、クルマ、ゲームに搭載されているブラウザの状況について、詳しく教えてください。

梅田:ではテレビからいきましょう。実はテレビには昔から身近にありまして、テレビのdボタンを押して立ち上がる画面は、実はブラウザなんです。

白石:dボタンはブラウザ起動ボタンでもあったわけですね。

梅田:はい、それにテレビのメニュー選択を行うアプリもHTMLで書かれていたりしますね。

白石: ハイブリッドキャストと言うのは何でしょうか？

梅田:テレビ向けのブラウザでは、以前はBML (Bloadcast Markup Language)という、XHTMLベースの独自言語が利用されていました。ですが現在では、HTML5をベースとしたテレビ用の規格がありまして、それが「ハイブリッドキャスト」です。

ハイブリッドキャストは「放送と通信の連携」を目的として、NHKさんを中心とした標準化が行われています。単にHTML5が使えると言うだけではなく、スマートフォンとの連携（セカンドスクリーン）機能なども備えています。

白石:民放局の、ハイブリッドキャストへの対応度合いとかはいかがですか？

梅田:各社とも、現在対応を拡充している段階ですね。2020年の東京オリンピックで、テレビ放送をより楽しく観せるのが、各社共通の目標になっています。

白石:ちなみに昔聞いた話なのですが、テレビって意外にも低スペックで、重たいWebページを表示させるのは難しいと聞いたことがあります。その状況は現在では変わりましたか？

梅田:いえ、あまり変わりないです。テレビの中で一番高価な部品はやはりパネル。その他の部品、例えばCPUなどは、やはり廉価なものが使われることが多いんですね。なのでテレビ向けのWebページは、軽量であることが望まれます。

車とブラウザ

白石:では次は車とブラウザの関係について教えてください。

梅田:自動車業界では、カーナビを中心とした、操作可能な中央のスクリーンを「HMI (Human Machine Interface)」と呼びます。HMIでブラウザを利用できると、例えば自動車のマニュアルをHTMLで書いたりできます。HTMLは多言語化しやすいのでメリットは大きいですね。

あとは車載システムにアプリを追加することができるものもあります。インターネットと繋がって、例えば天気を表示したり、運転を楽しくするようなアプリがインストールできたりします。車載システムは「情報（インフォメーション）」と「娯楽（エンターテインメント）」を提供するという概念から、「インフォテインメント」とか、「IVI（In-Vehicle Infotainment：車載インフォテインメント）」と呼ばれたりします。HMIでブラウザが利用できるなら、そうしたアプリもWeb技術で開発できるようになります。

白石:車載システムにブラウザを搭載するという動きは、どれくらい進んでいるものなんでしょうか？

梅田:海外では結構進んでいます。車載システムのOSは共通化が進みつつあって、主要なものとしてはAGL (Automotive Grade Linux)やGENIVIがありますが、これらには今後ブラウザが搭載される予定があります。

ちなみにAGLって、Tizen IVIが元になっているんですよ。Tizenは一時期HTML5にも注力していましたので、白石さんはご存知じゃないかと思いますが。

白石:ええっ！Tizenって久しぶりに聞いた名前です。そうだったのか…そういう風に受け継がれていたんですね。IT業界って、思わぬところが繋がってたりするので面白い(笑)

ところでそういう車載システムとかだと、テスラの車とかは進んでるイメージありますけど、実際のところどうなんでしょう？

梅田:確かにテスラは進んでいて、WebKitを搭載した車載システムを既に積んでいますね。ただ、古いバージョンのWebKitを搭載していたため、そのセキュリティホールを突かれてハッキングが可能な状態になっていたことがあったりします。車載システムの高度化に伴って、セキュリティリスクも高まりつつあるというのが実情です。

ゲームとブラウザ

白石:ゲーム機にブラウザが搭載されているという点についてはいかがでしょう？

梅田:実は、ゲーム機にブラウザが搭載されているのは結構昔からなんです。2003年に発売されたPlayStation 2や、2004年に発売されたPlayStation Portableには、もう入っていましたからね。

白石:そんなに昔から入っていたんですね。そう言えば、ガラケーとかにもブラウザ積まれてたし、そう言えば組み込みブラウザって結構昔からあったんですよね。

梅田:そうですね。それに、ゲームソフト自体にブラウザが積まれていたこともありましたよ。

白石:ええっ！ゲームソフトがブラウザを内蔵していたんですか？

梅田:そうです。例えばモンスターハンター3には、弊社のNetFrontというブラウザが内蔵されていました。

白石:ゲームソフトにブラウザが入ってるなんて、考えたこともありませんでした。すごい世界だ。

ブラウザ開発ってどんな仕事？

白石:そもそもブラウザ作ってる会社ってあまりないですよね。そこら辺の実際をお聞きしてみたいです。ブラウザ開発って、どのように進めるものなんですか？

梅田:基本的には、W3Cの仕様を満たすように実装するというのがブラウザ開発の中心になります。ただ、今はオープンソースのブラウザをベースに開発していますので、少し仕事の範囲が変わりましたね。W3Cの仕様を満たすために開発するのは、主にChromiumやWebKitのコアチームに任せて、私たちはその移植が中心になりました。

白石:なるほど、今はブラウザエンジンそのものの開発に深く食い込んでいるわけではないと。

梅田:ただ、弊社ではEPUBのエンジンも作っていまして、そのために独自開発した部分とかは結構ありますね。例えば縦書きレイアウトとかは、W3Cに提案されている仕様を元に弊社で開発したコードを、ブラウザエンジン側にコントリビュートしたりもしています。

白石:ちなみにブラウザ開発って、どんな言語を使って行うんですか？

梅田:WebKitやChromiumはC++で書かれているので、C++ですね。C++ってメモリマネジメントが重要な言語ですが、WebKitとかってそこら辺が少しいいかげんだったりするんです(笑)。

白石:え、そうなんですか？メモリリークしたり、とかですか？

梅田:さすがに派手なメモリリークとかはめったにありませんが、メモリ確保に失敗した時の処理が甘かったり、とかですね。で、車載システムとかで利用する場合って、「動かない」って状況になるのはすごくまずいわけです。運転中は安全がなにより最優先ですから。そういう穴を潰して本家にコントリビュートする…というのもたまにありますね。

組み込みブラウザベンダーはつらいよ

白石:ACCESSさんはブラウザと言っても、更に「組み込みブラウザ」を作っているという数少ない存在。そういう、数少ない組み込みブラウザベンダーならではの苦労などをお聞きしたいです。

梅田:そうですね、まず先ほども申し上げたように、現在はChromiumやWebKitをベースに開発しています。以前は独自のブラウザエンジンでしたが、数年前にWebKitに切り替えたんです。ただ、WebKitはそもそも組み込み用途が主ではありませんでしたから、当初はハードのスペック的な制約との折り合いを付けるのが大変でしたね。（Webページが）メモリに乗り切らないので、数キロバイト単位に分割してメモリに載せるようにしたり…

白石:うわー、それは大変そう…。

梅田:最近はハードのスペックが向上したので、そういう苦労をすることも少なくはなってきましたけどね。あとは、レンダリングのパフォーマンスを改善するのも大変ですね。車載システムだと、最低でも60fpsは要求されるので、動画のデコードをハードウェアに行わせるようにするとか、CanvasをGPUレンダリングするとか。スクロールが滑らかになるようチューニングするのも大変でした。

白石:WebKitとChromiumは使い分けてるんですか？

梅田:お客様からのご要望や、用途に応じて使い分けています。WebKitはリリースサイクルがだいたい年一回で安定していますが、Chromiumのリリースサイクルはもっと速くて、コードもどんどん変化していきます。どちらがいいということでもなくて、それぞれにメリットがありますね。

白石:大変興味深いお話です。組み込む製品ごとに異なる苦労とかはあったりするんですか？

梅田: 車の場合とかは、製品の開発サイクルが長いのが特徴です。一つの車を作るのに5年とかかかったりすることもあるので、何回もつなぎ込みが発生するわけです。

白石:5年！Webの世界で5年と言ったら、状況はかなり変わってしまいますよね。

梅田:そうですね。ベースになっているブラウザもどんどん進化していくので、つなぎ込みを行うたびに、できるだけ最新に近づけていくようにするんです。その際に、ブラウザエンジンが持つAPIが変わってしまうことも珍しくありません。そういう事態に対応しやすいように、APIを抽象化したレイヤーを持っていたりします。

白石:いやー、ぼくみたいなフロントエンドエンジニアが全然体験したことのない苦労だ(笑)

梅田:他には、ブラウザの機能を拡張しなくてはならないこともよくあります。組み込みの場合って、HTML5が元々持っている機能だけじゃ足りないことが多いんですよ。

ゲームの場合は、ゲーム機というハードに閉じているからか、独自に拡張することが多いのが特徴です。

車載の場合は、Vehicle APIっていうAPIがW3Cで標準化されていますので、その実装を行うのも仕事の一つです。このAPIを使うと、例えばキーロックの情報を取れたりと、車載システムならではの機能を利用することができます。

PCやスマホ「じゃない」Webアプリ開発とは

白石:では最後に、PCやスマホじゃない世界でのWebアプリ開発について、どのようなものかお聞かせください。

梅田:基本的には、それほど変わるところはありません。組み込みブラウザと言っても結局WebKitやChromiumをベースとしていますし、HTML5以降はブラウザ間の互換性も高くなっていますし。

ただ、市場によって制約はありますね。例えば車載システムで動作する場合は、運転手の気を逸らさないようUIガイドラインがあったりします。

一方で、市場ごとに特有の拡張機能を使うことも求められます。

白石:先ほどおっしゃっていた、車載システム上で使えるVehicle APIなどですね。

梅田:そうです。そして、そうした標準化されたAPIと言うのは、組み込みの世界で特に重要なんです。

基本的にオープンなPC/スマホに比べて、組み込みは市場に特化しがちな世界でもあります。クローズドな世界で、クローズドな技術を使っているのでは、スキル的にもビジネス的にも拡がりにくい。

オープンで標準化されたAPIを使うことで、そうした事態を避けることができる。Web技術者も、活躍できる場がどんどん広がっていきます。

白石:なるほど。ちなみに、車載の世界とかでは、App Storeのようなアプリプラットフォームが出てくる可能性はあるのでしょうか？そして、Webで作ったアプリであればそれらのプラットフォームにどこでもデプロイできるというような可能性はありますか？

梅田:はい、そういう可能性はもちろんあります。アプリプラットフォームみたいな構想は各社持っていて、今後登場してくるのは間違いありません。 その時に、Web技術を使ってアプリを開発できる可能性も、それが複数のプラットフォームで展開できる可能性も、大いにあると思います。

そうした世界を見据えて、総務省さんと一緒に「Webとクルマのハッカソン」というイベントをここ数年開催しています。10月下旬から申し込み開始ですので、興味のある方にはどんどん参加してほしいですね。

白石:あ、そのイベント去年ぼくが審査員やったやつだ(笑)。去年もすごく盛り上がりましたよね。本日は組み込みブラウザ開発の話、そしてPC/スマホ以外のWeb開発の話など、普段あまり聞けないお話をお聞かせいただき、ありがとうございました！

こんにちは、編集長の白石です。

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

今回お話を伺ったのは、株式会社サイバーエージェントの青野健利さんです。

青野さんのセッション「Deep dive into TypeScript」に関するスライド資料は、こちらで公開されています。

なお本稿のサンプルコードは、ほとんどが上記スライドから引用したものになります（一部説明を簡略化するため、青野さんの許可を得て筆者が書き換えた部分もあります）。

筆者からのお詫び: 今回のインタビュー、および対象セッションは大変内容が濃く、記事にすると長大になりすぎる＆スライド資料が大変参考になるため、「型」の話に絞った記事として再構成させていただきました。ご容赦ください。

TypeScript、基本の基本

白石: 青野さん、今日は取材をお受けいただきありがとうございます。まずは簡単に自己紹介をお願いします。

青野: はい、私は2010年ごろからWeb系の仕事に従事していまして、2011年からサイバーエージェントに所属しています。普段は広告系の部署で、チャットボットのツールを作ったりしています。

白石: 今回はTypeScriptについてお聞きできるということですが、仕事でもTypeScriptを使ってらっしゃるのですか？

青野: はい。というか、TypeScriptしか使っていません(笑)。

白石: なるほど(笑)。ではまずはTypeScriptについて、簡単に概要を教えていただけますか？

青野: TypeScriptとは、Microsoftが作ったJavaScriptのスーパーセットですね。特徴は静的型付けの言語だということ、あとはECMAScriptの新しい仕様を先取りしているというところですね。AltJSと呼ばれる言語の中では、頭一つ抜きん出て利用されている言語じゃないかと思います。

白石: 今回は「Deep Dive」というセッションタイトルでもあったとおり、かなり深いところまでお話されてそうですよね。私も普段TypeScriptは使っていますが、どこまで一緒に潜れるか、不安です(笑)。まずは簡単なところから教えてください。

青野: はい、まずは型についてお話しましょう。TypeScriptにおける型の最も大きな特徴は、コンパイル時にのみ評価されるということですね。コンパイルされた結果のJavaScriptは型を持たない言語ですから、当然型の情報は含まれていません。

また、TypeScriptは型を書かなくてもよい言語です。型推論があるので、変数の型が代入文から自動的に推論されます。また、anyという型があって、この型の変数に対しては、どんなプロパティアクセスやメソッド呼び出しを行ってもコンパイルエラーになりません。

これらの特徴は、すべてJavaScriptとの統合を真面目に考えているからこそです。既存のJavaScript資産を活かせるよう、そしてJavaScriptコードとの相互運用性を高く保てるよう、よく考えられています。

白石: 既存のJavaScript資産をTypeScriptでも使えるよう、型定義ファイルがコミュニティの手で作られていますよね。

青野: Definitely Typedですね。品質に多少の問題があるので賛否両論ではありますが、コミュニティの力が発揮された素晴らしい成果だと思います。

Structual Subtyping

白石: では、だんだん詳しい話題に踏み込みましょうか。

青野: はい、まず、TypeScriptの型システムは、Structual Subtypingを採用しているのが特徴です。これは、型の同一性を型の名前ではなく、型の構造だけで判断するというものです。

例えば、xとyというメンバーを持つPoint2Dというインターフェースと、それを引数として受け取るメソッドがあったとします。

そのメソッドに渡すオブジェクトは、xとyというメンバーを持ってさえいれば、Point2Dインターフェースを実装している必要はありません。

interface Point2D {
 x: number;
 y: number;
}
const point = {
 x: 0,
 y: 0
};
function acceptPoint2D(point: Point2D) {}
acceptPoint2D(point);

白石: ダック・タイピングの静的型付け版、みたいな感じですよね。

今、インターフェースの話が出ましたが、TypeScriptにおけるユーザー定義型についても教えてください。

青野: TypeScriptでは、型を定義するのにクラス、インターフェース、Enum（列挙型）のような機能があります。

ECMAScriptでも、6からはクラスを作れるようになりましたが、TypeScriptではより多くの機能を持ったクラスを使うことができます。例えばアクセス修飾子を付けて、プロパティやメソッドの公開範囲を限定することができたり、readonlyキーワードを用いてイミュータブルなプロパティを作ることもできます。

インターフェースはクラスが実装すべき規約を表すための機能です。implementsというキーワードでクラスに付与すると、インターフェースが持つメソッドやプロパティを実装しないとコンパイルできなくなります。

TypeScriptのインターフェースはコンパイル時にのみ用いられます。出力されるJavaScriptコードには、インターフェースの情報は残りません。

// クラスの例。OtherClassを継承し、OtherInterfaceを実装している
// アクセス修飾子、staticプロパティ、readonlyプロパティなど、TypeScript固有の機能が多数ある
class MyClass extends OtherClass implements OtherInterface {
  public constructor() { super(); }
  protected methodFoo() { }
  private property: number = 1;
  public static methodFoo() { }
  private static property = 1;
  public get getter() {}
  public set setter(value: any) {}
  public get set prop() {}
  private readonly immutableProp: string = 'a';
}

白石: typeというキーワードで型が作れますよね。インターフェースとの使い分けがいまいちよくわからないんですが。

// 以下のように型を作ることもできる
type MyType = {
  a: number;
};

青野: typeキーワードは、基本的には他の型のエイリアスを作るだけなんです。同様のことをインターフェースで実現できる場合は、インターフェースの利用が推奨されています。例えばtslintで、typeの代わりにインターフェースを使うように強制することもできますね。

ちょっと変わった型…文字列リテラル型、Index Type

青野: ただ、文字列リテラル型（String Literal Type）を定義する場合はtypeキーワードを使う必要があります。

白石: だんだん深い話になってきましたね。文字列リテラル型というのは、型に文字列リテラルを指定できるっていうTypeScript独自の機能ですね。

// 'hello'か'world'しか代入できないHelloWorld型を定義
type HelloWorld = 'hello' | 'world';

// 以下の文はコンパイルエラー
const s: HelloWorld = 'good morning';

他にも、Index Typeというのもあります。この機能を使うと、プロパティが動的に変化するオブジェクトの場合も、コンパイラで可能な限り型チェックできるようになります。以下の例では、キーは文字列、その値も文字列となる動的な型を定義しています。

// Index Type
type StringMap = { [key: string]: string };

白石: プロパティ名のところに[name: type]のように書くのがポイントですね。

型の合成（Intersection Type）と型の結合（Union Type）

青野: ほかにtypeを使用する必要があるのは、型の合成を行う場合です。

白石: 型の合成？

青野: はい、Intersection Typeと言って、型の積集合を作る機能です。もっと簡単に言えば、二つの型を混ぜ合わせる機能ですね。使用方法は簡単で、二つ以上の型を’&’でつなぐだけです。

// Insersection Type
type A = { x: number };
type B = { y: number };
// Point2Dはxとyをメンバーに持つ
type Point2D = A & B;

クラス、インターフェース、type宣言で作成した型など、様々な型を混ぜ合わせて新しい型を作ることが可能です。

白石: こんな機能あったんですね、知りませんでした。

青野: 他にはUnion Typeといって、どちらかの型を排他的に持つ型を作ることもできます。こちらは、二つ以上の型を’|’でつなぐことで作ることができます。

// Union Type
type UnionType = string | number;

白石: Union Typeは使ったことあります。いろんな型を受け取る関数を作るときとかに便利ですよね。

総称型（ジェネリクス）

青野: ジェネリクスは「総称型」とも呼ばれ、型をパラメータ化できるというものです。

総称型は、パラメータ化された型を外から与えられて、初めて実際の型が決まります。

// <T>が型パラメータを表す
class MyArray<T> {
  private arr: T[];
  public push(value: T) { this.arr.push(value); }
}
const numArr = new MyArray<number>();

上の例で言うと「T」がパラメータ化された型ですね。Tは、MyArray型を実際に使っている new MyArray<number>()のところで、number型を与えられています。

また、パラメータ化される型に「ある型を親として持っていなくてはならない」などの制約を設けることもできます。その場合はextendsキーワードを用いて、以下のように型パラメータを記述します。

function fn<T extends {x: number}>(value: T) {
  // valueはプロパティxを確実に持っている
  return value.x + 1;
}

白石: ジェネリクスはTypeScript固有の機能というわけではないですよね。C++やJava、C#など、静的型付けの言語はジェネリクスを備えるものも多い。

Type Guard

青野: Type Guardは、型をインテリジェントに絞り込む機能です。例えば以下のようなコードでは、instanceofやtypeofで判定しているif文のブロック内では、変数をその型だと見なして、キャストせずに利用することができます。

function fn(
  x: Element | number | boolean
) {
  if (x instanceof Element) {
    // console.log((<Element>x).tagName);
    console.log(x.tagName);
  } else if (typeof x === 'boolean') {
    console.log(x);
  } else {
    // console.log((<number>x).toFixed(0));
    console.log(x.toFixed(0));
  }
}

白石: あ、これは知ってますし、よく使いますね。最初この機能を知った時、最近のコンパイラは頭がいいなあ、と感動しました。

青野: さらにType Guardは、開発者が拡張することもできるんですよ。以下のような関数を用意しておくと、if文の条件式でこの関数を用いた時、そのブロック内では変数がstring型として扱われます。

function isString(x: any): x is string {
  return typeof x === 'string';
}
let n = 'a';
if (isString(n)) {
  // キャストせずにstring型として扱える
  console.log(n.toUpperCase());
}

白石: 戻り値の型に<仮引数名> is <型名>と指定するんですね。Type Guardを自作できるとは知りませんでした。

never型

青野: neverという型もあります。neverは決して到達できない、何も代入することのできない型を表します。例えば、必ずエラーをthrowする関数の戻り値型をnever型にしたり、到達することのないコードブロックの変数型がneverになったりします。

// 必ずエラーをthrowする関数
function test1(): never {
  throw new Error('error');
}
function test2(value: string | number) {
  if (typeof value === 'string') {
  } else if (typeof value === 'number') {
  } else {
    // 到達しないブロック
    // ここではvalueはnever型として扱われる
    value
  }
}

白石: なんとなく分かる気はしますが、何の役に立つんですか？これ。

青野: 確かにわかりづらいですよね。voidとの違いがわからないという話もよく出ます。

ただ、以下の例を見るとわかりやすいんじゃないかと思います。例えば後者の特徴（到達することのないコードブロック内での変数型がneverになる）をうまく使うと、より型安全なコードを書くのに役立ったりします。

enum Test { KEY_1 = 1, KEY_2, KEY_3 }
function test(m: Test) {
  switch (m) {
    case Test.KEY_1:
      return 'key1';
    case Test.KEY_2:
      return 'key2';
    default;
      // Test.KEY_3のケースが存在するので、mはnever型ではない
      const check: never = m;
  }
}

白石: なるほど、到達しないはずのコード位置で変数をneverとして扱うコードを書いておけば、コンパイラがコードの到達可能性をチェックしてくれるということですね。

Mapped Type

青野: Mapped Typeは、TypeScript 2.1から入った、比較的新しくてなかなか面白い機能です。この機能を使うと、他の型を元にして、型を動的に定義することができるんです。

白石: だいぶ深い話になってきたな…。型を動的に定義、とはどういうことですか？

青野: 例えば、「あるインターフェースがあって、そのプロパティすべてをreadonlyにした新しい型を作りたい」といった場合を考えてください。

白石: ああ、そういうのはありそうですね。でも、元のインターフェースを継承してもできないし、どうすればいいんですか？

青野: そういう場合TypeScriptでどうやるかというと、まず元のインターフェースのプロパティ名を全て含む型を作るんです。

keyofというキーワードを使うと、型のプロパティ名を全て含む文字列リテラル型を取得できます。

interface MyInterface {
 a: string;
 b: number;
 c: boolean;
}
type AKeys = keyof MyInterface;
// AKeys = 'a' | 'b' | 'c'

青野: そして、以下のように書くことで、全てのプロパティをreadonlyにした型を作ることができます。

・プロパティ名に[P in AKeys]と指定していること ・プロパティの型指定を行うところにMyInterface[P]を指定していること ・全てのプロパティの先頭にreadonlyが付与されること

がポイントになります。

type MyInterfaceClone = {
  readonly [P in AKeys]: MyInterface[P]
};
// MyInterfaceClone = {
//  readonly a: string;
//  readonly b: number;
//  readonly c: boolean;
// }

白石: 元の型のプロパティをループしながら、新しい型を作るような感覚ですね。コンパイル時に、動的な処理を行って型を作っていっているような感覚ですね。

青野: こうしたテクニックを使うと、全部のプロパティをPromiseでラップしたり、null許容型にしたりした新しい型を作るのも容易に行なえます。

白石: いやー、TypeScriptは型の定義方法がとても柔軟ですね…。しかし、だいぶ深いところまできた気がしますね。ぼく普段TypeScript使ってるのに、知らないこともたくさんありました。

青野: いや、実はこのスライドで紹介してるのは、私が重要だと判断したところだけで、TypeScriptにはまだまだ機能があります(笑)。

白石: ええっ、もう頭がいっぱいいっぱいなんですが…。

Variance

白石: もうちょっと頑張ります。ここからは、TypeScriptに今後搭載される予定の機能とかロードマップ、議論されている話について伺っていきたいと思います。

青野: はい、では一つ目の話題は「Variance」です。これは、「ある型と別の型が相互代入可能か」っていう関係性についてのお話です。

例えば、Baseというクラスと、それを継承しているクラスがあったとして、それらの配列と、それらを仮引数にとる関数について、それぞれ相互代入可能かを考えてみましょう。

class Base {
 value = 1;
}
class Derived extends Base {
 otherValue = 2;
}
class Another extends Base {
 anotherValue = 3;
}

以下は配列の場合です。親クラス型の配列（baseAttr）に、子クラス型の配列（derivedArr）は代入できます。これを共変の関係といいます。

親クラス型の配列変数に、子クラスの配列を代入するというのはよくあるシチュエーションです。配列が共変であるというのは、実用上の利便性が高いんです。

（筆者注: Wikipediaの「共変性と反変性」の項目も参照のこと）

declare let baseArr: Base[];
declare let derivedArr: Derived[];
// Covariant 共変
baseArr = derivedArr;
// Contravariant 反変 Error
// TypeScriptでは認められていない
derivedArr = baseArr;

しかし、これらの型を仮引数に取る関数について考えてみましょう。この場合、どちらの方向の代入も成り立ってしまうのです。これを双変の関係といいます。

declare let processDerived: (derived: Derived) => void;
declare let processBase: (base: Base) => void;

// Bivariant 双変
processDerived = processBase;
processBase = processDerived;

// Runtime Error.
processBase(new Another())

つまりTypeScriptは、配列については共変、関数については双変としているわけですが、これは実は型システムに矛盾を生じます（※）。 こうした矛盾はあえて受け入れたものであり、その理由は「配列の共変性」による利便性、実用性を重んじてのことでした（※）。

しかし実は、関数についての双変性をやめ、C#のように共変／反変をin/outパラメータで指定できるようにしてはどうか…という議論が持ち上がっています。

白石: …む、むずかしい…

※ここは、議論が詳細過ぎるため編集上割愛しました。詳しくは青野さんのスライドをご覧いただくくか、なぜ TypeScript の型システムが健全性を諦めているかというna-o-ysさんの記事が参考になると思います。

Unique Symbol型

これからの展望としては、Unique Symbol型ですね。これはconstな変数やreadonlyなプロパティを、クラスやインターフェース、typeのプロパティ名に使うことができます。

const x = "literal name";
const y = 1;
export interface A {
  [x]: string;
  [y]: string;
}

白石: Computed property namesを型宣言時に使えるような感じですね。

青野: ちなみに、ECMAScriptにprotocolという機能を追加するって提案があります。Unique Symbol型とはあまり関連はありませんが、プロパティ名にシンボルを指定するというところから思い出しました。

白石: それはどういうものですか？

青野: インターフェースに近くて、implementsするクラスに実装を強要するものです。複数のプロトコルをimplementsすることもできます。

白石: 型の概念が薄いJavaScriptにも、ついにインターフェース相当のものが！でも、それならinterfaceってキーワード使えばいいのに…。

青野: そうですねー。ただ、目的は似通っていますが、プロトコルは「シンボルの集合」という形で表現されたり、デフォルト実装を提供できたりと、結構違いはあります。

※青野さんがその後書いてらっしゃったブログ記事からの引用ですが、プロトコルは以下のように宣言／実装するそうです。

protocol ProtocolName {
  // 実装が必要なシンボルを宣言
  thisMustBeImplemented;
}
  
class ClassName implements ProtocolName {
  [ProtocolName.thisMustBeImplemented]() {
    ...
  }
}

可変長型

青野: ほかには、可変長型をサポートすることも予定されています。可変長型というのは、言ってみれば配列要素の型をまとめて保持する型です。

...Tのように記述することで可変長型を表すことができます。

function makeTuple<...T>(...ts: ...T): ...T {
  return ts;
}
const ts = makeTuple('a', 1, {x: 1});
// ...T = [string, number, {x: number}]

可変長型のサポートにより、可変長引数を取る関数で引数の型を利用できたり、可変長の型パラメータを実装できます。

また、可変長型はタプルとも互換性があります。

白石: こんなアイデアまであるんですね…ぼくなんか、TypeScriptでタプル使えるの今まで知りませんでした(笑)。セッション内容の、型に関するお話だけでも、すごいボリュームになりました。。だいたいこんなところでしょうか…？

青野: そうですね、他にはStructual Subtyping以外の型システム、例えばNominal Typingなどを許容しよう（※）という話もありますが…まだ実装の同意は取れてない状態ですね。

白石: もうお腹いっぱいです(笑)。大変詳しい話を聞かせていただき、今日はありがとうございました！

こんにちは、編集長の白石です。

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

今回は、「Nintendo SwitchとWeb」という講演をされていた任天堂さんに、Switch開発におけるWeb技術の活用方法や、開発秘話を伺ってきました。任天堂のお二人は京都から、リモートでの取材に応じていただきました。

HTML5 Conferenceのセッション会場は超満員（写真提供: html5j）

任天堂株式会社 企画制作部 フロントエンドエンジニア 堀川雄司氏（左）
企画制作部 ディレクター 津田 宗孝氏（右）
（写真提供: html5j）

Nintendo SwitchではWeb技術が大活躍！

白石 簡単に自己紹介をお願いできますか？

津田 企画制作部ディレクターの津田です。2011年に入社し、Switchでは、各種ネットワークサービス、コンポーネントブラウザーや本体内蔵ソフトのディレクション関係に携わってきました。

堀川 同じく企画制作部で、フロントエンドエンジニアの堀川です。私は2013年に入社し、ゲームソフトのダウンロード販売を行う、Nintendo eShopやゲーム連動サービスなどのWebサービスの開発を行っています。

白石 ぼく全然ゲームをやらないもので、ゲーム機の中身がどうなっているのか全然知らないんです。Nintendo SwitchではWeb技術がかなり使われている、というだけでも驚きでした。

津田 Nintendo Switchには、WebKitをベースとしたブラウザーコンポーネントが搭載されているんですよ。それを、スマートフォンで言うところの「WebView」のように、ゲームや本体内蔵ソフトからブラウザコンポーネントとして使うことができます。

白石 そうなんですか！そのブラウザって、どのように活用されているんですか？

津田 活用の方法としては、まずはスマートフォンとの連携ですね。

例えばいろんな情報を入力する場合など、普段使い慣れているスマートフォンで入力していただくほうがスムーズに進めていただけます。ユーザーも慣れていますし。 なので、例えば「ニンテンドーアカウント」（※）を作成するときとかは、ゲーム機で行うのはメールアドレスを入れるところまでです。 以降の入力の大半はスマホで行えるようになっています。

※ニンテンドーアカウント…任天堂が提供する各種サービスを利用するためのアカウント。インターネット対戦を行う際などに必要とされる

白石 スマホとSwitchで、得意分野を補い合っているんですね。

堀川 ほかには、Switchにはゲームの画面を撮影する機能があるのですが、撮影した画面写真と動画をSNSに投稿する場合などにも、Webの仕組みを使っています。具体的には、クラウド上の中間サーバーにテキストや画像のデータを送信するのに、ブラウザをクライアントとして用いています。

白石 なるほど、そういうクラウドのクライアントとしての処理も確かにWebのほうがやりやすそうですね。

津田 それだけじゃありません。ゲーム内のコンテンツにも、HTMLやCSSなどのWebコンテンツは入っていますよ。 まず気付くことはないと思いますが、普段のゲーム画面でも、Webブラウザで作った画面がさり気なく使われていたりします。

白石 おお、これ途中からWebに切り替わってるんですよね？すごくシームレスで、ネイティブで作られた画面とほとんど区別がつかないですね。 でも、なんでここだけWeb技術を使っているんですか？

津田 いわゆるゲームの画面と異なり、こういった文字の多いドキュメント画面で、特に多言語展開するケースにおいては、ゲームのNativeプログラムで作るより非常に早く開発することができるんですよね。

白石 なるほど、スマホとの連携、クラウドへのデータ送信、多言語コンテンツなど、Webが得意な部分についてはWebを積極的に使ってらっしゃるということですね。

津田 はい。私たちのチームでは「世界中のユーザーとゲームを繋げる」というビジョンがあるんです。その「繋げる」をこれまで以上に大きく広げるために、Webを積極的に使っているという流れです。当日のセッションではこれ以外にも、スマートフォンアプリの「Nintendo みまもりSwitch」や「Nintendo Switch Online」といったアプリでも、Webを様々な形で活用している例をご紹介しました。

Nintendo eShopはReactで作られている！

白石 今回のセッションでは、Nintendo eShopというサービスの構築に関するお話が中心だったそうですね。

津田 はい、Nintendo eShopというのは、Nintendo Switch上でゲームソフトを購入するためのオンラインショップです。Switchを持っていないときにでも、スマホなどからゲームソフトを購入できるようなサービスも提供しています。両者ともWebで作られています。

白石 そういうマルチプラットフォーム的な展開は、Webの最も得意とするところですよね。

堀川 そうです。スマートフォンやPCから見えるところはレスポンシブに作っていて、コードもかなりの部分が共有できています。ゲーム機で操作する場合はボタンでの操作になるので、多少は異なるコードが使われていますけどね。

eShopは、Webアプリとしてはかなり大規模と言って差し支えないレベルだと思いますが、アーキテクチャとしては全体的に統一されています。アーキテクチャの基盤としてはReactを使っています。

白石 おお、Reactが使われてるんですか！Nintendo Switchの中でReactが動いているって、Web技術者としてはちょっと胸が熱くなりますね。 eShopは、どういう流れで作られたんでしょうか？

堀川 プロジェクトの発足は2015年末です。Switchが発売されたのが2017年3月ですから、その1年ちょっと前からプロジェクトが始まったということになりますね。 eShopを作るにあたって私たちがよりどころにしたのは、「すぐに」というキーワードです。

Nintendo eShopを支える、3つの「すぐに」

白石 「すぐに」ですか？

堀川 はい。具体的には「すぐに出会える」「すぐに買える」「すぐに改善」の3つを満たすショップであるべき、と考えて開発に臨みました。

まず「すぐに出会える」というのは、「購入したい商品にすぐに出会える」ということです。 ゲームの魅力を少しでも正確に、多くの方に伝えて、「購入したい」と思っていただきたいということですね。

そのため、以前はショップ内に閉じていたゲームのプロモーションを、Switchの待ち受け画面で表示される「ゲームニュース」に任せることにしました。

UIに関しても全面的に見直し、欲しいゲームにすぐに出会えるようにUIポリシーを再構築しました。

「すぐに買える」というのは、「買いたい」と思ったらすぐに買えるような場所でありたいと思いました。そこで、Switch上の様々な場所からeShopに行くことができるように導線をはりめぐらしました。

堀川 また、ゲームを買おうかなと思って購入画面にいくと、全く別の印象をもった「システム画面」っぽかったりすると、ゲームを買いたいという熱が冷めてしまいます。そこでゲーム画面と購入画面をできるだけシームレスに見えるようなデザインを目指しました。

しかしゲームの数は非常に多いので、そのそれぞれに手作業で背景色を指定したりするのは、非常に骨が折れます。

なので私たちは独自のアルゴリズムで、ゲームの画面イメージから色を自動で抽出し、背景色に指定するという処理を行っています。 私たちはこの処理で抽出したカラーパレットを自動的に生成できるように開発し、ゲームの魅力や個性を尊重しつつ、開発の効率を向上させることに成功しました。

白石 これ、画像の中で一番使われている色を選んでいるというわけでもなさそうですね。ちゃんとゲームの特徴を捉えた色が選ばれている。どうやってるんですか…？

堀川 そこは企業秘密です(笑)。

そしてWebとReactが選ばれた

堀川 最後は「すぐに改善」です。eShopは長期に渡って運営し、成長させていくプロジェクト。

eShopは、数多くの言語や国と地域に対応させていく必要がありますので、言語だけでなく、税率や通貨などの国際化も必要です。 それらの地域で例えば税率が変更されたりしたら、すぐに修正していけるような開発環境を構築していく必要がありました。

そういう改善のしやすさと、長期的な成長の土台を作るために開発環境の選定を行いまして、2015年末に「Webしかない」という決定を下したんです。

白石 確かに、そういう変更と反映のしやすさはWebの利点ですね。

堀川 Webで行くと決まってからは、改善しやすい設計とパフォーマンスを両立させるために、ライブラリの選定を行いました。

使い勝手の面を考えるとシングル・ページ・アプリケーションが望ましかった。 また、Nintendo Switchは「サクサク動く」ことも大事にしていますので、パフォーマンスが良いことも重要です。 そうして、結局私たちが選んだのはReactとReduxの組み合わせでした。

白石 2015年末くらいにそれを選ばれたというのは、かなり新しめの取り組みでしたよね、きっと。

堀川 はい、私たちはその時点で最善と思われる手法を、積極的に採用しています。 Reactを使う場合は、いろんなライブラリを組み合わせて使うのが普通です。以下が、私たちが使っているライブラリの一例です。

白石 Reactを徹底して使われたということがわかります。大規模なWebアプリを作るのに、Reactを使ってみていかがでしたか？

堀川 やはり、コンポーネント指向での開発は、様々な利点があると感じました。コンポーネント単位でのテストは容易ですし、再利用性も向上します。 CSS Modulesを使ったおかげで、大規模サイトにもかかわらずCSS設計が破綻しなかったのも良かったですね。

Nintendo eShop開発秘話（1）: デザイナーとエンジニアの間に溝が！

白石 eShopの開発を行うにあたって、いろんな課題にぶつかったんじゃないかと思うのですが、実際にはいかがでしたか？

堀川 まず開発初期の段階で、コンポーネント指向を巡って、デザイナーとエンジニアの間で溝ができてしまったのは頭を悩ませました。

白石 コンポーネント指向で溝、ですか。

堀川 はい。コンポーネント開発を進める上で何を共通化するのかで、デザイナーとエンジニアの間で感覚が全然違ったんですね。ぼくらは最初、それに気づいていませんでした。

デザイナーはコンポーネントに分割することで、「見た目」「体験」を共通化できるものと考えます。だから、見た目が異なる場合は違うコンポーネントになると考える。

一方エンジニアは、「内部」「機能」を共通化するものだと考えがちです。なので、「価格を表示する」というコンポーネントがあるとすると、それをできるだけ再利用しようとする。

だから例えば、デザイナーが「画面によっては価格を目立たせたいから、違うデザインにしたい」と伝えても、エンジニアは「価格を表示するという機能が共通なのだから、同じコンポーネントで」と考えてしまい、コミュニケーションに溝ができてしまうんです。

白石 「共通化」と言っても、それぞれの立場で重視するものが違うから、「何を共通化するか」の感覚も違ったと。

堀川 そうしたコミュニケーションの溝を埋めるために試行錯誤した結果、結局、全体のモックアップを先に開発することにしました。 このときはReactも使わずに、デザイナーが作ったデザインカンプを元に、プレーンなHTMLとCSSを使って作りました。

こうして、開発するもののイメージを先に合わせておくことで、デザイナーとエンジニアの認識のズレを抑えることができました。

白石 なるほど、ゴールイメージの共有を行うことで、認識のズレが解消されたわけだ。

堀川 そうです。特にeShopは、既存のサービスも既にありましたので、ゴールイメージは共有できているものと何となく思っていたんですよね。問題の原因にはそうした思い込みもあったと思います。

ほかにチーム内の意識を共有するためにやったこととしては、コンポーネントのカタログを作ることですね。Storybookを使用すると、アプリケーション外で動作するReactコンポーネントのカタログを作れます。コンポーネントの動作を簡単に確認できるので、非常に便利でした。

白石 Storybookって初めて知りました。便利そうですねーこれ。

Nintendo eShop開発秘話（2）: 仕様が複雑すぎる！

堀川 次に、eShopを設計するにあたっては、ユーザーストーリー（※）を中心としました。例えばこういうユーザーストーリーです。

※ユーザーストーリー…ユーザーがシステムを通じて達成できることを書き下した文章

白石 なるほど、結構粒度細かいですね。この粒度だと、ユーザーストーリーの数がかなり多くなったのではないでしょうか？

堀川 はい、かなりの数です。ユーザーストーリーはスプレッドシートで一覧にして管理していたのですが、実際にはこんな感じです。

白石 おー、すごい！実際の開発に使われていたスプレッドシートとか見ると、テンション上がりますね(笑) ストーリー以外にも、いろんな情報が書き込まれていますね。

堀川 はい、テストケースや品質目標も、全部ユーザーストーリーを中心に組み立てていったので。

品質目標というのは、「Never（あってはならない）」「Must（できなければいけない）」「Want（あったらいいな）」という項目をストーリーに付与できるようにしたものです。これで、ストーリーに基づくユーザー体験を一定品質で保証できるようにしました。

白石 モックも作って、設計も入念に…って、設計段階で品質を上げようとする努力がすごいですね。

堀川 いえ、まだあります。テスターに早くから協力してもらったのも、eShopの品質の上では重要でした。

eShopは先ほども申し上げた通り、数多くの国と言語を扱わなければなりません。実際にはそれに加えて法律や通貨、決済方法なども考慮に入れて仕様を作っていく必要があります。だから仕様がどうしても複雑になってしまうんですよね。

なので、テストのプロが仕様を決める段階でチェックをするようにして、早い段階で重大な考慮漏れに気付けるようにしたわけです。

白石 このスライドにあるような事柄を、全部エンジニアが一人で考えて仕様に落とすのはさすがに難しいですもんね。

Nintendo eShop開発秘話（3）: 最後は「お祭り」！そして任天堂がWebに期待すること

堀川 リリースまであと半年っていう段階で、大変なことが判明しまして。Switch上で、OSからWebまで統合して動かしてみたら、全然期待するパフォーマンスが出ないし、尋常なく不安定で遅かったんですよ。起動も遅いし、不安定だし。

白石 えー！それはゾッとする話ですね…

堀川 大問題だったので、全チームに呼びかけて助けを求めました。SDK/OSプログラマ、本体アプリプログラマ、ブラウザーエンジニア、サーバエンジニア、デザイナー…。弊社は、多くの関係者が一つの建物にいるので課題の共有が早くできるため、結果的に改善も早くできるのがすごくいいところです。

全員が1つの目標に向かってアイデアを出し合いました。エンジニアは最適化のアイデアを。デザイナーは起動アニメを工夫して、起動待ちのストレスを軽減しました。 まさにこれは「お祭り」という感じでしたね。誤解のないようにお伝えしておくと、お祭りとは「炎上」ではありません。力の結集なんです。

我々はWebサービスを作る上で、フロントエンド、バックエンドだけではなく、ブラウザー、OS、そしてゲームソフトやハードまであらゆる関係者全員の力を結集してプラットフォーム、そしてプロダクト、サービス、コンテンツを生み出しています。非常にダイナミックな体験ができます。

無事、2017年3月、Nintendo Switchの発売にこぎつけることができたのは、こうした全員参加の「お祭り」あってこそだったんです。

白石 Nintendo Switch発売の裏側で、そんなことが起きていたとは、聞いていてちょっと感動的でもありました。もっといろいろお話を聞きたいところですが、残念ながらそろそろお時間になってしまいました。最後の質問です。HTML5Experts.jpはWeb技術者向けの媒体ですので、任天堂さんがWebに期待していることを教えていただけますか？

津田 それはやはり、最初に申し上げた「世界中のユーザーとゲームをつなげる」というビジョンに尽きます。あらゆる人々やあらゆるコンテンツを、デバイスを超えてつなぐことができるのは、Webは最適だと思っています。

堀川 そして、Webの世界は進化が速いですが、ビジョンをより高いレベルで達成するためにも、私たちも常に最善の手法を採用して、より優れたWebサービスを開発していきたいと思います。弊社ではフロントエンジニアを募集しておりますので、一緒に開発してくれる方をお待ちしてます。

白石 本日は、大変興味深いお話をどうもありがとうございました！

堀川/津田: こちらこそ取材いただきまして、ありがとうございました。

こんにちは、編集長の白石です。

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

今回お話を伺ったのは、freeeの伊原力也さんと、ビジネス・アーキテクツの太田良典さんです。

お二人のセッション「多様なユーザーニーズに応えるフロントエンドデザインパターン〜書籍「インクルーシブ HTML + CSS & JavaScript」より」に関するスライド資料は、こちらで公開されています。

「インクルーシブ」に込められた意味とは？

白石: 今回は取材をお受けいただきありがとうございました！簡単に自己紹介をお願いします。

太田: ビジネス・アーキテクツに所属している太田です。大規模企業サイトの構築、ガイドライン策定などを行ってきました。

Webアクセシビリティ関連に昔から取り組んでいまして、「Webアクセシビリティ基盤委員会」の翻訳作業部会主査を担当しています。

▲株式会社ビジネス・アーキテクツ 太田良典さん　　※写真提供：html5j [HTML5 Conference 2017事務局

伊原: freee株式会社の伊原です。Webサイトやアプリケーションの情報設計を行っています。私もWebアクセシビリティ基盤委員会に所属しており、「理解と普及作業部会」にて活動しています。

他には、HCD-Netという人間中心設計を推進する団体でも活動しており、UXデザインの普及に務めています。

▲freee株式会社 伊原力也さん　※写真提供：html5j [HTML5 Conference 2017事務局

白石: 本日は、HTML5 Conferenceでお話された内容を主にお聞きしたいのですが、このセッションは、今度出版される書籍を元にしてらっしゃるんですよね。

伊原: はい、11月4日に出版される「インクルーシブ HTML + CSS & JavaScript」という書籍の内容をベースにしています。

私たちは2年ほど前にデザイニングWebアクセシビリティという書籍を、その半年ほど前にはコーディングWebアクセシビリティという書籍を上梓しました。

今回のセッションの元になった書籍は、いわばそうした流れを組んだ最新のものだといっていいと思います。特にコーディングWebアクセシビリティとは、著者も同じヘイドン・ピカリング氏ですし、続編といって差し支えないかと思います。

白石: では、今回もWebアクセシビリティに関する書籍なんですね。

太田: そうです。「コーディングWebアクセシビリティ」では特に、WAI-ARIAの使い方について詳しく論じられていました。WAI-ARIAの基本的な知識はあっても、「なぜそう書くのか」「いつどう使うのか」を知らない方に向けて、具体的な例を挙げつつ語った本です。

白石: では、今回の書籍は「インクルーシブ HTML + CSS & JavaScript」となっているわけですが、これはどういう内容の本なのでしょうか？

伊原: 原著のタイトルは「Inclusive Design Patterns」と言うのですが、サブタイトルは「Coding Accessibility Into Web Design」（Webデザインの中にアクセシビリティをコーディングする）となっていて、こちらの方がわかりやすい(笑)。

ぶっちゃけて言えば、アクセシビリティに配慮したコーディング例を具体的に挙げていっているという本です。

原著者がなんで「インクルーシブ」という単語を用いたかというと、「アクセシビリティ」というと、「アクセシビリティガイドラインを満たしていくこと」とか、「特定の障害を持つ人に向けた配慮」というニュアンスが強く根付いてしまっているからだと言っています。

また、「アクセシビリティ」という言葉自体には、デザインや設計という意味は含まれていない。アクセシビリティとは単に「アクセスできる可能性の度合い」のことですから。

一方でインクルーシブというのは「包括的」とか「全てを包む」といったニュアンスを含む英単語で、「できるだけ受け入れる」とか「できるだけ含める」という意味合いがあります。原著者が「インクルーシブ」という単語を用いたのは、「できるだけ多くの人に使ってもらえる」「できるだけ多くの状況で使える」ものをデザインしていこう、という意図なんです。

太田: ただ、日本語版では元のタイトルにある「デザインパターン」という言葉は使いませんでした。Web制作の世界では、「デザインパターン」と言う単語からはWebデザインを想起してしまいがちなので…。

アクセシビリティにおいては、そういう（UI）デザインのニュアンスだけが強いわけではありませんからね。

白石: 「デザインパターン」という単語は、エンジニアの方であれば逆に馴染みはあるかもしれませんね。

しかし、「コーディングWebアクセシビリティ」や「デザイニングWebアクセシビリティ」という書籍がありながら、今回新しい書籍を出版されたのはどういう背景があるのでしょうか？

太田: ここ10年くらいで、JavaScriptを用いた動的なUIがすごく普及しました。Ajaxがその立役者で、JavaScriptを利用して非同期にUIを書き換えるような作り方が一般的になってきました。

おかげで、WebサイトのUXは全般的に向上しましたが、一方で、アクセシビリティ的には新たな課題を抱えることにもなったわけです。元々、HTMLはアクセシブルに設計されているのに、JSがそれを損なってしまうケースが散見されるようになったのです。

例えばフォーム送信などは良い例です。昔ながらのフォームで、「送信」ボタンを押したら次のページ…という流れであれば、アクセシビリティに問題はあまりありません。ただこれを、JavaScriptを用いてAjaxでデータ送信するようにした途端、アクセシビリティが低下してしまうことが多い。

伊原: そもそも、JSで「アプリ」を作ろうとすると、アクセシビリティへの配慮がされにくくなりがちです。ほとんどdivやspanでマークアップして、見た目上動けばOK…という場合が少なくありません。

それを、セマンティックなHTML要素とWAI-ARIAを活用して、アクセシブルでUXにも優れたWebアプリを作ろうというのが、この「インクルーシブ HTML + CSS & JavaScript」で述べていることです。

実践！アクセシブルな商品リストを作ってみる

白石: では、アクセシブルなマークアップの具体的なパターンを幾つかお話いただきたいと思います。

ただ、セッションの内容全体についてはスライド資料をご覧になってもらえればいいと思うので、ここでは、私が個人的に疑問に思ったことなどを遠慮なくツッコませていただきつつ、ポイントとなる部分をおさらいしていっていただけると嬉しいです。

伊原: わかりました。では一つ目の例として、商品リストを見ていきます。

このサイトは画像アセットを購入できるサービスという想定ですが、UIデザインについては、Amazonの検索結果のようなものを想像して頂ければいいと思います。

リストの項目それぞれは商品名やレビュー結果、そして「すぐに購入」ボタンなどがあります。

これが複数縦に並んでいるリストをイメージしてください。

白石: こういう一覧の実装方法っていろいろですよね。個人的には、単にdivを並べるときもあれば、表っぽければtableを使うときもあります。

伊原: まず、リストそのものはリスト要素（ulやol）を使ってマークアップした方がいいかなと思います。

ここでリスト要素をお薦めするのは、要素の意味合いがわかりやすいのと、スクリーンリーダーがリストを読み上げるのに特別な機能を持つからですね。

太田: 例えばスクリーンリーダーは、リストの項目数を先に読み上げたり、前後のリスト項目にジャンプしたりできるんです。項目数って結構大事で、項目数が多い場合と少ない場合では、ユーザーの行動も変わってきますからね。

白石: なるほど。

伊原: また商品名ですが、見出し要素を使用するのが最適です。スクリーンリーダーは見出しに直接飛んだり、直前の見出しを読みあげたりすることもできる。 リストと見出しを組み合わせることで、一覧の見出しを飛ばし読みしていくようなことが可能になるんです。

まとめると、以下のようなマークアップがおすすめですね。

<li>
  <h3>
  ガソリンスタンドにたたずむ裸の男 <a href="/artist/kenny-mulbarton">by <cite>ケニー・マルバートン</cite></a>
  </h3>
</li>

白石: liの中に見出し要素を置くと、リスト項目が全て個別のセクションということになりますが、それは問題ないんでしょうか。HTML5からは、見出し要素は暗黙的にセクションを構成するようになりましたよね。

太田: はい、確かにセクショニングアルゴリズムの観点から、liの中にh3を入れることを望ましくないと考える人もいるかもしれません。ここは意見が分かれるところでしょうね。 ただ、アクセシビリティの観点からは支援技術で実際に使えるかどうかが重要で、その意味では十分に実用的だと言えると思います。

「今すぐ購入」ボタンはボタンにする？それともリンクにする？

伊原: 次は、「今すぐ購入」ボタンをどうマークアップするかを検討してみましょうか。

白石: うーん、これはbutton一択じゃないですか？

伊原: それもアリです。buttonを使うケースとしては、JavaScriptと組み合わせて、購入処理をその場で行えるようにするような場合ですね。

でもこの例のサイトは一般的なプリント写真購入サイトをイメージしているものなので、「今すぐ購入」ボタンを押したら、写真の購入確認画面に飛ぶことになります。

白石: そうなると、写真の購入確認画面へのリンクとして実装したほうが良さそうですね。

伊原: はい、そのほうがJavaScriptがなくても動きますし、要素の意味合いも明確になります。ここではa要素を使いましょう。

以下のようなマークアップがまずは望ましいですね。

<a href="/product/naked-man-in-garage" class="button">今すぐ購入</a>

白石: このマークアップだと、class="button"となっていますし、CSSで見た目をボタンっぽくするイメージですね。例えばWAI-ARIAを使って、このリンクのロールをボタンにするというのはいかがでしょうか？

<!-- role要素でbuttonを指定 -->
<a href="/product/naked-man-in-garage" role="button">今すぐ購入</a>

伊原: あ、それはやめてください。これでは、元のHTML要素が持つセマンティクスが変わってしまい、この要素はリンクではなくボタンであるという意味合いになってしまいます。

白石: なるほど、ここでは見た目だけボタンにしておいて、セマンティクスは変えないのが望ましいと。

太田: そうなんです。WAI-ARIAって覚えると濫用されがちな技術でもありますが、基本的には「WAI-ARIAは使わない」のが正しい。

W3Cの「Using WAI-ARIA」という文書の先頭に書いてあるのは、「（HTMLでまかなえる場合は）WAI-ARIAは使うな」なんですよ(笑)。

例えばボタンや見出しがあったとしたら、素直に<button>や<h1>を使えば良い。WAI-ARIAを使う必要は必ずしもないんです。基本的にはHTML5の語彙を用いて、足りないところをWAI-ARIAで補う、という形が望ましい。

リンクテキストにも配慮しよう！

伊原: あともう一つ考えてみたいのは、リンクテキストです。このままだと全てのリンクが「今すぐ購入」になってしまいますが、それってアクセシビリティに優れていると言えるでしょうか？

白石: うーん…見出しに商品名はあるので、全くアクセシブルじゃないとは思いませんが。リンクテキストも読み上げられるんですよね？全部が「今すぐ購入」じゃ不親切かも？

伊原: そうです。「何を購入できるか」が、リンクテキストから分かると、よりアクセシブルですよね。

なので、非表示のテキストでリンクテキストをより詳細化すれば、UIデザインも損なわれません。

<a href="/product/naked-man-in-garage" class="call-to-action">
  <span class="visually-hidden">ガソリンスタンドにたたずむ裸の男を</span>今すぐ購入
</a>

白石: なるほど、不可視のテキストも利用してより説明的にするとは…！アクセシビリティへの配慮を真面目に考えてないと、まず出てこない発想ですね。

伊原:ちなみに他にもやり方はいくつかありますが、この本ではSEOにおける内部対策的な意味合いも込めて、このやり方が推奨されています。

検索結果ページ（SERP）にも配慮する

伊原: 最後に、検索エンジンの結果ページで商品（Search Engine Result Pages）がどう見えるか、についても配慮した方がいいでしょう。

白石: 検索結果ページですか？なんでですか？

伊原: 支援技術ユーザーの中には、目的のページに辿り着くために、検索エンジンのインターフェースを利用する人も多くいるんです。Google検索って、site:を前につけるとサイト内検索を行えるじゃないですか。

白石: ああなるほど。言われてみれば、ぼくもAmazonの中検索するのに、Google検索をよく使います(笑)。

伊原: 例えばマイクロデータとschema.orgを使えば、検索結果の表示をより充実させることが可能です。以下に、商品のレビュー結果を表すマークアップの例を示します。

<span itemprop="aggregateRating" itemscope itemtype="http://schema.org/AggregateRating">
<span itemprop="ratingValue">4</span>つ星、
レビュー数<span itemprop="reviewCount">13</span>
</span>

白石: そうか、今までぼく、「マイクロデータ使っとけば検索結果ページで目立てるかな」くらいしか考えたことなかったんですが、アクセシビリティの点から考えても重要なんですね。あんまりちゃんと意識したことなかったです。

見た目ではなく機能でマークアップせよ！

伊原: では次の例に移らせてください。表示結果を絞り込んだり並び順を変えたりするUIを実装してみたいと思います。

白石: うーん、こういうの実装するんだったら、ぼくだったらどうするかなあ。ナビゲーションメニューみたいなものと捉えて、リストとa要素とかでやるかもしれません。

伊原: それも悪くないのですが、このメニューって、どれかが選択中の場合は他のメニューを選択できませんよね。それってどうします？

白石: …JavaScriptのお世話にならざるを得ないかもしれません。

伊原: そう、でも、標準のHTMLには、そういう「排他的」な選択を行うためのフォーム要素があります。

白石: …ラジオボタン、ですか？

伊原: そのとおりです！

このデザインだけからだと、見た目はラジオボタンとは似ても似つきませんが、ここではラジオボタンを使うことにします。マークアップの段階では、見た目ではなく機能に沿ってマークアップするのが重要ですから。

ラジオボタンのスタイリング…やりにくい！どうする？

白石: でも、ラジオボタンは「◎」みたいな余計なUIがくっついてきちゃいますよね？しかもあれがブラウザごとに異なる上、どのブラウザのデザインもあんまりカッコよくない(笑)。

伊原: そうなんです。ラジオボタンってスタイリングしにくいので評判が良くないですよね(笑)。だから、結局他の要素を使っちゃう…なんてことも起きちゃうんですが、そこは工夫次第です。

ここではlabel要素をうまく使って、目標とするデザインを実現しましょう。label要素は、それ自身をクリックすることで、対象となるラジオボタンやチェックボックスの状態を変更できますよね。

白石: ああ、なるほど！labelはクリッカブルな状態で表示しておいて、ラジオボタン本体は隠しちゃえばいいんだ。

伊原: そうです。labelさえあればラジオボタンのクリックは可能ですので、実際のラジオボタンは隠しちゃってもいいんですよね。ラジオボタンのフォーカス状態やチェック状態はCSSの擬似クラスで指定できますので、CSSだけで表示の切り替えが可能です。

例えばこんな感じになります。

<input type="radio" name="sort-method" id="most-recent" checked />
<label for="most-recent">新着順</label>

<input type="radio" name="sort-method" id="most-popular" checked />
<label for="most-popular">人気順</label>
...(略)...

[type="radio"] + label {
  cursor: pointer;
  /* その他、基本のスタイル */
}
[type="radio"]:focus + label {
  /* フォーカス時のスタイル */
}
[type="radio"]:checked + label {
  /* 選択時のスタイル */
}
/* ラジオボタンを見えなくする */
.sorter [type="radio"] {
  position: absolute !important;
  width: 1px !important;
  height: 1px !important;
  padding:0 !important;
  border:0 !important;
  overflow: hidden !important;
  clip: rect(1px, 1px, 1px, 1px);
}

白石: なるほど、これならHTMLのセマンティクスもわかりやすいし、JavaScriptもいらない。素晴らしい。

伊原: ちなみに、このCSSの!important連打は「とにかく扱いづらいラジオボタンを消し去ってやりたい」という原著者のジョークなので、真似しないでください(笑)。

無限スクロールはやっぱり×？「もっと読む」はどう実装するか

伊原: 最後に、検索結果が複数ページに渡る場合、どういう風なUXが望ましいかを考えてみたいと思います。昔よく使われていたのはページングですが、今は無限スクロールを採用するサイトも多いですね。

白石: はい、ぼくも自社で運営しているTechFeedというアプリで無限スクロールを採用しています。

伊原: ただ、アクセシビリティ的には無限スクロールは使わないほうが無難です。

白石: えっ！いろんなサイトが採用しているし、使いやすいとも思うんですが…

伊原: 理由はいくつかあります。

まず、スクロールという操作が読み込みを誘発することが、ユーザーにとって望ましいことなのかどうか。ユーザーは次のページ読み込みを望んでいないかもしれないですよね。

あと、スクロールバーを使っているユーザーは、新たなページが読み込まれた瞬間スクロールバーが勝手に上下するので、混乱します。

最後に、ページのフッターにたどり着けないことがあります。フッターに要素を置いているにもかかわらず、無限スクロールがあるものだから、フッターに触りたくとも触れない…という事態が起こりうるのです。

白石: ふむ、理由はわかります。では、代わりにどうデザインすべきだと思いますか？

伊原: ページ読み込みをユーザーが制御できればいいので、「もっと読む」ボタンを明示的に設置するというのは一つの解決策ですね。

白石: でも、いちいちそのボタンを押さなくちゃならないというのも結構面倒な気がします…。あと、サービス事業者側としては、無限スクロールでどんどん下に読んでいってもらうことで、ユーザーの滞留時間を伸ばしたいという気持ちもあると思うんですよね。

伊原: この本では、ユーザーが「もっと読む」ボタンをよくクリックするようなら、その時に改めて「続きを自動的に読み込むか」を尋ねるようにするというやり方が紹介されています。その質問に「YES」と答えるのなら、そのユーザーにとっては、先ほど挙げられていた無限スクロールのデメリットが気にならないという証拠でもあると。

白石: なるほど。確かにそのほうがユーザー本位でもありますね。

太田: あとこういう動的にリストを追加する場合、アクセシビリティの観点から一点注意点があります。

読み込みが完了したら、新しく読み込んだデータの先頭にフォーカスを移すことです。そうしないと、スクリーンリーダーのユーザーが、次にどこに行けばいいかわからなくなってしまいますから。

そのために、新たに読み込んだデータの先頭にtabindex="-1"を指定しつつ、JavaScriptでフォーカスを与えます。

...
<li>
  <!-- tabindexを指定して、タイトルをフォーカス可能にする -->
  <h3 tabindex="-1">
    ガソリンスタンドにたたずむ裸の男<a href="/artist/kenny-mulbarton">by <cite>ケニー・マルバートン</cite></a>
  </h3>
  ...
</li>
<li><!-- 新たに表示された商品の2番目 --></li>
...

白石: おお、こういう配慮は全く考えていませんでした。勉強になります。ちなみに、tabindexにマイナス値を指定することなんてできるんですね…知りませんでした。

太田: tabindexにマイナスを指定すると、ユーザーはそこにフォーカスを当てられないのですが、スクリプトでなら当てられるようになります。

「アクセシビリティは0点か100点っていう話じゃない」

白石: 本日は、いろんな例についてマークアップを考えられて面白かったです。

ただ最後に質問があります。

最近のWebアプリはどんどん動的になっていて、「UIのほとんどをJavaScriptで構築する」という場合も少なくありません。Single Page Applicationなんかはその最たるものだと思います。

こうしたサイトでも、アクセシビリティを担保することは可能なんでしょうか？相当の工数をかけないと難しいんじゃないかという気がしているのですが。

伊原: 確かに、SPAのアクセシビリティは面白いテーマです。ただ、SPAだからアクセシビリティの担保が難しいということはないと思います。

というのも、Google DocsやGoogle SlidesはWAI-ARIAにかなり対応していて、コンテンツの読み上げに対応しているんですよ。

白石: え、そうなんですか！それらのアプリ、SPAの代表格みたいなもんだと思ってました…。「SPAはスクリーンリーダーになじまないんじゃないか」なんて思ってましたが、それは単なる思い込みですね。

伊原: どんなサイトでもまずは一回、スクリーンリーダーで読み上げを行ってみることをお勧めします。SPAであっても、意外なほどスクリーンリーダーが綺麗に読み上げてくれることもありますので。

太田: 私はいつも言っているのですが、アクセシビリティって0点か100点かだけではないんです。全くアクセスできないサイトもなければ、全世界のすべての人がパーフェクトにアクセスできるサイトもありません。全てのサイトがその中間のどこかに位置していて、少しでもよくしていこうという考え方が大事だと思います。

伊原: 「アクセシブルかどうか」はちょっとした改善で大きく変わったりもするものです。

例えば先日、とあるサイトをスクリーンリーダーで読み上げてみたのですが、ほとんど問題なく使える。ただ一点、そのページで一番重要なラベルだけ読み上げてもらえないんです。こういう点を改善するだけで、アクセシビリティはぐっと向上する。

なので、まずはアクセシビリティ上の問題を特定し、問題の重要度を判断して、重要なところから対応していく…という現実的なアプローチが、アクセシビリティを向上させていく上では大事だと思っています。

白石: 本日は、いろんなお話を聞かせていただき、ありがとうございました。

こんにちは、編集長の白石です。

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

今回お話を伺ったのは、東京理科大学4年の石井翔さんです。

石井さんのセッション「WebGLの今とこれから ~今のWeb開発で使うからこそ知っておきたい周辺技術~」に関するスライド資料は、こちらで公開されています。

スライド資料 （注: 重いのとモバイルから見えないのはご容赦ください by 石井翔さん）

WebGLの現状

白石: 本日は取材をお受けいただいてありがとうございます！簡単に自己紹介をお願いします。

石井: 東京理科大学4年生の石井 翔です。昨年、私が進めているGrimoire.js（注: モバイルからだと多少レイアウトが崩れます by 石井翔さん）というプロジェクトが未踏IT人材発掘・育成事業に採択され、スーパークリエータに認定されました。

白石: Grimoire.jsはWebGLのライブラリですね。Grimoire.jsについてもあとでお聞かせ願いたいのですが、まずはWebGLの概要や現状についてお話いただけますか？

石井: WebGLは、一言で言えばWeb上で3Dコンテンツを扱うための技術です。2010年に仕様が策定されており、既に多くのブラウザで実装されている技術です。ブラウザ上でどの技術が使えるかを測定するCan I Useでの結果を見ても、92%以上のブラウザがサポートしていて、広く使える状態にあると言っていいでしょう。

ただこれは、WebGL 1.0の話です。WebGL 2.0はまだまだですね。ChromeとFirefoxだけが対応しているという状態で、特にiOSで使えないのが厳しいです。「ブラウザを限定すれば使える」という状態です。

白石: WebGL 1.0と2.0って何が違うんですか？…ぼく、3Dプログラミングが全然わかってないので、理解できるか自信がないのですが(笑)

石井: 浮動小数点テクスチャなどがWebGL 2.0の主な機能ですが、3Dプログラミングの知識がない人に向けて話すのはちょっと難しいですね(笑) とりあえず、ライブラリ作者なら知っておくべきですが、ライブラリのユーザーはそれほど気にする必要はないかと思います。 ライブラリ作者も、WebGL 2.0が使えない環境では1.0にフォールバックするように実装していることが多いでしょうし。

（筆者注: WebGL 2.0の強化点についてはQiitaで良い記事を見つけました。ぼくにはちんぷんかんぷんですが…）

白石: なるほど、あまり気にしなくていいと(笑) 安心しました。

石井: 3Dをご存じない方にとって大事なのは、そもそもWebGLとはGPUを扱うための技術だということをしっかり理解しておくことです。

CPUは、CPUは複雑な処理を逐次的に処理することを得意としています。CPUの場合はコアの数が4とか8とかに限られていることが普通です。

一方GPUの場合は、「異なるデータに対して同じ処理を施す」のを並列で実行するのに特化しています。なのでGPUは、コアの数が1,000を超えることも普通です。 こうした特徴を持つGPUだからこそ、大量の頂点を移動する処理など、3Dプログラミングに必要とされる「単純な処理の並列実行」に向いているんです。

白石: こうした特徴は、最近だと機械学習の分野とかにも活かされているんですよね。単純なベクトル計算とかが多いから。

石井: そうです。で、WebGLってそもそもOpenGL（※）と同じなので、CGの取り扱いに関しては共通している部分がほとんどです。ただ、置かれている環境は、OpenGLネイティブのゲームやアプリとは随分違う。

一番違う点は、WebGLは必要とされるリソースが全部Web上にあって、ダウンロードが必要という点です。モデルデータの読み込みに時間がかかるんですよね。

だから今まではゲームなど、「読み込みに時間がかかりそうだ」とユーザーも了解しているコンテンツが多かったんです。でも、本来使うデータをしっかり選べば短いロード時間で使えるものも多いんですよ。シェーダーアートとか。

※OpenGL（オープンジーエル、Open Graphics Library）は、クロノス・グループ (英: Khronos Group) が策定している、グラフィックスハードウェア向けの2次元/3次元コンピュータグラフィックスAPIである（Wikipediaより引用）

白石: 確かに、WebGLでできたゲームとか、読み込みに数分待たされるものもありましたね。

石井: はい。モデルデータが大きいと、それだけダウンロードやデータ読み込みに時間がかかってしまう。なので、そうしたWebGLの問題を解決すべく、CGの世界にも進化が起きようとしているんです。

ランタイム向け3Dデータフォーマット「glTF」

白石: 具体的にはどのような進化ですか？

石井: 一つはglTF (GL Transmission Format) と言って、汎用的な3Dアセットフォーマットです。ツールに依存しない軽量フォーマットとして、Khronosが普及を進めています。

glTF

白石: ツールに依存しない、というのはどういう意味ですか？

石井: 以前WebGL上でモデルファイルを扱う際には、MayaやBlenderといったツールのファイルをそのまま読み込んで利用することが一般的でした。これは言わば、「Photoshopのpsdファイルはあるけど、jpgやpngなどの汎用的な画像フォーマットがない」という状況です。

白石: そんな状況だったんですね…知りませんでした。ゲームやアプリとしてひとまとめにパッケージングしてしまうから、汎用フォーマットが必要とされなかったんでしょうか。

石井: 概ねそういうところです。そういう状況を変えようと、COLLADAという汎用フォーマットがKhronosによって提案され、一定程度普及はしています。

ただ、COLLADAファイルはCG編集ツール間でデータをやり取りするためのフォーマットとして設計されているため、WebGLアプリケーションが読み込んで利用するには、編集用のパラメーターなど不要な部分も多いんです。また、XML形式だというのも、ファイルサイズや解析速度の点で不利になります。

glTFは、COLLADAファイルから編集用のパラメータを取り除いて、JSON形式にしたものと言ってほぼ差し支えありません。

白石: なるほど。ただ、そういうフォーマットって、普及させるのがなかなか大変な気もしますが、どうなんでしょう？

石井: glTFは既に様々なライブラリにもサポートされていますし、普及は中々順調と言えると思います（参考: glTFのライブラリサポート状況）。

glTFの面白いところは、大手ベンダーの採用意欲が高いというところです。MicrosoftやAutodeskという大手ベンダーが乗っかってきているんですよ。 Khronos自身WebGLの仕様策定元なので、この分野で発言力が強いこともあります。また、最近ではApple WatchのページでglTFが使われてたりもします。

白石: Apple Watchの公式サイトでもですか！それはかなりの人がアクセスしたでしょうね。確かに、これ単なる画像じゃない。スクロールと共に水滴が別々の動きをしてる…！（重いけど）

Apple Watch Series 3のサイト

石井: glTFは「オーディオにおけるMP3, ビデオにおけるH.264、画像におけるJPEG」といったように、「3DといえばglTF」となることを目指しているとのことで、普及にかけるKhronosの意気込みも並々ならぬものがあります。

頂点データ専用の圧縮形式「draco」

石井: もう一つ注目の技術としては、Googleがオープンソースで開発しているdracoという圧縮形式です。頂点データを効率よく圧縮する技術で、元々の頂点データのサイズに比べて4倍から16倍の圧縮率を誇ります。

白石: 先ほどのglTFにしか使えないんですか？

石井: いえ、汎用的なポリゴンデータ形式（.ply）に対応しているので、元のファイルフォーマットは選びません。

白石: ブラウザによる対応も必要なんですか？

石井: いえ、ブラウザがネイティブ対応するというものでもないんです。dracoによって圧縮されたポリゴンデータは、JavaScriptでデコードすることができます。

白石: なるほど、アプリケーションが自前で圧縮データを展開するんですね。でもそれだと、デコード処理にかかる時間がちょっと心配です。

石井: WebAssemblyでできたデコーダーもあるし、Web Workersで展開すればUI処理を阻害することもないので、そこはあまり問題ないと思いますよ。使うブラウザを選ぶということもありませんし、Three.jsのようなライブラリに任せてしまえば、アプリケーションはデコードについて意識する必要もありません。

白石: ほかには、Webだと画像のサイズを結構気にしたりしますが、CGの世界ではどうなんでしょう？

石井: CGだと、テクスチャ画像のサイズを削減するという話になりますね。ただ、単に画像のファイルサイズを小さくするだけでは片手落ちなんです。 いくら元画像のファイルサイズを小さくしても、GPUに乗るときにはフルサイズにデコードされてしまうので、メモリ使用量などにすごく影響するんですね。

なので、GPUが直接扱えるテクスチャ圧縮形式というものがありまして、それらを利用すると、GPU上でも圧縮した状態で画像を扱うことができます。DirectXだとS3TCという形式、iOSだとPowerVR Texture Compression (PVRTC) というように、ベンダーごとに異なってくるんですが。

白石: ベンダーごとに異なるんだと、取り扱いが面倒ですね。

石井: はい、なのでこういうフォーマット変換はWebpackなどで自動化されるべきだと思います。このように、今まではエンジンが自動的に行なってきたことも、WebGLの場合はプログラマーが自分で意識しなくてはなりません。

白石: まとめると、3DをWeb上で行うためにはいろいろな課題があって、それが徐々に解決されつつあるということですね。汎用モデルフォーマットが普及しつつあり、頂点データの圧縮ツールも登場した。そして、テクスチャ圧縮も自動化されるだろうと。

石井: そうです。そもそもWebは、多様なデバイスがネットワークで繋がれていることが前提です。そういうユビキタスな環境で、3Dが自由に表現できる世界に向けて、今まさに具体的で重要な進化が起こっているということです。

WebGLの未来

白石: こうした動きを踏まえて、WebGLの未来はどうなると思いますか？

石井: 今のコンピューターの世界は、やはり2Dを前提としているのは間違いありません。3Dが利用されるシーンは、ゲームなど、コンピューティングのごく一部に限られていました。マテリアルデザインなども、3Dの要素をうまく取り入れてはいますが、前提は2Dです。

ただ、今、GoogleやApple、Microsoftなどの強力なベンダーたちが、こぞってARやMRに力を入れています。このまま進めば、映画館や不動産屋さんとか、あらゆるお店の軒先にARのオブジェクトが浮いている…という世界は普通に来るんじゃないかと思っているんです。3Dがより身近になる世界です。

ただ、そういうのを見るために、わざわざアプリをインストールするのは面倒ですよね。近い将来、そういう面倒くささが、AR/MRの普及を妨げる大きな一因になってくるんじゃないかと思うんです。

しかしWebGLがそういう状況を打開できるんじゃないか、と期待しています。WebGLはWebブラウザさえあれば動きます。PCでもスマホでも動く。アプリのインストールが必要ないし、しかも安全なサンドボックス上で動きます。

白石: 確かに！もしかすると、ビーコン技術との組み合わせとか（※）で、アプリのインストールを必要とせず、気軽にバンバンARコンテンツを見るような時代が来るかもしれませんね。

※Webとビーコン技術との組み合わせとして、Eddystoneという仕組みがGoogleから考案されている

石井: 実際、GoogleがWebARという仕様を作ったりもしていますし、ARには各社力を入れているので、Webでも早晩ARが使えるようになるだろうと思います。

白石: でも実際、要素技術が揃っているだけでは世の中変わらない…という現実もあるかと思います。WebGLも、実際には随分前から使えるようになっていたわけですし。こういう「要素技術が揃っているだけでは越えられない壁」は、どうやったら超えられると思いますか？

石井: 難しい問題ですが、一つは3Dコンテンツの制作コストが高いというのも、普及を妨げる要因にはなるのかなと思います。ただそれは、「人が作る」ことを前提とするからコストが高くつくんだと思うんですよね。

そういう点では、2Dに関しては既にPaintsChainer（AI技術を使い、線画を自動で着色するサービス）やMakeGirlsMoe（AIで自動的に萌えキャラを作成するサービス）のようなサービスが出てきています。同様に、自動で3Dコンテンツを生成するようなサービスも近いうちに登場して、コンテンツの制作コストが劇的に下がるんじゃないでしょうか。

白石: AIサービスでコンテンツの制作コストが激減するというのは面白い発想ですね〜

石井: Adobe Senseiも最近話題になっていますし、デザインの一部をAIに任せるというトレンドが来つつあるのは確実かなと思いますね。

Grimoire.jsは、WebGLをWebエンジニアにとっての「筆」にする

白石: では最後に、開発を進めていらっしゃるGrimoire.jsについても、簡単にご紹介頂けますでしょうか？Three.jsなどのライブラリとは何が違うんでしょう？

石井: Grimoire.jsはWeb開発の中でWebGLを扱うためのフレームワークです。Three.jsやBabylon.jsは、発想がCG中心なんですよね。画面全体をCGで構築するようなコンテンツにはいいのですが、Webコンテンツと混在させて、相互がやり取りするようなプログラムを作るには適していないんです。CGとWebには大きな隔たりがある。それに決められた構造を両者に与えて橋をかける必要があった。

この隔たりは、プログラミングスタイルにも大きく表れてきます。

CGの場合は、フレームごとにグラフィックを変更させていく、いわばフレーム指向です。
一方でWebの場合は、イベントに応じて処理を行うのが普通ですよね。いわばイベント指向です。
こうした隔たりがあるせいで、CG側とWeb側が、お互いにどうデータを受け渡しすればいいか、正解がないというのが今の状況です。

Grimoire.jsは、CG側とWeb側の、2つのAPIを提供することで、両者がシームレスに同居するようなアプリケーションを簡単に作ることができるように設計されています。

白石: 具体的にはどのようなコードになるんでしょう？

石井: Grimoire.jsは、GOMLという専用のマークアップ言語でCGを記述することができます。そして、GOMLの要素を変更することで、簡単にCGを変更できるんです。例えば、立方体にテクスチャを貼り付けて、自動的に回転するようなCGは以下のようなマークアップで簡単に実現できます。

<goml>
  <scene>
    <camera></camera>
    <mesh texture="logo.png" geometry="cube">
      <mesh.components>
        <Rotate speed="1,1,1" />
      </mesh.components>
    </mesh>
  </scene>
</goml>

そして例えば、マウスが重なった時だけこの立方体が2倍の大きさになる…という処理は、以下のようなJavaScriptで実現できます。

gr(function() {
  var mesh = gr('#simple .canvas')('mesh')
  mesh.on('mouseenter', function () {
    mesh.setAttribute('scale', '2.0')
  })
  mesh.on('mouseleave', function () {
    mesh.setAttribute('scale', '1.0')
  })
})

白石: おお、簡単ですね！これならWebエンジニアでも簡単に扱えそうです。

石井: はい、そうなんです。イベントを受けてパラメーターを書き換えるという流れは、今のWebアプリケーションフレームワークなどの潮流を見れば古い感じを受けるかもしれませんが、結局のところこれだけあればいくらでもラップすることができます。そのようなモダンなWeb開発の環境でもシームレスに環境を選ばず導入できるんです。Grimoire.jsの目標は「WebGLを、Webエンジニアにとっての『筆』にする」ことなんです。

一方で、CG側にはUnityに近いようなインターフェースのAPIが提供されています。TypeScriptで記述できるビルド環境が提供されているので、Webに疎いCGサイドでもすぐにWebエンジニアの使う筆を作ることができます。再利用可能で、最終的なパラメーター調整などをWeb側が簡単に行えるわけです。実際、そのためにChrome拡張でWebGLの空間をそのまま操作できるインスペクタも提供しています。

Grimoire.js Inspector

WebエンジニアにとってCGをより身近にすること、そしてCGがより一般的な世界にすることを目指しています。

白石: とても期待しています！本日はWebGLの基本的な事柄からGrimoire.jsまで、いろいろ教えていただいてありがとうございました。

石井: 1.0リリースを年内に行いたいと思っています。興味がある方がいたら公式サイトから開発チームのSlackなどに入ると新しい様々な情報が拾えるかと思います。またいくつかの例も載っているのでご覧いただけると幸いです。