XIA Wiki

Appearance

Gemma 4 × Quest 3：オンデバイスLLM推論の構築ガイド ​

🤖 AI再構成 — Notion の作業記録 Gemma4×Quest3 を元に、他の Quest 3 関連記事との関係を踏まえて再構成しています。

Quest 3 のスタンドアロン環境で Google の小型 LLM Gemma 4 をローカル推論させ、パススルーカメラ映像に対して解析を行うための検証・構築記録。

関連記事 ​

方針まとめ ​

観点推奨
対象モデルGemma 4 E2B から始める（モバイル寄り）
E4B は重くなりやすいので使用しない前提
推論の起動常時推論は避ける。A ボタン押下時など手動トリガーから
理由負荷・発熱・バッテリー・UX

開発手順（推奨順序） ​

1. 開発環境を固定 ​

Unity / Android / JDK / Quest 前提を最初に固める。

  • Unity: Android ビルド、IL2CPP、ARM64
  • Min SDK 32、Target SDK 34
  • Quest 3 実機前提

2. Unity プロジェクト作成 ​

ベースは URP blank project か、Meta の Passthrough Camera API サンプル を参照する構成。

必要パッケージ（用途により選択）:

  • Meta XR 系
  • OpenXR、XR Management
  • Input System、UGUI、URP

3. Input System 方針を最初に決める ​

Input System only を推奨。旧 UnityEngine.Input と混在させると実機で例外が出る可能性あり。

  • Quest コントローラ → OVRInput
  • キーボード系 → UnityEngine.InputSystem

4. パススルーカメラを先に成立させる ​

最優先。Gemma を入れる前に、Quest 3 のカメラ映像が Unity 上で表示されることを実機で確認する。

順序が重要:

カメラ表示 → 中央クロップ保存 → 推論接続

公式 SDK を使用していれば大きな問題にはならないはず。

5. Android Manifest と権限 ​

Quest 3 のパススルーカメラには manifest 設定が重要。

  • HEADSET_CAMERA
  • USE_SCENE
  • PASSTHROUGH
  • 対応デバイス metadata

これが不足すると、アプリが起動してもカメラ入力は成立しない。

6. 画像入力は中央クロップで始める ​

フルフレームではなく 中央クロップ + 縮小 + JPG 化 が推奨。

今回の採用値:

  • サイズ: 512x512
  • JPG quality: 85
  • 中央クロップ

7. Android bridge で LiteRT-LM を呼ぶ ​

Unity から直接 Gemma 4 を扱う専用導線はないため、以下の構成が必要:

Unity (C#) → C# wrapper → Android plugin (.androidlib) → bridge → LiteRT-LM 0.10.0

8. モデルファイルを Quest 3 に配置 ​

今回はモデルを APK に同梱せず、端末側のアプリ用ストレージ に置く前提。

  • 配置先は applicationId に依存 → パッケージ名を変えるとパスも変わる
  • Gemma 4 を使うアプリを複数作る場合は、全アプリからアクセスできる場所への配置が理想（要検証）

9. 最初のプロンプトは短く ​

最初の用途は「画像中央の物体名を短く答える」程度に絞ると安定。

  • 画像を先、テキストを後に与える
  • 短い英語プロンプトで、日本語の短い物体名だけを返させる

注意: プロンプトに「これは Quest3 のパススルー画像です」という説明を含めると、AI 出力内容にも高頻度で「Quest3 の〜」という関係ない文言が混入する。

10. UI に状態遷移を表示する ​

Quest 3 内では PC コンソールが見えないため、状態を UI 上に出すとデバッグしやすい。

状態の例:

  • WaitingPermissions
  • WaitingCamera
  • WaitingModel
  • InitializingModel
  • Ready
  • Analyzing
  • Error

最初は AI の返答欄とデバッグ状態表示は分けるべき。

ハマりどころ ​

JDK / Gradle / LiteRT-LM の整合性（最重要） ​

LiteRT-LM 0.10.x と Unity 既定の JDK 環境が噛み合わず、class file version 65.0 と 61.0 の不一致が発生。

対策: Android Studio の jbr を使い、Unity と Gradle の両方から JDK 21 系を参照させる。

LiteRT-LM の API 差分 ​

LiteRT-LM は更新で API が変わることがある。 ライブラリ更新時は「ビルドが通るか」だけでなく、実機で推論まで確認する前提で。

モデル配置の権限問題 ​

adb shell mkdir で先にサブフォルダを作ると shell 所有になり、モデルファイルが存在していてもアプリ側が WaitingModel のまま。

安全な順序:

  1. アプリを一度起動して保存先を作らせる
  2. その後 adb push

製品化に向けた追加観点 ​

プライバシー設計 ​

パススルー画像には、机上資料・PC 画面・室内の機密物・個人情報が入り得る。

  • 一時画像をどこに保存するか
  • いつ削除するか
  • ログに残すか

を明確にする必要あり。

パフォーマンス測定 ​

今回は「成立確認」が主目的。製品レベルでは以下を別途測る:

  • 推論時間
  • メモリ使用量
  • 発熱
  • バッテリー消費
  • UX 上の待ち時間

フォールバック設計 ​

GPU/GPU 初期化失敗時に CPU/CPU へ一度フォールバックする構成を採用。 Quest 3 では毎回理想的に GPU 初期化できる前提で組まない方が安全。