- edge撤退とこれからの姿
- 空間インターフェースの中で、これまでのブラウザ技術を基盤として、デスクトップアプリのように種々のアプリケーションを実行する姿を想像しています
- なぜブラウザを引き継ぐのか？
- 空間インターフェースのブラウザで求められるもの
- 現在から未来へ続く橋
- 空間に解き放たれたブラウザ
- 参考文献
edge撤退とこれからの姿
edge has gone away. but it is the weakest of four kings. I hope:
want safari to follow. They became the basis under cause (refs: Tactics Ogre). chrome and firefox, each one intends more native and more evolutional, will survive and accelerate web to next stage. and new one will come...page-typed browser will be once ported as same as now. but, in the process to spacial interface, it will disassemble. some elements which try to recompose current web (such as web components including web packaging, ES module, realm etc.) will become increasingly important.
by the way, 2D UI remains there. many input interfaces will replace to calling directly by voice AI agent and gesture including eye tracking, but many outputs will display on 2D UI. I saw such landscape at DENNOU-COIL.
これは、edgeが独自エンジンから撤退することを発表した時に、私がSNSに投稿した文章です。
BrokenEnglishだし、インターネットミームを使ってフザケて書いているため、ざっと言い直すと、「chromiumに統一されていくことは憂う話ではない」と言いました。
なぜなら、edge撤退は、2次元ディスプレイにおける競争だからです。ユーザーインターフェース世界は、既に空間インターフェースへの移行が始まっています。ブラウザは大きな変化をするはずです。次代の挑戦権を、もっとも進化を志向してきたchromeと、もっともネイティブを打ち出してきたfirefoxが得たと言えるし、結局のところ、空間インターフェースに標準を当てた新たなブラウザが生まれることが、必然ではないでしょうか。
chromiumに統一されていってますが、次代の空間インターフェースにおける位置付けでは、chromiumもスタート地点に立っているだけなのです。これからリソースは、空間インターフェースの開拓へ徐々に向かっていき、その中で新たに空間インターフェースに相応しいブラウザが誕生するでしょう。
本記事では、ブラウザがどう変化するのかについて、もう少し詳細にこれまで見聞きし自分の頭の中に浮かんでいるイメージを文章化してみます。後半ではブラウザがどう変わるかについて私見を述べています。
- 新しい概念を理解するために、大きなファクターだけを取り上げることにします。WebGL、WebComponents, WebPackaging, WebAssembly, ESModule, xxxWorkers, Realm, WebRTCといった個々の技術詳細は取り上げません。
- 私自身は、ブラウザ開発会社に勤めた経験もありませんし、chromiumなどのブラウザのOSS開発にコントリビュートした経験もありません。よって、既にこのような開発計画が存在している等の事実は何も知らずに書いています。
- 重要なインスピレーションの源はいくつもありますが、この記事自体は、それらをインプットに、空間インターフェースの軸から私の脳内に生まれた"繋がり"をアウトプットしているものです。例え、英語記事を探したところで、同じような話が出てくるかもしれませんし、出てこないかもしれません。
- 要は、特にエビデンスは無く、私が勝手に妄想したことが多分に含まれています。
空間インターフェースの中で、これまでのブラウザ技術を基盤として、デスクトップアプリのように種々のアプリケーションを実行する姿を想像しています
本題に入る前に、これから述べることと現在のXRアプリ開発との違いを明確にするために、現在のXRアプリ開発を整理しておきます。
中心は、各デバイスごとのネイティブアプリです。ヘッドセットでは、Unity/Unrealによるデスクトップアプリです。DirectXなどを直接操作するネイティブ開発も行われます。スマホならARkit/ARcoreを用いて、やはりUnityまたはスマホデバイスに合わせSwiftかJavaで書いたネイティブアプリとなります。
もう一つのXRアプリ開発としては、普段利用しているブラウザで、文書の代わりにWebGLを用いたVRコンテンツを埋め込みで実行するといったものになります。
この記事の対象はどちらでもありません。ブラウザ自身が空間インターフェースの中でどのような姿になるかという視点です。それは、これまでのブラウザ技術を基盤として、空間インターフェースの中でデスクトップアプリのように種々のアプリケーションを実行する姿となります。
イメージしやすい光景として、『電脳コイル』の風景を上げます。電脳コイルは、ARゴーグルが一般的になった未来世界を描いたアニメです。
教室でクラスメートの邪魔をするために、空間にブラクラのように次々とウィンドウを発生させている場面です。どんな技術かはわかりませんが、この一つ一つがwindow.openだと、頭の中で置き換えてみてください。現在ブラウザソフトで重なって納められているタブに相当するものが、ほどけて同時に表示される姿です。これが、空間インターフェースにおけるブラウザソフトになると考えています。
なぜブラウザを引き継ぐのか？
空間インターフェースに、ブラウザを引き継いでいく必要があるのか？当然のことだと考える人もいるだろうし、疑問に思う人もいるかと思います。ですので、空間インターフェースにブラウザを基盤とするアプリケーション実行環境が必要である意義を、改めて考えてみましょう。
1. 既存のインターネット資産が膨大にある
20年以上に渡り、膨大なコンテンツがインターネットに生まれてきました。空間インターフェースになっても利用できると期待することは当然でしょう。
2. 新たに作られるコンテンツも2D的な媒体で十分なものが多いのではないか（少なくとも脳波に直接送るまでは）
空間インターフェースでは音声や映像や3Dオブジェクトの存在感が大きくなるでしょう。しかし、テキストという媒体の持つ強みって意外と大きいと思っています。同じ量の文章が音声とテキストであったとして、より速く把握したり、自分のペースで進めたり、深く理解するために何度も繰り返せるのは、テキストの方に軍ぱいが上がると考えています。外国語を学ぶとはっきりします。リスニングよりリーディングの方が取り組み易いでしょう。そして、テキスト文書の共有は、ブラウザ誕生のもっとも核となるユースケースでした。
3. 誰でも任意のプログラムを公開できインストールしないで実行できる自由なweb
3つ目が、私が最も重要であると考えているものです。ブラウザとは「任意のリモートプログラムをダウンロードし実行するサンドボックス」のソフトウェアです。
あくまで基本思想の話になりますが、どんな人が作ったどんなプログラムでも、URLアドレスを持たせれば公開できるし、URLアドレスを指定すればダウンロードして実行できます。再びあくまで基本思想の話になりますが、実行環境はセキュリティ的に隔離されており、別のURLアドレスに行けば前のURLアドレスのプログラムは破棄されます。
以上のようなwebの思想をまとめたSLICEという宣言を紹介します。
Secure - All domains are sand-boxed from each other and sites are sand-boxed away from the users machine. The user can go to any site and know they are safe.
Linkable - You can point to any page or piece of content just by sharing a URL
Indexable - Because you can link to anything, if public it can be discovered by any person or machine that can index it to make it universally discoverable to everyone.
Composable - Iframes and JavaScript allow us to quickly compose and embed new sites, apps and services just by dropping in some JS and hooking things together.
Ephemeral - There is nothing to install, you go to the page and interact with it, leave the page and when you do it stops taking up resources.
（以下、意訳）
- Secure: 全てのドメインはお互いに分け隔てられ、サイトは利用端末から隔離されている。利用者はどんなサイトにも行けるし、安全であるとわかっている。
- Linkable: どんなページやコンテンツにもポインタして、URLをシェアすることができる
- Indexable: どこでもリンクできるので、どんな人なり機械なりでもコンテンツを収集することができ、ユニバーサルにコンテンツを探すための索引を作ることができる
- Composable: IframeとJavaScriptを用いれば、素早く簡単に既存のコンテンツに新しいサイト、アプリ、サービスを埋め込んで合成することができる
- Ephemeral: インストールするものは何もない。ページに行き、何か行い、ページを離れれば、リソースを解放する
私が考える空間インターフェースでのブラウザとは、この「任意のリモートプログラムをダウンロードし実行するサンドボックス」環境を受け継ぎ、新たな空間アプリケーションを作っていくための実行基盤となるものです。そのために、何が変わるだろうか、何を変えればいいのだろうかという視点に立ったものです。
過去の資産との互換性を保つためにブラウザを搭載するという目的にはあまり注意を向けていません。現行のヘッドセットに搭載されているブラウザで、もうできているからです。
空間インターフェースのブラウザで求められるもの
入力はガラッと変わる
既にいくつもヘッドセットが実用化されていますが、情報の入力源は、PCやスマホから大幅に変わっています。もちろん、バーチャルキーボードのように、旧来のUIを模倣したものも移植されていますが、補助的なものです。中心となるものは、ヘッドセットのセンサーを活かして、直感的かつ肉感的なものになっています。ブラウザのメニューやイベントなどの入力インターフェースも合わせて変えていく必要があります。
音声で入力される
スマホで始まった音声AIアシスタントは、空間インターフェースでこそ本領を発揮すると見込まれます。空間インターフェースは、6DoF（six degrees of freedom）と呼ばれるように、全天球的に広がっています。しかし、音声ならば、視覚で表現されるものではないため、空間の座標とは無縁でどこからでも応答可能になるからです。
ジェスチャーで入力される
既に空間に存在しているオブジェクトは、目線や手を用いて「直接」操作できます。タッチインターフェースよりも更にUIは進化して、掴んだり投げたりと肉感的になります。指の形や手順を組み合わせてパターン認識させることで、特定のメニュー操作のようなものもできます。キーボードで例えると、ショートカット/キーバインドに相当するものと言えるでしょう。
コントローラーから入力される
今の多くのヘッドセットデバイスは、物理コントローラーが中心になっています。特定の専門用途でもなければ、過渡期の一時的なものではないかと考えていますが、頭に入れておくべき要素です。
アウトプットはタブが解けて個別のアプリケーションになる
現在は、既存のブラウザを移植して、入力部分を調節したものとなっていますが、一時的なものだと考えています。6DoF空間に合わせて、然るべき適応が行われることが自然です。その姿は、タブの役目が無くなり同時並列的に表示されるものだと考えています。
メニューUIは一新される
現在のツールバーは無くなり、コントロールパネルは再デザインされるでしょう。一つのウィンドウとして、コンテンツ領域とセットになっている必要はあまり無いのではないかと考えています。
タブではなくてウィンドウ
本稿の中心にあるものです。現在のタブが解けて、個別のデスクトップアプリのような姿となり、同時並列的に空間に存在している姿を思い浮かべています。
6DoFに合わせたレンダリングエンジン
本稿はブラウザ自身の変化に焦点しているため、ブラウザの上で稼働するwebアプリがどのようになるかにはあまり触れませんが、windowの中でカメラやセンサーに連動した描画や3D的な立体描画する話だけでなく、6DoF空間の中でどの座標や向きでどんな範囲にどのくらいの大きさで出力するかといったコントロールも求められてきます。
現在から未来へ続く橋
空間インターフェースは突然変異的に生まれたものではありません。OSやデバイスの一つ一つの技術は、PCやスマホなどで培われた土壌から連続的に発展しています。これは、空間インターフェースにおけるwebも同じことです。そして、今も現在進行形で日々進歩しています。PC、スマホのwebから地続きに、空間インターフェースへと繋がっていく道があるのです。その現在から未来へ続く橋をまとめます。
chromiumはすでに分離されている
chromiumはマルチプロセスアーキテクチャーです。以下はchromiumのドキュメントから引用したものです。
（ https://www.chromium.org/developers/design-documents/multi-process-architecture より引用）
rendererプロセスに着目すると、タブごとにプロセスが分かれています。上記の図を、現在のPCインターフェースに置き換えた図を引用します。
（ https://developers.google.com/web/updates/2018/09/inside-browser-part1 より引用）
つまり、空間インターフェースにおいて、タブが解かれ、一つ一つのタブがデスクトップアプリとなる姿を提示しましたが、内部構造的には既に準備ができてると言えます。
タブアプリはネイティブアプリのように振る舞える
プロセスが分かれたタブ間のアプリケーションは互いに直接通信ができます。Iframeで用意されているpostMessageモデルは、WebWorkerの実装などによって更に世界が広がっています。例えば、Paul Kinlan氏のデモでは、サーバを通さずにブラウザアプリケーション同士が通信して呼応しています。
右奥はChrome Castを繋げたTVです。手前のPCからpresentationAPIを使って、TVにwebアプリを表示しています。手前のPCのブラウザでボタンを押すと、右奥のTVに出力しているアプリケーションが音を鳴らしています。異なるwindowで動いている2つのwebアプリ間で、サーバを介さずにIPC（Inter-Process Communication）で通信を行なっているデモとなります。
これができるということは、空間インターフェースにおいて、タブが解かれて一つ一つがデスクトップアプリとなったwebアプリは、SLICE原則に挙げられているSecureから逸脱しない範囲でなら、互いに通信し合うことが可能であるという話になってきます。
さらに、PWAにより、webアプリのOS統合が着々と進み、webから配布されたアプリケーションのローカル領域の生存期間が伸びています。webアプリが、他のネイティブアプリと同じように、デスクトップに存在することが可能になってきています。
しかし、より重要なことは、デスクトップに存在することよりも、デスクトップに存在することができるようになった延長として、ネイティブAPI連携やバックグラウンド実行の開拓が始まることだと考えています。WindowsやAndroidでは、PWAのストア配布が可能になっていますが、次はネイティブAPIや決済がフォーカスされています。
ServiceWorkerのバックグラウンド実行は、あまり進んでいませんが、私が聞く限りではユースケースが無いからという話でした。後述しますが、空間インターフェースでは、座標や時間などの諸条件の変化をトリガーにしたアプリ起動が重要になってくると想像しています。
この手の話では、常にセキュリティが問題になりますが、Androidでは十分に考慮した上で種々の実装が進められています。Androidでwebアプリが実現できたことは、空間インターフェースでも同じように利用できるようになるはずです。
ヘッドレスブラウザのようにruntimeとして引き継ぎつつ、UIを作り直す
既に、プロセス制御構造はある程度準備できてるとして、描画はどうするのか？空間インターフェースでは、360度どこからでもアプリケーションを覗き込めます。アプリケーションの裏側に回ることもできるのです。現在のレンダリングエンジンから6DoFに対応した描画機構が必要になるのは必然と言えます。
前項のマルチプロセスを利用して、タブを一つのアプリケーションとして扱う姿は、AndroidにおけるChrome Custom Tabs、デスクトップ向けのchromeアプリなどで形になっています。これらは、webサイト側はそのままの状態で、つまり、ブラウザからのアクセスもできる状態でありつつ、クライアント側でカスタムUIで表示する形態です。
更に一歩踏み込んでみましょう。Androidのホームスクリーンにgoogle Searchの検索ボックスだけが搭載されています。
→ 
アプリとwebを統合的に検索する機能となっており、最初のページはアプリとwebの結果が混合されています。いわば、ヘッドレスブラウザのようにバックグラウンドで通常のwebリソースを処理しつつ、UIだけをネイティブとして作り直しているようなニュアンスです。
実際には、あくまでAndroidアプリとして作られているだけでしょうが、なぜヘッドレスブラウザという話を持ち出しているかと言いますと、前述のPaul Kinlan氏が、2014年にHeadless Webというコンセプトで、siriの音声からこのようなUIを呼び出すということを提唱していたからです。当時のスライド資料を引用します。
（ https://speakerdeck.com/paulkinlan/this-is-the-web-platform から抜粋）
このように、既存のブラウザをruntimeとして使いつつ、描画パートを作り変えるようなアプローチを、6DoF空間でも行えないでしょうか？
既にブラウザ用に作られたリソースから、6DoF空間に描画する試みは行われています。HoloLensでwebVRを実行するデモを引用します。
ThreeJS also works :)
— デコシ (@Ash_Yin) March 29, 2018
It's strange to play rollercoaster on hololens.... pic.twitter.com/yvVCqsYCSp
前述のスマホの例から、インターフェースが6DoF空間に変わり、見た目は派手になりました。しかし、ネイティブとwebの2つの世界が連続して展開されている構造は同じものです。順番こそ、スマホの例はネイティブからwebに繋げるものでしたが、HoloLensの例だとwebからネイティブに繋げるという点で、逆になっていますが。
このような機能は、基本的にOSや専用ブラウザに組み込まれているものですが、HoloLensではユーザー向けに解放している実験PJがあります。HoloJSというPJで、その構成を私のスライド資料から引用します。
ブラウザ用にWebGLで作られているソースを、ブラウザからネイティブアプリへ投げ、アプリ内でWebGLからOpenGLへディスパッチして、ネイティブのレンダリングエンジンに繋げるという構造になっています。ブラウザにはあまり手を入れず、ブラウザからソースを取得して、6DoF空間で改めて描画し直すというブリッジ形式です。
WebXR device APIによりブラウザアプリケーションのまま6DoF空間に展開する
現在のヘッドセットにおけるブラウザから6DoF空間に展開する実装形態は、種々のアプローチがあります。しかし、ほとんどはブラウザから展開すると一つのアプリケーションとして空間を専有する形になります。没入感を高めるために故意にやっているところもあるでしょうが、複数のアプリケーションを並行実施することができません。また、基本的に片道切符となり、何らかのフィードバックをブラウザに返すことが大幅に制限されます。
わざわざネイティブ空間に展開せずに、ブラウザのままで6DoF空間への展開を行いたいところです。6DoF空間への描画はもちろん、カメラや音声やジェスチャーによる入力もできる形で。
既に、そのような目的で、WebXR Device APIの策定が始まっています。HoloLensやMagic Leapに搭載されるブラウザもそれぞれ独自に実装が行われていますが、こちらはweb標準の規格になります。
WebXR Device APIは、XRに必要なブラウザのセンサー入出力のハンドリングや描画のAPI仕様を定めるものです。ヘッドセットだけでなく、ARcore/ARkitなどを媒介にしたPCやスマホも対象になっていますが、スペック策定のターゲットが6DoF空間であることが冒頭に謳われています。
WebXR Device APIが実装されたブラウザのイメージを説明します。デバイスが、カメラ映像や音声や目線や体の動きをキャッチして、ブラウザに上げます。ブラウザのレンダリングでは、カメラが捉えたリアルワールドの映像にCG(computer graphic)を重ねられるようにレイヤーが定められ、デバイスの向きと位置を判定し、グラフィカルフレームを生成して描画します。
これは、ブラウザ自身が搭載するものであることが重要です。タブが解けて、空間に同時並列的に存在する各個のwebアプリは、それぞれ6DoF空間でインタラクティブに入出力ができるようになるのです。
Missing Parts
以上、いくつかの観点から、既に現在のwebから空間インターフェースへ繋がっていく橋が着々と架かりつつあることを説明してきました。しかし、現在では欠けているパーツがあります。
私が考える最も欠けているパーツは、起動方法をwebアプリ側で指定できることです。6DoF空間では、全天球的に描画できるスペースが広がります。 だからこそ、6DoFという訳ですが、タブが解き放たれたとしても、広大な空間でどこに設置したらいいのか？また、その大きさや形状はどう規定されるのか？
もちろん、トリガー側で新しく起動するwindowの大きさや位置を指定することは比較的容易です。例えば、既に起動しているwebページでwindow.openするときに、大きさや形状を指定できるように。または、PWAのように、デスクトップにインストールしてmanifestで起動方法を指定するような方法です。
しかし、空間インターフェースでは、音声によるAIアシスタントがUIの統合コントロール機関になっていくと想定されます。音声AIだけでなく、特定の位置や時間やその他センサーやネットワークなどからの取得情報によりトリガーされることもニーズとして出てくるでしょう。
そうなると、理想はwebアプリ側で起動方法を指定できることです。例えば、私たちが音声AIに対して、とあるwebアプリを要求すると、音声AIアシスタントが、webサーバにリソースを取りに行きます。そのリソースの中に起動方法が含まれているような形式です。webサーバ側は、UserAgentのような方式で、6DoF空間からのリクエストを判定して、6DoF空間用のリソースを返すような形になるでしょう。それならば、音声AIアシスタントは、取得した起動方法をもとに、タブアプリを6DoF空間に描画すればいいわけです。現在のchromiumのブラウザプロセスが、音声AIアシスタントに組み込まれた姿とも言えるでしょうか。
これが実現すると、6DoF空間には、個々のwebアプリをインストールしないで利用できるようになります。「任意のリモートプログラムをダウンロードし実行するサンドボックス」環境を受け継ぎ、新たな空間アプリケーションを作っていくための実行基盤としての空間インターフェースのブラウザが実現した姿だと考えます。
空間に解き放たれたブラウザ
冒頭に戻ります。chromiumに統一されていくことは憂う話ではなく、そのchromiumですら空間インターフェースへの移行という文脈では、スタート地点に立っているだけだと言いました。そして、空間インターフェースのブラウザの姿を述べました。そこでは、chromiumが最右翼に位置していること、私が想像していることは実現可能性が十分にあるものであることを、現在から未来へと続く橋で説明しました。では、ブラウザが本当にその姿になったら、どんな世界になるのでしょうか？
これは、空間インターフェースの未来世界をイメージして製作されたイメージビデオです。リアルワールドにCGが溶け込み、コンピューター世界との境目が無くなった姿です。FPSのアングルで進むと、様々なアプリケーションが登場します。ゲーム、メッセージング、ユーティリティツール、建物や器具に絶対座標やマーカーで備え付けられているアプリケーション。起動方法も様々です。操作者が明示的に呼び出すもの、ネットワーク側からプッシュされて呼び出されるもの、現実物体側に付随している情報から呼び出されるもの、位置情報や時間などの特定条件の変化を検知して呼び出されるもの。
ブラウザが空間に解き放たれると、このビデオに登場する多くのアプリケーションが、webアプリとして提供されることになると考えています。これらを事前に私たちが身に着けるデバイスにインストールしておかないといけないと考えることの方が、非現実的ではないでしょうか。一体、どれだけのアプリケーションのインストールが必要になるのでしょうか！
「任意のリモートプログラムをダウンロードし実行するサンドボックス」環境を受け継ぎ、新たな空間アプリケーションを作っていくための実行基盤が必要なのです。その役目は、これまで述べてきたように、空間インターフェースに解き放たれたブラウザが担うことが、これまで築いてきた技術的基盤から最も地続きに未来へ繋がっている道だと考えています。
参考文献
最後に、本稿にあたり、多きく影響を受けた参考文献を挙げておきます。
Paul Kinlan氏
最もインスピレーションを受けています。空間は対象にしていませんが（確認してる限りは）、スマホというモバイルインターフェースに対して行なっている思考やR&Dは、空間インターフェースを考えるにあたっても確実に糧になるものです。本稿でも、SLICE、HeadlessWeb、window間の通信を取り上げました。私はあまり知りませんでしたが、WebIntentをリードしていたそうです。なお、2018年6月に来日してchrome tech talk nightで登壇されていて、window間のデモを披露されていました。ハッシュタグ#chromejp でもその様子を追えます。
SLICEについての記事
クライアントのwindow間の通信
Helio
magic leapというヘッドデバイス専用のchromiumベースで作られているブラウザです。ヘッドセット専用のブラウザというところが重要で、空間インターフェースのブラウザの現在進行形を探る最前線にいると認識しています。webに対するアプローチとしても、spatialとかunflatといった用語が続々と登場します。2019年1月13日に東京でMagicLeapMeetupが開催されて"The Spetialized Web"（空間化されたウェブ）というセッションが行われました。
他にもFirefox Reality/chrome VRも欠かせないでしょう。それぞれヘッドセットをターゲットにして開発されています。
WebXR Device API
6DoF空間をターゲットにして、カメラや音声やセンサーのインターフェース、レンダリング方式などのスペックを策定しています。
