- 大規模言語モデル（LLM）ベースのエージェントにおける**スキル（Agent Skills）**の効果を定量的に評価するための初のベンチマークで、11分野84タスクを含む
- 各タスクはスキル未適用、キュレーション済みスキル適用、自己生成スキル適用の3条件で評価され、合計7,308件の実行軌跡が収集された
- キュレーション済みスキルは平均**+16.2ポイントの性能向上**を示したが、分野ごとの差が大きく、一部タスク（84件中16件）ではかえって性能が低下した
- **自己生成スキル（Self-generated Skills）**は平均的に効果がなく、モデルが手続き的知識を自力で安定して生成できないことを示した
- **小さく集中したスキルモジュール（2～3個構成）**は包括的な文書型スキルより効率的であり、スキルを活用した小型モデルがスキルなしの大型モデルと同等の性能を達成した
SKILLSBENCH 概要
- SKILLSBENCHは、LLMエージェントのスキル強化効果を評価するためのベンチマークで、Harborフレームワークを基盤に構築されている
- 各タスクにはコンテナ環境、決定論的バリデータ、参照解答（oracle）が含まれる
- スキル適用の有無によって同一タスクを繰り返し実行し、スキルの純粋な効果を測定する
- 既存のベンチマークがモデルの基本能力のみを評価していたのに対し、SKILLSBENCHはスキルが性能に与える影響を直接測定する
スキル（Agent Skills）の定義と構成
- スキルは**手続き的知識（procedural knowledge）**を含む構造化パッケージであり、モデルを改変せずに推論時点でエージェントの行動を拡張する
- 構成要素:
SKILL.md（タスクへのアプローチ手順）、実行可能スクリプト、コードテンプレート、例など
- スキルは次の4つの基準を満たす必要がある
- 手続き的内容を含むこと
- 単一事例ではなくタスククラス単位で適用できること
- 構造化された構成要素を含むこと
- ファイルシステムベースで移植性を確保すること
- システムプロンプト、few-shot例、RAG検索、ツールドキュメントはスキルとは見なされない
タスク構成とデータセット構築
- 各タスクは指示文、環境、解答、バリデータの4要素で構成される
- 環境はDockerコンテナで隔離され、再現性を保証する
- バリデータは決定論的なテストスクリプトで、合格/不合格を自動判定する
- 105人の貢献者が322件の候補タスクを提出し、自動検証と人手レビューを経て最終的に84タスクが選定された
- 貢献者は次の要件を満たす必要がある
- 人間が作成した指示文（LLM生成は禁止）
- スキルは特定タスクの解答ではなく手続き的ガイダンスを提供すること
- すべての検証は**決定論的（assertionベース）**な方式で行うこと
- 自動構造検証、オラクル実行、AI生成検出、リーク監査を通過すること
- リーク防止のため、スキル内にタスクごとのファイル名、定数、テスト参照などが含まれる場合は却下される
ベンチマーク構成と難易度分類
- SKILLSBENCHは**11分野（ソフトウェア、ヘルスケア、金融、ロボティクスなど）**の84タスクで構成される
- 難易度は人間の作業時間を基準に3段階に分けられる
- Core（60分未満）17件
- Extended（1～4時間）43件
- Extreme（4時間超）26件
実験設定
- 3種類の商用エージェントハーネスを評価: Claude Code、Gemini CLI、Codex CLI
- 7つのモデルを使用: GPT-5.2、Claude Opus 4.5/4.6、Claude Sonnet 4.5、Claude Haiku 4.5、Gemini 3 Pro、Gemini 3 Flash
- 3条件で評価
- No Skills: スキル未適用
- With Skills: キュレーション済みスキル適用
- Self-Generated Skills: モデルが直接スキルを生成して適用
- 合計**7,308件の有効な実行軌跡（trajectories）**を収集
評価指標
- **通過率（pass rate）**を基本指標として使用
- **正規化利得（normalized gain）**も追加で計算し、絶対的な向上と比率的な向上をあわせて分析
- 各タスクは5回繰り返した後、平均スコアを算出
主な結果
- キュレーション済みスキルは平均**+16.2ポイント向上**で、構成ごとに+13.6～+23.3ポイントの範囲
- 分野ごとの差が大きく、ヘルスケア（+51.9ポイント）で最大の向上、ソフトウェアエンジニアリング（+4.5ポイント）で最小
- 84件中16件のタスクではむしろ性能が低下
- 自己生成スキルは平均的に効果がないか、負の影響を与えた
- モデルは手続き的知識を自力で安定して生成できなかった
- **集中型スキル（2～3モジュール）**は包括的な文書型より高い効率を示した
- 小型モデル＋スキルの組み合わせは、スキルなしの大型モデルと同等の性能を達成した
結論
- SKILLSBENCHはスキル中心の評価体系を提供し、スキルがLLMエージェントの実作業性能に与える影響を定量的に実証する
- 結果は、スキル設計の品質と分野適合性が性能向上に決定的であることを示している
- 今後の研究において、スキルの構造的な設計原則と自動生成の限界を解明するための基礎資料として活用できる
1件のコメント
Hacker Newsのコメント
「Self-Generated Skills」という概念は興味深いが、人々が考える 「LLMが自らスキルを学習する過程」 とは異なる点を指摘したい。
この研究では、単に問題を解く前に関連する手続き的知識を生成するようプロンプトを与えているだけで、実際の 「経験から学んだスキル」 とは隔たりがある。
メディアにはこの違いをきちんと区別して報じてほしい。
LLMが自らスキルを生成するとしても、探索や学習が不可能な構造なので、結局は自分のコンテキストを反復しているにすぎない。
こうした結果を一般化するのは誤解を招きやすい。
すでにモデル内部にある知識なら、わざわざ文書にする必要はなく、本当に表面化しにくい情報であるときにだけ意味がある。
試行前にスキルを作るのは現実離れしたアプローチだ。
エージェントに質問させ、問題解決の過程を経たあと、その結果を 証拠に基づく圧縮されたスキル にまとめる方式が効果的だった。
①失敗の捕捉 → ②原因診断 → ③改善ツールの選定 → ④バージョン管理された成果物として記録 → ⑤必要に応じてゲートへ昇格、という流れだ。
こうしたループをすべてのエージェントの基本指針に含めている。
私は Claude向けのskill-creator を別に作って使っている。
Claudeがすでに知っている情報を再びスキルとして書いてしまうのを防ぐため、文書には必ず
①学習データ外の情報、②現在のセッションにのみ有効なコンテキスト、③未来のClaudeの行動を整合させる情報だけを含めるようにしている。
全文は GitHubリンク にある。
インターネット由来の学習データは品質のばらつきが大きく、モデルが 専門家レベルの選別 をできると期待するのは難しい。
非自明な洞察を含む文章こそが、良いスキルの基準になりうる。
研究結果の中で最も興味深いのは、自己生成スキルは性能を下げ（-1.3pp）、キュレーションされたスキルは大きく向上させる（+16.2pp） という点だ。
これは、LLMは手続き的知識の 消費者 としては優れているが、生産者 としては弱いという仮説と一致する。
特にソフトウェア分野よりヘルスケアで効果がずっと大きいのは、SWEデータがすでに豊富だからである可能性が高い。
たとえば Adobe React Spectrum UI は、スキルなしで使うとひどいが、よく作られたスキルを使うとまったく違ってくる。
単にモデルに「スキルを作れ」と言うだけでは意味がない。
新しい情報や外部資料 で知識を拡張しなければ、結局は自分の出力を再入力する循環にすぎない。
私はスキル生成時に自動でリサーチを行い、最新情報やワークフローに合わせて精製する skill-creator を使っている。
その条件でスキルを作らせるのは無意味だ。
LLMを複数階層で自動化するほど、各段階の品質が落ちる傾向がある。
アイデアと実装計画を人間が握り、LLMがコーディングだけをするなら問題ないが、計画まで任せると急激な 品質低下 が起きる。
要約や再生産を繰り返すうちに、最終的に意味が崩壊してしまう。
一定のタイミングごとに 新鮮な人間の入力 が必要だ。
私は大規模コードベースで、まずLLMに探索レポートを書かせ、新しいセッションでそれを参照しながら作業している。
トークンは多く使うが、重要な細部を見落とさない。
結局のところ重要なのは、モデルに十分な 世界知識 を供給しているかどうかだ。
自然言語は本質的に不安定なので、反復して伝達されるほど歪みが大きくなる。
私たちがこれほどよく意思疎通できていること自体が驚くべきだ。
open loop 構造では精度が落ちるが、各段階が自ら調整できるなら、ずっと安定する。
私は agentic-readyデータウェアハウス（ GitHub.com/mathisdrn/orca ）を作っている。
当初はスキルをベンチマークに最適化しようとしていたが、DsPy や GEPA のように、モデルの言語そのものを評価者兼ビルダーとして使うアプローチのほうが効率的だ。
AnthropicやOpenAIのskill-creatorにも、こうした 自己最適化構造 があるのか気になっている。
この研究は驚くほどでもなく、実務的にも大きな意味はないと思う。
実際には、モデルが 自分の潜在知識だけでスキルを作るケースはほとんどない。
研究はそのような限定条件で実験しているので、結果は当然だ。
もっと面白いのは、モデルが人間にインタビューしたり、ディープリサーチ後にスキルを生成 したりする方式だろう。
むしろこういう論文が出たことのほうが驚きだ。
しかも、この種の研究は「モデルに何の文脈も与えずベストプラクティス文書を書かせる管理者」を防ぐ助けにもなる。
今回の研究はそうした文脈を考慮していない。
最近は、あまりにも多くの賢い人たちがこうした AI論争にエネルギーを浪費 しているように感じる。
昔はただ役に立つソフトウェアを作っていたのに、今では毎週出てくる新しいAIトピックに没頭している。
Web3やJSフレームワーク以上に強力な nerd-sniping効果 がある。
今回の記事も、実質的には予想可能な結果を確認しただけだ。
しかし間もなく新しいモデルが出て、こうした議論自体が無意味になる可能性も高い。
多くのチームは「スキル戦略に切り替えろ」と指示される一方で、その間に新モデルのほうがうまくやってしまう。
結局みな 不安定な生存構造 の中で方向性を見失っている。
私も 自己生成文書の品質低下 をよく目にしてきた。
LLMがコードから「ベストプラクティス」を抽出すると、しばしば誤ったパターンがそのまま文書化される。
たとえば C# コードで
ConfigureAwait(false)やTask.Runが誤用されていたケースがあった。こうした問題に対処するため、私たちは キュレーション済み知識システム を構築中だ。
Markdownベースの agentic coding が次世代の抽象化レイヤーになると信じている。
この特性が全体の動作にどう影響するのか、まだ明確ではない。
投稿されたタイトルが「Self-generated agent skills are useless」だったが、これは HNガイドライン に反している。
元のタイトルを維持し、意見はコメントで表現するのが公正だ。
明確なタイトルのほうがコミュニティに大きな洞察を与えられると思う。
意図はクリック誘導ではなく、核心的な発見を強調 することだった。