3つのKotlinプロジェクトでエージェント向けSKILL最適化を実測：GEPAの平均改善はわずか4.9ポイントで、ノイズの範囲を超えず

coding agent向けの`SKILL.md`や`AGENTS.md`といったリポジトリ説明ファイルは、低コストで性能を高める手段とみなされることが多い。しかし、文書が専門的に見えるからといって、エージェントが実際にコードをうまく修正できるとは限らない。9月14日付のarXiv最新リストに掲載された研究は、「reverse-PR mining」を提案した。Kotest、Ktor、Koogでマージ済みのPRを選び、関連する変更を同一の凍結済みベースライン版へ逆適用することで、テストが失敗する状態を修正タスクへと変換する。この方法により、現在のコードから単純な問題を直接合成した場合、最先端のエージェントが説明文書なしでも性能上限に達してしまう問題を回避できる。

研究者らはさらに、GEPAとSkillOptにrolloutのフィードバックを用いてSKILLを反復的に書き換えさせ、同じエージェントについて「文書あり」と「文書なし」の問題解決能力の差を評価した。3つのKotlinリポジトリでは、GEPAの文書によって平均4.9ポイントの改善が得られた。一方、SkillOptは初期文書をわずか0.1ポイント上回っただけだった。人間による評価は数値よりも楽観的で、Koogのメンテナーは、生成物に、通常ならプロジェクトへ実際に参加しなければ得られないビルドやモジュールに関する知識が含まれていると評価した。

真に重要な発見は、評価目標を容易に取り違え得ることだ。文章の品質、リポジトリに関する事実の数、元のPRとのCodeBLEU類似度、さらにはtokenコストを目標にしても、読み物としては網羅的でありながら、エージェントの挙動を改善しない文書が選ばれる可能性がある。コストを目標にすると、空のSKILLが好まれることさえある。そのため、エンジニアリングチームは別のモデルに文書を評価させるだけではなく、凍結済みバージョン、実行可能なテスト、文書なしのベースラインを用いた対応比較を行うべきだ。

ただし、4.9ポイントの改善は、単一エージェントにおける実行間のばらつきと依然として切り分けられていない。また、実験対象も3つのJVM／Kotlinプロジェクトに限られている。今後はリポジトリとタスクの数を増やし、各実行のtrajectoryを公開するとともに、モデルやエージェントフレームワークを変更した後も文書が汎化できるかを検証する必要がある。