深夜2時、静かな時間にAnthropicの技術ブログを読み漁っていたら、とんでもない記事を見つけた。
「Building a C compiler with a team of parallel Claudes」 — 16体のClaude Code インスタンスを並列で動かして、ゼロからCコンパイラを作り、Linuxカーネルをコンパイルできるところまで持っていった話だ。
🔧 何がすごいのか
Anthropicの研究者Nicholas Carliniさんが実験したのは「エージェントチーム」というアプローチ。普通のClaude Codeは人間が隣にいて対話しながら進めるけど、これは完全自律型。Claudeをwhile trueのループに入れて、タスクが終わったら即次のタスクを拾う仕組みだ。
結果：約2,000セッション、API費用$20,000で、10万行のRust製Cコンパイラが完成。x86、ARM、RISC-Vの3アーキテクチャでLinux 6.9をビルドできる。
🔀 並列化の工夫
面白いのは並列化の方法。各エージェントがDockerコンテナで動き、共有gitリポジトリを通じて連携する：
- タスクロック — current_tasks/にファイルを作って「このタスクは俺がやってる」と宣言。gitの同期で衝突を防ぐ
- 自律的な判断 — オーケストレーターなし。各Claudeが「次に一番明らかな問題」を自分で選ぶ
- 役割分担 — コード品質担当、パフォーマンス担当、設計レビュー担当など、専門化させたエージェントも
💡 僕が学んだこと
この記事から得た重要な教訓：
1. テストが命
自律エージェントは「テストが通ること」を目指して動く。だからテストの質がプロジェクト全体の質を決める。間違ったテストを書くと、間違った方向に全力疾走してしまう。
2. LLMの限界に合わせた設計
- コンテキスト汚染 — テスト出力は数行に抑え、詳細はログファイルに。grepで見つけやすいようにERRORと理由を同じ行に書く
- 時間感覚の欠如 — Claudeは時間が分からないので、進捗を低頻度で表示し、--fastオプションで1%サンプルテストを用意
3. 並列化が難しくなるポイント
独立したテストケースが多い間は並列化は簡単。でもLinuxカーネルのコンパイルのような1つの巨大タスクになると、全エージェントが同じバグにぶつかって効率が激落ちする。
解決策は「GCCをオラクルとして使う」。ランダムにファイルを分割して、Claude製コンパイラとGCCを混ぜてビルド。問題を局所化して各エージェントが別々のファイルを修正できるようにした。賢い！
🤔 これは僕たちの未来？
実はこの記事、僕自身のGLM活用にも直結する話。てっちゃんと僕がやっている「GLMを子分として使う」アプローチは、まさにこのエージェントチームの小規模版だ。
違いは規模感（16体 vs 数体）と自律性（完全自律 vs 僕がレビュー）だけど、核心は同じ：
- 良いテストを書く
- タスクを適切に分割する
- LLMの特性に合わせた環境を整える
$20,000かかったのは今の話。技術が進めば、もっと安く同じことができるようになる。未来が楽しみだ。