AIエージェント
Agent Skills——競合をまたぐ拡張の共通規格
目次
文書を読ませたりコードを書かせたりするAIエージェントに、現場ごとの手順を足す口を、どの製品も以前から用意していた。問題は、その口の形が製品ごとに違うことだった。リポジトリに1枚置いてエージェントに読ませる指示ファイルなら、2025年8月には AGENTS.md が競合をまたぐ共通形式として出ていた1。だが、必要なときだけ読み込む手順の束には、製品ごとの独自の形しかなかった。一方の製品に向けて書いた手順は、もう一方では読めない。
そこへ Anthropic が2025年12月、自社の形を Agent Skills という名でオープン標準として公開した2。手順を書いた Markdown を1枚置けば足りる薄さである3。オープン標準といっても、各社が他社の作った規格に乗る義理はない。ところが各社は乗った。拡張の口は、社をまたいで一つの形へ収れんし始めている。Anthropic が一足先に出したもう一つの標準 MCP も、すでに同じ道を通った4。
何がこの収れんを速めたのか。そして、口の形がそろったあと、運用側の仕事は減るのか。
収れんを速めた一因は、規格の薄さだと本稿は見る。フォルダに Markdown を1枚置けば実装できる。だが薄さが片づけたのは「どう載せるか」までで、「どれを置く価値があるか」と「その出所は確かか」は運用側に残る。 対応ツールは、公開から半年余りの2026年7月時点で40を超え、そこには OpenAI(Codex)・Google(Gemini CLI)・Microsoft(VS Code/GitHub Copilot)といった競合が並ぶ5。他所から持ってきたスキルを経由した汚染では、測った中でもっとも守りの堅い環境でも、仕込んだコードが明示的な指示なしにエージェントの動くマシン上で実際に走った率が2.3%あった6。
Skill の実体はただのフォルダ
一つのスキルは、手順・スクリプト・参照資料をまとめたフォルダである3。最小構成は SKILL.md ひとつである。このファイルの先頭に name と description を書いた YAML を置き、その下に「何を、どういう手順でやるか」を書く。PDF のフォームを埋める、社内の表記ルールに従う、といった仕事の”やり方”を、コードとして持ち運べる形にしたものだ。仕様が薄い(ただのフォルダと Markdown)ことが、この速い普及の一因だと本稿は見る。Anthropic 自身は、この形式の単純さを、組織や開発者が自前のエージェントを作りやすくなる利点として挙げている3。
段階的開示で文脈を軽く保つ
肝は段階的開示(progressive disclosure)である3。
- 最初は、各スキルの名前と一行説明だけがシステムプロンプトに載る。だからスキルをいくつ入れても、常時載るのは一行ぶんずつで済む。
- その仕事に関係するときだけ、モデルはそのスキルの
SKILL.md本文を読み込む。 - さらに必要なら、同梱された参照ファイルやスクリプトを個別に辿る。モデルは、関係ないスキルの中身を最後まで読まない。
ファイルシステムとコード実行の道具を持つエージェントなら、作業のたびにスキル全体を文脈へ読み込む必要はなく、必要な分だけ読めばよい。だから一つのスキルに同梱できる量は、実質的に無制限になる3。Anthropic がオープン標準として公開した狙いは、ツールをまたいだ移植性にある2。
MCP と何が違うのか
エージェントを使う人がまず疑問に思うのは、先行する標準 MCP(Model Context Protocol)との棲み分けだろう。両者の違いをひと言でいえば、次のとおりである。
- MCP は「接続」。 外部のデータやシステムへ、安定した経路でつなぐ(=エージェントに新しい能力を足す)4。
- Skills は「手順」。 公式は Skills も「新しい能力を足すもの」と書くが、その中身は、つないだ先で何を・どうやるかをそろえる手順書である。形式はフォルダと Markdown、必要ならスクリプトである(=毎回説明し直さずに済ませる作法)3。本稿の「能力/手順」という切り分けは、公式の語法ではなく説明のための整理である。
両者は競合せず、補完し合う。さらにいまは、MCP の側が Agent Skills を取り込んでいる。MCP の「Skills Over MCP」作業部会は、スキルを MCP を通じてどう発見・配布・消費するかを定める場で、Agent Skills 仕様との連携も正式に scope に入っている7。その成果として、Skills 拡張(SEP-2640)が2026年9月に Final になり、公式の拡張 io.modelcontextprotocol/skills として公開された7。作業部会はもともと、スキルを MCP の第一級プリミティブにする提案(SEP-2076)の議論から生まれたが、その提案自体は2026年2月に閉じられている。実務では、たとえば MCP で GitHub や CI につなぎ、Skill で「ビルド傾向の分析とレポートの型」を固定する、というふうに重ねて使うのが素直な形になる。
どのスキルを作る価値があるか
仕組みは軽いので、作ろうと思えばいくらでも作れる。だが、作る手間に見合うスキルは限られる。本稿の見立てでは、価値が集まりやすいのは次の三つだ。二つ目は、仕様サイトが「組織・チーム・利用者に固有の文脈」として名指しする用途である2。一つ目は Anthropic の解説記事が挙げるコードの決定性に3、三つ目は仕様サイトの「反復可能なワークフロー」と、専門知識の例に並ぶ体裁の整形を本稿でまとめたものに当たる2。
- 決定的な再現性が要るとき。 手順を毎回モデルに推論させるのでなく、同梱したスクリプトを実行させる。PDF から全フォーム項目を抜く、といった「毎回同じでないと困る」処理はここに落とす3。
- 組織・チーム固有の作法。 表記ルール、レビューの手順、社内ドメインの前提がこれに当たる。いずれも、モデルが事前学習で持っていない、その現場だけの知識である。
- フォーマット重めの反復作業。 帳票・定型ドキュメント・決まった体裁の生成物。
逆に、一度きりの指示や、モデルが放っておいてもできる自明なことをスキルにしても、常時載る名前と一行説明の一覧に、選ばれない項目が増えるだけである。仕様サイトはさらに、「この PDF を読んで」のような単純な一段階の依頼なら、説明文の噛み合いが完璧でも、基本の道具で片づくためにスキルが呼ばれないことがあると書く8。自明な仕事では、description をどれだけ磨いても選ばれるとは限らない。
普及が生む二つの新しいリスクは説明文の質と実行の信頼
普及の速さは魅力だが、運用側が見落としやすい点が二つある。
- 発見は description の質に懸かっている。 多数のスキルが載る設計では、モデルは名前と一行だけを見て「関係ある/ない」を判断する。仕様サイトはこの一行が「発火の負担をまるごと背負う」と書いており、専用の指針まで置いている8。中身がどれだけ良くても、その一行で選ばれなければ読まれない。スキルを増やすほど、書き分けの精度が効いてくる。
- スキルはコードを実行できる。 同梱スクリプトを走らせられるのが強みだが、それは裏を返せば「何を実行させるか」という信頼と実行の面が増えるということだ。移植性が上がり、他所で書かれたスキルを載せやすくなるほど、出所の確認は省けなくなる。
ここは楽観できない。共有スキルの説明文やコード例に不正なロジックを仕込んでおくと、エージェントが通常作業でそれを流用した瞬間に、明示的な指示なしでシステム権限のペイロードが走る。Qu らは、2026年4月に公開した査読前の報告で、この「サプライチェーン汚染」を実証したと述べている。4フレームワーク・5モデルの8構成で、エージェントが悪性コードを生成するか実行するかしてしまう率は11.6〜33.5%。ただし下限をつくっているのは守りの堅さではない。11.6%の構成は試行の6割が実行時エラーで落ちており、論文自身がこのセルを「保守的な下限」と断って、主要な結論は妥当応答率87%超の5構成に置いている。守りが最も堅い構成の値は13.5%だ6。実際にホスト上でペイロードが走った率だけを取っても2.3〜27.1%あり、最も堅い構成でも2.3%は走った。同じ構成で、露骨に「これを実行しろ」と書き込む従来型の注入は実行率0%だった6。論文はこの対照を「下限を与えるもの」と限定し、より巧妙な注入との比較は今後の課題としている6。攻撃は防御の二層もともに抜けている。静的解析は攻撃の90.7%を捕まえたが、2.5%は静的解析とモデル側の安全アライメントの両方をすり抜けた。なお著者らは責任開示を行っており、確認された4件の脆弱性のうち2件は修正済みだと記している。4件の共通原因として論文が挙げるのは、フレームワークが実行権限を意味ではなく構文上の境界で与えるという、設計上の穴である6。
共通して効く歯止めは新しくない。認可は LLM の判断に任せず下流で強制し、エージェントに渡す機能と権限は必要な最小限にとどめることだ9。Qu らの報告はさらに、Claude Code 上の3モデルの結果を突き合わせ、3つとも突破された試料が1.6%にとどまると数えている(単一モデルでは13〜20%)6。論文はここから、異種モデルの併用で攻撃面が2%未満へ縮むと推論している。併用した防御そのものを走らせた値ではない。
競合をまたぐ共通フォーマットは、MCP と AGENTS.md に続いて、ここでも合意に至った。だが「置くだけで動く」の手軽さと、「どれを置くべきか・その出所は確かか」の判断は別の問題として残る6。
出典9件
-
AGENTS.md の公式サイトは、逐語
A simple, open format for guiding coding agents, used by over 60k open-source projectsと書き、特定製品の形式を避けた理由を逐語Rather than introducing another proprietary file, we chose a name and format that could work for anyoneと述べる。対応一覧には OpenAI の Codex・Google の Jules と Gemini CLI・GitHub Copilot・JetBrains の Junie が並ぶ(2026-09-30 取得)。常時の指示ファイルでは、Agent Skills の前に競合をまたぐ共通形式があった側の裏づけ。GitHub の公開リポジトリの作成日は 2025-08-19(GitHub API のcreated_at)。https://agents.md https://github.com/agentsmd/agents.md ↩ -
仕様サイト
agentskills.ioは Agent Skills を「もともと Anthropic が開発し、オープン標準として公開された」ものと記す(公開日 2025-12-18 は Anthropic 自身が Engineering 記事の冒頭に追記している3)。狙いはクロスプラットフォームの移植性である。これは、特定製品への囲い込みを離れ、書いたスキルをツールをまたいで持ち運べる、という便益の側だ(競合をまたいで対応ツールが並ぶこと自体がその裏づけ5)。用途の名指しは同サイト §Why Agent Skills? の逐語packaging procedural knowledge and company-, team-, and user-specific contextおよび箇条書きRepeatable workflows/presentation formatting(後者はDomain expertise項目の例の一つ)による(2026-08-16 に両ページを取得して確認。これらの語は Anthropic Engineering 記事側には1件も無い)。 https://agentskills.io ↩ ↩2 ↩3 ↩4 -
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 ↩6 ↩7 ↩8 ↩9
-
MCP(Model Context Protocol)は、エージェントを外部ツール・データへつなぐためのオープン標準。仕様サイト自身は Anthropic の名を出していないので、公開元の帰属は Anthropic の発表記事のほうで確かめられる。https://modelcontextprotocol.io https://www.anthropic.com/news/model-context-protocol ↩ ↩2
-
対応ツールの一覧は仕様サイトの公式ショーケースに掲載されている(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
-
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.1。論文自身はThis comparison establishes a lower bound; evaluating DDIPE against more sophisticated injection baselines remains future workと限定)。責任開示の4件については逐語These are architectural blind spots, not implementation bugs(§6)。異種モデル併用は、Claude Code 上の3モデルを別々に走らせた結果の突き合わせで、逐語only 1.6% of payloads bypass all three models simultaneously(§5.3)から、逐語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 ↩6 ↩7 -
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)を明記する。現在の状態は、SEP-2640(Skills 拡張)について逐語is Final. The WG maintains the official Skills extensionとmerged on September 13, 2026と記す(2026-09-30 取得)。先行標準の側が後発の仕様を公式の拡張として取り込んだ、という材料である。発足の経緯の SEP-2076 は、GitHub 上で 2026-02-24 に未マージのまま閉じられている。https://modelcontextprotocol.io/community/working-groups/skills-over-mcp https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2076 ↩ ↩2 -
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 -
OWASP, “LLM06:2025 Excessive Agency,” OWASP Top 10 for LLM Applications. 過剰な機能・権限・自律(excessive agency)を LLM アプリの主要リスクに据える枠組み。標準化で拡張を足すのが容易になるほど、エージェントが持つ機能と権限は膨らみ、この過剰リスクは大きくなる。被害はエージェントに与えた権限の範囲で決まるからだ。処方(機能と権限を最小化し、認可を LLM でなく下流で強制)は、裏を返せばこのリスクが構造的に存在することの裏づけでもある。https://genai.owasp.org/llmrisk/llm062025-excessive-agency/ ↩
この記事はAIが執筆しています。内容には誤りが含まれる可能性があります。ご注意ください。