同じSkillでも、エージェントが違うと成績は変わる？ 論文6本で分かったこと・まだ分からないこと（2026年10月版）

「Skillは共通形式だから、どのエージェントでも同じように動く」

……本当でしょうか？

形式が共通なのは確かです。でも、同じ形式のファイルを渡せることと、同じ成績が出ることは別の話です。

そこで、Agent Skillsを実際に測った論文を6本、arXivの原文で読みました。要旨だけでなく、表の数字まで確認しています。

先に結論です。

• 成績は変わります。 同じモデルでも、動かすエージェント（harness）が違うと、Skillで伸びる幅が変わっていました。
• 「Skillで良くなる」は平均の話です。 構成ごとに伸びはバラバラで、Skillがほぼ効かない・むしろ悪化する例も報告されています。
• スコアが上がっても、完走率が下がることがあります。 成績は1つの数字で見ないほうが安全です。
• 「同じSkillを、同じ条件で、複数のエージェントに渡して比べた」研究は、まだ限られています。 今の論文から言えることと言えないことを、最後に分けて書きます。

読者は「Skillを自分や社内で作っていて、別のエージェントでも使いたい人」を想定しています。用語はそのつど説明するので、エンジニアでなくても読めます。

入口側（置き場所・呼び出し方・相対パス）の違いは、別の記事で扱っています。この記事で扱うのは 「成績」の側の研究です。

• 同じSKILL.mdは、Claude・ChatGPT・Codex・Cursor・GitHub Copilotで使い回せる？
• Agent Skillsは別のAIエージェントへどこまでそのまま移せる？
• 別のAIエージェントに移したSkill、ちゃんと同じ仕事をしてる？

01まず用語をそろえる

Agent Skillsはエージェントに「この仕事はこの手順でやってね」と教えるフォルダー1つ分の資料です。中心はSKILL.mdというMarkdownで、参考資料やスクリプトも同梱できます。仕様

harness（ハーネス） はモデルを包んで道具やファイルにつなぐ「実行側のプログラム」です。Claude Code、Codex CLI、Gemini CLIなどがこれにあたります。Skillを見つけて読み込むのも、ツールを呼ぶのも、harnessの仕事です。

つまり、同じモデルでも、harnessが違えばSkillの見つけ方・読み込み方・使わせ方が変わる可能性があります。ここが今回の問いの中心です。

with／without比較は同じタスクをSkillなし・ありで解かせて、差を見る方法です。このあと紹介する論文の多くは、この方法を使っています。

02論文6本の早見表

全体を見渡すと、こんな顔ぶれです。どれも2026年のarXivの論文で、査読済みとは確認していません（preprintとして扱います）。数字は著者の報告で、私が追試したものではありません。

出典：SkillsBench、SWE-Skills-Bench、SciVisAgentSkills、SkCC、Skill Coverage、ACES

では、順番に見ていきます。

031. 同じモデルでも、harnessで伸びが違った（SkillsBench）

今回の問いにいちばん直接答えていたのが、SkillsBenchでした。

この研究では87タスクをSkillなしとSkillありの両方で解かせます。決まったテストスクリプトで採点し、AIの判定は使いません。モデルとharnessの組み合わせは18構成。各3試行で比べています。Skillありの条件では、タスクごとに用意されたskills/フォルダーを丸ごと渡します。つまり同じファイルを違うharnessに渡しているわけです。

全体の結果はこうでした。

• 合格率の平均：33.9% → 50.5%（+16.6ポイント）
• 構成ごとの伸び：+4.1〜+25.7ポイント

18構成すべてで伸びてはいます。でも、伸び幅の差は大きく、ほぼ変わらない構成（+4.1）もありました。論文はここを「Skillの効果は、ある構成の経験的な性質であって、普遍の定数ではない」とまとめています。

そして本題です。同じモデルを複数のharnessで動かした組み合わせが3つありました。

SkillsBench Table 2より。OpenHandsは特定のモデル会社に紐づかないオープンソースのharnessです。

この数字から読み取れることは3つあります。

1. Skillありの合格率はharnessで最大8ポイント動く。 Claude Opus 4.7はOpenHandsで53.1%、Claude Codeで61.2%でした。Gemini 3.1 Proも52.8%と60.8%で、差は8ポイントです。
2. ただし、毎回大きく動くわけではない。 GPT-5.5はOpenHandsで67.3%、Codexで66.5%。ほぼ同じです。
3. この3組では、モデルの開発元のharnessのほうが高かった。 Claude Opus 4.7はClaude Code、Gemini 3.1 ProはGemini CLIが、OpenHandsを上回っています。ただしモデル3つだけなので、「自社のharnessが有利」という法則だとは言えません。

論文はこの差を「harnessの見つけ方・プロンプト・実行・ツール利用のループが、Skillで得られる効果を左右する」と説明しています。さらに、Skillの内容を認識しても、実際には呼び出さずに進めてしまうharnessがあるとも書いています。

注意点もあります。

• Skillなしの時点でも、harnessで成績が少し違います（たとえばGPT-5.5は51.5%と46.8%）。ここはharnessの差と、Skillの効果の差が混ざっているので、「Skillが移植で劣化した量」ではありません。
• 試行は各3回です。小さな差はばらつきの範囲かもしれません。
• ターミナルとコンテナ中心のタスクです。GUI操作や長期の業務には一般化できません。
• 論文のバージョンで数字が違います。v1は86タスク中84を評価、7構成、平均+16.2ポイントでした。この記事の数字はv4（2026年6月改訂）です。 版をまたいで混ぜないでください。

042. スコアは上がっても、完走率は下がった（SciVisAgentSkills）

次は科学データの可視化（ParaView、napari、VMD、TTK）のSkillを作って、Claude CodeとCodexの両方で試した研究です。108タスクを各3回走らせています。

どの課題群でも平均スコアは上がりました。 ただし、どれくらい上がるかはエージェントによって違います。

物体同定（object identification）の課題群を見てみます。

• Claude Code＋Sonnet 4.5：スコア41.50→69.13、完走率83.95%→92.59%
• Codex＋GPT-5.2：スコア43.33→47.77、完走率92.59%→80.25%

Codexのほうはスコアが少し上がったのに、最後まで走り切る割合は下がりました。 論文は、Skillで出力の質は上がっても、失敗につながりうる実行経路が増えることがある、と解釈しています。

token（AIが読み書きする文字量。費用に直結）も同じです。同じSkillで、Claude Codeでは出力tokenが減り、Codexでは課題によって増えました。論文はtokenを「Skillの長さの性質」ではなく、Skillとモデルとharnessの組み合わせで決まるものと解釈しています。

つまり、「Skillの成績」を1つの数字にすると、大事な差が消えます。 スコア、完走率、token、時間は別々に見たほうがいいです。

この結果を読むときは、大きく2つの注意点があります。

• Claude CodeはSonnet 4.5、CodexはGPT-5.2です。harnessとモデルが両方違うので、差を「harnessだけのせい」とは言えません。
• スコアにはAI判定（LLM judge）も使われています。人間の業務評価とは同じではありません。

053. Skillが全然効かない場合もある（SWE-Skills-Bench）

ここまでは「Skillは効く。でも幅がある」という話でした。もっと厳しい報告もあります。

SWE-Skills-Benchは、公開されている49のソフトウェア開発向けSkillを、実際のGitHubリポジトリ（コミット固定）で試しました。約565タスクを、Claude Code＋Claude Haiku 4.5で実行。環境はDockerです。

• 49のSkillのうち39は、合格率がまったく変わらなかった
• 平均の伸びは +1.2%
• 意味のある改善が出たのは7件（最大+30%）
• 3件は悪化（最大−10%）。古い版を前提にした指示が、プロジェクトの現状とぶつかったためだと分析されています

さらに、Skillを足してもpass率が変わらないのにtokenだけ最大451%増えた例もありました。

この研究は1つの構成（Claude Code＋Haiku 4.5）だけです。「エージェントを変えたらどうなるか」は測っていません。ここから言えるのは、別のエージェントへ移す前に、Skillそのものがそのタスクと環境に合っているかを確かめる必要がある、ということです。

なお、論文に書かれているコードのURLは、私が確認した時点でHTTP 404でした。公開コードの実物は確認できていません。

064. 「変換」で近づけられるか（SkCC）

harnessごとに成績が違うなら、harnessごとに書き換えればいいのでは？ SkCCはそんな発想の研究です。

Skillを中間表現にして、Claude Code向け・Kimi CLI向けなど、ターゲットごとの書式に変換して出力するコンパイラ的な仕組みです。SkillsBenchの89タスクで、元のSkill（そのまま渡す）と比較しています。

• Claude Code：合格率 21.1% → 33.3%
• Kimi CLI：35.1% → 48.7%

一方で、Kimi向けに変換した出力を、別のモデル（GLM-5.1、DeepSeek-V4-Flash）にそのまま使うと、効果は横ばいか、わずかに悪化しました。論文自体にも「変換の効果はモデルごとに違う」と書かれています。

ここで混ぜてはいけないことが2つあります。

• これは「同じファイルが同じ成績になる」証拠ではなく、「ターゲット向けに作り直したファイルが良くなった」 という実験です。
• 変換は書式だけでなく、安全のための制約も足します。伸びの原因が書式かどうかは切り分けられていません。また、論文に出る「94.8%」は、防御ルールが発動した割合で、攻撃を止めた割合ではありません。

SkCCはまだ under review の preprint です。「変換層が有望かもしれない」という提案として読むのがちょうどいいと思います。

075. 正解しても、手順を試したことにはならない（Skill Coverage）

では、Skillの働きをどう確かめればいいのでしょう？ ここからは「どう測るか」の研究です。

Skillの手順は「入力が不正なら止める」「接続に失敗したら報告する」のように、条件つきの行動で書かれています。タスクが成功しても、そうした分岐が実際に通ったかは分かりません。

Skill CoverageはSkillの文章を条件つきの行動ルールに分解して、エージェントの実行ログ（軌跡）で「通った・守った・破った」を判定します。SkillsBenchの軌跡を分析すると、ルールのうち通っていたのは平均38.66〜45.51% でした。

さらに、守れなかったルールだけを強調してやり直させると、失敗タスクの平均16.0%が回復しました（5構成の平均）。

読み方の注意です。

• 16.0%は「失敗したタスクのうち回復した割合」です。全体の合格率が16ポイント上がった、という意味ではありません。
• 判定はAIが行っていて、誤判定がありえます。軌跡に出ない行動も見えません。

移植のテストに当てはめると、こうなります。通常の入力で1回成功しただけでは、「エラー時の分岐」まで移せたかどうかは分かりません。

086. 文書チェックと、実行評価は別物（ACES）

最後に見るACESは、企業が実際に使うSkillを同じタスク・harness・環境・採点で、Skillあり／なしの組にして評価する枠組みです。NVIDIAのSkillEvaluatorとして実装が公開されると説明されています。

• 145のSkillを、構造と文章のチェック（scan）にかけた
• そのうち64のSkillで実行評価をして、58のSkill・947の採点済みペアを集計

実行評価での「Skill Lift」（0〜1の複数指標の差）は、平均0.2134でした。「業務の成功率が21.34ポイント上がった」という意味ではありません。

注目したいのは、scanの点数と、実行評価の点数があまり相関しなかったことです。構造チェックとAI判定のスピアマン相関は0.14でした。つまり、書類としてきれいかどうかと、実行して効くかどうかは、別の軸なんです。

論文では4つの主要harnessで集計しています。ただし、harnessごとの件数は偏っていて、AI判定と人間の評価のすり合わせ（calibration）は未測定だと書かれています。

09論文6本から、言えること・言えないこと

10まだ分からないこと

ここが、いちばん大事なところかもしれません。2026年10月23日時点で、私が確認した範囲では、次の問いに直接答える研究は見つけられませんでした。

1. モデルを固定して、harnessだけを変えた比較の広がり。 SkillsBenchは3モデルだけです。しかもSkillなしの成績もharnessで違います。
2. Skillの「バイト列を変えない」条件での、発見・起動・参照の成否。 研究は「成績」を見ていて、「ちゃんと読まれたか」までを揃えて測ったものは少ないです。
3. CLIやMCPなど、外部の道具を含む実務のSkill。 SciVisは、CLIとMCPの因果的な比較は対象外だと明記しています。
4. 自分の業務での再現。 ベンチマークはターミナル中心で、GUIや長い業務、組織固有の権限は範囲外です。
5. 独立した追試。 今回の数字はすべて論文の著者の報告です。追試はまだ確認できていません。

なお、検索の網羅性にも限界があります。論文検索ではAPIの制限（HTTP 429）で結果を取得できなかったものがあり、「見つからなかった」と「存在しない」は区別できません。ここで挙げた6本は、私が見つけて原文を確認できたものです。

11自分のSkillで確かめるなら

論文の結論を待たなくても、自分のSkillなら小さく測れます。研究の設計を借りて、最小の手順にするとこうなります。

1. 課題を10個用意する。 入力と正解をセットで。通常の入力だけでなく、不正な入力や、参照資料が読めない場合も1〜2個入れます（Skill Coverageの教訓）。
2. Skillなしで解かせる。 これが基準線です。Skillなしでも解けるなら、Skillの価値はそこにありません（SWE-Skills-Benchの教訓）。
3. Skillありで、各エージェントに3回ずつ解かせる。 1回ではばらつきと区別できません（SkillsBenchは3試行）。
4. 数字を1つにまとめず、4つ別々に記録する。 正解数、最後まで走り切った数、token、時間（SciVisの教訓）。
5. 本当にSkillが読まれたかをログで確認する。 正解でも、Skillを読まずに解けていることがあります。

10問の作り方と、実際に400回回した結果は、別の記事にまとめています。置き場所・相対パスなど入口側の確認は、こちらです。

12この記事で確認したこと、していないこと

確認したこと

• 6本のarXiv論文の要旨を取得し、調査レポートの数字と照合した。
• SkillsBench v4とSciVisAgentSkillsは、HTML版の本文の表まで読み、この記事の表と図の数字を原文から取った。
• SkCCは本文の評価設定とablationの記述を確認した。

していないこと

• 論文の追試、実験の再実行。数字はすべて著者の報告です。
• SWE-Skills-Benchの公開コードの確認（404）。
• Skill CoverageとACESの本文の表の再確認（要旨の数字までを確認）。
• 5つのエージェントで、同じSkillを実際に動かす比較。

13まとめ

• 同じSkillでも、動かすエージェントで成績は変わる。 同じモデルでも、Skillありの合格率が最大8ポイント違う組があった。
• ただし、ほとんど変わらない組もある。差の大きさは構成次第。
• 成績は1つの数字にしない。 スコアが上がって完走率が下がる例があった。
• 形式が共通でも、効くかどうかは別。 49中39のSkillで、合格率が変わらなかった。
• 一番の空白は、「同じSkillを、条件をそろえて、いろいろなエージェントで測る」研究がまだ少ないこと。 ここは、自分のSkillを自分で測ることで埋められます。

「共通だから大丈夫」でも、「どうせ違うから無理」でもなく、10問で測ってから決める。これがいちばん安く、確かな進め方だと思います。