高校生の有料Discord Botが月利益1.2万円 — 原価320円に月500円を付けた根拠を読む

無料が当たり前の市場に、高校生が有料で入った

Discordのボイスチャットでテキストを読み上げるBotは、2021年の時点ですでに無料のものが複数存在していた。そこへ月額500円のサブスクリプションで参入し、公開2年目に月およそ1万2,000円の利益を出したのが、当時高校3年生だったsizumita氏のBardBot(bardbot.net)である。本稿は同氏がZennに公開した運営記録をもとに、この小さな黒字がどんな計算の上に立っているのかを分解する。

金額そのものは大きくない。それでも取り上げる理由は、原価が明示され、価格の根拠が説明され、加入ペースまで具体的な頻度で出ている個人開発の記録が国内にほとんどないからだ。この事例の価値は稼いだ額ではなく、単価設計の透明さのほうにある。

公開されている数字

売上高そのものは開示されていない。出ているのは「月12kほどの利益」という結果値と単価だけなので、本稿でも会員数や月商を逆算はしない。推定を重ねると、この事例で唯一確かな「原価と価格の関係」まで曖昧になるからだ。

売っているのは機能ではなく「混雑していないこと」

BardBotが作られた動機は、機能の不足ではない。本人の説明はこうだ。無料の読み上げBotは「どれも使う人数が多すぎて制限があったり、読み上げが遅くなったりするという問題」があった。つまり無料Botの弱点は、開発者の怠慢ではなく、共有リソースを無料で開放していることそのものにある。利用者が増えるほど1人あたりの取り分が減り、品質が下がる。これは運営努力では解けない構造的な制約だ。

有料化は、その制約を金銭で切り離す行為だった。課金額に応じて読み上げ文字数の枠を確保するモデルなら、ユーザーが増えても既存ユーザーの品質は落ちない。可用性99%という数字を掲げられるのも、収益がインフラ費用に紐づいているからである。ここで売られているのは読み上げ機能ではなく、「他人の利用量に品質を侵食されない状態」だと言い換えられる。

価格が先ではなく、原価が先だった

値付けの説明が明快である。Google Cloud Text-to-Speechの単価は100万文字あたり1,600円。上限の20万文字を使い切った場合の原価は約320円。「そこにサーバー代がかかるとすると、これくらいが妥当」として月500円が決まっている。

この構造で重要なのは、320円が上限ケースの原価である点だ。20万文字は月間の枠であって、全ユーザーが毎月使い切るわけではない。実際の平均消費が枠を下回るほど、1件あたりの実効原価は320円より小さくなり、粗利率は上がる。従量課金の原価に定額の枠を被せるモデルは、この差分が利益になる。逆に言えば、枠を大きく取りすぎたり、原価単価が改定されたりすれば、粗利は一気に消える。500円という価格は感覚ではなく、この一本の計算式で支えられている。

潮目が変わったのは「他人の記事に載ったとき」

運営記録には「なかなかサブスク加入者が増えない」という見出しがある。対策として挙がっているのは3つ。Twitterアカウントの開設、noteでの記事執筆による誘導、そしてすでによく読まれている他者の記事に掲載してもらうことである。そして本人はこう書く。「おかげで4日に1~2人のペースでサブスク加入していただくことができました」。

前後の数値が両方とも出ているわけではない(前は「増えない」という定性表現のみ)。それでも、加入ペースが具体的な頻度で語れるようになった地点がここだ、という因果は本人が明示している。自前のアカウントを育てるのではなく、既に読者がいる場所に自分のプロダクトを置いてもらう——チャネルを作るのではなく借りる判断が、この事例における転機である。個人開発で最も欠けやすいのが集客であることを踏まえると、月12kの黒字は技術力ではなくこの一手で決まっている。

技術選択は「止まらないこと」への投資だった

可用性99%は結果的に出た数字ではない。最初のBotはPythonで書かれていたが、Discord APIのラッパーが開発終了したうえ、メモリ使用量が1日あたり5%ずつ上昇する問題を抱えていた。次にF#を試すもラッパーが動かず断念し、最終的にRust + Serenityへ書き直している。設定を複数Bot間で即時反映させるための内部APIにはGo + Echo、WebはNext.js + Firebase、キャッシュにRedis、ホスティングはECS on EC2(t3.micro、リザーブドインスタンス)という構成だ。

コスト意識も一貫している。データベースはCloud SQLを「費用が高すぎるため断念」してFirestoreを採用。ログ基盤はKibana + Elasticsearchを、無料枠で使えるOracleのARMインスタンス(メモリ24GB、4vCPU)にセルフホストしている。課金はStripe CheckoutとBilling Portalに任せ、Webhookを受けるFirebase FunctionsがFirestoreを自動更新する。決済まわりを自作しないことで、1人でも運用が回る形にしてある。

一方で、Webのホスティングは「Hobbyと何が違うのかわからないのでHobbyにしたいですが、営利目的なので仕方がない」としてVercel Proを使っている。粗利が1件あたり数百円規模の事業で、こうした固定費は重い。月12kという利益は、原価を削る努力の積み上げの上に残った数字である。

弱点はどこにあるか

事業がDiscordというひとつのプラットフォームの上にしか存在せず、API仕様や規約が変われば、収益はまるごと影響を受ける。単価の薄さも弱点で、月500円の商品で利益を倍にするには会員数を倍にするしかなく、営業レバレッジが働きにくい。さらに、運営者の可処分時間が学業に直結するという制約がある。記事内でも「大学受験が終わるまでは保守点検くらいしかできない」と明言されており、成長が本人のライフステージに強く縛られている。

海外展開のためのi18n対応、受験後の新機能開発、企業向けDiscord Botという3つの構想は語られているが、いずれも記事時点では未着手である。本稿はそれらを成果として扱わない。

この事例のどこが移植できるか

移植できるのは、原価から価格を引く順序だ。従量課金のAPIを使うプロダクトなら、上限ケースの原価を出し、そこに固定費を乗せ、切りのいい額に丸める。この手順は誰でも踏める。無料の代替品が存在する市場でも、その無料が「共有リソースの混雑」で品質を落としているなら、有料の入り込む余地があるという読みも、別の市場に持ち込んで通用する。

移植しにくいのは2点。ひとつは、Rustへの書き直しや複数言語での実装を高校生のうちに単独でやり切れる技術力。もうひとつは、よく読まれている他者の記事に載せてもらえる関係性で、これは未踏ジュニア採択者というコミュニティ内の立ち位置と無縁ではない。加入ペースが変わった転機の部分こそ、最も再現しにくい要素だと見るべきだろう。

そして規模の限界も直視しておきたい。月12,000円は、生活を変える金額ではない。ただし原価と価格の関係が正しく設計されているサービスは、会員数が増えたときに利益が比例して伸びる。この事例が示したのは到達点ではなく、伸ばせる形になっているかどうかの検査方法である。

あわせて読みたい

• Sidekiq — OSSの無料版と有料版を1人で両立させた収益設計
• Plausible — 無料の巨人がいる市場で有料プロダクトがARR100万ドルに届くまで