はじめに

Claude Code や Codex を使っていると、Skill（スキル） を追加する場面が増えてきました。Skill は、AI エージェントに「この種類の仕事はこう進める」と教えるための手順書フォルダです。公開されている Skill を入れたり、自分で書いたり、AI に書かせたりしている方も多いと思います。

ただ、ここで 1 つ疑問が残ります。その Skill は、本当に役に立っているのでしょうか。 入れたあとに「なんとなく賢くなった気がする」と感じても、Skill のおかげなのか、たまたまなのかは区別がつきません。

この疑問に、実験で答えようとした研究が SkillsBench です。同じ課題を「Skill なし」と「Skill あり」の両方で AI に解かせて、合格率がどれだけ変わるかを測りました。この記事では、SkillsBench の論文と公開データを読み、次の 3 つの問いへの答えを整理します。

Skill を入れると、本当に解けるようになるのか
AI に Skill を自作させても、同じ効果が出るのか
たくさん・詳しく書くほど、よく効くのか

先に結論を図で見てください。問いと答えが上から順に強調されます。

この図から分かること：人が選んで磨いた Skill は合格率を平均 16.6 ポイント上げた。一方、AI に書かせた Skill や、量の多い Skill は期待ほど効かなかった。

想定読者は、Claude Code・Codex・Gemini CLI などを使い始めた方と、チームで Skill を整備しようとしている方です。論文や統計の知識は前提にしません。用語は出てくるたびに説明します。

この記事の確認範囲

確認日：2026 年 11 月 12 日
読んだもの：論文「SkillsBench: Benchmarking How Well Agent Skills Work Across Diverse Tasks」（arXiv 2602.12670）の初版 v1（2026 年 2 月 13 日）と最新版 v4（2026 年 6 月 14 日）の本文と付録、公式サイト skillsbench.ai のリーダーボード（2026 年 7 月 16 日に再計算されたもの）、公式ブログ「SkillsBench 1.1」（2026 年 6 月 16 日）、GitHub の公開リポジトリにある課題と Skill の実物、Liner による論文の要約ページ
手元ではベンチマークを実行していません。数字はすべて論文と公式サイトの値です
この論文は初版と最新版で数字がかなり違います。 ネット上の紹介記事の多くは初版の数字を使っています。この記事は最新版を基本にし、初版との違いは 1 つの節にまとめました

背景：Skill・ハーネス・ベンチマークという 3 つの言葉

本題に入る前に、3 つの言葉をそろえておきます。

Skill（Agent Skills） は、ある種類の仕事のやり方をまとめたフォルダです。中心になるのは SKILL.md という 1 枚の文書で、冒頭に名前（name）と 1 行の説明（description）、そのあとに手順や注意点を書きます。必要に応じて、そのまま動かせるスクリプトや参考資料も同じフォルダに入れます。2025 年に Anthropic が仕様を公開し、今では Codex や Gemini CLI なども同じ形式を読めます。

Skill の数は急に増えています。論文の集計では、公開されている Skill は初版の時点で約 4.7 万件でしたが、最新版の時点では約 201 万件（配布元ごとに重複を除いて合計した数）になりました。中身を取得できた約 77 万件を調べると、約 6 割は SKILL.md が 1 枚だけの小さなものでした。数が増えるほど、「どれが本当に効くのか」を確かめる方法が必要になります。

ハーネス（agent harness） は、AI モデルを包んで実際の作業をさせる道具のことです。Claude Code、Codex CLI、Gemini CLI、OpenHands などがこれにあたります。ファイルを読み書きする、コマンドを実行する、Skill を見つけて読み込む、といった仕事はハーネスが受け持ちます。

ベンチマークは、AI の実力を同じ条件で比べるための課題集です。

論文は、この関係をパソコンにたとえています。モデルが CPU、ハーネスが OS、Skill がアプリです。次の図で、下の層から順に確認してください。

この図から分かること：Skill はただのファイルなので、モデルを作り直さずに足せる。ふだん読まれるのは名前と 1 行の説明だけで、関係がありそうなときに初めて本文が開かれる。

図の右下に書いた「必要なときだけ本文を開く」仕組みは、段階的開示（progressive disclosure） と呼ばれます。この仕組みのおかげで Skill をたくさん置けるのですが、裏を返すと、説明文が的外れだと本文は読まれません。 この点は、あとで出てくる「自作 Skill が効かなかった理由」に関係します。

Skill と、よく似たほかの方法との違いも表にしておきます。論文の Table 1 をもとに、言葉を補いました。

方法	部品として使い回せるか	手順を教えられるか	実行できるコードを持てるか
プロンプトに直接書く	×	少しだけ	×
RAG（資料を検索して渡す）	○	×（事実を渡すのが中心）	×
ツール（関数を呼ばせる）	○	×（機能の説明が中心）	○
Skill	○	○	○

SkillsBench の測り方：Skill の有無だけを変える

なぜ新しいベンチマークが必要だったのか

これまでのベンチマークは、「このモデルは課題を何割解けるか」を測るものでした。モデルの力、ハーネスの力、追加した知識の力が、1 つの点数に混ざっています。これでは「Skill を足したら何ポイント良くなるか」は分かりません。

SkillsBench は、同じ課題を、Skill の有無だけを変えて解かせます。 課題の指示文、データ、実行環境、採点方法は同じです。この方法をペア評価と呼びます。次の図で、1 つの課題が 3 つの条件に分かれ、同じテストで採点される流れを追ってください。

この図から分かること：見るのは「Skill ありの点数」ではなく「Skill を足したときの差」。採点はプログラムによるテストで、AI に採点させていない。

3 つの条件を言葉でも整理します。

Skill なし：指示文とデータだけを渡して解かせます。
厳選 Skill あり：その分野に詳しい人が用意した Skill を、作業フォルダに置いておきます。指示文は「この Skill を使え」とは言いません。AI が自分で見つけて使う必要があります。
自作 Skill：先に AI 自身に Skill を書かせ、その Skill だけを置いて解かせます。この条件は一部の構成だけで試されています。

合否の判定には pytest（Python のテスト実行ツール）を使います。成果物のファイルを機械的に検査し、すべての検査を通れば合格です。AI に出来ばえを採点させる方法は、結果がぶれるため使っていません。

課題の中身：実務に近い 87 件

課題は、学校の練習問題ではなく、専門家が実際に行う仕事から作られています。最新版では 8 分野・87 件です。難しさは「その分野の専門家が AI なしで解くと何時間かかるか」で分けられ、1 時間未満が 6 件、1〜4 時間が 53 件、4 時間超が 28 件でした。

具体例を 1 つ紹介します。公開リポジトリにある flood-risk-analysis（洪水リスク分析）という課題の指示文は、要約すると次のような短いものです。

ミシガン州の観測所の水位データがある。2025 年 4 月 1〜7 日に洪水が起きた観測所を探し、観測所の ID と洪水の日数を CSV に出力せよ。

指示は数行ですが、正しく解くには「15 分おきの観測値を日ごとの最大値に直す」「洪水と判断するしきい値は米国の国立気象局の基準を使う」といった、その分野の決まりごとを知っている必要があります。この課題には Skill が 3 つ付いていて、データの取り方、しきい値の調べ方、洪水日の数え方がそれぞれ短くまとめられています。

結果は、Skill なしの合格率が 1.9%、Skill ありが 68.5% でした。モデルの頭の良さではなく、「その業界の手順を知っているかどうか」で差がつく課題だと分かります。

課題の選び方：Skill を「答えのメモ」にしない

ペア評価には落とし穴があります。Skill に課題の答えが書いてあれば、合格率が上がるのは当たり前です。それでは「指示どおりに写せるか」を測っているだけになります。

そこで SkillsBench は、課題の採用にかなり厳しい審査を置いています。次の図で、400 件の応募が 87 件に絞られる流れを見てください。

この図から分かること：採用率は 22%。Skill に課題固有のファイル名・数値・コマンドを書くことは禁止されている。一方で「Skill の有無で差が出ない課題」は落とされている。

審査のポイントは次のとおりです。

指示文は人が書く：AI が書いた指示文は、評価される AI 自身のくせを引き継ぐため認められません。検出ツールと人の目で確認します。
Skill は「その種類の仕事」に使えるものに限る：1 つの課題だけに通用する答えは書けません。課題固有のファイル名、数値、解答そのもののコマンド列が Skill に入っていないかを、自動で検査します。
お手本の解答が必ず通る：人が用意した解答でテストに 100% 合格することを確認し、解けない課題や壊れたテストを除きます。
人が 30 分以上かけてレビューする：データが本物か、現実の仕事に近いか、抜け道がないかを確認します。

図の最後に書いた注意点は大事です。レビューでは「Skill の有無で差が出ない課題」は不採用になります。つまり、残った 87 件は Skill が効きやすい課題に寄っています。 この点は、あとの「結果を読むときの注意」でもう一度取り上げます。

論文は 6 月に大きく更新された

結果に入る前に、1 つ断っておくことがあります。SkillsBench の論文は、2026 年 2 月の初版から 6 月の最新版（v4、公式には SkillsBench 1.1）で、実験の規模も数字も大きく変わりました。

ネット上でよく見かける次の数字は、すべて初版のものです。

7 つの構成、7,308 回の実行
厳選 Skill で平均 +16.2 ポイント
2〜3 個の Skill で +18.6、4 個以上で +5.9
Skill ありの Haiku 4.5（27.7%）が、Skill なしの Opus 4.5（22.0%）を上回った
Claude Code は Skill をよく使い、Codex CLI は Skill を無視しがち

次の図で、初版と最新版を項目ごとに並べました。

この図から分かること：「厳選 Skill は効く」という主な結論は変わらず、数字もほぼ同じ。ただし自作 Skill の評価は「ほぼ変わらない」から「はっきり悪化」に変わった。

著者も増えています。初版は 40 人で、所属は BenchFlow（このベンチマークを運営する企業）、Amazon、オハイオ州立大学、スタンフォード大学、カーネギーメロン大学、カリフォルニア大学バークレー校などでした。最新版は 78 人・36 の所属になり、AI の安全性研究で知られるバークレー校の Dawn Song 教授が助言役として加わっています。

試した組み合わせも変わりました。初版は Claude Code・Codex CLI・Gemini CLI の 3 つのハーネスと 7 つのモデルでした。最新版は、オープンソースのハーネス OpenHands を加えた 4 つのハーネスで、GPT-5.5、Claude Opus 4.8、Gemini 3.1 Pro、GLM 5.1 など 18 通りの組み合わせを試しています。以下、この組み合わせを「構成」と呼びます。

ここから先の数字は、断りがない限り最新版のものです。

結果 1：厳選 Skill は平均で 16.6 ポイント効く

最初の問い「Skill を入れると、本当に解けるようになるのか」の答えです。次の図は、18 構成のうち 7 つを抜き出したものです。灰色が Skill なしの合格率、青が Skill を足して伸びた分です。

この図から分かること：18 構成すべてで合格率が上がった。ただし伸び幅は +4.1 から +25.7 まで広く、一律ではない。

ここで「ポイント」という言葉を確認しておきます。合格率が 33.9% から 50.5% になったとき、その差の 16.6 を「16.6 ポイント上がった」と言います。「16.6% 増えた」とは意味が違うので注意してください。

18 構成すべての結果は次の表のとおりです（論文 Table 2）。

ハーネス	モデル	Skill なし	厳選 Skill	伸び
OpenHands	GPT-5.5	51.5%	67.3%	+15.8
Codex	GPT-5.5	46.8%	66.5%	+19.7
Claude Code	Opus 4.7	43.0%	61.2%	+18.2
Gemini CLI	Gemini 3.1 Pro	36.0%	60.8%	+24.8
OpenHands	GLM 5.1	32.7%	58.4%	+25.7
OpenHands	Claude Opus 4.8	45.7%	54.1%	+8.4
OpenHands	Kimi K2.6	33.4%	54.0%	+20.6
OpenHands	Claude Opus 4.7	42.1%	53.1%	+11.1
OpenHands	MiniMax M3	29.7%	53.0%	+23.3
OpenHands	Gemini 3.1 Pro	33.8%	52.8%	+19.0
OpenHands	DeepSeek V4 Pro	26.9%	50.1%	+23.2
OpenHands	Gemini 3.5 Flash	41.1%	48.2%	+7.1
OpenHands	Claude Sonnet 4.6	33.5%	47.2%	+13.6
OpenHands	DeepSeek V4 Flash	27.5%	44.7%	+17.2
OpenHands	Grok 4.3	22.8%	41.7%	+18.8
OpenHands	GPT-5.4 Mini	29.9%	41.4%	+11.5
OpenHands	MiniMax M2.7	18.1%	34.9%	+16.8
OpenHands	Gemini 3.1 Flash Lite	16.0%	20.1%	+4.1
平均		33.9%	50.5%	+16.6

表から読み取れることを 3 つ挙げます。

1 つ目は、いちばん強い構成でも合格率は 67% だということです。 Skill を足しても、3 回に 1 回は失敗します。失敗の中身を見ると、時間切れやエラーは少数で、約 9 割は「最後まで作業したがテストに通らなかった」ものでした。Skill は万能の解決策ではありません。

2 つ目は、もともと強い構成ほど伸びるわけではないことです。 いちばん伸びたのは OpenHands と GLM 5.1 の組み合わせ（+25.7）でした。逆に、OpenHands と Gemini 3.5 Flash は Skill なしで 41.1% と高いのに、伸びは +7.1 にとどまっています。

3 つ目は、同じモデルでもハーネスで結果が変わることです。 Gemini 3.1 Pro は Gemini CLI だと 60.8% ですが、OpenHands だと 52.8% です。Claude Opus 4.7 も Claude Code では 61.2%、OpenHands では 53.1% でした。Skill をどう見つけ、どう読ませるかはハーネスの仕事なので、ここで差がつきます。

分野ごとの差：モデルが知らない手順ほど効く

分野ごとに見ると、伸び幅には 3 倍近い開きがあります（論文 Table 3）。

分野	課題数	Skill なし	厳選 Skill	伸び
自然科学	14	42.0%	70.8%	+28.8
メディア・コンテンツ制作	5	23.3%	47.4%	+24.1
サイバーセキュリティ	7	29.5%	48.4%	+18.9
産業・物理システム	14	23.9%	39.6%	+15.7
金融・経済	9	19.1%	33.3%	+14.2
オフィス業務	14	40.5%	53.0%	+12.6
ソフトウェア開発	16	37.6%	49.2%	+11.6
数学・最適化	8	45.7%	55.4%	+9.7

伸びが大きいのは、地震や水文の解析、動画や 3D データの変換、侵入検知といった、業界ごとの決まった手順がある分野です。こうした手順は、モデルが学習したデータの中に十分には含まれていないと考えられます。

逆に、ソフトウェア開発や数学は伸びが小さめでした。プログラミングの知識はモデルがすでによく知っているので、Skill で足せる分が少ないということです。Claude Code で普通のコーディングをしている場面は、Skill の効果がいちばん出にくい側にあたります。

なお、課題数が 5 件や 7 件の分野は、1 つの課題の結果で数字が大きく動きます。論文も、この 2 分野は参考値として扱うよう書いています。初版で目を引いた「医療分野で +51.9 ポイント」という数字も、付録の課題一覧を見ると 2 課題だけの分野でした。最新版では分野の分け方が変わり、この数字はなくなっています。

結果 2：AI に書かせた Skill は逆効果だった

2 つ目の問いは「AI に Skill を自作させても、同じ効果が出るのか」です。Skill を書くのは手間がかかるので、AI に任せたくなります。SkillsBench はこれも試しました。

最新版の手順は次のとおりです。まず、作成担当の AI に課題の指示文と環境を見せ、Anthropic が公開している Skill 作成用の Skill（skill-creator）を使って Skill を書かせます。このとき「課題そのものは解くな」と指示します。次に、まっさらな別の AI に、その Skill だけを置いた状態で課題を解かせます。

次の図の左側が結果です。3 つの構成それぞれについて、Skill なし・自作 Skill・厳選 Skill の合格率を並べました。

この図から分かること：自作 Skill は 3 構成すべてで Skill なしを 8.1〜11.5 ポイント下回った。同じ構成で厳選 Skill は 18.2〜24.8 ポイント上げている。

「効果がない」ではなく「ないほうがまし」という結果です。論文は実行記録を 12 本調べ、理由を 4 つ挙げています。

そもそも読まれない：Codex と Gemini CLI の記録では、12 本中 10 本で、解く側の AI が自作 Skill に一度も触れていませんでした。人が用意した Skill はハーネスの仕組みで見つけられたのに、自作のものは見つけられなかったということです。
書く作業が、解く作業を圧迫する：Claude Code の実験では、作成と解答が同じ実行の中で続けて行われました。Skill を書くことに時間を使い切り、解答を出す前に終わった例があります。
自信満々の間違いが固定される：3D データから部品の重さを求める課題で、自作 Skill は「重要な注意点」として「座標の単位はミリメートル」と書き、1000 倍の換算を組み込みました。解く側はそれを疑わずに使い、答えが 3 桁ずれました。人が書いた Skill には、正反対の「ミリメートルと決めつけないこと」という注意が書かれていました。なお論文は、この課題の採点がのちに見直され、ミリメートルと解釈した答えも認めるよう直されたと注記しています。個別の例は割り引いて読む必要がありますが、3 構成とも下がったという全体の向きは変わらない、というのが著者の説明です。
勝った例は「答えの書き写し」だった：自作 Skill のほうが良かった数少ない例では、作成担当が採点対象の環境を見て、その課題専用の答えを Skill に書いていました。使い回せる手順ではなく、カンニングに近いものです。

3 つ目は特に教訓になります。Skill は「信頼できる手順書」として読まれるので、間違いが書いてあると、AI はそれを疑わずに従います。 何も渡さなければ自分で確かめたかもしれないことを、Skill が止めてしまうわけです。

初版との違いと、読むときの注意

この実験は、初版と最新版でやり方が違います。初版では、指示文の末尾に「解く前に、役立ちそうな Skill を 1〜5 個書いてから解きなさい」と足すだけでした。結果は 5 構成の平均で −1.3 ポイントで、「ほぼ効果なし」という結論でした。最新版は作成と解答を別の AI に分けた、より本格的な方法です。

また、著者自身が限界を認めています。最新版の −8〜−12 ポイントという数字には、Skill の中身の質だけでなく、「読まれなかった」「作成が解答を邪魔した」という実験の組み方の影響も混ざっています。「AI は良い Skill を書けない」とまでは言い切れません。

言えるのは、「AI に Skill を作らせて、中身を確かめずに入れておく」やり方は、この実験では役に立たなかったということです。AI に下書きを書かせること自体が悪いのではなく、人が中身を確かめ、説明文で正しく呼び出されるかを見る工程が要る、と読むのが妥当だと考えます。

結果 3：Skill は「少なく・短く」が強い

3 つ目の問いは「たくさん・詳しく書くほど、よく効くのか」です。次の図で、左に Skill の個数、右に SKILL.md の長さごとの伸び幅を示します。

この図から分かること：Skill が 4 個以上の課題は伸びが半分ほど。何でも書いた網羅的な文書は、ほとんど効いていない。

個数について見ると、1 個の課題は +18.0、2〜3 個は +19.0 で、4 個以上になると +10.1 に落ちます。論文は、読む負担が増えることと、指示どうしがぶつかることを理由に挙げています。

長さについては、短いもの（+19.0）と標準的なもの（+21.5）がよく効き、詳しいもの（+14.5）はやや下がり、網羅的な長い文書は +0.7 でした。

論文は、伸びが大きかった上位 10 課題の Skill を調べて、効く Skill に共通する 5 つの型も挙げています。

そのまま動くスクリプトを同梱している（アルゴリズムを文章で説明するだけにしない）
使うべきデータの出どころと、読み込むときのくせを名指ししている
成果物のファイル形式の決まりを具体的に書いている
結果が満たすべき条件（検算に使える性質）を書いている
説明文（description）が具体的で、AI が最初の一読で「これだ」と分かる

共通しているのは、「AI が自力では推測できない、細かいが決定的な情報」に絞っている点です。一般的な解説を長く書いても、AI はすでに知っているので効きません。

1 つ注意があります。この比較は、同じ課題で Skill の個数や長さを変えて試したものではありません。課題ごとに付いている Skill は決まっているので、「4 個以上の Skill が付く課題は、もともと難しい課題だった」という可能性が残ります。網羅的な文書にあたるのも 5 課題だけです。「少なく・短く」は有力な目安ですが、証明された法則ではない、と受け取ってください。

結果 4：Skill は、モデルの実力差をある程度埋める

論文は、Skill がモデルの実力差をある程度埋めることも示しています。Skill なしでは下にいたモデルが、Skill を足すと、Skill なしの上位モデルを追い抜く例です。公式サイトのリーダーボードと公式ブログから、分かりやすい例を 3 つ拾いました。

Skill を足したモデル	Skill なし → あり	追い抜いた相手（Skill なし）	合格率
Claude Haiku 4.5（Claude Code）	8.8% → 30.1%	Claude Opus 4.5（Claude Code）	23.8%
MiniMax M2.7（OpenHands）	18.1% → 34.9%	GLM 5.1（OpenHands）	32.7%
GLM 5.1（OpenHands）	32.7% → 58.4%	Claude Opus 4.8（OpenHands）	45.7%

1 行目は、初版で「Haiku 4.5 が 27.7%、Opus 4.5 が 22.0%」と報告されて話題になった比較です。最新の課題セットで測り直した公式リーダーボードでも、同じ関係が保たれていました。

これは費用の面で意味があります。論文の付録によると、1 回の実行にかかった API 費用は、いちばん合格率が高かった OpenHands と GPT-5.5 の組み合わせで約 1.67 ドル、OpenHands と Claude Opus 4.8 の組み合わせで約 14.02 ドルでした。良い Skill を用意できる仕事なら、いちばん高いモデルを使わなくても済む場面がある、ということです。

また、Skill を足しても作業時間はほとんど増えていません。公式ブログによると、1 課題あたりの平均時間は Skill なしで 14.5 分、Skill ありで 13.8 分でした。使うトークン数は、増える構成と減る構成の両方があります。Skill を読む分だけ増える場合もあれば、手探りの試行錯誤が減って少なく済む場合もあるためです。

ただし、表の比較は「Skill あり」と「Skill なし」という別の条件どうしです。上位のモデルにも同じ Skill を足せば、さらに上に行きます。「下位のモデルのほうが優れている」という意味ではありません。

結果 5：Skill を「読んだ割合」と「解けた割合」は別

初版には、「Claude Code は Skill の活用度がいちばん高く、Codex CLI は Skill の内容を認識しながら使わずに自力で解くことが多い」という観察が書かれていました。この部分はよく引用されています。

最新版では、この点を数字で測り直しています。Skill 読み込み率（Skill Invocation Rate） は、Skill ありの実行のうち、AI が課題に付いた Skill を実際に読んだ、または使った実行の割合です。次の図で、紫の棒が読み込み率、緑の棒が合格率です。

この図から分かること：読み込み率は 46% から 99% まで幅がある。読み込み率が高い順に合格率が並ぶわけではない。

最新版の数字では、読み込み率がいちばん高いのは Codex と GPT-5.5 の組み合わせ（99.2%）で、Claude Code と Opus 4.7 は 68.2% でした。初版の観察とは逆の並びです。

ただし、「逆転した」と単純には言えません。モデルは GPT-5.2 から GPT-5.5 に、Opus 4.5 から Opus 4.7 に変わり、ハーネスも更新されています。初版は割合の数字を示さない観察で、最新版は実行記録を数えた結果です。確かなのは、「Codex は Skill を使わない」という初版の印象は、最新版のデータでは裏づけられないということです。ハーネスの比較は数か月で変わるので、古い記事の結論をそのまま信じないほうが安全です。

もう 1 つ読み取れるのは、読み込み率と合格率が別物だという点です。Claude Code と Opus 4.7 は読み込み率が 68.2% でも合格率は 61.2% あります。論文は「Skill を見つけることは、たいていの場合ボトルネックではない。失敗の多くは Skill を読んだあとで起きている」とまとめています。

Skill が足を引っ張る 3 つの型

平均では効く厳選 Skill も、課題によっては逆効果になります。最新版では、87 課題のうち 13 課題で、Skill を足すと合格率が下がりました。下がり幅は最大で 7.4 ポイントです。

論文は、下がった課題の実行記録を Skill なしの場合と見比べて、3 つの型に分けています。次の図で、型と対策を対応させて見てください。

この図から分かること：3 つの型に共通するのは、「唯一の正しい手順」だけを書き、使う場面の境目や逃げ道を書いていないこと。

A：手順が重すぎる　理屈としては正しい本格的な方法を指定した結果、もっと簡単に正解へたどり着ける道を AI が選べなくなります。
B：得意なやり方を押しのける　一般的なレシピが、モデルがもともと持っていた、より良い解き方を上書きしてしまいます。
C：直せない道具へ誘導する　壊れやすい道具や厳密な形式を必須にしたために、エラーの修正で行き詰まります。

論文はこの対策として、SKILL.md の冒頭に「この手順はどれくらい重いか」「どんな場合に使い、どんな場合は使わないか」「うまくいかないときの軽い代替手段」を書く欄を設けることを提案しています。まだ提案の段階ですが、自分で Skill を書くときにすぐ取り入れられる考え方です。

自分の Skill に活かす

ここからは、SkillsBench の結果を手元の Skill づくりにどう使うかをまとめます。この節は論文の内容そのものではなく、結果をもとに筆者が整理したものです。

書く前に確かめる順番

次の図は、Skill を入れるかどうかを決めるときの確認の順番です。

この図から分かること：出発点は「AI が素ではつまずく作業かどうか」。最後は必ず、あり・なしを比べて確かめる。

AI が素ではつまずく作業かを確かめる。 まず Skill なしで何回かやらせてみます。問題なくできる作業に Skill を足しても、効果は小さく、かえって下がることもあります。
手順・形式・落とし穴を、短く具体的に書く。 1 つの作業につき 1〜3 個に収めます。一般的な解説は削り、AI が推測できない情報に絞ります。
あり・なしを同じ条件で比べる。 同じ依頼を、Skill を置いた状態と置かない状態でそれぞれ 3 回以上実行し、結果を比べます。合否は、できれば目視ではなく、テストやチェック用のスクリプトで判定します。
モデルやハーネスを替えたら測り直す。 同じ Skill でも、組み合わせで効き方が変わるためです。

SKILL.md の書き方の例

効く Skill の 5 つの型と、逆効果を避ける対策を 1 枚に入れると、次のようになります。題材は、日本の業務システムが出力する CSV の読み込みです。Shift_JIS、全角の数字、金額のカンマなど、AI がよくつまずく細かい決まりごとがある作業を選びました。これは説明用に筆者が書いた例で、SkillsBench の課題ではありません。

---
name: jp-business-csv
description: 日本の業務システムが出力した CSV（Shift_JIS、全角数字、「1,200円」形式の金額）を pandas で読み込んで数値に直す。文字化けする、金額の列が数値にならない、というときに使う。
---

# 日本の業務 CSV を読む

## 使う場面・使わない場面
- 使う：文字コードが分からない CSV、全角数字や「円」「,」が混ざった金額の列がある CSV
- 使わない：UTF-8 で、数値の列がそのまま読める CSV（pandas の read_csv だけで足りる）

## 手順
1. `scripts/load_csv.py` に入力ファイルと出力ファイルを渡して実行する（読み込み、金額の変換、UTF-8 での保存まで行う）
2. スクリプトが失敗したときだけ、下の「手で直す」を使う

## 手で直す（軽い代替手段）

「手で直す」の節には、次の Python コードを書きます。

import unicodedata
import pandas as pd

# shift_jis ではなく cp932 を指定する（「①」や「髙」が入っていても読める）
df = pd.read_csv(path, encoding="cp932", dtype=str)

# 金額の列だけ全角を半角に直し、「,」と「円」を取って整数にする
df["金額"] = (
    df["金額"]
    .map(lambda s: unicodedata.normalize("NFKC", s))
    .str.replace(r"[,円]", "", regex=True)
    .astype(int)
)

そのあとに、確認の項目を続けます。

## 終わったら確かめること
- 読み込みの前後で行数が変わっていない
- 金額の合計が、元のファイルの合計行と一致する
- 出力は UTF-8（BOM なし）で、列の順番は入力と同じ

中の Python コードは、手元の pandas 2.3.3 で、全角数字と「①」「髙」を含む CSV を使って動作を確認しました。scripts/load_csv.py は例として名前だけ示したもので、中身は用意していません。

この例のどこが、論文の結果と対応しているかを表にします。

例の中の箇所	対応する論文の知見
説明文に「文字化けする」「数値にならない」と症状を書いた	説明文が具体的だと、最初の一読で選ばれる
スクリプトを先に実行させる	動くコードの同梱が効く
cp932 を指定する理由を 1 行で書いた	データの読み込みのくせを名指しする
出力の文字コードと列の順番を指定した	成果物の形式の決まりを書く
行数と合計の一致を確認させる	検算に使える条件を書く
「使わない場面」と「軽い代替手段」を書いた	逆効果の 3 つの型への対策

公式の仕組みで測りたい場合

SkillsBench の課題と評価の仕組み（BenchFlow）は、Apache 2.0 ライセンスで公開されています。自分の Skill を同じ形式の課題にすれば、論文と同じペア評価ができます。公式リポジトリの README には、次のような始め方が書かれています。筆者は実行していないので、試すときは README の最新版を確認してください。

# リポジトリを取得する
git clone https://github.com/benchflow-ai/skillsbench.git
cd skillsbench

# 評価ツール BenchFlow を入れる（uv が必要）
uv tool install benchflow
uv sync --locked

# 課題の構成が正しいかを検査する
bench tasks check tasks/offer-letter-generator

# お手本の解答でテストが通ることを、手元の Docker で確かめる
bench eval run --tasks-dir tasks/offer-letter-generator --agent oracle --sandbox docker

AI に解かせる実行には各社の API キーが必要です。論文の付録によると、1 回の実行にかかる費用は、安いモデルで約 0.15 ドル、高いモデルでは 20 ドルを超えます。最初は 1〜2 課題で試すのが安全です。

結果を読むときの注意

SkillsBench は丁寧に作られたベンチマークですが、数字をそのまま自分の環境に当てはめる前に、知っておきたい点があります。多くは論文自身が「限界」として書いているものです。

Skill の質が高い前提での数字です。 論文は、公開されている Skill を 4 つの観点・12 点満点で採点しています。世の中の Skill の平均は 6.2 点でしたが、ベンチマークで使った Skill の平均は 10.1 点でした。ネットで拾った Skill を入れて同じ効果が出るとは限りません。
Skill が効く課題が選ばれています。 先に見たとおり、Skill の有無で差が出ない課題は採用されていません。+16.6 ポイントは「Skill が役立つ種類の仕事での効果」であって、あらゆる仕事の平均ではありません。
課題と Skill が最初から組になっています。 実際の現場では、数十個の Skill の中から合うものを AI が選ぶ必要があります。この「選ぶ難しさ」は、今回の実験にはほとんど含まれていません。
「情報が増えただけ」の効果と区別できていません。 Skill を足すと AI が読む文章が増えます。同じ長さの無関係な文章を足した場合との比較は、まだ行われていません。
個数と長さの分析は、傾向であって実験ではありません。 同じ課題で Skill の数や長さを変えて比べたわけではないためです。
端末で動く課題に限られます。 画面を操作する AI や、複数の AI が協力する作業には、そのまま当てはまりません。
モデルは入れ替わります。 リーダーボードは 2026 年 7 月時点のもので、その後に出たモデルは含まれていません。

まとめ

SkillsBench が示したことを、最初の 3 つの問いに沿って振り返ります。

Skill は効くのか：人が選んで磨いた Skill は、合格率を平均 33.9% から 50.5% に上げました。18 構成すべてで効果があり、モデルがよく知らない業界の手順ほど大きく効きます。プログラミングのようにモデルが得意な分野では、伸びは小さめです。
AI に自作させてもよいか：作らせたものをそのまま入れると、3 構成すべてで Skill なしより悪くなりました。読まれない、間違いが固定される、という 2 つが大きな原因です。人による中身の確認が欠かせません。
多く・詳しく書くべきか：1〜3 個・短めの Skill がよく効き、4 個以上や網羅的な長い文書は伸びが小さくなりました。動くスクリプト、データのくせ、出力形式、検算の条件、具体的な説明文の 5 つに絞るのが目安です。

そして、いちばん大事な教訓は測り方そのものにあります。Skill の効果は、あり・なしを同じ条件で比べないと分かりません。 ハーネスやモデルが変われば結果も変わります。初版の観察が、4 か月後の最新版で入れ替わった例も見ました。

次の一歩として、いま使っている Skill を 1 つ選び、それを外した状態で同じ作業を 3 回やらせてみてください。差が出なければ、その Skill は削るか、書き直す候補です。