Ray-Ban Meta Display アプリ開発（DAT 使用） — 環境構築と実機接続

1. はじめに

今回は、Meta社が2026年にDeveloper Preview提供を開始した Ray-Ban Meta Displayの実機を入手したので、弊社が提供するAI対話サービス「Up-Agent ray-ban」向けの開発に着手しました。

Ray-Ban Meta Displayは、グラス本体に直接アプリをインストールするのではなく、Meta Wearables Device Access Toolkit（DAT SDK）というSDKを使い、スマートフォン側のアプリからグラスを制御する構成を取ります。
DAT SDKを使うことで、グラスのカメラとディスプレイを利用できます。

特徴的なのは、グラス本体とのペアリングやDAT SDKへのアプリ登録、グラス個体のDeveloper Mode切り替えといった導入まわりの手続きを、自作アプリ自身ではなくMeta公式の「Meta AIアプリ」が仲介する点です。
本記事では、これからRay-Ban Meta Display向けの開発を始める人が最初に知っておくと時間を節約できる、環境構築とハマりどころを扱っていきます。

2. 全体構成 — グラス・DAT SDK・Meta AIアプリ・自作アプリの関係

環境構築の詳細に入る前に、グラス・DAT SDK・Meta AIアプリ・自作アプリの4者がどう関係しているのかを図にまとめました。

自作アプリはDAT SDKを依存として組み込み、BLE経由でグラスのカメラ・ディスプレイを制御します。
一方、マイク・スピーカーはDAT SDKの管轄外で、標準のBluetoothプロファイル経由で扱います。
また、Bluetoothペアリングそのものや、アプリ登録・グラス個体のDeveloper Mode切り替えといった導入まわりの手続きは、自作アプリではなくMeta公式の別アプリ「Meta AIアプリ」が仲介します。
この4者の役割分担を最初に押さえておくと、次章以降のハマりどころも理解しやすくなるかと思います。

3. 開発環境のセットアップ

3.1 必要なもの

DAT SDK（mwdat-core / mwdat-display / mwdat-camera 等）はMaven CentralではなくGitHub Packagesで配布されており、最終的にはどのやり方でもこのGitHub Packagesリポジトリへの依存解決に行き着きます。

SDK本体は facebook/meta-wearables-dat-android で公開されており、導入の入口としては大きく2通りが用意されています。

• 公式サンプルプロジェクトCameraAccess / DisplayAccess をクローンし、それをベースに手を加えていく方法。
  GitHub Packages依存やmanifest設定が最初から一式組まれた状態で始められるため、とにかく早く動かしてみたい場合に向いています。
• 既存または新規のプロジェクトに、GitHub Packagesの依存関係を自分で追加していく方法。
  自社の既存アプリに組み込みたい場合や、プロジェクト構成を自分好みにしたい場合はこちらになります。

今回は後者（新規プロジェクトに自分で依存を追加する方法）で行いました。
具体的には、依存を解決するために read:packages スコープを持つGitHubの個人アクセストークン（classic）が必要で、settings.gradle.kts にMeta公式のGitHub PackagesリポジトリをMavenリポジトリとして追加した上で、トークンを local.properties（またはCI環境なら環境変数）経由で渡します。

Display機能（グラスへのテキスト/画像/ボタン表示）を使うには、SDK v0.7以降で必須となったDAM（Device Access Toolkit App Model） を有効にする必要があります（詳細はGetting Started、Android Display実装ガイド を参照）。
※ SDK v0.9.0 以降はDAMが常時有効設定となったため設定不要となりました。
新規プロジェクトなら最初からDAMベースで組んでおくのが無難です。

実機が無い期間はMeta公式の Mock Device Kit（Developer Center から辿れます）で開発を進められますが、後述するようにMock環境と実機とでは挙動が異なる部分（特に接続まわり）があるため、最終的には実機での検証が欠かせませんでした。

4. 実機接続までにハマりやすい罠

ここからが本記事の本題です。Ray-Ban Meta Displayは「Bluetoothでペアリングさえできれば動く」という単純なデバイスではなく、複数のレイヤーで別々の許可・設定が必要です。

4.1 manifestのmeta-dataに数字だけの文字列を使うと登録が壊れる

DAT SDKのDeveloper Mode設定は公式ドキュメント通りに書くとこうなります。

<meta-data android:name="com.meta.wearable.mwdat.APPLICATION_ID" android:value="0" />
<meta-data android:name="com.meta.wearable.mwdat.CLIENT_TOKEN" android:value="0" />

ここで android:value=”0″ のように中身が数字だけの文字列だと、aapt2がこれをTYPE_INTとしてコンパイルしてしまいStringではなくなります。

SDK内部はBundle.getString(key)で読むため、型がIntだとnullが返ってしまい、以下のようなログが出ていました。

E MetaWearablesConfig: Failed to read metadata from manifest: com.meta.wearable.mwdat.APPLICATION_ID, the app might be misconfigured

さらに厄介なのは、この状態でもWearables.startRegistration(activity)を呼ぶとMeta AIアプリへの画面遷移自体は起きるため、一見動いているように見えることです。
実際にはディープリンク先のパラメータが空になっており、登録が正しく完了しません。

対策: android:valueに生の値を書かず、resValueで文字列リソース化してから@string/…で参照します。

// app/build.gradle.kts defaultConfig 内

resValue("string", "mwdat_application_id", "0")

resValue("string", "mwdat_client_token", "0")

<meta-data android:name="com.meta.wearable.mwdat.APPLICATION_ID" android:value="@string/mwdat_application_id" />

meta-dataに文字列を期待するライブラリ全般に言える教訓ですが、特に“0”や“1”、“true”のような数値・真偽値に見えるリテラルは危険です。

4.2 「Bluetoothペアリング」「アプリ登録」「グラス個体のDeveloper Mode」は全部別物

Wearables.createSession(AutoDeviceSelector())がNo eligible device foundのまま失敗し続ける場合、Bluetoothペアリングが完了していても、以下を全部クリアする必要があります。

1. Bluetoothの実行時権限（BLUETOOTH_CONNECT/BLUETOOTH_SCAN）を取得しているか。
   Android 12以降ではmanifestに宣言するだけでは有効にならず、実行時にダイアログでユーザー許可を得る必要があります。
2. アプリ単位のDAT登録（Wearables.startRegistration）が完了し、registrationStateがREGISTEREDになっているか。
3. Meta AIアプリ側で「このグラス個体」のDeveloper Modeを有効化しているか。
   アプリ単位の登録とは別に、デバイス単位でMeta AIアプリの設定内からグラス個体名を選んでDeveloper Modeを有効にする必要があり、これを行うとグラス本体にDAT用のコンポーネントがインストールされます。
4. クライアント側のSDKバージョンと、グラスにインストールされたDATコンポーネントのバージョンが合っているか。
   ズレていると後述の接続エラーになります。

4.3 セッションは作れるのにSTARTING直後にSTOPPING / STOPPEDになる

createSession・session.start()までは成功しSession state: STARTINGのログも出るのに、直後にSTOPPING→STOPPEDになってaddDisplayまで辿り着けないことがあります。

このログの時刻付近を見ると、SDK内部のタグに核心的な原因が出ていました。

E DAT:CORE:SessionChannel: DAM session started but DWA did not report its version

E DAT:CORE:DATSession: Session channel error: START_ERROR_DAT_APP_ON_THE_GLASSES_UPDATE_REQUIRED

START_ERROR_DAT_APP_ON_THE_GLASSES_UPDATE_REQUIREDは文字通り「グラス側のDATアプリの更新が必要」という意味です。

前項でMeta AIアプリ経由でDATコンポーネントをインストールした直後は、グラス本体を再起動しないと反映が完了しないことがあるというのが実際に踏んだ最後の落とし穴でした。
再起動後はSession state: STARTED → Display state: STARTEDまで到達し、無事レンズへの表示に成功しました。

このエラーはAGENTS.mdによると「DeviceSessionError.DAT_APP_ON_THE_GLASSES_UPDATE_REQUIRED」としてアプリ内で検知が可能でした。エラーハンドリングの際はこちらを活用するとよさそうです。

5. グラス単体で何ができるのか — できること・できないこと

DAT SDK経由で見た場合、Ray-Ban Meta Displayは基本的に入出力デバイスとして振る舞います。

• 入力: カメラ（映像/静止画）、マイク（音声。ただしDAT SDKの管轄外で、標準のBluetoothプロファイル経由）
• 出力: ディスプレイ（テキスト/画像/ボタン等の宣言的UI）、スピーカー（Bluetooth経由）
• 操作: captouch（テンプル部のタップ）のみ。Neural Band操作もこのタップにマッピングされる
  

実機検証では、以下のような制約（一部は公式ドキュメントにも記載あり）がいくつかあることが分かりました。

• back gesture（2本指テンプルタップ）は、アプリの状態に関わらず表示セッションそのものを終了させます。 アプリ内の「戻る」操作として乗っ取ることはできないため、戻る操作は必ず画面内のボタンとして実装する必要があります。
• 記事執筆時点ではNeural Bandのシステムジェスチャー（グラスホーム画面表示 / Meta AI呼び出し）でグラス表示がグラスOSに奪われても、アプリ側はこれを検知する手段が一切ありません。
  セッション状態・表示状態・エラーのいずれのイベントも発火せず、コンテンツ送信APIも成功を返し続けます。
• ジェスチャーの独自割り当てや、他アプリの操作を無効化するようなキオスクモード的な制御は一切できません（プロトコルレベルで公開されているイベントはクリック・戻る・エラーの3種類のみ）。

6. スマートフォン側アプリの役割

グラス本体にはアプリ実行環境が無く、演算能力もカメラ・ディスプレイの入出力を賄う程度に限られています。
音声認識・自然言語理解・応答生成のような重い処理をグラス側で完結させることはそもそも不可能で、状態管理・ビジネスロジック・外部サービスとの通信は全てスマートフォン側のアプリが担う設計が前提になります。
つまりRay-Ban Meta Display向けの開発は、「グラスに何を表示させるか」を考える以前に、普通のアプリとして、DAT SDKというI/Oデバイス制御レイヤーをどう薄く安全に扱うかという設計課題だと捉えるのが実態に近いです。

DAT SDK自体がまだPreview段階で仕様変更もあり得るため、直接依存をアプリ全体に染み出させず、薄いラッパー越しに使うことをおすすめします。

7. まとめ

Ray-Ban Meta Display向けのアプリ開発は、これまでのAR/MRグラス開発とは全く異なる制約と向き合う作業でした。
グラス本体はあくまで入出力デバイスで、実行環境・状態管理は全てスマートフォン側アプリが担うという明確な役割分担のもと、DAT SDKと付き合っていく必要があります。
これからRay-Ban Meta Display向けの開発に着手する方にとって、少しでも遠回りを減らす助けになれば幸いです。
SDKは今後も更新が続くと見られるため、本記事の内容も執筆時点（2026年7月〜8月）のバージョンに基づく点はご留意ください。