LLMエージェントの「リグレッション税」— スキルを追加すると、なぜ性能が下がるのか

スキルを追加した。ベンチマークは上がった。めでたし——本当にそうでしょうか？

arXiv に公開された最新論文（Tank & Nama, arXiv:2607.22520）は、その楽観的な評価に冷水を浴びせます。約 5,832 回の実行を分析したところ、手続き的スキルの追加により 553 タスクが新規に解けるようになった一方で、324 タスクが新規に失敗していたことが判明しました。グロスゲインの 59% がリグレッション（性能後退）で相殺され、純利益はわずか 229 タスクにとどまります。

この記事では、次の 3 点を解説します。

• リグレッション税とは何か、どう測るか
• スキルが失敗を引き起こす 3 つのメカニズム
• エージェント開発者が明日から実践できる対策

リグレッション税とは何か — 「純利益」で見ないと騙される

ゲインとリグレッションは同時に発生する

**手続き的スキル（procedural skill）**とは、エージェントが特定のタスクを実行するための手順・手続きを記述したモジュールです。「Excelのピボットテーブルを作る」「財務文書から数値を抽出する」といった、ステップバイステップの指示をエージェントに与えるものだと考えてください。

スキルを追加すると、「これまで解けなかったタスクが解けるようになる（ゲイン）」と「これまで解けていたタスクが壊れる（リグレッション）」が同時に発生します。多くの評価レポートは「平均スコアが X% 上昇」と報告しますが、これはゲインとリグレッションの内訳を隠したまま提示している状態です。

5,832 回の実行が示した数字

論文の分析結果を図式化すると、以下のようなウォーターフォール構造になります。

スキルなし基準点
    ↑ +553 タスク（新規解決）
    ↓  −324 タスク（新規失敗）
    ────────────────
    純利益 +229 タスク

一見すると「229 タスク改善できた」と読めます。しかし裏側では、これまで正しく動いていた 324 のタスクが壊れているのです。実際の開発現場では、エンドユーザーが既存機能の劣化を体験することになります。

最も重要な発見 — 「良いスキル」の条件は改善量ではない

論文が示した驚くべき知見は、最高性能のスキルの特徴です。それは「新規に解けるタスクが多いこと」ではなく、**「リグレッションが少ないこと」**でした。

評価の軸を「どれだけ改善したか」から「どれだけ壊さなかったか」へと転換することが、スキル品質の正しい見方です。

失敗を引き起こす 3 つのメカニズム

論文の核心は、「なぜスキルがタスクを壊すのか」を実行トレース分析によって 3 つのメカニズムに分解した点にあります。

① スキル説明浸透 — 呼ばなくても汚染される

最も直感に反するメカニズムがこれです。スキルの本体が一度も実行されていないのに、説明文（スキルの概要テキスト）がシステムプロンプトやコンテキストに存在するだけで、エージェントの挙動が変化します。

OfficeQA-Pro のリグレッション 14 件のうち 9 件がこのメカニズムによるものでした。

実務への含意は明確です。「使われていないスキルは無害だ」という前提は誤りです。スキルライブラリの定期棚卸しには、使用率ゼロのスキルを削除する正当な根拠があります。

② グラウンディング置換 — 入力の読み取りが壊れる

最大の要因がこれで、OfficeQA-Pro の 81 件中 59 件を占めます。スキルに記述された汎用的な手順が、入力段階でエージェントを誤ったデータや定義へ誘導します。

論文が示す具体例は印象的です。あるエージェントは、1934 年の統計文書に記載された数値「549」をスキルなしでは正確に読み取れていました。しかしスキル追加後、同じ値を「949」と誤読するようになったのです。スキルの「表から数値を抽出する」という汎用的な手順が、具体的な事実確認の処理を上書きしてしまったと考えられます。

抽象度の高い手順書ほど、具体的な入力情報との整合確認を阻害する傾向があります。

③ 検証置換 — 出力チェックが抑制される

SpreadsheetBench において、スキル追加後に 226 件の正しい数式が値のみ採点で「失敗」と判定されました。スキルの手順が、出力段階のセルフチェックや検証ステップを飲み込んでしまったことが原因です。

重要なのは、採点方法を実行ベースに切り替えて再評価すると、+11〜+49 タスクが回復したことです。これは「本当の性能劣化」と「採点方法の問題」を切り分けることの重要性を示しています。

3 つのメカニズムの共通構造

3 つに共通するのは、スキルが「加算」ではなく「置換」として機能するという構造です。手順の追加は、既存の暗黙的な良い振る舞い（事実確認、出力検証、具体的な読み取り）をオーバーライドします。このことを理解すると、スキル設計の判断基準が根本的に変わります。

実験はどう組まれたか — 結論を信じてよい根拠

2 つのベンチマーク

モデル × ハーネスの 3 構成

論文は特定のモデルやフレームワーク固有の癖を排除するため、以下の 3 構成でクロス検証を行っています。

• OpenCode / minimax-m2.7
• Codex / GPT-5.4-mini
• Claude Code / sonnet-4.6

これにより、今回の発見がモデル依存の現象ではないことが担保されています。Claude Code のスキル機構を使っている開発者にとっても、直接関係する知見です。

統計的裏付けとトレース分析

有意性検定には McNemar 正確検定を採用し、集計値レベルの確認を行っています。さらに重要なのは、集計だけでなく実行トレースを 1 件ずつ読んで失敗段階を分類したことです。この丁寧なトレース分析こそが、3 つのメカニズムを特定できた根拠です。

この研究の限界（正直に書く）

ベストプラクティスとして、論文の限界も明示します。ベンチマークがドキュメント QA と表計算に偏っており、コーディングや会話タスクでの再現性は未確認です。また、スキル記述の品質差をどこまで統制できているかという点も、今後の検証が必要です。ただし、3 モデルのクロス検証という実験設計の堅牢さは評価できます。

スキルは増やすほど悪化する — スキルシャドーイング問題

リグレッション税と同時に理解すべき関連研究があります。arXiv:2605.24050「More Skills, Worse Agents?」では、スキルライブラリが 202 個に拡大すると最大 21% の性能低下が確認されています。

主犯はコンテキスト長ではない

性能低下の主因として疑われやすいのは「プロンプトが長くなること」です。しかし分析の結果、コンテキストオーバーヘッドの影響は小さく有意でないことが示されました。

真の主因はスキルシャドーイングです。関連する複数のスキルが干渉し合い、エージェントが正しいスキルを選択できなくなる現象です。ライブラリサイズに比例してシャドーイングは増大します。「長いから悪い」ではなく「紛らわしいから悪い」という結論は、実装上の対策を根本的に変えます。

リグレッション税との掛け算

• 1 スキルあたりのリグレッション税 × スキル数 = ライブラリ全体の負債

スキルを「無料で追加できる機能」として扱っている運用が最も危険な状態です。段階的に理解を深めていくと、スキルライブラリはコードの依存関係と同様に管理コストを伴う資産であることが見えてきます。

開発者が今日からできる対策と設計指針

評価の作り方を変える

実際の開発現場でまず変えるべきは、スキルの評価方法です。

• パスレートの差分ではなく「ゲイン数 / リグレッション数」に分解して報告する
• スキルあり / なしのタスク単位のペア比較を必ず記録・保存する
• 採点が値一致依存になっていないか確認し、実行ベース採点を検討する

Osmosis を切り分ける A/B 設計

スキル説明浸透の有無を定量化するには、以下の 3 条件を比較するだけで実現できます。

条件 1 と条件 2 の差が、そのまま「置いてあるだけの汚染」の量です。

スキルの書き方 3 原則

① 汎用的な手続きより、具体的なグラウンディング情報を書く 「数値を抽出する」ではなく「列 B の単位は百万ドルであり、A5:A20 の範囲から抽出する」のように、抽象度を下げた具体記述がグラウンディング置換の対策になります。

② 実行可能な出力検証をスキル内に埋め込む 「最後に回答が入力と整合するか確認する」という手順を明示的に書くことで、検証置換を防ぎます。値を返すだけでなく、検証ステップを手順として含めることが重要です。

③ 手続きステージより「入力グラウンディング」と「出力検証」を厚くする 何をするかの手順より、何を読むか・何を確認するかを充実させる設計が、3 つのメカニズムすべてへの横断的な対策です。

実装チェックリスト

スキルを追加するたびに確認してください。

• スキル追加前後で同一タスクセットを実行し、ペアで差分を出した
• 新規失敗タスクを 1 件ずつトレースで読み、入力・出力どちらの段階か分類した
• 説明のみ条件での A/B を取り、Osmosis の有無を確認した
• 採点が値一致依存になっていないか確認した
• スキルに具体的なデータ定義・参照先を書いた
• スキルに検証ステップ（実行可能なもの）を含めた
• 3 ヶ月使われていないスキルを棚卸しした

まとめ — スキルは資産ではなく、負債込みの投資

「スキルを足せば賢くなる」という直感は、純利益で見ると半分しか正しくありません。グロスゲインの 59% がリグレッションで相殺されるという数字は、スキル追加を「無料の機能拡張」と見なしてきた従来の認識を根底から揺るがします。

論文が示す最も実践的な教訓をまとめると：

• 良いスキルの条件は「壊さないこと」。改善量ではなくリグレッション量で評価する
• 説明文はコンテキストに入れるだけでコストが発生する。使われていないスキルは無害ではない
• 手続きより、グラウンディングと検証を厚くする。抽象的な手順書はリスク要因になる

次のアクションとして、まず 1 つだけ試してください。手元のエージェントに対して、スキルあり / なしで同一タスクセットを実行し、ペア単位で差分を確認する——これだけです。

あなたのスキルライブラリ、リグレッションを測ったことはありますか？

参考文献

• Tank & Nama, The Regression Tax: Decomposing Why Skills Help and Hurt LLM Agents, arXiv:2607.22520
• More Skills, Worse Agents? Skill Shadowing in LLM Agent Systems, arXiv:2605.24050