Claude Media
cowork-plugin-managementで自社用Coworkプラグインを作る手順
Coworkチュートリアル

cowork-plugin-managementで自社用Coworkプラグインを作る手順

Anthropic製cowork-plugin-managementの2スキル(create-cowork-plugin・cowork-plugin-customizer)の進め方と、.pluginファイル化・MCP設定の流れをまとめます。

読了目安 約17分

cowork-plugin-managementは、業務プラグインを使うためのプラグインではありません。Coworkで自社用のプラグインを作り、既存のプラグインを自社のツールに合わせて書き換えるための、Anthropic製のプラグインです。中身は2つのスキルで、どちらも質問に答えるだけで.pluginファイルまで仕上がる作りになっています。ここでは、それぞれが何を聞き、何を出力するかを、リポジトリのファイルに沿って追います。

作ったプラグインを組織に配ったり、グループごとに見せる範囲を絞ったりする管理者向けの設定は、Coworkプラグインの組織管理が扱っています。

cowork-plugin-managementには何が入っているか

anthropics/knowledge-work-pluginsリポジトリのcowork-plugin-managementディレクトリ(v0.2.2)は、.claude-plugin/plugin.json、LICENSE、skills/の3つだけで構成されています。plugin.jsonの説明文は「組織のツールとワークフローに合わせたプラグインの作成・カスタマイズ・管理」で、作者はAnthropicです。

skills/には2つのスキルがあります。

スキル役割出力
create-cowork-plugin役割新しいプラグインを対話で一から作る出力.pluginファイル
cowork-plugin-customizer役割既存プラグインを自社向けに調整する出力調整後の.pluginファイル

どちらもスキルのcompatibility欄に、Coworkのデスクトップアプリ環境が必要と書かれています。cowork-plugin-customizerは、リモートコンテナ上の会話では探索の段階で中断します。

業務プラグインの側(Marketing・Sales・Product Managementなど)を先に知りたいときは、Claude部門別プラグインの使い方が入口になります。プラグインというしくみそのものはClaude.aiのプラグイン機能の解説にまとめてあります。

create-cowork-plugin — 5つの段階で一から作る

このスキルは、プラグインを「スキル・エージェント・フック・MCPサーバー連携を束ねた、自己完結のディレクトリ」と定義し、次の5段階で進めます。

手順

create-cowork-plugin の進行

  1. 1

    1. 発見(Discovery)

    何を作りたいか、誰がどんな場面で使うか、外部ツールと連携するかを聞きます。答えが済んでいる質問は飛ばし、最後に理解を要約して確認します。

  2. 2

    2. 部品の計画

    スキル・MCP・エージェント・フックのどれが要るかを決め、作らない部品も含めた一覧表を見せて承認を取ります。

  3. 3

    3. 設計と追加の質問

    部品ごとに細部を詰めます。スキルならどんな依頼で起動するか、MCPならサーバーの種類と認証方式、といった内容です。

  4. 4

    4. 実装

    ディレクトリ、plugin.json、各部品、README.mdの順にファイルを作ります。

  5. 5

    5. 確認とパッケージ化

    作った内容を要約し、構造を検証してから.pluginファイルにまとめます。

質問にはAskUserQuestionを使う指示があり、「業界標準のはずだ」という既定値を勝手に採らず、わからない項目は選択肢つきで聞く方針です。ユーザーへの発言は、ファイルパスやスキーマ名を出さず、プラグインが何をするかの言葉で話すよう指示されています。

作られるプラグインの形

スキルが前提にしている構成は次のとおりです。

plugin-name/
├── .claude-plugin/
│   └── plugin.json      # 必須
├── skills/
│   └── skill-name/
│       ├── SKILL.md
│       └── references/
├── agents/
├── .mcp.json
└── README.md

必須なのは.claude-plugin/plugin.jsonだけで、必須キーはnameです。名前はケバブケース(小文字とハイフン)にし、バージョンはセマンティックバージョニングで0.1.0から始めます。使わない部品のディレクトリは作りません。

部品の置き場所と形式は次の表のとおりです。

部品場所形式
スキル場所skills/*/SKILL.md形式Markdown + YAMLフロントマター
MCPサーバー場所.mcp.json形式JSON
エージェント場所agents/*.md形式Markdown + YAMLフロントマター
フック場所hooks/hooks.json形式JSON
コマンド(旧形式)場所commands/*.md形式Markdown + YAMLフロントマター

Coworkの利用者にいちばん役立つのはスキルです。新規のプラグインはskills/*/SKILL.mdで作り、旧形式のcommands/は利用者が必要だと明示したときだけ使います。エージェントはCoworkではあまり使われず、フックはほとんど使われません。

スキルの書き方に関する指示

スキルのフロントマターはnameとdescriptionが必須です。descriptionは三人称で「This skill should be used when the user asks to ...」の形にし、起動のきっかけになる言い回しを引用符つきで並べます。本文は命令形で書き、3,000語以内(目安は1,500〜2,000語)に収め、詳細はreferences/に逃がします。「スキルの本文はユーザー向けの説明書ではなく、Claudeへの指示書」という整理です。

次の例は、スキルのcomponent-schemas.mdにあるフロントマターの書き方です。

---
name: api-design
description: >
  This skill should be used when the user asks to "design an API",
  "create API endpoints", "review API structure", or needs guidance
  on REST API best practices, endpoint naming, or request/response design.
metadata:
  version: "0.1.0"
---

MCPサーバーの書き方

.mcp.jsonには3種類の接続方式の例があります。ローカルプロセスならコマンドと引数、リモートならSSEまたはHTTPで、認証が要る場合はheadersに${API_TOKEN}のように環境変数を参照させます。プラグイン内のパスには${CLAUDE_PLUGIN_ROOT}を使い、絶対パスは書きません。必要な環境変数はREADMEに書き残します。

{
  "mcpServers": {
    "api-service": {
      "type": "http",
      "url": "https://api.example.com/mcp",
      "headers": {
        "Authorization": "Bearer ${API_TOKEN}"
      }
    }
  }
}

検証と.pluginファイル化

最終段階では、まずclaude plugin validateで構造を確かめます。Cowork内などでこのコマンドが使えないときは、次の項目を手作業で点検します。

  • .claude-plugin/plugin.jsonが存在し、少なくともnameを含む正しいJSONである
  • nameがケバブケース(小文字・数字・ハイフンのみ)である
  • 参照しているディレクトリ(skills/など)が実在し、形式が合っている
  • 各スキルのディレクトリにSKILL.mdがある

claude plugin validateはClaude Code側のコマンドで、./my-pluginのようにディレクトリを渡して実行します。Validation passed with warningsは読み込めるが直す点がある状態で、--strictを付けると警告も失敗として扱えます。

claude plugin validate ./my-plugin

パッケージ化は、/tmpでzipを作ってから出力先にコピーする手順です。出力先へ直接書くと権限で失敗し、一時ファイルが残ることがあるためです。

cd /path/to/plugin-dir && \
  zip -r /tmp/plugin-name.plugin . -x "*.DS_Store" && \
  cp /tmp/plugin-name.plugin /path/to/outputs/plugin-name.plugin

ファイル名はplugin.jsonのnameに合わせます(code-reviewerならcode-reviewer.plugin)。チャットに出た.pluginファイルは、中身を見られるプレビューとして表示され、ボタンを押して受け入れる流れです。

cowork-plugin-customizer — 既存プラグインを自社向けに直す

もう1つのスキルは、すでにあるプラグインを自社のツールと手順に合わせる役を担います。起動すると、まず次のコマンドでプラグインの実体を探します。

find mnt/.local-plugins mnt/.plugins -type d -name "*<plugin-name>*"

見つからないときは、リモートコンテナで会話していると判断し、「プラグインのカスタマイズは現在デスクトップアプリのCoworkモードでのみ使えます」という趣旨のメッセージを返して中断します。

3つのモードの見分け方

次に、grep -rn '~~\w'でプラグイン内に~~で始まる置換点があるかを調べ、モードを決めます。

くらべる

カスタマイズの3モード

~~あり

汎用プラグインの設定

~~の置換点が残っている雛形です。~~JiraをAsanaに、~~your-team-channelを#engineeringに、といった形で実値に置き換えます。置換点があれば、利用者が別の部分を指定しない限りこのモードになります。

~~なし・箇所指定あり

部分的な調整

「コネクタを直したい」「スタンドアップのスキルを更新したい」のように、直す場所を言われたときです。該当箇所だけを読み、関係のない項目は提示しません。

~~なし・範囲指定なし

全般的な調整

プラグイン全体を読んで現状を把握し、何を変えたいかを利用者に尋ねます。

どのモードでも、プラグインやスキルの名前は変えません。ディレクトリ名・ファイル名・name欄の書き換えは禁じられています。利用者に見せる文章では~~や置換点という言葉を出さず、「プラグインができること」と「組織が使うツール」の言葉で話す指示もあります。

進め方は5つのフェーズ

手順

customizer のフェーズ

  1. 1

    フェーズ0: 意図の確認

    部分的・全般的な調整のときだけ行います。依頼に添えられた背景(例:「毎朝#eng-updatesで非同期スタンドアップをしている」)があれば後の回答に使い、なければ短い自由記述の質問を1つします。

  2. 2

    フェーズ1: 社内の知識源から集める

    チャット、文書、メールの接続先を検索し、使っているツール名、手順、チームの慣習(命名・ステータス・見積もりの尺度)、ワークスペースIDなどの設定値を集めます。

  3. 3

    フェーズ2: やることの一覧を作る

    調整の項目を、「Companyでのスタンドアップ準備の進め方を把握する」のように、技術用語を使わない文面で並べます。

  4. 4

    フェーズ3: 項目を片づける

    ユーザーの入力か検索結果に明確な答えがあれば確認なしで反映し、なければ質問します。答えがわからない・飛ばした場合は、値を変えず、雛形なら~~のまま残します。

  5. 5

    フェーズ4: MCPを探して接続する

    調整で判明したツールについて、MCPレジストリを検索し、未接続なら接続ボタンを出し、プラグインのMCP設定を更新します。

フェーズ1で社内の知識源を使うため、SlackやMicrosoft Teamsなどの接続先がないと、すべての項目を利用者への質問で埋めることになります。その場合、最後に「SlackやTeamsを接続すると、次回から答えを自動で見つけられます」という趣旨の一言を添えます。検索の型はsearch-strategies.mdにあり、GitHub/GitLab、Asana/Jira/Linear、Slack/Teams、Datadog/Grafana、Figma、Salesforce/HubSpotといった語の検索例が並んでいます。

MCPの探し方と設定ファイルの扱い

フェーズ4で使う道具は2つです。search_mcp_registryはキーワードの配列を受け取り、最大10件の候補(名前・説明・ツール一覧・URL・directoryUuid・接続済みかどうか)を返します。suggest_connectorsはdirectoryUuidsを受け取り、ユーザーが接続できるボタンを画面に出します。

カテゴリごとの検索語は表で決まっています。

カテゴリ検索語の例
project-management検索語の例asana, jira, linear, monday, tasks
software-coding検索語の例github, gitlab, bitbucket, code
chat検索語の例slack, teams, discord
documents検索語の例google docs, notion, confluence
crm検索語の例salesforce, hubspot, crm
data-warehouse検索語の例bigquery, snowflake, redshift

このほか、calendar・email・design-graphics・analytics-bi・wiki-knowledge-base・conversation-intelligenceのカテゴリがあります。

書き込み先の設定ファイルは、次の順で決まります。

  1. plugin.jsonにmcpServers欄があれば、そのパスのファイルを編集する
  2. なければプラグイン直下の.mcp.jsonを使う
  3. mcpServersが.mcpbファイル(同梱サーバー)だけを指しているなら、.mcp.jsonを新しく作る

URLを持たないディレクトリ項目もあります。エンドポイントを管理者が接続時に決める種類で、プラグインの設定側のサーバー名がディレクトリ項目の名前と一致すれば、URLが一致したのと同じ扱いになります。

同梱のサンプルcustomized-mcp.jsonは、github(HTTP、Bearer ${GITHUB_TOKEN})、asana(SSE)、slack、figma、datadog(DD-API-KEYとDD-APPLICATION-KEYのヘッダー)の5つを並べています。末尾にはrecommendedCategoriesというキーがあり、source-controlやproject-managementなどのカテゴリ名が列挙されています。

仕上げ — 要約と.pluginファイル

調整が終わると、調整後のディレクトリからsetup/を除いてzip化します。setup/は調整後に不要になるので、zipには入れません。

cd /path/to/plugin && \
  zip -r /tmp/plugin-name.plugin . -x "setup/*" && \
  cp /tmp/plugin-name.plugin /path/to/outputs/plugin-name.plugin

ファイル名は元のディレクトリ名のままで、coderならcoder.pluginです。利用者には、「Slackで調べてわかったこと」「文書で調べてわかったこと」「あなたの回答」の見出しで学習内容を分けた要約を見せ、接続できたMCPと、まだ接続が必要なMCPを手順つきで示します。

どちらから始めるか

迷ったときの判断を、材料別に分けると次のようになります。

手元にあるもの使うスキル
作りたい業務の構想だけがある使うスキルcreate-cowork-plugin
公開プラグインを試して、自社のツール名に直したい使うスキルcowork-plugin-customizer
自作プラグインのコネクタだけ差し替えたい使うスキルcowork-plugin-customizer(部分的な調整)
社外にも配るので、ツールの名前を固定したくない使うスキルcreate-cowork-plugin で、社外配布と伝える

最後の行について、create-cowork-pluginは~~の置換点を「社外の人も使うと利用者が明示した場合だけ」導入するよう指示しています。そのときはツール名をカテゴリ名で書き(「Jira」ではなく~~project tracker)、ルートにCONNECTORS.mdを置いて、カテゴリと置換点と選択肢(Slack/Teams/Discordなど)の対応表を載せます。社内専用なら、置換点を最初から作らないのが既定です。

つまずきやすい点

  • リモート環境では動かない: cowork-plugin-customizerはプラグインのマウント先(mnt/.local-pluginsとmnt/.plugins)を前提にしています。デスクトップアプリ以外の会話では、探索の段階で中断されます。
  • 名前は変えられない: 調整の過程でプラグイン名やスキル名を直したくなっても、スキルの指示では変更が禁じられています。名前を変えたいなら、create-cowork-pluginで作り直す形になります。
  • 値がわからないときは空のまま: 調整中に答えがなければ、既定値で埋めず元の値(雛形なら置換点)を残します。あとでgrep -rn '~~\w'をかけると、未設定の箇所を洗い出せます。
  • zipは/tmp経由: 出力先に直接書くと権限で失敗することがあります。

組織への配布は別の画面で管理する

この記事の2つのスキルが担当するのは、.pluginファイルを作るところまでです。作ったプラグインをTeamやEnterpriseの組織に配り、グループごとに見せる範囲を絞る設定は、管理者向けの別の仕組みです。手順はCoworkプラグイン管理の記事にまとめています。CIから公開したい場合はPlugins APIでの公開手順が参考になります。

まとめ

cowork-plugin-managementは、プラグインの設計から.plugin化までを対話で任せる土台です。ゼロから作るならcreate-cowork-plugin、公開プラグインを自社用に直すならcowork-plugin-customizerと覚えておくと選びやすくなります。どちらもCoworkのデスクトップアプリが前提なので、まずデスクトップでfindが通るかを確かめるのが最初の一歩です。

この記事を共有:XはてブLinkedIn

関連する記事

Cowork をもっと見る →