Webに足りなかったもの

私はWebが大好きです。リンクを1つクリックしたら（インストールなど煩わしい手続きなしで）すぐに新しいコンテンツを読めるのは最高の体験だなと常日頃感じています。ただし、今までのWebアプリのユーザー体験は決して最適なものではないとも思っています。たとえば以下のような体験をした覚えはありませんか？

• 朝の満員電車でも情報収集に勤しむ現代のビジネスパーソンのあなた。つり革に捕まりながらなんらかの記事コンテンツを見ようとリンクをタップする
• 途端にHTMLのレスポンス待ちで真っ白な画面。レスポンスが返ってきたと思ったら今度はWebアプリ側のローディングGIFが動き出す。
• しばらく待つとテキストが表示され読み始めるものの、時間差で画像が差し込まれレイアウトがずれる（どこを読んでいたんだっけ？）。極めつけは全画面広告が画面を占拠し、嫌になってそっとブラウザを閉じる（代わりにソーシャルアプリやゲームアプリを起動する）。

このように世に出回っている多くのWebアプリはパフォーマンスに課題があります。特に、さまざまなスペックなデバイスがあらゆる環境で利用されるモバイルにおいては、Webアプリは単純に耐えられないくらい遅く、実測で3G回線と同等な環境における平均ページロード時間は19秒もかかっているという統計もあります[1]。 Webアプリはとにかくこのパフォーマンスをどうにかしなければなりません。

一方ですでにネイティブ アプリに慣れ親しんでいるユーザーの期待値を満たすためには、パフォーマンスを改善するだけでは十分ではありません。

• ホーム画面にアイコンを追加したり
• プッシュ通知がタイミングよく送られてきたり
• オフラインでも動作する信頼性だったり

「ユーザー体験の基準」がどんどん上がっていくなか、Webアプリだけがこのような体験を提供できずに取り残されている状況がずっと続いていました。時代に合わせて、ユーザーが求める機能性もWebアプリで実現できなければならないのです。

PWAはベストプラクティス集である

そこで満を持して登場したのがPWAです。PWAと聞くと何かを特定の技術を指すものと思われるかもしれませんが、実はそのコンセプトは幅広く、どちらかというと前述した Webアプリ本来の課題を解決し、よりよいユーザー体験を実現するためのベストプラクティス集のようなものです。Googleが提供しているProgressive Web App Checklist なるものがあり詳細な内容はそちらを確認いただければと思いますが、PWAのコンセプトをざっくり申し上げると以下となります。

• とにかくパフォーマンスいいWebアプリを作りましょう。SPAでもSPAじゃなくても、どんなフレームワーク使っても使わなくても、なんでもいいので、表示が速くて画面遷移がスムーズなものにしてユーザーに好かれましょう。
• また、最新のWeb APIを積極的に使って、機能性も身につけましょう。たとえば、Webアプリをホーム画面に追加できるようにしたり、オフラインでも動作するようにしたり。そんな今までWebアプリでは実現できなかった機能が実装できるようになったんだから、やらない手はないでしょう？

少し上記でも触れていますが、PWAはあくまでベストプラクティス集なので特定のサードパーティーフレームワークやライブラリには依存しません。世の中には ReactやAngularを使ったPWAもありますし、Vanilla JavaScriptなPWAもあります。また、サーバーサイドの構成には一切言及しません。したがって技術スタックを変えずとも適用可能なベストプラクティスでありますし、一度に全部を適用するのではなく段階的に（= Progressively）最適化することもできます。

以下の項目でPWAの特徴をより具体的に見ていきます。

ハイパフォーマンス

何より重要であり最も難しいテーマとなります。パフォーマンスの基準としては、2015年にChromeチームが発表したユーザー中心に考えるパフォーマンスモデルであるRAIL[2]を前提に考えていただければ間違いありませんが、各Webアプリの特性や環境に応じてそれぞれのサービスごとに Performance Budget（ロード時間やファイルサイズ等の上限を決め、それを「予算」として管理する）を設けることをオススメします。たとえば、2017年のChrome Dev SummitでChromeチームが推奨したPerfromance Budgetは、TTI（Time to interactive)を5秒以内、それを実現するためにクリティカルパスのファイルサイズを170KB以内に収めるというものです。[3][4]

何事もまずは現状分析から。Webアプリのパフォーマンス測定やプロファイリングをするLighthouseやChrome DevTools等のツールを使って現状の評価とボトルネックを確認し、対応すべきポイントを決めて最適化を進めます。その後はCalibreやSpeedCurveといったパフォーマンスモニタリングツールを利用して定点観測するといいでしょう。

ハイパフォーマンスなPWAを作るためのデザインパターンであるPRPLパターンもまた参考にすべき方式です。PRPLパターンはPush 、Render、Pre-cache、Lazy-loadの頭文字を取ったもので、主にApp Shell モデルやSPAを採用したWebアプリのために用意されたパターンですが、それ以外の構成に関してもパフォーマンス向上のヒントとなる点が多くあります。

• Push/Render: 初期描画に必須なリソースをHTTP/2 Server Pushするか link rel=preload を利用することで先行取得します。そしてそのリソースを利用し、特にAbove the fold [5] (スクロールしないで見える範囲)を優先してレンダリングします。
• Pre-cache: 次ページ（またはルート）で使用するであろうリソースを先読みします。これにはService Workerを利用するといいでしょう。
• Lazy-load: 初期描画に必要なもの以外はすべてLazy-loadします。SPAであれば別ルートの取得がこちら該当しますし、スクロールに合わせたフラグメントの取得であればIntersection Observer APIを利用するといいでしょう。

上記のとおり、Webアプリでもパフォーマンスをあげるためのツールやデザインパターンなど、使えるナレッジが多くたまってきました。ぜひともこれらを利用してハイパフォーマンスなWebアプリの開発を実現してください。

ホーム画面に追加

Web App Manifestを実装するとWebアプリをホーム画面に追加できるようになります。以下のようなJSON形式のマニフェストファイルを用意し、

{
   "name": “PWA Demo Application”,    
   "short_name": “PWA demo”,
    "icons": [{
        "src": “/assets/icon.png”, "sizes": “192x192”
     }],
    "start_url": “/index.html”,
    "display": “standalone”,
    "scope": “/”
}

link タグでページにひも付けた上で、Service Workerをインストールすると、

<link rel="manifest" href="/manifest.json">

<script>
if ('serviceWorker' in navigator)    
   navigator.serviceWorker.register('/sw.js')
</script>

このようにホーム画面へ追加を促すプロンプトが上がってきます。ホームに追加した後はフルスクリーンで起動しますし、Androidの場合は1つの アプリとしてみなされディープリンクまで可能です。

1点補足すると、この「ホーム画面に追加」は強力ですが、よりユーザーに気持ちよく追加してもらえるように、意味のあるタイミングでプロンプトを表示するとさらにいいでしょう。これを実現するためにぜひともonbeforeinstallpromptイベントハンドラーを利用してください。

onbeforeinstallpromptイベントハンドラーはプロンプトが表示される直前に呼び出されます。そのタイミングでプロンプト表示が適切でなければ表示をキャンセルし、別の任意のタイミングで表示することができます。たとえば、画面上に独自の「ホームに追加アイコン」を作成し、それの onclickのイベントハンドラ内でプロンプトを表示させることも可能です。

var deferredPrompt;
window.addEventListener('beforeinstallprompt', (e) => {
  console.log('beforeinstallprompt Event fired');
  // デフォルトのタイミングでは表示させない
  e.preventDefault();
  // Eventオブジェクトを保存しておく
  deferredPrompt = e;
  return false;
});
// どっか別のタイミングで...
deferredPrompt.prompt();

また執筆時点での最新のChrome Canary (67.0.3394.0)ではプロンプト表示形式を以下のように変更して、ホームに追加の体験をより良くすべく機能検証をしています。ポイントはページ下部に表示されるバナーがコンテンツの邪魔にならないサイズに調整され、PWAが追加済であればそのディープリンク用のバナーに差し替えます。また、前述のprompt関数を利用してユーザーのインタラクションに応じてプロンプトを表示する際は、モーダル表示に切り替わります。

オフライン対応

ハイパフォーマンスの解説でも少し登場したService Worker と Cache APIを利用することでWebアプリをオフラインで実行することが可能になります。Service Workerとはオリジン単位（またはパスの粒度）でインストール可能なJavaScriptで書かれたクライントサイドプロキシのことで、ページ内で発生するHTTPリクエスト / レスポンスを監視したり、それを書き換えたり、必要に応じてリソースを先読みすることもできます。これとCache APIというHTTPリクエスト/ レスポンスオブジェクトをKey-Value形式で保存できるAPIを組み合わせることで、オフライン時でもあらかじめキャッシュしておいたレスポンスを利用すことができるようになるわけです。

このService WorkerとCache APIの組み合わせは「Service Worker の紹介」に記載の方法で使用することができますが、より汎用的な使い方をまとめたWorkboxというライブラリを利用するのも1つの手です。Workbox を利用すると実装が煩雑になる、特定のファイルのラインタイムキャッシュも以下のようにシンプルに記述することができます。

workbox.routing.registerRoute(
  new RegExp('.*\.js'),
  workbox.strategies.networkFirst()
);

Workboxはその他にも、ファイル単位でリビジョンを付与したPrecaching、Expirationの定義やBackground Syncを利用したオフライン時の Google Analytics の計測などの機能も提供します。

オフラインの戦略はWebアプリの特性に応じて変わってくるものです。例えばニュースサイトであれば、トップページに出ている注目記事をすべて先読みし、オフラインでも読めるようにすることも考えられますし、ECサイトであればまた別の戦略が適している場合もあるでしょう。電波状況が比較的良好な日本においても、速度制限や電車内などオフライン（または不安定なネットワーク）になりえるユースケースは存在しますし、最低限でも Offline Dinasourはユーザーに見せないようにフォールバックページを用意すべきです。

その他のWeb API

以下にPWAを実装する上で注目すべきその他のWeb APIを列挙します。

• プッシュ通知: Push API / Notification API
• 自動ログイン: Credential Management API
• 支払いフォームの強化: Payment Request API

上記のAPIも組み合わせることによって、リエンゲージメント性の向上や商品の購買フローを最適化することができます。

クロスプラットフォームなイニシアチブ

上記にあげたPWAで利用するWeb APIは、すべてのブラウザで利用できることを目標に標準化を進めています。個別の対応状況を確認するにはCan I Useをご参照いただければと思いますが、冒頭に述べましたとおりiOSでもiOS 11.3からSafariでService Workerが動作するようになりましたし、Microsoft はWindowsストアにPWAを載せはじめました[6]。このように、さまざまな形でPWAのクロスプラットフォーム利用の機運が高まっていると言えます。

また、PWAはProgressive Enhancementな実装を推奨している点も改めて触れておきます。たとえばService Workerを利用したオフラインキャッシュの実装は、Service Workerが未実装なブラウザでもWebアプリ本来の動作には影響がないように以下のように条件分岐をいれることを推奨しています。

// ServiceWorkerが利用できる場合にのみ
if ('serviceWorker' in navigator) {
  // ServiceWorkerを登録する
  navigator.serviceWorker.register('/sw.js')
}

特定の環境のみでしか動かないWebアプリを作るのではなく、どの環境でもハイパフォーマンスに動作するようにし、最新のWeb APIが利用できる環境では進んでそれをレバレッジするとよいでしょう。

Webアプリ vs ネイティブ アプリ

PWAはその機能性や実現したいコンセプトから「PWAはネイティブ アプリを潰そうとしているのか？」「Webアプリがネイティブアプリにかなうはずない！」など当該テーマにおいては辛辣なコメントを見かける場面もあります。ここで1つお伝えしたいことは、多くのユーザーはネイティブアプリなのかWebアプリなのかというプラットフォームの選択には関心がないということです。大事なのは「うまい、やすい、はやい」ユーザー体験の良いサービスを提供することです。PWAの出現によりWebアプリでもそれを実現する準備が整いつつあり、事業者やソフトウェア エンジニアとしては理想のサービスを提供できるプラットフォームのオプションが増えるという意味で、このWebの進化を前向きに捉えていただければ幸いです。

実際Webアプリにはまだできないこともあります[7]。ただし、Webアプリには他のプラットフォームよりも優れたリーチがあり、その意味でWeb アプリとネイティブ アプリがむしろ手を取ることは、戦略としても決して矛盾しません。

使用したい機能がWebプラットフォームが提供するもので十分であり、技術スタックをWebのみに集約するメリットも感じるのであれば「PWA のみ」という選択肢も今後は出てくるかと思います。しかし、前述した「まだできないこともある」という前提を加味するとネイティブアプリが活躍する場面は引き続きありますし、PWAは「Webアプリ vs ネイティブアプリ」という二者択一を迫る提案ではない点をご理解ください。

ユーザー体験の新たな基準

このようにPWAはWebアプリの「ユーザー体験の新たな基準」を満たすために作られたベストプラクティスでしかありません。重要なのはそれぞれの機能を単純に実装するのではなく、Webアプリの特性に応じて使い分け、ときにはカスタマイズし、ユーザーによりよいサービスを提供することです。今回ご紹介しました各種ツールやデザインパターン、iOSでもService Workerが利用できるようになった点など、舞台は整いつつあります。ぜひとも最高のWeb体験を実現すべくPWAの考え方を取り入れてみてください。

• [1] The need for mobile speed: How mobile latency impacts publisher revenue
• [2] RAILモデルでパフォーマンスを計測する
• [3] Fast By Default: Modern Loading Best Practices (Chrome Dev Summit 2017)
• [4] Can You Afford It?: Real-world Web Performance Budgets
• [5] Above the fold
• [6] First Windows 10 Progressive Web Apps (PWA) published by Microsoft hit the Store
• [7] What Web Can Do Today

連載4回目の今回は、7月28日にリリースされた、SkyWay ScreenShareのチュートリアルをお届けします。

SkyWay ScreenShareは、WebRTCのWebアプリケーションで画面共有を簡単に実装できるライブラリ、画面共有に必要なChrome・Firefox向けのExtensionが簡単に実装できるソースコードが含まれています。

画面共有機能の概要

WebRTCの画面共有機能は、ブラウザ画面やPCのデスクトップ画面をリアルタイムで相手に配信できる機能です。

Chromeでの画面共有の様子

WebRTCの画面共有機能はChrome 34以上または、Firefox 33以上で利用可能です。

Chromeでの実装

画面共有機能は、Chrome 26で初めてブラウザに実装されました。当初は、Chromeのchrome://flagsからEnable screen capture support in getUserMedia()というフラグをONにし、getUserMedia()のオプションを指定することで、実現できていました。しかし、セキュリティ上の問題からChrome 34でそのフラグが削除され、代わりにChrome Extensionをインストールするか、Chrome Appsからしか利用できなくなりました。

Firefoxでの実装

Firefoxについては、Firefox 33から画面共有機能が実装されています。Firefoxの場合は、Chromeとは方式が異なり、about:configのmedia.getusermedia.screensharing.enabledという設定をtrueに設定し、media.getusermedia.screensharing.allowed_domainsという設定項目に、画面共有機能を許可するWebサイトのドメインを追加することで利用できるようになります。また、media.getusermedia.screensharing.allowed_domainsには、Mozillaが許可したサービスのドメインが予め設定されています。こちらにドメインを追加してもらいたい場合は、このサイトの下部に掲載されているフォームから申請が可能です。（筆者は申請したことはありませんが、恐らく審査があると思われます）

標準化の状況

WebRTCのJavaScriptAPIの標準化はW3Cで行われています。この画面共有機能についても、今年の２月に仕様書が作られて標準化が進められています。仕様書は「Screen Capture」です。仕様書についての詳細な解説は割愛しますが、現在、ChromeとFirefoxで実装されている画面共有機能はブラウザベンダごとの独自実装であり、今後実装が変更になる可能性は高いと考えられます。

SkyWay ScreenShareの使い方〜ビルド編〜

ここからSkyWay ScreenShareの使い方を説明します。はじめに、github.com/nttcom/SkyWay-ScreenShareからファイル一式をローカル環境にcloneして下さい。また、ここに書いている内容の詳細はREADMEにも掲載していますので、合わせてご覧ください。

Chrome Extensionの作成

まずはマニフェストファイルを修正します。JSONファイルのひな形にそって必要な項目を入力して下さい。アイコンファイルも必要です。

{
  "name": "Your extension name here",
  "short_name": "Your extension short_name here",
  "version": "Your extension version number here",
  "manifest_version": 2,
  "description": "Your extension description here",
  "icons": {
    "16": "icon16.png",
    "48": "icon48.png",
    "128": "icon128.png"
  },
  "permissions": [
    "desktopCapture",
    "tabs"
  ],
  "background": {
    "scripts": ["background.js"],
    "persistent": false
  },
  "content_scripts": [{
    "matches": [""],
    "js": ["content.js"],
    "all_frames": true,
    "run_at": "document_end"
  }]
}

尚、ここで重要なのは matchesです。ここには、このExtensionのりようを許可するWebサイトのURLを記載します。必ずご自身のWebサイトのURLを指定して下さい。ワイルドカードを利用して複数のURLにマッチさせることも可能ですが、その場合は、あなたのExntensionを他のWebサイトで利用される可能性があります。セキュリティ上もよろしくありません。

例："matches": ["https://*.skyway.io/*"]

次にビルドしましょう。SkyWay-ScreenShareではビルド用のgulpタスクとnpm-scriptでエイリアスコマンドを用意しています。SkyWay-ScreenShareディレクトリの直下で、次の２行のコマンドを実行します。npmコマンドは事前に使えるようにしておいて下さい。

npm install
npm run build-chrome

ビルドが完了したら、出来上がったファイルをChromeに読み込ませましょう。chrome://extensions/ にアクセスし、デベロッパーモードを有効にします。そして、パッケージ化されていない拡張機能を読み込むをクリックし、以下のディレクトリを指定します。

SkyWay-ScreenShare/chrome-extension/screenshare_chrome_extension/

読み込むと以下のようになります。（この画像はChromeウェブストアからダウンロードしたものが写っています）

Chrome Extensionを読み込みます

また、ディレクトリと同一フォルダにあるscreenshare_chrome_extension.zipは、Chromeウェブストアにアップロードする際に利用できます。

これでChrome Extensionの作成は完了です。

Firefox Extensionの作成

（注意）SkyWay-ScreenShareのリポジトリには、「Firefox Add-On」という表記で記載しておりますが、画面共有機能を利用するために作成するモノは、Firefox Extension（拡張機能）となります。Add-OnはFirefoxの拡張機能やテーマ等全ての総称となるため、リポジトリの表記とは異なりますが、本記事中では、Firefox Extensionと表記を統一させて頂きます。

Firefox Extensionでは、メインプログラムとパッケージファイルの二つを修正します。まずは、メインプログラムです。

var pageMod = require('sdk/page-mod');
var self = require('sdk/self');
var __temp = require('chrome');
var Cc = __temp.Cc;
var Ci = __temp.Ci;

var domains_to_add = [''];
var addon_domains = [];
var allowed_domains_pref = 'media.getusermedia.screensharing.allowed_domains';
var enable_screensharing_pref = 'media.getusermedia.screensharing.enabled';

 ~~ 省略 ~~

ここではdomains_to_add = [''];に、画面共有機能を有効にするWebサイトのドメインを指定して下さい。指定方法は以下のようになります。

例：domains_to_add = ['*.skyway.io']

次にパッケージファイルを修正します。ここではExtensionの基本情報を入力していきます。ひな形にそって必要な情報を入力して下さい。アイコンファイルも必要です。

{
    "name": "your_add-on_name_here",
    "title": "Your add-on title here",
    "description": "Your add-on description here",
    "author": "Your add-on author here",
    "version": "Your add-on version number here",
    "license": "Your add-on license here",
    "homepage": "Your add-on homepage url here",
    "icon64": "icon64.png",
    "icon": "icon48.png"
}

次にFirefox Extensionのビルドに必要なツール「cfx」をインストールします。インストール方法はこのサイトを参考にして下さい。

ツールのインストールが完了したら、まずはプレビルド（pre build）を行います。ExtensionをビルドするためにはランダムなIDを予めパッケージファイルに記載しておく必要があるため、初回のプレビルドで、パッケージファイルにIDを挿入しています。

npm install
npm run pre-build-firefox

初回のプレビルドでIDが挿入された場合、以下の様なエラーが発生します。これは問題ありません。

No 'id' in package.json: creating a new ID for you.
package.json modified: please re-run 'cfx xpi'

再度以下の通り、ビルドを行って下さい。

npm run build-firefox

ビルドが完了したら、Firefoxに読み込ませて動作確認を行いましょう。about://addonsにアクセスし、作成したExtension本体である、SkyWay-ScreenShare/firefox-addon/screenshare_firefox_addon.xpiをドラッグ・アンド・ドロップさせます。

Firefox Extensionを読み込みます

Firefox Extensionの配布は、通常のWebサーバ上に上記xpiファイルを設置し行って下さい。

これでFirefox Extensionの作成は完了です。

JavaScriptライブラリの作成

SkyWay-ScreenShareには今まで作成したExtensionを利用するためのJavaScriptライブラリ「screenshare.js」が同梱されています。自分でビルドする場合は、以下のように行って下さい。

npm install
npm run build-library

ビルドに成功すると、以下の通りライブラリが生成されます。

SkyWay-ScreenShare/dist/screenshare.js
SkyWay-ScreenShare/dist/screenshare.min.js

また、ライブラリはCDNでも提供しています。

<script src="https://skyway.io/dist/screenshare.js"></script>
<script src="https://skyway.io/dist/screenshare.min.js"></script>

最後に、ライブラリの修正や機能追加などは大歓迎です。TypeScriptのソースファイルを同梱していますので、その際はご利用下さい。Pull Reqestもお待ちしています！

SkyWay ScreenShareの使い方〜アプリ開発編〜

ExtensionとJavaScriptライブラリの準備ができたところで、同梱しているサンプルアプリケーションを例に、画面共有機能を使ったアプリの開発方法をご紹介します。

まず、newでオブジェクトを作成します。debugオプションを指定するとコンソールログにデバッグログが出力されます。

// スクリーンキャプチャの準備
var screen = new SkyWay.ScreenShare({debug: true});

次に、startScreenShare()メソッドを利用して、画面共有機能を開始するためのコードを実装していきます。このメソッドの第一引数には、取得する映像の縦横サイズとフレームレートを指定します。第二引数のコールバック関数は、正しく取得できた場合に呼ばれ引数としてStream Objectが返ってきます。これをVideo要素に入れてあげれば画面が表示されます。

また、第四引数についてはChromeのみ利用できるオプショナルなコールバック関数で、画面共有が何らかの方法で終了した場合に呼ばれます。Firefoxでは現状終了検知が出来ないため、Chrome限定です。

screen.isEnabledExtension() はExtensionが利用しているブラウザで有効かどうか（インストール済みかどうかも含めて）を判定します。

// スクリーンシェアを開始
$('#start-screen').click(function () {
	if(screen.isEnabledExtension()){
			screen.startScreenShare({
					Width: $('#Width').val(),
					Height: $('#Height').val(),
					FrameRate: $('#FrameRate').val()
			},function (stream){
					$('#my-video').prop('src', URL.createObjectURL(stream));
					if(existingCall != null){
							var _peerid = existingCall.peer;
							existingCall.close();
							var call = peer.call(_peerid, stream);
							step3(call);
					}
					localStream = stream;

			},function(error){
					console.log(error);
			},function(){
					alert('ScreenShareを終了しました');
			});
	}else{
			alert('ExtensionまたはAddonをインストールして下さい');
	}

});

次に、画面共有をプログラム側で終了させる場合のコードを実装していきます。現在は終了のための専用メソッドは用意していません。先ほど取得したStream Objectを保持しておき、終了したいタイミングでstop()メソッドを読んで下さい。これで、画面共有が止まります。いずれ、Stream Objectの管理機能を実装する予定なので、その時には専用のメソッドを用意します。

// スクリーンシェアを終了
$('#stop-screen').click(function () {
	localStream.stop();
});

アプリ開発方法の紹介は以上です。

おわりに

今回は、SkyWay-ScreenShareを使った、WebRTCの画面共有機能の実装方法をご紹介しました。画面共有機能は様々なユースケースで活用できる機能ですので、是非ご自身のアプリケーションに組み込んでみてください！

次回は、同じく7月28日にリリースされたSkyWay-DrivingVehicleについてのチュートリアルをお届けいたします。

連載3回目の今回は、SkyWayの付加機能としてリリースされているSkyWay音声認識機能の利用方法についてお届けいたします。SkyWay音声認識機能とは、クライアント（ブラウザ側）でマイク等を通じて入力した自由発話音声を、サーバ（SkyWay側）と連携して、文字列として受け取る機能のことです。いますぐ試してみたい方は、デモサイトから試用可能です。(注：WebSocketが疎通する環境でないと、正常に動作しません)

同様の機能を実現するAPIとして、Speech Recognition APIがありますが、caniuse.comでも示されるように対応するブラウザが限定されています。SkyWay音声認識機能では、標準では対応していないFirefox等のブラウザも対応可能です。

準備

以降で記載するサンプルコードの中で、SkyWayが提供しているAPIキーが必要となります。実際にお手元で試される場合は、SkyWay公式サイトから開発者登録を行ってください。本記事のサンプルで利用するには、利用可能ドメインに「localhost」と書いた、APIキーを取得する必要があります。

今回作成するサンプル

作成するサンプルは、「音声認識を開始するボタン」と「認識結果を表示するエリア」の2要素のみで構成するシンプルな音声認識アプリケーションです。

スクリーンショットはこちらです。

SkyWay音声認識スクリーンショット

こちらを構成しているサンプルコードは以下の通りです。

<!DOCTYPE html>
<html lang="ja">
<head>
	<title>SkyWay Speech Recognition Sample</title>
</head>
<body>

<!-- 音声認識開始用のボタン、および結果表示用のエリア -->
<button id="start_rec">start</button>
<div id="result"></div>

<!-- 必要なライブラリ群の読み込み  -->
<script src="https://code.jquery.com/jquery-1.11.3.min.js"></script>
<script src="https://skyway.io/dist/msgpack.codec.js"></script>
<script src="https://skyway.io/dist/libspeexdsp.js"></script>
<script src="https://skyway.io/dist/resampler.min.js"></script>
<script src="https://skyway.io/dist/speechrec.min.js"></script>

<!-- 音声認識用のコードサンプル -->
<script>
SpeechRec.config({
   'SkyWayKey':'3969c30a-2789-4e46-9155-79a188256633',
   'OpusWorkerUrl':'libopus.worker.js'
});

$("#start_rec").click(function(){
	SpeechRec.start();
	console.log("音声認識を開始します");
});

SpeechRec.on_proc(function(info){
	console.log(info.volume);
});

SpeechRec.on_result(function(result){
    console.log(result.candidates);
    $("#result").text(result.candidates[0].speech);
});
</script>

</body>
</html>

上記HTMLを任意の名前で保存してください。本記事ではsample.htmlという名前で保存します。また、htmlを格納するディレクトリと同じ階層に

• libopus.js
• libopus.worker.js

の2ファイルを保存して置いてください。音声認識に必要なライブラリとなります。　

動かしてみよう

既にApacheやNginxをインストールされている場合はそちらも活用できますが、今回はpythonからシンプルなWebサーバを起動してみます。コマンドはpython -m SimpleHTTPServerです。

localhostの8000番でWebサーバが起動するので、http://localhost:8000/sample.htmlへ、Chrome/Firefox/Operaのいずれかでアクセスしてみましょう。画面が表示されたら、「start」ボタンをクリックすると、マイク使用許可確認のポップアップが表示されますので、Allow/許可を押下します。その後に自由に発話して、適当なタイミングで発話をやめてください。音声認識結果が上手くいくと、数秒以内に音声認識結果の文字列が表示されます。

コードのポイント解説

SkyWay音声認識機能を利用するためには、大きく分けて2つの処理が必要になります。

1. コンフィグの設定・コールバックの設定

まずSpeechRec.config関数を利用して、SkyWayKeyおよびlibopus.worker.jsへのパスを設定します。サンプルでは、以下のようにconfigを設定しています。

SpeechRec.config({
   'SkyWayKey':'3969c30a-2789-4e46-9155-79a188256633',
   'OpusWorkerUrl':'libopus.worker.js'
});

SpeechRec.configには、その他のパラメータも設定可能であり、ドキュメントから確認できます。

次に各種コールバックの設定をします。サンプルでは2種類のコールバックを設定しています。

SpeechRec.on_proc(function(info){
	console.log(info.volume);
});

SpeechRec.on_result(function(result){
    console.log(result.candidates);
    $("#result").text(result.candidates[0].speech);
});

1つ目のon_procは、発話時の音声ボリュームを取得できた場合に発火するコールバック関数です。サンプルでは、コンソール画面に音量を表示するようにしています。

2つ目のon_resultは、音声認識結果を取得できた場合に発火するコールバック関数です。サンプルでは、結果をコンソール画面に表示する処理、および#resultで指定されるdivエリアに、音声認識結果を書き込む処理をしています。

サンプルでは分かりやすいように、コールバックを2つのみしか設定していませんが、実際にはさらに多くのコールバックを設定可能です。詳細はコールバック関数一覧をご確認ください。

2. 開始・停止の実行

コンフィグおよびコールバックの設定が完了したら、実際に音声認識を開始・停止するための関数を呼び出します。サンプルでは、#start_recボタンがクリックされた際に呼び出すSpeechRec.startが、音声認識を開始するための処理に該当します。

$("#start_rec").click(function(){
	SpeechRec.start();
	console.log("音声認識を開始します");
});

なお、開始だけではなく任意のタイミングで音声認識を終了させるSpeechRec.stop等もあります(サンプルでは省略)。その他の関数はドキュメントから確認いただけます。

おわりに

いかがでしたでしょうか。今回はSkyWayの付加機能である、音声認識機能について解説いたしました。

次回は画面共有を簡単に実現するSkyWayScreenShareライブラリについてお届けします。

連載2回目の今回は、7月28日にリリースされたライブラリ、SkyWay MultiPartyのチュートリアルをお届けします。 SkyWay MultiPartyは、一言で言うと多人数によるビデオ・テキストチャットを『簡単に』作るためのライブラリです。

本ライブラリを使用することで、グループビデオチャットやテキストチャットを、 ほんの20行程度のJavaScriptコードで実装をすることができます。

サンプルコードを用意していますので、手元で実行しながら進めてみましょう。

10行ビデオチャット

以下のスクリーンショットをご覧ください。

まずはこのような複数人が参加できるビデオチャットシステムを、10行程度のJavaScriptコードで実装してみましょう。 サンプルコードを以下に記載します。

<!doctype html>
<html>
<head>
  <script src="https://code.jquery.com/jquery-1.11.3.min.js"></script>
  <script src="https://skyway.io/dist/0.3/peer.min.js"></script>
  <script src="https://skyway.io/dist/multiparty.min.js"></script>
  
  <style> video { width:200px; } </style>

</head>
<body>

  <div id="streams"></div>

<script>

  // MultiParty インスタンスを生成
  multiparty = new MultiParty( {
    "key": "********-****-****-****-************"  /* SkyWay keyを指定 */
  });

  multiparty.on('my_ms', function(video) {
    // 自分のvideoを表示
    var vNode = MultiParty.util.createVideoNode(video);
    $(vNode).appendTo("#streams");
  }).on('peer_ms', function(video) {
    // peerのvideoを表示
    var vNode = MultiParty.util.createVideoNode(video);
    $(vNode).appendTo("#streams");
  }).on('ms_close', function(peer_id) {
    // peerが切れたら、対象のvideoノードを削除する
    $("#"+peer_id).remove();
  });

  // サーバとpeerに接続
  multiparty.start()

</script>
</body>
</html>

早速動かしてみましょう。

上のコードを、videochat.htmlという名前で保存します。

19行目でSkyWayのAPIキーが必要となりますので、使用する際はSkyWayから開発者登録を行ってください。 本サンプルで使用するには、利用可能ドメインに『localhost』と書いて、APIキーを取得する必要があります。

PCにApacheやNginxなどのサーバがインストールされている場合は、そちらで動かしても問題ありませんが、 入っていない場合は、以下の様にPythonのコマンドでWebサーバを起動できます。

python -m SimpleHTTPServer

localhostの8000番ポートでWebサーバが起動するので、Chrome、Firefox、Operaのいずれかのブラウザでアクセスしてみましょう。

次に別のタブやブラウザで、もう2、3個同じページを開いてみます。

複数人参加のビデオチャットが実装できていることがわかります。

ビデオチャットのコード

それではコードを見てみましょう。

今回はjQueryを使用するので、4行目でjQueryを読み込んでいます。 (SkyWay MultiPartyを使用するのにjQueryが必須というわけではありません) 5行目と6行目で、SkyWayライブラリ(peer.min.js)とSkyWay MultiPartyライブラリ(multiparty.min.js)を読み込んでいます。 13行目で、ビデオを表示するためのdivを1つ用意しています。

18〜33行目がJavaScriptコードです。大きくMultiPartyオブジェクトの生成部分と、イベントハンドラ部分に分かれています。

SkyWay MultiPartyでは、最初にコンストラクタを呼ぶことで MultiPartyオブジェクトを生成します。引数にはAPIキーが必要となります。

// MultiParty インスタンスを生成
  multiparty = new MultiParty( {
    "key": "********-****-****-****-************"  /* SkyWay keyを指定 */
  });

続くコードがmultipartyオブジェクトのイベントハンドラになります。

multiparty.on('my_ms', function(video) {
    // 自分のvideoを表示
    var vNode = MultiParty.util.createVideoNode(video);
    $(vNode).appendTo("#streams");

  }).on('peer_ms', function(video) {
    // peerのvideoを表示
    var vNode = MultiParty.util.createVideoNode(video);
    $(vNode).appendTo("#streams");

  }).on('ms_close', function(peer_id) {
    // peerが切れたら、対象のvideoノードを削除する
    $("#"+peer_id).remove();
  });

SkyWay MultiPartyでは、

multiparty.on('イベント名', コールバック関数)

の形式で、イベントハンドラを設定することができます。

サンプルでは3つのイベントに対し、ハンドラを定義していることがわかります。

1つ目が'my_ms'で、これは自分のメディアストリームの準備が整った際に発生するイベントです。メディアストリームとは取得した映像や音声を扱うためのオブジェクトで、例えばPCのカメラやマイクから取得した映像・音声がこれにあたります。 コールバックとして呼ばれる関数には、メディアストリームから生成したオブジェクトURLとidがオブジェクトとして渡されます。 ライブラリにはそのオブジェクトからvideoノードを生成するユーティリティが用意されていますので、それを使用しvideoノードを生成・表示しています。

2つ目は、'peer_ms'というイベントに対するコールバックで、これはチャットの相手(peer)のメディアストリームを取得する準備が整った際に発生するイベントです。 こちらも自分のメディアストリームと場合と同様、videoノードを生成・表示しています。

3つ目のイベントは'ms_close'で、peerのメディアストリームの切断を検知した際に発生します。 このコールバックでは、peerのvideoノードを削除する処理を書いています。

以上で、ビデオチャット機能を実装することができました。

10行テキストチャット

続いてテキストチャット機能も実装してみましょう。

まず、テキストの入力と表示を行うためのHTML要素を追加します。 以下のコードを『<div id="streams"></div>』の下に追加してみましょう。

<div>
    <form>
      <input type="text"><button type="submit">send</button>
    </form>
    <div id="message"></div>
  </div>

次に、以下のJavaScriptコードを、『</script>』の前に追加します。

//テキストを入力し、submitしたとき
  $("form").on("submit", function(ev) {

    //onsubmitのデフォルト動作（reload）を抑制
    ev.preventDefault();

    //テキストを取得
    var $input = $(this).find("input[type=text]"); 
    var data = $input.val();
    $input.val("");

    //テキストを表示
    $("#message").append(data + "<br>");

    //peerにメッセージを送信
    multiparty.send(data);

  });

  // peerからテキストメッセージを受信したとき
  multiparty.on('message', function(mesg) {
    $("#message").append(mesg.data + "<br>");
  });

それでは先ほどのページをリロードしてみましょう。

入力フォームが追加されたことがわかります。 文字を入力し、エンターキーを押すと、そのテキストが表示されます。

他のタブや、ブラウザから入力したテキストも表示できることが確認できます。

テキストチャットのコード

それではコードを見てみましょう。 テキストチャットのコードは、データを送信する際の処理と、データを受信する際の処理に分かれています。

以下のコードで、テキストが入力され、送信されるまでの処理を記述しています。

//テキストを入力し、submitしたとき
$("form").on("submit", function(ev) {

  //onsubmitのデフォルト動作（reload）を抑制
  ev.preventDefault();

  //テキストを取得
  var $input = $(this).find("input[type=text]"); 
  var data = $input.val();
  $input.val("");

  //テキストを表示
  $("#message").append(data + "<br>");

  //peerにメッセージを送信
  multiparty.send(data);

});

multiparty.send()で、テキストをそのまま送信していることがわかります。

そして以下の部分で、メッセージを受信した際に発生するイベント'message'に対する、コールバックを設定しています。

// peerからテキストメッセージを受信したとき
multiparty.on('message', function(mesg) {
  $("#message").append(mesg.data + "<br>");
});

簡易ではありますが、テキストチャットを実現することができました。

おわりに

今回は、SkyWay MultiPartyを使ったビデオ・テキストチャットの作り方をお届けしました。 少しのコードで簡単に実装できることがお分かりいただけたかと思います。

次回は、同じく7月28日にリリースされたSkyWay音声認識APIについてのチュートリアルをお届けいたします。

WebRTCを簡単に利用するためのプラットフォームSkyWayをご存知ですか？本連載では、WebRTCを簡単に利用するためのプラットフォームSkyWayについて、基本的なチュートリアルから、各種ライブラリの紹介までしていきます。

連載第1回目である今回は、まず、WebRTCの基本的な説明をした後に、実際にSkyWayを使って、ビデオチャットの作成とデータチャンネルを使ったチャットの作成をしていきます。

WebRTCとは

WebRTCとは、ブラウザやアプリ間でビデオや音声、データのやり取りをP2P(Peer to Peer)で行うことを可能にする規格です。 従来のビデオチャットは互換性のない独自技術で実装されていましたが、WebRTCはオープン標準として仕様が作成・公開されており、相互接続が保証されています。

また、ブラウザで動作することから特別なアプリケーションをインストールする必要がありませんし、すでにあるウェブアプリケーションに埋め込むことで、シームレスにビデオチャットを動かすこともできます。さらに、オープンソースのコードを利用することで、ブラウザだけに限らず、ネイティブアプリにWebRTCを組み込むことも可能です。

WebRTCの仕組み

WebRTCはビデオ等のデータをP2Pでやり取りすることが出来ますが、実際にブラウザ間で直接接続をするためには、まず、互いに自分のIPアドレス／ポート番号等の情報を教え合わなければなりません。一般的に、この情報交換を行うためにシグナリングサーバというサーバを用意する必要があります。

※交換する情報はIPアドレス、ポート番号以外にもいくつかあります。

また、お互いがNATの内側に存在する場合やFirewallの内側にいる場合、シグナリングサーバだけでは接続することができません。そのために利用するのが、STUN／TURNサーバです。ここでは具体的な説明は省略しますが、作成したアプリケーションをユーザに広く使ってもらうためには、これらのサーバも用意する必要があります。

(詳細を知りたい方は、がねこまさしさんが書かれたコチラの記事をお読みください: 壁を越えろ！WebRTCでNAT/Firewallを越えて通信しよう)

SkyWayとは

今までの説明を見てWebRTCは「大変そうだ」と思った方は多いと思います。実際、シグナリングサーバやSTUN/TURNサーバを用意するのは容易ではないです。

そこで登場するのがWebRTC開発者向けプラットフォーム「SkyWay」です。SkyWayは、以下の図で示す通り、複雑なシグナリング処理を担うAPI郡とJavascriptライブラリ／Android,iOSライブラリ、STUN/TURNサーバで構成されています。

このSkyWayを利用することで、シグナリングサーバやSTUN/TURNサーバを独自に用意する必要はなく、開発者はP2P通信部分のプログラミングにのみ集中することができます。

利用者登録が必要です

SkyWayは現在トライアルサービス中で、誰でも無料で使うことができます。さっそくウェブサイトから利用者登録をしてみましょう。

http://skyway.io/

「登録を行う」ボタンをクリックして、開発者登録画面に向かいます。

必要事項を入力します。ここで入力するドメイン名は、セキュリティ向上を目的として行っているOriginチェックのために必要となっています。ここのドメイン名は開発者登録後に変更可能ですので、まずは「localhost」とだけ入力しておいてください。

登録が正常に完了したら、ログインページへ行き、ログインしてください。ログインが完了すると以下の画面のような開発者ダッシュボードが表示されます。

右に表示されいるのがAPIキーです（上図ではマスクしています）。こちらをJavaScriptやiOS/Androidのコード内に埋め込み、SkyWayのAPIにアクセスします。

ちなみに、設定変更ボタンをクリックすると、利用ドメインの編集やRestAPIの有効無効の切り替え、そしてAPIキーの削除が可能です。

これでSkyWayを利用するための準備が整いました。早速ビデオチャットを実装してみましょう。

簡易ビデオチャットの作成と実行

まず、ビデオチャットを実装するにあたり、以下の環境をご用意ください。

• Chorme, Firefox, Operaのいずれかのブラウザ
• カメラ／マイク （PCに接続可能なもの）

まずは以下の内容で、HTMLを書きます。適当なフォルダに「videochat.html」というファイル名でHTMLファイルを作成してください。

    
    
    


    
Simple Video Chat
    

        
        
    
    

        
MyID: -
        
PeerID: -
    
    

        
        Start Call
        End Call
    

HEADタグ内で、jQueryとSkyWayライブラリ、そして今回作成するビデオチャット用のJavaScriptを読み込んでいます。jQueryはボタンクリック時のイベントを設定するときに使用します。SkyWayライブラリは今まで説明してきたとおり、シグナリング部分の処理を全部行ってくれるライブラリです。

次にJavaScriptのコードを書きます。先ほどのHTMLと同じフォルダに、「videochat.js」というファイル名でJavaScriptのファイルを作成してください。ここで、APIキーは先ほど入手したものに置き変えて入力してください。

// カメラ／マイクにアクセスするためのメソッドを取得しておく
navigator.getUserMedia = navigator.getUserMedia || navigator.webkitGetUserMedia || navigator.mozGetUserMedia;

var localStream;    // 自分の映像ストリームを保存しておく変数
var connectedCall;  // 接続したコールを保存しておく変数

// SkyWayのシグナリングサーバーへ接続する (APIキーを置き換える必要あり）
var peer = new Peer({ key: 'YourApiKey', debug: 3});

// シグナリングサーバへの接続が確立したときに、このopenイベントが呼ばれる
peer.on('open', function(){
    // 自分のIDを表示する
    // - 自分のIDはpeerオブジェクトのidプロパティに存在する
    // - 相手はこのIDを指定することで、通話を開始することができる
    $('#my-id').text(peer.id);
});

// 相手からビデオ通話がかかってきた場合、このcallイベントが呼ばれる
// - 渡されるcallオブジェクトを操作することで、ビデオ映像を送受信できる
peer.on('call', function(call){
  　
    // 切断時に利用するため、コールオブジェクトを保存しておく
    connectedCall = call;

    // 相手のIDを表示する
    // - 相手のIDはCallオブジェクトのpeerプロパティに存在する
    $("#peer-id").text(call.peer);

    // 自分の映像ストリームを相手に渡す
    // - getUserMediaで取得したストリームオブジェクトを指定する
    call.answer(localStream);

    // 相手のストリームが渡された場合、このstreamイベントが呼ばれる
    // - 渡されるstreamオブジェクトは相手の映像についてのストリームオブジェクト
    call.on('stream', function(stream){

        // 映像ストリームオブジェクトをURLに変換する
        // - video要素に表示できる形にするため変換している
        var url = URL.createObjectURL(stream);

        // video要素のsrcに設定することで、映像を表示する
        $('#peer-video').prop('src', url);
    });
});

// DOM要素の構築が終わった場合に呼ばれるイベント
// - DOM要素に結びつく設定はこの中で行なう
$(function() {

    // カメラ／マイクのストリームを取得する
    // - 取得が完了したら、第二引数のFunctionが呼ばれる。呼び出し時の引数は自身の映像ストリーム
    // - 取得に失敗した場合、第三引数のFunctionが呼ばれる
    navigator.getUserMedia({audio: true, video: true}, function(stream){

        // このストリームを通話がかかってき場合と、通話をかける場合に利用するため、保存しておく
        localStream = stream;

        // 映像ストリームオブジェクトをURLに変換する
        // - video要素に表示できる形にするため変換している
        var url = URL.createObjectURL(stream);

        // video要素のsrcに設定することで、映像を表示する
        $('#my-video').prop('src', url);

    }, function() { alert("Error!"); });

    // Start Callボタンクリック時の動作
    $('#call-start').click(function(){

        // 接続先のIDをフォームから取得する
        var peer_id = $('#peer-id-input').val();

        // 相手と通話を開始して、自分のストリームを渡す
        var call = peer.call(peer_id, localStream);
            
        // 相手のストリームが渡された場合、このstreamイベントが呼ばれる
        // - 渡されるstreamオブジェクトは相手の映像についてのストリームオブジェクト
        call.on('stream', function(stream){
            // 相手のIDを表示する
            $("#peer-id").text(call.peer);

            // 映像ストリームオブジェクトをURLに変換する
            // - video要素に表示できる形にするため変換している
            var url = URL.createObjectURL(stream);

            // video要素のsrcに設定することで、映像を表示する
            $('#peer-video').prop('src', url);
        });
    });

    // End　Callボタンクリック時の動作
    $('#call-end').click(function(){
        // ビデオ通話を終了する
        connectedCall.close();
    });
});

これらはローカルのファイルとして開いても動作しません。ローカルPC上にサーバを立ててファイルをホスティングしてあげる必要があります。このためだけにローカルPCにApacheやNginxを入れるのもの大変なので、今回はPHP付属のビルトインサーバを利用します。 ターミナルを開いて次のコマンドを入力してください (要PHP5.4.0以上)

$ cd {HTML/Javascriptのあるフォルダ}
$ php -S localhost:8888

これで準備が全て整いました。早速ブラウザで開いてみましょう。WebRTCは現在のところChrome, Firefox, Operaでしか動作しないため、それらのブラウザを利用する必要があります。また現在も開発が続けられている分野ですので、最新バージョンを利用するのが望ましいです。

今回は、ビデオ通話を開始する側と受ける側の両方を自分で試してみます。ですので、以下のURLを2つのウィンドウ（またはタブ）で開いてみてください。

http://localhost:8888/videochat.html

無事に表示されたでしょうか？

アクセス時に、カメラとマイクへのアクセスについて許可を求められるので、許可しておきましょう。許可すると、カメラ映像が画面左に表示されます。

それでは、早速通話を開始してみたいと思います。まず、接続相手のIDを渡す必要があります。ビデオ通話を受ける側のIDをコピーして、かける側のテキストボックスに貼り付けてください。相手のIDをちゃんと貼り付けることができたなら、隣の「Start Call」を押します。

2つの映像が表示されれば成功です。

以上が簡単なビデオチャットのチュートリアルでした。非同期処理が中心でかつ、通話を開始する側と受ける側の両方の処理を書く必要があるため、慣れるまでコードの理解が難しいですが、ここさえ乗り越えればスムーズにコードを書くことができますので、少しづつ理解してみてください。

データ通信を使った文字ベースチャット

続いてWebRTCを用いたデータ通信を使ったチャットアプリを作ってみたいと思います。既にビデオチャットを理解できていれば、全く難しいことはありません。

先ほどと同様に、以下の内容で、HTMLを書きます。適当なフォルダに「datachat.html」というファイル名でHTMLファイルを作成してください。

    
    
    


    
Chat
    

        
        Connect
        Close
    
    

        
MyID: -
        
PeerID: -
    
    

    

        
        Send
    
    

次はJavaScriptです。先ほどのHTMLと同じフォルダに「datachat.js」というファイル名でJavaScriptのファイルを作成してください。 APIキーについてもビデオ通話と同様に、先ほど入手したものに置き変えてください。

var conn;     // データ通信用connectionオブジェクトの保存用変数 

// SkyWayのシグナリングサーバーへ接続する  (APIキーを置き換える必要あり）
var peer = new Peer({ key: 'YourApiKey', debug: 3});

// シグナリングサーバへの接続が確立したときに、このopenイベントが呼ばれる
peer.on('open', function(){
    // 自分のIDを表示する
    // - 自分のIDはpeerオブジェクトのidプロパティに存在する
    // - 相手はこのIDを指定することで、通信を開始することが出来る
    $('#my-id').text(peer.id);
});
 
// 相手からデータ通信の接続要求イベントが来た場合、このconnectionイベントが呼ばれる
// - 渡されるconnectionオブジェクトを操作することで、データ通信が可能
peer.on('connection', function(connection){
  　
    // データ通信用に connectionオブジェクトを保存しておく
    conn = connection;

    // 接続が完了した場合のイベントの設定
    conn.on("open", function() {
        // 相手のIDを表示する
        // - 相手のIDはconnectionオブジェクトのidプロパティに存在する
        $("#peer-id").text(conn.id);
    });

    // メッセージ受信イベントの設定
    conn.on("data", onRecvMessage);
});

// メッセージ受信イベントの設定
function onRecvMessage(data) {
    // 画面に受信したメッセージを表示
    $("#messages").append($("
").text(conn.id + ": " + data).css("font-weight", "bold"));
}

// DOM要素の構築が終わった場合に呼ばれるイベント
// - DOM要素に結びつく設定はこの中で行なう
$(function() {

    // Connectボタンクリック時の動作
    $("#connect").click(function() {
        // 接続先のIDをフォームから取得する
        var peer_id = $('#peer-id-input').val();

        // 相手への接続を開始する
        conn = peer.connect(peer_id);

        // 接続が完了した場合のイベントの設定
        conn.on("open", function() {
            // 相手のIDを表示する
            // - 相手のIDはconnectionオブジェクトのidプロパティに存在する
            $("#peer-id").text(conn.id);
        });

        // メッセージ受信イベントの設定
        conn.on("data", onRecvMessage);
    });

    // Sendボタンクリック時の動作
    $("#send").click(function() {
        // 送信テキストの取得
        var message = $("#message").val();

        // 送信
        conn.send(message);

        // 自分の画面に表示
        $("#messages").append($("
").html(peer.id + ": " + message));

        // 送信テキストボックスをクリア
        $("#message").val("");
    });

    // Closeボタンクリック時の動作
    $("#close").click(function() {
        conn.close();
    });
});

では、ローカルにHTTPサーバを立てて開いてみましょう。

$ cd {HTML/Javascriptのあるフォルダ}
$ php -S localhost:8888

http://localhost:8888/datachat.html

先程と同様に、接続を開始する側と接続を受ける側の両方が必要なため、2つ開いてください。無事に表示されましたでしょうか？

それでは、データ通信を開始してみたいと思います。接続相手のIDをコピーして、接続を開始する側のテキストボックスに貼り付けて、Connectボタンを押してください。

相手のIDがお互いの画面に表示されれば接続できています。では、チャット欄に文字を入力してSendボタンを押してみましょう。 相手の画面と自分の画面、両方に表示されれば成功です。

以上が簡単なテキストチャットのチュートリアルでした。WebRTCを使えば、テキストだけじゃなく、JavaScriptのオブジェクトやファイル等も送ることが可能です。

おわりに

今回はSkyWayを使った、簡単なビデオチャット／文字ベースチャットのチュートリアルをお届けしました。WebRTCは便利で高機能な反面、自分で実装しようとすると大変ですが、SkyWayを使うことで手軽に利用可能です。

次回はSkyWayを使って、Android/iPhoneでWebRTCを簡単に使う方法をお伝えしたいと思います。

スゴい人たちに集まってもらって、「Webは死ぬか」について語り合っていただいたスペシャル企画。前半は「Webメディア・コンテンツ」について、それぞれのご意見を伺いました。

メディアビジネスからCookie、ディープラーニングまで──ビジネス面に注目した 前半とは異なり、後半はWebのテクノロジー面にフォーカスして、「死ぬか？」を論じていただきたいと思います。今回は、（含蓄を多量に含んだ）脱線多めで失礼します！

「ブラウザ」の存在感が薄れていく時代

白石 前半はビジネス面に注目してお話いただいたので、後半はテクノロジー面にフォーカスしていきたいと思います。いわば、「Webテクノロジーは死ぬか？」というお話になるかと思います。例えばよく取り沙汰されるのがネイティブ vs Web、みたいな話ですが…

羽田野 そういう話もいいですが、僕はWebの位置付けから話したいですね。Webというものを一般の人々がどう見るか、がここ数年でずいぶん変わったんじゃないかと思うんです。

昔はWebにアクセスしようとすると、ブラウザをまず立ち上げていました。でも今はそうじゃなくて、モバイルで何かしようとするとまずアプリを立ち上げますよね。

白石 「Webブラウザを（意識的に）立ち上げる」という行動は、モバイルデバイス上ではめちゃくちゃ減ってそう ですよね。検索するときくらいでしょうか？検索って行動自体、スマホユーザはそれほど頻繁に行っているのかどうかも疑問ですが…うちの妻なんかは、だいたいLINEかゲームか、という感じです(笑)。

羽田野 それは人によりそうですよね。うちの家族なんかは、割と検索はしてるみたいです。でも、ブラウザという言葉は知らないでしょうね。たぶんうちの子供なんかは、Webという言葉も知らない。

白石 こういうお話って、ブラウザ作ってる方からするとどうですか。少なくとも消費者にとっては、「ブラウザ」という存在がかつてほど重要じゃなくなっているのではないか、という指摘だと思いますが。

及川 そうですね…まずはWebをどう捉えるか、「Webとは何か？」という話から始める必要があると思います。その上で、ブラウザとは何なのか？を考えてみる。

僕はここ数年、Webとは何か、Web技術とは何かをずっと考えてきました。例えば「プロトコルとしてのHTTPを使っていればWebである」という話もあれば、コンテンツやアプリのプラットフォームという側面もある。コンテンツという点で言えば、セマンティック性を持つHTMLという技術は未だに非常に重要だし、（Webは）それに依存している。だからクローラがHTMLを機械的に処理することもできる。検索エンジンそのものも、HTMLに深く依存しているし、いまだにスケールしているところであると。

もう一方で、どうやってユーザにそれ（コンテンツ）をリーチさせるかというところに関してはどうでしょう。例えば、RSSがなくなりつつある。そもそも（RSS）フィードと呼ばれるものだって、あれはパーマネントなリンクってものの集まりだったなわけじゃないですか。そうすると、URL、URIが持つ強みってところが非常に大きいんですよ。

例えばある人から見た場合には、中身、コンテンツはなんでもいいんですよ。もしかしたら、HTMLが書かれていなくてもいいかもしれない。CSVでもいいかもしれない。単なるテキストでもいいかもしれない。URI/URLの、インターネットという巨大な名前空間の中で、一意に特定できるというパワーはすごい わけです。

白石 なるほど。

及川 考えてみた場合、HTMLとURIはどちらもすごく重要だし、いまだにリプレースできるものはないくらいの存在なわけですね。少なくとも技術という面で見た場合、この二つ（HTMLとURI）は非常に強力だし、今後も生き続けていくんじゃないかと思います。

そしてブラウザ云々というのはここにまさしく関わっていて、その両方をパッケージとしたものだったわけです。ここ20年近く使われている、いわゆるWebといったものを使うためには、ブラウザというものがフロントエンドに必要だった。しかしその一部しか使わないのならば、そのフロントエンド部分というのは、ネイティブアプリでもいいし、何でもいい。それでもWeb技術を使っているのは間違いない。

例えばIoTの文脈でも、デバイス間がつながるというところでURIを使いましょう、というのをGoogleが実験的に提唱しているんですが…。

白石 Physical Webってやつですね。

及川 そうです。例えばそれを使うとなった場合、「Web技術を使ってるでしょ」と言われればまさしくその通り、というわけです。

Webの本質とは何か？

羽田野 Webって言葉がすごく曖昧ですよね。ある人にとってはプロトコルですが、僕らにとってはブラウザの上で動くアプリのことだったりするし。

及川極端な話をすると、Webアプリを作るぞとなったときに、HTTPじゃなくてWebSocketを使うことにして、さらにそこにバイナリを流して…ってなったら、ほぼUnixのソケットアプリケーションみたいになるわけですよ。そしてバイナリを紐解くところに例えばNative Client (※)を使うとなったら、HTMLもJavaScriptも使っていないわけです。それは果たしてWebなんでしょうか？でも、ブラウザで動いているわけですよね。

こう考えると、Webの本質というのは考えてみると難しくて。何を持ってWebと呼ぶか？先ほど僕は、HTMLとURIはどちらも重要と申し上げましたが、HTMLを使わないWebは容易に考えうるわけです。

だから僕が最近思うのは、Webの本質ってURIかな、と思っています。「一意に決まる」ということ。

白石 Webから、代替可能なものを全て削ぎ落とすと、URIが残るという感じでしょうか。

及川 そうですね。そもそもインターネットって、シンプリシティ（単純さ）から始まっている んですよ。OSI参照モデルって昔やってたんですけど、OSIってとてつもなく分厚い技術書があるわけです。あんなの実装できるわけないんだけど─4年くらいかかって実装したDECだとか、大変な目にあったわけですが。（※及川さんは元DEC）

一同: (笑)。

及川 ああいうのをやっていた当時の技術者からすると、そこに出てきたTCP/IPなんていうのは、当時の技術者からすると「バカにしてんのか？」っていうくらいシンプルだった。テキストでTelnetでつないでサーバと会話できちゃう、っていう。「なんだこれ？」の世界ですよ。でも、あのシンプリシティが「勝った」わけですね。

RESTに関しても、2000年代前半にあったいわゆる「（XML） Webサービス」も、今やほとんど使われてなくて、ほとんどの場合RESTが使われるようになっている。それも単純さが持つ力です。そうした単純さを突き詰めると、結局Webの本質は、URI/URLというところに行き着くのかな、と思っています。

羽田野 まさに、IoTの世界にもURI/URLは食い込もうとしていますしね。誰も異論はないところかな、と思いますよ。

清水 HTTPも2になっちゃうと、ずいぶん変わっちゃうわけで。もはや、僕らが知っている牧歌的なHTTPではない。Webと言った場合、もはやプロトコルすら指していないんじゃないかとは思いますね。

及川 そのとおりですね。HTTP/1って今の時代には必ずしも最適化されていないんです。SPDYを始め、2も出てきていて、そこ（プロトコル）もリプレースされていくのはそのとおりだと思いますね。Googleも、まだ標準化の方には進めていないですが、QUIC(※)なんてプロトコルも作っていたりしますし。

※ Native Client…Googleが開発した、Webページ上でC/C++のコードを安全に実行するための仕組み（Wikipedia）
※ QUIC…Googleが開発している実験的なトランスポートレイヤーネットワークプロトコル（Wikipedia）

エンジニアにとってのWebの「安心感」

清水 ところで急にエンジニアっぽくないことを言うんですが、Webの安心感ってすごい んですよね。

白石 安心感？どういう意味ですか？

清水 例えば今、ディープラーニングとかやっていて、Facebookが作ったTorchってやつとか、NVIDIAのDIGITSっていうツールセットとかあるんですが、フロントエンドがWebなんです。

インストールして起動するとnginxが立ち上がって、操作は全部Webブラウザからしてください、と。CUIもあって、コマンドラインはコマンドラインである種の安心感あるんだけど、Web（画面）が出てきた時の安心感ってすごくて(笑)。「（エンジニアが）ハンドルできる」っていうのが伝わってくるっていうか。この安心感って、Webが持ってる強力な力かな、と。

あともう一つは、先ほどの及川さんの「単純さ」の意見に賛同するものですが、一回画面レンダリングしたら終わり、っていう世界観が元々のWebにはあったわけで。それって、書いてる方もすごく安心なんですよね。

今うちの会社は、紆余曲折あってPHPを全社的に使っているんですが、画面を一回書けばおしまいっていうのが、可用性的に安心して使えるんです。これがJavaだったら、どこか一箇所に間違いがあったらシステム全体デプロイしなおさなくちゃいけないところが、PHPだったら、「今見てる人は前のバージョン、次来た人は新しいバージョン」っていう割り切りができる。リクエストごとにトランザクションが終了する、っていうのが、実はシンプルかつ強力な機能なんです。

React（の仮想DOM）なんかは、そこまでもバーチャルにして効率的なやりとりをしましょう、というのはわかりつつも、そもそも元々Webが持っているパラダイム、頭からお尻まで書いてトランザクション終了、っていう思想を、今風にカッコよくしただけのものだとも思っています。

それくらいWebが持っていたシンプリシティっていうのはすごく強力で、Webで操作できるってことはつまり、プロトコルがRESTで用意されているってこと。ってことは、プログラム同士も繋げられるし、サービス同士も繋げられるし、要はマッシュアップできるっていう。Webが流行り始めてもう20年くらいになると思うんですが、この20年でそういう傾向ってますます強くなってると思うんです。

及川 ユニバーサルだというのはすごい強みですよね。何でも繋げる安心感、と清水さんはおっしゃいましたが、例えば家電でも何でもいいんですが、ネット接続をしたいと思った時に、ちゃちいWebサーバを内蔵しておけばいいんですよね。アクセスポイントがその代表例ですが、（HTMLで書けるので）設定画面を用意する労力も大したことないですし。

アプリ内ブラウザのセキュリティ

白石 ちなみに、僕らにとってURIって絶対なくならないものですし、Webの本質であるというご意見にも賛成です。が、ユーザからするとURIって全然見えないものになっているのではないかと思うんですが。

及川 それは全然構わないんじゃないでしょうか。先ほどお話しあったように、ブラウザが使われなくなってきていて、アプリの中で使われるようになってきているのなら、URIは裏で使われるというので全然構わないと思います。

白石 いきなりあんまり関係ない話なんですが、今まで誰かに聞きたかったんで聞いちゃいます。今までフィッシング詐欺防止のために、ブラウザベンダーは一生懸命アドレスバーの表示方法を工夫していたかと思うんですが、アプリ内ブラウザ（WebView）の場合、URLが全く見えない状態になります。それって、セキュリティ上大丈夫なんでしょうか？

及川 それは、アプリ内ブラウザ作ってる人に聞いてほしいですが(笑)。でもやっぱりモバイルになると、スクリーンが小さいという制限があって、セキュリティをきちんと確保して安心だと言いつつ、でも不必要な情報を出さないようにしなくちゃいけない。アドレスをユーザが確認できるようにしたところで、アドレスがすごく長かったりしたら、どこか1文字違っていたりしても絶対にわからないわけです。

だから、アドレスを全部表示するのがセキュリティ上優しいわけでもないという前提で、そこをどうすればいいかというのを、アプリ内ブラウザであっても普通のブラウザも考えなくちゃいけない所です。

最近はセキュリティめちゃくちゃ厳しくなってきてます。例えばWebをHTTPSオンリーにしようという議論がなされていたり、HTTPSにしたとしても怪しいSSL証明書なんて山のようにあるので、それらを全部banしていくようにしたり。要は、ユーザがサイトの安全性を目で確認する、という時代じゃなくなってるんですよね。むしろ、そうしない限りはWebが破綻します。

アプリにも、URI（つまりWeb）の力が必要だ

及川 あと、前半藤村さんがリンクの透過性の話をしていらっしゃいました。あれは結局のところ、アプリにもURIの力が必要だ、という話なんですよね。モバイルアプリを皆さん一生懸命作りますが、実際にユーザが何個入れているか、そのうちのいくつをアクティブに使っているかというと、すごく少ない。USのデータで見ると、確か31個とかしか入れていなくて、そのうちの10個くらいしか日常的に使っていない。

でも、世の中にはアプリなんて山のようにあって、ランキングが上の方のやつしかインストールされない。ランキングが下の方のやつなんて、一生懸命作ってもインストールさえされない。

彼らがもしWebをやめちゃったら、ユーザにリーチさえできなくなるし、エンゲージできなくなりますよね。そこをブーストさせるには、もしかしたら検索エンジンでロングテールのコンテンツにリーチさせるのと同じ論理が働くんじゃないかというところで、App Indexingだったり、App Linksみたいな話になるわけです。

検索した結果、「こんなアプリもあります」とアプリのインストールをうながしたり、インストールされていたならば「ここから先はアプリで見ませんか」とユーザーをナビゲートしてあげる。ここはハイブリッドなアプローチが必要です。ここでいうハイブリッドというのは、WebViewを使う云々の話だけじゃなくて、ユーザリーチ、ユーザとのエンゲージメントという点においても、Webとのハイブリッドなものが必要になる ということです。

羽田野 そういう点だと、Webの方が安心ですね。アプリの中で競争に勝てと言われると、ちょっとつらい。膨大なアプリの中で、自分の作ったアプリがユーザにリーチする確率がどれほどかと考えると、かなり厳しい。 僕から見ると、アプリの世界ってゼロかイチの世界に見えます。

一方Webは、良くも悪くも分散しているので、しょぼいサイトを作ったとしても、ニーズにマッチしてさえいればそれなりに人が集まる。ゼロにはなりません。スモールスタートをやるには、Webってすごいいいな、と思います。今はアプリの世界は、スモールビジネスが成り立たない世界になっちゃっているかな、と。

清水 探したくもならないもん。こういうアプリあるかな、と思って探したらいっぱい出てきすぎちゃって、嫌になっちゃう。

白石 確かに…。

Web技術は、21世紀のマシン語である

白石 ただここで、あえてWebに不利な論調を持ち込んでみたいです。せっかく「Webは死ぬか？」を話す機会なので。最近僕の知り合いがプログラミングの教育ビジネスをやってるんですけど、Web教えないんですよね。AnrdoidやiPhoneアプリの作り方から教えるんです。これでは、Web技術が広まっていかないぞ、と…

及川 でも、僕もそうですよ(笑) 。今でも東日本大震災の被災地の方でたまに教えていたりするんですけど、Corona SDKっていうのを使ってスマホアプリ教えてます。

白石 えー(笑)。

羽田野 僕、思いますけど、ゼロから覚えるならアプリのほうが楽なんですよ。

及川 なんでかわかります？Webは自由度が高すぎる んですよ。スクリーンサイズから何から、前提とするものが少なすぎる。でも子どもたちがやりたいのは、自分が持ってるスマホで、自分のアプリを動かしたいだけなんです。どんな簡単なものであっても、自分の持っているスマホで動くと嬉しい訳ですよね。

Corona SDKとかって、簡単な物理エンジンが乗っかっていて、高校生くらいなら1日もやればそれなりのものが作れるんですよ。教科書通りに写経して、ちょっとここ変えようね、くらいのレベルであれば。はじめて作ったものが、自分の手元でコントロールできる喜びっていうのは、やっぱりアプリのほうが上なんですよね。

羽田野 僕は自分の息子や娘にWeb技術教えられるかって言うと、ちょっとつらいですよね。だったら、Androidアプリとか教えるほうが手っ取り早い。だって、HTMLの構文教えるだけでも結構大変ですよ。それに加えて、CSS教えて、JavaScript教えて、なんて言ったら…

清水 そこは僕一つ考えがあって。今のHTML, CSS, JavaScriptっていうのは、21世紀のマシン語 なんですよ。概念的にも、実際的にも。

実際UnityのHTML5プレイヤーなんてまさにそうで、Emscripten(※)使って、人間が読むことを想定しないコードを吐き出している。それがV8 (※)とかでJITコンパイルされながら動くわけですよね。これ、昔の「べーしっ君」（※）ですよ。

もう、今のWeb技術はマシン語だから。HTMLからやれっていうのは、マシン語からやれって言ってるのと一緒なんですよ。 それにWeb技術って、いろんな歴史の澱（おり）が積み重なってる。86でいうセグメントみたいな。呪われた概念っていうか（笑）

※ Emscripten…C/C++のコード（厳密にはLLVMコード）からJavaScriptを出力するコンパイラ
※ V8…Googleがオープンソースで開発するJavaScriptエンジン。Google ChromeやNode.jsで利用されている。
※ べーしっ君…ASCIIが発売していたBASICのJITコンパイラ

Extensible Webの可能性

及川 たしかに現状、Webの後方互換性を保つためのレガシーなコードが、ブラウザにはたくさん入っている。今改めて必要な要素技術を考えるとしたら、ブラウザに今入っているものとは大きな隔たりが出てくるでしょう。

でも今おもしろいのは、Extensible Web の考え方です。

低レベルのAPIを整備して、なんか新しいAPIだったり要素だったりを作るとしても、それらの組み合わせで作れるようにしましょう、ってところから始まっている。そうなると、今後はAPIのレイヤー化が進むはずです。そうなると、下のレイヤーがどんどんマシン言語化していくってことですよね。で、上のレイヤーっていうのは、どんどんいろんなモノが乗っかって、その時に一番ポピュラーだったやつだけがブラウザに初めから組み込まれている、ビルトインされているって形になるかもしれないですね。

羽田野 将来のブラウザに期待したいのは、下位互換性を全て捨てた新しい、軽いブラウザが欲しいですね。marqueeとか、古い要素の実装もすべてない。Web閲覧のためのWebブラウザと、アプリの実行環境としてのWebブラウザって、用途が違うじゃないですか。アプリの実行環境として使うのであれば、古いものがなくたって困らない。そういう実装があってもいい気はしますね。

及川 Extensible Webの考え方が進んで、レイヤー化されてコンポーネント化されたものが許されるならば、それもあり得るかもしれませんね。ブラウザには、デフォルトでは本当にミニマムなエンジンだけが入っていて、必要に応じてレガシーな要素のコードがダウンロードされるみたいな。

白石 Extensible Webは、そこまでの未来を志向しているんでしょうか？

及川 そこまではまだわかりません。ただ、今Webの機能って、APIができたんだけど使わない、使えないっていうものが山ほどある わけですよ。よく言われるのがEditing。contentEditable (※)なんてのは最悪 です。あれでほんとにベーシックなエディタ機能を作ろうと思ったって作れないわけですよ。

結局みんなどうしているかって、みんなそんなの諦めちゃって、みんな何千行か何万行かあるJavaScriptエディタを一生懸命書いてるわけですよね。だとしたらそんなの（contentEditable）全部なくしちゃえ、そのほうがブラウザ軽いし、と。むしろ、そういうエディタたちが持っているミニマムな機能を標準化して、互換性のある形で全てのブラウザに入れてください、のほうがハッピーなわけです。

contentEditableが代表例ですが、要は入っていても使われないとか、使えない機能がたくさんある。

※ contentEditable…HTML5で規定された、編集可能なWebページを作成するための仕様。

ハイブリッドアプリの現状

白石 ここで、Webテクノロジーとモバイルといえば絶対に外せない話題として、アプリカン (※) というハイブリッドアプリのフレームワークを作っていらっしゃる羽田野さんにお聞きしたいんですけど、ハイブリッドアプリの現状はいかがでしょう？

羽田野 正直なところ、現状はやはりそれほど盛り上がってはいないですね。

白石 一番のネックはUIのパフォーマンスだったと思うんですけど、現在どうなんでしょう。

羽田野 やはり、時代が進むにつれて、ほぼ問題はなくなっていっています。今のスマホって、マシンパワーすごいじゃないですか。今でもAndroid2をサポートしなくちゃならないというお客さまにとっては、WebViewだときついですけどね。例えば無限スクロールのない情報表示系アプリとかであれば、全く問題のないレベルです。であれば、マルチデバイスで動作するWeb技術には大きなメリットがあるというのが、僕らの想いです。

清水 日本はゲームアプリが多いから、パフォーマンス上の要件も厳しいってのもあると思いますけどね。うちの会社で、enchant.jsで作ろうって提案すると、社員に反対されるんですよ（笑）。「（エフェクトとか）いっぱい出すと重くなるからダメです」って。ゲーム作る人間は、ギリギリまでパフォーマンス追求したいんです。

※アプリカン…http://www.applican.com/

いい機会なので、清水亮にenchantMOONについても聞いてみる。

白石 清水さん、自己紹介の時にオーサリングツールとしてenchantMOONを作ったとおっしゃってましたけど、それって、先ほどの「Web技術はマシン語だ」というところとつながるんでしょうか？Web技術には、オーサリングツールが必要だと？

清水 必要かどうかはわからないですが、プログラミングとかオーサリングとかのハードルを下げたい という想いはありますね。

コンピュータの性能がここまで上がってしまって、人間の何百倍の性能になってしまっているときに、コンピュータを使う方法って、アプリケーションじゃないだろう、と思っている。今って、例えばワープロにしても、「コンピュータに使われている」みたいな状態になってると思う。「コンピュータが提出する文章をお前さんが書きなさい、この枠組みで」みたいな。そこを逆に人間が主体になって、「おれはこういう情報がほしい」とか「こういうのが書きたい」みたいなことをこいつ（コンピュータ）に命令して、こいつが書くようにならなきゃいけない、みたいな一つの思いがあって。

白石 なるほど。それがハードルを下げたい、っていうことなんですね。

清水 僕ブログ流行った時に、「こんなに書きたい人が世の中にいるんだ」って感動したんですよ。それまではHTML書かなきゃダメって世界だったものが、誰でも普通に書けるようになって、いろんな人が書くようになったと。そういう意味では、その中で実はみんな自分を表現したいという人は、実はたくさんいるんじゃないかなと。

ただ、まだやっぱりハードルが高い。文章書くのは難しいとか、写真撮るだけだったらできる、っていうんでTwitterやInstagramが流行る。で、簡単だからやってるっていう話と、文章書くの難しいとかプログラミング難しいって話はリンクしてるなあ と思っていて。

だったら、もう少しそこら辺のハードルを下げてあげる。プログラミングとかオーサリングとかのハードルを下げてあげた時に何が起きるんだろう、っていうのが僕が思っているところで。ちなみにこれは僕のシンギュラリティ (※) に向けた心構えでもあるんですけど、プログラミングを克服しないと人類は次の世代にいけない と思っています。

enchantMOONはもともと、「パソコン大好きオジサンが怖いもの見たさで買う」というターゲティングでした。とはいえ、買った人はほとんど使いこなせていないんです。むしろすごく使いこなした人たちっていうのが、女子中学生なんです。

一同: へえ！！

清水 品川女子学院で、貸してくれって言うから貸してあげたんです。一時間くらいしか説明しなかったんですけど、気がついたら爆発的にデカいコンテンツ作ってる。

で、逆にそれをプログラマとかに渡すと、作れないんですよ。自分で作ったほうが速いから。でも文化系とか、コンピュータリテラシ高くない人に渡すと、ものすごいエネルギーでもってなんか作り始めるっていうのが、MOONを作って一番感じたターニングポイントです。

自分が表現したいこと、迷路を作ったりとか、ブロックを組み合わせてシューティングゲーム作ったりとか、そういうものを自分たちの力で作れるっていうのに、魅力を感じてくれたみたいで。そういう人たちにとっては、遅いとか重たいとかほぼ問題にならなくて。取り合いになったって聞いて、すごく嬉しかったです。文化祭とかあれで発表するみたいな。小さな話ではあるんだけど、僕にとっては自信になりました。

だから例えば、仮に今のWeb技術というのがマシン語であるならば、それに対するライトウェイト言語みたいな、ハードルを格段に下げる方法があったならば、コンテンツのビッグバンっていうのはもっと起きるんじゃないかと。

商業メディアって滅ぶ方向にいくんじゃないかという話をしました。でも、もっとハードルが下がって、もっと表現力が上がって、もっと人々に開放されることによって、もっといろんな人がそこに参加してきて、大きな流れが起こっていくんじゃないかな、っていうことを漠然と思っています。

※ シンギュラリティ…人工知能が人間の能力を超える、とされている特異点のこと（Wikipedia）

まとめ、感想、エトセトラ

白石 ではそろそろお開きにしたいと思います。今回の対談に関する感想をお願いできますか？

及川 えーと、Webは死にません！（笑）。楽しかったです。いろんな見方があるな、と。

藤村 僕は後半、ちょっと食い足りないところがありましたね。話をちょっと戻せなかったんだけど、基本僕ら（スマートニュース）が作っているネイティブアプリは、圧倒的にモノづくりの人にとっての利便性というよりも、消費者にとっての完成度みたいなのが問われるところがあって。消費者にとっての消費財って、モノづくりの人にとっての利便性ってどうでもいいんですよね。

そこでどのくらい完成度の高いものを作れるかってこだわって作っていく時に、Webってこういう風に作れるって聞いてても、ピンと来ないところが僕にはあって。良い反応速度を出そうとギリギリまで頑張っているっていうのが、ネイティブアプリを選択している我々の中には重要な要素なんですよね。そういうところをもう少しうまく言えればよかったな、と。

後半の文脈って、開発する人にとってのWebの意味、みたいなところが割と語られていたんだけど、使う人とか楽しむ人とか、ゲームやる人にとっての視点だったらどうだったのかっていうのは、ちょっと語りきれていない気がしています。

白石 スマートニュースなんかは、UXにすごくこだわっていると評判のアプリですもんね。

藤村 羽田野さんもさっき言われていましたが、スマホの上では圧倒的にネイティブが採用されているという事実もあるわけで。ゲームがたくさん時間をとっているからだ、っていういろんな解釈はあるんだけど、そうはいってもアプリが選択されちゃっているということに、踏み込まなきゃいけなかったんだけど、そこには踏み込み足りなかったと…悔いが残ります。

白石 そこはこちらも突っ込んで聞きたいところでした。ぜひまた、次の機会にお願いします。では、清水さんいかがですか？

清水 さっき結構しゃべったんで、特にないです(笑) 。まあ、Webは死なないでしょう。 個人的には、もっとマシン語化が進んでいくかな、と思いますね。

白石 もっと上位レイヤーが充実してくるという感じですか。

清水 いや、まだ効率が悪いので。WebGLとCSS3の住み分けとかもまだ微妙な感じですし。そこらへんがもっとスマートになればいいな、と。あと、主流になるかは怪しいですが、HoloLensとかOculusとか、あの手のコンテンツをWebで書く日が来るのかなあ、と漠然と。

白石 Mozillaが、MozVRっていうのやってますよね。

及川 GoogleもChrome ExperimentsでCardBoard向けのやつがあります。

清水 あと一つ言い忘れていたのは、Webの良い点は、フロントエンドからバックエンドまで全てオープンソースだということですね。JavaScriptの実行エンジンから、レンダリングエンジンから、Webサーバから、全部オープンソース。フロントエンドから全てオープンソースっていうのはすごいな、と。ありそうでなかった画期的なもので、だから、エンジニアとしてはWebは安心して使える。少なくとも僕が死ぬまでは、こうした知見が活かせるんじゃないかと、僕は結構楽観的に考えていて。

っていうのは、Unixが出てきて40年経ったけど、結局まだみんなUnix使っているわけですよ。オープンソースで枯れているコードって使われ続けていくので、Webも同様の理由で、あと半世紀残っても全然おかしくないな、と思ってますけどね。残ってほしい、死なないでほしい、という願望もありますが。

羽田野 OperaのCTOで、CSSの発明者であるホーコン・リーさんも、「活版印刷は500年使われている。Webも今後500年使われるだろう」という言葉を残していらっしゃいますね。

白石 では最後に、羽田野さん、今日の感想をお願いします。

羽田野 これ以上何もありません。同じWeb側の人なのに、見え方が違ってるんだな、と。特に僕的にウケたのは、JavaScriptはマシン語であるというご意見でした。時代が変わるって怖いな、と。（マシン語でのコーディングにこだわる）老害的な存在になってしまわないよう気をつけないと。「DOMを直接叩け！」とか言ってたら疎まれる時代がそのうち来るんでしょうね(笑)。

白石 では、本当に名残惜しいんですが、そろそろお開きにしたいと思います。本日は本当に、ありがとうございました！

今また、「Webの死」を予言する論調をそこここに見かけます。モバイルやウェアラブルといった新たなコンテキストが、プラットフォームネイティブな技術の優位性を後押ししているだけではなく、Webコンテンツの消費の仕方を大きく変え、Web上で成り立っていたビジネスモデルをも脅かしつつあります。

本当にWebはヤバいのか、気になってしょうがないので、スゴい人たちに集まってもらって、「Webは死ぬか」について語り合っていただきました。Webを取り巻く様々な論点を包括的に議論でき、貴重な場になったのではないかと自負しております。 Webに関わる人にとっては必読の対談だと思います！でもこの記事、長くて濃いので、心してかかってくださいね:-)

　▲左から藤村厚夫さん、清水亮さん、羽田野太巳さん、筆者・白石俊平、及川卓也さん

メンバー紹介

白石 皆さま、このたびはお集まりいただき、ありがとうございます。まずは自己紹介からお願いできますでしょうか。

及川 及川卓也 です。Google Chromeのエンジニアリングマネージャーを務めています。ChromeのうちのBlinkと呼ばれるレンダリングエンジンだったり、WebのDeveloper FacingなAPIを開発する、といったことをずっとやっています。立ち位置としては、「Webを推進する」ということをやっていますので、Webには未来を感じています。特にこの2～3年、技術面から「Webとは何なんだろうな」とずっと考えていたので、それにも通じる話かなと思っています。

藤村藤村厚夫 です。以前はアイティメディアという会社の経営に携わっていましたが、現在はスマートニュースという会社で、メディア事業開発という立ち位置で働いています。スマートニュースは、検索エンジンと同じく、Webをクロールしてアプリで表示するということを全自動で行います。とはいっても、そのコンテンツを作り出した方々との良好な関係を持たないと、コンテンツを使い続けるわけにもいきません。なので、多くのコンテンツホルダーの方々とパートナーシップ、または交渉するといったことがメインの仕事になります。

業界全体で見ると、メディアで飯を食っていける仕組みを作り出さなくてはならない、ビジネスとしてのコンテンツの流通というものを考えなくてはならない、自分たちだけではなく、コンテンツを作っている方々と我々の中でビジネスの構造を作っていかなくてはならない…こうした中で、これからのデジタルメディアを考えていかなくてはならない。そのためにはどうしたらいいか…というのが普段からの問題意識です。

清水 清水亮 です。僕自身はもともとマイクロソフトっていう会社で開発をしていて。その後ドワンゴという会社の立ち上げでモバイルウェブというのがカネになる——僕はなるとは思ってなかったんですが——というムーブメントを体験し、その後自分の会社を作ったあとも、モバイルウェブで食わしていただいて。その後スマートフォンが出てきた時は、モバイル公式サイトってビジネスモデルが崩壊しちゃう、どう立ち居振舞えばいいのかってところでアプリを作ったりしていました。

最近はHTML5が出てきたんで、enchant.jsというゲームエンジンを作ったりしていて、アプリを作るのはほとんどやめちゃいました。HTML5については、情報を見るのは誰でもできるのだけど、作るのはまだまだ難しい、という非対称性があると考えていて、その問題に一石を投じるため、enchantMOONというオーサリングツールを作っています。 最近は仕事でディープラーニングに触れたりしています。

羽田野 羽田野太巳 と申します。個人会社として有限会社futomiをやっています。そちらはもともとCGIというのが流行っていた時代に始まっていて、サーバサイドのシステム開発を主に行っていました。それがどんどんアプリケーション寄りになってきて、いつの間にかHTML5をやっていたと。今ではほとんどが、ブラウザの上で動くアプリとしてのWebの仕事が中心になっています。一言で申しますと、私はビジネスというよりはWebデベロッパーというカテゴリに入るのかなと思います。

もう一方で私は、ニューフォリアという会社の役員もやっておりまして、そちらではWebアプリの開発もやるんですが、デジタルサイネージも手がけておりまして。デジタルサイネージは実はプロプライエタリなシステムだらけ、互換性もなく閉鎖的なシステムで運用されているのが実情なんですが、実際に街中でご覧になって分かる通り、仕組みとしてはとてもシンプルなんですね。一言で言うとスライドショー。「こんなのWebでいいじゃん」という発想から、いわゆるサイネージプレイヤーを全部JavaScriptベースでブラウザの上で動かすというチャレンジを、ニューフォリアではやっております。

白石 私も対談に参加する人間として、自己紹介させていただきます。 HTML5 Experts.jpの編集長、白石俊平 です。昨年まではhtml5jというコミュニティのリーダーもやっておりましたがそこからは引退しまして、今は自分の会社を大きくしていくことに注力しようとしているところです。

では、いよいよ本題に入らせていただきたいと思います。

今回は大きく2つに分けてディスカッションを行いたい と思います。

前半はビジネス寄りの話を中心にしたい と思います。「Webビジネスは死ぬか？」って話ですね。これって、ECとかが死ぬことはないと思うんですが、最近危ういなと思うのはメディアを中心とした広告ビジネスですね。モバイルの時代になり、コンテンツの消費のされ方も変わってきましたし、アプリ中心の世界ではCookieによるターゲティング広告がうまく機能しなくなってきたという話もあります。そうした話題を中心として。

後半はテクノロジー寄りの話 として、よく言われるネイティブ vs Webの話をはじめとして、いろいろとお聞きできればと思います。

先に言っておきますが、まあ現実問題として、「Webは（そうそう）死なない」って結論が出るのはなんとなくわかっております(笑)。ただ、「死ぬか？」という問題提起をすることで、現在のコンピューティングの課題や最前線の話題を浮き彫りにしたい、それが本企画の趣旨になります。

ではまず、「Webメディア・コンテンツ」といった話題を中心に、話し合っていただきましょう！

コンテンツプラットフォームとしてのWebは死ぬか？

羽田野 まず最初に伺っておきたいんですが、皆さん「Web寄り」の人でしょうか？立場が似通ってて、おんなじような意見の方ばっかりだったら面白くならないな、と思って。

藤村 私は違うかも…。孤立感を感じております(笑)。

及川 でも、スマートニュースこそ、コンテンツプラットフォームとしてのWebに強く依存しているわけですよね。コンテンツプラットフォームとしてのWebが死んじゃったら、スマートニュース成り立たなくなっちゃう。

清水 僕は、スマートニュース危ないと思ってて。

白石 早速爆弾ですね(笑)。

清水 結構付き合いの長いKADOKAWAって会社が、電子化に専念して、（週刊アスキーが）近々紙をやめるってことらしいんです（注: 取材を行ったのは2015年5月18日）。ただ、今回の電子化っていうのは、各種ブックストアで販売される電子書籍版だけにするって話なんですよね。Webだけっていう話じゃなくて（編集部注: 詳しくは、週アスのサイトに掲載されている「『週刊アスキーがウェブ/電子版に完全移行』ってどゆこと？発表後1ヵ月の機会にまとめてみた」という記事をどうぞ）。

白石 そうなんですか、知らなかった。てっきりWebだけにするもんだとばかり思ってました。

清水 これは一例なんですが、そういう電子書籍とかって、スマートニュースとかじゃまだカバーできない領域ですよね。

一方で週刊アスキーのWebメディア、週アスプラス（編集部注: 現在は「週刊アスキー」）が儲かっているのか、というと多分そこまで儲かってない。少なくとも紙の週刊アスキー時代のように、莫大な海外出張費が出るほどには全然儲かってない。

例えばこないだのBuild（米国で開催されたマイクロソフトのカンファレンス）で、知り合いのジャーナリストとかに聞いてみると、みんな自腹で来ているわけです。何十万もかけて渡米する費用が、原稿料でペイできるのか？できるわけがない。「ライターは食えない」という状況の中で、今って（よほどの売れっ子以外は）惰性で書いてるか、副業で書いているか、っていう人しか残ってないと思う。

これって、Webメディアっていうビジネスが総じて成り立たなくなりつつあるんじゃないかと思うんですよね。モバイルコンテンツの時とかは、300円とかをユーザがなし崩し的に払ってくれていたわけですが、今はかつてのスケールで収益化に成功しているメディアは存在してないと思うんです。

で、Webメディアが成り立たなくなったら、スマートニュースみたいなキュレーションメディアも成り立たない。

Webメディアというビジネスは今後も成り立つのか

藤村 2000年にWeb専業のメディア（＠IT）を立ち上げて、Webプラットフォームの上にいわゆる出版社を作ってやってきた立場から言うと、「Webメディアが儲からない」ということはないと思います。株式公開もしましたし、現時点でも、事業として利益を出し継続性を持ってやっている。ただ、儲かることの意味というのは変わっている と思います。

例えば、パブリッシングプラットフォームとか、コンテンツのロジスティックス —— 先ほど私は「流通」という言葉を使ったかもしれませんが —— 大量のコンテンツに的確にユーザがリーチする、もしくはその逆で、ユーザに的確にコンテンツを届けるといった、「コンテンツの交通整理」みたいなものが必要になっていると思いますし、それをマネタイズするための手法も、Webの上でいろいろ出てきています。そして、それぞれの機能が、それぞれ成熟してきていると僕は思っているんですね。

例えば、以前は（メディア企業は）CMSを自分たちで作っていたわけですよ。我々もそうだったんですが、CMSを作ることから始める、広告を表示する仕組みから開発してビジネスの仕方を考えていた。しかし言ってみれば、自分たちでそれらを作ことの効率の悪さみたいなのに気づいて、そこに一つの「レイヤーキング」みたいな構造ができあがった。それが先ほどの、ライターは食える食えないとか、いろいろな事象に繋がっている。それは、Web専業メディアが出てきた1995年くらいから20年経って、従来のモデルがそのままでは通用しなくなってきたという事実なんだと思います。

様々なレイヤーでパワープレイヤーが出てきて、ビジネスの仕組みを変えざるを得ないという段階に到達したと。これからそういう組み換えと、新しいトレンドの中で、どういうビジネスが有効であるかと考える時期かなと。それが、コンテンツプラットフォームとしてのWebというところにおける自分の問題意識です。

ですから一般論として、食えないというものではないけれども、「やってりゃどうにかなる」というものでもない。 なので、変わっていこうとしている途上なので、新しいものを見通そうと思うと、いろんな課題がある。私は、メディアビジネスが生き残っていくにはオンラインしかないと思っている。それは20年間、認識は変わっていません。

しかし例えばそれが、自立的に生きていくのか、FacebookのようなWalled Gardenを持っているところと組まなければならないのかとか、Webの自律性とかそういうところだけでは答えが出せない、という段階に差しかかっていると思います。コンテンツプラットフォームとしてのWebを語る上では、そういう論点を整理していかなくてはならないかなと思いました。

ライターは儲からない、ブロガーは儲かる！？

羽田野 「4大メディア」時代からウェブになって、食える人が大きく変わってしまったんじゃないでしょうか。儲かる人が変わっちゃっただけで、ある人はWebのせいで儲からなくなったけど、ある人はWebで儲かるようになったっていう。

清水 ただ、ライターって立場から見ると、明らかに「儲からなくなった」と言えます。 僕はライター出身ですが、今の時代ライターで食っていこうとは考えられないくらい、原稿料が安い。昔は1ページ2～3万だったのが、今は1記事5,000円とかです。5,000円じゃ生活できないですよ。しかも、雑誌とかの部数は割と横ばいなんです。メディアとしての稼ぐ力が全体的に下がっちゃったんでしょうね。だから、今これからライターになろうとする人は、めちゃくちゃ大変です。ほとんど仙人目指すみたいな(笑)。

白石 今までのお話を踏まえると、紙も儲からない、Webも儲からないとなると、全体的に「出版」という市場は縮小している、ということになるんでしょうか？

清水 どこまでを「出版」と捉えるかによると思いますね。例えばKindle本でいうと、部数は紙ほど出ませんが…100分の1とかそんなもんじゃないでしょうか。印税としての実入りは大きい。まとまった情報にお金を払うというカルチャーはまだ生きていて、ただそれが、今のところWebではない というだけです。まあ電子書籍も、「EPUBはWeb技術だ」って話もあるかもしれませんけども。

他にはブログ、これは今後もずっと生き残ると思います。ちなみにブログやってて面白い発見があったんですが、僕はアフィリエイトべたべた貼ってるんですけど、紙の本と電子書籍、紹介した時の売上が100倍違うんですよ。

白石 どっちがよく売れるんですか？

清水 電子書籍です。電子書籍のほうが100倍売れる。

全員 へえー！

清水 僕のブログを読んで、「この本を読みたい」と思った人は、すぐその場で読みたいんですね。明日まで待たない。でもね、僕のブログ経由の売上がAmazonのランキングを左右するようなレベルなんです。要は数百部の売上がランキングを左右するような世界。3,000部から、っていう紙の世界から考えると、まだまだ電子書籍のスケールって小さい。

白石 ちなみに今のお話を聞いて、「ジョナサン・アイブ」の本を清水さんのブログ経由で購入したのを思い出しました(笑)。

清水 それはどうもありがとうございます(笑) 。個人的な体験で言うと、ライターを一生懸命やってた頃より、実は今のアフィリエイト収入のほうが大きいです。楽して同じ収入稼げるという意味では、出版社に頼ってた頃より今のほうが自由かもしれません。出版社に「書きすぎ」とかって止められることもありませんしね。

今は月に1回10万ビューくらいの記事を書くだけで、数万円って収入になってしまうので。ライターを超頑張ってた頃よりは、稼ぎやすくはなってると思います。まあ、正直記事の質は下がってますけどね。書き散らかしているので…。

Webメディアは（むしろ）ゴールドラッシュ！？

白石 ちょっと今までのお話を総合すると、Webメディアのビジネスというのがこの先も成り立つのか？というところがグレーだと。

清水 僕は成り立たないと思うんですよねえ。

白石 僕も一時期ライター専業だったので、お気持ちわかります。辞めたのも、食ってけないのが明白だったからでしたし…。なのでまず、Webメディアというビジネスモデルが今後も成り立つのか。そしてスマートニュースのような、「その上」に成り立っているキュレーションメディアはどうなるのか、と。また昔ながらのWebメディアというのとはまた違った形態、例えば電子書籍やブログならば活路はあるのではないか…という流れかと思います。

ここまでの流れを受けて、藤村さんいかがですか？

藤村 うーん、いろんな論点があるので、絞って解いていかなければいけないんだと思いますけど。ただお金という観点で言うと、Webの上で大きく動いているのは間違いない。それをうまく集められる存在が、かつては出版社でした。しかし今はGoogleやFacebookのような存在が、お金を大きく集めている。お金のシフトが生じている。

お金を集められるパワープレイヤーと、お金を分配する仕組みが、かつてのような生態系とは違ってきているわけです。 こうした変化の中で、ある人にとっては食えたもんじゃないという話になるわけです。その一つが、コンテンツを一生懸命作ってきた事業体が、なぜ金巡りが悪くなって続かなくなるんだ、みたいな。

羽田野 既存の出版社からすると、今のWebのビジネスって、すごく小粒なものなんじゃないでしょうか。非常に小粒で、分散してしまっている感じ。足すとあまり変わっていないのかもしれませんけど。

藤村 おっしゃるとおり、メディアビジネスを営んでいる存在は、昔に比べてすごく多いと思います。スマートニュースで、私は媒体社さんとのお付き合いという仕事が中心ですが、やってもやっても追いつかないくらい新しい媒体が生まれてきている。

お金の流れ方、ビジネスのスタイルが変わってきている。ある人は過去との比較で、「とうてい食えたもんじゃない」とおっしゃるかもしれない。でも、これまでメディアをやって来なかったような人たちによる新しい参入が引きも切らない。例えば、バイラルメディアとかはものすごいブームで。語弊があるかもしれませんが、ある意味、イージーにメディアのビジネスをスタートできる環境も整ってきている。

清水 参入障壁は明らかに下がってますよね。

藤村 自分は、メディアで苦しい思いをされている方々がいるのは知りつつも、ある種のゴールドラッシュの体をなしている部分があると思っています。

今日のWebメディアは、プラットフォームを抜きにして語れない

白石 僕はFacebookの藤村さんの投稿とかよく眺めているんですが、例えばバイラルメディアブームの火付け役になったBuzzFeedは、今でも話題を振りまいていますね。

藤村 強力なユーザーリーチを持っているプラットフォームというのが、一つではなく、いくつか分散して存在するようになってきています。少し前までは、検索エンジンを軸に生態系ができていました。ハッキリ言えば、Googleをターゲットにして、コンテンツの作り方やマーケティングの仕方が研究されていました。今はそれが変わろうとしています ―― Googleの及川さんの前でこんなことを言うのもなんですが(笑)。今は例えば、Facebookにぴったり寄り添ってコンテンツを作ると、Facebookが持っている巨大なユーザーリーチの恩恵を受けられるようになるわけです。BuzzFeedがまさにその典型です。

白石 Facebookといえば先日、Instant Articlesという取り組みを発表しましたね。これって端的にいうと、メディアのコンテンツがFacebookに自動で転載される仕組みなんだと思っています。僕はそれを見て、コンテンツの「コピー」が大量にWeb上に流通する…という現象が連想されまして。昨今のバイラルメディアブーム然り、今毎日のように問題になっている「引用か、盗用か」という議論も然りで。

藤村 理想的な意味での、Webにオリジナルコンテンツを作れば誰もがそこに集まってきて、自分たちのブランドの上で成長していく…というシナリオが難しくなってきているというのが、おっしゃられた事象の背景にあると思います。

検索エンジンだけを考えていれば良かった時代においては、「良いコンテンツを作ればそこに人が集まってきてくれる」という方程式を描きやすかった。しかしそこを今、少し見直さなくちゃならない時期なのかもしれません。

例えばFacebookのニュースフィードにピタっとハマったコンテンツを作らないと、中々ビジネスの上げ潮に乗れないとか、そういうことが実際に起きている。そういう事実を受け入れられない方々にとっては、こんなヒドイ時代はないというかもしれない。でも逆に、そういうアルゴリズムを理解して活用できる人々は、すごい成長力を持てる時代に入ってきている。いい意味でも悪い意味でも、巨大なリーチを持ったパワープレイヤーの存在との関係性は避けて通れないんです。Google,Facebook,Twitter,Pinterest,Instagram…そうした大小のプラットフォームが今は並存している時代。

白石 BuzzFeedなんかは、「自分たちがメディアを保有する必要性すらない」と言っていたりしますよね。

藤村 そういう言い方もし始めていますね。BuzzFeedなんかは、そもそもがFacebookにものすごく依存していたりするわけです。自分たちのサイトは持っているけど、Facebookが自分たちのビジネスに占めるインパクトがあまりにも大きいので、自分たちでサイトを運営するコストを全て排して、Facebookに記事を配信するというモデルでもやっていけるぞ、と。もともと通信社などのビジネスモデルもそういうものですし、以前からそういうモデルはあったんですけどね。今の時代に、改めてそういう考え方が出てきている。

白石 ちなみに、Facebookに直接記事を書くぞとなったら、どうやって稼げるんでしょう？

藤村 2つやり方があります。Facebook自体がNative Adsっていうパワフルな広告ビジネスを営んでいます。投稿されたコンテンツの間にFacebookが広告を配信して、そこで上がった売上を分け合うというモデル。もしくは、自分たちが広告主を連れてきたのだったら、100%取っていっていいってモデルです。

BuzzFeedはさらに、自分たちが広告コンテンツも作ってFacebookに流しちゃえ、なんて大胆なことを言っている。ここまで議論しているとディープな話になりますけどね(笑)。

白石 そうですね、ちょっとFacebookやBuzzFeedに突っ込んだ話から戻りますか。

藤村 僕が気になっているのは、一人のライターさんが執筆したとして、それをマネタイズする仕組みが大きく変わっているんじゃないかということ。

羽田野 執筆のマネタイズというと、広告以外マネタイズが思いつかないなあ…。

藤村 あ、僕が関心持ってるのはですね、「結局プラットフォームが牛耳ってる」とか、FacebookのようにWalled（壁に囲まれた）な世界が出来上がることは、Webの開放空間の可能性を信じる人にとっては気持ちのいいことじゃないはず。でも、ビジネスという点から言うと、実際そういう世界になりつつあるってところです。 「開放空間は、開放的で気持ちはいいんだけど、お金にはならないね」「結局閉鎖系みたいなところがお金にはなりやすいね」という話になっていってしまうのか。僕はそこがシンプルに知りたいところ。

羽田野 ブログブームで、あれだけ発信したい人が世の中にいたというのは個人的には驚きでしたけど、今はそれほどの盛り上がりではないように思います。開放空間でまとまった情報を発信するというのは、ハードルがすごく高かったのかな、と。

結局のところ、閉鎖的な空間で、ある程度見知った人々と情報をやりとりするというニーズのほうが、はるかに大きかったのではないでしょうか。少なくとも、ブログを書いて発信しようとする人よりも、SNSで発信している人々のほうが母数が大きい。（メッセージングアプリとかを含めると）インターネットユーザ全体と言ってもおかしくない。そこが、FacebookなどのSNSやメッセージングアプリが、莫大なユーザーリーチを得ている理由じゃないでしょうか。

Cookieは死ぬか？

白石 「Webは死ぬ」という文脈でよく取り沙汰されるのが、Cookieに以前ほどの力がなくなってきたこともあるかと思います。モバイルアプリの上では、アプリがそれぞれWebViewでWebコンテンツを開くことも多く、Cookieによるユーザセッションがそれぞれ分断してしまう。

藤村 要は、ターゲティング広告、リターゲティング広告が使えなくなる、ということですね。広告ビジネスとしては機能不全になってしまう。Webの世界では通用していた広告ビジネスが、アプリ経由では使えなくなると。

白石 TechCrunchでも、Cookieは死んだという記事が掲載されたりしていました。

藤村 Cookieが通用しなくなりつつあるかと言われれば、実際そうじゃないでしょうか。でもね、あたかもCookieがお金であるかのような扱われ方、Cookieでユーザをひたすら追いかけて…というモデルが「健全」であるかというと、ちょっと疑問を感じます。

白石 ユーザの立場からすると、ちょっと気持ち悪いですよね。

藤村 Webとアプリの間に断絶が起きていることは間違いありません。その断絶の中で失われるものがいくつかあって、そのうちの一つがCookieです。じゃあCookieみたいなものが失われることを嘆き悲しむべきかどうかは、僕は相対的なものだと思っています。Cookieが失われるのであれば、もっとユーザの利便性も考えた上で、次にできることが求められるんじゃないかと思う。

白石 なるほど。

失われた透過性

藤村 マーケティングとかリタゲとかそういう概念からは少し離れるかもしれませんが、Webとアプリの間の断絶でもう一つ失われているものがあって、それが僕には気になっています。それは 透過性 です。

白石 というと？

藤村 端的にいうと、リンクの問題ですね。ディープリンクみたいなものはいろんなところから提供されつつありますが、Webの中で成立していたリンクの関係ほど自由じゃない。透明性が高くありません。そうなると、「自分たちのコンテンツの魅力によって人を引き寄せよう」という世界は、アプリの中では作りにくいんです。このことが、コンテンツがお金に変わるような価値を持ちきれない一つの理由であり、問題を難しくしている気がしています。

アプリとWeb, Webとソーシャル、そういうものの間に、透過性を阻害するような要因がたくさん出てきていて、そこはすごく力を持つ時代でもあります。そこを克服する考え方なり、技術的な手法、標準作りとかはすごく重要じゃないかと思います。

白石 リンクの不自由さが、アプリとWebの世界の行き来をしにくくしている原因の一つなんですね。

藤村 アプリのプラットフォームが分かれているのも、そういうのをスムーズにさせない理由だと思います。Webの上では、自由な往来が許容されていました。しかしアプリではそうではありません。そうなると、結局マーケティングの仕組みが前時代的になるんですよ。

Webだったら、良いコンテンツが検索エンジンを通じて伝わることを期待できる、そういう、かなり信頼できる方程式がありました。アプリでは、それは絶対に伝わりません。そうなると、無理やりお金を使って、大昔に流行ったようなマーケティングをまたやらなくてはならない。そういうことが当たり前のように起きている。すごい課題だと思うし、不健全なところだと思う。お金を払ってインストールさせるブースト広告とか、今の時代に変じゃないですか、と。あまりにも前時代的だと思います。

人工知能の「学び」は個人情報か？

白石 ちょっと戻ると、Cookieのパワーは今後落ちていく。で、それに代わるものは出てくる、と。

藤村 そうですね。で、何がどこに出てくるかによって、今後の世界は大きく違ってくると思います。

清水 結局のところ、Cookieはそこまでいいもんじゃなかったでしょ、って言ってもいいんじゃないですか？広告のあり方としては、（リタゲでひたすら追いかけられるより）今のスマートニュースとかのほうが健全だと思います。今やっているかどうかは知りませんが、パーソナライズもできるし、自然に目に入ってくるけど、クリックしたくなければしなければいいわけで。Cookieで同じ広告何度も見せるというのは、理屈の上では合っているのかもしれないけど、不健全な気はする。

羽田野 ところでパーソナライズって、便利な局面と、便利じゃない局面がありますよね。 例えばパーソナライズド検索とかって、言ってみれば「マイブーム」でしかないし。そうじゃなくて、「私」というフィルターを通さない世界を見たい時もある わけで。なんでもパーソナライズがいいわけじゃないだろう、と。Facebookとか、パーソナライズが行き過ぎてて気持ち悪く感じちゃうときもあります。さっきの広告の話もそうですけど。

清水 でもそれも、ハッキリ言うと慣れじゃないかな。今の若い子たちって、最初からそういう世界に慣れきっちゃってて、そんな気持ち悪さとかとは無縁だと思いますよ。

及川 パーソナライズって、どんどん良くなっていくって性質のものですしね。ユーザが快適に感じるように、というふうに調整されていくんです。

羽田野 でもそこにはジレンマがあるような気がします。的確なパーソナライズを行うためには、サービスにどんどん個人情報を渡していかなくてはならない。そこも慣れなんでしょうか。

清水 慣れの問題もあると思いますし、あと、個人情報と思われているものも、個人情報じゃなくなってくる可能性もあるんじゃないかと思いますね。例えば 統計情報って、個人情報とは見なされにくい じゃないですか。

結局のところサービス側が欲しいのって、ユーザの行動履歴そのものじゃなくて、「ユーザが何に関心を抱いているか」という点なんですよね。だからユーザの行動履歴 、例えばユーザが見ているページの特徴量だけを抽出して、ニューラルネットワークに学習させていくと、ニューラルネットワークには重みしか残らない。そうなるとそれって、もはや個人情報とは呼ばれなくなる可能性もあるんじゃないでしょうか。

今までのように、原始的にキーワードを抜き出したり、単純な履歴から類推するんじゃなくて、全体的にこの人は何に関心があるんだろう、どういう話題だったら長く見てるんだろうかってことを、人工知能が総合的に判断するわけです。

ブラウザは人工知能を搭載していく

清水 僕は、MicrosoftがEdgeにCortanaを搭載するのって、それも狙いの一つじゃないかと思う んですよね。ブラウザ上の行動を逐一観察することができる。どういうWebページに長く滞在しているか、どこらへんでスクロールを止めたか、などなど。

そういう情報をとった上でサービスが記憶するものが個々の閲覧履歴じゃなくて、「何に関心があるか」というメタデータであれば、それは個人情報とは言えないのではないでしょうか。

羽田野 EdgeはWebページにマーキングを行うことができますが、それもまさに、そういうことかもしれませんね。ユーザの関心事を浮き彫りにするための機能。

清水 そうそう。積極的にユーザとインタラクションしつつ、人工知能が搭載されているブラウザ。これって、ある意味ではすごく安全です。一番怖いのって、自分のWeb閲覧履歴が第三者に握られてしまって、しかもそれがいつかどこかに流出してしまうっていう危険性ですからね。

ディープ・ラーニングがここまで進んでいる世界で、ユーザの行動履歴を大量に学習させていくことで、サービスは「私が何に関心を持っているか」を学びます。個人情報として、履歴が残って気持ち悪いのは、個々の行動履歴が残るからキモチワルイのであって、ニューラルネットワークに残された重み付け情報であれば、もしかするとそれほど抵抗感はないのかもしれません。

白石 いやー、メディアビジネスからCookie、ディープラーニングに至るまで、盛りだくさんですね。一旦ここで、前半のビジネスっぽい話題は終わりにして、Webテクノロジーを中心にした話に移りましょうか。 なんかビジネスっぽい話題だと、及川さんの発言が奮わないし(笑)。

及川 いや、言いたいことはたくさんあるんですが、ぼくが話しだすと止まらなそうな話題なので自重してたんです(笑)。喉元まで何度も出かかってるんですけどね。

白石 (笑) では、及川さん大活躍の[後編]に続きます！

こんにちは、清水です。先日のHTML5 ConferenceでFirefox OS上で動作するアプリの開発と、Firefox Marketplaceの公開に関する講演をさせていただきました。今回はその講演内容のうち、アプリ作成に関する部分を重点的に説明します。

すべてWeb技術で

Firefox OSの特徴は、ユーザの目にする部分は全てHTML5で実装されている点にあります。音楽アプリ、カメラ、ギャラリーといったプリインストールされているものはもちろん、ダイヤラーや、SMS、スマホのロックスクリーンや、ホーム画面といったシステムよりのアプリもすべてHTMLとJavaScript、CSSだけで実装されています。

Firefoxをインストールして、開発スタート

Firefox OSのアプリ開発に必要なことはただ一つ、Firefoxのインストールです。開発者アカウントの作成も、ディベロッパープログラムへの登録も、専用SDKのインストールも必要ありません。

FirefoxにはWebIDEという機能があります。これはアプリ開発ツールとして必要な機能を一通り持っています：

• ファイルの作成・編集機能、シンタックスハイライト
• デバッガ、インスペクタ
• シミュレータの起動、
• 実機との接続管理、アプリの転送機能

リリース版のFirefoxでも十分開発に耐えますが、開発をするなら Firefox Developer Editionの利用をお勧めします。Mozillaの提供する開発者向けの機能をいち早く利用できる点が特徴です。

Firefox Developer Editionは、リリース版とは異なる場所にインストールされます。また初回起動時に開発用のプロファイルを作成するため、リリース版との併用が可能です。Firefox Syncを利用して同期しておけば、ブックマークや履歴、パスワードは通常利用しているものと共有できます。

Hello World!

ではさっそく、WebIDEを利用してHello Worldしてみましょう。Firefoxのメニューから「Web 開発」→「Web IDE」と進んでWeb IDEを起動します。起動すると次のような画面が表示されます。

画面の左上にある「アプリを開く」をクリックすると展開されるメニューから「新規アプリ」を選びます。

選ぶとテンプレートの選択を求められます。「HelloWorld」テンプレートを選び、プロジェクト名にアプリの名前を入力して、「OK」ボタンを押すとアプリのテンプレートが作成されます。

シミュレータのインストール

次にシミュレータをインストールします。シミュレータはブラウザのアドオンとして提供されています。画面右上のメニューから「シミュレータをインストール」を選び、表示された画面の中から開発を行う Firefox OSのバージョンに合わせたシミュレータをインストールします。

KDDIから販売されているFirefox OS端末、Fx0はFirefox OS 2.0で動作しています。国内向けにアプリを書く場合は、Firefox OS 2.0のシミュレータをインストールするとよいでしょう。

アプリの起動と修正の反映

作成したテンプレートを、インストールしたシミュレータ上で実行します。WebIDE上部にある「実行ボタン」を押すと、実行できます。

実行すると、次のような画面が表示されます。

このテンプレートでは、起動時にindex.htmlが表示されます。これを次のように修正します。

<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width,user-scalable=no,initial-scale=1">
    <title>Hello World</title>
    <link rel="stylesheet" href="app.css">
    <script src="app.js" defer></script>
  </head>
  <body>
    <h1>こんにちは世界！</h1>
  </body>
</html>

また、app.jsを次のように修正すると、アプリのロードが終了した時点でアラートダイアログが表示されます。

window.addEventListener("load", function() {
  alert("Hello World!");
});

WebIDEの実行ボタンをもう一度押すと、これらの修正が実行中のアプリに反映されます。

アプリの構造

テンプレートに従って作成されるファイルは以下のような構造をしています。

HTMLやJavaScriptに加えて、”manifest.webapp”というファイルがあります。これはアプリに関するメタデータで、これはアプリのインストールや、Mozillaの提供するアプリストアであるFirefox Maretplaceにアプリを登録時に参照されます。

manifest.webappの実体は次のようなJSONファイルです。

{
  "name": "こんにちは世界",
  "description": "A Hello World app",
  "launch_path": "/index.html",
  "icons": {
    "16": "/icons/icon16x16.png",
    "48": "/icons/icon48x48.png",
    "60": "/icons/icon60x60.png",
    "128": "/icons/icon128x128.png"
  },
  "type": "privileged",
  "permissions": {}
}

各項目の詳細については、Mozilla Developer Networkのアプリマニフェスト をご覧いただくのが確実ですが、上記の例にある項目は以下のような意味を持ちます。

以上のように、HTML、CSS、JavaScriptにmanifest.webappを足したものが、Firefox OSアプリの最小構成となります。

Firefox OS で利用できる API

Firefox OS のアプリは、すべてJavaScriptで記述します。そのため カメラやGPSといったセンサー類へのアクセスや、バイブのコントロール、SDカードへのデータ保存などは、HTML5で利用できるAPIを通して行います。利用できるAPIの一部分を挙げると、以下のようになります。

• Ambient Light Sensor API：環境光センサーを利用して周囲の照度を取得できる
• Geolocation API：端末の物理的な位置を取得できる
• Vibration API：ゲームなどのフィードバックのために、バイブレーションをコントロールできる
• Camera：デバイスに内蔵されたカメラを利用して動画や、写真を撮影できる
• Contacts：連絡先データベースへのアクセスが可能になる
• Device Storage：SD カードなど、端末の持つストレージに対して読み書きが行える

例えばDevice Storage APIを利用して、SDカード中のファイルをすべてコンソールに出力するプログラムは、次のようになります。

var sdcard = navigator.getDeviceStorage("sdcard");
var cursor = sdcard.enumerate();
cursor.onsuccess = function(){
  var file = this.result;
  console.log(file.name);
  if(!this.done){
    this.continue();
  }
};

WebActivities：アプリの機能を利用する API

音楽のライブラリや、写真のギャラリー、カメラでの撮影といった機能を実装する方法は2つあります。1つは上記にあげたAPIを利用して1から機能を作る方法、もう1つはWebActivitiesを利用して他のアプリを呼び出す方法です。

標準でインストールされている音楽アプリや、ギャラリー、カメラアプリは、「ライブラリから音楽の選択する」「ギャラリーから写真を選ぶ」「写真を撮る」といったアプリの機能の一部を他のアプリから利用できるようになっています。

これを利用しているアプリの例には、Cameran があります。Cameranは写真にフィルタや効果を追加するアプリなのですが、自分で写真撮影や管理機能を実装しているのではなく、インストールされている他のアプリの提供する「画像を選ぶ機能」を利用しています。

他のアプリが提供している機能を、自分のアプリから呼び出して利用するためのAPIが、WebActivitiesです。例えば、他のアプリが提供するJPEG形式の画像を選択する機能の呼び出しは、次のようにWebActivitiesを利用して実現できます。

var activity = new MozActivity({
  name: "pick",
  data: {
    type: "image/jpeg"
  }
});
activity.onsuccess = function() {
  var picture = this.result;
  console.log("A picture has been retrieved");
};

尚、WebActivitiesを利用して呼び出せるのは機能の名前であって、アプリではありません。おなじ名前の機能が複数のアプリから提供されている場合、どのアプリを利用するかはユーザの選択に任されます。

WebActivitiesの詳細、特に標準でインストールされているシステムアプリが提供する機能名については、Mozilla Developer Network の Web アクティビティをご覧ください。

アプリケーションの権限

上記のAPIすべてを、アプリから利用できるわけではありません。強力なAPIの利用には、それに見合った権限が必要となります。

Firefox OSのアプリは権限に応じて次の3つに分類されます。

• 一般のアプリ (type:web)
• 特権アプリ (type: privileged)
• 内部アプリ (type: certified / internal)

最後の内部アプリ、以前は認定アプリ (Certified App)と呼ばれていたアプリは、キャリアもしくはそれに準じるベンダしか作成を許されていません。そのため私たちが作成するアプリは、一般アプリもしくは特権アプリのどちらかになります。

権限と、利用できるAPIの対応関係は、OSのバージョンによって異なります。対応関係はWebIDEの「許可設定一覧」で確認できます。

許可設定一覧は以下のようになっています。

✓は利用可能、✕ は不可能、! は利用可能だが利用時にユーザに対して通知されることを表しています。

以下の例では、Camera APIを利用するためには、アプリを特権アプリとしなければならないことがわかります。

実際に作ってみよう

以上がFirefox OSアプリの概要でした。これを踏まえて、ボイスレコーダーアプリの作成を例に、アプリの作成例をみてみましょう。

今回作成するアプリは次のような1画面のアプリとなります。画面をタップすると録音を開始し、もう1度のタップで録音を終了します。録音した音声は ogg ファイルとして音楽ライブラリに保存されるものとします。

なお今回作成したサンプルは、 gistで公開しています。 こちらもご利用ください。

使用するAPIとアプリの権限

今回は次のAPIを利用します。

DeviceStorage APIを利用するためには、アプリの種別を特権アプリとする必要があります。またいくつかのAPIを利用するためには、manifest.webappのpermissionsの項目に記述を行う必要があります。そのため manifest.webappを以下のように記述します。typeと permissionsの項目が、それぞれ設定されていることを確認してください。

{
  "name": "audio-caputre-sample",
  "description": "An sample app to capture audio through microphone",
  "launch_path": "/index.html",
  "icons": {
    "16": "/icons/icon16x16.png",
    "48": "/icons/icon48x48.png",
    "60": "/icons/icon60x60.png",
    "128": "/icons/icon128x128.png"
  },
  "type": "privileged",
  "permissions": {
    "audio-capture": {
      "description": "To record audio"
    },
    "device-storage:music": {
      "description": "To store captured audio",
      "access": "readwrite"
    }
  }
}

HTML と CSS の記述

アプリのビューは HTML と CSS で定義します。今回のアプリでは次のものを利用しました。

<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width,user-scalable=no,initial-scale=1">
    <title>audio capture test</title>
     <script src="app.js" defer></script>
    <link rel="stylesheet" href="app.css">
  </head>
  <body>
    <canvas id="canvas"></canvas>
    <p id="recording">●REC</p>
  </body>
</html>

CSS は以下のようになっています。

body{
   margin: 0;
   padding: 0;
 }
 #canvas{
   width: 100%;
   height: 400px;
   margin: 0;
   padding: 0;
   box-sizing: border-box;
 }
 #recording{
   color: red;
   position: fixed;
   top: .5em;
   left: .5em;
   display: none;
 }

JavaScript を使った録音

コードの全体像は gist に公開したものをご覧いただくこととして、 ここではマイクからの入力ストリームの取得、録音、そしてファイルへの出力部分について解説します。

まずは、マイクからの入力ストリームの取得方法です。manifest.webapp中のpermissionsの項目に”audio-capture”を追加すると、 つぎのようにGetUserMediaを使っ、てマイクからの入力を扱うための入力ストリームを取得できます。

navigator.getUserMedia({video: false, audio: true}, 
                       streamAquired, 
                       error =>{
                         console.log(error);
                       });

この実行が成功すると、コールバック関数が呼ばれます。取得した入力ストリームは、関数の第1引数として与えられます。上記の例では streamAquired という関数が呼ばれます。この関数は入力ストリームを利用する様々なオブジェクトの初期化を行います。

ここで初期化されるオブジェクトの中には MediaRecorder オブジェクトがあります。初期化は次の様に行われています。

var initRecorder = function(stream){
  recorder = new MediaRecorder(stream);
  recorder.ondataavailable = (event) => {
    console.log(event); 
    if(storage != null){
      var filename = createFileName(event);
      console.log("attempt to save as " + filename);
      var req = storage.addNamed(event.data, filename);
      req.onsuccess = function(){
        console.log("saved as " + this.result);
      };
      req.onerror = function(){
        console.log(this.error.name);
      };
    }
  };
};

MediaRecorderオブジェクトは、その名の通りメディアデータの記録を行うオブジェクトです。startメソッドを実行すると記録を開始し、stopメソッドを実行すると記録を停止し、記録したデータを用意します。データの用意できると、dataavailableイベントが発生します。用意されたデータは、dataavailableのdata属性でBlobとして参照できます。

上記の例では取得したBlobオブジェクトを、DeviceStorage APIのaddNamedメソッドを使って保存をしています。ここで利用しているstorageオブジェクトは次の様に作成されています。

var storage = navigator.getDeviceStorage("music");

これは音楽データ用のストレージを取得しています。取得できるストレージの種類は次の4種類です。これ以外にもappsというアプリ用ストレージがありますが、これはシステムアプリからのみアクセスが許可されており、我々の作成するアプリは操作できません。

取得したストレージに対してメソッド呼び出しを行うと、DOMRequestオブジェクトを返します。このオブジェクトのonsuccess属性やonerror属性に関数を登録することで、その操作が成功したか、失敗したかを知ることができます。上記の例では単に成否をログに出力しているだけですが、エラー処理が必要な場合などは、こちらにその処理を記述することになります。

気軽に作ろう！

以上 Firefox OSアプリの構成と作成方法について概観しました。

Firefox OSに向けたアプリの作成についてまとめると、次の3点になるかと思います。

• Firefoxがあれば開発をはじめられる
• Firefox OSアプリ = HTML + JS + CSS + manifest.webapp
• ライブラリの追加なしで、ハードウェアをコントロールできる

とにかく開発を始めるための敷居が低く、HTMLや CSS、JavaScriptといったWeb標準技術のみで、ハードウェアへアクセスし、コントロールするようなアプリが作れます。

しかもブラウザエンジンがOSに組み込まれているため、作成したアプリのコンパイルやビルドが必要ありません。Webページを作るように、修正したアプリを再読み込みして即座に実行できます。また本文中では解説しませんでしたが、実機へのアプリの転送やデバッグもシミュレータと同様の手順で行えます。

このように開発の敷居が低く、簡単にアプリを作り始められるFirefox OSで、みなさんも作る自由を謳歌してください。

当日のセッションの動画・スライドは、こちらからご覧ください。

Youtube / Slideshare

参考資料

• Firefox Developer Edition
• Firefox OS
• Mozilla Developer Networkのアプリセンター
• WebAPI
• GetUserMedia
• DeviceStorage API
• MediaRecorder API
• Web Audio API
• アプリマニフェスト

WebGLとWebSocketによる3Dオンラインレースゲーム「JS-Racing」の全て！（後編）

前回に引き続きHTML5 Japan Cup 2014にてWebGL賞と優秀賞をいただいたオンラインレースゲーム、JS-Racingの技術解説をさせていただきます。

サーバサイドの使用技術

サーバサイドの技術としてNode.jsを使用しています。Node.jsはサーバーサイドで動作するJavaScriptで、ノンブロッキングI/Oというモデルを採用しています。非同期処理でデータベースへのアクセスとWebページの表示を別々に行ってくれるので、ストレスなく大量のページの表示が出来ます。また、Socket.ioというライブラリを扱うことで、WebSocketを使用したリアルタイム通信を実現するができます。

Node.jsでWebアプリケーションを構築する場合、実験的にローカルのみの開発の場合は問題ありませんが、公開するとなると、Node.jsをインストールして実行できるサーバが必要になります。そのためには共有サーバのレンタルではなく、管理者権限 (root) が付与される専用サーバや、仮想専用サーバ（VPS）のレンタルが必要になると思います。管理者権限のため自由に環境をセットアップする事ができるために、そのWebアプリケーションに合わせた環境構築が可能になります。

ExpressによるWebアプリケーションフレームワークの利用

Node.jsで作成したWebアプリケーションの場合、リクエストURIの解析からファイルの配信など、HTTPサーバの機能を実装しなくてはいけません。これらの基本機能が備わったWebアプリケーションフレームワークを利用することで、非常に手軽にWebアプリケーションを作成できます。今回は、多数開発されているWebフレームワークのなかでも、有名で多く利用されているExpressを利用しました。

var express = require("express");
var app = express();
// HTMLエンジンとしてjadeを使用
app.set("view engine", "jade");
app.set("views", __dirname + "/views");
app.use(express.static(__dirname + "/public"));
// js-racing.knockknock.jp/にアクセスがあった場合、
// /views/index.jadeに「title=JS Racing」と「version=ver1.2」の値を渡して、HTMLを表示
app.get("/", function(req, res) {
    res.render("index", {
        title: "JS Racing",
        version: "ver1.2"
    });
});
// js-racing.knockknock.jp/controller.htmlにアクセスがあった場合、
// /views/controller.jadeに「title=JS Racing」と「version=ver1.2」と「id=URLパラメータのidの値」の値を渡して、HTMLを表示
app.get("/controller.html", function(req, res) {
    res.render("controller", {
        title: "JS Racing",
        version: "ver1.2",
        id: req.query.id
    });
});
app.set("port", process.env.PORT || 3000);
var server = require("http").createServer(app);
server.listen(app.get("port"), function(){
    console.log("Express server listening on port " + app.get("port"));
});

22行目のreq.query.idはhttp://js-racing.knockknock.jp:3000/controller.html?id=000000として渡された、URLパラメータのidの値が参照できます。この値は、ソケット通信時に発行されたソケットIDの値で、PCから発行されたスマフォ用のURL（QRコードか短縮URL）にURLパラメータとして付加されたもので、この値を元にPCとスマートフォンとのペアリングを行います。

ExpressはHTMLのテンプレートエンジンとしてJadeか、ejsを選択することができます。Jadeはインデントが必須です。閉じタグを省略できる代わりに、DOMの入れ子構造に沿って適切にインデントを使用する必要があります。基本的な記法がHTMLとは違うために、HTMLに親しんだマークアップエンジニアからすれば、慣れるまで違和感があるものだと思います。ejsはJadeとは違い、基本的な記法はHTMLをベースにしていますので、ローカルでくみ上げたHTMLをejsに組み込むことが容易です。今回はより楽にコード量を少なくHTMLを構築したいという点で、閉じたタグなしで記述できるJadeを選択しています。

// オープニングタイトル表示部分
section#sceneOpening.scene-opening(style="display: none;")
    div.scene-opening__inner
        div.scene-opening__box5
            h1.scene-opening__ttl
                // expressから受け取ったパラメータ、titleの値を挿入
                span.scene-opening__ttl__txt #{title}
                    br
                // expressから受け取ったパラメータ、versionの値を挿入
                span.scene-opening__ttl__txt2  #{version}

Jadeはこのようにインデントによって、要素の入れ子構造を定義しています。そのため閉じタグが不要で、HTMLを非常に簡略化して記述することが可能になります。HTMLを簡略化できるだけがJadeの特徴ではありません。HTMLをコンポーネント化して再利用したり、条件分岐をさせたり、繰り返し処理をさせたり、これまでサーバサイドで行っていたようなことがNode.jsで可能になります。ちなみにCSSはSass（Compass）を使い、記法にはBEMという命名規則を採用しています。

Socket.ioによるリアルタイム通信

車の同時走行と、スマートフォンからの車の操作を実現するためには、ブラウザとサーバ双方から、任意のタイミングでデータを送受信する必要があります。このリアルタイム通信を実現するために、Socket.ioを利用しています。Socket.ioはWebSocketなどのリアルタイム通信技術をラップして、シンプルなAPIを提供しているため、通信部分の煩雑さを意識することなく、リアルタイム通信を簡単に構築することができます。

スマートフォンからの車の操作を実現するために、接続時に発行されたソケットIDを共有することで、スマートフォンとPCをペアリングして相互通信しています。サーバを介しての通信なので、若干のタイムラグが発生する懸念もあったのですが、現状ではタイムラグを感じることはありませんでした。環境に依存することですので、あくまで今回の場合はということですが。

var socketArr = [];
io.sockets.on("connection", function(socket){
    // Socket.IDをPCに送信
    socket.emit("emit_id_form_server", socket.id);
    // PCから車の状態を受信
    socket.on("emit_carcondition_form_client", function(data){
        // 受信した車の状態
        var info = {
            id: socket.id,
            name: data.name,
            x: data.x,
            y: data.y,
            bodyAngle: data.bodyAngle,
            wheelAngle: data.wheelAngle,
            speed: data.speed,
            colorBody: data.colorBody,
            colorWing: data.colorWing,
            colorDriver: data.colorDriver
        };
        // 接続しているクライアントごとの情報を更新
        var flg = true;
        var i = 0, max;
        for (i = 0, max = socketArr.length; i < max; i = i + 1) {
            if (socketArr[i].id == info.id) {
                socketArr[i] = info;
                flg = false;
            }
        }
        if (flg) {
            socketArr.push(info);
        }
    });
    // スマートフォンからの操作情報を受信
    socket.on("emit_controller_data_form_client", function(data){
        var id = data.id;
        var event = data.event;
        var value = data.value;
        var flg = false;
        var sockets = io.sockets.sockets;
        var i = 0, max;
        for (i = 0, max = sockets.length; i < max; i = i + 1) {
            // ソケットIDが一致したクライアントに操作情報を送信
            if (sockets[i].id == id) {
                sockets[i].emit("emit_controller_data_from_server", {
                    id: id,
                    event: event,
                    value: value
                });
                flg = true;
            }
        }
        // ソケットIDが一致したクライアントが存在しなかった場合はスマートフォンに接続解除イベントを送信
        if (!flg) {
            socket.emit("emit_disconnect_client_from_server");
        }
    });
    // 接続しているクライアントの情報を1秒間に3回、接続しているクライアント全てに送信
    setInterval(function(){
        socket.emit("emit_other_carcondition_from_server", socketArr);
    }, 1000 / 3);
});

接続している全てのクライアントに、接続している全てのクライアントの情報を送信するイベントは、ネットワークの負荷を考えて、1秒間に3回と制限をかけています。つまり3FPSのタイミングで同期をとることになりますが、クライアント側では30FPSでゲームが進行しているために、タイムラグが発生してしまいます。タイムラグによって発生する違和感をなくすために、クライアント側ではサーバ側から配信されるクライアント情報を元に、前回配信された情報との差分を10で割った値を算出して、クライアント側の1FPS毎の値として反映させ、違和感を解消しています。

MongoDBでラップタイムの保存と走行データの保存

ラップタイムを保存したり、走行データを保存するのにデータベースとしてMongoDBを利用しています。MongoDBは、オープンソースのドキュメント指向データベースです。RDBMSのようにレコードをテーブルに格納するのではなく、ドキュメントと呼ばれる構造的データをオブジェクト形式でデータを管理します。 ちなみにNode.jsからMongooseを利用し、MongoDBに接続しています。Mongooseでは、Schemaインスタンスを通してModelを定義する事ができます。以下のようなオブジェクト形式でデータを管理出来るのが、MongoDBの特徴です。

var UserSchema = new mongoose.Schema({
    id:String, // ソケットID
    name:String, // 名前
    date:String, // 登録日
    time:Number, // ラップタイム
    comment: String, // コメント
    color: {
        body: String, // ボディカラー
        wing: String, // ウィングカラー
        driver: String // ドライバーカラー
    },
    runningPath: Array // 走行データ
});
var Users = db.model("user", UserSchema);

走行データは1秒間に30回、車の位置と角度を記録した配列ですので、全てのユーザーの分だけ保存すると、データ量が肥大してしまう可能性があります。データ量を押さえるために、ラップタイムでソートして10位圏外の走行データは保持していません。

サーバサイドではNode.jsのおかげで、Webアプリケーションを構築する環境がとても整ってきていると思います。 基本的な言語はJavaScriptですので、サーバサイドもフロントエンドエンジニアが押さえるべき領域になっているのではと思います。

その他の技術的トピック

サーバサイド、クライアントサイドの技術それぞれの紹介を軸として、説明させていただきましたが、これ以外にもいくつか工夫した、技術的なポイントがありますので、紹介します。

コースデータの共有

3D表現を利用するために使用したthree.jsと、ゲームエンジンとして使った2D物理エンジンBox2DJSで、コースデータを共有するために2次元配列を使用しました。各値には数値を格納して、数値によってthree.jsでは壁、道路、芝、タイヤ、木、等の3Dモデルが配置され、Box2DJSでは3Dモデルの形状に沿った障害物を配置します。ちなみに開発当初、コースエディット機能や、SNSでコース共有機能等を考えていましたので、テキストデータとして扱いやすい2次元配列をコースデータとして採用したという経緯があります。

module imjcart.logic.map.value {
    export class MapConst {
        // コースデータ用の2次元配列
        static MAP:any = [           
　　　　　　[1,1,1,1,1,1,1,1,1,　〜省略〜　1,1,1,1,1,1,1,1,1,1,1], 
　　　　　　[1,4,4,4,4,4,4,4,4,　〜省略〜　4,4,4,4,4,4,4,4,4,4,1],
           〜省略〜　　　　　　
　　　　　　[1,1,1,1,1,1,1,1,1,　〜省略〜　1,1,1,1,1,1,1,1,1,1,1]
        ]
        // コースデータ配列内の各値が、何を表しているかの定数
        static MAP_KEY_NONE:number = 0; // アスファルト
        static MAP_KEY_WALL:number = 1; // 外壁
        static MAP_KEY_BLOCK:number = 2; // ブロック
        static MAP_KEY_TIRE:number = 3; // タイヤ
        static MAP_KEY_GRASS:number = 4; // 芝
        static MAP_KEY_TREE:number = 5; // 木
        static MAP_KEY_CAR_START_POSITION:number = 6; // 車のスタート位置
        static MAP_KEY_LAP_MEDIAN_CENTER_02:number = 7; // ゴールライン（逆走制御）
        static MAP_KEY_LAP_MEDIAN_CENTER_01:number = 8; // ゴールライン（逆走制御）
        static MAP_KEY_LAP_START_POINT:number = 9; // ゴールライン
        static MAP_KEY_SAND:number = 10; // 砂地
    }
}

ただ、このような膨大な量の2次元配列を、テキストエディタで作成、編集するのは非常に非効率だと考えて、途中からExcelによって管理する方法に切り替えました。Excelでは条件付き書式を設定して、セルの値によって、わかりやすいように色づけするように設定しています。データ書き出しの際には、ExcelからCSVデータとしてテキストデータを書き出して、CSVデータをテキストエディタで置換して2次元配列にしています。

コースの装飾

コースは直線と直角だけではなく、カーブ等の曲線も再現できなくてはいけません。2次元配列をコースデータとして利用する場合は、この点を補完する必要があります。また、コースというのは大抵、両脇のシケインとの境目にラインが引いてあります。こういったアスファルトや芝生といった要素以外の装飾を、周りの要素の配置条件に応じて追加することで、よりコースらしい外観を作る事ができます。下のキャプチャが装飾やカーブの補完をかけている物と、コースデータをそのまま表示したものとの違いです。

まとめ

以上が今回作成したJS-Racingの主な技術解説になります。Webアプリケーションを構築するには、今回解説したように多くの技術が必要となります。ご紹介した技術は、たくさんある中から必要なものを取捨選択した結果ですので、当然コンテンツが変われば、必要となる技術も変わります。このコンテンツで使用した主な技術の全体図をまとめました。

オンラインレースゲームというシンプルな内容のコンテンツですが、プラットフォームとしてWebブラウザを使用している点に注目していただけると嬉しいです。今までご紹介した技術は、オンラインゲームを作るだけの技術ではなく、Webコンテンツを作る上で、大きな可能性を持っている技術になります。私はゲームを作る上でこれらの技術を利用していますが、Web上の様々なサービスと連携をとることで、もっと広がりを持つコンテンツを作ることができると思います。ぜひ皆さんも、HTML5とJavaScript（クライアントサイド、サーバサイド含む）を使って、Webアプリケーションを作ってみてください。

今回はHTML5JapanCup2014にてWebGL賞と優秀賞を受賞したオンラインレースゲーム、JS-Racingの技術解説を書かせていただきます。

このコンテンツはWebGLの3D表現を活かした3Dレースゲームです。
また、WebSocketを使用しサーバを介して、複数のクライアントでの同時走行が可能なオンラインゲームになっています。同時に、ソケット通信時に発行されるソケットIDをPCとスマートフォンで共有することで、スマートフォンからPC上の車を操作することも可能です。

クライアントサイドの使用技術

クライアントサイドの構築において、目的・用途に応じて使用した言語やライブラリに関して解説します。

TypeScriptによるクラス設計

クライアントサイドのメインとなるロジックをTypeScriptを使用して設計しました。TypeScriptはマイクロソフトによって開発されたフリーでオープンソースのプログラミング言語です。大規模JavaScriptアプリケーションに向けて開発されたTypeScriptは、これまでのJavaScriptにはない以下の機能を有しています。

• 型注釈とコンパイル時の型チェック
• クラス
• インターフェイス
• モジュール

TypeScriptはコンパイルして最終的にJavaScriptに出力することができます。今回のように多くの機能の実装が必要になるWebアプリケーションでは、クラスベースのオブジェクト指向言語的な特徴を持つTypeScriptは、設計しやすく非常に有効なものになります。

ActionScript3と同じように、1つのTSファイル（TypeScriptファイル）にクラスを1つだけ記述して、ファイル名とクラス名を一致させました。また、モジュール毎にディレクトリを作成して、クラスを格納しています。これにより機能毎にモジュールとクラスを整理する事ができ、再利用しやすく見やすいコードになりました。最終的には、クラス毎に作成したTSファイルを、クラス毎のJavaScriptファイルに出力（コンパイル）し、Gruntで結合、圧縮して、実際に読み込むJavaScriptファイルにしています。

今回の場合、モジュールの分け方は、まず表示要素とロジックにモジュールを分けました。表示要素はゲームの各シーンや、3D描画、画面下部のランキング表示というように、表示要素単位でさらにモジュールを細分化していきます。ロジックは、イベントや値管理、定数、ユーティリティ、コースデータ管理、物理演算、リアルタイム通信といった、機能単位でモジュールを細分化していきます。このようにモジュールを分けていくことで、大規模なコンテンツ開発の際には、各クラスの責任範囲が明確化でき、バグが発生した際にも、原因を特定しやすく、さらには仕様変更にも強くなります。

TypeScriptは大規模開発においては、非常に設計しやすく、クラスベースのオブジェクト指向言語のメリットを最大限に享受できるものだと思います。ただその分、設計における手間と、なによりコード記述量が多くなります。中規模以下の案件では、最低限の設計で手軽に構築できるCoffeeScriptも、よい選択肢ではないかと思います。

Box2DJSを使った2D物理演算

車を走らせたり、障害物と衝突したりといった、ゲームの中核となるロジックはBox2DJSを使用しています。Box2DJSは、質量・速度・摩擦をシミュレーションするJavaScriptの2D物理演算エンジンです。

表現方法自体は3Dですが、物理演算エンジンは2Dを使用しました。今回のようなシンプルなゲームを作るには、3Dの物理演算エンジンより、2Dの物理演算エンジンの方が、ゲームバランスや操作感において向いていると感じます。コンシューマーゲームなどの本格的なゲームとなると、3D物理演算エンジンによる処理は、必要不可欠なものだとは思いますが、その分、マシンへの負荷も高くなります。

物理演算に関しては、別途サンプルを作成して、チューニングしていきました。ゲームの中核となる部分ですので、まずこのサンプルで楽しいと思えるかどうかで、最終的なゲームのゴールが見えてくると思います。可能な限りゲーム性向上のためのチューニングしていくことが大切です。

初期段階のモックアップのイメージですが、まずはこのようにBox2Dを使って、2Dレースゲームを構築しました。この2Dレースゲームの情報を3D表示部分や情報部分（スピードメーター等）やコースデータ管理ロジック、リアルタイム通信ロジックに渡します。

物理演算クラスimjcart.logic.physics.Physicsにて、マップ情報を元にnew Carで車インスタンスを生成し、車の状態が変更したイベントCHANGE_CAR_CONDITION_EVENTをキャッチして、イベントを発行します。

public createCar() {
    // マップ情報を元に車を生成
    var x = 0;
    var y = 0;
    var i, j, max, max2;
    for (i = 0, max = imjcart.logic.map.value.MapConst.MAP.length; i < max; i = i + 1) {
        for (j = 0, max2 = imjcart.logic.map.value.MapConst.MAP[i].length; j < max2; j = j + 1) {
            if (imjcart.logic.map.value.MapConst.MAP[i][j] == imjcart.logic.map.value.MapConst.MAP_KEY_CAR_START_POSITION) {
                y = imjcart.logic.map.value.MapConst.MAP_BLOCK_SIZE * i;
                x = imjcart.logic.map.value.MapConst.MAP_BLOCK_SIZE * j;
                break;
            }
        }
    }
    this._car = new Car(this._context, this._world, x, y);
    // 車状態変更イベント
    this._car.addEventListener(event.PhysicsEvent.CHANGE_CAR_CONDITION_EVENT, (evt) => {
        this.dispatchEvent(imjcart.logic.physics.event.PhysicsEvent.CHANGE_CAR_CONDITION_EVENT, {
            x: evt.x,
            y: evt.y,
            bodyAngle: evt.bodyAngle,
            wheelAngle: evt.wheelAngle,
            speed: evt.speed,
            power: evt.power,
            gear: evt.gear,
            direction: evt.direction
        });
    });
}

imjcart.logic.physics.Carクラスでは、update関数が実行されると、入力されている値をホイールに反映し、車の状態に変化を与えます。変化した車の情報を付加して、車の状態が変更したイベントCHANGE_CAR_CONDITION_EVENTを発行します。

public update() {
    // ホイールに力を適応
    var i = 0, max;
    for (i = 0, max = this._frontWheels.length; i < max; i = i + 1) {
        var wheel = this._frontWheels[i];
        var direction = wheel.GetTransform().R.col2.Copy();
        direction.Multiply(this._enginePower);
        wheel.ApplyForce(direction, wheel.GetPosition());
    }
    // ホイールと車をつなぐジョイント部分に角度を適応
    for (i = 0, max = this._frontWheelJoints.length; i < max; i = i + 1) {
        var wheelJoint = this._frontWheelJoints[i];
        var angleDiff = this._steeringAngle - wheelJoint.GetJointAngle();
        wheelJoint.SetMotorSpeed(angleDiff * this._steerSpeed);
    }
    // 車状態変更イベントの発行
    var position = this._body.GetPosition();
    var velocity = this._body.GetLinearVelocity();
    var speedX = Math.abs(velocity.x);
    var speedY = Math.abs(velocity.y);
    var speed = 0;
    if (speedX < speedY) {
        speed = speedY;
    } else {
        speed = speedX;
    }
    this.dispatchEvent(imjcart.logic.physics.event.PhysicsEvent.CHANGE_CAR_CONDITION_EVENT, {
        x: position.x,
        y: position.y,
        bodyAngle: this._body.GetAngle(),
        wheelAngle: this._frontWheelJoints[0].GetJointAngle(),
        speed: speed,
        power: this._enginePower,
        gear: this._gear,
        direction: this._engineDirection
    });
}

dispatchEventメソッドは、イベントを発行するlib.event.EventDispacherクラス（オリジナルで作成）に定義されたメソッドです。表示要素のクラスはこのlib.event.EventDispacherクラスを継承しています。

three.jsの3D表現

WebGLを使った3D表示部分にはthree.jsを使用しています。three.jsは、WebGLを扱うライブラリとしては、最もよく使われているJavaScriptライブラリです。

Blenderというオープンソースの3次元コンピュータグラフィックスソフトウェアを使って、3Dモデルの作成を作成し、three.jsで読み込んで表示しています。Blenderで作成する3Dモデルデータ（今回のモデルデータはOBJ形式）は、ジオメトリ（形状）とUVテクスチャのみで、three.jsを使って、質感などの調整をしています。

また、今回のように実行環境が制限しづらいWebアプリケーションでは、なるべく多くのユーザーが利用できるように、マシンへの負荷は極力減らさないといけません。特にレースゲームは、現在走っているコースの先が見える必要があり、視野を広くしなければならないために、処理するデータ量が増え、より負荷がかかってしまいます。この負荷軽減のために、以下のことを考慮しています。

1. ポリゴンが少なくても成り立つデザイン
2. 影をつけない
3. ジオメトリ（形状）の結合
4. 負荷の少ないマテリアル（質感）を選択

1つめのポリゴンが少なくても成り立つデザインに関しては、下のタイヤのサンプルで、左のタイヤはポリゴン数を極端に減らしていますので、光や深度の計算が少なくなり、マシンへの負荷も小さくなります。右のタイヤはリアルなタイヤを再現したために、ポリゴン数も多く、マシンへの負荷も大きくなります。配置する量が少数ならそれほど問題になりませんが、コースデータに沿って多数配置する障害物ですので、マシン負荷は大きくなります。ただ、ポリゴン数が少ない分、リアルな表現からは遠く離れてしまっています。コース全体のデザインも含めてですが、リアルな表現を求めないポップなデザインを採用することで、低ポリゴンでも違和感のないようにしています。

2つめの影をつけないですが、下のキャプチャを見ていただければ、影がない左側のキャプチャと影がある右側のキャプチャでは、3D空間としての説得力にだいぶ違いが出てしまっているかと思います。ここは苦渋の決断ですが、影をつけることはthree.jsではとても負荷のかかる処理なので、より多くのユーザにストレスなく遊んでもらうためにも影をつけない方を採用しました。

ちなみに影を出すには、レンダラーのshadowMapEnabledをtrueにして、光源のcastShadowをtrueにします。そして影を作る側の物体のcastShadowをtrueにして、影を受ける側の物体のreceiveShadowをtrueにします。デフォルトではfalseのため影が出ません。

// レンダラー
renderer.shadowMapEnabled = true;
// 光源
light.castShadow = true;
// 影を作る側
mesh.castShadow = true;
// 影を受ける側
mesh.receiveShadow = true;

3つめのジオメトリの結合に関してですが、WebGLコンテンツの様にGPUを使用するコンテンツは、ジオメトリの数だけGPUに対してドローコール（描画命令）をします。このドローコールの回数はパフォーマンスに大きく影響します。ジオメトリをTHREE.GeometryUtils.merge(geometry, mesh)メソッドで結合することで、不要なドローコールの発生を少なくすることができます。注意点としては、結合したものは個別に動かすことや、マテリアルを個別に設定することはできませんので、今回は壁やコースなど、個別に動くことのない、大量に描画する必要のある要素に対してジオメトリの結合をしています。

var geometry = new THREE.Geometry(); // 空のジオメトリを作成
var meshArr = [];
// モデルデータとマテリアルを読み込む
var loader = new THREE.OBJMTLLoader();
loader.load("models/block03/block03.obj", "models/block03/block03.mtl", (object) => {
    object.traverse(function (child) {
        if (child instanceof THREE.Mesh) {
            child.material = new THREE.MeshLambertMaterial(child.material);
            child.material.ambient = new THREE.Color(imjcart.display.main.view3d.value.View3dConst.AMBIENT_COLOR);
            meshArr.push({
                mesh: child,
                material: child.material
            });
        }
    });
    // 読み込んだモデルデータをマップデータに沿って、クローンして配置。
    var i, j, max, max2;
    for (i = 0, max = imjcart.logic.map.value.MapConst.MAP.length; i < max; i = i + 1) {
        for (j = 0, max2 = imjcart.logic.map.value.MapConst.MAP[i].length; j < max2; j = j + 1) {
            if (imjcart.logic.map.value.MapConst.MAP[i][j] == imjcart.logic.map.value.MapConst.MAP_KEY_BLOCK) {
                var tagX = imjcart.logic.map.value.MapConst.MAP_BLOCK_SIZE * j + (imjcart.logic.map.value.MapConst.MAP_BLOCK_SIZE / 2);
                var tagY = 1;
                var tagZ = imjcart.logic.map.value.MapConst.MAP_BLOCK_SIZE * i + (imjcart.logic.map.value.MapConst.MAP_BLOCK_SIZE / 2);
                var mesh = meshArr[1].mesh.clone();
                mesh.position.set(tagX, tagY, tagZ);
                THREE.GeometryUtils.merge(geometry, mesh); // 空のジオメトリにマージして結合していく
            }
        }
    }
    this._block = new THREE.Mesh(geometry, meshArr[1].material);
    this._scene.add(this._block);
});

最後に4つめの負荷の少ないマテリアル（質感）の選択は、表面の質感を上げるマテリアルを選択すると、その分マシンへの負荷が上がるということです。マテリアルの種類は代表的なもので、以下のメリットがあります。

1. MeshBasicMaterial : 光の影響を受けない
2. MeshLambertMaterial : 影や光の反射などを描画できる（ランバート反射モデル）
3. MeshPhongMaterial : 影や光の反射などをより綺麗に描画できる（フォンシェーディング）

マシンへの負荷に関しては1、2、3の順に次第に高くなります。選択したマテリアルの違いもマシン負荷への影響は大きいですが、マテリアルにバンプマップを使うかどうかもマシン負荷への影響は大きくなります。バンプマップは表面に細かな凹凸を表現します。下のキャプチャはアスファルトにバンプマップを適応したもの（右）と、適応していないもの（左）の違いです。表現力を上げるためには、バンプマップを採用したいところですが、ここでもマシン負荷を考慮してバンプマップを使っていません。

リアルな表現に近づければ近づけるほど、マシンへの負荷が増えてしまいます。ある程度の表現力は確保しながら、どれだけ負荷を減らせるかの調整は、これくらいのスペックなら問題なく表示できるようにしたいというターゲットとなるマシンを決めて、そのマシンで最低限確保したいフレームレートを決めます。あとは都度、フレームレートを確認しながら調整するということの繰り返しになります。マシンスペックだけでなく、ブラウザによっても表示速度に差異があることを意識していなければなりません。

HTML5のAPIによる新しい表現力

WebGL以外のHTML5の要素も、それぞれの特徴にあわせて適宜使用しています。

• Canvas：コースマップ（コース縮尺図）
• SVG：スピードメーター
• WebFont：タイトルやテキスト全般
• CSS3：角丸やドロップシャドウやボタンデザイン

WebGLによる3D表示をしているCanvasの上に、各要素を配置していますが、上に乗っかっている要素を動かしたり、形状を変更させる場合には、背景に不透明な物を敷くなどの工夫が必要になります。そうしないと上に乗っかっている要素に変更があるたびに、下のCanvas全体まで、不要な再描画処理がかかってしまい、描画のパフォーマンスを著しく低下させてしまいます。

まとめ

以上が今回作成したJS-Racingで利用した、主なクライアントサイド技術になります。

3D表現として利用したWebGLは、IE11の対応によって最新のモダンブラウザでは、ほぼ実行可能な環境が揃ってきていると思います。

ユーザーのマシンスペックや、WebGL対応ブラウザの普及率を考えると、まだある程度ユーザーをしぼる必要がありますが、最近では話題を呼んでいる3Dコンテンツも次第に増えてきたように感じます。

次回はサーバサイドの使用技術と、その他の技術トピックに関して解説する予定です。