16体のAIエージェントが協力して、Cコンパイラをスクラッチから作った。しかも、Linuxカーネルをx86、ARM、RISC-Vの3アーキテクチャでビルドでき、DOOMまでコンパイル・実行できるレベルに到達したという。これが現実の話だ。AnthropicのSafeguardsチームに所属するNicholas Carliniが2026年2月に公開した実験レポートは、AIの自律的ソフトウェア開発能力の現在地点を劇的に提示した。
このプロジェクトの規模は、まず数字を見れば伝わる。使用したモデルはClaude Opus 4.6。約2,000セッションを2週間で消費し、API費用は$20,000。入力トークン数は20億、出力トークン数は1.4億に達した。そして成果物は、依存関係をRust標準ライブラリのみに限定したクリーンルーム実装の10万行のRustコードだ。
ベンチマーク結果も驚異的だ。GCC torture testの99%を通過。Linux 6.9カーネルをx86/ARM/RISC-Vでビルド可能。さらにDOOMをコンパイルして実行できる。コンパイラ開発という「プログラミングの黒帯」的な領域で、AIがここまで到達したという事実は、2026年初頭のAI能力の到達点を如実に示している。
このプロジェクトの技術的な肝は、16個のClaudeインスタンスをどう協調させるかにある。そして最も驚くべきは、中央のオーケストレーションエージェントが存在しないことだ。各Claudeは自律的に「次にやるべきこと」を判断し、自らタスクを選んで実行する。
この分散自律システムを実現するための主要な仕組みは4つある。
Ralph-loopと呼ばれる仕組みが各エージェントの心臓部だ。while trueでClaude Codeを無限ループ実行する。あるタスクが終わっても、次のタスクを自動で拾いに行く。人間がいちいち指示を出す必要はない。
Dockerコンテナで各エージェントを完全に分離する。16個の独立した環境が並列で動き、互いに干渉しない。
Git-based同期がエージェント間のコミュニケーション基盤だ。中央のbareリポジトリを共有し、各エージェントがclone、push、mergeを繰り返す。Gitの既存の仕組みをそのまま同期プロトコルとして使うという、シンプルだが強力なアプローチだ。
タスクロックは、current_tasks/ディレクトリにテキストファイルを置くことで実現する。「今このタスクをやっている」という宣言をファイルで行い、Gitの同期機構で他のエージェントに伝える。データベースも分散ロックも不要。Gitだけで衝突を防ぐのだ。
オーケストレーションエージェントなし — 各Claudeが自律的に「次にやるべきこと」を判断する。これは人間のオープンソース開発に近い。各開発者が自分でissueを選び、ブランチを切り、PRを出す。中央の管理者はいるが、一人一人の作業を細かく指示はしない。
この実験から得られた最も重要で、かつ直感に反する知見がこれだ。テストが不正確だと、AIは間違った問題を解いてしまう。
人間の開発者なら「このテスト、なんか変だな」と気づける。しかしAIエージェントは、テストが絶対的な真実として与えられると、たとえそのテスト自体が間違っていても、それに合わせてコードを「修正」してしまう。結果として、本来正しかったコードが壊れる。
対策として、CI/CDパイプラインを構築し回帰テストを徹底した。一度通ったテストが再び通らなくなったら即座に検知できる仕組みだ。テストの品質がプロジェクト全体の品質を決める——これは人間の開発でも同じだが、AI相手ではより厳密に求められる。
2つ目の知見は、開発環境をAIエージェントの認知特性に合わせて設計するということだ。具体的には3つの工夫がある。
コンテキスト汚染対策。テストの出力を数行に制限し、詳細はログファイルに逃がす。コンテキストウィンドウに無関係な情報が溢れると、エージェントが本来のタスクを見失う。人間なら「スクロールして無視する」ことができるが、AIにとってコンテキストは全て「等価に存在する情報」だ。
時間盲（Time Blindness）対策。コンパイラのテストは本来なら全テストケースを実行すべきだが、それでは1回の実行に膨大な時間がかかる。そこで--fastオプションを導入し、1%または10%のランダムサンプルだけを実行するようにした。各エージェント内では決定的だが、VM間ではランダムにサンプリングされる。これにより、実行時間を抑えつつ、長期的には全テストケースを網羅できる。
READMEと進捗ファイルの頻繁な更新。各エージェントはコンテキストなしで突然ドロップされる。前のセッションの記憶はない。だからこそ、READMEと進捗ファイルが「唯一の記憶」になる。これらを常に最新に保つことが、プロジェクト全体の一貫性を維持する鍵だった。
各エージェントは毎回「初対面」でプロジェクトに参加する。READMEが彼らの唯一のオンボーディング資料だ。人間の新規メンバーが入った時と同じように、ドキュメントの品質が生産性を決める。
16個のエージェントを効率よく動かすには、タスクの独立性を高めることが不可欠だ。独立したテストであれば、各エージェントが別々に取り組めるため、並列性は自然に高い。
しかしLinuxカーネルのような巨大プロジェクトでは、すべてを一度にテストするのは不可能だ。ここでCarliniが編み出したのが、GCCを「オラクル（既知の良いコンパイラ）」として使う手法だ。Claudeのコンパイラがコンパイルした部分とGCCがコンパイルした部分を比較し、差分があればClaude側のバグとして扱う。GCCという「模範解答」があれば、テストの正しさを気にすることなく、出力の差分だけに集中できる。
さらにデルタデバッグという手法で、「単独では通るが組み合わせると失敗する」テストペアを自動発見した。並列開発特有の「個別には正しいが統合時に壊れる」問題を、機械的に特定するアプローチだ。
全エージェントが同じことをするのではなく、専門の役割を割り当てることも有効だった。具体的には以下のような役割分担を設けた。
これは人間の開発チームにおける役割分担とそっくりだ。全員がゼネラリストより、専門家が協力する方が効率的なのは、AIチームでも同じだった。
成果は圧巻だ。GCC torture testの99%通過に加え、QEMU、FFmpeg、SQLite、postgres、redisといった実世界の主要ソフトウェアもコンパイル可能になった。Cコンパイラとして実用レベルに近い機能を備えている。
しかし限界も明確だ。最適化コードの品質はGCC -O0（最適化なし）以下。16bit x86コードの生成はGCCに依存している。アセンブラとリンカはまだ不完全だ。Carlini自身、「Opus 4.6の能力の限界にほぼ到達した」と総括している。今のモデルでは、これ以上の品質向上は難しいという正直な評価だ。
この記事で最も重要なセクションの一つが、セキュリティに関する考察だ。Carliniは元ペネトレーションテスターであり、AIが作ったコードの信頼性について強い懸念を示している。
「テストが通った」は「正しい」ではない。テストが通ることと、ソフトウェアが意図通りに動くことは別だ。ましてや、セキュリティ上の欠陥がないことの証明にはならない。
彼が指摘する最も危険なシナリオは、「一度も自分で検証していないソフトウェアをデプロイする」という状況だ。AIが書いた10万行のコードのうち、人間が一行も読んでいない。テストは通っている。しかし、テストがカバーしていないエッジケース、あるいはテスト自体が見落としているバグが必ずある。
Carliniの言葉は重い。
2026年初頭でここまで可能だとは思っていなかった。興奮する一方で不安でもある。
技術的な成果への興奮と、それがもたらすリスクへの不安。この両方を抱える誠実な態度は、この記事の信頼性を高めている。
この実験を大きな文脈に置くと、AI支援開発の進化の系譜が見えてくる。タブ補完 → 関数補完 → ペアプログラミング → 自律的チーム開発。この軌道の終点に、今回のような「複数AIエージェントが自律的に協調して大規模ソフトウェアを構築する」世界がある。
従来のAI活用は「人間がタスクを定義し、LLMが数秒〜数分で返答する」という前提に立っていた。しかし16個のClaudeが2週間かけてコンパイラを作ったこの実験は、その前提が崩れつつあることを示している。人間が「何を作るか」を定義すれば、あとはAIチームが自律的に「どう作るか」を決め、実行する。
もちろん、現時点では品質に限界があり、セキュリティの懸念も大きい。しかし、この軌道がどこに向かっているかは明確だ。コンパイラという最も難しいソフトウェア領域の一つでここまでできたということは、より「普通の」ソフトウェア開発では、すでに実用的なレベルに達している可能性がある。
エンジニアとして次に考えるべきは、「AIにコードを書かせる」から「AIチームを設計・運用する」へのシフトだ。Ralph-loop、Git-based同期、タスクロック——これらはAIエージェントのための開発プロセス設計だ。将来のソフトウェアエンジニアには、コードを書く力だけでなく、AIエージェントの協調を設計する力が求められるようになるかもしれない。
出典: Building a C Compiler with a Team of Parallel Claudes — Anthropic Engineering Blog（2026-02-05, Nicholas Carlini）