Agent Plugins 1.0.0とは — AIエージェント拡張を1つのフォーマットに束ねるベンダー中立オープン標準

Agent Plugins（エージェントプラグイン）とは、2026年8月6〜7日に公開された、AIエージェントの拡張機能を配布するためのベンダー中立なオープン仕様「Agent Plugins 1.0.0」の略称である。Agent Skills（特定タスクの手順や知識を記述したファイル群）とMCP（Model Context Protocol）サーバーの設定を1つのフォルダにまとめてパッケージ化し、対応する複数のエージェントクライアントで共通の形式として再利用できるようにする点が核心である。仕様はGitHubのagentplugins/agent-plugins-specリポジトリでオープンに開発されている。

これまでAIエージェントの拡張機能は、ChatGPT・Cursor・VS Code・GitHub Copilotなど製品ごとに独自のフォーマット、独自のディレクトリ構造、独自のセットアップ手順を持っていた。1つの拡張機能を複数のエージェントクライアント向けに提供したい開発者は、製品ごとに設定ファイルを書き直し、フォルダ構成を変え、動作確認をやり直す必要があった。Agent Plugins 1.0.0が解決しようとしているのはこの重複コストである。「一度作れば、対応する複数のエージェントクライアントで使える」という配布モデルを目指している。

提案元はVercelで、AWS・Anysphere（Cursorの開発元）・GitHub・Microsoft・OpenAIの担当者が共同で仕様化にあたった。Technical Steering CommitteeのCore MaintainerにはAWS・Cursor・Microsoft・OpenAI・Vercelに加えてGoogleも参加している。一方で、MCPとAgent Skillsという2つの主要技術を自社で生み出したAnthropicは、本仕様の共同策定には参加していない（Anthropicは自社製品Coworkに独自のプラグイン機能を追加する方向で動いている）。この点は優劣の話ではなく、業界の拡張エコシステムが複数の潮流に分かれつつある事実として押さえておきたい。

Agent Pluginsのパッケージは、ルートに配置するマニフェストファイルplugin.jsonを中心に構成される。仕様上の最小必須フィールドは$schemaとnameの2つのみで、それ以外の要素はすべて任意（オプショナル）である。任意で追加できる要素は主に3種類ある。1つ目はskills/ディレクトリで、ここに個々のAgent Skillsをサブフォルダ単位で格納する（各スキルはSKILL.mdにnameやdescriptionなどのフロントマターを持つ）。2つ目はmcp.jsonで、そのプラグインが提供するMCPサーバーの起動設定を記述する。3つ目はクライアント固有の名前空間付きディレクトリ（例：com.example.client/）で、特定のエージェントクライアントだけが解釈する追加設定を、他のクライアントの動作に影響を与えずに同梱できる。

plugin.jsonの最小構成は次のようになる。

重要なのは、インストールや配布の仕組みそのものは仕様の範囲外だという点だ。Agent Plugins仕様が定めるのは「クライアントがプラグインの中身を発見し、ロードするために必要な形式」だけであり、パッケージをどこからどう取得させるか（レジストリ、ZIP配布、Git URLなど）は各クライアントが独自に扱う。commands・hooks・agentsといった、クライアント側で既に固有の形をとっている要素も、今回は標準化の対象になっていない。つまりAgent Plugins 1.0.0が担うのは「フォルダの中身をどう並べるか」というパッケージング層だけであり、そのフォルダをユーザーにどう届けるか、クライアント内でどう有効化するか、といった配布・実行の体験は各社の裁量に委ねられている。これは仕様をシンプルに保ち、各クライアントの既存のセキュリティモデルやUIを壊さずに済むという設計判断だと理解できる一方、後述するように配布時の安全性（署名検証やサンドボックスなど）が今のところ標準化されていない理由にもなっている。

ローンチ時点でAgent Plugins 1.0.0に対応を表明しているエージェントクライアントは、ChatGPT・Codex・Cursor・GitHub Copilot・Kiro・VS Codeの6つである。Googleはローンチ日にあわせて、Agents CLIとData Agent Kitという2つの実装を公開した。開発ツール系（Cursor・GitHub Copilot・VS Code・Kiro）と対話型AIサービス（ChatGPT・Codex）の両方に対応クライアントが揃っている点は、この仕様が「開発者のエディタ内エージェント」だけでなく「一般的な対話型AIエージェント」も対象に含めていることを示している。もっとも、対応表明の内容は各社のドキュメントやリリースノートで随時更新される可能性があるため、実際に導入を検討する際は各クライアントの最新情報を確認したい。

「Agent Pluginsは結局MCPと同じものか」「Agent SkillsやClaude Codeのプラグイン機能、VS Code拡張とどう違うのか」という疑問は当然出てくる。それぞれ扱う範囲が異なるため、並べて整理する。

整理すると、MCPとAgent Skillsはそれぞれ「ツール接続」「タスク知識」という部分機能の標準であり、Claude CodeのプラグインやVS Code拡張は特定製品専用の拡張パッケージ形式である。Agent Plugins 1.0.0はこの中間に位置し、MCPとAgent Skillsという既存の2つの部品を「1つの配布可能な単位」としてラップし、複数のクライアントに向けて同じ形で提供できるようにする役割を担う。既存技術を置き換えるものではなく、それらを束ねる上位のコンテナフォーマットだと理解するのが実態に近い。言い換えれば、これまで「MCPサーバーはこのリポジトリ、Agent Skillsはこの設定ファイル」と別々に配布・案内していたものを、1つのフォルダ・1つのマニフェストにまとめて渡せるようになる、というのがAgent Plugins 1.0.0の実務上のメリットである。Claude CodeのプラグインやVS Code拡張のように特定製品のエコシステムに閉じたものではなく、対応する複数のクライアントで同じパッケージがそのまま動くことを目指している点が、既存の製品専用拡張形式との一番の違いといえる。

現時点のAgent Plugins 1.0.0はまだWorking Draft（作業中の草案）扱いであり、実務で気になる次の要素は本稿執筆時点では明記されていない、あるいは将来課題として明示的に仕様の範囲外に置かれている。特に企業導入を検討する場合、「誰が作った拡張を、どこまでの権限で動かすか」を制御する仕組みが仕様側に存在しないことは大きな制約になる。プラグインを外部から取得して実行する以上、実行環境の分離や改ざん検知は利用者側で別途用意する必要があるということだ。

- パーミッションモデル（プラグインがどこまでの権限を持つかの制御）
- サンドボックス（実行環境の分離・隔離）
- 署名検証（プラグインの改ざん・出自の検証）
- シークレット管理（APIキーなど機密情報の扱い）
- マーケットプレイス・レジストリ（プラグインを発見・入手する共通の場）

v1.0.0がWorking Draftである以上、今すぐ大規模な移行作業を行う段階ではない。ただし、社内でMCPサーバーやAgent Skillsをすでに複数製品向けに個別実装している組織であれば、次の3点は先取りしておく価値がある。第一に、既存のMCPサーバー設定とAgent SkillsのSKILL.mdを、製品固有のディレクトリ構造から分離しておくこと。将来plugin.jsonでラップする際に移行コストが下がる。第二に、社内で使っているエージェントクライアント（ChatGPT・Cursor・VS Code・GitHub Copilotなど）が対応表明した時点で、まずは非機密なプラグインから試験導入し、パーミッションやシークレットの扱いは自社側のポリシーで別途担保すること。仕様側にセキュリティ機構がまだない以上、実行環境の権限制御は利用者側の責任範囲になる。第三に、社内MCP連携やAgent Skills活用の知見は資産として蓄積しておくこと。関連する基礎知識は

- MCP 2026-07-28 仕様公開で最新のMCP仕様動向を確認する
- Claude Code MCP連携ガイドで既存クライアントでのMCP実装パターンを把握する
- EmDashのAI統合機能でMCPとAgent Skillsを組み合わせた実装例を見る

といった記事も参考になる。仕様がWorking Draftから正式版に向けて固まっていく過程で、パーミッションモデルやレジストリの提案が出てくる可能性が高く、今後の追随が必要な領域だ。特に、社内で複数のエージェントクライアントを併用している組織ほど、拡張機能のメンテナンスコストが製品数に比例して増えていく構造になりがちだった。Agent Plugins 1.0.0がWorking Draftから正式版へ進み、対応クライアントが増えていけば、社内向けMCPサーバーやAgent Skillsを「1つのプラグインとして保守し、複数クライアントに配る」という運用に移行できる可能性がある。今の段階では仕様の変更リスクを踏まえて本番の重要業務に依存させることは避けつつ、動向を継続的に追っておくのが実務的な立ち位置になる。