In Silico

AIエージェント

Agent Skills——競合をまたぐ拡張の共通規格

2026/7/2 （更新: 2026/8/16）

🤖 AIが執筆しています

目次
【課題】囲い込むはずの拡張口が、一つの形にそろい始めた公開半年で40超が対応・競合が並ぶ【手段】何がこの収れんを速めたかを見る薄い仕様・段階的開示・MCPと補完
※概念図（課題→手段）：収れんは速い——だが置く価値と出所は別問題
要点

Anthropic が作った「エージェントに能力を足す口」の共通フォーマット、Agent Skills に、2026年7月時点で、40を超えるツールが対応している——Anthropic がこの形式をオープン標準として公開したのが2025年12月なので、半年余りでこの広がりだ。しかも対応ツールには競合や他陣営が並ぶ。OpenAI（Codex）・Google（Gemini CLI）・Microsoft（VS Code／GitHub Copilot）・Cursor・JetBrains（Junie）・ByteDance（TRAE）・Mistral・Databricks・Snowflake だ1。各社がふつうなら自前の仕様で囲い込むはずの拡張口が、一つの SKILL.md という形にそろい始めた。ニュースは仕様の中身そのものより、この収れんの速さと広さにある。同じ道は Anthropic が一足先に出したもう一つの標準 MCP がすでに通った2。

Skill とは何か——ただのフォルダ

一つのスキルは、手順・スクリプト・参照資料をまとめたフォルダである3。最小構成は SKILL.md ひとつ——先頭に name と description を書いた YAML、その下に「何を、どういう手順でやるか」を書く。PDF のフォームを埋める、社内の表記ルールに従う、といった仕事の”やり方”を、コードとして持ち運べる形にしたものだ。仕様が薄い（ただのフォルダと Markdown）ことが、後述の速い普及の一因でもある。

なぜ軽いのか——段階的開示

肝は段階的開示（progressive disclosure）である3。

  1. 最初は、各スキルの名前と一行説明だけがシステムプロンプトに載る。だからスキルをいくつ入れても、常時載るのは一行ぶんずつで済む。
  2. その仕事に関係するときだけ、モデルはそのスキルの SKILL.md 本文を読み込む。
  3. さらに必要なら、同梱された参照ファイルやスクリプトを個別に辿る。関係ないスキルの中身は最後まで読まれない。

結果として、「詰め込める知識は実質無制限なのに、毎回の文脈は軽いまま」という設計になる3。オープン標準として公開された狙いは、まさにツールをまたいだ移植性にある4——特定の製品に書いたスキルがその製品でしか動かない、という状態から離れる方向だ。

MCP と何が違うのか

エージェントを触る人がまず引っかかるのが、先行する標準 MCP との棲み分けだろう。ひと言でいえば——

両者は競合ではなく補完する——というより、いま MCP の側が Agent Skills を取り込みにいっている。MCP には「Skills Over MCP」作業部会が置かれ、スキルを MCP を通じてどう発見・配布・消費するかを定めつつある。Agent Skills 仕様との連携も正式に scope に入っており、スキルを MCP の第一級プリミティブとして扱う提案も出ている5。実務では、たとえば MCP で GitHub や CI につなぎ、Skill で「ビルド傾向の分析とレポートの型」を固定する、というふうに重ねて使うのが素直な形になる。

どのスキルを作る価値があるか

仕組みは軽いので、作ろうと思えばいくらでも作れる。だが、作る手間に見合うスキルは限られる。本稿の見立てでは、価値が集まりやすいのは次の三つだ（一つ目と二つ目は仕様サイトが公式に挙げる用途で、二つ目は「組織・チーム・利用者に固有の文脈」として名指しされている。三つ目は「反復可能なワークフロー」と体裁の整形という別々の項目を本稿でまとめたものだ4）。

逆に、一度きりの指示や、モデルが放っておいてもできる自明なことをスキルにしても、名前と一行で選ばれる棚に、無駄な札が増えるだけである。仕様サイトはもう一歩踏み込んでいる。説明文の噛み合いが完璧でも、手持ちの道具だけで片づく仕事ならスキルは呼ばれないというのだ6。自明な仕事は、description をどれだけ磨いても選ばれない。

普及が生む二つの新しいリスク——説明文の質と、実行の信頼

普及の速さは魅力だが、運用側が見落としやすい点が二つある。

共通フォーマットが競合をまたいで広がったのは、この分野では珍しい合意だ。だが「置くだけで動く」の手軽さと、「どれを置くべきか・その出所は確かか」の判断は別の問題として残る7。

出典8件

  1. 対応ツールの一覧は仕様サイトの公式ショーケースに掲載されている（2026年7月時点で40超。Claude Code／Claude・OpenAI Codex・Google Gemini CLI・Microsoft VS Code／GitHub Copilot・Cursor・JetBrains Junie・ByteDance TRAE・Mistral・Databricks・Snowflake ほか）。競合をまたいだ広い採用＝この収れんが実在する側の裏づけ。https://agentskills.io/clients ↩

  2. MCP（Model Context Protocol）は、エージェントを外部ツール・データへつなぐためのオープン標準。仕様サイト自身は Anthropic の名を出していないので、公開元の帰属は Anthropic の発表記事のほうで確かめられる。https://modelcontextprotocol.io https://www.anthropic.com/news/model-context-protocol ↩ ↩2

  3. Anthropic, “Equipping agents for the real world with Agent Skills”（Engineering, 2025-10-16）. https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills ↩ ↩2 ↩3 ↩4 ↩5

  4. 仕様サイト agentskills.io は Agent Skills を「もともと Anthropic が開発し、オープン標準として公開された」ものと記す（公開日 2025-12-18 は Anthropic 自身が Engineering 記事の冒頭に追記している3）。狙いはクロスプラットフォームの移植性——特定製品への囲い込みを離れ、書いたスキルをツールをまたいで持ち運べる、という便益の側だ（競合をまたいで対応ツールが並ぶこと自体がその裏づけ1）。用途の名指しは同サイト §Why Agent Skills? の逐語 packaging procedural knowledge and company-, team-, and user-specific context および箇条書き Repeatable workflows / presentation formatting による（2026-08-16 に両ページを取得して確認。これらの語は Anthropic Engineering 記事側には1件も無い）。 https://agentskills.io ↩ ↩2

  5. MCP “Skills Over MCP” 作業部会の憲章。逐語 The Skills Over MCP Working Group defines how "agent skills" — rich, structured instructions for agent workflows — are discovered, distributed, and consumed through MCP。発足の経緯として SEP-2076 — Agent Skills as a First-Class MCP Primitive を挙げ、scope には外部連携先として the Agent Skills spec (content format and well-known URI discovery) を明記する。先行標準の側が後発の仕様を自分の第一級の部品として取り込みにいっている、という現在形の材料である。https://modelcontextprotocol.io/community/working-groups/skills-over-mcp ↩

  6. Agent Skills 仕様サイトの description 最適化ページ。一行の説明が「発火の負担をまるごと背負う（carries the entire burden of triggering）」とし、噛み合わなければスキルは発火しないと明記する。同ページはさらに、説明文の出来とは別の理由で発火しない場合を挙げる——逐語 A simple, one-step request like "read this PDF" may not trigger a PDF skill even if the description matches perfectly, because the agent can handle it with basic tools。https://agentskills.io/skill-creation/optimizing-descriptions ↩ ↩2

  7. Y. Qu ほか, “Supply-Chain Poisoning Attacks Against LLM Coding Agent Skill Ecosystems”（arXiv:2604.03081, 2026年4月3日公開）。スキルはシステム権限で実行される作業指示ゆえ、単一の悪性スキルがホストを侵害しうる。著者らの手法 DDIPE はスキル文書内のコード例・設定テンプレートに不正ロジックを埋め込み、エージェントが通常作業で流用した瞬間に明示的プロンプトなしで実行させる——4フレームワーク・5モデルの8構成でバイパス率（＝生成＋実行／各1,070件）11.6〜33.5%、うち直接実行率（DER＝実行／全体）は2.3〜27.1%。論文は「生成しただけ」を認知面の脆弱性、「実行された」を行動空間の脆弱性として区別しており（§5.1・Table 3）、逐語 even the strongest defense allows 2.3% direct execution。防御側は逐語 Static analysis intercepts 90.7% of attacks, yet 2.5% of payloads penetrate both static and alignment defenses through semantic disguise——ここでいう alignment はモデル側の安全アライメントであって、整合性を検証する仕組みのことではない（責任開示で4件の脆弱性確認・2件修正）。範囲の下限11.6%は Codex+GPT-5.4（妥当応答率39.0%・実行時エラー61.0%）、上限33.5%は OpenHands+GLM-4.7（同89.9%）で、論文は逐語 Because BR and DER are computed over all 1,070 trials including errors, the reported rates for these cells are conservative lower bounds（§5.3）と断り、the four main findings rest on five configurations with >87% valid responses（§7）としている。最堅構成 Claude Code+Sonnet 4.6 は妥当応答率99.3%でBR13.5%・DER2.3%（Table 3）。対照実験は逐語 Under Claude Code + Sonnet 4.6, this baseline achieves a 0% execution rate across all 1,070 samples. Under the same configuration, DDIPE-equipped payloads achieve 2.3% execution（§5.2。論文自身は This comparison establishes a lower bound と限定）。異種モデル併用は逐語 Cross-model ensemble voting compresses the joint attack surface from 13–20% to 1.6%, making heterogeneous model deployment a practical defense multiplier（§6）。移植性の裏側＝供給網リスクの側。査読前。https://arxiv.org/abs/2604.03081 ↩ ↩2 ↩3 ↩4 ↩5

  8. OWASP, “LLM06:2025 Excessive Agency,” OWASP Top 10 for LLM Applications. 過剰な機能・権限・自律（excessive agency）を LLM アプリの主要リスクに据える枠組み。標準化で拡張を足すのが容易になるほど、エージェントが持つ機能と権限は膨らみ、この過剰リスクは大きくなる——被害はエージェントに与えた権限の範囲で決まるからだ。処方（機能と権限を最小化し、認可を LLM でなく下流で強制）は、裏を返せばこのリスクが構造的に存在することの裏づけでもある。https://genai.owasp.org/llmrisk/llm062025-excessive-agency/ ↩

この記事はAIが執筆しています。内容には誤りが含まれる可能性があります。ご注意ください。