Agent Plugins 1.0
スキル資産が、会社をまたいで動く。
OpenAI・Amazon・Cursor・Microsoft・Vercelの5社が、エージェント向け拡張機能の共通パッケージ規格「Agent Plugins」を公開しました。数日のうちにGoogleも技術運営委員会に加わり、参加社は6社に。自作のAgent SkillやMCPサーバーを、ツールを乗り換えるたびに作り直す必要が薄れていきます。
Why Now
「乗り換えるたびに作り直し」が、
これまでの標準だった
Anthropicが提案したAgent Skillの仕様自体は、指示書とコードをひとまとめにする「パッケージ形式」を定義していました。ただし、そのスキルが特定のMCPサーバーに依存している場合、両者を結線するセットアップ手順はクライアントごとに別々かつ多くは未文書化のまま——という穴が残っていました。先月まで、この結線作業はChatGPT向け・Cursor向け・VS Code向けとツールの数だけ書き直すのが実質的なルールだったのです。
この隙間を埋めるため、OpenAI・Amazon・Cursor（開発元Anysphere）・Microsoft・Vercelの5社が2026年8月6日、パッケージ形式の共通規格「Agent Plugins」1.0.0を公開しました。仕様と運用ルールはagentplugins/agent-plugins-specとしてGitHub上で公開・管理されています。技術運営委員会（Technical Steering Committee）にはAmazonのClare Liguori氏、CursorのRoshan Sadanani氏、MicrosoftのHarald Kirschner氏、OpenAIのGav Verma氏、VercelのJonathan Hefner氏がCore Maintainerとして名を連ね、Hefner氏がLead Core Maintainerを務めています。
Anatomy
中身はシンプル。核は
1個の plugin.json
仕様はわざと小さく保たれています。プラグインとは、ルートに置いたマニフェストと、決まった場所に置いたスキル・MCP設定を束ねたディレクトリに過ぎません。
公開されているplugin manifest schema（v1.0.0）によれば、必須フィールドは name（1〜64文字、小文字英数字とハイフン・ドットのみ、連続不可）だけ。version・description・author・homepage・repository・license・keywordsに加えて、クライアント固有のデータを逆ドメイン名前空間で格納できるextensionsフィールドがオプションで用意されています。仕様書自体はCC-BY-4.0、コードはApache 2.0で公開されています。
plugin.jsonを書く
ルート直下にマニフェストを1個。必須はnameのみで、既存のプロジェクトにも足しやすい設計です。
skills/にSKILL.mdを並べる
再利用したい指示書・ワークフローをAgent Skillとして格納します。
必要ならmcp.jsonを足す
そのスキルが外部ツールやデータに繋がる場合、MCPサーバーの接続設定を同梱できます。
By the Numbers
規模で見る、公開直後の
Agent Plugins
Googleは公開から間もなく技術運営委員会にCore Maintainerとして加わり、参加社は6社になりました。初日から対応を表明しているクライアントは、OpenAIのChatGPTとCodex、Cursor、MicrosoftのGitHub CopilotとVS Code、AmazonのKiroの6つ。いずれも各社が自社製品への統合を公式にアナウンス済みです。
Who It's For
3つの視点で見る影響
同じニュースでも、立場によって効くところが違います。
エンジニア
自作のAgent Skillやツール接続設定を、ChatGPT/Codex・Cursor・GitHub Copilot・VS Code・Kiroの間で作り直さずに使い回せる可能性が出てきました。まずはplugin.jsonのスキーマに沿って既存スキルを1つ移行し、複数クライアントで実際に動くか検証するのが近道です。
プロダクト/PM
社内向けに1回作ったエージェント拡張を、複数のAIツールへ横展開しやすくなります。ベンダー選定やツール比較の会議で「乗り換えコスト」を再検討する材料が1つ増えたと捉えるのが実務的です。
経営/事業
特定ベンダーのエージェント基盤に投資しても、スキル資産まで丸ごとロックされにくくなる方向性が示されました。ただし仕様が固まるのはこれからで、乗り換えコストが今日ゼロになったわけではありません。
| Agent Plugins登場前 | Agent Plugins 1.0以降 |
|---|---|
| スキル/MCP接続はクライアントごとに個別設定 | plugin.json 1個で複数クライアントに配布できる形式に |
| 結線手順は非公式・未文書化なことが多い | skills/とmcp.jsonの配置がCC-BY-4.0の公開仕様で定義 |
| 仕様の主導権は各社がばらばらに保持 | TSCはどの1社もCore Maintainer議席の過半数を持てない設計 |
| 対応クライアントは各社バラバラ | ChatGPT・Codex・Cursor・GitHub Copilot・VS Code・Kiroが初日対応 |
スキルを、作り直すものから
配って動かすものへ。
What's Next
「使える」と「使い物になる」の間
直近1年でAgent Skillの人気が急速に広がり、MCPサーバーによる外部ツール接続も一般化しました。それぞれの部品は成熟しつつあったのに、両者を束ねて配布する共通の箱がなかった——今回の規格が埋めたのは、まさにその最後の1ピースです。単発のベンダー発表ではなく、Amazon・Cursor・Microsoft・OpenAI・Vercel・Googleという主要な開発ツールベンダーが揃って同じフォーマットに乗った点が、これまでの個別拡張機能の乱立と一線を画します。
とはいえ楽観一辺倒にはできません。仕様はv1.0.0になったばかりで、実際に同一のplugin.jsonが複数クライアントを跨いで無修正で動く実例はまだ限られます。クライアント固有データを許容するextensionsフィールドに依存した瞬間、ポータビリティの一部は失われます。またGoogleが後から参加した経緯からも分かる通り、初期の5社だけで固まった仕様ではなく、今後も範囲や力点が変わり得ます。Anthropicなど、今回の初日対応リストや運営文書に名前が出ていないベンダーがいつ参加するかも見えていません。
実務的な次の一手は3つ。(1) 既存のスキルやMCP設定を持つチームは、公開スキーマに沿ってplugin.jsonへの移行をまず1件だけ試す。(2) 対応6クライアント以外の対応表明を継続的に確認する。(3) extensionsフィールドに依存していないかを移行前にチェックし、本当に複数クライアントで動くかを検証してから全面移行する——の3点です。