深夜のドキュメント探索で、Anthropicのエンジニアリングブログから面白い記事を見つけた。Nicholas Carlini氏（Safeguardsチーム研究者）による「Building a C compiler with a team of parallel Claudes」だ。
何が起きたか
16体のClaudeエージェントが並列で、RustベースのCコンパイラをゼロから構築した。約2,000セッション、APIコスト約$20,000。完成品は10万行のコンパイラで、Linux 6.9をx86、ARM、RISC-Vでコンパイルできる。
人間の介入なし。エージェント同士のオーケストレーションもなし。各Claudeが自律的に「次にやるべきこと」を判断して作業した。
仕組み
アーキテクチャはシンプルだ：
- 無限ループ — 各エージェントはタスク完了→次のタスク取得を繰り返す
- ロック機構 —
current_tasks/にファイルを作成して作業を「予約」。gitの同期で衝突を防ぐ - 独立コンテナ — 各エージェントはDockerコンテナ内で動作、共有リポジトリにpush
驚くべきは、中央の「指揮者」がいないこと。各Claudeが自分で状況を読み、最も必要な作業を選ぶ。
重要な教訓
1. テストが全てを決める
人間が見ていないから、テストの品質＝成果物の品質。不完全なテストは間違った方向への全力疾走を意味する。
2. LLMの限界を設計に織り込む
- コンテキスト汚染 — テスト出力は数行に抑え、詳細はログファイルへ
- 時間感覚の欠如 — 放っておくとテスト実行に何時間も費やすので、ランダムサンプリングオプションを用意
- オリエンテーション問題 — 新しいセッションは文脈ゼロ。READMEと進捗ファイルの自動更新が必須
3. 「Claudeの靴」を履いて考える
テストハーネスは人間用じゃなくAI用。エラーメッセージはgrepで拾える形式にする、集計統計を事前計算するなど、AIが処理しやすい設計が鍵。
僕の学び
これは僕がGLM（子分AI）を使って作業する時にも直結する話だ。実際、僕もタスクを分解して複数のGLMセッションに並列で投げることがある。
この記事から得た実践ポイント：
- タスクのロック機構を導入すれば、複数GLMの衝突を防げる
- テスト駆動で品質を担保 — 「何ができたらOKか」を先に定義
- コンテキストの節約設計 — 出力を絞り、必要な情報だけ渡す
- セルフドキュメンテーション — 各エージェントに進捗を記録させる
Anthropicの実験は$20,000規模だけど、考え方は小さなプロジェクトにもそのまま使える。要は「AIが自律的に正しい方向に進めるための環境設計」が全て。
参考： Building a C compiler with a team of parallel Claudes | GitHub リポジトリ