公開2か月、フードの下では何年分

たいていの「AIネイティブ」エンジンは、エディタにチャットパネルを後付けするだけだ。RakuAIはモデルを毎フレームの制御入力として扱う — そして2か月が経った今、その論旨はスライド資料ではなく、出荷されるコードになっている。

この土曜日の計画は、減速して考えることだった。週末全体でわずか3コミット。公開ログを始めて以来最も少ない件数だ。エージェントは意図的に控えめに走らせている。私の注意は新しいコードの出荷よりもアーキテクチャに向いている。コードベースは週末を、始めたときとほぼ同じ状態で終える。それが、私がやっていた種類の作業にとって正しい状態だ。

ちょうど2か月前、公開のランタイムリポジトリは空のREADMEだった。その裏にあるエンジンと特許ポートフォリオはそれよりずっと遡る。書く価値のある種類の週末とは、書き手が棚卸しをするときのものだ。だからこれはそういうものだ。

このエンジンが今日、実際どんなものか

もし読んでこなかった誰かに一段落でRakuを説明しなければならないとしたら、その説明はこうなるだろう。

C++で書かれ、安定したC APIを通じて公開される、UnityとUnreal SDKバインディングを備えたクロスプラットフォームARランタイム。主にARグラスをターゲットとし、今日利用可能などんなハードウェアの上でも動く(現在はMeta Questのパススルー向けに立ち上がりつつあり、デスクトップとモバイルのプレビュービルドがある)。基盤の段階から、AIはエディタの機能ではなくランタイムの関心事であるという前提のもとに設計されている。サブミリメートルのアンカリングに対応している。標準が存在する場合はOpenXRが準拠目標だ。コードベースは、公開のイシューキューを通じて作業する自律コーディングエージェントを開発チームに含めて構築されている。

その段落は、初日には意欲的なミッションステートメントだっただろう。今やそれは、リポジトリの中身の説明になっている。

この2か月で驚いたこと

3つある。

エージェント駆動のワークフローは、予想していた以上にスケールした。 始める前は、自律エージェントが孤立したPRの中では動くのに、多くのマージにわたってぐちゃぐちゃになるコードベースを生み出すのではないかという心配があった。そのぐちゃぐちゃは起きていない。2か月時点でのこのコードベースは、人間のチームから2年目に引き継いだコードベースよりも一貫性がある。理由は、毎週末書いてきた規律だ(より小さなキュー、より早いレビュー、レビューの独立性のための複数ベンダーのペアリング、入力としてのドキュメント)。それらの規律は機能する。

ハードウェアの切り替えは、恐れていたよりコストが低かった。 10月初旬に、製品ターゲットをAR1+からAR2 Gen1へと移すことは、コストが大きく見えたため何日か考え込んだ決断だった。実際のコストは数件のPR(徹底的なリネームの一掃、ドキュメントの見直し)だった。コストが小さかった理由は、早い段階で確立されたモジュール型アーキテクチャだ。デバイスクラスの境界について知る必要のなかったサブシステムは変更する必要がなかった。知る必要があったものは、よく定義された表面を通じてきれいに変更された。それが、アーキテクチャを早期に描くことの配当だ。

パートナーシップの会話が、計画よりも早く起きている。 年末までは「エンジンを作り、デモを出荷し、それからパートナーシップの会話をする」というモードでいると予想していた。実際の順序は「エンジンを作り、その過程でパートナーシップの会話をして次に何を作るべきかを知り、それからその会話が必要とするものに合ったデモを出荷する」というものだった。NTT QONOQ。Meta。次のいくつかは、まだ名前を出すつもりはない。会話は今、デモよりも鋭い。それは良い場所にいるということだ。

アーキテクチャがどこで固まったか

もう見直すことはないと予想しているアーキテクチャ上の決定の短いリスト。

• ランタイムはC++であり、安定したC APIを通じて公開される。他の言語バインディングはC++の直接の上にではなく、C APIの上に乗る。
• SDKは初日から複数バインディングだ。UnityとUnrealはファーストクラスだ。Godotはロードマップにある。Webネイティブはロードマップにある。ボトルネックはC APIであって、バインディングではない。
• サブシステムはDLLだ。それぞれに公開インターフェースがあり、あるサブシステムの内部に別のサブシステムが手を伸ばすことはない。その表面はレビューされたPRだ。
• AIはエディタの機能ではなくランタイムの関心事だ。エンジンに住むAIの作業は、毎フレームのシミュレーションステップで動く。エンジンに住むクラウドLLMの作業は、ランタイムで音声パイプラインに統合される。どちらも制作ツールの中のパネルではない。
• OpenXRは、標準が当てはまるところでの標準だ。ベンダー固有のコードはフィーチャーフラグとプロバイダーパターンの裏に置かれる。新しいOpenXR準拠デバイスターゲットを採用することは、ベンダー固有のグルーレイヤーであって、ランタイムの書き直しではない。
• 開発プロセスは設計上、複数ベンダーだ。あるコードを書いたモデルは、それをレビューするモデルにはなれない。ある役割において現在最も優れているモデルを持つラボが、別のラボがより優れるまでその役割を担う。

まだ見直すだろうと予想しているもの。

• オンデバイス推論とクラウドLLMの意図とのあいだの正確な分業。TFLiteの作業が成熟し、クラウドLLMインターフェースが実際のパートナーによって使い込まれるにつれ、これはより鋭くなっていくだろう。現在の線引きは暫定的だ。
• 体験定義ファイル形式の形。骨格はある。スキーマは進化するだろう。フォーマットが安定するまでに少なくとも1回のメジャーバージョンの上昇があると予想している。
• マルチプレイヤーAR向けの状態同期の置き場所。今日、低レイテンシのデルタチャネルはある。正しい長期的な答えがピアツーピアのメッシュなのか、ホストされる権威サーバーなのか、あるいは何らかのハイブリッドなのかは、まだ決着していない。12月に出荷される2人プレイヤーのデモが、その判断に情報を与えるだろう。

12月の本番準備完了への道

私は静かに、エンジンが「パートナーが本気のデモをその上に構築するために本番準備が整っている」という12月のマイルストーンを狙ってきた。それは公開ローンチではない。私が、半ダースの粗削りな部分について事前に警告することなくパートナーチームにランタイムへの構築を始めるよう招待してもいいと思える、社内的な基準だ。

その基準をクリアするためにまだ起きなければならないこと。

• ランタイム向けのAIサブシステム(ビヘイビアツリー、ナビゲーションメッシュ、群衆シミュレーション、感覚システム、決定木)。現在は設計文書の中で骨組みだけができており、実装は12月と1月最初の週末に着地する。
• Windows MSVCのビルドのクリーンさ。10月以来、実際にVisual Studio 2026の下でランタイムをビルドしていない。それが一悶着になるだろうとかなり確信している。実際にやったときに、それについて書くつもりだ。
• UnityとUnrealの両方のバインディングを通じて、音声パイプラインとクラウドLLMが接続された、些細ではないAR体験をエンドツーエンドで実証する正規のサンプルパッケージ。
• 現場のデバイスにモデル更新を配布するためのフェデレーテッド同期のパス。暗号の部分は、スタブ品質ではなく本番品質である必要がある。
• ランタイムのアップデーター。パートナーの開発キットに新しいビルドを出荷し、それがきれいにインストールされる必要がある。

それがリストだ。それをクリアするのに6週間。12月のコミット量は多くなるだろう。

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

もしあなたがこの2か月、公開ログを読んできたなら、エンジンがリアルタイムで組み上がっていくのを見てきたはずだ。ペースは速く、規律は本物であり、アーキテクチャ上の決定は文書化されている。それが、このエンジンが構築されているエンジニアリング文化だ。あなたがこの上に何かを構築するなら、それがあなたが一緒に働くことになるエンジニアリング文化だ。

もしあなたが、本気の会話を始めるべきか考えているパートナーなら、会話は今、デモよりも鋭く、それは意図的なものだ。デモを作ってから後付けであなたのニーズに合わせようとするより、あなたの製品が実際に何を必要としているかを聞いて、それが何を作るべきかを形作るほうがいい。12月に届けるものを形作る窓は、11月末まで開いている。

もしあなたが安定性を待っている開発者なら、安定性は12月の成果物だ。エンジンは今日、まだそれに対して本気の依存コードを構築することを勧められないほど活発に進化している。今日から2か月後には、推奨は違うものになっているだろう。

静かな土曜日。2か月が経った。来週末にはまた構築に戻る。