【日次ログ】Agent Plugins 1.0：共通化できる部分と残る互換性確認
Agent Plugins 1.0で共通になるのは、主にSkillsとMCPサーバー設定をまとめる形式です。「一つにまとめられる」と「移行先で全機能が無改造で動く」は同じではありません。独自のエージェント、フック、ルールまで含めて運用している場合は、共通部分と製品専用部分を分ける必要があります。
2026年9月5日、初稿をGitHubの発表と仕様本文で再確認しました。これは文書照合であり、同一プラグインを複数製品へインストールした比較試験ではありません。表紙の「資産を使い回せる」は、以下の対応範囲に限って読む必要があります。
1. 仕様の公開とCopilotの対応発表は別の日
GitHubの8月12日付発表によると、仕様は8月6日にGitHubとAWS、Anysphere、Microsoft、OpenAI、Vercelが公開し、同日にGoogleがコアメンテナーに加わりました。
8月12日の記事は、VS Code、Copilot CLI、GitHub Copilot SDK、Copilotアプリでの一般提供を案内しています。仕様の共同公開と、各製品の対応開始を一つの出来事として扱うと、どの環境で使えるのかが曖昧になります。
初稿の説明文にはAnthropicを共同公開企業に含める誤記がありました。参照した発表の記載に合わせて訂正しています。また、企業数だけを根拠に、すべての製品が同じ機能に対応したとは判断できません。
2. 共通部分と製品専用部分の境界
公式の構成ガイドでは、ルートのplugin.jsonが基本となり、SkillsやMCP設定は必要に応じて含めます。最小のマニフェストだけで、すべての機能が追加されるわけではありません。
| 部分 | 仕様で整理される内容 | 移行時に残る確認 |
|---|---|---|
plugin.json |
スキーマとプラグインの基本情報 | 移行先がその仕様版を扱えるか |
skills/ |
Skills対応クライアントが読むスキル群 | 内容・依存ツール・実行環境が合うか |
mcp.json |
MCPサーバー設定 | 通信方式、認証、起動コマンドが使えるか |
| クライアント固有拡張 | 製品専用機能を名前空間で分離 | 移行先では読み飛ばされないか |
| インストール・更新・有効化 | 共通形式の仕様範囲外 | 各製品の導入方法と管理設定を確認する |
たとえばGitHubの発表では、Copilot専用のエージェント、コマンド、ルール、フックなどを専用領域へ置く方法が説明されています。拡張仕様は、非対応の名前空間を他のクライアントが無視できるとしています。
つまり、読み込み時にエラーがなくても、必要なチェック用フックが動いているとは限りません。「インストール成功」を「業務手順も同じ」と読み替えないことが大切です。
3. 既存プラグインを急いで変換する必要はあるか
GitHubは、Agent Plugins 1.0形式ではない既存のCopilotプラグインも引き続きサポートし、移行を必須にしないと案内しています。新しい標準が出たこと自体は、現在動いているものを即日変換する理由にはなりません。
Awesome Copilotマーケットプレイスは既定で利用できる案内先ですが、唯一の配布経路という説明ではありません。共通仕様そのものは配布・更新・画面の挙動を統一していないため、組織のマーケットプレイス設定や許可範囲も別に確認します。
特にMCPの接続先や実行権限は、ファイル形式が共通になっても安全性が保証されるわけではありません。既存の認証情報を別の製品へ自動的に移す、管理者の制限を迂回する、といった移行手順にはしないでください。
4. 実務で資産を移す前の点検手順
以下は仕様から整理した確認手順です。このサイトで動作互換を実証した結果ではありません。小規模なチームなら、最初から全資産を変換せず、機密を含まない一つのスキルから確認する方が切り分けやすくなります。
- 現在のプラグインを、Skills、MCP、製品専用機能に分類する。ルールやフックが担う確認処理を洗い出す。
- 公式の対応一覧で、移行先の対応部品とMCPの通信方式を確認する。「対応クライアント」という見出しだけで全機能対応と扱わない。
- 各製品の導入手順、版条件、管理者による許可を確認する。移行元で使う秘密情報を、そのまま配布物へ含めない。
- 小さな課題で、スキルが呼ばれたか、MCP接続が成立したか、専用の確認処理が動いたかを別々に記録する。
- 動かない部分は共通形式の問題か、通信・認証・実行環境か、製品専用機能かを切り分ける。本番の手順を切り替えるのはその後にする。
記録欄は「移行元／移行先と版／部品／期待した処理／実際の結果／不足時の対応」で十分です。とくに公開前チェックをフックに任せているなら、それが移行後も実行されることを独立して確認する必要があります。
5. 今回分かったことと未検証の範囲
公式資料で確認できたのは、共通形式、製品専用拡張の境界、GitHub側の提供範囲、既存形式の継続対応です。プラグインの作成・導入、複数製品での同一課題の実行、Claude Codeとの相互運用は今回検証していません。対応一覧に名前がないことだけで、ある製品が利用不能だとも断定しません。
初稿にあった「以前はツールごとに作り直すか、一つに絞る二択」「同じ発想だから、そのまま移植できる可能性が増える」という説明は、具体的な互換性の根拠にならないため改めました。
2026年9月5日の改稿では、全面的な乗り換え容易化という見せ方から、共通化できる部分を見つけ、残る確認を減らすための規格という説明へ整理しました。次に見るのは対応企業の数ではなく、自分のプラグインに必要な部品が移行先で動くかどうかです。