ハクソク

世界を動かす技術を、日本語で。

長時間稼働する自律コーディングのスケーリング

92日前原文(cursor.com)

概要

  • 数百のエージェントを同時に動作させて大規模プロジェクトに挑戦した経験談
  • 動的な協調から役割分担型のパイプライン構造への進化
  • 数百万行のコード生成と大規模な成果事例
  • モデル選択やプロンプト設計の重要性
  • 今後の課題と展望

エージェントによる自律的コーディングの最前線

  • 複数のエージェントを並列稼働させ、人間チームが数ヶ月かかるプロジェクトに挑戦する実験
  • 単一エージェントは小規模タスクに強いが、大規模プロジェクトでは非効率
  • 動的な協調（エージェント同士が進行状況を見てタスクを選ぶ）を最初に採用
    • 共有ファイルとロック機構で競合防止を試みるも、ボトルネックやデッドロック、失敗が頻発
    • 楽観的同時実行制御（状態変更時のみ書き込み失敗）も導入したが、本質的な問題は解決できず
  • 階層構造のない協調では、エージェントがリスク回避的になり、難題を避けて進捗が停滞

役割分担によるパイプライン構造への転換

  • プランナーとワーカーに役割分担するパイプライン構造に移行
    • プランナー：コードベースを探索しタスクを生成、必要に応じてサブプランナーを生成
    • ワーカー：割り当てられたタスクを遂行し、他のワーカーとの調整は不要
    • ジャッジエージェントが各サイクルの終了判定を担当
  • この構造で協調問題が大幅に解消し、数百のエージェントによる大規模プロジェクトも実現可能に

実験事例と成果

  • Webブラウザのゼロからの自作に挑戦
    • 1週間で100万行以上・1000ファイル超のコード生成
    • 新規エージェントもコードベースを理解し、継続的に貢献可能
    • 数百ワーカーが同一ブランチへ同時プッシュ、競合は最小限
  • SolidからReactへの大規模移行（Cursorコードベース）
    • 3週間で26.6万追加/19.3万削除の大規模編集
    • マージ可能な品質に到達
  • 新プロダクトのパフォーマンス改善
    • Rustによるビデオレンダリングの高速化（25倍向上）
    • ズーム・パンのスムーズな動作追加、コードは本番投入予定
  • その他の実験例
    • Java LSP: 7,400コミット、55万行
    • Windows 7エミュレータ: 14,600コミット、120万行
    • Excel: 12,000コミット、160万行

学びと知見

  • モデル選択が長期自律作業の効率性に大きく影響
    • GPT-5.2は指示遵守、集中維持、精密実装に優れる
    • Opus 4.5は早期停止・省略傾向あり
    • 役割ごとに最適なモデルを選択することで効率向上
  • 複雑さの排除がシステム改善に寄与
    • 品質管理・統合担当（インテグレータ）を廃止し、ワーカーの自律解決に任せた方が効率的
    • 分散システムや組織論のモデルは一部適用困難、適度な構造が重要
  • プロンプト設計が協調・集中・異常回避に最重要
    • システムやモデルよりも、プロンプトの工夫が成果を左右

今後の課題と展望

  • マルチエージェント協調は依然として難題
    • プランナーの自動再起動や、タスク完了時の動的計画更新が必要
    • エージェントの長時間稼働やドリフトへの対策として定期的なリフレッシュが必要
  • 大規模自律コーディングのスケーラビリティには希望
    • 数百のエージェントが数週間に渡り協調し、実際に大規模プロジェクトを推進可能
    • これらの技術は今後Cursorのエージェント機能に還元予定
  • AI支援ソフトウェア開発の最先端課題に興味がある人材を募集中（hiring@cursor.com）

Hackerたちの意見

「このシステムをテストするために、野心的な目標を設定したんだ。ゼロからウェブブラウザを作ることさ。」先週、LLMの予測をシェアしたんだけど、その中の一つは「2029年までに、誰かが主にAI支援のコーディングを使って新しいブラウザを作るだろう、しかもそれは驚きでもない」ってことだった。https://simonwillison.net/2026/Jan/8/llm-predictions-for-202... と https://www.youtube.com/watch?v=lVDhQMiAbR8&t=3913s このCursorのプロジェクトは、今見た中で2回目の試みだよ！もう一つはこれだね： https://www.reddit.com/r/Anthropic/comments/1q4xfm0/over_chr...
└
2029年？なんでそんなに遠いと思うのか全然わからない。もっと早くて2026年のQ2くらいだよ。
└
バーを上げる時が来た。2029年までに、誰かが主にAI支援のコーディングを使って新しいブラウザを作るだろう、驚きなのはそれがペリカン用に設計されていたことだ。
└
今、長期的なコーディング実験の目標として、ISO32000仕様書に基づいたPDFラスタライザーの実装を進めてるんだ。
└
いいね、「人工的なインターネットエクスプローラー」って呼べるね、略してaIEで。
└
ウェブブラウザはソースがあるから簡単に作れるはず。でも、俺のブラウザのSVGバグは全部直してほしいな…
同じような技術を使ってtjsを作ったんだ。[1] 世界で最も速くて正確なJSONスキーマバリデーターで、魔法のようなTypeScriptの型を持ってる。自律プログラミングについてたくさん学んだよ。gitサブツリーを使って作業を広げる「プランナー/デリゲート」パターンがすごくうまく機能することに気づいた。[2] どんな大きなソフトウェアも、確立された基準とテストスイートがあれば、コーディングエージェントによってすぐに書き直されて最適化されると思う。[1] https://github.com/sberan/tjs [2] /spawn-perf-agents claude command: https://github.com/sberan/tjs/blob/main/.claude/commands/spa...
これ、ちょっと皮肉に聞こえるかもしれないけど、マジで思ってるんだ。なんでそのPRをマージしないの？ここに暗示されてる未来は、めっちゃクールだよ。少しの監視で何でも作れるコーディングエージェントの群れ。高品質で複雑なプロジェクトに収束する長期的なプロジェクト。でも、具体例が薄い気がする。ウェブブラウザ、Excel、Windows 7は存在してるし、特にLLMのトレーニングセットに含まれてる。実際のコードに最も近いのはCursorのコードベースでやったことだけど、まだマージされてない。マージされたら連絡してって言いたくはないけど、エージェントが何百万行ものコードを生み出す能力には心配してないんだ。実世界の人間と交わる能力、つまりそのコードのユーザーやそれを基に何かを作りたい開発者との関係が心配なんだ。
└
ほとんどすべてのものがトレーニングセットに存在してるよ。研究以外のソフトウェアは、いろんな標準モジュールやアルゴリズムの寄せ集めに過ぎない。
└
>> なんでそのPRをマージしてないの？ コードをレビューするのが絶対に不可能だから、そこには無数の問題があるんだ。マージされる唯一の方法はYOLOで、プロダクションで数ヶ月間問題を修正することになるけど、それじゃ本来の目的が意味をなさなくなって、利益もほぼゼロになっちゃう。
└
> 長期的なプロジェクトが収束する これが私の考え方だよ。私は漸近的なものに興味がある。どんな初期条件（モデル×ワークフロー/ハーネス×入力テキストのアーティファクト）が最良の定常状態に収束させるのか？コードの行数は増えなくてもいいし、減ることもある。大事なのは、最良の出力なんだ。
└
> 高品質で複雑なプロジェクトに収束する長期プロジェクト 俺の経験では、エージェントは何にも収束しないんだよね。低品質のモンスターに分岐して、最終的には全く使えなくなる。
└
> ウェブブラウザ、Excel、Windows 7は存在していて、特にLLMのトレーニングセットに含まれている。ブラウザは3つちょっと、真面目なExcelライクなものとWindowsユーザーサイドの小部分があるだけ。これじゃ特定のタスクを再現するには全然足りないよ。
これ、めっちゃ脆いコードに見えるんだけど。https://github.com/wilsonzlin/fastrender/blob/main/crates/fa... `FrameState::render_placeholder`って何なの？ ``` pub fn render_placeholder(&self, frame_id: FrameId) -> Result { let (width, height) = self.viewport_css; let len = (width as usize) .checked_mul(height as usize) .and_then(|px| px.checked_mul(4)) .ok_or_else(|| "viewport size overflow".to_string())?; if len > MAX_FRAME_BYTES { return Err(format!( "requested frame buffer too large: {width}x{height} => {len} bytes" )); } // テストやデバッグでクロストークをキャッチするための決定論的なフレームごとの塗りつぶし色。 let id = frame_id.0; let url_hash = match self.navigation.as_ref() { Some(IframeNavigation::Url(url)) => Self::url_hash(url), Some(IframeNavigation::AboutBlank) => Self::url_hash("about:blank"), Some(IframeNavigation::Srcdoc { content_hash }) => { let folded = (*content_hash as u32) ^ ((*content_hash >> 32) as u32); Self::url_hash("about:srcdoc") ^ folded } None => 0, }; let r = (id as u8) ^ (url_hash as u8); let g = ((id >> 8) as u8) ^ ((url_hash >> 8) as u8); let b = ((id >> 16) as u8) ^ ((url_hash >> 16) as u8); let a = 0xFF; let mut rgba8 = vec![0u8; len]; for px in rgba8.chunks_exact_mut(4) { px[0] = r; px[1] = g; px[2] = b; px[3] = a; } Ok(FrameBuffer { width, height, rgba8, }) } } ``` この差分で何をしてるのか？https://github.com/wilsonzlin/fastrender/commit/f4a0974594e3... 時間の経過とともにどれだけの作業や再作業があったのか、そして各追加の実際に完成したテストケースのトークン/時間コストを見てみたいな。
└
タグから属性を取り出す面白い方法だね。https://github.com/wilsonzlin/fastrender/blob/main/crates/fa...
└
脆弱なコードでも、Cursorを使って更新して修正できるならいいんじゃないかな。理想的だよ、本当に、依存させてくれるし。
誰かリポジトリからテストを実行できた人いる？コードはエラーや警告だらけで、私が見た限りでは、どれも私のプラットフォーム（Linux）のせいじゃないみたい。いくつかのページのActionワークフローの履歴を見たけど、CIがしばらく失敗してるみたいだし、PRも全部CIに失敗してるのにマージされてる。これが成功例として使えるってどうやって確認されたの？それとも私が彼らの言いたいことを誤解してるのかな？スクリーンショットについて言及してるけど、彼らの目標が成功したかどうかは具体的に言ってないよね？「完全自律コーディング」のアプローチが正しいとは思えない。人間が何かを達成するために使うものとして考えた方が、もっと効果的に使える気がする。人間に運転させる方がいいと思う。品質がすぐに崩壊しちゃうから。
└
コードベースがすごくナビゲートしづらかった。200行未満の小さなファイルが何百、いや千を超えて、深くネストされたサブディレクトリにあったんだ。JavaScriptエンジンがどこにあるのか、DOMの実装がどこにあるのかを探したけど、GitHubの検索機能を使っても簡単には見つからなかった。正直、このブラウザが何を実装してるのか、どうなってるのか全然わからない。READMEもあんまり良くないし。理想的にはインストール手順がすぐ上にあるべきなのに、複数のファイルに分かれてる。 "running + architecture"って書いてあるREADMEのリンク（でも実際のファイル名はbrowser_ui.md？？？）は追いづらいし。依存関係の明示的なリストもないし、JavaScriptの実行やレンダリングがどうなってるのかの説明も全然ない。こんな大きなプロジェクトをエージェントがビルドしてコンパイルできたのはすごいけど、このコードベースは… AIのスラップみたいで、維持するためにお金を払ってもらってもやりたくない。AIエージェントに維持させることもできるけど、私の予想では、ある規模を超えると、自分たちの混乱を理解するのが難しくなると思う。結局、簡単には修正できない永久的なバグが残るだけだよ。
└
ここから記事を読むのはやめた方がいいよ: > 今日のエージェントは集中したタスクにはうまく機能するけど、複雑なプロジェクトには遅い。遅いってどういう意味？人間より遅いの？もっと速いGPUが必要？それって何を示唆してるの？次のトークンを生成するのに遅すぎる？使えるようにするのに遅すぎる？人間の介入が必要？この文章は、バブルをさらに膨らませるために作られてるんだ。
> 確かに一見シンプルなスクリーンショットに見えるけど、ブラウザをゼロから作るのはめっちゃ難しいよ。 > 別の実験として、CursorのコードベースでSolidからReactへのインプレースマイグレーションをやったんだ。それには3週間以上かかって、+266K/-193Kの編集があったよ。変更のテストを始めたところだけど、この変更をマージできる可能性があると思ってる。私の見解では、この投稿は真剣な議論をするには十分な詳細やニュアンスが欠けてるし、情報が少ないことは主に失敗を示唆してる、特にブラウザのケースではね。ブラウザのリポジトリが「何かしらできる」ってのはすごいけど、それ以上の注目すべき点があったら、30Kのコミットや1MのLoCみたいなボリュームメトリクス以上の詳細を説明すると思う。例えば、表示されている全機能が他のライブラリに委譲される数行に制約される可能性もあるし、リグレッションを避ける変更はマージ「可能」だけど、私たちの仕事の大半は「次の変更をマージすることは可能か？」って問いかけるんだよね。そして次の、100番目の変更もね。もし彼らがMRをマージしたら、実際にやってることになる。ブラウザの分析をもっと提示すれば、話す価値がある（「レンダリングする」以上に精査しなかったら、あんまり役に立たないテストだけど）。それまでは、コンパイルできる謎のエージェント出力の山で、未発見のメカニズムでapple.comのスクリーンショットを撮る実行経路が含まれてるんだ。
└
> コンパイルできる謎のエージェント出力の山だけど、これは本当にそうなの？ 私が見る限り、彼らはそう言ってないし、自分のCIでもコンパイルできないみたいだよ。
└
エージェント的なコーディングの最低ラインは、成功裏にコンパイルできる何かを作ることだよね。次は、ハッピーパスで成功裏に動く何か。そして、明らかなエッジケースをすべて処理できる何か。最も有用な指標は、広く使われているライブシステムが1年間動いて、バグの数が人間が作ったコードベースよりも少ないことだと思う。それが実現するまでは、懐疑的な姿勢は変わらないかな。
試してみたくてリポジトリをダウンロードしてビルドを実行したんだけど、100以上のコンパイルエラーが出たんだ。そこでGitHubのコミット履歴を見たら、少なくとも数ページ前から最近のコミットはCIで失敗してるのがわかった。どのコミットを選べば宣伝されてる半分動くバージョンが手に入るのかも不明だったし。とりあえずCargo.tomlを見て、プロジェクトがどう構成されてるのかを把握しようとしたんだけど、投稿の印象とは裏腹に、ほとんどのコアコンポーネントがオープンソースのライブラリから引っ張ってきたものだってわかった。quickjsエンジン、wgpuグラフィックス、winitウィンドウ＆入力、eguiでUI、HTMLパースなど、挙げればキリがない。TwitterではCEOが「カスタムJS VM」を使ってるって明言してたけど、これが特に誤解を招く表現だと思った。既存のコンポーネントを統合するのは、自律的にやるにはすごいことだけど、印象的なことをやった後にこんなに誤解を招く必要があるのか、正直戸惑ってる。リーダーシップに対する信頼はかなり減ったけど、もしかしたら自分のカスタムカーソルを生成できる日が近いと思うと少しホッとしてるかも。
└
やり方が違うよ。スクリーンショットを撮って、マネージャーや投資家に見せて「今、私たちのビジネスに何が可能か想像してみてください」ってプレゼンしなよ。昇進するか、別の場所に移って、あとは彼らに考えさせればいいんだ。
└
63295回のワークフロー実行のうち、成功したのは1426回だけらしい。これが実際には動いたことがない未検証のゴミの山だという印象を避けるのは難しいね。CIプロセスはほとんどのコミットで成功してないし。本当に驚きだよ。
└
みんなで自分のカスタムカーソルを作ろう！
└
WGPUでレンダリング、winitでウィンドウ、servo CSSエンジン、taffyでレイアウトって、既存のオープンソースRustブラウザのblitzにすごく似てるね。https://github.com/dioxuslabs/blitz もしかしたら、私たちもトレーニングデータに入ってたのかも！
ここにいるみんながこんなにネガティブで懐疑的なのはちょっと驚きだよ。ブラウザエンジンを作るなんて、ある意味信じられないことだと思う。多少は動くウェブサイトレンダラーに近づくなんてさ。最も悲観的な解釈をしても（人間の操作が多すぎる、既存のライブラリに依存している、コードの質が雑なところがある、全バージョンがコンパイルできないなど）それでも驚きだよ。
└
あんまり驚かないな。多くの（全部じゃないけど！）ネガティブなコメントを読むと、「このコードで作業することを想像すると、嫌だな」って感じる。LLMの仕事には結構感心してるけど、これも俺の経験と同じだよ…とはいえ、サンプルサイズが1で、数日間ちょっとしたクレジットでやっただけだけど。ポジティブな意見は、結局大事なのはコードが何をするかであって、見た目じゃないって指摘する人が多いね。例えば、ユーザーはコードを見ないし、コードに興味もないし、ビジネスで気にする人たちにとっても、LLMが積み上がる技術的負債を払わなきゃいけないかもしれない。* ミスが高くつく分野の人たち。あるプロジェクトでは、LLMに自己コードレビューをさせたら、自分の解決策にセキュリティの脆弱性を見つけたんだ。まだ知らないものがもっとあるかもしれない。** プロンプトに対してLLMが好きなようにやるのを許可して、結果を最後まで自分で読んだりコードレビューしたりしなかった元の意味で。
個人的に今考えてみると、あんまり好きじゃないのは、彼らが段階的にスケールアップしなかったことだな。ソフトウェアの複雑さの階段があるとしたら、シンプルなReact CRUDアプリから始まって、Paintのクローンみたいなもっと複雑なもの、さらにファイルマネージャーみたいなもっと複雑なものへと進んで、最終的にはウェブブラウザみたいな最も複雑なソフトウェアにたどり着く感じ。最初のタスクを100%達成して、次のタスクも素晴らしい結果を出して、3つ目は頑張って、最後にはまだ使えないけど期待できるものを作るようなシステムが見たいな。そうすれば、難易度のスケールアップが品質の徐々に低下につながることがわかるし、今どこにいて、どこに向かっているのかをちゃんと測れると思う。
今、opus 4.5を使ってるんだけど、これが彼らのベストモデルと言えるかも。多くの作業にはすごく良いけど、監視なしで放置すると微妙なエラーや不一致が出てくるんだよね。複雑な要求には曖昧さを取り除くためのプロンプトが全然足りないから、数日や数週間放置したらコードベースにどうなるか想像もつかない。