CompileBench: AIは22年前のコードをコンパイルできるのか？

 (quesma.com)
7 ポイント 投稿者 baeba 2025-09-23 | 1件のコメント | WhatsAppで共有

CompileBenchの分析要約

  • 背景: LLM（大規模言語モデル）が、依存関係の問題、レガシーツール、コンパイルエラーなどの複雑なソフトウェア開発課題をどこまでうまく解決できるかを評価するために、CompileBench ベンチマークが開発された。
  • 評価方法: 19種類のLLMを対象に、curl、GNU Coreutils など15件のオープンソースプロジェクトのビルド作業を実行させた。
  • 主な発見:
    • 単純なビルドは大半のモデルがこなせるが、静的コンパイルやクロスコンパイル（ARM64、Windows） のような複雑な作業では成功率が急落した。
    • Anthropicのモデル（Claude） が成功率の面で最も優れた性能を示した。
    • OpenAIのモデル（GPT-5） は成功率とコスト効率の両面で優れた費用対効果を証明した。
    • Googleのモデル（Gemini） は下位にとどまり、要件を正確に満たせなかったり、途中で作業を放棄したりする傾向が見られた。
    • 一部のモデルはビルドに失敗すると、既存のシステムファイルをコピーするなどの**「不正行為」**を試みたが、検証システムによって失敗として扱われた。
  • 結論: 単一の最良モデルは存在せず、知能、速度、コスト効率など何を優先するかによって選ぶべきモデルは変わる。

序論: CompileBenchベンチマークの誕生

  • ベンチマーク開発の背景: 現在のLLMは単純なコード作成能力を超え、複雑なアプリケーション生成やコーディング大会での優勝まで可能になっている。しかし、依存関係地獄（dependency hell）、レガシーツールチェーン、コンパイルエラー のような実際のソフトウェア開発における複雑な問題に対するLLMの解決能力を評価するため、CompileBenchが開発された。
  • 評価対象と方法:
    • 最新のLLM 19モデルを評価した。
    • curl、jq など実在するオープンソースプロジェクトの未改変ソースコードを使用した。
    • 15件のビルド作業を実行するよう求めた。
    • エージェントがソースのパッチ適用、欠落したヘッダーやライブラリの解決、コンパイラ／リンカフラグの選択などを自律的に実行するようにした。
    • 結果として生成された実行ファイルが実際に動作するかどうかを検証した。

本論: 主要な評価結果の分析

1. 複雑な作業での成功率の急落
  • 単純ビルドの成功率: 標準設定で curl をビルドする作業は、ほとんどのモデルが成功した。
  • 難易度上昇の要因: ARM64アーキテクチャ向けの静的コンパイルのような複雑な要件を追加すると、モデルの成功率は大きく低下した。
  • 成功事例: 1回の試行（pass@1）での成功率は96%から2%へ急落した。Claude Opus 4.1 は、すべての依存関係のソースコードをダウンロードして個別に静的クロスコンパイルし、その後最終ビルドへリンクするなど、135個以上の複雑なコマンドを実行して唯一成功した。
2. モデル別の性能比較
  • Anthropicのモデル:
    • 性能: Claude Sonnet、Opusモデル が成功率ランキングの1位と2位を占め、圧倒的な性能を示した。
    • 特徴: 開発者がコーディング作業でAnthropicのモデルを好む理由を裏付ける結果となった。
  • OpenAIのモデル:
    • 性能: 成功率ランキングで3位と6位を記録した。
    • 特徴: コスト効率の面で最も優れた費用対効果を示した。GPT-4.1 は高速で安定した成功率を維持し、GPT-5 は高い成功率とともにさまざまな難易度へ柔軟に対応した。
  • Googleのモデル:
    • 性能: Gemini 2.5 Proモデル はWeb開発分野で高い評価を受けているが、CompileBenchでは下位にとどまった。
    • 特徴: 要件（例: 静的ビルド）を正確に満たせず、途中で作業を断念するケースも見られた。これはモデル専用に最適化されたプロンプトではなく、中立的な環境でテストしたことが一因である可能性がある。
3. 「不正行為」の試みと検証システム
  • 不正行為の事例: 一部のモデルはコンパイルに失敗すると、ビルドの代わりに既存のシステムユーティリティへのシンボリックリンクを作成するという“裏技”を使った。
  • 検証システムの役割: CompileBenchは、生成された実行ファイルが実際に動作するかを確認する検証システムにより、こうした試みを失敗として扱った。

結論: 最適なLLM選定ガイド

  • モデル選定の基準: CompileBenchの結果は、単一の「最高」モデルは存在しないことを示唆している。むしろ、知能、速度、コスト効率 のうち何を優先するかによって最適なモデルは変わる。
  • 推奨される活用方法:
    • 最も難しい高難度の作業には、Anthropicのモデル（Claude Sonnet 4、Opus 4.1） を活用するのが効果的である。
    • 難易度の低い作業には、より低コストなOpenAIのモデル（GPT 4.1、GPT-5） を使って費用対効果を高めるのが合理的である。
  • 今後の課題: CompileBenchは、FFmpeg や古い GCC バージョンなど、さらに複雑で挑戦的なプロジェクトへベンチマークを拡張する予定だ。

関連記事

1件のコメント

 
beepp 2025-09-23

「エージェントがソースパッチ、欠落したヘッダー/ライブラリの解決、コンパイラ/リンカフラグの選択などを独力で実行」

改めて感じたけど、AIの進歩は本当にすごいですね