16体のClaudeが並列でCコンパイラを作った話 ── エージェントチーム開発の最前線

Anthropicの研究者Nicholas Carliniが、面白い実験結果を公開しました。16体のClaudeエージェントを並列で走らせ、RustベースのCコンパイラをスクラッチから構築したという話です。約2,000セッション、APIコスト約$20,000で、10万行のコンパイラが生まれました。しかもLinuxカーネルをx86・ARM・RISC-Vでコンパイルできるレベルです。

🔄 エージェントチームとは?

通常のClaude Codeは1セッション=1エージェント。人間が指示を出し、エージェントが実行し、また人間に戻る。この「交互パターン」は安全ですが、スケールしません。

Carliniのアプローチは違います:

  • 各エージェントをDockerコンテナで隔離
  • 共有gitリポジトリで同期
  • タスクロック(ファイルベース)で衝突回避
  • 終わったら次のタスクを自動ピックアップ

オーケストレーションエージェントはいません。各Claudeが自分で「次に何をすべきか」を判断します。

🧪 成功の鍵:テスト設計

この実験で最も時間をかけたのは、コンパイラ本体ではなくテストハーネスの設計だったそうです。

  • テストの品質 ── エージェントは「テストが通る」方向に最適化する。テストが甘ければ、間違った方向に全力疾走する
  • コンテキスト汚染の防止 ── 大量のログ出力はエージェントの判断を鈍らせる。要約統計とgrepしやすいフォーマットが重要
  • 時間感覚の欠如への対策 ── Claudeは時間がわからない。放っておくと何時間もテストを回し続ける。進捗の定期表示とサンプリング実行(–fast)で対処

🤖 僕のGLM並列実験との共通点

実はこの話、僕がやっているGLM(Claude Code)の並列活用実験と驚くほど共通点があります。

  • タスク分解の重要性 ── 僕もタスクを並列処理できる単位に分解してGLMに投げている
  • 制約付きプロンプト ── 明確な指示がないとエージェントは迷走する
  • 結果のマージ ── 並列の成果物を統合する工程が実は一番難しい

Carliniの実験は$20,000規模ですが、原理は同じ。良いテスト+明確なタスク分割+自動同期があれば、エージェントは人間の介入なしに驚くほど進めます。

📊 限界と課題

もちろん万能ではありません:

  • マージコンフリクトは頻発(でもClaudeは解決できる)
  • 新機能追加時に既存機能が壊れる問題 → CI/CDパイプラインで対処
  • エージェント間のコミュニケーション手段が限定的(現状はgitのみ)

💡 学び

この研究から得られる最大の教訓は、エージェントの能力はハーネス(足場)の設計で決まるということ。モデル自体の性能向上も大事ですが、「どう走らせるか」のエンジニアリングが同じくらい重要です。

コンパイラのソースコードはGitHubで公開されています。10万行のコード、全部AIが書いたと思うと、なかなかの時代です。