便利なAIスキルが失敗を増やす。307件の差分分析が示した「過剰な手順」の罠
AIエージェントに専門スキルを渡せば、普通は仕事がうまくなると考えます。
テストの手順、実装例、推奨ライブラリ、完了条件。人間が毎回説明しなくても、SKILL.mdを読み込めば同じ知識を再利用できる。これは理にかなっています。
ところが、内容が仕事に合っているスキルでも、失敗を増やすことがあります。しかも原因は「無関係な説明を読ませすぎた」だけではありません。もっと厄介なのは、参考例を必須仕様だと思い込む、正しい成果物を違う場所に置く、確認作業を増やしすぎて本体を終えられない、といった行動の変化です。
2026年8月12日に公開された論文「Agent Skills Can Be Harmful: An Empirical Study of Skill-Induced Failures in LLM Agents」は、この現象を307件の失敗事例から分解しました。
結論を先に言うと、スキル監査では文章の長さだけを見てはいけません。見るべきなのは、そのスキルがタスク固有の要件、実行環境、保存先、検証量をどう変えるかです。
「スキルあり」と「スキルなし」を同じ条件で比べた
研究チームが解きたかったのは、単純な成功率の問題ではありません。
スキルを使った実行が失敗しても、そもそもモデルに能力がなかった可能性があります。逆に成功しても、そのスキルがなくても同じ結果になったかもしれません。失敗した一回だけを見て「スキルが悪い」と断定することはできません。
そこで研究は、差分テストに似た比較を使いました。
- 監査対象のスキルを使う実行をターゲットとする
- 同じタスクをスキルなし、または意味の近い別スキルで実行する
- タスク、モデル、エージェント、リポジトリ、検査器を固定する
- 正誤だけでなく、トークン数、実行時間、ツール操作の軌跡も比べる
ターゲットが失敗し、参照実行が成功したら、スキル誘発の機能失敗候補です。両方成功しても、ターゲットのトークン数と時間がともに増え、どちらかが2倍を超えたら、高信頼の効率悪化候補とします。
ここで参照実行は正解そのものではありません。論文も「擬似オラクル」と明記しています。同じ問題が別のスキル条件なら解けた、または安く解けたことを示す比較対象です。
研究対象は、11分野84タスクのSkillsBenchと、490件のソフトウェア工学タスクを持つSWE-Skills-Benchです。公開スキル共有サイトから意味の近い候補を追加し、比較可能な組み合わせを826から20,664へ広げました。
実行にはOpenCode 1.15.1とClaude Opus 4.6を使っています。そこから自動抽出された665件の候補を、曖昧な事例、検査器が狭すぎる事例、重複事例を除きながら人手で精査し、最終的に307件を残しました。
失敗の68.8%は「関係ないスキル」ではなかった
307件の内訳は、機能失敗125件と効率悪化182件です。
機能失敗で最大だったのは、タスク実装の誤りです。125件中86件、68.8%を占めました。
さらに分けると、必要な要素を間違った方法で実装した事例が46件、必要な要素を省略した事例が36件です。スキルが完全に無関係だった「適用範囲の不一致」は、わずか2件でした。
つまり、危ないのは露骨に場違いなスキルだけではありません。話題としては合っているスキルが、再利用用の例や既定値を、目の前のタスクの必須仕様より強く見せてしまいます。
論文にある表計算タスクでは、純輸出をGDP比のパーセントで求める必要がありました。ターゲット実行は「輸出から輸入を引き、GDPで割る」まで実装しましたが、100倍する処理を落としました。参照実行はパーセント換算まで含めています。
RAGのデモでは、チャンク長、重なり、top-k、モデル設定をすべて変更可能にする必要がありました。スキル例は検索側の引数を詳しく示していたため、ターゲットはそこだけを実装し、モデル名の設定を省略しました。
スキルが嘘を教えたとは限りません。例としては正しくても、例にない要求まで消えたように扱ってしまう。ここが再利用知識の落とし穴です。
正しいものを、間違った場所へ置く
次に多い機能失敗は、成果物の置き場所でした。125件中24件、19.2%です。
論文のLangChainタスクでは、指定された保存先が libs/langchain/langchain/ でした。しかしターゲット実行は、現在のパッケージ構成として自然に見える libs/langchain/langchain_classic/ を選びました。内容がもっともらしくても、検査器が見る場所には何もありません。
実行環境の不一致も13件、10.4%ありました。あるopenpyxlタスクでは、エージェントが古い依存関係を直す代わりに新しいパッケージをインストールし、その外部パッケージで自己検査しました。評価環境は作業中のリポジトリを読み込むため、エージェントの「成功」と実際の評価が分離しました。
この二つは、同じ教訓を持ちます。
再利用スキルより、タスクが明示した保存先、API、出力形式、作業ディレクトリ、依存状態を優先しなければなりません。自然な設計への修正が、依頼への不服従になることがあります。賢く寄り道して、目的地だけ外す。AIエージェント版の「いい感じに直しておきました」です。
コストを増やした主因は、長文より「やることの増殖」
スキルのコスト問題というと、長い指示がコンテキストを圧迫すると考えがちです。それは事実ですが、最大要因ではありませんでした。
182件の高信頼な効率悪化を分類すると、結果は次の通りです。
- 過剰な手順：114件、62.6%
- コンテキスト膨張：46件、25.3%
- 依存関係の解決：22件、12.1%
過剰な手順114件のうち、検証のやりすぎが67件、重い実装パイプラインが30件、探索のやりすぎが17件でした。
コンテキスト膨張46件のうち43件は、毎回読み込まれるスキル本文が原因です。ただし全体で見ると、文章を読む費用より、スキルが追加した行動の費用が大きい。
たとえば「必ず全テストを実行し、失敗をすべて直し、再実行する」という規則は、大きな変更や高リスク領域には必要です。しかし一行の文言修正にも同じ手順を強制すれば、検証は品質管理ではなく固定費になります。
スキル本文を半分に削っても、エージェントが全体ビルド、複数環境、反復デバッグを続けるなら、実行費用はあまり下がりません。短文化だけで終わる最適化は、メニューを薄くしてコース料理の皿数を変えないようなものです。
スキルを「必須」「条件付き」「参考」に分ける
ここからは論文の直接的な結論ではなく、AICompanyによる実務への翻訳です。
最初にできる改善は、スキル内の手順を三段階に分けることです。
必須
守らなければ成果物が壊れる規則です。指定パス、公開API、禁止操作、セキュリティ境界、最小テストなどが入ります。
条件付き
変更の大きさ、影響範囲、不確実性、残り時間に応じて発動する規則です。全テスト、複数環境、性能測定、追加レビューなどをここへ置きます。
参考
実装例、テンプレート、推奨ライブラリ、過去の成功パターンです。タスクの明示要件と衝突したら、タスク側を優先します。
この区別がないと、エージェントは例を仕様にし、チェックリストを儀式にしやすくなります。
導入前に4点だけ機械的に比べる
スキルを使う前に、タスクとスキルから次の四つを抽出します。
- 必須の入力、出力、API、保存先
- 変更してはいけない環境状態
- スキルが追加する探索、依存関係、実装、検証
- 完了条件と中止条件
そのうえで、タスクにあるがスキルにない要素、スキルにあるがタスクにない既定値、両者で異なるパスや依存関係を一覧にします。
論文のSkillTriageも、対象実行と参照実行の差から、環境、実装、保存先、探索、検証、依存修復の証拠を抽出します。人手ラベルとの完全一致は、機能失敗で111件中ではなく125件中111件、88.8%でした。効率悪化では182件中132件、72.5%です。
これは有用な診断補助ですが、予防装置ではありません。すでに失敗差分が確認された事例を、後から分類する道具です。
小さなA/Bテストなら自分の環境でも再現できる
論文の全実験を再現するには多くの実行が必要です。しかし、自分のスキルを点検する小さな比較ならできます。
同じリポジトリの複製を用意し、同じモデル、同じタスク、同じ予算で、スキルなしとスキルありをそれぞれ複数回実行します。比べる項目は成功だけでは足りません。
- 指定されたファイルが正しい場所にできたか
- 必須要素に欠落や勝手な既定値がないか
- 作業環境の依存関係を変更していないか
- 実装前の探索が何手増えたか
- 検証コマンドを何回実行したか
- トークン数と経過時間がどれだけ増えたか
スキルありだけが失敗する、または両方成功してもスキルありだけが2倍以上高コストなら、本文を短くする前に行動差分を見ます。追加された探索、依存導入、ビルド、テスト、再実行のどこで費用が増えたかを特定します。
大切なのは、一回の成功例で合格にしないことです。エージェント実行にはばらつきがあります。複数回の結果と、具体的な軌跡の差を残して初めて、スキルの利益と費用を比較できます。
この研究だけでは分からないこと
結果は強いですが、一般化には限界があります。
第一に、主な実行環境はOpenCode 1.15.1とClaude Opus 4.6です。Codex、Claude Code、別バージョンのOpenCodeで同じ比率になるとは限りません。
第二に、対象はSkillsBenchとSWE-Skills-Benchです。医療、製造、金融を含む複数分野を扱いますが、実運用の長期プロジェクト全体を再現したものではありません。
第三に、失敗原因の分類には人手判断が入ります。研究チームは曖昧な事例を除外し、合議でラベルを確定しました。それでも、実装ミスと省略、環境不一致と保存先ミスの境界には主観が残ります。
第四に、参照実行は正解ではなく擬似オラクルです。別条件で成功したことは、ターゲットとの差を説明する強い証拠ですが、その成功物が最善とは限りません。
第五に、公開されたarXivページからは、307件のデータセットやSkillTriageの実装への直接リンクを確認できませんでした。第三者が同じ数字を再計算できる状態かは、今後の公開状況を追う必要があります。
便利なスキルほど、適用条件を狭く書く
この論文は「スキルを使うな」と言っているのではありません。再利用できる手順は、エージェントを速くし、専門知識を持たせ、組織のルールを守らせる重要な仕組みです。
ただし、便利なスキルほど影響範囲も広くなります。話題が合うだけで自動適用し、例と必須仕様を混ぜ、あらゆる変更に最大級の検証を要求すれば、正しい助言が失敗装置に変わります。
良いスキルは、手順を増やす文書ではありません。
何に使えるか、何を絶対に守るか、どの条件で重い確認を行うか、いつタスク固有の指示へ譲るかを明示する文書です。
スキルの品質は、読んだときの立派さではなく、使わなかった実行と比べて、正しさと費用がどう変わったかで判断する。307件の差分が示す、いちばん実務的な教訓です。
参考資料
※本記事は論文の一次情報を基に、AICompanyが実務への適用方法を独自に整理したものです。AICompanyは論文の実験を独立再現していません。