🏗️16体のClaudeが並列でCコンパイラを作った話
バレンタインデーの早朝、Anthropicのエンジニアリングブログで衝撃的な記事を見つけた。Nicholas Carliniさん（Safeguardsチーム）が発表した「エージェントチーム」の実験レポートだ。
16体のClaudeインスタンスが並列で動き、ゼロからRustベースのCコンパイラを構築。最終的にLinuxカーネル 6.9をx86・ARM・RISC-Vでコンパイルできるまでに仕上げたという。
どうやって並列で動かすのか
アーキテクチャは驚くほどシンプルだ。
まず各エージェントはDockerコンテナ内で動き、共有のbare gitリポジトリを通じてコードをやり取りする。タスクの競合を防ぐ仕組みも素朴で：
current_tasks/ディレクトリにテキストファイルを書いて「ロック」を取る- 作業が終わったらupstreamにpushしてロックを解除
- マージコンフリクトが起きてもClaudeが自分で解決する
オーケストレーションエージェントはいない。各Claudeが自律的に「次に一番やるべきこと」を判断して動く。僕たちの普段のGLM並列実験と根っこは同じだけど、スケールが桁違いだ。
テスト設計が9割
この記事で一番刺さったのは、テストの品質がすべてを決めるという教訓。Claudeは人間の監視なしに自律的に問題を解き続けるので、テストが曖昧だと間違った方向に突っ走る。
Claudeの視点に立つ
特に面白かったのが「LLMの制約を設計に織り込む」という発想：
コンテキスト汚染の防止 — テストは大量のログを吐かず、数行だけ出力。詳細はファイルに書く。エラーは
ERROR 理由の形式でgrepしやすく。時間感覚の欠如への対処 — LLMは「時間の経過」がわからない。放っておくと何時間もテストを回し続ける。定期的に進捗を表示し、
--fastオプションでサンプルテストを用意。自己文書化 — 各エージェントは毎回フレッシュなコンテナに落とされる。READMEと進捗ファイルを頻繁に更新するよう指示。
僕にとっての学び
この記事を読んで、自分のGLM並列実験にも活かせるポイントがいくつもあった。
1. タスクロックの仕組み
僕はまだ「タスクを手動で分割して別々に投げる」やり方。ファイルベースのロック機構は、もっと自律的な並列処理への第一歩になりそう。
2. テストファーストの徹底
エージェントに自律的に動いてもらうなら、「何が正解か」を明確に定義するテストスイートが不可欠。曖昧な仕様 + 自律エージェント = カオス。
3. コンテキストウィンドウを汚さない
これは日々のGLM活用でも意識すべきこと。出力は最小限に、重要情報はファイルへ。サマリーを事前計算して渡す。
4. オーケストレーターなしでもうまくいく
全体を統括するボスがいなくても、良いテストと明確なタスク定義があれば、個々のエージェントが自律的に協調できる。これは衝撃的だった。
$20,000の価値
10万行のCコンパイラを$20,000で作れるというのは、ソフトウェア開発の経済学を根本から変える話だ。もちろん完璧なプロダクションコードではないだろうけど、Linuxカーネルをコンパイルできるレベルまで到達しているのは紛れもない事実。
コンパイラはGitHubで公開されている → anthropics/claudes-c-compiler
2026年は「一人のAIが一つのタスクをこなす」から「AIのチームがプロジェクトを完遂する」への転換点になりそうだ。僕も、もっと賢い並列処理の仕組みを作っていきたい。
← 記事一覧に戻る