Agent Skillsは効くのか｜数字で仕分ける
この記事の結論
・AIエージェントに手順書（スキル）を渡すと、タスク合格率が33.9%→50.5%に上がったという実測があります。一方で、約25%のケースでは入れると逆に性能が下がるという報告もあります。
・その手順書がこの1週間で、GitHubトレンド同時3件・レジストリのパック配布開始と、一気に「配る・入れる」ものになりました。
・分かれ目は「何を書くか」。モデルが知らないこと（あなたの現場の失敗と手順）を書いたスキルだけが効く。自作スキル18個を毎日使う立場から、数字で仕分けます。
「Claude Codeにスキルを入れると強くなるらしい」。この手の話が、ここ数日で急に増えました。
きっかけは数字を見ると分かります。2026年8月9日の時点で、GitHubのトレンドにスキル集のリポジトリが3つ同時に載りました。この日の実測で、mattpocock/skillsが1日で+1,354スター（累計209,709）、addyosmani/agent-skillsが+778（累計84,330）、google/skillsが+481（累計16,560）。
その2日前の8月7日にはVercelが、スキルのレジストリskills.shに複数スキルをまとめて配る「Skill packs」を追加しています。
つまりいま、エージェント用の手順書が「書く」ものから「配る・入れる」ものに変わりつつある。npmでパッケージを入れるように、npx skills add でスキルを入れる世界です。
で、本当に効くのか。
ぼくはWebエンジニア6年目で、手元に自作スキルが18個あります。この記事の制作も、そのうちの1つを起動して回しています。つまり毎日使っている側の人間です。その立場から、今週のニュースの整理と、「効く・条件次第・危ない」の仕分けをやります。
先に結果だけ並べておきます。
・○ 選び抜いたスキル：実測でタスク合格率+16.6ポイント。小さいモデル+スキルが大きいモデル無スキルに並ぶ例も
・○ 自分の失敗を書いたスキル：モデルが知らない情報なので効く（ぼくの実感もここ）
・△ 人気ランキングからの導入：急成長スキル上位100件のうち92件が、わずか3発行者由来。数字は品質の指標にならない
・△ 自動発火：description が曖昧だと呼ばれない。「入れたのに使われない」が頻出
・✕ AIに自分でスキルを書かせる：平均すると効果なしという報告
・✕ 中身を読まずに入れる：未署名の実行可能な指示書。マルウェア配布の実例あり
この6つを、以下で順番に見ていきます。
何が起きたか。手順書の「市場」が立ち上がった1週間
まず事実関係から整理します。
Agent Skillsは、Anthropicが2025年10月16日に発表した仕組みです。公式の定義は「指示・スクリプト・リソースを入れたフォルダで、Claudeが必要なときに読み込むもの」。中身の実体は、SKILL.mdというMarkdownファイルが入ったフォルダです。
ポイントは、これがオープン標準として公開されたことでした。仕様サイトagentskills.ioには「Agent Skills形式はAnthropicが最初に開発し、オープン標準として公開された」と明記されています。
その結果、OpenAIのCodex公式ドキュメントもCursor公式ドキュメントも、いまや同じSKILL.md形式をサポートしています。agentskills.ioのクライアント一覧には、Claude Code・Codex・Cursor・GitHub Copilot・VS Code・Gemini CLIなど40以上が載っています。
ライバル同士のはずのAnthropicとOpenAIが、手順書のファイル形式では同じ仕様に乗った。ここが面白いところです。
そして今週、流通側が動きました。
・8月6日: Vercel Marketplaceで統合を入れると、そのプロバイダーの公式スキルが自動で入るようになった（例: データベースのNeonを入れると「Neonの使い方」スキルが配られる）
・8月7日: スキルレジストリskills.shに「Skill packs」登場。複数スキルを1つのURLで束ねて共有できる
・8月9日: GitHubトレンドにスキル集が3つ同時掲載（冒頭の数字）
skills.shは2026年1月にVercelが出したスキルのディレクトリ兼リーダーボードで、直近8週間のインストール数を見ると、上位のスキル（1位は運営元Vercel自身が出すfind-skills）は1本で約290万インストールに達しています（2026年8月9日閲覧）。
Googleも公式リポジトリgoogle/skillsで、GKEやBigQueryなど自社製品のスキルを配り始めています。ベンダーが「人間向けドキュメント」とは別に「エージェント向け手順書」を公式に出す段階に入った、ということです。
なぜ重要か。差がつく場所がモデルから手順書に移る
この動きが大事な理由は、モデル単体の性能差が縮んでいるからです。
各社のトップモデルは、ベンチマークで数ポイント差の接戦だと言われるようになりました。そうなると、同じモデルを使っても成果に差が出る理由は、モデルの外側にあることになります。どんな文脈を渡すか。どんな手順で作業させるか。つまり手順書です。
これを定量で示したのが、2026年2月に公開されたベンチマーク研究SkillsBench（arXivのプレプリントで、査読誌への採録は現時点で確認できません）。87タスク×8ドメインで、モデルとツールの組み合わせ18通りを検証した結果、人が選んで整えたスキルを渡すと平均のタスク合格率が33.9%から50.5%へ、+16.6ポイント上がりました。
しかもこの研究には、もう2つ大事な発見があります。
1つ目。小さいモデル+スキルが、大きいモデル無スキルに匹敵し得る。手順書は、モデルのグレードの差をある程度埋めてしまう。
2つ目。3モジュール以下に絞ったスキルが、網羅的な大きい束に勝つ。たくさん詰め込むほど強くなるわけではない。むしろ逆です。
エンジニアとしては、これはドキュメントの歴史の繰り返しに見えます。コードの再利用がコピペ→ライブラリ→パッケージマネージャと進化したように、AIへの指示もコピペ→テンプレート→スキルレジストリと進んでいる。いまはちょうど、npmが登場した頃の空気です。玉石混交で、便利で、危ない。
で、どこまで信じていいのか。数字で仕分ける
ここからが本題です。ブームの数字と、効果の数字は別物なので、分けて見ます。
○ 効く：選び抜いたスキルと、自分の失敗を書いたスキル
SkillsBenchの+16.6ポイントは「キュレーションされたスキル」の数字です。誰かが目的に合わせて選び、整えたもの。ただし注意点が2つ。平均+16.6の内訳は構成によって+4.1〜+25.7ポイントと幅があり、そして単一ベンチマークの結果で独立の追試はまだありません。どの構成でも同じだけ上がる、ではなく、条件が揃えば上がる、と読むのが正確です。
日本語圏にも同じ方向の実測例があります。KDDIアジャイル開発センターのエンジニアがスキル評価ツール3種を比較した記事では、曖昧に書いた初版スキルは「スキルなし」より結果が悪化し、書き直した改善版で採点が19.2点から77.5点に上がりました（スキル1本での事例です）。書き方で天地が分かれる。
ぼくの実感もここです。手元の18個のスキルのうち、明らかに効いているのは、過去の失敗をそのまま手順に変換したものです。たとえばぼくの記事制作スキルには「下書きを再投入するときは本文を全部消してから画像を入れ直す。順序を守らないと図解が消える」という一文があります。これは実際に図解を消した事故から書いた行です。
モデルは賢いですが、ぼくの過去の事故は知りません。モデルが知らないことを書いたときだけ、スキルは価値を持つ。
△ 条件次第：ランキング導入と自動発火
「じゃあ人気スキルを入れよう」となるのですが、ここに落とし穴があります。
スキルのディレクトリを運営するSkillselionが8月5日に公開した分析によると、skills.shの急成長スキル上位100件のうち92件が、わずか3つの発行者から出ていました。うち54件は同一スイートの一括配布で、その上位27件は1日あたり+342〜+345件と足並みを揃えて伸びていた。分析者は、インストール数はもはや開発者が個々に選んだことの代理指標ではない、と結論しています。
Hacker Newsでも、skills.sh公開直後から、インストール数ランキングは品質のシグナルにならないという趣旨の指摘が出ていました。スター数もインストール数も、いまのスキル市場では品質を保証しません。npmのダウンロード数が品質を保証しないのと同じです。
もう1つの罠が「入れたのに使われない」問題。スキルはエージェントが状況に応じて自動で読むはずが、実際にはdescriptionの書き方が曖昧だと発火しません。8月8日の検証記事では、自作18スキル（ユーザー14＋プロジェクト4）を全数計測した結果、最長でも948文字で上限の1,536文字に届いておらず、真因は文字数ではなく「いつ呼ぶか」の記述の欠落だったと報告されています。
ぼくも今朝、作ったスキルが読み込まれない問題を30分デバッグしました（原因はセッション起動時にしかスキャンされない仕様でした）。配るより、発火させる方が難しいんです。
✕ 効かない・危ない：自己生成と、中身を読まない導入
まず効かない方。SkillsBench自身が「スキルなし／人が整えたスキル／モデルが自分で書いたスキル」の3条件を比較しており、自己生成スキルは平均で効果なしと報告しています。モデルは「自分が読んで得をする手順書」を自分では書けない。手順書の価値の源泉が「モデルの外にある知識」だと考えれば、当然の結果です。
Microsoftの2本のプレプリントを解説した記事によれば、さらに厳しい数字もあります。スキルを入れたら性能が逆に下がる「負の転移」が約25%のケースで発生。そしてLLMに2つのスキルの優劣を読み比べさせると判定精度は46.4%、ほぼコイン投げでした（差が大きいペアではむしろ15.8%と逆相関）。
ただし検証済みの採点基準を与えると73.8%まで上がる。漠然と読んでも分からないが、見る観点を決めれば分かる、ということです。
次に危ない方。スキルの実体は「エージェントが読んで実行する指示書」です。署名も検証もなしに配布されている。
実害はすでに出ています。1Passwordのセキュリティチームは2026年2月、エージェントゲートウェイOpenClawのスキルレジストリClawHub（Claude Codeとは別プロダクトです）でダウンロード上位のスキルが、偽の依存パッケージ経由でmacOSに情報窃取マルウェアを送り込む多段チェーンを実装していたと報告しました。
彼らの表現を借りれば「エージェントのエコシステムでは、指示を読むことと実行することの境界が崩壊する」。
セキュリティベンダーFaberlensは、静的スキャナを全通過したOSSスキル200本のうち87%がエージェントの安全性を劣化させたと報告しています（自社ツールを売る会社の自社研究なので、その分は割り引いて読んでください）。
今月8月4日には、あるスキルリポジトリのHacker Newsスレッドに「このリポジトリはマルウェアに感染している。npxで入れるな」という警告コメントが投稿される事案もありました。警告の真偽自体は未検証です。ただ、こういう警告が飛び交う市場になった、という事実が重要です。
対策側も動き始めていて、スキルに署名検証やサンドボックス実行を付けるツール、スキル専用のセキュリティスキャナが今年前半だけで複数登場しています。npmがマルウェア対策を後付けで積み上げてきた歴史を、スキル市場は早送りでなぞりそうです。
ぼくの結論。スキルは「買う」より「書く」が先
18個のスキルで毎日回している人間としての、正直な結論を書きます。
その前に、ぼくの18個の内訳を正直に晒します。毎日のように起動しているのは、記事や動画の制作パイプラインを回す4〜5個。どれも過去の事故（図解を消した、順序を間違えた、数字を盛りかけた）がそのまま手順として焼き込まれています。
逆に、初期に書いた一般論のスキル（コピーライティングの心得、のような内容）は、いま振り返るとこの半年ほとんど起動していません。ぼくの手元でも、生き残ったのは「失敗由来」だけでした。
だから結論はこうなります。入れるより、書く方が先です。
理由は上の数字が全部語っています。効くのは選び抜いたスキルで、選ぶ目はランキングが代替してくれない。そして「選び抜かれた」状態への最短ルートは、自分の現場の失敗から自分で書くことです。
ぼくの制作パイプラインで言えば、記事の太字の数を機械で数えて上限を超えたら差し戻す、という検品手順もスキルに書いてあります。こんなもの、レジストリのどこを探しても見つかりません。ぼくの現場にしか存在しない知識だからです。
逆に、他人のスキルを入れる価値があるのは、自分がまだ失敗していない領域の「他人の失敗の蓄積」を先回りで入手できるときです。その場合も、SKILL.mdはただのMarkdownなので、インストール前に全文読めます。読んでから入れる。未署名の実行可能ファイルに対する態度と同じでいい。
保存用に、ここまでの数字を判断基準に変換しておきます。
・自分で書く：過去の事故・社内の固有手順・機械的に判定できる検品条件。ここが最も効く（モデルが知らない情報だから）
・条件つきで借りる：ベンダー公式や発行者が明確なもので、全文を読み、用途が自分の穴と一致するとき
・入れない：人気ランキングだけで選んだもの・AIに自動生成させた一般論・中身を読んでいないスクリプト同梱スキル
この構図、実は人間のチームと同じなんですよね。優秀な新人に「頑張って」とだけ言って放り込むチームと、過去の事故がぜんぶ手順書になっているチーム。同じ人材でも成果は違う。エージェントの世界では、その手順書の差が+16.6ポイントという数字で見え始めた。それだけの話だと思っています。
今日からできること
Claude Code・Cursor・Codexを使っている人へ。
エージェントに同じ指示を3回打ったことがあったら、それが最初のスキルの種です。.claude/skills/名前/SKILL.md（Cursorなら.cursor/skills/、Codexなら.agents/skills/）にMarkdownで書くだけ。
frontmatterのdescriptionには「何をするか」だけでなく「いつ使うか」を具体的に書いてください。不発動の最大原因はここです。
他人のスキルを入れるときは、(1) SKILL.mdの中身を全文読む (2) スクリプトが同梱されていたらそれも読む (3) 発行者を確認する。この3つで、1Passwordが報告したような明らかに悪意ある配布の多くは避けられます。ただし前述のとおり、読んでも気づけない挙動の劣化は残ります。認証情報を扱う環境では、まず壊れても困らないプロジェクトで試すのが安全です。
エンジニアでない人へ。
この仕組みの本質は「AIへの指示を、その場で打つのをやめて、ファイルにして再利用する」というだけのことです。ChatGPTに毎回同じ前置きを打っているなら、その前置きをメモにして貼り付け運用にするだけで、あなたはもうスキルの本質をやっています。道具は後からついてきます。
ここまで読んでくれてありがとうございました。
この記事は、AI・エンジニアリングの話題を一次ソースと実測データで検証するシリーズとして書きました。あなたがエージェントに3回以上繰り返した指示は何ですか。コメントで教えてもらえたら、スキル化の勘所を返信します。
続きが読みたい方は、note（designing_edges）のフォローをどうぞ。AI実務を一次ソースと自分の運用で検証する記事と、査読論文ベースの健康・食事の連載を書いています。
関連記事では、擬人化の罠を扱った「AIエージェントは同僚ではない」も公開中です。
