2026年8月6日、OpenAI、Microsoft、Amazon、Cursor、Vercelが共同でAgent Plugins 1.0.0をリリースし、AI Agent向けのクロスプロダクト互換のプラグインパッケージ形式を確立しようとしています。開発者は、操作手順、スクリプト、参照資料からなるAgent Skillsと、データベース、クラウドサービス、開発ツールに接続するMCPサーバーを同じディレクトリに配置できます。理论上、一度パッケージ化すれば、ChatGPT、Codex、VS Code、Cursor、GitHub Copilot、Kiroなど互換性のあるクライアントで使用できます。これはモデルの能力を解決するものではなく、Agentエコシステムで進行しているフォーマットの断片化を解決することを目的としています。現在、同じ機能を異なる製品ごとに別々のリストファイルを作成し、ディレクトリ構造を変更し、複数のブランチを維持する必要があるためです。ただし、1.0.0仕様はまだ「作業草案」とされており、現在のところプラグインストア、インストールプロトコル、権限モデル、サンドボックス隔離、ソース検証は定義されていません。したがって、これはAgentエコシステムの「パッケージ形式」に過ぎず、任意のプラグインを安心してインストールできる成熟したアプリストアではありません。著者、出典：Jonathan Hefner、Vercel テクニカルチームメンバー
エージェントはスキルを備えているが、汎用的な「パッケージ」がない
AIエージェントエコシステムは過去1年で2つの重要な拡張機能を形成しました。
第一类是Agent Skills。它们通常由一份SKILL.md文件、相关脚本和参考资料组成，用来告诉Agent如何完成某类工作。比如，部署一个网站、分析财务文件或检查代码安全时，技能可以提供操作步骤、注意事项、验证规则和可直接执行的程序。
第二類はMCPサーバーです。MCPは、Agentが外部ツールやデータに接続するのを担当します。たとえば、データベースの読み取り、GitHubの操作、クラウドプラットフォームのステータス照会、または企業内部システムの呼び出しなどです。Skillsは「Agentにやり方を教える」ことに焦点を当てていますが、MCPは「Agentが実際に呼び出せるツールを提供する」ことに焦点を当てています。
問題は、これらのコンポーネントがこれまで一貫したパッケージ化方法を欠いていたことです。たとえスキルやMCPサーバーのコア内容が完全に同じであっても、開発者がそれを異なるAgent製品に接続する際、清單ファイル、ディレクトリ構造、設定フィールドをそれぞれ変更する必要がありました。その結果、同じ拡張機能が複数のクライアント専用バージョンとして生み出され、あるバージョンでバグが修正されても、他のブランチが同期されないことが頻繁に起こり、Googleが言う「分岐と逸脱」が生じました。
Agent Pluginsが提供するのは、これらの機能を包む汎用的なラッパーです。その役割はJavaScriptエコシステムのpackage.jsonまたはコンテナ分野のOCIフォーマットに近い：内部のコードやプロトコルを置き換えるのではなく、これらをどのように整理・発見・読み込むべきかを一貫して記述します。
プラグインは、本質的にディレクトリです。
按照1.0.0版规范、Agent Pluginは固定構造を持つディレクトリであり、ルートディレクトリにはplugin.jsonが含まれている必要があります。最もシンプルな構成では、使用する規格バージョンとプラグイン名を宣言するだけで十分です。
プラグインにスキルが含まれる場合、それらはすべてskills/ディレクトリに統一して配置し、各スキルは独自のSKILL.mdを持ち、スクリプト、参照ファイル、その他のリソースを付属させることができます。プラグインが外部ツールに接続する必要がある場合、ルートディレクトリにmcp.jsonを配置し、1つ以上のMCPサーバーを宣言します。
MCPセクションは現在、ローカルでのプロセス起動によるstdio、現在推奨されるStreamable HTTP、および旧システムとの互換性のために維持されているHTTP+SSEの3つの接続方式をサポートしています。異なるクライアントはすべての伝送方式をサポートする必要はありませんが、stdioまたはStreamable HTTPのいずれか少なくとも一つはサポートする必要があります。
この固定構造による直接的な利点は、クライアントがファイルの場所を推測する必要がなく、プラグイン作成者が各製品ごとにディレクトリを再設計する必要がないことです。Skillsのみをサポートし、MCPをサポートしない互換クライアントでも、スキル部分の読み取りを継続できます。MCPの設定にエラーが発生した場合、仕様ではクライアントがエラーのあるサーバーを可能な限りスキップし、プラグイン全体が完全に機能しなくなることを防ぐよう求められています。
Agentプラグインは、ベンダーが独自の機能を保持することを可能にします。クライアントは逆ドメインを使用して独自の拡張名前空間を構築できます。たとえばcom.example.client。他のクライアントは認識できない独自の設定を無視し、プラグイン全体を拒否すべきではありません。これにより、標準は共通の基盤を提供しつつ、すべての製品に完全に同じ機能を強制することなくなります。
最初の対応製品は主要なプログラミングエージェントをカバーしています
公式互換リストには現在、VS Code、Cursor、GitHub Copilot、ChatGPT、Codex、およびAmazonのKiroが含まれています。Vercelが初期の仕様案を提唱し、その後AWS、Cursorの親会社であるAnysphere、Microsoft、OpenAI、およびVercelが初期の技術指導委員会を設立しました。GitHubも仕様の整備に参加しています。
Googleはリリース当日にコア保守作業への参加を発表し、関連製品でこのフォーマットをサポートし始めました。GoogleはAgents CLIとData Agent KitでAgent Pluginsを採用し、開発者がBigQuery、Spanner、Cloud SQLなどのデータ機能をポータブルなプラグインとして組み合わせられるようにする計画です。
この参加者グループは、モデルや製品の面で同じ陣営に属していないため注目されます。マイクロソフトはVS CodeとGitHub Copilotを所有し、OpenAIと密接な関係を持っています。Cursorは独立したAIプログラミングツールです。AWSはKiroを所有しており、クラウド市場でマイクロソフトやGoogleと競合しています。VercelはAIアプリケーションのデプロイプラットフォームを目指しています。これらが共同でパッケージ化標準を策定しようとしていることは、プラグインの断片化がすでにすべての企業の保守コストを増加させていることを示しています。
仕様はオープンライセンスに基づいており、技術的な議論と意思決定は公開プロジェクトで行われる予定です。これは制度設計上、単一のモデル企業がフォーマットを完全に支配することを避けようとしています。ただし、オープンなガバナンスが実際に効果を発揮するかどうかは、今後のバージョンの意思決定プロセスと、各製品が独自の拡張機能にどれほど依存するかにかかっています。
それは意図的に何も解決していない
エージェントプラグインで最も誤解されやすい点は、「プラグイン」という名称がブラウザ拡張機能やモバイルアプリストアを連想させることです。実際、現在の1.0.0バージョンではパッケージ形式を統一しただけで、完全なプラグイン配布およびセキュリティ体制は構築されていません。
Googleの公式な解説では、第1版ではプラグインをどのプロトコルを通じてインストールするか、どこで検索・ダウンロードするか、また権限の申請、ユーザー確認、実行サンドボックス、発行者身份およびソースの検証について規定されておらず、これらの作業は各Agentクライアントが独自に実行することになっています。
規則では、プラグイン内のファイルパスが../またはシンボリックリンクによってプラグインルートディレクトリから脱出しないよう求めていますが、公式は明確に述べています：このパス制約は、プラグインプロセスをサンドボックス化することを意味しません。stdio経由で起動されたMCPサーバーは依然としてプログラムを実行する可能性があります。どのファイル、環境変数、ネットワーク、ユーザーデータにアクセスできるかは、クライアントの権限システムによって決まります。
リモートMCPエンドポイントは原則としてHTTPSを使用しなければならず、プラグインはパスワードやその他のシークレットを公開されたリクエストヘッダーまたは環境設定に直接記述してはなりません。ただし、1.0.0では汎用OAuth設定や移植可能な資格情報参照メカニズムが提供されておらず、認証発見、ユーザーログイン、資格情報の保存はクライアント側で処理されます。
したがって、フォーマットの統一は悪意のある拡張機能の拡散効率を高める可能性もあります。開発者は「一度パッケージ化すればどこでも実行可能」ですが、攻撃者も理論的には同じことができます。今後、この標準が大規模に採用されるかどうかを決定するのは、ディレクトリ構造ではなく、署名、権限通知、サプライチェーンレビュー、自動更新、および取り消しメカニズムが適時に整備されるかどうかでしょう。
なぜ第一版はSkillsとMCPのみに対応しているのですか？
多くのAgent製品には、コマンド、イベントフック、サブAgentテンプレート、インターフェースコンポーネント、およびカスタムワークフローが含まれています。制作者は、第一版でこれらの内容を強制的に統一するのではなく、すでに一定のクロスプラットフォーム基盤を形成しているSkillsとMCPの2つのコンポーネントのみを選択しました。
これはやや保守的だが現実的な選択である。標準が最初からすべてのAgentの機能を定義しようとすると、膨大になり、特定の製品の現在の設計が業界全体の長期的な規則として固定されてしまう可能性がある。Agent Pluginsは、まず最も明確な問題に取り組む：Agentの操作知識とツールを、一つの持ち運び可能なソフトウェアパッケージに統合する。
Googleはまた、個々のスキルやMCPサーバーのすべてをプラグインとしてパッケージ化する必要はないことを特に注意喚起しています。プラグインは、共同でインストールされ、バージョン管理され、移行される一連の機能に適しています。たとえば、データベース開発用プラグインには、SQLクエリスキル、データベースMCP接続、トラブルシューティングガイド、デプロイスクリプトが同時に含まれる可能性があります。一方、単純な説明ファイルのみの場合、スキルとして直接配布する方が適しているでしょう。
実際に弱体化しているのはプラットフォームのロックかもしれない
標準が十分なクライアントサポートを得れば、開発者はチームがCursorからVS Codeに切り替えたり、Codexから他のエージェントに移行したりしても、すべてのスキルとツールの接続を再構築する必要はありません。個人または企業が長年にわたり蓄積したエージェントの機能は、ユーザーとともに移行でき、基盤となるモデルとクライアントがより簡単に置き換えられるようになります。
これはAgentプラットフォームの競争方式を変えるでしょう。ベンダーは、閉じられたプラグイン形式だけでユーザーを留めるのではなく、モデルの品質、実行の信頼性、権限制御、インターフェース体験、およびプラグイン発見機能において継続的に競争する必要があります。開発者にとって、移植可能なプラグインは、ほぼ同じプロジェクトを各Agentマーケットで繰り返してメンテナンスする必要なく、一度の投資でより多くの潜在ユーザーをカバーできることを意味します。
しかし、真の移植性には依然として境界がある。クライアントは仕様の一部のみを実装する可能性があり、異なる製品の認証メカニズムや実行環境も異なる。プラグインは認識されても、すべてのクライアントで完全に一貫した動作を保証されるわけではない。ベンダー固有の名前空間を大量に使用するプラグインは、形式的な互換性の外観の下で事実上のロックインを再び生み出す可能性がある。
また、MCPは当初Anthropicによって推進されたが、Anthropicは現在、Agent Pluginsが公表した初期のコアメンテナーおよび最初の公式互換クライアントのリストには含まれていない。これはClaudeが今後このフォーマットをサポートしないことを意味するわけではないが、新しいラッピング標準がすべての主要なAgent陣営をカバーしていないことを示している。
ある標準が成功したかどうかは、プラグインが実際に流動するかどうかで決まります。
Agent Pluginsの現在の最大の価値は技術的複雑さではなく、複数の競合ベンダーが同じ問題を認めたことにある：モデルはますます多くのツールを呼び出せるが、各プラットフォームが独自のプラグインラッピング方式を保持すれば、Agentエコシステムは初期のモバイルアプリやブラウザ拡張機能が互いに分断された歴史を繰り返すことになる。
最初の仕様は非常に簡素で、プラグインがどのように見つけ、インストールし、信頼するかという問題さえ解決していません。しかし、この抑制的なアプローチがむしろ強みである可能性もあります。まず、最も基本的で合意形成が容易な層を統一し、SkillsとMCPサーバーに共通の輸送手段を提供した上で、権限、配布、その他のコンポーネントは後続のバージョンに委ねています。
注意してください、公式仕様ページはバージョンが1.0.0と記載されていますが、状態はまだ「Working Draft」であり、今後の詳細が変更される可能性があります。現在のサポートは主に標準策定に参加したメーカーによるものであり、より広範なAgentエコシステムがこれを採用しているとは証明されていません。