社内の開発チーム向けにAIエージェントの環境を整えたとします。社内のAPIを叩くMCPサーバーを立て、コーディング規約やレビュー観点をエージェントに読ませる手順書を書き、導入マニュアルを作って全員に配る。ここまでで数週間から数か月かかります。
そして半年後、標準ツールを別のものに切り替える話が出ます。ライセンス費用の見直しかもしれませんし、精度の評価が変わったのかもしれません。そこで担当者が言うことになります。「あれはCursor用に作ったものなので、Copilotに移るなら作り直しです」。
この一言があるせいで、多くの会社がツールの見直し自体を先送りしています。乗り換えコストが読めない選択肢は、検討のテーブルにすら乗らないからです。
作り直していたのは中身ではなく「入れ方」
冷静に分解すると、作り直しになっていたものの大半は、エージェントに渡す知識やツールの中身ではありません。社内APIを叩く実装も、規約を書いた文書も、そのまま流用できる形をしています。
作り直しが発生していたのは、それらをどうやってクライアントに認識させるかの部分です。設定ファイルの置き場所も、名前も、記法も、必要な手順もクライアントごとに違いました。同じ内容を6通りの入れ方で書き直し、6通りの導入手順書をメンテナンスする。これが「移行コスト」の正体です。
つまり、標準化されるべきだったのは知識やツールの中身ではなく、その梱包の仕方でした。
8月6日に決まったこと
2026年8月6日、OpenAI・Microsoft・Amazon・Cursor（Anysphere）・Vercelが共同で Agent Plugins 1.0.0 を公開しました。Agent SkillsとMCPサーバーを配布可能なプラグインとしてパッケージ化するための、ベンダー中立な仕様です。
提案を始めたのはVercelで、そこにAWS・Anysphere・GitHub・Microsoft・OpenAI・Vercelの担当者が加わって仕様が固められました。技術運営委員会（TSC）のコアメンテナはAWS・Cursor・Microsoft・OpenAI・Vercelから出ています。Googleも中心的なメンテナンスへの参加を表明し、Agents CLIとData Agent Kitで対応を進めると発表しています。
公開時点で対応しているクライアントは、ChatGPT、Codex、Cursor、GitHub Copilot、Kiro、VS Codeです。一度作ったプラグインが、クライアントごとの導入手順を書き直すことなく、この6つに入ります。
仕様はオープンライセンスで公開され、メンテナ・貢献プロセス・技術的な意思決定も公開されています。特定企業の製品ロードマップが仕様の方向を決める構造になっていない、という点が明示されています。
MCPを置き換えるものではない
ここは誤解されやすいので明確にしておきます。Agent PluginsはMCPと競合する第三のフォーマットではありません。Agent SkillsとMCPサーバーの上に乗る梱包の層です。
MCPが「エージェントが外部のツールやデータにどう接続するか」を定めるのに対し、Agent Pluginsは「そのMCPサーバーとスキルの束を、どう配って、どうインストールさせるか」を定めます。層が違うので、片方がもう片方を不要にすることはありません。
MCPそのものの仕組みを把握していない場合は先にMCP完全ガイドを、標準としての立ち位置についてはMCPがLinux Foundationへ移管された意味を確認してください。この2つを踏まえると、今回加わったのが上流の1層だけであることが見えやすくなります。
発注・内製の判断で変わること
社内AI基盤を発注する側、あるいは内製する側から見ると、変わるのは主に次の2点です。
1つめは、ツール選定の可逆性が上がったことです。これまで「どのAIクライアントを社内標準にするか」は、一度決めたら数年動かせない判断でした。周辺の作り込みが全部そこに紐づくためです。梱包が共通化されると、乗り換えのコストが「作り直し」から「配布先を増やす」に近づきます。判断を早く下せるようになり、間違えたときの傷も浅くなります。
2つめは、見積もりの読み方が変わることです。AIエージェント関連の開発を外部に発注するとき、これまでは「どのクライアント向けか」を仕様に書く必要がありました。今後は「Agent Plugins形式でパッケージ化して納品すること」と書けば、対応クライアントの範囲を成果物の条件として指定できます。特定クライアント専用の実装で納品されて、乗り換え時に再発注になる、という事態を契約段階で防げます。
社内向けにMCPサーバーを立てる部分の設計は社内専用MCPサーバーの実装ガイドにまとめています。今回の変更は、そこで作ったものの配り方に関わる話だと捉えてください。
共通化されていないものを数え違えない
一方で、これで社内展開が楽になったと読むのは早計です。標準化されたのは梱包であって、権限とデータの扱いは何も共通化されていません。
プラグインが「どのクライアントにも入る」ということは、裏返せば入れてはいけない場所にも入りやすくなったということです。社内APIへの接続情報を含んだプラグインが、個人のアカウントで使っているクライアントに入る経路ができます。配布が簡単になるほど、配布先の統制が効いているかどうかが効いてきます。
導入前に押さえるべきなのは、少なくとも次の3点です。
- 誰がプラグインを社内に持ち込めるかを決める。 配布が容易になった以上、野良プラグインの持ち込みは前提として扱う必要があります
- 資格情報をプラグインに同梱しない構造にする。 エージェント側に鍵を持たせない設計は、標準が変わっても要件として残ります
- どのクライアントを許可するかを明示する。 「対応クライアントが6つある」ことと「6つとも社内で許可する」ことは別の判断です
エージェントに対する権限付与を組織として管理する枠組みはMCPのエンタープライズ管理認可で扱っています。梱包が標準化された今、実質的な論点はこちら側に移ったと考えたほうが実態に合います。
次にやること
すでに社内でAIエージェント向けの作り込みをしているなら、まずその資産がどのクライアントに紐づいているかを1枚に書き出してください。MCPサーバー、規約文書、導入手順書がそれぞれどこ専用になっているかが見えれば、Agent Plugins形式にまとめ直したときに何が浮くかが判断できます。
これから発注する予定があるなら、要件に納品形式を書き足すだけでも効果があります。仕様が公開されている以上、これは受注側にとっても追加の負担が小さい条件です。
社内AI基盤の設計や、既存の作り込みの棚卸しを含めて相談したい場合は、グリームハブの開発・AI・自動化のご相談で承っています。既存環境や利用しているクライアントによって現実的な進め方は変わるため、個別にご相談ください。お問い合わせからどうぞ。
Sources
- Introducing Agent Plugins — Vercel
- AWS Supports Agent Plugins: An Open Standard for Portable Agent Extensions — AWS Open Source Blog
- Vercel、OpenAI、GitHub、Microsoft、AWS、Anysphereらが参加、AIエージェントのプラグイン共通規格「Agent Plugins」発表 — gihyo.jp
- OpenAI, Microsoft, and Cursor Unite Behind Agent Plugins to End Fragmented AI Workflows — AlphaSignal
- OpenAI and four rivals just agreed on one standard for AI agents — The Next Web
