はじめに
Claude Code を使い込んでいくと、便利な MCP サーバー設定やカスタムコマンドが手元に増えていきます。チームのみんなにも使ってほしいのに、設定ファイルを共有するのは意外と面倒です。
そこで活用したいのがプラグイン機能です。MCP サーバー設定、カスタムコマンド、スキルなどをひとつのパッケージにまとめて、チームで共有できます。各メンバーがコマンド一発で導入できるため、「設定ファイルをコピーして、ここを書き換えて...」といったやり取りから解放されます。
この記事では、チーム専用のプラグインマーケットプレイスを構築し、プラグインを共有する方法を紹介します。
なぜプラグインで共有するのか
Claude Code の設定は個人の .claude/ ディレクトリや settings.json に保存されます。便利な設定を作っても、チームメンバーに共有する際には「このファイルをあのディレクトリに追加して…」と説明することになりがちです。
プラグインとしてパッケージ化すると、この問題がきれいに解決します。
-
/plugin install一発でインストールできる - 各自が必要なプラグインだけを選んで導入できる
- Git 管理で変更履歴が追える
- チーム全体で同じツールセットを使える
マーケットプレイスの構築
構築場所の選択
マーケットプレイスを置く場所として、プロダクトのコードベース内に置くか、専用リポジトリを作るかの2択があります。
| 方式 | メリット | デメリット |
|---|---|---|
| コードベース内 | 通常のレビュープロセスに乗せられる | ローカル編集時に Git 差分が発生する |
| 専用リポジトリ | プラグインの調整・実験がしやすい | レビュー体制を別途整える必要がある |
実際に運用してみると、プラグインの調整や実験をする機会は意外と多いです。コードベース内だと、ブランチを切り替えるたびに stash が必要だったり、プラグインの変更がプロダクトのコミット履歴に混ざったりと、細かいストレスが積み重なります。
個人的には専用リポジトリを作る方式をおすすめします。プラグインの開発サイクルとプロダクトの開発サイクルを分離できるため、気軽に試行錯誤できます。
ディレクトリ構成
マーケットプレイスの基本的な構成を見てみましょう。
my-team-marketplace/
├── .claude-plugin/
│ └── marketplace.json
├── plugin-a/
│ └── .claude-plugin/
│ └── plugin.json
├── plugin-b/
│ └── .claude-plugin/
│ └── plugin.json
└── ...
ルートの .claude-plugin/marketplace.json がマーケットプレイス自体の定義で、各サブディレクトリが個別のプラグインになります。プラグインが増えてきたらカテゴリごとにディレクトリを切って整理するのも良いでしょう。
最初のプラグイン: plugin-dev
マーケットプレイスを作ったら、真っ先に plugin-dev を用意することをおすすめします。これは「プラグインを開発するためのプラグイン」で、いわばプラグイン開発の土台です。
Anthropic 公式の plugin-dev をフォークして、チームの好みに合わせて調整すると良いでしょう。plugin-dev の詳細については以下の記事で解説しています。
plugin-dev を導入しておくと、以降のプラグイン作成が驚くほど楽になります。「〇〇するプラグインを作って」と Claude に頼むだけで、必要なファイル構成を自動生成してくれます。プラグイン開発の敷居がぐっと下がるので、チームメンバーが自発的にプラグインを作ってくれるようにもなります。
作成したプラグインの例
実際にチーム向けに作成したプラグインをいくつか紹介します。どんなものをプラグイン化すると便利か、参考にしてみてください。
MCP サーバー設定
Notion MCP や Figma MCP など、チームで共通して使う MCP サーバーの設定をプラグイン化しました。
MCP サーバーの設定は地味に面倒です。公式ドキュメントを探して、自分の環境に合った導入方法を見つけて作業しなければなりません。これをプラグインにまとめておくと、新メンバーのオンボーディングが格段にスムーズになります。
コミット分割コマンド
変更を機能単位で分割してコミットするカスタムコマンドです。
チームでコミットメッセージの規約を定めていても、人によって解釈はブレるものです。コマンドの中に規約を埋め込んでおけば、Claude がそれに従ってメッセージを生成してくれるため、チーム全体で一貫したコミット履歴を保てます。
Notion チケット作成スキル
会話の中で出てきたタスクを Notion のチケットとして登録するスキルです。
「これ Notion にチケット作成しといて」と言うだけで、Claude が会話の文脈からタイトルや説明を自動生成してくれます。実装中に「あ、これ後で直さなきゃ」と思ったことを、その場でチケット化できるのが便利です。
運用のポイント
プラグインの粒度
プラグインは小さめの粒度で作っておくのがコツです。
「便利だからみんな入れて」と言って巨大なプラグインを押し付けると、使わない機能まで抱え込むことになります。必要な機能だけを選んで導入できる状態にしておくと、チームメンバーからの抵抗感が少なくなります。
たとえば Notion MCP と Figma MCP は別のプラグインに分けておくと、Notion だけ使いたい人、Figma だけ使いたい人、それぞれのニーズに対応できます。
チームメンバーの導入方法
チームメンバーは以下の手順で導入できます。
まず、マーケットプレイスを追加します。
/plugin marketplace add your-org/your-marketplace
あとは好きなプラグインをインストールするだけ。
/plugin install plugin-name@your-org/your-marketplace
マーケットプレイスを一度追加してしまえば、以降は /plugin メニューから視覚的にプラグインを選べます。
まとめ
Claude Code のプラグイン機能を使うと、個人の便利設定をチームの共有資産に変えられます。
ポイントをおさらいします。
- 専用リポジトリでマーケットプレイスを作成する
- plugin-dev を真っ先に用意して、プラグイン開発の土台を整える
- プラグインは小さい粒度で作成し、必要なものだけ選んで導入できるようにする
「便利な設定を作ったけど、共有するのが面倒で結局自分だけで使っている」という状況は、チームにとってもったいないことです。プラグインという形でパッケージ化しておけば、チーム全体の開発体験を底上げできます。
Discussion