
エージェントにスキルを持たせる運用が広がっています。作業手順をSKILL.mdにまとめて渡しておけば、毎回ゼロから試行錯誤させるより安定して動きます。この形式を日々の業務に組み込んでいるチームも増えてきました。
そうなると次は、スキルを書く作業そのものを自動化したくなります。社内のリポジトリや分厚いマニュアルをAIに読み込ませ、手順書を抽出させてみたとします。出てきたスキルは見出しが整い、参考資料も添えられており、一見すると申し分ありません。ところが、それをエージェントに渡して動かしてみると、成功率が思ったほど上がりません。それどころか、スキルなしで動かしたときより成績が下がる場面さえあります。
見た目が整ったスキルと、実際に機能するスキルのあいだには、想像以上の距離があるようです。本記事では、スキルの自動生成を正面から測定した検証をもとに、生成スキルが役立つ条件と壊れ方のパターンを紹介します。
LLMエージェント向けスキル生成パイプラインのベンチマーク「SkillGenBench」
SkillGenBench: Benchmarking Skill Generation Pipelines for LLM Agents
| 著者 | Yifan Zhou, Zhentao Zhang, Ziming Cheng |
|---|---|
| URL | https://arxiv.org/abs/2605.18693 |
スキルは「使う」だけでなく「作らせる」対象になった
スキルとは、特定の作業のやり方をマークダウン形式の手順書にまとめ、補助スクリプトや参考資料とともにフォルダごとエージェントに渡す仕組みです。プロンプトに毎回知識を詰め込む方法と違い、保存して使い回せるうえ、監査や共有、バージョン管理もしやすくなります。エージェント開発の現場では、手順知識の置き場所としてこの形式が急速に定着してきました。
ただし、スキルを人手で書き続けるのは負担の大きい作業です。新しいライブラリが出るたび、マニュアルが改訂されるたびに、手順の知識は古びていきます。リポジトリやドキュメントからスキルを自動生成するツールが相次いで公開されている背景には、この維持コストを下げたい需要があります。
一方で、楽観できない観測も先行して報告されてきました。スキルの利用効果を測った先行の検証(SkillsBench)では、人が丁寧に整備したスキルは成績を押し上げる一方、自動生成されたスキルは挙動が不安定で、性能を下げる場合すらあると示されています。文脈の中に答えの手がかりが明示されていても、モデルがそれを正しい手順に変換し損ねる頻度が高いという報告(CL-Bench)もあります。知識を抽出して手順に落とす工程そのものが、どうやら難所になっています。
こうした問題意識から、スキルの生成能力だけを取り出して測るベンチマークが新たに構築されました。名前はSkillGenBenchで、コードも公開されています。設計の肝は、生成と実行の分離にあります。スキルを書く側のモデルと、書かれたスキルを使って課題を解く側のモデルを別々に用意し、実行側を1つのモデル(MiniMax-2.5)に固定する構成です。実行側の能力が一定なら、成績の差はスキルの質の差として読めます。生成側にはClaude Sonnet 4.5、GPT-5、Kimi K2.5、GLM-5、MiniMax M2.7、Qwen3.6 Plusの6モデルが使われ、いずれも同じエージェント実行環境(Claude Code)経由で動作します。

生成の状況を2つの軸で切り分けた設計
スキルを作る状況は、2つの軸で整理されています。
1つ目の軸は生成のタイミングです。解くべき課題が先に明かされ、それに合わせてスキルを作る「タスク条件付き」と、課題を知らされないまま素材だけからスキル集を作り置きし、後から明かされる課題に流用する「タスク非依存」に分かれます。前者は的を絞って蒸留する力を、後者は使い回しに耐える抽象化の力を測ります。実務でいえば、案件が来てからスキルを書くか、ナレッジベースとして先に整備しておくかの違いに対応します。
2つ目の軸は知識の出どころです。コードリポジトリを素材とする課題では、手順が明文化されておらず、ディレクトリ構成や設定ファイル、エントリスクリプトの中に暗黙的に埋まっています。長文ドキュメントを素材とする課題では、手順自体は明文化されているものの、条件分岐やパラメータの決まりが文書のあちこちに散らばっています。前者には掘り起こす作業が、後者にはかき集めて統合する作業が求められる構図です。
課題は全部で187問あり、画像処理、音声、推論、Web操作など9つの領域にまたがります。いずれもコンテナ化された環境で実行され、隠しテストケースとの照合や成果物の比較によって機械的に採点されます。見逃せないのは課題選別の厳しさです。素材を読まなくても2割以上の確率で解けてしまう課題や、素材を丸ごと渡せば半分以上解けてしまう課題は弾かれ、678個の候補のうち187個だけが残されました。スキルの出来が成績を左右する課題だけが採用されている、と読める構成です。

採点にはpass@3という指標が使われます。生成されたスキルを使って最大3回試行し、1回でも検証を通れば成功とみなす方式です。
比較されたのは性格の異なる5つの生成方式
生成パイプラインとして、作り方の発想が異なる5方式が比較されました。いずれも同じ素材を受け取り、同じ形式のスキルパッケージを出力します。
| 方式 | スキルの作り方 |
|---|---|
| Naive Prompt | 素材を読ませて一度の生成でスキルを書かせる最小構成 |
| SkillNet | 専用のスキル作成ツールキットを介して素材を変換する |
| SkillSeekers | ドキュメントやリポジトリをスキルへ変換する公開パイプライン |
| SkillCreator | 下書きと自己評価を繰り返して練り上げるAnthropic公式のスキル作成エージェント |
| EvoSkill | スキルなしで実行した記録を渡し、経験から手順を抽出させる |
ベースラインとして、スキルを一切渡さない素の条件も同じ実行モデルで測定されています。生成スキルの価値は、この素の成績との差分で判断される建て付けです。
平均ではスキルなしを上回れない方式が大半だった
6つの生成モデルで平均した成績がこちらです。数値はpass@3の達成率で、リポジトリ由来とドキュメント由来に分けて示します。
| 方式 | リポジトリ由来 | ドキュメント由来 |
|---|---|---|
| スキルなし | 13.8% | 23.4% |
| Naive Prompt | 12.2% | 21.9% |
| EvoSkill | 10.8% | 23.2% |
| SkillNet | 12.5% | 21.4% |
| SkillCreator | 12.2% | 22.9% |
| SkillSeekers | 14.4% | 25.0% |
両方の素材でスキルなしを上回ったのは、5方式のうちSkillSeekersだけでした。それも、リポジトリ由来で13.8%から14.4%へ、ドキュメント由来で23.4%から25.0%へという小幅な上積みにとどまります。残る4方式は平均するとスキルなしと同等か、それ以下でした。スキルを渡したせいで成績が落ちる逆転は、例外的な事故ではなく平均値として現れています。なお絶対値が全体に低く見えるのは、素材を読まなければ解けない課題だけを残した選別の結果でもあります。
成績を下げる典型は、生成されたスキルが誤った前提、不完全な手順、実態と食い違う入出力仕様を含む場合だと分析されています。中途半端な手順書は、実行側モデルが元々持っている知識と衝突し、かえって判断を迷わせます。逆に、実行側が自力では推測できない、素材に固有の正確な手順を含むときに限り、スキルは成績を押し上げていました。
素材による難易度の開きも目を引きます。ドキュメント由来の成績が21〜25%で推移するのに対し、リポジトリ由来は11〜14%にとどまりました。環境構築、コマンドの作法、データの流れといった実行の構造がコードのあちこちに暗黙的に散らばっており、それを文章として掘り起こす難しさの表れだと解釈されています。
生成モデル別に見ると順位は入れ替わります。多くのモデルでSkillSeekersが最上位に立つ一方、SkillNetはQwen3.6 Plusとの組み合わせで20.3%の首位となり、SkillCreatorはGLM-5でほぼ同水準に並びました。また、187問という規模では95%信頼区間が±5ポイント前後あり、方式間の差の多くは統計的に判別しきれない水準だという留保も示されています。順位の細部より、全体としてスキルなしを安定して超えられていないという大きな構図のほうが、確かな読み取りどころになります。
作り置きのスキル集はさらに分が悪かった
課題を知らされる前にスキル集を作り置きするタスク非依存の設定では、成績がさらに沈みました。リポジトリ由来の課題で2つの生成モデルを使った比較では、課題を知ってから作れば16.3%だった方式が作り置きでは13.8%まで落ち、スキルなしの水準と並びます。一度の生成で書かせる方式に至っては12.2%と、スキルなしを下回りました。

課題の手がかりなしに素材だけを渡された生成側は、後で何が問われるかを推測しながら、汎用的に使えそうな手順を選んで抽象化するしかありません。その過程で、実行に不可欠な細かい制約が削ぎ落とされます。構造としてはもっともらしいのに実行要件と噛み合わないスキルができあがる、というのが作り置きに固有の失敗パターンだと分析されています。
生成側に与える思考の予算を増やせば解決する、という話でもありません。生成時のトークン上限を2Kから128Kまで動かした実験では、16K〜24Kあたりまで成績が急伸した後、32K〜64Kで頭打ちになり、それ以上はほぼ伸びませんでした。長く考えさせれば良いスキルになるという関係ではなく、何を書き留めるべきかを掴めるかどうかが成績を分けています。
失敗の中身は素材の種類でほぼ決まっていた
スキルを使って答えを出したのに検証で弾かれた事例を分類すると、素材ごとにまったく違う顔ぶれが現れました。数値は、検証不合格となった事例に占める割合です。
| 失敗の種類 | リポジトリ由来 | コード文書由来 | ドメイン知識文書由来 |
|---|---|---|---|
| 実行環境や依存関係 | 53% | 11% | 0% |
| 入出力の形式やスキーマ | 27% | 85% | 15% |
| 素材や成果物の扱い | 20% | 4% | 4% |
| 数値や数式の誤り | 0% | 0% | 37% |
| ルールや状態の扱い | 0% | 0% | 44% |

リポジトリ由来の失敗は、半分以上が実行環境と依存関係のつまずきでした。ライブラリの導入手順、コマンドの組み立て、ファイルの置き場所といった運用上の作法を文章に起こせていないスキルは、中身の理解が正しくても動きません。コード文書由来では、失敗の85%が入出力の形式の不一致に集中しています。APIの引数名や返り値の構造、出力ファイルの命名といった細部を一字一句の精度で転記できるかが勝負どころです。ドメイン知識文書由来では、ルールの適用ミスと数値の誤りで8割を占めました。しきい値や係数、条件分岐の優先順位を丸めずに書き留める正確さが問われる領域です。
レビューすべき場所が素材によってここまで違うなら、生成スキルの検品も一律のチェックリストでは機能しないと言えます。
成績を動かしたのは推測できない固有の事実
具体的な課題を見ると、スキルが価値を持つ条件がはっきりします。画像をアニメ調に変換するライブラリ(AnimeGANv3)を扱う課題では、内部の色チャンネルの並びが一般的なRGBではなくBGRで、専用の変換処理を挟まないと暖色と寒色が反転した画像が出力されます。合成データ生成ライブラリ(Faker)の課題では、ユーザー名の重複を防ぐには通常のメソッドではなく重複防止用のプロキシを経由する決まりがあり、出力を再現するにはクラスレベルのシード設定を生成より前に済ませる必要があります。PDF解析ライブラリ(PDFPlumber)の課題でも、単語の数え方ひとつで、テキストを空白で区切る素朴な実装と専用メソッドとでは数字が食い違います。
どれも、ライブラリ名から常識的に推測しても辿り着けない仕様です。モデルが自力で補えない固有の事実を正確な形で含むスキルだけが、成績を動かしていました。裏を返せば、どこにでも書いてある一般論を並べただけのスキルは、コンテキストを消費するだけで成果に結びついていません。
体裁の良さと実行の成功は別の能力だった
生成されたスキルそのものを静的に採点する診断も併用されました。入出力契約の明示、環境構築の記述、素材への参照、手順の網羅性、制約の保持、簡潔さといった観点を、ルールベースで機械的に確かめる方式です。
すると、実行成績と静的スコアの順位が一致しませんでした。実行成績で首位だったSkillSeekersは、静的診断では手順の網羅性や制約の保持が最低水準です。逆に、静的診断で最も整っていたSkillNetは、実行成績では平均してスキルなしを下回りました。仕様として何を書くべきかを網羅する力と、実行環境で実際に通る手順を書く力は、別物だという示唆です。体裁を整えただけのスキルは動かず、動いたスキルが整っているとも限りません。スキル生成の本丸は、仕様の記述と実行の現実をつなぐ部分にあると結論づけられています。
生成スキルを運用に乗せる前のチェックポイント
ここまでの結果は、スキルの自動生成を見送る理由としてではなく、導入時の検品方法を組み立てる材料として読めます。
スキルなしとの比較を必ず取る
整って見えるスキルでも、平均すれば素の状態に負ける方式が大半でした。生成したスキルを採用する前に、同じタスクをスキルなしで走らせた数字と突き合わせる手順が、負の転移を防ぐ最低限の検品になります。静的スコアと実行成績が一致しなかった結果を踏まえると、体裁のレビューだけで合格を出す運用は危ういと考えられます。
素材の種類でレビューの目を切り替える
リポジトリから作ったスキルなら、依存関係の導入手順と実行コマンドが最初の確認点です。失敗の53%がそこに集中していました。API文書から作ったなら、引数名や入出力スキーマの転記精度を疑います。失敗の85%が形式の不一致でした。業務マニュアルや規程類から作ったなら、しきい値や条件分岐の数値を原典とひとつずつ照合します。誤りの8割がルールと数値に由来していました。
一般論を削り、固有の事実が残っているかを見る
成績を動かしたスキルは、色チャンネルの並びやシード設定の順序のような、モデルが推測しようのない事実を正確に含んでいました。レビューの際は、検索すればすぐ出てくる一般的な手順を削り、その素材からしか得られない決まりごとが残っているかを基準にすると、分量と効果の両面で引き締まります。
作り置きの汎用ライブラリは小さく始める
課題が見える前にまとめて生成したスキル集は、課題を知ってから作るスキルに届かず、素の成績すら下回る場合がありました。ナレッジベースの一括生成は構想として魅力的ですが、現状の生成パイプラインには荷が重い設定です。まずは案件単位で生成し、実績の出たスキルだけを共有ライブラリへ昇格させる運び方が手堅いと考えられます。
生成に予算を積むより情報の質を変える
トークン上限を引き上げても、成績の伸びは32K〜64Kで頭打ちになりました。生成の思考量を増やすより、実行テストの結果を生成側に戻す、環境情報を機械的に収集して渡すといった、書く材料の質を変える工夫のほうに伸びしろがあると考えられます。
まとめ
スキルの生成は、生成方式だけで決まる問題ではなく、生成モデル、実行モデル、素材の性質が絡み合うパイプライン全体の問題だという見立てが、検証を貫く結論です。リポジトリからの生成は実行構造の掘り起こしで、文書からの生成は細部の転記精度でつまずきます。そして、仕様として整ったスキルと実行を通るスキルのあいだには、一貫した隔たりがありました。
限界も明示されています。187問という規模では信頼区間が±5ポイント前後あり、方式間の優劣の多くは確定的とは言えません。実行側モデルが1つに固定されている点や、静的診断がルールベースの代理指標にとどまる点も、結果を広く一般化する際の留保になります。
とはいえ、実務側の指針としては具体的です。実行による検品、素材別のレビュー観点、案件単位での育成という型を先に持っておけば、自動生成の恩恵を取りこぼしにくくなります。スキルを書かせる時代は、スキルを検品する技術とセットで進んでいきそうです。
本記事の関連研究