Amazon、Cursor、MicrosoftにOpenAIとVercelを加えた中核メンテナーが、AIエージェントの拡張機能を持ち運ぶためのオープン標準「Agent Plugins」を共同で管理する。公開済みの仕様1.0.0は、既存のAgent SkillsとModel Context Protocol（MCP）サーバーを一つのディレクトリに収め、対応製品が同じ規則で発見、検証できるようにした。各社の製品ごとに同じ部品を並べ替え、設定を書き直してきた作者の負担を減らす狙いだ。ただし、そろえたのはプラグインの「荷姿」であり、インストール後の権限や実行環境まで統一したわけではない。
plugin.jsonがそろえる最小単位
Agent Pluginsの最小構成は、ルートにplugin.jsonを置いたディレクトリである。マニフェストには、仕様の版を指定する$schemaとプラグイン名が必須になる。機能本体は任意で追加でき、1.0.0が可搬コンポーネントとして定めたのはAgent SkillsとMCPサーバーの2種類だ。
my-plugin/
├── plugin.json
├── skills/
│ └── summarize/
│ ├── SKILL.md
│ ├── scripts/
│ └── references/
└── mcp.jsonskills/の直下には、手順や専門知識を記したSKILL.mdを含むフォルダを置く。Agent Pluginsはスキルの中身を再定義せず、Agent Skills仕様に従うファイルをどこで見つけるかだけを決める。MCPについても通信方式そのものはMCP仕様に委ね、mcp.jsonでローカルプロセスを起動するstdio、リモート接続用のStreamable HTTP、旧式のHTTP+SSEを記述できるようにした。
この分業が今回の変化をよく表している。Agent Skillsはエージェントに仕事の手順を渡し、MCPサーバーは外部のツールやデータへ接続する。Agent Pluginsは両者を同じ箱に収め、対応クライアントが読み込むまでの約束を加えた。作者はスキルのフォルダやMCP設定を製品ごとの独自配置へ移す作業を減らせる。
仕様は読み込み失敗の扱いもそろえた。無効なスキルが一つあれば、そのスキルを飛ばして兄弟のスキルを読み込む。MCPサーバーの一つが起動や認証に失敗しても、ほかのサーバーやスキルは止めない。プラグイン全体を一括で成功か失敗かに分けず、壊れた範囲を狭く閉じ込める設計である。
5つの対応先でも、読める部品は同じではない
公式の対応一覧には、Visual Studio Code、Cursor、GitHub Copilot、ChatGPT & Codex、AmazonのKiroが並ぶ。5つともAgent Skillsを読み込める。MCPでは、ChatGPT & CodexがstdioとStreamable HTTPに対応し、残る4つはこの2方式に旧式のSSEを加えている。
| 対応クライアント | Agent Skills | MCPトランスポート |
|---|---|---|
| Visual Studio Code | 対応 | stdio、Streamable HTTP、旧式SSE |
| Cursor | 対応 | stdio、Streamable HTTP、旧式SSE |
| GitHub Copilot | 対応 | stdio、Streamable HTTP、旧式SSE |
| ChatGPT & Codex | 対応 | stdio、Streamable HTTP |
| Kiro | 対応 | stdio、Streamable HTTP、旧式SSE |
差が残るのは、仕様が段階的な採用を認めているためだ。適合クライアントはAgent SkillsかMCPサーバーの少なくとも一方を実装すればよく、MCP対応でもstdioかStreamable HTTPの一方を扱えれば要件を満たす。したがって、一つのパッケージを5製品へ配れても、含めた部品がすべて同じように動くとは限らない。作者は利用先の対応表を確認し、使えない部品を含んだときの挙動まで試す必要がある。
各社固有の機能を同梱する逃げ道も用意された。com.example.clientのような逆ドメイン名を使えば、クライアント専用の設定やhooksをプラグインに加えられる。ほかのクライアントは未対応の名前空間を無視できるため、共通部分を壊さず独自機能を拡張できる。一方、そのディレクトリは可搬コンポーネントではない。commandsやhooks、agentsは1.0.0の共通範囲から外れ、rulesとLSPサーバーも各製品の実装に残る。
権限と配布は標準の外に残る
Agent Plugins 1.0.0は、配布元やマーケットプレイスを定めていない。インストールと更新、ユーザーへの見せ方は各クライアントが管理する。権限確認や信頼ポリシー、サンドボックスも共通化していない。共通のplugin.jsonがあっても、ある製品で許可した操作が別の製品でも許可されるわけではない。
セキュリティ面で仕様が定めるのは、主にパッケージの境界である。クライアントが読み込み、実行するファイルは、シンボリックリンクなどを解決した後もプラグインのルート内に残らなければならない。MCPの作業ディレクトリや実行ファイルが外へ抜ければ、そのサーバー項目を無効にする。ただし、この検査は起動したMCPプロセスを隔離せず、実行中にアクセスできるパスも制限しない。
認証も持ち運べない。1.0.0にはOAuthや資格情報への参照を共通化するフィールドがなく、リモートMCPの認証はクライアント側が引き受ける。設定ファイルのHTTPヘッダーや環境変数はパッケージから読めるため、仕様はそこへ秘密情報を埋め込まないよう求めている。企業が導入を判断するときは、形式への適合とは別に、配布元の確認、実行コードの審査、権限の付与方法を製品ごとに調べなければならない。
Anthropic抜きで始まった共同管理
初期Technical Steering Committee（TSC）は5人で構成される。AmazonのClare Liguori、CursorのRoshan Sadanani、MicrosoftのHarald Kirschnerが名を連ねる。OpenAIからはGav Verma、VercelからはJonathan Hefnerが参加し、HefnerがLead Core Maintainerを務める。役職は企業ではなく個人が持ち、単一ベンダーがCore Maintainerの過半数を占められない。提案や技術判断は公開し、参加は広く受け入れるという。
Agent Pluginsが包む二つの仕様は、どちらもAnthropicから始まった。MCPは同社が2024年11月に公開し、2025年12月にはLinux Foundation傘下のAgentic AI Foundationへ寄贈した。Agent SkillsもAnthropicが開発し、2025年12月にオープン標準へ移した。しかし、2026年8月8日時点のAgent Plugins初期TSC名簿にAnthropicの名前はない。公式資料はその理由を説明していない。
共同標準が実際の移植コストを下げるかどうかは、5つの対応クライアントが同じサンプルパッケージをどこまで同じ結果で読み込めるかで測れる。さらに権限確認や認証の差が作者側の個別対応を残すなら、共通化の効果は配布前で止まる。次の版で可搬コンポーネントが増えるのか、まず1.0.0の適合試験とクライアント別の実装表が更新されるかが、標準の実効性を決める。
