Lovableは2025年11月時点でユーザー数800万人に迫り、1年未満で$200M ARRを記録しました。そのユーザーの多くは、コードを1行も書いたことがない起業家や事業担当者です。
この記事では、彼らが実践している「アイデアを思いついた日にアプリを公開する」サイクルを5ステップで再現する方法を紹介します。対応するケーススタディとして、Lovableが12ヶ月で$200M ARRを達成した構造分析もあわせて読むと、なぜこのやり方が機能するのかがより深く理解できます。
「まず動くものを作る」という順序の逆転
従来のプロダクト開発は時間がかかります。要件定義→設計→開発→テスト→リリース、という流れをたどると、アイデアが世に出るまでに数ヶ月かかることも珍しくありません。その間にアイデア自体が古くなる。検証もできない。
vibe codingはその順序を逆にします。まず動くものを作り、公開し、使ってもらう。フィードバックを受けて、また作る。この速度感が、検証コストを劇的に下げます。
重要なのは「完成させること」ではなく「検証すること」です。完璧なアプリを作るのではなく、「この機能は本当に使われるか」という問いに答えるための最小限のものを作る。vibe codingの強さはここにあります。
始める前に整理しておく3つのこと
スキルは不要です。ただし、準備なしに始めると時間を無駄にします。事前に確認しておくべきことは3つです。
まず、何を検証したいかを1文で言えること。「ToDoアプリを作りたい」ではなく「フリーランサーが請求書と案件を1画面で管理できるかどうかを確かめたい」というレベルまで絞り込む必要があります。この精度がプロンプトの質に直結します。
次に、ターゲットユーザーが具体的に思い浮かぶこと。「誰でも使える」ものは「誰も使わない」になりがちです。「週に3件以上案件を抱えるWebフリーランサー」くらいの解像度があれば十分です。
最後に、SNSのアカウントがあること。アプリを作っても公開しなければ検証になりません。XやTwitterに300人でもフォロワーがいれば、最初の反応を得るには十分です。ゼロから始める場合は、LinkedInのほうが反応を得やすいことが多いです。
5ステップで24時間サイクルを回す
以下のステップは、1日でアイデアを公開するためのものです。完璧を目指さず、「動いて、伝わる」レベルを目標にしてください。
ステップ1:アイデアを「何を、誰に、どんな形で」で圧縮する(所要時間:30分)
最初にやることは、プロンプトを書くことではありません。アイデアの輪郭を固めることです。
「何を解決するか」「誰のために」「どんな画面になるか」の3点を紙か文書に書き出してください。例えば「フリーランスのWebデザイナーが、案件ごとに作業時間と請求金額を記録できるシンプルなダッシュボード。トップ画面に今月の合計請求額と稼働時間が表示される」といった形です。
この30分をケチると、後でLovableを何度も修正することになります。最初の精度が高いほど、生成の手戻りが少なくなります。
ステップ2:Lovableにプロンプトを渡してアプリを生成する(所要時間:1〜2時間)
Lovable(lovable.dev)にアクセスし、ステップ1で固めたアイデアをそのまま英語か日本語でプロンプトとして入力します。重要なのは「機能の説明」だけでなく「見た目の雰囲気」もセットで伝えること。「シンプル」「ミニマル」「プロフェッショナル」など、一言で十分です。
最初の生成は1〜2分で完了します。見た目が想定と違ったり、機能が足りなかったりしても、チャット欄で追加指示するだけで修正できます。「左のナビゲーションバーを削除して、上部にシンプルなメニューを追加してください」のような指示で、コードを触らずに変更が反映されます。
1〜2時間で「これなら見せられる」レベルになれば十分です。細部の完成度は後回しでかまいません。
ステップ3:VercelでURLを取得して公開する(所要時間:15〜30分)
LovableはVercelとの連携が組み込まれています。「Deploy」ボタンを押すだけで、独自のURLが発行されます。「https://your-app-name.vercel.app」のような形で、誰でもアクセスできるURLが手に入ります。
ドメインを取得する必要はありません。「まず見てもらう」という目的ならVercelのサブドメインで十分です。後で使い続けると判断してから独自ドメインを設定しても遅くはありません。
ステップ4:SNSでシェアしてフィードバックを集める(所要時間:1時間)
URLが手に入ったら、すぐに投稿します。ポイントは「作りました」ではなく「こんな問題を解決したいと思って作りました」という文脈で伝えること。なぜ作ったのかが伝わると、反応率が変わります。
X(Twitter)への投稿には、スクリーンショットとURLをセットで添付してください。文字だけの投稿より大幅に反応率が上がります。LinkedInの場合は「自分はこういう課題を持っていた→こう解決した」という一人称のストーリーが効きます。
「使ってみたフィードバックをもらえると嬉しいです」と明示することで、コメントや直接メッセージが届きやすくなります。最初は5人からの反応でも、次のステップを判断するには十分です。
ステップ5:フィードバックを次のプロンプトに変換する(所要時間:1〜2時間)
フィードバックが届いたら、それを次の修正指示に変換します。「ナビゲーションがわかりにくい」というコメントがあれば「トップ画面に使い方の説明を3行追加してください」という指示になります。「スマホで見づらい」なら「レスポンシブデザインに最適化してください」です。
このステップが最も重要です。フィードバックを受け取って「なるほど」で終わらせず、即座にプロンプトに変換してLovableに投げる。翌日には改善版が公開されている。これが24時間サイクルを回す、ということです。
Lovableのヘビーユーザーが口を揃えて言うのは「最初のプロンプトは60点でいい」という感覚が身についてからスピードが上がった、という点です。完璧なプロンプトを書こうとしなくなったとき、サイクルが加速します。
ツールの選び方——3つのレベル
メインで使うのはLovableです。UIが直感的で、日本語のプロンプトも通じます。月$25〜のサブスクリプションで、1ヶ月に十分な数のアプリを生成できます。
Bolt.newは代替として有力です。無料枠があり、フロントエンドの生成はLovableと同等以上の精度を持ちます。ただしデプロイの手順がやや複雑なため、最初はLovableのほうが迷いが少ないです。
Cursorは、生成したコードを細かく修正したいときに使います。Lovableの出力をCursorに持ち込んで、特定の箇所だけを変えるという使い方です。コードの読み書きが全くできなくても、Cursorのチャット機能だけで多くの修正ができます。完全な初心者なら、最初はLovableだけに集中するほうが効果的です。
向いている人と向いていない人
このやり方が合うのは、「作りながら考える」タイプの人です。頭の中でアイデアを完成させてから動き出す人より、まず形にして反応を見たい人に向いています。スタートアップの立ち上げ期、社内ツールのプロトタイプ、副業で何かを試したい、という状況に特に機能します。
一方で、向いていない場面もあります。個人情報を扱うアプリや、決済機能が必要な本番環境での運用は、エンジニアのレビューなしには危険です。vibe codingで作れるのはプロトタイプと検証用のツールです。本格運用を前提にする場合は、エンジニアとの協力が必要になります。
また「完璧なものを作ってから公開したい」という気持ちが強い人には向いていません。このサイクルは未完成を公開することが前提です。公開することへの抵抗感が大きいと、サイクルが回りません。
最初の1日でわかること
24時間でアプリを公開してフィードバックをもらうと、数週間の議論では得られない情報が手に入ります。「誰が使うか」より「誰が使わないか」のほうがよくわかります。想定していなかった使い方をされることもあります。
完成度より速度を優先するのは、手を抜くためではありません。仮説を現実で検証する機会を増やすためです。Lovableが800万人のユーザーを集めた理由は、そこにあります。
AI編集部コメント
書いていて一番感じたのは、「24時間サイクル」の本質はスピードそのものより「仮説検証の密度」だということです。作る回数を増やすことで、何が機能して何が機能しないかの感覚が磨かれていきます。
Lovableユーザーのリサーチを読んでいて気づいたのは、ヘビーユーザーのほとんどが「最初のプロンプトで完璧を目指すのをやめた」と言っていること。記事には盛り込めなかったですが、これが最大の転換点だと思います。
ツールは何でもいいです。大事なのは「公開するまでやりきる」こと。公開しないプロトタイプには検証価値がありません。