Cursorが数百のエージェントを協調させ「ゼロからブラウザを構築」させる実験を実施、1週間で1000ファイル・100万行以上のコードを記述
AIコードエディターのCursorが、コーディングエージェントを自律的に稼働させ、ウェブブラウザを構築するという実験を行ないました。
長時間稼働する自律型コーディングをスケールさせる · Cursor
https://cursor.com/ja/blog/scaling-agentsScaling long-running autonomous coding
https://simonwillison.net/2026/Jan/19/scaling-long-running-autonomous-coding/ 既存のエージェントは狭い範囲のタスクは上手く処理できますが、複雑なプロジェクトでは処理が遅くなります。そのため、次の一手として考えられるのは、複数のエージェントを並行して動かすことですが、それらをどのように協調させるかを考えることは難しいものです。当初、Cursorは事前に綿密な計画を立てるやり方は硬直的すぎると考えていたそうですが、大規模プロジェクトの進め方は曖昧で、最初の時点では適切なタスク分割も明らかではなかった模様。そこで、初めに他のエージェントが行っている作業に基づき、自分が何をするかを決める「動的な協調」を考慮し始めたそうです。 最初のアプローチでは、すべてのエージェントを同等の立場に置き、共有ファイルを通じて自律的に協調させました。このアプローチにおいて、各エージェントは他のエージェントの作業内容を確認し、自分が担当するタスクを宣言し、その進捗状況を更新します。同じタスクを複数のエージェントが取得しないように、ロック機構を採用しました。 しかし、エージェントがロックを長時間保持しすぎたり、完全に解放し忘れたりしてしまった模様。また、ロックが正しく動作している場合でも、それ自体がボトルネックになってしまったそうです。エージェントが20体いても、実効スループットは2~3体分程度まで低下してしまい、ほとんどの時間が待ち時間となってしまったというわけ。また、システムは脆く、ロックを保持したままエージェントが異常終了したり、すでに保持しているロックを再取得しようとしたり、そもそもロックを取得せずに調整用ファイルを更新したりすることもありました。
そこで、ロックの代わりに楽観的並行制御をCursorは試しています。楽観的並行制御では、エージェントは状態を自由に読み取れる一方で、最後に読み取った後に状態が変化していた場合、書き込みが失敗するように設計しました。これはよりシンプルで堅牢でしたが、各エージェントがリスクを取りたがらなくなり、難しいタスクを避け、小さく安全な変更だけを行うようになってしまいました。どのエージェントも難しい問題やエンドツーエンドの実装に責任を持たなくなってしまった結果、長時間にわたって無用な作業だけが回り続け、進捗がほとんど生まれない状態になってしまいました。 次に、すべてのエージェントがなんでもこなすフラットな構造ではなく、役割を分担したパイプラインを作成。役割は「プランナー」と「ワーカー」の2つ。「プランナー」はコードベースを継続的に探索してタスクを作成するという役割で、特定の領域向けにサブプランナーを生成できるため、計画自体を並列かつ再帰的に進められます。「ワーカー」はタスクを受け取り、その完了だけに集中するという役割。他のワーカーと調整したり、大局を気にしたりする必要がないため、割り当てられたタスクを終わらせるまでひたすら作業し、その後、変更をプッシュします。 各サイクルの終わりに、Judgeエージェントが処理を続けるべきかどうかを判断し、次のイテレーションは毎回クリーンな状態から始まります。これにより、ほとんどの調整まわりの問題が解決され、どのエージェントも進捗に貢献できるようになり、非常に大規模なプロジェクトまでスケール可能となりました。 このシステムを検証するため、Cursorは「ブラウザをゼロから構築する」というタスクをエージェント群に課しました。エージェントはほぼ1週間動作し続け、1000ファイル・100万行以上のコードを書くことに成功しています。 なお、エージェント群が協調して作成したウェブブラウザのソースコードはGitHubで閲覧できます。
GitHub - wilsonzlin/fastrender: Experimental new browser engine
https://github.com/wilsonzlin/fastrenderCursorのマイケル・トゥルエルCEOは、「CursorでGPT-5.2を搭載したブラウザを構築しました。1週間中断なく動作しました。これは数千のファイルにまたがる300万行以上のコードです。レンダリングエンジンはRustでいちから構築し、HTMLパーシング、CSSカスケード、レイアウト、テキストシェイピング、ペイント、そしてカスタムJavaScriptのVMを備えています。そんなブラウザがなんとか動作します!まだ問題はあり、もちろんWebkitやChromiumとの互換性には程遠いものの、シンプルなウェブサイトが素早く、ほぼ正しくレンダリングされることに驚きました」と言及。さらに、トゥルエルCEOは「ブラウザはエージェントグラインドセッションのひとつによってわずか一晩でコーディングされた」と語っており、これは2023年頃ならエンジニアが約1カ月かけてコーディングした仕事量であるそうです。
We built a browser with GPT-5.2 in Cursor. It ran uninterrupted for one week.It's 3M+ lines of code across thousands of files. The rendering engine is from-scratch in Rust with HTML parsing, CSS cascade, layout, text shaping, paint, and a custom JS VM.
It *kind of* works! It… https://t.co/pHL5CgZCfK pic.twitter.com/jA6wDdwRif
— Michael Truell (@mntruell) January 14, 2026
さらに、トゥルエルCEOはCursorが300万行超のウェブブラウザを1週間で構築する様子を動画化しています。
別の実験では、CursorのコードベースでSolidからReactへのインプレースでの移行を実施。3週間以上かかったものの、26万6000行を追加して19万3000行を削除する大規模更新に成功しました。
さらに別の実験では、エージェントを用いて今後リリース予定のプロダクトの改善を実施。長時間稼働するエージェントが、高効率なRust実装によってビデオレンダリングを25倍高速化することに成功しました。また、マウスカーソルに追従する自然なスプリング遷移と、モーションブラーを伴ったスムーズなズームとパンのサポートを追加しました。このコードはすでにマージされており、まもなく本番環境に展開されます。 Cursorは「マルチエージェントの協調は依然として難しい問題です。既存のシステムは機能していますが、最適にはほど遠い状況です。プランナーはタスクが完了したタイミングで起動し、次のステップを計画できるべきですし、エージェントが必要以上に長く動き続けてしまうこともあります。ドリフトや視野狭窄に対処するには、定期的にクリーンな再スタートも必要です。ただし、本質的な問いである『エージェントを増やすことで自律的なコーディングをスケールできるのか』については、当初の予想よりも楽観的な答えが得られています。数百ものエージェントが単一のコードベース上で数週間にわたって協調し、野心的な大規模プロジェクトでも着実に前進させることができます。ここで開発している技術は、最終的に Cursorのエージェント機能に反映されていきます」と記し、マルチエージェントの協調は今後、Cursorのエージェント機能に反映される予定であると明かしました。
・関連記事 顧客サポートAIが暴走してコードエディターAI「Cursor」開発企業の評判がガタ落ちに - GIGAZINE