Android XR Developer Preview 4の導入判断：Glimmer、Engine Hub、Unreal/Godot対応で確認すること

3行まとめ

DP4の位置づけ

Android XR Developer Preview 4は、没入型体験と拡張型体験の両方に向けたAPI、ツール、ライブラリの更新として読む。

既存Androidアプリ

通知、音声、短い状態表示、ナビゲーション補助のような体験をグラス向けに切り出せるかを見る。

XR/ゲーム資産

Unity、Unreal Engine、Godot、OpenXRの既存資産を、Engine HubやDirect Previewでどう検証するかが入口になる。

Developer Previewやalphaライブラリを含むため、最初の判断軸は本番採用ではなくPoCの設計に置く。

• Googleは2026年6月15日、Android XRのDeveloper Preview 4、Jetpack Projected、Jetpack Compose Glimmer、ARCore for Jetpack XR、Android XR Engine Hub、Unreal Engine/Godot対応などを公式に整理した。
• この記事では、Android XRを「新しいSDKが出た」という話ではなく、既存Androidアプリをグラス向けに拡張する入口と、Unity/Unreal/Godot/OpenXR資産をXRへ持ち込む入口に分けて読む。
• まだDeveloper Previewやalphaライブラリを含むため、本番投入の判断より先に、PoC、実機検証、入力方式、視認性、ビルド/反復速度、対応デバイスを確認したい。

Android XRの今回の公式更新は、スマートグラスやXRヘッドセットに関心がある開発者だけの話ではない。既存のAndroidアプリを持つチームにとっては、通知、音声、短い状態表示、ナビゲーション補助のような体験をaudio glassesやdisplay glassesへ切り出す入口になる。一方で、Unity、Unreal Engine、Godot、OpenXRでXRコンテンツを作ってきたチームには、Android XR Engine HubやDirect Previewを使って反復速度を検証する入口になる。

ただし、今の段階で「Android XR対応を急いで本番化すべき」と読むのは早い。公式ドキュメント上でも、Jetpack XR SDKの依存関係にはalpha版が並び、Developer Preview 4へのフィードバックが求められている。この記事では、2026年6月16日に確認できたAndroid Developersの一次情報をもとに、どのチームが、どの順番で試すべきかを整理する。Android全体の直近動向をあわせて見る場合は、<a href="https://googl-watch.blog.mo-gmo.com/monthly-topics-2026-06/">2026年6月の重要トピックまとめ</a>も参考にしてほしい。

Android XR Developer Preview 4は何を判断する更新か

既存Android開発者

今あるアプリから、グラスで短く確認できる状態、通知、音声応答、作業補助を切り出せるかを検討する。

XR/ゲーム開発者

Engine Hub、Direct Preview、Unity、Unreal、Godot、OpenXRのどこから入るかを既存資産に合わせて決める。

共通で見ること

エミュレータで足りる確認、実機が必要な確認、alpha APIの変更を吸収できる計画を分けておく。

DP4はニュース見出しとして覚えるより、1週間から数週間のPoCで答える問いを作るために使う。

DP4はSDK単体ではなく、開発ルートを選ぶ更新として読む

根拠

2026年6月15日のAndroid Developers Blogは、Android XRのDeveloper Preview 4を、没入型体験と拡張型体験の両方に向けたAPI、ツール、ライブラリの更新として紹介している。本文中では、Android StudioのXR Emulatorで物理デバイスなしにやり取りを試せること、既存モバイルアプリをintelligent eyewearへ広げるためのJetpack ProjectedやDevice Availability API、display glasses向けのJetpack Compose Glimmer、さらにEngine Hubとエンジン対応の拡大が並んでいる。

ここで大事なのは、DP4をひとつの機能名として覚えることではない。Android XRには、少なくとも次の3つの入口がある。

入口	主な読者	まず見るもの
既存Androidアプリの拡張	Kotlin、Compose、Androidアプリ開発チーム	Jetpack Projected、Device Availability API、Jetpack Compose Glimmer
現実理解を使うXR体験	AR/XR機能をAndroid側で試すチーム	ARCore for Jetpack XR、エミュレータ、実機検証
エンジン資産のAndroid XR移植	Unity、Unreal、Godot、OpenXRチーム	Android XR Engine Hub、Direct Preview、各エンジンの公式ガイド

既存Android開発者とXR/ゲーム開発者で入口が違う

条件

既存Android開発者は、まず「今あるアプリの何をグラス向けに切り出せるか」を見るべきだ。スマートフォン画面をそのまま小さく映すのではなく、短い通知、音声応答、手を使わない確認、道案内、翻訳、現場作業の補助のように、グラスだから意味が出る機能を探す。

XR/ゲーム開発者は、Engine Hub、Direct Preview、Unity、Unreal、Godot、OpenXRのどこから入るかが先になる。既存のUnity資産があるチームと、Unrealの高品質レンダリングに寄せたいチーム、Godotの軽量なOpenXR実験を重視するチームでは、最初の検証項目が変わる。

まだ「本番採用」より「PoCの設計」に向く

注意点

Googleの公式ページでは、Android XR SDKがDeveloper Preview 4に到達したことが複数のドキュメント上で案内されている。加えて、Jetpack XR SDKのセットアップページでは、androidx.xr.runtime:runtime:1.0.0-alpha14、androidx.xr.glimmer:glimmer:1.0.0-alpha13、androidx.xr.projected:projected:1.0.0-alpha08のようなalpha版依存関係が示されている。

そのため、この記事での推奨は「今すぐ全社標準にする」ではない。まずは、1週間から数週間のPoCで、次の問いに答えられるかを見るのが現実的だ。

• 既存アプリに、グラスで短く表示する価値のある状態や通知があるか。
• グラスの着用状態、接続状態、入力可能状態に合わせてアプリ側の動きを変えられるか。
• エミュレータだけで済む確認と、実機が必要な確認を分けられるか。
• Engine HubやDirect Previewで、XR開発の反復速度が実際に上がるか。
• Developer Previewやalpha APIの変更を、プロジェクト計画の中で吸収できるか。

既存AndroidアプリがGlimmerとJetpack Projectedを試す条件

1. 1切り出す体験を選ぶ

   短い通知、音声応答、手を使わない確認、道案内、翻訳、現場作業の補助などを候補にする。

2. 2Jetpack Projected

   既存モバイルアプリから、audio glassesやdisplay glasses向けの補完的な体験を作る入口として見る。

3. 3Device Availability API

   グラスの接続、着用、一時的な利用不可に合わせて、表示、入力、音声、リソース解放を切り替える。

4. 4Jetpack Compose Glimmer

   display glasses向けに、視認性、フォーカス、入力、テーマ、コンポーネントを評価する。

長文入力や複雑な設定画面より、少ない操作で成立する体験を最初の検証対象にする。

Jetpack Projectedは「既存アプリの補助体験」を作る入口

確認項目

Googleの公式ブログは、audio glassesやdisplay glasses向けの開発について、ゼロから別アプリを作るだけでなく、既存モバイルアプリから補完的なaugmented experienceを作れると説明している。その入口として出てくるのがJetpack Projectedだ。

ここで考えるべきなのは、「自社アプリをAndroid XR対応にするか」ではなく、「既存アプリの中に、グラス向けに切り出したほうが便利な小さな体験があるか」だ。

既存アプリの要素	グラス向けに向く可能性	最初の確認
配送、移動、現場作業の状態	手を使わずに次の行動を確認できる	1画面に出す情報量を減らせるか
翻訳、会話、音声メモ	音声入力や短い返答と相性がよい	マイク、音声出力、権限の扱いを切れるか
通知、承認、リマインダー	視線移動を少なくできる	過剰通知にならない条件を作れるか
地図、ナビゲーション、チェックリスト	視界の中で次の手順を見られる	安全性と誤操作を評価できるか

一方、長文入力、一覧の細かい比較、複雑な設定画面、表計算のような作業は、グラス向けの最初の題材にしにくい。画面を移植する発想ではなく、補助体験として切るのが出発点になる。

Device Availability APIは着用状態や接続状態に合わせる判断軸

根拠

Device Availability APIは、display glassesやaudio glassesの利用可否を標準のLifecycle.Stateに対応させるAPIとして説明されている。公式ページでは、グラスがホスト端末から切断される、ユーザーが外して一時的に利用不可になる、といった変化を考慮するためのものとして整理されている。

記事執筆時点で公式ページに示されている状態の意味は、実装判断にも直結する。

Lifecycle state	デバイス状態	実装で見ること
CREATED	接続はあるが、ユーザーが装着していない	カメラや音声などグラス固有処理を止める
STARTED	ユーザーが装着している	入力、音声、表示を有効にする
DESTROYED	デバイス切断またはサービス接続喪失	projected contextを使い続けない

このAPIは、単に画面状態を監視するためのものではない。音声ルーティング、ホットワード、入力期待値、バッテリー、プライバシーに関わる。たとえばグラスが外された状態で、カメラや音声ストリームをそのまま維持する設計は避けたい。実機検証に入る前から、状態変化に応じてどのリソースを解放するかを設計に入れておくべきだ。

Jetpack Compose Glimmerはdisplay glasses向けUIとして評価する

評価基準

Jetpack Compose Glimmerは、display glasses向けのaugmented Android XR experienceを作るためのCompose UI toolkitとして公式ドキュメントで説明されている。通常のAndroid UIを小さく表示するためのものというより、グラス固有の視認性、フォーカス、入力、テーマ、コンポーネントを扱うための入口と見たほうがいい。

Glimmerを試す価値があるのは、次のような条件があるチームだ。

• 既存アプリがKotlinやJetpack Compose中心で、状態管理やコンポーネント分割がすでにある。
• display glassesで短く読ませる情報を選べる。
• タップ、スワイプ、音声入力、通知開始など、少ない操作で成立する体験を作れる。
• グラス向けUIを、スマートフォンの縮小版ではなく、別の表示面として設計できる。

逆に、既存画面の全機能をそのままdisplay glassesへ持ち込む前提なら、Glimmerを入れる前に情報設計をやり直したほうがよい。グラスの画面は、長時間読む場所ではなく、必要な瞬間に短く使う場所として考える。

ARCore for Jetpack XRとエミュレータで検証すること

1. 机上確認

   平面、アンカー、geospatial poseなど、使いたいperception機能と対象デバイスを先に対応表で見る。

2. XR Emulator

   物理デバイスなしで、画面構成、状態遷移、基本的なAPI呼び出し、ビルド手順を確認する。

3. 実機確認

   視認性、装着状態、入力、接続、音声、パフォーマンスなど、エミュレータでは判断しにくい点を見る。

4. 依存関係管理

   Developer Previewやalpha依存関係を管理し、更新時の差分確認と最小構成でのビルド確認を先に置く。

エミュレータで動くことと、実機で快適に使えることは分けて判断する。

ARCore for Jetpack XRは現実理解を使う機能の入口

根拠

ARCore for Jetpack XRは、Android XRアプリが現実世界を理解するためのperception機能を扱う入口として説明されている。公式ドキュメントでは、平面データの取得、空間へのアンカー、現実の位置に基づくgeospatial poseなどが例として示されている。

ここで重要なのは、ARCore for Jetpack XRを「ARCoreの名前が付いているから既存ARCoreと同じ」と読まないことだ。Android XR向けの文脈では、XR headsets、wired XR glasses、AI glassesなど複数のデバイス型があり、どのAPIがどのデバイスで使えるかを確認する必要がある。

エミュレータで足りる確認と実機が必要な確認を分ける

確認項目

公式ブログは、Android Studio内のXR Emulatorを使って、物理デバイスなしにコードを試せると説明している。これは初期検証にはかなり大きい。グラスやヘッドセットを全員分そろえる前に、レイアウト、状態遷移、基本的なAPI呼び出し、ビルド手順、チーム内レビューを進められるからだ。

ただし、エミュレータで動くことは、実機で快適に使えることと同じではない。分けて確認したい。

検証段階	確認できること	実機に残ること
机上確認	ユースケース、情報量、権限、対応デバイス	視認性、疲労感、装着中の操作感
エミュレータ	画面遷移、API呼び出し、基本レイアウト、ライフサイクル反応	実環境の明るさ、入力精度、空間認識の品質
実機検証	装着中の見え方、音声/入力、接続、バッテリー	長期利用時の習慣化、現場での安全性
小規模ユーザーテスト	実作業中の詰まり、通知の多さ、使われる場面	本番規模の運用、サポート負荷

Androidアプリ全般の品質やメモリ監視も同時に見るなら、公開済みの<a href="https://googl-watch.blog.mo-gmo.com/googl-52-android-17-memory-limits-leakcanary-checklist/">Android 17のメモリ制限対応</a>も合わせて読んでおくと、XR以前の足元を確認しやすい。新フォームファクタに対応するほど、既存アプリのクラッシュ、リーク、画像リソース、バックグラウンド動作の粗さが表に出やすくなる。

依存関係は用途別に分けて見る

注意点

2026年6月16日に確認したJetpack XR SDKのセットアップページでは、没入型体験とAI glasses向け拡張体験で、追加する依存関係が分けられている。数字は変更される可能性があるため、実装前には公式ページで再確認してほしい。

用途	公式ページで示されている主な依存関係	記事執筆時点の意味
immersive experiences	runtime:1.0.0-alpha14、scenecore:1.0.0-alpha15、compose:1.0.0-alpha14、material3:1.0.0-alpha17、arcore:1.0.0-alpha14	headsetsやXR glasses向けの空間UI、SceneCore、ARCoreを試す入口
augmented experiences	runtime:1.0.0-alpha14、glimmer:1.0.0-alpha13、glimmer-google-fonts:1.0.0-alpha13、projected:1.0.0-alpha08、arcore:1.0.0-alpha14	audio glassesやdisplay glasses向けに、Projected、Glimmer、ARCoreを組み合わせる入口
ProGuard利用時	com.android.extensions.xr:extensions-xr:1.3.0をcompileOnlyで追加	implementationやapiにしないという公式の注意がある

この表は、実装のコピペ用ではない。判断材料として読むべきだ。alpha版を含む以上、PoCでは依存関係の固定、更新時の差分確認、最小構成でのビルド確認を先に置く。

Android XR Engine HubとDirect Previewを使う条件

1. 1Windowsホスト

   Android XR Engine Hubを使うための開発ホストを用意し、チーム内で再現できる手順にする。

2. 2Android XR device

   USB-C接続、developer options、debugging、stream clientなど、物理デバイス側の前提を整える。

3. 3Engine Hub

   デバイス接続、runtime設定、ストリーミングツールをエンジン横断で管理する中枢として使う。

4. 4Unity/Unreal/Godot

   使うエンジンを決め、OpenXR Runtimeや各エンジン側の初期設定を検証手順に入れる。

5. 5Direct Preview

   毎回APKを書き出す代わりに、ライブデータを使って手、目線、空間メッシュ、アンカーなどの調整時間を測る。

便利さだけでなく、接続、設定、ランタイム、ストリーミングの前提をチームが維持できるかを見る。

Engine Hubはエンジン横断の開発中枢として読む

条件

Android XR Engine Hubは、XR開発のワークフローをまとめるデスクトップツールとして公式ページで説明されている。デバイス接続、runtime設定、ストリーミングツールを複数ゲームエンジン横断で扱うためのものだ。2026年6月16日時点の公式ページでは、Android XR Engine HubはWindows向けに提供されている。

導入前に見るべき条件は明確だ。

• Windowsホストを用意できるか。
• Android XR deviceを接続できるか。
• Unity、Unreal Engine、Godotのどれを使うか決められるか。
• OpenXR Runtimeの切り替えやstream clientの導入を、開発環境の手順に入れられるか。
• エンジン内で試したい入力やperception機能が、Direct Previewで扱える範囲にあるか。

Engine Hubは、XR開発のすべてを自動化する魔法の箱ではない。むしろ、接続、設定、ランタイム、ストリーミングを明示的に管理する道具として見るほうが現実的だ。

Direct Previewは反復速度を検証する機能として扱う

上振れ

Direct Previewは、Android XR Engine Hubの機能として、ゲームエンジンのエディタ内で複雑なインタラクションを試し、物理Android XR deviceからのライブデータを使って反復できると説明されている。公式ドキュメントでは、毎回APKを書き出す代わりに、ホストマシンでレンダリングとデバッグを行い、ビジュアル viewportをデバイスへ送り、対応するOpenXR extensionsをホスト側へリアルタイムに戻す流れが示されている。

これはXR開発ではかなり大きな意味を持つ。手や目線、空間メッシュ、パススルー、レイキャスト、アンカーのような体験は、小さな調整のたびにビルドとデプロイを繰り返すと、試行回数がすぐに減る。Direct Previewでその待ち時間を減らせるなら、初期PoCの密度が上がる。

一方で、準備は軽くない。公式手順では、Engine Hubの導入、Android XR deviceのUSB-C接続、developer optionsとdebuggingの有効化、stream clientのインストール、Active OpenXR Runtimeの設定、各エンジン側の初期設定が必要になる。導入判断では、ツールの便利さだけでなく、チームがその前提を維持できるかを見たい。

Unity、Unreal、Godot、OpenXRをどう選び分けるか

項目	内容	見方
Unity		既存のUnity XR資産、AR Foundation、XR Interaction Toolkit、URP、Vulkan、Android向け運用経験があるチームで優先しやすい。
Unreal Engine		高品質な3D表現、既存VR資産、BlueprintやC++でのXR実装があり、Android XR Extensions for Unrealを確認できるチーム向け。
Godot		Godot 4系で軽量にXR実験をしたい場合や、オープンソースエンジンを軸にしたい場合に検証候補になる。
OpenXR直書き		標準APIとAndroid XR固有の拡張差分を追える体制があり、エンジンに依存しない実装判断をしたいチーム向け。

成熟度、拡張対応、入力、権限、配布条件は用途ごとに変わるため、単純な勝敗ではなく条件差で判断する。

Unityは既存XR制作フローとURP/Vulkanを確認する

評価基準

Unity向けのAndroid XR公式ガイドは、Android XRのUnity対応がOpenXRの上に構築され、多くのOpenXR関連機能がUnityでもサポートされると説明している。さらに、Unity 6のmixed reality tools、XR Interaction Toolkit、AR Foundation、OpenXR Plugin、URP、Vulkanなどが確認対象として出てくる。

Unityから始める優先度が高いのは、次のようなチームだ。

• 既存のUnity XR資産がある。
• AR FoundationやXR Interaction Toolkitに慣れている。
• URPとVulkanを前提にプロジェクトを整理できる。
• Android向けビルド、Google Play配布、パーミッション管理の運用経験がある。

Unityは入り口が広いぶん、既存プロジェクトのレンダーパイプライン、アセット負荷、入力設計がそのまま課題になる。Android XR対応だけを見ず、プロジェクトの足場を一緒に見直す必要がある。

UnrealはOpenXRベースの高品質XR資産で見る

確認項目

Unreal Engine向けの公式ガイドでは、Unreal EngineのXR開発サポートがOpenXR標準に基づくこと、Android XR Extensions for UnrealがAndroid XR固有の機能を補うことが説明されている。高品質な3D表現、既存VR資産、BlueprintやC++でのXR実装を持つチームには入口になる。

確認したいのは、レンダリング品質だけではない。OpenXR Plugin、Android XR Extensions for Unreal、入力マッピング、手のトラッキング、目線、顔トラッキング、パーミッション、Google Play配布時の品質ガイドラインまで含めて見る必要がある。特に目線データなどは権限の扱いが絡むため、デモ段階からプライバシー説明と許可取得の設計を外さないほうがよい。

Godotはオープンソース資産とOpenXR Vendors Pluginで見る

条件

Godot向けの公式ガイドは、GodotのXR開発サポートもOpenXR標準の上にあり、Android XR固有機能にはGodot OpenXR Vendors Pluginを使うと説明している。Godot 4系で軽量にXR実験をしたいチーム、オープンソースエンジンを軸にしたいチームには、検証の候補になる。

公式ガイドでは、Android export、Minimum SDK 34、One-Click Deploy、Android XR固有のvendor extension、Action Mapによる入力なども扱われている。ここでの注意は、「公式対応がある」ことと「自分たちの用途で成熟している」ことを分けることだ。UnityやUnrealと同じ成熟度だと決めつけず、必要なextension、ツールチェーン、デバッグ手順、チームのGodot経験を確認したい。

OpenXR直書きは標準APIと拡張差分を追えるチーム向け

評価基準

Android XRのOpenXR公式ページでは、OpenXR 1.1 specificationと一部vendor extensionsのサポートが説明されている。OpenXRは、複数XRデバイス向けに共通APIで作るための標準だが、実際の体験ではベンダー拡張やデバイス差分も見ることになる。

OpenXRから直接入るのは、エンジンに依存しない描画、独自ランタイム、既存のネイティブXR基盤、複数デバイス横断を強く意識するチーム向けだ。標準APIを使えることは魅力だが、trackables、raycasting、anchor persistence、object tracking、QR code tracking、depth textures、passthrough、scene meshing、eye-tracked foveation、space warp、performance metricsのような項目を、どのデバイスとruntimeでどう扱うかまで追える体制が必要になる。

入口	向いているチーム	最初の確認	注意点
Unity	既存Unity XR資産、AR Foundation、XR Interaction Toolkitがある	Unity 6、URP、Vulkan、OpenXR package	既存アセットの負荷と入力設計を再確認
Unreal	高品質3D、Blueprint/C++、既存VR資産がある	OpenXR Plugin、Android XR Extensions for Unreal、権限	レンダリング負荷と権限説明が重くなりやすい
Godot	軽量なXR実験、OSSエンジン、Godot 4系資産がある	OpenXR Vendors Plugin、Minimum SDK 34、Android export	成熟度を用途別に検証する
OpenXR	標準API、独自基盤、デバイス横断を重視する	OpenXR 1.1、vendor extensions、入力/性能機能	拡張差分を追う体制が必要

導入前チェックリスト

項目	内容	見方
Androidアプリチーム		既存アプリから切り出せる小さな体験、短い表示、着用状態の切り替え、エミュレータと実機の確認範囲を見る。
XR/ゲームチーム		エンジン、バージョン、レンダリング設定、入力方式、Engine HubとDirect Previewの前提を確認する。
プロダクト責任者		動いた後に見る指標として、視認性、入力疲労、プライバシー、配布条件、運用負荷を先に決める。
停止条件		体験価値が弱い、実機前提が重い、alpha変更を吸収できない、ユーザー説明が難しい場合はPoCで止める判断を残す。

見栄えのよいデモより、詰まりどころと続ける条件を早く見つけることに価値がある。

Androidアプリチーム向け

確認項目

既存Androidアプリチームが最初に見るべきなのは、XRという言葉の大きさではなく、既存アプリの中から切り出せる小さな体験だ。

チェック	Yesなら進める	Noなら先にやること
グラス向けに短く見せる情報がある	GlimmerのUI検証へ進む	既存画面の棚卸しから始める
着用中/未着用/切断の状態変化を扱う必要がある	Device Availability APIの検証へ進む	状態別に止める処理を決める
音声、通知、短い確認で成立する	Projected体験のPoCを作る	複雑な入力を減らす
Android StudioやGradle依存を更新できる	Jetpack XR SDKの最小構成を試す	ビルド環境を先に整える
実機検証の計画がある	エミュレータと実機の役割を分ける	エミュレータだけで判断しない計画にする

Android開発環境そのものを見直すなら、<a href="https://googl-watch.blog.mo-gmo.com/googl-47-android-cli-10-antigravity-skills-bench/">Android CLI 1.0の導入判断</a>も参考になる。Android XRの検証では、SDK、エミュレータ、ビルド、エージェント支援、テストの流れが一緒に絡むため、CLIや開発支援ツールの整備も効いてくる。

XR/ゲームチーム向け

評価基準

XR/ゲームチームは、既存資産から逆算するほうが早い。Unityで作っているならUnityのAndroid XRガイド、Unrealで作っているならUnrealガイド、Godotで作っているならGodotガイド、エンジンに依存しないならOpenXRページから見る。

最低限、次の順番で確認したい。

1. 既存プロジェクトのエンジン、バージョン、レンダリング設定を確認する。
2. Android XRで使いたい入力を決める。手、目線、コントローラ、音声、タッチのどれが主役かを分ける。
3. Engine HubとDirect Previewの前提を満たせるか見る。
4. 1週間程度のPoCで、ビルド、接続、反復速度、視認性、入力疲労、performance metricsを確認する。
5. Google Play配布や品質ガイドラインを本番前提の課題として別管理する。

この段階では、見栄えのよいデモよりも、詰まりどころを早く見つけるほうが価値がある。Direct Previewで反復が速くなるとしても、チーム内で環境を再現できなければ、1台の検証機に依存したPoCで止まってしまう。

プロダクト責任者向け

停止条件

プロダクト責任者は、技術チームが「動いた」と言ったあとに見る項目を先に決めておきたい。Android XRはフォームファクタ、入力、装着、視界、音声、プライバシー、配布条件が絡む。既存アプリの新機能追加よりも、体験検証の不確実性が高い。

停止条件も明確にしておく。

• 対象デバイスが曖昧なままになっている。
• 実機検証の予定がなく、エミュレータ確認だけで進めようとしている。
• 既存アプリのどの体験を切り出すか決まっていない。
• Developer Previewやalpha APIの変更を吸収する余裕がない。
• グラス利用時の通知、録音、カメラ、視線、位置情報の説明方針がない。

このどれかに当てはまるなら、今は本番計画ではなく調査タスクに落とすのがよい。Android全体の利用者向け更新を追う場合は、<a href="https://googl-watch.blog.mo-gmo.com/googl-17-june-android-drop-2026/">June Android Drop 2026の確認点</a>も合わせて読むと、GoogleがAndroid上でどの体験を拡張しているかを見渡しやすい。

まず作るならどんなPoCがよいか

1. 1状態表示だけに絞る

   次に見るべき1行、確認すべき1つの状態、短い音声応答など、最小の体験から始める。

2. 2着用中と未着用を分ける

   グラスの利用状態に合わせて処理を切り替え、通知や音声が過剰にならないかを見る。

3. 3実機で視認性を確認する

   エミュレータで基本フローを確認し、実機で読みやすさ、入力、疲労感を確認する。

4. 4反復速度を測る

   手の入力、目線フォーカス、レイキャスト、空間アンカーのうち1つを選び、Direct Previewで調整時間を比べる。

5. 5捨てられる範囲に収める

   alpha依存関係の変更が出ても、PoCを捨てられるスコープと期間にしておく。

完成度より、短い検証で続ける理由と止める理由を明確にする。

既存アプリなら「状態表示だけ」に絞る

最小スコープ

既存Androidアプリから始めるなら、最初のPoCは欲張らないほうがよい。たとえば配送、現場作業、学習、翻訳、ナビゲーション、メッセージ確認のようなアプリなら、最初は「次に見るべき1行」「確認すべき1つの状態」「短い音声応答」だけを切り出す。

PoCの成功条件は、次のように小さく定義できる。

• display glasses向けに、1つの状態を短く読める。
• 着用中と未着用で処理を切り替えられる。
• 通知や音声が過剰にならない。
• エミュレータで基本フローを確認し、実機で視認性と入力を確認できる。
• alpha依存関係の変更が出ても、PoCを捨てられる範囲に収まっている。

エンジン資産なら「反復速度」を測る

成功条件

Unity、Unreal、Godot資産があるチームは、最初から完成体験を作るより、Engine HubとDirect Previewで反復速度が上がるかを測るほうがよい。たとえば、手の入力、目線フォーカス、レイキャスト、空間アンカーのうち1つだけを選び、従来のビルド/デプロイとDirect Previewで、1回の調整にかかる時間を比べる。

ここで見るべき指標は、華やかな映像ではない。

見る指標	なぜ必要か
セットアップ再現性	1人の環境でしか動かないPoCを避ける
1回の変更から確認までの時間	XR開発の試行回数に直結する
入力の安定性	手、目線、コントローラの違いで体験が崩れないかを見る
実機での視認性	エンジン内の見た目と装着中の見え方がずれるため
権限と説明	目線、顔、カメラ、空間情報は利用者説明が重要になる

次に読むなら

参照した主な情報源

• Android Developers Blog: What’s New in Android XR: Tooling, Engine Support, and Ecosystem Updates

https://android-developers.googleblog.com/2026/06/what-is-new-android-xr.html

• Android Developers Blog: Android XR Updates for Unity, Unreal, and Godot

https://developer.android.com/blog/posts/android-xr-updates-for-unity-unreal-and-godot

• Android Developers: Set up the Jetpack XR SDK

https://developer.android.com/develop/xr/jetpack-xr-sdk/set-up-sdk

• Android Developers: Check device availability at runtime for audio glasses and display glasses

https://developer.android.com/develop/xr/jetpack-xr-sdk/glasses/check-availability

• Android Developers: Build UI for display glasses with Jetpack Compose Glimmer

https://developer.android.com/develop/xr/jetpack-xr-sdk/jetpack-compose-glimmer

• Android Developers: Enhance app experiences with perception using ARCore for Jetpack XR

https://developer.android.com/develop/xr/jetpack-xr-sdk/arcore

• Android Developers: Android XR Engine Hub

https://developer.android.com/develop/xr/engine-hub

• Android Developers: Set up Direct Preview in the Android XR Engine Hub

https://developer.android.com/develop/xr/engine-hub/direct-preview

• Android Developers: Develop with Unity for Android XR

https://developer.android.com/develop/xr/unity

• Android Developers: Develop with Unreal Engine for Android XR

https://developer.android.com/develop/xr/unreal

• Android Developers: Develop with Godot for Android XR

https://developer.android.com/develop/xr/godot

• Android Developers: Develop with OpenXR

https://developer.android.com/develop/xr/openxr

更新履歴

1. 2026年6月15日

   Android Developers Blogで、Android XR Developer Preview 4と関連ツール、ライブラリ、エンジン対応の更新が整理された。

2. 2026年6月16日

   Jetpack XR SDK、Glimmer、Projected、ARCore for Jetpack XR、Engine Hub、Direct Preview、Unity、Unreal、Godot、OpenXRの公式ページを確認した。

3. 実装前の再確認

   Android XR SDK、Jetpack XR SDK、Glimmer、Projected、ARCore for Jetpack XRはDeveloper Previewやalphaライブラリを含む。

4. 記事の位置づけ

   この記事は製品・開発者向け情報の確認を目的としており、投資助言ではない。

実装前には、公式ページでバージョン、対応デバイス、権限、配布条件を再確認する。

• 2026年6月16日: Android Developers Blog、Jetpack XR SDK、Glimmer、Device Availability API、ARCore for Jetpack XR、Engine Hub、Direct Preview、Unity、Unreal、Godot、OpenXRの公式ページを確認して初版を作成。
• Android XR SDK、Jetpack XR SDK、Glimmer、Projected、ARCore for Jetpack XRはDeveloper Previewやalphaライブラリを含むため、実装前には公式ページでバージョン、対応デバイス、権限、配布条件を再確認してほしい。
• Alphabet Watch JapanはAlphabet Inc.およびGoogleとは非提携の独立ブログです。この記事は製品・開発者向け情報の確認を目的としており、投資助言ではありません。