週次ペースを始める

ブラウザの中の生成コンテンツで十分な場合もある。だが実際のキッチンの壁に固定された生成コンテンツこそが製品だ。これは、シミュレーションのすべてのステップであなたのモデルからの指示を受け取るために構築されているエンジンの話だ - ゼロ日目、公開の場で。

この土曜日から、このブログの定期的な週次ペースが始まる。これより下にある4つのエントリは、今年の夏の初めにあった設計文書の土曜日たちだ。エージェント編成、デモスイート、フォルダ構成、そしてコードが始まる前の最後の振り返り。ここから先のペースは週次だ。ブログが扱う対象そのものは新しいものではない。

私はARグラス、現実世界に固定された空間体験、そしてそれを駆動するランタイムのあるべき形について、10年以上考えてきた。その思考の一部は2010年代初頭に特許となり、今私たちが構築しているものの背後にあるIPを今も支えているメガネ型フォームファクターのポートフォリオになった。その一部は、日の目を見ることのなかったプロトタイプになった。ほとんどは、私が他の仕事をしているあいだ、バックグラウンドで動き続けていた。

この1年で変わったのは、世界の他の部分がついに追いついてきたということだ。コンピュートは十分小さくなった。光学系は十分良くなった。クラウドLLMは十分本物になった。オンデバイス推論は十分速くなった。10年早すぎたアイデアだった製品は、ようやく出荷できる製品になった。

そこで私は出荷を始めた。現在進行中のコードはすでに数か月分ある。コミットはプライベートリポジトリに存在しており、それを整理してコードベースを統合しながら、今こうして公開の場に持ち出しつつある。このブログは、ここから先の公開記録だ。

これからの数か月はどんな形になるか

この土曜日の計画の形を、これから来るものの一例として示す。

• ランタイム。今朝の机の上にはAR1+スマートグラス仕様の草稿がある。PDF、PowerPoint、Markdownの各バージョンがあり、LLMがそれについて推論でき、パートナーが読め、デザイナーがレビューできる。重要なのは仕様であって、フォーマットではない。フォーマットは読み手のためのものだ。
• main.cpp と、新しくチェックインされたランタイムのメインループの骨格。
• レイテンシトラッカーのヘッダーと実装スタブ。レイテンシは、このエンジンを定義する指標になるだろう。
• CI上のCMakeビルドワークフロー。すべてのプッシュがクリーンなマシンからのクリーンなビルドを得られるようにする。
• Copilotオンボーディングガイド。チーム内のエージェントが、チームがどう機能するかを知るためのものだ。

SDKのリポジトリも、この土曜日に独自の足場を得た。初期段階のUnity HelloARサンプル。初期段階のUnreal HelloARサンプル。両方のバインディング用のヘッダー骨格。パッケージ公開ワークフロー。

そのどれも出荷可能なものではない。だがすべてが、何かを出荷可能にする前に必要となるものだ。両方のリポジトリを、継ぎ目のところで意図的に結合させながら同時に動かしていくというこのパターンは、これから繰り返し登場するテーマになるだろう。

なぜ公開初日にスマートグラスの仕様なのか

仕様は意図的なものだ。ほとんどのエンジンは、まずランタイムアーキテクチャを選び、それに乗りそうな製品を後から探しに行く。私はこれを逆の順序でやっている。製品は、人々が現実世界で身に着けるARグラスであり、エンジンはその製品にとって正しい形でなければならない。だから、粗削りであっても仕様が最初に書かれる。

これはマーケティング文書ではない。強制関数だ。それは、エンジンがどんな種類のハードウェア上で動かなければならないか、レイテンシ予算は何か、AI表面が実際にはどう見えなければならないかを述べている。以降のあらゆるアーキテクチャ上の決定は、その仕様を指差し、「この決定は仕様に資するものか、それとも代わりに作りたい別のエンジンに資するものか」と問うことができる。後者のカテゴリこそが、エンジンプロジェクトが息絶える場所であり、私はこれまでもそこに近寄らなかったし、今後もそうするつもりだ。

なぜ初日にCopilotガイドなのか

この週末のもう一つの意図的な取り組みは、Copilotオンボーディングガイドだ。最初のバージョンは粗削りだ。今後10回は書き直されるだろう。だがこのガイドが存在するのは、エージェントがチームの一員であり、チームはチームがどう機能するかを知る必要があるからだ。

このガイドが述べているのは以下だ。

• 戦略は何か、そして私たちが作っていないエンジンは何か
• ロードマップはどこにあるか
• イシューはどうファイルされ、どう拾われ、どう閉じられるか
• 良いPRとはどんなものか
• レビュアーは何をすべきか(レビュアーは時に私であり、時に別のエージェントである)

「エージェントがドキュメントを読む」という枠組みは、単なる仕掛けではない。それは、週末は1人の人間、それ以外の時間は複数の自律的なコーディングアシスタントが継続稼働している、というワークフローを運用する上での実務上の現実だ。ガイドが悪ければ、作業も悪くなる。ガイドが良ければ、作業は正しくなり、レビューのコストは下がる。

なぜ今、公開ログなのか

いくつか理由がある。

特許は誰も語らない10年前の先行技術だ。私たちが語ってこなかったからだ。 このエンジンが遡るメガネ型フォームファクターの発明は、何年もかけて静かに認可され、継続出願されてきた。公開のエンジニアリング記録に、その実際の系譜を指し示させたい。空間ARは去年の夏に誰かが思いついた新しいものではない。この作業はずっと遡る。

パートナーシップの会話が始まりつつある。 ハードウェアパートナー、AIラボ、スタジオ。それらの会話は、デッキの代わりに読める公開のエンジニアリング記録があるときのほうが鋭くなる。デッキは整えられたバージョンだ。ブログは実際のバージョンだ。

開発ワークフローが本当に新しく、見せる価値がある。 公開フェーズの初日からチームにAIエージェントがいる。複数のベンダー。並行するブランチ。公開のイシューキュー。そのどれもこのプロジェクトのために発明されたものではない。異例なのは、これほど本気のものに対してそれをすべて同時にやることだ。教訓がまだ正直でいられるほど新鮮なうちに、それが起きている最中に書き留めておきたい。

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

もしあなたが大手AIラボのどこかにいて、これを読んでいるなら、ここに売り込みがある。このエンジンは、あなたのモデルからの指示を受け取るために明示的に構築されている。後付けではない。エディタパネルの中でもない。ランタイムの中で、シミュレーションステップで、毎フレームだ。アーキテクチャ上の決定はまさに今、公開の場で、明示的な文書の軌跡とともに起きている。あなたのモデルが、ユーザーが立っている実際の物理空間を理解する能力を向上させたなら、このエンジンこそが、その理解で何かをするための場所になる。

もしあなたが、いずれこの上に何かを構築することを考えている開発者なら、SDKはランタイムと歩調を合わせて動いている。UnityとUnrealのサンプルは、この週末の時点でSDKリポジトリに種として蒔かれている。まだ動かない。いずれ動くようになる。この段階で両方のバインディングが存在する理由は、6か月後にランタイムアーキテクチャが固定されてしまい、SDKがそれに合わせて自分を変形させなければならない、という瞬間を私が決して迎えないようにするためだ。

もしあなたが消費者として初期のシグナルを見ているなら、シグナルはこうだ。このエンジンは、最も面白い体験とは実際の場所におけるAR体験であり、AIこそがそれらの体験を反応させるものである、という前提のもとに構築されている。ブラウザの中の生成コンテンツで十分な場合もある。だが、あなたのキッチンの壁に貼り付いた生成コンテンツこそが実際の製品だ。

今日は土曜日だ。ブログは公開された。明日からまた構築に戻る。