Anthropic AI C Compiler、GCCより遅いバイナリを構築するのに$20kかかる
- Aisha Washington
- 6月6日
- 読了時間: 10分
更新日：6月17日
最近、テクノロジーの世界では自律コーディングに関する大規模な実験が行われました。AIエージェントのチームが機能するCコンパイラを構築することに成功したのです。このプロジェクトは、しばしば「Anthropic AI C Compiler」の能力のデモンストレーションとして引用されます。16体のClaude Opus 4.6エージェントが並行して作業しました。彼らは2週間で約10万行のRustコードを生成し、トークン使用量で約2万ドルかかりました。表面的には、見出しは印象的です。生成されたソフトウェアは、Linuxカーネル6.9（x86、ARM、RISC-Vアーキテクチャにまたがる）をコンパイルでき、古典的なゲーム「
Doom」を実行できます。しかし、実際のパフォーマンス、ユーティリティ、コード品質を掘り下げると、物語は「革命的なブレークスルー」から「高価な学術的演習」へとシフトします。生成されたコンパイラは、標準的なツールよりも大幅に遅いバイナリを生成し、基本的な最適化に苦労し、機能するために既存のインフラストラクチャに大きく依存しています。パフォーマンスの現実：Anthropic AI C Compilerはどのように比較されるか
開発者やエンジニアにとって、コンパイラで最も重要な指標は、生成されるマシンコードの効率です。ここで「
Anthropic AI C Compiler」 業界標準に達していません。
Anthropic AI CコンパイラとGCCおよびClangのベンチマーク
ユーザーレポートと初期ベンチマークでは、深刻なパフォーマンスのボトルネックが示されています。生成されたバイナリを remio の AnthropicのAIソリューション とGNUコンパイラコレクション（GCC）のものを比較すると、その差は歴然としています。
AI生成コンパイラは、内部の「最適化」を有効にしても、すべての最適化を無効にしたGCC（-O0）よりも遅いコードを生成します。システムプログラミングの世界では、これは致命的な欠陥です。30年前のツールのベースラインとなる最適化されていないパフォーマンスに勝てないコンパイラは、本番環境では実用的な価値を提供しません。
問題は速度だけではありません。アーキテクチャの完全性に関するものです。「Anthropic AI C コンパイラ は、独自のリンカおよびアセンブラを持っていません。Cから中間表現への高レベルな翻訳を実行しますが、最終的には機械コードのアセンブルやライブラリのリンクといった重労働は、システムの既存のGCCインストールに引き渡されます。また、16ビットx86コンパイルを処理できないため、Linux起動シーケンス中に必要なリアルモードのブートコードを処理できず、これらの特定のファイルではGCCへのフォールバックが必要になります。
AIがバックエンド最適化で苦戦する理由
エンジニアリングコミュニティからのフィードバックによると、大規模言語モデル（LLM）はコンパイラ設計の「簡単な」部分には長けていますが、最適化に必要な複雑なアルゴリズムロジックでは失敗しています。
コンパイラは実質的に2つの部分からなります：フロントエンド（テキストの解析）とバックエンド（最適化ロジック）。LLMは解析、つまり言語的なタスクに長けています。C構文をRustの構造体に翻訳することは、Claude Opusが得意とするところです。しかし、バックエンドには厳密な数学的概念が関わってきます：レジスタ割り当てのためのグラフ彩色、命令スケジューリング、ループ不変コード移動、制御フロー解析。
これらは言語的なパターンではなく、グラフ理論とハードウェア制約への厳密な準拠を必要とする論理パズルです。「Anthropic AI C コンパイラ最適化の構造を模倣していますが、その背後にある数学を理解していません。コンパイラのように見えるRustコードを生成しますが、内部のアルゴリズムは命令サイクルを効果的に削減したり、メモリへのアクセスを効率的に管理したりしません。AIは複雑なシステムの定型的な部分を再現することはできますが、高性能エンジニアリングの問題を「推論」することはまだできないことを証明しています。
自律コーディングプロジェクトのアーキテクチャ
このプロジェクトがどのように構築されたかを理解することは、コンパイラ自体よりも価値があります。このプロセスは、自律コーディングエージェントを展開しようとしている企業にとって、青写真であり、警告でもあります。
Claude Opus 4.6 エージェントが 10 万行の Rust コードに協力した方法
開発プロセスでは、特定の「エージェントチーム」アーキテクチャが利用されました。Claude Opus 4.6 の 16 インスタンスがカスタムハーネス内で動作しました。これは単純なチャットインターフェイスではなく、クローズドループシステムでした。
タスク割り当て: エージェントはチケットを受け取ります（例：「構造体解析の実装」）。
実装: エージェントは Rust コードを記述します。
テスト: システムはコードのコンパイルとテストスイートに対する実行を自動的に試みます。
修正: テストが失敗した場合、エラーログがエージェントにフィードバックされ、再試行されます。
このループは約2,000回発生しました。同様のシステムを構築する開発者にとっての重要な教訓は、「ノイズリダクション」の重要性です。初期のイテレーションは、テストスイートがコンテキストウィンドウに無関係なデータ（標準出力ノイズ）を大量にダンプし、モデルを混乱させたため失敗しました。入力のサニタイズ、つまりAIに特定の失敗シグナルのみを与えることが、成功の鍵となりました。
既存のGCCリンカおよびアセンブラへの依存
このプロジェクトはしばしば「スクラッチから構築された」と表現されますが、技術的には不正確です。この Anthropic AI C Compiler トランスパイラとして機能し 実行可能ファイルを作成するためにGNUエコシステムの重厚な仕組みに依存しています。アセンブリとリンクのステップをGCCにオフロードすることで、AIはバイナリ生成の最も壊れやすい部分を回避しました。
このハイブリッドアプローチは、AIソフトウェアのトレンドを示しています。つまり、決定論的なレガーツールをクリティカルインフラストラクチャに依存し、AIを上位レベルのロジックに使用します。これはプロトタイプとしては機能しますが、AIが現時点ではバイナリ構築のフルスタックを独立して処理できないことを浮き彫りにしています。
開発者エクスペリエンスとコード保守性
今日ソースコードをダウンロードしても、オープンソースへの貢献に対応できるツールは手に入りません。手に入るのは成果物です。
AI生成されたRustコードの品質を検査する
リポジトリをレビューしたシニア開発者は、コードは機能するものの、専門家による人間のエンジニアリングのニュアンスが欠けていると指摘しました。機能的ではあるが冗長です。
アーキテクチャには明確な「学生レベル」の品質があります。コンピュータサイエンスのプログラムでは、Cコンパイラの作成は標準的な学期ごとの課題（「コンパイラ101」）です。学部生グループは通常、数ヶ月で動作するコンパイラを作成できます。Anthropic AI C コンパイラ このレベルで動作します。問題を解決しますが、長期的な安定性を確保する革新や洗練されたデザインパターンを採用することはありません。
AIソフトウェア開発における「凍結されたリポジトリ」問題
このプロジェクトの最も致命的な側面は、そのライフサイクルかもしれません。初期リリース以降、リポジトリはほとんど、あるいは全くメンテナンスされていません。プルリクエストは応答されず、イシューは積み上がっていきます。
これは、AI生成コードベースにおける主要なリスク、すなわち保守性の欠如を示しています。人間がコードを書くとき、システムのロジックのメンタルマップを構築します。AIが10万行のコードを生成した場合、そのメンタルマップを持つ人間はいません。バグを修正するには、AIのロジックをリバースエンジニアリングする必要があります。元の「作成者」（AIエージェント）が修正のためにオンラインでない場合、コードは「スラッグ」になります。つまり、一瞬は機能しますが、要件が変わった瞬間に無用の長物となります。
Anthropic AI C Compiler の経済性
このプロジェクトには 20,000 ドルの API クレジットという価格が付きました。この数字は、必要な費用対効果分析を促します。
20,000 ドルの開発コストの分析
無料で利用できるツール (GCC/Clang) を模倣するために 20,000 ドルを費やし、しかもその模倣が不十分であることは、眉をひそめさせるものです。同額で、企業は数ヶ月間ジュニア開発者を雇うことができたでしょう。そのジュニア開発者は学習し、改善し、最終的にはコードベースの長期的な健全性に貢献したはずです。AI クレジットはサンクコストであり、モデルはこのプロジェクトから直接次のプロジェクトに役立つような形で「学習」するわけでもなく、バグを修正するために残るわけでもありません。
しかし、研究開発と見なせば、そのコストは正当化されます。16 の並列エージェントのコンテキストウィンドウと調整を管理することが可能であることを証明したのです。価値があったのはコンパイラではなく、ワークフローデータでした。
学生プロジェクト対エンタープライズ AI ソリューション
決定的なのは、Anthropic AI C Compiler が、AI は「コモディティ」コーディングタスクを自動化できることを実証したことです。これは、以前に数千回解決されており、大量のトレーニングデータが利用可能なプロジェクトです。C コンパイラは十分に文書化されています。もしタスクが斬新なものであった場合、つまり、既存のドキュメントがない新しい言語のコンパイラを作成するようなものであった場合、エージェントはおそらく失敗したでしょう。
これは、現時点では、自律エージェントは新しいエンジニアリングソリューションを開拓するよりも、標準的で十分に理解されているソフトウェアコンポーネントの足場を築くのに最も適していることを示唆しています。
この実験は現実を突きつけるものです。私たちはAIコーディングの「Hello World」フェーズは過ぎましたが、「シニアエンジニア」フェーズには到達していません。私たちは、コンピュータサイエンス学部の2年生を効果的に自動化しました。彼らは勤勉で、動作する課題を生成できますが、インターネットの重要なインフラストラクチャを設計する準備はできていません。
よくある質問
Q: Anthropic AI C CompilerはGCCやClangの代わりになりますか？
A: いいえ、実用的な代替にはなりません。アセンブラやリンカのような必須コンポーネントがなく、生成されるコードは大幅に遅く、確立されたオープンソースコンパイラよりも機能が少ないです。
Q: AIはこのコンパイラを完全にゼロから構築しましたか？
A: 完全ではありません。CからRustへのロジックを生成しましたが、コンパイラは依然として機械コードのアセンブルとライブラリのリンクのためにGCCツールチェーンに依存しており、特定のブートローダーファイルをコンパイルするためにGCCを使用しています。
Q: Anthropic AI C Compilerの構築にはいくらかかりましたか？
A: Claude Opus 4.6エージェントを実行するために、APIトークンで約20,000ドルかかりました。 これには、2週間にわたる反復的な生成、テスト、デバッグのフェーズが含まれていました。
Q: 生成されたコードは保守可能ですか？
A: レビューによると、コードの保守は困難です。人間が直感的に完全なアーキテクチャを理解できず、リポジトリがAIによって積極的に更新されていないため、「デッドコード」になるリスクがあり、パッチの適用やアップグレードが難しくなります。
Q: Anthropic AI C Compiler は何を正常にコンパイルしましたか？
A: Linuxカーネルバージョン6.9をx86、ARM、RISC-Vアーキテクチャ向けにコンパイルし、1993年のゲーム「Doom」も処理しました。これは、パフォーマンスの欠点にもかかわらず、複雑で実際のコードベースを処理できることを証明しています。
