AIエージェント向けプラグインは、クライアントごとにmanifestと配置を作り直す状態から抜け出し始めました。
しかしAgent Plugins 1.0が共通化したのは、代表的な6機能のうちSkillsとMCP serversの2つだけです。
この「狭い標準化」こそ、移植性と各製品の進化を両立させる設計上の核心です。

2026年8月31日、GitHubはVS Code v1.132〜v1.135のAIエージェント更新をまとめ、Agent Plugins 1.0準拠プラグインの導入を主要項目として挙げました。さらに9月2日時点のVS Code公式ドキュメントには、パッケージの検出、MCP serverの起動、更新、クライアント固有拡張の扱いまで明記されています。

この記事ではニュースの要約ではなく、Agent Plugins 1.0をパッケージ境界のプロトコルとして読み解きます。

まず結論：標準は「全部入り」ではない

VS Codeの公式ドキュメントが列挙する6機能を、移植可能性で分けると次のようになります。

機能	Agent Plugins 1.0で標準化	VS Code / Copilot固有の配置	主な役割
Skills	はい	`skills/<name>/SKILL.md`	手順、知識、スクリプトを必要時に読む
MCP servers	はい	`mcp.json`	外部ツールやデータへ接続する
Custom agents	いいえ	`com.github.copilot/agents/`	ペルソナ、モデル、ツール構成を固定する
Hooks	いいえ	`com.github.copilot/hooks/hooks.json`	ライフサイクル時にコマンドを実行する
Slash commands	いいえ	`com.github.copilot/commands/`	チャットから定型処理を起動する
Rules	いいえ	`com.github.copilot/rules/`	クライアント固有の振る舞いを制約する

標準化率だけ見れば2/6、約33%です。それでも価値があるのは、Skillsが「どう判断するか」、MCPが「何を実行できるか」というエージェントの再利用可能な核を押さえているからです。一方、UIコマンドやhookのイベント名まで固定すると、各クライアントの開発速度を標準が縛ってしまいます。

「同じパッケージを読める」と「全クライアントで同じ機能が動く」は別です。仕様は、クライアントが未対応のcomponent typeやnamespaceを無視できるようにしています。

最小構成は2フィールドと固定ディレクトリ

最小のplugin.jsonに必須なのは$schemaとnameの2フィールドです。

{
  "$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
  "name": "release-safety"
}

パッケージは次のように置きます。

release-safety/
├── plugin.json
├── skills/
│   └── preflight/
│       ├── SKILL.md
│       └── scripts/
│           └── verify.sh
├── mcp.json
└── com.github.copilot/
    ├── agents/
    └── hooks/
        └── hooks.json

ここで重要なのは、plugin.jsonに各componentのパスを書かないことです。クライアントは必ずrootのskills/とmcp.jsonを見ます。Skillはskills/直下の子ディレクトリだけを探索し、さらに深い階層を再帰探索しません。

この固定探索には3つの効果があります。

manifestのパス差し替えによる曖昧さをなくす
クライアントが高速かつ決定的にcomponentを列挙できる
パッケージ監査で「どこに実行物があるか」を予測できる

読み込みは一括成功ではなく、段階的に壊れる

Agent Plugins 1.0の読み込みは、単純なall-or-nothingではありません。障害の範囲を意図的に狭くしています。

plugin.jsonを検証
  ├─ 致命的なschema違反 → plugin全体を拒否
  └─ 有効
      ├─ skills/を探索 → 不正なSkillだけskip
      ├─ mcp.jsonを検証 → 不正ならMCP全体だけ無効
      │   └─ serverごとに検証 → 不正なserverだけskip
      └─ 対応namespaceを読む → 未対応namespaceは無視

例えば、mcp.jsonのschema versionがplugin.jsonと一致しなければMCP機能は無効になりますが、正しいSkillsまで巻き添えにはしません。1つのMCP serverが起動や認証に失敗しても、別serverとSkillsの読み込みは継続します。

この設計は、複数ベンダーのクライアントで完全一致を期待するより、共通部分を安全に取り出し、非対応部分を局所的に落とす方が現実的だという判断です。

MCP設定がtransportを「推測」しない

Agent Plugins 1.0のmcp.jsonは、stdio、streamable-http、非推奨のsseという3つのtypeを明示します。クライアントは設定からtransportを推測せず、宣言された方式で最初の接続を行います。

{
  "$schema": "https://agent-plugins.org/schemas/1.0.0/mcp.schema.json",
  "mcpServers": {
    "local-checker": {
      "type": "stdio",
      "command": "./bin/checker",
      "args": ["--state", "${PLUGIN_DATA}/checker"],
      "cwd": "${PLUGIN_ROOT}"
    },
    "deploy-api": {
      "type": "streamable-http",
      "url": "https://deploy.example.com/mcp"
    }
  }
}

PLUGIN_ROOTは配布物の読み取り位置、PLUGIN_DATAは更新後も残る書き込み可能な状態領域です。依存関係、cache、生成物をplugin本体から分離できるため、更新で状態を消しにくくなります。

一方で安全上の制約も厳密です。

commandはshell文字列ではなく単一の実行可能token
package内の実行ファイルは./で始まる相対パス
非loopbackのremote endpointはHTTPS必須
URLやHTTP headerでは環境変数展開を行わない
headersやenvにsecretを埋め込んではならない

つまりこれはsecret配布規格ではありません。OAuth discovery、資格情報の保存、ユーザー同意はクライアント側の責務です。

「閉じたcore、開いた端」が互換性を作る

rootのplugin.jsonはclosed schemaです。許可されたtop-level field以外を製品が勝手に生やすのではなく、クライアント固有データはextensionsのreverse-domain namespaceへ入れます。ファイルも同じ名前のtop-level directoryに隔離します。

{
  "$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
  "name": "release-safety",
  "version": "1.0.0",
  "extensions": {
    "com.github.copilot": {
      "channel": "stable"
    }
  }
}

VS Codeはcom.github.copilotを解釈し、別クライアントは知らないnamespaceを検証せず無視します。coreの意味を汚染せずに製品固有機能を追加できるため、標準の更新を待たずに実験できます。

Claude形式や既存Copilot形式との違い

VS Codeは2026年9月2日時点で4形式を自動判定します。

形式	manifest位置	portable core	root変数
Agent Plugins 1.0	`plugin.json` + canonical `$schema`	Skills、MCP	`${PLUGIN_ROOT}`
Copilot形式	rootの`plugin.json`	クライアント依存	`${PLUGIN_ROOT}`または`${CLAUDE_PLUGIN_ROOT}`
Claude形式	`.claude-plugin/plugin.json`	クライアント依存	`${CLAUDE_PLUGIN_ROOT}`
Legacy OpenPlugin	`.plugin/plugin.json`	クライアント依存	`${PLUGIN_ROOT}`

既存形式は即座に廃止されません。VS CodeはClaude形式も読み込めますし、GitHubは既存Copilot pluginに移行を要求していません。したがって、短期的には1.0準拠coreとクライアント固有manifestを併置する期間が生まれます。

実務での設計指針

新規pluginでは、まず処理を3層に分けると移植しやすくなります。

portable knowledge: skills/に手順、判断基準、補助scriptを置く
portable capability: mcp.jsonに明示的なtransportでtool接続を置く
client experience: agents、hooks、commands、rulesをreverse-domain namespaceへ置く

CIでは少なくとも次を検証すべきです。

2つのschema URLが同じspec versionを指す
plugin名が1〜64文字で、小文字英数字・-・.の制約を満たす
各skills/<name>/SKILL.mdがAgent Skills仕様に従う
stdioのpathがplugin root外へescapeしない
remote MCPのURLがHTTPSで、headerにcredentialを含まない
固有機能なしでもSkillとMCPだけで最低限の価値が残る

配布後の運用も要注意です。VS Codeはextensions.autoUpdate有効時、24時間ごとに更新を確認しますが、npmやPyPI由来のpluginは自動更新せず、ユーザーの明示操作を要求します。供給元によって更新モデルが異なるため、versionを上げるだけで全利用者へ同時反映されるとは限りません。

限界と未解決点

Agent Plugins 1.0は、pluginの安全性を認証する仕組みではありません。VS Code公式ドキュメントも、hooksとMCP serversがローカルでcodeを実行し得るため、publisherと内容を確認するよう警告しています。

また、次の限界があります。

portableなのは2 component typeだけで、agent personaやhook semanticsは一致しない
MCP clientはstdioかstreamable-httpの最低1方式だけ対応すれば適合できる
仕様はmarketplaceの審査品質、署名、reputationを統一しない
OAuthやsecret参照のportable fieldはない
clientごとのtool承認UIやsandbox差により、同じMCP serverでも実行結果は同一とは限らない
1.0対応を名乗る全クライアント間での完全な相互運用試験結果は、今回参照した一次資料には示されていない

したがって、「一度作ればどこでも同じ動作」は言い過ぎです。正確には、一度package化すれば、対応クライアントが共通coreを同じ場所から発見できる段階に到達した、と捉えるべきです。

まとめ

Agent Plugins 1.0の本質は、巨大な共通APIではありません。必須2フィールドのmanifest、2種類のportable component、固定探索、局所的なfailure boundary、reverse-domain拡張という小さな契約です。

6機能すべてを標準化しなかったからこそ、SkillsとMCPという価値の中心だけを持ち運び、VS Code、Copilot、その他のクライアントが独自の体験を更新できます。AIエージェントのplugin設計では、共通化の広さより、どこまでを壊れない境界として固定するかが重要になったのです。

参考リンク

GitHub Copilot in VS Code, August 2026 releases（2026-08-31）

Agent plugins in VS Code（2026-09-02参照）

AI settings reference（2026-09-02参照）

Agent Plugins Specification 1.0.0

Agent Plugins 1.0 in VS Code, Copilot CLI, and the Copilot app（2026-08-12）