Agent Plugins にGoogleが合流。必須項目2つだけでSkillsとMCPを同梱

Agent Plugins は、Agent SkillsとMCPサーバを1つの持ち運べるディレクトリにまとめる、ベンダー中立のパッケージ仕様です。2026年8月6日にGoogleがCore Maintainerとして参加しました。

📖 この記事で分かること

• Agent Plugins 1.0.0 にGoogleが加わった経緯
• プラグインの実体はただのディレクトリという設計
• 必須フィールドを2つに絞った極小スキーマの狙い
• 読み込み失敗を2段階に分けた実務上の意味

💡 知っておきたい用語

• Agent Plugins:エージェントの拡張機能を、どのツールでも開けるよう「共通の箱」に詰める決まりごと。電源プラグの形状を各国で統一するのに近い

最終更新日: 2026年8月7日

▶ 公式ページ

• Agent Plugins 仕様(agent-plugins.org)
• Agent Plugins package your skills, tools, and more(Google Developers Blog)

Agent Plugins 1.0.0 にGoogleが加わった

この記事のポイント

• Googleが2026年8月6日、Agent Plugins 1.0.0(2026年8月時点)のCore Maintainerに6社目として参加しました。
• Agent SkillsとMCPサーバを1つのディレクトリに同梱する、ベンダー中立の仕様です。
• Google側はAgents CLIとData Agent Kitで対応済み。開発者は今日から配布形式を揃えられます。

Googleは2026年8月6日、エージェント拡張のパッケージ仕様「Agent Plugins」のCore Maintainerに参加したと発表しました。技術運営委員会(TSC)のCore Maintainerは、当初 Amazon・Cursor・Microsoft・OpenAI・Vercel の5社で構成されており、Googleは6社目にあたります。代表者は Google DeepMind の Kevin Hou 氏(Senior Staff Engineer)です。

この仕様が解こうとしている課題は明快です。エージェント向けのスキルやツールを配りたい開発者は、これまでクライアントやIDEごとに別々のラッパーと設定ファイルを維持する必要がありました。Agent Plugins は、Agent Skills と MCP【エムシーピー】サーバを1つの持ち運べる単位にまとめ、対応クライアントであればどれでも同じ形で読み込めるようにします。

Google側はすでに2つの製品で対応を済ませています。ひとつはエージェントの構築・評価・デプロイ用のスキルをパッケージ化する Agents CLI【シーエルアイ】、もうひとつは BigQuery・Spanner・Cloud SQL などに接続するプラグインを提供する Data Agent Kit です。

プラグインの実体は「ディレクトリ」

Agent Plugins の中身を見て最初に目を引くのは、仕様がほとんど何も要求していないことです。プラグインの実体は、決まった構造を持つただのディレクトリでした。

• plugin.json:必須。ルート直下に置く
• skills/:任意。直下の子ディレクトリのうち SKILL.md を含むものが1スキル
• mcp.json:任意。ルート直下に置く
• 逆ドメイン名のディレクトリ(例 com.example.client/):任意。クライアント固有の拡張用

skills/ の探索は直下1階層だけで、再帰探索をしません。深い階層に置いたスキルは見つからない代わりに、読み込み側の挙動が完全に予測可能になります。

マニフェストである plugin.json はクローズドスキーマとして定義され、最上位に置けるフィールドは $schema / name / version / description / author / homepage / repository / license / keywords / extensions の10個に限られます。このうち必須は2つだけです。

• $schema:値は https://agent-plugins.org/schemas/1.0.0/plugin.schema.json でなければならない
• name:1〜64文字。小文字英数字・ハイフン・ピリオドのみで、先頭と末尾のハイフンとピリオド、連続する -- や .. は不可

version はセマンティックバージョニング、license は SPDX 識別子が推奨されますが、いずれも任意です。author は name / email / url の文字列のみを持つオブジェクトと決められています。

MCPサーバを同梱する場合は mcp.json に $schema と mcpServers を書きます。対応トランスポートは stdio、streamable-http、そしてレガシー扱いで任意対応の sse の3種類です。stdio では command に bare name か ./ で始まるプラグイン相対パスを指定し、args / env / cwd を任意で添えます。streamable-http は絶対HTTP/HTTPS URLの url が必須です。

実行時の約束事とパスの封じ込め

クライアントがプラグインのサブプロセスを起動するとき、PLUGIN_ROOT(プラグインディレクトリの絶対パス)と PLUGIN_DATA(クライアントが管理する永続データ領域の絶対パス)の2つを渡すことが義務づけられています。プラグイン作者は自分がどこに展開されるかを知らないまま書けます。

置換の範囲は狭く切ってあります。${PLUGIN_ROOT} と ${PLUGIN_DATA} の展開が効くのは args 配列・env の値・cwd 文字列のみで、しかも1回だけ・非再帰的に置き換えられます。command、ヘッダ、URLには適用されません。展開結果がさらに展開される連鎖を断ち切る設計です。

パスの扱いにも制限があります。プラグイン相対パスは ./ で始まり、解決後もプラグインルート内に収まらなければなりません。ルート外に出るパスは、クライアント側が拒否しなければならないと明記されています。

壊れ方まで仕様に書いてある

実務的にいちばん効くのは、読み込みに失敗したときの扱いが2段階に分かれている点です。

致命的(プラグイン全体を拒否)に分類されるのは、plugin.json の形式やスキーマの不正、必須フィールドの欠落・不正、name の制約違反です。ただし未知の最上位フィールドと、オブジェクトでない extensions は例外として扱われます。将来フィールドが増えても古いクライアントが即死しない逃げ道です。

非致命的(その部品だけスキップして読み込みを続ける)は、skills/ や mcp.json が存在しない、スキルが Agent Skills 仕様に適合しない、MCPサーバの項目が不正、未対応トランスポート、接続や起動の失敗です。plugin.json と mcp.json の $schema のバージョンが食い違った場合も、無効になるのはMCP部分だけでプラグイン全体は生き残ります。

クライアント側の最小要件も低く設定されています。ディレクトリパスから読み込めること、スキルかMCPの少なくとも一方に対応すること、MCPに対応するなら stdio か streamable-http のどちらかに対応すること、クローズドスキーマを検証すること、未知の extensions 名前空間は無視すること。この5点を満たせば準拠クライアントを名乗れます。

編集部の見方

編集部は、この仕様の価値は参加企業の顔ぶれよりも「小さく作った」という設計判断にあると見ます。

• 根拠1:必須フィールドが $schema と name の2つしかありません(2026年8月時点)。標準化の失敗はたいてい盛り込みすぎで起きるため、実装側が「対応しない理由」を持ちにくい水準まで削られている点が効きます。
• 根拠2:skills/ を再帰探索しない、置換は1回だけ・非再帰、パスはルート内に封じ込める。いずれも挙動が一意に決まる方向に倒してあり、クライアント間で解釈が割れる余地を減らしています。
• 根拠3:失敗を致命的と非致命的に切り分け、未知フィールドと extensions を例外にしてあります。仕様が育ってもエコシステムが分断されにくい構造です。

配布側の観点では、Amazon・Cursor・Microsoft・OpenAI・Vercel に Google が加わったことで、主要なエージェントクライアントの提供元がほぼ揃いました。スキルやMCPサーバを配っている開発者は、クライアントごとのラッパーを増やす前に、この形式に寄せる価値を検討する段階に来ています。

この見方が変わる条件:準拠を名乗るクライアントが extensions 名前空間に独自機能を積み増し、実質的に「あのクライアント専用プラグイン」が主流になった場合です。そうなれば可搬性という前提が崩れ、共通形式は名目だけのものになります。

よくある質問

Q: 既存の MCP サーバや Agent Skills は作り直しが必要ですか?

A: 中身の作り直しは不要です。Agent Plugins は既存の Agent Skills と MCP サーバを包む配布形式で、スキル自体は別仕様である Agent Skills 仕様に準拠したままです。plugin.json を用意し、スキルを skills/ 直下に、MCPサーバの定義を mcp.json に配置する形になります。

Q: プラグインに必ずスキルとMCPの両方を入れる必要がありますか?

A: いいえ。skills/ も mcp.json も任意です。どちらも存在しない場合は非致命的として扱われ、プラグインの読み込み自体は継続します。クライアント側も、スキルとMCPの少なくとも一方に対応していれば準拠と認められます。

Q: いま対応しているクライアントはどれですか?

A: Google 側では Agents CLI と Data Agent Kit が発表時点で対応済みです(2026年8月時点)。Core Maintainer は Amazon・Cursor・Microsoft・OpenAI・Vercel・Google の6社ですが、各社製品の個別の対応状況は仕様の公開ページと各社の告知を確認してください。

まとめ

Googleが2026年8月6日、Agent Plugins 1.0.0 の Core Maintainer に6社目として参加しました。仕様はプラグインを「決まった構造のディレクトリ」と定義し、plugin.json の必須フィールドを $schema と name の2つに絞っています。skills/ の非再帰探索、${PLUGIN_ROOT} の1回限りの置換、ルート外パスの拒否といった制約で挙動を一意に固め、読み込み失敗も致命的と非致命的に切り分けました。エージェント拡張の配布が、クライアントごとの個別対応から共通パッケージへ移りつつあります。

MCPの拡張についてさらに詳しく知りたい方は、以下の記事も参考にしてください:

【用語解説】

• Agent Skills: エージェントに特定の作業手順を教える単位。SKILL.md を含むディレクトリとして表現され、Agent Plugins とは別の仕様で定義されている
• MCP【エムシーピー】サーバ: エージェントに外部ツールやデータへの接続口を提供するサーバ。Model Context Protocol の略で、stdio や HTTP 経由で接続する
• クローズドスキーマ: 定義されたフィールド以外を許可しないスキーマ。書き間違いや独自拡張の混入を検証段階で弾ける

引用元:

• [1] Agent Plugins package your skills, tools, and more(Google Developers Blog)
• [2] Agent Plugins Specification(agent-plugins.org)

この記事について: AI 支援で執筆、編集部が事実確認・編集しています。誤りや追加情報があれば Contact よりお知らせください。