PaPoo
cover
technews
Author
technews
世界の技術ニュースをリアルタイムでキャッチし、日本語でわかりやすく発信。AI・半導体・スタートアップから規制動向まで、グローバルテックシーンの「今」をお届けします。

ProgramBenchは「AIにゼロからソフトウェアを再現させる」ベンチマーク

キーポイント

「AIにソフトウェアを作らせる」時代の、ちょっと本質的すぎる問い

最近の language model は、コード補完どころか「アプリを一式作る」みたいな使われ方が増えています。
いわゆる agent が、最初の seed を置いて、コードベースを保守して、少しずつ育てていく――そんな未来像がかなり現実味を帯びてきました。

でも、ここで大事なのは、​本当に“ソフトウェアを作れている”のかという点です。

既存の benchmark は、たとえば

といった、かなり切り出された作業が中心でした。
もちろんそれも重要なんですが、実際のソフトウェア開発ってそんなに単純ではありません。設計をどうするか、どこに処理を置くか、どんなファイル構成にするか、将来の拡張に耐えられるか――こういう高レベルの architecture decisionが効いてきます。

ProgramBench は、まさにその穴を突いてきた研究です。
正直、かなり筋がいい問いだと思いました。AIにコードを書かせる話は派手ですが、​​「動く」だけでなく「まともな形で再構築できるか」​を問うのは、地味だけど本質です。

ProgramBench って何をするの?

この benchmark では、モデルに与えられるのはあるプログラムとその documentationだけです。
そこからモデルは、​参照実装(reference executable)と同じふるまいをする codebase を設計し、実装しなければなりません。

ここでのポイントは、​実装の見た目は自由だということです。
つまり「このクラスを作れ」「この関数名で書け」といった縛りはなく、最終的に同じように動くかどうかだけを見ます。

image_0002.svg

この評価のために使われるのが、​agent-driven fuzzing です。
fuzzing は雑に言うと、いろいろな入力を大量に投げて「変なところで壊れないか」を調べる手法です。ProgramBench では、この fuzzing を agent によって回し、​end-to-end behavioral tests を作ります。

要するに、

という設計です。
これはかなり賢いです。実装構造を固定すると、AIが“それっぽく真似る”だけになりがちですが、動作だけを問うなら本当の理解力が見えやすい。個人的には、こういう benchmark の方がずっと面白いと思います。

対象はかなり本気。小物だけじゃない

ProgramBench のタスクは全部で 200件
しかも、単純な CLI tool だけではありません。​FFmpeg、SQLite、PHP interpreter のような、広く使われている大規模ソフトウェアまで含まれています。

ここが重要です。
小さいお題なら、最近のモデルはかなり高い確率で“それなり”に見えるものを出せます。でも、FFmpeg や SQLite みたいな世界に入ると、話は一気に変わります。
こうしたソフトは、単にコード量が多いだけではなく、細かい仕様、境界条件、互換性、設計の積み重ねが必要です。

つまり ProgramBench は、AIに対して

「ちょっとしたコードを書けるか」
ではなく
「現実のソフトウェアの複雑さに耐えられるか」
を問うています。

この切り口はかなり痛いところを突いていて、だからこそ価値があると思います。

結果は厳しい。かなり厳しい

9つの language model を評価したところ、​どのモデルも1つのタスクすら完全には解決できなかったとのことです。
そして最も良かったモデルでも、​全タスクのうち3%でしかテストの95%を通せなかった

image_0003.svg

この数字、かなりインパクトがあります。
「95%通せるなら結構すごいのでは?」と思うかもしれませんが、ソフトウェアでは最後の5%が地獄だったりします。例外処理、細かい入力、互換性、性能、設計上の一貫性――このあたりで崩れると、結局“使えるソフト”にはなりません。

つまりこの結果は、

私はこれを「AIが弱い」というより、​ソフトウェア開発が思った以上に複雑だと露呈した結果だと受け取りました。
人間が当たり前にやっている設計判断って、実は相当な蓄積の上に成り立っているんですよね。

AIは“人間っぽいコード”ではなく、“1ファイル巨大スクリプト”に寄りがち

論文のもう1つ面白い発見は、モデルがmonolithic、つまり1つにまとまった大きな単一ファイル実装を好む傾向です。
しかもそれは、人間が書くコードとはかなり違う形だそうです。

これはめちゃくちゃ「AIあるある」だと思いました。
モデルは、局所的にはうまく書けても、長期的な設計の分割やモジュール化が苦手になりやすい。
結果として、

という方向に流れがちです。

もちろん、1ファイルにまとめるのが悪いとは限りません。小さなツールならむしろ合理的です。
でも、FFmpeg や SQLite 級の世界では、それでは到底足りない。
ここに、​AIの「それっぽさ」と「本物の設計力」の差が見えます。

image_0004.svg

この研究が面白い理由

ProgramBench の良さは、単に「難しい問題を作った」ことではありません。
ソフトウェアエージェントをどう評価すべきかという、かなり根っこの問題に踏み込んでいる点です。

今後、AIはコード生成だけでなく、

みたいな役割を担うかもしれません。
そのとき必要なのは、単発の bug fix 能力ではなく、​ソフトウェア全体を見通す力です。

ProgramBench は、その能力を測るための土台になりそうです。
しかも「実装の形」を押しつけずに「動作」で評価するのが、かなり良い。
ベンチマークって、作り方を間違えるとモデルが変な攻略を始めてしまうんですが、これはその罠をうまく避けようとしているように見えます。

まとめ

ProgramBench は、language model がプログラムをゼロから再構築できるかを測る benchmark です。
結果はかなり厳しく、現時点では AI が本格的なソフトウェア開発を“総合力”でこなすにはまだ距離があることを示しました。

ただ、私はこの研究を悲観的には見ていません。むしろ逆で、​何ができて、何がまだできないのかが、かなりクリアになったのが大きいと思います。
AIの進歩はたしかに速いですが、ソフトウェアは甘くない。
ProgramBench は、その当たり前を、ちゃんと測れる形にしたのがえらい。そういう論文です。


参考: ProgramBench: Can Language Models Rebuild Programs From Scratch?

同じ著者の記事