skill は増やすほど強くなるのか ── 『More Skills, Worse Agents?』を読む
skill を書いていると、つい「いい skill が増えれば、エージェントは強くなる」と思ってしまう。SKILL.md にドメインの手順を書く。タスク完了率が上がる。だから、もっと書く。もっと足す。
ただ、その「足していく」方向に、あまり語られてこなかった落とし穴がある。今回読んだ論文は、そこを正面から測っている。結論を先に書くと ── 役に立つ skill だけを集めても、数が増えると、エージェントはむしろ弱くなる。しかも弱くなる理由が、たぶん直感とは違う。
何の論文か
"More Skills, Worse Agents? Skill Shadowing Degrades Performance When Expanding Skill Libraries"。Databricks の Hongwen Song・Song (Vinson) Wei による、ワークショップ Agent Skills '26 の論文です。
紛らわしいので先に書いておく。これは SkillsBench ── 人が作った skill は役に立つ、AI が自己生成した skill はほとんど役に立たない、を示したあの論文 ── とは別物です。評価データセットとして SkillsBench を使ってはいるけれど、この論文が問うているのは一点だけ。ライブラリに skill が増えたとき、何が起きるのか。
どれくらい落ちるのか
実験はシンプルです。2つの条件で成功率を比べる。ひとつは、そのタスクの成功率を上げると分かっている skill だけの、小さなライブラリ。もうひとつは、そこに skill を大量に足した大きなライブラリ。
skill を 202 本まで増やすと、成功率は最大で 21ポイント 下がった(2モデルの平均)。足している skill は、壊れたものでも、いじわるに仕込んだものでもない。どれも人が手で書いた、それぞれ別のどこかのタスクで役に立つ skill です。それでも、棚に並ぶ数が増えるだけで落ちる。
劣化を、2つに分ける
この論文の面白いところは、その低下を原因ごとに分けてみせたことです。
ひとつは context overhead ── 文脈オーバーヘッド。skill が増えれば、その名前と説明文が文脈を圧迫する。正しい skill を選べていても、文脈が膨らんだぶん、実行の質が落ちる。
もうひとつが skill shadowing ── スキル・シャドウイング。ライブラリが大きくなるほど、エージェントが間違った skill を選ぶようになる。プログラミングの変数シャドウイングと同じで、説明文がそれっぽく被った別の skill が、本来選ぶべき skill を覆い隠す。
意外なのは、どっちが犯人か
直感だと、犯人は context overhead だと思う。skill が増える、文脈が膨らむ、悪化する ── 素直な筋です。
でも測ってみると、そう素直にはいかない。202本時の21ポイントの低下を点推定で内訳に割ると、shadowing が約 68%、context overhead が約3割 ── shadowing のほうが大きい。しかも context overhead は信頼区間がゼロをまたいでいて、統計的には実在を確定できていない。論文自身、context overhead もありそうだ ── 正しい skill を選べているケースでも、ライブラリが大きいほど成功率は落ちる ── が、今回のサンプル数では測りきれない、と書いている。だから、データではっきり名指しできる犯人は shadowing のほうです。「間違った skill を掴むこと」。文脈の重さも足を引っ張ってはいるはずで、ただ今回の規模では確定できなかった。
論文の mario-coin-counting の例がわかりやすい。コインを数えるタスクなのに、ライブラリには video-frame-extraction という名前の skill が紛れている。説明文の見た目がクエリにうまく合ってしまう。結果、エージェントは 26回の試行すべてで この間違った skill を選んだ。一回も、本来選ぶべき skill のほうを選んでいない。
この誤選択を説明するのが、shadowing の起きるタイミングです。エージェントが skill を選ぶとき、見えているのは各 skill の名前と description だけ。本文(SKILL.md の中身)は、まだ読み込まれていない。つまり誤選択は、中身を見る前 ── インターフェースの情報だけ ── で起きている。
モデルで壊れ方が違う
副次的だけど、壊れ方がモデルで違ったのも面白い。ライブラリが大きくなると、Haiku 4.5 は「そもそも skill を選ばなくなる」方向に、Sonnet 4.6 は「間違った skill を選び続ける」方向に崩れた。この実験の範囲では、小さいモデルは諦め、大きいモデルは誤選択する、という崩れ方に見える。
skill を運用している人にとって、何が変わるか
ここからが、実際に .claude/skills/ を育てている人の話です。
shadowing が名前と description だけで起きる以上、手を入れるべきは「skill の中身を磨くこと」より「選択を設計すること」になる。
手をつけやすいのは命名と説明文です。description を、互いに被らないように書く。自分の skill 棚に、説明文の似た skill が複数並んでいるなら、それは将来どこかで誤選択を生む種だと思っておいたほうがいい。
具体的にどうするか。たとえば video-processing、frame-extraction、image-analysis のような、説明の近い skill が並ぶなら、description の段階で差をはっきりさせておく。「入力は動画か、静止画か」「最終成果物はフレーム画像か、数値の集計か、レポートか」「使ってはいけない場面はどこか」── このあたりまで description に書いてしまう。本文(SKILL.md の中身)でどれだけ丁寧に説明しても、選択のときには読まれない。それでは遅い。
もう一段上は、ライブラリを丸ごと文脈に積むのをやめる、という方向。論文も次の一手として、検索で候補を前もって絞る、description の紛らわしさを削る、選択そのものを学習させる、といった方向を挙げている。全部見せてから選ばせるのではなく、候補を絞ってから見せる。
突飛な話ではない。「結局、skill は何本まで載せられるのか」── 運用していれば一度は思うこの問いに、性能の側から手をつけたのがこの論文だ、と読むこともできます。同じ問題意識の研究なら、清華大学の "Skill Retrieval Augmentation for Agentic AI" もある。
鵜呑みにしないために
面白い論文だけど、過大評価はしないほうがいい。これはワークショップ論文で、規模も控えめです。skill 202 本、2モデル、しかも単一プロバイダ(Anthropic の Haiku 4.5 と Sonnet 4.6)の範囲での結果。それともうひとつ、評価の対象になっているのは「その skill がそれなりに役に立つ」と確認できた task/model の組だけです。skill がそもそも役に立たないタスクまで含めた、一般的な平均ではない。著者自身、ライブラリがさらに一桁大きくなったときや、別のアーキテクチャでも同じ傾向が続くかは未解決だ、と書いている。「skill は増やすな」という単純な教訓に畳むのは、たぶん読みすぎです。
まとめると
この論文を一行に畳むと、こうなる。エージェントに正しい手引きを与えるはずの skill が、整理されないまま増えると、それ自体が誤った選択を生む。
厄介なのは、shadowing を起こす skill が、壊れてもいないし悪意で作られてもいないことです。video-frame-extraction は、動画フレーム抽出のタスクにとっては完全に正しい skill。つまり「正しさ」は、skill が単体で持つ性質じゃない。その skill と、いま解こうとしているタスクと、棚に他に何が並んでいるか ── その関係の中で初めて、「正しい手引き」になるか「罠」になるかが決まる。
skill ライブラリを育てるとき、本当に設計すべきなのは、たぶん一本ずつの中身よりも、「どれを選ばせるか」のほうです。
参考
- More Skills, Worse Agents? Skill Shadowing Degrades Performance When Expanding Skill Libraries(Song & Wei, Agent Skills '26)── https://openreview.net/pdf/d0442bc35b36808ccd4a60602430b40597dff620.pdf
- SkillsBench: Benchmarking How Well Agent Skills Work Across Diverse Tasks(arXiv:2602.12670)── https://arxiv.org/abs/2602.12670
- Skill Retrieval Augmentation for Agentic AI(arXiv:2604.24594)── https://arxiv.org/abs/2604.24594
Discussion