Claude プラグインを公式ディレクトリに出す手順

2026年9月25日、Anthropic は Claude directory（ディレクトリ）向けの directory submission portal（開発者ポータル）を公開しました。有料プランの開発者は、パートナープログラムへの事前申請なしで、GitHub 上のプラグイン一式（plugin bundle）か、人が接続するリモートの Model Context Protocol（MCP）サーバー（MCP connector）を、開発者ポータルから提出できます。提出のあと、レビュー状況を追い、承認後の設定に従って公開し、公開後の利用状況を見られます。

ここに記載した内容は、その日の公式ブログおよび提出・公開に関する英語の公式ドキュメントで公開されている情報に基づいています。公式ブログでは、Plugins は MCP connectors と Agent Skills（またはその両方）をまとめたもので、Claude 向けサードパーティ拡張の主な作り方として位置づけられています。承認されると Claude directory に載ります。同じブログは、中核の仕様を一般に MCP 2.0 と呼び、2026年7月28日版の仕様を指しています。プラグイン体験に関係する拡張として、MCP Appsと Enterprise Managed Authの名前も挙がっています。仕様書の中身はこの記事では扱いません。

提出で迷うケースは、次の表から節へ飛んでください。

こんなときはこの節へ

こんなとき読む節
Free で出せるか、Team では誰が出すかを知りたい誰が出せるか
plugin bundle と remote MCP のどちらを出すか迷っている何を出せるか
ディレクトリ、/plugin のマーケットプレイス、claude.com/marketplace を一つにまとめそうディレクトリとマーケットプレイスの違い
claude-plugins-official にこのポータルから出したいディレクトリとマーケットプレイスの違い
画面をどの順に進むか、private のまま出せるか知りたい提出の段取り
既存の掲載を、今すぐプラグインへ作り替えないといけないと思っているディレクトリとマーケットプレイスの違い
Validate の Blocks や Policy hold の意味が分からないValidate の結果
承認後に誰が公開するか、auto-publish がいつ効くか知りたい公開の仕方
公開後に何が見えるか知りたい。ブログの図の数字を実数と書きそう公開後の Usage
チャットでは hooks が動かない、という困りごとを避けたいコンポーネントが動く場所
名前、README、ライセンス、ピン、秘密情報で止まりそう提出前チェックリスト
スクリーンショットを用意しないといけないと思っているスクリーンショット
安全面や、金銭取引のように載らない用途を確認したい提出時に守るポリシー

誰が出せるか

提出できるプランは Pro、Max、Team、Enterprise です。Free では提出できません。公式ブログは “developers on paid Claude plans” とだけ書いており、ディレクトリへの公開手順がこの 4 つを具体的にしています。料金の額やプランの優劣は、参照した出典にはありません。

役割はプランで分かれます。Pro と Max は、自分のアカウントから出します。役割の確認はありません。Team と Enterprise は、Owner が出します。Enterprise では、Owner が Organization settings、その中の Roles にあるカスタムロールで、Directory 権限を他のメンバーに渡せます。

パートナープログラムへ先に申し込む必要はありません。掲載は、提出した claude.ai の組織に属します。plugin bundle では、同じリポジトリのフォルダを先に出した組織が掲載を持ちます。別の組織からの再提出は、ポータルが拒みます。長く掲載を持つ組織から出してください。

GitHub アカウントは、提出するその組織の claude.ai に接続します。別の組織で接続したものは引き継がれません。ポータルは、そのアカウントがリポジトリに push できるかを GitHub に問い合わせます。公開リポジトリの Validate 自体は、この確認をしません。そのため、Validate は通っても、作成や提出で止まることがあります。

ディレクトリのプラグインを Discover で見るのも、Pro、Max、Team、Enterprise です。Team と Enterprise では、Owner が組織のソースから directory を外せます。

何を出せるか

ポータルの “What would you like to submit?” で、次のどちらかを選びます。手順の入口は Publish to the directory と Submit your plugin です。

plugin bundle は、skills、commands、agents、hooks、MCP サーバー参照を含むプラグインフォルダです。組み合わせは自由です。出典は GitHub リポジトリです。公開前は private のままでも、検証と提出はできます。掲載が live になる前には、public が必須です。載り方は、コンポーネントをまとめたプラグインです。directory は、プラグインを github.com のリポジトリから読みます。

MCP connector は、人が接続するリモート MCP サーバー 1 つです。出典はサーバーの URL で、リポジトリは要りません。載り方は、ディレクトリから接続するコネクタです。

自分でリモート MCP を動かしているなら、プラグインがそれを参照していても、コネクタとしても別に提出します。同じ組織から両方出すと、掲載を pair できます。コネクタ側にだけ、ツール単位の health と usage のダッシュボードがあります。プラグインの Usage タブは、そこまでは分解しません。

Skills だけの提出種別はありません。bundle に入れます。Desktop extension（ローカル MCP を MCPB として載せる形）は deprecated です。directory は、MCPB の新規受付をしません。ローカル MCP は、plugin bundle に含めて配ります。

1 つのリポジトリに複数のプラグインがあるときは、フォルダごとに提出します。1 つの組織につき、リポジトリとフォルダの組み合わせは 1 提出です。続きは Submissions から開きます。提出したあと、リポジトリとフォルダは変えられません。変えるなら、新規提出です。他の組織が同じ組み合わせを出していると、“Already submitted by another organization” と出ます。自組織がリポジトリを所有するなら、directory@anthropic.com に連絡します。以前の Console 提出が残っている場合は、移行手順に従います。

組織は、24 時間に最大 10 件まで提出を作れます。保存した下書きと、取り下げ（withdraw）も、この数に入ります。上限のときは “Daily submission limit reached” と出ます。

以前の Claude Console のプラグイン提出フォームは、もうサポートされません。Withdraw ボタンがあるものは、取り下げてからポータルで出し直します。ボタンがないものは、directory@anthropic.com に移してもらいます。ポータルに同じリポジトリとフォルダの下書きがあるなら、先にその下書きを消します。移すと、新版のスキャンと公開、ステータス、公開後の利用数字が付きます。古いフォームの URL を、今の手順としては書きません。

コネクタのステータスは、プラグインとは別表です。名前は Draft、In review、Changes requested、Not approved、Approved、Published です。既定では、自動スキャンのあと Community connector として載り、人のレビューは一部だけです。Verified の別申請はありません。この記事の主題はプラグイン提出なので、コネクタフォームの全項目は書き切りません。コネクタ側の手順は Submit a connector を見てください。

ディレクトリとマーケットプレイスの違い

名前が似ていても、別のものです。一つにまとめないでください。根拠は Claude Code のマーケットプレイス説明、公開と配布、プラグイン概要 です。

呼び方何かどう出すか
Anthropic’s directory / Claude directoryclaude.ai 上のカタログです。人がプラグインとコネクタをブラウズします開発者ポータルから提出します。別の「Claude Marketplace 申請」はありません。Marketplace のサイトから来た人も、directory に提出します
Claude Marketplace（ウェブサイト）claude.com/marketplace です。プラグイン、コネクタ、パートナー製品、サービスパートナーを見る場所です/plugin marketplace add で追加する marketplace ではありません。リストの入口は directory への提出です
Plugin marketplace（Claude Code）.claude-plugin/marketplace.json があるリポジトリです。プラグインの取得先を並べたカタログです。ホストされたストアではありません自分の git リポジトリを公開すれば、提出フォームなしで配れます。Claude Code では /plugin と name@marketplace を使います
claude-plugins-officialAnthropic の official marketplace です。リポジトリは anthropics/claude-plugins-official です。対話セッションの初回に、Claude Code が追加します。管理ポリシーなどで止まる場合もありますこの directory ポータル経由の提出は受け付けません。公式マーケットプレイスへの掲載は、Anthropic のパートナー窓口に聞きます
claude-communitycommunity marketplace です。リポジトリは anthropics/claude-plugins-community です。著者が Anthropic に提出したサードパーティプラグインが入りますユーザーが /plugin marketplace add anthropics/claude-plugins-community で追加します。名前はリポジトリ名ではなく claude-community です
claude-code-pluginsdemo marketplace です。リポジトリは anthropics/claude-code です/plugin marketplace add anthropics/claude-code で追加します。公式マーケットプレイスではありません
自分の marketplace / 組織配布チームや全社向けの配り方です公開ディレクトリに出さずに配る別ルートです。組織設定や managed settings を使います

公式ドキュメントでは、Anthropic’s directory は、上の Claude Code marketplace 群とは別です。directory は claude.ai 上のカタログです。Claude Code のプラグイン概要も、plugin marketplace は Claude Marketplace ではない、と分けています。

claude.ai で directory から追加したプラグインは、アカウント同期で Claude Code に届き、@synced として読み込まれます。Claude Code のコマンドラインだけで入れたプラグインは、そのマシンに残り、claude.ai のアカウントには追加されません。2026年9月25日以降の自己申請が、community marketplace の marketplace.json に入るのか、directory からの @synced だけなのかは、公式が同一視していないので、ここでは断定しません。ユーザー向けに文書化されている届き方は、claude.ai または Cowork で追加し、Claude Code はアカウント同期で @synced を受け取る、という経路です。

公式ブログは、今後数週間で Claude と Claude Code に一つの発見体験が広がる、としています。Skills と MCP connectors は部品のままで、directory はそれらを載せ続けます。既存の skill、connector、plugin の掲載は、変更不要です。将来は、connector の掲載を plugin に変えられます。この「一つの発見体験」が揃った日は、未確認です。

Claude Code で directory を見るコマンドは、プラットフォーム対応表にある /plugin directory です。Claude Code v2.1.287 以降です。Discover タブは、追加済み marketplace のプラグインを出します。ウェブの Claude Marketplace は install 数を示し、一部に Anthropic verified の印があります。verified の判定の詳細はコネクタ検証側にあり、プラグインの公式マーケットプレイス掲載と directory 掲載を、同じバッジとしては書きません。directory の公開ページでは、コネクタについて、Verified の別申請はなく、レビュー中に Anthropic が決める、とあります。

提出の段取り

ここからは plugin bundle の画面順です。根拠は Submit your plugin です。レビューにかかる時間は、固定されていません。

  1. Submit new から Plugin bundle を選びます。
  2. Source に Repository を入れます。URL でも owner/repo でも構いません。フォルダのリンクを貼ると、path と branch が入ります。Plugin path は、.claude-plugin/plugin.json があるフォルダです。ルートなら空で構いません。Branch or tag は任意です。空ならデフォルトブランチです。ポータルは、これを tracked branch or tag と呼びます。タグは、付け替えるまでそのコミットを指します。ブランチ名にスラッシュがあるときは、フィールドに打つか、owner/repo@branch と書きます。
  3. Validate を実行します。結果は、読んだ 1 コミットだけに効きます。push したら、再検証します。Blocking を直してから先へ進みます。結果の意味は Validate の結果 にまとめています。
  4. Listing details に進みます。表示は plugin.json と README から読みます。出す前に変えるなら、リポジトリを直して再検証します。掲載後の name と短い説明は、live な版に従います。変えるには、ファイルを直して新版を公開します。
  5. Data handling では、個人データを読むか保存するか、宣言したコネクタ以外へデータを送るか、保持期間、18 歳未満向けか、を答えます。
  6. Compliance では、Anthropic が連絡できるメールを確認し、acknowledgement を 4 つすべて選びます。4 つの文言そのものは、取得した提出ページに列挙されておらず、未確認です。
  7. Review and submit で内容を確認します。新版の届き方は、デフォルトの “GitHub push webhook” か、“Scheduled check only” です。どちらでも、tracked branch または tag は、スケジュールでも確認されます。Submit for review を押します。webhook を残した場合は、提出後のページで Set up push updates を行います。GitHub で、そのリポジトリの admin が必要です。あとから Settings の Updates でも設定できます。

private リポジトリでは、レビュー開始前にコードを公開しなくて構いません。directory は private のままスキャンします。公開と再掲載には、public が必要です。条件は 3 つです。接続した GitHub が push できること、ソースを Anthropic にアップロードし、自動スキャンとレビュー担当が見ることに同意すること（表示は “This repository is private.”）、Claude GitHub App がそのリポジトリに入り、提出組織に接続されていることです。同意の前は、見えない人に対して存在を確認せず、“Couldn’t find that repository, branch, tag, or commit” になることがあります。public にしたあと、プラグインページで Check for new commits を押します。それまでは “Publishing needs a public repository” です。

Submit for review を押すと、tracked branch または tag の最新コミットをスキャンします。中身は、ディレクトリ規則の再検証と security scan です。Versions タブに、コミットごとの結果が出ます。最新版が live でない理由は、プラグインページに出ます。

スキャンのあと、状態は次のとおりです。すべてのチェックを通過すると、公開できます。Held for a reviewer のときは、人が読み、クリアするまで live になりません。hold は拒否ではありません。通過しないときは、満たしていない規則が出ます。セキュリティスキャンが失敗し、記録があれば、カテゴリが出ます。例は “Sends data to an undisclosed destination” です。取得できないスキャン、または結果なしで終わったスキャンは、再試行かリポジトリ修正かがページに出ます。修正後は Check for new commits を押します。

拒否（rejected）と、通過しないだけの違いは、次のとおりです。拒否では、版が承認されなかった、と出ます。Review タブに Resubmit for review が出るのは、拒否された提出だけです。拒否になるのは、レビュー担当の判断か、一度も公開されていないプラグインのセキュリティスキャン失敗です。拒否のあと、スキャンは止まります。Requested changes を読み、直して push し、Resubmit for review を押します。全チェックが再実行されます。拒否ではないときは、tracked branch に修正を push し、Check for new commits を押します。押さないと、次の定期確認まで待ちます。

提出後のステータスは、プラグイン名の横に出ます。意味は Track your directory submission に沿っています。

  • Draft は、まだ Anthropic に送っていない状態です。自分で Continue submission から続けます。
  • Scanning は、セキュリティスキャンの待ち、または実行中です。Anthropic 側や GitHub 側の失敗は、directory が再試行します。次に動くのは Anthropic です。
  • Needs changes は、最新版が落ちたか、取得または受理できなかった状態です。何を変えるかはページに出ます。次に動くのは自分です。
  • In review は、人が掲載を見ている状態です。hold のときはカテゴリ名が出ます。次に動くのは Anthropic です。
  • Approved は、通過したが、まだ live ではない状態です。誰が公開するかはカードに出ます。次に動くのは、カードが名指しした人です。Approved は、インストールできることを意味しません。インストールできるのは Published だけです。
  • Published は、ある版が directory で live な状態です。新しい版のスキャン、レビュー待ち、不合格もカードに出ます。不合格の新版は、公開中の版を落としません。新版が要修正と書いていない限り、誰も動かさなくて構いません。
  • Not live yet は、published 扱いですが、まだ載っていない状態です。directory チームが載せます。次に動くのは Anthropic です。
  • Delisted は、見えない状態です。Relist plugin で戻す依頼をします。
  • Withdrawn は、レビューも掲載もない状態です。

連絡先は、プラグインならポータルのメニュー Get help または Contact Anthropic です。不承認なら Appeal this decision があります。メールは directory@anthropic.com で、返信は遅れることがあります。コネクタは mcp-review@anthropic.com です。名前、提出組織、ポータルのステータスを書きます。Scanning と In review は、Anthropic 待ちです。

Validate の結果

ポータルの Validate は、ローカルの claude plugin validate より検査が多いです。ローカルコマンドは整形の確認です。README、ライセンス、名前の取り合いなどの directory 要件は、ポータルの Validate が見ます。根拠は Plugin pre-submission checklist と提出ページです。

結果の意味は、次のとおりです。

  • Blocks（レポートでは Blocking）は、直して再検証するまで提出できない結果です。
  • Held for a reviewer（Policy hold）は、提出はできる結果です。live の前に人が読みます。拒否ではありません。新版でも、同じ hold が付くことがあります。
  • Warning は、直さなくても提出できる結果です。Software Directory Policy は、別に守ります。
  • Note は、情報だけです。
  • Validation stops は、レポートの前に 1 つのエラーで止まる結果です。例は “Couldn’t validate that repository” と “Repository too large to validate” です。

Claude Code がある場合、ローカル確認は任意です。コマンドラインインターフェース（CLI）から、次を実行します。

claude plugin validate ./your-plugin

問題がなければ ✔ Validation passed と出ます。Claude Code の公開ガイドは、リリース前に claude plugin validate --strict ./your-plugin も勧めています。--strict は、警告（未知フィールドや version の欠如など）も失敗にします。version を意図して省略するなら、--strict を外します。

ポータルでは、Submit new、Plugin bundle、Source の入力、Validate の順です。Blocks を直し、push して、同じフォームの Source で Re-validate します。Blocks が消えたら、提出へ進みます。個々の検査項目は 提出前チェックリスト に置いています。

公開の仕方

公開の既定は、人が各版を公開する設定です。提出画面で選べるのは、次の 3 つです。

  • An Anthropic reviewer publishes each version がデフォルトです。通過後に自分が Publish を押し、レビュー担当が公開します。
  • The reviewer publishes only the first version では、初回は自分の Publish のあと、担当が公開します。以降の通過版は、auto-publish を切っておらず、レビュー待ちでもないときに、自分で live になります。
  • You publish the first version は、承認時に担当がこの設定にできます。初回は自分の Publish で live になります。以降は、上と同様です。

Auto-publish passing versions は、提出画面で設定します。提出後は、Settings の “Publish new versions automatically” です。担当が毎版公開する間は、auto-publish は効きません。Overview の Auto-publish 行が、自分のプラグインにどの設定が付いているかを示します。

公式ブログの “Once approved, you decide when to publish” は、ドキュメントの既定（担当が各版を公開する）より短い説明です。この記事の手順は、ドキュメント側を主にしています。

更新は、初回以降、tracked branch へマージすれば、directory が拾い、検査し、公開設定に従って出します。タグを追っているなら、タグを動かします。plugin.json に version があるなら、リリースごとに上げます。webhook があれば push のときにも確認し、なくても定期確認はあります。不合格や hold の新版のあいだは、最後に公開された版を配り続けます。新版のセキュリティスキャンが失敗したあとは、担当がクリアするまで、後続の版も待ちます。tracked branch または tag の変更は Settings です。レビュー中は変更できません。変更すると、待ちの公開依頼は取り消され、live の版はそのまま残ります。

取り下げと非掲載は、状態で操作が分かれます。

  • 未提出の下書きは、Delete draft で消します。
  • レビュー中で未公開のものは、Withdraw submission です。スキャンとレビューから外れ、何も公開されません。同じリポジトリとパスで再提出すると、開き直します。取り下げは、24 時間 10 件の数に入ったままです。
  • live のものは、ヘッダメニューの Delist plugin です。各 Claude アプリへの反映には、時間がかかることがあります。既にインストールされたものは更新が止まり、コピーが消えることがあります。pending のあいだは Delist requested です。
  • 戻すときは Relist plugin です。即時ではなく、directory が直接戻すか、担当に回します。断られることがあります。

公開後の Usage

場所は、開発者ポータルにある、公開済みプラグインの Usage タブです。提出できる人に開いています。中身は Manage your listing after publishing に書かれています。コネクタのダッシュボード（健康やツール別利用）は別ページで、このタブと混ぜません。組織内の利用（Customize、その中の Plugins にある Adoption と Activity。Team と Enterprise）も、提出者向け Usage タブとは別の画面です。

見られる範囲と項目は、次のとおりです。

  • 期間は、選んだ範囲で最大 90 日です。カンマ区切りの値（CSV）でエクスポートできます。
  • Reach は、installs、active accounts、retention です。install は surface 別、および流入別です。流入の例は Discover タブです。
  • Versions は、各版を使っているアカウントの割合です。
  • Components は、skill、command、agent、hook、MCP server それぞれの利用頻度です。
  • Quality は、Claude Code の版ごとの load errors です。MCP server ごとに、tool calls、error rate、latency があります。
  • Directory funnel は、listing views、install clicks、installs です。
  • 集計は 1 日 1 回、協定世界時（UTC）です。タブには、データの時点の日付が出ます。
  • 利用が記録されるまでは Preview で、サンプル数字が出ます。サンプルは実測ではありません。

公式ブログは、製品面と版ごとの installs、掲載が何回見られたか、どの検索から来たか、とも書いています。図のキャプションは “Data is illustrative.” です。図の数字は、実測として扱いません。検索語句の内訳は、Usage タブの公式リスト（views、clicks、installs）には出ていません。ブログの “which searches” がタブのどの列に対応するかは、未確認です。

掲載の name と短い説明は、live 版の plugin.json と README です。レビュー担当がどちらかを直していたら、その文が残ります。Settings で変えられるのは、載せる surface、連絡メール、ユーザーデータを集めるか送るかの回答です。コネクタのように、ダッシュボードで説明文を直接編集する、とは書いてありません。

コネクタのスラッグは、公開後に固定で、URL は https://claude.ai/directory/connectors/SLUG です。プラグイン掲載の URL の形は、取得した公開後のページではコネクタの形しか書いておらず、未確認です。

コンポーネントが動く場所

チャットだけで動く、と約束しないでください。公式ブログは、Claude Code ではプラグインに言語サーバープロトコル（LSP）、commands、hooks、agents も含められる、と書いています。対応は Plugin feature support の表です。表の HTTP はウェブの通信方式、SSE は Server-Sent Events です。提出時、ポータルはプラットフォーム対応の規則から、動く場所を出し、提出前に見せます。

コンポーネントChatCoworkClaude Code
Skills読みます読みます読みます
Commandsスキルとして読みます/plugin-name:command です読みます
Agents無視します読みます読みます
Hooks無視します読みます読みます
リモート MCP（固定 URL の HTTP、または SSE）Connectors タブに出ます。追加して接続したあと動きます読みます読みます
ローカル MCP（アプリが起動するコマンド。.mcpb を含みます）無視します。ウェブのタブでは “Runs in each session” と出ます自分のコンピュータで動く Cowork セッションでは読みます読みます
${user_config.*} を参照する MCPURL に参照があると無視しますデフォルトの無いオプションは無視します。Cowork は値を聞きません読み、値を聞きます
トップの bin/インストールできませんインストールできません読みます
LSP、output styles、themes、settings無視します無視します読みます
mod（hooks/hooks.json の modules）directory は Claude Code 向けに載せますdirectory は Claude Code 向けに載せます動きます

配置のよくある誤りは、commands/、agents/、skills/、hooks/ を .claude-plugin/ の中に置くことです。.claude-plugin/ に置くのは plugin.json だけです。他はプラグインのルートに置きます。

提出時に守るポリシー

すべての版に、自動検証とセキュリティスキャンがあります。新規掲載は、live の前に人が見ます。初回のスキャン失敗は拒否です。スキャンが見る例は、開示していない送信、隠れたコード、権限設定の変更です。

提出は、Software Directory Terms と Software Directory Policy に従います。Terms は Anthropic Software Directory Terms です。提出ページが遵守を求めています。Policy はヘルプセンター版で、ページの日付は 2026年4月15日です。本文は Anthropic Software Directory Policy を参照してください。ポリシーは、将来の変更も含めて守る、と書いています。

Policy の開発者要件のうち、ポータルのプラグイン項目一覧には無いが、Directory 全体に掛かるものは、次のとおりです。

  • ユーザーデータ収集やリモート接続では、プライバシーポリシーが要ります。
  • 確認できる連絡先とサポートが要ります。
  • 動作、目的、トラブルシュートの文書が要ります。
  • Anthropic が機能を確認できるテストアカウントとサンプルデータが要ります。
  • 中核機能の動くプロンプト例が、少なくとも 3 つ要ります。
  • エンドポイント、ドメイン、ユーザーインターフェース（UI）の所有が要ります。例外として、プラグインは、Software Directory で承認された Connector に接続してよい、とあります。
  • 合理的な期間での保守が要ります。
  • Terms と、公開されたデザイン指針への同意が要ります。

安全面では、次が禁止です。Usage Policy 違反の助長、ガードレールやシステム指示やサンドボックスの回避、機能に必要な範囲を超える会話データの収集（ログ目的でも）、メモリ、チャット履歴、会話要約、ユーザーファイルからの抽出、隠れた指示、難読化された指示、符号化された指示、外部から振る舞いの指示を動的に引いて実行させることです。

書面で明示の許可がない限り、非対応なのは次です。金銭、暗号資産、金融取引の実行です。AI による画像、動画、音声の生成を主とするものです。スライドや図などのデザイン支援で画像を出すものは、単体の画像生成サービスでなければよい、とポリシーにあります。広告、スポンサード、有料掲載が主のものも非対応です。

MCP の追加要件（ポリシー第 5 節）は、プラグインが参照するリモートサーバーに掛かります。ツール名は 64 文字以内です。readOnlyHint、destructiveHint、title があります。リモートで認証するなら、認識された認証局の証明書付き OAuth 2.0（外部サービスへサインインさせる認可の仕組み）です。Streamable HTTP が推奨で、SSE（Server-Sent Events）は当面使えますが、将来は非推奨になります。日付は書かれていません。

使う人向けの信頼警告は、出す側の審査とは別です。Claude Code の文書は、公式マーケットプレイスでも同じ文を出します。インストール、更新、利用の前にプラグインを信頼するよう求め、Anthropic はプラグインに含まれる MCP サーバーやファイルやその他のソフトウェアを管理せず、意図どおり動くことや、あとから変わらないことを検証できない、としています。根拠は Plugin security and trust です。プラグインはユーザー権限で任意のコードを実行し得ます。対象は hooks、mods、stdio の MCP、bin/、そして指示としてコンテキストに入るスキルです。hooks やサーバープロセスは、サンドボックスの外です。自動更新で、レビューしたファイルが変わり得ます。claude.ai のプラグイン概要も、directory の審査は marketplace の URL や自分でアップロードしたものには及ばないので、信頼できるソースだけを使う、と書いています。

提出前チェックリスト

この節の項目は、Plugin pre-submission checklist に載っている検査です。ポータルの Validate で Blocks を消してから提出します。チャットや Cowork で自分から追加する marketplace の上限は、ここにある directory 提出の検証上限とは別の表です。混同しないでください。そちらの数字は、公式ドキュメントを参照してください。

リポジトリとフォルダ

提出物は、.claude-plugin/plugin.json があるフォルダです。どこにも plugin.json がなく、skills/<name>/SKILL.md が 1 つ以上あるフォルダは、Note 付きで通り、Claude Code 専用として載ります。これは例外です。

marketplace リポジトリに複数のプラグインがあるときは、フォルダごとに検証し、提出します。Submit for review のときのタイトル例 “Pick one plugin first” は Blocks です。

hook、MCP の command、スクリプトが使うファイルと、plugin.json のコンポーネントパスは、プラグインフォルダの中に置きます。外を指すパスは Blocks です。読み込むものは、通常のファイルとフォルダにします。シンボリックリンク、Git submodule、Git LFS のポインタは、読み込む箇所では Blocks、それ以外では Warning です。人がインストールして受け取るのは、プラグインフォルダだけです。

.DS_Store、Thumbs.db、desktop.ini、__MACOSX をプラグインフォルダから除きます。残っていると Blocks です。検証中のメッセージは “This is a macOS or Windows system file” で始まります。提出後は “Files in the repository the scanner won’t accept.” です。

ファイル名は、Windows と macOS の両方で有効にしてください。コロンを入れず、末尾のドットやスペースを付けず、con.md や prn のような Windows のデバイス名を使わず、大文字と小文字だけが違う名前の対を置きません。失敗すると Validation stops になり、“Couldn’t validate that repository” と出ます。原因は、メッセージが区別しません。

プラグインまでの各フォルダ名は、英数字、ドット、ハイフン、アンダースコアだけにします。path の大文字と小文字は、リポジトリと一致させます。.gitattributes に export-ignore と export-subst を置かないでください。filter（Git LFS を含みます）のように内容を書き換える属性を、ルート、プラグインより上、プラグイン内に置かないでください。

サイズは、GitHub がアーカイブした状態で 50 MiB 未満、展開後 256 MiB 未満、ファイルとフォルダは 10,000 未満、プラグインフォルダ内の各ファイルは 5 MiB 未満です。超えると “Repository too large to validate” になります。

マニフェストと名前

name は小文字、数字、ハイフンで、64 文字までです。先頭と末尾は文字か数字です。非 ASCII は Blocks で、“Non-ASCII identifier” と出ます。それ以外のパターン違反（大文字など）は Warning です。

核は、自分の製品名やプロジェクト名にします。claude、anthropic、official、plugin、mcp、test を名前全体にしないでください。Anthropic が予約している marketplace 名にもしないでください。公式のもののように見せないでください。名前全体がこれらや予約名のときは Blocks で、“Name is taken” と出ます。test-plugin のように一般語だけのときは hold で、“Name may be confused with an existing listing” と出ます。

他の組織が使っている名前は使えません。大文字小文字や句読点だけが違う名前は、同一です。同一は Blocks、似せは hold です。name、displayName、author.name が、自分のものでない既存プラグイン、発行者、コネクタ、有名ブランドと紛らわしいと hold です。例は “Name matches a known brand” です。fork は許されますが、上流と同じ名前は hold で、“Fork uses the upstream project’s name” と出ます。displayName と author.name は、一つの文字体系にします。似せ文字や不可視文字は Blocks です。

hooks や mcpServers など、コンポーネントを宣言するキーは、プラグイン参照の綴りどおりにします。experimental に入れないでください。入れると Blocks です。description、author、version が無いと Warning です。directory 側は、version を置くならリリースごとに上げる、と書いています。Claude Code の公開ガイドは、git marketplace では version を省略し、コミット識別子（SHA）に任せる選択肢も書いています。directory に出すなら、上げる方を主にしてください。

公開後に name を変えないでください。Claude Code の公開ガイドは、既存のインストールは旧名で記録される、と書いています。これは移行時に注意する変更です。ラベルを変えるなら displayName を変えます。

README とライセンス

プラグインフォルダに README を置きます。できれば README.md です。40 語以上にしてください。コードブロック内の語は数えません。無い、または短いと Blocks で、“README missing” または “README too short” と出ます。directory は、README を掲載の説明として出します。

LICENSE ファイルか、plugin.json の license が要ります。無いと Blocks で、“License missing” と出ます。

フォルダ内のファイル

画像とフォント以外は、256 KiB 未満にします。超えると hold で、“Files or downloads the validator couldn’t inspect” と出ます。ファイル数は 512 以下です。超えると、同じタイトルの hold です。

許されるのは、テキスト（SVG を含みます）、完全な PNG、JPEG、GIF、WebP、フォントです。.ico、.pdf、.zip、コンパイル済みの実行ファイルなど、他のバイナリは hold です。README で同梱画像を見せるなら、Markdown の画像記法を使います。command、hook、スクリプトから、同梱の画像やフォントを参照しないでください。バッククォートやコードブロックにパスを書かないでください。書くと hold です。

MCP は、command と args、または url で宣言します。.mcpb や .dxt の束ねは hold で、“Bundled MCP server not inspected” と出ます。URL から束ねを取ると Blocks です。

実行と接続

パッケージランチャーは、npx、bunx、pnpm dlx、yarn dlx、uvx、pipx run、uv run です。ランチャーのパッケージは、正確な版にピンします。例は npx の @1.2.3 や、uvx の ==1.2.3 です。範囲や @latest は使えません。uv run は --locked または --frozen を付けます。未ピンは Blocks で、“Unpinned npx launcher” や “Unpinned uvx launcher” と出ます。

ランチャーやパッケージインストールがあるとき、レジストリ、インデックス、プロキシを決める設定（.npmrc、bunfig.toml、uv.toml など）を置かないでください。ランチャーがあると Blocks です。インストールだけのときは hold で、“Install may use a custom registry or package source” と出ます。

本物の資格情報を、例を含めて、どのファイルにも置かないでください。plugin.json の userConfig で sensitive: true とし、${user_config.KEY} で参照します。MCP のヘッダに資格情報があると Blocks で、“Secret in MCP headers” と出ます。ユーザーの環境に既にある資格情報（例は $GITHUB_TOKEN）を読んでサーバーへ送らないでください。README の例でも同じです。userConfig で聞きます。これは hold です。HTTP hook が送ると Blocks で、“Uses a credential from the user’s machine” と出ます。

.mcp.json は妥当な JSON にし、各サーバーは MCP ドキュメントのスキーマに合わせます。パースできないと Blocks で、“.mcp.json can’t be parsed” と出ます。リモート MCP の type は http、sse、ws です。url は、絶対の https:// または wss://、${user_config.KEY}、または固定エンドポイントが無いときの "" です。他のスキームは Blocks で、“MCP server URL is not https” と出ます。

ローカル MCP は、プラグイン内のファイルを、素の引数で起動します。例は node ${CLAUDE_PLUGIN_ROOT}/server.js です。シェル、-c のようなインライン、npm run のようなパッケージマネージャのスクリプトは hold で、“MCP server command wasn’t read” と出ます。hook や MCP の command では、パスを ${CLAUDE_PLUGIN_ROOT} からフルに書きます。他の変数、コマンド置換、ワイルドカード、python3 -c のようなインラインは、プラグインがリポジトリのサブフォルダにあるときは Blocks です。hook や MCP が実行するスクリプトに、ランチャーとパッケージインストールを入れないでください。サブフォルダ配置では、${CLAUDE_PLUGIN_ROOT} 以外のシェル変数、コマンド置換、プラグイン内の別ファイル呼び出しも入れないでください。hold のタイトルは “Scripts the validator couldn’t follow” です。

次は、他が全部通っても、人が必ず見る hold です。

  • 正確な版にピンしたランチャー、または --locked か --frozen の uv run でも hold です。タイトルは “Runs a pinned npx or uvx package” です。依存はインストール時に解決されるためです。
  • プラグインフォルダ直下の package.json と、package-lock.json、npm-shrinkwrap.json、bun.lock、bun.lockb の組は hold です。タイトルは “Dependencies install from a lockfile” です。インストール時に、Claude Code がそのロックファイルを入れます。
  • プラグインがサブフォルダにあるとき、検証が追えないプログラムは hold です。追うのは、素のシェルスクリプトだけです。該当するのは、hook、MCP、LSP の command、skill や command の !`...` がシェル以外を実行するとき、ディレクトリ全体をインタプリタに渡すとき、シェルが別ファイルを実行するときです。SKILL.md が Claude に実行を頼むだけのスクリプトは、この検査の外です。回避は、プラグインを専用リポジトリのルートに置くか、hook とサーバーのロジックを、${CLAUDE_PLUGIN_ROOT}/ でパスを書いたシェルに置くことです。コードを同梱しても、256 KiB などのファイル検査は残ります。

hooks、skills、commands、agents

hooks/hooks.json は妥当な JSON にします。トップは hooks オブジェクト、mod 用の modules 配列、またはその両方です。hooks のイベントと型は、hooks の参照にあるものだけです。詳細は公式ドキュメントを参照してください。HTTP hook は https:// です。崩れていると Blocks で、“hooks.json is invalid” と出ます。plugin.json の hooks フィールドに hooks/hooks.json を書かないでください。Claude Code は自動で読みます。書くと Warning です。

skill、command、agent の YAML front matter は妥当にします。description はリストではなく、単一のテキストです。パースできない、またはテキストでない description は Blocks です。front matter や description が無いのは Warning です。フォルダ名とファイル名は、Claude Code の綴りと大文字小文字どおりにします。例は hooks/、skills/、SKILL.md です。違うと Blocks です。

セキュリティスキャンの前に

スキャンが見るのは、開示していない振る舞いです。例は、データを別の場所へ送ること、隠れたコードを動かすこと、Claude の権限設定を変えることです。

初回提出でスキャンに落ちると、拒否されます。後の版で落ちると、live にできません。フラグされた新版は、hold になり得ます。Versions タブには “Didn’t pass the security scan”、またはカテゴリ（例は “Sends data to an undisclosed destination”）が出ます。README に、実行するもの、送るもの、取得するものを全部書きます。README が完全でも、許されるとは限りません。許否は Software Directory Policy です。コンパイル済み、パック済み、minify されたコードではなく、読めるソースをコミットします。読めないコードは hold です。

動作確認

自動検査は、役に立つかを見ません。スキルを実プロンプトで動かし、プラグインなしと比較します。Claude Code では claude plugin eval を使います。単一スキルの測り方は、スキル作成ドキュメントの測定手順です。詳細は公式ドキュメントを参照してください。ユーザーが使う各 surface で読み込みます。ドキュメントの見出しは “Test the plugin on each surface” です。

スクリーンショット

プラグイン bundle の提出チェックリストと提出手順に、スクリーンショット必須の項目はありません。

スクリーンショットの仕様があるのは、MCP App のコネクタ提出です。カルーセルは 3 枚から 5 枚、アプリの応答だけを切り、プロンプトは画像に入れず別テキストにします。根拠は Submit a connector です。スクショを用意する、と書くなら、MCP App をコネクタとして出す場合に限ってください。

コネクタ提出が求める掲載素材（ドキュメントの URL、プライバシーポリシーの URL、サポート連絡先、アイコン、MCP App ならカルーセル）は、プラグイン bundle のフォーム項目としては、提出ページに出ていません。プラグインの表示は、plugin.json と README から読みます。

参照した公式ページ

この記事の根拠にしたページは、次のとおりです。