Claude Codeのプラグインマーケットプレイスに、無料で自作プラグインを公開する。それだけで案件の問い合わせが来るようになりました。正確に言うと、公開から5週目に初めてXのDMで「うちの社内向けにカスタム版を作ってほしい」という相談が来て、そこから受託につながった、という話です。
有料販売ではありません。無料公開して認知を取り、本命の受託・顧問契約に送客するという設計。この記事では、その仕組みと、私が実際に3つプラグインを公開して分かった手応え・失敗をまとめます。
結論:プラグインは商品ではなく「名刺兼サンプル」として使う
先に結論を言うと、Claude Codeプラグインを副業の直接収益源にするのは筋が悪いです。理由は単純で、公式マーケットプレイスは基本無料が前提の文化だから。有料課金の仕組みも標準では用意されていません。
じゃあ何のために作るのか。答えは**「あなたが何を作れる人か」を、口で説明せずに証明するため**です。
2026年8月時点で、Claude Codeのプラグインは公式ドキュメントによると「skills(スラッシュコマンド)、subagents、hooks、MCPサーバー、LSPサーバー」をまとめた単一パッケージとして配布できる仕組みになっています。つまり1つのプラグインには、あなたの設計思想・コード品質・ドキュメント力・ニッチ理解が全部詰まっている。ポートフォリオとして極めて情報量が多いんです。
これを「サンプル」として使い、本命は月10〜30万円の受託や月額顧問に送客する。この2段構えが今回の骨子です。
なぜ2026年後半にこのルートが成立するのか
プラグインマーケットプレイスは2025年10月に正式公開されて以降、急速に拡大しました。あるディレクトリサイトによれば、2026年8月時点で登録されているプラグインは数百、スキルは数千規模。個人が公開したものも多数含まれます。
面白いのは、この数の増加が発見性の低下を招いていることです。「テストしたら11本中4本しか使い物にならなかった」というレビュー記事も出ていて、ユーザーは「誰が作ったか」でフィルタするようになってきた。ここに個人開発者が入り込む余地があります。
もうひとつ大きいのは、Anthropic自身が公式ドキュメントで「マーケットプレイス上のプラグインが意図通り動くことは検証できない」と明言している点。裏返せば、動作保証付き・サポート付きのカスタム版を提供する人に対する潜在需要が構造的に生まれているということです。
企業側から見ると「無料の◯◯プラグイン、うちの環境で動かないんですが」となったときに、GitHubのissueで待つより、作者に直接発注したほうが早い。ここが受注ルートになります。
送客が回るプラグインのテーマ選び
テーマ選定を間違えると、いくらDL数が伸びても仕事につながりません。私は最初、汎用的なコミット支援プラグインを作って公開しましたが、これは失敗でした。DL数はそこそこ出たものの、問い合わせはゼロ。理由は明白で、「これが動かない人」に予算がないからです。
送客が回るテーマの条件は3つあります。
- 業種・業務領域が特定できる(例:医療系の電子カルテ検証、会計事務所の申告書チェック)
- そのプラグインを必要とする人が、社内に予算裁量を持っている
- 汎用化しきれない部分が必ず残る(=カスタム開発の余地がある)
例えば「PDF請求書からfreee用の仕訳CSVを生成するプラグイン」なら、経理担当者が触り、経営者に「これ良さそう、社内用にカスタムしてほしい」と話が上がる。これが送客経路です。
逆に「コードレビューを厳しくするプラグイン」みたいな汎用開発者向けは、GitHubのスター数は伸びるけど発注につながりません。使う人にお金がないからです。厳しい話ですが、副業として組むなら「誰が金を出せるか」から逆算するしかないんですよね。
最小構成のプラグインを作る手順
実際に最小構成でプラグインを作ってみます。ここでは「議事録Markdownから決定事項だけを抽出してNotion用のフォーマットに変換する」というスキル1本入りのプラグインを例にします。
まずディレクトリ構成はこんな形になります。
my-meeting-plugin/
├── .claude-plugin/
│ └── plugin.json
└── skills/
└── extract-decisions/
└── SKILL.mdplugin.jsonに最小のメタデータを書きます。
{
"name": "meeting-decisions",
"version": "0.1.0",
"description": "議事録から決定事項だけを抽出しNotion形式に変換",
"author": {
"name": "Yasuyuki Handa",
"url": "https://example.com"
}
}次にSKILL.md本体。ここが実質的な中身です。
---
name: extract-decisions
description: 議事録Markdownを読み、決定事項のみをNotionテーブル形式に変換する
---
# 決定事項抽出スキル
## 入力
ユーザーが指定した議事録ファイル (.md)
## 手順
1. ファイル全体を読み込む
2. 「決定」「承認」「合意」「Action」の語を含む文を抽出
3. 各項目を「決定内容 / 担当 / 期限」の3列に整形
4. Notionのインラインテーブル記法で出力
## 出力例
| 決定内容 | 担当 | 期限 |
|---|---|---|
| 新料金プランは10月開始 | 田中 | 2026-09-30 |マーケットプレイス用のリポジトリを別に作り、.claude-plugin/marketplace.jsonにプラグインを登録すれば、公式ドキュメントの手順通りGitHubにpushするだけで配布できます。ユーザー側は/plugin marketplace add <あなたのGitHub URL>で追加できる形。
コード量としては拍子抜けするほど少ないです。むしろ勝負はSKILL.mdの中身、つまりプロンプト設計と業務理解のほうにあります。
READMEを「発注書のたたき台」にする書き方
プラグインを公開しただけでは問い合わせは来ません。READMEを「発注の入り口」として設計する必要があります。私が3つ公開してみて、問い合わせが来たREADMEには共通点がありました。
「できないこと」と「カスタム対応可」を明示していたことです。
具体的にはREADMEの下部に、こういうセクションを置きます。
## このプラグインの制限
- 対応する議事録フォーマットは Markdown のみ (Word/PDF は非対応)
- Notion 以外の DB (Airtable, kintone 等) には未対応
- 日本語以外の議事録は動作未検証
## カスタム開発について
上記の制限を外した社内版が必要な場合、個別対応します。
実績: 中小SaaS企業向けに kintone 連携版を納品 (2026年7月)
お問い合わせ: [フォームURL]これは営業文ではなく、ユーザーへの誠実な情報開示として書きます。ただしそこに問い合わせ導線を自然に埋め込む。効果は想像以上に大きく、私の場合3件中2件の問い合わせがこのセクション経由でした。
もう一点、READMEの冒頭に「なぜ作ったか」の1段落を必ず入れます。技術ブログの延長線として読まれるので、ここで人格が出るとそのままファン化する。ここは正直、コードより時間をかける価値があります。
集客導線を3層で組む
マーケットプレイスに置いただけでは埋もれます。私が試して効いたのは、公開直後に3つの導線を同時に打つやり方です。
1つ目はXでの公開告知。ただし「作りました」だけでは伸びません。「議事録から決定事項だけ抜くのを毎週やってて、Claude Codeプラグイン化した」のように、具体的な業務痛点から入る。実際に私が投稿した中で一番伸びたのはこの型でした。
2つ目はZenn/Qiitaへの技術記事。プラグインの中身を解説する記事を、公開と同時にセットで出します。検索流入は遅効性ですが、半年経つと安定して読まれ続けます。実際、私の1本目の記事は3ヶ月後のほうがDL経由の問い合わせが多かったです。
3つ目はプラグインディレクトリサイトへの登録。claudemarketplaces.comのような外部ディレクトリが複数あり、GitHubから自動収集されるものと申請制のものが混在しています。申請制のところは意外と埋まっていないので、初期発見性を上げるのに効きました。
3つ全部やっても、初月のDL数は数十〜百のオーダーだと思います。それでも「刺さる人にだけ届けばいい」設計なので、月1〜2件の問い合わせが来れば十分成立します。
問い合わせが来てからの単価設計
問い合わせが来たら、そこからは通常の受託と同じ流れです。ただしプラグイン経由の案件には特有の単価感があります。
私の実感ベースでは、社内カスタム版の初期開発で15〜40万円、月額サポート契約に転換すると月2〜5万円くらいのレンジ。これは公式に相場があるわけではなく、あくまで自分と周囲の個人開発者に聞いた範囲の話です。目安として捉えてください。
重要なのは、プラグインが既に動いているので、要件定義の工数が激減すること。「このプラグインの、この挙動を、こう変えたい」という具体的な会話からスタートできるので、通常の受託より見積もりが速く、受注確度も高い。ここが最大の強みです。
逆に、初期の見積もりで安易に値引きすると、あとで月額転換の交渉がしにくくなります。初期は相場感で通し、代わりに「本番導入まで伴走します」といったサポート範囲で価値を積む方が長続きしました。
OSS公開で消耗しないための線引き
最後に、これは3ヶ月やって痛感した話です。無料プラグインを公開すると、issueやDMで「動かない」「機能追加してほしい」という声が来ます。全部対応していると本業も副業案件も回らなくなる。
私が設定した線引きはシンプルで、**「無料で答えるのはドキュメントの誤り指摘だけ」**と決めました。機能追加やカスタム対応はすべて有償対応の案内に一本化する。これをREADMEに明記しておくと、ユーザー側も納得して発注に切り替えてくれます。
OSSの善意と、副業の収益は両立します。ただし境界を最初に引かないと、善意のほうに時間を食い尽くされる。ここだけは公開前に決めておいた方がいいです。
プラグインは営業資料の代わりになる
Claude Codeプラグインを副業に組み込むというのは、要するに営業資料の代わりにコードを置くという発想です。ポートフォリオサイトを作るより、実際に動くプラグインが1本あるほうが説得力が段違いに強い。しかも配布経路が公式マーケットプレイスなので、勝手にリーチが広がる。
直接収益は生まれません。でも、あなたが「Claude Codeで何ができる人か」を証明する装置としては、2026年後半時点で最もコスパの良い方法だと思っています。まずはSKILL.md1枚から始めてみてください。ディレクトリを切って、plugin.jsonを1つ書けば、その日のうちにGitHubにpushできます。
参考リンク
- Claude Code Docs - Create and distribute a plugin marketplace — 公式マーケットプレイスの作成・配布手順
- Claude Code Plugins Directory — 外部ディレクトリの登録と発見性
- Security Boulevard - 7 Claude Code Plugins Worth Your Time — 2025年10月9日のAnthropic発表内容とプラグイン構造