個人開発で「収益化までのロードマップ」を検索すると、多くは「アイデアを出す → MVP を作る → ローンチ → マーケティング」という粒度の粗い4ステップで終わっています。しかし実際に手を動かしたことがある人なら分かる通り、この粒度では何も動けません。問題は「月曜日の朝に何をするか」がわからないことです。
アイデアひとつを持った状態からスタートして、12週間後に実際に有料ユーザーがいる状態を作るまでの、週単位の詳細ロードマップを実例とともに整理しました。私が2014年から個人アプリ開発を続け、2026年にClaude Codeで新規プロダクトを立ち上げた際の実践手順をベースにしています。
各週に「何を作るか」だけでなく「Claude Codeに何を指示するか」「つまずきやすいポイント」まで含めました。読み終えたとき、月曜日の朝に迷わないはずです。
全体構造 — 12週間を4フェーズに分ける
12週間は大きく4つのフェーズに分かれます。
Phase 1（Week 1-3）: 構想と検証 — 作るべきものを決め、作る価値があるかを確認する期間です。多くの個人開発者はここを3日で終わらせようとして失敗します。3週間は必要です。
Phase 2（Week 4-7）: 実装 — Claude Code の真価が発揮される期間です。MVP を完成させ、自分で使えるレベルに到達します。
Phase 3（Week 8-9）: ローンチ準備と公開 — 決済・法務・SEO・導線を整えて世に出す期間です。実装より地味ですが、ここで手を抜くと収益がゼロのままになります。
Phase 4（Week 10-12）: 収益化と改善 — 最初のユーザーから学び、プロダクトと導線を磨き込む期間です。ここで得た学びが次のプロダクトに生きます。
各フェーズで「いま何が終わっていれば正常か」を明示しながら進めます。
Phase 1: 構想と検証（Week 1-3）
Week 1: 問題の特定と絞り込み
最初の週の目標は「自分が解決したい問題を1文で言い切れる」状態に到達することです。これができていないと、Claude Code がどれだけ速くても間違った方向に走ります。
私が実際に使っている方法は「過去1ヶ月で自分が3回以上同じ不便を感じた瞬間」をリストアップすることです。3回以上繰り返し遭遇している問題は、他の人も同じように感じている可能性が高いです。10個リストアップし、そのうち「自分が解けそうなもの」に絞ります。
この週のClaude Codeへの指示は、実装ではなく分析です。
以下の10個の「私が遭遇した不便」を評価してください：
1. ...
2. ...
各項目について、次の観点でスコアをつけてください：
- 他の個人開発者も同じ問題を抱えている確率（1-5）
- 技術的に1人で解ける難易度（1-5：低いほど易しい）
- 既存の解決策がないか不十分である確信度（1-5）
合計スコアが高い順に並べ、上位3つのターゲットユーザー像を具体化してください。
Claude Code は「誰が困っているか」を具体化するのが得意です。これを使ってターゲットを絞ります。
Week 2: 競合調査と差別化軸の決定
Week 2 は手を動かさずに調査する週です。上位3案について、既存の競合サービスを10個ずつ調べ、何が足りないか、何が高すぎるか、何が使いにくいかを洗い出します。
個人開発者が勝てる差別化軸は限られています。私の経験では、主に4つです。価格、速度、特定ユースケースへの最適化、そしてニッチの深さです。巨大プレイヤーが対応できない「特定の職種・特定の言語・特定のワークフロー」に絞り込むと、個人でも勝負できます。
この週末までに、決定すべきは3つです。作るプロダクト名、ターゲットユーザー（1人の具体的な人物像）、そして差別化軸。ここまで決めると、Week 3 以降の判断が楽になります。
Week 3: 技術選定とプロジェクト初期化
Week 3 からようやく Claude Code にコードを書かせ始めます。ただし本実装ではなく、「CLAUDE.md の整備」と「リポジトリの骨格作成」が目的です。
前編の技術スタック記事で紹介した構成（Next.js 16 + Cloudflare Workers + Stripe + Supabase + Auth.js）を採用するなら、Claude Codeに以下を指示します。
プロジェクト名: {決めたプロダクト名}
ターゲットユーザー: {1文で要約}
差別化軸: {価格/速度/ニッチ/ユースケース}
以下を作成してください：
1. CLAUDE.md — プロジェクト概要、技術スタック、制約、コーディング規約
2. リポジトリ骨格 — Next.js 16 App Router の初期構造
3. .env.example — 必要な環境変数の一覧とコメント
4. README.md — セットアップ手順と開発フロー
週末までにローカルで npm run dev が動けば Week 3 は成功です。この時点でまだ機能は何もなくて構いません。
Phase 2: 実装（Week 4-7）
Week 4: コア機能のプロトタイプ
この週の目標は「1つの機能だけ動くプロトタイプ」を作ることです。複数機能に手を出さない勇気が必要です。
Claude Code に MVP 機能を実装させる際、私がよく使うパターンは「最小限のユーザーストーリー3本」を渡すことです。
以下の3つのユーザーストーリーを満たす最小実装を作ってください：
1. ユーザーは{機能}を試せる（認証なし・無料）
2. ユーザーは結果を保存できる（認証必要）
3. ユーザーは保存した結果を一覧できる
今週は上記のみに集中してください。決済・多言語化・SEOは次週以降です。
この段階で Supabase の auth を繋ぎ、ローカルで「認証→機能利用→保存→一覧」の流れが動けば合格です。
Week 5: ユーザー動線とデザイン
Week 5 は見た目を整える週です。機能が動くだけのプロトタイプは、本人以外には理解不能です。
Claude Code にデザインを任せる際、私は参考URLを3つ渡します。「このサイトのヘッダーのような構造で」「このサイトの色使いで」「このサイトのタイポグラフィで」と具体的に指示します。Claude Code は優秀ですが、「かっこよく」のような曖昧な指示には弱いです。
この週末までに、自分以外の誰か1人（友人・家族・SNSのフォロワー）に触ってもらい、迷わず基本機能にたどり着けるかを確認します。迷いが発生したら、それは導線の問題です。
Week 6: プレミアム機能と制限設計
Week 6 で初めて「無料と有料の境界」を引きます。ここが個人開発の最大の難所です。無料部分が多すぎると収益化できず、少なすぎるとユーザーが離脱します。
2026年の相場感として、私が観測している「個人開発プロダクトの無料/有料比率」は以下です。
- SaaS型（月額課金）: 無料で試せる回数/日を2〜5回に制限、それ以上は有料
- 買い切り型: コア機能は無料、高度な機能やエクスポート機能のみ有料
- 定期コンテンツ型: 最新記事は有料、1ヶ月以上前は無料
自分のプロダクトがどの型かを決めたら、Claude Code に「制限ロジック」の実装を依頼します。KVまたはSupabaseで「ユーザーごとの今日の利用回数」をカウントする実装が定石です。
Week 7: 決済統合とダッシュボード
Stripe Checkout を統合する週です。前編の技術スタック記事で触れた price_data + product_data パターンを採用します。
この週でぜひ実装すべきは、自分用の「管理ダッシュボード」です。新規ユーザー数、決済成功数、失敗数、MRR（月間経常収益）が一目で見える簡易ダッシュボードを作ります。Supabaseのデータから集計するだけなので、Claude Code に依頼すれば数時間で作れます。
管理ダッシュボードが無いと、ローンチ後に「今どれくらい売れているか」を把握するために毎回Stripeダッシュボードを開くことになり、改善サイクルが遅くなります。
Phase 3: ローンチ準備と公開（Week 8-9）
Week 8: 法務・SEO・OGP
ローンチ前に必須の項目が3つあります。特定商取引法に基づく表記、プライバシーポリシー、利用規約です。日本国内でStripeを使って決済する場合、これら3つは必須です。
Claude Code にテンプレートから起こさせることは可能ですが、最終チェックは必ず自分で行ってください。特に「返金ポリシー」と「キャンセルポリシー」は、後々のトラブルを大きく左右します。
SEOは、このタイミングで最低限のメタ情報だけ整えます。generateMetadata 関数で各ページのタイトル・説明・OGP画像を動的に生成します。OGP画像は、各ページで共通でもよいので、必ず設定してください。設定がないとSNS共有時に見栄えが悪く、初期の流入を逃します。
Week 9: 非公開β → 限定公開
Week 9 の前半は、知人5〜10人に触ってもらう非公開βです。後半で、SNSで限定公開します。
βで最も重要なのは「決済が完走するか」の確認です。私が経験した落とし穴として、チップとプレミアムのmetadataを区別せずに実装してしまい、チップ決済で全記事が読めてしまう、という不具合を経験しました。決済のplan_typeメタデータを正しく分岐させているか、必ず実決済で確認します。
限定公開では「課金した人が最初に見る画面」を磨き込みます。購入お礼画面、領収書の案内、使い方のガイドを明示します。ここの体験が悪いと、リファラルが生まれません。
Phase 4: 収益化と改善（Week 10-12）
Week 10: 最初の有料ユーザー100人へのアプローチ
ローンチ1週目で、何らかの流入経路を最低3つ持っている状態を目指します。私が個人開発で実際に機能した経路は以下です。
- 自分のSNS（Instagram・X・Threads）での告知
- 既存の自分のサイト・アプリからの誘導
- ターゲットユーザーが集まる場所での紹介（Reddit・Discord・note・Zenn など）
Claude Code にブログ記事を書かせて SEO で拾われるのを待つ、という戦略は12週間では間に合いません。検索順位が安定するまで3ヶ月以上かかります。最初の100人は、能動的に連絡する相手から獲得します。
Week 11: データからの改善
Week 10 で何人かの有料ユーザーが出たら、Week 11 は分析と改善の週です。見るべき数値は3つです。ランディングページの離脱率、無料→有料の転換率、有料ユーザーの継続率です。
Claude Code に Supabase のクエリを書かせて、これらを自動集計させます。
Supabaseの以下のテーブルから、過去7日間の次の数値を出すSQLを書いてください：
- visitors: ランディングページへの流入数
- signups: 無料登録した人の数
- purchases: 有料化した人の数
- churn_7d: 7日以内に解約した人の数
この数値を毎日見る習慣が、次のフェーズでの改善速度を決めます。
Week 12: 次の12週間の設計
最後の週は、次の12週間の設計をする週です。得られた学びをもとに、次に作るべき機能、もしくは次に作るべきプロダクトを決めます。
私の実感として、12週間で作り切ったプロダクトは、たいてい最初の構想の半分以下の機能しか実装できていません。残り半分は、Week 12 時点で「必要ない」と判明していることが多いです。これが個人開発の健全な状態です。足りなかったものを足すのではなく、「Week 10-11で最もユーザーが喜んだ部分を伸ばす」方向で次の12週間を設計します。
12週間で避けるべき3つの失敗パターン
最後に、私自身が経験した、あるいは他の個人開発者でよく観測する失敗パターンを3つ共有します。
ひとつめは「機能を増やしすぎる」です。Claude Code で実装が速くなった分、つい機能を追加したくなります。しかし機能が増えるほど、ユーザーは何を使えばいいか迷います。Week 4 で決めた3つのユーザーストーリーから外れる機能は、Week 12 までは追加しない規律が必要です。
ふたつめは「ローンチを先延ばしにする」です。Week 8-9 で公開する勇気を持つこと。完璧を目指すと、永遠にローンチできません。まだ荒削りでも、有料で買ってくれる人がいる状態のほうが、完璧を目指して誰にも届かない状態よりはるかに価値があります。
みっつめは「最初から複数流入経路に分散する」です。Week 10 では3つの流入経路を持つと書きましたが、最初の1週間は「最も反応の良い1経路」に集中するべきです。私の経験では、自分のSNSからの誘導が初動で最も効きます。SEOやReddit投稿は、時間差で効いてきます。
全体を振り返って — 次の月曜日に何をするか
この12週間ロードマップの最大の価値は、「次の月曜日に何をするか」を決められることです。
今が Phase 1 の Week 1 なら、今日のタスクは「過去1ヶ月で3回以上遭遇した不便を10個リストアップする」です。Claude Code に指示する前に、紙とペンで書き出すのがおすすめです。
ここから12週間後、あなたは「有料ユーザーがいるプロダクトを持つ個人開発者」になっているはずです。そこからが、本当の個人開発者人生の始まりです。