AndroidXRへの対応（SpacesCompatibilityPlugin）
本記事に記載の内容は、SpacesCompatibilityPlugin 1.0.0 と 2026年2月時点の検証結果をもとにしています。
Snapdragon Spaces Compatibility Plugin、Android XR、各種 OpenXR 関連パッケージは今後更新される可能性があります。
0. はじめに
MiRZA 向けアプリは、これまで主に Snapdragon Spaces SDK を前提として開発してきました。
一方、近年では Android XR という新しいプラットフォームも登場し、今後はそれに対応したデバイスへの展開も視野に入ってきました。そこで今回は、SpacesCompatibilityPlugin（以降、SCP）を使って、既存の Spaces SDK ベースの MiRZA アプリをどこまで少ない修正で Android XR 向けに移行できるのかを検証した結果をまとめます。
1. この記事で伝えたいこと
本記事で扱うのは、次の3点です。
Spaces SDK と Android XR がどうつながるのかSpacesCompatibilityPlugin が何を担うのか今回の検証時点で、SpacesCompatibilityPlugin をどこまで実運用に使えそうか
まずこの3点を整理したうえで、後半で MiRZA と Android XR デバイスでの検証結果を見ていきます。
2. Spaces SDK と Android XR の関連
Snapdragon Spaces SDK は Qualcomm 系デバイス向けの XR アプリ開発用 SDK です。一方、Android XR は Google / Samsung 主導の新しいプラ ットフォームで、OpenXR を前提にしています。
両者は同じレイヤのものではありません。Spaces SDK はアプリ開発用の SDK で、Android XR はそのアプリが動くプラットフォームです。つまり、既存の Spaces SDK ベースのアプリを Android XR 側へ移すには、ビルドターゲットを切り替えるだけでは足りず、前提にしている構成や実装も見直す必要があります。
さらに、Snapdragon Spaces SDK 自体も OpenXR を前提としているものの、移行時には以下の差分を吸収する必要があります。
- Spaces 固有の API やサンプル実装への依存を減らし、Android XR で扱いやすい Unity / OpenXR 構成へ整理すること
- MiRZA 向けに構成した入力、描画、UI の設計を Android XR 向けに見直すこと
この橋渡し役として位置付けられているのが SCP です。
3. SpacesCompatibilityPluginとは
SCP は、Qualcomm の公式紹介ページ の説明どおり、Android XR デバイスと Snapdragon Spaces デバイスの両方に向けたアプリを、単一の Unity プロジェクトで扱いやすくするためのプラグインです。既存プロジェクトを少ない調整で扱いやすくし、移行を進めやすくすることが位置付けられており、同ページの Seamless Migration でも 既存の OpenXR 機能を活かしながら、できるだけ少ない手戻り で Android XR へ移行する という考え方が示されています。
その前提として、Qualcomm の Setup Guide では OpenXR Plugin 1.15.1、AR Foundation 6.0.3、Unity OpenXR Android XR 1.0.0 が必須依存として示されており、XR Hands、XR Interaction Toolkit、Universal Render Pipeline (URP) なども互換確認済みパッケージとして整理されています。つまり、SCP は単体で完結する仕組みではなく、Unity / OpenXR 系のパッケージ構成の上に成り立つ移行プラグインです。
また、Qualcomm の Support ページ では、Lenovo VRX などの Snapdragon Spaces VR/MR ヘッドセットと、Samsung Project Moohan などの Android XR VR/MR デバイスがサポート対象とされる一方、MiRZA や Lenovo A3 などの Snapdragon Spaces AR グラスはサポート対象外とされています。
MiRZA 向けアプリの今後を考えるうえでは、この点が気になります。公式には MiRZA はサポート対象外ですが、今後の扱いを考えるには、実際にどこまで動くのかを確認しておく必要があります。そのため今回の検証では、Android XR 側でどこまで移行できるかを見るために Galaxy XR を、MiRZA で現実的にどこまで適用できるかを見るために MiRZA を確認しました。
4. SpacesCompatibilityPluginの現在地と今後
ここまでの情報と今回の検証結果をあわせて見ると、現時点での判断は次のようになります。
MiRZA アプリをそのまま SCP を使って Android XR へ移行するのは時期尚早今回検証した範囲では Android XR への移行自体は可能だが、AR 機能には制約が残る本格移行は、Unity 6 への更新や DRF 前提の体験設計の見直しとあわせて考える必要がある
この結果を見ると、SCP は「導入すれば移行完了」というものではありませんが、既存アプリを Android XR 向けに整理し、まずは移行の見通しを立てるための出発点としては有効です。実際、今回の検証でも環境整理や初期動作確認を進めるうえでは役立ちました。ただし、本格移行は SCP だけで完結するというより、Unity 6 への更新や DRF 前提の体験設計の見直しを含めた開発基盤の更新とあわせて考えるほうが自然です。
公式情報でも、SCP は既存の OpenXR 機能を活かしながら Android XR への移行を進めるための仕組みとして位置付けられています。なお、Qualcomm の Setup Guide では、Android XR Extensions for Unity との互換性について今後の対応が予定されている旨にも触れられており、周辺環境も含めてまだ整理が進んでいる段階だと分かります。
そのうえで、Qualcomm の Support ページ では、機能面の現在地が次のように整理されています。
| 区分 | 機能 |
|---|---|
| 現時点で Spaces と Android XR の両方で共通して扱える機能 | Head Tracking、Controller Tracking、Hand Tracking、Passthrough、Composition Layers、Hit Testing、Local Spatial Anchors、Foveated Rendering、Variable Display Refresh Rate、Plane Detection |
| commercial release に向けた対応予定機能 | QR Code Tracking、Image Tracking、Spatial Meshing、Camera Frame Access |
今回の検証では、こうした機能差やデバイス差がそのまま結果にも表れました。特に MiRZA では、AR 前提の既存アプリをそのまま移行できる状況ではありませんでした。そのため、今後は少なくとも次の点が改善・整理されることが望まれます。
- カメラアクセスや Image Tracking の改善
- アンカー永続化など AR 機能の安定化
- Android XR デバイス上での実装制約の緩和
5. 検証で確認したこと
ここでは、前半で整理した「SCP の位置付け」や「現在地」について、MiRZA と Android XR デバイスでの検証結果をまとめます。
5.1 検証の前提
今回の検証では、MiRZA 上で動作している既存アプリをベースに、Spaces SDK から SCP への移行を試みました。
検証時の主な前提は以下です。
- ベースアプリ: MiRZA 向けの Spaces SDK アプリ
- 元の開発環境:
- Unity 6000.0.58f2
- Spaces SDK 1.0.4
- OpenXR 1.15.0-pre.1
- AR Foundation 6.0.6
- SCP 適用に向けて更新した後の環境:
- Unity 6000.1.17f1
- Spaces SDK 1.0.4
- OpenXR 1.15.1
- AR Foundation 6.1.1
- Graphics API は Vulkan を優先に設定
5.2 MiRZAで確認したこと
まず MiRZA 側で確認できた状態は以下です。
- APK のビルドは可能
- アプリは起動する
- クラッシュはしない
- ただし、グラス側に何も表示されない
ビルドと起動までは確認できたものの、グラス側に映像が表示されず、実用動作には至りませんでした。OpenXR 初期化や表示経路まわりの問題も確認しており、少なくとも今回の検証時点では、SCP を MiRZA のような AR 前提デバイスへそのまま適用するのは難しいと判断しています。
5.3 Android XR デバイスで確認したこと
対して、Android XR デバイス側では前向きな結果も出ています。
今回の検証では、Galaxy XR 実機において SCP を適用したアプリが正常起動した ことを確認しました。少なくとも今回試した範囲では Android XR への移行自体は可能でしたが、AR 機能まわりにはまだ制約が残ります。具体的には、次のような点を確認しています。
- 基本動作は良好
- 一部 AR 機能には制約が残る
- アンカー保存機能は未動作
- メッシュ、平面検知は初動は早いが更新が遅い
- カメラアクセスや Image Tracking は動作不可の項目あり
5.4 移行時に必要だった対応
今回の検証では、Android XR 向け対応の作業は大きく次の4段階に整理できました。
5.4.1 環境刷新
- Unity 6 系へのアップグレード
- 既存 Spaces SDK 依存の整理
- OpenXR / AR Foundation / Graphics API の見直し
特に Unity 6 への更新は必須条件です。旧バージョンの Unity では SCP の前提を満たせま せん。
5.4.2 SCP の導入
- SCP のインポート
- Compatibility Tool による設定置換
- Vulkan 設定への調整
ここまでは比較的機械的に進められます。
5.4.3 コードのリファクタリング
Spaces SDK 依存コードは、そのままでは大量のエラーになります。検証では以下のような対応が必要でした。
- Spaces SDK の Sample 依存コードの削除
- 廃止された Dual Render Fusion (DRF) 関連コードのコメントアウトまたは削除
- Spaces 固有 API 呼び出しの置き換え
特に、Spaces SDK のサンプルを流用している箇所は削除や再実装が必要になりやすいです。
5.4.4 UX の作り直し
ここがいちばん大きな論点でした。
Android XR 対応では、単に SDK を差し替えるだけではなく、スマートフォンをコントローラとして使う Dual Render Fusion (DRF) 前提の体験を見直す 必要があります。というのも、DRF は MiRZA / Snapdragon Spaces 側の体験設計に依存しており、SCP でそのまま引き継げる共通移行対象には含まれていないためです。
今回の検証で重要だと分かったポイントは次の通りです。
- QCHT / Spaces 独自のプレイヤー構成をやめて、標準の
XR Originベース構成へ置き換える - QCHT 依存を減らし、
XR Handsなど Android XR で扱いやすい手段へ置き換える - スマートフォン操作前提の UI を見直す
この部分は単なるコード移植ではなく、体験設計の再構築として捉える必要があります。
5.5 SCP 適用と初期確認の目安
今回の検証で扱ったような比較的シンプルな構成、たとえば MRTK3 のサンプル に近い規模感であれば、SCP の適用と初期動作確認までは 約2時間 をひとつの目安にできると見ています。
内訳の例は以下です。
- 環境構築 / SDK 依存整理: 30分
- SCP 適用 / 設定変更: 20分
- コード修正（AR / Input 周辺）: 60分
ただし、これはあくまで 基本的な置き換え作業と初期確認 の目安です。実際のアプリでは、5.4.4 で述べた UX の見直しや AR 機能の再設計が追加で必要になるため、工数はアプリの要件に応じて増えます。
5.6 まとめ
ここまでの検証結果を踏まえると、SCP は Spaces SDK ベースの既存アプリを Android XR へ移行する際の有力な選択肢です。Android XR デバイス上では基本動作を確認できており、移行の出発点としては十分に有効でした。
一方で、2026年2月時点では MiRZA のような AR デバイスを前提とした移行にはまだ制約が多く、SCP へ差し替えるだけでそのまま展開できる段階にはありません。MiRZA のような AR デバイス向け展開については、今後 SCP の AR 対応が進むことを期待しつつ、リリース動向を見ながら判断していくのが現実的です。
そのため、Android XR 向け展開を進めるのであれば、
- Unity 6 への更新
- Spaces 固有依存を減らした Unity / OpenXR 構成への整理
- DRF 前提の体験設計の見直し
を前提に、段階的に移行を進めるのが現実的です。