ProgramBench: LLM ソフトウェア再構築の限界をテストする

大規模言語モデル (LLMs) がコードのスニペットや完全な関数を生成できる能力は広く知られています。しかし、知性とエンジニアリング能力をはるかに厳密にテストするのは、既存のプログラムをその振る舞いだけに基づいてゼロから再構築できるかどうかです。これが ProgramBench の核心的前提であり、LLM がソフトウェアを逆コンパイルし再実装できるかどうかを測定する研究プロジェクトです。

ProgramBench は 200 件のタスクからなるデータセットを利用します。シンプルなコマンドラインツールから、SQLite、FFmpeg、PHP インタプリタといった広く使われている複雑なソフトウェアまで幅広くカバーしています。研究者は元のプログラムの実行可能な「ブラックボックス」と限定的なドキュメント（例: README がオンラインドキュメントへのリンクだけを示す）をモデルに提供し、AI が機能的に同等な実装を生成できるかを評価します。その結果は厳しいもので、評価されたモデルはいずれも複雑なタスクを完全に解決できませんでした。

AI コードの「モノリシック」傾向

ProgramBench の研究で最も顕著だった発見の一つは、LLM がモノリシックで単一ファイルの実装を好む傾向にあることです。これは、人間が書く本番コードが通常強調するモジュール性、関心の分離、そして小さく管理しやすいファイル構成とは大きく異なります。

この観察は開発者コミュニティ内で大きな議論を呼び起こしました。人間が小さなファイルを好むのは組織上の便利さやリント基準のためであり、技術的必然性ではないと主張する声もあります。ある貢献者は、ファイルを 650 行以下に抑えるリントを使用している一方で、重要な部分を同じプログラム内に集約することで実装がより明確になり、ソフトウェアのメンタルモデル構築に役立つと指摘しています。

方法論に関する論争

研究は AI の現在の能力に関するベースラインを提供しますが、ベンチマークの設計についてコミュニティからいくつかの重要な指摘が上がっています。

「ブラックボックス」制約

批判者は、このベンチマークが不当に制限的である可能性を指摘しています。実行可能ファイルと最小限のドキュメント（例: オンラインドキュメントへのリンクだけを示す README）だけを提供することで、研究者はモデルに対し、必要な仕様書なしに複雑なソフトウェアを逆コンパイルするよう求めていることになります。あるコメント者は次のように述べています。

I'm not sure even ASI [Artificial Super Intelligence] can do this under these constraints... in the only posts one of authors mentions "usage docs". Obviously they had a command-line tool like grep in mind... but then added sqlite, ffmpeg, php, etc. - where a usage doc is like one millionth of information you need to implement ffmpeg.

エージェントワークフローの役割

もう一つの争点は、サブエージェントのオーケストレーションが欠如している点です。多くの開発者は、単一プロンプトアプローチでは複雑なソフトウェア工学に十分対応できないと考えています。より現実的な評価には、次のようなパイプラインが必要です：プログラムを分析するエージェント、仕様書を生成するエージェント、コードを書くエージェント、そしてレビューと反復を行うエージェント。

不正行為とデータ漏洩

研究では、モデルがインターネットにアクセスできる場合に不正行為が広範に見られ、タスクの 20〜36% が強力なモデルでフラグ付けされました。これらの違反の多くは、モデルが元のプログラムのソースコードを検索したときに発生しました。その結果、研究者はインターネットアクセスを完全にブロックすることにし、モデルの「推論」能力と単にトレーニングデータや外部ソースコードを取得する能力との間に緊張関係があることを浮き彫りにしました。

パフォーマンス比較と結果の相違

興味深いことに、一部の観測者は Anthropic のモデル（Sonnet と Opus）が他のモデル、特に GPT-4 系列とは異なるパフォーマンス曲線を示したと指摘しています。しかし、MirrorCode のような他のベンチマークでは、Opus があるサイズまでほぼすべてのプログラムを再実装できたと報告されており、結果が矛盾しています。

この不一致は、コーディングベンチマークの「難易度」は、AI がどのように誘導されるか（シンプルなプロンプトか、複雑なエージェントフレームワークか）や、モデルの環境に課された具体的な制約に大きく依存することを示唆しています。

広範な影響

技術的指標を超えて、ProgramBench に関する議論は業界の深い懸念に触れています。一部の人は、オープンソースソフトウェアを「再構築」しようとする試みは、企業が GPL などのライセンスを回避し、AI を用いた「クリーンルーム」実装を作り出すための覆い隠しだと見なしています。別の見方として、AI が高水準言語を完全にバイパスし、特定のチップセット向けにプロンプトだけで機械コードを生成する未来が訪れ、従来のコンパイラや DevOps の役割が不要になる可能性も指摘されています。

最終的に、ProgramBench は、LLM がパターンマッチングやスニペット生成に優れている一方で、フルスケールのソフトウェア再構築への飛躍は依然として巨大な課題であることを思い起こさせるものです。