Obsidianプラグイン販売で稼ぐAI時代の副業設計図

Obsidianでは、自作プラグインで日々の作業を楽にしている人が大勢います。
そうやって作ったツールをGitHubに公開すると、「ほしい」と声がかかることも珍しくありません。
そうした声が増えてくると、有料で配ることも視野に入りはじめます。
ここ1年ほどで、数千円の値札がついた個人開発プラグインを、各所で見かけるようになりました。

背景にあるのは、ChatGPTやClaudeなどのAIアシスタントが、開発者の負担を実感できるレベルで減らしたことです。
TypeScriptの型定義からREADMEの英訳、バグ報告のコード返信まで、AIが下書きを担う時代になりました。
「Obsidianプラグインは無料が当たり前」だった空気は、開発者と読み手の両側から、ゆっくり書き換えられています。

ただし、AIで開発が楽になっても、販売を続ける段階になると話は別です。
どこで配布するか、いくらの値を付けるか、再配布をどこまで許すか、購入者からの質問にどう答えるか。
この4つを後回しにすると、リリース翌週には問い合わせ対応に追われ、次のバージョンをつくる時間がなくなるでしょう。

このページでは、その4つを順番に見ていきます。
副業として無理なく続けられる形を目指す方が、最初の1本を出すまでの道筋として読んでみてください。

ここ数年、Obsidianプラグインを個人で有料配布する人が、目に見えて増えてきました。
実装の下書きを担うのは、ChatGPTやClaudeといったAIアシスタントです。
これまで個人ではハードルの高かった工程まで、AIが下書きしてくれるようになりました。

現実的に、AIができる作業は、以下のとおりです。

• TypeScriptの型定義や設定UIの雛形作成
• READMEやLP文章のたたき台執筆
• バグ報告に対するコード修正案の生成
• ライセンス文書や英文サポートの翻訳

これらをAIが下書きしてくれるので、開発者は仕上げと確認に集中できます。
本業を抱えていても、季節ごとに1本のペースなら無理なく続けられるでしょう。

ただし、AIに任せきりで全部が終わるわけではありません。
最後にコードを動かして仕上げる作業は、開発者本人の役目です。
価格と販売チャネルを決める判断は、あなた自身が行う必要がありますね。

販売チャネル別に手数料と到達経路を比べる全体像

販売チャネルを選ぶときに見るのは、決済手数料と読者がたどり着く経路の2つです。
この2つは、チャネルによって大きく違います。
だから1つに絞らず、メインとサブの2系統を持っておくと無難でしょう。

主な選択肢を、手数料の目安で並べてみました。
公開されている料金体系を集めて、自前で整理した比較データです。

手数料だけ見ても、選び方を決めるのは難しいでしょう。
到達経路の違いと合わせてみると、自分に合うチャネルが浮かんできますね。

手数料が低いチャネルほど、購入者を集める仕事は自分に回ってきます。
だからこそ、まずは集客力に頼れるチャネルから始めるのが安全策です。
購入者が増えてきたら、自社LP(自分のサイト・販売ページ)での販売を、少しずつ増やしていきましょう。

価格帯と購入意欲が交差する現実的な落としどころ

価格設計は、感覚で決めてしまうと、まずうまくいきません。
購入者層の専門性と価格帯を2軸で並べると、4つのゾーンに分けて考えられます。

縦軸が「機能の専門性」、横軸が「価格帯」です。
自分のプラグインがどのゾーンに当たるかで、訴求の組み立て方が変わってきます。

たとえば、文章校正や表記ゆれ系のプラグインは「プロ向け本命ゾーン」に置きやすい性格を持っています。
プロのライターや編集者にとって、月1本の校正時間が半分になれば、3,000円程度は十分に回収できる金額になるからです。

ここで重要なのは、「誰のどの作業を何分減らすか」を軸に価格を組み立てていく発想でしょう。
逆に「便利だから売れる」だけの動機だと、購入後の満足度がぶれて返金につながりかねません。

開発から販売まで最短ルートを描き出す全体フロー

販売開始までの工程は、段取りで決まる部分がかなり大きいです。
全体の流れを6ステップで頭に入れておくと、迷う場面がぐっと減るでしょう。

工程ごとに焦点をずらすイメージで進めると、判断もぶれにくくなりますね。

ステップ6まで到達すると、開発者の手離れが一気に進む構造になります。
その結果、本業との両立もぐっと現実的になっていくでしょう。

ライセンスとサポート設計を決める3つの判断軸

販売前に必ず決めておきたいのが、ライセンス文書とサポート方針の2点です。
ここを後回しにすると、購入後の問い合わせで疲弊していく未来が見えてきます。

判断軸は次の3つに絞れますね。

ソース同梱は一見、価値を下げる方向に働くと感じるかもしれません。
ただ、AI改造を前提にしてしまえば、購入者が自分の用途に合わせて調整していける道が開けるのです。
結果として、サポート工数は逆に減っていくケースが多くなりますよ。

AIに任せる購入後サポートと自動化の運用設計

サポートをAIに任せる設計は、副業として続けるための心臓部になります。
仕組み化しないと、リリース後ほど疲弊して、配信そのものが止まる流れに陥りかねません。

具体的に整理しておきたい項目は、次のあたりですね。

• 不具合報告の受付窓口(GitHub Issuesに集約)
• アップデート通知の経路(RSSとリリースノートで一本化)
• カスタマイズ依頼の扱い(原則受けない方針を明示)
• AI相談プロンプト集(READMEに3〜5本を掲載)

やはり効くのは、READMEの中に「具体的な質問例」をそのまま載せる発想です。
購入者は迷わずプロンプトをコピーでき、AIから即座に答えが返ってくる体験につながりますよ。

このObsidianプラグインで○○な挙動を変えたいです。
ソースコード(下記の関数まわり)を読んで、設定の追記案を出してください。

【現状】
○○すると××される。

【希望】
○○したら△△にしたい。

【関連コード】
src/main.ts の onLoad メソッド付近。

このひと枠をREADMEに置くだけで、サポート負荷の体感が大きく変わってきます。

価値あるプラグインを堂々と売り出すための覚悟

無料配布が標準の世界でも、価値ある道具には対価が支払われていく流れになっています。
大切なのは、「無料との違い」を購入者が即座に理解できる設計に仕上げる覚悟でしょう。

この変化は、開発者側のモチベーションにも良い形で返ってきますよ。
購入者の本気が伝わるから、改善のサイクルがほどよい温度感で続いていきますね。

AI時代の副業設計として、いまから動く価値は十分にあるはずです。
無料配布が前提だった世界に、個人で有料を打ち出す側に立てる、というめずらしい立ち位置でもありますからね。