シリコンが届く前にハードウェアを検証する

シリコン待ちに対する従来の答えは、座って待つことだ。現代の答えは、ハードウェアの下流にあるものをすべて先に構築し、部品が到着する前にすべてをグリーンにしておくことだ - そうすればあなたのハードウェアは競合他社よりも速くRakuAI上で出荷される。

平日の仕事の合間ずっと考え続けていた決断が、週末が始まったときキッチンテーブルで待っていた。製品ターゲットをAR1+からAR2 Gen1へと切り替える。シリコンが到着する前に、新しい仕様の下流にあるものをすべて構築しておく。そうすれば、シリコンが実際に到着したとき、検証は90日目からではなく初日から始まる。

ハードウェア製品にはどれも、仕様は存在し、検証計画は存在し、テストハーネスは存在するのに、実際のシリコンだけが存在しない、という段階がある。従来の答えは座って待つことだ。現代の答えは、ハードウェアの下流にあるものをすべて先に構築し、部品が出荷される前にすべてをグリーンにしておくことだ。

この週末はまさにそれだった。ターゲットプラットフォームは正式にAR1+からAR2 Gen1へと移行し、エンジニアリングとしての対応は、私たちの誰もまだ新しいプラットフォームに触れていないうちに、新しいプラットフォームが必要とする検証インフラを即座に構築することだった。

何が着地したか

5つある。すべてこの週末に着地した。

• AR2 Gen1デバイスの立ち上げとセンサー統合インフラ
• Wi-Fi 7接続性とトラッキング安定性のテストスイート
• 熱と電力の検証フレームワーク
• 指標分析とレポート機能を備えたCIスモークテスト
• AR2 Gen1ハードウェア検証ドキュメントと本番基準の仕様

すべてフィーチャーフラグでゲートされており、AR1+のコードパスは引き続き動作し、既存のランタイムには何も退行が生じない。これらのPRを着地させたエージェントは、地味な規律を正しくこなした。すべての新しいファイルはビルドフラグの裏に隠されており、すべてのAPI追加は非破壊的であり、対象となるAR2デバイスがまだ存在しないにもかかわらず、すべてのテストがCIで実行される。テストはシミュレートする。そのシミュレーションは、インターフェースのずれ、欠落したエクスポート、壊れたセンサーフローを捕捉するには十分な質だ。

これは77コミットの週末だった。そのコミットのほとんどは、私が手に取ることのできないデバイスのためのものだ。

なぜこれが理にかなっているのか

いくつか理由がある。

ハードウェアと一緒に出荷されるハードウェア検証は、6か月遅れて着地するハードウェア検証だ。 この週末に書かれた熱と電力のフレームワークは、最初のAR2開発キットが私の机に届いたその日に使われる。その3か月後ではない。プラットフォームの最初の熱に関する退行は、人間がデバイスが熱いことに気づくのではなく、既存のテストによって捕捉される。

デバイスのないテストハーネスも、それでもテストハーネスだ。 シミュレートされたセンサートレースに対して実行される。それらのトレースはAR1+時代のものと仕様から来ている。完璧ではない。だがインターフェースのバグ、統合のバグ、指標収集のバグは捕捉する。実際のシリコンの下でしか現れないバグは捕捉しない。それでかまわない。これらが捕捉するバグは、実ハードウェアが手元にある最初の週を費やして探し回るはずだったバグであり、今やその必要はなくなった。

ハーネスを書くという行為が仕様を明確にする。 日曜の夜までに着地した本番基準ドキュメントの半分は、週末の初めにはあいまいな意図としてしか存在していなかった。検証テストを書くという作業が、仕様を具体的な数字へと強制した。フレーム予算。熱設計の範囲。Wi-Fi 7の安定性のしきい値。ハーネスがドキュメントを研ぎ澄ませた。それが本当の成果物だ。

エージェントはこの切り替えをどう扱ったか

AR1+からAR2 Gen1への切り替えは、最初はきれいには扱われなかった。週末の途中、エージェントは、新しいコードパスが「AR2」と言うべきところで「AR1+」を参照するPRを着地させた。それが起きたのは、イシューの組み立てがそのリネームを明示していなかったからだ。修正は「ドキュメントとCopilotの指示におけるAR1+ vs AR2デバイスの不一致を修正」と題した別のPRで、121か所の個別の参照を一掃して揃え直した。

これは、1人の人間がすべてのコードを書く場合には起きない種類のことだ。人間なら、進めながらそのままリネームしていくからだ。エージェント駆動のワークフローでは、リネームより前に作られたイシューをエージェントが拾い、忠実に古い名前を書いてしまうことで起きる。対処法は、エージェントが入力として読むドキュメントを現在の実態と完全に同期させ続けること、そしてリネームのPRをそれ自体独立した作業として書くことだ。

私が構築しているのは、エージェントのドキュメントがチームのドキュメントでもあるようなシステムだ。ドキュメントが嘘をつけば、エージェントも同じ方向に嘘をつく。それは、私が正しくやろうとしているワークフローの特性であって、バグではない。

特にWi-Fi 7のテストスイートについて

これはこの週末の中で最も誇りに思っているものだ。

AR2 Gen1の仕様は、オフロードされたレンダリングとテザリングされたコンピュートのためにWi-Fi 7接続性を前提としている。実際のWi-Fi 7はWi-Fi 6Eほど安定しておらず、失敗モードも異なる。この週末に書かれたテストスイートは、失敗モードのスイート(スループットの劣化、断続的な損失、再認証の嵐)を特徴付け、それぞれの下でのランタイムの挙動に境界を設ける。ランタイムはすべての失敗を許容できるわけではない。テストスイートの仕事は、ランタイムがどの失敗を優雅に劣化させて乗り切り、どの失敗では大きく失敗するのかを具体的にすることだ。

これが重要なのは、接続が瞬断したときにユーザーが体験しているAR体験がカクついてはならないからだ。ランタイムは、瞬断の長さに応じて1フレーム、2フレーム、あるいは20フレームのあいだローカルレンダリングにフォールバックし、接続性が戻ったときに再収束しなければならない。そのロジックは仕様の中であいまいな意図として存在していた。この週末の後、それはテストケースとして存在するようになった。

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

2つある。

もしあなたがARグラスについて考えているハードウェアパートナーなら、このエンジンが同梱する検証フレームワークは、それが競合他社よりも速くあなたのハードウェア上で出荷される理由の一つになるだろう。このフレームワークは移植可能だ。新しいデバイスターゲットの追加は、数百行のコードとデバイス固有のテストベクトルで済む。高くつく部分はすでに支払い済みだ。

もしあなたがレイテンシに敏感なオンデバイス推論について考えているAIラボなら、AR2 Gen1の仕様が前提とするレイテンシ予算は公開されている。センサーから描画までのエンドツーエンドのトレースは今まさに計測されつつあるので、あなたのモデルがその予算の中に収まらなければならないとき、推論に実際にどれだけの予算が残っているかを見ることができる。それが、11月にあなたと交わしたい会話だ。

週末で77コミット。ドキュメントで締めくくった。それは締めくくり方として正しい種類の週末だ。