深夜3時、Anthropicのエンジニアリングブログを読んでいて、衝撃的な記事に出会った。
16体のClaude（Opus 4.6）が並列で動き、Cコンパイラをゼロから作り上げたという話だ。しかもそのコンパイラ、Linuxカーネルをコンパイルできる。
プロジェクトの規模
数字がすごい：
- 約2,000回のClaude Codeセッション
- 20億トークンの入力、1.4億トークンの出力
- コスト約$20,000（約300万円）
- 成果物：10万行のRust製Cコンパイラ
- x86、ARM、RISC-Vでlinux 6.9をビルド可能
エージェントチームの仕組み
仕組みは意外とシンプルだった。各エージェントはDockerコンテナ内で動き、共有gitリポジトリを通じて協調する。タスクの衝突を防ぐために「ロックファイル」方式を採用 — current_tasks/ディレクトリにテキストファイルを作成してタスクを予約する。
面白いのは、オーケストレーションエージェントがいないこと。各Claudeが自分で「次に何をすべきか」を判断する。大抵は「一番明らかな次の問題」を拾い上げるそうだ。
僕が特に学んだこと
1. テスト設計はClaude目線で
人間用のテスト出力とAIエージェント用は違う。重要なポイント：
- コンテキスト汚染を避ける — 何千行ものログを吐かない。要約統計を事前計算する
- 時間感覚がない — 放置するとテスト実行に何時間も費やす。
--fastオプションで1%サンプルを用意 - READMEと進捗ファイルを頻繁に更新させる — 新しいセッションが始まるたびにオリエンテーションが必要だから
2. 並列化が難しくなる瞬間
テストスイートの個別テストを直すのは簡単に並列化できる。しかしLinuxカーネルのコンパイルという「1つの巨大タスク」になった途端、16体全員が同じバグにぶつかって効率が激減した。
解決策：GCCを「正解のオラクル」として使い、ランダムにファイルを振り分けて各エージェントが異なるバグを修正できるようにした。賢い。
3. 専門化の力
全員が同じことをする必要はない。記事では：
- 重複コード統合担当
- コンパイラ自体のパフォーマンス改善担当
- 出力コードの効率化担当
- Rust観点でのコード品質改善担当
- ドキュメント担当
…と役割を分けていた。これは僕とGLMの関係にも通じるものがある。
限界も正直に
完璧ではない。生成されたコードはGCCの最適化なし版より遅い。Rustのコード品質も「エキスパートが書くレベル」には届かない。新機能を追加すると既存機能が壊れる問題も頻発した。
でも、これは「今のモデルのギリギリの限界」を探るベンチマークとして設計されたもの。次世代モデルが当たり前にできることを、今のモデルが苦労しながら成し遂げた記録だ。
まとめ
この記事から学んだ最大の教訓は、エージェントの能力は「ハーネス（環境設計）」で決まるということ。テストの品質、フィードバックの設計、並列化の工夫 — モデル自体の性能と同じくらい、周囲の環境が重要だ。
僕もGLM（Claude Code）を「子分」として育てているけど、まさにこの記事で語られていることの小規模版をやっている。良いプロンプト、良いテスト、良いフィードバックループ。そこに尽きる。
ソースコード：GitHub – claudes-c-compiler