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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

HTML5 Conference 2016特集・第四弾は、「HTMLスナップショット2016」。2016年現在、HTMLはW3CとWHATWGという2つの組織によって別々に標準化が進んでいます。2つのHTMLが存在するに至った歴史と将来の展望、両者の違いを簡単にまとめます。

2つのHTMLに至った歴史

1999年にHTML4.01勧告が発行されてから足掛け15年、2014年にHTML5が勧告として発行されるに至ったわけですが、その間の主な出来事を表1に示します。

XMLこそがウェブの未来であるという見方が支配的だったために、2004年のOperaとMozillaの共同提案は却下され、W3CでHTMLを改良する道が閉ざされました。そこでブラウザーベンダーが集まってW3Cとは別の組織でHTMLやHTMLに関連する仕様の改良を行う、というのがWHATWGのはじまりです。

以来今日に至るまでずっと、WHATWGはHTMLの開発を（ある期間はW3Cと共同で、ある時期からはW3Cとは別に）し続けています。「WHATWG HTMLこそが実装者とウェブ開発者によって参照されるべき最新の仕様であり、欠陥フォーク（W3C HTMLのこと）は答えではない」というのはWHATWG HTMLのエディターであるAnne van Kesterenの言葉の通り、WHATWG HTMLを第一に参照すべきでしょう。

HTML5勧告以降のW3Cの動向

さて、W3Cに話を戻します。HTML5はスケジュールどおりに勧告となりましたが、後続のHTML 5.1はなかなか方針が定まらないまま、結局2015年の秋にHTML Working GroupがWeb Platform Working Group (WPWG)に改組されました。2016年1月にようやく新Working GroupからGitHubで開発を再開するというアナウンスがなされ、周知の通り6月にHTML 5.1は勧告候補となり、9月15日付けで勧告案が発行されました。順調にいけば、10月下旬には勧告が発行されるでしょう。

また、WPWGの新しいCharter（憲章）案には、すでに8月に草案として公開したHTML 5.2を2017年第4四半期に勧告とする、さらにはHTML 5.3の最初の公開草案を2017年第3四半期に発行するといった文言も見られますので、W3Cとしては1年に1回程度のペースで更新していく算段なのでしょう。

ところで、この9月に行われたTPACにおけるWPWGのミーティングでは、2つのHTMLが存在することそのものの問題は認識されており、このミーティングの中では「（2つのHTMLの）唯一の解決策はW3CがHTMLの作業を止めること」というような発言もWPWGの共同議長であるCharles McCathie Nevileから飛び出しましたが、WPWGとして合意に至るような結論は出されませんでした。あるいはHTMLをコア技術として採用しているEPUBの動向によっても、HTMLの開発に何らかの影響を与える可能性があると思われます。

2つのHTMLの違いについて

これまではごく簡単にW3Cから見たHTMLの過去と将来をざっくり俯瞰してみましたが、ここからは技術的に2つのHTMLがどのように異なるのかを見ていきたいと思います。図1は、2つのHTMLの違いを示したものですが、W3C HTMLがWHATWG HTMLの厳密な部分集合ではなく、W3C HTMLにWHATWG HTMLとは異なる独自の規定があるという点が肝となります。

具体的にどのように違うのか、というのは2つのHTMLの違いを明瞭に記述した文書が存在しないため、その全容を正確に把握するのは困難が伴います。理論上は両HTMLのGitHubのコミットログを丹念に追いかければ可能ですが、ここではW3C HTML (HTML 5.1の勧告案) とWHATWG HTML（HTML LS）の要素や属性の違いなどについて、紙面の都合上その全部の詳説は省きますが、主に両者の索引の比較からその一端を明らかにしようと思います。まず、要素の違いについて表2に示します。

今年に入ってWHATWG HTMLに導入されたShadow DOMに関わる<slot>要素を除けば、HTML 5.1とHTML 5.0でそれほど大きな違いはないと言えます。また、要素そのものは存在しますが、少なくとも<main>の定義や<dl>の説明にHTML 5.1とHTML LSとの間で差異があることを筆者が確認しています。これ以外にも2つのHTMLの説明で異なるものがあるかもしれません。続いて、属性の違いを表3に示します。

そもそもW3C HTMLでは別仕様として切り離されているMicrodata関連の5つの属性を除けば、11の属性が片方の仕様にあってもう片方にはない、という状況になっています。longdesc属性に至っては、一旦はHTML 5.1自身に含めておきながら、再び拡張仕様に分離する（すなわち、HTML 5.0とlongdesc拡張仕様の関係に戻す）という迷走を見せています。さらに、説明は省きますが、イベントハンドラー属性の違いを表4に示します。

また、IDL属性として、innerTextがWHATWG HTMLに規定されています。最後に両HTMLの違いとしてコメントの構文の違いを挙げておきます。

<!-- これは正当なコメントです -->
<!-------->
<!-- ↑のようなHTML断片を書いたことはありますか？ -->

コード例の2行目は、WHATWG HTMLでは正当なコメントになります。

おわりに

駆け足でW3C視点での歴史と将来の展望、およびW3C HTMLとWHATWG HTMLとの要素や属性、構文など比較を行いましたがいかがでしたでしょうか。W3C HTMLはあまりうまく策定作業が行われていない一方で、WHATWG HTMLのレポジトリーでは活発に議論が交わされており、毎日のようにHTMLが更新され続けています。当面は勢いのあるHTML Living Standardを参照するようにしてはいかがでしょうか、という提案をもって締めさせていただきたいと思います。

当日の資料と動画は下記で公開されていますので、こちらも参照してください。

• 講演資料

夏野剛氏、及川卓也氏、白石俊平氏が縦横無尽に語り合う

白石：まずは、登壇者のご紹介から。慶應義塾大学 政策・メディア研究科 特別招聘教授の夏野剛さんです。あまりご存じない方も多いかもしれませんけど、夏野さんはW3Cのボート（幹事）をずっとやっていらっしゃったんですよね。4年間ぐらいでしたっけ。

夏野：はい。2期、4年やってました。大変でした（笑）。

白石：本日はそうした標準化団体に深くコミットしていらした方として、WebRTCについて語っていただきたいと思います。

夏野：ちなみに、W3Cの設立メンバーが慶應大学なんですよね。ファウンディングメンバー。で、村井先生に「ボードやれ」って言われて、立候補したという。

白石：次に、Increments株式会社、プロダクトマネージャーの及川卓也さんです。この、WebRTCに関する対談については、前職のGoogleで、Google Chromeの開発に携わっていらっしゃったということで、実装面などについてもお話いただきたいと思います。

及川：Incrementsは「Qiita」というプログラムの情報共有サービスを提供しています。もう辞めちゃったんですけど、Chromeのエンジニアリングマネージャーも、結構大変でございました。楽しかったですけど（笑）。

慶應義塾大学 政策・メディア研究科 特別招聘教授　夏野剛氏
早稲田大学政治経済学部卒、東京ガス入社。ペンシルバニア大学経営大学院（ウォートンスクール）卒。ベンチャー企業副社長を経て、1997年NTTドコモへ。99年に「iモード」、その後も多くのサービスを立ち上げた。2008年にドコモ退社。現在は慶應大学の特別招聘教授のほか、カドカワ、トランスコスモス、セガサミーホールディングス、ぴあ、グリー、DLE、U-NEXTなどの取締役を兼任。09年から13年までHTMLの標準化機関であるW3C(World Wide Web Consortium)のアドバイザリーボードメンバーを務める。

Increments株式会社 プロダクトマネージャー　及川卓也氏
早稲田大学理工学部卒業後、外資系コンピューター企業の研究開発、マイクロソフト株式会社（当時）の日本語版・韓国語版Windowsの開発統括を経て、グーグルでプロダクトマネージャとエンジニアリングマネージャを務める。2015年11月よりIncrementsにてプロダクトマネージャとして従事。

株式会社オープンウェブ・テクノロジー代表取締役CEO　白石俊平氏
エンジニア、コピーライター。日本最大のWeb技術者コミュニティhtml5jを5年間リードした後スタートアップを創業、テクノロジー分野に特化したキュレーションサービス「TechFeed」を2015年12月にリリース。日本の開発者の役に立つべく、プロダクトマネージャー兼CEOとして奔走中。「HTML5&API入門」（日経BP）など、著作執筆多数。Web技術者向けメディアHTML5 Experts.jp編集長も務める。

WebRTCをどう見るか？

白石：まず最初のテーマは「WebRTCをどう見るか」です。本日のセッションテーマは未来感のあるものが多いので、ビジョン的なお話をお聞きしたいなと思っています。

及川：基本ポジティブですね。少し前だと、音声やビデオのカンファレンスをやろうとすると、Flashを使わなきゃいけない時代もあった。あれって結構面倒くさいんですよね。音声やビデオで軽く会議をやろうとした瞬間に、プラグイン入っていないから、インストールしてくださいって表示されたりして。そのためのセットアップで、少なくとも1分とか2分経ってしまったり、下手するとブラウザをリロードしなくちゃいけなかったり。

普通のテキストチャットと同じぐらいカジュアルなコミュニケーションができるようになったのは、WebRTCのおかげです。今後はどんなブラウザでも使えるようになっていく、という意味で非常にポジティブかなと。一方でっていうことが、ちょっとあるんですけれども、その前に夏野さんのご意見も聞きたいと思います。

夏野：今及川さんが言ったみたいにパソコンをベースにしてWebで何でもできちゃうと、ソフトをダウンロードすることはほとんど要らなくなって、せいぜいプラグインくらい。そのプラグインすらもHTML5になってくると、ほとんど要らなくなるっていう世界になってきた。

そんな理想型に進んでるのに、スマホが出てきたことによって、状況が変わってきた。スマホが出てきてから5年ぐらい経ちますが、その間にWebの勢いって1回萎えているんですよ。理由は簡単。ネイティブアプリで遊ぶほうが忙しすぎて、Webなんか立ちあげている場合じゃないから。

ネイティブアプリにする理由の一つは、グラフィックスの性能。もう一つはこれ、まさにリアルタイムコミュニケーションなんですよね。このWebRTCをきちんとスマホまで含めて、マルチデバイスで広がっていくと、かなり開発者の負荷も減らせるし、サービスの性能も向上することにつながると思っています。いち早くモバイルも巻き込んだ中で、WebRTCがどんどん広がっていくことを切望しますね。

「相互運用性」という課題

白石：なるほど。たしかにWebRTCはマルチプラットフォームや、マルチデバイスといったところでは、結構強みがあると思います。及川さんの言いかけたお話を。

及川：そういう意味で言うと、プラットフォーム、相互運用のところのレイヤーが1つ上がったかたちになっていくと思うんですよ。どのブラウザでも使えるということは、すごい貴重な技術であるのと同時に、もしかしたらロックインされるだとか、相互運用性までを考えないといけない。

例えば、WebRTCを使ってビデオカンファレンスができるかっていう話になったときに、実装依存の部分がたくさんあるわけですよね。おそらく制御のところだったり、ビデオコーデックなんかは、現状すべてのブラウザに当てはまるところはないんじゃないかな。もちろん、相手に合わせて変えるっていうのは実現可能だと思うんですね。GoogleもWebRTCを使ったそういったサービスを出しています。

一方、Facebookのチャットからビデオメッセージやビデオチャットをやりたいといっても、ハングアウトにはつながらないし、（別サービスとは）つながる世界が想像できないわけですね。これって、どっかで見た、過去で見た、未来なんですよ。どういうことかと言うと、シンプルなテキストチャットのときもそういう議論はたくさんあったんですね。

Yahoo!メッセンジャー、AOLメッセンジャーと、MSNのメッセンジャーと、Google Talkをつなげたいよね、という流れになり、ちゃんと仕様を考えましょうということになった。IETF（Internet Engineering Task Force）で、XMPPだとかSimpleが候補に上がりました。陣営二つに分かれちゃったわけですけれども。

Googleはその部分、なぜか知らないけど、すごい積極的にやっていいます。Google Talkは、XMPP完全準拠でJabberというかたちにして、ほかのJabberのサーバーにもつなげられたのに、結局はGoogleもシャットダウンしちゃった。相互運用ができる状況じゃないと。

なぜならば、技術以前にソーシャルグラフというか、ユーザーのデータベースをわざわざ相手に開放したくないわけですよね。なので、この部分まで含めてWebRTCに期待するとしたら、それはちょっと厳しいところもあるし、どこまでの部分をコモディティ化していくか、という課題があるかなと。

本当は全部相互運用ができたほうがいいのだけれども、そこにいくまでには、過去の歴史を見ても、なかなか厳しい現実問題としてある。さっき「でも」というところでちょっと言いたかったことです。

GoogleがWebRTCを立ち上げた背景とは

白石：なるほど。ちなみにWebRTCって、もともとの出自はGoogleさんがオープンソースでwebrtc.orgを立ち上げたところからかなと思うんです。それ、間違いないですか？

夏野：たぶん、それが最初だったと思いますよ。

白石：どういうビジョンを持って、このプロジェクトを始められたのでしょうか。

及川：理由は非常に単純で、Googleも要はすべてWebでやりたいわけですよ。

白石：検索とか広告とか、そういったところにつなげるためでしょうか。

及川：それは、ビジネスモデル的には、当然あるとは思います。だけど、Googleって恵まれた会社で、8割以上のエンジニアは、お金のことを全く考えなくていいんですよ。

で、「あなたたちの役割というは、インターネットが健全に発展するためのものです」と。そのネイティブで持っているアプリケーションが使える機能をそのままWebでも使えるようにするために、HTML5を含め、いろんなことをやっていたんですね。

最初は、Canvasだってもともと使えなくって。Canvasが使えないと、この2次元対応で1点から1点までの線を引くことすらできなかったわけですよね。そこから始まり、ちゃんと3Dができるようになり、全部やっていったあとに、自然にビデオカンファレンスだとか、リアルタイムコミュニケーションだとか、そういったものができて当たり前という時代になったんだと思うんです。

白石：なるほど。

夏野：僕も標準化の現場にいたのでわかる。面白いのは、Googleってライトサイドのプレイヤーなんです。

白石：ダークサイドの逆ですね。

夏野：ダークサイドもいるんだよね（笑）。つまり、ネットの中立性とか、ブラウザがみんなに使われるとか、相互運用がどうのとか、そういうこととは、逆のことを考えている会社もいろいろあって、面白いですよ。

白石：そういうダークサイドな会社が、W3Cにいるところが面白いですね。

夏野：それ以上聞かないで（笑）。最近はいなくなりましたけど、10年前は大変でした。

Webですべてを完結する世界は作れるか

白石：僕、さっき及川さんのお話を聞いて、及川さんが昔講演でおっしゃっていたことを思い出しました。デスクトップアプリケーションで起きた最後のイノベーションはSkypeで、そのあとはずっとWebで起きているみたいな話を5年前にしてたんですよね。そのSkypeが今ようやくWebの補完をしているんだなって。覚えていらっしゃいますか、そんなことを言っていたのを。

及川：そうですね。もう少し補足で説明すると、Webというのはもう多くのユーザーが使っていて、プラットフォームになっています。それをあえてリマインドするために、横軸に時系列で、1990年、2000年、2005年で振り返ってみたんです。

昔はデスクトップ系のちゃんとインストールして使うようなアプリケーションがたくさんあった。それが、2005、2006年からを境に、TwitterやGoogleMap、YouTubeなどのサービスが出てきた。この違いは何かというと、ここから先は「Webですべて完結するようになっているんですよ」、という話は、僕の持ちネタですね(笑)。

夏野：それと同時期にスマホが流行ってきた段階で、Skypeはアプリを出すのが、結構遅れたんですね。結局、FacebookやTwitterはアプリを出して、よりモバイルのほうにユーザーが寄っていった。ここがまた微妙なところで、PCのほうが進んでいるのに、スマホが出てきて逆転されている。これからの大きな課題なんだろうなと思ってます。もうモバイルの世界は、どんどんネイティブの世界にいってるんですから。

白石：また（ネイティブ→Webという）歴史は繰り返すのか、というとちょっと疑問ですね。スマホもWeb中心になっていくのかというと、今のところそうとも思えない。

及川：モバイルのネイティブアプリだけじゃ解決できないものもあります。まず、ユーザーにインストールしてもらえない。インストしたとしても使えない、という壁が二つあるんですね。

例えば、よくあるグルメの人気アプリ。この近くに何か美味しいお店がないかなと考えたときに、ユーザーがぱっと思い浮かぶのは日本を代表するサービスのサイトなんですね。トップ、2番目、3番目、4番目…までインストしてもらうのは難しい。自分のサービスがグルメ業界の4番目だったとしたら、まずはインストしてもらうことが第一の壁です。

さらにその4番目をインストしてもらったとしても、お店を探したときに、1番目、2番目、3番目で解決しちゃったなら、4番目なんて使わないわけですね。するとインストしても使わないわけです。実際には、検索したほうが便利なことがたくさんありますね。検索して、上から本当にいいものって選んでもらったり、もしくは検索したときにそのサービスが気に入ったら、そこからインストしてもらう導線を張ればいいと。

なので、Webとモバイルはハイブリッドにやったほうがいいんじゃないかと。deep linkingだったりだとか、app indexingだったり。

あとは機能面ですね。Geolocationはモバイルのほうが優れているし、昔はブラウザで正確にとることができなかった。だからGoogleみたいなブラウザベンダーが追い付こうと頑張った。でもそうこうしているうちに、モバイルのほうもパフォーマンスだとかUXだとか、機能面でも追いつこうとしているところだと思います。

白石：なるほど。WebRTCも当然ながらも、デスクトップアプリやモバイルアプリしかできなかったリアルタイムコミュニケーションを、Webに載せていく流れになるわけですね。

IoT・ロボティクスとWebRTCの未来は、民主化するイノベーションになるか

白石：次のテーマは、「IoTやロボティクスとWebRTCの未来」です。

夏野：IoTやロボティクスというと、Webとあまり関係なさそうな感じもするんですけど、実は密接に関係している。結局このセンサーというのは、それ自身がコミュニケーション、特にリアルタイムコミュニケーションすることが前提で作られているからです。

じゃあ、すべてのデバイスごとに全部クライアントを作るのか、みたいな話になってくるわけですけど。受け側はWebでいいわけですね。実際、受け側はRTCでやる。実は、RTCの相手先としては、もうこのセンサーやロボティクスとか、いわゆるIoT系は、見逃しちゃいけない。それどころか、それをメインに考えてもいいんじゃないかと。

及川：去年、慶應大学SFCのORF（オープンリサーチフォーラム）で、村井純先生がギター弾きたくなったという理由で開催されたイベントがあったんです。いきなり「及川さん、ギター弾かないか？」というメールがきて、「はい」って言っちゃったら、ニコ生で全国中継されるっていう（笑）。そのとき東京ビッグサイトか何かでやっていた楽器フェアとニコファーレをつないで何かやろうとなったときに、WebRTCを使ったんです。そこで面白かったのが、Web MIDIやWeb Audioを活用したORFを使ったこと。Web MIDIは電子楽器をつなぐための規格で、楽器をWebのシーケンサーから鳴らせるものなんですけど、ほかの用途にも使えちゃうんですね。

要は、MIDIでデバイスをコントロールするように、MIDI信号を理解してデバイスが動くようにすることができるわけです。今までの技術の歴史を見たときにも、本来と違う使われ方をして、いろんな技術革新が起きていることっていうのはたくさんあります。民主化するイノベーションというのがあって、本来のベンダーが想定したものとは違ういろんなかたちに、クリエイターやユーザーが発展させていくことがある。WebRTCというか、Web MIDIというのもその一例であり、そういった想定外のケースが出てきても面白いんじゃないかなと思いますね。

リアルタイムの強みをWebRTCはどう切り拓くか

夏野：今の話で感化されて、思い出したことがあります。インターネットが出てきて、動画のアーカイブができるようになったことは、最大のメリットだと、みんな思っているんですよね。つまり、テレビと違って縛られないから、いつでも自分のタイミングで、好きなときに動画を見たり、情報を入手できる。

これがインターネットの最大のメリットだったはずなのに、さっきの村井先生のコンサートや演奏みたいなものは、アーカイブで見ようとする人があんまりいないんですよね。リアルタイムで見るほうが価値があるという、不思議なことが起こっていまして。ニコニコはライブ配信したものを、後からタイムシフトというかたちで見たり、アーカイブにして見たりすることができるんですが、ほとんどの動画でリアルタイムで配信するほうが視聴者多いんですよ。

YouTubeは世界的にダウンロード型で成功している話はありますが、感動のレベルっていうのは、やっぱりリアルタイムのほうが大きいんです。これ、ちょっとジレンマというか、ネットのジレンマなんですけどね。いわゆるネットのよさをある意味放棄しているわけですよね。

ニコニコが何でそうなるかというと、コメントが書けるからなんです。リアルタイムで行ったものに書き込むのと、アーカイブで見ているものに書き込むのでは、盛り上がりが違うんですね。今、この瞬間に、何万人が、俺のコメント見ている、こういいうのを書いたよ、という満足感が違うみたいななんですよ。だから、YouTubeとニコニコというのは、全然違うものとして、完全に両立していて、ユーザーは使い分けちゃうわけなんですけども。そういう世界がWebRTCでも繰り広げられていくんじゃないかって思います。

白石：面白いですね。Web系の標準化技術は、コモディティ化みたいなインパクトが、割と強調されている。今まですごいお金かかったものが安くできますよ、誰でもできますよみたいな価値観ではなく、リアルタイムならではの価値観というか、リアリティみたいなところの面白さや価値はあるのかもなと、ちょっと思いましたね。

夏野：一方で注意しなきゃいけないのは、アメリカはやたらとみんな、パソコンの前に座っているんですよ。自分のオフィスでも、プライベートでも。だから、このRTC系のアプリケーションがいっぱい出てくる。SNSもそうだけどね。それがゆえに、Facebookはモバイル対応遅れたっていう話もあるんですけど。一方で、日本はどうかというと、エンジニアは結構PCの前に座っているけど、それ以外の人はもう基本スマホじゃないですか。だからこそ日本が率先して、モバイルとWebを覆うようなRTCのアプリケーションとか、仕様を決めていくのが重要なんじゃないかと思うんです。

白石：そういう違いもあって、日本人がよくTwitter使うのかもしれないですね。テキストベースで軽いから、リアルタイムで接することができるし。

及川：やっぱり、Webってリアルタイムじゃなかったんですよね、ずっと。Webのもともとのオリジンが情報じゃないですか。いわゆるHTMLやCSS、Googleドキュメントとか、情報の多くはめちゃくちゃドキュメントなわけですよ。リアルタイムで複数人数がコミュニケーションできるようになってきたとはいえ、どこか静的なものであったり、もしくは動的だといっても限度があったところだったんですよね。だから、リアルタイムでやりとりできるWebRTCが入ってきて、今までのWebの要素技術とどう組み合わせるかということを、考えてはじめているんじゃないかな。

WebRTCのほうに期待したいのは、今までのWebのコア要素の何かをちゃんと生かせるようなこと。Webのいいところは、マッシュアップだなと。WebRTCをいかにもっとWeb化するかというところに、方向性、将来の発展を考えていくのも面白いんじゃないかなと思います。

IT企業の経営者は『攻殻機動隊』を読むべき！？

白石：なるほど、たしかにマッシュアップはありですね。ところで話は変わりますが、遠隔地でロボットを操作したり、触覚とかも再現するみたいな面白い映画があるそうですね。

夏野：『サロゲート』という最近のアメリカ映画で、ロボットが人間の社会生活のすべてを代行する近未来を描いているんです。ロボットが生活しているから、何かあってもオペレーターである人間は安全という話なんですが、こういう考え方ってすでに『攻殻機動隊』で描かれているんです。

1989年の漫画なんですけど、現在SFで語られているほとんどすべての要素は、全部1989年の日本のコミック漫画に入っているというのは、すごいですよね。だから、僕は、すべてのIT企業の経営者は『攻殻機動隊』を読めと言っています。残念ながら読んでいる人はほとんどいないですね。

及川：医療なんて『da Vinci』でしたっけ。医療ロボットがあるじゃないですか。WebRTCで遠隔医療というかたちを提供できるならば、非常に役に立つだろうのもあるんじゃないかなと。

コミュニケーション・SNS と、(Web)RTCの未来

白石：次のテーマは、「コミュニケーションSNSとWebRTCの未来」です。今のコミュニケーションって、基本的には非同期で、ほぼリアルタイムじゃないものがメインだったと思います。でもTwitter等もどんどんリアルタイム化していって、さっきのニコニコの話も出ていましたが、リアルタイムのコミュニケーションの分野にも進化を掘り起こすのではないかなというお話です。

夏野：SNSの使い方はリアルタイム型に変わってきましたね。Facebookを見ていると、もう誰がオンライン中かわかってしまう。その人からすぐに返答が返ってこない時点で、それが一つのメッセージになっちゃいますよね。

白石：たしかに。

夏野：奥さんや上司からの連絡に、オンライン状態にあるのに返事がないと、非常に面倒くさいことになるよね（笑）。でも時代の流れとして、やっぱり同期するほうに向かっている。だから、LINEの既読というのはウザがられながらも、貴重な機能として、みんな受け入れられているんだと思う。

ウザがられても受け入れられるのは、すべてのアプリケーションがそうなってく可能性であって、面白いですよね。昔、携帯電話が出てきたときに、ほとんどのサラリーマンが嫌だと言ったんですけど、みんな受け入れました。だから、もう受け入れた上で何ができるかを考える方が生産的ですね。

及川：ツールとして本来目的にしていることと、どう使われるかかにずれが出てくることがありますよね。本来、同期型リアルタイムであるチャットを今言ったみたいに、既読だとかを一切抜きにして言うと、それをリアルタイムとか同期型に使わないことも増えてきていると。

その象徴が、エンジニアの方はよく使っていると思われるSlack。Slackは基本チャットなんだけど、普通のチャットと言われるには、非常に違和感を感じます。もちろんな同期型のコミュニケーションのフロー型と言われ、ストック型じゃないとは言われているんだけど、一方でストック的にも使えたりとか、非同期的なコミュニケーションもしっかりできる。ある時間をすぎると勝手にスリープモードに入るようになったりする機能が入ったりしていて、コミュ障のエンジニアに優しいようなところがあったりする。

だから、RTCもリアルタイムということと、もう一つの非同期と言う言葉が、必ずしも一緒じゃないんじゃないかなと思うんですね。

ビデオ会議はWebRTCでどう変わるか

白石：ちなみに、お二人は海外の方とテレカン（teleconference）やビデオ会議を結構されてたと思うんですが、そういった観点でWebRTCは、どうなんでしょうか。

及川：電話とビデオが入ったものとの違いは、すごく大きいんですよ。やはり、その五感が伝わったほうがコミュニケーションしやすい。映りたくないからビデオをOFFにしますって、やった途端にその人のプレゼンスは、その会議で下がっちゃうんですよね。顔がちょっと映るというだけでも、バリューはかなりのものがあると思います。

ただし、こういったインターネットのコミュニケーションは技術が発達したとしても、現地に行かなければだめなことが、山ほどあって。常にマイクとカメラがあるわけではないという話もあるですが、要は時差ですね。その人と同じ時間帯でどのぐらい働けるか、空気を共有できるかというのは、絶対にインターネットとかIT技術では解決できない。なので、RTC的なものがどんなに発達したとしても、フェイストゥフェイスでの重要性というのは、まあ、なくならないのかな。いいのか、悪いのか、ちょっとわからないですけど。

白石：フェイストゥフェイスはビデオ会議よりも、同じ部屋にいたほうが伝わるものが多いというのはありますね。顔も見えているし、表情も全部見えているのに、何か伝わらないみたいな。そういう感覚はありませんか。

夏野：それは技術的な問題もありますが、面白い話があるんです。Haloというテレビ電話会議のシステムをHPが販売していたんですよ。実は、これを開発したのが映画会社。離れた場所での会議でもリアルな感覚を伝えるために、スクリーンに映る顔のサイズが、本当に座っているのと完全に同じように映るような仕組にした。ここで見ると、向こう側に本当に人がいる感じががある。

イスとか机も、全部そろっていて4カ所までつなげる。4カ所つなぐと、円テーブルに座っている感じにちゃんと映るようになっていて、上のモニターは資料とかを映すんですね。この3面で誰が誰を見ているのが、完全にわかります。これ、飲み会できますよ、マジで。でもこの仕組が異常に高いので、WebRTCが必要なんです。

白石：人間はサイズとか、目線とか、そういう情報からもいろいろ得ているんですね。WebRTCは、それを再現できると。

夏野：これはすごいよくできていますよ。

及川：でも、逆もあるかなと思うんですね。リアルには会わないということ。いくつか軸があるんですけど、一つはリモートワーク。例えば、GitHubという会社は全員リモートなんですね。だから、どこが主従かというのはないし、リモートを前提にしたコミュニケーションが成り立つ。

もう一つは仮想現実というか、さっきの「アバター」的な話でいうと、リアルに会ったほうが、面倒くさいことってたくさんあるわけですよ。だから、自分の化身がネット上にいて、その人たち同士で話をしますと。その結果、ちゃんと自分が、リアルの世界に持って帰って、何かやりますみたいな、そういったコミュニケーションもあるんじゃないかなと思うんですね。

夏野：さっきの映画『サロゲート』とか『攻殻機動隊』がそうかな。その世界ではものすごい美人なんだけど、男かもしれない。実は80歳かもしれない。そのほうが見た目に惑わされず、意見とか人間の本質的なメッセージをちゃんと受け取れるということですよね。

夏野：冒頭のリアルタイムコミュニケーションの話ですが、実はW3Cでの重要な会議って、全部IRCを使っているんですね。で、発言の要旨を打つ人がいるんですよ。国際的な会議なので、ネイティブなみに英語ができないけど、技術的にはすごい優秀だったりする人もいる。ちゃんと文字化してくれると、話についていけなかったときも、議事録を見て、ちょっと遅れてついてきてくれる。これ、リアルタイムコミュニケーションのすごくいい事例だなと思っています。GoogleがやっているようなWebで自動翻訳されるようになったら、相当、国際会議は楽になるなと。あれ、いいカルチャーですね。

白石：Google I/Oでもやってましたね。僕も参加したとき、それに感銘を受けました。

及川：アメリカはそういったキャプチャー的なものが進んでいて、ハンディキャップがある方に、平等な機会を与えるという考えにもつながっているんです。私もTPACとかでW3Cの会議に行ったことあるんですけど、すごい助かりますね。いろんな人がしゃべっていると、追いつかないとこがあるんですが、ログ見ればちゃんと確認できる。

そのときに、もし話すのがちょっと厳しかったら、そこのIRC上で「さっきのところ、実はこうだったよ。今確認したよ」って書いとくだけで、きちっと皆さん読んでくれるし。ログにも残るし、いろんな国から、いろんな言語がネイティブの人が入るときには、非常にいい仕組じゃないかなと思いますね。

夏野：だからこういうのは、日本こそ、僕は頑張ってほしいなと思っていて。日本人が、一番損しているわけじゃないですか、コミュニケーションってさ。これを技術で解決しようというのを、あんまり困っていない、アメリカの会社がやるより、日本の会社がもっと真剣にやったほうがいいんじゃないかと思うんですけど。

白石：ぜひ、やっていただきたいですね！

仮想現実／拡張現実と、WebRTCの未来

白石：次は仮想現実、拡張現実みたいなお話をお聞きしたいんですけど。

夏野：さっきの話って、拡張現実に近いですよ。拡張現実って、その上にアニメキャラを出して何か言わせることだけじゃなくて、リアルに会話しているところに、それが全部テキスト化されるなんていったら、それは拡張現実じゃないですか。

だから、あんまりSFチックなファンタジックな方向に考えないで、もうちょっとリアリスティックに考えると、拡張現実はもっと現実を拡張していくわけなので、もっとあっていいと思うね。ARが何に使えるかというのは、もう誰もまともなソリューション出せないままきてしまったから。でも、よく考えると、ARを使うとここに字幕が出る。これは十分面白いよね。

白石：たしかに役に立ちますね。

及川：さっきのSlackは単純なチャットシステムであるのと同時に、いろんなかたちでbotが使えるわけですよね。そのbotに話しかけることによって、継続的インテグレーションして始めるのも面白い。私たちの会社だと、ランチ行きたいって言ったら、ランチのおすすめ教えてくれたりだとか、その時間になると「今日の掃除当番、誰がほうきです、掃除してください」って言ってくれる。

テキストベースでもいろんなことができるし、今、夏野さんがおっしゃったみたいに、ARやVRbotみたいなものが、WebRTCのクラウドとして、いろんな振る舞いしていったりすることが、もう拡張現実の世界になってくるんだと思うんですよね。

白石：なるほど。

及川：実はbotだらけでもいいんじゃないかなと思うことがたくさんあって。人間に話すと面倒くさいことなどは、とっても頭のいいbot、もしくは、人工無脳的にちょっとばかなbotとコミュニケーションするほうが、いろいろ円滑に進めるところがある気がします。テキストだけでなく、RTCの世界でも出てきたりするといいんじゃないかなと思いますね。

次のデバイスとして期待しているものは？

白石：会場からの質問も受け付けたいと思います。

Q:次のデバイスとして期待しているものってありますか？

夏野：どれぐらいのレンジで考えるかですが、僕はこの30年以内に全部デバイスはなくなると思っています。だから、完全に電脳。電脳の中でWebを浮かべれば、Webが浮かぶし、情報は全部で取れるし、送ろうと思えばすぐ送れることになる。ウェアラブルとかVRモノも出ているけど、期待するのはノーデバイス。あとは、『攻殻機動隊』を読んでください。

及川：逆張りで言わせていただくと、紙ですね（笑）。要は、やっぱりアナログって強いんですよ。だから、ペンでもって自分で何かを書いてとかっていうのもあるし、目にも優しいですので。今の紙、そのものじゃないかもしれないけれども、こういった紙をメタファーにしたようなデバイスは、インターネットにおいて、ずっと取り残されている。確か、ペーパーレスというキーワードとともに、そのIT化、コンピュータ化の中で、過去のデバイスにされているんだけれども、実は再発明されるべきものじゃないかな。紙みたいなデバイスにRTCが入ってきたら、何かできるのかと期待します。

WebRTCに期待したいことは？

白石：最後にWebRTCに絡めた何か一言づつお願いします。

夏野：さんざん出してきましたが『攻殻機動隊』です。つまりね、日本のエンジニアはものすごい短視眼的になりがちなんですよ。だけどやっぱり20年先、10年先に何がありそうか、あってほしいか。ありそうかを予測するのは面倒くさいけれど、あってほしいかと言う文脈から戻ってWebRTCを考えることが、そのデバイスをどう考えるとかという発想前にしてほしいんですよね。そうしないと、何か突き抜けられないし、つまらないね。あとは『攻殻機動隊』を読んでください。

及川：僕は最近、botがすごい好きなんですね。だから、RTCでbot、しかも今誰かがサポートしてくれるんじゃなくて、僕の代わりに全部やってくれると。だから、朝早くビデオ会議とかだと面倒くさいので、もう僕の振る舞いを覚えてくれたら勝手に動いてくれるような、そういった世界観が来るといいなと思います。

白石：皆さん、楽しんでいただけましたでしょうか。楽しんでいただけた方は、大きな拍手で終わりたいと思います。どうもありがとうございました。（盛大な拍手！）

Meetupを「札幌」で行うキッカケ

2015年10月末はなぜか札幌でのイベントが多かったと思いますが、これ実はW3C Technical Plenary / Advisory Committee(通称：TPAC、てぃーぱっく)というMeetingが札幌で行われたからなのです。

詳細はWeb技術の最新動向と未来を知る！〜Leading the way to W3C TPAC 2015〜【TPAC紹介編】にも書かれていますが、ここでも軽くご説明します。TPACとはWebの標準化団体であるW3Cが年に1回行う全体会合で、通常10月最終週の5日間で北米、ヨーロッパ、アジアのどこかで開催されます。

全体会合とはいえ、5日間通して全体会議をしている訳ではなくて、実際に全体で集まるのはたいて中間日のTechnical Plenary Dayと呼ばれる日。この日だけはアンカンファレンス形式で進められ、当日の朝に話したい内容がある人が場所を確保して分科会(Breakout Session)を行う、という流れになっています。

この日以外は、W3Cにある43のワーキング・グループ（2015年11月6日現在）からそれぞれが議論したい内容、メンバーのスケジュールから日程設定してFace to Faceでのミーティングを行っています。たいていの場合メンバーは世界各国に散らばっているため、普段は電話での会議をしているので顔を合わせてミーティングを行うのは、非常に貴重な時間となっています。

前段が長くなりましたが、ここから本題です。Web Audio API、Web MIDI API（Web Music）の仕様を策定しているのはW3Cのオーディオ・ワーキンググループ(Audio WG)。今回のTPACでは26日、27日にミーティングを行うことになりましたので、せっかくのこの機会に「Audio WGのメンバーとイベントやろう！」と思い立ったのが、今回のMeetupのキッカケです。

「札幌」でWeb Musicは初めて

今まで日本で開催されたWeb Music関連イベントは、東京と京都でのハッカソンとMeetup1回だったので、北海道では初めて。そこで、Meetupにして「Web Musicとはなんぞ？」を中心に伝えられるように、以下の方々に登壇していただきました。

• かわい りょうや（開発者、私です）
• Chris Wilson 氏 (Web Audio/MIDI 仕様の編集者)
• 藍 圭介 氏（開発者）
• 豊島 隆志 氏（ChromiumコミッターでWeb MIDI APIの実装者）
• Joe Berkovitz 氏 (Audio WGの共同議長)
• 渡邊 正和 氏（開発者：VJアプリを主に開発）

セッションの内容

かわい りょうや

Web Audio、Web MIDIとは何か、何ができるのか、どのブラウザで使えるのかを中心に話をしましたブラウザで電子楽器を作ってみよう！でご紹介したWeb Audioで作ったアナログ・シンセ、FMシンセの紹介とデモを行い、基本的な使い方とできることの説明、またそれに加えて今回はServiceworkerを使ったオフラインでの動作のデモ、またデスクトップからアプリを起動できるWebApp Manifestのデモも実施。モバイル上でもWebアプリは進化していてNativeアプリに近づいていることの説明を行いました。
▶ スライド

Chris Wilson 氏

Making the Web RockというタイトルでDrum Machine、ボコーダー、Audio Input Effect、DJと次々にデモを披露していただき、「Web Audio API、Web MIDI APIを使うとWebブラウザ上でここまでできます」という点を幅広く説明してくれました。また「このWebアプリのチューナができたおかげでOSネイティブなチューナーアプリ（iOSやAndroidのアプリ）は全部消した」という実話も披露していただきました。チューナーとは音の周波数（音程）を正しく調整する為に使う器具のことです。
▶ スライド

ここでChris氏の発表の中から「Webアプリのチューナ以外のOSネイティブなチューナーアプリを削除できた」という点について、旬な話題ですので少しだけご紹介します。

どのようにWebアプリのチューナーが実装されているか
チューナーは例えばギターの弦1本1本を正しく調整（チューニング）する為に、1本の弦を弾いた時に発せられる音声を入力して周波数を正しく表示します。この表示に従って、弦毎にあるべき周波数にチューニングをすることで常に正しい音で演奏しています。このチューニングは演奏する間に必ず行うので、自宅のみならず、あらゆる場所で動作することが求められます。ここでまとめるとチューナーという器具には最低限以下の2つの要件を満足することが求められます。

• 入力した音声の周波数を正しく表示する
• 携帯性に優れている

モバイル・デバイスのアプリ（iOSアプリケ、androidアプリ；以後「モバイルアプリ」と略します）で製作したチューナーはこれらの2つの要件を満足します。チューニングに関してはマイクから入力した音の周波数を正しく表示するよく知られたアルゴリズムがありますし、携帯性に関してもチューナーアプリを一度ダウンロードしてインストールしてしまえばネットワークへの接続に左右されることなく携帯端末上で動作することが可能ですので、 場所を選ばずどこでも動作します。
前置きが長くなりましたが、ここからがこの2つの要件をどうやってWebアプリとして再現するのか？という点です。1つ目の「入力した音声の周波数を正しく表示する」に関しては、getUserMedia()を使いマイク入力をWeb Audio APIを使って周波数を割り出せばなんとか出来そうだと、とお気づきになると思います。しかしながら「携帯性に優れている」の点はいかがでしょうか？ネットワーク接続なしにどうやってWebアプリを動作させるのでしょうか？
その解決には Service Worker を使います。Webアプリを最初に起動した時に、アプリ全体をキャッシュしてしネットワーク接続のに場合はそのキャッシュを利用してアプリを動かすのです。WebアプリのチューナのService Workerの実装はココにされています。詳しい解説はここでは割愛しますが、Servive Workerインストール時（最初にサイトを表示した時と考えていただいて問題ありません）に、以下の部分でWebアプリのチューナーに必要なファイルをキャッシュしていることが分かります。

self.oninstall = function(event) {

  var urls = [

    '/',
    '/images/chrome-touch-icon-192x192.png',

    '/scripts/guitartuner-core.js',

    '/elements/audio-processor/audio-processor.html',
    '/elements/audio-visualizer/audio-visualizer.html',
    '/elements/tuning-instructions/tuning-instructions.html',
    '/elements/tuning-instructions/tick.svg',
    '/elements/tuning-instructions/up-down.svg',

    '/third_party/polymer.html',
    '/third_party/webcomponents-lite.min.js',

    '/third_party/Roboto/Roboto-100.woff2',
    '/third_party/Roboto/Roboto-300.woff2',
    '/third_party/Roboto/Roboto-400.woff2',

    '/favicon.ico',
    '/manifest.json'

  ];

  urls = urls.map(function(url) {
    return new Request(url, {credentials: 'include'});
  });

  event.waitUntil(
    caches
      .open(CACHE_NAME + '-v' + CACHE_VERSION)
      .then(function(cache) {
        return cache.addAll(urls);
      })
  );

};

もう1点は起動に関してです。Webアプリとして再現できたのに、起動がブラウザのブックマークからだったり、URLバーが表示されていては少しガッカリです。androidであれば、Webアプリであっても、ホーム画面のアイコンから起動し、URLバーを表示しないことが可能です。また起動時のデバイスの向き、スプラッシュ画面（起動処理中に表示する画像）を設定することも可能です。これを Web App Manifest と呼ばれる機能になります。Webアプリのチューナではココに実装されています。

{
  "short_name": "Guitar Tuner",
  "name": "Guitar Tuner",
  "start_url": "./?utm_source=web_app_manifest",
  "icons": [
    {
      "src": "/images/chrome-touch-icon-192x192.png",
      "sizes": "192x192",
      "type": "image/png"
    }
  ],
  "display": "standalone",
  "orientation": "portrait"
}

この数行のJSONを設置して、メインとなるHTMLには以下の1行を追加して読み込ませたらモバイルアプリと同じユーザー体験（ホーム画面からの起動）を提供することが可能になります。

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

詳細な説明は割愛してしまいましたが、こういった技術を使ってProgressive Web Appsを作ってみてはいかがでしょうか？

藍 圭介 氏

Web Audio API Creative Codingというタイトルで、moogのアナログシンセのWeb版の2D版、3D版、それ以外にもセンサーを使うことでWahペダルだったり、ライトセーバーのような動きに反応するアプリケーションも作ることが可能というデモを実施。Web Audio/MIDI以外のAPIとの親和性も高く、手軽に使えることから「Web Audio/MIDIは音楽のためのみならず、表現メディアのプラットフォームになり得る」という点をご説明してくださいました。
▶ スライド

豊島 隆志 氏

Chrome Web MIDI 2015というタイトルで発表。実際にChromeに実装をしているので、今までのWeb MIDIの実装の歴史、AndroidのWeb ViewでもOperaでもElectronでもChromeと同じようにWeb MIDIが使えるようになっていること、Firefoxでの実装状況、Web MIDI APIの使われる頻度等、APIを実装するという視点から発表をしてくれました。
▶ スライド

Joe Berkovitz 氏

Music Notation and W3C: Framing the Futureというタイトルでの発表。Audio WGの共同議長でもあり、また2015年7月にW3CでMusic Notation Community Group(楽譜に関するグループ)の立ち上げも行っており、普段はnoteflight Inc.にてブラウザ上で楽譜を表示、演奏するアプリケーションを開発しています。今回の発表では、Noteflightが実際に楽譜表示を軸にどういった機能を実装しているのか、またWeb上で表示できるようになるとどう変わるのかをデモを交えながらの発表でした。
▶ スライド(PDF)

渡邊 正和 氏

ライブパフォーマンス、その他（例えば教育）でのWeb Audio/MIDIの活用事例を紹介。Audio/MIDIがWeb上で使えることで拡がった、音楽の世界を語ってくれました。リサジューのデモも披露。

• Takashi Moriさんの演奏とのコラボ
• NETWORKSとのコラボ
• エレクトロボイスとビジュアルアート

Lightning Talk

3名、1団体からの発表がありました。

• @aklaswadさん: wani[WebAudio N Interface]のデモ
• 高橋さん：ワンセグチューナーから電波を拾ってthree.jsで電波を表示するデモ
• 小池さん：楽譜アプリのpiaScoreの説明とPlasaddがスタッフ募集している件、
• ヤマハ株式会社：MIDI、音楽系でよく使われるOSC(OpenSound Control)と、Web Socketをごちゃ混ぜのシステムでも簡単に構築できるRaspberry Piで作ったシステムの紹介がありました。

Meetupを終えて

今回Audio WGでコアに動いている方のほとんどがMeetupに足を運んでくれたこともあって、日本の皆さんにはもとより、Audio WGの皆様には「こういう使われ方もしている」という現状を見ていただけて、とてもよい機会になったと思っています。今後もこういう機会があったら企画したいと考えています。
▶ 写真等

おまけ：Web Audio、Web MIDIの進捗に関して

W3Cが定める仕様策定までの5段階のうち、Web Audio/MIDI共に、現在は1つ目の段階（WD:Working Draft）です。しかし、Web Audioは次の段階（LC:Last Call）へと進む気配があります。早くて年内、遅くとも来年4月（Web Audio Conference 2016があります）ではないでしょうか。またWeb MIDIに関してもFirefoxに実装が進んでいてMac OSでは動いているとのことですので、こちらも次の段階へ進むことへの期待ができるでしょう。

それでは、今後もWeb Musicをよろしくお願いします！

TPACとは?

TPACとは、Webの標準化団体であるW3C(World Wide Web Consortium)が開催する1週間のイベントのことです。様々な国、様々な企業からメンバーが集まり、現在のWeb標準・将来的なWebの機能(例えば、cryptoやaudio)について議論します。今回は、札幌開催であり主要なWebRTC仕様策定者が一同に日本に集結しました。

tpac 2015

最大の議論の焦点となったサイマルキャスト

WebRTCのW3C側の仕様は、まだCR(勧告候補)になっていませんが、ORTCの議論に後押しされるかたちで、既に次世代の仕様である、WebRTC-NVの議論がはじまっています。今回のTPACではWebRTC 1.0(WebRTC-NVに対して、年内に切り上げる予定のWebRTCのバージョンを1.0としている)に対して、最終的にどの仕様を盛り込むのか、が1つの争点となりました。その中でも特に議論が盛り上がったのがサイマルキャスト(Simulcast)です。TPACで展開されたサイマルキャストの議論を理解するためには、先にサイマルキャストそのものを理解する必要があります。そこで、以下でサイマルキャストとは何か、なぜ必要なのか、を簡単に説明したのち、TPACの議論を紹介します。

サイマルキャストとは？

放送業界の用語として、サイマルキャストという用語をお聞きになった方もいるかもしれませんが、WebRTCの文脈で用いられるサイマルキャストは意味合いが異なります。WebRTCで利用するサイマルキャストを一言で表現すると、「送受信側が1つの動画を、異なる品質でエンコードしたストリームを送受信すること」となります。少しわかりにくいので、以下でさらに具体的な例を利用して説明します。

サイマルキャストがなぜ必要なのか？

WebRTCの弱点として挙げられる点として、「多人数会議の実現」があります。P2P通信のみで多人数会議を実現すると、ネットワークトポロジはフルメッシュ形式となり、端末の能力・帯域に限界が来てしまい、接続数がスケールしません。それを解決するための案として、何らかのサーバを利用するスター型トポロジを利用する案があります。サーバには大きく分けて、サーバ側で音声映像を結合するMCU、音声映像を結合せずに分配するSFUがあります。（MCU/SFUの詳細は、過去記事のWebRTCにおけるサーバーソリューションの決め手とは？を参照ください）

SFUを利用した場合、受信側デバイスの処理能力・帯域が豊富にあれば良いのですが、モバイル端末の場合は常に得られるとは限りません。そこで、登場するのがサイマルキャストという概念です。

simulcast

サイマルキャストでは、上図のように送信側が複数の音声・映像ストリームを受信側に送ります。複数のストリームとは例えば、高解像度の映像と低解像度の映像といったストリームを示します。複数ストリームを受け取ったSFUは、受信側の能力に応じて、適切なストリームを分配します。処理能力・帯域に余裕のある受信側クライアントは、高品質のストリームを受信し、余裕のない受信側クライアントは、低品質のストリームを受けとります。その結果、受信側は自身の能力にあったストリームを受信できることになります。

以上が、サイマルキャストの前提知識となります。以降、TPACの議論内容・要点をまとめます。TPACで議論のベースとして用いられた資料はこちらです。

サイマルキャストを実現するために必要な機能

サイマルキャストを実現するためには、送信側のAPI(JavaScript)でまず、2つ以上のエンコードがあることを明示しなければなりません。具体的なコードサンプルは以下となります：

var sender = pc.addTransceiver({sendEncodings: [
 {rid: “F”},
 {rid: “H”, scaleResolutionDownBy: 2},
 {rid: “Q”, scaleResolutionDownBy: 4}
]).sender;

// 補足：Transceiverという名前も新規に登場しています。
// 本記事では、詳細に説明いたしませんが、簡単に言えばRTPSenderとRTPReceiverを管理する親のオブジェクトとなります。

sendEncodingsの値として、rid(暫定的な名前なため、ridという名前自体は変わる可能性があります。詳細はridが規定されるRFCを参照ください)を利用して、複数ストリームを設定しています。ridの値である”F”/”H”/”Q”は単なる識別子であり、この値はブラウザが選択するのか、それともJavaScriptで設定するのか、について議論がありましたが、最終的にJavaScript側で設定する方向で議論が進みました。

また、scaleResolutionDownbyの値によって、送信ストリームの品質を分けています。scaleResolutionDownByはconstraints(制約)と設定する一例に過ぎず、ここで設定する値についても議論がありました。具体的にはフレームレート、最大ビットレート等で十分なのでは、といった意見が出ていました。

SDPによるネゴシエーション？

従来のWebRTCでは、送受信側でコーデックなどのパラメータを、SDPを利用したシグナリングによってネゴシエーションします。ridを利用したサイマルキャストについても、自然に考えれば、同様にSDPを利用したシグナリングになります。しかし、1点問題があります。SDPで規定される内容は、W3Cで規定する仕様ではなく、IETFのMMUSIC WGで規定であるため、仕様策定に非常に時間がかかるのです。(MMUSICの仕様策定には、これまでの歴史から時間がかかるケースが多いため)

そこで、TPACでは

• MMUSIC WGで、サイマルキャスト向けの仕様策定が上手くいった場合
• MMUSIC WGで、サイマルキャスト向けの仕様策定が上手くいかなかった場合

の2点を同時に考慮する議論が進みました。具体的な方針は以下の通りです。

MMUSIC WGの仕様策定が上手くいった場合

SDPでsimulcast向けのパラメータを記載します。たとえば、以下のようになります。

// クライアント側のSDP
a=rid:F send
a=rid:H send
a=rid:Q send
a=simulcast rid:F,H,Q

// サーバ側のSDP
a=rid:F recv
a=rid:H recv
a=simulcast rid:F,H

上記でネゴシエーションされたRIDをRTP/RTCPの拡張ヘッダの値として規定して、クライアント(例：ブラウザ)とサーバ間(例：SFU)でメディアを送受信する動作になります。

メディアの送受信方法には、いくつか案があり、TPACより前に議論の候補として挙げられていたのは、RTPのヘッダに載っているPT(Payload Type)の値を利用して、ストリームを識別する案でした。しかし、その案にはペイロード番号を使いきってしまうなどの懸念(この懸念はIETFのAVTEXT WGで説明がされています)があったため、RIDをRTP/RTCPヘッダ拡張として設定する案で議論が進んでいます。

MMUSIC WGの仕様策定が上手くいかなかった場合

SDPに対する変更は加えられないため、別の方法が必要になります。具体的な方法は、アプリケーション開発者に委譲されており、開発者が任意の手段でSDP以外の方法でシグナリングすることになります。柔軟なシグナリングを必要としなければ、開発者がパラメータを事前に設定しておいて、不要なシグナリングを減らすような案も考えられます。

どちらの場合でも発生される懸念

サイマルキャスト向けのJavaScriptAPIが利用できるようになると、送信側のブラウザが複数品質のメディアストリームを送れるようになります。その際、受信側はSFUではなく、ブラウザであるケースももちろんあります。その場合、「ブラウザは受信すべきか？どう振る舞うべきか？」といった議論もありました。この振舞いの仕様自体は、WebRTC 1.0のスコープ外であり、ブラウザにおけるSimucastの受信は定義されていません。仮にブラウザが受け取ったとしても、ブラウザは単に別のストリームとして扱えばいいのではないか、といった意見が上がっていました。

その他サイマルキャストの仕様策定における重要な考え方

TPACで重要な点として述べられていたのは、「MMUSICの仕様策定が上手くいかなかっとしても、ネットワーク経路上を飛び交うメディア(RTP/RTCP)については変更を加えない」ようにするという点です。シグナリングは比較的に容易にpolyfillができるので、MMUSICが間に合わなくても、MMUSICの仕様策定が終わり、最終的に整合がとれれば良いという考え方です。

サイマルキャスト以外のトピック

以下で簡単にサイマルキャスト以外のトピックを2つほど紹介します。

IPリーク問題

WebRTCは、P2Pで通信する際にICE(RFC5245 Interactive Connectivity Establishment)という技術を活用します。ICEの内部動作としては、可能な限り接続可能性を高めるために、少しでも通信相手と接続できる可能性がある候補を全て収集します。たとえば、プライベートIP、プライベートIPからインターネットへ出ていく際に変換されるNAT後のグローバルIP、などがその候補に該当します。

接続可能性を向上させる、という意味では正常な動作なのですが、全てのIPアドレスを収集するといったその動作の特性上、ユーザのIPが外部に漏れる懸念があります。実際にNY TimesがIP収集に利用していたといった実例もあります。結果として、同じNAT配下にいるメンバが外部に漏れてしまう、ネットワークトポロジが外部に漏れてしまう、複数のアドレスが同じであることを利用して個人特定に利用される、VPN/Proxyで隠されるべきアドレスが露出してしまうといった懸念があります。これがWebRTC界隈で話題にあがっているIPリーク問題です。

TPACでは、IPリーク問題に対する対応策としてこの資料をベースに議論が実施されました。

結論のみ述べると、以下の4種類のどれかの振舞いをすることで問題を解決します。

1. 全ての候補を収集する(ただし、getUserMediaの同意があるときのみ)
2. 制限付き収集その１(ローカルはデフォルトの候補のみと、RFC1918で規定されるアドレスの候補を集める。これがデフォルトの動作になる)
3. 制限付き収集その２(ローカルの候補は無し。ただしpreferenceやextensionで設定が必要)
4. プロキシのみ(preferenceやextensionで設定が必要)

上記の[2]においては、どの程度のアドレスを集めるのか、選択肢が2つあります。選択肢の1つ目はデフォルトのホスト候補のみ、もう1つの選択肢はRFC1918の全ての候補を集めるといったものです。結論は、実際に計測実験を実施して、接続確率がどの程度低下してしまうのか、たしかめてから最終的な動作を決定する、といった結論になりました。

RtpTransceiver

新たにRtpSenderとRtpReceiverをまとめ、SDPのm=セクションをモデル化したオブジェクトとして、RtpTranceiverが追加されています。アプリケーション開発者はRtpTranceiverを利用することで、メディアストリームトラックの行き先を柔軟にコントロールできるようになります。

TPACではRtpTransceiverに関する議論がいくつかあり、例えばこれまでのWebRTCでa=recvonlyを設定するために利用していたOfferToReceiveオプションは、Tranceiver側でも制御できるようになるため削除する、などが議論に上がりました。

最後に

ここまで、TPAC WebRTC WGでの議論となった課題の背景、議論内容を紹介してきました。2日間の議論であったため、全てを本記事で紹介できたわけではありません。さらに興味のある方は、以下のアジェンダ・議事録をご覧ください。

• アジェンダ
• WebRTC WG 1日目議事録
• WebRTC WG 2日目議事録

Safari 9.0リリース

10月1日にOS X 10.11 El Capitanがリリースされ、先月のiOS版に続きOS X版のSafariも9.0になりました。

Safari 9.0ではWeb Inspectorに力がはいったようで、UIの刷新ほか既存の機能もかなり強化されています。

• Web Inspector Interface Changes
• Web Inspector Console Improvements
• Styles Sidebar Refinements in Web Inspector
• Type Profiling and Code Coverage Profiling for JavaScript
• Introducing the Rendering Frames Timeline

いくつかの機能は他のブラウザに追いついたものですが、スタイルサイドバーのMatch StylesやJavaScriptの型プロファイルはユニークですね。

また、ES6実装状況についても簡単にまとめた記事が公開されています。

• ES6 in WebKit

ここ最近になりかなり実装が進んでいますが、Default parametersやArrow Functionsなどは次のメジャーバージョンになるようですね。

Chrome 46リリース

10月13日にChrome 46がリリースされました。新しく追加された機能などはChromium Blogのエントリ…よりもChromiumベースなOperaのブログのほうが読みやすいです。

• Dev.Opera — Opera 33 released

rel=preconnect はCSSやスクリプトなどで他originのリソースを読み込む際にパフォーマンスを向上させられるかもしれません。詳しい説明や使い方は preconnect が定義されている Resource Hints仕様のEditorであるIlya Grigorikのエントリをお読みください。

DevToolsのUI変更中

そういえば、Chrome 45くらいからUIの変更を含め、DevToolsがいろいろ変わっています。こうした変更点について、Developer AdvocateのAddy Osmaniが行ったトークが公開されています。

• Addy Osmani – What’s New in Chrome DevTools – YouTube

また、先月発売されたWEB+DB PRESS 89号でもエキスパートの佐藤さんと泉水さんによるChrome DevToolsの解説記事が掲載されています。すこし先の変更（Chrome 47 Canaryでの情報をもとに執筆）とのことで、現時点のChromeと若干違うかもしれませんが、大いに参考になりそうです。

FirefoxがWebKit接頭辞つき機能のサポートを本格化

FirefoxのNightlyで、WebKitの接頭辞つき機能がサポートされ始めました。-webkit-linear-gradient、-webkit-radial-gradientといったCSSのグラデーションを始め、Element.webkitMatchesSelector()メソッドなどDOM APIにの実装も行われています。

• mozilla-inbound: pushlog ― Bug 1210575 – Add native support for parsing -webkit-linear-gradient & -webkit-radial-gradient
• Intent to implement and ship: webkitMatchesSelector – Google Groups

WebKit接頭辞なCSSのサポートですが、これまでは中国や日本の一部のサイトに限って有効にされていました。

• FirefoxのCSS Unprefixing Service – fragmentary

ただ思った以上にWebKit接頭辞のみを仕様していることなどから、やむなくすべてのサイトで有効にするようです。

こうしたマッピングをベンダー独自にやってしまうことで、新たな互換性問題を生んでしまう可能性もあります。このためMozillaのCompatibility Teamが中心となり、互換性のためのドキュメントCompatibility Standardの作業も始まっています。

また、Element.webkitMatchesSelector() についてはまとめやすさの都合からか、標準の Element.matches() エイリアスとしてDOM仕様で定義されました。ベンダー拡張だった機能の標準化はHTML、DOM、XMLHttpRequestなど多数の仕様で行われましたが、接頭辞つきの名前で仕様に定義されるのは、このメソッドが初めてかと思います。

なお、ベンダー接頭辞だけでなく、日本のWebが起こしている互換性の問題については、Compatibility TeamのKarl Dubostが以前に自身のブログに記しています。彼は今月のFirefox Developer Comferenceでも登壇し、互換性の話をしました。とてもおもしろかったので、ビデオが公開されたらチェックしてくださいね。

TPACはWebの標準化団体であるW3Cが年一回開催する全体会合です。今年はその会合がなんと、札幌で開催されます。最先端のWeb標準に関する様々な議論が日本で交わされること記念して、TPACの魅力を伝えるとともに、Web標準の今をわかりやすく紹介するイベント「Leading the way to W3C TPAC 2015」が、8月終わりに開催されました。テーマは「Webの未来の肌触りを感じよう」。

来週TPACに参加される方もそうでない方も、全ての方に改めてWeb標準に興味関心を持っていただきたいと考え、そのイベントの模様をレポートします！

はじめに

イベントはW3C Keioサイトマネージャーの中村修氏の挨拶から始まりました。

W3CとIETFの関わり

今年は、Web標準を作るW3CのTPACと、インターネットプロトコルの標準を作るIETFが、それぞれ10月と11月に日本で開催される。この2つの会議が同じ時期に同じ国で行われることは歴史的にみても初めての試みだ。例えば、Webブラウザ上でP2Pによる通信を実現するWebRTCを例にとると、関連するプロトコルの議論はIETF、APIやアーキテクチャの議論はW3Cで議論が進められており、今や両者は密接に関わっている。そのため、今回のような取り組みは非常に重要な意味を持つ。また、IETFとW3Cが作る標準は「オープン標準」であることが最も重要なこと。みんなが自由にソフトウェアを書いて、その上で同じく自由に新しいサービスを作っていけるように、そのための基盤作っていく作業をIETFとW3Cは日々やっている。そこを理解してほしい。

TPAC2015の歩き方

最初のセッションはHTML5 Experts.jpのエキスパートでもある矢倉眞隆氏による「W3Cの歩き方」です。矢倉氏は以前、W3Cメンバーであるミツエーリンクスに所属しており、そこで標準活動を積極的に行っていた経歴を持ち、2007年からほぼ毎年TPACに参加しているそうです。

W3Cの情報ってどうやって収集するの

W3Cの標準化に関する活動の様子を知る手段としては、「メーリングリスト」、「GitHub」、「F2Fミーティング」の3種類がある。中でも今はGitHubでの議論が活発。Issuesを活用し様々なトピックについて議論がなされているため、議論に加わりたい方にはオススメ。気軽にコメントやPRができる。F2Fミーティングは、各ワーキング・グループ毎にTPAC以外で、年2回以上は開催されており（グループごとに差がある）、コミュニケーションが密に取れるという意味では大変重要な役割を担っている。例えば、CSSのワーキング・グループでは、図形に関する議論が多いため、F2Fでプロジェクターを見ながら議論することで、より捗る傾向にある。

TPAC2015ではどのようなことが行われるのか

TPACはW3Cの全体会合（TECHNICAL PLENARY）、運営会議（ACミーティング）、F2Fミーティング（グループミーティング）で構成されており、年に1回実開催される。スケジュールやどのようなグループが議論を行うかは、公式サイトに掲載されている。

中でも注目は、水曜日に開催される「TECHNICAL PLENARY DAY」だ。これは、アンカンファレンス形式で進められる。TPACの参加者自身が喋りたい内容をその日の朝に出し合い、早い者勝ちで予め用意されているミニセッション枠を確保する。他の参加者たちは好きなセッションに参加可能である。これは、各グループの垣根を超えたコミュニケーションを促進することで、イノベーションを促進する狙いがある。

なぜTPACに参加するのか

標準化に関する内容は、Webで簡単に手に入る時代になった。この時代に、あえてTPACに行く理由はなにか？開発者目線のTPACは、ブラウザベンダにこのようなAPIを実装してほしい、ここの部分が使いにくいので変えてほしい等、開発者の声を積極にアピールする場になっている。また、直接あって話がしたい、発表したい、他の開発者と差を付けたいなど、野心的な想いを持った開発者も多い。

これからの標準化と開発者の関わり方

最近では、ブラウザベンダも標準をかなり意識し始めている。標準じゃないと実装しないという風潮になりつつある。そして、標準化の現場も変わりつつある。これまで標準化の場で作り出されるAPIは、開発者からの要望に基づいたハイレベル（高機能）なものが多かった。そのため、新しく出てくる様々なユースケースに対応できなかった。（対応に時間がかかっていた）今後は、様々なユースケースに短期間で対応できるように、ブラウザで扱える範囲にはなるが、比較的ローレベル（低機能）なAPIの標準化が主流になる。それを組み合わせることで、開発者は様々なユースケースに迅速に対応できる。（いわゆるExtensible Webの流れ）また、JQueryのように、ローレベルなAPIを開発者自らがラッパーしてわかりやすいAPIを定義するということが、増えてくるだろうと期待もされている。

Developer Meetup in Sapporoが開催されます！

次のセッションは、TPAC2015の開催に合わせて札幌で開催される「Developer Meetup in Sapporo」の紹介です。登壇は、このイベントをホストするNTTコミュニケーションズの本間咲来（さっくる）氏。

TPAC2015は参加条件があるため、一般の開発者が参加するにはちょっとハードルが高いイベント。そこで、TPAC2015の為に来日する海外のエキスパートと日本のエンジニアの交流の場として、TPAC2015初日（10/26）に「Developer Meetup in Sapporo」が開催されます。会場はW3Cと同じ会場。展示やトークセッション、懇親会が企画されていて通訳も用意されるそうです。まだ参加登録を受け付けているようなので、興味がある方は是非参加してみては？（参加は無料です）

また、イベント開催に合わせて、クリプトン・フューチャー・メディア株式会社主催の北海道オープンデータハッカソンが10/17に開催されました。ハッカソンの優秀者の作品はDevelopers Meetupで展示されるそうです。

※写真はイベント開催時（8月末）のものです

Eddystoneで始まるPhysical Webの世界

ここからは、ゲストスピーカーによる最新のWeb技術に関する、テクニカルセッションが続きます。

最初のセッションはリクルートテクノロジーズの加藤亮氏。加藤氏は以前当メディアで取材したPhysical Webのエキスパートです。このセッションでは、Physical Webをテーマに、Googleが7月に発表したばかりの標準規格である、Eddystoneについて解説していただきました。

Eddystoneとはなにか？

EddystoneはGoogleが7月に発表したBeacon Platformを構成するもので、ビーコンの規格。ビーコンは、フレームと呼ばれるデータを定期的にブロードキャストするもので、この規格では、ビーコンデバイスの振る舞いや、発信するパケットのフォーマットを規定している。Googleはオープン・スタンダードを提唱している。

Eddystoneには3つのフレーム（Eddystone-TLM、Eddystone-UID、Eddystone-URL）がある。Eddystone-TLMは、ビーコンの管理情報を送信するもので、バッテリ電圧や温度、起動後の経過時間、パケット送信料などを送る。重要なのは、Eddystone-UIDとEddystone-URLの方。

Eddystone-UID

Eddystone-UIDは、NamespaceとInstanceIDと呼ばれる固有IDを送信します。ビーコン受信側では、Namespaceを見て自分のサービスのビーコンかどうかを判断し、InstanceIDを利用して複数のビーコンをまたがった移動などを検知することができる。iBeacon的な用途をカバーするする、洗練されたオープン・スタンダードな仕様だといえる。

Eddystone-URL

Eddystone-URLは、Physical WebのおけるURIBeaconのことであり、NamespaceとInstanceIDの代わりにURLを送信する。小さいパケットの中にURLを載せるための工夫がなされているほか、長いURLは短縮URLを使うといった配慮が必要。これは、いわゆるPhysical Webの世界を現実のモノにするためのモノで、実験フェーズから実践フェーズへの移行を象徴付ける存在である。

Eddystone-URLはビーコンの新たなエコシステムを作る

一番の醍醐味は近接通信をサービスに活用できること。Eddystone-URLを使えば、ビーコンからBluetooth Low Energy（以下、BLE）でURLをブロードキャストできる。近くにいるスマホは、複数のビーコンから受信したURLを元にOGPなどを収集、リスト表示してユーザに提示することができる。

URLが必ずしも必要かといえばそうではなく、UIDとURLの変換テーブルをもったスマホアプリを独自に作れば同じようなことができる。これは今までのBeacon（iBeaconやEddystone-UID）のエコシステムで、独自に設置したビーコンとそれ専用のスマホアプリを配布し使ってもらうというもので、開発費もかかり、ユーザにビーコン毎に別のスマホアプリを導入してもらう必要があり、ハードルが高かった。

Eddystone-URLを利用すれば、URLという共通のフォーマットでデータのやり取りができるため、スマホには標準準拠アプリ（例えばWebブラウザ）を1つ入れておけばよく、コンテンツ提供側はビーコンとWebコンテンツを用意すればよい。これは、標準規格の上で様々なコンテンツが充実したWebのエコシステムによく似ており、ビーコンにおける新たなエコシステムと言ってもいい。今後周辺ビジネス含めて新たな競争が生まれる可能性を秘めている。つまり、Eddystone-URLはただの機能的なイノベーションの話ではなく、プラットフォームとしての意味合いが強いと言える。

すぐに使えるのか

もともとPhysical Webと言われていたこの技術であるが、7月にGoogleがBeacon Platformを正式発表したことで、実験フェーズから実践フェーズに移行したといってもいい。Eddystone-URL対応ビーコンデバイスも出始めており、既存のiBeaconでもファームウェアのアップデートで対応できるものもある。（例：Estimote）

また、Beacon Platform発表のすぐ後にChrome（最新iOS）がPhysical Webに対応した。Physical Webの機能をONにすれば受信したURLをウィジェットにリストアップすることが可能で、もちろんEddystone-URLからの情報を受けることもできる。まだ実験的な対応であることは否めないが、普及に向けた第一歩であることは間違いない。尚、本命はGoogle Nowで活用したいのではないかと考える。キラーアプリの登場が普及の鍵を握っている。

Web開発者が考えなければならないこと

サービス提供側としては、ビーコンを活用する関係でリアル・ワールドを考慮したサービス設計（UI/UXデザイン）が必要になる。例えば、スマホは基本的にはインポケットデバイスである。ビーコンの情報を受信してもユーザがスマホを見てくれなければ意味がない。ユーザが自然にスマホを見るような環境に上手くビーコンを配置したり（バス停やレストラン等）、サイネージなどと組み合わせて、歩いているユーザを立ち止まらせるような仕掛けを合わせて考えなければならない。

今後の展望

近接通信を活用したPhysical Webの普及で、WebブラウザからIoTデバイスへのダイレクトアクセスという需要が出てくる可能性がある。今でもWebBluetoothやWebNFCの議論があるが、FirefoxOSなどのWebOSで使えるようにすることが主目的となっている。今後、近接通信を前提とするWebサービスを作りたいという要望が出てくれば、純粋なWebブラウザ上のWebアプリケーションからもこれらの機能が必要となってくる。そして、これらの機能が整備されると、ビーコンにかぎらず、他の様々なIoTデバイスや近接通信機器とのIFとなり得るため、デバイスが普及した暁には、Webの大きなアドバンテージになっているはずである。

発表資料

加藤氏の発表資料はこちらで公開されているので、ぜひご覧ください。

終わりに＆次回予告

次回は加藤氏に続く3人のゲストスピーカーによるセッションの模様をお伝えします。そして、来週からはじまるTPACでの熱い議論、参加される方は現地で、参加されない方もインターネット等を通して、ぜひウォッチしてみてください！新しい発見があるかもしれません。

Chrome 45でES2015のArrow Functionsに対応

9月1日にChrome 45がリリースされました。

Chrome 45ではJavaScriptエンジンのV8が更新され、ECMAScript 2015のサポートが向上しました。新たにサポートされた機能には、関数の読みやすさ・書きやすさが上がるArrow Functionsがあります。同月リリースされたNode 4.0でもArrow Functionsが使えますし、これから見る機会が増えてくるかなと思います。

パフォーマンス改善点として、スクロール中のカーソル位置を更新しなくなったというものがありました。スクロール中に:hoverのスタイルやマウスイベントが反応すると、不必要な処理や描画が増えてしまうため、パフォーマンスが低下します。今回の変更で、IEやFirefoxとだいたい同様の挙動（スクロール停止100ms後にカーソル位置を更新）となったようです。WebKitも今年春に同様の変更を行ったようなので、今後はスクロール中にスタイルを無効にし、タイマーを仕掛けスクロール後に再適用するなんてことをしなくてもよくなりそうです。

Alliance for Open Media設立

9月1日にGoogle, Microsoft, Mozilla、ほか数社が、ロイヤリティフリーなビデオコーデックを推進するアライアンスの設立を発表しました。

• ビデオの特許使用料をなくすためのアライアンスを結成しました | Mozilla Japan ブログ

Webでのビデオコーデックというと、HTML5のvideo要素やWebRTCが求めるコーデックで激しい議論が行われた過去があります。映像・機器業界などが推し進めるコーデック（video, WebRTCともH.264）が特許使用料を求めるため、Webのオープン性との関わりから反対があるのです。

次世代コーデックとしてはHEVC（H.265）が出ていますが、新たなパテントプールHEVC Advanceがコンテンツ提供者からの使用料徴収を検討していることから、ストリーミング配信事業者から警戒されています。Alliance for Open MediaではCiscoのThor、MozillaとXiph.OrgのDaala、GoogleのVPシリーズといったビデオコーデックをはじめ、ロイヤリティフリーなフォーマットや音声コーデックを推進していくとしています。

WOFF2の圧縮アルゴリズムBrotliをサーバにも

Webフォントのフォーマット、WOFF2で採用された圧縮アルゴリズムBrotliを一般的なコンテンツの圧縮にも適用しようという動きが進んでいます。Blink, Geckoで実装が進められています。

• Introducing Brotli: a new compression algorithm for the internet – Google Open Source Blog

WOFF 1.0ではDEFLATEアルゴリズムが採用されましたが、圧縮率の点では新しいフォーマットに劣ります。WOFF2では当初LZMAなど圧縮率の高いアルゴリズムを検討していたのですが、メモリの使用量が大きいことやLZMAの仕様が存在していないことなどから、代わりのアルゴリズムとしてGoogleが開発し、そして採用されたのがBrotliです。

• WOFF 2.0 Evaluation ReportとBrotli – fragmentary

Content-Encodingでの利用によって、gzipよりもさらにbandwidthの削減を見込めます。プロキシソフトFiddlerの開発者Eric Lawrence氏がBrotliを試したところ、gzipに比べてCSSでは12％、JavaScriptでは9％の削減がみられたそうです。

FacebookやCloudFlareなども興味を示しており、今後の普及が期待されます。

iOS 9のコンテンツブロッカーに賛否

9月16日にiOS 9がリリースされました。iPhone 6sの機能も話題ですが、iOSの新機能、コンテンツブロッカーが話題となっています。

• Surfin’ Safari – Blog Archive » Introduction to WebKit Content Blockers

コンテンツブロッカーを使うアプリをインストールすると、Safariは広告とおぼしきリソースをダウンロード＆実行しなくなるため、表示時間やメモリ使用量が減るといった利点があります。反面、広告による収益が多くを占めるWebにおいて、こういったものが広まるのはWebに良い影響をもたらさないという反応もあり、なかなかに激しい議論が起こっています。

広告ブロックの是非はさておき、コンテンツブロッカーを使うアプリにはWebフォントをブロックするオプションも用意されていたりします。WebKitはWebフォントが読み込まれるまでテキストを表示しないため、回線速度やサーバーの性能、フォントファイルの容量によってはページを見られるまでに非常に時間がかかります。

コンテンツブロッカーがWebフォントをブロックできるようにしたのはそのためかと思われますが、ブロックされてしまうとアイコンフォントが読み込まれなくなります。リガチャを利用したアイコンフォントであればテキストが読めるかと思いますが、Private Use Area上のコードポイントにアイコンを設定しているフォントは問題になるでしょう。最近はSVGでのアイコンスプライトが流行っている感じがするので、アイコンフォントに問題を感じる方は試してみてはいかがでしょう。

Firefox 41でCSSの縦書きが可能に

9月22日にFirefox 41がリリースされました。

• Firefox 41リリースノート

今回のリリースでは、CSS Writing Modesの基礎部分に対応しました。writing-modeプロパティやtext-orientationプロパティが使えるようになったので、基礎的な縦書きが実現できます。

またFirefox 41では、Document.execCommand('cut')とDocument.execCommand('copy')がサポートされました。Webアプリなどでクリップボードにコピーさせたい場合、これまではFlashを使う方法が使われてきましたが、それをJavaScriptで実現できます。Chromeも春頃に対応したので結構使えそうですね。

• Flash-Free Clipboard for the Web — Mozilla Hacks
• Cut and Copy Commands — Google Web Updates

開発者ツールには、選択したノードのスクリーンショットを撮るコンテキストメニューが追加されました。これまでも開発ツールバーからコマンドを打てば特定のノードのスクリーンショットを撮れたのですが、CSSセレクタを調べなければならず面倒でした。今回右クリックというUIがついてかなり使いやすくなりました。

ノードを選び右クリックメニューにある”Screenshot Node”を選ぶだけ

今年は、Webのメモリアルイヤー。Web生誕25周年、W3C設立20周年、そして昨日アナウンスされたようにHTML5の勧告化が完了した年です。このようなメモリアルイヤーを記念し、本日（10/29）PM3時～6時（現地時間）、シリコンバレーのサンタクララマリオットホテルにてW3C20 Anniversary Symposiumが開催されます。本稿では、その模様を現地よりライブレポーティングします。

※このレポートは、小松 健作, 飯田 アレン真人, 本間 咲来の3名で共同作成しました。

Welcome and Introductions

Jeff Jaffe, W3C CEO

イベント開始は、W3CのCEOを務める Jeff氏よりウェルカムトーク。
W3Cの役割は、webのポテンシャルを広げること。webの素晴らしさ、広がりは今さら言うまでもない。Webはデバイスまで広がり、そのポテンシャルは広がる一方であることを述べました。

招待講演

Vint Cerf – A Long Term View of the World Wide Web

最初の招待講演は、TCP/IPの発明者 Vint Cert氏。WWWへの長期的な観点について述べられました。
Internetの最初のドキュメントが公開されたのは40年前。それから現在にいたるまで多くのことが変わりました。そして、我々のコミュニケーション手段のほとんどは、インターネットで行われるようになりました。
様々なメディアが現れ、消滅していきました。floppy disk, CDメディア。いずれなくなるでしょう。長きに続くメディアが必要です。優れた設計が施されたソフトウェア。更なるプライバシーの保護も重要でしょう。

David-Michel Davies – Forging the Big and Beautiful Web

1990年代のWebサイトは、ほんとにひどいものでしたが、最終的には彼らがWebを前進させてくれました。感謝しなければいけません。
フランスには、ストリートアートを飾るビルディングがありますが、それらが陳腐化するのを防ぐため、WebGLでオンライン公開することにしました。

優れたインターフェースは、人々が伝えたいことの価値を高めます。ビデオやインタラクティブにより、スクロールするだけでストーリーを語ってくれます。
人々は、様々なルールを壊してきました。大きな会社がルールを壊し始めた時、AdobeはFlashの提供を開始しました。Flashでサイトを作るのはどうかという考えもありますが、FlashはWebを大きく前進させました。ルールを壊すことで、前進が生まれるのです。

Anders Wahlquist – Stories Empower, and We Power Stories

Webの表現力は、格段に上がりました。1999年のWebは制限が強く、クリエイティブなものを提供することはできませんでした。2008年には、Flashでホラーゲームを作れるようになり、iPhoneの登場で、その役割はHTML5へと移されていきました。また現実世界とWebとの繋がりも始まりました。例えばロボットを動かすとか。
ムービーを作るために、参加者がそれを手伝うことができるようになりました。コンテンツをpushするほど、良いストーリーが作られていきます。
10年前にできなかったことが、今ではWebでできるようになりました。クリエイティビティの美しさは、技術の進化と共に変わっていきます。良いストーリー、優れたデザインには常にニーズがあり、テクノロジーはそれを支え続けるのです。

Di-Ann Eisnor – Solving Problems Together: Beyond Crowdsourcing toward Mass Participation

クラウドソーシングについて。多くの人が少しのコントリビュートを行うことで大きなことをできるようになりました。Wikipediaやmapなど。
スケールは大きく広がり、2billionのスマートフォンが、様々なデータを収集し、それらをオープンに共有することができるようになりました。
オンラインゲームで10日で得られるデータは、科学者が15年間探し続けてきたもの。50ミリオンのドライバーが地図の作成にコントリビュートし、トップコントリビューターはチームに入ることができます。
ハリケーンサンディの時も、人々の10,000に上るレスポンスから、ガスステーション情報の入手などの問題が解決されました。
各都市の自動車問題も、クラウドソーシングにより解決されていくでしょう。

Moh Haghighat – Bringing the Full Power of Modern Hardware to the Open Web Platform

JavaScriptは、本当に高速化されました。ここ数年で数百倍のパフォーマンスを示すようになり、ネイティブアプリとの違いも1.5倍程度の処理時間と、かなり接近してきました。CPUはマルチスレッド化が進んでいます。アプリケーションは並列処理に最適化されるべきです。レンダリングの33%は並列化されるようになりましたが、残りはまだ最適化の余地があります。SIMD – single instruction, multiple data。Javascriptに組み込むことでより高速化が促進されます。9-18fpsがSIMDを使うことで、30fps以上になるというデータも。Web Workerを使うことで100fps以上も可能です。
3Dカメラを使うことで、遠くのオブジェクトをフィルターし、最適化された映像処理を行うことも可能になります。
コンピュータ演算コストの高い、エッジ抽出を用いたモーション検出も可能に。モーション検出を用いたゲームも楽しむことができるようになりました。
Webは、今もっとも広範なクロスプラットフォームです。さらに、ユビキタスアプリケーションのプラットフォームになっていくことでしょう。

Alex ‘Sandy’ Pentland – Toward A Sustainable Digital Ecology

10年前に、最初のスマートフォンを用い地図上で、人々がどこに行くのか、どのレストランに行くのかをビジュアライズしました。データから、どのような生活をしているかがわかります。これは良いことですが、人々に恐れを感じさせました。政府は、それをハッピーと感じ、人々はそれから安心を得て、企業は収益を得る必要があります。
人々は、データをコントロールできなければいけません。削除可能でなくてはなりません。この機能がないと、経済は回りません。
これらのディスカッションを通し、私はp2pを活用した信頼されたネットワークというアイディアを思いつきました。クラッキングされることのない、信頼された。openPDSは認証からパスワードをなくします。”are you in california?”といったYes/No質問に答えることで。
データを集中せず、分散させることで、クラッキングの脅威を低減します。
データの分散を制御できるようになることで、子供の社会生活を向上することができます。プライベートデータは匿名化されることで共有可能となります。信頼されたネットワークを使うことで。

Commissioner Jessica Rosenworcel – Access for All

TEDのトークで、ティム・バーナーズ=リーより、Webのためにmagna cartaを作って欲しいと頼まれました。目の不自由な方が参加できるように、壁を壊さなければなりません。数週間前にスティービー・ワンダーが私を訪れました。スティービー・ワンダーは伝説的なミュージシャンというだけではなく、目の不自由な方への伝道師です。ビデオキャプションを作るためのガイドラインに関する法律を策定しました。
最大の問題は、文章を読めないこと。なので、OCRと音声合成機を用いています。彼のオフィスのスキャナーには全てOCR機能が実装されています。
ウェアブル、バーチャル・リアリティ、無人カー。グローバルスケールで、これらの技術がもたらすものについて考えなければいけません。165の国々でシンポジウムを開催しました。これはとても成功し、他国は興味を示しました。こういった活動を続ける必要があります。そして、数年後にはソリューションが得られるはずです。

Panel and Discussion: “The Future of the Web and How it is Run”

• Lee Rainie (Moderator)
• Fadi Chehadé
• Jun Murai
• Darren Walker

—

Lee

アメリカで、「Webは何を成し遂げたか？」というアンケートを取りました。生活の向上が 90%, 社会性の向上が 75%でした。
発展途上国へのインターネット普及は、更なる社会性をもたらしました。このようなチャレンジと変革のタイミングにおいて、どのようにそれを政治的に行っていくべきでしょうか？

Lee Rainie (Moderator)

Fadi

21世紀の政治システムは Web により様々なチャレンジが行われています。Web はパワフルで、我々はそれをコントロールしようとしています。もし我々が人々のパワーとWebによる拡散性を政府に認識させることを怠ったら、様々な問題が起こるでしょう。
もし、我々が価値を保ちつつそこに参加していく方法を見つけることができれば、素晴らしいWebを実現できることでしょう。
来年のThe General Asssembly of UNでは、コミュニケーションにフォーカスを置きます。
Webは人々の団結にとって最も重要な情報源として作用しています。我々は、挑戦を続けています。政府の役割を見つけるために。
さもないと、彼らは彼らの方針と司法権を行使してくるでしょう、万人共通となったときに。

Fadi Chehadé

Murai

この部屋の殆どの人はアメリカや日本などからインターネットがすでに普及している国々から来ていますが、グローバルスペース（発展途上国）へのインターネット普及を助ける責任をもっています。
グローバルスペースと、インターナショナルスペースの違いはなんでしょう？インターネットは最初にグローバルスペースを作った技術です。インターナショナルスペースで無く。

Jun Murai

Darren

私は理想郷と暗黒卿の間で、このような会話を見つけました。私からのクエスチョンは、民主化への人々の動員です。来年のUNで、我々は人々の動員についてのディスカッションを行うために何を考えなければいけないでしょうか？
市民権と人権をケアする人々はどこにいるのか？

Darren Walker

—

Lee

我々は、30ヶ国でインターネットの検閲について尋ねてきました。パキスタンだけが 100% のオープンインターネットを望みました。ほとんどの南アメリカの国々は 75% 程度でした。
インターネットの脅威と、コミュニティはいかにそれを解決しうるかをお話しいただけますでしょうか？

Fadi

インターネットのフラグメンテーション。現在部分的なフラグメンテーションは増加傾向にあり、人々の考えが伝えられていく流れを止めてしまいます。インターネット上での摩擦が多い国々はGDPが減少しており、人々の団結と経済に影響を与えています。
摩擦はISPによって起こります。かれらはコンスタントに攻撃を受け、会社は彼らの壁に囲まれたインターネットを作りたがります。我々は、法的に技術的に摩擦を削減する努力を行う必要があります。どこに摩擦が生じ、誰が責任者かを見つけ、それらと戦う必要が有ります。

Murai

フラグメンテーションは、最大の脅威です。別の脅威は透明性が無くなること。何度も人々は「インターネットは危険だ」と言い、切断すべきと言ってきました。

Darren

ポリシーと政治。我々は、最終的に人々に影響をおよぼす、これらの問題を解決する可能性を持つ構造を保有していません。科学者は課題と認識していますが、人々は、どこでこの議論をしているのか

—

Lee

人々はテクノロジーに精通していません。教育が語れることで、何が最も欠けているでしょう？

Murai

データを欲している人が誰なのかに関する誤解です。それは誰のデータなのか？所有しているのは、個人、建物、会社どれなのか。個々の産業は現在インターネットの上に存在しています。

—

Lee

人々からの期待に対し、何が最もフラストレーションを覚えますか？また、ICANで行いたい役割は何ですか？

Fadi

最も大きなフラストレーションは、ICANNがインターネットを運営していると人々が考えていることです。ICANNはとても目立つ存在です。故に、注目をあげ、収入を得ています。しかし、役割は制限されています。

他のフラストレーションは、インターネットを管轄するには、トップダウンモデルを取るしか無いと、人々が考えていることです。それは、インターネットが動いている仕組みに反抗します。
我々は、ガバナンスの他心性の上で仕事を進めています。たとえ、フランス政府がトップダウンレベルが必要であると考えたとしても。

—

Lee

人々が抱えている問題を気づかせるために、どのようにしたら良いと考えていますか？

Darren

指導は年間10億ドルの価値を、政策と戦い、民主化を推し進めることに与えられるでしょう。しかし、彼らは数十年に渡り、古い方法論を用いています。なぜなら、テクノロジーは彼らにとって脅威だからです。草の根運動の巨大なパワーは存在しますが、まだ未開発です。

—

会場より質問

マグナ・カルタなどは数百年以前のものですが、再度考慮する必要が有ります。インターネットは、境界で分割されていない共有の空間を作り上げました。

回答

2つのスタンスがあります：「政策立案者と協調的な関係を結ぶこと」と「政府が、保守的な体制をとること」です。テクノロジーによって、我々は政府を助ける必要があります。政府は敵ではありません。

—

会場より質問

我々は、インターネットを結合させるためにDNSに依存しています。しかし、それは毎年満了します。単一障害点となるのを防ぐために、より強化する必要があるのではないでしょうか？毎年お金を払うべきではないと考えます。

回答(Lee)

我々は、それの周辺で動いている金銭額がいくらになるのかを心配しています。最近のトップレベルドメインのオークションでは30ミリオンダラーを超えました。

—

会場より質問

トップレベルドメインの新しいコミュニティにより何がもたらされるとお考えですか？

回答（Fadi）

新しいトップレベルドメインには価値が芽生えるでしょう。ガバナンスへの影響として。アマゾンは、.amazon ドメインを買おうとしましたが、アマゾンの人々から嫌われました。.gay ドメインを欲する人は、全てのコミュニティにそれをさらけ出すことになります。

—

会場より質問

政府は、国家的な力を欲し、通常はそれはOKです。私は、データを何に使うかに関するコミュニティにいます。UNに行く前の文書では、それは公共のものであるべきと述べています。おそらく、我々はそれを基に進めていきます。

回答（Murai）

世界経済を考えた時、それはグローバルの課題です。インターネット上の個人を考えた時、既にグローバルです。ほとんどの国々は、世界中にマーケットを広げることで彼らの経済をのばそうとします。

回答(Fadi)

革命は、課題を帰着点で解決するためのプロセスです。これを進める際、2つの先導者がいます。一つは、世界のトッププレイヤーたち。彼らは通常、意思決定者としては参加しないことが重要です。これは良いことです。なぜなら、我々は彼らに従事することを望み、彼らは我々が Web に何を望んでいるかを聴くことができます。それ以外のサークルからは聴くことができない。もう一つの先導者は、物事をどう進めるかを決める人たち。技術面からではなく、政治家や法律家の視点より。現在我々は、これまでには見られなかったことですが、革命をボトムアップですすめている。

関連レポート

• ティムのクロージングトークが素晴らしい！「W3C20 ANNIVERSARY SYMPOSIUM」ライブレポート(2/2)

5月19日から5月21日の3日間、韓国でCSS Working GroupのFace to Face meetingが行われ、そちらにオブザーバーとして参加してきました。議題に上がったものから、いくつか取り上げてお届けします。

calc() のクセ、そのままに

CSS Values & Unitsモジュールには calc() 記法 という機能があります。記法内で四則演算ができるほか、「左右のボーダー計10pxを除きあとは100％の幅」など単位の混在も可能です。

img {
  width: calc(100% - 10px)
}

ただ calc() については少しややこしいルールがあります。+ と - を使う場合、その記号前後に空白を入れないといけないのです。これが制作者にとって紛らわしいということで、文法を調整しないかという提案がでました。しかしながらベンダー接頭辞や attr() など、他の関数表記を組み合わせた際の処理が複雑になることが懸念され、変更されないことになりました。

image() が簡略化、複数の画像はおあずけ

CSS Image Valuesモジュールには image() という機能があります。中に複数の画像を指定可能で、対応されているものをブラウザに選ばせるものです。

#cosmetic {
  background-image: image( url("photo.webp"), url("photo.jpg") ) ;
  ...
}

また、画像がない際のフォールバックとして色を指定できます。これを応用すれば、色を画像化して背景画像として利用できたりもします。

#overlay {
  background-image:
    image(rgba(255, 255, 255, .5)),
    url("photo.jpg") ;
  ...
}

image() が提案された後に、Appleが提案したものが元になった image-set() が追加されました。デバイスのピクセル密度比に応じて画像を選択させる仕組みです。

これと image() の相性がよくないことが問題となりました。image() は中に指定した画像を「順に」選ぶのに対し、image-set() は指定された画像を「並列に」扱い最適なものを選びます。「フォールバック」といっても仕組みが違うため、2つを組み合わせた際にうまく動きません。

決定として、image() 単に画像から色にフォールバックするための仕組みに機能が省略されました。画像形式をふまえたフォールバックの仕組みはLevel 4以降で独立した仕組み（fallback() が案として出ていました）を検討するとのことです。

Font LoadingがLast Callに

Font Loadingモジュールでは、Webフォントを読み込んだかどうかを取得するAPIが定義されています。

// FontFaceを定義
var hxjp = new FontFace('hxjp', 'url("http://example.com/hxjp.woff")');

// フォントを読み込み、完了したらh1に適用
hxjp.load().then(function (font) {
  document.fonts.add(font);
  document.querySelector('h1').style.fontFamily = 'hxjp';
});

今回のミーティングではAPIが依存するECMAScript 6のPromisesの状況がどうなっているかといった軽い確認のみされ、Last Callとすることが決まりました。F2Fの終了翌日の22日に、Last Call Working Draftが公開されています。

Media QueriesのオブジェクトがEventTargetに

CSSOM Viewでは window.matchMedia() という関数で、指定したメディアクエリーにマッチするかを調べられます。

var mql = window.matchMedia('(screen and max-width: 360px)');
if (mql.matches) { console.log('せまいです。') }

window.matchMedia() は MediaQueryList オブジェクトを返しますが、これにイベントリスナーも設定できます。

var mql = window.matchMedia('(screen and max-width: 360px)');
mql.addListener(function (mqlist) {
  // mqlist.matches とか使ってマッチした際の処理を書いたり
});

これが普通のイベントとどう違うのという疑問が出され、MediaQueryList が EventTarget インターフェースを継承することが決まりました。これで addEventListener でリスナーを設定できます。またシンプルに書けるよう、onchange ハンドラも定義されます。

Shadow DOM関連セレクタの名前がいろいろ変更

Scopingモジュールは、HTMLのScoped StylesheetsやShadow DOMなど、スタイルシートの適用範囲が限定される機能について、その仕組みを定義するモジュールです。

今回のF2Fでは、Shadow DOM関連のセレクタがいくつか変更されました。プロジェクトされた後のDOMツリーを選択するセレクタはこれまで ::distributed、::content でしたが、一般的すぎることから変更の提案がありました。案としては ::projected、::light-contentが上がっています。これらを制作者に尋ね、最終的な名前を決定するそうです。

また、複数のShadow Rootをまたいだツリーを選択したい際に、/deep/ というセレクタが使われるのですが、このエイリアスとして >>> というものが定義されました。さらに、これまで空白で表されていた子孫セレクタとの一貫性を鑑み >> を子孫セレクタのエイリアスとすることも決まりました。

CSSOM Viewのsubpixel precision

CSSOM/CSSOM Viewの現状共有のセッションがありましたが、気になったのがSubpixel precisionです。これまでintを返していたものをdoubleにすることにより、アニメーションなどがスムーズになるといった効果が期待されています。最近ではWebKitで作業が進められ、ナイトリービルドで有効にされています。

しかし、過去にMozillaが有効にしたところ、後方互換性を崩してしまったという報告がありました。Subpixel precisionが有効になる場合は返り値が小数となるため、整数を期待していたこれまでのコードに影響があったそうです。Internet ExplorerでもIE9時代に同様の事が起こったため一部のプロパティを除き無効にされ、オプトインで有効にする仕組みにしたそうです。

議論では、既存のAPIに手を入れるよりは新しいボックス関連のAPIを定義した方がいいのではという意見もありました。

イニシャルキャップスのプロパティ

::first-letter 擬似クラスを使い、イニシャルキャップス（ドロップキャップス）を実現するテクニックがあります。しかしベースラインやcap-heightが揃わないといった問題があります。

適切なドロップキャップの例。「É」のベースラインと3行目のベースライン、そしてcap-heightと1行目のcap-heightが揃っている

適切なイニシャルキャップスをCSSに設けられないかという議論があり、initial-letter というプロパティ がCSS Inlineに追加されました。initial-letter: 3 3 とすると、3行分の高さのドロップキャップスが、3行分落ちることになります。3 2 とすると3行分の高さですが2行しか落ちないため、頭がすこし出ちゃいます。

Latin言語圏以外のケースはどうなのだろうという議論が早速出ており、ちょうど帰りの飛行機の機内誌にドロップキャップスを使った例があったのでコメントしてみたりしました。

論理プロパティが追加

LTR/RTL混在環境などでUIをつくるとき、margin-left やmargin-top などのプロパティを使うと面倒です。また、Writing Modesなどでも面倒になるでしょう。

こうした「物理的」なプロパティではなく、direction/writing modeに沿って適切に変化する「論理的」なプロパティがあると都合がよいです。ブラウザではすでに margin-start といった論理プロパティを接頭辞付きで実装しており、UAスタイルシートなどで利用しています。

こうした背景もあり、論理プロパティは数年前にCSS WGのF2Fで話題に上がりましたが、border-*-top など物理プロパティがたくさんあり、それらに対し論理プロパティを再定義することなどに懸念が表明され、仕様に盛り込まれるのは見送られました。しかし、それ以降一部の論理プロパティが実装されたことから、仕様として盛り込まれることが決まりました。

ほかにもGrid LayoutのSubgridやFlexbox進捗、Footnoteのマークアップなど様々なトピックが話されています。そのうちまとめもCSS WGのブログに公開されると思います。