2026/01/15 7:18
**タイトル：** 長時間稼働する自律型コーディングのスケーリング
RSS: https://news.ycombinator.com/rss
要約▶
Japanese Translation:
要約
本研究は、大規模自律コーディングが最も効果的に機能するのは、プランナーとワーカーという二層階層でエージェントを組織した場合であることを示しています。単一プロジェクト上で数百の同時実行エージェントを用いた実験では、100万行以上のコードと兆トークンが生成されましたが、共有ファイルロックや楽観的コンカレンシーによる初期調整はボトルネックにより失敗し、進捗が停滞しました。
プランナー–ワーカー構造へ切り替えることでこれらの問題を解決できました。プランナーはコードベースを探索し、タスクを生成してサブプランナーを派遣します。一方、ワーカーは割り当てられた単一タスクに集中します。この構造はロック競合を排除し、多数のエージェントがほぼ衝突なく並行実行できるようにし、一つのエージェントが機能全体を責任持って完了できることを保証します。
主な成果として、約1週間でウェブブラウザをゼロから構築（≈100万行、1,000ファイル）したこと、Cursor の Solid→React 部分の移植、そして新しい Rust 機能により動画レンダリング速度を25倍に加速させたことが挙げられます。現在進行中のプロジェクト（Java LSP、Windows 7 エミュレータ、Excel、FX1）はすでに数百万行のコードを自律的に生成しています。
著者はまた モデル選択が重要 であることも発見しました。GPT‑5.2 は長期計画と正確な実装に優れ、プランナーとして GPT‑5.1‑codex を上回ります。一方 Opus 4.5 は早期終了する傾向があります。中間統合者の役割を除去するとさらに効率が向上し、ワーカー自身が衝突を解決できるようになります。最適な組織構造は「少なすぎて衝突・重複・漂移が発生」する状態と「多すぎて脆弱になる」状態の間にあり、よりシンプルなシステムの方が過度に複雑なモデルよりも良いパフォーマンスを示します。
最後に プロンプトエンジニアリング が不可欠です。よく設計されたプロンプトは病的行動を防ぎ、集中力を維持し、効果的な協調を可能にします。
今後の研究ではプランナーの起床ロジックを洗練させ、エージェントの漂移を減らし、周期的な「新たなる開始」を導入して自律コーディングをさらにスケールアップする予定です。採用されれば、この協調モデルは開発労力を削減し、衝突を減らし、企業やオープンソースコミュニティ向けに迅速かつ大規模なコード生成を可能にします。
本文
私たちは数週間にわたり、コーディングエージェントを自律的に動かす実験を行ってきました。
私たちの目標は、人間チームが数か月かけて完成させるプロジェクトを、どこまで「エージェント主体」でコード化できるかを探ることです。
本稿では、1つのプロジェクトに対して何百もの同時実行エージェントを動かし、その作業を調整しながら、100万行以上のコードと数兆トークンを書き上げた経験から得た知見を紹介します。
単一エージェントの限界
今日のエージェントは狭いタスクにはうまく対応できますが、複雑なプロジェクトでは速度が遅くなります。次に自然に思えるステップは複数のエージェントを並列で動かすことですが、それらをどのように調整するかが課題です。
最初の直感は、事前計画を立てると硬直化してしまうというものでした。大規模プロジェクトの道筋は曖昧で、開始時点で適切な作業分割が見えてくるわけではありません。そのため、私たちは「動的調整」から始めました。エージェントは他者の現在の活動に基づいて、自ら何をするか決定します。
調整の学習
初期アプローチ – 等価ステータスと共有ファイルによる自己調整
- 各エージェントは他者が何をしているか確認し、タスクを取得して自分の状態を更新します。
- 同じタスクを2人以上が同時に取得するのを防ぐためにロック機構を使用しました。
しかし、面白い失敗が起きました：
- ロックの保持時間が長すぎる／解放忘れ：正しくロックしていても、20名のエージェントは実質2〜3名分しかスループットにならず、ほとんどの時間を待ち状態に費やしました。
- システムが脆弱：ロックを保持中に失敗したり、既に持っているロックを再取得しようとしたり、ロックを取らずに調整ファイルを書き換えたりするケースが発生しました。
そこでロックを楽観的排他制御（Optimistic Concurrency Control）へ置き換える試みも行いました。エージェントは状態を自由に読み取り、書き込み時に状態が変わっていたら失敗させる方式です。単純で頑健になりましたが、それでも深刻な問題が残ります。
階層構造が無いと、エージェントはリスク回避的になります。難しいタスクを避け、安全な小変更に留まるため、誰も大きな課題や end‑to‑end 実装を担わず、長時間進捗が出ない「作業の循環」に陥ります。
プランナーとワーカー
次のアプローチ – 役割分離
- プランナー：コードベースを継続的に探索しタスクを生成します。特定領域用にサブプランナーをスパーンさせ、計画自体を並列・再帰的に行います。
- ワーカー：タスクを拾い上げ、完了まで専念します。他のワーカーと協調したり全体像を考えたりしないで、自分の割り当てられた作業に「グラインド」して終わったら変更をプッシュします。
各サイクルの終盤でジャッジエージェントが継続するか決定し、次のイテレーションは新たに開始します。これによりほとんどの調整問題が解消され、大規模プロジェクトでも単一エージェントがタンネルビジョンになることなくスケールできます。
数週間にわたる実行
システムを検証するため、目標は「ゼロからウェブブラウザを構築」でした。エージェントはほぼ1週間動作し、1000ファイルにわたり 100 万行以上のコードを書き上げました。GitHub 上でソースコードを閲覧できます。
コードベースが大きくても、新しいエージェントはそれを理解し、有意義な進捗を出せます。数百のワーカーが同時に動作し、ほぼ衝突なく同じブランチへプッシュします。
他の実験例：
- Solid → React マイグレーション（Cursor コードベース）: 3週間で +266K / -193K の編集。マージが可能と判断しています。
- ビデオレンダリング改善: 長時間稼働したエージェントにより、Rust バージョンを最適化してレンダリング速度を25倍にし、スムーズなズーム/パンや自然なスプリング遷移を追加。コードはマージ済みで近日本番投入予定です。
さらに実行中の興味深い例：
| プロジェクト | コミット数 | 行数 |
|---|---|---|
| Java LSP | 7.4 K | 550 K |
| Windows 7 エミュレータ | 14.6 K | 1.2 M |
| Excel | 12 K | 1.6 M |
| FX1 | 9.5 K | 1.2 M |
私たちの学び
- トークン投入：数十億トークンを単一目標に向けて投下。システムは完璧ではないものの、期待より遥かに効果的です。
- モデル選択が重要：GPT‑5.2 は長時間自律作業で指示追従・集中力・逸脱防止・正確な実装が優れており、Opus 4.5 は早期停止しやすく、手っ取り早い道を選びがちです。役割ごとに最適なモデルを使うことで性能が向上します。
- シンプル化：多くの改善は複雑さを削減することから生まれました。品質管理・衝突解決用インテグレータ役はボトルネックになり、ワーカー自身が衝突処理できるため不要でした。最良のシステムは思ったよりも簡素です。
- 構造と柔軟性のバランス：構造が少なすぎると衝突・重複作業・逸脱が増え、過度に構造化すると脆弱になります。最適な量は中間に位置します。
- プロンプトエンジニアリングの重要性：システム全体の挙動は、エージェントへの提示方法に大きく左右されます。調整・逸脱防止・長期集中を実現するには多段階の試行が必要です。ハーネスやモデルよりもプロンプトが鍵となります。
今後の展望
マルチエージェントの協調は依然として難題です。現在のシステムは機能しますが、最適化には遠い道のりがあります。プランナーはタスク完了時に次を計画し起動するようにすべきですが、エージェントは長時間走り続けるケースもあります。定期的なリセットで逸脱やタンネルビジョンを防ぐ必要があります。
しかし核心の質問――「より多くのエージェントを投入して自律コーディングを拡張できるか？」―に対する答えは楽観的です。数百のエージェントが同じコードベースで何週間も協力し、実際に野心的プロジェクトを進められます。
この取り組みで開発した技術は、最終的に Cursor のエージェント機能へ反映される予定です。AI 支援ソフトウェア開発の最前線で挑戦したい方は、hiring@cursor.com までご連絡ください。