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

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

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

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

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

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

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

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

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

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

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

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

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

テレビとブラウザ

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

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

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

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

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

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

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

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

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

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

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

車とブラウザ

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

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

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

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

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

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

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

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

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

ゲームとブラウザ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2013年11月30日（土）に開催されました「HTML5 Conference 2013」の、株式会社テレビ朝日メディアプレックス 正田 聖さんによるセッション「次世代テレビを知る！ハイブリッドキャスト×HTML5」の内容をご紹介します。

拡張していくテレビとユーザー

近年、ユーザーのインターネットの利用時間が増加しており、テレビの視聴時間が減少していると言われています。一般的に言われている「テレビ離れ」という現象です。ただし、実際にはそういうことはありません。例えば、インターネットの検索ワードでは、テレビの話題が常に上位にあります。さらに、今年、テレビで放送されたアニメ映画の話題（台詞）が、Twitterで世界歴代最高瞬間風速を記録し、秒間14万3,199件のツイートがありました。このように、ユーザーは、どこかしらでテレビと向き合い、テレビの話題を誰かとしています。

ユーザーは、従来の視聴者、読者、消費者といった側面だけではなく、SNSやブログなどに代表されるように、制作者、参加者、発信者として劇的に進化してきました。ユーザーは、テレビを受動的に見るという従来型の楽しみ方だけではなく、拡張した新しい楽しみ方を先行して実践しています。一方、放送局などのサービス提供側は、このような新しい楽しみ方を未だに捉えられていません。そこで、ハイブリッドキャストというものが、このような新しいテレビの楽しみ方を技術的な側面からアプローチする手段として期待されています。

放送と通信を融合するハイブリッドキャスト

最近は、ネット接続環境を持ち、様々なアプリケーションを実行できるスマートテレビが多く販売されていますが、これらは、放送と通信を個別を利用しているに過ぎません。ハイブリッドキャストには、放送と通信を同期して利用できるという決定的な違いがあり、ハイブリッドキャストは、放送と通信を融合する技術であるということができます。インターネットの世界は自由でオープンなものであり、あらゆる情報を取得することができますが、人によっては有害なものも含まれるため、ハイブリッドキャストが安心・安全に利用されるよう、配慮する必要があります。

ハイブリッドキャストには、新しいビジネスモデルを構築することができるという期待があります。例えば、テレビを視聴した人が、テレビで紹介されていた商品を他のECサイトで注文した場合、現在、そのような購買を放送事業者側でコントロールすることはできません。また、いくらSNSでテレビの話題が盛り上がろうとも、放送事業者は全くそれに関与できません。ハイブリッドキャストを利用することで、放送事業者・サービス提供者側で、このような視聴者の行動をコントールすることができ、新しいビジネスモデルを構築することができると期待されています。

ハイブリッドキャストの技術仕様

ハイブリッドキャストはHTML5に準拠しています。そのため、HTML5で開発されたアプリケーションを、ハイブリッドキャストで動かすことができます。今までは、放送で送られてくる情報をデジタル放送受信機・従来のテレビで利用するためには、これらの情報を全て受信機で処理する必要があったのですが、インターネット・クラウドを利用することによって、テレビ受信機だけでは困難であった負荷の高い処理を、サービス提供者側で分担することができるというメリットもあります。そのため、既存のデータ放送だけでは実現できなかった高機能なサービスを提供できるようになる可能性があります。

ハイブリッドキャストは三つの要素で構成されています。一つ目は放送局です。放送局は、電波による放送を提供することに加えて、アプリケーションやコンテンツを開発するサービス事業者に対して、番組情報のメタデータを提供します。二つ目はサービス事業者です。サービス事業者はアプリケーションの開発から配信までを行い、ハイブリッドキャストのサービスを提供します。放送局がサービス事業者を兼ねることもあります。三つ目はハイブリッドキャスト受信機です。これはハイブリッドキャストのアプリケーションを実行するもので、モバイル端末との連携も可能になっています。

ハイブリッドキャストアプリケーションの種類

ハイブリッドキャストアプリケーションには、二つの種類があります。一つは放送と連動するアプリケーションです。編成チャンネルの視聴中に自動的に起動し、チャンネルが終了すると、自動的に終了するアプリケーションです。もう一つは非連動アプリケーションです。こちらは放送とは無関係に動作するアプリケーションです。受信機のメニュー操作（リモコン操作）によってアプリケーションの選択・起動を行います。アプリケーションの終了も、視聴者が手動で行います。

ハイブリッドキャスト対応テレビ ＝ HTML5 ＋ ハイブリッドキャスト拡張API

ハイブリッドキャスト対応テレビとは、HTML5とハイブリッドキャスト拡張APIの両方を実行できるブラウザを搭載したテレビのことを指します。既に東芝とパナソニックよりハイブリッドキャスト対応テレビが販売されています。

ハイブリッドキャスト拡張APIは、IPTVフォーラムが主体となって仕様が策定されているAPIであり、こちらのフォーラムのWebサイトより仕様を確認することができます。ハイブリッドキャストAPIのサンプルコードを以下に掲載します。

var url = "http://example.com/";
navigator.receiverDevice.setURLForCompanionDevice(url, {
	"auto_start": true
});

var message = "{ test: 'sample' }";
companionDevice.sendTextToHostDevice(message);

navigator.receiverDevice.addCompanionDeviceTextMessageListener(
function(text, deviceId){
	// textにデータが保存されている	
});

アプリケーション開発における検討事項

受信機と搭載ブラウザ

ハイブリッドキャストアプリケーションの受信機の性能が低いため（現時点ではスマートフォンより劣る）、アプリケーション開発時には、実機での検証が必須となります。搭載されているブラウザは、一般のブラウザとは異なり、受信機のメーカーが独自に開発したものとなっています。そのため、将来的にはHTML5に準拠する方向で進められているものの、現時点では受信機によってブラウザの仕様が異なる状態となっています。

ユーザー操作

マウスやトラックボールなどのポインティングデバイスの利用は基本的には想定していません。操作は全てリモコンの、決定ボタン、戻るボタン、十時ボタン、4色ボタンで行われることを想定しています。

スタイルの切り替え

CSSの仕様上、メディアタイプとして「tv」が定義されているのですが、ハイブリッドキャストのブラウザがこれにマッチするか否かは、実装依存となってしまいます。そのため、現時点では、デバイスの描画領域のサイズでスタイルを切り替える方が望ましいとされています。

<meta name="viewport" content="width=3840">
<link rel="stylesheet" media="(max-device-width: 1920px)" href="default.css" />
<link rel="stylesheet" media="(max-device-width: 3840px)" href="4k2k.css" />

デバッグ方法

ハイブリッドキャストではブラウザのデベロッパーツールが使えないので、デバッグを行う際には、以下のようにエラーログをサーバ側へ出力する方法などが考えられます。

window.onerror = function ( text, file, num ) {
	var error_url = "http://example.com/";
	var req = null, msg = [file, '@', num, '-', text];
	if(!XMLHttpRequest) return true;
	req = new XMLHttpRequest();
	req.open( 'POST', error_url, true );
	req.onreadystatechange = function() {
		if ( req.readyState == 4 && req.status == 200 ) return true;
		else if ( req.status != 200 ) return false;
	}
	req.setRequestHeader( 'Content-Type', 'application/x-www-form-urlencoded' );
	req.send( "msg=" + msg.join(' ') );
	return true;
}

JavaScriptのパフォーマンス

現状、ハイブリッドキャストの受信機の性能が非常に低いため、JavaScriptのパフォーマンスに非常に気をつかう必要があります。例えば、以下のような基本的なことに気をつける必要があります。

• JavScriptファイルの読み込みはbody要素の最下部に配置する
• DOM操作時はローカル変数にキャッシュしてアクセスを減らす
• 再描画と再配置を極力減らす

実装・検証デモ

テレビ映像領域の移動検証、放送領域にCanvasを重ねるオーバーレイ検証、アニメーションの実装方法ごとの動作比較、お絵描きアプリの開発検証の、4つのデモをお見せします。テレビ映像領域の移動検証については、想定していたよりも残像は発生しませんでしたが、やはり動きが重いという印象があります。オーバーレイ検証についても、PCよりも表示速度が劣るという結果になりました。お絵描きアプリは、受信機とモバイルを連携させ、スマートフォン側で描いた絵をテレビ上へ同期させるというものです。ハイブリッドキャスト拡張APIを用いて、同一無線LAN上でデバイス間で直接通信を行っています。こちらも受信機の性能により、テレビへの同期・描画が少し遅くなっています。

ハイブリッドキャストの今後の展望

ハイブリッドキャストは、次世代テレビの基盤技術になる可能性を持っています。ハイブリッドキャストの拡張APIに関しても、オープンになっており、広くサービス事業者に提供されています。今まで放送のコンテンツは放送局が独占していましたが、それらをサービス事業者・サードパーティが自由に利用することができるようになり、それらと融合した新しいサービス・コンテンツを開発することができるようになると考えられます。これにより、冒頭でお話しした通り、ユーザーが現在実践している、拡張された新しいテレビの楽しみ方を、技術的に支えることができると期待されています。今後、ハイブリッドキャストの受信機がどのくらい普及するのか、ハイブリッドキャスト対応のサービスがどのくらい提供されるのかという懸念点がありますが、メディアが持つ力は非常に絶大なものですので、広く開かれたAPIにより、サードパーティが素晴らしいアプリケーション・コンテンツを開発し、テレビの楽しみ方を拡大していけるのではないかと期待しています。