AIエージェントのSkillは、全部直すな。WMLが失敗箇所だけを修復してHard Accuracy 90.33%を達成した仕組み
AIエージェントが失敗したとき、怖いのは失敗そのものだけではない。修正役のAIがSkill全体を書き直し、昨日まで動いていた手順まで壊すことである。
人間のコードレビューなら「そこだけ直して」と言える。しかし、長い実行ログ、複数ファイルのSkill、外部から集めた手順が相手になると、どの工程の何が悪く、どこまで編集してよいかが曖昧になる。修正が大きいほど賢そうに見えるが、だいたい回帰バグも大きい。AIも大掃除を始めると、必要なネジまで捨てる。
2026年7月23日に公開された論文「Workflow-Localized Mechanism Learning」は、この問題を失敗箇所の局所化として扱う。提案手法WMLは、失敗した工程、原因となった機構、機構同士の関係、最小の編集先を先に決める。そして、その範囲だけを修正し、再評価で改善した場合だけ採用する。
論文の表計算エージェント評価では、SpreadsheetBenchのHard AccuracyがDeepSeekで90.33±1.53%に達した。最強の非WML手法は84.33±2.08%で、差は6.00ポイントだった。重要なのは数字だけではない。Skillを自由作文で直すのではなく、編集権限を証拠に結び付けた点に実務的な価値がある。
古い問題：修正する層は分かっても、場所が広すぎる
エージェントのSkillは、単一のプロンプトとは限らない。論文では、発見や起動条件を持つL1、常に読み込むワークフロー本体のL2、必要なときだけ読む機構別リソースのL3という構造を使う。
既存研究は、失敗ログを使ってSkill文書を更新したり、どの層を直すべきかを選んだりしてきた。しかし、同じL2やL3の中にも複数の工程と規則がある。
たとえば、表計算エージェントが計算自体には成功したのに、禁止された形式で結果を書き込んだとする。この場合に足りないのは、出力形式を決める単独の規則かもしれない。
一方、保存、処理順序、失敗時の復旧、保存後の確認という規則が個別には存在しても、組み合わせ方が悪い場合がある。この失敗は、一つの規則へ説明を足すだけでは直らない。
同じ「保存工程の失敗」でも、原因と編集先は違う。ここを分けずに直すと、狭い不具合からSkill全体の改築工事が始まる。
核心：失敗を4つの住所へ変換する
WMLのNode-Mechanism Attributionは、失敗ごとに4つの情報を作る。
- 失敗したワークフローノード
- 関係する再利用可能な機構
- 単独機構の知識不足か、複数機構の関係不良か
- レイヤー、ファイル、節まで含む型付き編集先
論文はワークフローを、文脈取得、対象特定、操作選択、実行と変換、状態反映、確認と終了の6ノードへ抽象化する。これは表計算専用のオブジェクト名ではなく、処理上の役割である。
次に、原因を2種類へ分ける。
- 単独機構の知識不足なら、その機構を担当するL3リソースだけを直す
- 複数機構の選択、順序、競合処理、共同検証が悪いなら、L2の構成プロトコルだけを直す
モデルが自由にファイルを選ぶわけではない。診断結果を決定的なレジストリへ通し、合法なノードと編集先へ対応付ける。既存の指示ですでにカバーされている、診断同士が矛盾する、証拠から編集先を一意に決められない。このような場合は編集を見送る。
この「何もしない」という選択は地味だが重要だ。自動修復では、間違った改善より安全な保留のほうが安い。
外部Skillは、全文を混ぜずに部品として使う
WMLを実装するWGSOは、第三者Skillも修復材料に使う。ただし、検索で見つけたSkill全文をプロンプトへ貼る設計ではない。
外部の手順を、出所、機構、適用範囲、手続き、検証条件、信頼度を持つ記録へ分解し、最適化側の索引へ置く。現在のSkillと過去の修復記憶で知識が足りない場合だけ、原因に合う記録を検索する。
選ばれた知識は、型付き編集先と保存条件の範囲で適応、統合、または却下される。外部Skillの文章がそのまま実行側へ入るわけではない。
この設計には二つの意味がある。
第一に、別の開発者が書いた手順から、必要な判断規則だけを再利用できる。第二に、外部Skillに含まれる命令や前提が、無制限に現在のエージェントへ流れ込むのを防ぎやすい。
ただし論文も、外部手順にはプロンプトインジェクションや悪意ある処理が混ざる可能性を認めている。出所、ライセンス、適用範囲、汚染検査は別途必要である。「外から拾ったSkillだから即戦力」は、だいたい採用面接を省略した状態に近い。
改善した修正方法だけを記憶する
WGSOは、実行、採点、原因帰属、局所パッチ、再評価を繰り返す。候補の構造差分が許可範囲を越えていないかを検査し、同じバッチで再実行する。改善した候補だけをSkillへ反映し、悪化や不完全な候補は元へ戻す。
さらに、Patch-Strategy Memoryという最適化側の記憶を持つ。ここへ保存するのは、外部Skillの全文ではない。
- どの種類の失敗だったか
- どの範囲を編集したか
- 何を壊さない条件にしたか
- どの検証を通したか
- 結果は改善、却下、悪化のどれだったか
改善が確認された編集方法だけが、次の修正を制約する方針として強化される。却下された修正も負の履歴として残るが、成功方針には昇格しない。
つまりWMLは、Skillの内容と、Skillをどう直すかという知識を分けている。実行役へ修復履歴を全部背負わせないため、Skill本体の肥大化も抑えやすい。
実験：4条件すべてでWMLが首位
主評価はSpreadsheetBenchとWikiTableQuestions、実行モデルはDeepSeek-chatとQwen3.6-Flashである。訓練型手法は3回の独立実行の平均と標本標準偏差で比較された。
WMLの結果は次の通りだった。
| 実行モデル | SpreadsheetBench Hard Accuracy | WikiTableQuestions Denotation Accuracy | |—|—:|—:| | DeepSeek | 90.33±1.53% | 84.00±2.00% | | Qwen3.6-Flash | 74.67±3.51% | 83.00±2.00% |
4列すべてでWMLが首位だった。最強の非WML手法との差は、順に6.00、2.33、4.67、3.00ポイントである。
WikiTableQuestionsは追加最適化なしの転移評価だが、表をワークブックへ変換して回答セルへ出力する設定である。一般的な別領域へそのまま転移した証拠ではない。
アブレーションも、局所化が飾りではないことを示す。Full WMLのHard Accuracyは90.00±1.00%だった。Node-Mechanism Attributionを外すと84.67±0.58%となり、5.33ポイント下がった。Cell Accuracyの低下は7.89ポイントで、3種類の除去条件の中で最大だった。
第三者知識の強化経路を外した場合もHard Accuracyは5.33ポイント、Patch-Strategy Memoryを外した場合は3.33ポイント低下した。原因の局所化、足りない知識の補充、成功した修正方法の記憶が、それぞれ結果へ寄与している。
Skillを一度学び、安い実行系へ渡せるか
論文は、改善済みSkillをLLMワークフローコンパイラへ渡す実験も行った。コンパイラはSkillから型付きワークフローと実行コードを作り、共通のサンドボックスで動かす。
Compiler-Supported50で、WMLは40/50件をhard PASSした。最強の非WML手法は23/50件で、差は17件だった。成功1件当たりのコストも、WMLが33,352トークン、1.35回のLLM呼び出しで最小だった。
同じWML Skillを、自由度の高い直接SkillAgentで動かすと46/50件、コンパイル実行では40/50件だった。コンパイルは6件の成功を失う一方、総トークンを8,835,158から1,334,063へ、LLM呼び出しを562回から54回へ減らした。
これは、コンパイル実行が常に優れるという結果ではない。対応範囲では安く、制約しやすく、監査しやすい。未知の作業では直接エージェントへ戻す。Skillを一度改善し、使える範囲だけ軽量な実行系へ落とすハイブリッド構成が見えてくる。
AICompanyの応用案：Codexの修正ルールへ翻訳する
ここからは論文の実証結果ではなく、AICompanyによる応用案である。
CodexやOpenCodeでSkillを保守するなら、失敗記録を次のような小さな構造へ変換できる。
“json { "failed_node": "verification", "mechanisms": ["test_selection", "exit_code_check"], "relation": "multi_relation", "edit_target": "workflow.md#validation", "preserve": ["passing_smoke_test", "no_external_send"], "gate": ["targeted_test", "regression_test"] } “
この例では、テスト選択と終了コード確認の規則は個別に存在するが、共同検証の順序が悪い。したがって、各テスト手順を全面改稿せず、検証工程の接続規則だけを直す。
小さく試すなら、過去の失敗10件で十分である。
- 各失敗を6つの工程へ分類する
- 単独規則の不足と、規則同士の接続不良を分ける
- 編集可能なファイルと節を固定する
- 既存の成功例を保存条件にする
- 対象テストと回帰テストの両方が通った修正だけ採用する
見るべき指標は、成功率だけではない。変更行数、触ったファイル数、回帰件数、保留率も記録する。局所化が効けば、同じ成功率でも変更範囲と回帰が減るはずだ。
限界：表計算で勝った。一般の開発で勝ったとはまだ言えない
実験の中心は表計算エージェントである。6ノードの分類、機構語彙、L2とL3の構造が、ソフトウェア保守、ブラウザ操作、ロボットでも有効かは未検証だ。
アブレーションは3 seedで、論文も記述的な差として扱い、有意差を主張していない。パッチ採用は同じバッチで比較されており、独立した長期回帰セットも今後の課題である。
Compiler-Supported50は、WMLの開発軌跡からコンパイラが実行可能な成果物を作れた50件で構成された。開いた世界の全タスクを代表するベンチマークではない。
公式リポジトリはMITライセンスで、中核実装、プロンプト、評価器、固定seed 42の再現入口を公開している。一方、生成済み軌跡、実験ログ、データセット、外部Skillコーパスは含まれない。再現にはSpreadsheetBench Verified、LibreOffice、外部Skillコーパス、モデル認証情報と計算費用が必要である。
結論：賢い修正より、修正権限の狭さを設計する
WMLの中心は、AIにもっと自由に直させることではない。失敗の証拠から、原因と編集先を狭くし、改善を確認できた修正だけを通すことである。
単独規則の不足なら、その規則だけを直す。複数規則の接続が悪いなら、接続部分だけを直す。外部Skillは全文を混ぜず、出所と適用範囲を持つ部品として使う。成功した修正方法は、実行Skillとは別に記憶する。
AIエージェントが長く働くほど、性能を決めるのは一回の賢い回答だけではなくなる。失敗後にどこまで触ってよいか、何を守るか、どの検証を通すか。その修正契約こそ、Skillを育てるための次の重要部品である。
一次資料
【送料無料】マクロキーパッド、ストリームコントローラーデッキゲームストリーミングショートカットキーボード、18個のプログラム可能