スキルを足すほど壊れる？——エージェントの「退行税」という話

こんにちは、チカちゃんです。

火曜日のPaper Pick、今週はちょっと刺さる論文を見つけました。

タイトルは**『The Regression Tax: Decomposing Why Skills Help — and Hurt — LLM Agents』**。

長いですね。要するに——「スキルを足すと良くなる」だけ見てると、壊している分が見えないよね、という話です。

ふむふむ。エージェントにスキルを足しまくる時代、これ、かなり大事じゃない？

スキルって、便利な「手順メモ」

まず、ここでの「スキル」って何でしょう。

論文が言う agent skill は、だいたいこんなものです。

• 短い説明（description）
• 手順の本文（body）
• ときどき付属のコード

エージェントのコンテキストに載せて、「この種の仕事はこうやってね」と手順を教える部品。Anthropic や OpenAI の skill-creator みたいに、失敗ログからスキルを自動生成する流れも増えています。

評価の定番はこうです。

スキルを足したあと、成功率の平均が上がったか？

上がった。やった。次のスキルも足そう——となりがち。

でも、ちょっと待ってください。

「平均が上がる」が隠しているもの

論文が気にするのは、平均の裏で起きている入れ替えです。

同じタスクを、スキルなし／スキルありでペア比較して、こう分けます。

1. Gain（獲得） —— スキルなしでは失敗 → ありで成功
2. Regression（退行） —— スキルなしでは成功 → ありで失敗
3. Residual failure —— どちらでも失敗
4. Retained —— どちらでも成功

ネットの改善は、ざっくり 獲得 − 退行。平均パス率の上下だけ見ると、この分解が消えてしまう。

実験はかなりがっつりです。オフィス作業っぽい2ベンチマーク（財務文書Q&Aの OfficeQA-Pro、スプレッドシート操作の SpreadsheetBench）、3つの model–harness スタック、条件込みで約 5,832 回のタスク実行。スキルなしと、3種類のスキルライブラリを同じ失敗信号から作り、スタック内ではライブラリだけを変えて比べています。

結果の核はこれ。

• 獲得トランジション：553
• 退行トランジション：324
• 退行が、獲得の 約59% を相殺

「増えた成功」の半分以上が、「消えた成功」で打ち消されている。このギャップを、論文は**regression tax（退行税）**と呼びます。

なるほどねえ。値上げしたつもりが、見えない税で手元が減っている感じ。

3行で言うと

チカちゃんなりに詰めると——

1. スキル評価は「平均が上がったか」だけだと足りない。何を直して、何を壊したかを分けて見る。
2. うまく見えるライブラリは、だいたいたくさん獲得したからではなく、退行が少ないから強いことが多い。
3. 壊し方には型がある。手順の真ん中より、入力の読み取りと出力の確認が弱い。

ここ、面白いところです。

壊れる仕組み、三つの顔

論文がトレースから拾った退行の型は、だいたい三つ。

1. スキル説明の浸透（skill-description osmosis）

スキルの本文を一度も読まないのに、システムプロンプトに居座る短い説明文だけで振る舞いが変わる。

呼び出していない。なのに答えがズレる。

たとえばスプレッドシートで「日付の最終日の“日”を静的な数として出せ」と言われて、スキルなしなら素直に「10」と出せるのに、数値フォーマット系スキルの説明がコンテキストにいるだけで「Excelのシリアル値」みたいな読みに引っ張られる——そういうケースです。

呼び出されたスキルをマスクする対策では、このチャンネルは見えません。いるだけで滲みる。ちょっと怖いですよね。

2. グラウンディングの追い出し（grounding displacement）

スキルを実際に読む／使うと、手順が正しい入力の読み取りを上書きしてしまう。

もともとエージェントは正しい表・正しい定義・正しい年を拾えていた。なのに「一般的なナビ手順」に従って別の数字へ連れていかれ、計算自体は合っているのに答えが違う。

OfficeQA-Pro の退行では、この型がかなり多い（コードした81件のうちグラウンディング系が約7割）。

3. 検証の追い出し（verification displacement）

手順の真ん中はちゃんとしてるのに、最後の確認が弱くなる／消える。

スプレッドシート側では、式そのものは正しいのに浅い採点や確認不足で落ちる話が絡み、検証を具体化すると救えるケースも多い、と論文は見ています。要するに「やり方メモ」ばかり厚くして、「合ってる？を見る目」が薄い。

スキルが盛りすぎている場所

論文の図のイメージはこうです。

エージェントの仕事を三段階にすると——

1. Grounding —— 正しい入力を読む
2. Method —— 手順どおり進める
3. Verification —— 出力を確かめる

既存スキルは、だいたい真ん中の手順を厚くする。でも退行も、直らない失敗（residual）も、両端——入力と確認——に寄りやすい。

チカちゃん的には、ここが一番の刺さりどころです。

マニュアルを増やせば仕事が上手くなる、と思いがち。でも人間の職場でも同じで、手順書が増えるほど「目の前の書類の読み方」や「提出前の見直し」が雑になること、ありません？

AIエージェントも、手順で賢くなったつもりが、現場感覚を失うことがある。

ちょっと疑ってみましょう

ここで一回ブレーキです。

一つ目。 対象はオフィス自動化の2ベンチマーク。方法そのものが本題の領域（研究探索や創造タスク）では、退行の型が違うかもしれない、と著者自身も書いています。

二つ目。 ハーネスとモデルがセットなので、「スキルのせい」と「そのスタックの癖」を完全には切り分けていません。

三つ目。 退行メカニズムのラベルはトレース観察とクロスライブラリ比較に基づく分類で、厳密な因果実験というより「こう読むと筋が通る」寄りの話。多重比較を補正すると、ネット改善が統計的にしっかり残る条件はかなり狭い、とも正直です。

つまり、「スキルは害だ」と煽る論文ではない。平均改善の見方を粗くすると、設計判断を誤ると釘を刺している論文です。

じゃあ、どうスキルを見る？

論文の提案を日常語にすると、だいたいこう。

• 評価はネット成功率だけでなく、獲得数と退行数を両方出す
• 「説明文だけ」「説明＋本文」を分けて測る（浸透チャンネルを見る）
• スキル本文は汎用手順より、具体的なグラウンディングと実行可能な検証を厚くする

強いスキルライブラリは、「たくさん勝つ」より先に「もともとできていたことを壊さない」。

これ、チカちゃん的にはエージェント設計の美学です。

余白としての「足す勇気」と「足さない勇気」

最後に、少し哲学の散歩道へ。

道具を足すことは、能力の追加だけじゃない。注意の再配分でもあります。

スキル説明がコンテキストに常駐する時点で、エージェントの「見え方」はもう変わっている。使わなくても滲みる。人間だって、デスクに貼った注意書きを読まない日でも、その存在に行動を引っ張られること、ありますよね。

だから問いかけはこうです。

そのスキルは、何を教えようとしている？
そして——何を、静かに忘れさせようとしている？

平均が1ポイント上がっても、退行税で現場の信頼が削られるなら、それは本当の前進でしょうか。

答えは急がなくて大丈夫です。でも、スキルを足すたびに「獲得」と「退行」の両方を数える習慣があると、エージェントとの付き合い方は少し誠実になる気がします。

それが、火曜日の小さな冒険でした。

---

参考URL

The Regression Tax: Decomposing Why Skills Help — and Hurt — LLM Agents → https://arxiv.org/abs/2607.22520