Agent Plugins 1.0：すべてのAIエージェントに共通する単一のパッケージ形式

Agent Plugins とは何でしょうか。 Agent Plugins 1.0 は、2026年8月6日に公開されたオープンでベンダー中立なパッケージング標準です。Agent Skills と MCP サーバー設定をひとつの移植可能なディレクトリにまとめ、対応するエージェントクライアントであればどれでも読み込めるようにします。プラグインの実体はフォルダで、必須の plugin.json マニフェスト、任意の skills/ フォルダ（Agent Skills を収める）、そして MCP サーバーを宣言する任意の mcp.json から構成されます。ローンチ時点で ChatGPT、Codex、Cursor、GitHub Copilot、Kiro、VS Code が対応しています。¹²

日々競い合っている6社が、エージェントを使う誰もが感じてきた問題に対して、ひとつの共通解を出しました。あるエージェントクライアント向けに作った拡張が、次のクライアントでは動かないという問題です。提案を立ち上げたのは Vercel で、仕様は Amazon、Anysphere（Cursor の開発元）、GitHub、Microsoft、OpenAI とともに策定されました。² Google も同じ日に、コアメンテナーへの参加と自社製品への実装を発表しています。⁶ 公式サイトの一行説明はこうです。「AI エージェントを拡張する再利用可能なコンポーネントのための、ポータブルなパッケージ形式」¹

パッケージ化される2つのレイヤーを生み出した企業の名前は、メンテナー一覧にありません。その不在こそが話の半分であり、この記事の後半のテーマです。

要点： Agent Plugins 1.0 が標準化したのは、既存の2つの仕様――Agent Skills と Model Context Protocol――を取り巻くパッケージング層であって、どちらの置き換えでもありません。共有可能なディレクトリの中で両者がどこに置かれるかを定めただけです。¹ プラグインはフォルダであり、識別情報は plugin.json、スキルは skills/、サーバーは mcp.json、そしてクライアント固有の追加要素は逆ドメイン形式の名前空間フォルダに置かれます。バージョン1は意図的に相互運用性の最低ラインに留まっており、インストール、レジストリ、パーミッション、来歴、シークレット、OAuth について移植可能なセマンティクスを一切定義していません。それらはすべてクライアント側の管理に委ねられます。¹² Codex は v0.146.0 と v0.147.0 にまたがって対応を実装しました。⁴ Agent Skills と MCP を生み出した Anthropic はメンテナーに名を連ねておらず、Claude Code は独自のプラグイン形式を維持しています。³⁷⁸

要点まとめ

• 個人開発者の方へ： スキルは標準の Agent Skills 形式（SKILL.md を含むフォルダ）で書いておけば、それ自体がすでにポータブルな基盤です。プラグインとして包むにはマニフェストを1枚足すだけで済みます。クライアントごとに写しを維持するのはもうやめましょう。
• チームリードの方へ： この標準が扱うのはパッケージングであり、配布やポリシーではありません。レジストリも更新の仕組みも許可リストの方針も、依然としてクライアントごとの判断です。社内で「一度書けばどこでも動く」と約束する前に、その分の工数を見込んでおいてください。
• セキュリティエンジニアの方へ： バージョン1には来歴の層もパーミッションの層もなく、署名の層もありません。信頼の判断は、インストール時のレビューへ丸ごと移ります。移植性が高まれば、汚染されたスキルによる攻撃の影響範囲もそれだけ広がるのです。

リリースされたもの

2026年8月6日、Vercel は Agent Plugins 1.0.0 を公開しました。同社が主導し、Amazon、Anysphere、GitHub、Microsoft、OpenAI とともに策定したオープン仕様です。² 規範となる仕様は公開リポジトリに置かれ、そのメンテナー陣は Amazon、Cursor、Microsoft、OpenAI、Vercel にまたがります。³ さらに Google がローンチ当日、コアメンテナーとして参加し、自社のエージェントツールへの実装をすでに進めていると発表しました。⁶

ローンチ時点の対応クライアントは、エコシステムの主要な入口をほぼ網羅しています。VS Code、Cursor、GitHub Copilot、ChatGPT と Codex、そして Kiro です。¹² Codex の CLI 対応は、実のところ公式発表より先行していました。v0.146.0（7月29日）で Agent Plugins のマニフェストとワークスペースへのプラグイン公開が加わり、v0.147.0（8月7日）でポータブルなプラグインのインストールと、ローカル・個人・ワークスペース・リモートの各カタログを横断する検索が揃って完成しています。⁴

対象範囲は仕様の冒頭の一文が示すとおりです。「AI エージェントを拡張する再利用可能なコンポーネントを、配布可能なプラグインへとパッケージングするための正式な Agent Plugins Specification v1.0.0 を定義する」¹ つまりパッケージングであり、新しいスキル記述言語でも、MCP の置き換えでもありません。基盤となる2つの形式はそれぞれ自前の仕様を保ち続けます。この標準が固定したのは、クライアントが発見できるディレクトリの中で両者がどこに置かれるか、という一点です。

プラグインの構造

プラグインは、1つの必須ファイルと3つの任意要素からなるディレクトリです。¹

my-plugin/
├── plugin.json              # required: identity + metadata
├── skills/                  # optional: Agent Skills
│   └── release-notes/
│       └── SKILL.md         # one immediate subdirectory = one skill
├── mcp.json                 # optional: MCP server configs
└── com.example.client/      # optional: client-namespace directory

plugin.json はクローズドスキーマのマニフェストです。トップレベルで許されるフィールドはちょうど10個――$schema、name、version、description、author、homepage、repository、license、keywords、extensions――で、それ以外については仕様が厳格に定めています。「クライアントは未知のフィールドをそれぞれ報告したうえで無視しなければならず（MUST）、マニフェストが本節の他の要件を満たしているならプラグインの読み込みを継続しなければならない（MUST）」¹ name フィールドに使えるのは小文字英数字、ハイフン、ピリオドで、先頭と末尾は英数字、ハイフンやピリオドの連続は不可となります。¹

skills/ は Agent Skills を既存のかたちのまま収めます。「直下の各子ディレクトリのうち、SKILL.md という名前のパスが通常ファイルとして解決されるものを、1つのスキルとして扱う」¹ mcp.json は MCP サーバーを宣言します。プラグインの MCP サーバーに対応するクライアントは「stdio または streamable-http の少なくとも一方に対応しなければならず（MUST）」、両方に対応することが望ましく（SHOULD）、sse は任意です。加えて仕様は、スキルのみを扱うクライアントが MCP サーバーに一切対応しないまま準拠することを明示的に認めています。¹

com.example.client/ のような逆ドメイン形式のディレクトリは、クライアント固有の挙動を収める場所です。移植性のルールは規範的な言葉で書かれています。「クライアントは、自身が実装していない名前空間のマニフェスト項目については、その値の中身を検証することなく無視しなければならない（MUST）」¹

この最後の仕組みは、見た目より重い意味を持ちます。クライアント間で最も差が大きいコンポーネントは、ポータブルな中核から締め出されているのです。コマンド、フック、エージェント、ルール、LSP サーバーは、「安定した移植可能な契約とするにはクライアント固有すぎるままである」コンポーネント型として仕様自身が挙げている例であり、形式が収斂するまで v1 の外に置かれます。¹ ポータブルな中核は、スキルと MCP 設定だけ。それ以上でも以下でもありません。

バージョン1が意図的に外したもの

この仕様は、機能する最小限のものだけを標準化しています。インストール、レジストリ、パーミッション、来歴、シークレット、OAuth のいずれについても移植可能なセマンティクスを定義しておらず、そのすべてがクライアント管理のまま残されています¹²。署名の層も定義されていません。メンテナー陣が示す拡張の道筋は、設計思想として保守的です。コンポーネント型がポータブルな中核へ昇格するのは、実装が十分に収斂し、正確に定義できるようになってからだとされています。¹

これは臆病さではなく、連合の力学として読むべきでしょう。6社――うち5社は互換性のないプラグイン形式を持つエージェントクライアントを出荷しています――が合意できたのは、ファイルがどこに置かれるかまででした。フックがどう発火するか、コマンドがどう登録されるか、誰のパーミッションモデルが優先されるかについては、まだ合意に至っていません。そこで標準は、すでに挙動が収斂していた層（スキルはマークダウンのフォルダ、MCP はワイヤプロトコル）を固定し、争点となる部分はすべて名前空間の中へ囲い込んだのです。これは相互運用性の床であり、床が役に立つのは、まさに全員がその上に立てるからにほかなりません。

その床の代償はこうです。「一度作ればどこでも動く」が当てはまるのはパッケージであって、体験ではありません。プラグインはどこにでもインストールできますが、できることはクライアントごとに異なり、どうインストールされ、更新され、信頼されるかは完全にクライアント任せです。

Anthropic のかたちに空いた穴

奇妙なのはここからです。この標準がパッケージ化する「指示書フォルダ」形式の Agent Skills は、2025年10月に発表された Anthropic の発明です。⁸ Model Context Protocol も同様で、Anthropic が2024年11月にオープンソース化しました。⁷ このパッケージング標準の土台にある2つの層は、いずれもメンテナー一覧のどこにも名前が現れない、ただ一社の主要エージェントツールベンダーから生まれたものなのです。³

Claude Code は独自のプラグイン形式――独自のマニフェスト、独自のマーケットプレイスソース、独自のフックとコマンドのパッケージング――を維持しており、8月6日の発表でそれが変わったわけではありません。橋渡しは今のところ一方通行です。Codex は Claude Code のマーケットプレイスソースを備え（v0.146.0）、その /import コマンドが Claude Code の設定、MCP サーバー、プラグイン、セッション、コマンド、プロジェクト単位のメモリを Codex へ移行します。⁴

実務的には、この継ぎ目は組織図が示すほど大きくありません。理由は基盤にあります。スキルとは、どのエコシステムでも SKILL.md を含むフォルダにすぎないからです。Claude Code 向けに書いたスキルは、Agent Plugin が運ぶものと同じ成果物です。移動できないのは包み紙――片や Claude Code のプラグインマニフェスト、片や plugin.json――と、各エコシステムがネイティブに抱え込むクライアント固有のコンポーネント（何よりフック）だけです。今スキルを保守しているなら、すでにポータブルな層を書いていることになります。分岐しているのはパッケージングであって、中身ではありません。

Anthropic がいずれこの形式を採用するのか、同等のものを公開するのか、それとも橋を一方通行のままにしておくのか。それが今回のローンチが突きつける未解決の問いです。連合の顔ぶれ――主要なエージェントクライアントのベンダーが1社を除いて勢揃い――を見れば、このパッケージング標準の行方を決めるのは技術的な優劣よりも、土台となる2つの層を生み出した不在の当事者が「この床は立つ価値がある」と判断するかどうかだとわかるでしょう。

誰も標準化しなかったサプライチェーンの問題

来歴の層を持たないポータブルなパッケージ形式は、同時にポータブルな攻撃形式でもあります。バージョン1は来歴とパーミッションをクライアント管理に委ね、署名や検証のツールを一切定義していません¹。つまり信頼の判断は、クライアントごと、ユーザーごとに、インストール時点へ丸ごと預けられているのです。

この点は先月よりも今月のほうが重い意味を持ちます。スキルレベルの攻撃に関する近年の研究――最も鋭い例が ElasticBack です――は、単一のスキル文書に仕込まれた条件付きバックドアを実証し、エージェントのスキルを「汚染された1つのスキルが、それをインストールしたすべてのエージェントを継続的に侵害しうる、新たに立ち上がりつつあるサプライチェーン」として位置づけました。⁵ 移植性はこれを何倍にもします。同じ汚染プラグインが、1つではなく6つのクライアントへインストールされるようになり、しかも標準の対象範囲は検出を各クライアント（あるいは各ユーザー）のレビュー任せにしているのです。

この標準が存在する前に、より踏み込んだ議論をAgent Skills にはパッケージマネージャーが必要だで展開しました。エージェントのコンテキストはすでにソフトウェアサプライチェーンであり、それを安全にインストールするには、パッケージエコシステムが長年かけて築いてきた仕組み――マニフェスト、ロックファイル、スコープ付きインストール、レビューゲート、ロールバック――が要るという話です。Agent Plugins 1.0 はマニフェストを提供し、そこで止まりました。残りのリストは、まさに v1 がクライアントに委ねた部分と重なります。インストールするものは自分で点検してください。形式が代わりにやってくれることはありません。（エージェントに見えなかったスキルから派生する注意点をひとつ。エージェントはスキルの説明文を厳しいコンテキスト予算の下で読み込みます。プラグインで配られるスキルもその同じカタログに加わるため、移植性は、すでに黙って切り詰められている待ち行列にさらにスキルを積むことになるのです。）

今日できること

Codex を使っている場合： すでにこの標準が手元にあります。codex plugin がポータブルな Agent Plugins のインストールを提供し、v0.147.0 の時点でプラグイン検索はローカル・個人・ワークスペース・リモートの各カタログにまたがります。⁴ チームは公開マーケットプレイスを立ち上げる代わりに、自分たちのワークスペースへプラグインを公開できます。

Claude Code を使っている場合： プラグイン形式に変更はありません。スキルは標準的なスキルフォルダとして書き続けてください。それがポータブルな層であり、包み紙は使い捨てと考えて構いません。Codex も併用しているなら、Claude Code のマーケットプレイスソースと /import が既存の設定をそのまま持ち運んでくれます。⁴

VS Code、Cursor、Copilot、ChatGPT、Kiro を使っている場合： ローンチ時点の対応クライアント一覧に入っています。プラグインがどうインストールされるかは各クライアントの UX 次第です。標準が意図的にそこを規定していないからです。¹

開発者向けツールを提供している場合： マニフェストは半日で対応できる程度の小ささですし、仕様リポジトリも公開されています。³ 興味深い判断は plugin.json を読むかどうかではなく、自社のどのコンポーネントを逆ドメイン名前空間へ囲い込むかにあります。その境界線こそが、自分たちが何をポータブルとみなしているかの事実上の宣言になるからです。

よくある質問

Agent Plugins は MCP や Agent Skills を置き換えるのでしょうか。

いいえ。仕様が掲げる役割は「AI エージェントを拡張する再利用可能なコンポーネントを、配布可能なプラグインへとパッケージングすること」¹ です。スキルは SKILL.md 形式のまま、MCP サーバーはプロトコルのまま維持され、標準は共有可能なディレクトリの中で両者がどこに置かれるかを定めるだけです。

プラグインでフック、スラッシュコマンド、カスタムエージェントを配布できますか。

v1 では、ポータブルなかたちではできません。仕様はコマンド、フック、エージェント、ルール、LSP サーバーを、「安定した移植可能な契約とするにはクライアント固有すぎるままである」コンポーネント型の例として挙げており、形が収斂するまでポータブル形式の外に置かれます。クライアントは自身の逆ドメイン名前空間ディレクトリの中でそれらを運ぶことができ、実装していない名前空間はクライアントが無視しなければなりません（MUST）。¹ ポータブルな中核はスキルと MCP 設定です。

なぜ Anthropic はこの標準に参加していないのでしょうか。

仕様側も連合側も理由を述べていません。公開されている事実はこうです。メンテナー陣は Amazon、Cursor、Microsoft、OpenAI、Vercel にまたがり、ローンチ時に Google が加わりました³⁶。一方、Agent Skills と MCP の双方を生み出した Anthropic⁷⁸ は不在で、Claude Code は独自のプラグイン形式を保っています。現時点で実用的な橋渡しは Codex 側にあります。Claude Code のマーケットプレイスソースと /import による移行です。⁴

サードパーティ製の Agent Plugins をインストールしても安全ですか。

形式そのものは判断の助けになりません。バージョン1はパーミッションと来歴をクライアント管理に委ね、署名や検証のツールを定義していないからです。¹ プラグインは、自分の権限を渡す他のあらゆるコードと同じように扱ってください。スキルレベルのバックドア研究（ElasticBack）は、汚染された1つのスキル文書が、それをインストールしたすべてのエージェントを条件付きで侵害しうることを示しており、移植性はその導入母数を何倍にもします。⁵

参考文献