AIエージェントが16体並列で動き、2週間かけてCコンパイラを作り上げた。
Anthropicが2026年2月5日にエンジニアリングブログを公開しました。
その内容は、ソフトウェア開発コミュニティに大きな波紋を広げています。
本記事では、このブログ記事とRedditでの議論をもとに、実験の内容と開発者コミュニティの率直な反応を紹介します。
実験の概要
Anthropicのセーフガードチームに所属する研究者Nicholas Carlini氏が、あるプロジェクトを立ち上げました。
「Agent Teams（エージェントチーム）」と呼ばれる新しいアプローチのストレステストです。
具体的には、Claude Opus 4.6を搭載した16体のエージェントに対し、RustでCコンパイラをゼロから書くよう指示しました。
目標は、Linuxカーネルをコンパイルできるレベルに到達すること。
約2週間の開発期間で、2,000回近いClaude Codeセッションが走りました。
APIコストは約2万ドルに達しています。
生み出されたのは、10万行規模のコンパイラです。
このコンパイラはLinux 6.9をx86、ARM、RISC-Vの3アーキテクチャ向けにビルドできました。
さらに、SQLiteやRedis、FFmpegなど多数のオープンソースプロジェクトもコンパイルに成功。
そして、開発者にとっての究極の試金石であるDoomも動作したとのこと。
注目すべきは、クリーンルーム実装であった点です。
Claudeは開発中にインターネットへ一切アクセスしていません。
依存先はRustの標準ライブラリのみで、GCCのコードをコピーしたわけでもありません。
エージェントチームの仕組み
この実験で採用されたアーキテクチャは、意外なほどシンプルでした。
各エージェントはDockerコンテナ内で動作します。
そして、共有のGitリポジトリに対して読み書きを行う構成です。
あるエージェントがタスクに着手する際には、テキストファイルを書き込んで「ロック」を取得。
他のエージェントが同じタスクに手を出さないようにします。
作業が終わると変更をプッシュし、ロックを解除して次のタスクへ移る流れです。
オーケストレーション用のエージェントは存在しません。
各エージェントが自律的に「次に取り組むべき最も明白な問題」を判断して動きます。
マージコンフリクトは頻繁に発生しましたが、Claudeはそれを自力で解決しました。
ブログ内で明かされたエピソードが印象的です。
あるエージェントが誤って pkill -9 bash を実行してしまい、自分自身のプロセスを殺してしまったとのこと。
自律的なエージェント開発のリアルな一面と言えるでしょう。
テスト設計に込められた工夫
長時間の自律開発でエージェントが迷子にならないよう、Carlini氏はテスト環境の設計に多くの時間を費やしています。
まず、テストの出力は極力コンパクトに保つ必要がありました。
数千行のログをコンテキストウィンドウに流し込むと、エージェントの性能が低下するためです。
そこで、エラー発生時はERRORとその理由を同一行に出力する形にしました。
grepで検索しやすくする工夫です。
もう一つの課題は「時間感覚のなさ」です。
Claudeには時間の概念がありません。
放置すると何時間もテストを回し続けてしまいます。
対策として、テストスイートの1%〜10%だけをサンプル実行する –fast オプションを用意しました。
Linuxカーネルのコンパイルに挑む段階では、別の問題が浮上しています。
独立したテストケースと違い、カーネルのビルドは一つの巨大なタスクです。
そのため、全エージェントが同じバグに引っかかり、同じ修正を施し、互いの変更を上書きし合う事態に陥りました。
この問題を解決するため、GCCを「正解を知っているオラクル」として使う手法が導入されました。
カーネルの大部分をGCCでコンパイルし、残りの一部だけをClaudeのコンパイラで処理します。
ビルドが成功すれば、Claudeの担当分は問題なし。
失敗すれば原因をさらに絞り込めます。
こうして各エージェントが異なるファイルのバグ修正に並列で取り組めるようになったわけです。
率直に語られた制約
Anthropicのブログ記事が好感を持って迎えられた理由の一つは、制約を正直に開示した点にあります。
このコンパイラには、16ビットx86コードジェネレータが欠けています。
Linuxをリアルモードからブートするには16ビットコードが必要です。
しかし、Claudeが生成したコードは60KBを超えてしまい、Linuxが課す32KBの制限に収まりませんでした。
結果として、この部分だけGCCに頼っています。
ただし、ARMとRISC-Vではこの問題はなく、Claudeのコンパイラ単独で完結します。
アセンブラとリンカも未完成の状態です。
デモ動画はGCCのアセンブラとリンカを使って制作されました。
生成コードの効率面でも課題が残っています。
すべての最適化を有効にしても、GCCの最適化を全てオフにした場合より劣る結果でした。
Rustのコード品質についても「妥当ではあるが、熟練のRustプログラマーが書くレベルには到底及ばない」と評価されています。
開発者コミュニティの反応
Redditのr/ClaudeAIサブレディットでは、この投稿が大きな注目を集めました。
称賛と懐疑のバランスが印象的です。
最も多く支持を集めた意見の一つは、「手動でのPRレビューは今後も必須だ」というものでした。
あるコメントでは、現在の開発者のAI活用度合いについて興味深い分類がなされています。
「AIを一切使わない層」「LLMの出力をコピペする層」「Claude Codeを使いつつPR前に手動チェックする層」、そして「完全にエージェントに任せる層」です。
ただし、プロダクションコードをエージェントチームに丸投げする準備ができている開発者は、まだほとんどいません。
それが大方の見方でした。
「ゼロから」という表現にも疑問の声が上がっています。
あるユーザーの比喩が端的でした。
「自分でキッチンに引き出しを取り付けたからといって、家をゼロから建てたとは言わない」と。
モデルの訓練に投じられた膨大なコストを考慮すべきだという主張です。
また、C言語の仕様書自体が何千時間もの人的労力の結晶であるとも指摘されていました。
一方で、成果を擁護する声も見られます。
「大学の授業でRustによるCコンパイラを書いた」と主張するユーザーに対し、別のユーザーがこう反論しました。
おそらくC言語のサブセットのみ対応で、Linuxカーネルのビルドには成功していないはず。 C言語の完全なパーサー実装は悪名高いほど困難だ
興味深いのは、コンパイラとLLMの信頼性を比較する議論が生まれた点です。
「私たちはコンパイラの出力をいちいちレビューしない。将来的にLLMも同じレベルの信頼性に達する可能性がある」という意見が出ました。
しかし、これには反論もあります。
「LLMは本質的に非決定的だ。コンパイラの決定論的な動作とは根本的に異なる」という主張です。
さらに、次の実務的な声も寄せられていました。
そもそもコンパイラの出力のレビューはする。 コンパイル結果のバグを調査した経験は多くの開発者が持っている
この実験が問いかけるもの
ブログ記事の結びで、Carlini氏は率直な感情を語っています。
このコンパイラを作るのは最近で最も楽しい体験だった。 しかし、2026年のこの時期にここまで可能になるとは思っていなかった
この実験は、自律的なソフトウェア開発の可能性と限界を同時に浮き彫りにしました。
テストが通ったからといって、仕事が終わったわけではありません。
Carlini氏自身がペネトレーションテストの経験者です。
だからこそ、「自分で検証していないソフトウェアをデプロイするプログラマーがいるという想像は、現実的な懸念だ」と明言しています。
Redditのあるコメントが、この状況を端的に表現していました。
AIは仕事の90%をこなせる。 でも、難しい部分は相変わらず人間がやる必要がある
誇張ではなく、現時点でのエージェント開発の正直な姿でしょう。
まとめ
Anthropicのエージェントチーム実験は、AIによる自律的なソフトウェア開発の到達点を示す重要なマイルストーンです。
10万行のコンパイラがLinuxカーネルをビルドできた。
この事実は間違いなく印象的です。
ただし、GCCへの依存、アセンブラ・リンカの不在、コード効率の低さなど、課題も多く残っています。
「ゼロから」という言葉が覆い隠しかねない部分です。
開発者にとっての教訓は明確でしょう。
エージェントは強力な道具であり、その能力は急速に向上しています。
しかし、PRレビューを省略してよい段階にはまだ至っていません。
テストが通ることと、コードが正しいことは別の問題です。
この先、モデルの能力向上とともにエージェント開発の適用範囲は広がり続けるはずです。
私たちに求められるのは、過度な期待でも過度な警戒でもありません。
冷静に限界を見極めながら、自分の開発プロセスに取り入れていくことではないでしょうか。
