結論：validateは構造確認、導入可否は別の判断
Claude Code 2.1.289では、marketplace manifestも同じfolderにあるpluginでclaude plugin validateがpluginを飛ばしてしまう問題が修正されました。修正後は検証が動くようになりますが、validateの成功は配布元・権限・MCP・hooks・更新経路まで安全だと証明するものではありません。
一次情報は公式changelog、Plugins overview、plugin marketplaces公式資料です。Plugins overviewはpluginをskills、agents、hooks、MCPなどのcomponentを一単位で配布する仕組みと説明し、marketplace資料はcatalogとsourceを管理します。既存のarchive配布やplugin-dirの動的読み込みとは異なり、本稿はvalidateを入口に導入審査を分離します。
plugin.jsonとmarketplace manifestの違い
| 対象 | 役割 | 確認すること |
|---|---|---|
.claude-plugin/plugin.json | 個別pluginのname、version、descriptionなど | 必須項目、componentsの配置、version更新 |
| marketplace manifest | catalog内のpluginと取得source | URL、Git・archive、SHA、credential、更新責任 |
| component | skill、agent、hook、MCP、modなどの実行単位 | prompt、tool、外部通信、権限、context負荷 |
| validate結果 | 構造・形式の検証結果 | 導入審査、運用監査、rollbackとは分離 |
一つのfolderへcatalogのmanifestとpluginのmanifestが同居すると、検証対象の取り違えが起きやすくなります。公式修正はその判定を扱いますが、会社側ではrepository、marketplace、plugin rootを台帳の別欄にし、誰がどのsourceを検証したかを残します。
8手順でvalidateと導入審査を分ける
- Claude Codeのversion、
claude plugin validateの実行場所、対象revisionを記録します。 - marketplace manifestとplugin rootを別の作業directoryへ展開します。
.claude-plugin/plugin.jsonのname、version、description、componentsを確認します。- marketplace側のsource URL、取得方式、SHA、credential、更新責任者を台帳にします。
- 2.1.289以上でvalidateを実行し、同じfolderにmarketplace manifestがあるケースも再現します。
- skill・agent・hook・MCP・modを一覧化し、外部通信、ファイル、shell、context負荷を確認します。
- project、user、managedのscopeごとに、誰へ有効になるかとpermission promptを確認します。
- 不合格時の停止、承認、version固定、rollback、再検証日を決めてからmarketplaceへ公開します。
検証時にpluginのhookを本番repositoryへ実行しません。componentを無効化したsandbox用projectでvalidateと起動確認を行い、ログへtokenや社内pathを残さないようにします。更新後は以前のSHAと比較し、差分があるのにversionが変わらない場合を停止条件にします。
配布方式を比較する
| 方式 | 利点 | 運用上の論点 |
|---|---|---|
| local folder | 開発中の修正を速く試せる | sourceが個人端末に散り、再現性が弱い |
| Git source | revisionとreviewを結び付けられる | credential、branch、SHA固定、停止手順が必要 |
| archive | 配布物を固定しやすい | root位置、size、digest、更新versionを管理する |
| marketplace | catalogと複数pluginをまとめられる | catalog変更と個別plugin変更を分けて監査する |
公式資料で確認できる形式上の条件と、社内の安全基準は分けます。sourceにSHAがあるから悪意あるcomponentがないとは限らず、hooksやMCPがどのデータを扱うかをレビューします。pluginを有効にするとskillやagentの説明がcontextへ載り、MCP serverやhookがsessionで動くため、品質だけでなく利用量・権限・外部接続の影響も見積もります。
導入前チェックリスト
- 2.1.289以上でvalidateを実行した
- plugin.jsonとmarketplace manifestの役割を分けた
- source URL、revision、SHA、versionを記録した
- skill、agent、hook、MCP、modを一覧化した
- permission、外部通信、file、shellの範囲を確認した
- local・project・managedの適用scopeを確認した
- 更新、停止、rollback、再検証の担当者が決まっている
企業導入では「validateが通ったpluginを全員へ配る」前に、試験利用者を限定し、context負荷と実行ログを観察します。marketplaceを変更できる人と、導入を承認する人を分け、変更差分がない更新だけを自動適用するルールは置かない方が説明しやすい場合があります。例外は期限と解除条件を持たせます。
FAQ
- plugin.jsonとmarketplace manifestは同じファイルですか？
- 通常は役割が異なります。plugin.jsonは個別pluginの情報、marketplace manifestはcatalogとsourceの情報です。同居する構成では対象を分けて検証します。
- validateが失敗したらpluginを修正してよいですか？
- まず原本のrevisionと失敗ログを保全します。修正はbranchで行い、version・SHA・review・再検証を記録してから配布します。
- pluginの安全運用を無料診断できますか？
- できます。source、component、権限、外部通信、context負荷、rollbackを無料診断（60秒）で整理します。
pluginの審査では、形式エラーを直すことと、組織の業務で使ってよいことを混同しないようにします。validateの出力、sourceのhash、component一覧、承認記録を一つのrelease packetにし、再現可能なsandboxで確認します。公式資料にない安全保証や料金削減率は記載せず、契約と利用量は自社のprovider条件で別途確認します。
2.1.289の修正は、検証が抜ける条件を減らすための更新です。これを機会にmarketplaceのcatalog、個別plugin、実行component、適用scopeを分けて管理すれば、導入判断と障害時のrollbackを同じ手順で再利用できます。