Agent Plugins 1.0.0 とは何か - スキルとMCPサーバーを1つの箱で配る新標準

3行でいうと

• Agent Plugins 1.0.0 は、Agent Skills と MCP サーバーを1つのディレクトリにまとめて配るための、ベンダー中立なパッケージ形式の仕様です。2026年8月6日に公開されました。
• 中身は驚くほど小さく、必須なのはルート直下の plugin.json だけ。スキルは skills/、MCP サーバーは mcp.json という固定位置から発見されます。
• インストール方法・配布・権限モデル・UI はあえて仕様の外に置かれています。「箱の形」だけを揃えて、あとは各クライアントに任せる、という割り切りです。

何が問題だったのか

Agent Skills（SKILL.md）も MCP も、それ単体ではすでに移植可能な標準です。スキルはどのエージェントでも読める Markdown ですし、MCP サーバーはどのクライアントからでも同じプロトコルで喋れます。

移植可能でなかったのはそれらを入れる箱のほうでした。Claude Code は .claude-plugin/plugin.json、Cursor は .cursor-plugin/plugin.json、GitHub Copilot はルートの plugin.json、というように、クライアントごとに別のマニフェストとディレクトリ規約が生まれていました。MCP の設定ファイル名も mcp.json だったり .mcp.json だったりと揺れがあり、トランスポート（stdio か HTTP か）を設定オブジェクトの形から推測する実装まであります。

結果として、同じスキルと同じ MCP サーバーを2つのクライアントに配ろうとすると、パッケージをフォークして2つ分メンテすることになり、やがて中身がずれていく（fork and drift）。Google の発表記事はこの状況を「問題はコンポーネントではなくマニフェストだ」と表現しています。

Agent Plugins は、この「箱」の部分だけを最小限そろえにいった仕様です。

誰が作ったのか

Vercel が提案し、Amazon Web Services / Anysphere（Cursor）/ GitHub / Microsoft / OpenAI / Vercel の各社が共同で仕様をまとめた、と Vercel の発表記事は説明しています。

ガバナンスは Technical Charter で規定され、Technical Steering Committee（TSC）は Core Maintainer で構成されます。リポジトリの MAINTAINERS.md に記載されている初期メンバーは次のとおりです。

Charter には「単一のベンダーが Core Maintainer 議席の過半数を握ってはならない」という条項が明記されています。ライセンスは仕様テキストと文書が CC-BY-4.0、コードが Apache 2.0 です。

Google は2026年8月6日付の Developers Blog で、Kevin Hou 氏を代表として Core Maintainer に加わると表明しています（本記事執筆時点のリポジトリの MAINTAINERS.md には、まだ上記5名のみが記載されています）。

プラグインの中身

プラグインはディレクトリです。アーカイブ形式でもレジストリから取得するバンドルでもありません。仕様の Design Decisions セクションは、この選択の理由を「ls / cat / git といった標準ツールでそのまま覗けて、開発中にその場で編集でき、特別なツールなしにバージョン管理に載る」からだと説明しています。

標準レイアウトはこうなります。

my-plugin/
├── plugin.json
├── skills/
│   └── summarize/
│       ├── SKILL.md
│       ├── scripts/
│       │   └── analyze.sh
│       └── references/
│           └── checklist.md
├── mcp.json
├── com.example.client/
│   └── hooks/
├── LICENSE
└── CHANGELOG.md

必須なのは plugin.json だけで、skills/ も mcp.json も任意です。そして重要な制約として、plugin.json はコンポーネントの位置を変更できず、コンポーネントをインライン宣言することもできません。発見パスの設定も、優先順位のルールも存在しない、ということです。

最小のプラグイン

実質2行です。

{
  "$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
  "name": "hello-plugin"
}

これに skills/greet/SKILL.md を1枚置けば、もう有効なプラグインになります。

---
name: greet
description: Greet the user and offer help.
---
 
Greet the user and offer help.

plugin.json の仕様

マニフェストのスキーマは閉じている（closed）のが特徴です。トップレベルに置ける項目は次の10個だけで、それ以外のフィールドはスキーマ違反になります。

$schema の値は 1.0.0 では https://agent-plugins.org/schemas/1.0.0/plugin.schema.json でなければなりません。しかも仕様は、クライアントはプラグイン読み込み時にスキーマをネットワーク取得してはならないと定めています。$schema はあくまで「ローカルに実装済みの検証ルールを選ぶためのキー」であって、フェッチ先ではないわけです。

name の制約もきっちり決まっています。

• 1〜64文字
• 小文字英数字、ハイフン、ピリオドのみ
• 先頭と末尾は英数字
• -- と .. の連続は不可

有効な例は my-plugin / acme.tools / lint3r、無効な例は My-Plugin（大文字）/ -start（先頭ハイフン）/ has--double / too.many..dots です。

未知のフィールドの扱いがうまい

閉じたスキーマというと厳しすぎる印象を受けますが、失敗の境界が丁寧に切られています。

• 未知のトップレベルフィールド: スキーマ違反ではあるが致命的ではない。クライアントは報告した上で無視し、プラグインの読み込みは続行する
• extensions がオブジェクトでない: 同じく報告して無視、続行
• それ以外のスキーマ違反: 致命的。クライアントはプラグインを拒否し、いかなるコンポーネントも発見・実行してはならない

タイポ検出とスキーマ駆動の補完が効く厳格さを保ちつつ、フィールドが1つ増えただけで既存クライアントが全滅する事態は避ける、というバランスの取り方です。

skills/ の扱い

Agent Plugins はスキルの形式そのものは定義しません。SKILL.md のフォーマットもフロントマターの項目も、Anthropic 発の Agent Skills 仕様が正典であり、Agent Plugins が定義するのは「プラグインの中でスキルをどこから発見するか」だけです。

ルールはシンプルで、skills/ の直下の子ディレクトリのうち、SKILL.md という名前の通常ファイルを持つものが1つのスキルとして扱われます。より深い階層を再帰的に探索してはならないと明記されています。

skills/
└── deploy/
    ├── SKILL.md
    ├── scripts/
    │   └── rollback.sh
    └── references/
        └── runbook.md

スキルが1つ壊れていても、クライアントはそれをスキップして他のスキルとコンポーネントの読み込みを続けます。skills/ が存在しないこと自体はエラーではありません。

Claude Code でスキルを書いたことがある方なら、この形はそのままです。スキル単体の書き方はClaude Code スキルで新規サイト立ち上げをワンコマンド化するで扱っています。

mcp.json の仕様

MCP サーバーの設定はプラグインルートの mcp.json に置きます。plugin.json の中にインラインで書くことも、別のパスから読むことも禁止されています。

トップレベルは $schema と mcpServers の2つだけです。

{
  "$schema": "https://agent-plugins.org/schemas/1.0.0/mcp.schema.json",
  "mcpServers": {
    "validator": {
      "type": "stdio",
      "command": "./bin/validator",
      "args": ["--data", "${PLUGIN_DATA}/validator"],
      "env": {
        "CONFIG": "${PLUGIN_ROOT}/config.json"
      },
      "cwd": "${PLUGIN_ROOT}"
    },
    "deployment-api": {
      "type": "streamable-http",
      "url": "https://deploy.example.com/mcp",
      "headers": {
        "X-Tenant": "public-tenant"
      }
    }
  }
}

トランスポートは明示必須

既存クライアントは設定オブジェクトの形からトランスポートを推測していましたが、Agent Plugins ではtype の宣言が必須で、クライアントは宣言されたトランスポートで初回接続を試みます。接続に失敗したときのフォールバックは仕様の範囲外です。

MCP 対応クライアントは stdio か streamable-http の少なくとも一方をサポートすればよく、両方が望ましい、とされています。ローカルプロセス実行とリモートHTTP接続では信頼モデルが違うため、両方を必須にすると実装と攻撃面が無意味に広がる、というのがその理由です。

command は1トークン、シェル文字列ではない

command には実行ファイル1トークンしか書けません。シェルコマンド文字列（sh -c "..." 相当の1行）は不可です。値は次のどちらかに限られます。

• 素の実行ファイル名（プラットフォームの検索ルールで解決）
• ./ で始まるプラグイン相対パス（プラグインルートを基準に解決）

プラグインにバイナリを同梱する場合は必ず後者を使う必要があります。また command にはプレースホルダ展開が適用されません。

${PLUGIN_ROOT} と ${PLUGIN_DATA}

stdio サーバーを起動するクライアントは、サブプロセスに次の2つの環境変数を必ず与えます。

• PLUGIN_ROOT: プラグインルートの絶対パス。同梱のスクリプト・バイナリ・設定ファイルを参照するのに使う
• PLUGIN_DATA: そのプラグインインスタンス専用の、クライアント管理の永続データディレクトリ。書き込み可能で、プラグイン更新をまたいで内容が保持される

PLUGIN_DATA は node_modules や仮想環境、生成コード、キャッシュなど「更新で消えては困る状態」の置き場です。パッケージの中身は更新時に丸ごと差し替わりうるので、この分離が効きます。

プレースホルダ展開は args の各要素、env の各値、cwd に対して行われ、1回きり・非再帰です。置換で現れたテキストをさらに走査してはならない、と明記されています。env のキー、command、リモートURL、HTTPヘッダには展開されません。

また env に PLUGIN_ROOT / PLUGIN_DATA という名前のエントリを書くと、そのサーバー設定は無効になります。予約変数はクライアントが自分でセットするからです。

パッケージ境界の安全設計

地味ですが重要なのが、パス封じ込め（containment）の規定です。

クライアントがパッケージ由来のファイルを読んだり実行したりするとき、解決後のパスはプラグインルートの内側に留まらなければなりません。シンボリックリンクやジャンクション、reparse point の類でルート外へ抜けるパスは拒否されます。

破れたときの扱いは、影響範囲が最小になるよう段階的に決められています。

1. plugin.json がルート外に解決される -> プラグイン自体を拒否
2. 固定コンポーネント位置がルート外 -> そのコンポーネント種別を無効扱い
3. 発見された SKILL.md がルート外 -> そのスキルだけスキップ
4. MCP の command / cwd が封じ込めに失敗 -> そのサーバーエントリだけ無効
5. その他のパッケージパス -> そのパスへのアクセスのみ拒否

なお仕様は、これがプラグインのサブプロセスをサンドボックス化するものではないと明言しています。あくまで「パッケージが供給するファイルへのアクセス」の話であって、起動したプロセスが何をするかは制約していません。

壊れ方が設計されている

Agent Plugins を読んでいて一番好感が持てるのは、失敗が独立している点です。

• MCP サーバーが起動・接続・認証に失敗しても、そのプラグインのスキルは生きたまま
• サーバー1つの設定が不正でも、他のサーバーは読み込まれる
• クライアントが対応していないトランスポートのエントリは、スキップされるだけ
• 対応していないコンポーネント種別は無視する（エラーではない）

そのうえで「クライアントは不正な設定とコンポーネントの失敗を報告すべき（SHOULD）」という診断要件が対で置かれているので、静かに壊れるのではなく見える形で壊れるようになっています。

あえて入れなかったもの

v1 が標準化したコンポーネント種別はスキルと MCP サーバーの2つだけです。コマンド、フック、サブエージェント、ルール、LSP サーバーは入っていません。

理由は Design Decisions に書かれています。スキルと MCP は「このプロジェクトの外にすでに確立した仕様があり、クライアントをまたいだ採用実績がある」のに対し、他はまだクライアント固有すぎて、安定した移植契約にならない、という判断です。

では既存のフックやサブエージェントはどこへ行くのか。答えがクライアント拡張の逆ドメイン名前空間です。

example-plugin/
├── plugin.json
├── skills/
│   └── summarize/
│       └── SKILL.md
└── com.example.client/
    └── hooks/
        └── hooks.json

マニフェスト側にも同じ名前空間でデータを置けます。

{
  "$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
  "name": "example-plugin",
  "extensions": {
    "com.example.client": {
      "setting": true
    }
  }
}

Agent Plugins は拡張データの中身にいっさい意味を割り当てません。実装していない名前空間は中身を検証せずに無視することが求められます。中央のクライアント名レジストリを作らずに衝突を避けるための、素直な設計です。

対応クライアント

agent-plugins.org が「Compatible clients」として掲載しているのは、本記事執筆時点で次の5つです。

AWS は Kiro の拡張機構である Kiro Powers が Agent Plugins 仕様にネイティブ対応したこと、AWS Agent Toolkit が Lambda / S3 / DynamoDB / CDK などをカバーする30以上のスキルを同形式で提供することを発表しています。Google は Agents CLI と Data Agent Kit（BigQuery / Spanner / Cloud SQL 接続）の2製品で対応済みとしています。

VS Code の実装が現実を物語っている

VS Code のドキュメントを読むと、移行期のリアルがよくわかります。VS Code はルートのマニフェストを見て4つの形式を自動判別します。

MCP 設定ファイルの位置も、Agent Plugins 形式なら mcp.json、Claude / Copilot 形式なら .mcp.json と分岐します。つまり標準ができたからといって既存形式が消えるわけではなく、当面はクライアント側が全部読む、という運用になっています。

なお VS Code は現状、Agent Plugins 1.0 パッケージ内のクライアント拡張データとディレクトリを無視すると明記しています。エスケープハッチは仕様上用意されていても、クライアントが必ず使うわけではありません。

Cursor も同様に、Agent Plugins と .cursor-plugin/plugin.json を持つ Cursor Plugins の両方を並行サポートし、「仕様に準拠したプラグインは変更なしで Cursor にロードされる」としています。ルール・エージェント・コマンド・フックは引き続き Cursor Plugins 側の機能です。

Claude Code はどうなのか

本ブログは Claude Code の記事が多いので、ここははっきり書いておきます。

Anthropic は TSC に入っておらず、agent-plugins.org の Compatible clients にも Claude Code は掲載されていません（本記事執筆時点）。Claude Code のプラグインは引き続き .claude-plugin/plugin.json を起点とする独自形式で、コマンド・サブエージェント・フック・MCP サーバーを1パッケージにまとめられます。この形式はClaude Code プラグイン導入ガイドで扱っています。

ただし断絶しているわけではありません。

• スキルの中身（SKILL.md）は Anthropic 発の Agent Skills 仕様そのもので、Agent Plugins はそれを正典として参照しています
• Google の Agents CLI は、Agent Plugins 形式でパッケージしたうえで「Antigravity、Gemini CLI、Claude Code、Cursor のいずれでも使える」と説明しています
• VS Code は Claude 形式のプラグインを Agent Plugins と並べて読み込みます

構図としては、コンポーネントの標準（Agent Skills / MCP）は共有されていて、箱の標準だけがまだ二本立て、という状態です。Anthropic は MCP と Agent Skills という2つの標準を自ら開いてきた実績があるので、今後どう動くかは注目どころですが、現時点で公式表明は確認できていません。

既存プラグインの移行

仕様リポジトリとは別に、agent-plugins-example という参照パッケージが公開されていて、その中に移行ガイドがスキルとして入っています。要点を抜き出すとこうなります。

.claude-plugin/plugin.json / .plugin/plugin.json / .github/plugin/plugin.json / .codex-plugin/plugin.json などのマニフェスト、skills/ .agents/skills/ .github/skills/ .claude/skills/ などのスキル配置、.mcp.json などの MCP 設定、フック・コマンド・サブエージェント・LSP・UI アセットの場所をすべて洗い出します。消費者と代替先が判明するまで、何も消さない・動かさないのが原則です。

移行ガイドが強調しているのは順序です。まずポータブルなマニフェストとコンポーネントを追加し、動いているクライアント固有パッケージはそのまま残す。ポータブル側を正（source of truth）にして、レガシーアダプタは必要なぶんだけ生成する。全対応クライアントでテストし、消費者の移行が済んでから古いファイルを消す。

リポジトリの構成としては、ポータブルなパッケージとクライアントアダプタを兄弟ディレクトリとして並べ、どれが正本かを明示して同期を自動化する形が推奨されています。

そして「プラグインにしない」判断

Google の発表記事に、実務的で良い一節があります。

単一のクライアントに単一の MCP サーバーを配るだけなら、mcp.json 単体のほうが簡単な答えのままです。スキルが1つだけなら、プラグインは要りません。Agent Plugins が元を取るのは、まとまって存在すべきコンポーネントがあり、それらが一緒に旅をする必要があるときです。

パッケージ形式が標準化されると何でも包みたくなりますが、包む理由がないものを包むコストのほうが大きい、という話です。

まだ無いもの

FUTURE_CONSIDERATIONS.md に、v1 で扱っていない領域が正直に列挙されています。「静かに省略したのではなく、明示的に名指ししてある」という点は評価できます。

• 権限・承認 UX: 信頼モデル、権限宣言、サンドボックス要件、段階的な信頼レベル
• 来歴検証: 署名検証、ソースリポジトリとビルドを結ぶ attestation
• シークレット取り扱い: secrets フィールド、クライアント仲介の秘密注入、ローテーションと失効
• 企業統制: 許可/拒否リスト、組織スコープのレジストリ、中央設定のオーバーライド
• 監査証跡: install / enable / disable / update / uninstall の標準イベントスキーマ
• 依存解決: プラグイン間の依存宣言とバージョン制約
• テストと検証: 標準リンタ、クライアント実装向け適合テストスイート

つまり現時点の Agent Plugins は、npm でいえば「package.json のフォーマット合意」までしか無い状態です。レジストリも、署名も、権限も、依存解決も無い。そこは各クライアントが自前で埋めており、実際 Cursor はチームマーケットプレイスと手動レビュー、VS Code はマーケットプレイス設定と信頼プロンプト、Anthropic は公式カタログというように、配布層はすでに各社バラバラに実装されています。

まとめ

• Agent Plugins 1.0.0 は2026年8月6日公開の、Agent Skills と MCP サーバーをまとめて配るためのベンダー中立なパッケージ形式です。Vercel の提案から AWS / Anysphere / GitHub / Microsoft / OpenAI / Vercel が共同で策定しました。
• プラグインはディレクトリで、必須は plugin.json 1枚。スキルは skills/ 直下、MCP は mcp.json という固定位置から発見され、マニフェストで位置を上書きすることはできません。
• マニフェストのスキーマは閉じていますが、未知フィールドは報告して無視・続行。コンポーネントの失敗も互いに独立していて、1つ壊れても他は生きます。
• v1 のコンポーネントはスキルと MCP サーバーの2つだけ。フック・コマンド・サブエージェント・LSP は逆ドメイン名前空間のクライアント拡張へ逃がす設計です。
• 対応クライアントは VS Code / Cursor / GitHub Copilot / ChatGPT & Codex / Kiro。Claude Code は現時点で掲載がなく、.claude-plugin/plugin.json の独自形式が続いています。
• インストール・配布・権限・署名・監査はすべて仕様の外。そこは各クライアントの実装と、将来のバージョンに委ねられています。

「箱の形だけ揃えて、あとは触らない」という抑制の効いた仕様です。既存プラグインを持っているなら、まずはポータブルなマニフェストとコンポーネントを追加するところから始めるのが、いちばん事故が少ない進め方でしょう。

参考リンク

• Agent Plugins 公式サイト
• Agent Plugins Specification 1.0.0（仕様本文）
• agentplugins/agent-plugins-spec（GitHub）
• agentplugins/agent-plugins-example（参照パッケージと移行ガイド）
• Introducing Agent Plugins（Vercel）
• Agent Plugins package your skills, tools, and more（Google Developers Blog）
• AWS Supports Agent Plugins（AWS Open Source Blog）
• Agent plugins in VS Code（公式ドキュメント）
• Plugins（Cursor 公式ドキュメント）
• Agent Skills Specification
• Model Context Protocol Specification