Claudeプラグインの公開方法|審査と3つの配り方
「自分で作ったClaudeのスキルを、ほかの人にも使ってもらいたい」「でも、どこに出せばいいのか、審査で何を見られるのかが分からない」——スキルやMCPサーバーを作り溜めてきた人ほど、配る段になってこの2つで止まります。
結論から言うと、Claudeのプラグインは、2026年9月25日に開いた開発者ポータル(claude.ai/directory/manage)から、有料プランのアカウントで誰でも公式のディレクトリに申請できます。ただし配り方はディレクトリだけではなく、「ディレクトリ」「自分のマーケットプレイス」「組織内への配布」の3つがあり、誰に使わせたいかで選ぶ経路が変わります。審査で止まるのは中身の良し悪しより、READMEとライセンスの有無、ファイル名、外部パッケージの版の固定、鍵の扱いといった形式の項目です。
株式会社Fyveは、社内で80本を超えるClaude Codeのスキルを毎日動かしていますが、まだ1本も外に配っていません。この記事では、公式ドキュメントをもとにポータルの手順と審査の項目を整理し、手元のスキル1本を実際にプラグインの形に包んで検査にかけた結果と、85フォルダを公式のチェックリストに当てて「配れる・配れない」を数えた結果までを書きます。
Claudeのプラグイン公開ポータルとは|2026年9月25日に開いた申請窓口
Anthropicは2026年9月25日、公式ブログ「Build plugins for Claude with the directory submission portal」で、Claudeのディレクトリ(claude.ai/directory)にプラグインを申請するための開発者ポータルを公開しました。発表の要点は次のとおりです。
- 誰が出せるか:有料のClaudeプラン(Pro・Max・Team・Enterprise)のアカウント。Freeでは申請できない。事前に申し込むパートナー制度はない
- 何を出せるか:GitHubに置いたプラグイン一式(スキル・MCPサーバー・コマンド・エージェント・フックなど)か、リモートのMCPサーバー1つ
- 審査:申請した時点で自動の検証と安全性のスキャンが走り、ポータル上で状態・スキャン結果・推奨される修正を確認できる
- 公開のタイミング:承認されたあと、いつ公開するかは開発者が決められる
- 公開後の数字:インストール数(利用面・版ごと)、掲載ページの表示回数、掲載にたどり着いた検索語
ここでいう「プラグイン」は、スキル(作業の手順を書いた SKILL.md)やMCPコネクター(外部のサービスにつなぐ口)を1つの包みにしたものです。公式ドキュメントの説明では、プラグインは一度追加すれば claude.ai、デスクトップとモバイルのアプリ、Cowork、Claude Code のそれぞれで使えます。ただし、どの部品がどこで読み込まれるかは画面ごとに違い、フックやエージェントはチャット画面では読み込まれません。
プラグイン一式とMCPコネクターの違い
ポータルで「Submit new」を押すと、最初に「何を申請するか」を2択で聞かれます。違いは次の表のとおりです。
項目 | プラグイン一式(Plugin bundle) | MCPコネクター(MCP connector) |
|---|---|---|
中身 | スキル・コマンド・エージェント・フック・MCPサーバーの参照を含むフォルダ | リモートのMCPサーバー1つ |
出どころ | GitHubのリポジトリ(掲載が公開される前に公開リポジトリにする必要がある) | サーバーのURL(リポジトリ不要) |
審査 | 版ごとに自動検証とセキュリティスキャン。新規の掲載は人の審査を通ってから公開 | 自動のポリシースキャンのあと、既定では「Community」として掲載。Anthropicの判断で「Verified」の審査に回ることがある |
公開後の数字 | インストール数・版・スキルとMCPサーバーの実行回数・エラー率 | サーバーの稼働状況・ツールごとの利用・エラーの内訳 |
注意したいのは、スキル単体は申請の種類として存在しないことです。公式ドキュメントにも「Skills aren't a submission type on their own. Put them in a bundle.」とあり、スキルを1本だけ配りたい場合でも、プラグインの形に包んで出します。また、自社のサービスにつなぐリモートのMCPサーバーを持っている場合は、プラグイン一式とは別にコネクターとしても申請するよう案内されています(コネクター側にだけ稼働状況のダッシュボードが付くため)。
Claudeプラグインの配り方は3つ|誰に使わせるかで選ぶ
「プラグインを公開する」と聞くとディレクトリへの申請を思い浮かべますが、公式ドキュメントが並べている配り方は、実際にはもっと広いものです。Claude Code側のドキュメント「Publish and distribute a plugin」と、claude.com側の「Roll out a plugin to your whole organization」を合わせると、次の3つ(+マーケットプレイスを使わない手渡し)に整理できます。
配り方 | 誰が入れられるか | 必要なもの | 審査 | 更新の届き方 |
|---|---|---|---|---|
① Anthropicのディレクトリ | claude.ai・Coworkで追加した人(Claude Codeにもアカウント連携で届く) | GitHubのリポジトリと有料プランのアカウント | あり(自動+人) | 公開した版が自動で届く |
② 自分のマーケットプレイス | リポジトリにアクセスできる人(非公開リポジトリならチーム内だけ) |
| なし | 既定はオフ。利用者が更新するか自動更新を有効にする |
③ 組織内への配布 | TeamまたはEnterpriseの組織のメンバー | 組織設定の「Plugins & skills」、またはClaude Codeの管理設定 | なし(組織の外には出ない) | 既定ブランチへのpushと同期、または管理設定の自動更新 |
(手渡し) | フォルダや.zipを受け取った人 | プラグインのフォルダ | なし | 届かない(送り直し) |

判断の軸はひとつで、「知らない人にも見つけてほしいか」です。見つけてほしいならディレクトリ、知り合いや社内の数人に渡すだけなら自分のマーケットプレイス、会社の全員に同じものを入れたいなら組織内への配布です。ディレクトリに出すと審査の手間がかかる代わりに、掲載ページの表示回数や検索語まで分かるようになります。
自分のマーケットプレイスで配る最小の手順
審査を通さずにチームへ配るなら、②がいちばん軽い方法です。公式ドキュメントの手順をそのまま書くと、プラグインのリポジトリの .claude-plugin/ に plugin.json と並べて次のファイルを置きます。
{
"name": "your-marketplace",
"owner": { "name": "Your Name" },
"plugins": [
{ "name": "deploy-helper", "source": "./" }
]
}使う側は、シェルで claude plugin marketplace add your-org/your-marketplace を一度実行し、claude plugin install deploy-helper@your-marketplace で入れます。リポジトリが非公開なら、そのリポジトリを複製できる人しか入れられないので、マーケットプレイスも非公開になります。申請のフォームはなく、ファイルをpushした時点で「公開」です。
ひとつ注意があります。plugin.json に version を書いた場合、版番号を上げずにpushしても利用者には新しい版が届きません(claude plugin update が「すでに最新」と返す)。版番号を毎回上げるか、Gitで配るマーケットプレイスなら version を書かずにコミットのIDで判定させるか、どちらかに決めておきます。また、Anthropic自身の公式マーケットプレイス(claude-plugins-official)にはこのポータルからは載せられない、とClaude Code側のドキュメントに明記されています。

ディレクトリに出す手順|開発者ポータルの流れ
①のディレクトリに出す場合の流れを、公式ドキュメントの順に並べます。
- 申請できるか確かめる:Pro・Maxは自分のアカウントから申請できる。Team・EnterpriseはOwnerが申請する(EnterpriseはOwnerが「Directory」権限を他のメンバーに渡せる)。掲載は申請した組織のものになり、同じリポジトリのフォルダを別の組織が後から申請すると拒否される
- 手元で形式を検査する:
claude plugin validate --strict ./your-plugin - ポータルで検証する:claude.ai/directory/manage で「Submit new」→「Plugin bundle」→ リポジトリを入力 →「Validate」。止まる項目(Blocking)を直してpushし、「Re-validate」
- 申請する:止まる項目がなくなったら審査に出す
- 状態を追う:ポータルの状態表示で、誰が次に動くかを確認する
- 公開する:承認されたら公開。以後は追跡しているブランチにマージするだけで、新しい版がスキャンされて届く
手順2のローカル検査は、あくまで形式の検査です。公式のチェックリストにも、claude plugin validate は「ファイルが正しい形式か」しか見ず、READMEやライセンスの有無、名前が他と重なっていないかといったディレクトリ側の決まりはポータルの「Validate」でしか分からない、と書かれています。手元で通っても、ポータルで止まることがある前提で進めます。
ポータルに出る状態の意味
プラグイン一式の申請には、次の状態が表示されます。「誰が次に動くか」が分かれば、待つべきか直すべきかで迷いません。
状態 | 意味 | 次に動く人 |
|---|---|---|
Draft | まだAnthropicに送っていない | 自分 |
Scanning | 申請済み。セキュリティスキャンの待ちか実行中 | Anthropic |
Needs changes | 最新の版が通らなかった。何を直すかはプラグインのページに出る | 自分 |
In review | 審査担当者が確認中 | Anthropic |
Approved | 通ったが、まだ公開されていない | カードに書かれた人 |
Published | ディレクトリで公開中 | なし |
Delisted | ディレクトリに表示されていない | 再掲載したいなら自分 |
見落としやすいのが Approved の段階ではまだ誰もインストールできない点です。インストールできるのは Published になってからです。審査にかかる期間は公式に「固定されていない」とされており、目安の日数は示されていません。通らなかった場合は、プラグインのページから「Appeal this decision」で異議を出せます。
Claudeプラグインの審査で止まる項目|事前チェックリストの要点
公式の「Plugin pre-submission checklist」は、検査の結果を4つに分けています。
- Blocks(止まる):直して検証し直すまで申請できない
- Policy hold(人の確認待ち):申請はできるが、審査担当者がその版を読んでから公開される。却下ではない
- Warning(警告):直さなくても申請できる
- Note(情報):直すものはない
項目は多いのですが、スキルを書き溜めてきた人が引っかかりやすいものに絞ると、次の表になります。
項目 | やること | 守らないと |
|---|---|---|
README | プラグインのフォルダに40語以上のREADME(コードブロック内の語は数えない) | 止まる |
ライセンス |
| 止まる |
ファイル名 |
| 止まる |
名前 | 小文字・数字・ハイフンで64文字以内。 | 止まる(一般的な語だけの名前は人の確認待ち) |
フォルダの外 | フックやスクリプトが使うファイルはすべてプラグインのフォルダ内に置く | 止まる |
不要なファイル |
| 止まる |
外部パッケージ |
| 止まる(固定しても人の確認待ちになる) |
鍵 | 本物の鍵をファイルに書かない。 | 止まる |
環境の鍵 | 利用者の環境にある鍵(例: | 人の確認待ち |
ファイルの大きさ | 画像とフォント以外は1ファイル256KiB未満、全体で512ファイル以下 | 人の確認待ち |
加えて、申請後には説明していない動作(データをどこかへ送る、隠れたコードを動かす、Claudeの権限設定を変える)を探すセキュリティスキャンが走ります。最初の申請でこれに落ちると却下です。公式の助言は2つで、プラグインが「何を動かし、何を送り、何を取ってくるか」をREADMEにすべて書くことと、圧縮・難読化したコードではなく読めるソースを置くことです。ただし「READMEに書けば何でも許される」わけではなく、許される範囲は「Anthropic Software Directory Policy」が決める、とも書かれています。
手元のスキル1本をプラグインに包んで検査してみた
文書を読むだけでは引っかかる場所の実感がつかめないので、社内で使っている小さなスキル(gitのコミットメッセージの書式を揃えるだけのもの)を1本選び、プラグインの形に包んで claude plugin validate にかけました。使ったのはClaude Code 2.1.296です。
1回目:名前だけ書いたplugin.json
.claude-plugin/plugin.json に "name" だけを書き、skills/ の下にスキルのフォルダを置いた状態です。結果は「Validation passed with warnings」で、警告は3つでした。
versionがないdescriptionがないauthorがない
同じものを --strict 付きで検査すると、警告がエラー扱いになって「Validation failed」で終わります。CIに組み込むときは --strict を使うよう公式が勧めているので、この3つは最初から書いておくのが無難です。
手元の検査では出なかった問題
このとき、もうひとつ気づいたことがあります。選んだスキルの本文のファイル名が、正しい SKILL.md ではなく小文字の skill.md になっていました。社内では何か月も問題なく動いていたファイルです。ところが手元の検査はこれを指摘しませんでした。macOSのファイルシステムは既定で大文字と小文字を区別しないため、普段の利用でも検査でも目立たなかったのだと考えています。
公式のチェックリストでは、部品のファイル名を決められた綴りと大文字小文字で書くことは「止まる」項目にあたります。私たちはポータルには出していないので、ポータルが実際にこれを止めるかどうかは確かめていません。それでも、手元で通ったことは、ポータルで通る保証にならないという公式の注意書きが、具体的な形で当てはまった例でした。
2回目:直したあと
ファイル名を SKILL.md に直し、plugin.json に次の項目を足しました。名前は予約語や一般的な語だけにならないよう、用途の分かる名前に変えています。
{
"name": "prefixed-commit-helper",
"displayName": "Prefixed Commit Helper",
"version": "0.1.0",
"description": "Create git commits with a consistent prefixed message format.",
"author": { "name": "Example" },
"license": "MIT"
}この状態で --strict 付きの検査は「Validation passed」になりました。ただし、ポータルで必要なREADME(40語以上)はまだ置いていないので、この状態でポータルに出せば止まるはずです。手元の検査とポータルの検査の差は、READMEとライセンスファイルのように「中身ではなく、配る相手のための付属物」に集中している、というのが実際に触ってみた感触です。
85本のスキルを持っていて、1本も配っていない理由
次に、社内のスキル置き場にある85フォルダを、公式のチェックリストの項目で数えてみました。数え方は単純な文字列の検索で、厳密な判定ではありません。
見た項目 | 該当数(85フォルダ中) | チェックリスト上の扱い |
|---|---|---|
READMEがある | 0 | なければ止まる |
ライセンスのファイルがある | 2(どちらも外部から取り込んだもの) | なければ止まる |
本文のファイル名が | 82(小文字の | 綴りが違えば止まる |
スキルのフォルダの外にある社内の資料・スクリプトを参照している | 49 | フックやスクリプトが外を使えば止まる |
環境にある鍵(APIキー等)を読んでいる | 6 | サーバーへ送れば人の確認待ち |
社内の資料も環境の鍵も参照していない | 33(外部から取り込んだものを多く含む) | — |

READMEとライセンスは書けば済むので、本当の壁はそこではありません。壁は49本が社内の資料を参照していることです。私たちのスキルの多くは、「この台帳を読んで」「この規範に従って」と社内の別のファイルを前提に書かれています。社内で使う分には、それが強みです。前提を毎回書かずに済み、規範を1か所直せば全部のスキルに効くからです。しかしプラグインとして配ると、受け取った人の手元にはその資料がありません。公式ドキュメントにも「インストールした人が受け取るのはプラグインのフォルダだけ」とあります。
逆に言えば、配れるスキルは、最初から「1つのフォルダで完結する」ように書いたものだけです。社内の資料を参照していない33本の多くは外部から取り込んだもので、自分たちで書いて完結しているものは少数でした。社内のスキルを配りたくなったら、私たちは次の順で判定しています。
- 他の人の役に立つか:社内の台帳や顧客の情報を前提にした手順は、外に出しても動かない。出す意味があるのは、どの会社でも同じ形で起きる作業(書式を揃える、決まった形式で出力するなど)
- 1つのフォルダで完結するか:社内の資料を参照している箇所を、フォルダ内に写すか、利用者が自分で用意する前提に書き換えられるか
- 鍵を利用者に入れてもらう形にできるか:環境の鍵を読む書き方を、
userConfigで入力させる形に直せるか - 知らない人にも見つけてほしいか:見つけてほしければディレクトリ、知人やチームに渡すだけなら自分のマーケットプレイス
この順で見ると、私たちのスキルのほとんどは1で止まります。社内の仕事の進め方そのものを書いたものだからです。配るために書き直すと、社内での使いやすさが落ちます。だから今は「配るためのスキル」と「社内で使うスキル」を分けて考え、前者を作るときは最初から1つのフォルダで完結するように書く、という方針にしています。
公開したあと|使用状況の数字と更新の届け方
ディレクトリで公開したプラグインには、ポータルに「Usage」タブが付き、インストール数、版ごとの内訳、スキルとMCPサーバーごとの実行回数、エラー率が見られます。発表時のブログでは、掲載ページの表示回数と、掲載にたどり着いた検索語も見られるとされています。
社内で使っているスキルについて、私たちが一番知りたいのは「本当に使われているか」です。社内向けには、Claude Codeの /skill-doctor で各スキルが文脈をどれだけ使い、どれだけ呼ばれたかを確かめられますが、外に配ったものは手元からは見えません。公開後に「どのスキルが何回動いて、どれだけ失敗したか」が分かることは、配る側にとってディレクトリを選ぶ大きな理由になります。
更新は、最初の申請のあとは追跡しているブランチにマージするだけです。ディレクトリがコミットを拾ってスキャンし、公開されると利用者に届きます。ただし、新しい版も毎回スキャンされ、通らない版は公開されません(公開中の版はそのまま残る)。README・ライセンス・版の固定といった項目は、最初の申請だけでなく毎回の更新で守り続ける必要があります。
よくある質問
無料プランでもClaudeのプラグインを申請できますか
できません。申請できるのはPro・Max・Team・Enterpriseのアカウントです。一方、公開されたプラグインを追加して使えるのも有料プランの人です(公式ドキュメント「Build for Claude」の記載)。
審査にはどのくらいかかりますか
公式には「固定されていない」とされ、目安の日数は示されていません。状態はポータルで確認でき、ScanningとIn reviewのあいだはAnthropic側が動く段階です。
ディレクトリに載せずに、社内だけで配れますか
配れます。Claude Codeの利用者だけなら、非公開のGitリポジトリに marketplace.json を置く「自分のマーケットプレイス」で足ります。claude.aiやCoworkの利用者にも届けたいなら、TeamまたはEnterpriseの組織設定から配布できます。どちらも審査はありません。
Claude Marketplaceへの申請はこれとは別ですか
別の申請はありません。公式ドキュメントに、Claude Marketplace(プラグインやコネクターを探すWebサイト)から来た場合もディレクトリに申請すればよい、と書かれています。
以前のClaude Consoleのフォームで申請したものはどうなりますか
既存の掲載はそのまま残りますが、新しい版の配信や使用状況の数字を使うには、開発者ポータルへ移す必要があります。Consoleのフォームでのプラグイン申請は、すでにサポートが終わっています。
関連記事
プラグインに入れる前に、スキルが本当に出力を良くしているかを測る方法はこちらで書いています。
スキルをこれから作る場合は、Anthropic公式の「スキルを作るスキル」から始めるのが近道です。
受け取った側でプラグインがどう読み込まれるかは、こちらにまとめています。
まとめ
- 2026年9月25日、Claudeのディレクトリにプラグインを申請する開発者ポータル(claude.ai/directory/manage)が開いた。有料プランなら誰でも申請でき、パートナー制度への申し込みは要らない
- 申請の種類は「プラグイン一式」と「MCPコネクター」の2つ。スキル単体では申請できず、プラグインに包んで出す
- 配り方はディレクトリ・自分のマーケットプレイス・組織内配布の3つ。「知らない人にも見つけてほしいか」で選ぶ。後の2つは審査なし
- 審査で止まりやすいのは、READMEとライセンスの有無、ファイル名の綴り、外部パッケージの版の固定、鍵の書き方といった形式の項目。手元の
claude plugin validateはその一部しか見ない - 社内向けに書いたスキルは、社内の資料を前提にしているぶん配りにくい。配るなら、最初から1つのフォルダで完結するように書く
スキルやプラグインは、作ることより「どこまで任せ、誰に配るか」を決めるほうに判断が要ります。株式会社Fyveでは、こうしたClaude Codeの運用の決め事を自社で確かめながら、業務に入れる会社の環境づくりもお手伝いしています。
参考にした情報源
- Claude Blog:Build plugins for Claude with the directory submission portal(2026年9月25日)
- Claude Docs:Build for Claude
- Claude Docs:Publish to the directory
- Claude Docs:Plugin pre-submission checklist
- Claude Docs:Track your directory submission
- Claude Docs:Roll out a plugin to your whole organization
- Claude Code Docs:Publish and distribute a plugin
- Unite.AI:Anthropic Opens Directory Submission Portal for Claude Plugins
※2026年10月17日時点の情報です。審査の項目や画面の名前は変わることがあるため、申請の前に最新の公式ドキュメントで確認してください。
Claude Codeを「素のまま」使うな

設定で差がつく——CLAUDE.md・権限・スキルの実物を公開(全24ページ)
素のClaude Codeは"優秀な新入社員"。仕事を教えるほど、自分専用になります。覚えさせる4点セット——会社の説明書(CLAUDE.md)・権限の柵・手順書(スキル)・フォルダの地図——を、1人会社の実運用からコピペで使える型つきで公開します。
- そのまま書き換えて使えるCLAUDE.mdの型
- お金と送信をAIに触らせない「3段階の柵」
- 1回教えたら何度でも動く、手順書のコピペ雛形
- AIが迷子にならないフォルダ構造の3原則
メールアドレス登録で他にも様々な資料を閲覧できます








+8PDF 17点・合計440ページ + すぐ使えるzip素材 3点
どれも登録後の受け取りページから、まとめてダウンロードできます。
毎週配信の無料ニュースレター「AIネイティブ超研究」の購読特典です。メール登録後すぐ、受け取りページのご案内が届きます。そこにはこの資料に加えて、過去の特典もすべてまとめて置いてあります。あわせて、AI活用に関するお知らせやお役に立てそうなご案内をお送りすることがあります。解除はいつでも1クリック。
御社の業務に合わせたClaude Code導入支援
「AIツールを導入したが、現場で使われない」を終わらせる。
業務課題のヒアリングから設計、ハンズオン実践、運用定着まで一貫して支援します。