Agent Plugins 1.0、Anthropicだけ仲間はずれ？ 実際にClaude Codeで動くか検証してみた

はじめに

2026年8月6日、AWS、Microsoft、OpenAI、Vercel、Cursorが「Agent Plugins 1.0.0」という新しいオープン仕様を発表しました。
AIエージェントのスキルとMCPサーバーを、プラットフォームをまたいで持ち運べる形にパッケージ化するための規格です。
発表と同時にGoogleもCore Maintainerとして参加し、VS Code、GitHub Copilot、Cursor、ChatGPT、Kiroにはすでに統合されているとのことでした。

ニュースを追っていて気になったのは、この顔ぶれにAnthropicが入っていないことです。
よく見ると、この仕様のskills/部分は
「Anthropicが作ったAgent Skills仕様に準拠すること」
が要件になっています。
土台を作った会社が、その土台の上に建った標準化団体には入っていない、という状態です。

Anthropicが参加しなかった理由は分かりません。
今回やりたかったのはそこの詮索ではなく、もっと手を動かせる話です。
「参加していない」という状態が、実際どれくらいの実害になるのか？
今日時点でAgent Plugins 1.0.0のパッケージを1つ用意して、Claude Codeで動かそうとしたら、どれだけ苦労するのか。実際に試してみました。

仕様を読んでみる

ニュース記事の要約だけで判断すると痛い目を見ることがあるので、まず本家のリポジトリを見にいきました。

• 仕様書: agentplugins/agent-plugins-spec
• サンプルパッケージ: agentplugins/agent-plugins-example

読んでみると、Agent Plugins 1.0.0のパッケージ構造はかなり最小限に絞られていました。ルートにplugin.json(manifest)、任意でskills/ディレクトリ、任意でmcp.json。plugin.jsonのトップレベルフィールドは$schemaとnameを含めて10個までとスキーマがクローズドになっていて、それ以外のフィールドは弾かれるようです。

skillsの中身は「Agent Skills仕様に準拠すること」とだけ書かれていて、それ以上の独自ルールはありませんでした。
ここを読んだ時点で、もしかしたらそんなに大変な変換にはならないのでは、という予感がありました。

Claude Code側の形式も見てみる

次にClaude Code自身のプラグイン形式のドキュメントを読みました。
こちらも.claude-plugin/plugin.jsonというmanifestを中心に、skills/、.mcp.jsonなどのコンポーネントを持つ構造です。

両方読み終えて並べてみると、差分は拍子抜けするくらい小さいものでした。

manifestのフィールド名(name、version、description、author、homepage、repository、license、keywords)はほぼ共通していて、置き場所がplugin.json(ルート直下)か.claude-plugin/plugin.jsonかが違うだけです。mcp.jsonも同様で、ファイル名がmcp.jsonか.mcp.jsonかの違いしかありません。

一番身構えていたのはMCPサーバーの設定でした。
stdioとHTTP系の2種類のトランスポートがあって、フィールド名がプラットフォームごとに微妙に違う、というのはMCP関連ではよくある話だからです。
ところが実際に見比べると、stdio/streamable-http/sseという型名も、command/args/envやurl/headersというフィールド名も、両方とも同じでした。Claude Codeのドキュメントには「streamable-httpはhttpのエイリアスとして受け付ける」ともあり、向こう側もMCPのエコシステムをちゃんと見て設計しているようです。

結局、本当に違うのは次の3点だけでした。

• manifestの置き場所(plugin.json → .claude-plugin/plugin.json)
• MCP設定ファイルの名前(mcp.json → .mcp.json)
• プレースホルダー変数の名前(${PLUGIN_ROOT} / ${PLUGIN_DATA} → ${CLAUDE_PLUGIN_ROOT} / ${CLAUDE_PLUGIN_DATA})

skills/配下は完全に無変換で使えます。
両方とも同じAgent Skills仕様を参照している以上、当然といえば当然なのですが、実際に仕様書同士を突き合わせて確認できたのは収穫でした。

変換スクリプトを書く

差分が3つだけなら、というわけで標準ライブラリだけで動くPythonスクリプトを書きました。plugin.jsonを読んで.claude-plugin/plugin.jsonとして書き出し、mcp.jsonがあれば中身のプレースホルダーを置換して.mcp.jsonにリネームし、skills/はそのままディレクトリごとコピーするだけの、わりと素朴な作りです。

最初の関門：--strictで一発アウトになった話

変換自体はすんなり動いたのですが、検証で少しびっくりする場面がありました。
公式のサンプルパッケージを変換したあと、claude plugin validateを--strict付きで実行したところ、いきなり終了コード1で失敗したのです。

$ claude plugin validate ./converted-example --strict
⚠ Found 1 warning:
  ❯ author: No author information provided. Consider adding author details for plugin attribution
✘ Validation failed (--strict treats warnings as errors)

一瞬「変換のどこかが壊れているのか」と焦ったのですが、中身を読むと単に「author情報がない」という警告を、--strictが問答無用でエラー扱いにしていただけでした。
サンプルパッケージ自体がauthorフィールドを設定していないので、これは変換の問題ではなく元データの話です。--strictを外して実行し直すとこうなりました。

$ claude plugin validate ./converted-example
⚠ Found 1 warning:
  ❯ author: No author information provided. Consider adding author details for plugin attribution
✔ Validation passed with warnings

--strictは「CIで使う分にはちゃんと仕事をする」フラグで、人間が手元で様子見するときにいきなり使うと驚くことになる、というのが今回の学びです。

実際にロードして使えるか試す

manifestが構文的に妥当というだけでは、まだ「本当に使えるか」の証明にはなりません。
そこで--plugin-dirオプションで実際にセッションにこのプラグインを読み込ませ、Claude Code自身に聞いてみることにしました。

$ claude -p --plugin-dir ./converted-example \
    "Without doing anything else, tell me: do you currently have a skill \
     available named migrate-agent-plugin? Answer in one sentence."

Yes — agent-plugins-example:migrate-agent-plugin is available in this session.

agent-plugins-example:migrate-agent-pluginという名前空間付きでスキルが認識されていました。
ここまで来て、ようやく「動く」と言える状態になったと思います。

念のため、mcp.json側のパス(公式サンプルには入っていなかった)も確認したかったので、stdioサーバーとstreamable-httpサーバーを1つずつ持つ小さなパッケージを自分で書いて変換してみました。${PLUGIN_ROOT}や${PLUGIN_DATA}をcommand・args・env・cwdのあちこちに仕込んでおいたのですが、変換後はすべて${CLAUDE_PLUGIN_ROOT}・${CLAUDE_PLUGIN_DATA}に置き換わっていて、こちらもclaude plugin validateを通りました。

この検証で分かったこと、分からなかったこと

Agent Plugins 1.0.0の仕様書自身が、配布の仕組みや来歴検証(provenance)、権限モデルをスコープ外だと明言しています。
各プラットフォームがその上に独自のマーケットプレイスとセキュリティ層を積む前提の設計です。

今回試したのはあくまで「ポータブルな核の部分(スキルとMCPサーバー)が本当に移植可能か」という一点で、その上に乗る5社それぞれのマーケットプレイスが将来的にオープンなまま保たれるのか、それとも結局バラバラのウォールド・ガーデンになっていくのかは、この検証だけでは何も言えません。
そこは今回あえて踏み込みませんでした。

分かったのは、今日この瞬間においては、「Anthropicが参加していない」という状態のコストがほぼゼロだったということです。理由は単純で、Claude Codeが最初から使っているAgent Skills仕様そのものが、この新しい標準の土台になっているからだと思われます。参加していなくても、土台を作った側が結果的に一番互換性のある位置にいた、という少し皮肉な結果になりました。

おわりに

標準化の話は往々にして「誰が参加したか」というポリティクスの話に寄りがちですが、今回は実際にファイルを動かして確かめられる範囲がはっきりしていたので、手を動かして白黒つけるタイプの検証としてはやりやすいネタでした。

最後まで読んでいただきありがとうございました。