シリーズ: AI とともにコードを学ぶ

最初のコミットの前、最後の土曜日

最初のコミットに先立つ設計上のマイルストーン。

純粋な設計だけの最後の土曜日 紙の上での3か月が、コミット1へと収束する 編成10体のエージェント デモ8件を仕様化 フォルダ構成を描画 API表面を下書き 特許10年前のIP コミット #1 まずワークフローを設計する。コードベースはそれを何年も反映し続ける。 AR1+の仕様を固定 - レイテンシ予算、熱設計、センサー能力
コードのない3か月が、いずれ考古学的に発掘されるべき1つのコミットへと収束していく。

2027年に出荷されるエンジンは、コミット1が行われる前に自分のチーム、自分のデモ、自分のAPIを知っていたエンジンであり、2025年に走り出して即興でやった数十のエンジンではない。RakuAIは、コードベースがそれを何年も反映できるよう、四半期をかけてワークフローを設計した。

これは最初のコミットが入る前の最後の土曜日だ。来週末にはランタイムのリポジトリが開く。SDKのリポジトリが開く。ドキュメントのリポジトリが開く。エージェントたちがイシューキューに取り組み始める。実際のコードが始まる。

その一文がここまで来るのに1年かかった。この製品の下にある特許ポートフォリオは10年かかった。作業が設計から実装へと移る前に書き留めておきたいのは、この3か月の準備作業から学んだことだ。ここでの教訓は、今後2年間コードベースが反映することになるものだからだ。

コードなしの3か月で何をやり終えたか

正直さを強制するために、リストにして書き出しておく。

エージェント編成が固まった。 定義された役割を持つ10体のエージェント。プロダクト、SDK、スタジオ、マーケティング、オペレーション、AI・データ戦略、Codex開発サブエージェント、デベロッパーリレーションズ、戦略パートナーシップ、そして全体を統括するエージェントガバナンス。それぞれにシステムプロンプト、ツールセット、他のエージェントとのやり取りのセットがある。編成は、エージェントがセッションの開始時に毎回読む場所に文書化されている。

デモスイートが仕様化された。 8つの代表的デモ。それぞれに、書かれた説明、実証すべき能力のリスト、推定される複雑さ、そしてそれが住むことになるSDKフォルダ内の場所がある。「これは何のためのものか」と尋ねるスタジオは、自社のユースケースに対応する動くサンプルを得ることになる。

SDKのフォルダ構成が描かれた。 アプリ。モジュール。アセット。ドキュメント。設定。各トップレベルフォルダには定義された目的がある。各サブフォルダには明確な慣習がある。今後1年間で入ってくるコードは、正しい場所が存在するがゆえに正しい場所に収まる。

モジュールのAPI表面が下書きされた。 HUDレンダラー。ジェスチャー入力。視線トラッキング。マルチプレイヤー同期。オーバーレイアニメーター。音声制御。各モジュールの公開インターフェースは疑似コードでスケッチされている。エージェントは、安定した契約に対して疑似コードを実際の実装に置き換えることになる。

ハードウェアターゲットが固定された。 AR1+スマートグラスの仕様が、エンジンの主要ターゲットとして最終化された。レイテンシ予算。熱設計の範囲。センサー能力。この仕様が、以降のあらゆるアーキテクチャ上の決定を強制する関数になる。

特許ポートフォリオが文書化され、監査された。 この製品を支える、10年前に遡るメガネ型フォームファクターのIPは読み直され、継続出願は顧問弁護士とともにレビューされ、どの発明が請求されているかについての公的な説明は一貫している。IPが基盤だ。コードベースはその上に構築されるものだ。

公開のエンジニアリングログがキューに入った。 このブログは来週の土曜日、最初の定期投稿とともに公開される。これより前の4つのエントリは、夏のあいだに行われた設計作業の公開版だ。ここから先は週次のペースになる。

何もやらないうちにエージェント駆動ワークフローについて学んだこと

自分が知っていると思っていることのほとんどは、いずれ間違いだったと判明するだろう。それが正直な最初の所見だ。紙の上でワークフローを3か月設計することは、本番でワークフローを走らせることとは同じではない。実際のコードの最初の1か月は、予想していなかったものを表面化させるはずだ。

とはいえ、コミットしてもいいと思ういくつかの直感がある。

エージェントは新奇な部分よりも退屈な部分のほうが得意だろう。 テレメトリの配線、ビルド設定、テストハーネス、ドキュメントの一斉整備。これらはパターンが明確に定義されているため、エージェントがきれいに着地させるタスクだ。新奇なアーキテクチャ上の判断(新しいサブシステムの境界、新しいスレッディングモデル、新しいAPI表面)は、パターンがそれほど明確でないため、エージェントが苦戦するタスクだ。正しい分業は、アーキテクチャの作業は自分のものとして保ち、実装の作業をエージェントに委譲することだ。

フレーミングの作業こそが実質的な作業になるだろう。 ゆるく組み立てられたイシューは、大まかに正しいPRを生む。精密に組み立てられたイシューは、精密に正しいPRを生む。今後1年で最も複利的に効いてくるスキルは、エージェントが着手するイシューを組み立てるのがうまいことだ。土曜日の朝のほとんどは、そのフレーミングに費やされることになるだろうと予想している。

レビューがボトルネックになるだろう。 5体のエージェントが並行してPRを生成すれば、たった1人の人間レビュアーはおよそ土曜日1日で飽和する。防御策は、キューの深さを小さく保つこと、初回コメントに対してエージェント同士でレビューさせること、そして自分が実際に読んでいないものはマージしないという規律だ。その規律は書き留めた。それが100件のPRが並ぶ土曜日という現実に触れたときどう持ちこたえるかは、これから分かる。

エージェントはテストを通過するスタブを書くだろう。 最も心配している失敗モードは、エージェントの実装がプレースホルダーの値を返し、テストがたまたまそのプレースホルダーに対して通過し、コードベースが「自分が何をしているか」についての嘘を育ててしまうというものだ。この監査パターンは書き上げてあり、定期的に実行することにコミットしている。その頻度が、監査を省略したい誘惑に対して持ちこたえるかどうかは、まだ open な問いだ。

この先にとって特許がなぜ重要なのか

特許ポートフォリオについて、具体的に書き留めておきたいことがある。このプロジェクトの中で最も誤解されやすい部分だからだ。

特許は既知の競合に対する防御的な堀ではない。空間ARグラスというカテゴリにはまだ既存プレイヤーがいない。特許は訴訟戦略でもない。私たちは訴える商売をしているわけではない。

特許が何であるかというと、許可証だ。私と共同発明者が10年以上前に出願したメガネ型フォームファクターの発明は、現代のARグラスを可能にするアーキテクチャ上のパターンをカバーしている。それらのパターンは今や、このカテゴリで何かを作ろうとする者にとって当たり前の前提になっている。先に出願していたということは、後発組にはない行動の自由と、後発組が作り出せない信頼をパートナーに対して持てるということだ。

来週の土曜日に開くコードベースは、その許可の上に構築される。以降のあらゆるアーキテクチャ上の決定は、基盤となるIPの問題が既に解決済みだと前提できる。それは堀よりも静かな種類の優位性だ。そしてより長持ちする優位性でもある。

次の土曜日に向けて持っていくもの

短いリストだ。何か本気のことが始まる前日に立てる、あの種の意図だ。

  • ランタイムのリポジトリを、きれいなREADMEときれいな仕様へのリンクとともに開く。最初のコミットは、いずれの考古学的発掘が見つけてほしいと思うものであるべきだ。
  • エージェントのキューに最初の10件のイシューをファイルする。それぞれが鋭くスコープされている。それぞれがタグ付けされている。それぞれに、エージェントが自己チェックできる受け入れ基準がある。
  • 公開のエンジニアリングログを、ペースを示すような投稿から始める。正直で、具体的で、感傷を排したものだ。
  • エージェントが書けるコードは、手で書かない。エージェントがチームだ。彼らを使う。
  • 自分がフレーミングする前に、エージェントにアーキテクチャに関わる何かを触らせない。アーキテクチャ上の判断は自分のものだ。
  • 適切な時間にノートPCを閉じる。これはマラソンであって、一発のスプリントではない。

この先、公開ログを読む人へのメモ

ブログは来週末に公開される。これより前のエントリは設計文書の回顧録だ。来週末以降のエントリはライブのエンジニアリングログになる。ペースは週次だ。声のトーンは正直だ。ワークフローを走らせている規律は、コードベースが反映することになる規律そのものだ。

もしあなたがどこかのAIラボにいて、これを未来に読んでいるなら、あなたが見ているエンジンは、ワークフローがどう見えるべきかを知っていた誰かによって、コードが1行も書かれる前に設計され、そのワークフローに合わせて構築されたコードベースだ。それが、このエンジンと2025年に走り出した他の十数個のエンジンとの違いだ。

もしあなたがハードウェアパートナーで、自社のデバイスがどのエンジンの上で出荷されるべきか考えているなら、このエンジンがターゲットとするAR1+の仕様は本物であり、このエンジンが同梱するデモスイートは仕様化されており、SDKが提供する開発者向けの物語はマッピングされている。他のエンジンはそのすべてを後付けしなければならない。このエンジンはそうする必要がない。

もしあなたが開発者で、いずれこの上に何かを構築することを考えているなら、SDKはあなたのことを念頭に置いて設計されている。8つの製品カテゴリに対応する8つのデモ。あなたの足元で変わることのないフォルダ構成。実装が始まる前に固定されたAPI表面。

もしあなたが競合他社で、これを読んでいるなら、設計フェーズは終わった。ビルドフェーズは来週末から始まる。驚かれるより先に知っておいてもらったほうがいい。

あと1週間で最初のコミットだ。今日は、純粋な設計作業だけの最後の土曜日だ。次にこのブログを書くとき、コードは既に始まっている。

あなたのモデルが指揮するために設計されたエンジン

1行のコードが書かれる前、10年前の特許基盤の上に構築された - RakuAIは、LLMメーカーとハードウェアパートナーが自信を持って構築できる空間ランタイムだ。

← すべての記事