LovableでWebアプリを作る基本手順

LovableでWebアプリを作るなら、最初の指示を長くするより「誰が、何を終えるために使うか」を決め、ひとつの主要画面と操作から形にするのが近道です。小さなMVPをPreviewで確かめ、要件の抜けを直してから認証やDatabaseを足します。画面が生成されたことと、ユーザーの作業が最後まで通ることは別なので、公開前には成功だけでなく失敗時の表示も試してください。

たとえば「家計簿アプリ」だけでは、入力項目、保存先、編集方法、誰がデータを見られるかが曖昧です。「一人で使い、日付・金額・カテゴリを登録し、月ごとの支出を確認する。登録内容は後から編集できる」のように、利用者と完了状態を先に決めます。この記事では、この一文からMVPを作り、画面・データ・テストへ落とす手順を示します。

生成前に決める仕様は、画面より利用者の作業

最初に、利用者、開始条件、最後に得たい結果を書きます。要件が固まっていない部分は、AIに補完させず「未決定」として残しましょう。とくにログイン、個人データ、外部API、決済は、見た目を決めるのと同じpromptで曖昧に任せない方が安全です。

表は横にスクロールできます

決めること	家計簿アプリの例	後で困る曖昧さ
利用者	本人が自分の支出を記録	家族共有の要否が不明
最初の作業	金額と日付を入力して保存	入力必須項目が不明
完了状態	一覧に表示され、月合計に反映	保存したか判断できない
失敗時	金額不正は入力欄の近くに表示	何を直すか分からない
データ境界	MVPは本人の記録だけ	他ユーザーから隔離する方法が不明

この表で回答できない部分が、最初のBuildで作る範囲かを判断する材料になります。最初から通知、共有、分析、複数通貨を足すと、画面は増えても主要作業の完成を確認しにくくなります。

Plan modeは「コードを書かせる前の仕様確認」に使う

LovableのPlan modeは、projectを調べて変更計画を作り、Buildの前に人が確認・編集できるモードです。画面追加やデータ構造変更のように影響が広い場合は、先に計画を出し、何を作るかだけでなく何を作らないかも確認します。

そのまま使える要件のたたき台：

利用者：一人で使う個人向け家計簿

目的：支出を記録し、月合計を確認する

最初に作る範囲：入力画面、保存済み一覧、月合計

入力：日付、金額、カテゴリ、任意メモ

成功条件：保存後に一覧へ追加され、合計へ反映される

失敗条件：金額が空・負数なら保存せず、理由を入力欄の近くに表示

今回作らない：共有、通知、銀行連携、予測

変更前に確認：保存先、認証、ユーザーごとのデータ分離

これは完成仕様ではありません。Planの出力に、使わない機能、曖昧な保存先、過剰な権限が混ざっていないかを見ます。質問が残るならPlanを直してからBuildへ移ります。単純な静的ページまで毎回Plan modeにする必要はなく、失敗時の影響が大きい変更ほど計画を挟む、と考えるとよいでしょう。

Buildは主要な一連の操作をひとつずつ作る

要件が決まったらBuild modeで実装します。最初の指示は、画面の見た目より振る舞いと完了条件を具体的にします。

prompt例：

支出入力画面に日付、金額、カテゴリ、メモを置く。金額は正の数を必須とし、不正なら保存しないで理由を表示する。成功したら一覧に追加し、表示中の月合計を更新する。まず既存projectの構成を確認し、保存先を変更する前に計画を示す。今回、共有、通知、外部APIは追加しない。

「使いやすくして」だけでは、入力後に何が起きるかや、既存機能をどう扱うかが決まりません。成功後の状態と、エラー時の状態を別々に書くと、生成結果を試しやすくなります。Buildが既存ファイルやデータ構造を広く変更する提案をした場合は、その範囲が必要かを確認してから進めます。

Previewでは見た目ではなく利用者のflowを通す

Previewを開いたら、次のように実際の操作を行います。

1. 入力欄を空のまま保存し、エラーが分かる場所に出るか。

2. 金額に文字や負数を入れて保存し、データが誤登録されないか。

3. 正しい支出を保存し、一覧と月合計の両方へ反映されるか。

4. ページを再読み込みし、保存済みの値が残るか。

5. 別画面へ移動して戻り、入力の二重登録や表示のずれがないか。

6. 幅の狭い画面で入力・保存・一覧確認ができるか。

1つ目の操作で止まるなら、まず入力検証を修正します。保存後の合計だけが違うなら、表示式や月の境界（例: 月末・翌月初日）を確認します。再読み込みでデータが消える場合は、見た目だけでなく保存先の設定を見直します。これらは見た目の好みではなく、Reader Jobが完了したかの確認です。

まずは使ってみる

記事の文脈に合うToolへ進めます。報酬の有無で見た目は変えていません。

• 

  Lovable

  公式サイトを見るTool詳細を見る

Backendを追加するタイミングを分ける

入力内容を一時的に画面に表示するだけなら、Databaseは不要かもしれません。一方、再読み込み後も保存したい、ユーザーごとに記録を分けたい、複数端末で使いたいなら、永続化と認証の要件が発生します。Lovable Cloudのbuilt-in backendやSupabase連携など選択肢がありますが、選ぶ前に「何をどこへ保存し、誰が読めるか」を決めてください。

Database導入時は、画面上で他人のデータが見えないことだけでなく、直接requestされた場合のアクセス制御も確認します。たとえばユーザー別データを保存するなら、recordにuser identityを関連付け、未ログイン利用者や別ユーザーから読めない条件を設計します。Authenticationを追加しただけでは、authorization（その人がそのrecordを読めるか）が完成したことにはなりません。具体的なRLS設定は利用するbackendとschemaに合わせ、Security記事で別に確認します。

公開前は「生成できたか」と「運用できるか」を分ける

公開前の確認表を作ると、未検証の機能を完成扱いしにくくなります。

表は横にスクロールできます

領域	確認する操作	合格の目安	止める条件
主機能	入力から結果表示まで通す	主要flowが最後まで動く	保存・集計が食い違う
入力検証	空欄・形式違いを試す	直し方を示し不正値を拒否	失敗が無表示
Data access	未ログイン・別ユーザーを試す	要件外のdataを取得できない	他人のrecordが見える
Mobile	主要画面を狭い幅で操作	操作と表示が続けられる	ボタンや入力が隠れる
Error path	通信・保存失敗を確認	再試行や問い合わせ先が分かる	成功したように見える

Previewで確認できた範囲、実際の公開環境でまだ確認していない範囲を分けて記録します。外部API、メール送信、決済、カスタムdomainなどは、previewで画面が動くことだけで本番設定まで保証されません。権限、secret、環境ごとの接続先を別に確認します。

公開判断に使える受け入れテストを先に作る

「動いた」と「使える」を分けるには、入力例と期待結果を1組で残します。家計簿MVPなら、最初は次のような少数のケースで、保存・一覧・集計のつながりを確認できます。

表は横にスクロールできます

入力例	期待する結果	失敗なら確認する場所
月末日、1,200円、食費	4月の一覧と合計へ反映	日付の月境界、集計条件
金額が空欄	保存されず、金額入力欄に理由が出る	必須判定、error表示
金額が0または負数	要件に応じて拒否される	validation条件
同じ保存操作を二度押す	意図しない二重登録がない	button無効化、request重複
再読み込み後	保存済みの値が残る	永続化先と読込処理

このテスト例は特定の実装を保証するものではなく、作る側と確認する側が「成功」を同じ意味で使うための叩き台です。0円を許すサービスなら、その行の期待結果を要件に合わせて変更します。日付も、表示だけ正しくてもUTC変換で前日扱いになる場合があります。月末と翌月初日を続けて登録し、月別集計の境目が意図どおりか確かめます。

公開直前には、Previewで通った手順を公開URLでも繰り返します。Previewと本番では保存先、認証、環境変数が違う場合があるためです。公開環境の設定がまだ整っていないなら、テスト結果を推測してPASSにせず、確認済み範囲と未確認範囲を分けて残します。

AIものさしの判断

まず静的画面と一つの主要flowだけでMVPを作り、入力から結果まで通るかを確かめる人にはLovableの段階的な進め方が合います。要件が曖昧なまま大きな変更を加える場合は、先にPlanで選択肢と影響を確認してください。DatabaseやAuthが必要なら、画面ができた後に足すのではなく、誰のデータをどう守るかを要件へ含めます。

「見た目ができた」だけで公開判断をせず、成功・入力エラー・保存失敗・別ユーザーのアクセスを試してから次へ進みます。まだデータ境界やbackendを決められないなら、MVPを静的な試作に留めるのが安全です。読者が最初の作業を終え、失敗時にも何を直すか分かる状態になって初めて、Webアプリの作り方として一区切りです。