はじめに
Claude Codeのスキルやhooksを自分で作っていると、そのうち人に渡したくなります。そこで次のようなことに迷うはずです。
- 同僚にスキルを渡したいが、フォルダをコピーして配るのは面倒で、直したときに配り直せない
- プラグインにすればよいと聞いたが、スキルと何が違うのか、どこに何を置くのかがわからない
- GitHubに上げれば公開になるのか、公式の一覧に載せるには申請が要るのかがわからない
- 社内のチームはCodexも使っていて、同じものを両方で使いたい
この記事では、Claude Codeのプラグインを作り、配り、直したものを届けるところまでを、2026年11月10日に公式ドキュメントを読んで確かめた内容でまとめます。当社も、自社で使うスキルをプラグインにして、非公開のリポジトリからClaude CodeとCodexの両方に配っています。そこでつまずいたことも書きます。
プラグインとスキルの違い
スキルは、SKILL.md に手順を書いた1つの部品です。プラグインは、スキル、サブエージェント、hooks、MCPサーバーなどをまとめて、名前と版を付けた配布の単位です。
| スキル | プラグイン | |
|---|---|---|
| 中身 | SKILL.md と、使うスクリプトや資料 | スキル、サブエージェント、hooks、MCP、LSPなど |
| 置き場所 | ~/.claude/skills/ やプロジェクトの .claude/skills/ | マーケットプレイスから入れる |
| 呼び方 | /スキル名 | /プラグイン名:スキル名 |
| 配り方 | フォルダをコピーする、Gitで共有する | マーケットプレイスを追加して、入れる |
| 更新 | 配り直す | 版を上げてpushすると、利用者が更新できる |
自分1人で使うだけなら、スキルのままで足ります。複数の人やパソコンで同じものを使いたい、直したものを配り直したい、hooksやMCPの設定も一緒に渡したい、というときにプラグインにします。スキルが増えすぎたときの整理はスキルの整理の記事に書いています。
公開の仕方
作ったプラグインの出し方は、誰に使ってもらうかで決まります。
| 出し方 | 使える人 | 申請 | 向いている場合 |
|---|---|---|---|
| 公開リポジトリのマーケットプレイス | 誰でも | 要らない | 個人で作ったものを広く使ってもらう |
| 非公開リポジトリのマーケットプレイス | リポジトリをcloneできる人 | 要らない | 社内やチームだけで使う |
| Anthropicの公式ディレクトリ | Claudeの利用者 | 要る。審査がある | 製品として見つけてもらう |
公式ディレクトリに出す場合も、プラグインはGitHubのリポジトリから読み込まれます。まず自分のリポジトリで、入れて動くところまで作ってから申請します。
プラグインを作る
フォルダの作り方
最小のプラグインは、マニフェストの plugin.json と、スキルが1つあれば動きます。
review-kit/
├── .claude-plugin/
│ └── plugin.json
└── skills/
└── pr-check/
└── SKILL.md
{
"name": "review-kit",
"version": "1.0.0",
"description": "プルリクエストを出す前の確認をまとめたスキル集"
}
公式の作り方では、.claude-plugin/ の中に置くのは plugin.json だけです。skills/、agents/、hooks/hooks.json、.mcp.json は、プラグインのフォルダの直下に置きます。.claude-plugin/ の中に入れたスキルは読み込まれません。
手元で試す
作ったフォルダを指定して、Claude Codeを起動します。
claude --plugin-dir ./review-kit
この状態で /review-kit:pr-check と打てば、スキルが動くかを確かめられます。起動したままファイルを直したときは、/reload-plugins で読み直します。
配る前に、形が合っているかを確かめるコマンドもあります。
claude plugin validate ./review-kit
--strict を付けると、警告も失敗として扱います。社内で配る場合は、プルリクエストのたびにCIでこのコマンドを流しておくと、壊れた版を配らずに済みます。トラストバンクのSREの記事は、この形で社内のGitHub Actionsの規約をスキルにして配っています。
hooksとMCPのパス
hooksやMCPで、プラグインの中のスクリプトを呼ぶときは、${CLAUDE_PLUGIN_ROOT} から書きます。公式の説明によると、プラグインは入れたときに、版ごとのキャッシュのフォルダへコピーされます。プラグインの外にあるファイルを相対パスで読むスクリプトは、手元では動いても、入れた人の環境ではファイルが見つかりません。${CLAUDE_PLUGIN_ROOT} も版ごとに変わるので、そこに作業中のデータを書き込まないようにします。@yureki_labさんの記事も、保存のたびにlintをかけるhookで、このつまずきを書いています。
GitHubのマーケットプレイスで公開する
marketplace.jsonを置く
マーケットプレイスは、プラグインの一覧を書いた .claude-plugin/marketplace.json を持つリポジトリです。プラグインを1つだけ出すなら、プラグインと同じリポジトリに置けます。
{
"name": "review-tools",
"owner": { "name": "your-name" },
"plugins": [
{
"name": "review-kit",
"source": "./",
"description": "プルリクエストを出す前の確認をまとめたスキル集"
}
]
}
source は、プラグインのフォルダの場所です。1つのリポジトリに複数のプラグインを置くなら、./plugins/review-kit のように、それぞれのフォルダを指します。
これをGitHubにpushすれば、公開は終わりです。申請のフォームはありません。
使う人が入れる手順
使う人は、マーケットプレイスを追加してから、プラグインを入れます。
claude plugin marketplace add your-name/review-tools
claude plugin install review-kit@review-tools
@ の後ろに書くのは、marketplace.json の name です。リポジトリ名と違う名前を付けた場合は、name のほうを書きます。READMEには、この2行をそのまま載せておくと迷われません。
社内だけで配る
リポジトリを非公開にすれば、マーケットプレイスも非公開になります。公式の説明では、そのリポジトリをcloneできる人が使えます。社員のGitHubアカウントを組織のリポジトリに入れておけば、追加の仕組みなしで社内配布ができます。
当社もこの形です。非公開のリポジトリに、開発、資料づくり、SEOなどの社内のスキルを60個ほどまとめたプラグインを置き、各自のパソコンから入れています。
更新を届ける
公開した後に一番つまずきやすいのは、直したものが利用者に届かないことです。
versionを上げる
plugin.json に version を書いている場合、版を上げずにpushしても、利用者の手元は古いままです。公式の説明では、リリースのたびに版を上げるか、version を書かずにGitのコミットで追うか、のどちらかにします。
当社では、2026年9月にこれで失敗しました。スキルを1つ消したとき、変更履歴と package.json は1.18.0に上げたのに、Claude Codeが読む .claude-plugin/plugin.json は1.17.0のままでした。利用者の手元では消したはずのスキルが一覧に残り、Claude Codeがそのスキルの説明を根拠にして、もう使っていない手順を答えました。今は、変更履歴に「版は plugin.json でも上げる」と書き残し、Codex用の plugin.json も同じ版にそろうかを、変更のたびに確かめています。
自動更新の設定
公式の説明では、自動更新が既定でオンなのは、claude-plugins-official などのAnthropicの公式のマーケットプレイスと、claude.aiから追加したものです。自分で作ったマーケットプレイスはオフなので、版を上げても、利用者が更新するまでは届きません。利用者は次のコマンドで更新します。
claude plugin update review-kit@review-tools
更新したプラグインは、次にClaude Codeを起動したときか、/reload-plugins を実行したときに読み込まれます。claude plugin marketplace update review-tools は一覧を新しくするだけで、入れてあるプラグインは古い版のままです。
自動更新は、Claude Codeの中で /plugin を開き、Marketplacesの欄でマーケットプレイスを選んで、Enable auto-updateを選ぶとオンになります。社内で配るなら、最初に入れてもらうときに、これもオンにしてもらいます。カンリーの記事にも、更新は手で行う、という追記があります。
Anthropicの公式ディレクトリに申請する
Claudeの利用者に見つけてもらいたい場合は、Anthropicのディレクトリに申請します。公式の手順で確かめた条件は次のとおりです。
- 申請できるのは、Claudeの有料プラン(Pro、Max、Ultra、Team、Enterprise)の人。無料のアカウントでは申請できない
- 申請先は claude.ai/directory/manage
- どの版にも自動の検証とセキュリティの検査がかかり、新しい掲載は人が確認する
- 検証と申請のあいだはリポジトリが非公開でもよいが、掲載される前に公開する
当社は申請していないので、審査にかかる日数はわかりません。Claude Codeの公開の説明によると、ディレクトリはclaude.aiとCoworkで探す一覧で、1つの掲載がclaude.ai、Cowork、Claude Codeの利用者に届きます。ただし、対応表によると、claude.aiのチャットではサブエージェント、hooks、手元で動かすMCPサーバーは読み込まれません。claude.aiのチャットでも使ってほしいなら、主な処理をスキルに入れておきます。
なお、Anthropicの公式のマーケットプレイス claude-plugins-official は、ディレクトリの申請を受け付けていません。
同じプラグインをCodexにも出す
ChatGPTとCodexにも、プラグインの仕組みがあります。形は似ていますが、置き場所と使える部品が違います。
| 項目 | Claude Code | Codex |
|---|---|---|
| マニフェスト | .claude-plugin/plugin.json | ルートの plugin.json。.codex-plugin/plugin.json も読む |
| マーケットプレイス | .claude-plugin/marketplace.json | .agents/plugins/marketplace.json |
| 追加のコマンド | claude plugin marketplace add | codex plugin marketplace add |
| hooks | 使える | 公開ディレクトリには出せない。入れても自動では信頼されない |
| サブエージェント、コマンド | 使える | スキルに直す |
1つのリポジトリに、両方のマーケットプレイスを並べて置けます。クラスメソッドの記事では、Claude Code用に公開していたマーケットプレイスに、Codex用の marketplace.json と plugin.json を足して、両方から入れられるようにしています。CodexもClaude Code用のhooksのために CLAUDE_PLUGIN_ROOT を渡すので、hooksの設定を共用できたそうです。ただし、hookが [ で始まる文字を出すと、CodexがJSONとして読もうとして失敗した、というつまずきも書かれています。
当社では、Claude Code用のスキルを元にして、Codex用のフォルダを変換のスクリプトで作っています。手で2つを直すと、片方だけ直し忘れるからです。変換でしていることは次のとおりです。
- スキルの先頭の設定のうち、Codexが読まない項目(
disable-model-invocation、argument-hintなど)を外す - スキル名の
_を-に直す - 本文の「Claude Code」をCodexに、
WebSearchのようなClaude Codeの道具の名前を一般の言い方に直す plugin.jsonの版を、Claude Code用と同じにそろえる
Codex用のフォルダは手で直さない、直すのは元のスキルか変換のスクリプト、と決めています。
OpenAIの公開ディレクトリに出す場合は、Claudeのプラグインを申請する手順があります。Claude用のプラグインをそのまま上げると変換されますが、hooks、LSP、テーマなどは外し、サブエージェントとコマンドはスキルに直す必要があります。Claude側の掲載や審査の結果は引き継がれません。
入れる人が確かめること
プラグインは、入れた人のパソコンで、その人の権限で動きます。hooksは決まったタイミングでコマンドを実行し、MCPサーバーは外のサービスにつなぎます。人のプラグインを入れる前と、自分のプラグインを公開する前に、次を確かめます。
hooks/hooks.jsonに、どのタイミングで、どのコマンドが書かれているか.mcp.jsonに、どのサーバーを起動し、どこへつなぐかが書かれているかbin/に実行ファイルがあるか。ある場合、何をするものか
作る側は、READMEにこの3つを書いておくと、入れる人が判断しやすくなります。社内で配る場合も、スキルとhooksの変更はプルリクエストで人が見る形にしておきます。
公開している人の例
| 誰が | 何を | 出し方 |
|---|---|---|
| クラスメソッド | 作業管理と報告書づくりのプラグインを、Claude CodeとCodexの両方に | 公開リポジトリ |
| トラストバンク | GitHub Actionsの社内規約をスキルにして配る | 社内のマーケットプレイス |
| カンリー | チームのコマンドとサブエージェントを共有 | 社内のマーケットプレイス |
| Dawid Nitkaさん | 自分のパソコン間で同じプラグインを使うためのマーケットプレイスの雛形。版の番号は自動で上げる | 公開リポジトリ |
| Vercel | 自社サービス向けのスキル、コマンド、MCPを、Claude Code、Codex、Cursorなどにまとめて | 公開リポジトリ |
日本語で書かれた例は、社内やチームへの配布が中心でした。会社の中で同じ手順を全員に使ってもらうためにプラグインにした例が多く、個人が広く公開した例は少なめです。
まず作るなら
最初は、自分がよく使うスキルを1つプラグインにして、別のパソコンから claude plugin marketplace add で入れてみてください。そこで、入れる手順、更新の届き方、パスの書き方を一度通しておけば、社内配布も公開も同じ手順の延長でできます。

