Agent Plugins 1.0とは​何か​ ──OpenAI・Microsoft・Amazon・Googleが​合意した​AIエージェント拡張機能の​共通フォーマットを​解説

2026年8月6日、Amazon・Cursor・Microsoft・OpenAI・Vercel が Agent Plugins 1.0.0 という共通仕様を公開した^[1][3]。同じ日に Google もコアメンテナとして加わっている^[4]。

決めたのは、AIエージェントの拡張機能を どういう形のフォルダに入れて配るか だけだ。中身の技術を新しく発明したわけではない。それでも、これまで各社がバラバラに決めていた「入れ物」が揃うと、一度作った拡張機能をツールを乗り換えても持ち運べるようになる。

この記事で分かること——①何が決まったのか ②なぜ「入れ物」だけが問題だったのか ③仕様の実際の中身 ④この顔ぶれに Anthropic がいない理由 ⑤権限もサンドボックスも署名検証も、まだ何も決まっていないという重要な事実。

この記事の数値・仕様はすべて公開されている一次資料（仕様サイト、仕様リポジトリ、各社の発表）に基づくもので、CAG自身が性能などを検証したものではない。手元の Claude Code で実際に確認した部分だけ、その旨を明記している。

01 何が​公開されたのか ──決めたのは​「箱」だけ

Agent Plugins は、AIエージェントの拡張機能をひとつのフォルダにまとめて配るための、ベンダー中立の仕様である^[1]。

ここで言う拡張機能は、いま2種類ある。

部品	何をするもの
Agent Skills	AIに「この作業はこうやる」と教える手順書のセット。Markdownで書かれた SKILL.md を中心に、補助スクリプトや参考資料をフォルダにまとめたもの
MCPサーバー	AIを社内データベースやカレンダー、外部サービスなどの実際の道具につなぐ接続口。MCP（Model Context Protocol）はその接続の共通規格

どちらもすでに仕様があり、それぞれ普及もしている。Agent Plugins はこの2つを再定義しない。この2つを一緒に入れて配るための箱の形だけを決めた。

仕様サイトの説明もそこを繰り返している。配布方法、インストール方法、権限、UI、クライアント固有の機能は、各クライアントの裁量のまま残す。可搬にできる部分だけを最小限そろえる、という立て付けだ。

版番号は 1.0.0 だが、仕様書のステータス欄は Working Draft（作業中の草案）と書かれている^[2]。

02 中身は​前から​あった​ ──足りなかったのは、​一箱ぶん

なぜ箱だけが問題になるのか。Google の発表がこの状況を具体的に書いている^[4]。

スキルを1つ書き、それと組みで動くMCPサーバーを1つ書いたとする。2つで1つの仕事をきちんとこなす。ここまでは何の問題もない。ところが、それを2つ目のクライアントにも配ろうとすると詰まる。スキルは同じ、MCPサーバーも同じ。違うのはその2つを包んでいる外側である。ディレクトリの並べ方が違い、マニフェスト（説明書きのファイル）が要求する項目が違い、MCPの設定の書き方も違う。

結果として、作者はパッケージをフォークして、本来まったく同じはずの中身のコピーを2つ持ち、それが少しずつズレていくのを眺めることになる。

問題は部品ではなく、マニフェストだった。^[4]

これは発注する側の言葉に置き換えると分かりやすい。社内向けに作らせたAIの拡張機能が、開発ツールを乗り換えた瞬間に作り直しになる、という話だ。中身は1行も変わっていないのに。

03 仕様を​開けてみる​ ──ディレクトリ1つ、​マニフェストは​実質2行

実際の形は拍子抜けするほど小さい。プラグインとは、次のようなディレクトリのことである^[1][2]。

my-plugin/
├── plugin.json          # 必須。これがあればプラグイン
├── skills/              # スキルを1つずつサブフォルダで
│   └── summarize/
│       ├── SKILL.md
│       ├── scripts/
│       └── references/
├── mcp.json             # MCPサーバーの設定
└── com.example.client/  # 特定クライアント専用の置き場

必須なのは plugin.json ひとつだけ。その中身も最小構成では実質2行だ。

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

残りは全部「決められた場所にある」ことで通じる。設計として面白いのは、マニフェストに何ができないかが決まっている点である。

• コンポーネントの置き場所を変更できない
• コンポーネントをマニフェストの中に直接書けない
• 探索パスの設定項目もなければ、優先順位のルールもない

「設定できる余地」を減らすことで、クライアント側は迷わず読める。仕様書の言い方だと、探索・検証・読み込みが決定的な手続きになる。

実務で効きそうな決めごとが3つある。

部品は独立して壊れる。mcp.json に書いたサーバーが1つ起動に失敗しても、そのプラグインのスキルまで巻き添えで無効になることはない。クライアントはその項目だけ飛ばして読み込みを続け、失敗を報告する。

MCPの接続方式は明示させる。各エントリに type を必ず書かせ、stdio・Streamable HTTP・従来のHTTP+SSE のどれなのかを設定の形から推測させない。

プラグインの外にはアクセスさせない。仕様上、読み書きするパスはプラグインのフォルダの中に収まっていなければならず、シンボリックリンクなどで外に出るパスはクライアントが拒否しなければならない（MUST）と定められている^[2]。

そして最後の com.example.client/ は逃し場だ。逆ドメイン形式の名前を付けたこのフォルダは、そのクライアントが自由に使ってよい領域で、知らないクライアントは無視する。共通部分を小さく保つために、共通にできない部分に居場所を与える設計になっている。

04 この​顔ぶれに​ Anthropic が​いない​ ──手元の​ Claude Code と​並べてみる

仕様リポジトリの MAINTAINERS には、コアメンテナが個人名で5人載っている^[2]。

氏名	所属（仕様の議論で代表する組織）
Clare Liguori	Amazon
Roshan Sadanani	Cursor
Harald Kirschner	Microsoft
Gav Verma	OpenAI
Jonathan Hefner	Vercel（Lead Core Maintainer）

ここに Google の Kevin Hou（Google DeepMind）がコアメンテナとして加わった^[4]。ガバナンス文書には、役職は組織ではなく個人が持つこと、特定企業に席は予約されないこと、そして 1社がコアメンテナ席の過半を握ってはならない ことが明記されている^[2]。

一方、仕様サイトの互換クライアント一覧に並んでいるのは次の5つだ^[1]。

クライアント	Agent Skills	MCPの接続方式
VS Code	対応	stdio / Streamable HTTP / legacy SSE
Cursor	対応	stdio / Streamable HTTP / legacy SSE
GitHub Copilot	対応	stdio / Streamable HTTP / legacy SSE
ChatGPT & Codex	対応	stdio / Streamable HTTP
Kiro（Amazon）	対応	stdio / Streamable HTTP / legacy SSE

コアメンテナにも、この一覧にも、Anthropic と Claude Code の名前がない。

これは少し引っかかる話だ。箱に入れる中身2つは、どちらも Anthropic 由来だからである。MCP は Anthropic が作って公開した規格であり、Agent Skills ももともと Claude 向けの形式で、その後オープン標準として公開され、現在は agentskills.io で仕様が維持されている^[6]。中身を作ったのは Anthropic で、その中身を包む箱を決めたのは他の全員、という構図になっている。

ただし、これを「Anthropic が遅れている」と読むのは正確ではない。手元で確かめると、事情がもう少し具体的に見える。

執筆時点の Claude Code（バージョン 2.1.226）でプラグインの実物を開くと、こういう形をしている^[7]。

プラグイン/
├── .claude-plugin/
│   └── plugin.json      # マニフェストは隠しフォルダの中
├── skills/
├── commands/             # スラッシュコマンド
└── agents/               # サブエージェント

マニフェストの中身も違う。Claude Code 側は "skills": ["./skills/engineering/tdd", ...] のように、スキルの場所をマニフェストの中に配列で列挙している。これはAgent Plugins が明示的に禁じた書き方だ。

そして決定的なのは、扱う部品の数である。Agent Plugins v1 が可搬にしたのは Skills と MCP の2つだけで、commands・hooks・agents はクライアント側に残すと Vercel の発表に明記されている^[3]。Claude Code のプラグインはその3つを標準装備しているので、そもそも v1 の箱には収まりきらない。

つまり今回そろったのは、各社の拡張機能が 共通して持っている部分の最大公約数 である。Agent Plugins の技術運営委員会も、部品の種類を今後増やす可能性は残す、と書いている^[3]。

05 わざと​決めなかった​こと​ ──権限・サンドボックス・署名検証

導入を考える側にとって、いちばん重要なのはここだ。

Agent Plugins v1 は パッケージの形式であって、それ以上のものではないと自ら宣言している。仕様が定義していないものを、発表文がそのまま列挙している^[4]。

しかもこれらは黙って省かれたのではなく、リポジトリの Future Considerations（今後の検討事項）に、次の版で扱うかもしれない項目として書き出されている^[2]。そこに並ぶ項目が、そのまま企業導入のチェックリストになっている。

いま決まっていないこと	検討事項として挙がっている内容
権限と承認	マニフェストでの権限宣言（ファイル・ネットワーク・ツールへのアクセス）、プラグインごとの機能制限、インストール時の同意フロー、段階的な信頼レベル
来歴の検証	公開プラグインの署名検証、ソースリポジトリとビルドをつなぐ証明の連鎖、信頼できる発行者の署名を必須にする方針
秘密情報の扱い	認証情報やAPIキーをどう渡し保管するか、設定ファイルに平文で置かない仕組み、プラグイン間で秘密を覗かせない分離
企業統制	名前・発行者・署名によるインストールの許可／禁止リスト、組織単位のレジストリと承認フロー、利用者設定より優先される中央設定
監査ログ	インストール・有効化・更新・削除の標準イベント形式、外部ログ基盤やSIEMへの転送

読んでのとおり、組織として安全にプラグインを配る仕組みは、まだ1つも標準化されていない。

これは仕様の欠陥ではなく、意図的な線引きだ。可搬にできる部分から先に固め、安全性は各クライアントが自分の責任で実装する。ただし導入する側から見れば、「共通フォーマットに対応している」ことは、安全性については何も保証しない、という意味になる。

拡張機能を配る仕組みの安全性については、以前に別の角度から書いている。

関連記事 ｜ 箱の中身そのものが実行権限を持っている便利なAIスキル、入れる前に中身を見ていますか ──Agent Skillは「プロンプト集」ではなく、実行権限を持つ部品だった →

06 導入する​側が、​今日確認できる​こと

現時点で言えることを、事実の粒度で並べる。

今日から実際に効くこと

• 対応クライアントは VS Code / Cursor / GitHub Copilot / ChatGPT & Codex / Kiro の5つ。仕様サイトが各クライアントの対応範囲を公開している
• 自社で作ったスキルとMCPサーバーを、1つのフォルダにまとめて複数クライアントに配れる
• 標準の側から見ると Claude Code は現時点で対象外。ただし Claude Code は自前のプラグイン機構をすでに持っている

まだ決まっていないこと

• プラグインに何を許すかの権限モデル、隔離実行、署名や来歴の検証
• 組織単位の許可リスト・承認フロー・中央設定・監査ログ
• 認証情報の安全な渡し方

社内で確認しておくと良いこと

• 外部から持ってきたプラグインを誰が承認するか。標準は決めてくれないので、自社ルールが必要になる
• MCPサーバーは実際にコマンドを実行し外部サービスに接続する。何につながるかを一覧にできているか
• 手元のスキルやMCP設定が、いまどのツール固有の形式で書かれているか

最後にもうひとつ。Google の発表には、標準化する側が書くとは思えない一節がある。

すべてのスキルがプラグインである必要はない。^[4]

MCPサーバーを1つ、1つのクライアントに配るだけなら mcp.json だけで足りる。スキルが1つしかないならプラグインは要らない。一緒に運ばれるべき部品が複数あるときにはじめて、この箱は元が取れる。

拡張機能の入れ物が共通になったのは前進だ。ただ、揃ったのは箱の形だけで、その箱に何を入れてよいかを決めるのは、まだ各社と、それを使う組織の仕事として残っている。