こんにちは、サーバーサイドグループのマネージャーの鬼木です。
今回は、社内向けに Claude Code のプラグインマーケットプレイス を作り、各自が個人環境で育てていたSkillを部署横断で共有できるようにした取り組みを紹介します。
背景：個人で作ったSkillの共有の仕組みがなかった
Claude Code を使っていると、自分の業務に合わせたSkill（特定の観点でコードレビューする、仕様の叩きを詰める、など）を作りたくなります。実際わたし達のチームでもいくつか作っていました。
ただ、これらは各自の ~/.claude 配下にローカル保存されるだけで、他のメンバーが使う手段がありません。隣の人が便利なSkillを作っていても気づけず、似たものを別々に作り直す「車輪の再発明」も起きていました。これを口頭での共有に頼らず、仕組みで解決したいと考えていました。
そんな時に、Claude Code で 社内向けのマーケットプレイスを作れる ことを知り、共有の仕組みを作れそうだと考えたのがきっかけです。
Claude Code のマーケットプレイス機能とは
簡単に仕組みを説明します。Claude Code のマーケットプレイスは、GitHub リポジトリそのものを配布元にできる 機能です。リポジトリに 2 種類の JSON を置くだけで成立します。
.claude-plugin/marketplace.json— マーケットプレイス全体のプラグイン一覧（カタログ）- 各プラグインの
.claude-plugin/plugin.json— そのプラグイン単体のメタ情報
利用者側は、リポジトリを一度登録すれば一覧から検索・インストールできます。
# マーケットプレイスを登録（初回のみ）
/plugin marketplace add {GitHub organization}/claude-code-marketplace
# プラグインをインストール
/plugin install go-code-review-oniki@yappli-marketplace
Claude Code のマーケットプレイスには多くのメリットがありますが、特に以下のようなところから社内共有の仕組みとして有用と感じ、導入しました。
- Git で管理できる — 変更履歴・レビュー・差分がそのまま Git に乗ります。他の人が作った
SKILL.mdの中身自体を参考にできることも利点です。 - 権限が Git（GitHub）の権限とイコールになる — セキュリティ面でもこれが大きな利点でした。誰が閲覧・追加・変更できるかは、リポジトリのアクセス権限そのもので決まります。社内リポジトリにしておけば社外からは見えませんし、書き込みも PR・ブランチ保護といった既存の仕組みで制御できます。Skill配布のためだけに新しい権限管理を用意する必要がなく、普段の開発と同じルールに乗せられます。
- Skillを開発リポジトリとは別管理にしつつSkillを紐づけることができる — 開発リポジトリの .claude/settings.json に、extraKnownMarketplaces（社内マーケットプレイスの登録）と enabledPlugins（使うプラグインの有効化）を設定することで、そのリポジトリを開いた新しいメンバーは、自分でインストール操作をしなくても対象の Skill を使用できます。また、Claude Codeマーケットプレイスでは、社内（サードパーティ）のマーケットプレイスは既定では自動更新が無効ですが、extraKnownMarketplaces のエントリに autoUpdate: true を付けておけば、各メンバーが手動で更新しなくても最新が取り込まれます（手動で更新する場合は /plugin marketplace update）。そのため例えば特定のレビューSkillを開発リポジトリに紐づけることで、新しいメンバーの開発時に自動でそのSkillが使えるようにすることができるなど、開発の立ち上がりをフォローアップすることにも役立つと思いました。
作ったもの：社内マーケットプレイスの構成
仕組み自体はシンプルなのですが、いざ社内共有用に作ろうとした時にディレクトリのテンプレートなどは特に見つからなかったため、どういった構成にするかは迷ったポイントでした。公式ドキュメントは機能の説明が中心で、「チームで運用するときの型」は自分達で決める必要があります。そこでまず、迷わず追加できる規約を整えるところから始めました。
ディレクトリ構成
第1階層を「対象サービス」と「対象ドメイン」の2つに分けています。
plugins/
services/ # サービス単位のプラグイン
yappli/
backend/go-code-review/oniki/
pdm/spec-tools/employee1/
infrastructure/cfn-lint/employee2/
domains/ # サービスに紐づかないドメイン単位
atlassian/workflow/employee3/
qa/create-e2e-test-case/qa/
分類はシンプルで、第1階層は services と domains の2つだけです。
services… 特定のプロダクトに関わるSkillを置く場所です。プロダクトごとにディレクトリを分けます。例えば自社が「勤怠管理サービス」と「ECサイト」を提供しているとすると、services/kintai/...、services/ec/...のように分け、その配下にそれぞれのサービスのコードレビューや仕様確認のSkillを置きます。domains… 特定のプロダクトに依存しない、領域ごとのSkillを置く場所です。どのサービスでも使えるテーマごとにディレクトリを分けます。例えばオンボーディングやインシデント対応であれば、domains/onboarding/...、domains/incident-response/...のように置きます。
末端のディレクトリは 作成者（author）単位 です。個人名でもチーム名でも、shared でも構いません。
ここで一番考えたのが分類の軸です。ロール単位やプロジェクト単位で切ると一見わかりやすいのですが、組織やプロジェクトは変わりやすく、ディレクトリの引っ越しが頻発します。一方サービスやドメインは比較的変化しにくいため、サービス・ドメイン単位 を採用しました。長く運用しても破綻しにくい軸を選んだ、という判断です。
必須ファイルと登録方法
プラグインには .claude-plugin/plugin.json を必須とし、Skill共有がメイン用途なので skills/SKILL.md を置く構成を基本にしています。plugin.json には name / description / version / author を必須フィールドとして定めました。
そして全プラグインを marketplace.json に登録します。name は {scope}-{目的}-{author} という命名規則に統一しました。
{ "name": "yappli-go-review-oniki", "source": "./plugins/services/yappli/backend/go-code-review/oniki", "description": "Yappliバックエンド(Go)のコードレビュー。masterとの差分に対して複数観点で並列レビューし、統合された指摘リストを出力する。", "keyword": ["backend", "server", "golang"] }
細かい点ですが、検索対象が name / displayName / keyword のみで description は検索に効かない、という仕様があります。そのため keyword には name に出てこない語（例: golang, server）を入れる、といった運用上の勘所もルール化しておきました。
追加の手間を小さくする工夫
この取り組みで一番こだわったのが、「プラグインを追加するハードルをどこまで下げられるか」です。いくら土台を作っても追加の手間が重ければ誰も使ってくれないと考えたため、AI friendlyにすることも意識して設計しました。
目指したゴールは、GitHub の中身を一切知らなくてもSkillを追加できる状態です。追加する人がディレクトリ規則や JSON フォーマットを覚える必要はないはずだと考え、初期設計の段階からディレクトリやファイルのフォーマット、そして CLAUDE.md の書き方を意識し、AI（Claude Code）が迷わずに作業できるように設計しました。
具体的な工夫は、リポジトリに置くドキュメントの役割を 読み手別に分けた ことです。
- README.md — human readable を意識。利用者向けに「登録 → 検索 → インストール → 更新」の使い方を書く。
- CLAUDE.md — AI friendly を意識。ディレクトリ構成・必須ファイル・命名規則・
marketplace.jsonのフォーマット・PR 前の確認手順を、Claude Code が読んで実行できるよう構造化して書く。
実際には、利用者はこのリポジトリで Claude Code を起動し、こう指示するだけです。
「○○のSkillをプラグインとして追加して」
すると Claude Code が CLAUDE.md を参照し、
- 規約に沿った正しいディレクトリにファイルを配置し
plugin.jsonを必須フィールド付きで生成しmarketplace.jsonに命名規則どおりのエントリを追記しclaude plugin validateで構成を検証する
ところまで、自動でやってくれます。つまり CLAUDE.md 自体が「追加作業の自動化スクリプト」のような役割 を果たしています。リポジトリ構造を覚えるコストをドキュメントとAIに肩代わりさせた、というのがこだわりポイントです。
参考までに、実際に置いている CLAUDE.md と README.md を載せておきます。CLAUDE.md は Claude Code が構成を組むための規約（ディレクトリ・必須フィールド・命名規則）を、README.md は人が読む使い方を、それぞれに寄せて書き分けています。
CLAUDE.md（実物）
# CLAUDE.md Yappli社内用 Claude Code マーケットプレイスのリポジトリ。スキルやプラグインを社内で共有するためのもの。 ## ディレクトリ構成 ``` plugins/ services/ # サービス単位のプラグイン {サービス名}/ {領域}/ {pluginの目的}/ {author}/ domains/ # サービスに紐づかないドメイン単位のプラグイン {ドメイン名}/ {pluginの目的}/ {author}/ ``` - 第1階層は `services`（対象サービス）と `domains`（対象ドメイン）の2つ - `services` の例: yappli, yappli-crm, webx - `domains` の例: hiring, tech-blog, onboarding, incident-response - `{author}` は個人名でもチーム名でも `shared` でもよい - ロール単位やプロジェクト単位ではなく、サービス・ドメイン単位で分類する（変更可能性が低いため） ## 必須ファイル - `.claude-plugin/plugin.json` — 全プラグインで必須 - `skills/SKILL.md` — スキルを共有するプラグインで必要（基本的にスキル共有がメインの用途） ### plugin.json の必須フィールド | フィールド | 説明 | |-----------|------| | `name` | プラグイン名 | | `description` | プラグインの説明 | | `version` | バージョン。指定がなければ `"1.0.0"` | | `author` | 作成者。オブジェクト形式: `{"name": "作成者名"}` | ## marketplace.json `.claude-plugin/marketplace.json` にプラグインを登録する。 ### フィールド | フィールド | 必須/推奨 | 説明 | |-----------|----------|------| | `name` | 必須 | `{scope}-{pluginの目的}-{author}` の形式。`{author}` は個人名・チーム名・`shared` など。例: `yappli-go-review-oniki` | | `source` | 必須 | プラグインディレクトリへの相対パス | | `description` | 推奨 | 日本語で1〜2文。何に対して何をするかを簡潔に | | `keyword` | 推奨 | `name` に含まれない検索用キーワードを中心に入れる | `category`, `author`, `tags` は記載不要（`tags` は検索対象にも表示にも影響しない）。 ### エントリの例 ```json { "name": "yappli-go-review-oniki", "source": "./plugins/services/yappli/backend/go-code-review/oniki", "description": "Yappliバックエンド(Go)のコードレビュー。masterとの差分に対して複数観点で並列レビューし、統合された指摘リストを出力する。", "keyword": ["backend", "server", "golang"] } ``` ### 補足: 表示と検索の仕様 - `displayName` がある場合は `name` より優先的に表示される - 検索対象は `name`, `displayName`, `keyword` のみ（`description` は検索対象外） - `category` は表示上のグルーピングにのみ影響する ## PR前の確認 - `claude plugin validate <プラグインディレクトリのパス>` を実行してプラグインの構成を検証する - `marketplace.json` の `plugins[].name` が既存エントリと重複していないことを確認する
README.md（実物・一部抜粋）
# claude-code-marketplace Yappli社内用の Claude Code プラグインマーケットプレイスです。コードレビュー、ドキュメント作成支援などのスキルを共有・利用できます。 対象: 開発部メンバー（エンジニア以外も含む） ## 使い方 ### 1. マーケットプレイスの追加 Claude Code で以下を実行し、マーケットプレイスを登録します（初回のみ）。 ``` /plugin marketplace add {GitHub organization}/claude-code-marketplace ``` ### 2. プラグインの検索 ``` /plugins ``` プラグイン一覧が表示されます。Search 機能でキーワード検索も可能です（検索対象: name, displayName, keyword）。 ### 3. プラグインのインストール 一覧から選択するか、名前を指定してインストールします。 ``` /plugin install go-code-review-oniki@yappli-marketplace ``` ### 4. マーケットプレイスの更新 GitHub上のこのリポジトリに追加された最新のプラグインを参照できるようにするには、以下を実行します。 ``` /plugin marketplace update yappli-marketplace ``` ## プラグインを追加したい場合 このリポジトリ上で Claude Code を起動し、以下のように指示してください。 ``` 「○○のスキルをプラグインとして追加して」 ``` CLAUDE.md にディレクトリ構成・命名規則・marketplace.json のフォーマットがまとめられており、Claude Code が自動的に参照して適切な構成でプラグインを作成します。 ### 運用ルール - `main` ブランチへの直 push は禁止です - CI で簡単な validation チェックを設定しています - 普通に PR 作成 → マージ で追加していただければと思います - コードではないため、approve は必須化していません。セルフマージで OK です
運用ルールもあえて軽くしました。
mainへの直 push は禁止（PR 経由のみ）- CI で簡単な validation チェックのみ
- コードではないので approve は必須化せず、セルフマージで OK
レビュー必須のような重いフローにすると追加が止まると考え、最低限の安全装置だけ残し、あとは気軽に出せることを優先しました。
実際に集まったプラグイン
立ち上げから少し経ちましたが、ありがたいことに複数チームからプラグインが集まり、部署横断で活用が広がっています。
| 作成者 | 分類 | プラグイン | 内容 |
|---|---|---|---|
| oniki | services / backend | go-code-review | Go サーバーサイドのコードレビュー |
| employee1 | services / pdm | spec-tools | PdM 向け仕様レビュー支援 |
| employee2 | services / infrastructure | cfn-lint | CloudFormation テンプレート検証 |
| employee3 | domains / atlassian | workflow | Jira / Confluence 操作ワークフロー |
| qa | domains / qa | create-e2e-test-case | PR から E2E テストケースを導出 |
振り返り（うまくいったこと / これから）
うまくいったことは次の3点です。
- 複数チームからプラグインが集まった — backend / PdM / QA / インフラ / Atlassian と横断で広がった
- 追加の手間が小さい — CLAUDE.md を Claude Code が参照するため「○○を追加して」で構成が整う
- 運用ルールを軽くできた — セルフマージ運用で参加障壁を下げられた
一方で、運用してみて気づいたこともあります。例えば、新たなプラグインを追加した時に、チーム内なら一声かければ済みますが、チームを超えて使用できるようなものだと共有コストがかかるため、main にマージされたら自動で Slack チャンネルに通知を流せると良いと思いました。
このように、似たSkillが増えてきたときの整理ルールなども含め、まだまだ 育てていくフェーズ だと思っています。
最後に
ヤプリでは、このように Claude Code をはじめとした AI ツールを業務に取り入れ、自分達で開発体験を改善していくエンジニアを募集しています。こうした取り組みに興味を持たれた方は、ぜひカジュアル面談にお越しください！
