見出し画像

Snap Specs × WebXR 実機検証レポート──WebAR開発者がARグラスに参入するための技術ガイド

ARグラス市場の背景をおさらいしたい方はこちら:
空間コンピューティング市場2,294億ドル、ARグラス7製品が一斉発売
Ray-Ban Meta日本上陸——700万台が証明した「毎日かけるAIグラス」の破壊力
Snap Specs一般発売迫る--ARグラス時代に広告・イベントはどう変わるか

Snap OS 2.0でSpecsにWebXRブラウザが搭載された。WebAR開発者にとって「ARグラス対応」は延長線上にあるのか、それとも別世界なのか?実機テストの結果を元に、対応状況・制約・実践的なTipsを整理する。

1. WebXR対応の実態──何が動いて、何が動かないのか

公式ドキュメント:Snap Spectacles WebXR

フレームワーク別動作状況

フレームワーク別

重要な発見: Polyfillなしでも動作する。immersive-vrモードで黒背景を使えば、透過ディスプレイ上でAR風に見えるため、AR的な体験をVRモードで実現する方が現時点では安定する。

WebXRで利用可能な機能

  • ✅ 6DOFヘッドポーズトラッキング

  • ✅ ハンドトラッキング(フルジョイントスケルトン)

  • ✅ ピンチ、グラブ、ジェスチャー

  • ✅ WebXRセッションのキャプチャ・共有(動画録画)

  • ✅ ロケーション

WebXRで利用不可の機能(Lens Studio必須)

  • ❌ カメラアクセス/パススルーテクスチャ

  • ❌ 深度データ

  • ❌ ヒットテスト(サーフェス検出・オクルージョン)

  • ❌ マイク / BLE / SnapML / ゲームパッド / フロア高さ取得

環境とのインタラクションが必要ならLens Studio一択。 WebXRは「空間に浮かぶUI/コンテンツ」向き。

2. Lens Studio vs WebXR──使い分けの判断基準

WebXRが適しているケース

  • 環境とのインタラクションが不要なコンテンツ

  • クロスプラットフォーム展開(スマホ・VR・Vision Pro・Specs)

  • 地図・データ可視化など、Webツールが優れている領域

  • URL配信でアプリストア審査を回避したい場合

Lens Studioが必須のケース

  • AI機能の利用(画像認識・音声会話等)

  • 現実環境とのインタラクション(物体配置・オクルージョン・深度)

  • カメラアクセス・マイク・BLE等のデバイス機能 / SnapML利用

⚠️ WebXRの配信課題

現時点でSpecsにはQRコードスキャン機能がない。URLは手動入力が必要で、キーボードの精度も低いため長いURLの入力はストレスになる。

実践的な対策: 短いドメインを取得しWebXR体験の一覧ページを設ける / ブックマーク機能を活用する / デモ時はあらかじめURLを入力しておく

3. パフォーマンスの現実

FPS比較(実機テスト結果)

FPS比較

→ スマホ比で概ね半分程度のパフォーマンス。ローポリ・軽量テクスチャ・シンプルシェーダーが必須。

トラッキング品質

ヘッドポーズ、ハンドトラッキング、ピンチ・グラブはいずれも30FPS以上を維持できていればLens Studioと同等の滑らかさ。WebXRだからといって入力品質が劣るわけではない。

⚠️ バッテリーが最大の課題

深刻な問題: USB接続で充電中であってもバッテリーがゼロになるケースが発生。通常のLens実行では充電が追いつくが、WebXRでは追いつかない。

運用対策: 公開デモでは体験時間を数分に制限 / 複数デバイスをローテーション運用 / バッテリー残量の監視・管理体制を整備。発熱に関しては問題なし。

デバッグ環境

リモートデバッグは非対応。 WebXRシーン内にデバッグコンソールを組み込む必要がある。FPS表示・ログ出力用の3Dオーバーレイを実装するのが現実的。

4. スマホWebAR → Specs WebXR 移行ガイド

入力方式の変化

入力方式

A-FrameのハンドトラッキングデモはSpecs上で良好に動作。既存のA-Frameプロジェクトにハンドインタラクションを追加するのは比較的容易。

表示領域の再設計

スマホの全画面表示から、46度FOVの透過型ディスプレイへ。「スマホで見えていたものがARグラスでは視野外」は頻出する問題。コンテンツの配置・情報量を根本的に見直す必要がある。

既存コンテンツの移植性(実テスト結果)

テスト結果

実践的なアプローチ

  • 新規開発はimmersive-vrモード + 黒背景で設計するのが最も安定

  • 既存WebXRコンテンツの最小限の変更でSpecs対応は可能

  • Specsをターゲットに含めて設計すれば、VR・スマホ・Specsのクロスプラットフォーム展開が実現できる

推奨フレームワーク

  1. A-Frame(最推奨)— 最も安定、サンプルの多くがそのまま動作

  2. WebXR Device API直接利用 — immersive-vrモードなら60FPSで完璧

  3. Three.js + カスタムローダー — Adam Vargaのwebxr-ar-demosを参考に

  4. Babylon.js — 非推奨(パフォーマンスが劣悪)

  5. PlayCanvas — 非推奨(Snap推奨だがデモが動作せず)

5. 比較まとめ

比較まとめ

6. 次のステップ

Designiumの取り組み

DesigniumはSpectaclesが開発者向けに公開された初期から実機開発に取り組み、プロトタイプを含めこれまでに20件以上のSpectacles向けARコンテンツを制作してきた。本レポートの実機検証結果も、その開発過程で蓄積した知見を基にしている。

代表実績:Tokyo Time Machine(Snap公式パートナーシップ/2022)
浅草寺を舞台にしたAR歴史体験。SpectaclesのCustom Landmarkersを用い、実環境に過去の映像を正確に重ねる位置連動ARを実装した。

クロスプラットフォームWebXR — スマホ・VR(Meta Quest)・Vision Pro・Specsのすべてで動作するWebXR体験の開発が、Designiumの差別化ポイント。Specs向けに設計すれば、最小限の変更で他プラットフォームにも展開できる。

エンジニアへの呼びかけ

WebAR開発の経験があるエンジニアにとって、Specs向けWebXR開発は確実に「延長線上」にある。A-Frameの経験があればすぐに始められる。Specs WebXR開発に興味がある方、共同でテスト・検証を進めたい方はぜひご連絡ください。

ARグラス向けコンテンツの企画・開発にご興味がある方は、ぜひお気軽にご相談ください。

開発のご相談はこちら

制作実績はこちら