Agent Plugins 1.0 が GA、プラグインを一度作れば複数のエージェントで動く

要約

GitHub が 2026-08-12、Agent Plugins 1.0 への対応を VS Code、Copilot CLI、GitHub Copilot SDK、GitHub Copilot アプリで一般提供にしました。全 Copilot プランが対象です。

Agent Plugins 1.0 は 2026-08-06 に公開されたオープン標準で、エージェント向けのスキルと MCP サーバーを1つのインストール可能なプラグインとしてまとめる仕様です。AWS、Anysphere（Cursor）、Microsoft、OpenAI、Vercel、Google が支持を表明しています。特定ベンダーに紐づかない形で「一度作れば複数のエージェントクライアントで動く」ことを目指したものです。

これまでは、複数のエージェントへ同じプラグインを配ろうとすると、クライアントごとに別のマニフェストとディレクトリ構成を維持する必要がありました。1.0 では構成が標準化されます。plugin.json に $schema フィールドを足し、スキルは skills/ 配下、MCP の設定は mcp.json に置きます。Copilot 固有のコンポーネントは com.github.copilot/ ディレクトリに入れる決まりで、他のクライアントはこのディレクトリを無視します。共通部分と固有部分を明示的に分離する設計です。

既存の GitHub Copilot プラグインとは完全な後方互換があり、移行作業は不要とされています。加えて Awesome Copilot マーケットプレイスからのインストールにも対応しました。

企業側のガバナンスは、既存の仕組みがそのまま使えます。Copilot Business / Enterprise は managed-settings.json でプラグインの可用性を管理でき、Agent Plugins 用に別建てのポリシーを用意する必要はありません。

何が変わったか

• Agent Plugins 1.0 対応が VS Code / Copilot CLI / Copilot SDK / Copilot アプリで GA になった
• 全 Copilot プランが対象
• plugin.json への $schema 追加、skills/ 配下のスキル、mcp.json の MCP 設定という標準構成が定まった
• Copilot 固有のコンポーネントは com.github.copilot/ に置き、他クライアントは無視する
• 既存の GitHub Copilot プラグインとは後方互換があり、移行作業は不要
• Awesome Copilot マーケットプレイスからプラグインをインストールできる
• Business / Enterprise は既存の managed-settings.json でプラグインの可否を統制できる

業務インパクト（一般企業向け）

効いてくるのは、社内向けのスキルや MCP サーバーを配っている組織です。

これまで「社内の申請フローを叩く MCP サーバー」や「レビュー観点をまとめたスキル」を配布しようとすると、エージェントごとに包装をやり直す必要がありました。開発部門は VS Code、デザイン寄りのチームは別のクライアント、といった具合に利用ツールが割れている組織では、この包装作業がそのまま維持コストになります。1.0 はこの重複を消す方向の変更です。

もう一つの効果は、標準化の決定を急がなくてよくなることです。「社内のエージェントは Copilot に統一する」と決めきる前に、まず共通仕様でプラグインを作っておけます。ツール選定は数年単位で揺れるものですが、資産の側が特定クライアントに固定されていなければ、選定を見直しても作り直しになりません。AWS・Microsoft・OpenAI・Google・Vercel・Anysphere が同時に名を連ねている点は、この期待を持つ根拠として十分でしょう。

管理面では、新しい統制の仕組みを覚え直す必要がありません。managed-settings.json でプラグインの可否を管理する運用がそのまま継続します。ここは地味ですが重要で、新しい配布形式が入るたびに別のポリシー体系が増えていくと、管理者側で把握しきれなくなります。

一方で、実務として気をつける点もあります。プラグインが複数クライアント間で持ち回れるということは、審査すべき対象が増えるということでもあります。マーケットプレイスから入れられる範囲が広がった分、社内でどのプラグインを許可するかの線引きは早めに決めておいた方がいいでしょう。標準化の恩恵は配布側だけでなく、配布したい第三者にも同じように働きます。

副業・個人活用視点

個人開発者や副業でツールを作る立場だと、作ったものの到達範囲が広がるという話になります。

これまで「Copilot 向けに作ったスキル」は Copilot の利用者にしか届きませんでした。1.0 の構成で作れば、対応した他のクライアントの利用者にも同じものが届きます。自分の作ったスキルを公開して認知を取りたい場合、母数が変わるのは無視できません。

作る側の手間としては、com.github.copilot/ の切り分けさえ意識しておけば済む設計になっています。共通で使える部分は共通の場所に置き、Copilot でしか意味のない部分だけ専用ディレクトリに逃がす。この分離を最初から守っておけば、後から他クライアント対応を足すときに書き直しが発生しません。逆に共通部分に Copilot 固有の前提を混ぜ込むと、その利点は消えます。

案件として拾える切り口は、社内プラグインの整備です。「レビュー観点をスキルにする」「社内 API を MCP サーバーにする」といった作業は、これまでもニーズはありましたが、配布形式がクライアント依存なぶん提案しづらい面がありました。標準ができたことで「作ったものが一定期間使い続けられる」という前提が置けるようになり、提案としての説得力は上がります。

発信のネタとしては、実際にプラグインを1つ作って複数クライアントで動かしてみる検証が素直です。仕様が公開された直後は「動くと書いてある」と「実際に動く」の距離が読者の関心事なので、詰まった箇所も含めて記録すると価値が出ます。