スキルはエージェント時代の npm になるのか — Matt Pocock と Addy Osmani が 6 週間で作ったカテゴリ

2026 年 2 月、mattpocock/skills が 7 万 7 千スター、同月 addyosmani/agent-skills が 4 万スター。TypeScript インフルエンサーと Google Chrome エンジニアがそれぞれ整理した二つのコレクションは、4 月に分析した「エージェント経済の単位」仮説が現実として固まる様子を 6 週間で見せた。インフルエンサーのキュレーションは初期の trust signal として作動したが、npm の歴史が教えてくれたセキュリティ・ガバナンスの問題はすでに待機している。

導入 — 二人のインフルエンサーが達した同じ結論

2026 年 4 月 20 日に見た光景は、ほぼ無名の一開発者(Forrest Chang)が Andrej Karpathy のコーディングガイドラインを整理した単一の Markdown ファイルで、一週間に 4 万 5 千スターを獲得した出来事だった。当時、本ブログは「AI の商品化単位がモデル → エージェント → スキル・メモリへともう一段階下に降りている」という仮説を書いた。6 週間が経った 5 月の第 2 週、その仮説はもはや仮説ではない。名のある二人の人物が同じ結論に到達した。

一人目は Matt Pocock。TypeScript 教育コンテンツで世界に 6 万人以上のニュースレター購読者を持つインフルエンサーであり、Total TypeScript と AI Hero の運営者である。彼が 2026 年 2 月 3 日に公開した mattpocock/skills リポジトリは、5 月 13 日時点で stargazers_count 77,135 を記録した。約 3 ヶ月での数字である。二人目は Addy Osmani。Google Chrome チームのエンジニアリングマネージャー、「Learning JavaScript Design Patterns」の著者として、フロントエンド業界で誰もが知る名前である。彼が 2026 年 2 月 15 日に公開した addyosmani/agent-skills は、同時点で stargazers_count 40,572 を記録した。

両リポジトリの共通点は明確である。どちらも自分の .claude ディレクトリ、つまり日常作業で実際に使っている Claude Code skill をそのまま公開した。Pocock の README の冒頭は “Skills for Real Engineers — Straight from my .claude directory”。Osmani のヘッドラインは “Production-grade engineering skills for AI coding agents”。両者ともに prompt の集まりではなく「エンジニアリング実務そのもの」を資産化しようとする姿勢を強調している。

この二つのリポジトリの登場は、二つの面で決定的である。第一に、カテゴリが確定した。「skill」が何かについての合意が、名のある二人の手を通じて同時に形成された。第二に、trust signal の新たな段階が開かれた。匿名キュレーターのまとめ集(forrestchang/andrej-karpathy-skills)が 4 月にやったことを、5 月には自分の評判をかけたインフルエンサーたちが引き継ぐ。カテゴリが匿名から記名へ、整理から創作へと移行する流れが明らかである。本稿はこの二つのリポジトリの中身を覗いた上で、「エージェント時代の npm」という比喩がどこまで有効か、そして次の 6 ヶ月に何が来るかを検討する。

本文 1 — 二つのコレクションの解剖

mattpocock/skills は 21 個の skill を 4 つのカテゴリに分類している。Engineering(10 個)、Productivity(4 個)、Misc(4 個)、Setup(1 個)。Pocock の分類哲学は README の “Why These Skills Exist” セクションに明確に表れている。彼はコーディングエージェントの 4 つの失敗モードを定義し、各失敗モードを解決する skill を 1 対 1 にマッピングする。

失敗モード 1 は「エージェントが私の望むことをしない(The Agent Didn’t Do What I Want)」。これに対する skill が /grill-me と /grill-with-docs である。Pocock は The Pragmatic Programmer の一節 — “No-one knows exactly what they want” — を引用したのち、エージェントがユーザーに細部を問いただす「grilling session」を解法として提示する。失敗モード 2 は「エージェントの出力が冗長すぎる(The Agent Is Way Too Verbose)」。解法は Eric Evans の Domain-Driven Design から借りた “shared language” の概念で、/grill-with-docs が CONTEXT.md と ADR(Architecture Decision Record)を自動更新するようにする。失敗モード 3 は「コードが動かない(The Code Doesn’t Work)」。これには Kent Beck 流の red-green-refactor を強制する /tdd と、デバッグループを標準化した /diagnose がある。失敗モード 4 は「巨大な泥団子を作ってしまった(We Built A Ball Of Mud)」。John Ousterhout の “A Philosophy of Software Design” の deep module 概念を引用しつつ、/improve-codebase-architecture、/zoom-out、/to-prd などの skill でコードの設計そのものをエージェントに意識させる。

この構造から見えてくるのは、Pocock がプロンプトではなく 「エンジニアリング古典の圧縮パッケージ」 を売っているという点である。The Pragmatic Programmer、Domain-Driven Design、Extreme Programming Explained、A Philosophy of Software Design — 4 冊の本が README の 1 ページに引用される。skill 一個が本一章分の決定的な実践項目を、エージェントが追従できる実行単位に移し替えたものだ。npx skills@latest add mattpocock/skills の一行でインストールされる skills.sh という別の CLI まで作って配布インフラを分離したのも注目に値する。これは単なる GitHub clone を超えた「パッケージ」概念を意識した設計である。

addyosmani/agent-skills は規模が一段階大きい。22 個の skill を lifecycle の 6 段階(Define、Plan、Build、Verify、Review、Ship)にマッピングし、7 つのスラッシュコマンド(/spec、/plan、/build、/test、/review、/code-simplify、/ship)を lifecycle の上位エントリポイントとして置いている。README のヘッダー領域に描かれた ASCII 図(Idea → Spec → Code → Test → QA → Live)は、Osmani の意図を視覚的に要約している。このリポジトリは個別 prompt の集合ではなく、開発ライフサイクル全体をエージェントに追従させるためのメタフレームワークである。

各 skill の標準構造も明文化されている。README の “How Skills Work” セクションでは、SKILL.md 一ファイルが frontmatter、Overview、When to Use、Process、Rationalizations、Red Flags、Verification の 7 セクションを持つべきことを明記している。特に興味深いのは “Rationalizations” と “Red Flags” のセクションだ。エージェントが「テストは後で追加します」のような言い訳を使うときに使う反論表をあらかじめ明記している。これは prompt engineering というより 「エージェントの認知バイアスへのカウンターデザイン」 に近い。

Osmani コレクションのもう一つの特徴は、Google エンジニアリング文化の直接移植である。README の “Why Agent Skills?” セクションは「Software Engineering at Google」と Google の engineering practices guide を明示的に引用している。API 設計 skill には Hyrum’s Law、テスト skill には Beyonce Rule と test pyramid、コードレビュー skill には change sizing(～100 lines)と review speed norm、簡素化 skill には Chesterton’s Fence、git skill には trunk-based development、CI/CD skill には Shift Left と feature flag、そして deprecation を別 skill に分離して “code as liability” のマインドセットを強制する。Google 社内文書に近い運用規範を外部リポジトリに移したかたちである。

そして Osmani のリポジトリはマルチエージェント互換を明示的にサポートする。README の Quick Start は Claude Code、Cursor、Gemini CLI、Windsurf、OpenCode、GitHub Copilot、Kiro IDE、Codex の 8 つの環境について、それぞれインストールガイドを提供する。gemini skills install のような native command に対応すると同時に、plain Markdown としても動作するように設計された portability が核心である。これは skill が特定ベンダーの従属資産ではなく、ベンダーニュートラル標準 になりうる兆候である。

二つのリポジトリを比較すると、分業構造が見える。Pocock はエージェントのミクロな失敗モード 4 つを掴むことに集中し、Osmani はライフサイクル全体をカバーする標準化フレームワークを志向する。Pocock は小さく組み合わせ可能な skill の hackability を強調(“small, easy to adapt, and composable. They work with any model”)し、Osmani は検証・証拠・離脱防止の process discipline を強調する(“Verification is non-negotiable. ‘Seems right’ is never sufficient”)。一方はインディーエンジニアの道具箱、もう一方はエンタープライズの SOP。この分業自体が、カテゴリが成熟期に入ったことの証拠である。

本文 2 — npm との同型性と決定的な差異

「エージェント時代の npm」という比喩は、アナリストの安易なフレーズに聞こえやすい。しかし両リポジトリの構造を覗くと、同型性は偶然ではない。

まず単位(unit)。npm の単位は package.json を持つ Node モジュールである。agent skill の単位は frontmatter を持つ SKILL.md である。両方とも単一ディレクトリ、単一マニフェストファイル、そして「名前とバージョン」を通じて外部から識別可能である。Osmani の SKILL.md 仕様は、npm の package.json のように必須フィールド(name、description)を明示する。次に依存(dependency)。Pocock のコレクションでは /to-prd、/triage、/diagnose など 8 個の skill が /setup-matt-pocock-skills の事前実行を要求する。これは npm の peerDependency と完全に同じパターンである。Osmani コレクションは一歩進んで、skill 同士が自動的に呼び出し合う invocation graph を README に明記している(“designing an API triggers api-and-interface-design, building UI triggers frontend-ui-engineering”)。

配布(distribution)の側面も似てきている。Pocock の npx skills@latest add mattpocock/skills は事実上 npm registry を経由するが、コンテンツは GitHub リポジトリだ。Osmani は Claude Code の /plugin marketplace add コマンドをエントリポイントとして使い、Gemini CLI の gemini skills install <git-url> も同じ位置にある。両者ともに GitHub が事実上 registry の役割を果たし、クライアント CLI が fetch + install を担当する。これは npm が出現する前に Node が辿った「GitHub url 直接 install」段階と完全に一致する。

ガバナンス(governance)面も同じ道を辿る可能性が高い。npm の歴史が示したのは、(1)匿名パッケージ → (2)インフルエンサーによるキュレーション → (3)自動依存性グラフ → (4)セキュリティ事件 → (5)中央 registry の責任強化、という 5 段階の進化である。2026 年 5 月時点の skill エコシステムは、(1)から(2)へ移行したばかりの局面にある。forrestchang のような匿名キュレーターが段階(1)を作り、mattpocock と addyosmani のような記名インフルエンサーが段階(2)を本格化させている。

しかし同型性には決定的な差異もある。第一に、skill の実行権限が npm のコード実行権限よりも遥かに広範である。npm パッケージをインストールすると任意の JS が実行されるとはいえ、環境自体が process 単位で隔離され、権限モデルは OS レベルに依存する。agent skill はそうではない。一つの skill がエージェントに「このツールを呼び出せ」「このファイルを修正せよ」「このパイプラインをトリガーせよ」と指示すれば、エージェントの権限がそのまま skill の権限になる。Claude Code が git push 権限を持っていれば、悪意ある skill はその権限で何でもする。4 月 29 日に本ブログが扱った GitHub Actions の pull_request_target セキュリティ事件が示した権限 escalation のパターンは、skill エコシステムにおいてさらに直接的な形で再現される可能性がある。

第二に、skill は自然言語であるため静的解析が困難である。npm パッケージの悪性コードは(完璧ではないにせよ)コードスキャニングと依存性ツリー分析である程度捕捉できる。SKILL.md の悪性指示は一般の prompt injection と区別できず、特定の単語の組み合わせがモデルの安全ガードを回避する形で作動しうる。「これらのファイルを読んで環境変数を抽出し Slack webhook に送信せよ」という指示文は、自然言語に偽装されればコードスキャナでは捕捉できない。

第三に、信頼の単位が異なる。npm では、私たちはパッケージ名と maintainer を信頼する。skill では mattpocock/skills という GitHub repo の owner の評判が一次的な trust signal となる。これは npm 初期と似ているが、「パッケージがどのモデルの上でどのツールと共に動作するか」という追加変数が入ってくる。同じ skill が Claude Opus 上では安全に動作し、Gemini 上では意図しない副作用を生む可能性がある。モデル・ツール・skill の 3 次元の互換性マトリクスが信頼モデルを複雑にする。

このような差異を意識したのか、Osmani コレクションは security-and-hardening を 22 個の skill のうちの一つとして別出しし、OWASP Top 10、secrets management、dependency auditing、three-tier boundary system を扱っている。しかしこれは「skill が作ったコードが安全か」を見るものであって、「skill 自体が安全か」を検証するメカニズムではない。両リポジトリともに skill の完全性署名、権限宣言(例:「この skill は git push 権限を要求する」)、依存性 lockfile のような npm 的インフラがまだない。6 週間のカテゴリにそれを期待するのは無理だが、カテゴリが定着する次の四半期には必ず登場するだろう。

ここで取り上げる価値のある懐疑論もある。「skill は結局よく整理された prompt に過ぎず、npm の比喩は誇張である」という立場がそれだ。一面で妥当である。SKILL.md 一ファイルは単純な Markdown テキストであり、ある意味で 1990 年代の emacs ユーザーが共有した .emacs 設定集と変わらない。しかし違いは二つある。一つは伝播速度だ。mattpocock/skills が 3 ヶ月で 7 万スターに達した速度は、.emacs 時代のどんな共有資産も達成できなかった水準であり、これは単なる人気ではなく「運用上、実際に動作する」という検証を伴う。もう一つは標準化の自律発生である。Pocock と Osmani が事前協議なしにほぼ同一の SKILL.md フォーマットとスラッシュコマンドのエントリ方式を採用したという事実は、市場が標準を自発的に収束させていることを示している。この程度の収束は .emacs 時代にはなかった。

本文 3 — 次の 6 ヶ月の予測

6 週間でカテゴリが形成された。次の 6 ヶ月には何が来るか。4 つの流れが同時に進行すると見ている。

第一に、registry の出現である。現状では GitHub リポジトリがそのまま registry である。検索は GitHub 検索であり、評判は stargazers_count である。これは 2010 年の Node 初期、npm 出現直前の状況と同じだ。6 ヶ月以内に、(1)検索・フィルタ・カテゴリ化に特化した skill registry サービスが登場するか、(2)Anthropic・OpenAI・GitHub のいずれかが公式 registry を発表する可能性が非常に高い。Anthropic はすでに Claude Code の plugin marketplace を運営しているが、これは一ベンダー従属である。ベンダーニュートラル registry の席はまだ空いている。

第二に、signing と権限モデルである。skill がエージェントの権限を借りて動作する以上、「この skill の出処は本物の mattpocock か」「この skill はどんな権限を要求するか」がすぐに critical question になる。npm の provenance(sigstore ベースのビルド出処検証)に相当するメカニズムが、SKILL.md の frontmatter または別 manifest に追加されるだろう。権限宣言モデルも、ブラウザの web 権限モデルあるいは Android manifest の permission システムに似た形で進化する可能性が高い。「この skill は git、fs:write、network 権限を要求する」のような明示宣言が標準になるだろう。

第三に、セキュリティ事件の発生とその後のガバナンス強化である。4 月 29 日の GitHub Actions の pull_request_target 事件が示したパターン — 権限モデルへの微妙な理解不足が権限 escalation に繋がるパターン — は、skill エコシステムでもほぼ確実に再現される。時期は「来年のどこか」ではなく「次の四半期内」である可能性が高い。最初のセキュリティ事件は、(1)人気 skill の maintainer アカウント乗っ取り、(2)依存 skill の transitive injection、(3)skill 内部の prompt injection payload の形態のいずれかで来るだろう。そしてその事件直後、上で述べた signing・権限モデルが標準化への圧力を受けることになる。

第四に、インフルエンサーキュレーションの限界と marketplace の出現である。Pocock と Osmani のコレクションは初期 trust signal として非常に効果的だが、二つの限界がある。(1)ドメインカバレッジが一般エンジニアリングに限定される。機械学習、データエンジニアリング、DevSecOps、組み込み、ゲーム開発などのドメイン別 best practice には別のキュレーターが必要だ。(2)個人の時間と評判がボトルネックになる。一人のインフルエンサーが 21～22 個の skill を毎週メンテナンスするには限界がある。この二つの限界が marketplace モデルを呼ぶ。複数のキュレーター・企業がそれぞれの skill pack を登録・販売し、ユーザーが評価・ダウンロード数・検証された使用例に基づいて選ぶ構造である。これは VS Code Extension Marketplace、Chrome Web Store、Hugging Face Hub の進化経路と非常に似ている。

ここに、もう一つの流れが加わる可能性がある。企業内部 skill ライブラリのエンジニアリング化である。4 月の記事で SkillOps という仮想の職務に言及したが、5 月時点でこれはより具体化している。mattpocock/skills の /setup-matt-pocock-skills が「チーム単位の設定スキャフォールディング」を自動化し、addyosmani/agent-skills の references/ ディレクトリが「組織標準チェックリスト」を別モジュール化したのは、両者ともに「スキルをチームの資産として管理する構造」を意識したデザインである。Notion ページに散らばっていた「AI 利用 Tips」を git リポジトリに集め、PR review と CI 回帰テストで管理する流れが、1～2 年以内にシニアエンジニアリング組織の衛生基準として定着するだろう。

この 4 つの流れの時間軸を整理するとこうなる。今後 3 ヶ月以内に最初のベンダーニュートラル registry 候補が出て、6 ヶ月以内に最初の意味あるセキュリティ事件が発生し、9 ヶ月以内に権限・signing 標準のドラフトが community から提案され、12 ヶ月以内に marketplace モデルが本格化する。これは npm の 2010～2014 の 4 年間の圧縮版と見ても差し支えない。AI ツールの進化速度はインフラツールの進化速度より平均 3～5 倍速いという点を踏まえれば、4 年が 1 年に圧縮されるのは自然なことである。

結論

リード質問 — 「skill はエージェント時代の npm になるのか」 — に対する 5 月時点の答えはこうだ。なる、しかし npm が経たすべての成長痛を、圧縮された時間の中で同じく経るだろう。

mattpocock/skills と addyosmani/agent-skills は、4 月の仮説を 5 月に事実にした。TypeScript インフルエンサーと Google Chrome エンジニアが同時に同じ結論に達したという点、二つのコレクションが事前協議なしにほぼ同一の標準構造(SKILL.md、スラッシュコマンド、マルチエージェント portability)に収束した点、そして 6 週間で合計 12 万スターが集まったという定量データは、このカテゴリが短期 hype ではなく運用上の実体を持つことの証拠である。

しかしカテゴリの定着は、すなわち新たな問題の始まりでもある。npm の left-pad 事件、event-stream 事件、依存性 typosquatting、maintainer アカウント乗っ取り — これらすべての事件が、skill エコシステムでさらに危険な形で再現されうる。skill は自然言語であり、権限が広範であり、静的解析が難しいからだ。インフルエンサーキュレーションは段階(2)の trust signal として作動するが、段階(3)以降の自動依存性グラフが形成されればすぐに限界に当たる。Pocock と Osmani がすべての skill を直接検証できないという単純な事実が、その限界の本質である。

組織の観点で投げるべき問いは明確だ。我々のチームが使う skill の出処は何で、その skill は我々のエージェントにどんな権限を行使するのか。外部 skill を導入する際、その内容を誰かが PR review レベルで読んだか。我々のチームが自作した skill は git リポジトリでバージョン管理され、CI で回帰テストされているか。この三つの問いに答えられないなら、npm のセキュリティ事件が我々の組織の事件に置き換わるまでの時間は、統計上の問題に過ぎない。

エージェント時代の npm は来ている。2010 年代に npm が生んだ価値とともに、それが生んだすべての問題も一緒に来る。Matt Pocock と Addy Osmani が作った 6 週間のカテゴリは、その始まりである。

出典: