Claudeに10万行のCコンパイラを書かせた実験 — 16並列・2,000セッション・約2万ドルで何が起きたか

2026年2月5日、AnthropicのSafeguards researcherであるNicholas Carlini氏が、自身のengineering blogで「16並列のClaudeにCコンパイラを書かせた」実験を公開しました。約2週間・2,000セッション・2万ドル弱のAPI予算で、Rust製の10万行Cコンパイラが完成し、x86 / ARM / RISC-Vの3アーキテクチャ向けにLinux 6.9カーネルをビルドできる水準に到達した、という内容です。

本記事は単なる成果紹介ではなく、「長尺コーディングをLLMに任せたとき、何が回り、何が壁になるか」を編集視点で読み解きます。Cコンパイラという題材は古典的に「中規模ソフトウェア工学のベンチマーク」として扱われてきた領域であり、ここで起きた現象は、エージェント型開発を業務に取り込みたい読者にとって参考材料になります。

背景 — なぜ「Cコンパイラ」が試金石になるのか

Cコンパイラは、人間の中級〜上級エンジニアが数か月から1年単位で書く中規模システムソフトウェアの代表例です。仕様(C99 / C11)が明確で、テストの正解(GCCの出力)が外部に存在し、フロントエンド・最適化・コード生成と工程が分かれているため、「自律エージェントが長期間の文脈を維持できるか」を測る素材として向いています。

過去、LLMにフルスタックのアプリを書かせる実験は数多くありましたが、その多くは「短い関数を量産する」「テンプレからWebアプリを組み立てる」レベルにとどまっていました。Cコンパイラは、

• 数十のサブシステムが噛み合う
• 単機能の改善が他の領域を壊しうる(構文木の変更が最適化器を壊す等)
• 正解が「他のコンパイラの出力」という形で外部から検証できる

という性質を備えており、短期記憶の限界・並列分業・テスト設計の3点を同時に試せます。Carlini氏自身も「Opusの能力の限界に近づいた」と表現しており、現行モデルにとっての到達点を測るベンチマーク的な意味合いが強い実験です。

実験の全体像 — 16エージェント・2,000セッション・約2万ドル

数値で見ると、規模の感覚が掴みやすくなります。

入力トークンに対し出力トークンが約14倍少ないのは、エージェントが「コードベース全体を読み込んでから小さな差分を書く」という現実的なソフトウェア開発の挙動と一致しています。プロンプトキャッシュが効きやすい構造ともいえます。

費用の2万ドル弱は、人間エンジニア1人の月給に届かない水準で、10万行規模のRustコードと、それを支えるテスト群が出てきたことになります。「コスト効率の比較」を単純化するのは危険ですが、ベンチマークとしての到達点が「人間1人月の予算内」に入ってきたこと自体が、本実験の最も大きな数字だと読めます。

自律ループの設計 — git同期とファイルロックで「次のタスクを自分で取る」

技術的に最も模倣しやすいのは、エージェントが自分で次のタスクを取りに行く仕組みです。Carlini氏は「Claudeが人手の介入なしに延々と動き続ける」状態を作るため、以下の構成を取りました。

• 各エージェントは独立したセッションで起動
• タスクキューはgitリポジトリ内のcurrent_tasks/ディレクトリ
• エージェントは作業前にロックファイルを書き込み、git pushで他エージェントに「自分が取った」と通知
• 完了後は上流の変更をpullしてマージ、結果をpushしてロックを外す
• 無限ループでセッションを再起動し続ける

これは、いわゆるジョブキュー + 楽観的並行制御をgitで代替した構造です。CIやKubernetesに頼らずgit単体で組めるのが、エージェント運用としては小さく始めやすい点でしょう。並列度が16程度であればgitのロック衝突も現実的に捌けます。

このパターンは、Anthropicが示したcontext engineeringの4戦略のうち「サブエージェントによる並列化」をgit nativeで実装した版とも読め、再現性のあるレシピとして参考になります。

テストが「ほぼ完璧」でないと、Claudeは違う問題を解いてしまう

本記事で繰り返し強調されているのは、テストの質です。Carlini氏は次のように述べています。

"Claude will work autonomously to solve whatever problem I give it. So it's important that the task verifier is nearly perfect, otherwise Claude will solve the wrong problem."

(訳: Claudeは与えた問題を自律的に解くので、タスクの検証器がほぼ完璧でない限り、別の問題を解いてしまう)

これは、人間レビュー前提のCI設計とは要求水準が異なる点を示しています。人間が書くPRであれば、CIが「だいたい通る」で十分でも、コードレビューで意図のずれを補正できます。一方、自律エージェントではテストが通った時点で完了扱いになるため、テストに穴があると、エージェントは穴を通り抜ける最短経路を学習してしまいます。

Carlini氏が紹介している実装上の工夫は、人間ではなくClaudeが読みやすい形でエラーメッセージを設計する点に集約されています。

• エラー文に問題の所在(ファイル名・行・期待値・実測値)を具体的に書く
• コンテキスト汚染を避けるため、不要なログを抑える
• 決定論的にサンプリングできるオプションを用意する

「LLMの読み手目線でテストを書く」という発想は、エージェント向けツール設計の原則で示された「ツールはエージェントが解釈しやすい応答を返すべき」という議論と同じ系譜にあります。テストもツールの一種であると捉えると、整合性が取れます。

並列化のボトルネック — Linuxカーネル単体タスクで足が止まった

並列16エージェントが効果を発揮するのは、タスクが独立した小さな単位に分解されている間だけです。記事内でも、Linuxカーネル全体を1つのタスクとして扱った段階で進捗が頭打ちになった、と報告されています。

打開策は、GCCを「正解オラクル」として参照し、ファイル単位で「GCCの出力と一致するか」を検証する形に分解することでした。これにより、各エージェントは別々のソースファイルを並列に担当でき、再び並列度が活きるようになります。

ここから読み取れる実装原則は単純です。

1. 大きなタスクをそのまま投げない — 並列度に応じて分割可能な粒度に落とす
2. 正解の参照系を外部に置く — 自前のテストだけでなく、既存実装(GCC等)を比較対象に使う
3. 分割の単位を「ファイル / 関数」と一致させる — マージ衝突を最小化できる

逆に言えば、これらが満たされない領域(GUIの細かな調整、対話設計、要件定義など)では、並列エージェント方式は人間チームほど効きにくい、と読むのが現実的でしょう。

エージェントの「役割分担」も人間チームと似てくる

Carlini氏は、専門特化型エージェントを併用することで成果が安定したと述べています。

• 重複コードの整理だけを担当するエージェント
• パフォーマンス最適化だけを担当するエージェント
• ドキュメント生成だけを担当するエージェント

これは、人間ソフトウェアチームでいう「リファクタ係」「パフォーマンスエンジニア」「テクニカルライター」の分業と相似形です。プロンプト設計上は単純で、各エージェントに与えるシステムプロンプトの観点を変え、評価関数(=何を成功とするか)を絞るだけで効果が出る、というのが本実験の示唆です。

Agent Skillsの設計思想と組み合わせると、各役割に固有の知識(コーディング規約、最適化のチェックリストなど)をSkillsとして注入する形でも再現できそうです。

限界の輪郭 — 何が「できなかった」かが最も重要な情報

ベンチマークとしての価値は、できたことよりもできなかったことの輪郭にあります。本記事で明記されている限界は次の通りです。

特に、16-bit x86の出力で60kbを超える(32kbの上限を超過する)ような、アーキテクチャ固有の制約はOpus 4.6でも越えにくかった、と報告されています。これは「過去のモデルでは完全に失敗していた領域に部分的に到達した」という進歩でもあり、同時に「現行世代の限界を示す指標」でもあります。

"The resulting compiler has nearly reached the limits of Opus's abilities." (訳: 出来上がったコンパイラは、Opusの能力の限界にほぼ達している)

この一文は、本実験を「Opus 4.6世代のベンチマーク」として読むうえでの錨になります。次世代モデルが出たとき、同じ方法論で何が「できる側」に移るかを観測する基準点ができた、と捉えられます。

編集視点 — 長尺コーディングの「前提コスト」を可視化した実験

本実験の意味を、編集視点で3点に分けて見ていきます。

1. 「LLMに任せられる規模」の上限が、1段引き上がった

10万行のシステムソフトウェアが、人間1人月以下のAPIコストで仕上がる、というデータポイントが公開されたこと自体が産業的なインパクトです。これまでベンチマーク文脈で語られてきた「数十関数のコード生成」「Webアプリの雛形」とは桁が異なります。

2. 自律エージェント運用は、テスト設計に投資が前倒しされる

人間レビュー前提なら「CIはだいたい通れば良い」で済みますが、自律ループではテストの完成度が上限を決めることが、本記事で明示されました。エージェント型開発を業務導入する場合、まずテスト・受け入れ条件・参照オラクルの設計に工数を割く判断が現実解になりそうです。Claude Codeを使った業務導入では、Claude Codeのサンドボックス設計で示された「実行環境の境界」と組み合わせて、検証器の精度を運用面から担保する構図がイメージしやすくなります。

3. 「人間が検証していないコードのデプロイ」というセキュリティ論点が前景化する

Carlini氏は元penetration testerで、本記事の末尾で「人間が個人的に検証していないソフトウェアを開発者がデプロイすることへの懸念」を明示しています。コンパイラのような基盤ソフトでは特に、生成コードの脆弱性が下流の全ソフトウェアに波及します。エージェントが書いたコードを本番に流す体制を取るなら、検証パイプラインの設計が品質保証の生命線になる、というのが筆者の慎重な楽観の中身です。

まとめ

• 規模感: 16エージェント / 2,000セッション / 2週間 / 2万ドル弱で10万行Cコンパイラ
• ビルド実績: x86 / ARM / RISC-VでLinux 6.9・QEMU・SQLite等が通る水準
• 設計の核: gitとファイルロックで自律ループ、GCCを正解オラクルに使う並列分業
• 最大の教訓: テスト(検証器)の質が上限を決める。「Claudeに読ませる」前提でテストを書く
• 限界: 16-bit x86・アセンブラ・最適化はGCCに及ばず、Opus 4.6世代の天井を可視化した
• 次の論点: 自律生成コードの検証・デプロイ責任をどう設計するか(Claude Code完全ガイドで扱う運用面と地続き)

Cコンパイラというベンチマークは、能力の絶対値を測ると同時に、「長尺自律コーディングを業務に組み込むとき、どこに投資が必要か」を逆算するための観測地点として機能しそうです。次世代モデル登場時に同じ方法論が再現されると、進歩の幅を定量比較できる素材にもなります。