- 16個のClaudeエージェントが並列に協力してRustベースのCコンパイラを完成させ、Linux 6.9カーネルをビルドできる水準に到達
- 約2,000回のセッションと2万ドルのコストで10万行規模のコードを生成し、x86・ARM・RISC-Vアーキテクチャをサポート
- エージェントたちは自動ループハーネスを通じて人間の介入なしに継続的に作業し、テスト・並列化・役割分担の構造で効率を高めた
- 成果物はGCC互換性と高いテスト通過率を示したが、16ビットx86コード生成・リンカー・最適化品質などは未完成の状態
- この実験は自律型LLMチームの限界と可能性を検証した事例であり、今後は完全自律開発環境の安全性と品質管理が中核課題として浮上
エージェントチームベースのCコンパイラプロジェクト概要
- 複数のClaudeインスタンスが並列に協力して1つのコードベースを開発する実験
- 人間のリアルタイム介入なしに自律的にコード作成・テスト・修正を反復
- 目標はRustで書かれたCコンパイラを完成させ、Linuxカーネルを直接ビルドすること
- 合計16個のエージェント、約2,000回のセッション、2億入力トークン・1.4億出力トークンを使用
- 成果物は100,000行規模のコンパイラで、Linux 6.9カーネルおよび主要なオープンソースプロジェクト（QEMU、FFmpeg、SQLite、Redisなど）のビルドが可能
長期実行のためのClaudeハーネス設計
- 既存のClaude Codeは人間の入力が必要だったが、無限ループ構造の自動実行ハーネスにより自律進行が可能に
- 各作業完了後、直ちに次の作業を行う自動反復構造
- 作業中にClaudeが誤って
pkill -9 bashを実行し、自分自身を終了させた事例もあった
- 並列実行構造はDockerコンテナとGit同期を活用
- 各エージェントは
/workspaceで作業後、/upstreamへプッシュ
- **テキストファイルベースのロック(lock)**で作業衝突を防止
- マージ競合はClaudeが自ら解決
並列Claudeの運用方式
- 並列実行の利点は同時デバッグと役割分化
- 一部のエージェントはコード作成、一部はドキュメント化・品質管理・性能最適化を担当
- 通信や中央調整役は存在せず、各エージェントが自律的に次の課題を選択
- Git履歴には各エージェントの作業ロック記録と進捗ドキュメントが残る
Claudeチームプログラミングから得られた教訓
高品質なテストの重要性
- Claudeは与えられたテストを基準に自律作業するため、検証器の正確性が中核
- **継続的インテグレーション(CI)**パイプラインを構築し、既存機能が壊れないよう強制検証
- オープンソースのビルドスクリプトとコンパイラテストスイートを活用して品質を確保
Claudeの視点からの環境設計
- 各エージェントはコンテキストのない新しいコンテナで開始するため、進捗状況の文書化が必須
- READMEと進捗ファイルを継続的に更新するよう指示
- 文脈汚染の防止: ログは最小限にし、エラーは
ERRORキーワードで識別できるよう記録
- 時間認識の欠如を補うため、
--fastオプションで1〜10%のサンプルテストを実施
並列化の限界と解決
- 独立テストが多いときは並列化が容易だが、Linuxカーネルビルドは単一の巨大作業で衝突が発生
- 解決策としてGCCを基準コンパイラオラクルとして使用
- 一部のファイルはGCCで、残りはClaudeコンパイラでビルド
- 失敗時には問題ファイルを絞り込みながら並列デバッグが可能
- その後デルタデバッグで相互依存エラーを検出
エージェントの役割分化
- 重複コードの除去、性能改善、効率的なコード生成、Rust構造の改善、文書化など専門化された役割分担
- 並列性と専門化を組み合わせ、大規模コードベース管理の効率を向上
Opus 4.6モデルの性能評価
- Opus 4.5までは大規模プロジェクトをビルドできず、Opus 4.6で初めて実用水準に到達
- クリーンルーム実装でインターネットアクセスなしにRust標準ライブラリのみを使用
- GCC torture test suite 99%通過、Doom実行可能
- 限界点:
- 16ビットx86コード生成不可で、ブート段階ではGCC呼び出しが必要
- アセンブラ・リンカー未完成で、一部バグが存在
- 生成コードの効率が低く、GCCの最適化無効時よりも非効率
- Rustコード品質は良好だが専門家水準には未達
自律エージェントチームの限界と可能性
- プロジェクトはLLM自律協調の限界測定のためのベンチマーク
- 完全自律開発は品質保証・セキュリティリスクを伴う
- 人間による検証なしのコード配布への懸念を表明
- しかし、自律型エージェントチームが複雑なプロジェクトを完成できることを実証
- 今後はモデルの発展とともに安全な自律開発戦略が必須課題として提示される
今後の展望
- 言語モデルの進化はIDE自動補完 → 関数補完 → ペアプログラミング → 自律的なプロジェクト遂行へと進展
- Agent teamsは完全自律開発の可能性を示す
- 急速な技術進歩のスピードへの驚きと同時に、新たな倫理・安全フレームワークの必要性を強調
- 前向きな活用が否定的なリスクを相殺すると期待される一方、新しい開発パラダイムへの備えが必要
2件のコメント
Cで作られたコンパイラではなく、Rust標準ライブラリだけで作られたプロジェクトなのだから、gcc/clangのCコードが学習データに含まれているという批判は、少しゴールポストの移動ではないかと思います。いずれにせよ、すごいです。
Hacker Newsの意見
私はGoogleでほぼ10年にわたり、ClangでLinuxカーネルをビルドする作業をしていた。今回のプロジェクト（clangbuiltlinux.github.io）では、LLMが2,000回のセッションと2万ドルのAPI費用で同じことをやってのけたという。実際にブートまでしたというのだから驚きだ。ただし、生成されたコードの効率性は低く、GCCの最適化無効版よりも非効率的だという。それでも本当にすごいプロジェクトだ
Cursorブラウザプロジェクトよりはるかに現実的なアプローチだ。クリーンルーム実装として、インターネット接続なしでRust標準ライブラリだけを使ったという。10万行規模のコンパイラでLinux 6.9、QEMU、FFmpeg、SQLite、Postgres、Redisまでビルド可能だという。
Opus 4.5は初めて大規模テストを通過できるようになり、今回の結果はその限界をほぼ使い切ったように見える。
さまざまな制約にもかかわらず、印象的な実験だと思う
最初は「おお、すごい」と思ったが、すぐ考えが変わった。Cコンパイラは仕様が非常に厳密なソフトウェアなので、LLMが扱いやすい部類だ。
だが、私たちの仕事の大半は要件が曖昧で、目標が絶えず変わる環境にある。そういう領域でもうまく機能するのかが気になる
unspecified behaviorがどれだけ多いことか結果が完璧であるべきだという期待には違和感がある。可能だということ自体が驚きだ。こうした試みが次のOpusやSonnetの学習に反映され、いつか効率的なコンパイラを自力で作るモデルが現れるかもしれない
このプロジェクトはLinuxカーネル、QEMU、FFmpeg、Redis、Doomまでビルドできるという。本当に驚きだ。
ただし、この種のエージェントシステムはテスト可能な領域ではうまく動く一方で、ビジネス意思決定のような文脈が必要な領域では限界がある
すごいプロジェクトだが、「クリーンルーム」への言及は外したほうがよかった。著作権のあるコードで訓練されたモデルなのだから、むしろ逆に近い
GitHub issueによれば、問題はincludeパスの欠落が原因だという。コンパイラ自体は正常らしい
私はすべてのプロンプトとエージェント構成を公開してほしい。学習用として非常に有用だろうし、再現のために2万ドルを自分で出すのは負担が大きい
これはCursorブログの動く版のようなものだ。実際にLinuxカーネルをビルドしたという証拠のほうがはるかに説得力がある
これは「ピラミッドは建てられても大聖堂は建てられない」型のアプローチだ（関連記事）。
莫大な計算資源を投入して機能を力ずくで実装したようなもので、2万ドルを燃やしたと表現したくなる。
指数的な計算資源で線形的な結果を得るのは意味があるとしても、長期的には非効率な方向に見える