Skillsが効くのは「知識を足すから」ではなく「手順の道しるべになるから」──8,135件のトライアルが示した実態

LLMエージェントに「構造化された知識のパッケージ」を渡すSkills機能は、実務での効果が広く認められつつある一方、「なぜ効くのか」「どこで失敗するのか」という根本的な問いは、これまで十分に検証されてこなかった。2026年8月14日にarXivで公開された論文「Demystifying Agent Skills」は、この問いに統制実験とペア軌跡分析で正面から答えようとしている。著者9名の所属はPrinceton University・UC San Diego・Stanford University・University of Southern California・Johns Hopkins Universityの5大学。

3行まとめ

• Skillsが効く場面の65.7%は「手順の道しるべ（procedural anchoring）」として機能し、知識注入として効く場面はわずか4.5%。Skillは直接比較でWorkflow Memoryを+6.06ポイント上回った（95%信頼区間[+0.76, +11.36]）
• 論文全文を読むと、Skillは実行系の失敗（SC2）を減らす一方（124/528 vs 生実行197/528）、逆に「呼び出し・適用範囲の失敗」（SC3）は生実行の19/528から78/528へ増加している——Skillには副作用として「あるのに誤用・過剰適用される」リスクがあることが数字で示されている
• タクソノミーの人間検証では、独立した人手評価とLLM判定の一致率95.8%・Cohen's κ=0.952。実験にはCodex+GPT-5.3-Codex、Gemini CLI+Gemini-3.1-Pro-Preview、検索段ではQwen3-Embedding-0.6Bが使われている

「タスク成功率が上がるか」だけを見てきた既存の評価

論文はまず、既存の評価手法の限界を指摘する。

"Skills have emerged as a practical and effective approach for enhancing LLM agents at inference time through structured packages of knowledge. However, existing evaluations largely measure whether skills improve aggregated task success, leaving a more fundamental question underexplored: When do skills help, why do they work, and where do they fail?"

（原文ではこの最後の問いはイタリック体・太字で強調されている。引用ではその強調記法を外し、文字自体をそのまま転記した）

（Skillsは、構造化された知識パッケージを通じて、推論時にLLMエージェントを強化する実務的かつ効果的な手法として台頭してきた。しかし既存の評価は、Skillsが集計されたタスク成功率を改善するかどうかを測定するにとどまり、より根本的な問い——いつSkillsが役立ち、なぜ機能し、どこで失敗するのか——は十分に検討されていない）

「効果があるかどうか」は測られてきたが、「なぜ効くのか」「いつ効かなくなるのか」というメカニズムの解明は手薄だった、という指摘だ。

8,135件のトライアルを分析した規模

論文の分析規模は具体的な数字で示されている。

"We normalize 8,135 trial records from controlled experiments and retain 238 valid unique labels from 240 open-coded records. We consolidate these observations into a taxonomy of three high-level categories and twelve skill-use modes: skills work when noisy trajectories become procedural anchors that stabilize execution."

（統制実験から得た8,135件のトライアル記録を正規化し、240件のオープンコーディング記録から238件の有効な固有ラベルを保持した。これらの観察結果を、3つの上位カテゴリと12の「スキル利用モード」からなる分類法に統合した。Skillsが機能するのは、ノイズの多い軌跡が、実行を安定させる「手順の道しるべ（procedural anchor）」になる時だ）

「手順の道しるべ」という表現がこの論文のキーワードだ。Skillsは、モデルに新しい知識を教え込むというより、すでに持っている能力を安定して発揮させるための「軌道の目印」として機能する、という見方を提示している。

論文全文（arXiv HTML版）を読むと、要旨だけでは分からない実験条件が付録に明記されている。

（出典：論文全文 §3.2「Model and benchmark selection」・§4「Skill-Use Mechanisms: A Contrastive Taxonomy」）

さらに、528トリプルを3つの上位カテゴリ（SC1〜SC3）に分類した集計も付録に記載されている。SC1は「自律的に成功、または手順の道しるべとして機能した」ケース、SC2は「環境構築・出力整形・シェル実行などの実行系の失敗」、SC3は「手順は存在するのに誤用・過剰適用・無視された失敗」を指す。

（出典：論文全文 §4、集計値は528トリプルに対するアーム単位の割り当て数）

Skillは実行系の失敗（SC2）を大きく減らす一方、呼び出し・適用範囲の失敗（SC3）は生実行の19件から78件へ、4倍以上に増えている。「Skillsは万能ではなく、あるのに誤用される・過剰に適用されるという新しい種類の失敗を持ち込む」ことが、この内訳から読み取れる。

数字：Skillsが効く理由の65.7%は「手順の安定化」、知識注入はわずか4.5%

論文が示す最も重要な数字はここだ。

"Skills improve over Workflow Memory by 6.06 points in matched comparisons. Procedural anchoring accounts for 65.7% of skill cases, versus 4.5% for explicit knowledge injection, showing that skills stabilize action rather than inject missing facts."

（マッチさせた比較において、SkillsはWorkflow Memoryを6.06ポイント上回った。手順の道しるべ（procedural anchoring）としての機能は、Skillsが効いたケース全体の65.7%を占める一方、明示的な知識注入として機能したケースはわずか4.5%だった。これは、Skillsが不足している事実を注入するというより、行動を安定させるものであることを示している）

多くの人が「Skillsは知識を追加で教える仕組みだ」と直感的に理解しているかもしれないが、この論文の分析では、実際に効果を発揮している場面の大半（65.7%）は「知識の追加」ではなく「実行の安定化」だった、という結果だ。

検索プールが大きくなるほど、精度が急落する

もう1つの重要な発見は、Skillsの検索（どのSkillを呼び出すか）に関するものだ。

"Retrieval is a separate bottleneck: as pools grow from 5 to 100, actual-use precision falls from 29.6% to 3.3%. Confusable distractors impair offline identification, yet downstream success remains stable; exact ground-truth invocation is neither sufficient nor necessary."

（検索は別のボトルネックだ。Skillの候補プールが5個から100個に増えるにつれ、実際に使用される際の精度は29.6%から3.3%まで低下する。紛らわしい候補（distractor）は、オフラインでの識別を妨げるが、最終的なタスク成功率は安定したまま維持される。正確な正解Skillの呼び出しは、十分条件でも必要条件でもない）

これは直感に反する結果だ。「正しいSkillを正確に呼び出せているか」という精度が3.3%まで落ち込んでも、最終的なタスクの成功率自体はそれほど落ちない、というのは、Skillの検索精度と実際の成功率が、必ずしも単純に連動しないことを示している。

Skillsが失敗する条件

論文はSkillsが機能しない条件についても整理している。

"Skills fail under brittle assumptions, incompatible contexts, or insufficient adaptation."

（Skillsは、壊れやすい前提条件・互換性のない文脈・不十分な適応の下で失敗する）

つまり、Skillが想定している前提が現在の状況と食い違っていたり、文脈が合わなかったり、状況に応じた調整が不足していたりすると、うまく機能しなくなる、という整理だ。

「何を教えるか」より「どう手順を踏ませるか」という示唆

筆者は、Claude Codeのスキル機能を使う際、漠然と「専門知識を教え込む」という感覚で捉えていたが、この論文の分析結果を読むと、実際に効いている場面の大半は「知識の追加」ではなく「ふらつきやすい実行を、決まった手順に沿わせて安定させる」という役割だったという。これは、Skillsを設計する際に「何を教えるか」よりも「どういう手順を踏ませるか」を重視すべきだという、実務上の示唆にもつながる発見だと感じる。「検索プールが大きくなると精度が急落するが、成功率は安定する」という結果も、Skillの数を増やす際に検索精度だけを気にしすぎる必要はないかもしれない、という点で興味深い。

Table 11の内訳──12モードすべての名称と、腕（arm）ごとの構成比

論文本文のTable 11（付録）には、SC1〜SC3をさらに細分化した12の「スキル利用モード」が、Raw／Workflow Memory（WF）／Skillそれぞれの腕でどれだけの割合を占めたかとともに列挙されている。528トリプルに対するアーム単位の構成比（%）は次の通り。

出典: 論文全文Table 11「Contrastive skill-use taxonomy over 528 paired triples」（2026年8月31日確認）

この内訳を見ると、Skill条件で最も目立つ失敗モードは「skill_guidance_misapplied_or_ignored」（Skillの指示が誤適用された、または無視された）で10.0%を占めており、これが記事前半で触れたSC3急増（19件→78件）の主因になっていることが分かる。一方、Raw条件で最多だった失敗モード「autonomous_clean_success」（48.7%、こちらは失敗ではなく「何の支援も無くても自力で成功した」ケース）は、SkillやWorkflow Memoryを与えるとほぼ消える（Skillでは0.2%）。これは、単純なタスクではそもそもSkillが無くても解けてしまうケースが一定数あり、その分だけベースラインの「自力成功」率が高く出ている、という構造を示している。

付録の追加実験──「簡易な手順書」との比較でもSkillが上回る

論文はSkillの優位性が「単に手順テキストを与えたから」なのか「SKILL.mdという再利用可能な形式そのもの」に由来するのかを切り分けるため、Terminal-Bench-2の26タスクに限定した追加実験（Table 12、付録A.8）も行っている。

"To test whether the observed skill advantage can be explained by compact procedural text alone, we add two lightweight baselines on the same 26 selected Terminal-Bench-2 tasks used in the Gemini CLI + Gemini-3.1-Pro-Preview comparison."

（訳：観測されたSkillの優位性が、コンパクトな手順テキストだけで説明できるかを検証するため、Gemini CLI + Gemini-3.1-Pro-Preview比較で使われたのと同じ26のTerminal-Bench-2タスクに、2つの軽量ベースラインを追加した）

タスクあたり5トライアル（計130トライアル）での成功率は次の通りだった。

出典: 論文全文Table 12（2026年8月31日確認）

簡潔な手順書（Short plan）を与えるだけではRaw（支援なし）と大差なく、むしろわずかに下回っている（47.7% vs 50.0%）。検証テンプレート（Test-first）やWorkflow Memoryはある程度成功率を押し上げるが、SKILL.mdという再利用可能な形式のSkillが79.2%と頭一つ抜けている。この結果は、「手順を言葉で説明するだけ」では再現できない、SKILL.md形式そのものの効果があることを示している。

トークンコストで見ると、SkillはRawより安く、Workflow Memoryより高い

論文付録A.9（Table 13）は、Raw・Workflow Memory・Skillの3条件が共通して有効なトークン計測データを持つ83タスクに絞り、成功率とトークン使用量をタスクあたり平均で比較している。

出典: 論文全文Table 13「Matched success and token-cost analysis」（2026年8月31日確認）

論文はこの結果を「Workflow MemoryはRawに対して成功率をほぼ変えずにトークンコストを大幅に下げる」「Skillは、Workflow Memoryより93.8Kトークン多いコストと引き換えに、4.8ポイントの成功率向上を得ている（Skill vs Workflow Memoryの比較で"better but costlier"と表現）」と整理している。なお同じ表の別の行「Skill vs Raw」は+5.5ポイントかつトークンも34.2K少なく、こちらは"better and cheaper"と書かれている。つまりSkillは「無料の改善」ではなく、Workflow Memoryと比べると追加のコンテキスト消費と引き換えの性能向上だ、という数字が付録から読み取れる。

SKILL.md形式・Harborフレームワークの出典確認

論文が採用する標準化フォーマット「SKILL.md」は、Anthropicが公開しているリポジトリanthropics/skillsを参考文献として引用している（論文の参考文献リストに「Anthropic (2025). Skills: Public Repository for Agent Skills」として記載、アクセス日2026年5月23日）。このリポジトリを2026年8月31日にGitHub APIで確認したところ、スター数172,733・作成日2025年9月22日だった。また、評価に使われた「Harborの標準評価フロー」は、同じく論文の参考文献にあるharbor-framework/harbor（Harbor Framework Team, 2026「Harbor: A framework for evaluating and optimizing agents and models in container environments」）を指しており、GitHub API確認時点でスター数4,800・作成日2025年8月4日・Apache License 2.0だった。

LLM判定への依存・手元再現なしという限界は残る

この分析の労働集約的な部分（軌跡のラベル付け）自体がLLM判定（人間検証は一部サンプルのみ）に依存している点は、論文自身が人間検証（95.8%一致）で補強してはいるものの、100%人手によるラベル付けではないという設計上の限界であり、本記事もこの限界をそのまま引き継いでいる。この記事の執筆にあたって、SKILL.mdを実際に作成してSkillとWorkflow Memoryの挙動差を手元で再現したわけでもない。

論文自身も第7節「Limitations」で3つの限界を挙げている。①評価対象がターミナル操作・ツール利用系のベンチマークに限られ、長期のWeb操作やオープンエンドな協働までは扱っていない。②評価したエージェント・モデルの組み合わせは限られており、他のスキャフォールドやモデル系統・バージョンに一般化するとは限らない。③失敗機構の分類法（タクソノミー）は、正規化した全記録の約3%を層化抽出したオープンコーディングから作られており、網羅的なラベル付けではないため、まれな挙動は過小評価されている可能性がある。本記事の数字を読む際は、この3点が前提として付いていることに注意してほしい。Zenn記事検索（2026年8月27日実施）では「Demystifying Agent Skills」に該当する日本語記事は見つからなかった。

関連記事

• Claude Codeとは──コード生成に留まらない「仕事を渡せる」AIエージェント
• AIエージェントとは？仕組みと活用事例【2026年解説】
• AIエージェントとは──指示に答えるAIと、仕事を進めるAIの違いをわかりやすく整理する