エンジンが大人になった週末
構築中だったコードベースが、他者がその上に構築できるものへと変わる瞬間がある。RakuAIにとって、その瞬間はクリスマスと年末の間にあった276コミットの週末だった。
コードベースが前進する週末もあれば、コードベースがカテゴリを変える週末もある。クリスマスと年末のあいだの週末は、後者の種類だった。
各リポジトリにわたって276コミットが着地した。ランタイムは、研究プロジェクトをプラットフォームへと変える種類の表面積を育てた。空間アンカー。OpenXRコンポジション。オンデバイスの小規模言語モデル推論。本物の暗号を伴うフェデレーテッド同期。光通信チャネル向けハードウェア抽象化。そのほとんどは並行するエージェント作成のPRで着地し、2か月間走り続けてきた複数ベンダーのワークフローを通じてレビューされ、マージされた。
土曜の朝、私はコーヒーと、優先度の高いTODOでいっぱいのキューを前に座った。日曜の夜、私はラップトップを閉じたとき、土曜に開いたときとは違うエンジンを前にしていた。これは、何が出荷されたか、それが何を意味するか、そしてなぜ2026年が他の人々がこのエンジンを本気で受け止め始める年になると私が考えるかについての投稿だ。
大きな着地物
SLM推論のためのTensorFlow Lite C API。 これが私が最も興奮しているものだ。ランタイムは今、TFLite形式の小規模言語モデルを読み込み、ファーストクラスのランタイム操作としてそれに対する推論を実行できる。動機は単純だ。すべてのモデルがクラウドへの往復である必要はない。AR体験を駆動するAIの挙動の一部は、タイトで、集中していて、オンデバイスで動かせるほど小さい。TFLiteのパスがそれを私たちに与えてくれる。XRAssistantServiceを通じたクラウドLLMのパスが、もう片方の端を私たちに与えてくれる。エンジンは今や両方にまたがっている。
空間アンカー完成(Epic #555)。 完全な空間アンカーのライフサイクル。作成、永続化、デバイスをまたいだ共有、異なるセッションでの復元、期限切れ。永続化レイヤーはlibcurl HTTPを通じてクラウドにバックされており、暗号化レイヤー(AES-256-GCM、PBKDF2鍵導出)も同じ週末に着地した。アンカーは今やファーストクラスのランタイムオブジェクトだ。今日も、明日も、1か月後も、2人の異なる人が所有する2組の異なるグラスをまたいで、同じキッチンカウンターに仮想オブジェクトを配置する必要のあるAR体験が、機能する。
カルマンフィルタによるアンカーポーズの安定化。 小さなことだが、大きな意味を持つ。フィルタリングされていないアンカーのポーズは、ちょうど違和感を覚えるだけの揺れが出る。カルマンの状態予測フィルタリングを施したアンカーのポーズは、しっかりしていると感じられる。ランタイムは今やそのフィルタを自動的に適用する。上位のアプリケーションはそれを知る必要がない。
OpenXRコンポジションレイヤーマネージャーとアクションスペース。 11月からのOpenXR背骨の作業の続きだ。コンポジションレイヤーマネージャーは、1フレームがカメラパススルー、ユーザーの仮想コンテンツ、そしてあらゆるシステムオーバーレイを、正しい順序で正しいブレンドモードで組み合わせることを可能にするものだ。基盤的であり、過小評価しやすい。
共有アンカー向けの本番用AES-256-GCM暗号化とUDPピア発見。 これが「同じ部屋にいる友人とアンカーを共有する」ことを実際に安全に出荷できるようにするものだ。共有アンカーのプロトコルは、エンドツーエンドで認証付き暗号化を使う。ピア発見は、クラウドへの往復を経ることなく、ローカルでUDP経由で行われる。共有ARにとってのプライバシーとレイテンシの物語は本物だ。
光チャネル向けハードウェア抽象化レイヤー(33件のセンサーTODOを解消)。 光リンクは、デバイスに存在する場合、今やRFリンクと対等な存在になった。両方とも、11月に着地した同じデュアルモードのリンクマネージャーの裏に抽象化されている。上位のランタイムは、配線上でどちらの無線が使われているかを気にしない。
フェデレーテッド同期が本物の暗号へと配線された。 フェデレーテッド同期のサブシステムは、秋のほとんどの間スタブ駆動だった。この週末、それは本物の実装を育てた。HTTPトランスポート、JSONエンベロープ、暗号署名検証。AI/MLのモデル更新は今や、フェデレーテッドな経路を通じて安全にデバイスに配布できる。
ベンダーの目SDK統合とトークン検証。 一握りのベンダー固有のアイトラッキングSDKが、今やOpenXRプロバイダーインターフェースの裏に配線され、ベンダーのライセンスレイヤー向けの適切なトークンベースの認証も伴う。
レンダラー全体にわたるGPUプロファイリング計測(15件のTODOを解消)。 パスごとのGPUタイミング、メモリ予算、パイプラインストール検出が今やライブになった。もしフレームが長引けば、どのパスが予算を食ったのか正確に見える。
ランタイムアップデーター機能(10件のTODOを解消)。 ランタイムは今、現場で自己更新できる。バージョン管理され、署名され、ロールバック可能だ。これは、必要になるまで誰も気づかない種類の配管作業であり、その時になって初めて、プラットフォームとアートプロジェクトの違いになる。
このペースから学んだこと
1回の長い休暇の週末で276コミットというのは、従来の開発ワークフローでは機能しないペースだ。このワークフローで機能するのは、私が満たし続けるキューに対してエージェントが並行して出荷するように構築されているからだ。クリスマスから年末にかけてこのペースで走った中でのいくつかの観察がある。
Epic構造がその存在価値を発揮した。 月の半ばあたりで、イシュートラッカーをEpic配下のサブイシューというパターンに切り替えた(ランタイムコアフェーズ1向けのEpic #506、空間アンカー向けのEpic #555、OpenXR拡張向けのEpic #508)。各Epicは、一貫性のある作業のまとまりを閉じる1つのPRを得る。エージェントはサブイシューを並行して実装するが、マージは1つのアトミックなEpicレベルのPRとして起きる。それがコードベースにずっときれいな履歴を与え、レビューを扱いやすくした。
TODO追跡システムは正しい一手だった。 今月の初め、コードベースを走査して TODO コメントを見つけ、それぞれについて優先度付きでGitHubのイシューを作成する自動化システムを追加した。クリスマスの追い込みが始まる頃までに、追跡対象のランタイムTODOは342件になっていた。エージェントは最優先のものから拾っていった。この週末で、そのうちおよそ150件を解消した。コードベースは12月初めよりも意味のある形できれいになっている。
リポジトリをまたぐマージのタイミングが重要だ。 この週末、いくつかのEpicにおいて、ランタイムとSDKは互いに数時間以内に変更を着地させなければならなかった。ランタイムが新しいC APIを公開したら、SDKは同じ日にそのバインディングを更新しなければならない。統合を正直に保つため、いくつかのSDKのPRを保留し、いくつかのランタイムのPRを同じ時間帯にマージした。
エージェントは自分の役割においてより上手くなってきている。 この週末に着地しているPRは、9月に着地していたPRよりも明らかにきれいだ。その一部はコードベースがより成熟してきたことによるものだ。その一部はワークフローがより規律あるものになったことによるものだ。その一部はモデル自体が、このコードベースが生み出す種類の作業においてより上手くなってきていることによるものだ。3つとも本物だ。
2026年に向けて、このエンジンはどこにいるか
チェックリスト版だ。
- AR1+からAR2 Gen1への切り替え:完了
- OpenXRの背骨:完了
- XRAssistantServiceを通じたクラウドLLMの意図統合:完了
- TFLiteを通じたオンデバイスSLM推論:完了
- 高精度オーバーレイのためのサブミリメートルのアンカリング:完了
- 永続化、共有、適切な暗号を備えた空間アンカー:完了
- Wi-Fi 7オフロードレンダリングパイプライン:完了
- デュアルモードRF/光リンクマネージャー:完了
- アイトラッキング、ハンドトラッキング、フルボディトラッキング:完了
- 複数プロファイル最適化を備えたフォービエイテッドレンダリング:完了
- センサーと光チャネル向けハードウェア抽象化:完了
- モデルとコンテンツ配布のためのフェデレーテッド同期:完了
- バージョン管理とロールバックを備えたランタイムアップデーター:完了
- マルチプラットフォームビルド(Linux、macOS、Windows MSVC 2026):完了
- テレメトリとOpenTelemetryパイプライン:完了
- 342件のTODOを追跡、今月約150件を解消:進行中だが、まとまりつつある
まだ完了していないもの。モデルレイヤーをシミュレーションステップに結びつけるAIサブシステム。ビヘイビアツリー。ナビゲーションメッシュ。群衆シミュレーション。感覚システム。決定木。それが、1月最初の週に着地すると予想している作業だ。ランタイムはそれらを受け入れる準備ができている。今日、このエンジンには骨組みがある。来週末には神経系を手に入れる。
パートナー、ビルダー、ラボにこれから読み取ってほしいこと
もしあなたが、このエンジンが2026年にあなたのデバイス上で出荷できるか見積もっているハードウェアパートナーなら、答えはイエスであり、それを現実にするための作業は、この時点ではほとんどがベンダー固有のグルーコードだ。エンジン自体は準備ができている。
もしあなたが、自社のモデルの推論予算をARランタイムのどこに最もうまく使えるか考えているAIラボなら、TFLiteのオンデバイスパスとクラウドLLMのXRAssistantServiceパスの両方が、今や本番品質だ。もしあなたのモデルがオンデバイス予算に収まるなら、シミュレーションステップの上で動かせる。収まらないなら、クラウドのパスが開いている。どちらにせよ、統合はモデルに依存せず、私はあなたのモデルがその背後にある最良のモデルになってほしいと思っている。
もしあなたが2026年にこのエンジンの上に何かを構築することを考えている開発者なら、この表面積は本物だ。C APIは安定している。SDKバインディング(UnityとUnreal)は本物だ。OpenXRの背骨は、このエンジンが複数のデバイスをターゲットにすることを意味する。このURLのブログは、このエンジンがどうやってここまで来たかの公開ログだった。あなたがこのプラットフォームに体験を持ち込むとき、そのエンジニアリング文化がどんなものになるか知りたければ、読み返してほしい。
276コミット、1年の終わり、大人になったエンジン。違う週末、同じワークフロー。来週の土曜日にはまた構築に戻る。
あなたのモデルをシミュレーションステップに載せる
RakuAIは、TFLiteを通じたオンデバイスSLM推論とクラウドLLMのパスの両方を出荷している - モデルに依存せず、本番品質で、あなたの重みを受け入れる準備ができている。空間ランタイムの中で、あなたの推論予算が最も遠くまで届く場所を見てみよう。