ChatGPT、Claude、Geminiからの指示を受け取るために作られた

「この製品は特定の1社のモデルの上でしか動かない」という時代は短い。RakuAIは、ChatGPTでもClaudeでもGeminiでも、あるいはあなたのモデルでも、どんなモデルでもリアルタイムでAR体験を駆動できるように作られている。最良のモデルを持ち込んでほしい。ランタイムの準備はできている。

今日クラウドLLMと統合しているほとんどのゲームエンジンは、あなたが予想する通りのやり方でそれをやっている。モデルがチャットパネルとしてエディタに取り付けられる。あなたはそのチャットパネルに向けて入力する。パネルは何らかのコンテンツやコードを書く。何が起きたのかまったく知らないランタイムは、後になってその結果の成果物を実行する。

それはRakuがやっていることではない。Rakuは、クラウドLLMからの指示を、制作上の便宜としてではなくランタイムの関心事として受け取るために作られている。この週末の作業は、それを明示的なものにした。

何が着地したか

この週末、ランタイム全体で118コミット。目玉となる部分はこうだ。

• クラウドLLMの応答をファーストクラスのランタイム機能として音声パイプラインに接続するXRAssistantService
• 複数プロファイルによるパフォーマンス最適化を備えた、視線トラッキングによるフォービエイテッドレンダリング
• OpenXRのXR_EXT_eye_gaze_interactionプロバイダー
• XRランタイム向けのハンドトラッキングとジェスチャー認識
• 71関節のスケルトンを備えたフルボディトラッキング
• アイトラッキングインフラにおける固視検出と滞留タイマー
• 高解像度パススルー、深度センシング、ライティング推定
• ホストサーバーとレイテンシモニタリングを備えたWi-Fi 7オフロードレンダリングパイプライン
• リアルタイムマルチプレイヤーARのポーズと状態同期のための低レイテンシデルタチャネル
• Android XR向けサブミリメートルアンカーサービス
• Android XRスタックを持たないAndroidデバイス向けARCoreセンサーブリッジ
• マルチレイヤーHUDコンポジターとオーバーレイAPI
• シーン理解のためのARサーフェスデモとルームビジュアライザーのサンプル

このうちいくつかは特に語る価値のある目玉だ。Wi-Fi 7オフロードレンダリングパイプラインはその一つ。XRAssistantServiceはもう一つ。どちらもパートナーシップを見据えた形をしている。

XRAssistantServiceと、それが実際何のためにあるのか

XRAssistantServiceは、これまでに私たちが出荷した中で最もきれいなパートナーシップ誘致型のエンジニアリングだ。その形はこうだ。

ランタイムには音声パイプラインがある。ユーザーは話す。音声認識はデバイス上でローカルに、低レイテンシで動く。そのテキストはアシスタントサービスにストリーミングされる。アシスタントサービスはそのテキストをクラウドLLMに渡す。クラウドLLMは、意図を表すトークンをストリームで返す。ユーザーが言ったことを踏まえて、AR体験が次に何をすべきかという意図だ。ランタイムはそのストリームを解析し、飛行中にランタイムのアクションへと変換する。応答のための音声合成もストリーミングされる。

ビルダーとラボに気づいてほしい部分は、LLMがユーザーの1ターンにつき1回しか呼び出されないわけではないということだ。音声パイプラインは(適切なバックエンドの対応があれば)ターンの最中もモデルへのトークンのストリーミングを続けることができ、モデルはランタイムが継続的に作用する意図を生成し続けることができる。それが、「クラウドLLMからの指示をランタイムの関心事として受け取る」ということの実際の意味だ。それはAR体験に貼り付けられたチャットボットではない。ランタイムが、モデルの意図のストリームを、ユーザーの視線と同じ優先度の制御入力として扱っているのだ。

このインターフェースは設計上、モデルに依存しない。ChatGPTもこれを動かせる。Claudeもこれを動かせる。Geminiもこれを動かせる。小さなオンデバイスモデルもこれを動かせる。アシスタントサービスのプロトコルに準拠した意図トークンのストリームを生成するものなら何でも、これを動かせる。この週末に構築したのは、そうしたモデルとランタイムの残り部分とのあいだの統合レイヤーだ。

もしあなたがそうしたラボのどこかにいて、これを読んでいるなら、これが私たちがあなたと話したい統合だ。私たちは、あなたのモデルがこのエンジンが話せる唯一のモデルであるという特別なパートナーシップを望んでいない。私たちが望むのは、あなたのモデルが、このエンジンが話せる最良のモデルになることだ。なぜなら統合はオープンであり、あなたのモデルが生み出す体験は、他の誰かのモデルが生み出す体験よりも良いものになるからだ。

Wi-Fi 7オフロードレンダリングパイプライン

これはもう一つの、パートナーシップを見据えた形をした部分だ。ARグラスには熱設計の範囲がある。その熱設計の範囲は小さい。その熱設計の範囲の中のコンピュート予算は、一部の体験がレンダリングしたいと望むものよりも小さい。従来の答えは体験のほうを妥協することだ。Wi-Fi 7の答えは、フレームの一部をテザリングされたコンピュートボックス(スマートフォン、ベルトパック、同じ部屋のデスクトップ)でレンダリングし、その結果をストリーミングすることだ。

この週末、オフロードレンダリングパイプラインがエンドツーエンドで着地した。ホストサーバーはどこでも動く。グラス上のランタイムはWi-Fi 7経由でホストと話す。フレームのレイテンシは監視されており、リンクが瞬断したとき(実際にするだろうが)、ランタイムはローカルレンダリングへと優雅に劣化できる。

これがパートナーにとってなぜ重要か。ハードウェアパートナーが、デスクトップクラスの体験を出荷するためにグラスにデスクトップクラスのGPUを搭載する必要がないということだ。コンピュートは、コンピュートが最も安価な場所にあればいい。重要なのはリンクだ。私たちはこのリンクを中心にランタイムを構築している。

OpenXRの足場

この週末のコミットの多くはOpenXR準拠のためのものだった。XR_EXT_eye_gaze_interaction。ハンドトラッキング。ARKitとARCore向けのプロバイダーパターン。このコードベースにおいてOpenXRが重要な理由は、それが、このエンジンをハードウェアパートナーをまたいで移植可能にしたいと私たちが望んでいるレイヤーだからだ。もしハードウェアパートナーがOpenXR準拠のランタイムを出荷すれば、このエンジンはその上に出荷できる。今月構築しているインターフェースは、意図的にベンダー固有側ではなく標準側にある。それが、このエンジンが中立であり続ける方法だからだ。

まだできていないことについて正直に

この週末に着地したもののいくつかはWIPだった。特にハンドトラッキングのPRはまだ不完全に配線されている。フォローアップで修正中の PoseStabilizer のリンクエラーがある。アイトラッキングは固視検出があるが、アプリケーションレイヤーとの滞留タイマーの統合はまだ終わっていない。フルボディトラッキングは入っているが、ジェスチャー認識の部分はまだもっとサンプルが必要だ。

これについてはっきりさせておきたい。というのも、エージェント駆動の開発作業のパターンとして、多くのWIPが同じ週に着地し、そのWIPはPRのタイトルに明示的に名付けられるからだ。もしこの週末のコミットログを読んでいくつかの場所に「[WIP]」を見かけたら、それは意図的なものだ。完全な成果物は今後2週間かけて揃っていく。

パートナーとビルダーにこれから読み取ってほしいこと

もしあなたが次の主要モデルを構築しているAIラボで、あなたのモデルの出力をシミュレーションステップの制御入力として扱うARランタイムに関心があるなら、私に話してほしい。XRAssistantService統合レイヤーは2025年11月にこのエンジンで出荷され、年末までには接続できる安定したインターフェースになる。

もしあなたがWi-Fi 7を搭載し、外部コンピュートの物語を持つARグラスを構築しているハードウェアパートナーなら、オフロードレンダリングパイプラインはまさにあなたのハードウェアが作られた対象のワークロードだ。ランタイムはそれに対応する準備ができている。

もしあなたが、このエンジンでどんな種類の体験を構築できるか考えている開発者なら、その答えはコミットログの中に見え始めている。ユーザーの発話の途中で応答する音声駆動のAR体験は実現可能だ。サブミリメートルのアンカリングを備えたリアルタイムのマルチプレイヤーARは実現可能だ。どちらに必要なコンピュートも、あなたの体験が必要とするものに応じて、グラスの上、あるいはテザーの先に存在する。

118コミット、大きな週末だった。土曜にラップトップを開いたときと日曜の夜とでは、このエンジンは違って見える。