「作る」から「届ける」へ — コードが書けない教員が、初めて収益化を目指した話
「作る」から「届ける」へ — コードが書けない教員が、初めて収益化を目指した話
10 min read
— views
目次

Stripeの「テスト決済が成功しました」という通知を見たとき、手が震えた。

大げさじゃない。本当に震えた。テストカード 4242 4242 4242 4242 を入力して、Webhookが動いて、データベースのユーザーステータスが premium に変わる。画面の上では「Payment Succeeded」の文字が光っている。

動いた。ちゃんと動いた。

でもそのとき感じたのは達成感じゃなくて、「これ、本番で動かなかったらどうしよう」という純粋な恐怖だった。

僕はこれまで、5つのアプリを作って占いアプリを3日でPlay Storeに出した話を書いてきた。でも今回の話は、それらとは質が違う。「作る」フェーズから「届ける」フェーズへ——無料で作って無料で使ってもらう世界から、お金をいただく世界に足を踏み入れた話だ。

この記事は、その転換点で感じたこと、やったこと、怖かったことの全記録。

「作る」から「届ける」への転換を象徴するイラスト


無料から有料への壁 — 「お金をもらう」ことの恐怖

これまで作ったアプリは、全部無料だった。

授業の進度管理、旅費精算、席替えツール——どれも「自分が困っているから作った」もので、同僚に「使ってみて」と渡すだけでよかった。バグがあっても「ごめん、直すわ」で許される空気がある。感謝されたら嬉しいし、使われなくても別に困らない。

でも「お金を払ってもらう」は、全く別の行為だった。

品質保証の責任が生まれる。「お金を払ったのに動かない」は許されない。無料なら「まあそんなもんか」で済むバグが、有料では「詐欺じゃないの?」になりかねない。

正直に言おう。Stripeを組み込んで決済の仕組みが動くところまで来たとき、一番強かった感情は「こんなもの、誰が買うんだろう」という自信のなさだった。

テスト環境では完璧に動く。テストカードで何十回も決済を繰り返して、Webhook処理も、ステータス更新も、解約処理も、全部確認した。でも本番は別世界だ。テスト環境の 4242 4242 4242 4242 は、本物のクレジットカード番号じゃない。

本番に切り替えるボタンを押す指が、ためらう。「本番に切り替えたら、もう引き返せない」——その感覚は、教壇で初めて授業をした日の緊張に似ていた。

そして案の定、公開直後にバグが出た。

本番環境で初めて発覚した不具合。テストでは出なかった挙動。決済が正しく処理されないケースが見つかった。メール通知が飛ばない問題も発覚した。

「もしこれ、誰かがお金を払った後に起きていたら——」

深夜のhotfix。まだ誰にも知られていないサービスなのに、手が震えるほど焦っていた。不思議だ。ユーザーがゼロの段階で、こんなに怖い。これが「お金をもらう」ということの重みなのだと、身をもって知った。

Stripe決済テスト成功の瞬間


Star Oracle — 占いアプリがWeb版になるまで

以前の記事で、モバイル版のStar Oracleを3日で作ってPlay Storeに出した話を書いた。あのときは「作るのが楽しい」というテンションで突っ走った。

でもモバイル版を作った後、ずっと頭の片隅にあったことがある。「これ、Webでもやりたい」。

アプリは日常的に使われやすい。でもWebには、URLひとつで誰でもアクセスできる手軽さがある。SNSでシェアされたリンクをタップすれば、インストール不要ですぐ体験できる。この「摩擦のなさ」は、アプリにはない強みだ。

そうして生まれたのが Star Oracle Web(現在休止中)だ。モバイル版とは完全に別のコードベースとして、Next.jsで再構築した。Stripe決済を組み込み、Vercelにデプロイした。

守護タロット診断

Star Oracleの軸になっているのが、守護タロット診断だ。生年月日を入力すると、あなただけの守護タロットカードがわかる。

MBTIで「私はINFPです」と自己紹介するように、「私の守護タロットは【月】です」とシェアしてもらえる文化を作りたい。SNSで「私の守護カードはこれだった!」と回ってくる世界。占いそのものではなく、自分を知るきっかけとしてのタロット体験。

タロット占い

もちろん、本格的なタロットリーディングもできる。ワンオラクル(1枚引き)、3枚スプレッド、ケルト十字——3つのスプレッドを用意した。毎日の行動指針として、朝に1枚引く使い方を想定している。

基本機能は無料で使える。Premium(月額 ¥980)にすると、フル78枚デッキ、全スプレッド、恋愛や仕事の詳細アドバイスが解放される。「まず無料で体験して、気に入ったら深く使う」という設計にした。

正直、まだユーザーは少ない。でも、「収益が入るかもしれない仕組み」を最初から組み込んだサービスを完成させたこと自体が、僕にとっては大きな一歩だった。

Star Oracle Webのトップページ


Claude Codeのコンテキスト窓との格闘

Star Oracle Webの開発は、ほぼすべてClaude Codeと一緒にやった。認証、決済、データベース、API——コードが書けない僕が、これだけの規模のWebサービスを形にできたのは、間違いなくClaude Codeのおかげだ。

でも、楽しいことばかりじゃなかった。

開発が佳境に入ると、会話が長くなる。ファイルをたくさん読んで、修正して、テストして、また修正して——を繰り返していると、あるタイミングでClaude Codeが急におかしくなる。

さっきまで完璧に理解していたプロジェクト構造を忘れる。指示していないファイルを勝手にいじる。同じミスを繰り返す。ひどいときには、「このプロジェクトの構造を教えてください」と聞いてくる。さっきまで一緒に設計していたのに、相棒が記憶喪失になるのだ。

「また最初から説明するの?」

このフラストレーション、バイブコーダーなら共感してもらえると思う。

原因はわかっている。コンテキストウィンドウの圧縮だ。Claude Codeには会話の長さに上限がある。上限に近づくと、過去の会話が圧縮される。その瞬間、積み上げてきた文脈——「このファイルはこう」「ここは触らないで」——が一部失われる。相棒の脳が、突然リセットされる。

何度も痛い目に遭って、ようやく戦い方を覚えた。

  • CLAUDE.mdをちゃんと書く → プロジェクトの「取扱説明書」。技術スタック、コマンド、絶対に触らないファイル。圧縮されてもCLAUDE.mdは常に読み込まれるから、最低限の文脈が保たれる
  • /compactを能動的に使う → 圧縮されるのを待つのではなく、自分のタイミングで圧縮する。「ここまでの文脈をまとめて」と自分でコントロールする方が精度が高い
  • 1タスク1セッションを意識する → 「認証を実装する」と「決済を実装する」は別セッション。全部を1つの会話でやろうとしない
  • サブエージェントに調査を任せる → 検索やファイル探索は別のエージェントにやらせて、メインのコンテキストを節約する

面白いのは、これがプロジェクト管理そのものだということ。タスクを分解して、文脈を整理して、ドキュメントを書く。人間のチーム開発でも同じことが求められる。

AIとの協働は「無限の相棒」ではなく、「記憶に限界がある優秀な同僚」と付き合うこと。制約を理解して、付き合い方を設計する。Claude Codeに鍛えられて、僕は少しだけプロジェクト管理がうまくなった。


2本柱 — アプリ版とWeb版で収益化を狙う

Star Oracle Webの公開と同時進行で、もうひとつ大きな動きがあった。

fortune-app(Star Oracleのモバイル版)が、Google Play Storeの本番審査に出ている。

React NativeとExpo SDK 54で構築したモバイルアプリ。クローズドテストを経て、ようやく本番審査に提出した。審査を通れば、全世界177の地域で公開される。

アプリ版はWeb版とは課金モデルが違う。Web版がサブスクリプション(月額 ¥980)なのに対して、アプリ版は買い切りだ。恋愛アドバイス ¥250、仕事アドバイス ¥250、3枚スプレッド ¥350、ケルト十字 ¥480——一度買えばずっと使える。

チャネルごとに課金モデルを変えたのには理由がある。Webは更新が楽だ。審査なしですぐデプロイできるから、サブスクで継続的に価値を提供しやすい。アプリは日常の中に溶け込みやすい。朝起きてスマホを開いて、1枚タロットを引く。その習慣に対して、一度だけ支払う方が自然だと考えた。

つまり、Web版のサブスク収益とアプリ版の単発課金——2本の柱が同時に立とうとしている。

「まずWebで無料体験する → 気に入ったらアプリでも使う」という導線。片方だけでは弱い。両方あることで、ユーザーとの接点が増える。

半年前の僕に「お前、2つの収益チャネルを持つサービスを運営してるよ」と言っても、絶対に信じないだろう。もちろん、審査が通るかはまだわからない。通っても、すぐにお金が入ってくるとは限らない。でも、「収益が発生しうる状態」を自分で作れたという事実は、もう誰にも否定できない。


「作る」から「届ける」へ

振り返ると、僕の個人開発は3つのフェーズを経てきた。

第1フェーズ:自分のために作る。 授業の進度管理アプリ、旅費精算アプリ、席替えツール。自分が困っていることを解決するために作った。コードは書けないけど、困りごとを言語化すればAIが形にしてくれる。それを知っただけで世界が変わった。

第2フェーズ:楽しいから作る。 占いアプリを3日で作ったり、ブログのエージェントチームを組んだり。「作ること自体が楽しい」というフェーズ。誰かに使ってもらえたら嬉しいけど、動機の中心は自分の好奇心だった。

第3フェーズ:届けるために作る。 Star Oracle Web。初めて「誰かに届けて、対価をいただく」ことを前提に設計した。

正直に言うと、第3フェーズは第1・第2よりしんどい

楽しさだけじゃ乗り越えられない壁がある。Stripeの決済テストを何十回も繰り返す退屈さ。「このエラーハンドリング、お金が絡むから絶対に落とせない」というプレッシャー。公開後に見つかるバグへの冷や汗。

でも、しんどいけど、嫌じゃない。

「自分が作ったものに、誰かがお金を払ってくれるかもしれない」——その可能性があるだけで、朝起きたときのワクワクが違う。

コードは書けない。今でも書けない。でも、困りごとを言語化して、AIと一緒に形にして、世に届けるところまで来た。今はまだ、収益はゼロに等しい。Play Storeの審査が通っても、すぐに売れるとは思っていない。

でも、「作って終わり」から「作って、届ける」に変わったこと自体が、僕にとっての成長だった。

怖い。でもワクワクしている。たぶん、この感覚が正解なんだと思う。

See ya!

Share: 𝕏