この記事は、Google が Agent Plugins に Core Maintainer として参加し、自社製品にそのサポートを組み込み始めることを告知するものである。記事は Agent Plugins 1.0.0 を、Agent Skills と Model Context Protocol サーバーをポータブルなプラグインにパッケージ化するための、オープンでベンダー中立な仕様だと説明している。この仕様を公開したのは、Amazon、Cursor、Microsoft、OpenAI、Vercel のコアメンテナーから成る技術運営委員会である。
記事の議論の軸は、ポータビリティがどこで崩れるかという点にある。記事によれば、スキルとそれに付随する MCP サーバーはそれぞれ単体ではポータブルだが、それらを包むラッパーはポータブルではない。クライアントごとに求められるディレクトリ構成、マニフェストのメタデータ、MCP 設定の形が異なるため、2 つ目のクライアント向けに出荷しようとする作者は、パッケージをフォークし、次第に食い違っていく複数のコピーを保守する羽目になる。記事の診断は「中核の問題はコンポーネントではない。マニフェストだ」というものである。
要点
- プラグインは 1 つのディレクトリである。その中身は、実質的な内容がスキーマ参照と名前だけの
plugin.jsonマニフェスト、Agent Skills 形式でskills/の下に置かれるスキル、そしてすべてのエントリーに明示的なトランスポート種別を記したmcp.jsonで宣言される MCP サーバーである。 - マニフェストでは、コンポーネントの配置場所を変えることも、コンポーネントをインラインで宣言することもできない。そのため、設定すべき探索パスも、覚えるべき優先順位も存在しない。
- コンポーネントはそれぞれ独立して失敗する。クライアントは存在するものをすべて読み込み、起動に失敗した MCP サーバーはスキップされて報告されるが、それによってプラグインのスキルまで使えなくなることはない。
- 逆ドメイン形式のディレクトリ（たとえば
com.example.client/）は、1 つのクライアントが所有する名前空間であり、フック、エージェント、コマンドなど、そのクライアントが追加したいものなら何でも置ける。他のクライアントはこれを無視する。記事は、これがポータブルな中核を小さく保つ仕組みだと位置づけている。 - すべてをプラグインにすべきではない。単一のクライアント向けの単一の MCP サーバーや、単一のスキルにはプラグインは不要である。このフォーマットは、ひとまとまりで一緒に持ち運ばれるコンポーネントのためのものである。
- バージョン 1 はパッケージフォーマットであり、それ以上のものではない。インストールの仕組み、配布プロトコル、パーミッションモデル、サンドボックス化、信頼や来歴の検証、ユーザー体験のいずれも定義していない。記事はこれを正しい判断だとしている。こうした責務は IDE、CLI、マネージドなエンタープライズプラットフォームの間で異なるためであり、プロジェクトがそれらを将来の検討事項として明示していることにも触れている。
- 記事は 4 つのレイヤーを区別している。見つける（Agentic Resource Discovery）、記述する（AI Catalog）、パッケージ化する（Agent Plugins）、実行する（MCP と Agent Skills）であり、各レイヤーは他のレイヤーとは独立して採用できるとしている。
- 公開当日にこのフォーマットをサポートする Google の製品として Agents CLI と Data Agent Kit の 2 つが挙げられており、今後さらに増える見込みだとされている。
背景
これは、Google が参加したばかりの仕様について、同社のエンジニアとプロダクトマネージャーが書いた Google 自身の説明である。そのため、実際の普及状況を測定して報告するものではなく、フォーマットの設計と、Google がそれを支持する理由を説明している。記事は、パッケージングは各クライアントがそれぞれ作り直すのではなく共有されるべき「地味なインフラ」だという立場で締めくくられている。