1つの実行環境から、2件以上のcoding agent課題を取り出す。
そんな再利用を積み上げて、388個のmodern repository baseから900件のtaskを作った研究が登場しました。対象はbug fixだけではありません。feature追加、test生成、API migration、security repairまで含みます。
論文はChange2Task: From Repository Changes to Executable Coding Agent Tasks and Environmentsです。
新しいtaskをゼロから合成するのではなく、過去のmerged PRを、保守された現在のcodeへ移し替えます。Git履歴を「昔の記録」から「現在のagentが解く実行課題」へ変える発想です。
古い問題。coding agentのtaskは環境ごと高い
coding agentの評価taskには、issue文と正解patchだけでは足りません。
repositoryをcheckoutできること、dependencyが入ること、testが動くこと、agentが修正できる壊れた状態があること、修正後を判定できること。この一式が必要です。
そのためtaskを増やすほど、container image、setup時間、storage、registry traffic、cold startが増えます。taskが1件増えるたびに環境も1個増やしていたら、評価datasetより先に請求書が育ちます。元気なのは請求書だけ、という少し困る構図です。
過去のPRには、開発者が直した現実の問題、変更理由、patch、testが残っています。ただし古いcommitへ固定すると、dependencyやbuild手順まで古くなります。
Change2Taskの問いは明快です。
過去の保守意図だけを取り出し、現在も動くrepositoryへ移せないか。
中心アイデア。過去PRを現在のcodeへ逆向きに埋め込む
Change2Taskは、merged PRと、その子孫にあたる健康なmodern revisionを組にします。
健康な状態をHとします。ここへtask patchを当て、agentが直すべき状態Cを作ります。さらにrestoration patchを当てたH’で健康な振る舞いへ戻ることを確かめます。
重要なのは、昔のcodeを丸ごと復元しないことです。現在のAPI、wrapper、cache、周辺機能は保ち、過去PRが表していたmaintenance obligationだけを再現します。
構成は3段階です。
Level 1。Patch Reversal
過去PRの変更が現在のcodeにも直接対応するなら、そのpatchを逆向きに適用します。
開発者が修正したbugなら、現在のcode上でその修正部分だけを元へ戻し、bugを再登場させます。source patchとの構造的な距離が最も近い方法です。
Level 2。Code Mapping
refactoringで行番号やindentが変わっていても、変更後blockが現在のfileに一意に残っている場合があります。
この段階では、historical post-change blockを現在のcodeから探し、過去のpre-change blockへ局所的に置き換えます。対象blockが複数ある、fileが消えた、pure additionやpure deletionで対応が作れない場合は次へ進みます。
Level 3。Agent Reconstruction
symbol名やcall chainまで変わり、機械的な対応が弱い場合はconstruction agentを使います。
agentへ渡すのは、PR description、historical patch、現在のbehavior host、target check、regression check、許可されたedit範囲、過去attemptの失敗理由です。候補patchは最大4回で、apply、syntax、scope、fidelity、lifecycleのgateを通します。
ここは魔法の「AIでいい感じに」ではありません。agentの出力を狭いdiffと実行可能な契約へ閉じ込めています。
pass、fail、passでtaskを証明する
再構成できたように見えるpatchでも、本当に同じ保守課題とは限りません。
Change2Taskは3状態を検証します。
- 健康なHではtarget checkとregression checkが通る。
- task状態Cではtarget checkが失敗し、regression checkは通る。
- restored状態H’ではtarget checkとregression checkが再び通る。
つまりtargetはpass、fail、pass。regressionはpass、pass、passです。
さらに、historical source patchとmodern restoration patchを、file、hunk、changed line、symbol、target check、regression checkの6要素で比較します。aggregate fidelityは0.65以上、line、hunk、file ratioは0.50以上など、明示された最低条件があります。
testを落とすだけなら簡単です。関係ない機能まで壊せば、いくらでも赤くできます。Change2Taskが難しくしているのは、「狙った課題だけを再現し、周辺は壊さず、修正すれば元へ戻る」ことです。
実験結果。1,130件から900件を完成
論文は12のpublic benchmark collectionとreleaseから1,130件のconstruction-eligible changeを集めました。
最終的に900件をtaskとして確定しています。成功率は79.6%です。
構成routeの内訳は次の通りです。
- Patch Reversal: 95件
- Code Mapping: 190件
- Agent Reconstruction: 615件
大半がLevel 3である点は重要です。Git patchを単純にreverseするだけでは、現在のcodeへ移植できる範囲は小さい。repositoryの進化をまたぐには、behavior mappingと実行feedbackが必要でした。
Bug Fix 621件のmatched comparisonでは、Change2Taskが500件、SWE-smith PR Mirrorが387件を回収しました。回収率は80.5%対62.3%。Change2Taskはverified taskを相対的に29.2%多く作っています。
ただし、この比較はBug Fixに限定されます。5 task familyすべてでPR Mirrorを上回った、という結果ではありません。
再構成taskはagentの順位を保てるか
現在のcodeへ移したtaskが簡単すぎたり、難しすぎたりすれば、benchmarkとして意味が薄れます。
論文は900 taskを4つのcoding agent configurationで解かせ、historical branchとChange2Task branchを比較しました。合計3,600 pairです。
両branchのsolve数はそれぞれ1,478件、41.1%で一致しました。Originalだけ成功が186件、Change2Taskだけ成功も186件です。aggregate agreementは89.7%、Cohen’s kappaは0.787でした。
論文Abstractの「最大98.0% agreement」は最良の個別条件です。全体のagreementは89.7%です。この区別は小さく見えて大事です。最大値はスポットライト、全体値は室内灯くらい役割が違います。
結果は、再構成taskが完全に同一ではない一方、agent間の比較signalを大きく崩していないことを示します。
900環境を388 baseへ減らした効果
taskごとにbase環境を1つ用意する比較では900 baseが必要です。Change2Taskは388 modern baseを共有しました。1 baseあたり平均2.32 taskです。
同一hardware、同一retention、同一accounting ruleで比較した結果は次の通りです。
- setup時間: 3,240時間から1,349時間。58.4%減
- retained storage: 5,580GBから1,607GB。71.2%減
- end-to-end expenditure: 1,917ドルから1,710ドル。10.8%減
時間とstorageの減少に比べ、総費用の減少は10.8%です。Agent Reconstructionとtask固有のmaterialization、verificationには追加費用がかかるためです。
「環境を半分以下にしたから費用も半分以下」という話ではありません。ここでも、都合のよい数字だけを一人旅させないことが重要です。
実務へ移すなら、まず小さなPR-to-task pipelineを作る
ここからはAICompanyの解釈です。
Change2Taskの全systemを再現できなくても、考え方は社内coding agent評価へ移せます。
最小構成は次のようになります。
- merged PRのうち、変更前後を区別できるtestがあるものを抽出する。
- 現在のdefault branchから固定commitを選び、clean buildとtest通過を記録する。
- historical patchをreverseできる場合だけtask patchを作る。
- current base、task state、restored stateでtargetとregressionを実行する。
- diff、commit hash、test command、結果をtask receiptとして保存する。
最初からAgent Reconstructionまで入れず、Level 1だけで始めるのが安全です。回収率は低くても、どのPRが現在のcode上で再利用できるかを測れます。
次にCode Mappingを加えます。最後に、失敗categoryとedit scopeを明確にできた範囲だけagent reconstructionへ渡します。
この順序なら、task生成agent自身の暴走を防ぎながら、毎週のmerged PRから継続評価setを増やせます。Codexや他のcoding agentを更新したときも、自社repositoryの保守意図で回帰を測れます。
どこまで信用できるか
第一に、79.6%の分母はraw recordではありません。
最初のsource recordは1,783件です。evidence、runnable modern base、behavior alignmentなどを通過した1,130件がconstruction-eligible setです。したがって、あらゆるPRの約8割をtask化できるという意味ではありません。
第二に、対象はpublic PythonとJava corpus、5 task family、4 agent configurationです。UI、分散service、性能要件、hardware behaviorは、通常のtestだけで同じように扱えません。
第三に、900件中615件はClaude Code with Opus 4.8を使うAgent Reconstructionで作られました。別model、別prompt、別budgetでも同じ回収率になるかは未検証です。
第四に、semantic alignment auditはKimi K3とDeepSeek V4 Proのjudgeに加え、disagreementへのmanual adjudicationを使っています。実行testは強い証拠ですが、maintenance intentの同一性には判断が残ります。
第五に、論文とarXiv metadataからChange2Taskの公開実装やdataset URLは確認できませんでした。結果を第三者がすぐ再現できる状態ではありません。
最後に、10.8%の費用削減は、この研究のhardware、価格、storage policy、retention periodに基づくmatched comparisonです。自社環境ではtask per baseとCI費用を測り直す必要があります。
結論。Git履歴は評価資産になり得る
Change2Taskの新しさは、過去PRを再利用したことだけではありません。
historical intentを現在のcodeへ移し、pass、fail、passのlifecycleでtaskを証明し、複数taskでmodern baseを共有した点にあります。
900件のtask、89.7%のaggregate outcome agreement、58.4%のsetup時間削減、71.2%のstorage削減は、この設計が単なるアイデアで終わっていないことを示します。
一方で、eligible setの強い前処理、agent reconstruction依存、公開artifact不在という制約もあります。
それでも実務への第一歩は明確です。自社のmerged PRを、閉じたticketとして眠らせない。current branch上で再実行できるtask receiptへ変える。
coding agentの評価setは、外から買うだけのものではありません。repositoryが毎日生み出している保守履歴から、継続的に育てられます。
参照
【送料無料】マクロキーパッド、ストリームコントローラーデッキゲームストリーミングショートカットキーボード、18個のプログラム可能