LayerXPublicationへの投稿
🐬

Agent Skills自動最適化の研究、中身はほぼ深層学習の訓練ループだった

223
に公開
Agent
llm
Agent
Anthropic
Skills
tech

Ai Workforce事業部FDE部エンジニアの堤(@ozro_223)です。
本記事では、Coding Agent（以降、エージェントと呼びます）に持たせるスキルを、ハーネスの工夫でエージェントの実行経験から学習させる2026年上半期の研究動向を紹介します。ここでいうスキルは、Agent Skillsに代表される、SKILL.mdを含むフォルダを指します。

先に種明かしをすると、どの研究も、訓練データ・損失関数・勾配・学習率にあたる部品を1つずつテキストに置き換えた、深層学習の訓練ループとほとんど同じ形をしていました。

いま、AI界隈ではLoop Engineeringという言葉がバズワードになっています。「エージェントにプロンプトを書くのをやめて、エージェントを動かすループを設計せよ」という考え方です。
私も業務でエージェントの自己改善に取り組んでおり、そこでぶつかった問題と解決策の考察を以前ブログに書きました。

https://zenn.dev/layerx/articles/b36ceffe6b5e20

この記事に、同僚のcipeさんが言及してくれました。

https://x.com/cipepser/status/2067126384812761399?s=20

指摘の通り、エージェントの自己改善とスキルの自己改善・自動更新は、本質的に同じ問題だと私も考えています。今回は前回記事の続きとして、自己改善・自動更新の話題をスキルの側から扱った研究、ハーネスの工夫によるスキル自動最適化を見ていきます。

なお、本記事で紹介する論文はすべて2026年3〜6月公開の未査読プレプリントです。本記事では数値の優劣ではなく、ループの設計を中心に見ていきます。

公式ガイドは、すでに訓練ループの形をしている

前提として、Agent Skillsの仕組みと、Anthropicが推奨するスキルの作り方を短くおさらいします。
Agent Skillsは、SKILL.md（YAML frontmatter＋手順の本文）と参照ドキュメント、実行可能スクリプトを束ねたディレクトリです。読み込みはprogressive disclosure（段階的開示）と呼ばれる3段階で行われます。

  1. 起動時は、全スキルのname/descriptionだけがシステムプロンプトに載る
  2. スキルが必要と判断されたとき、初めてSKILL.md本文が読まれる
  3. 参照ファイルは、さらに必要になった時点でエージェントが自分で辿る

同梱スクリプトはbashで実行されるため、コード自体はコンテキストに載らず、出力だけがエージェントへ入力され、トークンを消費します。この3段階の読み込みとトークン数の目安は、Anthropicの公式ドキュメントに載っています。スキルを書く人に有用な情報がまとまっているので、一読をおすすめします。

正直、Anthropicのドキュメントの品質が高すぎて、これらを読めば十分だと思います

https://platform.claude.com/docs/en/agents-and-tools/agent-skills/overview
https://platform.claude.com/docs/en/agents-and-tools/agent-skills/best-practices

ここで注目したいのは、公式のベストプラクティスが、書き方のTips以上に「作る順番」を規定していることです。公式が示す手順は次の通りです。

  1. Identify gaps: スキルなしでClaudeを代表的なタスクで走らせ、具体的な失敗や不足しているコンテキストを記録する
  2. Create evaluations: そのギャップを検証する3つのシナリオを作る
  3. Establish baseline: スキルなしでのClaudeの性能を測定する
  4. Write minimal instructions: ギャップに対処し評価をパスするための最小限のコンテンツを作成する
  5. Iterate: 評価を実行し、ベースラインと比較して改善する

ドキュメントには「広範なドキュメントを書く前に評価を作れ（Create evaluations BEFORE writing extensive documentation）」と明記されています。さらに Anthropicのエンジニアリングブログ では、タスクを進めている最中のClaude自身に、成功したアプローチとよくある失敗をスキルへ蒸留させることを推奨しています。

タスクを走らせて経験を集め、評価で測り、ギャップを埋める編集をして、また測る。公式ガイドはすでに、訓練ループの形をしています。2026年の研究群がやっているのは、このループの各部品の自動化です。

論文は、訓練ループを実行する各部品に分解できる

スキル自動最適化を扱う2026年上半期の論文は、手法名もフレームワークもバラバラですが、どれも深層学習の訓練ループと大きな流れは変わっていないように見えます。

訓練データをモデルに流し、出力の悪さを損失関数で測り、損失が減る方向の勾配で重みを少しずつ更新する。1回の更新幅は学習率で抑え、検証データで過学習を監視する。スキル最適化の研究群は、この訓練ループの部品を1つずつ、次のように置き換えています。

  • 学習するパラメータは、SKILL.md
    • モデルの重みは一切更新せず、スキル文書だけを書き換えていきます。
  • 訓練データは、エージェントの実行トラジェクトリ（実行軌跡）
    • 人が用意したお手本ではなく、エージェントがタスクを実行した成功・失敗の記録から学びます。
  • 損失関数は、検証信号
    • 書き換えたスキルが前より良いか悪いかをスコア付けします。正解データがあるとは限らないため、ここが一番設計の難しい部品です。
  • 勾配と学習率は、テキスト編集とその量の制御
    • 「この失敗を防ぐには、この手順を足すべきだ」という編集の向きが勾配に、1回の更新で許す編集量の上限が学習率にあたります。
  • 過学習（過適合）の監視は、編集の採否判定
    • 提案された編集を無条件には取り込まず、評価が改善したときだけ採用します。

こうして並べると、データを集め、損失を定め、検証しながら更新するという、機械学習・深層学習で長く続いてきた流れと大きくは変わりません。変わったのは、更新の対象が重みではなくテキストになったことです。

ただし、この対応付けは論文群を読むための私の整理で、実際に勾配を計算しているわけではありません（後述するSkillOptとSkillGradは、論文自身がこの比喩を使っています）。以降の章では、訓練データ、損失関数、勾配と学習率の順に、部品ごとの代表的な論文を見ていきます。

なお、このループの外側にもう1つ、推論時にどのスキルを読み込むかというルーティングの論点があります。SkillRouter: Skill Routing for LLM Agents at Scale は、スキルが約8万件の規模ではどれを使うかの選択自体が問題になり、ルーティング側がname/descriptionしか見られない設定では精度が31〜44ポイント低下すると報告しています。descriptionを磨くだけでは足りないという興味深い示唆ですが、本記事ではスキルの改善に絞ります。

スキルはトラジェクトリから蒸留する

まず、訓練データです。研究群が共通して選んだデータソースは、人間が書いたドキュメントではなく、エージェント自身の実行トラジェクトリでした。

その代表が Trace2Skill: Distill Trajectory-Local Lessons into Transferable Agent Skills です。簡単に流れを書くと、次のようになります。

  1. タスクを走らせて、成功・失敗のラベル付きトラジェクトリを集める
  2. トラジェクトリごとに割り当てたサブエージェントが、エラー分析・成功分析を行い、独立に編集パッチ（「この手順を足す」「この記述を直す」のような、スキルへの修正案）を提案する
  3. 大量のパッチを階層的にマージし、単一のスキルディレクトリ（SKILL.md＋参照ファイル）に統合する


図1: Trace2Skillの3段階パイプライン。トレースごとに独立にパッチを提案し、マージで統合する。出典: Trace2Skill (arXiv:2603.25158), Figure 2

重要なのはマージの基準です。独立したパッチの間で繰り返し現れる編集を「そのタスク領域に共通する性質の証拠」とみなして残し、一度しか現れない修正は捨てます。個別トラジェクトリの偶然に過適合しないための、正則化に相当する考え方です。

もう1つの売りは、蒸留したスキルがモデルをまたいで使い回せることです。Qwen3.5-35Bのトラジェクトリから作ったスキルが、より大きいQwen3.5-122BのエージェントをWikiTableQuestionsで最大57.65ポイント改善したと報告されています。モデルの蒸留では大きいモデルを教師にして小さいモデルを学習させるのが（恐らく）普通なので、小さいモデルの経験が大きいモデルを強くするのは一般的な蒸留とは逆向きの結果です。ただしこれは「最大（up to）」の値で、1ベンチマークでの自己報告です。論文自身も、この転移は「しばしば成立する（often transfer）」とヘッジしています。

ただ、出来上がったスキルそのものの品質は、ここまで直接は測られていません。Trace2Skillのマージ基準は「繰り返し現れる編集を残す」という間接的なフィルタですし、転移の数値も、ベンチマークを走らせて初めて分かる事後の結果です。この品質の確認を生成の段階に組み込んだのが MIND-Skill: Quality-Guaranteed Skill Generation via Multi-Agent Induction and Deduction です。成功トラジェクトリからスキルを抽象化する帰納エージェントに、逆向きの検証をする演繹エージェントを組み合わせます。演繹エージェントは、出来上がったスキルだけを頼りに元のトラジェクトリをなぞり直し、その出来を3つの観点で採点します。

  • 再構成損失
    • スキルに従った実行が、元のトラジェクトリの手順をどれだけ再現できたか
  • 結果損失
    • 再現した実行が、元のタスクの正しい結果にたどり着けたか
  • ルーブリック損失
    • スキル文書自体の品質と抽象度が、採点基準（ルーブリック）を満たしているか

「損失」と呼ばれていますが、実体はLLMジャッジによる0〜10のスコアで、形式的な保証ではありません（全く余談ですが、LLMに0~10のスコア付けをするのはおすすめしません。私は0~10のスコア付けで品質の高いLLM-as-a-judgeを構築できた試しがありません）。このスコアを TextGrad で最適化した結果は、Qwen3.5-122B-A10BでAppWorldとBFCL-v3の平均59.1で、ベースラインのACE（56.1）やTrace2Skill（55.1）を上回ったと報告されています。

「要約して終わり」ではなく「そのスキルだけで元の仕事を再現できるか」を確かめる発想は、手で書いたスキルのレビューにもそのまま使えます。書き上げたスキルだけを渡された別セッションのエージェントが、元のタスクをやり直せるか。私はこの観点でスキルを見直したことがありませんでした。

正解がなくても検証信号は作れる

来ました、最難関手順の検証信号（評価）についてです。
検証信号の設計には、2つの壁があります。評価用の正解データが潤沢にある業務は多くないこと。そして、正解があっても、最適化ループの中でそのまま使い続けると、スキルが評価セットに過適合することです。前回の記事で触れた、評価への情報リークと同じ問題がここでも顔を出します。

この2つの壁に対する研究群の答えは、共通して「正解を最適化ループから隔離し、正解の代わりになる検証信号を自作する」です。この章では、代用品の作り方が対照的な2本を見ていきます。

正解データがないという1つ目の壁に正面から答えたのが、CoEvoSkills: Self-Evolving Agent Skills via Co-Evolutionary Verificationです。スキル生成器と並んで、Surrogate Verifier（代理検証器）というもう1つのエージェントを置き、両者を共進化させます。強化されるのは、スキルとテストスイートの両方です。

  • 生成器は、スキルを強化する
    • 検証器が自前のテストスイートでスキルの出力を採点し、どこが落ちたか・どう直すべきかの診断を返します。生成器はこの診断をもとにスキルを改修します。
  • 検証器は、テストスイートを強化する
    • 正解のテストデータは、生成器からも検証器からも隔離されていて、どちらもその内容や期待値を見られません。節目ごとにテストが実行されますが、返ってくるのは最終的に合格したか否かだけです（論文はこの採点役をground-truth oracleと呼びます）。検証器は「自分は合格と判断したのに、テストは落ちた」という不一致を、自分のテストがまだ甘い証拠として使い、テストスイートを難しくしていきます。

テストが難しくなるほど診断の質が上がり、スキルも良くなる。この噛み合いが共進化です。報告値では、Claude Opus 4.6でpass rate 71.1%に到達し、スキルなしの30.6%、人手作成スキルの53.5%を上回りました。進化は最大5ラウンドで、実測では正解テストの実行は平均約2.4回とのことです。


図2: CoEvoSkillsの共進化ループ。正解テスト（oracle）が返すのは右上のpass/fail信号だけ。出典: CoEvoSkills (arXiv:2604.01687), Figure 3

OpenSkill: Open-World Self-Evolution for LLM Agents は別解です。検証器を育てる代わりに、テストの根拠になる事実を外の世界から取ってきます。流れは3段階です。

  1. ドキュメント・リポジトリ・Webからタスクに関連する知識を集める。このとき、正解を知らなくても真偽を確かめられる事実（公式ドキュメントに書かれた参照値、有名データセットの既知の統計量など。論文はverification anchor・検証アンカーと呼びます）も一緒に集める
  2. 検証アンカーから「出力はこの参照値と一致しているか」のような、合否を機械的に判定できる仮想テストを組み立て、合格するようにスキルを直していく
  3. 仕上がったスキルを、それまで隠しておいた正解テストで最終評価する


図3: OpenSkillの全体像。左下の正解テストは進化中はアクセスできず、右端の最終評価で初めて解錠される。出典: OpenSkill (arXiv:2606.06741), Figure 2

ループが回るのは2の中です。仮想テストに落ちると、どのテストに落ちて、原因は実装のミスか知識の不足か、という診断を自然言語で作り、それをもとにスキルを直してまた実行します。反復は既定で最大3ラウンドです。診断が「知識の不足」を示したときだけ、1に戻って追加の検索をします。正解データをスキルの改善に使わない建て付けを守るため、正解が登場するのは3の最終評価だけです。SkillsBenchでは自動手法の中で最良のpass rate（Claude Opus 4.6で43.6%、GPT-5.2で42.1%）と報告されていますが、人手で作り込んだスキル（44.5%と44.8%）には届きません。

OpenSkillで注目すべきは、2の反復回数を変えた実験です。SocialMazeでは反復3回がピーク（82.7%）で、5回では79.9%、10回では78.0%へ劣化しています。正解データを改善に使わない建付けで実施しているにもかかわらず、ループを回せば回すほど性能が落ちています。
これは、自作の検証信号の品質が問題で（検証器のPrecisionは約57%）、精度が落ちているらしいです。そのため、（当たり前ですが）ループを回す際の検証器の品質は非常に重要になってきます。

では、この仕組みは自分の仕事にも使えるのでしょうか。たとえば私が強化したいのはブログ執筆のスキルで、この分野に正解データがないとします。上記で紹介した設計を当てはめてみると、必要な部品が見えてきます。CoEvoSkills型なら、節目に合否だけを返す採点役が要ります。ブログでは、「公開してよい出来か」を判定する筆者自身がこれにあたります。OpenSkill型なら、機械的に真偽を確かめられる検証アンカーが要ります。「1文が100字を超えていない」「見出しが体言止めになっていない」のような文体ルールはアンカーにできます。ここまでは自動化のループに乗ります。乗らないのは「読んで面白いか」のような機械的に判断するのが難しい部分です（そして、ここの評価が一番大事！）。結局、機械的な判定に落とせないドメインロジックの評価は、この研究群をもってしても自動化できておらず、課題として残り続けます。その判定を曖昧なままループに入れると何が起きるかは、先ほどの反復劣化が示している通りです。

SKILL.mdを、テキスト空間の勾配降下で更新する

残る部品は勾配と学習率です。

Microsoftと上海交通大学らのグループによる SkillOpt: Executive Strategy for Self-Evolving Agent Skills の問題意識は、今のスキルの作られ方にあります。人が手で書くか、LLMに一発で生成させるか、LLMに自由に書き直させるか。どのやり方でも、書き換えた後のスキルが書き換える前より良くなる保証はありません。そこでSkillOptは、モデルの重みを訓練するときと同じ規律を、スキル文書の書き換えに持ち込みます。エージェントのモデル自体には一切手を付けず（論文はこれを「凍結」と呼びます）、スキル文書を唯一の学習パラメータとして扱います。流れは次の通りです。

  1. モデルが現行スキルでタスクを実行し、スコア付きのトラジェクトリを得る
  2. 別に用意したoptimizer役のモデルが、成功・失敗のトラジェクトリを分析し、スキル文書への編集（追加・削除・置換）を提案する
  3. 編集をマージして有望な順に並べ、上限数まで取り込んだ候補スキルを作る
  4. 訓練に使っていない検証タスクで候補を評価し、スコアが厳密に改善したときだけ採用する（同点でも棄却）


図4: SkillOptの全体像。右側に「parameter→skill document、learning rate→edit budget」の対応表がそのまま載っている。出典: SkillOpt (arXiv:2605.23904), Figure 1

この論文では、深層学習の最適化器のアナロジーを徹底しています。1ステップで許す編集数の上限はtextual learning-rate budget（テキスト学習率予算）と呼ばれ、既定では学習率スケジューラー（コサインスケジュール）で減衰します。序盤は大きく書き換え、終盤は細かい統合に移る、という制御です。棄却された編集は捨てずにバッファへ貯めて、後の提案に活かします。さらに、ステップ単位の細かい編集とは別のレイヤーとして、slow/meta updateという仕組みがあります。エポック（訓練タスクひと巡り）の終わりに、同じタスクを前のエポック時点のスキルと現在のスキルの両方で実行し直し、結果を「改善」「悪化」「ずっと失敗」「安定して成功」の4群に分類します。そこから読み取れる長期的な方針を、スキル文書内の保護された欄に書き込みます。この欄はステップ単位の編集では上書きできないため、目先の失敗への対処で長期的な学びが消される事故を防げます。

もう1つ実務的なのは、最適化がすべて事前の訓練フェーズで完結することです。成果物は訓練済みのスキル文書1枚で、本番のエージェントはそれを読み込むだけです。推論のたびにoptimizerモデルを呼ぶ必要はありません。実装は GitHubで公開されています。

同時期の SkillGrad: Optimizing Agent Skills Like Gradient Descent は、このアナロジーをさらに進化させたものになります。SkillOptとの違いは2つです。

  • 更新の対象が、1枚のMarkdownファイルからスキルフォルダ全体に広がる
    • スキルフォルダを、メタデータ（呼び出し判断に使う）・SKILL.md本文（常に読まれる）・参照リソース（必要時だけ読まれる）の三層に分けて扱います。最初の章で説明した3段階読み込みと同じ構造です。修正を提案するだけでなく「どの層に書き込むか」まで判断し、全タスクに共通する手順はSKILL.md本文へ、特定ケース向けの詳細は参照リソースへ、と振り分けます。
  • 繰り返し現れる失敗パターンを、momentumとして持ち越す
    • 毎回の診断を使い捨てにせず、反復をまたいで繰り返し現れるパターンを永続メモリに蓄積し、次の編集の判断材料にします。勾配の移動平均で更新方向を安定させる、momentumのテキスト版です。

SkillOptが学習率と検証ゲートを持ち込んだとすれば、SkillGradはmomentumとパラメータの層構造まで揃えた形です。


図5: SkillGradの最適化ループ。実行→損失証拠→診断→momentum→layer-awareなパッチ適用を反復する。出典: SkillGrad (arXiv:2605.27760), Figure 1

ただし、1つ注意があります。SkillOptもSkillGradも、評価に使用しているのはベンチマークの正解データです。SkillOptのスコアは正解率などベンチマーク固有の指標で、採否の判定も、訓練に使っていない検証タスクでのスコアです。SkillGradの報酬も、ベンチマークタスクの成否です。つまりこの2本は 「正しく採点できる環境」 を前提に置いたうえで、更新の規律を設計しています。個人的に実務では、こちらの「正しく採点出来る環境」を作るのが一番大変なのですが、この部分は未解決のままです。結局、一番設計が難しい部品は検証信号だ、という前章の話に戻ってきます。

そもそもスキルは効いているのか

最後に、そもそもスキルを持たせること自体に効果はあるのか、という問いに触れておきます。ここには、冷や水をかける報告があります。SWE-Skills-Bench: Do Agent Skills Actually Help in Real-World Software Engineering? は、公開されている49本のソフトウェアエンジニアリング向けスキルを、実GitHubリポジトリ由来の約565タスクで評価しました。結果、49本中39本は、スキルを渡してもpass rateが上がりませんでした。49本全体で平均しても、改善はわずか+1.2%です。はっきり改善した（最大+30%）のは特定用途に特化した7本だけで、残る3本はむしろ性能を最大10%劣化させています。

私はこれをスキルが不要という話ではなく、本記事のループの必要性を裏付ける結果として考えています。評価なしで（思い思い）書かれたスキルの大半は、おそらく「効果ゼロの39本」側に入ります。実際に効果のある7本を見分ける（作成する）手段が評価であると考えています。書いたスキルが効いているかを一度も測ったことがないなら、測るところから始める価値があります（何度も言いますが、これが難しいんですけどね...）。

おわりに

ここまで見てきた通り、SKILL.md（あるいはスキルに使用するスクリプト等を含むディレクトリ）は、書いて終わりの文書ではなく、訓練ループの中で更新され続けるパラメータと捉えられています。訓練データはエージェントのトラジェクトリ、損失関数は検証信号、勾配はテキスト編集。そして全手法に共通するのは、生成した編集をそのまま採用せず、必ず検証と検証結果による更新を挟む設計でした。

同じループを手で回してみたい人には、Anthropicが公開している skill-creator が参考になります。何をスキルに昇格させるかの判断基準が具体的に書かれています。繰り返し現れる行動だけを昇格させる、Trace2Skillのマージ基準と同じ発想です。

今回の調査を通して、結局評価の問題は解決出来なかったのですが、もうこれは誰も汎用的に解けていない人間に残された最後の仕事かもしれませんね。まだ仕事は残りそうで良かった。

最近話題のFDE(Forward Deployed Engineer)やLayerXについて興味のある方は是非以下のサイトからカジュアルにお話しましょう！

https://jobs.layerx.co.jp/opendoor/2d3cdd370bae8051a659fdd1dbd9d595/

References

LayerX
LayerXPublication

すべての経済活動を、デジタル化する。SaaS + Fintech に取り組む LayerX のエンジニアの記事が集まる Publication です。

Discussion