💬 NLP

Change2Task: From Repository Changes to Executable Coding Agent Tasks and Environments

本論文は、マージされたプルリクエストを、履歴的なリポジトリ状態の再構築と現代的なコードベース上での検証を通じて、検証済みかつ実行可能なコーディングエージェントのタスクへと自動的に変換するシステムであるChange2Taskを紹介しており、これにより既存のベースラインと比較して、セットアップコストを削減しタスクのリカバリ率を向上させつつ、学習データの供給量を大幅に増加させる。

原著者： Haomin Qi, Xingliang Wang, Xuanqi Gao, Baihui Sang, Xin Zhang, Minghua Ma, Pengfei Gao, Yu Kang, Qingwei Lin, Saravan Rajmohan, Dongmei Zhang, Qi Zhang

公開日 2026-07-31

📖 1 分で読めます☕ さくっと読める

CC BY 4.0

原著者： Haomin Qi, Xingliang Wang, Xuanqi Gao, Baihui Sang, Xin Zhang, Minghua Ma, Pengfei Gao, Yu Kang, Qingwei Lin, Saravan Rajmohan, Dongmei Zhang, Qi Zhang

原論文は CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) でライセンスされています。 ✨ これは以下の論文のAI生成解説です。著者が執筆または承認したものではありません。技術的な正確性については原論文を参照してください。免責事項の全文を読む

コンピューターがソフトウェアエンジニアになろうと学習している世界を想像してみてください。これらの「コーディング・エージェント」は、単に一行のコードを書いて終わるのではなく、プロジェクトを開き、ファイルを読み、バグを修正し、テストを実行し、失敗したらやり直すことができる、デジタルな弟子のような存在です。しかし、ここには落とし穴があります。本当に優れたものになるためには、彼らは現実世界の課題で練習する必要があります。彼らが壊れた機能を直したり、新しい機能を追加したりするための膨大な「演習」ライブラリ、そして明確な「合格」または「不合格」の成績が必要です。

問題は、こうした練習用の演習を作成することが非常に困難で、コストがかかることです。通常、テストを作成するには、あらゆる問題に対して、完璧に隔離されたコンピューター環境（デジタルなサンドボックスのようなもの）を構築しなければなりません。もし1,000個の異なるコーディング・チャレンジを作りたいなら、1,000個の異なるサンドボックスを作る必要があり、それには膨大なストレージ容量と時間が必要になります。これは、料理のレシピを一つ学ぶたびに、そのレシピのために完全に設備が整った新しいキッチンをゼロから作り上げるようなものです。あまりにも手間がかかるため、練習問題が底をついてしまい、エージェントがエキスパートになるために必要なトレーニングを受けることができなくなってしまうのです。

ここで、Change2Taskという新しいアイデアが登場します。これは、コードのための魔法のタイムマシンのようなものです。レシピごとに新しいキッチンを作る代わりに、Change2Taskは実際のソフトウェア・プロジェクトの履歴、つまり、過去に人間の開発者がバグを修正したり機能を追加したりした際の巨大な記録簿（ログ）に注目します。そして、その古い実社会の物語を見て、「この課題を、現在のバージョンのソフトウェア上で、全く同じように再現できるか？」と問いかけるのです。

このシステムは、賢いエディターのように機能します。それは「マージされたプルリクエスト」（変更が受理され、コードに追加されたことを意味する専門用語です）を見つけ出し、それをリバースエンジニアリングしようと試みます。コンピュータに対し、その変更を「元に戻す」ことで壊れた状態を作り出し、次にコーディング・エージェントに対して、それを再び修正するという目標を設定させます。しかし、ここでの魔法のトリックは、最初から作り直すのではなく、すでに稼働している現代的で健全なバージョンのソフトウェア上で行うという点です。もし元の修正が行われた当時からコードが大きく変化している場合、Change2Taskは、古い修正を新しいコードへとマッピングするために、3つの異なる戦略を使用します。

パッチ反転 (Patch Reversal): コードがあまり変わっていない場合は、単に古い修正を逆方向に反転させます。
コード・マッピング (Code Mapping): コードの場所が移動している場合は、古いコードの新しい場所を見つけ出し、そこを入れ替えます。
エージェント再構成 (Agent Reconstruction): コードが全く異なっている場合は、スマートなAIエージェントを使用して、新しい環境の中でどのように問題を再現するかを考え出します。

研究者たちは、これをバグ修正、新機能の追加、新しいテストの作成、古いツールの更新（API）、およびセキュリティ・パッチの適用という5つの一般的なコーディング・タスクでテストしました。彼らは、公開されているソフトウェア・プロジェクトから1,130件の実世界の変更を取り出しました。システムは、それらのうち900件を動作可能で検証済みの練習タスクへと正常に変換することに成功しました。成功率は約80%です。

これがどれほど刺激的なことかを理解するには、節約されたコストを見る必要があります。同じ「キッチン」（ソフトウェア環境）を複数の異なる練習問題で再利用することにより、環境のセットアップに必要な時間を58.4%削減し、必要なストレージ容量を71.2%削減しました。実際、以前の手法（単に古い修正を直接コピーしようとする手法）よりも、29.2%多くの検証済みタスクを作成することができました。

チームは、これらの再作成されたタスクが公平であるかどうかについても確認しました。彼らは、異なるAIコーディング・エージェントに、オリジナルの歴史的なバージョンと新しい現代的なバージョンの両方で問題を解かせました。結果はほぼ同一でした。エージェントは98%の確率で同じ「合格」または「不合格」の判定を得ました。これは、新しいタスクが単なるランダムな推測ではなく、実際の開発者の作業を忠実に再現していることを証明しています。

要するに、Change2Taskは単に多くの練習問題を見つけるだけでなく、既存のものをいかに再利用可能で効率的にするかという方法を見出したのです。それは、ソフトウェア開発の歴史を、次世代のAIコーダーを訓練するための再生可能な資源へと変え、レッスンごとに新しい世界を構築する必要はなく、ただ古い世界を新鮮な目で見る方法を知っていればよいのだということを証明しています。

技術サマリー: Change2Task

問題提起

コーディングエージェントのスケーリングには、トレーニング、ベンチマーク、および評価のための、高品質で実行可能なデータの継続的な供給が必要です。各タスクユニットは、現実的なソフトウェアの状態を、仕様、開発ツール、および信頼できる検証と組み合わせる必要があります。現在の手法は、以下の大きなボトルネックに直面しています：

コストと規模: 実行可能な環境を生成することは高価です。daVinci-EnvやSWE-Universeのようなシステムは、個々のタスクに対して個別のスナップショットを維持するために、膨大なインフラストラクチャとストレージを必要とし、高い構築コストとストレージ圧迫を招いています。
データの限界: 過去のベンチマーク（例：SWE-bench）は、タスクを元の（多くの場合、時代遅れとなった）リポジトリのリビジョンに紐付けており、現代的なコードベースへの適用性を制限しています。逆に、合成タスク生成（例：SWE-smith）は、真の開発者の意図やメンテナンスの文脈を欠いたインスタンスを生成する可能性があります。
ギャップ: 単一の維持管理されたリポジトリ環境から、複数の検証済みかつ開発者に根ざしたタスクを派生させることで、冗長なセットアップの努力を軽減しつつ、実行可能なデータの多様性を拡大する必要があります。

メソドロジー

Change2Task は、マージされたプルリクエスト（PR）を、同じリポジトリの健康的で現代的な後継リビジョン上の検証済みコーディングエージェントタスクへと変換するために設計されたフレームワークです。本システムは、ライフサイクル $V_{pre} \xrightarrow{P_s} V_{post}$ （歴史的な状態変化）に基づき、これを $H \xrightarrow{D} C \xrightarrow{G} H'$ （現代のベースからタスク状態、そして復元された状態へ）として再構成します。

プロセスは、以下の4つの主要な段階で構成されます。

1. タスク証拠の派生

システムは、マージされたPRから、その説明、実装パッチ、および実行可能なチェックを含む証拠を抽出します。これにより以下が定義されます：

ターゲットチェック: 再構成されるべき条件。
回帰チェック: 整合性を維持しなければならない周囲の振る舞い。
ソース変更プロファイル: 影響を受けたコンポーネントと編集範囲の記録。
条件が曖昧である場合、チェックが実行不能である場合、または変更を分離できない場合は、候補は除外されます。

2. 現代的なタスクベースの確立

各適格なPRに対して、同じリポジトリの系統から、固定された健康的で現代的な後継リビジョン（ $H$ ）が選択されます。このベースは、クリーンなチェックアウト、ランタイム依存関係、および実行可能なチェックをサポートしている必要があります。システムは、処理を進める前に、マッピングされたターゲットおよび回帰チェックが $H$ 上でパスすることを確認します。

3. タスク状態の構築

Change2Taskは、健康なベース（ $H$ ）をタスク状態（ $C$ ）へと変容させるタスクパッチ（ $D$ ）を生成するために、3レベルの適応型構築戦略を採用しています：

レベル1：パッチの反転: ソースパッチが現代のコンテキストと互換性がある場合、そのパッチを直接反転させます。
レベル2：コードのマッピング: 直接的なリプレイが失敗した場合、システムは現代のファイル内にある歴史的な変更後のブロックを特定し、それを変更前の形式に置き換えます。これにより、インデントの正規化や保守的なローカル変換が可能になります。
レベル3：エージェントによる再構成: 構造的な対応関係が不十分な場合、構築エージェント（PRの証拠と現代のコンテキストを使用）がスコープを限定した候補パッチを提案します。これらは構文、スコープ、およびライフサイクルチェックによってフィルタリングされ、ソース変更プロファイルの忠実度によってランク付けされます。

4. ライフサイクルとスコープの検証

すべての候補は、3つの状態で検証されます：

健全（ $H$ ）: ターゲットおよび回帰チェックがパスする。
タスク（ $C$ ）: ターゲットチェックが特定のタスク条件（例：バグまたは不足している機能）を露呈させ、一方で回帰チェックは引き続きパスする。
復元（ $H'$ ）: 復元パッチ（ $G$ ）を適用した後、両方のチェックセットがパスし、システムが健全な状態に戻れることを確認する。

また、システムは、現代のタスクが元の変更を些細なものにしたり（スコープの崩壊）、無関係な広範な編集を要求したり（スコープの膨張）しないよう、スコープと忠実度のゲートを強制します。

主な貢献

Change2Task フレームワーク: 開発者に根ざしたメンテナンス変更を現在のコードへと転送し、その由来、振る舞い、スコープ、および復元可能性を検証する汎用的なツール。
適応型構築: 必要に応じて複雑さを段階的に高めていく3層のアプローチ（反転、マッピング、再構成）により、有効なタスクの回復を最大化します。
タスクアダプター: バグ修正、機能追加、テスト生成、API移行、セキュリティ修復の5つの異なるタスクファミリーをサポートする統一されたインターフェース。
効率化メカニズム: 単一の維持管理されたベースから複数の軽量なタスクバリアントを派生させることで、環境セットアップ、ストレージ、および手動構築の重複した努力を大幅に削減します。

実験結果

システムは、5つのタスクファミリーにわたる1,130の構築適格なソース変更を用いて評価されました。

回復率: Change2Taskは900組のペアタスクを完成させ、全体で**79.6%**の検証済みタスク構築成功率を達成しました。
- バグ修正: 500件のタスクを回収。
- 比較: 621件のバグ修正候補の照合セットにおいて、Change2Taskは500件のタスクを回収しましたが、これはSWE-smith PR Mirrorベースラインの387件と比較して、**29.2%**の相対的な向上を示しています。
忠実度: コーパスは0.894のタスク重み付きソース変更プロファイル忠実度を達成しました。エージェントによる評価において、歴史的ケースと再構成されたケースの間では、最大**98.0%**の出力一致が見られました。
エージェントの一貫性: 3,600組のマッチしたエージェント・タスクのペア全体において、オリジナル（歴史的）ブランチとChange2Task（現代的）ブランチの間の総合一致率は89.7%（Cohen's $\kappa$ = 0.787）でした。ペアの解決率の差は無視できる程度（0.0ポイント）であり、現代のタスクが歴史的なアンカーの比較評価シグナルを保持していることを示しています。
リソース効率: 900個のタスクに対して388個の現代的ベースを再利用した結果、以下の効果が得られました：
- セットアップ時間の**58.4%**削減。
- ストレージ要件の**71.2%**削減。
- エンドツーエンドの支出の**10.8%**削減。

意義と主張

本論文は、Change2Taskがリポジトリの履歴を、受動的な記録から検証可能なコーディングタスクの回復可能なソースへと効果的に変換することを主張しています。その主な意義は以下の通りです：

スケーラビリティ: 個々のタスクに対して固有の環境を作成するという法外なコストをかけることなく、コーディングエージェントのトレーニングのための実行可能なデータの供給を拡大するメカニズムを提供します。
グラウンディング（接地）: 歴史的な変更の「開発者に根ざしたメンテナンス契約」を保持し、タスクが合成されたアーティファクトではなく、現実世界のメンテナンスの意図を反映することを保証します。
効率性: 現代的なベースを再利用することで、大規模なエージェント評価に関連する計算およびストレージのオーバーヘッドを劇的に削減します。

著者らは、Change2Taskを既存の環境準備ツール（RepoLaunchなど）を補完するものとして位置づけています。具体的には、ベースが実行可能になった後のフェーズ、すなわち、その投資から最大限の数の異なる検証済みタスクを派生させることを目的としたフェーズに対処しています。