数週間にわたって、コーディングエージェントを自律的に稼働させる実験を行ってきました。

私たちの目標は、通常は人間のチームが数か月かけて完了させるようなプロジェクトに対して、エージェント駆動のコーディングの最前線をどこまで押し広げられるかを見極めることです。

本記事では、単一のプロジェクトで数百のエージェントを同時に稼働させ、その作業を調整し、合計で100万行以上のコードと数兆トークンを書き上げる様子を観察して得られた知見を紹介します。

#単一エージェントの限界

現在のエージェントは、狭い範囲のタスクにはうまく機能しますが、複雑なプロジェクトでは処理が遅くなります。自然な次の一手は、複数のエージェントを並行して動かすことですが、それらをどう協調させるかを考えるのは難しい問題です。

当初は、事前に綿密な計画を立てるやり方は硬直的すぎると考えていました。大規模プロジェクトの進め方は曖昧であり、最初の時点では適切なタスク分割も明らかではありません。そこでまずは、他のエージェントが現在行っている作業に基づいて、自分が何をするかを決める「動的な協調」から始めました。

#協調の学習

最初のアプローチでは、すべてのエージェントを同等の立場に置き、共有ファイルを通じて自律的に協調させていました。各エージェントは他のエージェントの作業内容を確認し、自分が担当するタスクを宣言し、その進捗状況を更新します。同じタスクを複数のエージェントが取得しないようにするため、ロック機構を使っていました。

しかし、これは興味深い形でうまくいきませんでした。

1. エージェントがロックを長時間保持しすぎたり、完全に解放し忘れたりしました。ロックが正しく動作している場合でも、それ自体がボトルネックになっていました。エージェントが20体いても、実効スループットは2～3体分程度まで低下し、ほとんどの時間が待ち時間に費やされていました。

2. システムは脆く、ロックを保持したままエージェントが異常終了したり、すでに保持しているロックを再取得しようとしたり、そもそもロックを取得せずに調整用ファイルを更新したりすることがありました。

そこでロックの代わりに楽観的並行制御を試しました。エージェントは状態を自由に読み取れる一方で、最後に読み取った後に状態が変化していた場合は書き込みが失敗するようにしました。これはよりシンプルで堅牢でしたが、依然としてもっと根本的な問題が残っていました。

階層がないと、エージェントはリスクを取りたがらなくなりました。難しいタスクを避け、小さく安全な変更だけを行うようになったのです。どのエージェントも難しい問題やエンドツーエンドの実装に責任を持ちませんでした。その結果、長時間にわたって作業だけが回り続け、進捗がほとんど生まれない状態になってしまいました。

#プランナーとワーカー

次に試したアプローチは、役割を分離することでした。すべてのエージェントがなんでもこなすフラットな構造ではなく、責務を分けたパイプラインを作りました。

• プランナー はコードベースを継続的に探索してタスクを作成します。特定の領域向けにサブプランナーを生成できるため、計画自体を並列かつ再帰的に進められます。

• ワーカー はタスクを受け取り、その完了だけに集中します。他のワーカーと調整したり、大局を気にしたりはしません。割り当てられたタスクを終わらせるまでひたすら作業し、その後変更をプッシュするだけです。

各サイクルの終わりに、Judge エージェントが処理を続けるべきかどうかを判断し、次のイテレーションは毎回クリーンな状態から始まります。これにより、ほとんどの調整まわりの問題が解決され、どのエージェントも視野狭窄に陥ることなく、非常に大規模なプロジェクトまでスケールできるようになりました。

#数週間にわたる稼働

このシステムを検証するために、私たちは「ブラウザをゼロから構築する」という野心的なゴールを設定しました。エージェントはほぼ 1 週間動作し続け、1,000 ファイルにわたって 100 万行以上のコードを書きました。GitHub 上のソースコードを閲覧できます。

コードベースの規模にもかかわらず、新しいエージェントでも内容を理解し、有意義な前進を生み出せます。数百のワーカーが同時に動作し、同じブランチに最小限のコンフリクトでプッシュしています。

一見ただのスクリーンショットに見えるかもしれませんが、ブラウザをゼロから構築するのは非常に難しい作業です。

別の実験として、Cursor のコードベースで Solid から React へのインプレースでの移行を行いました。3 週間以上を要し、+266K/-193K の変更が行われました。変更のテストを開始した現時点で、この変更をマージすることは十分可能だと考えています。

さらに別の実験として、今後リリース予定のプロダクトの改善を行いました。長時間稼働するエージェントが、高効率な Rust 実装によってビデオレンダリングを 25 倍高速化しました。また、マウスカーソルに追従する自然なスプリング遷移とモーションブラーを伴った、スムーズなズームとパンのサポートも追加しました。このコードはすでにマージされており、まもなく本番環境に展開されます。

私たちは、他にも興味深い例をいくつか現在も稼働させています：

• Java LSP: 7.4K commits, 550K LoC
• Windows 7 emulator: 14.6K commits, 1.2M LoC
• Excel: 12K commits, 1.6M LoC

#ここまででわかったこと

私たちはこれらのエージェントに対して、単一の目標に向けて数十億トークン規模でデプロイしてきました。システムは決して完全に効率的ではありませんが、想定していた以上に高い効果を発揮しています。

極めて長時間にわたって動作するタスクでは、どのモデルを使うかが重要になります。私たちは、GPT-5.2 モデルのほうが自律的な長時間の作業に大きく優れていることを見出しました。具体的には、指示の遵守、集中の維持、ドリフトの回避、そして実装の正確さと完遂度において優れています。

Opus 4.5 は、都合がよいときには早めに処理を打ち切ったり近道を取ったりする傾向があり、すばやく制御を人間側に戻します。また、モデルごとに得意な役割が異なることもわかりました。GPT-5.2 は、GPT-5.1-codex よりもプランニング能力が高く、後者はコード用に特化して学習されているにもかかわらずそうなっています。現在は、単一の万能モデルではなく、各ロールに最適なモデルを使い分けています。

多くの改善は、機能を足すことではなく、複雑さを取り除くことから生まれました。私たちは当初、品質管理とコンフリクト解消のために integrator ロールを構築しましたが、これは問題解決よりもボトルネックを増やす結果になりました。Workers は、すでに自分たちでコンフリクトを処理できていたのです。

最善のシステムは、しばしば想像しているよりもシンプルです。私たちは最初、分散コンピューティングや組織設計のシステムを参考にしようとしました。しかし、それらのすべてがエージェントに有効というわけではありません。

適切な構造のレベルは、その中間あたりにあります。構造が少なすぎると、エージェント同士が衝突し、作業が重複し、ドリフトが発生します。構造が多すぎると、今度はシステムが脆くなります。

このシステムの挙動のかなりの部分は、最終的にはエージェントのプロンプト設計に帰着します。うまく協調させ、病的な挙動を避け、長時間にわたって集中を維持させるには、大規模な試行錯誤が必要でした。実行環境（ハーネス）やモデルも重要ですが、プロンプトはそれ以上に重要です。

#今後の展望

マルチエージェントの協調は依然として難しい問題です。現在のシステムは機能していますが、最適にはほど遠い状況です。プランナーはタスクが完了したタイミングで起動し、次のステップを計画できるべきですし、エージェントが必要以上に長く動き続けてしまうこともあります。ドリフトや視野狭窄に対処するには、定期的にクリーンな再スタートもまだ必要です。

ただし、本質的な問い――エージェントを増やすことで自律的なコーディングをスケールできるのか――については、当初の予想よりも楽観的な答えが得られています。数百ものエージェントが単一のコードベース上で数週間にわたって協調し、野心的な大規模プロジェクトでも着実に前進させることができます。

ここで開発している技術は、最終的に Cursor のエージェント機能に反映されていきます。AI 支援によるソフトウェア開発で最も困難な問題に取り組むことに関心があれば、ぜひ hiring@cursor.com までご連絡ください。