24/7稼働するエージェントチームはどう作られたか：SpaceXAIエンジニアのLauren Tan氏が判断をシステムに組み込むまで

一晩で20のPRを自動マージ、その背景には600以上のリファクタリングPR

Lauren 氏による本編の発表は、動画開始からおよそ六分後に始まります。彼女が引き継いだのは、実際に動作しているものの、グリーンフィールドプロジェクト特有のリスクを伴う GrokBot のコードベースでした。プロトタイプは急速に生成されましたが、コードには安定したガードレールがありませんでした。

Lauren 氏は、自身がコードを直接見ることはもうほとんどないと述べています。とある朝起きると、約20のPRがエージェントによって自動マージされていました。先月は約1000のPRを提出し、今月は12日目にして、すでに800件近くに達しています。

これらの数字はすべて彼女の自己申告によるもので、公開動画には独立して監査可能なリポジトリやPRのリストは添付されていません。これらは納品規模を示すものではありますが、コードの価値、欠陥率、一般的な生産性を直接証明するものではありません。

彼女はまた、なぜ積極的にエージェントにタスクを分割させるのかを説明しました。個々のPRは数十行の場合もあれば、数百行から数千行に及ぶこともあり、固定された上限はありません。彼女が重視しているのは、各コミットを可能な限りアトミックにして小さな変更を説明できるようにし、Git の履歴を、コンテキストの理解、変更のロールバック、欠陥の特定のためのツールとして使い続けることです。これはPRの数を増やすことではありません。四万行の巨大なPRは、たとえマージに成功したとしても、問題が実際にどこから始まったのかを答えるのは難しいでしょう。

最初に注目すべきは、これら四つの数字の関係です。

20件の自動マージPRは出力側であり、600件以上のリファクタリングPRはインフラストラクチャ側です。その間には再設計されたコードベースがあり、より賢いプロンプトだけではこのギャップを埋めることはできません。

GrokBot は当初、急速に生成されたグリーンフィールドアプリケーションでした。速度は速いものの、そのアーキテクチャは自然と「エージェントがその時点で最も都合の良い方法」へと成長していきます。各タスクは局所的に完了できますが、長期的に積み重なると、ディレクトリ、依存関係、プロセス、状態管理が互いに絡み合い始めます。エージェントはまだ変更を続けられるかもしれませんが、人間がそれを理解し信頼することはますます難しくなります。

Lauren 氏が選んだのは、エージェントのために作業環境を再構築することでした。彼女はこの Electron アーキテクチャを Dune と呼んでいます。目標は、エージェントが行う決定の数を減らし、構造が抽象的な原則を代わりに担うことです。

正しい経路を最短経路にする：Dune がエージェントをどう制約するか

Dune には非常に強い設計判断があります。エージェントは近道を好むので、最短経路を正しい経路として設計する、というものです。

これは「AI のためにより完全なコーディング規約を書く」というアプローチよりも具体的です。コーディング規約は、エージェントが毎回それを記憶し、理解し、積極的に従うことを要求します。一方、アーキテクチャによる制約は、エージェントが見ることのできる選択肢自体を直接変更します。

誤りの余地を減らす「規範を覚えておいて」を、エージェントが簡単には迂回できない仕組みへと変える

1. 機能単位のコロケーション1つの機能に関する状態、コンポーネント、ロジックは可能な限り同じ場所にまとめる
2. プロセス境界メインプロセスとレンダラープロセスの役割を明確にし、重い処理がUIを圧迫しないようにする
3. 依存関係グラフ検査レイヤーやプロセスをまたぐインポートはCIで機械的にブロックする
4. 危険なパターンの無効化エージェントが繰り返し悪用するパターンに対して、lintやコンパイル時のガードを設定する

第一の層は、機能のコロケーションです。機能の大部分のコードは同じディレクトリに置かれ、エージェントは状態、コンポーネント、ビジネスロジックを探すために複数の共有ディレクトリを横断する必要がありません。「自分はオンボーディングを変更している」と認識するだけで、主要な作業を対応する機能ディレクトリ内に制限できます。

第二の層は、プロセス境界です。Electron のメインプロセスとレンダラープロセスは、異なる役割を担います。計算や I/O が誤ってレンダラー側に入り込むと、UI の描画と時間を奪い合うことになります。60 FPS を維持するには、各フレームが約16ミリ秒しかないため、重いタスクが境界を越えると、簡単にカクつきを引き起こします。Dune は、明確なディレクトリ構造とインポートグラフのチェックを使用して、このような依存関係の越境を防ぎます。

第三の層は、既知の危険なパターンを直接禁止することです。Lauren 氏は二つの過激な例を挙げました。useEffect の直接使用を禁止し、通常のコードコメントも禁止しました。これらは必ずしも常に間違っているわけではありません。彼女が狙ったのは、エージェントによるこれらの反復的な悪用です。特にコメントは、モデルが PR 議論での一時的な意見を恒久的なルールとして書き記し、現在のコードとは無関係な歴史的な説明を残すことがよくあります。

これらのルールはすべてのチームに適しているとは限りませんが、背後にある方法論は移転可能です。エージェントが最も頻繁に取る悪い近道を見つけ、API、ディレクトリ、型、依存関係を通じて、そもそもその近道に入れないようにできるかを最初に検討します。

手動のリマインダーを CI へ：人間の判断をいかに早くシステムに組み込むか

コードレビューで繰り返し出てくる同じコメントは、まだシステムにコンパイルされていないルールです。

エンジニアが毎週「この依存関係はレンダラープロセスからインポートできない」「ここで共有状態を直接読んではいけない」「この機能は専用のディレクトリに入れるべき」とコメントしなければならないとしたら、チームは最も高価で遅い方法で制約を実行していることになります。つまり、エラーが発生するのを待って、人間が見つけるという方法です。

Lauren 氏が示した移行の順序は明確です。

最後の行は重要です。Rules、Skills、BugBot には価値がありますが、これらは比較的ソフトな制約です。エージェントはそれらを読み飛ばしたり、誤解したり、長時間のタスクの中で忘れたりする可能性があります。一方、アーキテクチャ、型システム、コンパイラ、CI は機械的な結果を返すため、「私は従いました」という言葉だけで回避することはできません。

彼女は Rust を具体的な例として挙げました。厳格なコンパイラと借用チェッカーは、コードレビューのかなり前に、ある種の大きなエラークラスを排除します。この例は、すべてのチームが Rust に移行すべきだと言っているのではありません。テクノロジースタック自体が、人間の介入なしに機械的に実行できるエンジニアリング上の判断の量を決定することを示しています。

つまり、人間がエンジニアリング判断から撤退したわけではありません。人間の仕事の位置が変わったのです。個々のPRで繰り返しリマインドすることから、事前にインターフェース、エラースペース、合格条件を設計することへと移動しました。

この事前設計にはリファクタリングの時間とトークンがかかりますが、その利益は最強のモデルだけのものではありません。境界が十分に明確になれば、能力の低いエージェント、新しく参加したエンジニア、さらにはコードベース全体に詳しくないプロダクトやデザインの担当者でも、同じガードレール内で安全に貢献しやすくなります。

検証能力が並列処理の上限を決める：エージェントは自分でプロダクトを起動できなければならない

アーキテクチャはコードをより整然とさせ、CI は既知の悪いパターンを防ぐことができます。しかし、その両方でも、ユーザーが見る機能が実際に使えることを証明することはできません。

Lauren 氏は、検証をエージェントのツールボックスの中で最も重要な能力と呼んでいます。ここでの「検証」は、単にユニットテストを実行することをはるかに超えています。エージェントはアプリケーションを起動し、ユーザーが報告した画面に移動し、操作を実行し、問題を再現し、CPU トレースやヒープスナップショットを収集し、変更を完了し、同じ経路で問題が解決したかどうかを確認できなければなりません。

このループの一部が欠けていると、人間が中継役になります。エージェントがコードを書き、人間が開発版を起動する。人間がボタンが反応しないことを発見し、コンソールエラーをコピーする。エージェントが修正し、人間がもう一度クリックする。単独のエージェントなら何とか連携できますが、十のエージェントが並行すると、同じ一人の人間がボトルネックになります。

機能マップは「エージェントがプロダクトのどこにあるのかを知らない」という問題を解決します。ユーザーは「左サイドバーが重い」と言うか、スクリーンショットと疑問符三つだけを送るかもしれません。しかし、コードベースに「ユーザーが見ている左サイドバー」というファイルは存在しません。機能マップは、ユーザーの視点からエントリーポイント、サブ機能、ショートカットキー、DOM セレクタ、コード上の位置を記録し、曖昧な報告を実行可能な経路に変換します。

この考え方は後に PStack に取り入れられました。Cursor の公式リポジトリで公開されている create-verification-skill には、今も同じ原則が残っています。コードベースからユーザーが実際に触れる UI を特定し、主要機能のマップを作成し、実際にプロダクトを起動し、少なくとも一つの機能を駆動し、証拠を保存し、環境をクリーンアップした後も保存した証拠を確認できることを確かめます。自分で実行していない検証スキルは、単なるドラフトに過ぎません。

Skills もテストされるべき：PStack はどのようにエージェントの失敗から生まれたか

Lauren 氏によると、PStack は最初に壮大な方法論を設計し、それを Skills に小分けにしたわけではありません。それは失敗の観察から始まりました。

エージェントが関連するコードを読まずに自信を持って根本原因を判断したため、まず証拠を検索することを要求するスキルが生まれました。エージェントが実際のアプリケーションを操作できなかったため、Control Glass と検証スキルが生まれました。エージェントがユーザーの言う機能を見つけられなかったため、機能マップが補われました。

能力の回帰テストSkillは失敗のサンプルから生まれ、そのサンプルに立ち返ってテストされなければならない。

具体的な失敗を観察する→実行可能なSkillとして記述する→評価基準を定義する→複数モデルで分離して実行する→回帰結果を比較する合格：コードベースに初めて触れるエージェントでもタスクを完了し、証拠を残せる

Skill を作成しただけでは終わりません。彼女は評価を「エージェントのユニットテスト」と理解しています。まずタスクの採点基準を設定し、隔離されたディレクトリまたは worktree で複数のサブエージェントを起動し、異なるモデルに同じタスクを実行させ、その後、コーディネーターエージェントまたは別のジャッジモデルが採点します。Skill を変更したら再実行し、目標とする結果に、より安定して導くかどうかを観察します。

彼女は、エージェントが自分がテストされていると認識して行動を変えないように、評価用ディレクトリに目立たない名前を付けることさえあります。スキルが、自分が評価されていると知っている場合にのみ機能するのであれば、その結果は信頼できません。採点は別のモデルによるクロスチェックも可能で、スキルの修正、タスクの再実行を繰り返し、失敗モードが実際に収束するまでループを続けます。

これはチームに非常に実用的な判断基準を与えます。Skill の品質はドキュメントの長さで証明されるものではありません。コードベースに初めて触れるエージェントがそれに従ってタスクを完了できるか、検査可能な証拠を残すか、別のモデルに変えても機能するか、失敗した時にスキル、環境、タスクのいずれに原因があるかを特定できるか、を見る必要があります。

このループはまた、チーム知識の形態を変えます。伝統的な経験は、しばしばシニアエンジニアのレビューコメント、口頭でのリマインダー、インシデントの記憶に散在しています。エージェントチームはそれらを、配布、実行、採点、回帰テストが可能なエンジニアリング資産に変える必要があります。

ローカルでの観察から自動マージへ：信頼は段階的に得るもの

Lauren 氏は、チームが初日から数百のクラウドエージェントを起動することを提案していません。彼女の順序は正反対で、ローカルから始め、ツール呼び出しを開き、エージェントが何を読んだか、何を読まなかったか、どのように失敗したかを観察し、その後、アーキテクチャ、検証、スキルを追加します。

ローカルでの検証が安定したら、タスクはクラウドに移行されます。彼女は Benny というエージェントの例を挙げました。エラーレポートが届くと、Benny はクラウドデスクトップを起動し、Cursor を実行し、同じ操作スキルを使って再現を試み、メインブランチがすでに修正されているかを判断します。ライブデモでは、問題がメインブランチで修正済みであることを確認し、残りのアクションは新しいビルドをリリースすることだけでした。それは「たぶんここだと思う」という言葉ではなく、再現結果、環境状態、次のアクションを提出しました。

信頼は段階的に獲得するモデル能力は一部に過ぎない。権限は証拠と可逆性に基づいて決定される。

1. ローカルでの観察エージェントが何を読み、どう失敗するかを把握する
2. 制御下での変更ディレクトリ、権限、タスク範囲を制限する
3. 独立検証実製品を実行し、証拠を残す能力を持つ
4. クラウド上での実行分離された環境、独立したブランチ、監査可能性を確保する
5. エラーのトリアージ再現、状態判断を行い、次のステップに引き継ぐ
6. 自動マージ機械的なゲート、短いロールバック、運用監視が整っている状態

公開版の Cursor Cloud Agents の実装は、より製品化されています。公式ドキュメントによると、各エージェントは独立した VM で実行され、承認されたリポジトリをクローンし、独立したブランチで作業し、ドラフト PR で引き継ぎます。ネットワークへの外向き通信、シークレット、監査、リポジトリ権限は、依然としてチームによる設定が必要です。Cursor のセキュリティノート では、デフォルトの引き継ぎプロセスに人間によるレビューを明確に組み込んでいます。

自動マージは、クラウドでの実行よりももう一段階ハードルが高いものです。前者はエージェントがどこで実行されるかを決めるだけですが、後者はエージェントがメインブランチを変更できるかどうかを決定します。この権限を開放するには、チームは少なくとも次のことを証明する必要があります。タスクの境界が明確であること。アーキテクチャが高リスクなエラーを機械的に防げること。エージェントが実際のプロダクトを実行すること。失敗の証拠が追跡可能であること。ロールバックパスが十分に短いこと。監視がリリース後の異常を検出できること。

プロダクトマネージャーやデザイナーが直接コードに貢献できるのも、同じ条件に基づいています。システムがまず、許容される変更範囲を十分に明確に絞り込み、コードベース全体に詳しくない人やエージェントが境界を越えにくくすることで、参加のハードルは本当に下がります。

PR 数は生産性ではない：この方法から学べること、そのまま真似できないこと

この共有は、大量のトークンを使い、コードベースを書き直し、エージェントに自動マージさせ、PR 数で効率を証明するという、高生産性の秘訣として誤読されがちです。

PR 数は、変更がいくつの小片に分割されたかを記録するだけです。一つの大きなタスクを十の PR に分割することもできますが、逆に十の PR が単なる小さな修正の場合もあります。PR 数には、欠陥率、手戻り、ロールバック、ユーザー価値、納品時間、保守コストは自動的には含まれません。

METR が2026年に開発者生産性実験を更新した際、非常に示唆に富む限界が示されました。2025年後半のツールの生データには加速の兆候が見られましたが、参加者の選択バイアス、低い報酬、複数人が同時にエージェントを実行することによる計時困難のため、研究チームはこれらのデータは非常に弱い程度の証拠しか提供しないと判断しました。研究アップデート では、並列エージェントによって「一つのタスクに費やされた人間の時間」の測定がさらに難しくなったと明確に指摘されています。

一人の高生産性エンジニアの PR 数は、生産性研究の代わりにはなりません。より適切なチーム指標は、以下を同時に見る必要があります。要件から検証可能な結果までの時間、人間の介入回数、欠陥とロールバック、検証証拠の完全性、変更の可逆性、そして最終的なビジネス成果です。

グリーンフィールドとブラウンフィールドでは、同じ改修方針は取れません。完全な新規アプリケーションは最も迅速に生成できる一方、ガードレールがないまま暴走しやすいため、初日からエージェントに適した境界を設計するのが有効です。成熟したコードベースに厳格な型、テスト、権限、大規模なエンジニアリング規範がすでにあるなら、新規プロジェクトよりもエージェントに向いている可能性があります。全面書き換えは、既存の構造が機械的な境界を提供できず、移行を段階的に検証できる場合にのみ検討に値します。

Lauren氏はまた、大手テクノロジー企業が人数も能力も経験も異なる人間のエンジニアのために構築した枠組み、規約、権限制限、誤操作防止機能が、そのままエージェントにも有効だと指摘しました。エージェントエンジニアリングは、突然現れた新しい学問分野ではありません。既存の優れたインフラの多くは、もともと人間の組織向けに設計されたガードレールを、モデル向けに再利用しているにすぎないのです。

モデル呼び出しや一晩の実行にかかるコストも、別途計算する必要があります。動画内のトークン投入からは再利用可能なコスト表が得られません。また、末尾にある特定のモデル、価格、能力についてのその場の議論は、製品更新により陳腐化するため、他チームの予算や成果を約束する根拠にはできません。

したがって、本当に再現可能な成果は「毎月1000件のPR」ではありません。人間の同期コストを段階的に下げる方法、すなわち、まずエージェントのエラーが起こる範囲を狭め、次にエージェントに結果を自律検証させ、繰り返し発生する失敗を評価済みの能力として書き出し、最終的に証拠に基づいて権限をさらに開放するという一連の流れこそが成果です。

24/7で稼働するエージェントチームが、人間の判断を不要にするわけではありません。判断のタイミングが、深夜にコードを一行ずつ確認する作業から、昼間にシステム設計や完了条件の定義、証拠の確認を行う場へと、前倒しされたにすぎないのです。