Agent Pluginsが標準化するもの、しないもの——スキルとMCP設定の可搬性

ChatGPT、Cursor、GitHub Copilotなど、複数のAIエージェント製品を併用する企業では、製品ごとに追加したスキルや接続設定を、将来どこまで持ち運べるかが課題になります。

作り込みが増えるほど、「今使っている製品から乗り換えるとしたら、この投資はどうなるのか」という問いは重くなります。

この問いに、業界の共通仕様という形で一部の答えを出そうとする動きが出てきました。

Agent Plugins 1.0.0 が定めるもの

Vercelは2026年8月6日、AIエージェント向けの拡張を共通形式で配布する仕様「Agent Plugins 1.0.0」を公開しました。

Vercelが提案し、AWS・Anysphere（Cursorの開発元）・GitHub・Microsoft・OpenAI・Vercelの代表者が共同で仕様を策定したものです。

技術運営委員会にはAWS・Cursor・Microsoft・OpenAI・Vercelのメンテナーが参加しており、仕様とスキーマは公開されています。

この仕様が対象にしているのは、拡張機能一般ではなく、エージェントスキル（Agent Skills）とMCPサーバーの2つです。

MCPは、AIが外部システムと接続するための共通規格を指します。

構成は次のとおりです。

ルートにplugin.jsonを置いたディレクトリを、ひとつのプラグインとして扱います。

必要に応じて、エージェントスキルを収めるskills/ディレクトリや、MCPサーバーの接続設定を記述するmcp.jsonを追加できます。

plugin.jsonは必須ですが、skills/とmcp.jsonはどちらも任意です。

スキルだけ、MCP設定だけ、あるいは両方を含める、のいずれも可能で、仕様上、決められた場所にファイルが無いことをクライアントがエラーとして扱ってはならないと定められています。

plugin.jsonに必須の項目も、仕様バージョンを示す$schemaとプラグイン名を示すnameの2つだけです。

Vercelの説明によれば、これまでは同じスキルやMCPサーバーを複数の製品で使う場合でも、製品ごとに異なるメタデータ・配置場所・設定形式へ合わせ直す必要があり、その断片化が課題だったとされています。

なお、この仕様が共通化しているのは、単なるディレクトリの並べ方だけではありません。

プラグインの検証、コンポーネントの発見、MCP設定の読み込み、一部のコンポーネントが壊れていた場合の障害分離、仕様バージョンの判定までを含む、クライアント間の最低限の共通契約が定められています。

対応先としては、発表時点でChatGPT・Codex・Cursor・GitHub Copilot・Kiro・VS Codeが挙げられています。

ただし、仕様のステータスは1.0.0の公開時点で「Working Draft」と表示されています。

複数の主要製品がすでに対応しているという事実と、成熟した業界標準として定着したかどうかは、分けて捉えるのが妥当だと考えています。

共通フォーマットだけで可搬性は得られるか

主要プレイヤーの合意のもとで共通仕様が公開されたこと自体は、拡張づくりに投資してきた企業にとって歓迎できる動きです。

ここからは、公開仕様を踏まえたMIFの見解です。

立ち止まって考えたいのは、この仕様が共通化した範囲と、各製品・各企業の側に残る範囲を区別せずに「これで乗り換えが楽になる」と受け取ってしまうことのリスクです。

拡張の可搬性は、少なくとも次の3つの層に分かれます。

①パッケージの可搬性は、どこに何があるかを各クライアントが共通の方法で発見・検証・読み込みできるか、という層です。

Agent Pluginsが主に標準化しているのは、この層になります。

②挙動の可搬性は、同じスキルを読み込ませたときに、異なるモデルやクライアントで同じ工程・同じ出力品質を再現できるか、という層です。

ここはパッケージ仕様だけでは保証されません。

仕様は、スキルを利用者やモデルにどう見せるかを各クライアントの裁量に委ねています。

③運用の可搬性は、認証・権限・秘密情報・インストール・更新・配布・サンドボックス・監査といった、実際に業務で動かすための条件を別の製品へ移せるか、という層です。

この層も、仕様が定める可搬コアの外側にあります。

同じプラグインを読み込めることと、同じ品質・同じ権限・同じ安全性で運用できることは、別の話だという整理です。

可搬性と安全性も、分けて考える

もう一つ分けて考える必要があるのが、可搬性と安全性です。

Agent Pluginsの形式で読み込めることは、そのプラグインを自社環境で実行してよいことを意味しません。

仕様は、インストール元やレジストリ・マーケットプレイス、権限確認の画面、信頼ポリシー、サンドボックス、有効化や更新の扱いを、いずれも各クライアントの設計に委ねると明示しています。

とくにMCP接続では、注意すべき点があります。

mcp.jsonには、ローカルで起動するサーバーやリモートのサーバーの接続方式を記述できますが、認証は共通化されていません。

仕様には、共通で使えるOAuthの設定項目も、認証情報を参照するための項目も定義されておらず、認証はクライアント側の管理に委ねられると明記されています。

加えて、設定に書くヘッダーは package に含まれる可視データであるため、そこに認証情報や秘密情報を含めてはならない、という制約もあります。

つまり、製品を乗り換える際には、接続先の設定だけでなく、認証・権限・監査の仕組みを別途移行対象として洗い出す必要があります。

「製品固有を避ける」ではなく「混ぜない」

ここで一つ、よくある結論の飛躍を避けておきたいと考えています。

「乗り換えやすさのために、製品固有の作り込みは避けるべきだ」という結論には、私たちは与しません。

特定製品の独自機能によって実務上の価値が高まる場面は現実にありますし、それを一律に手放すのは合理的ではありません。

Agent Pluginsの仕様自体も、製品固有機能を否定していません。

逆ドメイン形式の名前空間を使って、特定クライアント向けのデータやファイルをplugin.jsonのextensionsや専用ディレクトリに置く仕組みが用意されており、自分が実装していない名前空間を、クライアントは中身を検証せずに無視すると定められています。

仕様が示しているのは「製品固有の最適化をするな」ではなく、**「共通化できる部分と製品固有の部分を混ぜるな」**という設計だと理解しています。

自社の業務ルール・判断基準・参照してよい情報の範囲・共通のMCP接続といった可搬コアと、特定製品の画面操作・フック・独自機能に依存する部分を、分けて管理する。

この線引きこそが、仕様の登場によって引きやすくなった部分だと考えています。

拡張の棚卸しから始める

読み終えて「では自社は何をすればいいか」となったとき、まず取りかかりやすいのは、いま作り込んでいるスキルや接続設定の棚卸しです。

以下は、その棚卸しを始めるための一例です。

自社の状況やリスクの置き方に合わせて、項目も判断基準も置き換えて使ってください。

対象	共通形式で持ち運べる部分	製品・運用側に残る部分	次に確認すること
（例）問い合わせ下書きスキル	スキル本文、テンプレート、参照資料	起動方法、モデル固有の出力傾向、製品固有のツール名	複数のクライアントで同じ評価項目を使って試す
（例）社内ナレッジ検索のMCP接続	サーバーのURL、通信方式、非機密の設定	OAuth、認証情報、アクセス権限、利用者の承認	認証・権限設定を別製品でも再構成できるか
（例）ローカルのMCPサーバー	実行コマンド、引数、プラグイン内のファイル	サンドボックス、実行許可、OS・ランタイム依存	実行環境と権限をクライアントごとに確認する
（例）コマンド・フック	1.0.0の可搬コアには含まれない	製品固有の名前空間・形式	代替手段で足りるか、個別移植が必要か
（例）配布・更新	仕様では共通化されない	マーケットプレイス、更新の承認、バージョン管理	誰が配布と更新を承認するか

表の列も粒度も、あくまで叩き台です。

大事なのは「共通形式に沿っていれば安心」と早合点せず、何がそのまま移り、何を再設定することになるのかを具体的に把握しておくことだと考えています。

まとめ

Agent Plugins 1.0.0は、エージェントスキルとMCPサーバーをひとつのプラグインとしてまとめ、対応するクライアントが共通の方法で発見・検証・読み込みできるようにする仕様です。

これによって、製品ごとに異なっていたパッケージ構造や配置、MCP設定を合わせ直す負担は、小さくなる可能性があります。

ただし、共通化されるのは拡張のすべてではありません。

インストール、認証、権限、サンドボックス、更新、利用者への見せ方、製品固有機能は、引き続き各クライアントと導入企業の設計に残ります。

同じプラグインを読み込めることと、同じ品質・権限・安全性で運用できることは別です。

重要なのは、製品固有の最適化をすべて避けることではありません。

自社の業務ルール・判断基準・参照資料・共通のMCP接続といった可搬コアを、製品固有のフックやコマンド、認証、画面操作から分けて管理することです。

今回の仕様公開は、乗り換えが自動的に容易になったことを意味するものではありません。

自社が積み上げてきた拡張のうち、何が共通形式で持ち運べ、何が製品や運用環境に残るのかを棚卸しするための、具体的な基準がひとつ増えた——そう捉えるのが適切だと考えています。

情報確認について

本記事は2026年8月時点で、Vercelの発表「Introducing Agent Plugins」および Agent Plugins の公式仕様サイト（仕様本体・プラグイン作者向けガイド・クライアント実装者向けガイド・MCPサーバー設定・クライアント拡張の各ページ）を主要な参照元として作成しています。

仕様のステータスは確認時点で Working Draft と表示されており、対応クライアントの範囲や仕様の内容は今後更新される可能性があります。

導入を検討する際は、利用するコンポーネントと各クライアントの対応範囲を、最新の公式情報でご確認ください。