コーディングAIの誤検知判定F1が0.43から0.70へ。GSEがスキルを育てる方法
コーディングAIに失敗から学ばせると、次は賢くなる。そう考えるのは自然です。ただし、学びをメモとして足し続けるだけでは、別の仕事で邪魔になる知識や、互いに矛盾する手順も増えていきます。人間の「忘れないように付箋を貼る」が、最後には壁一面の付箋になる問題です。
2026年8月に公開された論文Learning Globally Reusable Skills for Coding Agentsは、この問題をskill bank全体の変更管理として扱うGSE（Globalized Skill Evolution）を提案しました。OpenHandsによるbug reportの誤検知除去では、最も強い比較手法のF1 0.43に対し、GSEは0.70でした。
重要なのは、モデルを再学習した結果ではないことです。失敗traceから作るskillを、関係図、統合、回帰testの3段階で管理した結果です。
古い問題：1件の失敗を直すと、skill bank全体が少しずつ壊れる
Coding agentのskillは、repository探索、test作成、error解釈、patch確認などの手順を自然言語でまとめたものです。実行に失敗したら、そのtraceを読んで新しい注意点を追加する。ここまでは多くの自己改善手法と似ています。
難しいのは、その注意点が他のskillと独立していないことです。
例えば「mockを使って外部serviceを切り離す」というskillは、「integration testでは実service contractを確認する」というskillと衝突する場合があります。「変更methodだけを見る」という高速化skillは、「caller側の前提まで追う」という探索skillより先に発火すると、bugの原因を見落とします。
局所的に成功した更新をそのまま追加すると、3つの問題が起きます。
- 特定repositoryにしか通じない指示が残る
- 同じ能力を表す似たskillが増える
- 依存、併用、衝突の関係が見えない
GSEは、skillを単独の文書ではなく、関係を持つsystemとして扱います。
核心は3段階。関係を見る、共通化する、過去を再生する
GSEの処理は次の順番です。
- Agentの失敗traceから、能力不足の原因を診断する
- 更新提案をDSLで構造化する
- Skill Relation Graphで他skillへの影響を見る
- 発生元の失敗caseを再実行し、直せない提案を捨てる
- 似た提案をcluster化し、case固有部分を削る
- 関係する過去caseをreplayし、性能が落ちない更新だけを採用する
更新提案には、対象skill、edit操作、変更内容、理由、期待する挙動、relation変更が含まれます。自由文をそのままskill bankへ放り込まず、変更の意図と影響を機械的に追える形にするわけです。
Skill Relation Graphは3種類の関係を持つ
論文のSkill Relation Graphは、skillをnode、関係を有向edgeとして表します。Edgeは次の3種類です。
- dependency: 後段skillが前段skillの前提や出力に依存する
- co-usage: 一緒に、または特定の順序で使うと効果が高い
- conflict: 同時に有効化すると矛盾する
このgraphがあるため、1つのskillを書き換えるとき、直接つながるskillも含めて整合性を確認できます。更新対象だけを見て「直った」と判断しない点が肝です。
Cluster統合は、失敗例を一般的な能力へ変える
新しい提案が元caseを直しても、まだ採用しません。GSEは、同じskill群を変更する提案や、意味的に近い新規skill提案をまとめます。そのclusterから共通patternを抜き出し、repository名や特定API名などのcase固有情報を除いてcandidate skill bankを作ります。
最後にhistorical replayを実行します。既存skillの変更なら、そのskillが過去に使われたcaseを再実行します。新規skillなら、cluster内の提案を生んだcaseを再実行します。性能を維持または改善できなければmergeしません。
これは、skill版の「unit testだけ通ったのでmainへ入れました」を防ぐ仕組みです。少し地味ですが、地味な回帰testはだいたい後でヒーローになります。
実験で何が伸びたのか
研究は2種類のsoftware engineering taskを使いました。
1つ目はbugを再現するtestの生成です。Multi-SWE-BenchのJava部分から、実際にbugを発火できる108 method、9 projectを手作業で確認しています。
2つ目はbug reportのfalse positive除去です。ByteDanceと構築したIndustrialBugsを使い、8つのGo repositoryから500 reportを集めました。内訳は実bug 132件、false alarm 368件です。
各runでは1 projectを丸ごと評価用に残し、残りのprojectだけでskill bankを進化させるone-project-held-out方式を採用しました。評価対象そのものからskillを作る漏洩を避け、別projectへ移せるかを見ています。
主なF1は次の通りです。
| Task | Agent | 最強baseline | GSE | |—|—:|—:|—:| | Bug-revealing test生成 | OpenHands | 0.22 | 0.31 | | Bug-revealing test生成 | mini-SWE-agent | 0.29 | 0.38 | | False-positive filtering | OpenHands | 0.43 | 0.70 | | False-positive filtering | mini-SWE-agent | 0.39 | 0.46 |
OpenHandsのfalse-positive filteringでは、precisionが0.29から0.55、recallが0.84から0.95へ上がりました。単に多くをbug扱いしたのではなく、見逃しを減らしながら誤検知も抑えた結果です。
Ablationが示すこと。Graphだけでも、replayだけでも足りない
GSEからSkill Relation Graphを外すと、OpenHandsのfalse-positive filtering F1は0.70から0.59へ下がりました。Cluster統合とreplay-driven validationを含むgeneralization機構を外すと0.54まで下がりました。
Bug-revealing test生成でも、full GSEのF1 0.31に対し、どちらを外しても0.27です。
論文の主張は明確です。Skill同士の関係を守る仕組みと、局所更新を一般化して過去caseで検証する仕組みは、どちらも必要です。
ただし、これは因果関係を完全に分離した証明ではありません。AblationはOpenHandsを代表agentとして使い、同一のDeepSeek-V4-Flashを基盤LLMにしています。別modelや長期運用でも同じ差が出るかは未確認です。
実務へ持ち込むなら、skill fileを直接書き換えない
ここからはAICompanyの解釈です。論文はCodexやOpenCodeを直接評価していません。
実務への最小構成は、次のようにできます。
“text failure trace -> structured proposal -> candidate skill branch -> origin case replay -> related regression replay -> accept or reject -> versioned skill bank “
最初からgraph databaseを導入する必要はありません。各skillに depends_on、works_with、conflicts_with のmetadataを持たせ、Git branchでcandidateを作るだけでも考え方を試せます。
測るべき指標は、成功率だけではありません。
- Skill追加前後の成功率
- 既存caseのregression数
- Skill発火回数と未使用skill数
- Promptへ読み込むtoken数
- Skill重複率
- Rejectされた更新の理由
特に「元の失敗が直った」と「skill bank全体が良くなった」を別のgateにすることが重要です。
Costは無料ではない
GSEのskill evolutionは1 case平均401.55K tokensで、Trace2Skillの357.64Kより12.28%多く使いました。
Downstream executionは593.21K tokensです。Human skillの620.58K、Live-SWE-agentの613.61K、Trace2Skillの619.65Kより少ない一方、base agentの489.31Kよりは多い。つまり、GSEは「tokenを減らす手法」ではなく、「追加costと引き換えに判断品質を上げ、他のskill手法より実行時の迷走を抑えた手法」です。
費用が高い環境では、すべての失敗からskillを作るのではなく、再発頻度、影響度、既存skillとの重複を先に判定した方がよいでしょう。
限界。まだ自動でskill bankを放置できる段階ではない
強い結果ですが、次の制約があります。
- IndustrialBugsとproprietary agentは非公開で、主要結果を外部から完全再現できない
- GSEの公式code repositoryを公開arXiv pageから確認できない
- 基盤LLMはDeepSeek-V4-Flashに固定されている
- Temperature 0で、複数seedの分散や信頼区間が示されない
- 評価taskはtest生成と誤検知除去に限られる
- 未観測のskill同士の衝突をhistorical replayだけで保証することはできない
また、one-project-held-outはproject間の移植性を見る良い設計ですが、時間をまたいだ長期劣化や、skill数が数千へ増えたときの探索costは測っていません。
結論：Agentの学習力より、学びをmergeする仕組みが重要になる
GSEの価値は、coding agentに新しい知識を足したことではありません。Skillを関係付きのsystemとして扱い、局所test、共通化、historical replayを通してからmergeしたことです。
OpenHandsのfalse-positive filtering F1が0.43から0.70へ伸びた結果は、この変更管理が単なる整理術ではない可能性を示しています。一方で、非公開dataと単一model依存があるため、数字をそのまま自社環境へ移すことはできません。
実務でまず試すなら、agentが失敗するたびにskill fileへ追記する運用を止めることです。Candidate branchを作り、元caseと関連caseをreplayし、versionを残してからmergeする。Agentを賢くする前に、Agentの学び方を壊れにくくする。その順番が効きます。
【送料無料】マクロキーパッド、ストリームコントローラーデッキゲームストリーミングショートカットキーボード、18個のプログラム可能