入れすぎたAIエージェントの「スキル」が正答率を落とす理由──77人の研究者が87タスクで測った「効くスキル」の条件

Claude Codeをはじめとする複数のAIエージェントツールに、手続き的な知識をパッケージ化して渡す「スキル（Agent Skills）」という機能が急速に広まった。しかし「スキルを入れれば入れるほど良い」という直感は正しいのか。77人という大規模な研究者チームがarXivで公開した論文「SkillsBench」は、この問いに定量データで答えている。

3行まとめ

1. 77人の研究者チームが、18のモデル・ハーネス構成×87タスクで測定した結果、厳選されたスキルは平均正答率を33.9%から50.5%（+16.6ポイント）に押し上げた（SkillsBench論文、2026年6月14日改訂版）
2. モジュール数3個以内に絞り込んだスキルが、大きく網羅的なスキルの束を上回った。一方、エージェント自身にスキルを書かせる「自己生成」条件は、スキルなしより最大11.5ポイント低い結果になった
3. 効果はドメインごとに大きく異なり、自然科学分野で+28.8ポイントに対し数学・オペレーションズリサーチ分野では+9.7ポイントにとどまった。87タスク中13タスクではスキルがむしろ正答率を下げた

そもそも「スキル」とは何か

Anthropicは2025年10月16日付の公式ブログで、Agent Skillsを「エージェントが動的に発見・読み込みできる、指示・スクリプト・リソースをまとめたフォルダ」と定義している。1つのスキルはSKILL.mdというファイルを含むディレクトリで、YAMLフロントマターにnameとdescriptionを記載する。エージェントは起動時に全スキルのnameとdescriptionだけをシステムプロンプトに事前読み込みし、そのタスクに関連すると判断した場合にのみSKILL.md本体を読み込む「progressive disclosure（段階的開示）」という設計になっているという。同社は2025年12月18日付で、Agent Skillsをクロスプラットフォームで使えるオープンな標準として公開したことも追記している。

何を測ったベンチマークか

論文の要旨はこう始まる。

"Agent Skills are structured packages of procedural knowledge that augment large language model (LLM) agents at inference time. Despite rapid adoption, there is no standard way to measure whether they actually help."

Agent Skillsは、推論時にLLMエージェントを拡張する、手続き的知識の構造化されたパッケージだ。急速に採用が広まっているにもかかわらず、それらが実際に役立っているかどうかを測る標準的な方法はこれまで存在しなかった、と論文は指摘する。

そこで研究チームが構築したのが「SkillsBench」だ。

"We present SkillsBench, a benchmark whose current inventory contains 87 tasks across 8 domains paired with curated Skills and deterministic verifiers."

現時点のインベントリは、8つの領域にまたがる87のタスクと、それに対応する厳選されたスキル、決定論的な検証器（verifier）のセットからなる。論文本文（HTML全文版）によると、この87タスクは142人の貢献者による400件の投稿から選ばれたもので、人間の専門家がAIの補助なしで完了するのにかかる推定時間で3段階に層別化されている：60分未満の「Core」が6タスク、1〜4時間の「Extended」が53タスク、4時間超の「Extreme」が28タスクだ。各タスクはコンテナ化された単位として、固定データ・模範解答（oracle solution）・決定論的な検証器を備えており、「スキルなし」と「スキル付与」の両条件で同じタスクを解かせることで、スキル単体の寄与を切り分ける設計になっている。

主要な結果：スキルは平均で16.6ポイント正答率を押し上げる

論文の最新の集計評価は、18のモデル・ハーネス構成に対して、87タスクのベンチマークを「スキルなし」条件と「厳選されたスキルあり」条件の両方で実行した、対照実験の形をとっている。

"Curated Skills raise the average pass rate from 33.9% to 50.5% (+16.6 percentage points; 25.5% normalized gain), with configuration-level gains ranging from +4.1 to +25.7 pp."

厳選されたスキルは、平均正答率を33.9%から50.5%まで押し上げる（+16.6ポイント、正規化した伸び率で25.5%）。構成ごとの伸びは+4.1ポイントから+25.7ポイントまで幅がある。

核心的な発見：「絞り込まれたスキル」が「網羅的な束」に勝つ

この論文が示す、実務者にとって最も重要な発見が次の一文だ。

"Focused Skills with at most three modules outperform larger or exhaustive bundles, and smaller models with Skills can match larger models without them."

モジュール数が最大3個までに絞り込まれたスキルは、それより大きい、あるいは網羅的なスキルの束を上回る。 さらに、スキルを与えられた小型モデルは、スキルなしの大型モデルに匹敵する性能を出せることも示された。

これは、「使えそうなスキルを片っ端からインストールしておけば安心」という発想とは逆の結果だ。スキルを大量に積み込むことは、必ずしも性能向上につながらず、絞り込まれた少数精鋭のスキル構成の方が、より良い結果を生むということになる。

なぜ「多すぎるスキル」は逆効果になりうるのか

論文本文（HTML全文版）は、この現象を2つの切り分け実験（アブレーション）で定量的に示している。1つはタスクに付与するスキルの「数」を変えた場合、もう1つはスキル文書の「詳細度」を変えた場合の効果だ。

論文はこの結果を「過剰な内容がオーバーヘッドや矛盾する指示を生んでいることを示唆する」と説明しており、「網羅的な散文よりも、絞り込まれた手続き的な指示の方が勝る」とも書いている。数の面では2〜3個までが最も伸びが大きく、4個以上になると伸びが半分近くまで落ちる。詳細度の面でも、標準的な長さの記述が最も良い結果を出し、「網羅的なドキュメント」まで詳しく書き込むとほぼ効果がなくなる（+0.7pp）という、直感に反する結果が出ている。

論文はさらに、スキルを与えられた小型モデル「MiniMax M2.7」（正答率34.9%）が、スキルなしのより大型なモデル構成「OpenHands + GLM 5.1」（32.7%）や「OpenHands + MiniMax M3」（29.7%）を上回ったことも示しており、スキルがモデルの規模差の一部を埋め合わせられる可能性を示唆している。

ドメインごとの効果には大きな差がある

論文本文の「Table 3」は、8つのドメインごとの正答率をスキルなし・スキルありの両方で示している（Nはドメインごとのタスク数、Δは伸び幅）。

論文は「モデルの事前学習でカバーが薄い、専門的な手続き知識を要するドメイン（科学的信号処理、セキュリティ分析、マルチメディア変換のワークフローなど）ほど伸びが大きく、事前学習・ツール対応が手厚いドメインほど伸びが小さい」と分析している。タスク単位で見ると、87タスク中13タスクではスキルがむしろ正答率を下げており、下げ幅が最大だったのは「exam-block-sequencing」と「suricata-custom-exfil」（いずれも-7.4pp）だった。逆に伸びが最大だったタスク群（上位10件、平均+67.0pp）には、llm-prefix-cache-replay（スキルなし1.9%→スキルあり94.4%）やdapt-intrusion-detection（0%→81.5%）が含まれる。

自分でスキルを書かせても代わりにはならない

論文は、エージェント自身にAnthropic公式ツール「skill-creator」でスキルパックを作らせ、そのスキルだけで問題を解かせる「自己生成（self-generated）」条件も、3つの主要ハーネス構成（Claude Code + Opus 4.7、Codex + GPT-5.5、Gemini CLI + Gemini 3.1 Pro）で別途評価している。結果は、3構成すべてで「スキルなし」条件を下回った（Claude Code + Opus 4.7で-8.1pp、Codex + GPT-5.5で-11.3pp、Gemini CLI + Gemini 3.1 Proで-11.5pp）。同じ3構成で「厳選されたスキル」条件は+18.2〜+24.8ptの伸びを示しており、両者の差は大きい。

論文の軌跡監査（trajectory audit）は、この落ち込みの原因を「生成されたスキルパックをソルバー側のエージェントが結局見つけていない」「スキル作成側の作業がソルバー側の作業を圧迫している」「自信ありげに誤った内容のパックが使われている」の3点に帰しているが、この監査自体は10の（タスク、構成）ペアから抽出した12件のソルバー軌跡を対象にしたものであり、全体を代表する量ではないと論文自身も位置づけている。

公開されているスキルの数そのものが1年で桁違いに増えた

論文はベンチマーク構築の前提として、GitHubやマーケットプレイス、パートナー企業の在庫から集めた「スキル」の総数も集計している。2026年時点のスナップショットでは、ソース単位で重複排除した状態で201万4,000件のスキルが存在した。これは2026年1月に集計した約3万7,000件のスナップショットから、数ヶ月で1桁以上増えた規模だという。日次の追加件数は2025年10月16日に初めて1日100件を超え、2026年4月7日には1日3万3,692件という最大値を記録している。

このうち、リポジトリが生きていて実際にクローンできた76万7,430件のスキル本体を構造的に分析した結果として、論文は次の数字を挙げている。

• 59.9%がSKILL.md1ファイルのみの最小構成
• 86.4%が5ファイル以下（中央値1、平均5.6）
• ファイル拡張子の内訳は、全427万ファイル中.mdが51.7%、.pyが6.9%、.tsが6.1%、.jsが5.7%、.jsonが4.8%で、自然言語の指示文書が実行コードより優勢

この数字は、記事執筆時点でよく言及される「4万7,150件のスキルを品質監査した」という趣旨の第三者解説とは一致しない。SkillsBench論文の本文を読んだ範囲では、「47,150」という数字そのものは見当たらなかった。論文が実際に示しているのは201万4,000件（発見総数）と76万7,430件（構造分析できた件数）であり、この記事ではこの2つの数字だけを事実として扱う。

研究チームの規模

この論文の著者リストにはXiangyi Li氏を筆頭に76名の共著者が名を連ねており、UC Berkeleyの著名なセキュリティ・AI研究者であるDawn Song氏も含まれている（同氏は本記事で別途扱ったAIエージェントのベンチマークは「ハック」できるというBenchJack論文にも名を連ねている）。論文は2026年2月13日に初版が提出された後、3月・6月と複数回改訂されており、直近の第4版は2026年6月14日付けだ。

実務への示唆

AIエージェントに「スキル」や「サブエージェント」の形で知識を持たせる際、量よりも「タスクに本当に必要なものだけを、絞り込んだ形で」渡すことの重要性を、この研究は定量的に裏付けている。エージェントに渡す情報全体をどう設計するかという「コンテキストエンジニアリング」の考え方とも重なる部分が大きい（詳しくはコンテキストエンジニアリングとはを参照）。AIエージェントの基本概念についてはAIエージェントとはも参照してほしい。

測ったのは正答率だけ、速度への影響は不明

• 本記事はarXiv掲載論文（プレプリント）のAbstractと、arXivが公開しているHTML全文版（v4）の両方をcurlで取得して確認した。ただし全文版はHTMLへの自動変換であり、図表・数式の一部はテキストとして崩れて表示される部分があった。本記事の数字は、崩れた箇所を除いて文章として読み取れた範囲のものにとどまる。
• 「47,150件のスキルを品質監査した」という趣旨の第三者解説記事の数字は、論文本文を通しても該当箇所を見つけられなかった。論文が実際に示しているエコシステム規模の数字（201万4,000件・76万7,430件）は本文中に明記して区別してある。
• 「モジュール数3個以内」の効果は、Appendix Fの2つのアブレーション実験（スキル数・詳細度）に基づく全体平均の数字であり、これも記事内の表で示した8ドメイン別のΔ幅（+9.7〜+28.8pp）を踏まえると、ドメインによって最適なスキル数・詳細度が異なる可能性は残る。論文自身、この点をドメイン別に切り分けた追加分析は示していない。
• 自己生成スキルが劣る原因についての「軌跡監査」は、10の（タスク、構成）ペアから抽出した12件のソルバー軌跡を対象にした定性分析であり、87タスク・18構成の全体を代表する定量的な検証ではない。論文自身がこの限界を明記している。
• 論文が直接測定しているのは「正答率（タスク達成度）」であり、処理速度・レイテンシ・コストへの影響を直接測定した数値は、本記事で確認した範囲（Abstract・本文の主要な発見部分）には含まれていない。「スキルを入れすぎると重くなる／遅くなる」という体感は読者の間にあり得るが、それを裏付ける数値をこの論文は示していない。
• 論文著者の所属一覧にはBenchFlow・OSU・Amazon・UC Berkeley・Stanford・Princeton・CMUなど多数の組織名が並ぶが、各著者がどの発見にどう貢献したかの内訳は確認していない。