Agent Skillsの効果をSkillsBenchが実測 — 最適は3モジュール以下

Agent Skillsを渡すと、エージェントは本当にタスクをうまく解けるようになるのでしょうか。この問いに対照実験で答えたのが、77名の研究者が公開した論文「SkillsBench」です。87個のタスクを18種類のモデル・ハーネス構成で検証したところ、Skillsを与えた場合の平均成功率はSkillsなしの33.9%から50.5%へ上がりました。ただし伸び幅は構成によって大きく違い、Skillの作り方次第では成功率を下げるケースも13タスクで出ています。

SkillsBenchはAgent Skillsをどう測ったのか

Agent Skillsは、Anthropicが2025年10月に公開した仕組みです。指示・スクリプト・参考資料をフォルダにまとめ、エージェントが必要なタイミングで動的に読み込めるようにします。起動時に読み込むのは各Skillの名前と説明文だけで、実際に使うと判断したときだけ本文を読み込む「段階的開示」が土台です。2025年12月18日には、クロスプラットフォームで使える公開標準としてAgent Skillsが公開されました。

SkillsBenchは、この仕組みが実際の作業でどれだけ役に立つかを測るベンチマークです。1,400人規模のコントリビューターのコミュニティと、400件のタスク提案、142人の貢献者を経て、自動チェックと人手レビューで87タスクに絞られました。対象は自然科学・メディア制作・サイバーセキュリティ・産業システム・金融経済・オフィス業務・ソフトウェア工学・数理最適化の8領域です。

手順

1タスクが評価に入るまでの関門

1. 1

   4つの自動ゲート

   構造の整合性、模範解答(オラクル)の実行、指示文の出所、Skillと解答の漏洩を機械的に確かめます。指示文は、AI文章検出と人手ラベルを併用して、すべて人間が書いたものだけに揃えられています。

2. 2

   漏洩の排除

   タスク固有のファイル名・パス・マジックナンバー、オラクルのコマンドそのもの、期待される出力を含むSkillは弾かれます。Skillが答えを丸ごと持つ「隠し解答集」になるのを防ぐ仕組みです。

3. 3

   メンテナーの人手レビュー

   通過したタスクは、メンテナーが30分以上かけてレビューします。Skillありとなしで差が出ないタスクは、情報量が低いとして外されます。

採点も人間ではなく、決定論的なpytestベースの検証スクリプトが行います。同じタスクを同じコンテナ上で、Skillsなしの条件とSkillsありの条件の両方で実行し、成功率の差を測ります。温度は0に固定し、1つの(構成、タスク、条件)につき3回の試行を採点しました。18構成×87タスク×2条件×3試行で、全体の枠は9,396件です。

Skillsを入れると成功率はどこまで上がるか

18構成のすべてで、Skillsを与えると成功率が上がりました。平均の改善幅は16.6ポイントで、論文は正規化ゲイン(伸びしろのうち埋まった割合)を25.5%と報告しています。構成ごとの差は大きく、最大は25.7ポイント、最小は4.1ポイントでした。

絶対値が高い構成が、最も伸びるとは限りません。Skillsありの上位はOpenHands+GPT-5.5、Codex+GPT-5.5、Claude Code+Opus 4.7ですが、最大の伸びはOpenHands+GLM 5.1でした。Skillsなしで強い構成でも伸びが小さい例があり、Opus 4.8は+8.4ポイント、Gemini 3.5 Flashは+7.1ポイントに留まります。

同じモデルでもハーネスが変わると効果は変わります。Opus 4.7はClaude Code上で61.2%、OpenHands上で53.1%でした。Gemini 3.1 ProもGemini CLIで60.8%、OpenHandsで52.8%と差が出ています。一方、GPT-5.5はOpenHandsの67.3%とCodexの66.5%でほぼ並びました。ハーネスがSkillの発見・提示・実行をどう仲介するかで、実際に得られる効果が変わるというのが論文の読み方です。

モデルの大きさと効果の関係でも、目を引く結果があります。MiniMax M2.7はSkillsありで34.9%となり、SkillsなしのOpenHands+GLM 5.1(32.7%)とOpenHands+MiniMax M3(29.7%)を上回りました。手順的な知識が要るタスクでは、Skillsがモデルの地力の一部を補えることになります。

Skillの数と長さをどう決めるか

設計要因の切り分けも行われています。Skillの個数では、2〜3個の組み合わせが最も伸び、4個以上でほぼ半減しました。本文の詳しさでは、標準的な長さが最良で、網羅的な文書は効果がほぼ消えています。

数字

Skillの個数と長さによる改善幅

• 1個

  +18.0

  単独のSkill

• 2〜3個

  +19.0

  最も効いた個数

• 4個以上

  +10.1

  ほぼ半減

• 簡潔 / 標準

  +19.0 / +21.5

  短めの本文

• 詳細

  +14.5

  書き込みすぎ

• 網羅的

  +0.7

  ほぼ効果なし

論文は、4個以上で落ちる理由を「余分な内容が負荷や矛盾した指示を生むため」と推測しています。網羅的に書き込むほど成功率が上がるという直感とは逆の結果で、焦点を絞った手順のほうが長い文章より効きます。

もう一つ見逃せないのが、Skillを見つけられていないわけではない点です。論文のFinding 4は、Skillの発見は通常ボトルネックではないとしています。Skillを読み込んだ試行でも失敗は続くため、問題はSkillに触れた後の使い方にあります。

エージェントに作らせたSkillは使えるのか

Anthropicのskill-creatorを使い、エージェント自身にSkillパックを作らせたうえで、そのパックだけを使って解かせる条件も試されています。対象はClaude Code、Codex、Gemini CLIの3構成です。

くらべる

人手で用意したSkillと自己生成Skill

+18.2〜+24.8pt

人手でキュレーションしたSkill

3構成すべてでSkillsなしの基準を上回りました。論文の監査では、効いたSkillは検証が見る形式や不変条件を具体的に書いていました。

-8.1〜-11.5pt

エージェントが自己生成したSkill

Claude Code+Opus 4.7で-8.1、Codex+GPT-5.5で-11.3、Gemini CLI+Gemini 3.1 Proで-11.5ポイントと、3構成すべてがSkillsなしの基準を下回りました。

軌跡を監査すると、原因は3つに分かれます。生成したパックを、解く側が結局発見していない場合があります。パックの作成作業が本来の解決作業を押し出してしまう場合もあります。そして、自信満々だが誤った内容のパックが使われる場合です。ただし論文自身も、この差にはSkillの中身の質と、作成役・解決役の干渉が混ざっていると述べています。

Skillsが逆効果になる13タスクで何が起きたか

87タスクのうち13タスクでは、Skillsを与えたことで成功率がむしろ下がりました。最も落ち込んだのはexam-block-sequencingとsuricata-custom-exfilで、いずれも-7.4ポイントです。adaptive-cruise-control・mars-clouds-clustering・r2r-mpc-control・econ-detrending-correlationも、それぞれ-5.6ポイント低下しました。

軌跡の監査では、下の3つの型が繰り返し出ています。型ごとに、論文が示す作り手への示唆が異なります。

逆効果

Skillが足を引っ張る3つの型

• 重い手順が単純な道を押し出す

  原理的には正しいが重い最適化の手順をSkillが指示し、簡単に正答へ着く道が使われなくなります。adaptive-cruise-controlとr2r-mpc-controlが該当します。示唆は、任意の手順に印を付け、速い経路も用意することです。

• 得意な既定の解き方を上書きする

  汎用のレシピが、モデルが元から持つ直接的なコーディングやデバッグの戦略を抑えます。exam-block-sequencingとecon-detrending-correlationが該当します。示唆は、好ましい手順だけでなく適用範囲の境界も書くことです。

• デバッグできないソルバーへ誘導する

  壊れやすいフレームワークやスキーマをSkillが義務づけ、正解にたどり着く前に失敗します。suricata-custom-exfilとmars-clouds-clusteringが該当します。示唆は、デバッグの代替手段と検証の手順を添えることです。

3つに共通する根本原因は、原理的には正しくても、日常の実行には重すぎるか壊れやすい手順を指示している点だと、論文はまとめています。これを受けて論文は、SKILL.mdのフロントマターに「想定するツール・トークンコスト」「適用範囲の境界」「軽量な代替手順」を示す複雑さ契約を加える案を出しています。公式仕様ではなく、論文側の提案です。

効いたSkillは何が違ったのか

反対に、最も効いた10タスクの平均改善は+67.0ポイントです。llm-prefix-cache-replayは成功率が1.9%から94.4%へ、dapt-intrusion-detectionは0%から81.5%へ上がりました。論文は、これら上位タスクのSkillを一対ずつ比べて、5つの書き方を抜き出しています。

書き方

効いたSkillに共通する5つの書き方

• 動くスクリプトを同梱する

  アルゴリズムの説明だけでなく、調整済みの既定値を持つ実行可能なスクリプトを付けます。llm-prefix-cache-replayなどが例です。

• データの出所と癖を名指しする

  正規のデータソースと、解析時の癖を明記します。flood-risk-analysisやdapt-intrusion-detectionが例です。

• 検証が見るファイル形式の制約を書く

  verifierが調べる形式の条件をそのまま書きます。threejs-structure-parserが例です。

• 検証が主張する不変条件を示す

  verifierが確かめるアルゴリズム上の不変条件を明示します。protein-expression-analysisなどが例です。

• 説明文をタスク固有にする

  フロントマターのdescriptionを具体的にして、エージェントが最初の走査で照合できるようにします。

どの型も、一般論でなく、そのタスクに固有の情報を渡している点が共通です。逆効果の3型が「一般的に正しい手順」を押し付けていたのと対照的です。

ドメインによる効果差

Skillsの効果はタスクの領域によっても大きく違います。

論文は、事前学習で手薄になりがちな専門的手順ほど効果が大きいと解釈しています。信号処理やセキュリティ解析、マルチメディア変換のような領域です。事前学習とツール群が手厚い領域では、外部の手順ガイドの価値が相対的に小さくなります。

この結果をSkill設計にどう持ち込むか

実測結果は、Anthropicが説明する「段階的開示」の考え方と方向が一致します。SKILL.md本文を簡潔に保ち、参考ファイルへ情報を分割する設計は、簡潔〜標準的な長さのSkillが最も効いた結果と噛み合います。命名規則と段階的開示の具体ルールはAgent Skillsの命名規則と段階的開示の設計原則で扱っています。

複数のSkillを組織で配布する場合は、Agent Skillsのエンタープライズ配布のリスク階層評価やバージョン管理と合わせて、モジュールの分割単位を見直す材料になります。Agent SDK経由での呼び出しはAgent SDK Skillsの使い方、MCP経由での配布はSkills over MCPとは何かにまとめています。

結果の読み方には、論文自身が挙げる限界が付きます。タスクは端末上のコンテナで動く再現性重視のもので、GUIエージェントやマルチエージェント連携、非常に長い作業への一般化は保証されません。評価対象のモデルとハーネスは限られ、Skills統合の仕様も時間とともに変わりえます。Skillを入れると文脈が長くなるため、効果の一部が「手順の構造」でなく「文脈の量」による可能性も、論文は未解決の論点として挙げています。

まとめ

Skillsは平均で成功率を押し上げますが、効くのは少数・焦点を絞った・タスク固有の人手のSkillで、数を増やす、網羅的に書く、エージェントに即席で作らせるといった方向では効果が消えるか逆効果になります。自分のSkillを見直すときは、一般論の手順を並べていないか、適用範囲と軽い代替手段を書いているかを確かめる材料になります。