株式会社ヘンリーでソフトウェアエンジニアをしているwarabiです。
今回はClaude Code Skillを社内に展開する際に選択したClaude Code Marketplaceの導入と、SkillのPlugin化による副次的な恩恵についてお話しします。
背景
ヘンリーの業務でClaudeCodeを今よりもっと活用するために、開発業務を全自動で行うOrchestrator型Skillの作成と、Skillのチーム展開に関する課題整理をこれまで行ってきました。
それぞれ詳細は以下のブログにまとめてあります。
チーム展開の課題を整理した結果、チームSkill展開について以下の方針を取りました。
個人SkillとチームSkillは別で管理する
Skillはdotfilesやエディタ設定と同じく、個人の作業効率を高めるための環境構築の一部として考える。
各自はSkillという個人の環境を改善していき、そのうえで作られたSkillや知見をチームに還元する。
チームに展開する汎用SkillはStarter Kitの位置づけにし、利用するかどうかは任意とする
Skillの作成についてはまだ十分な知見が溜まっていない。この状態でSkillの利用を必須とすると、どう更新していくか意見の衝突が起きやすくなりSkill作成・更新の停滞に繋がりかねない。
チームSkillは「Starter Kit」の位置づけにし、自身のSkill環境が用意できていない人向けの出発点とする。
方針が固まったので、今回はこのStarter Kitを具体的にどうやってチームに届けるかを考えます。
Claude Code Marketplace
結論から言うと、Claude CodeのMarketplace機能を使いSkillのチーム展開を行いました。
Claude Codeは公式のMarketplaceから様々なPluginが展開されており、利用者は好きなPluginを選択することで便利なSkillを簡単に導入することができます。
Figma, Linearなど外部サービス連携や、skill-creatorのような便利系など様々なPluginが公式から提供されています。
このMarketplace機能ですが、公式のMarketplaceだけでなくGitHubリポジトリを使うことで各自がMarketplaceを簡単に作成することができます。
Marketplaceとして認識させるために必要な設定ファイル、およびPluginフォルダを含めることでGitHubリポジトリをMarketplaceとして扱うことができます。
Marketplaceの登録もコマンド1発で済みます。
/plugin marketplace add [organizaion-name]/[repository-name]
設定ファイルなど詳細については公式ドキュメントを参考にしてください。
https://code.claude.com/docs/ja/plugin-marketplaces
補足説明: Pluginについて
新しくPluginというワードが出てきましたが、これは複数Skillや複数Agentなどを纏めて管理する単位と思っていただければ大丈夫です。
marketplace/plugins
├── github-pr // GitHub操作に関するSKillをまとめたplugin
│ └── skills
│ ├── review-pr
│ │ └── SKILL.md
│ └── triage-github-pr-comments
│ └── SKILL.md
├── dev-workflow // 開発系Skill,Agentをまとめたplugin
├── agents
│ ├── create-pr-agent.md
│ ├── ...
│ └── triage-review-agent.md
└── skills
├── dev
│ └── SKILL.md
├── ...
└── plan-implementation
└── SKILL.md
Skill, Agentの他にもhooksやsettingsの管理なども行えます。
https://code.claude.com/docs/ja/plugins
Marketplaceの利点
Marketplaceを使ったSkillのチーム展開にはいくつかの利点がありました。
GitHubでのSkill管理の流れと整合する
チーム管理とするStarter Skillは公開後もPullRequestが送られて成長していくことを前提としており、1つのリポジトリで管理する想定でした。
リポジトリをそのままMarketplaceとして登録できる機能はこの想定と合致しています。
自動更新機能がある
これまでのSkill作成の経験から、Skillは一度作ったら終わりではなくそこから育てていくものと私は認識しています。
定期的にSkillの更新を行う場合、その度にSkillを利用するメンバーに毎回手作業での更新を促すのは全員にとって手間があり現実的ではありません。
その点Marketplace機能は登録したリポジトリを監視する機能があり、更新があれば自動で各自の環境に反映をすることができます。
利用するPluginを取捨選択できる
Starter Kit自体を利用する・しないの判断は各自に任せていますが、Marketplace機能を使うとStarter Kitの中でも更に必要なPluginを選択してインストールできます。
またSkill開発者目線でも、利用者への影響を気にせず新しいPluginをMarketplaceに追加できる利点もあります。
これらMarketplaceが持つ機能の恩恵もあってチームへのSkill展開がアナウンスや勉強会での紹介だけで済み、想像より簡単に浸透させることができました。
Skillを直す時もPullRequestをマージすれば各自の環境に自動更新されるためアナウンスも不要となり、導入だけでなくSkill改善のコストも低くおさえることができています。
他に検討した案
Marketplaceの他に、いくつか検討した案についてそれぞれ見送った理由を書いておきます。
案1: 開発本体のリポジトリにSkillとして配置する
ヘンリーの開発環境はモノレポではなく、複数のリポジトリに同じSkillを配置する必要が出てきます。更新の同期が破綻する未来が見えていたので候補から外しました。
案2: ローカルの ~/.claude にcloneする
~/.claude には他のClaude設定ファイルが既に存在しており、それらを除外する手間がかかる- 最新版を取り込み直すたびにgit pullが必要になる
- pushしたくないローカル専用のSkillとコンフリクトする可能性がある
設定ディレクトリに配布物を混ぜること自体に抵抗を感じたというのが正直なところです。
案3: MDMを使った配布
Skillを配りたいだけの目的に対して仕組みが大げさすぎました。管理の複雑さも増すため候補から除外。
Marketplaceによる副次的な恩恵
またチームへの展開手段とは別で、Skill開発者向けの大きな利点がMarketplaceにはありました。
それは、Plugin化によるフォルダの整理です。
PluginによってSkillの境界を引ける
現状のClaude Codeでは単純にSkillを作成・管理する場合 ローカルの~/.claude/skills やプロジェクトの .claude/skills にフラットに配置する構造になります。
Skillの数が少ないうちはあまり問題になりませんが、Skillを作り込んでいくうちにその数は確実に増えていきます。
特にOrchestratorSkillのように親Skillが子Skillを呼び出す構成では、一つのワークフローに対して複数のSkillファイルが必要となります。今後もSkillを作り続けると、100を超えるSkillがフラットに並ぶ日も来るかもしれません。
この問題にMarketplaceのPluginという単位が効いてきます。関心事によってPluginを分けられるため、1つのPluginに含まれるSkill数を抑えつつ、全体の整理もつけやすくなります。
ローカル管理の場合（フラットな配置）
.claude/
├── agents
│ ├── create-pr-agent.md
│ ├── implement-agent.md
│ ├── plan-agent.md
│ ├── plan-review-agent.md
│ ├── review-agent.md
│ ├── triage-agent.md
│ ├── triage-execute-agent.md
│ └── triage-review-agent.md
└── skills
├── check-updates
│ └── SKILL.md
├── create-plugin
│ └── SKILL.md
├── create-pr
│ └── SKILL.md
├── dev
│ └── SKILL.md
├── implement
│ └── SKILL.md
├── improvement
│ └── SKILL.md
├── linear-manage
│ └── SKILL.md
├── linear-triage
│ └── SKILL.md
├── linear-triage-execute
│ └── SKILL.md
├── linear-triage-review
│ └── SKILL.md
├── lint-settings
│ └── SKILL.md
├── memory-manager
│ └── SKILL.md
├── plan-implementation
│ └── SKILL.md
├── retrospective
│ └── SKILL.md
├── review-lint-rules
│ └── SKILL.md
├── review-pr
│ └── SKILL.md
└── slack-notify
└── SKILL.md
Marketplace管理の場合（Plugin化による整理）
marketplace/plugins
├── dev-workflow
│ ├── agents
│ │ ├── create-pr-agent.md
│ │ ├── implement-agent.md
│ │ ├── plan-agent.md
│ │ ├── plan-review-agent.md
│ │ ├── review-agent.md
│ │ ├── triage-agent.md
│ │ ├── triage-execute-agent.md
│ │ └── triage-review-agent.md
│ └── skills
│ ├── create-pr
│ │ └── SKILL.md
│ ├── dev
│ │ └── SKILL.md
│ ├── implement
│ │ └── SKILL.md
│ ├── linear-manage
│ │ └── SKILL.md
│ ├── linear-triage
│ │ └── SKILL.md
│ ├── linear-triage-execute
│ │ └── SKILL.md
│ ├── linear-triage-review
│ │ └── SKILL.md
│ └── plan-implementation
│ └── SKILL.md
├── github-pr
│ └── skills
│ ├── review-pr
│ │ └── SKILL.md
│ └── triage-github-pr-comments
│ └── SKILL.md
├── retrospective
│ └── skills
│ ├── improvement
│ │ └── SKILL.md
│ └── retrospective
│ ├── SKILL.md
│ └── template.md
├── sentry-triage
│ ├── agents
│ │ └── sentry-investigate-agent.md
│ └── skills
│ ├── sentry-investigate
│ │ ├── SKILL.md
│ │ └── template-result.md
│ └── sentry-triage
│ └── SKILL.md
└── slack-notify
└── skills
└── slack-notify
└── SKILL.md
dev-workflowには開発フロー全体のSkillが、github-prにはPRレビュー関連が、といった具合に関心事で区切られています。フラットなskillsフォルダに全部を並べていた頃と比べると、どのSkillがどの文脈に属するのかが構造として表現されるようになりました。
Skill同士の依存関係が組めるわけではなくSkillの記述次第ではPluginの境界を越えた呼び出しも行えてしまうため、これはあくまでファイル整理上の利点ではあります。ただ、フラットに置くことしかできなかったSkillにPluginという1段区切りを設けることができるのは、Skill開発者にとって大きなメリットとなります。
おわりに
Claude Code Marketplaceを導入したことで、Skillのチーム展開における配布と更新の課題をシンプルに解決できました。GitHubリポジトリとの親和性が高く、既存の開発フローに自然に組み込むことができています。
そして当初は配布手段として検討したMarketplaceでしたが、Plugin単位でSkillの境界を引けるという副次的なメリットも得られました。Skillの数が増えるほど、この整理の恩恵は大きくなると感じています。
