関連スキルもエージェントの足を引っ張る可能性：307件の失敗事例、その多くは誤実装と過剰な検証に起因

エージェントスキルは通常、手順、例、検証ルールを `SKILL.md` にまとめたものだが、「内容がタスクに関連している」からといって、読み込めば必ず有益になるとは限らない。Microsoft Research、華中科技大学などの研究者は、差分監査手法を提案した。モデル、エージェントフレームワーク、タスク、コンテナ、検証器を固定し、スキル構成だけを変更する。スキルありの実行が失敗し、スキルなし、または意味的に類似する別のスキルを使った実行が成功した場合、後者を疑似 oracle として、スキルが引き起こした振る舞いの差分を特定する。[論文](https://arxiv.org/abs/2608.11888)

研究は [SkillsBench](https://www.skillsbench.ai/) と [SWE-Skills-Bench](https://github.com/GeniusHTX/SWE-Skills-Bench) を起点とし、さらに公開スキルサイトから類似候補を検索することで、比較可能なペアを826組から20,664組へ拡大した。証拠が不十分なもの、検証器の対象範囲が狭すぎるもの、重複事例を除外した結果、スキルによって誘発された問題が307件残った。内訳は、機能的失敗が125件、高い確信度で確認された効率低下が182件だった。機能的失敗のうち86件はタスクの実装ミスで、その内訳は、誤った API、値、出力構造を使用したケースが46件、必要な要素を完全に欠落させたケースが36件だった。スキルの適用範囲そのものを誤って判断したことに起因する事例は、わずか2件だった。

効率低下の判定基準は、token 使用量と所要時間の両方が増加し、少なくとも一方が参照実行の2倍を超えることだった。114件は追加手順に起因し、そのうち過剰なテスト、再ビルド、デバッグが67件を占めた。また、スキル本文によるコンテキストの肥大化だけが原因となった事例も43件あった。チームはさらに SkillTriage を用いてペア軌跡を分析し、詳細なサブカテゴリについて、人手によるラベルとの一致率は機能的失敗で88.8％、効率問題で72.5％だった。

エンジニアリング上の示唆は、スキルを無効化することではなく、バージョンごとの評価が必要な実行ポリシーとして扱うことだ。本文は簡潔に保ち、例や完全なチェックリストは必要になるまで読み込まず、変更リスクと残りの予算に応じて検証範囲を調整する。ただし、実験で使用されたのは OpenCode 1.15.1 と Claude Opus 4.6 のみであり、根本原因の分類にも人手による判断が含まれている。この結果が異なるモデルやフレームワーク、企業の非公開スキルでも再現できるかどうかは、今後の検証を待つ必要がある。