Agent Skillsの効果をSkillsBenchが実測 — 最適は3モジュール以下
Agent Skillsは本当にタスク成功率を上げるのか。87タスクの検証結果、モジュール数と複雑さの影響、逆効果になった13タスクの共通パターンを一次データで確認します。
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月には、この仕組みがAnthropic単独の機能から複数プラットフォームで使える公開標準として切り出されました。
SkillsBenchは、このAgent Skillsが実際の作業でどれだけ役に立つのかを定量的に測るために作られたベンチマークです。1,400人規模のコミュニティから寄せられた400件のタスク提案を、142人の貢献者・自動チェック・人手レビューでふるいにかけ、87タスクまで絞り込みました。対象領域は自然科学・メディア制作・サイバーセキュリティ・産業システム・金融経済・オフィス業務・ソフトウェア工学・数理最適化の8つに及びます。
検証の設計が特徴的です。同じタスクを同じコンテナ上で、Skillsを与えない条件とSkillsを与える条件の両方で実行し、成功率の差分を測ります。モデルやハーネスの違いによる影響と、Skill自体の効果を切り分けるための工夫です。判定は人間の採点ではなく、決定論的なpytestベースの検証スクリプトで自動的に行われます。
87タスクの検証結果 — 平均成功率33.9%から50.5%へ
主要な結果は、18種類のモデル・ハーネス構成のすべてでSkillsを与えると成功率が改善したことです。改善幅の平均は16.6ポイントですが、構成ごとの差は大きく、最大で25.7ポイント、最小では4.1ポイントに留まりました。
| ハーネス | モデル | Skillsなし | Skillsあり | 差分 |
|---|---|---|---|---|
| OpenHands | モデルGPT-5.5 | Skillsなし51.5% | Skillsあり67.3% | 差分+15.8pt |
| Codex | モデルGPT-5.5 | Skillsなし46.8% | Skillsあり66.5% | 差分+19.7pt |
| Claude Code | モデルOpus 4.7 | Skillsなし43.0% | Skillsあり61.2% | 差分+18.2pt |
| Gemini CLI | モデルGemini 3.1 Pro | Skillsなし36.0% | Skillsあり60.8% | 差分+24.8pt |
| OpenHands | モデルGLM 5.1 | Skillsなし32.7% | Skillsあり58.4% | 差分+25.7pt |
| OpenHands | モデルClaude Opus 4.7 | Skillsなし42.1% | Skillsあり53.1% | 差分+11.1pt |
| OpenHands | モデルGemini 3.1 Flash Lite | Skillsなし16.0% | Skillsあり20.1% | 差分+4.1pt |
| 平均(18構成) | モデル— | Skillsなし33.9% | Skillsあり50.5% | 差分+16.6pt |
同じモデルでもハーネスが変わると効果は変わります。Claude Opus 4.7はClaude Code上では61.2%まで伸びますが、OpenHands上では53.1%に留まりました。この差が示すのは、ハーネスがSkillの発見・提示・実行の流れをどう仲介するかで、実際に得られる効果が変わるという点です。Skillsはただ文脈に追加情報を積む機能ではなく、ハーネス側の実装が効果の上限を決めているという指摘です。
モジュール数と複雑さでどう変わるか — 3モジュール以下が最良
Skillの設計要因についても切り分け実験が行われています。まずSkillの個数です。1つのSkillだけを使ったタスクは+18.0ポイント、2〜3個の組み合わせは+19.0ポイント伸びましたが、4個以上を束ねると伸びは+10.1ポイントに半減しました。Skillは増やすほど効くわけではありません。
Skill本文の詳しさについても同様の傾向が出ています。簡潔な記述と標準的な長さの記述はそれぞれ+19.0ポイント・+21.5ポイント伸びましたが、詳細な記述は+14.5ポイントに下がり、網羅的な文書ではわずか+0.7ポイントとほぼ効果が消えました。網羅的に書き込むほど成功率が上がるという直感とは逆の結果です。
エージェント自身にSkillを作らせた場合の結果も示されています。3つの構成で、エージェントがAnthropicのskill-creatorを使って自らSkillパックを作成しました。それだけを使って解いたところ、Claude Code + Opus 4.7で-8.1ポイント、Codex + GPT-5.5で-11.3ポイント、Gemini CLI + Gemini 3.1 Proで-11.5ポイントと、いずれもSkillsなしの基準より成績が下がりました。同じ3構成で人間が事前に用意したSkillを使った場合は+18.2〜+24.8ポイントの改善だったので、差は歴然としています。軌跡を監査すると、原因は3パターンに分かれます。生成したパックをソルバー側が結局発見していない、作成作業自体が本来の解決作業を押し出してしまう、そして自信満々だが誤った内容のパックが使われる、というものです。
ドメインごとの効果差 — 自然科学は+28.8pt、数理最適化は+9.7pt
Skillsの効果はタスクの領域によっても大きく違います。
| ドメイン | タスク数 | Skillsなし | Skillsあり | 差分 |
|---|---|---|---|---|
| 自然科学 | タスク数14 | Skillsなし42.0% | Skillsあり70.8% | 差分+28.8pt |
| メディア・コンテンツ制作 | タスク数5 | Skillsなし23.3% | Skillsあり47.4% | 差分+24.1pt |
| サイバーセキュリティ | タスク数7 | Skillsなし29.5% | Skillsあり48.4% | 差分+18.9pt |
| 産業・物理システム | タスク数14 | Skillsなし23.9% | Skillsあり39.6% | 差分+15.7pt |
| 金融・経済 | タスク数9 | Skillsなし19.1% | Skillsあり33.3% | 差分+14.2pt |
| オフィス業務 | タスク数14 | Skillsなし40.5% | Skillsあり53.0% | 差分+12.6pt |
| ソフトウェア工学 | タスク数16 | Skillsなし37.6% | Skillsあり49.2% | 差分+11.6pt |
| 数理最適化・OR | タスク数8 | Skillsなし45.7% | Skillsあり55.4% | 差分+9.7pt |
最も伸びたのは自然科学(+28.8ポイント)、メディア・コンテンツ制作(+24.1ポイント)、サイバーセキュリティ(+18.9ポイント)でした。逆にソフトウェア工学(+11.6ポイント)と数理最適化(+9.7ポイント)は伸びが小さめです。この差の背景にあるのは、事前学習データで手薄になりがちな専門的手順ほどSkillsの効果が大きいという傾向です。信号処理やセキュリティ解析、マルチメディア変換のような領域が該当します。反対に、モデルが元から強い前提知識やツール群を持つ領域では、外部からの手順ガイドの価値が相対的に小さくなります。
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の4タスクも、それぞれ-5.6ポイントの低下が確認されています。
トラジェクトリを監査した結果、原因は3パターンに整理されています。Skillが不必要に重い処理手順を指示している場合、エージェントが元々持っていたより良いデフォルトの解き方をSkillが上書きしてしまう場合、そしてエージェント自身がデバッグできないソルバーへ誘導してしまう場合です。共通する根本原因は、適用範囲の限定や軽量な代替手段を持たない「唯一の正しい手順」として書かれていることだと論文はまとめています。
この分析を踏まえて、論文はSKILL.mdのフロントマターに「想定するツール・トークンコスト」「適用範囲の境界」「軽量な代替手順」を明示する複雑さ契約を加える案を提案しています。これはAnthropicの公式仕様ではなく、論文側からの改善提案です。
一方で、Skillsが最も効いたタスクでは平均+67.0ポイントという大きな改善も出ています。llm-prefix-cache-replayはSkillsなしで1.9%だった成功率が94.4%まで上がり、dapt-intrusion-detectionは0%から81.5%まで上がりました。効果の裾が広いことも、この検証結果の特徴です。
Claude Code・Agent SDKでのSkill設計にどう活かすか
今回の実測結果は、Anthropic公式記事が説明する「段階的開示」の考え方と方向が一致します。SKILL.md本文を簡潔に保ち、参考ファイルへ段階的に情報を分割するこの設計は、検証が示した「簡潔・標準的な長さのSkillが最も効き、網羅的な文書ほど効果が薄れる」という結果と噛み合います。命名規則と段階的開示の具体的な設計ルールはAgent Skillsの命名規則と段階的開示の設計原則にまとめています。
検証結果をSKILL.mdの設計判断に落とすと、次のような目安になります。
| 観点 | 実測結果 | 設計の目安 |
|---|---|---|
| Skillの個数 | 実測結果1個+18.0pt、2〜3個+19.0pt、4個以上+10.1pt | 設計の目安1つのSKILL.mdに詰め込みすぎず、3個以下の単位で分ける |
| 本文の長さ | 実測結果簡潔+19.0pt、標準+21.5pt、詳細+14.5pt、網羅的+0.7pt | 設計の目安詳細を書き込みすぎず、簡潔〜標準的な長さに留める |
| 作り手 | 実測結果人手キュレーション+18.2〜+24.8pt、エージェント自己生成-8.1〜-11.5pt | 設計の目安実行中にエージェントへ即席生成させず、事前に人手で用意する |
| 適用範囲の明記 | 実測結果逆効果13タスクの根本原因は適用範囲・軽量代替を欠いた「唯一の正しい手順」 | 設計の目安想定ツール・トークンコスト・適用範囲の境界・軽量な代替手順を明記する |
複数のSkillを組織で配布する場面では、Agent Skillsのエンタープライズ配布で扱っているリスク階層評価やバージョン管理と合わせて、モジュールの分割単位を見直す材料になります。
Skill自体をAgent SDK経由でどう呼び出すかの実装はAgent SDK Skillsの使い方で扱っています。また、MCP経由でSkillを配布する仕組みについてはSkills over MCPとは何かで解説しており、配布経路が変わってもSkill本体の設計原則は今回の検証結果がそのまま当てはまります。
エージェント自身にSkillを生成させる運用を検討している場合は、この検証で自己生成Skillが軒並みSkillsなしの基準を下回った点に注意が必要です。人手または専門知識を持つ人が事前にキュレーションしたSkillと、エージェントが即席で作ったSkillは、同じ「Skill」という形式でも効果が別物として現れています。
まとめ
SkillsBenchの検証では、Agent Skillsを与えると18構成すべてで成功率が改善し、平均で33.9%から50.5%へ上がりました。ただし伸び幅は構成やドメインで大きく異なり、モジュール数が3個を超える・記述が網羅的すぎる・エージェント自身が即席で作ったSkillを使う、といった条件では効果が薄れるか逆効果になることも確認されています。SKILL.mdを簡潔に保ち、適用範囲を絞ったSkillを少数だけ用意する設計は、Anthropic公式が示す段階的開示の考え方とも噛み合う方針といえます。