この記事のポイント
Agent Plugins 1.0.0はplugin.jsonを必須、Skillsとmcp.jsonを任意とする最小構成で6社共同策定された配布フォーマット
MAINTAINERS.md正本ではAmazon・Cursor・Microsoft・OpenAI・Vercelの5名。Googleは8月6日にCore Maintainer参加を表明したが正本反映は未確認
Copilotは2026年8月12日にVS Code・CLI・app・SDKでGA、Awesome Copilot marketplaceがデフォルトで利用可能となり企業導入の入口が整った
v1.0.0はpermission・sandbox・可搬なsecrets参照・公式registryが未定義で、企業採用時はクライアント側の統制で補完する前提が要る
Anthropicの正式対応は未確認。Claude Code採用企業は公式対応表明のタイミングを企業採用時期の判断軸として意識する必要がある

Microsoft MVP・AIパートナー。LinkX Japan株式会社 代表取締役。東京工業大学大学院にて自然言語処理・金融工学を研究。NHK放送技術研究所でAI・ブロックチェーンの研究開発に従事し、国際学会・ジャーナルでの発表多数。経営情報学会 優秀賞受賞。シンガポールでWeb3企業を創業後、現在は企業向けAI導入・DX推進を支援。
Agent Plugins 1.0.0は、Vercel発起・6社共同で2026年8月6日に公開された、AIエージェント用のAgent SkillsとMCPサーバー設定を同一フォルダで配布するベンダー中立オープン標準です。
ChatGPT・Codex・Cursor・GitHub Copilot・Kiro・VS Codeがローンチ対応し、GitHub Copilotは同月12日にVS Code・Copilot CLI・Copilot appでGAしました。対応クライアントが同じ構成でSkills・MCP設定を読み込めるようにする節目のリリースです。
本記事では、仕様の中身と対応クライアント、TSC構成とAnthropic不在の意味、v1.0.0で意図的に含まれなかった要素、MCP・Agent Skills・GitHub Copilot pluginとの位置関係、企業採用の判断軸を解説します。
目次
Agent Plugins 1.0.0とは?6社共同のAIエージェント用パッケージング標準
Agent Pluginsの構成——plugin.jsonを必須とする3要素
Agent Pluginsの対応クライアントとインストール方法
Agent Pluginsのガバナンス構造とAnthropic不在の意味
Agent Plugins 1.0.0で意図的に含まれなかった要素
Agent PluginsとMCP・Agent Skills・GitHub Copilot pluginの位置関係
企業がAgent Pluginsの採用を検討するときの判断軸
Agent Plugins 1.0.0とは?6社共同のAIエージェント用パッケージング標準

Agent Plugins 1.0.0は、Amazon・Anysphere(Cursor)・GitHub・Microsoft・OpenAI・Vercelが共同で策定し、2026年8月6日にVercelが公開した、AIエージェントの拡張機能を配布するためのベンダー中立オープン標準です。
Agent Skills(再利用可能な指示・スクリプト・参考資料のパッケージ)とMCPサーバー設定を1つのフォルダにまとめ、各クライアントが対応するコンポーネントを同じ構成で読み込めるようにする、というのが唯一の目的です。
これまで各社が独自形式でSkillsやMCP設定を管理していた分断状態に対して、6社共同で配布フォーマットのベンダー中立化を打ち出した点が業界的な意味合いになります。
Skills・MCPを束ねるパッケージング層の位置

AIエージェント周辺では、2024年から2026年にかけて役割の異なる複数の仕様が短期間で確立されました。Agent Plugins 1.0.0がどの層に位置するかを、既存の関連仕様と並べて整理します。

GoogleがAgent Plugins対応表明時に公開した「1つのpluginがIDE・CLI・Enterpriseに配布される」概念図(出典:Google Developers Blog)
概念図の左側にあるパッケージフォルダは、Agent Pluginsが担う「配布単位」に相当し、右側のIDE・CLI・EnterpriseはCopilot・Cursor・ChatGPT等のクライアント群を抽象化した表現です。
整理すると、MCPは実行時の通信、Agent Skillsは能力単位のパッケージ、Agent Pluginsは配布単位のパッケージという3層構造で棲み分けています。MCPとAgent Skillsそれぞれの仕様更新の経緯や、GitHub Copilot pluginを含む位置関係の詳細は、後段の「Agent PluginsとMCP・Agent Skills・GitHub Copilot pluginの位置関係」セクションで扱います。
Agent Pluginsが生まれた背景と目的

Agent Plugins 1.0.0が短期間で6社共同標準として合意された背景には、直前2〜3年で走ってきた2つの仕様(Agent SkillsとMCP)が別々に進み、各クライアント側で個別統合コストが積み上がっていた事情があります。
本セクションでは、Skills側の分断状況、MCP側の仕様更新、Vercel起案から公開までの経緯を整理します。
Skills形式は各社実装で分断していた
Agent Skillsの中核であるSKILL.mdフォーマットは、Anthropicが2025年12月18日にオープン標準として公開しました。その後短期間でOpenAI・Microsoft・JetBrains・Cursor・Google Gemini CLI・Block Goose等の複数クライアントで対応が進みましたが、各クライアントは独自のディレクトリ配置を並列で持ち込んでいました。

以下の表で、代表的なクライアントのSkills配置場所を整理しました。
| クライアント | Skills配置場所 |
|---|---|
| Claude Code | ~/.claude/skills/{name}/SKILL.md |
| GitHub Copilot | .github/skills/、.agents/skills/、.claude/skills/ |
| Cursor | .cursor/skills/ |
| Codex CLI | ~/.agents/skills/ |
この状態で1つのSkillを複数のクライアント向けに配布するには、クライアントやスコープによっては同じSKILL.mdを別パスに複製したり配置を変更したりする必要がありました(表の通りGitHub CopilotとCodexはユーザースコープでは.agents/skills/を共有できるため、常に4回複製する話ではありません)。
開発者から見ると「同じ知識を複数の場所に別々に登録する」状態が発生していたわけです。
Vercelの公式アナウンスは、この分断を「同じコンポーネントを複数のクライアント形式に何度も適応させる作業」と表現しており、Agent Plugins 1.0.0はここに対する設計レベルの解として位置づけられています。
MCPも7月に更新、設定は各社バラバラ

もう一つの背景が、MCP側の仕様更新です。MCP(Model Context Protocol)は2026年7月28日に大きな仕様改訂を経て、bidirectional statefulからrequest/response statelessモデルに移行しました。
header-based routing(HTTPヘッダーによるルーティング)、multi-round requests(複数ラウンドの要求)、cacheable list results(リスト結果のキャッシュ)といった機能が追加され、大規模ツール群を扱うエージェントで実用性が上がりましたが、MCPサーバーの設定ファイル形式(コマンド起動方法・環境変数・接続URL)は各クライアントの独自形式のままでした。
SkillsとMCPは役割が違うため統一する必要は薄いのですが、実際の企業ユースケースでは「社内ナレッジ検索のSkillと社内DB接続のMCPサーバーをセットで配布したい」というニーズが多く、両者を1度に配布できる共通様式が求められていました。
Vercel起案から公開までの経緯

Agent Plugins 1.0.0の策定プロセスは、以下の流れで進みました。
-
Vercelが最初にプロポーザルを公開
Vercelが最初にプロポーザルを出し、共同策定の呼びかけを行った
-
Amazon・Anysphere・GitHub・Microsoft・OpenAI・Vercelの6社で仕様策定
公開前の策定期間に、6社の代表者が集まって1.0仕様のドラフトを固めた
-
2026年8月6日に公開
Vercelら6社が公式ブログで共同発表し、ローンチクライアントも同日対応済みの状態で公開された
-
発表と同日にローンチクライアント6つが対応済み状態でリリース
ChatGPT・Codex・Cursor・GitHub Copilot・Kiro・VS Codeが発表当日から利用可能
発表と同日にローンチクライアントが対応済みの状態でリリースされた点が、他の業界標準策定プロセスとは異なる特徴です。仕様の公開と実装の展開が同時に走ったことで、開発者がすぐに手を動かせる状態からスタートしました。
Agent Pluginsの構成——plugin.jsonを必須とする3要素

Agent Plugins 1.0.0の実体は、単一のディレクトリにplugin.json(必須)とskills/・mcp.json(任意)を配置するシンプルな構造です。
本セクションでは、公式仕様(agent-plugins.org/spec 1.0.0)に基づき、各要素の役割と必須項目を整理します。
plugin.jsonがマニフェスト本体

plugin.jsonはプラグインのメタデータを宣言する必須ファイルです。トップレベルフィールドは10個に固定されており、未知フィールドはクライアントに無視されます。必須は2つ、任意が8つという構成です。
以下の表で、plugin.jsonの全フィールドを整理しました。
| 種別 | フィールド | 内容 |
|---|---|---|
| 必須 | $schema | "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json"固定 |
| 必須 | name | 1〜64文字、小文字英数字とハイフン・ピリオドのみ |
| 任意 | version | Semantic Versioning推奨 |
| 任意 | description | 短い説明文 |
| 任意 | author | name/email/urlを持つオブジェクト |
| 任意 | homepage | URL |
| 任意 | repository | ソースリポジトリURL |
| 任意 | license | SPDX識別子推奨 |
| 任意 | keywords | 検索用タグの配列 |
| 任意 | extensions | クライアント固有設定(逆ドメイン名前空間) |
nameフィールドは連続するハイフンやピリオド(--・..)を含めることができず、alphanumericで始まりalphanumericで終わる必要があります。
extensionsフィールドは、特定クライアントだけが読む拡張設定を格納する場所で、com.example.clientのような逆ドメインnamespaceで区切ります。他クライアントは自分のnamespace以外を無視するため、クライアント固有設定を含めても全体の互換性が壊れない設計です。
skillsディレクトリにSKILL.mdを配置
skillsディレクトリには、複数のSkillを並列に配置できます。直下の各サブディレクトリが1つのSkillとして扱われ、SKILL.mdを含んでいる必要があります。ネストしたサブディレクトリは非対象で、skills/foo/bar/SKILL.mdのような2段以上の階層は認識されません。
Skillの中身はAnthropicのAgent Skills仕様に完全準拠し、Skillディレクトリ内にscripts・references・assetsの3種類のサブディレクトリを補助的に持てます。
Agent Plugins v1.0.0はSkills仕様に独自拡張を加えず、SKILL.mdをそのまま採用する設計です。この点が、Anthropic発のSKILL.mdが業界標準として定着したことを裏付けています。
mcp.jsonでMCPサーバー設定を統一

mcp.jsonはAgent Pluginsに含めるMCPサーバーの起動設定を宣言するファイルです。トップレベルは"$schema": "https://agent-plugins.org/schemas/1.0.0/mcp.schema.json"とmcpServersオブジェクトの2つが必須で、mcpServersはサーバー名をキー、設定をバリューとして並べます。
以下の表で、対応する3種類のサーバータイプを整理しました。
| type | 用途 | 必須フィールド |
|---|---|---|
| stdio | ローカルプロセスとして起動しstdioで通信 | type、command |
| streamable-http | HTTPで接続する外部サーバー | type、url |
| sse | Server-Sent Events接続(v1.0.0で非推奨) | type、url |
stdio型は最も一般的で、command(実行ファイル)に加えてargs・env・cwdを任意で指定できます。streamable-http型は外部のリモートMCPサーバーに接続する場合に使い、headersでHTTPヘッダーを追加可能です。sse型はv1.0.0で非推奨扱いとなっており、新規プラグインではstreamable-httpを採用するのが推奨されています。
仕様書は明確に「認証情報をheadersやenvに埋め込んではいけない」と定めており、シークレット管理はクライアント側の責務として切り出されています。
最小構成のplugin.json例
最小構成でAgent Pluginsを作る場合、plugin.jsonは以下の2行だけで成立します。
{
"$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
"name": "my-plugin"
}
このplugin.jsonをディレクトリに置き、隣にskills/{name}/SKILL.mdを1つでも配置すれば、対応クライアントに読み込まれる有効なAgent Pluginになります。
MCPサーバー設定が不要な場合はmcp.jsonを省略できます。逆にMCPサーバー設定だけを配布したい場合は、skillsディレクトリなしでmcp.jsonのみを含めた構成も有効です。
このシンプルさが、既存の複雑なpluginフォーマット(GitHub Copilot plugin等)と比べたときの設計思想の違いを表しています。「まず配布フォーマットだけを揃える」という割り切りが、6社合意を短期間で実現した要因の1つです。
Agent Pluginsの対応クライアントとインストール方法

Agent Plugins 1.0.0は、発表時点で6つのクライアントがローンチ対応しています。本セクションでは、ローンチクライアントの対応状況、GitHub Copilotの2026-08-12 GA、既存pluginからの移行作業、エンタープライズ運用時の一元管理を整理します。
ローンチ対応6クライアントの一覧
以下の表で、ローンチ時点でAgent Plugins 1.0.0に対応する6クライアントを整理しました。
| クライアント | 提供元 | 対応状況 |
|---|---|---|
| ChatGPT | OpenAI | ローンチ対応 |
| Codex | OpenAI | ローンチ対応 |
| Cursor | Anysphere | ローンチ対応(TSC参加) |
| GitHub Copilot | GitHub/Microsoft | 2026-08-12にGA |
| Kiro | Amazon | ローンチ対応 |
| VS Code | Microsoft | ローンチ対応 |
加えて、GoogleがKevin Hou氏を代表としてCore Maintainer参加を表明し、Agents CLIとData Agent Kitで対応を開始しています(MAINTAINERS.md正本への反映は本記事執筆時点で未確認)。
Skills・MCP対応済みの他のGoogle製品への拡大予定も表明されていますが、対象製品名は未公表です。
Claude Codeについては、Anthropic本体がCore MaintainerでもローンチクライアントでもないためAgent Plugins 1.0.0の公式サポートは表明されていません。
Google側発表ブログではAgents CLIの配布先ターゲットとしてClaude Codeが挙げられていますが、これはGoogle製スキルの配布経路であり、任意のAgent Plugin全般の互換性を保証するものではありません。
GitHub Copilotは8月12日にGA

GitHub CopilotはAgent Plugins 1.0.0の対応を2026年8月12日にGAとして展開しました。対応範囲はVS Codeエディター内、Copilot CLI、Copilotデスクトップアプリ、Copilot SDKの4面で、全プランで利用可能です。
Awesome Copilot marketplaceがデフォルトで利用可能となっており、公式マーケットプレイスからpluginをインストールできる状態です。既存のGitHub Copilot pluginsはAgent Plugins対応前のフォーマットも継続サポートされるため、既存プラグインの強制移行は不要です。
Copilotの動きが早かった背景として、MicrosoftがTSCに参加し、GitHubが仕様策定の6社に含まれていたことがあります。
仕様公開の翌週にGAを打ち出せたのは、内部実装が並行して進んでいたためです。他クライアントも同様に対応を進めており、AI総合研究所の観察としては、marketplace周辺の選択肢は今後数ヶ月で広がっていく見立てです。
既存pluginは互換性を保ちながら段階移行

既存のクライアント固有プラグインをAgent Plugins 1.0.0に移行する作業は、公式移行ガイドで5段階に整理されています。
-
plugin.jsonの追加
マニフェストルートに"$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json"を含むplugin.jsonを追加する。既存のname・versionがあれば流用可能。
-
Skillsの移動
既存のスキル資産をskills/{name}/SKILL.mdの構成に配置し直す。SKILL.md本体はAgent Skills仕様に完全準拠する。
-
MCP設定の変換
既存のMCPサーバー設定をmcp.jsonに変換し、"$schema": "https://agent-plugins.org/schemas/1.0.0/mcp.schema.json"とmcpServersを宣言する。各サーバーはstdio・streamable-http・sseのいずれかのtypeを明示する。
-
クライアント固有要素の保持
クライアント固有ファイルは、対象クライアントが文書化した拡張namespaceディレクトリへ保持する。対応namespaceが公開されていないクライアントは既存の互換パッケージを別途維持する形になる。
-
全クライアントでのテスト
Agent Plugins対応クライアント(Copilot・Cursor・Codex・Kiro等)で同一プラグインをインストールし、想定通りに動作するか動作検証を通す。
Agent Plugins Exampleリポジトリに公式のサンプルプラグインと移行ガイドが公開されており、実装の起点として参照できます。
既存プラグインを持っているチームは、まず1つのプラグインをこのサンプルに沿って書き換え、複数クライアントで動作するかを段階的に検証するのが実務的です。
エンタープライズでの一元管理

Copilot Business / Enterprise顧客は、既存のmanaged-settings.jsonのトップレベルキーenabledPlugins・extraKnownMarketplaces・strictKnownMarketplacesでpluginとmarketplaceを制御でき、Agent Plugins用の追加ポリシーは不要です。
社内で許可するpluginを明示リスト化し、社内Gitリポジトリまたは共有ディレクトリを社内marketplaceとして扱う場合はextraKnownMarketplacesでそれらを追加したうえで、strictKnownMarketplacesを有効化して既定marketplaceからのインストールを禁止する運用となります。エンタープライズが最初に確認すべきは、対象クライアントの管理コンソールに「Agent Plugins対応版のポリシー設定画面」が追加されているかどうかです。
Copilotの場合は既存のmanaged-settings.jsonにenabledPlugins・extraKnownMarketplaces・strictKnownMarketplacesを設定するだけで済むため、運用切り替えの負担は小さく収まります。
Agent Pluginsのガバナンス構造とAnthropic不在の意味

Agent Plugins 1.0.0は仕様のシンプルさもさることながら、GitHub agentplugins/agent-plugins-specリポジトリで定義された運営ルールにも特徴があります。
本セクションでは、TSC(技術運営委員会)の構成、意思決定プロセス、Anthropic不在の意味を整理します。
TSCは個人保有、単独ベンダー過半数を憲章で禁止

Agent Pluginsのガバナンスは、GOVERNANCE.mdで以下のように定義されています。
-
座席は個人保有、企業に予約されない
全ての運営役割は個人が保有し、企業単位の指定席は存在しない設計。
-
単独ベンダーが過半数を握れない
Core Maintainer席の過半数を1社の在籍者が占めることを憲章で禁止している。
-
意思決定プロセスは公開
contribution processとtechnical decisionsは公開されており、新機能や仕様のmaterial changeはGitHub Discussionsで議論される。
2026年8月13日時点のMAINTAINERS.md正本には、Amazon・Cursor・Microsoft・OpenAI・Vercelの5名がCore Maintainerとして掲載されています。
Googleは8月6日にKevin Hou氏を代表としてCore Maintainer参加を表明していますが、正本への反映は本記事執筆時点で未確認です。個人単位の設計により、特定企業が席を独占しないバランスが担保される仕組みとなっています。
Anthropicは不在だがSKILL.mdは採用
Agent Plugins 1.0.0の設計上、興味深いのがAnthropicの立ち位置です。AnthropicはTSCにもCore Maintainerにも参加していません。

しかし、Agent Pluginsがskills/ディレクトリ配下で採用しているSKILL.mdフォーマットは、Anthropicが2025年12月18日にオープン標準化したAgent Skills仕様そのものです。つまりAgent PluginsのSkills半分はAnthropic発の仕様に完全準拠しているのに、Anthropic自身は運営体制に入っていないという構造になっています。
Anthropic側の立場については公式表明がありません。Claude Codeには独自のpluginエコシステム(Claude Security Pluginなど)が既に存在し、独自路線を継続する余力を持っています。
実務的な影響としては、Anthropicによる正式なAgent Plugins対応は本記事執筆時点で未確認で、Agent Plugins形式のpluginがClaude Codeでそのまま動作する保証はありません。
Googleが提供するAgents CLIはGoogle製スキルの配布先としてClaude Codeを対象に含めていますが、これはGoogle製品固有の対応であり、任意のAgent Plugin全般の互換性を意味するものではありません。AI総合研究所の支援現場でも、Claude Codeを社内標準に据えている企業からは「Anthropicが今後対応表明するか」を採用時期の判断軸として意識する声が既に出始めています。
Agent Plugins 1.0.0で意図的に含まれなかった要素

Agent Plugins 1.0.0はミニマルな仕様として設計されており、多くの企業向け機能がv1.0.0の範囲外に置かれています。
以下の表は、仕様書本文とその将来検討事項を突き合わせ、v1.0.0の範囲外に置かれている代表的な7領域を記事側で整理したものです。
| 未定義領域 | 内容 | 現状の扱い |
|---|---|---|
| permission / sandboxing | pluginプロセスへのシステムアクセス統制 | 各クライアントの実装依存 |
| secrets / credentials | 認証情報の可搬な参照フィールド | env・headers直書き禁止、外部管理必須 |
| registry / package discovery | 公式パッケージレジストリ・依存解決 | クライアント固有のmarketplaceに委ねる |
| OAuth / authorization | プラグイン単位のOAuth設定 | クライアント側で実装 |
| その他コンポーネント(commands / hooks / agents / rules / LSP) | Skillsとサーバー以外の拡張 | 今後の議論対象 |
| MCP transport fallback | 接続失敗時の代替経路 | 未定義 |
| plugin dependencies | プラグイン間の依存関係宣言 | 未定義 |
7項目のうち、企業採用で影響が大きいのはpermission・secrets・registryの3つです。以下でそれぞれの実務影響を掘り下げます。
permissionとsandboxが未定義

Agent Plugins 1.0.0はpluginファイルへのアクセス範囲をplugin root内に限定する規約を持っていますが、これは「plugin配布物のファイル読み取り境界」であって、「pluginから起動したプロセスのシステムアクセス制御」ではありません。
pluginから起動されたMCPサーバーがローカルファイルシステムやネットワークにどこまでアクセスできるかは、各クライアントのsandbox実装(あるいはその欠如)に完全に依存します。
企業採用時は、対象クライアントごとに「plugin実行時のシステムアクセス範囲」を確認し、必要に応じてOSレベルのsandbox(macOSのSeatbelt、Linuxのseccomp/AppArmorなど)で補完する運用設計が要ります。
特に金融・医療・重要インフラのように監査要件が厳しい業種では、v1.0.0のミニマル仕様のままpluginを本番導入するのはリスクが高く、クライアント側の統制水準を先に確認する順序が必要です。
secretsはenvとheadersに直書き禁止

MCPサーバー設定でenvやheadersを使えますが、仕様書は明確に「認証情報を埋め込んではいけない」と定めています。
実運用では、環境変数の中身を1Password CLI・HashiCorp Vault・AWS Secrets Manager等で解決してからpluginプロセスに渡す設計が求められます。plugin.jsonやmcp.jsonに認証情報を書いた状態でリポジトリにcommitしてしまう事故を防ぐには、CI側でsecret scanning(TruffleHog・Gitleaks等)を組み込むのが定石です。
社内のpluginレビュー基準に「envとheadersに認証情報やシークレットを書いていないか」の項目を加え、レビュー時点で機械的に弾く運用にしておくと、後からの事故を予防できます。
公式レジストリなし、配布はクライアント依存
Agent Plugins 1.0.0には公式のパッケージレジストリが存在しません。バージョン解決・依存解決・脆弱性通知の仕組みも定義されていないため、配布・発見・更新は各クライアント固有のインストール機構に委ねられています。marketplace(Awesome Copilot marketplace等)はその一例で、他にrepository経由・ローカルパス指定・URLダウンロード等の経路がクライアントごとに用意されています。
複数クライアント対応のpluginを配布する場合、実務ではGitHub Releasesや社内Gitリポジトリ・共有ディレクトリにpluginバンドルを公開し、対象クライアントがrepository参照やmarketplace追加登録に対応している範囲でそれぞれの経路から取得させる形になります。
Vercelの公式アナウンスは、その他コンポーネント(commands・hooks・agents等)について「semanticsが収束し可搬性のニーズが実証されてから議論に入る」段階的アプローチを明示しており、v1.0.0は「まず配布フォーマットだけを揃える」意図で設計されています。
企業側は、「v1.0.0で足りないもの」を認識した上で、既存のCI/CD・シークレット管理・アーティファクトリポジトリの資産で穴を埋める前提でPoCに入るのが安全です。
Agent PluginsとMCP・Agent Skills・GitHub Copilot pluginの位置関係

Agent Plugins 1.0.0は既存の複数の規格と共存する形で登場したため、「MCPやAgent Skills、GitHub Copilot pluginとどう違うのか」という疑問が現場で頻出します。
本セクションでは、Agent Pluginsを含めた4規格をレイヤーで整理し、それぞれの棲み分けを解説します。
実行/能力/配布の3レイヤーで棲み分け
以下の表で、4規格の関係を3層のレイヤーで整理しました。
| レイヤー | 規格 | 役割 |
|---|---|---|
| 実行レイヤー | MCP(Model Context Protocol) | エージェントと外部ツール/データソースの通信プロトコル |
| 能力パッケージレイヤー | Agent Skills(SKILL.md) | 1つの能力をMarkdown+スクリプト+参考資料でパッケージ化 |
| 配布パッケージレイヤー | Agent Plugins 1.0.0 | 上位2レイヤーを1フォルダにまとめて複数クライアントに配布 |
| クライアント固有拡張レイヤー | GitHub Copilot plugin等 | 特定クライアントに特化した拡張フォーマット |
MCPは「通信手段」、Agent Skillsは「能力の単位」、Agent Pluginsは「配布の単位」、GitHub Copilot pluginは「特定クライアント向けの拡張」と、それぞれ担当する層が異なります。競合ではなくレイヤー違いの補完関係です。
Agent Plugins 1.0.0のフォルダにはSkills(SKILL.md)とMCP設定(mcp.json)が両方含められるため、Skills単体またはMCP単体で作られた既存資産をAgent Pluginsとして束ねなおすことで、複数クライアントで再利用できるようになります。
既存独自pluginも並存する

Agent Plugins 1.0.0の登場前から、各クライアントは独自のplugin形式を持っています。
-
GitHub Copilot plugin
GitHub Copilot独自の拡張フォーマット。VS Code・CLI・desktop app・SDKで動作。Agent Plugins 1.0対応後も既存のGitHub Copilot pluginはサポート継続。
-
Claude Code plugin
Anthropic独自のpluginフォーマット。.claude-plugin/plugin.jsonを持つパッケージ形式で、marketplace経由でインストールしたpluginはClaude Codeが~/.claude/plugins/cache/にキャッシュ管理する。Agent Plugins 1.0.0の公式対応は未確認で、相互運用の保証はない。
-
Cursor rules
.cursor/rules/配下のCursor固有ルール定義。Agent PluginsのSKILL.mdとは別レイヤー。
Agent Plugins 1.0.0は既存pluginフォーマットの置き換えではなく、複数クライアントに配布する必要が出てきた時点で共通様式に統一する選択肢として位置づけられます。単一クライアントで完結する用途では既存の独自フォーマットを継続する方が実装コストが低い場合もあります。
A2Aとは対象レイヤーが異なる

エージェント関連のもう一つの仕様にA2A(Agent-to-Agent Protocol)があります。
A2Aはエージェント同士の連携・委任・多エージェント協調のプロトコルであり、Agent Pluginsが扱う「単一エージェントの拡張機能配布」とは対象領域が異なります。
企業でマルチエージェント基盤を構築する場合、A2A(エージェント間の連携)+ Agent Plugins(エージェント拡張の配布)+ MCP(ツール接続)の3層を並行して設計することになります。それぞれ独立に進化していく仕様なので、混同せず、担当領域を分けて把握しておくことが重要です。
企業がAgent Pluginsの採用を検討するときの判断軸

Agent Plugins 1.0.0は登場から約1週間の新標準です。企業導入を検討する際は、「今すぐ採用すべきか」「様子見すべきか」「採用不要か」をケース別に判断する必要があります。
本セクションでは、AI総合研究所の企業向けAI推進支援における観察を踏まえ、ケース別の判断軸を整理します。
今すぐ採用を検討すべき企業

以下の条件のいずれかに該当する企業は、Agent Plugins 1.0.0を今から検討する価値が大きいです。
- CopilotとCursorとCodexなど複数のAIコーディングツールを社内で並行運用しており、Skillsを各社向けに複製管理する非効率が既に発生している
- 社内で自作したSkillsやMCPサーバーを部門横断で配布したいが、Copilot・Cursorそれぞれの独自形式に対応する工数が採算に合わない
- GitHub Copilot Business/Enterprise契約があり、Awesome Copilot marketplace経由でのplugin配布を検討中
- 開発者ツールベンダーとして、複数のAIエージェントクライアント向けに拡張機能を提供している
これらのケースでは、Agent Plugins 1.0.0を採用することで「1回作ったポータブルコアを複数クライアントで再利用できる」効果が短期間で回収可能な状態にあります。
ただし対応コンポーネントや細部の挙動はクライアントごとに検証が必要です。特に「複数AIコーディングツール並行運用」は、AI総合研究所の支援現場でも2026年後半以降ますます一般的になってきており、Skills資産が積み上がる前にAgent Plugins形式に統一しておくと、後からの再実装コストを大きく削減できます。
様子見を推奨するケース
以下の場合は、v1.1〜v2の仕様追加を待ってから採用判断を下すのが安全です。

- Claude Codeが社内標準のAIコーディングツールで、他クライアントへの拡大予定がない
- permission / sandboxの統制が業界標準として必要な業種(金融・医療・重要インフラ)
- secrets管理を仕様レベルで統一したい要件がある
Agent Plugins 1.0.0はpermission・sandbox・可搬なsecrets参照が未定義で、クライアント側の実装に完全依存します。
統制要件が厳しい業種では、v1.0.0のミニマル仕様では監査・コンプライアンス上の説明責任を果たしにくく、Anthropicが公式対応表明するタイミング(もしくはv1.1でセキュリティ関連の議論が固まるタイミング)を待つ判断が現実的です。
Anthropic対応表明を待つ理由
Claude Codeは、AI総合研究所の支援現場でも社内利用の広いツールの1つとして観察していますが、前述のようにAnthropic自身はAgent Plugins 1.0.0のCore Maintainerに不在です。
AI総合研究所の支援現場で観察している傾向として、企業内でAIコーディングツールの標準化が進む2026年後半以降、「Copilot中心か、Claude Code中心か」の選択が事業インパクトに直結するケースが増えています。
Agent Pluginsを採用するかどうかは、この社内標準ツールの選定と密接に連動する意思決定になります。
Claude Code中心で運用している企業は、Anthropicが Agent Pluginsの公式対応を表明するまで、既存のClaude Code plugin形式を継続するのが低リスクの選択肢です。
逆に、Copilot・Cursor・Codexを横断利用している企業は、Agent Plugins 1.0.0を先行採用して社内Skills・MCP資産を統一しておくと、後から対応クライアントが増えたときの再実装コストを抑えられます。
PoC設計の推奨手順

Agent Plugins 1.0.0のPoCを実施する場合、以下の3ステップで進めるのが実務的です。
-
Step 1: 既存Skillsをplugin形式に変換
社内で既に運用中のClaude Code skillまたはCopilot skillを1つ選び、plugin.jsonとskills/ディレクトリの構成に置き換える。SKILL.md自体は流用可能。
-
Step 2: 対象クライアントで動作確認
CopilotとCursorで同じpluginをインストールし、Skillが両方で同じ挙動をするか確認する。挙動差があれば、対象クライアントが文書化した拡張namespaceに振り分けるか、対応namespaceがなければ既存の互換パッケージを別途維持して対応する。
-
Step 3: MCP設定を追加して配布経路を確定
社内のMCPサーバーがあればmcp.jsonに追加し、GitHub Releasesや社内Gitリポジトリへの配布経路を確定させる。secretsはVaultなどの外部管理を組み込む。
この3ステップで、企業としてAgent Plugins 1.0.0を継続採用するか判断できるだけの実装経験と運用課題の把握が得られます。AI総合研究所の実装経験上は1ヶ月程度で回せる規模感なので、まずは1つのSkillsをこのフローに乗せて手触りを確かめるのが、意思決定の質を上げる最短ルートです。
Agent Plugins対応をきっかけに社内AIエージェント基盤を整えるなら
Agent Plugins 1.0.0の登場で、複数のAIコーディングツールを跨いだSkills配布の標準化が進みました。ただ、企業が実際に社内展開する段階では、モデル選定・plugin配布・実行権限管理・監査ログ・データガバナンスを一体で設計する層が必要になります。仕様が「配布フォーマットだけを揃える」ミニマル設計で切り出された分、企業側で埋めるべき統制レイヤーは増えている状況です。
AI総合研究所が提供するAI Agent Hubは、社内AIエージェント基盤をAzure Managed Applicationsとして自社テナント内に閉じて構築する運用基盤です。Agent Plugins対応クライアントの選定・plugin配布経路の設計・実行時の権限管理・監査対応まで、一気通貫で支援できます。
-
複数AIコーディングツールの統合管理
Copilot・Cursor・Codex・Claude Codeの中から社内標準を決定し、社内Skills・MCPサーバーをAgent Pluginsとして統一配布する体制を設計。
-
社内plugin marketplaceの構築
Awesome Copilot marketplaceや社内Gitリポジトリを組み合わせて、社内で許可したpluginだけを配布する運用フローを構築。
-
secretsとpermissionの補完設計
Agent Plugins v1.0.0で未定義のsecrets管理とpermission統制を、Vault・OS-level sandbox・監査ログで補完する設計。
-
データは100%自社Azureテナント内で完結
plugin実行時のデータ・ログ・処理内容は自社Azureテナント内に閉じる設計。Azure Managed Applicationsとして、AIの学習対象からも完全除外。
AI総合研究所の専任チームが、Agent Plugins 1.0.0対応判断から社内AIエージェント基盤の統合設計まで一貫して支援します。AI Agent Hubのサービスページで、企業横断AIツールをAgent Pluginsで統一運用する実装例をご確認ください。
Agent Plugins対応をきっかけに社内AIエージェント基盤を整えるなら
複数ツール横断の運用基盤を1つの管理層で束ねる
Agent Plugins 1.0.0でSkillsとMCPの配布フォーマットは統一されましたが、実行時のpermission・secrets・監査ログは各クライアント任せのままです。AI Agent Hubは、Copilot・Cursor・Codex・Claude Codeを横断した社内AIエージェント運用基盤をAzureテナント内に閉じて構築し、モデル・plugin配布・権限管理・監査対応を1画面で統合します。
まとめ
本記事では、Agent Plugins 1.0.0について、仕様の中身・対応クライアント・ガバナンス構造・v1.0.0で未定義の要素・MCPやAgent Skillsとの位置関係・企業採用の判断軸を、2026年8月時点の最新情報で解説しました。
2026年8月時点で押さえておくべきポイントは次の3つです。
- plugin.jsonを必須にSkillsとMCP設定を任意で束ねる配布標準として、Vercel発起・6社共同で2026年8月に公開、Copilot GA済で企業導入の入口が整った
- Amazon・Cursor・Microsoft・OpenAI・Vercelの5名がCore Maintainer、Anthropicは不在だがSkills半分はSKILL.mdをそのまま採用する変則構造
- v1.0.0はpermission・sandbox・secrets参照・公式registryが未定義で、統制要件の厳しい業種はv1.1とAnthropic対応表明を待つ判断が現実的
Agent Plugins 1.0.0は、AIエージェント業界が「各社独自pluginの並列開発」から「共通配布フォーマット+クライアント固有拡張」へと転換する節目のリリースです。企業として最も重要な意思決定は採用可否そのものよりも、社内標準のAIコーディングツール(Copilot / Claude Code / Cursor)をどこに置くかという上位判断で、その延長線上でAgent Pluginsの採用時期が決まります。
まずは社内で運用中のSkillsまたはMCPサーバーを1つ選び、Agent Plugins 1.0.0形式に変換するPoCから着手するのが、複数クライアント対応の第一歩として最も実用的です。













