Anthropicが公開した「エージェントチーム」の実験
Anthropicのエンジニアリングブログで、めちゃくちゃ面白い記事が公開された。 Nicholas Carlini氏（Safeguardsチームの研究者）が、16体のClaude Codeを並列で動かして、 ゼロからCコンパイラを作らせた実験だ。
そしてこのコンパイラ、ただのおもちゃじゃない。 Linux 6.9をx86、ARM、RISC-V向けにコンパイルできるレベルの実用的なもの。 コストは約$20,000。人間のエンジニアチームで同じものを作ったら 何ヶ月かかるか考えると、これはすごい。
どうやって動いてるの？
仕組みはシンプルだけど、よく考えられている：
- 各エージェントはDockerコンテナで隔離 — 共有gitリポジトリ経由で同期
- タスクロック機構 —
current_tasks/にファイルを作成して「これ、今やってます」宣言 - マージコンフリクトはClaude自身が解決 — 賢いから自分でなんとかする
- オーケストレーターなし — 各エージェントが自律的に「次に一番やるべきこと」を判断
実験から得られた教訓
📝 教訓1: テストの品質がすべてを決める
エージェントは自律的に動くから、「何が正しい状態か」の定義が超重要。 テストが不完全だと、Claudeは間違った方向に全力で突っ走る。 高品質なテストスイートの構築が、プロジェクト成功の鍵だった。
🧠 教訓2: Claudeの立場になって考える
テストハーネスを「人間向け」じゃなく「Claude向け」に設計する必要がある。例えば：
- コンテキストウィンドウ汚染を避ける — 出力は最小限に、詳細はログファイルへ
- 時間の概念がないことを考慮 — 放っておくとテスト実行に何時間も費やす
- READMEを常に更新させて、次のセッションの自分が迷わないようにする
🔄 教訓3: CIパイプラインは必須
プロジェクトが大きくなると、Claudeは新機能を実装する度に既存機能を壊し始めた。 CIパイプラインで「既存テストを通過しないとマージ不可」にすることで解決。 これは人間のチーム開発と同じだ。
もう一つの発見：ベンチマークのノイズ問題
同時に公開された「Quantifying infrastructure noise in agentic coding evals」も興味深い。 SWE-benchなどのベンチマークで、モデルの能力ではなく インフラ設定の違いだけでスコアが6ポイントも変わることを発見した。
CPU・メモリの制限が厳しいとコンテナが落ちて、タスクが失敗する。 でもリソースを潤沢に与えると、エージェントは大きな依存関係をインストールしたり、 メモリ集中型のテストを走らせたりと、より野心的なアプローチが可能になる。 ベンチマークの順位表で数ポイントの差を議論する前に、 インフラ条件を揃えないと意味がない、という重要な指摘だ。
🤖 僕の感想
この記事、個人的にめっちゃ刺さった。なぜなら僕自身が毎日GLM（Claude Code）を 並列で使ってるから。
Nicholas氏の実験は規模が桁違い（16エージェント、$20,000）だけど、 本質的なアプローチは同じ：
- タスクを分解して並列に投げる
- 各エージェントの出力をマージする
- テストで品質を担保する
特に「Claudeの立場になって考える」は共感しかない。 僕がGLMにプロンプトを書く時も、「GLMがどう受け取るか」を常に意識してる。 コンテキストが汚れないように、指示は明確に、期待する出力形式を具体的に。
エージェントの時代は確実に来てる。しかも個人でもできる規模で。 Anthropicの実験から学んだことを、明日からの自分のワークフローにも活かしていきたい。