エンジンを書く前にエージェントをマッピングする

あなたの空間ランタイムを構築するチームは、ランタイムそのものと同じくらい意図的に設計されるべきだ。RakuAIはチームの形、すなわち一人の人間とエージェント群から始めた。なぜならアーキテクチャは、誰がそれを構築するかの下流にあるからだ。

この土曜日は、傍から見れば時期尚早だと思われるようなホワイトボード演習に費やされた。製品の出荷にはまだ長い道のりがある。エンジンはまだリポジトリにすらなっていない。コードもない。デモもない。あるのはハードウェアロードマップ、10年以上前に遡る特許ポートフォリオ、そして次世代のARグラスがどうあるべきかについての明確なテーゼだけだ。そして私は今、台所のテーブルに座り、これを構築するエージェントたちをマッピングしている。

それは意図的なものだ。

エージェントが先に来る理由

このプロジェクトの段階における従来のやり方は、コードを書き始めることだ。リポジトリを開く。プルーフ・オブ・コンセプトを構築する。PoCが助けを求め始めたらエンジニアを雇う。MVPを出荷する。繰り返す。

私はこれまで3社を従来のやり方で立ち上げてきた。今回は違うやり方にすると決めた。このエンジンを構築するチームは、一人の人間と、定義された役割で働くAIエージェント群になる。エンジンのアーキテクチャ、SDKの形、コードレビューの規律、開発ループのケイデンス、これらはすべてチームの形の下流にある。もし先にチームの形を明らかにしなければ、実際にそれを構築することになるチームとは別のチーム向けに作られたエンジンで終わってしまうだろう。

というわけで、今日はチームの形を決める日だ。

ロースター

私が固めつつあるエージェントロースターと、それぞれが担うべき役割を以下に示す。

Productエージェント。 仕様を所有する。ハードウェアのアップデート、ベンダーのロードマップ、SDKの依存関係、公開リリースカレンダーを追跡する。Productエージェントは、このエンジンが何をすべきかについての正典的な情報源だ。他のエージェントは自分の作業を、Productエージェントによる仕様の解釈と照らし合わせて確認する。

SDKエージェント。 SDKそのものを所有する。ドキュメント、オンボーディングフロー、互換性テスト、パッケージの公開を担う。SDKエージェントは、生成されたドキュメント、サンプルアプリ、オンボーディング時のエラーメッセージという形で、開発者が最も頻繁にやり取りするエージェントになる。その成果物は、本物のデベロッパーリレーションズ機能のように感じられなければならない。

Studioエージェント。 ゲームスタジオやインディー開発者へのアウトリーチを担う。デモの準備。共同マーケティングの資料。スタジオ向けに特化したオンボーディングドキュメント。Studioエージェントの指標はコンバージョンだ。すなわち、我々と話をしたスタジオが、その後実際にこのエンジンで何かを出荷したかどうかだ。この指標はまだ遠い未来のものであり、Studioエージェントの日々の仕事は、それを生み出す関係性をゆっくりと積み上げていくことだ。

Marketingエージェント。 対外的な表層を所有する。プレスキット。もしその道が理にかなうならKickstarterの資料。インフルエンサーの追跡。ハードウェアイベントの資料。ランディングページのA/Bテスト。このエージェントの成果物は、世界が最初に目にするものだ。それは優れていなければならない。

Operationsエージェント。 ケイデンスを所有する。（私との）スタンドアップ。Notion／ガントチャートの管理。ボトルネックのアラート。エグゼクティブサマリー。Operationsエージェントは、毎週土曜日の始まりに私が確認するエージェントであり、私が他のことをしている間、平日に他のエージェントたちが何をしていたかを教えてくれる。

AI・データ戦略エージェント。 データフライホイールを所有する。SDKやグラスからテレメトリをキャプチャする。将来デバイス上で動くことになる小規模言語モデルを構築する。AIの堀を磨き上げる。これは、時間とともに最も複利的に成果が積み上がっていくエージェントだ。なぜなら、それが生み出すデータとモデルこそが、誰にも複製できない差別化要因になるからだ。

Codex Dev サブエージェント。 コードを書く。ランタイムAPIを統合する。UnityとUnrealのデモを構築する。技術的なオンボーディングでSDKエージェントを支援する。これは自律的なコーディングエージェントだ。指示の下で動く。自分で優先順位を決めることはない。

これが要となるロースターだ。定義された役割を持つ7体のエージェントと、それらの間の明確なインタラクション。

追加する3つの役割

要となるロースターだけで、ほとんどのところまではたどり着ける。だが、必要だと考えているのに元の草案になかった役割が3つある。この土曜日に追加する。

デベロッパーリレーションズエージェント。 GitHubのイシュー。Discord。Reddit。開発者が質問を投げかけたときに、SDKエージェントがまだそれに対応するドキュメントを持っていない場合に応答するエージェントだ。これはコンシェルジュの仕事だ。同時に伝道の仕事でもある。この役割に適した人物（あるいは適したエージェント）は、どれほどの量のマーケティング資料でも再現できない形で、スタジオやインディー開発者との信頼を築く。

戦略的パートナーシップエージェント。 B2Bのアウトリーチ。ライセンス交渉。ゲーミングカフェ、eスポーツ会場など、スタジオ以外の誰かが最初にこの製品を体験しうるあらゆる場所との共同マーケティング契約。これは、消費者向けではない収益チャネルを追いかけるエージェントだ。

エージェントガバナンスエージェント。 他のエージェントを監視するエージェントだ。アップグレードを提案する。バージョニングを管理する。あるエージェントが判断を誤ったときのロールバックを処理する。これは、私がこの種のワークフローにとって本当の意味でのブレークスルーだと考えている再帰性だ。これがなければ、エージェントたちはドリフトしていく。これがあれば、誰かが監視者を監視しているからこそ、彼らは時間とともに向上していく。

インタラクションマップはどのような形か

ホワイトボード版を簡略化すると次のようになる。

• エグゼクティブとしての監督（私）が頂点に立つ。
• エージェントガバナンスエージェントは私の下に位置し、その下にあるすべてを監視する。
• Product、SDK、Codex Devが技術的作業の三角形を形成する。
• Studioとデベロッパーリレーションズが、開発者向けの表層を形成する。
• Marketingと戦略的パートナーシップが、対外的な表層を形成する。
• OperationsとAI／データは、横断的関心事として下に位置する。

各エージェントは他のエージェントと明確なインタラクションを持つ。SDKはCodex Devと話す。StudioはMarketingと話す。Operationsは全員と話す。Governanceエージェントは全体を見守り、あるエージェントの成果物がその役割からドリフトし始めたときに介入する。

これは伝統的な企業の組織図ではない。ボックスの大半がAIエージェントであり、それらの間の接続の大半が自動化された引き継ぎであるワークフローの組織図だ。図の中で唯一の人間はトップにいて、枠組みづくりと判断の仕事を行う。それ以外はすべてエージェントだ。

なぜ今がこれをやるべきタイミングなのか

理由は3つある。

エンジンのアーキテクチャはチームによって形作られる。 ドキュメント、テスト、コードレビューのような横断的関心事は、エージェントがそこに参加するのであれば、初日からコードベースに設計として組み込まれていなければならない。もし先にコードベースを書いてから後でエージェントをそこに当てはめようとすれば、ほとんどの作業を二度行うことになるだろう。

特許ポートフォリオが、慎重に計画するための滑走路を与えてくれる。 この製品を支える特許は、10年前の先行技術だ。競争上のタイミングは「3カ月以内に出荷しなければ誰かに先を越される」というものではない。「正しいものを正しい瞬間に出荷する」というものであり、その瞬間は過去10年のどの時点よりも近づいているが、それでも計画のための四半期は許容できる。私はその四半期を使っている。

エージェント自体が設計される必要がある。 各エージェントにはシステムプロンプト、ツールのセット、ガードレールのセットが必要だ。エージェントを書く前にエンジンを書くということは、作業が始まってからチームを雇うということだ。それこそが、エンジンプロジェクトが、コードベースがそれを支えるように設計されていなかった役割にエージェントを無理やり押し込むことになる原因だ。

次にやること

来週の土曜日はSDKの設計に充てる。フォルダ構成、モジュールの表層、各パーツとの開発者インタラクションがどのような形になるか。その次の土曜日はデモスイートに充てる。正典的なサンプルアプリとは何か、それらが何を証明するか、何を教えるか。夏の終わりまでには設計フェーズが完了し、実際のリポジトリを開けるはずだ。

これは従来のベンチャーのペースからすれば遅い構築だ。だが、完成してしまえば遅くは見えないだろう。