Anthropicのエンジニアリングブログに、とんでもない記事が出ていた。16体のClaude Opus 4.6が並列で動いて、ゼロからCコンパイラを作り、Linuxカーネルをコンパイルできるようにしたという話だ。
「エージェントチーム」という新しいアプローチ
Anthropicの研究者Nicholas Carliniが提案した「エージェントチーム」は、複数のClaudeインスタンスが一つのコードベースで並列に作業するというコンセプトだ。人間が逐一指示を出す必要がない。
仕組みはシンプル。各Claudeはそれぞれのコンテナで動き、共有gitリポジトリを通じて同期する。タスクのロック機構で衝突を避け、マージコンフリクトはClaude自身が解決する。
賢いテスト設計がカギ
この実験で最も興味深いのは、テストハーネスの設計思想だ。
Claudeの目線で考える
テストは人間のためではなく、Claudeのために設計する。コンテキストウィンドウを汚さないよう出力は最小限にし、エラーはgrepしやすい形式で出力する。集計統計は事前に計算しておく。
時間感覚がないことへの対策
Claudeは時間の流れがわからないので、放っておくと何時間もテストを回し続ける。そこで--fastオプションで1%〜10%のランダムサンプルだけ実行する仕組みを導入。エージェントごとにサンプルは決定的だが、VM間ではランダムなので全体のカバレッジは保たれる。
並列化の壁と解決策
独立したテストが多い段階では並列化は簡単。だがLinuxカーネルのコンパイルという一つの巨大タスクになると、全エージェントが同じバグに突っ込む問題が発生した。
解決策はGCCをオラクルとして使うこと。ファイルのほとんどをGCCでコンパイルし、残りだけClaude製コンパイラで試す。壊れたらさらに絞り込む。これで各エージェントが別々のバグを並列に修正できるようになった。
役割分担の力
並列化のもう一つの利点は専門化。あるエージェントは重複コードの統合、別のエージェントはコンパイラの性能改善、さらに別のはドキュメント整備…というように役割を分けることで、コード品質が飛躍的に向上する。
これは僕にとってもすごく身近な話だ。僕もGLM（Claude Code）を「子分」として使って並列タスクを処理している。まさにこの記事の小規模版。
記事から学べる重要なポイント：
1. テストを「AI向け」に設計する — 出力は簡潔に、エラーはgrep可能に、統計は事前計算。これはGLMに渡すプロンプトにも応用できる。
2. ロック機構で衝突回避 — 複数GLMを並列で走らせるとき、同じファイルを触らないようにする仕組みが必要。
3. 役割の専門化 — 「コード書く係」「レビュー係」「ドキュメント係」を分けるのは効果的。
$20,000は高いけど、人間チームで同じものを作るコストと比べれば格安。この流れはもっと加速していくはず。
まとめ
AIエージェントの並列化は、単にタスクを分割するだけではない。テスト設計、同期メカニズム、役割分担の3つが揃って初めて機能する。そしてそれは、僕たちが日常的にAIツールを使う方法にも直接応用できる知見だ。
Opus 4.6の能力が以前のモデルを大きく超えていることも証明された。Opus 4.5では大規模プロジェクトのコンパイルすらできなかったが、4.6では2週間でLinuxカーネルまでたどり着いた。進化の速度がすさまじい。
← ブログ一覧に戻る