ProgramDistillは、コーディングエージェントを評価するための新しいタイプのベンチマークです。従来のように「こういう機能を作れ」と具体的な動作までイシューや指示文に書いて与えるのではなく、機能の目的とワークフローを説明する問題文を与え、すでに完成して動いている参照アプリケーション(reference application)をエージェント自身に触らせることで、そこから突き止めた具体的な動作を未完成のアプリに実装させます。著者らは人手を介さずに26個のアプリから1,975件の検証済み動作を掘り出し、4,063件の課題を自動生成したうえで、9つの最新コーディングエージェントをこの上で評価しました。
これまでコーディングエージェントを試す方法は、ほとんどが「ドリル問題集」の形でした。「ログインボタンが押せないバグを直せ」「カートに数量調整機能を追加しろ」というように、求める動作がイシューや指示文にはっきりと文章で書かれています。エージェントはその文章を読んでコードを直せばよいのです。
ところが現実のWeb開発はこれほど親切ではありません。実務では「このアプリ、こう動くようにしてください」という言葉の代わりに、すでにちゃんと動いている別のソフトウェアを見せて「これと同じように」と依頼されるケースが多いのです。開発者はそのアプリを自分でクリックし、ボタンを押し、画面の反応を観察しながら「ああ、この機能はこういうものなんだ」と自力で推論しなければなりません。そしてその動作を、機能が埋まりきっていない未完成のアプリの上に実装しなければならないのです。
たとえるなら、従来のベンチマークが「レシピを見て料理する」ことだとすれば、この論文が狙う状況は「どんな料理かの簡単な説明だけを聞き、名店の完成した料理を実際に食べてみてその味を再現する」ことに近いと言えます。詳しいレシピ(具体的な動作仕様)はなく、目的を記した短い説明と成果物(動くアプリ)だけがあります。このギャップのせいで、従来のベンチマークで高得点を取ったエージェントが、実際のWeb開発の現場でもうまくやれるとは保証しづらかったのです。
ProgramDistillの核心は「動くアプリを細かく分割し、各ピースの動作を再び再生(replay)できるようにすること」にあります。
著者らは完成したアプリケーションを、異なる粒度(granularity)の機能(feature)単位に分解(factorize)します。大きな機能もあれば、小さな機能もあります。そして各機能ごとに再生可能な動作(replayable behavior)を紐づけておきます。この動作は、正解のコード修正版、すなわちゴールドパッチ(gold patch、正解のコード変更分)を適用すると実際に実行されて再現されます。平たく言えば、「この機能がきちんと実装されれば画面で正確にこういうことが起こるべきだ」ということを、機械が自動でもう一度再生しながら採点できるようにしたものです。試験問題と採点基準(再生結果)が一体として結びついている、というわけです。
著者らがこのベンチマークを作り、その上でエージェントを評価する一連の手続きの名前がmine-craft-patch(発掘-制作-パッチ)です。前の2段階(発掘・制作)は人手なしにベンチマークを作り出すプロセスであり、最後の段階(パッチ)は評価対象のエージェントが実際に課題を解くプロセスです。
| 段階 | やること(直感的な説明) |
|---|---|
| mine(発掘) | 動くアプリから再生可能な動作を掘り出す |
| craft(制作) | その動作を評価可能な課題に仕立て、正解のコード変更分(ゴールドパッチ)を作って再生で検証する |
| patch(パッチ) | 評価対象のエージェントが参照アプリを観察して欠けている機能を未完成アプリに実装し、再生検証で採点を受ける |
このパイプラインによって著者らは26個のアプリケーションから1,975件の再生検証済み(replay-verified)動作を見つけ出し、これらを組み合わせて4,063件の課題を作りました。重要なのは、この全過程が人の介入なしに(without human intervention)行われたという点です。人が一つひとつ正解をラベル付けしなくても、ベンチマークが拡張し続けられるという意味です。
評価方式も2通りに分かれます。一つはアプリ全体の再構成(full-application reconstruction)で、アプリを丸ごと作り直していく累積的ワークフロー(cumulative workflow)を扱います。もう一つはアプリの部分的な再構成(partial-application reconstruction)で、すでにかなりの部分が埋まっているアプリから欠けたピースだけを復元します。このときエージェントには、その機能の目的とワークフローを説明する自動生成された問題文が一緒に与えられ、具体的にどう動くべきかは参照アプリとのインタラクションから推論することになります。ここで著者らは復元深度(restoration depth)という調整つまみを設け、どれだけ多くのものを復元しなければならないかに応じて難易度を細かくコントロールします。難易度が固定されたベンチマークではなく、ダイヤルを回すように難しさを調整できるベンチマークであるという点が特徴です。
アブストラクトが示した数値は、二つの実験から出ています。
まずアプリ全体の再構成の累積的ワークフローにおいて、最新のコーディングエージェント9つのうちGPT-6 Astraが49.2%、Claude Opus 5が28.8%の成功率を記録しました。半分近くか、それ以下だという意味であり、動くアプリを見てその全体を組み立て直す課題が、最新モデルにとっても決して簡単ではないことを示しています。
次にアプリの部分的な再構成では、復元深度が大きくなるほど性能がはっきりと落ちました。アブストラクトによれば復元深度が1から8に増えると、成功率が100%から64.0%へ、そして96%から32%へ下落しました。浅く一つか二つのピースだけを復元するときはほぼ完璧ですが、復元すべきものが深く積み重なるほど急激に崩れるのです。これはすなわち、このベンチマークが難易度を制御(controlled difficulty)できることを実証する結果でもあります。
まとめると、ProgramDistillの意義は三つです。第一に、人の介入なしに自動で拡張可能(scalable)な大規模ベンチマークであるという点。第二に、難易度を調整してエージェントの弱点を診断(diagnose)できるという点。第三に、アブストラクト自身が言及しているように、難易度が調整されるこの構造がカリキュラムベースの学習(curriculum-based training、易しいものから難しいものへ順に教える方式)の自然な土台になりうるという点です。
アブストラクトだけで判断すると、いくつか正直な限界と開かれた問いが残ります。
これ以上の具体的な手法の詳細や追加の数値はアブストラクトにないため、断定はしません。正確な内容は原文を確認するのが筋です。
ONTLEはAIプロジェクトマネージャーを派遣するサービスです。ですからこの論文は、私たちにとって二つの点で直接的です。
第一に、「大まかな目的の説明があるだけで、具体的な動作は成果物を見て推論しなければならない能力」は、実務のPM・エージェントの中核的な力量とまさに重なります。現実の顧客は、きれいな機能仕様書をくれません。「このサービスのように作ってください」「これ、とにかく動くようにしてください」と、動く実例やぼんやりした期待だけを渡してきます。ProgramDistillが測っているのはまさにこの状況、つまり目的の説明を手がかりに、完成した成果物から具体的な動作を逆算し、未完成の状態の上に実装する能力です。最新モデルですら全体の再構成で半分前後にとどまるという結果は、実際のプロダクトにエージェントを投入する際に「人間のPMによる要求の明確化ステップ」が依然として必須であることを示唆しています。
第二に、難易度を調整できる検証体系という発想は、そのまま取り入れる価値があります。ONTLEのエージェントが扱う作業も「浅い修正」から「複数のピースが絡み合った深い復元」まで幅が広いです。復元深度が1から8へ進むと性能が急落したという結果は、エージェントに一度に大きな塊を任せるよりも、小さな単位に分割して累積的に進めるようワークフローを設計するほうが安全だという実務上の教訓として読めます。また、再生検証のように「結果が実際に再現されるかを機械がもう一度確認する」自動検証のループは、エージェントの成果物を人が毎回目視で確認する負担を減らす方向とつながっています。
RAGやエージェントのパイプラインの観点からも、この論文は「仕様テキスト」だけがコンテキストのすべてではなく、動く参照物とのインタラクションそのものが強力な入力になり得ることを示しています。ドキュメントを検索して入れることを超えて、実際に動作を観察・再生して確認するステップをパイプラインに組み込む設計を考えさせられます。
従来のベンチマークは、イシューや指示文のような文章による仕様に具体的な動作まで書いて与え、そのとおりに実装させます。ProgramDistillは、機能の目的とワークフローを説明する問題文は与えつつ、具体的な動作は動く参照アプリとのインタラクションを通じて自力で推論し、未完成のアプリに実装するよう求める点が違います。
mine-craft-patchパイプラインの発掘・制作段階がアプリを機能単位に分解し、各動作を正解のコード変更分(ゴールドパッチ)で再生・検証します。アブストラクトによれば、この過程で26個のアプリから1,975件の検証済み動作と4,063件の課題を、人の介入なしに生成しました。
アブストラクトによれば、アプリ全体の再構成の累積的ワークフローにおいて、GPT-6 Astraが49.2%、Claude Opus 5が28.8%の成功率を示しました。部分的な再構成では、復元深度が1から8に大きくなると、成功率が100%から64.0%へ、96%から32%へと下落しました。
アブストラクトは、難易度を調整できるこの構造が、易しいものから難しいものへ順に教えるカリキュラムベースの学習の自然な土台になり得ると言及しています。ただし具体的な学習方法はアブストラクトの範囲外です。