Lovableが向いている人・向いていない人

Lovableは、自然言語でWeb appを作れるAI開発platformです。

特に向いているのは、アイデアから動くWeb productまでを短距離で作りたい人です。

一方、既存の大規模codebaseを細かく保守したいengineerや、native mobile / backend-heavyなsoftwareを中心にする人は、別toolの方が合う場合があります。

向いている人を先に整理

Lovableが向いているのは、

• SaaSやMVPを早く作りたい

• Web app中心

• UIをpromptで作りたい

• SupabaseやLovable Cloudを使いたい

• GitHubへcodeを持ち出したい

• non-engineerも開発へ参加したい

• prototypeから公開まで一つのtoolで進めたい

人です。

向いている人1：0→1のMVPを作りたい

Lovableは「空のrepoから何を作るか」を自然言語で伝えるworkflowと相性がよいです。

LP、dashboard、予約system、会員app、internal toolなど、要件がまだ固まり切っていない段階でも画面を作りながら詰められます。

仕様書を書き切ってからcodingするより、動くものを先に見たい人に向いています。

向いている人2：Supabaseを使いたい

LovableはSupabase integrationを持ち、

• database

• authentication

• storage

• realtime

• Edge Functions

をchatから扱えます。

frontendだけ生成してbackendを別途実装するより、MVPを早くfull-stack化できます。

既にSupabaseを使う方針のprojectとは特に相性がよいです。

向いている人3：designを見ながら修正したい

codeを書くより、

「このsectionを狭く」

「buttonを右へ」

「このcardだけ変更」

のようにvisual feedbackで修正したい人にはLovableが分かりやすいです。

非engineer、designer、product managerが直接触れる余地があります。

向いている人4：最終的にGitへ移したい

LovableはGitHub / GitLab syncを提供しています。

Paid planではcode editing / downloadも利用できます。

MVPはLovableで作り、その後Cursorや通常のengineering workflowへ移す使い方ができます。

AI builderを最終hosting先に固定したくない人に重要です。

向いている人5：少人数teamでcreditsを共有したい

Lovableはseat課金ではなくworkspace credit制です。

全planでmember数はunlimitedで、shared credit poolを使います。

designer、PM、engineerが同じworkspaceで触る場合、人数ごとにsubscriptionを増やさず運用できます。

向いていない人1：native mobileが中心

Lovableの中心はWebです。

iOS / Android native appを直接作ることが主目的なら、Replitなどmobile対応を明示するserviceも比較します。

PWAで十分ならLovableでもよいですが、App Store配布を前提にするなら別workflowが必要です。

向いていない人2：大規模既存repoの保守が中心

Lovableは新規projectやWeb appのiterationと相性がよい一方、複雑なmonorepo、大規模backend、特殊infraなどでは一般的なIDE + coding agentの方が扱いやすい可能性があります。

この領域はproject構造によるため、一律には決められません。

向いていない人3：creditsを気にせず長時間agentを回したい

Build modeはtask complexityでcredit消費が変わります。

大きな変更、調査、browser check、image generation等はcostが増えます。

大量にtrial-and-errorする人は、fixed subscription型のcoding environmentと比較します。

向いていない人4：企業security要件が厳しいがFree / Proだけで済ませたい

SSO、RBAC、Security Center等はBusiness以上です。

auditやSCIMなどさらに高度なgovernanceはEnterpriseです。

会社導入では「appが作れるか」より、security controlのplan要件が先に決まることがあります。

まずFreeで確認すること

Freeには毎日5 build creditsがあります。一部regionでは月30 credits上限が案内されるため、workspace画面で自分の上限を確認してください。

試すなら、

1. login

2. database CRUD

3. responsive UI

4. deploy

5. Git sync

まで一つの小さなappで通します。

そこで修正回数とcredit消費を見れば、自分に合うか判断しやすいです。

まずは使ってみる

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

• 

  Lovable

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

90分の小さな試作で相性を見る

評判や画面の第一印象だけでは、完成後の手直しや引き継ぎやすさは分かりません。Freeで試せる範囲を使い、個人情報を含まない仮データで、完成条件を先に決めたWebアプリを一つ作ります。例は「架空の問い合わせを登録し、一覧・詳細・状態変更を行える小さな管理画面」です。これは試験用の題材で、Lovableで実行済みの結果ではありません。

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

時間	試す作業	記録するもの
0〜15分	入力項目、利用者、画面、完了条件を短く指定	最初の画面と欠けた要件
15〜40分	一覧・登録・編集を作り、responsive表示を確認	修正回数、credit、壊れた操作
40〜60分	認証や保存先をつなぐ前に、権限とデータ構造を確認	公開範囲、削除・編集権限
60〜75分	Git連携やcodeの引き継ぎ手順を確認	repositoryに反映できるか
75〜90分	別の人が操作し、再現できない箇所を記録	未完了条件、次の保守担当

合格条件は「画面が見える」だけにしません。必須操作が最後まで通ること、入力値を更新して再読込しても期待状態であること、エラー時に利用者が戻れること、第三者が変更箇所を追えることを確認します。DB、認証、外部連携を使う場合、公開前に権限設定・secretの置き場・backupと復旧も別途確認します。試作には架空データを使い、実顧客データや秘密情報を貼り付けないのが安全です。

終了時に次の三択で決めます。

• 続行：必須画面が通り、修正内容とcreditの消費を説明でき、チームの引き継ぎ方法も決まった。

• 条件付きで続行：UI試作は速いが、認証・hosting・保守の責任者または費用が未確定。公開前に担当と確認日を置く。

• 別の開発環境を比較：既存repository、特殊なserver構成、native appが中心で、試作から本番への受け渡しが重い。

判断を感想だけにしないため、各項目を「必須」「できれば」「対象外」に分け、試作後にPASS / FAIL / 未確認を付けます。必須が一つでもFAILなら公開へ進めず、未確認は担当者と確認期限を決めます。修正回数やcreditは試験中の実測値だけを使い、他人のprojectへ一般化しません。次の担当者が同じ操作を再現できるかも、引き継ぎの合格条件に含めます。

試作結果を選択へつなげる

最後に記録を短くまとめます。何が時間を短縮したか、何を人が直したか、後から誰がコードとデータを引き継ぐかの三点です。「UIが早くできた」だけで採用を決めず、試作の成功条件を満たしたか、未解決の本番条件は何かを分けて残します。認証・権限・個人情報・費用のどれかが未確定なら、本番公開は保留し、架空データの検証範囲に限定します。

試験を終える前に、アプリを別の権限の利用者で開き、見えてはいけない情報が表示されないかも確認します。保存・削除・再読み込みを一通り試し、公開後に戻せるbackupまたはGit上の変更点を残します。ここまで通れば、試作の「画面ができた」と「運用へ渡せる」を区別できます。

試作記録は「できた画面」だけでなく、操作の前提と失敗時の戻り方まで残します。たとえば権限の異なる二つのテストアカウントを用意し、閲覧・更新・削除それぞれで期待結果を先に書きます。結果が期待と違ったら、画面表示だけ直して合格にせず、保存後の再読込と別アカウントでの表示をやり直します。確認欄には、再現手順、発生した不具合、修正回数、最後に通った状態を記録します。これなら短い試作でも、見た目の速さと運用へ引き渡せる状態を切り分けられます。試作の評価結果はその一つの題材・担当者・期間に限るものとして扱い、サービス全体の性能評価へ一般化しません。

AIものさしの判断

Lovableが向いているのは、Web productを0→1で素早く形にしたい人です。

特にSupabase、visual iteration、Git handoffを組み合わせるworkflowに向いています。

native iOS / Android app、大規模既存repository、特殊なinfraが中心なら、Lovableだけで完結すると仮定せず、native mobileの開発・テスト手段、既存repositoryへ変更を戻せるか、hosting・運用・保守責任まで含めて別環境を比較します。Replitは公式docsでExpo / React Nativeによるnative appの作成・previewを案内しています。

評判より、実際に小さなfull-stack appを1本作り切る方が判断材料になります。