Claude Skills と Claude Code Plugins を「売れる商品」にする — 設計・審査・課金・改善の全要点

Claude Code のエコシステムで「商品になる」ものを作るのは、アプリ開発や SaaS とは違う難しさがあります。Claude Skills と Claude Code Plugins は、よくあるフレームワーク付属のテンプレートとは違い、AI が理解して実行する前提の成果物だからです。私がいくつかの Skill と Plugin を作って公開し、その中で「商品として売れたもの」と「公開しただけで終わったもの」の違いを整理してきた結果を実例とともに整理しました。

単なるチュートリアルではなく、ニッチの見つけ方から、設計、配布、課金、サポート、継続的な改善までを、一つの流れとして書きます。個人開発者が本気で「月に数万円〜十数万円稼げる小さな商品」を Claude エコシステムの上に作りたいときに、実践で使える地図になることを狙っています。

Skills と Plugins — どちらを商品にするべきか

まず最初に整理しておきたいのは、Claude Skills と Claude Code Plugins が「似て非なるもの」であることです。商品として売るときの性質がかなり違います。

Skills は、Claude が呼び出すたびにロードされるナレッジとワークフローのパッケージです。テキストファイルと少数のスクリプトで構成され、配布が軽く、ユーザーが導入する心理的ハードルが低いのが長所です。一方で、実行環境に深く食い込むことはしにくいので、ロジックの密度よりも「ドメイン知識 × 手順の型」を売りにする商品が向きます。

Plugins は、Claude Code そのものに差し込む機能拡張で、ツール・スラッシュコマンド・MCP サーバーを束ねて配布できます。カスタムツールや外部 API との連携、ローカルのファイル操作など、動作の密度で差別化できる商品に向きます。ただし、Skills より初見のハードルが高く、信頼関係が築けているユーザー向けに深く作り込む発想が必要です。

売れる商品を作るうえで、私はこの2つを次のように使い分けています。

Skills で売るもの: 特定の業界知識・特定のフォーマットに対する精度の高さ・「この形式で必ず作る」という型。典型例は「契約書レビュー Skill」「ECサイト商品説明文生成 Skill」「英語プレスリリース添削 Skill」など。
Plugins で売るもの: 開発者向けのツール統合、データ連携、特定のワークフローを一発で回すスラッシュコマンド集。典型例は「Stripe 請求書ワークフロー Plugin」「AWS CloudWatch ログ分析 Plugin」「iOS リリース支援 Plugin」など。

「どちらで作るか」を決めるのは、売りたい価値の密度です。情報と型で勝負するなら Skills、動作と統合で勝負するなら Plugins と覚えておけば、設計の最初の方向性で大きく迷うことは減ります。

「ニッチで刺さる」Skill を設計する型

Skills を商品として成立させるには、「誰でも使える汎用ツール」ではなく「特定の人にとって絶対必要なもの」を作る必要があります。汎用ツールは無料の公式 Skill と競合してしまい、個人開発者が課金を正当化する余地がほとんど残りません。

私が使っている「ニッチ特化 Skill」の設計型は次の通りです。

Step 1: 1つの職種 × 1つの作業に絞る。 たとえば「ECサイト運営者」×「商品タイトルと説明文の最適化」。「マーケター全般」×「記事作成」ではぼやけすぎです。この最初の一点集中で、Skill が解く問題が鮮明になります。

Step 2: その作業の現行プロセスを徹底的にヒアリングします。 現場の人がExcel・Notion・Google ドキュメントで何を見ながら作業しているかを、可能なら実際にログを取らせてもらって記録します。Skill はその「画面と紙」を AI に引き継ぐものなので、具体的なファイル構成やテンプレートまで理解する必要があります。

Step 3: 成果物フォーマットを1つに決める。 出力が「場合によって変わる」Skill は、ユーザーが使い込むほど信頼を失います。商品として売るなら、出力はバリエーションを持たせず、1つの決まった形式で必ず返すと決めてしまうほうが強いです。

Step 4: 「失敗の型」をあらかじめ潰す。 プロに成果物を見せたときに「それはプロが絶対にやらない」と言われそうな形は、Skill の中で明示的に禁止しておきます。この禁止事項が多ければ多いほど、Skill は「プロが横に座っている感覚」に近づきます。

この4ステップで設計した Skill は、汎用 Skill と比較してはるかに強い商品性を持ちます。汎用 Skill と並べたとき、ユーザーが「この人の Skill じゃなきゃ仕事にならない」と感じてくれれば、課金の壁は驚くほど低くなります。

Skill の中身 — 実際に「売れる」ファイル構成

以下は私が販売している小さな Skill の簡略版ファイル構成です。Claude Skills の基本仕様に合わせつつ、商品としての仕上がりを意識しています。

ec-product-description-pro/
├── SKILL.md                    # エントリポイント（必須）
├── style_guide.md              # 文体ガイド（最重要の核）
├── banned_phrases.md           # 使ってはいけない表現集
├── category_templates/         # カテゴリ別テンプレート
│   ├── fashion.md
│   ├── cosmetics.md
│   └── home_appliance.md
├── examples/                   # 入出力の実例
│   ├── input_001.json
│   ├── output_001.md
│   └── ...
├── scripts/
│   └── validate_output.py      # 出力チェック用
└── LICENSE

SKILL.md にはトリガー条件と概要だけを書き、本質的な知識は style_guide.md と category_templates/ に分けるのがコツです。全てを SKILL.md に詰め込むと、Claude がロード時に情報を取りこぼすリスクが上がります。

banned_phrases.md の存在が、商品としての Skill の「人格」を作ります。「〜です、〜ます口調で必ず書く」「〜と思います、〜かもしれません等の弱い断定を禁止」といった具体的なルールを書き込むことで、AI らしい汎用表現を徹底的に排除できます。

validate_output.py はオプションですが、プロ品質の Skill には入れておく価値があります。出力の文字数・禁止語・必須要素を機械的にチェックするだけで、「いつでも同じ品質を保つ」という信頼を商品として担保できます。

価格の決め方 — 「時給換算」で値付けしない

個人開発者が商品の値付けで一番やりがちな失敗が、「自分の時給 × 作業時間」で価格を決めることです。これは 100% 間違いです。Skill や Plugin のような情報商品の価格は、ユーザーが得る成果の価値で決めるべきものです。

私の値付けの手順はこうです。

その Skill でユーザーが1回あたり節約できる時間を見積もる（例: 30分）
その人の時間単価を見積もる（例: 時給3,000円 → 30分で1,500円）
その Skill が1ヶ月に使われる回数を見積もる（例: 月20回 → 月3万円の価値）
月額価格を「生み出す価値の10〜20%」に設定する（例: 月3,000〜6,000円）

この手順で出した価格は、自分の労力ではなく「ユーザーが払ってもお釣りが来る価格」になります。結果として、売上が自分の時給を大きく超える瞬間が来ます。

無料トライアルか、買い切りか、月額かという点では、Skills のように継続的に使うものは月額が向いています。買い切りにすると、Skill を改善し続けるインセンティブが薄くなりますし、ユーザーにとっても「更新されないかもしれない」という不安が残ります。

課金導線 — Stripe と Cloudflare Workers で最小構成を組む

Claude Skills や Plugins 単体では課金ができないので、外部の決済基盤を使います。個人開発者が最小コストで組むなら、Stripe + Cloudflare Workers の組み合わせが明確にシンプルです。

課金導線の全体像はこうなります。

ランディングページで Stripe Checkout へ誘導
決済完了後、Cloudflare Workers が Webhook を受け取り、ユーザー固有のアクセストークンを発行
ユーザーは SKILL.md の先頭に「このトークンを環境変数に設定してください」という手順を載せておき、自分の Claude Code に埋める
Skill の内部で、最初のアクションとして小さな API を叩き、トークンの有効性を検証

API 検証を入れておくと、トークンを持たないユーザーが Skill をそのまま使う経路を塞げます。Cloudflare Workers の KV にトークンと有効期限を置いておくだけの実装で、月数千円規模の商品なら十分な抑止力になります。

// 検証エンドポイント（Cloudflare Workers）
export default {
  async fetch(request, env) {
    const { token } = await request.json();
    const record = await env.TOKENS.get(token, { type: 'json' });
    if (!record || record.expires_at < Date.now()) {
      return new Response(JSON.stringify({ valid: false }), { status: 403 });
    }
    return new Response(JSON.stringify({ valid: true, plan: record.plan }));
  }
}

Skill 側では、Python のスクリプトでこのエンドポイントを叩いて「トークンが無効ならここで処理を止める」という動きをさせます。完璧なライセンス管理を作るのは個人開発では過剰なので、**「使おうと思えば迂回できるが、通常利用では十分機能する」**というレベルを目指すのが現実的です。

最初の100人をどう集めるか — 公開前に声を聞く

商品として Skill や Plugin を作るとき、一番多い失敗は「作ってから探し始める」ことです。私は今は作業順を完全に逆にしていて、ターゲットになるユーザーに作る前に話を聞くことを徹底しています。

流れはシンプルです。

自分が解きたい業界の SNS や Discord・Slack コミュニティを3〜5個特定する
その中で「AI を仕事に使いたいが、何から始めればいいか分からない」と発言している人を DM する
「いま仕事でこんなことをしているなら、こういう Skill を作ったら使いますか？」と聞く
「使いたい」と言ってくれた人の最初の10人を、βユーザーとして半額でクローズドに販売する

「声を聞く前に作る」のは、個人開発者がお金と時間を捨てる最短ルートです。逆に、声を先に聞いておけば、最初の売上が立つまでの時間は一桁月単位に縮まります。

私が実際に運営している Skill は、この方法で公開前に8人のβユーザーが決まり、公開初日で累計15,000円ほどの売上を立てました。金額自体は小さくても、「最初から買ってくれる人が居る」状態で公開できることが、その後の改善と集客の両面で大きな違いを生みます。

解約防止と継続改善のサイクル

月額の Skill で一番重要な指標は、MRR ではなく解約率です。月額で売る以上、新規が取れても同じだけ解約されればビジネスは拡大しません。

解約防止の基本は、ユーザーが Skill を使い続ける理由を作り続けることです。具体的には、以下のサイクルを2週間に1回のペースで回しています。

ユーザーの利用ログを匿名で収集する（内容ではなく、使われている頻度・パターン）
利用が減っているユーザーにのみ、短いアンケートを送る
アンケートで挙がった要望を元に、style_guide.md や banned_phrases.md に追加ルールを入れる
更新のたびに「これを追加しました」というメールを送る

このサイクルを回すと、ユーザーは「自分の意見が Skill に反映されている」という感覚を持ってくれます。Skill の中身が毎月少しずつ育っていくと感じてもらえる限り、解約率は低く保てます。

私が運営している Skill では、このサイクルを半年続けた結果、月次解約率が 3% 以下で安定しています。月額3,000円で解約率3%なら、単純計算で1人あたりの生涯価値は10万円を超えます。個人開発者が1つ持つ収益源としては、かなり悪くない数字です。

撤退ラインを最初に決めておく

最後に、情報商品を作るうえで精神衛生的に一番重要なのは、撤退ラインを最初に決めておくことです。

私は次のようなルールを自分に課しています。

公開から3ヶ月で有料ユーザーが10人未満なら、販売を止めて無料公開に切り替える
月次解約率が6ヶ月連続で7%を超えたら、根本的な設計を見直す
半年で一度もアップデートできない Skill は、商品ではなく「ただの公開物」として無料にする

このラインを決めていないと、売れない商品を「もう少し粘ろう」と延々と抱え続けてしまいます。商品として売る以上、売れないと判断したら素早く畳むほうが、次の商品を作るための体力が残ります。

個人開発者が Skills や Plugins を商品として成立させるのは、設計・価格・導線・改善・撤退までを一連のサイクルとして回すことに尽きます。Claude のエコシステムは新しいので、先行者として市場を作っていける余地がまだあります。アイデアが具体化する前に、まず「誰に何を届けるのか」を紙に書くところから始めてみてください。