「HTML Conference 2013」で行われたセッションから、株式会社サイバーエージェント大谷剛氏と船ヶ山慶氏による「現場の実例から学ぶ、最新鋭のWebアプリケーション開発フローとアーキテクチャ」の模様をお伝えします。

「なぞってピグキッチン」とは

今回作ったWebアプリケーションは、「なぞってピグキッチン」に使っている基本的な技術は、HTML、CSS、JavaScript。これにCanvasなど、他のフレームワークを組み合わせていますが、基本は前者の3つです。これをスマートフォンのブラウザ上で動かし、ネイティブのアプリと近い状態を作り上げたサービスです。

基本的な流れは、例えば（画面上の）ボタンをタップすると、背景色や文字色が変化する。さらに、せっかくCSS3が使えるのだから、角丸やシャドウを付けてみる。さらにアニメを付けてみる。――さらには画面全体を動かして、ぱっと見、ネイティブアプリのようなものを頑張って作りましょう、という流れです。

これが、HTML、CSS、JavaScriptですべて作られている基本の画面です。

左下に自分のアバタがあり、中央にキッチンがある。キッチンをデコレーションし、レシピを並べ、友達に料理をふるまい、キッチンを核にやっていこうと。それを楽しむゲームです。下のボタンを押せばモジュールが開きますが、モジュールからモジュールへとたどっていくのが基本の動きです。基本のURLは一つで、ページのリロードはせず、hashの部分のみで見た目を切り替える仕組みです。

ゲームの流れとして、パズルをして料理に必要な素材を収穫し、それを使って料理をします。制作チームのメンバーは、プロデューサー、エンジニア、デザイナー、ディベロッパーの大きく4つの職種があり、各職種にリーダー的なの人がいます。

フレームワークについて

フレームワークは世の中にたくさんあるのですが、それぞれ特性があります。例えばjQueryなどは有名ですが、スマートフォンで使うには、通信帯域が狭い中でファイルサイズが大きく厳しい。このように、どれがサービスに合っているのか、適性を見極める必要があります。

今回、「なぞってピグキッチン」に使用したフレームワークは「beez」と呼ばれるもの。現在は社内でしか使えませんが、近く社外にも公開する予定なので、その際には試していただければと思います。「スマートフォン開発をスピーディに進めるための、中・大規模クライアントブラウザ向けのフレームワーク（開発ツールキット）」というのが、beezの基本的立ち位置です。

ここで「開発ツールキット」とあるのは、スマホに特化したライブラリ、相性のいいライブラリをまとめてラップしたというのが大きな特徴だからで、そのためbeezを使う場合はbeez専用の言語、書き方ではなく、既存のライブラリの組み合わせで効率よく書けるようになっています。

主に先ほどのライブラリの中から、クライアントが主に触ると思われるものが以下の7つです。

＜１＞ Backbone.js

＜２＞ Underscore.js

＜３＞ Zepto.js

＜４＞ RequireJS

＜５＞ Handlebars

＜６＞ Stylus

＜７＞ bucks.js

簡単にまとめると、Backboneがbeezの中では全体のフレームワークを担い、HandlebarsがHTML、StylusがCSS、ZeptoがDOM操作、Underscoreがユーティリティ、Requireがモジュールを担っています。beezは、これら既存のライブラリに追加する形で、Manager、Controllerという概念を持っています。

Managerは、viewに関しては、グローバルに必ず1つしか存在しない、viewを必ず監視している立ち位置にあります。しかもviewが必要なくなったタイミングで、それを全部破棄しメモリ上から消したり、また必要になった場合には再復帰させたりします。特にスマートフォンの場合はメモリ制限が厳しいので、こうしたマネージメントを行うのが、beezの中のManagerの概念です。

beezは、ツリー構造でviewを管理しています。これはBackboneとかではなく、beez独自のものです。

Controllerの概念は、まずRouterというもの――これはBackboneのものなのですが、hashのフラグメントを常に監視しています。これがモジュール単位で、「クエスト」といったhashに書き換わると、クエストのControllerが呼ばれて、複数のviewとmodelを一気に作成します。そのうえで、クエストが必要としているCSS、i18nのファイルをロードします。

アーキテクチャ

M（Model）とV（View）とR（Router）、これにプラスして、beezのM（Manager）、C（Controller）。この5つの構造で、アプリケーションは成り立っています。

全体の流れとしては、Routerが会社に例えれば社長のような立場にあり、hashを常に監視していて、hashが変わったタイミングで、Controllerという部長クラスに指示を出します。Controllerは、その指令に従って、各社員にあたるModelに指令を下ろす。Modelは更に下のViewに指示。こうしてアプリケーションの見た目に反映される。このようなトップダウンの仕組みで、ボトムアップは基本NGですが、ViewからModelへは、ユーザーがタップした際のアラーム的なものは出ます。

これをまとめると、一番最初にログインした段階で、hashが何であれ、強制的に#mypageに書き換えます。それをRouterが捉え、該当するController（MyPageController）を呼び出します。MyPageControllerはViewとModelを作成。それぞれをひもづけて、いわば社員の“人員配置”をします。ここでユーザーがタップ操作をすると、それがModelに伝わり、Modelが上に伝える。例えば「area」というボタンがタップされたとすると、「#area」というhashに変えてくれというリクエストが行く。#hashに変わってからの流れはまた同様です。

共通機能群

最後に共通機能の部分について。先ほどから何度も登場しているアバターはCanvasで描かれていて、好きなところに移動もできますし、好きな服を着せてやることもでき、動作のバリエーションを登録しておけば、好きな動きをさせることも可能です。

服情報は、アバターの動きに合わせて服の位置等も変わるので、それに合わせてシート化されたものが用意されています。下に一見、横線のように見えるものがありますが、これは画像のデータを持っていて、腕の回転中心の座標情報などがここにあります。

あとは下から開いて左右に移動するなどといった、いかにもスマートフォンアプリっぽい画面制御。これもカスタマイズすれば、一部を固定し部分だけガリガリ動くといったことも可能です。

ポップアップもよく使いますが、これも基本形を作っておいて、それを適宜カスタマイズ。また、リロードが発生したときにエラーデータをキャッチし、ポップアップを自動で表示させるといったことも可能です。

【講演資料・セッション映像】

2013年11月30日に開催された「HTML5 Conference2013」において行われた数々のセッション。株式会社ACCESSの長野宏輔氏が「組込み+HTML5」の持つ可能性について語った「HTML5 run anywhere」をレポートする。

車載機器、ハイブリッドキャストなど
HTML5×組込はすでに実現

実は、HTML5の技術が利用されるシーンは、PCやスマホ向け以外にも広がってきている。例えば、テレビやカーナビ、ゲーム機、デジタルサイネージ、家電のUIなど。つまり組込向けにもHTML5のコンテンツが開発できる環境が、ここ数年で着実に用意されてきているのだ。

長野氏によると、例えば車載機器からの情報取得に関する技術として、W3Cを中心にwebinos GENIVI LG QNX CAR　Tuzen Webinosなど様々なプレーヤーから組込向けAPIが提供されていることで、仕様の策定を行っている。その結果、ガソリンのタイプやギアの種類、エンジンの回転数、エンジンオイル残量、室内温度、ドライバのIDなどがリアルタイムでナビゲーションのヘルプ画面に、ブラウザによって表示されることもすでに実用化している。

その一方で現状、先ほど紹介したようなプレイヤーが自社の技術を標準化しようとする傾向が強く、現状では各社のAPI仕様には違いが大きいなども問題点も指摘されている。

またテレビにおいても2013年、NHKから「ハイブリッドキャスト」と呼ばれる放送と通信を連携させた新しいテレビサービスがスタート。ニュースや気象など、番組に関連する情報をこれまでのデータ放送より鮮明な画質で提供するというもので、この技術にもHTML5を活用したアプリ開発が行われている。そしてここでも「SmartTV Alliance」として規定された規格が多数、出されている。

組込向けHTML5開発のメリット＆デメリット

他にもエアコンや洗濯機、炊飯器など利用対象となる家電製品は多々あるが、問題なのは「本当にこうした機器にも現実的に使えるのか？」という点。

そこで今回、改めて組込向けHTML5開発におけるメリットとデメリットをまとめてみたい。

メリット

• HTML5/CSS/JavaScriptによるコーディングが可能なため、開発者が多く、開発のスピードアップや効率化が可能
• 各種APIがすでに揃えられているため、開発環境が充実している

デメリット

• 基本的に低いスペックが多い
• 対象となる組込製品によってはエフェクト系が苦手な場合もある
• HTML5を実行するためには、実行環境に対する要求スペックが非常に高いＨＴＭＬ５実行するためには、実行環境に対する要求スペックが非常に高い点　例：「ROM：27MB　ＲＡＭ：起動7MB+コンテンツサイズ」

このように、開発環境が充実しているメリットもある半面、組込製品にHTML5を新規に導入するためのハードルの高さもあるようだ。 そのため、あえて「HTML5を使わない」という選択肢もある。 既存の組込向け製品に対する最適 なプロトコルが存在する（例：ECHONET Lite SEP2.0など）以上、それをもしHTML5に置き換えるとしたら、非常に手間がかかるという懸念点もあるのだ。

過去の組込技術を生かしつつ、
HTML5によってスマートデバイス連携を可能にさせる

そこで長野氏が提唱するのは、「過去の資産生かしつつ、Web標準技術を活用したUIアプリ開発を可能にしていく」という、より現実的な手法。同氏はこれを「餅は餅屋」ということわざに例えている。

例えば「HTML5+ECHONET Lite」の場合、家にルーター（HTML5ブラウザによるサービス+プロトコル）を設置し、そこから外部へはHTML5経由でクラウド、さらにそこからスマートフォンやタブレット端末に搭載されたHTML5アプリケーションによってエアコン温度の設定や電気のON/OFFを外部から自動操作できるようになる。

またこうした技術を活用して、スマホと家電をつなぐ「スマートデバイス連携」を可能にさせることも可能だ。例えばスマホをコントローラーにしてTVと連携することでゲームをプレイする。さらに「フルミエル」というアプリでは、ゴルフのスイングの軌道を「見える化」したり、電子出版としての活用も可能だ。

このように、いつでもどこからでもスマートデバイス連携を可能にするHTML5は今後、様々な組込機器にも広がっていくことが予想されている。そして、その動きをさらに加速させていくためには、もっと「HTML5×組込」に関する様々なプロモーション活動を活発化させていくことが、成功のカギを握っていると長野氏は指摘している。

本セッション最後に長野氏は、参加者に対して「HTML5と組込」というテーマにおいて、

• 今後、絶対につながってほしいもの
• 今後、確実につながるもの
• 今後も絶対につながらないもの

という3つのアンケート回答を求めた。

そこにはWeb技術者に対して、Webの仕事はもはやWebブラウザの中だけにあるのではないこと。そしてWeb技術者が持っているスキルをそのまま活かして、これまでとは全く異なる様々な業種で活躍できる時代が、もうすぐそこに来ていること。

その上で、Webブラウザ以外のプラットフォームが備える様々なJavaScript をAPIに触れながら、HTML5/JavaScriptが持つ非常に大きな可能性について今後、Web技術者が中心となって切り拓いてほしい、というメッセージが込められている。

【講演資料・セッション映像】

「今日は面白いのに話題になっていないよね、というHTML5のマニアックなAPIを紹介しようと思う」。冒頭でこう切り出して始まった羽田野太巳氏のセッション。テーマは「ようこそ、HTML裏APIの世界へ」。

HTML5のAPIはモテ系だけじゃない。非モテ系にも注目！

現在、HTML5の世界で世間の注目を集めているのはCanvasやWebGL、WebRTCなどのモテ系APIである。五感に訴えられる、派手で華やかなデモが作れるので仕事に結びつきやすい技術だ。「仕事に結びつきやすい」ことからモテ系と呼ばれているが、羽田野氏が紹介するのは非モテ系のAPI。

「語れる開発者仲間が少ないし、使ってもすごさがわからない。仕事になるかわからない。未熟なので仕様がなくなるかもしれない。でもいつか報われる日がくるんじゃないかと期待できる。そんな今はAPIを紹介する。ただ、さっきもいったようにハッピーエンドは期待をしないでほしい（笑）」

マニアレベル1「割とモテ系」の4つのAPI

羽田野氏は非モテ系APIをそのマニアック度から4つのレベルに分けて紹介。最初に取り上げたのはマニアレベル1（割とモテ系）のWebRTC DTMF(Dual-Tone Multi-Frequency)である。

WebRTC DTMFはいわばSkypeをブラウザで実現するためのAPIで、最大の特徴は映像、音声、データをP2Pで接続できること。IP電話の知識が必要になるため、「マニア心を揺さぶられる」（羽田野氏）という。「ダイヤルトーン音を発生させるできるため、自動音声装置（IVR）への応用が期待できる。

また将来的にはブラウザからコールセンターへ通話ができるようになるかも」と、ビジネス的にも注目されているAPIだという。実際にダイヤルトーン発信のデモを実施し、その実力を披露した。

次に紹介したのは「WebAudio API」。「音源の生成や合成ができるAPI。iOSなどで複数音源の同時再生に重宝する。高精度な再生タイミングが設定できるので、ゲーム系コンテンツにいい」と羽田野氏は説明する。

またこのAPIを使えば楽器のチューナーなど精度が求められるものには向いていないが、各種オーディオエフェクトやアナライザーなども作れるという。ただ「これはまだモテ系の機能。非モテ系の機能もある」と語り、非モテ系の機能の中からPannerNodeを使った立体音響のデモを実施。救急車のピーポー音のドップラー効果の例を再現。「仕事になるかどうかはわからないが」と言うものの、参加者の関心を大いにつかんだようだ。

三番目に紹介したのは「Media Souce Extensions（MSE）」で、「Internet Explorer（IE）11にしか実装されていない」APIです（もしかしたらChromeにも入っているかもしれないが試していないとのこと）。IEではMPEG-DASH（Dynamic Adaptive Streaming over HTTP）という国際標準のメディア・ストリーミングのプロトコルをサポートしている。

同APIの特徴は、HTTPアダプティブストリーミング配信。セグメントに分割されたビデオデータをVideo要素に流し込むだけのAPIで、低ビッドレートのストリーミングに途中で切り替えられるというもの。

「ファイルを取りに行くコードを一つ一つプログラマが書かなければならないなど、気が利かないAPI。プレイヤーを作るのは、プログラマの腕にかかっているので要注意。仕事にはならないAPIだが、チャレンジしたい人はぜひ」と羽田野氏と会場の笑いを誘った。さらにマニアレベル1では「Media Capture and Streams」も紹介。

これはChromeのみに実装されているAPIで、全画面がキャプチャーできるというもの。しかし「Windows上で実行するとOSが引きずられ大変なことになるので、今回はMacで紹介」と、Macでデモを実施。いろんなユースケースが考えられると、羽田野氏がその一例としてあげたのが、デジタルサイネージのリモート監視やヘルプデスク。「ビジネスにも応用できそうな面白いAPI」（羽田野氏）

縁の下の力持ち系。マニアレベル2のAPI

マニアレベル2（縁の下の力持ち系。目立たないので話題になっていない）で羽田野氏が取り上げたのは、「Encording」「Web Cryptography API」「DOMMatrix」「Transferable objects」という4つのAPI。「Encording」はブラウザに入っているAPIで、文字コードのデコード、エンコードに使えるAPI。

「Web Cryptography API」はIE11に実装されている、暗号論的擬似乱数列の生成やダイジェストの生成、公開鍵と秘密鍵の生成、デジタル署名の生成と照合、データの暗号化と複合化などの機能を持つAPIである。
「将来、ストレージに溜めたデータを暗号化したいというニーズはきっと出てくる。このAPIは単独で使えるのでそのときの有望株になるのでは」

ただ、暗号化の知識がないと使えないので、ハードルは高いAPIだそう。「DOMMatrix」は行列計算やグラフィックスにおける座標変換のためのAPI。元はCSSMatrixという名称だったとのこと。「Transferable objects」はデータ転送の機能を持つAPI。参加者で知っている人はたった一人というかなりマニアックなAPI。「ファイルサイズの大きい動画のリアルタイム処理などをするときに使うと有効だと思う」

「使い方がわからない」マニアレベル3のAPI

マニアレベル3とは、「きっとどこかに必要とする人がいるのだろうでも使い方がわからないというAPI。そこで羽田野氏が紹介したのは、「Clipboard API」と「Base64 utility methods」。

前者の「Clipboard API」はどんなものがペーストされたかが、リアルタイムで情報が取れるAPI。すべてのブラウザで実装していますが、「Web上でやる意味がいまひとつわからない。もちろん使ったこともありません」とのこと。

また「Base64 utility methods」はBase64エンコードとデコードの機能を持つAPI。ただ対応しているのはASCII文字だけで、バイナリーどころか日本語もNGとのこと。「利用シーンはまったく思い浮かばない。マニアの皆さんに考えていただきたい」と羽田野氏は参加者に呼びかけていた。

「きっといつかはモテ系に…」なマニアレベル4のAPI

マニアレベル4とは「きっといつかはモテ系APIになるだろう。でも利用できるブラウザが……」というレベルのもの。最初に紹介したのは「Screen Orientation」。これはAndroidやFirefox OSのFirefoxにしか実装されていないAPIで、オリエンテーションを固定できる機能を持っています。ただFullScreen APIを使ってフルスクリーンになっている状態でしか、使えません。「脱アップルストアを目指している人には魅力的なAPIでしょう」

「MediaStream Recoding」はFirefox Aurora（現在は音声のみ）しかサポートしていませんが、録画と録音機能を持つAPI。メディアストリームの記録を開始してから停止するまでの間に蓄積されたメディアデータをBlobオブジェクトとして取り出すことができる。 「Webアプリケーションの可能性を開くことが期待できるAPIだ」

最後に羽田野氏が紹介したのが「Web Animations 1.0」というタイムライン制御フレームワーク。連続処理や並列処理ができ、ビデオ再生のように扱えるというのが特徴だ。ただ「欠点は実装しているブラウザがまだ一つもないこと」と羽田野氏（Githubにて公開されているポリフィルがあるので紹介）。

「Githubではポリフィルが公開されており、私はそれを仕事で使っています。パフォーマンスも悪くない。もっと広まってほしいAPIです」 このようにマニア度の高いAPIを15個ほど駆け足で紹介し、羽田野氏のセッションは終了した。

【講演資料・セッション映像】

マイクロソフト春日井良隆氏のセッションテーマは「HTML5とIE11とWindows 8.1」。セッション冒頭、春日井氏は日常的に使用しているITデバイスを披露露。ソニー VAIO Tap 20のほか、iPadmini、Surface、Kindle Paperwhite、そしてiPhoneというデバイスを、用途別に使いこなしているという。

HTML5とJavaScriptという標準技術にWindowsは対応

「こういうデバイスの使い方は特別なことではなく、今後一般化する」と春日井氏は語り、今世の中で起こっていることを次のようにまとめた。

1. デバイスの多様化
2. タッチインターフェイス
3. ローカルからクラウドへ

そして「デバイスの多様化で期待されている技術がHTML5である」という。デバイスはPCとタブレット、スマートフォンと3つに大きく分かれるが、OSもPCはWindows 8やMac、Linux、タブレットはWindows 8とiOSやAndroid、スマートフォンはiOSやAndroid、WindowsPhoneのほか、Tizen、Firefox OSなどのリリースが予定されている。このような状況だからこそ「HTML5の存在感が出てきている。これは特に今日のセッションで強調したいこと」と春日井氏は力強く語った。

このような状況下で、WindowsとHTML5とどのように関係にあるか。HTML5の特徴の3本柱は「セマンティック」と「互換性」「Webアプリ」だが、第二の互換性においては、マイクロソフトは「IE9でSameMarkupというコンセプトを打ち出した。これはブラウザーによって、あるいは、ブラウザーのバージョンによって、異なるマークアップをする必要はないという今の我々の開発姿勢だ」と春日井氏は言う。

第三のWebアプリについても、Windows 8のアプリは、「HTML5とJavaScriptという標準技術で作れるようになっている」と春日井氏。当然、jQueryのようなJavaScriptライブラリーはそのまま使えるのだという。Objective-CとXCodeの知識が必要になるiOSアプリ、JavaとEclipseが必要になるAndoridアプリの開発と較べ、敷居はぐっと下がるだろう。

また最近ではTitaniumやPhoneGap、CreateJSなどのクロスプラットフォームフレームワークが非常に注目を集めている。これらのフレームワークで使う技術はいずれもHTMLとJavaScript。このようにWindowsアプリは特別な知識を身につける必要はないというわけだ。Windows 8では「WinJS.xhr」というというWebコンテンツを呼び出す関数が用意されており、これを使えば簡単にWeb上のコンテンツをダウンロードしてアプリから利用できるようになるという。

とはいえ、これまでJavaやC++などで開発してきた人にとって、JavaScriptと言う言語が持つゆるさが好きではないという人もいるだろう。そんな人にお勧めの技術があるとして春日井氏が紹介したのは、「aulJS」というJavaScriptを生成する中間言語だ。altJSにも複数あり、「TypeScriptはC♯を開発した人が開発した中間言語。同言語を紹介したサイト（http://www.typescriptlang.org/）に行くとJavaScriptとのコーディングの違いを体験でき、サンプルも手に入る」と言う。この際に試してみるものお勧めだ。

Web系開発ツールとしても有効な「Visual Studio」

次に春日井氏が取り上げたのが「Visual Studio」である。「Visual StudioはWindowsの開発ツールというイメージが強いが、Webアプリの開発する上で非常に効果的なツールになっている」と春日井氏。

それを証明するためデモを実施。例えば<video>というタグの後では次の設定内容はほぼ決まっている。Visual Studioではタブを2回押すことで、予想変換のように想定されたプログラム内容が勝手に表示されるようになっている。

CSSのカラー設定も「非常に効率的になる」と春日井氏はデモを実施。カラーパレットから指定することはもちろん、スポイトで直接色を抜き取り指定することができる。
「和文フォントが出ないという弱点はあるが、コーディングの作業を効率化する機能がかなり入っている。Visual Studio Expressというフリー版もあるので、ぜひ一度、試してほしい」（春日井氏）

IE11は「Touch」「WebGL」「MPEG-DASH」「Encripte Media Extension」サポート

最後に春日井氏が説明したのはIEについて。「IEではJavaScriptの処理のスピードの高速化を図っている。IE10と比べてもIE11では処理時間は高速化されている。他のブラウザと比較しても処理時間は短い」

最新のIE11では「Touch」「WebGL」「MPEG-DASH」「Encripte Media Extension」という4つのWeb標準をサポートしている。これからのデバイスはタッチも使えばマウスやペンも使うため、Pointerという概念でまとめてAPIをつくっている。「pointer events」を使って実装することで、マルチタッチが可能になる。「この仕様を検討するワーキンググループがW3Cに設立された」と春日井氏。

次の「WebGL」とは3Dの表現がブラウザの中でできるという技術だ。「3Dはエンタメのコンテンツだけに必要な技術ではない。例えばCADのデータをブラウザの中で表現することができるようになる。ビジネスの世界でも使える」 残りの2つの技術については、http://ie.microsoft.com/testdrive/HTML5/eme/で紹介されているので、こちらを見てほしい。

WebRTCなど注目技術への対応はどうなっているのかなども気になるところだ。しかし、それは「IEというブラウザが抱えるユーザー層が大きく影響している」という。というのもIEはエンタープライズのお客さまが多いのはもちろん、いわゆるブラウザというと青いeのマークという風に覚えているITにそれほど詳しくない一般ユーザーが多いこと。

そのため、安定している仕様、セキュリティ面で不安のない仕様を実装することに気を配っているというのである。IE9でWebSocketに対応しなかったのもそれが理由だったと春日井氏は明かす。とはいえ「当然、研究、検証はしており、その成果はHTML5LABSで発表している。ここでOKが出ればIEに実装していくことになる」とのこと。新しいHTML5への対応については、HTML5　LABS（http://html5labs.interoperabilitybridges.com/）をで紹介されているので、ぜひチェックしてほしい。

読み上げ機能や音声認識機能を標準で実装

そのほかにも最新のIEでは強化・改善された機能がある。第一にアクセスビリティの強化だ。読み上げ機能や音声認識機能を標準で実装。マイクを使えば音声だけで検索することもできるという。第二はF12開発者ツールも用意していること。F12キーを押すだけで日本語化された開発者ツールが起動する。「ここにいる開発者の方にぜひ使って欲しい」と春日井氏。

第三はIE11からドキュメントモードは非推奨となっており、Edgeモードという最新のレンダリングエンジンが優先されるようになったこと。条件付コメントはただのコメントとなる。「ブラウザのバージョンを指定したい場合は、メタタグを使って指定する」こととなると、その指定の仕方を紹介した。

自分の書いたコードに不安がある場合は、正しいかどうか、チェックするサイトをマイクロソフトでは用意しているという。それが「modarn.IE（http://loc.modern.ie/ja）」である。春日井氏は同サイトでも紹介されている「Brouser Stack」という有償のサービスについて説明した。「Brouser Stack」Web上で仮想環境をエミュレートするサービスで、例えばiOS6のSafari6でレンダリングするとどうなる、WindowsXPのIE10でレンダリングするとどうなる、という見え方がわかるというサービスだ。「互換性のチェックなどに使えるので便利。3カ月間は無料で使えるので、試してほしい」

セッションの終了の間際に春日井氏はキネクトのデモを実施。「体のジェスチャーで操作ができる時代ももうすぐ。Webは何かを見るためではなく何かをするためのプラットフォームになる」と春日井氏。デザインはもちろん、使い方も変わっていかざるを得ない。開発者も変わっていくときにきているのかもしれない。

【講演資料・セッション映像】

今後モバイルWebアプリはどこを目指すのか──。このヒントが得られたのが、DeNA小原隆郎氏の「地下鉄 x サクサク x これからのWebゲームアプリが備えるべき8つの機能」というセッション。

小原氏は昨年秋にDeNAに入社。「@uupaaというネームは知っている人もいるかもしれないが、ほとんどこのような場所に出ることがない。今日会えた人はラッキーだと思う」という前置きをしてセッションは始まった。

SPAでページをまたがった音楽の再生が可能に

同セッションは検証は必要ながらも、小原氏自身が気になっているWebアプリの技術的なトピックスを紹介するというもの。

まず最初に取り上げたのはネイティブにアプリにできてWebアプリにできないこととは何か。

• 電波のないところでは遊ぶ
• たくさんの映像やデータを扱う
• 音を鳴らす
• 3Dで動かす

このようにWebアプリにはでいないことが結構あるが、これらができなくてもせめて「サクサク感」はほしい、というのは万人の望み。とはいえ、従来のサーバからファイルを都度、ダウンロードするWebアプリには待ち時間という弱点がある。

サクサク感を出そうとしても明確な限界があり、いくら回線が速くなっても端末スペックが上がっても、今後コンテンツがリッチになればなるほど遅く重くなっていく。

これを解決する機能として小原氏が注目しているのが、「Single Page Application（SPA）」である。従来とは違い、SPAは基本となる画面が1つだけ存在し、次々と内容を書き換えていくWebアプリだ。
「開発者にとって何がうれしいかというと、進行に必要なデータをサーバから動的に取得し、アプリ側で情報の先読みを行うなど、これまでブラウザに任せていた部分が自分たちでチューニングできるようになること」

またSPAであれば次のようなことが可能になる。

• ページをまたがった音楽（BCM）の再生が可能になる。これによりゲームへの没入間が高まる。
• 電波が来ない環境でWebアプリをある程度動作させられる。ページの読み込み時間は800msから200msになるため、別次元のサクサク感を演出できる。

さらに「余計な話」とした上で「サーバサイドにすべてのロジックを置く必要がなくなる」ことも紹介した。しかし、SPAには次のような課題がある。

• チート対策（結果をバリデーションする仕込が必要）
• 従来の作り方とは大きく異なるので、現場にノウハウが蓄積されていない

だから、「今のところ頑張って移行する理由がない」と小原氏は語る。

WebAudioでBGMとSEの同時再生が可能になる!?

次に取り上げたのは「WebAudio」。従来のオーディオタグはストリーミングによるBGMの再生しか期待できなかったが、WebAudioならBGMとSE（Sound Effect：効果音）の同時再生が期待できるというのだ。

現在、WebAudioをサポートしているのはChromeとMobile Safariだが、この両者においては「使えるレベルで実装されている。しかも試したところ負荷も高くない」と小原氏は説明する。

Android2.3やiOS5など、この機能が使えない端末ではaudioタグを使ったSoundSpriteで、擬似的だが再生可能だそうだ。 今後、いずれは音階や音の長さといった情報からブラウザ上でリアルタイムに動的な波形を生成する（いわゆるMIDIファイル）という使われ方が可能になる。
「メモリを潤沢に利用できるようになったら、モバイルブラウザ上でチップチューンをこ流せるようになるかも」と、小原氏は期待を込める。

WebAudioの懸案事項として小原氏は次の4点を挙げた。

1. いきなりフルサウンドのゲーム開発は無理 理由は「Web開発の環境に音に対するノウハウは蓄積されていないから」（小原氏）だそう。したがって最初はSEだけということから始めるのが得策だ。
2. 波形の動的生成はまだ無理（ブラウザがメモリをあまり使えないため）
3. ボトムラインを設定し、機能をOFFにする対策が必要

「ライブラリ側でON/OFFする端末のカタログを持っておくという対策が必要になる」と小原氏。またAndoridの最低スペックはDual Core、1GBRAM、iOSは7、iPhone 4Sがボトムラインだそうだ。
「まだこの分野はほとんど誰もやっていないため、今なら差別化になる。チャレンジャーを募集している」と呼びかけた。

高解像度化が続くモバイル端末への対応

モバイル端末は高解像度化の一途をたどっている。端末の65～70％が200dpi以上解像度を持っており、326dpiのローエンド端末が登場する時代となっている。そこでCanvasも高解像度のサポートを開始。従来のCanvasRenderingContext2D#toDataURLは96dpi化されたデータを扱う。

また草案では「High Definitionバージョンがメソッドが追加されている」という。しかしImageDataを使ってライブエフェクトかけるには、数十MBを16ms以内に処理しなければならず、forループで回してもビジーループになってしまい、ブラウザのプチフリーズや過負荷によるシステムアラートが発生してしまうことになる。

その解決法として小原氏が期待しているのが「WebWorker」だ。WebWorkerでCanvasと聞くと「えっ」と感じる人もいるかもしれないが、最新のCanvasの仕様には実装はまだだが以下のようなメソッドが追加されている。

• canvas.transferContorolToProxy
• canvasProxy.setContext
• context.commit

夢は大きく膨らむが、無理もある、と小原氏は続ける。メモリ関連の改善が必要なこと、任意のタイミングでGC（グラフィックスコンテキスト）を発動できる仕組みがないなど、課題があるからだ。
「High Definitionはモバイルブラウザではまだ実用的ではないが、CanvasProxy+WebWorkerにはかなり期待している」

CommandPatternで発生頻度の低い不具合の再現も

第4のトピックスは「CommandPattern（コマンドパターン）」。これはデザインパターンの一つで動作とパラメータを中間言語化（カプセルか）したものである。

例えばゲームをある程度進めると、特定のAndorid端末ブラウザで描画が破綻するという現象があったとする。この不具合を再現するためには、ゲームを進める必要があり、確認するためにその環境を維持することはもちろん、修正後はまた確認しないといけない。「ラスボス登場の場面で現象が出たら、そこまでゲームを進めなければならず、大変」と小原氏。

また最小化コードを見つける作業も大変だ。これを解決するのがコマンドパターンというわけだ。つまり描画コマンドの保存と再生の仕組みが導入されればいつでも現象を再現可能になり、サーバがとまっていても調査を進められる。

そのほかにも、発生頻度の低い不具合の再現が簡単になる、最小化コードを見つける作業を大幅に省力化できる、保存しておいたコマンドはエンバグチェックのテストケースとしても再現できるなどが可能になる。
「AndroidブラウザやChrom for Androidの不具合で悩む時間が大幅に短縮されるかもしれない」（小原氏）

また「DrawCallを減らせるという効能もある」という。細切れで実行されるCanvasAPIは複数回のDrawCallを発生させる可能性が高いが、まとめて実行するとDrawCallを最小化できるというのだ。Chrome Canary版の「Canvas profiler」を使うと、DrawCollやCanvasAPIを可視化してくれる。「ぜひ、使ってほしい」（小原氏）

さらに「ゲーム画面のスナップショットと動画の作成も可能、リモートプレイにも展開できるかもしれない」という。

機能強化が続けられているWebWorker、その注目の機能

第5のトピックスは先ほどから登場している「WebWorker」である。「計算だけさせておくのはもったいない」と小原氏。機能強化はひっそりとされ続けており、例えばChromeとSafariでは次のような機能が使えるという。

• importScript
• JSON、BLOB、FileReade、FileRiedeSync
• Timer
• TipeArray
• MessageChannel
• WebSQL、WebSWLSync
• WebSocket、XML Http Request

またChromeでは次のような機能を先行して実装されている

• HighPerformanceTimer-performance now()
• Text Encorder/Text Decorder
• IndexdDB
• WorkerConsole
• ImageBitmap
• RequestFilesystem,RequestFilesystemSymc
• Crypto,Base64

気になるのはPostMessageの通信速度である。「検証は足りないかもしれないが、無負荷状態ならサクサク動く」ことがわかったという。

しかし「荷物が重いと遅くなる」とのこと。1MB程度の負荷ならなんともないが、32MBもの巨大な配列（payroad）を与えると速度が25％程度まで落ちてしまうこともあるというのだ。「巨大なデータの受け渡しはちょっと注意が必要」と小原氏は注意を促す。

WebWorkerは注目に値する技術だが、現在、既存のライブラリやフレームワークで動くものはほぼないという。ただImportScripitがあり、JavaScriptのプロトタイプ拡張をしてもWebWorker上では副作用なく行える。

またWebWorkerが利用できない環境ではiframeでエミュレーションできるという。 「WebWorkerは手つかずのブルーオーシャン。ライブラリを書きたい人には楽しい世界だ」

「Storage」「Cache」「Offline」

最後のトピックスとして紹介したのは「Storage」「Cache」「Offline」。 特にApplicationCacheは利用できるシーンが限られており、「開発者からもあれはないよ」といわれている。 そこで小原氏が注目しているのが。「LocalStrage+WebSQL」を使ったキャッシュである。これは画像やバイナリデータはBASe64化した状態でストレージに保存。取り出した後はDataURLで画像化しなどに埋め込んで利用するというものだ。

また小原氏は「AssetManifest」という考え方を利用しているとも言う。サーバ上でアセットのリストを作成し、ブラウザ側でリストを元にキャッシュを管理するというもの。これにより「ブラウザ任せにしない高度なキャッシュ管理が可能になる」というわけだ。 マニフェストは以下のパラメータが必要になる。

• IDまたはURL
• ファイルサイズ
• MimeType
• ファイルのHash値（MD5hashなど）
• 優先度や保存先などのパラメータ

次世代のStrageはどうなるのか。小原氏はIndexedDB+SrverWorker+DiscQouter ManagementAPIにより、「端末の空き容量の10％がストレージとして利用可能になる予定」と話す。これが整備されると現場の苦悩もなくなるかもしれない。 最後に小原氏は無限ストレージのデモを実施し、セッションを終えた。

【セッション映像】