Claude プラグイン公開の実務ガイド：申請・審査・運用まで

Claude プラグインを公開する最短手順

Claude プラグインの公開は、次の順番で進めます。

1. 申請に使うClaudeアカウントがPro、Max、Team、Enterpriseのいずれかであることを確認します。
2. リスティングを長期的に所有する組織を決めます。
3. .claude-plugin/plugin.json、README、ライセンスを含む形でプラグインをパッケージ化します。
4. フォルダをローカルでテストし、連携済みのGitHubアカウントからpushできるリポジトリへ配置します。
5. 開発者ポータルを開き、Plugin bundleを選択します。リポジトリ、必要に応じてプラグインのパス、追跡するブランチまたはタグを入力し、Validateを実行します。
6. データの取り扱い、コンプライアンス、連絡先、アップデート方法を設定し、Submit for reviewを選択します。
7. プラグインから自社運用のリモートMCPサーバーを参照する場合は、そのサーバーをMCP connectorとして別途申請します。

Anthropicが定めるGitHubへのアクセス条件とソースアップロード条件を満たしていれば、検証・審査中はリポジトリを非公開のままにできます。ただし、プラグインを公開する前には公開リポジトリへ切り替える必要があります。

ポータルを開く前に申請種別を決める

プラグインとコネクタは連携できますが、同じものではありません。プラグインが箱に収められた業務マニュアルだとすれば、リモートMCPサーバーはその背後で稼働するサービス窓口です。前者はClaudeにワークフローを教え、後者はClaudeから製品やデータへリアルタイムにアクセスできるようにします。

スキルは第3の申請種別ではありません。Plugin bundleの中に含めます。そのバンドルから自社のホスト型MCPサーバーを参照するなら、同じClaude組織から両方を申請し、同一のサーバーURLを指定します。これにより、ポータル側で2つのリスティングを関連付けられ、ユーザーに重複したツールセットが表示されるのを防げます。

リスティングの所有者を決める

組織の選択は単なる管理設定ではなく、長く影響するプロダクト上の判断です。Plugin bundleでは、リポジトリ内のフォルダを最初に申請した組織が、そのリスティングを所有します。同じリポジトリとフォルダを別の組織から重ねて申請することはできません。

アカウントのルールは明快です。

• ProまたはMaxでは、自分のアカウントから申請します。
• TeamまたはEnterpriseでは、Ownerが申請できます。
• Enterpriseでは、Ownerがカスタムロールを通じてDirectory権限を付与できます。
• そのClaude組織内で連携するGitHubアカウントには、対象リポジトリへpushできる権限が必要です。

制作会社がプラグインを開発しても、公開上の所有者をクライアントにする必要があるなら、クライアント側の組織から申請します。後でリポジトリを引き渡しても、ディレクトリのリスティングまで譲渡したことにはなりません。

公開ルートにかかる費用

Anthropicの公開手順には、ディレクトリ掲載のための個別料金は記載されていません。ただし、Freeアカウントからは申請できません。したがって、申請の入口で最低限かかる現金コストは、有料アカウントの料金です。

• 有料アカウントを持たない個人開発者なら、月払いのProを1か月$20で利用できます。年払いでは、$200を前払いし、月額換算は$17です。
• Teamは2人から利用できます。Standardを2席契約した場合、月払いなら1か月$50、年払いなら月額換算$40です。
• Maxは月額$100からですが、申請だけを目的にMaxを選ぶ必要はありません。

より大きな負担は、リリース準備そのものです。ホスト型プロダクトなら、バンドルとコネクタの2件をそれぞれ申請できる状態に整える必要があります。プラグイン側にも、安定したマニフェスト、コード以外で最低40語のREADME、ライセンス、データ取り扱いに関する回答、審査用の連絡先、そして公開可能なリポジトリが欠かせません。新しいポータルでは、検証、スキャン結果、審査状況、公開、アップデート、利用状況を1か所で扱えるため、調整コストは下がります。ただし、リリース作業そのものがなくなるわけではありません。

ディレクトリ公開に耐えるPlugin bundleの作り方

実用に足る最小構成は、次のとおりです。

your-plugin/
  .claude-plugin/plugin.json
  skills/your-workflow/SKILL.md
  README.md
  LICENSE

マニフェストには、変更しない小文字のname、ユーザー向けのdisplayName、version、内容が伝わるdescription、作者、ライセンス宣言または独立したライセンスファイルが必要です。恒久的に使う名前は慎重に決めてください。displayNameは変更できますが、マニフェストのnameがプラグインの識別子になります。

READMEは、単なるリポジトリ管理用ファイルではありません。ディレクトリではリスティングの素材として使われ、コード以外の単語が40語未満だと検証でブロックされます。プラグインで何ができるのか、どう使うのか、どのデータを送信するのかを明記します。実際に使える認証情報は、決してリポジトリへ入れないでください。

バンドルからリモートサーバーを参照する場合は、.mcp.jsonにHTTPSエンドポイントを記載します。APIキーは入れないでください。インストールした全ユーザーにプラグインファイルが配布されます。

ローカルテストの後にポータルでも検証する

GitHubへ送る前にローカル検証を行えば、プラグインファイルの不備を見つけられます。

claude plugin validate ./your-plugin
claude --plugin-dir ./your-plugin

最初のコマンドは、ファイルの構文とスキーマを確認します。2つ目は、作業中のフォルダを読み込んだClaude Codeセッションを1つ起動し、スキルやコマンドを実際に試せるようにします。ただし、ローカル検証はポータルのValidateボタンの代わりにはなりません。ポータルでは、ディレクトリ固有の要件、リポジトリ構成、名前の競合、ファイルポリシーなど、申請に関わる追加ルールも確認されます。

今回の検証では、1つのスキルと3つの架空issueファイルを含む小規模なrelease-note-builderプラグインを作成しました。issueの内容は、監査ログのCSVエクスポート追加、ページネーションの改善、重複メールの修正です。Claude Code 2.1.283で実行した結果はValidation passed、終了コードは0で、エラーも警告もありませんでした。

続いて、claude --plugin-dirでフォルダを読み込み、フィクスチャを使った動作確認を行いました。このマシンではClaudeの認証済みセッションがなかったため、モデルを呼び出す前にNot logged in · Please run /loginで停止しました。生成されたリリースノートは確認できていません。この境界は重要です。フォルダの検証はローカルで実行できますが、挙動を確かめるには認証済みのモデルアクセスが必要です。より本格的な動作テストについては、別ガイドのClaude Codeプラグイン評価を参照してください。

プラグイン申請フォームの入力手順

公開ドキュメントに記載された流れは、実務上6つの段階に分けられます。

1. ソース

GitHubリポジトリをURLまたはowner/repoの形式で入力します。プラグインがリポジトリのルートより下にある場合は、そのパスも追加します。今後のバージョンを追跡するブランチまたはタグを選ぶか、空欄のままにしてデフォルトブランチを追跡します。その後、Validateを選択します。

検証時に読み込まれるのは1つのコミットです。修正をpushしたら、レポートが新しいコミットを参照するようにRe-validateを選択してください。

2. リスティングの詳細

ポータルは、plugin.jsonとREADMEをもとにリスティングを生成します。名前、説明、使い方に誤りがある場合は、リポジトリ内のファイルを編集してから再検証します。公開時の約束と実際に配布するパッケージを、同じリリース内で一致させられる仕組みです。

3. データの取り扱い

個人データを読み取る、または保存するか、宣言したコネクタ以外の場所へデータを送るか、データを保持するか、18歳未満を対象とするかを回答します。単なるフォーム入力ではなく、プロダクト上の契約事項として扱ってください。

4. コンプライアンスと連絡先

Anthropicが審査連絡に使うメールアドレスを登録し、必須の4項目を確認します。指摘や修正依頼を受けてバージョンが差し戻される場合があるため、実際に担当者が確認する受信箱を指定します。

5. アップデート

デフォルトのGitHub push webhook、または定期チェックのみを選択します。どちらを選んでも、ディレクトリは指定したブランチやタグを監視できます。webhookの設定には、リポジトリの管理者権限が必要です。

6. 確認と審査申請

内容を確認し、Submit for reviewを選択します。1つの組織が24時間以内に作成できる申請は最大10件で、下書きと取り下げ済みの申請もこの件数に含まれます。既存の下書きを続けるつもりで、重複する申請を新規作成しないよう注意してください。

リモートMCPサーバーは別に申請する

プラグインから自社運用のリモートMCPサーバーを呼び出す場合は、Submit newへ戻り、MCP connectorを選択します。コネクタではフォルダではなく稼働中のサービスを掲載するため、より詳しい運用情報が求められます。

サーバーURL、ドキュメントとプライバシーポリシーのURL、アイコン、審査用のテスト認証情報、必要に応じてMCP Appのカルーセル画像を用意します。公開されている手順には、接続、同期されたツール、公開リスティング、ユースケース、企業情報、認証、データの取り扱い、テスト手順、コンプライアンス、最終審査が含まれます。

公開リスティングには、最大100文字のサーバー名、最大200文字の1行説明、最大2,000文字の詳細説明、1〜5個のカテゴリ、ドキュメント、プライバシー、サポート、アイコン、変更されないURLスラッグを登録します。製品の利用にアカウントが必要な場合は、データを入れたテストアカウントも審査担当者向けに用意します。ヘルスエンドポイントが応答しただけで、コネクタの準備が完了したと判断してはいけません。まずMCP Inspector、またはClaudeのカスタムコネクタとして、すべてのツールを実行してください。

審査ステータスは「次に誰が動くか」で読む

審査期間は明示されていません。「審査にはどれくらいかかるか」ではなく、「次に対応するのは誰か」を見ると、取るべき行動が分かります。

Approvedは、インストール可能という意味ではありません。利用できるのはPublishedになってからです。初期設定によっては、審査に通ったバージョンでもAnthropicの担当者が公開するまで保留されます。後から、検証に通ったアップデートを自動公開するよう設定できるプラグインもありますが、保留中のバージョンはそのまま待機します。

初回公開の前にアップデート運用を決める

公開後は、追跡対象のブランチへマージするか、追跡対象のタグを移動します。ディレクトリは新しいコミットを読み込み、検証とセキュリティスキャンを実行し、別バージョンとして表示します。versionは、リリースのたびにplugin.json内で更新してください。

アップデートが失敗したり保留されたりしても、正常に動いているリスティングは停止しません。新しいバージョンが公開されるまで、ディレクトリは直前の公開済みバージョンを配信し続けます。つまり、ブランチは単なるソース置き場ではなく、リリースフィードとして機能します。

Usageタブを使えば、改善のサイクルを回せます。最大90日までの期間を指定し、インストール数、アクティブアカウント数、継続率、バージョン構成比、コンポーネント利用状況、読み込みエラー、MCP呼び出しとレイテンシ、リスティングの閲覧数、インストールクリック数、インストール数を確認できます。数値はUTC基準で1日1回更新され、CSVとしてエクスポートできます。ポータルに記録される前に、インストール数を約束してはいけません。

Claude プラグイン公開の恩恵が大きい6つのチーム

1. リモートMCP製品を持つSaaSチーム

プロダクトチームは、稼働中のサーバーをコネクタとして申請し、そのサーバーを使うワークフロースキルをプラグインとしてまとめます。顧客が得られるのは、ツールへのアクセスだけではありません。ツールを有効に使うための手順も一緒に届きます。チーム側では、コネクタでサーバーの稼働状況とツール利用状況を、プラグインでインストール数とコンポーネント利用状況を把握できます。

2. ワークフロー系ソフトウェア企業

経費精算、採用、サポート、営業などのプラットフォームなら、最も有効な業務手順をスキルにし、製品コネクタと組み合わせられます。ユーザーが導入するのは、説明のないAPIメソッドの寄せ集めではなく、実際に使えるワークフローです。結果として、定着の質を高められます。

3. オープンソースプラグインのメンテナー

コードを公開したままリリースブランチを追跡し、ポータルを安定した掲載・アップデートチャネルとして利用できます。新しいコミットを修正している間も、直前の検証済みバージョンは利用可能です。リポジトリへのpushを毎回すぐにユーザー向け品質へ仕上げなければならないという負担を減らせます。

4. クライアント向けプラグインを納品する制作会社

制作会社がフォルダの開発とテストを担当しても、リスティングをクライアントの所有物にする必要があるなら、クライアント側の組織から申請します。リポジトリの管理権、ディレクトリの所有権、サポート窓口、分析データを発注側へまとめて引き渡せるため、納品後の関係が明確になります。

5. エンタープライズのプラットフォームチーム

EnterpriseのOwnerは、広範なOwnerロールを共有せず、担当メンバーにDirectory権限だけを付与できます。会社の組織内にリスティングを保持したまま、リリース作業と組織全体の管理を切り分けられます。

6. ターミナルの外へ展開するClaude Codeツール開発者

コマンドやスキルをより広いディレクトリへ展開できますが、その前に各利用面での対応状況を確認する必要があります。スキルはchat、Cowork、Claude Codeで動作します。エージェントとフックはchatでは動作せず、ローカルMCPサーバーもchatには対応していません。LSPサーバーはClaude Code専用です。どこでも同じ体験を提供できないパッケージについて、全環境で同一の機能が使えるように見せてしまう事態を避けられます。

ポータルを起点に作れる3つのプロダクト

1. 最有力案：Plugin Release Gate

リリースブランチがポータルへ到達する前に、プラグインを検査するGitHub checkを作ります。ローカル検証を実行し、READMEとライセンスを確認し、非対応のコンポーネント構成を警告し、マニフェストのバージョンを比較して、ディレクトリ申請の準備状況をレポートします。

需要はすでに表れています。claude code pluginsの米国での月間検索数は約5,400で、検索意図は商用、CPCは$6.22です。販売可能な最小構成は、GitHub App、Webレポート、リポジトリバッジの組み合わせです。ただし、Anthropicのディレクトリ検証と人による審査はローカルコマンドの範囲を超えるため、ポータルでの承認を保証するとは正直に言えません。提供できる価値は、防げるはずの失敗を減らすことであり、承認の確約ではありません。

2. Directory Listing Optimizer：掲載改善ツール

ポータルからエクスポートしたCSVを読み込み、閲覧数、インストールクリック数、インストール数、流入元、バージョン、コンポーネント利用状況を分析し、リリースやリスティングの改善案に変えるレポート機能を作ります。日次データが役立つだけのトラフィックを持つプラグイン公開者が購入者です。

claude pluginsの米国での月間検索数は約8,100で、検索意図は商用、CPCは$9.05です。MVPには、CSVアップロード、ファネル計算、バージョン比較、週次のアクションリストが必要です。課題は、初期データがないことです。公開されて実利用が始まるまで、その製品ならではの分析材料はありません。また、文書化された分析APIではなく、エクスポートファイルに依存します。

3. Cross-Surface Plugin Auditor：対応範囲の監査ツール

1つのプラグインフォルダについて、Chat、Cowork、Claude Codeのそれぞれが何を読み込むかを明示する静的スキャナーを作ります。トップレベルのbin/ディレクトリ、ローカルMCPを前提とする構成、chatで無視されるエージェントとフック、Claude Code専用のLSPを検出し、テストマトリクスを生成します。

claude-plugins marketplaceの米国での月間検索数は約1,900、難易度は16で、検索意図は商用です。MVPは、Anthropicの対応表をもとにしたリポジトリスキャナーです。課題は継続的な保守で、プラットフォームの対応範囲は今後も変わります。また、ターミナルだけを対象とする開発者には、広い環境への互換性が重要でない場合もあります。

最有力はリリースゲートです。初回掲載時だけでなく、すべてのバージョンで使われるからです。ポータルを置き換えようとせず、その機能を補完できる点にも強みがあります。

このポータルだけでは解決できないこと

有用性の低いプラグインを、ポータルが優れたものに変えてくれるわけではありません。検証で確認できるのは、ファイル形式が正しくポリシーに適合していることまでです。スキルによって結果が改善するかどうかまでは証明できません。すべてのClaudeアプリで、各コンポーネントが同じように動く保証もありません。審査期間は固定されておらず、申請すればVerifiedラベルが得られるわけでも、公開初日からインストールユーザーが集まるわけでもありません。

また、ホスト型MCP製品を1件のリスティングに統合するものでもありません。コネクタを分けて申請するのは、サーバーの認証、稼働状況、ツール、ポリシーにそれぞれ独立した運用記録が必要だからです。

統合されたディスカバリー体験は、9月25日のローンチ後、数週間をかけて順次展開されています。現時点で文書化されている利用面を前提に公開し、今後広がるディスカバリーは、いずれ得られる配信機会として扱ってください。まだ存在しないリーチを約束してはいけません。

月曜日に着手すること

まず、リスティングを所有すべきClaude組織を決めます。実際に使うワークフローを1つPlugin bundleにまとめ、変更しないマニフェスト名、役に立つREADME、ライセンスを用意してから、ローカル検証を実行します。自社のホスト型MCPサーバーを呼び出す場合は、コネクタ申請も並行して準備してください。所有者とリポジトリのパスが確定するまでは、ポータルでの申請を始めないことが重要です。

プラグインと本番用コネクタを一体の信頼できるリリースシステムとして構築したい場合は、AIプロダクションシステムをご覧ください。