こんにちは。もるふぉです。
自分のSKILL.mdが増えていくたびに、「これ、誰かに使ってほしいな」と思ったことはないですか。
業務で使えるレベルまで育てたプロンプトや自作ワークフローが、ローカルにひっそり眠っている。
GitHubで公開するにはノウハウごと渡すのが惜しい。
かといって受託のネタにするほどでもない。
その「もったいなさ」が、Skillを磨くほど大きくなっていきます。
そこに「Skillを売買できる」マーケットプレイスが出てきました。
Capafyです。
コードを公開せずに、使われた分だけ収益を得られる設計になっていて、ちょっと見過ごせないサービスです。
公式サイトと公式GitHub、それからPublisher Guideを読み解いた範囲で、現時点のCapafyを整理してみます。
Capafy とは何か — Skillマーケットプレイスの仕組みを整理する
Capafyを一言で言うと、SKILL.mdをベースにしたパッケージをエンジニア同士で売買できる場所です。
買う側はSkillをインストールするか、ブラウザ上で呼び出して使う。
売る側はSkillを登録して、使われた分だけ収益を得る。
GPTストアのSkill版、と言ったほうが直感的にわかりやすいかもしれません。
公式の説明では、Skillは「SKILL.mdファイルと、補助的なスクリプト・リファレンス・アセットを含む標準フォルダ」と定義されています。
SKILL.mdを核にしたパッケージング設計は、Claude Codeなどで使われているAgent Skillの考え方と親和性が高い形です。
実行モードは大きく2つあります。
Run on Capafy(Capafyのクラウド上で実行)と、Download(ローカルにダウンロードして自分のAgent Client上で実行)。
前者はコードが買い手に渡らないので、Publisherの知財が守られる作りになっています。
ノウハウを守りたいSkillはクラウド実行、カスタマイズしてもらいたいSkillはダウンロード型、と使い分けられます。
対応ランタイムは、Claude Code・Codex・OpenClawの3つ。
「Claude Code用のSkillしかCodex利用者には売れない」という制約がなくなる、つまり1つのSkillで複数のAgent Clientユーザーにリーチできます。
2026年6月時点では、3つの条件(マルチランタイム・クローズドソース可・課金型)を同時に満たすマーケットプレイスはほかに見当たりません。
Capafyの本質的な新しさは、ここからの話に詰まっています。
クローズドソースのまま収益化できる、という新しさが本質
ここがCapafyの一番面白いところです。
これまでSkillを世に出す手段は、基本的にオープンソース前提でした。
GitHubで公開する、Zennで解説記事を書く、公式のSkillsマーケットに無料で登録する。
どれも「ノウハウを開示することで認知や信頼を得る」モデルです。
技術的な情報発信としては正しいんですが、知財をそのまま渡してしまうので、エンジニア個人の収益にはほぼ繋がりません。
たとえば、PRレビューのコメントを整形してSlackに通知するワークフローを1ヶ月かけて磨いたとします。
GitHub公開すれば「スター」はもらえる。
でも、それが収益になることはない。
Zennで解説記事にしても、読まれた先でノウハウがコピーされて終わりです。
Capafyはそこが違います。
Run on CapafyモードでSkillはサーバーサイドで実行されて、買い手には「結果」だけが返ります。
プロンプトもスクリプトもPublisher側に残ったまま。
公式ドキュメントの言葉を借りると「あなたはプロンプトを保持したまま、相手は結果を受け取る」という構造です。
これはエンジニアの収益モデルが1段階変わる出来事です。
コードを書けることそのものではなく、「業務上のワークフローを再現可能なSkillとして設計する力」が、そのまま商品になります。
では、その「売る」設計はいくらで成立するのか。
収益モデルの選択肢を整理してみます。
Capafy の収益モデルを3パターンで整理する
公式のPublisherページを読み解くと、収益化の選択肢は3つに整理できます。
1つ目が時間課金です。
公式マーケットの掲載例では、1時間$3(約450円。1ドル=150円換算、以下同)で2時間ミニマム(合計$6、約900円)といった設定が見られます。
時間課金の最低設定価格は$1/時間(約150円)とされており、上限はPublisherが自由に決められます。
高専門性のSkillはより高い時間単価で出されることもあります。
短時間で完結する重い処理を売るときに合う設計です。
2つ目がサブスクリプションです。
日次・週次・月次の3軸で設定でき、利用頻度が安定するSkillに向きます。
公式ドキュメントでは月額$8(約1,200円)が最低設定価格とされており、月額$10(約1,500円)のサブスクから、Capafyのインフラ費用などを差し引いた金額がクリエイターの取り分になります。
具体的な計算式は公式ドキュメントに記載されており、手数料は今後変更される可能性もあります。
毎日使うワークフローSkillはこの形に向きます。
3つ目が買い切り型のDownloadモードです。
コードを実際に買い手に渡す方式で、価格はPublisherが自由に設定できる仕様です。
無料配布もできますし、専門性に応じて1,500円〜1万円台程度のSkillが並ぶことが想定されます。
ソースごと渡る仕様なので、知財を出してでも一度に大きく回収したい時に使う設計になります。
収益モデルの選び方は、Skillの性質次第です。
1回ごとの作業量が有限なものは時間課金、毎日使うようなワークフローはサブスク、ノウハウごと買い切ってもらえる完成度のものは買い切り、と整理するのが自然でしょう。
Capafyが他のプラットフォームと何が違うのか、並べて確認してみます。
Capafy と GPT ストア / 公式 Skill / HuggingFace との位置づけ
Capafyの立ち位置を、似たプラットフォームと並べて整理します。
こうやって並べると、Capafyの一意性が浮かびます。
「マルチランタイム対応」「クローズドソース可」「課金型」の3つを同時に満たすマーケットプレイスは、ほかに見当たりません。
GPTストアはChatGPT内で閉じていて、収益条件も限定的。
Anthropic公式のClaude Skillsはオープンソース配布が前提で、Publisher個人が報酬を得る仕組みはありません。
Hugging Face SpacesはモデルやSpacesの共有が中心で、Publisher単位の課金分配は組み込まれていません。
「自分のSkillをClaude Code利用者にもCodex利用者にも売れて、しかもコードは守れる」という設計は、現時点でCapafy固有の価値です。
実際にPublisherになるのはどのくらい手間なのか、公式ドキュメントから流れを追ってみます。
公式ドキュメントから読み解くCapafy Publisher の登録の流れ
公式のPublisher Guideを読んでいくと、Publisherになるまでの流れは思った以上にシンプルです。
大まかには、アカウントをPublisherロールに切り替える、Agent Client側にCapafyのPublisher Skillをインストールする、ローカルに作ったSKILL.mdをPublisher Skill経由でスキャンしてアップロードする、価格モデルを設定する、レビューを通って公開、という流れです。
面白いのは、SKILL.mdの作成自体をPublisher Skillが半自動でサポートしてくれる作りになっている点です。
公式の表現を借りれば、Publisher Skillが「ローカルファイルをスキャンして、リスティングフォームを埋めて、コンテンツをアップロードする」とのこと。
Skillを売る側のオンボーディング自体がSkillで動いている、という設計の一貫性は好感が持てます。
審査については、公開前にレビューが入る作りになっています。
詳細な基準まではドキュメントから読み取れませんが、品質と再現性が見られる前提で書いておいたほうが安全でしょう。
ここからは「では自分はどう動くべきか」という話をします。
Skill が「製品」になる時代に、エンジニアは何を準備すべきか
ここからは私の考察です。
Capafyの登場で1番大きいのは、エンジニアの成果物の単位が「コード」から「Skill」に1段階上がったことだと思っています。
これまで個人エンジニアが収益化する手段は、受託・転職・SaaS自作のどれかでした。
受託はフロー型でスケールしない。
SaaSはストック型ですが、開発・運用・サポートの負担が重い。
Skillはこの2つの中間にあります。
1度書いて、レビューを通せば、あとは使われるたびに収益が積み上がる。
サポートはSkillの品質と仕様の明確さで吸収できる範囲に収まります。
ここでエンジニアに問われるのは、コードを書く力ではなく「ワークフローを再現可能な単位で切り出して、SKILL.mdに落とす設計力」です。
普段の業務で動いている自分のテンプレートやプロンプトを、他人が同じ結果を再現できる粒度で言語化する力、と言い換えてもいいですね。
すぐにCapafyに登録しなくても構いません。
ただ、今夜でいいので、手元のSkillに名前を付けて、SKILL.mdを1本整えてみてください。
「このSkillは何をするものか」「誰が使うと嬉しいか」を言語化するだけで、商品化までの距離がぐっと縮まります。
手元が整っている人ほど、いざ動き出すときのスピードが違います。
「コードを書く」より「Skillを設計する」が中心になる時代は、もうそこまで来ています。



💬 コメント
ログイン か 会員登録 するとコメントできます