🎄本エントリは『WebXR』をテーマにしたアドベントカレンダー『WebXR ( WebVR/WebAR ) Advent Calendar 2021』の初日 Day 1 を飾るエントリです。

whoami

@ikkou a.k.a HEAVEN chan です。長らく WebXR 周辺の動向を追っていて、定期的に WebXR に関する『現状確認』エントリを投下しています。

本エントリでは『現状確認 2021 Summer』から少しだけ経過した『現状確認 2021 Winter』として 2021-12-01 JST 現在 の WebXR 全般に触れていきますが「個々の詳細」には触れません。また、具体的なコンテンツの動向にも触れません。それらは Day 2 以降で触れられていくことでしょう。本エントリを読めば WebXR の現状が概ね理解できることを目的としています。

Update 2021 Summer to Winter

手っ取り早く『WebXR ( WebVR/WebAR ) の現状確認 2021 Summer』から『Winter』への差分のみを知りたい方はこのパートをご覧ください。

期待されていた iOS 15 に WebXR Device API は適用されなかった👎
WebXR Device API 関連 Module/API のステータス更新👍
- WebXR Gamepads Module - Level 1 のステータスが Editor’s Draft から Working Draft になった
- WebXR Augmented Reality Module - Level 1 のステータスが Editor’s Draft から Working Draft になった
- WebXR Hit Test Module のステータスが Editor’s Draft から Working Draft になった
- WebXR Layers API Level 1 のステータスが Editor’s Draft から Working Draft になった
- WebXR Hand Input Module - Level 1 のステータスが Editor’s Draft から Working Draft になった
- WebXR Depth Sensing Module のステータスが Editor’s Draft から Working Draft になった
- WebXR Lighting Estimation API Level 1 のステータスが Editor’s Draft から Working Draft になった
WebXR Device API に対応している XR 関連デバイスが増加👍
- VIVE Flow が Firefox Reality で対応
- コンシューマー版 Nreal Light が Nebula のアップデートで対応

WebXR とはなにか?

Source. https://immersive-web.github.io/webxr-samples/

はじめに、本エントリにおける各用語の定義は次の通りです。
御託は良いから現状を、という方は次のパートにスキップしてください。

XR の定義

XR は特に次のような ◯◯ Reality 全般を包括する言葉です。
どこかの企業や団体が『標準仕様』を策定しているわけではありません。

VR(Virtual Reality) = 人工現実感(仮想現実)
AR(Augmented Reality) = 拡張現実感(拡張現実)
MR(Mixed Reality) = 複合現実感(複合現実)

三者三様の定義が発生しがちな MR の解釈次第では ◯◯ Reality 全般を包括する言葉は MR になるかもしれませんが、現時点では XR と呼ばれています。

表記として小文字はじまりの xR と、大文字はじまりの XR がありますが、昨今では、VR/AR/MR カンファレンスの「XR Kaigi」然り、Unityの「XR Interaction Toolkit」然り、大文字はじまりの XR 表記が一般的です。

ちなみに、大文字はじまりになる要因として、英語圏では sentence case により文頭が大文字になる、あるいは固有名詞は文頭が大文字になる、といった事情が考えられますが、確証はありません。

WebXR の定義

XR 同様に、WebXR もまた WebXR そのものを定める『標準仕様』はありません。
本エントリでは WebXR を次のように定義しています。

ブラウザ ( WebView を含む) を通した VR 体験を WebVR、同 AR 体験を WebAR と定義し、それらの総称を WebXR と定義する
上記を満たしていれば WebXR に関連する WebXR Device API の使用有無は問わない

WebVR とは

WebVR は VR に相当する表現・体験をブラウザを通して実現できるものです。

数年前までは例えば Google Cardboard のようなビューアーとスマートフォンを組み合わせるものが主流でしたが、Oculus Quest が WebVR に対応したことにより、現在は画質を始めとして体験の質が大きく向上しています。

まだ 1 度も WebVR を体験したことがない方は、お手元の PC やスマートフォンで下記のリンクから『Mozilla Hubs』にアクセスしてみてください。Oculus Quest をお持ちであれば、よりリッチな体験が可能です。

https://hubs.mozilla.com/

WebAR とは

WebAR は AR に相当する表現・体験をブラウザを通して実現できるものです。

AR はカメラを通して現実世界になにかを重畳させることが多く、その場合はスマートフォンを用いる「ビデオシースルー方式」か、HoloLens 2 や Nreal Light のような AR/MR デバイスを用いる「光学シースルー方式」となります。

今日現在、WebAR は WebVR に比べると体験する機会が多くあります！

まだ 1 度も WebAR を体験したことがない方で、iPhone や iPad といった iOS/iPadOS デバイスをお使いの方は Apple 公式の『Quick Lookギャラリー』にアクセスしてみてください。

このサイトでは iOS/iPadOS デバイス特有の USDZ による WebAR を体験できます。

Google 公式の Pixel シリーズを始めとして、Xperia や Galaxy などの Android デバイスをお使いの方は、Google 公式の『WebXR Experiments』にアクセスしてみてください。

このサイトでは Google による WebAR コンテンツを体験できます。

ただしこのページで体験できるのは ARCore に対応した端末をお持ちの方のみです。

詳細は後述しますが、これは WebXR Device API を使用しているためなので、現時点で WebXR Device API に対応していない iOS/iPadOS デバイスをお使いの方も体験できません。

もしも ARCore に対応していない Android デバイスをお使いの方は、具体的なサービスイメージを想像しやすい AR カメラサービスの『TOBIRA』を試してみてください。

https://tobira.me/

AR の 3 種別

AR は次の 3 種別に大きく分けられます。この種類によっても WebAR での実現方法が異なります。

空間に表示するだけなどマーカーを必要としない『マーカーレスAR』
二次元バーコードや画像など何らかのマーカーを必要とする『マーカーベースAR』
位置情報をトリガーとする『ロケーションベースAR』

WebMR は無いのか

WebVR、WebAR があって WebMR は無いのか気になる方がいるかもしれませんが、一般的な言葉として WebMR が用いられていることはありません。

後述する WebXR Device API は Web Mixed Reality 相当の表現も含めて XR と定義しています。

WebVR、WebAR の表記について

ときに WebVR は半角スペースありの Web VR として、WebAR は Web AR や web AR といった表記を見かけることもありますが、本エントリでは半角スペース無しの WebVR と WebAR という表記に統一しています。

また、『ブラウザAR®』という表記が見られることもありますが、これは®マークがついていることからもわかる通り、クラウドサーカス株式会社さんの登録商標となっています。ちなみに『ブラウザVR』や『ブラウザXR』は商標として登録されていません。

WebXR を構成する要素技術

WebXR は XR という特性はあるものの、WebXR を構成する要素技術は Web を構成する要素技術と変わらず、HTML、CSS、JavaScript、画像や 3D モデルなどの Assets、Backend といった要素技術が必要となります。特に描画まわりで必須となる JavaScript は重要な要素を占めています。

また、WebXR コンテンツの公開に際して HTTPS が求められることが多いことから、少なからず Backend の知識も必要となります。

例えば、もしも Hubs Cloud に手を入れようと考えているなら、AWS (Amazon Web Services) や、Reticulum で使われている Elixir/Phoenix の知識も必要となります。

XR コンテンツの開発では Unity や Unreal Engine などのゲームエンジンを用いる印象が強いかと思いますが、WebXR に関してはいわゆる『ウェブフロントエンドエンジニア』の領域となります。

しかしながら高度な開発がスキルを必要とせず、例えばソースコードをコピペしてブラウザで表示するだけでも動作するのが WebXR の良いところです。ビルドやコンパイルも必要ありません。ソースコードを書き換えてリロードすればコンテンツも更新されます。もちろんネイティブアプリに劣る部分もありますが、取っ掛かりの良さは XR コンテンツ開発の中でも一番です！

`WebXR Device API` とはなにか?

ここから本編です。

まずは WebXR を語る上で絶対に欠かせないが、本エントリの定義によれば必須要素ではない WebXR Device API の現状です。

なお、本エントリで語られていることの多くの原典は WebXR Device API を策定している W3C Immersive Web Working and Community Groups が運営している『Immersive Web Developer』です。

https://immersiveweb.dev/

改めて `WebXR Device API` とはなにか?

WebXR Device API は、VR、AR、MR といった XR デバイスの「向き」や「動き」などの「状態」をブラウザから取得する JavaScript API です。とても重要なことですが、この WebXR Device API そのものが WebXR コンテンツを形作っているわけではありません。

https://www.w3.org/TR/webxr/

例えば、カメラ越しに 3D モデルを表示する場合、3D モデルは Blender 等々で別途作成し、カメラ経由での映像取得は MediaDevices.getUserMedia() が、3D モデルの描画には WebGL といった JavaScript API が担っています。

ウェブの進化とともに、ブラウザ経由で USB デバイスにアクセスする WebUSB API や、Bluetooth デバイスにアクセスする Web Bluetooth など、ブラウザから直接ハードウェアにアクセスする API が生まれていますが、WebXR Device API もそういったもののひとつです。

繰り返しになりますが、WebXR Device API そのものが WebXR コンテンツを形作るわけではないので、WebXR コンテンツは、WebXR Device API を使うものと WebXR Device API を使わないものの 2 つに大別できます。

`WebXR Device API` を策定している Immersive Web Working Group

大前提として Web の仕様の多くは W3C が策定しています。その上で各 API の仕様は専用の Working Group (WG) が策定していて、WebXR Device API は Immersive Web Working Group が策定に向けた議論を重ねています。

Immersive Web Working Group の Co-Chairs は 2020/06/10 から

Samsung の Ada Rose Cannon (@adarosecannon) さん
Microsoft の Ayşegül Yönet (@ayssomething) さん
Google の Chris Wilson (@cwilso) さん

という 3 名体制で構成されています。

そして W3C 本体からは Atsushi Shimono a.k.a @himorin さんが参画しています。

この WG の概要は『Immersive Web Working Group Charter』にまとまっています。

W3C の勧告プロセス

各 WG で議論された API が勧告、平たく言うと「これで決まり！」という状態に至るには次のプロセスを踏む必要があります。

Editor’s Draft
Working Draft (WD)
Candidate Recommendation (CR)
Proposed Recommendation (PR)
W3C Recommendation (REC)

2021-10-26 現在 WebXR Device API のステータスは Working Draft です。

W3C Recommendation に至るためには、仕様策定だけではなく 一定数以上のブラウザ側の実装も必要 となり、双方が共に歩んでいく形になります。こうした背景もあり、Working Group には各ブラウザベンダーの方が参画しています。

WebXR のロゴについて

WebXR Sample Pages や WebXR Device API 関連の Spec でも見かける機会の多い WebXR のロゴですが、これは Deigo Gonzalez 氏によって提案されたものです。

Immersive Web WG の ML にもログが残っています。

当時はくるくるまわる WebXR のロゴも用意されていました。

https://toji.github.io/webxr-logo/

`WebXR Device API` 関連 Module/API

WebXR Device API とは別に、次に挙げるような WebXR Device API に関連するモジュールや API の策定も進められています。そもそも WebXR Device API それ単体では基本的なデータの取得しかできないため、関連するモジュールや API の実装も重要になってきます。

Gamepad API の拡張となる WebXR Gamepads Module - Level 1 (WD)
- 2021 Summer 時点では Editor’s Draft でしたが、2021-08-24 時点で WD になっています。
WebVR 2.0 時点では WebXR Device API と一緒だったがモジュール化にあたり AR 要素を抜き出した WebXR Augmented Reality Module - Level 1 (WD)
- 2021 Summer 時点では Editor’s Draft でしたが、2021-08-24 時点で WD になっています。ただし、Unstable API の注釈表記ありです。
WebXR コンテンツ上に DOM エレメントを配置するための The WebXR DOM Overlays Module (Editor’s Draft)
現実空間の平面にオブジェクトを置くための WebXR Hit Test Module (WD)
- 2021 Summer 時点では Editor’s Draft でしたが、2021-08-31 時点で WD になっています。
描画系を向上させる WebXR Layers API Level 1 (WD)
- 2021 Summer 時点では Editor’s Draft でしたが、2021-08-24 時点で WD になっています。
WebXR でハンドトラッキングを実現する WebXR Hand Input Module - Level 1 (WD)
- 2021 Summer 時点では Editor’s Draft でしたが、2021-08-24 時点で WD になっています。
深度情報を取得することでオクルージョンなどに利用できる WebXR Depth Sensing Module (WD)
- 2021 Summer 時点では Editor’s Draft でしたが、2021-08-31 時点で WD になっています。
アンカーを打てるようにする WebXR Anchors Module (Editor’s Draft)
環境光を推定する WebXR Lighting Estimation API Level 1 (WD)
- 2021 Summer 時点では未掲載でしたが、2021-09-09 時点で WD になっています。
MediaDevices.getUserMedia() なしに平面の情報を検出できる WebXR Plane Detection Module (Draft Community Group)

WebXR Device API のハードウェア・ブラウザそれぞれの実装状況もバラバラな状況でありながら、これらの関連 Module/API の追加やアップデートまで追いかけようとするとかなり大変ですが、W3C メンバーである @himorin さんが独自に編纂している『List of specifications in Immersive Web Working/Community Group』で各仕様の状況がひと目で確認できるようになっています。

`WebXR Device API` の前身にあたる `WebVR API` について

いわゆる VR 元年と叫ばれた 2016 年前後 ( もう 5 年も前! ) に WebVR に触れ、その後それっきりの方の中には、もしかすると「今は WebXR Device API なのか、ところで当時触ったことのある WebVR API はどうなった?」という疑問をお持ちの方がいるかもしれません。

かつては Oculus Rift CV1 や HTC VIVE などの VR HMD のみを対象にした WebVR API の策定が進められていました。しかし時代の流れとともに取り扱うものの対象に AR デバイスや MR デバイスも加わることとなり、2017-12-12 を以て deprecated つまり非推奨 となり WebVR API の策定は停止して WebXR Device API に引き継がれています。

deprecated 化に伴い、現時点で WebVR API をサポートしているモダンブラウザは Firefox のみとなっています。数年のときを経て当時 WebVR API を使用していた WebVR コンテンツを今改めて体験したい、という稀有な場合は Firefox を使用してください。

`WebXR Device API` に対応している XR 関連デバイス

VR HMD のみを対象としていた WebVR API から、AR、MR デバイスも対象とした WebXR Device API に変わったことで、対象となる XR 関連デバイスも変わりました。

WebXR Device API の検討が始まった 当時の Target hardware は次の通りです。

ARCore-compatible devices
Google Daydream
HTC Vive
Magic Leap One
Microsoft Hololens
Oculus Rift
Samsung Gear VR
Windows Mixed Reality headsets

時が経ち XR 関連ハードウェアも大きく変化しました。
2021-12-01 現在の主要な XR デバイスの対応状況は次の通りです。

ARCore 対応デバイス
- 既に発売されている Pixel 6 が掲載されていないなど、更新が追いついていないこともありますが、原則として ARCore 対応デバイス = WebXR Device API 対応 Android デバイスと捉えて問題ありません。
~~Google Daydream~~ (discontinued)
- Google Daydream はまさに白昼夢として儚く消え、2020-09 にリリースされた Android 11 でサポートが打ち切られました。
HTC VIVE
- 当時に比べて VIVE Focus や VIVE Cosmos、そして最新版の VIVE Flow など様々な派生デバイスが生まれましたが、引き続き対応しています。
- VIVE Flow での対応については 12/03 にやのせんさんが公開してくれました。
  - 「VIVE FlowでWebXR」について手短に
Magic Leap 1
- この数年で、名称が Magic Leap One から Magic Leap 1 に変わる、NTTドコモが資本・業務提携を結びドコモオンラインショップで取り扱いが始まる、Magic Leap Japan が生まれる、といった動きがありましたが、独自 OS である Lumin OS 0.98.20 は引き続き WebXR Device API をサポートしています。
~~HoloLens~~ ( WebVR API にのみ対応 )
- 初代 HoloLens は WebVR API には対応していましたが、WebXR Device API には対応していません。
HoloLens 2
- 当初は初代 HoloLens 同様 WebVR API のみの対応に留まっていましたが、現在は HoloLens 向けの Firefox Reality または HoloLens 2 の標準ブラウザである Edge 91 以降で WebXR Device API に対応しています。
~~Oculus Rift~~ (discontinued)
- PC 接続型の最終版にあたる Oculus Rift S はディスコンとなりましたが、内蔵されている Oculus Browser のバージョン次第では WebXR Device API が動作します。
~~Samsung Gear VR~~ (discontinued)
Windows Mixed Reality Headset
- もはや HP Reverb G2 くらいしか残っていない雰囲気の漂う Windows Mixed Reality Headset シリーズですが、内蔵ブラウザは Edge なので動作するようです。
  残念ながら筆者は未検証です。
Meta Quest 2
- 当時存在していなかったスタンドアロン型 VR HMD であり、特に WebXR Device API を用いた WebVR コンテンツの開発にもっとも有用なデバイスは Oculus Quest 2 改め Meta Quest 2 であると筆者は考えています。
- 内蔵している Oculus Browser は 2019 年末時点で WebXR Device API に対応し、現在は WebXR Device API の拡張モジュールであり「指を認識する」 WebXR Hand Input Module にも対応しています。
Nreal Light (エンリアルライト)
- 当時存在していなかったメガネ型デバイスの筆頭と言えば Nreal Light が挙げられますが、開発者向けのスマートフォンを必要としない Dev Kit ではなく、スマートフォンを必要とするコンシューマー版で使用する Android アプリの Nebula は WebXR Device API に対応しています。
  - Ref. FarePlay for NReal Release v0.50 is out. We got WebXR

`WebXR Device API` に対応している主要ブラウザ

Source. https://caniuse.com/webxr

Can I use... に掲載されている、主要ブラウザにおける WebXR Device API の状況です。

Edge / Chrome

Chromium エンジンを搭載した最新版の Edge と Chrome は WebXR Device API に標準対応しています。以前は chrome://flags で設定の変更が必要でしたが、現在は設定項目そのものが存在していません。

ところで Can I use... は仕様が確定すると緑色の背景色になりますが、標準対応している Edge / Chrome は緑色にはなっていません。これはブラウザ側は標準対応しているが、仕様の策定が道半ばであることを示しています。

This API is very extensive. Many of its features are still in development and/or don't have finalised specs yet.

現在は解消されていますが、一時期、特定の組み合わせで動作しない現象が起こりました。緑色にならない内は今後もこういったことが起こらないとは言い切れません。

Firefox

Gecko エンジンを搭載した Firefox は標準対応していないため、ユーザー自ら about:config で dom.vr.webxr.enabled を false から true に変更する必要があります。

これは Preview バージョンの Firefox Nightly でも同様です。

Firefox Reality

特定の XR 関連デバイス向けにリリースされている WedXR に最適化されたブラウザアプリ Firefox Reality であれば、同じ Firefox でも about:config から設定を変更することなく WebXR Device API に対応したコンテンツを体験できます。

HTC Viveport に対応しているので、VIVE 系統の最新デバイスである VIVE Flow も WebXR に対応する形になります。

Safari

Webkit エンジンの Safari は引き続き In Development ステータスです。

Source. https://webkit.org/status/#specification-webxr

Firefox と異なり、iOS/iPadOS の最新版では『設定項目自身が存在しない』ため、現時点で動作させる術はありません。

代替手段として、iOS には Mozilla による WebXR Viewer アプリによって WebView で WebXR Device API を Active にできます。

このアプリを使っても VR に向いていない iPhone 単体での WebVR は体験できませんが、例えば WebXR Samples の Immersive AR Session で実際に体験できます。

なかなか実装される気配の見えない Safari に対して思うこと

NDA の関係で詳細は伏せますが、15 Beta 時点ではちょっと期待したものの、結局 WebXR Device API は実装されないまま iOS 15 がリリースされました。

WebKit Bugzilla には [WebXR] Implement WebXR device API というチケットがあり、依存するチケットが 2 つ残されたまま半ば放置されているように見えますが、真相はいかに……。

これは半ば愚痴ですが、決してウェブ標準とは言えないような HTML <model> element を Experimental Features の 1 つとして実装するくらいなら、Experimental Features 扱いで構わないから先に WebXR Device API を実装して欲しかったと思うのは筆者だけでしょうか?

実際のところ WebXR Device API “にだけ” 対応してもあまり意味がないので、関連 Module/API も含めての実装という形が望ましいですが……。

Oculus Browser

前述の通り Oculus Browser は Meta Quest 2 に内蔵されている標準ブラウザです。いわゆる主要ブラウザのひとつとして数えられるブラウザではありませんが、WebXR を嗜むものにとって Meta Quest 2 は最高のデバイスです。

`WebXR Device API` 関連 Module/API の対応状況

caniuse だけでは WebXR Device API 関連 Module/API の状況がわからないので、そういったときは Immersive Web Developer の Support Table for the WebXR Device API を参照してください。ただし、必ずしも最新の情報が掲載されているとは言い切れないので、ときには自分自身で検証する必要があります。

WebXR コンテンツに `WebXR Device API` は必要なのか?

繰り返しになりますが、本エントリでは WebXR を次のように定義しています。

ブラウザ ( WebView を含む) を通した VR 体験を WebVR、同 AR 体験を WebAR と定義し、それらの総称を WebXR と定義する
上記を満たしていれば WebXR に関連する WebXR Device API の使用有無は問わない

この定義に拠れば『WebXR コンテンツに WebXR Device API は必須要件ではない』です。

世の中には WebXR Device API を使っていない WebXR コンテンツはたくさんありますし、特にスマートフォン向け WebAR コンテンツの場合は WebXR Device API 抜きでも成立するのが数多くあります。

対して VR HMD を使う WebVR コンテンツの場合は WebXR Device API を使うことでコントローラーはもちろん、ユーザー自身の「手」をコントローラーにする「ハンドコントローラー」にも対応できるため、 WebXR Device API を使うと、各ハードウェアプラットフォーム間の差分を吸収した「ウェブ」という共通プラットフォームにおいてワンソース・マルチユースを実現する可能性があります。

ただし、現時点で WebXR Device API はまだ『策定中の仕様』であり、不安定なものである ことを意識する必要があります。

また、先ほど例として挙げた「ハンドコントローラー」に関しても、WebXR Device API を使わずとも、例えば後ほど紹介する MediaPipe を始めとする JavaScript ライブラリやフレームワークでも吸収できるので、十分な検討が必要です。

WebXR コンテンツの開発方法

WebXR コンテンツの開発方法として次のパターンが挙げられます。

WebXR Device API をフルスクラッチで書く (Vanilla JS)
WebXR コンテンツの開発に向いている JavaScript ライブラリ、フレームワークを用いる
ゲームエンジンを用いる
ブラウザベースの開発ツールを用いる

WebXR コンテンツの開発方法について、それぞれの「詳細」や「具体的なソースコードの書き方」には触れませんが、個々の概要について説明します。

`WebXR Device API` をフルスクラッチで書く (Vanilla JS)

Vanilla JS こと素の JavaScript をフルスクラッチでゴリゴリ書く方法です。

WebXR Samples のソースコードを参考にすると良いでしょう。

例えば WebXR Device API に対応したスマートフォンで試せる Immersive AR Session のソースコードは immersive-ar-session.html です。

WebXR コンテンツの開発に向いている JavaScript ライブラリ、フレームワークを用いる

Immersive Web Developer の Getting started building a WebXR Website にもいくつか掲載されていますが、一例として次のような JavaScript ライブラリ、フレームワークが挙げられます。

どうしても Vanilla JS で書きたいんだ! のような特別な意思がない限りは、フルスクラッチでコーディングする際の手間をラップしてくれるライブラリ、フレームワークの利用をオススメします。

Babylon.js

https://www.babylonjs.com/

Babylon.js は Microsoft が開発しているブラウザ向けのリアルタイム 3D エンジンです。
A-Frame と異なり、WebXR コンテンツ開発のためものではなく、WebXR コンテンツ “も” 開発できるものです。

Microsoft が開発しているという背景もあり、Microsoft Docs にも公式のチュートリアルページが用意されています。

A-Frame

WebVR コンテンツを開発したいのであれば、まずこの A-Frame に行き着くはずです。

もともとは WebVR 向けのフレームワークとして登場しましたが、現在は WebAR にも対応しています。HTML ライクに記述できるため、初学者にも取っつきやすく、別のライブラリ、フレームワークと組み合わせて使われることも多いです。

Three.js

https://threejs.org/

Three.js は長らく使われているブラウザ向けの 3D 描画を目的とした JavaScript ライブラリです。特性は Babylon.js と同じく WebXR コンテンツ開発のためものではなく、WebXR コンテンツ “も” 開発できるものです。

Three.js は WebGL を取っつきやすくしたラッパーであり、先に挙げた A-Frame は Three.js のラッパーです。そのため、A-Frame を深く深く触ろうとすると、結果として Three.js に辿り着くこともあります。

AR.js

WebAR コンテンツを開発したいのであれば、まずこの AR.js に行き着くはずです。

https://ar-js-org.github.io/AR.js-Docs/

AR.js は WebAR に特化した JavaScript ライブラリです。Babylon.js や Three.js は WebXR コンテンツ “も” 開発できるものに対し、A-Frame が WebXR に特化しているように、AR.js は WebAR に特化しています。

一般的な二次元コードから WebAR コンテンツを表示する以外にも、画像をベースにする Image Tracking ( NFT: Natural Feature Tracking / 流行りの Non-Fungible Token ではない ) と、GPS の位置情報をベースにする Location Based の機能が備わっています。

8th Wall

https://www.8thwall.com/

これまで紹介したものと異なり、8th Wall は『商用利用』を前提としている WebAR のためのソリューションです。A-Frame 同様、もともとは WebAR のみを対象としていましたが、2019 年末から WebVR にも対応しています。

商用利用目的で 8th Wall を使う場合、月額 $99 のライセンスフィー + 最低でも月額 $1,250 のビュー数に応じたコマーシャルライセンスフィーが発生します。

https://www.8thwall.com/pricing

商用利用を前提として 8th Wall を検討する場合は、あらかじめこのコストを予算に含めておく必要があります。予算に余裕があるなら 8th Wall を選択し、余裕がないなら ( 多少の精度を犠牲にして ) AR.js を選択するという考え方もできます。

個人でちょっと試すような用途では使いにくいですが、さすがに有償なだけあり、特に SLAM の精度がかなり高く、NIKE や LEGO のようなナショナルクライアントによるプロモーション用途での利用事例も多々見受けられます。

ちなみに 8th Wall は開発パートナー制度を設けていて、各開発パートナー社のページから実際に8th Wall を用いた事例を参照できます。このページは WebAR コンテンツそのもののショーケースとしても大変参考になります。

https://www.8thwall.com/partners

国内では株式会社Mawariさんと株式会社palanさんの 2 社が事例付きで開発パートナーとして登録されています。

https://www.8thwall.com/mawari

https://www.8thwall.com/palaninc

model-viewer

https://modelviewer.dev/

model-viewer は Google が開発しているブラウザ向けの 3D 表示に特化したライブラリです。WebXR とも馴染みが深い iOS/iPadOS 向けの .usdz ファイルや Android 向けの .glTF ファイルを 2D で描画するだけではなく、WebAR として描画することも可能です。

AR Quick Look

AR Quick Look は Apple が開発している iOS/iPadOS 向けの .usdz ファイルを簡単に WebAR として描画する仕組みです。.usdz ファイルと .glTF ファイルに対応する model-viewer と異なり、iOS/iPadOS 向けの .usdz ファイルにしか対応していませんが、Safari の標準機能として提供されているため、ユーザーが iOS/iPadOS の Safari を使っていれば、別途ライブラリの読み込みは必要ありません。

ただし、macOS 向けの Safari を含む iOS/iPadOS の Safari 以外からアクセスした場合は 3D モデルが WebAR として表示されるわけではなく、単純に .usdz ファイルがダウンロードされてしまう点には注意が必要です。

p5.xr

https://p5xr.org/#/?id=getting-started

p5.xr は Processing を JavaScript に移植した JavaScript ライブラリである p5.js の WebXR 向けアドオンです。WebVR にも WebAR にも対応していて、日頃から Processing や p5.js に触れている方であれば、簡単に WebXR コンテンツを創れることを謳っています。

MediaPipe

https://google.github.io/mediapipe/

MediaPipe はクロスプラットフォームに対応した ML (Machine Learning:機械学習) ソリューションです。MediaPipe は 16 の機能を提供していますが、その中で WebAR の機能として使える JavaScript ライブラリでは次に挙げる 7 つの機能が利用できます。

Face Mesh
Face Detection
Hands
Holistic
Objectron
Pose
Selfie Segmentation

ゲームエンジンを用いる

WebXR コンテンツの開発に求められる要素技術の多くが『ウェブフロントエンドエンジニア』向けのものですが、一般的な XR コンテンツの開発の多くではゲームエンジンが用いられています。このゲームエンジンから WebXR コンテンツを「出力」する方法があります。

Unity + WebXR Export

Unity は WebGL 出力に対応していますが、単体では WebXR コンテンツとして出力できません。

かつては Mozilla が公開していた WebXR Exporter という Unity アセットを使う方法がありましたが、更新が止まり、対応できなくなっています。
現在は @DePanther 氏が開発する後継プロジェクトである WebXR Export を用いることで対応できます。

Unity の開発言語は一般的には C# です。JavaScript に抵抗がある、Unity が慣れている、という方にとって Unity + WebXR Export の組み合わせは最適解と言えます。

現在はオープンソース化された VR 向けお絵描きアプリである Tilt Brush をフォークして WebXR コンテンツ化した Silk Brush はこの WebXR Export で開発されています。

https://msub2.github.io/silk-brush/

Godot Engine

最近少しずつユーザーの増えているゲームエンジンとして Godot Engine が挙げられます。

https://godotengine.org/

読み方はゴドーエンジン、開発言語は独自の GDScript の他、C#、C++ にも対応しています。
Unity と同じ 2D/3D ゲームエンジンですが、標準機能として WebXR コンテンツの開発に適した WebXRInterface が用意されています。

Wonderland Engine

JavaScript ベースでありながら GUI のエディターを持つ Wonderland Engine (WLE) も挙げられます。

https://wonderlandengine.com/

Wonderland Engine は Unity や Godot Engine とは異なり、「Made for WebXR」と WebXR への最適化を謳っています。

ブラウザベースの開発ツールを用いる

手元でコーディングする JavaScript ライブラリ・フレームワークを用いる方法、ゲームエンジンを用いる方法とは別に、ブラウザ上にエディタが用意され、ブラウザ上で開発を完結させられるツールがいくつかあります。

PlayCanvas

PlayCanvas もまたゲームエンジンのひとつであり、WebXR コンテンツを開発するためだけのものではありませんが、比較的早くから、それこそディスコンになってしまった Daydream の頃から WebXR Device API に対応しているブラウザベースの開発ツールです。

https://playcanvas.com/

Amazon Sumerian

PlayCanvas と同じようなブラウザベースの開発ツールを Amazon が AWS の 1 サービスとして提供しています。それが Amazon Sumerian です。

https://aws.amazon.com/jp/sumerian/

国産 Web サービスを用いる

JavaScript ライブラリ・フレームワーク然り、ゲームエンジン然り、ブラウザベースの開発ツール然り、これまで紹介したものは海外発のものばかりです。そんな中、WebAR に関しては、国産 Web サービスがいくつか存在しています。

代表的な国産 Web サービスとして、クラウドサーカス株式会社さんが運営する『LESSAR』や、株式会社palanさんが運営する『palanAR』などが挙げられます。

https://less-ar.jp/

https://palanar.com/

2021 年の WebXR コンテンツの概観と 2022 年の WebXR 界隈の予測

2021 年の WebXR コンテンツの概観

2021 年の WebXR コンテンツの概観については、2021 Summer 時点から、さらに遡ると 2020 Winter からそう大きな変化はありません。

そんなところに Facebook 改め Meta 社の社名変更をきっかけに『メタバース』が突然キャズムを超えて降ってきた感があります。WebXR 周辺で言えば Hubs Cloud をはじめとする WebVR による独自のバーチャル空間作りは決して珍しいものではありませんが、この流れに乗って 2022 年は大きく進むかもしれません。

つい先日、A-Frame の最新 master と Oculus Browser の組み合わせで navigation API のサンプルが動作するようになったそうです。

むしろ今まで出来なかったの? と思われる方がいるかもしれませんが、これまで VR モードを維持したままサイト間の遷移はできませんでした。( 正確には “The Immersive Internet” を謳う JanusXR のようなものは存在していました! ) これができるようになったことで、平面世界のウェブコンテンツと同じように、WebVR 空間を自由に行き来できる機運が高まりました。

2022 年の WebXR 界隈の予測

引き続き新型コロナウイルス感染症は各方面に影響を及ぼしていますが、日本国内においては 2021-11-30 時点での新たに確認された感染者数が 132 人とされ、一時期に比べると少しずつ落ち着いてきているように見えます。しかし、海外では引き続き感染者数が増加、新たな変異株「オミクロン株」が登場、日本でも同変異株の感染者が発生するなど、2022 年もまだまだ気が抜けない状況が続くと考えられます。

そういったことを考慮すると 2022 年も GPS の位置情報をもとにするロケーションベースの WebAR コンテンツは少し難しい状況が続くかもしれませんし、対面タッチアップの代替となる WebAR のバーチャルトライオンは伸長し続けると予測するのが妥当でしょうか。

そして WebXR Device API がいつ Safari に実装されるのか、iOS/iPadOS 16 を待たなければならないのか、あるいは突然 iOS 12.2 で起きたような破壊的な変更が入らないか、気になることはたくさんあるので、引き続き動向をウォッチしていきます。

明日の Day 2 は ~~(カレンダーが埋まらなかったので) 引き続き @ikkou による『HTML <model> element のお話』~~ Limesさんによる『Babylon.jsのWebXR形式でテレポート移動を実装する方法』です！

現場からは以上です！

Discussion