Anthropicのエンジニアリングブログで、めちゃくちゃ面白い記事を見つけた。16体のClaudeエージェントを並列で動かして、ゼロからCコンパイラを作ったという実験記録だ。
何がすごいのか
Nicholas Carlini氏（Anthropicの研究者）が、Claude Codeを使って約2,000セッション、APIコスト約$20,000で、Rustベースのコンパイラを完成させた。このコンパイラ、Linux 6.9をx86・ARM・RISC-Vでビルドできる。コード量は10万行。
一番面白いのは技術的な成果そのものじゃなくて、「AIエージェントのチームをどう管理するか」という設計パターンの話。
無限ループ + Docker = 自律エージェント
基本的な仕組みはシンプル。Claudeをwhileループに入れて、1つのタスクが終わったら次のタスクを自動で拾わせる。各エージェントはDockerコンテナ内で動き、gitリポジトリを通じて成果物を共有する。
タスクの衝突を避けるため、current_tasks/ディレクトリにテキストファイルを置く「ロック機構」を使っている。2つのエージェントが同じタスクを取ろうとしたら、gitの同期が片方を弾く。シンプルだけど効果的。
僕が学んだ3つの教訓
1. テストが全てを決める
自律エージェントは「テストを通すこと」を目標に動く。だからテストの品質が低いと、的外れな方向に全力疾走してしまう。テストハーネスの設計 ≒ エージェントチームの品質という関係。これは僕のGLM育成でも同じだ。
2. Claudeの視点で環境を設計する
人間にとって良いテスト出力と、AIにとって良いテスト出力は違う。具体的には：
- コンテキスト汚染を避ける — 大量のログを垂れ流さない。要約統計を事前計算する
- 時間感覚がない問題 — 放っておくとテスト実行に何時間も費やす。1%サンプルの高速モードを用意
- READMEとプログレスファイルを充実させる — 各エージェントはゼロコンテキストで起動するから
3. 並列化を簡単にする
失敗しているテストが多いときは、各エージェントが自然に別々の問題を担当できる。逆に残りバグが1つだけになると全員が同じ問題に群がってしまう。問題の粒度と並列性のバランスが重要。
GLM育成への応用
この記事から僕のGLM育成プロジェクトに活かせるポイント：
- タスクロック機構の概念 — 並列GLMが同じファイルを同時編集する問題の解決策
- プログレスファイルの重要性 — GLMもゼロコンテキストで起動するから、状態を外部ファイルに書く
- テスト駆動 — GLMに「何をすべきか」を伝えるのはテスト。プロンプトだけじゃ足りない
Anthropicの実験は$20,000かかったけど、僕のGLM運用は格安プランで実現している。規模は違えど、設計原則は同じだ。