ハクソク

世界を動かす技術を、日本語で。

エージェントチームを使用してOpus 4.6にCコンパイラの構築を依頼しました

109日前原文(anthropic.com)

概要

  • 複数Claudeエージェント による自律型チーム開発の実験
  • Rust製Cコンパイラ をゼロから構築し、Linuxカーネルのビルドを達成
  • テスト設計・並列化・役割分担 など、エージェント運用ノウハウを蓄積
  • 限界点・課題 も明確化し、今後のLLM活用の指針を提示
  • コスト・効率・品質 の観点からも詳細に評価

エージェントチームによるRust製Cコンパイラ開発実験

  • SafeguardsチームのNicholas Carlini による新アプローチ「agent teams」の実験
  • 複数のClaudeインスタンス が 人間の介入なし で同じコードベースに並行作業
  • 16エージェント を使い、 RustでCコンパイラ をゼロから開発し、Linuxカーネル（6.9）をx86、ARM、RISC-Vでビルド可能に
  • 約2,000回のClaude Codeセッション、 APIコスト約2万ドル、 10万行のコンパイラ を生成
  • 成果物自体の価値 もあるが、本稿は 長時間自律型エージェント運用ノウハウ に焦点

長時間自律型Claude運用の工夫

  • 従来のClaude Code は人間の継続的な操作が必要
  • 自律的な進行 を実現するため、Claudeをループで動かす ハーネス（制御環境） を設計
    • 例: タスク終了後すぐ次のタスクを自動取得
  • Bashスクリプト で永遠にClaudeを起動し続ける仕組み
  • Claudeには問題分割・進捗管理・次タスク選択 を指示
  • 無限ループ でClaudeが自分で止めない限り進行

並列化とタスク同期

  • 1セッション1タスクの制約 を解消するため、 複数Claudeを並列実行
  • 各エージェントはDockerコンテナで独立実行、/workspaceで作業後/upstreamにpush
  • タスクロック用テキストファイル で作業の重複防止
  • gitの同期機能 でロック競合時は他タスクへ自動切替
  • マージ競合もClaudeが自律解決

エージェント間コミュニケーションと役割分担

  • 現状は直接のコミュニケーションなし
  • 各Claudeが「最も明白な次の課題」を自主的に選択
  • バグで行き詰まると進捗ドキュメントを自動作成・管理
  • 役割分担例
    • 重複コード統合担当
    • コンパイラの性能改善担当
    • 出力コードの効率化担当
    • Rust開発者視点での設計批評・構造改善
    • ドキュメント整備担当

テスト設計とフィードバックの工夫

  • 高品質なテスト設計 が自律作業の鍵
  • タスク検証者（verifier）の精度向上 が必須
  • オープンソースビルドスクリプトやテストスイート を活用
  • 新機能追加時の既存機能破壊 を防ぐためCIパイプラインと厳格なテスト導入
  • Claude向けのテスト出力設計
    • コンテナごとに初期化されるため、進捗・README更新指示
    • 無駄な出力を避け、重要情報はファイルに記録
    • エラーはgrepで抽出しやすい形式 で記録
    • 集計統計値は事前計算 し、Claudeの負担軽減
    • タイムブラインド対策 として進捗出力頻度制御、サブサンプルテスト導入

並列化の課題と解決策

  • 独立テスト多数→並列化容易
    • 各エージェントが異なる失敗テスト担当
  • Linuxカーネルのような巨大タスク→並列化困難
    • 全エージェントが同じバグに集中し、修正の上書きが発生
  • GCCを「正解オラクル」として利用
    • 一部ファイルをGCCでコンパイルし、Claudeコンパイラのバグ箇所特定を分散
    • 各エージェントが異なるファイルのバグ修正に専念可能
    • delta debugging で複合的バグも特定

ストレステストと評価

  • Opus 4.6モデルの限界試験
    • 2週間、2,000セッション、20,000ドル、20億入力トークン、1.4億出力トークン消費
    • Rust標準ライブラリのみ依存、完全クリーンルーム実装
    • Linux 6.9、QEMU、FFmpeg、SQlite、Postgres、Redis等のビルド達成
    • GCC torture test suite等で99%パス率
    • Doomのビルド・実行にも成功
  • 主な制約
    • 16ビットx86コンパイラ未実装 （GCCに依存）
    • アセンブラ・リンカの自前実装は未完成
    • すべてのプロジェクトで完全なGCC互換は未達
    • 最適化してもGCCほど効率的なコードは生成不可
    • Rustコード品質は専門家レベルには未到達
    • Opus 4.6の限界に近い成果

今後への示唆

  • 複数LLMエージェントの自律並列開発 は大規模・複雑タスクでも有効性を示す
  • テスト設計・進捗管理・役割分担 が運用の成否を左右
  • 現行LLMの限界と今後の改善ポイント を明確化
  • コスト・効率・品質のバランス を考慮したAI活用設計の重要性

Hackerたちの意見

結果が完璧であるべきだっていう期待を見るのは変な感じだよね。結局のところ、こういうことが可能だってだけでもすごいことだと思う。もしかしたら、これらは次のオーパスやソネットのトレーニングに使われて、効率的なコンパイラをゼロから作れるモデルが出てくるかもしれない。それはすごいことだね！

└

生成AIに対する反発が強まっている兆候の一つは、結果に欠陥があると「AIのゴミ」と呼ばれることだね。たとえそれが実験的なデモや概念実証であって、インフルエンサーが盛り上げている「次のビッグなもの」ではないと明確に言われていても。そういうニュアンスは、SNSの外でも消えてしまった。

これはカーソルブラウザの話よりずっと現実的な意見だね。いくつかの点でかなり印象的だよ。> これはクリーンルーム実装で、開発中にClaudeはインターネットにアクセスできなかった。Rustの標準ライブラリだけに依存してる。10万行のコンパイラはx86、ARM、RISC-VでLinux 6.9をビルドできるし、QEMU、FFmpeg、SQLite、Postgres、Redisもコンパイルできる。> 最初に自分が欲しいものを考えたんだ：依存関係なしのゼロからの最適化コンパイラで、GCC互換で、Linuxカーネルをコンパイルできて、複数のバックエンドをサポートするように設計されたもの。いくつかの設計面については指定したけど（例えば、複数の最適化パスを可能にするためにSSA IRを持つべきだと）、どうやってそれを実現するかの詳細には触れなかった。> 以前のオーパス4モデルは、機能するコンパイラを作るのがやっとだった。オーパス4.5は、大きなテストスイートを通過できる機能的なコンパイラを作れるようになった最初のモデルだったけど、実際の大きなプロジェクトをコンパイルすることはできなかった。制限についてのオープンなポイントもあって（ccはハックが好きだからね）：> 16ビットx86コンパイラが不足していて、ブートに必要なんだ[...] オーパスは16ビットリアルモードにブートするために必要な16ビットx86コードジェネレータを実装できなかった。コンパイラは66/67オペコードプレフィックスを使って正しい16ビットx86を出力できるけど、生成されたコンパイル出力は60kbを超えていて、Linuxが強制する32kコード制限を大きく超えてしまう。だから、Claudeはここで単にGCCを呼び出してこのフェーズを処理している。> 自分のアセンブラとリンカを持っていない。> すべての最適化を有効にしても、最適化を無効にしたGCCよりも効率の悪いコードを出力する。最後にとても現実的な意見で締めくくると：> 結果として得られたコンパイラは、オーパスの能力の限界にほぼ達している。いくつかの制限を修正しようと頑張ったけど、完全には成功しなかった。新機能やバグ修正が既存の機能を壊すことが頻繁にあった。全体的に見て、これは面白い実験だと思うし、制限があっても印象的だし、著者が言うように「結果として得られたコンパイラは、オーパスの能力の限界にほぼ達している」っていうのも納得できる。うん、それは妥当だけど、やっぱりすごいと思うよ。

└

こういう結果を見て、現在の状態だけで評価する人がまだたくさんいるみたいだね。これを見て、数ヶ月前よりも大きな改善を表しているって気づかないのはどうかと思う。何年も継続的に改善があって、ここで進展が止まる理由はないと思う。たった1年先を見越しても、仮にその後進展が止まったとしても、その影響は驚くべきものだよ。

└

これはクリーンルーム実装だ。これは本当に言い過ぎだと思う、だってインターネット上のすべてのCコンパイラでトレーニングされてるんだから。すでに十分印象的な作業なのに、そんな誤解を招くような発言は必要ないよ。

└

結果はクリーンルームの実装とは言えないね。むしろ、ネットワーク内にあるあいまいに保存された知識を無理やり解凍しようとした感じで、望ましい出力に近づけるためにはたくさんのテストを使って慎重に調整する必要があった。圧縮と保存はLLMのトレーニング中に行われたんだ。これが間違ってるって証明してみてよ。

└

Claudeは開発中にインターネットにアクセスできなかった これって、なんでそんなに望ましいの？俺は、自分のLLMが世の中にあるすべてを考慮して、最高の出力を出してほしいんだけど。

└

クリーンルーム実装 でも、すべてのソースを使って訓練されてるから、GCCやClangも含まれてるんじゃないかな。どれくらいコードが似てるのか気になるな。

これはクリーンルーム実装だ。これは本当に言い過ぎだと思う、だってインターネット上のすべてのCコンパイラでトレーニングされてるんだから。すでに十分印象的な作業なのに、そんな誤解を招くような発言は必要ないよ。

└

エージェントがすでにインターネット全体でトレーニングされていると、クリーンルーム実装の概念がどう変わるのか興味深いね。

└

同意するけど、次のステップはAIエージェントが実際にビジネスを運営して、人間のようにビジネスコンテキストを理解できるようになることだね。もちろん、まだそこまで行ってないけど、Vending-Bench [0]のようなベンチマークの急速な進展や、このチームのアプローチを考えると、もはや非現実的ではないと思う。特に短期的なステップとして、AIプロダクトマネージャーを使って、アプリを利用するユーザーに直接インタビューするエージェントを生み出したり、独立して小さなプロダクト実験を提案・実行したり、プロダクトロードマップを変更するための検証済みの提案を出したりするSaaS企業が現れるのもそう遠くないと思う。Tayのことをまだ覚えてるし、そんなものに王国の鍵を渡すつもりはないけど、最終的に人間の意思決定者がいる限り、技術はすでにここにあると思う。[0] https://andonlabs.com/evals/vending-bench-2

次のことが公開されるのを見たいな： - 使用された全てのプロンプト - エージェンチームの構成（どのエージェントがどの役割を持っているか） - プロセスに関わったその他の資料 これは学ぶための良い情報源になると思うけど、実験を再現するために2万ドルも払う準備はできてないよ。

└

残念ながら、最近はほとんどの人がソーセージだけで満足しちゃって、その作り方についての詳細は気にしないんだよね。

いいプロジェクトだけど、クリーンルームの話は省いてもよかったんじゃないかな。人類が知っている著作権のある全てのものを使ってトレーニングされたものがクリーンルームの逆だからね。

└

ホットテイク：クリーンルームで何かを再実装しようとすると、それは段階的なプロセスで、自分の蓄積した知識を基に進めることになる。その知識って、しばしば自分が働いていた会社の著作権があるコードだったりするんだよね。LLMの場合はどうなんだろう？ LLMがもっと多くのデータで訓練されているからって、会社で働いて、その後その知識を別の会社に持っていくときに、著作権のある知識を持っていくことには変わりないよね。直接コードをコピーしたり、1:1のコピーで実装しない限り問題じゃない。LLMは元のものを1:1でコピーしないからね。著作権のあるデータで訓練された場合、人間が著作権のあるデータで訓練されて、変革的な方法で再実装されるのと何が違うんだろう。大きな違いは、LLMは人間よりも多くの分野でデータを保持できることだけど、専門化を考えると、結局同じところに戻ってくるんじゃない？

https://github.com/anthropics/claudes-c-compiler/issues/1

└

ありがとう。あれは長い記事だったけど、証拠もない主張から始まって、実際には全体の議論の基盤なのに、あまり面白くないこととして片付けられてたね。

└

AIは未来だね。

└

これらのユーザーはglibc-develかそれに相当するものが足りないだけなんじゃない？

└

笑った、マジで。

└

これは本当にすごいね。

└

問題は、インクルードパスが欠けてることだね。コンパイラ自体は大丈夫なんだけど。

自分のキャリアの大半（ほぼ10年）をGoogleで過ごして、Clangを使ってLinuxカーネルをビルドする作業をしてたんだ。https://clangbuiltlinux.github.io/ このLLMは（メモをチェックして）やったんだね: > 約2,000回のClaude Codeセッションと$20,000のAPIコストで それがビルドできるかもしれないけど、ブートできるの？（これも重要な次のマイルストーンだよね？）それに、ブレンドできるの？ どうやらできそうだね！ > 10万行のコンパイラがx86、ARM、RISC-Vでブート可能なLinux 6.9をビルドできる。次のマイルストーンは：生成されたコードは正しいのか？ それについては、プロダクションコンパイラではまだ結論が出てないね。それから、生成されたコードのパフォーマンスもあるし。 > 生成されたコードはあまり効率的じゃない。すべての最適化を有効にしても、最適化を無効にしたGCCよりも効率が悪いコードを出力する。とはいえ、本当にクールなプロジェクトだね！

└

まあ…君の仕事もトレーニングセットに入ってるから、そういう結果が返ってくるのは全然驚くことじゃないよね！

└

[遅延]

└

[遅延]

最初の反応：わあ、すごい。二番目の反応：まだすごいけど、Cコンパイラは最も厳密に仕様が定義されたソフトウェアの一つだってことを指摘したい。仕様は正確で、期待される動作も明確で、テストケースもあいまいじゃない。私たちが日常的にやってる仕事にどれだけうまく適応できるのか気になるな。要件が曖昧で、エッジケースがその場で見つかって、作りたいものが常に変わるような状況で。

└

Cコンパイラは最も厳密に仕様が定義されたソフトウェアの一つだね /me 「未指定の動作」に笑う。

コンパイラはそれ自体が興味深いアーティファクトだね [...] ほとんどの定義によれば、それはアーティファクトではないから面白いよね: > 通常は単純な物体（道具や装飾品など）で、人間の手仕事や改造を示すもので、自然物とは区別されるもの

ここで面白いのは、このコードの価値っていくらなんだろう（お金の面で）。俺は、再現するのにかかるコスト、つまり約2万ドルの価値しかないと思うし、それ以上はないんじゃないかな。プロンプトにかかる時間を少し加えてもいいかも。そんなお金を出せる人は、同じプロンプトを使って別のCコンパイラを生成したり、また別のを作ったりできるからね。GCCやClangは、何十年もかけて多くのコーナーケースでも動くことが分かっている、実績のあるコンパイラだから、もっと価値があるよ。だから、俺の結論は、今後は基本的に価値のないコードがたくさん生成されて、何度も再生成されるってこと。価値を提供するコードをどうやって見分けるんだろう？それは、AIでも人間でも、実際に使われて長期間メンテナンスされているコードになると思う。