Claude CodeはなぜAgent Pluginsの初期リストにいない？共通規格1.0.0の正体

結論：排除されたのではなく、先行する別規格を持っている

最初に結論を言うと、Claude CodeがAgent Pluginsから排除されたと判断できる事実はありません。公式資料はAnthropicが初期メンバーにいない理由を説明しておらず、政治的な対立や囲い込みを断定する材料もありません。

理由が未公表であることを前提に、仕様差から考えられる可能性の一つが、Claude Codeはすでに独自のプラグイン配布方式を持ち、その対象範囲がAgent Plugins 1.0.0より広いため、発足時点では新規格の公式互換クライアントになっていない、というものです。言い換えると、仲間外れというより同じ部品を使う別の箱を先に持っていたと見る余地があります。

Agent Plugins 1.0.0とは何か

Agent Plugins公式サイトは、この規格を「AIエージェントを拡張する再利用可能な部品の、持ち運べるパッケージ形式」と位置づけています。狙いは、製品ごとに並べ替えたり複製したりしていた拡張機能を、1つの共通構造で配布できるようにすることです。

my-plugin/
├── plugin.json
├── skills/
│   └── summarize/
│       └── SKILL.md
└── mcp.json

1.0.0が共通化する部品は、現時点では次の2つだけです。

• Agent Skills — エージェントに仕事の進め方や判断基準を教える、SKILL.md中心の手順書
• MCPサーバー — 外部サービスや社内システムの道具をエージェントへ接続する仕組み

つまりAgent Pluginsは、エージェントの全機能を統一する巨大規格ではありません。仕様自身も、配布方法、インストール、権限、画面体験、製品固有の機能は各クライアントの管理下に残すと明記しています。まずSkillsとMCPだけを運べるようにする、小さな共通土台です。

初期リストにいて、Claude Codeはいない

初期のTechnical Steering Committeeには、Amazon、Cursor、Microsoft、OpenAI、VercelのCore Maintainerが参加しています。

また公式の互換クライアント一覧には、VS Code、Cursor、GitHub Copilot、ChatGPT・Codex、Kiro、Hermes Agent、OpenClawが掲載されています。2026年8月11日時点で、どちらにもAnthropicやClaude Codeの名前はありません。

ここで面白いのは、Agent Pluginsが束ねる2つの基礎技術が、いずれもAnthropic発であることです。Agent SkillsはAnthropicが公開したオープン仕様で、MCPもAnthropicが提唱したプロトコルです。部品はAnthropic発、箱の標準化は他社連合が先行という、少しねじれた構図になっています。

Claude Codeには、すでにもっと大きなプラグインの箱がある

Claude Code公式ドキュメントを見ると、Claude Codeのプラグインは .claude-plugin/plugin.json を入口に、SkillsとMCPだけでなく、サブエージェント、hooks、LSP、モニター、実行ファイル、設定まで1つに束ねられます。Agent Plugins 1.0.0が定義する部品より、対象範囲がかなり広いのです。

Skillsの置き場所はどちらも skills/ で、SKILL.mdの基本形式も共通です。しかしマニフェストとMCP設定の住所が違い、Claude Code固有の豊富な部品はそのままでは1.0.0の共通部分になりません。Claude Codeが今後ネイティブ対応する場合、既存形式との互換性や、新しい plugin.json と mcp.json の扱いが論点になると考えられます。

Claude Codeで使えない、という意味ではない

公式互換クライアント一覧にいないことと、共通部品を利用できないことは別です。Claude CodeはAgent SkillsとMCPの両方に対応しており、Vercel自身もVercel Pluginの案内で、同じプラグインをClaude Code、Cursor、Codexで使えると説明しています。変換やインストーラーが間に入れば、実用上は複数製品へ届けられます。

ただし、これはClaude CodeがAgent Plugins 1.0.0のパッケージをネイティブに読み込む公式互換クライアントである、という意味ではありません。部品レベルの互換性とパッケージ規格への準拠は分けて理解する必要があります。

企業が今から備えることは、共通部分と製品固有部分を分けること

企業にとって重要なのは、どの規格が勝つかを当てることではありません。自社で蓄積するAIエージェントの手順と接続設定を、最初から持ち運べる部分と製品固有部分に分けておくことです。

1. 1業務手順はAgent Skillsに寄せる — 判断基準、作業順序、品質条件をSKILL.md中心に書き、特定製品の命令を減らす
2. 2外部接続はMCPを優先する — API連携を製品専用機能へ閉じ込めず、複数エージェントから使える境界を作る
3. 3hooksやサブエージェントは薄い製品別レイヤにする — Claude Code固有の強みは活かしつつ、業務知識の本体をそこへ埋め込まない

この分離ができていれば、将来Claude CodeがAgent Pluginsへ正式対応しても、別の標準が広がっても、移行対象は外側の薄い設定だけです。自社の業務手順そのものは残ります。

Claude CodeのSkillsの作り方とClaude CodeのMCP連携一覧もあわせて読むと、共通部分をどのように作るか具体化できます。

今後見るべき3つの変化

• 公式の互換クライアント一覧へClaude Codeが追加されるか
• Claude Codeがルートの plugin.json と mcp.json をネイティブに読むか
• Agent Pluginsの共通部品が、SkillsとMCP以外へ広がるか

技術憲章は、憲章とプロジェクトの方針を守るすべての人に参加を開いています。現在の不在を最終決定と捉える必要はありません。

むしろ、各社が独自に育てた拡張機能のうち、どこまでが業界共通の資産になっていくかを見るための、最初の節目と捉えるのがよいでしょう。