Coworkプラグインマーケットプレイスを社内向けに作る手順

Anthropic製のマーケットプレイスだけでなく、Team・Enterpriseのオーナーは自社専用のマーケットプレイスを作れます。プラグインを入れる方法は、ZIPの手動アップロードと、GitHubまたはGitLabリポジトリの同期の2系統です。入口はどちらもOrganization settings > Plugins & skillsです。

プライベートマーケットプレイスは何を解決するのか

Anthropic製マーケットプレイスは法務・財務など汎用的な用途向けで、Knowledge Workマーケットプレイスは組織に最初から追加されています。自社の業務知識や社内システム連携のプラグインを配るには、自前のマーケットプレイスが要ります。

作ったマーケットプレイスは、Anthropic製と同じ画面で、同じ配布設定とグループオーバーライドの仕組みを使って管理できます。4段階のインストール制御とグループ単位の上書きの挙動はCoworkプラグイン管理にあり、ここでは作成と同期を扱います。

配布したプラグインはCoworkだけに届くわけではありません。チャット(Web版とClaude DesktopのChatタブ)にも、同じアカウントでサインインしたClaude Codeのセッションにも現れます。

手動アップロードとGitHub・GitLab同期、どちらを選ぶか

2つの系統は併用できます。主力プラグインは同期で管理し、単発の社内ツールは手動アップロードで別のマーケットプレイスに入れる、という分け方です。

手動マーケットプレイスを作る

エンジニアリングリソースなしで始められるのが手動アップロードです。ZIPは200MBまで受け付けられ、クライアント側とサーバー側の両方でチェックされます。

更新は同じ名前のプラグインを上げ直すだけです。旧版は自動で上書きされ、先に消す必要はありません。プラグイン名が識別子なので、legalは常にlegalを置き換えます。消したいときはOrganization settings > Plugins & skillsの「Inventory」タブから削除します。

GitHub同期のマーケットプレイスを作る

接続できるリポジトリの条件

github.com上のリポジトリは、プライベートまたはインターナルに限られます。パブリックリポジトリは組織マーケットプレイスに使えません。組織のGitHub Enterpriseホストにも対応します。

marketplace.jsonで使えるソース種別は、Claude Code本体より狭くなっています。マーケットプレイスのリポジトリ内を指す相対パス("source": "./plugins/my-plugin")が最も単純です。github・url・git-subdirも使えますが、npm・archive・commandは使えません。

マーケットプレイスの仕組み自体はClaude Codeのプラグインマーケットプレイスと共通です。特定のマーケットプレイスを遮断したいときはblockedMarketplaces設定を使います。

リポジトリの外を指すソースでプライベートのまま取得できるのは、次の2パターンだけです。

• マーケットプレイスのリポジトリと同じオーナーのgithub.comリポジトリ(Claude GitHub App経由で取得)
• 組織のGitHub Enterpriseホスト上で、GitHub Enterprise Appを入れたリポジトリ

それ以外のソースは認証なしで取得されます。別オーナーのgithub.comリポジトリやBitbucketなどは公開状態でなければ読めず、対応外のホストは拒否されます。条件に合わないプライベートリポジトリのプラグインは、フォルダをマーケットプレイス側へコピーして相対パスに直します。git subtreeやCIでのベンダリングが向いています。

接続の手順

リポジトリが候補に出ないときは、対象リポジトリにClaude GitHub Appが入っているかを見ます。

手元でmarketplace.jsonを検査するときの落とし穴

マーケットプレイス用リポジトリは、手元でもclaude plugin validate <path>で検査できます。ただしこのコマンドが見るのはClaude Codeの基準で、Coworkの同期や命名ルールまでは見ません。

v2.1.287で、相対パスのプラグインと、npmソースのBad_Nameというプラグインを並べたmarketplace.jsonを作って検査しました。マーケットプレイス名は予約名のclaude-plugins-officialにしています。結果は次のとおりでした。

⚠ Found 2 warnings:
 
  ❯ description: No marketplace description provided. ...
  ❯ plugins[0] plugin.json → author: No author information provided. ...
 
✔ Validation passed with warnings

警告は説明と作者の欠落だけで、予約名も大文字を含むプラグイン名もnpmソースも通っています。Claude Codeのドキュメントによれば、予約名と完全一致する名前が弾かれるのはマーケットプレイスを追加する時点で、manifestの検査では見られません。同期用リポジトリでは、検査が通っても次の節のルールを自分で確認する必要があります。

同期の仕組みとつまずき

初回同期は接続時に自動で走ります。GitHubの作成フローでは「Sync automatically」が既定でオンで、あとからマーケットプレイスのメニューで切り替えられます。同期のたびに、Coworkはリポジトリの最新コミットと前回同期時のコミットを比べます。差がなければスキップし、差があればmanifestを読み、各プラグインを検証し、マーケットプレイスの中身を丸ごと置き換えます。かかる時間は最大30分です。

自動同期のきっかけは何か

自動同期を動かす条件は、公式ページ内で2通りに読めます。作成フローの説明は「ブランチへのPRのマージ、または直接のpush」です。同じページの別の節では、デフォルトブランチへのPRのマージのうち、プラグインのバージョン更新を含むものだけが対象で、直接pushでは走らないとあります。

どちらの記述が現行かは、ページの記述だけでは決められません。自動同期を前提に運用するなら、プラグインのバージョンを上げたPRをデフォルトブランチへマージする流れにしておくのが安全側です。手動の「Update」(ページによっては「Re-sync」)はいつでも使え、同期のたびにプラグインは丸ごと置き換わります。

自動同期をオンにできない

トグルをオンにできるのは、そのリポジトリへのadmin権限を、個人のGitHub連携で持っている人だけです。権限がないと、Appが正しく入っていて手動更新も動いていても、「Cannot access repository. Ensure the repository exists and the Claude GitHub App is installed」と出ます。メッセージはApp側の不備を指していますが、原因が個人の権限にある例です。

もう1つの原因は、Claude GitHub AppのWebhooks(Read & Write)権限が未承認の古いインストールです。GitHub側に「Claude is requesting updated permissions」のプロンプトが出るので、リポジトリまたは組織のadminが承認します。

同期が失敗したとき

メッセージごとの原因は次のとおりです。

• 「content error」: リポジトリ内のどれかのプラグインの形式が誤っています。marketplace.jsonかプラグイン本体を直してpushし、再同期します。
• 「External plugin source type is not supported. Supported types: git-subdir, github, url」
• 「Repository not found on gitlab.com. Check the URL and make sure the repository is public.」

後ろ2つは、github・url・git-subdirでリポジトリ外を指すエントリを、組織側が取得できないときに出ます。npmなど非対応の種別も、この経路では使えません。公式のトラブルシューティングにはgitlab.comの例が載っていて、該当プラグインはスキップされる扱いです。

対処は共通です。該当フォルダをマーケットプレイスのリポジトリに移して相対パスにするか、Organization settings > Plugins & skillsの「Add」>「Upload a plugin」>「Add to an existing marketplace」で個別に上げます。メンバーが自分のCustomizeメニューからアップロードしたプラグインは、原則として本人専用で、組織には配られません。ただし共有がオンなら、特定の同僚やグループへ共有できます。

GitLab同期はベータで、別の準備が要る

github.com以外にも、gitlab.comまたは自前運用のGitLabインスタンスから同期できます。ベータ提供で、対象はプラグインマーケットプレイスの同期だけです。Claude Code on the webはまだGitLabリポジトリに対応していません。

GitHubとの違いは準備の量にあります。

• 可視性: gitlab.comではプライベートかインターナルが必須ですが、自前運用のインスタンスは公開範囲を問いません。
• アクセストークン: 個人・グループ・プロジェクトのどのトークンでも使えます。トークンのユーザーには、対象プロジェクトでReporter以上の権限が要ります。必要なスコープは、旧式ならread_api、細粒度ならProject・Branch・RepositoryのReadです。
• Webhook: 自動作成にはMaintainer権限とapiスコープ(旧式)、またはWebhookの作成・削除権限(細粒度)が要ります。足りなければ手作業で一度登録します。自前運用のインスタンスでは、api.anthropic.comへ外向きHTTPSが通ることも条件です。
• 自動同期: プロジェクトのデフォルトブランチへのpushのたびに同期が走ります。GitHubで「バージョン更新を含むPRのマージ」とする記述とは条件が違います。
• ソースの取得: プライベートソースとして読めるのは、マーケットプレイスと同じGitLabホスト上のurlまたはgit-subdirソースです。gitlab.comでは同じトップレベルのグループかユーザー名前空間に限られます。

GitLabの設定は、Organization settings > Claude Codeにある構成が前提で、構成の追加にはOwnerまたはPrimary Ownerの権限が要ります。マーケットプレイス名はプロジェクトのパスから付きます。

命名ルールと上限

プラグイン名はdeployment-toolsのように小文字をハイフンでつなぎ、Deployment Toolsのような形は使えません。displayNameをプラグイン側で指定すれば、カタログにはスラッグではなく読みやすい名前が出ます。

次のマーケットプレイス名は予約されていて、自作には使えません。

• claude-code-marketplace
• claude-code-plugins
• claude-plugins-official
• anthropic-marketplace
• anthropic-plugins
• agent-skills
• life-sciences

Anthropic公式を装う名前もブロックされます。

アップロードが拒否される主な原因は、200MBの超過、ZIPとして不正、1,000件の上限到達のいずれかです。プラグイン・スキルのスキャンを有効にしている組織では、悪意あるコードとして検出されたときも拒否されます。

配ったあとに見ておく3点

Skillsを切るとClaude Codeへの同期も止まる

組織でSkillsをオフにすると、スキルとプラグインのClaude Codeへの同期が止まり、同期済みのものも消えます。Coworkをオフにしても、Claude Codeへの同期には影響しません。Claudeには残したまま同期だけを止めたいなら、Claude Codeの管理設定でsyncClaudeAiSkillsとsyncClaudeAiPluginsをfalseにします。

「Required」はメンバーのPCで動く

「Installed by default」と「Required」のプラグインは、ClaudeアカウントでサインインしたメンバーのClaude Codeにも入ります。プラグインのフック、サブエージェント、MCPサーバーはメンバーのPC上で動きます。Requiredはメンバー側で無効にできないので、フックの中身を読んでから設定します。

再同期でグループ設定は消えない

GitHubまたはGitLab同期のマーケットプレイスを再同期しても、グループ単位のオーバーライドは残ります。消えるのは、プラグイン自体をマーケットプレイスから削除したときだけです。同期のたびに配布設定を作り直す必要はありません。

まとめ

リポジトリで管理しているプラグインは同期、そうでないものは手動アップロードという線引きが基本です。GitHubとGitLabの両方を使う組織では、自動同期の条件がホストごとに違う点が運用の分かれ目になります。同期が走るきっかけを、ホストごとに分けて決めておく形です。Coworkの全体像はClaude Cowork(クロードコワーク)とはで扱っています。