Lovableの基本的な使い方

Lovableは、作りたいWeb siteやWeb appを自然言語で説明すると、AIがcode、UI、backendまで組み立てるAI software engineerです。

初めて使う場合は、いきなり「SaaSを全部作って」と頼むより、

要件を決める → 最小画面を作る → UIを整える → backendを足す → test → publish

の順で小さく進めた方が安定します。

2026年現在はLovable Cloudでdatabase、authentication、storage、serverless functionsまで扱えるため、prototypeだけでなくfull-stack appまで作れます。

1. 最初に作るものを言語化する

promptを書く前に最低限、

• 誰が使うか

• 何を解決するか

• 必要なscreen

• 最重要feature

• visual direction

を決めます。

たとえば、

「美容室向けの予約dashboard。ownerが今日の予約とcustomer情報を確認できる。まずlogin、dashboard、customer listの3画面だけ作る」

くらいまで絞ると最初のbuildが安定します。

2. 新しいprojectで最初のpromptを送る

Lovableはchat形式でbuildします。

最初のpromptでは、すべての細部を詰めるより、

• app purpose

• target user

• core screens

• key action

• design tone

を伝えます。

LovableはUIだけでなくlogicやroutingも生成します。

生成後はpreviewを見て、次の変更を小さく指示します。

3. 一度に一つの目的で修正する

「designを全部変えて、authを追加して、DBも作って、Stripeも入れて」とまとめるより、taskを分けます。

たとえば、

1. dashboard layoutを修正

2. mobile responsiveを調整

3. loginを追加

4. database schemaを作る

5. paymentを追加

の順です。

2026年のDefault Modeはtask complexityに応じてcredit消費が変わります。

Pricing pageの例ではbutton色変更0.50 credit、auth追加1.20、5 sectionのlanding page生成1.70などが示されています。

大きな曖昧promptはcreditも修正回数も増えやすくなります。

4. Plan Modeで先に考えさせる

大きなfeatureを追加する前はPlan Modeを使います。

Plan Modeは1 message = 1 creditです。

「実装して」ではなく、

• 影響するfile

• database変更

• route

• security risk

• implementation steps

を先に整理させます。

planを確認してからbuildへ進むと、不要な変更を減らしやすくなります。

5. Lovable Cloudでbackendを追加する

backendが必要になったらLovable Cloudを使えます。

公式supportでは、

• database

• user authentication

• file storage

• serverless functions

をfull backendとして提供すると説明しています。

「email/password loginを追加」

「userごとにtaskを保存」

「画像uploadを追加」

のように自然言語で依頼できます。

ただしschemaやpermissionはproduction前に確認します。

6. connectorを追加する

Lovableは外部service connectorも提供しています。

2026年現在、Linear、Notion、Stripe、Slack、Shopify、Google Workspaceなどが案内されています。

API / MCP対応serviceは「Connect it yourself」から接続できる場合があります。

connector自体ではLovable creditを消費せず、code生成・変更時にcreditを使う仕組みです。

7. paymentを追加する

subscriptionやone-time checkoutも追加できます。

Lovable公式supportではbuilt-in paymentsを案内しています。

最初はtest checkoutで動作確認し、

• success

• cancel

• webhook

• user entitlement

• error

まで確認してからliveへ切り替えます。

「決済画面が出た」だけで完成とは考えません。

8. GitHubへsyncする

開発を続ける場合はGitHub integrationを使います。

Lovableで生成したcodeはuser側が所有します。

GitHubへ同期しておけば、

• Cursorで編集

• engineerへhandoff

• CI/CDへ接続

• code review

などへ移行しやすくなります。

Lovableだけにprojectを閉じ込めず、productionではrepositoryをsourceとして管理する方法もあります。

9. securityを確認する

公開前に、

• authentication

• database permission

• secret / API key

• upload validation

• public route

• admin permission

を確認します。

AIが「動くapp」を作れても、「安全なproduction app」が自動的に保証されるわけではありません。

2026年にはLovable側もsecurity scan / governance機能を拡充していますが、最終責任は運用側に残ります。

10. publishする

動作確認後にpublishします。

Lovableではhostingもcredit systemへ統合されており、小規模・新規appではincluded grant内で収まる場合が多いとPricing pageで説明しています。

trafficやapp sizeが増えると追加credit消費が発生する場合があります。

公開後はusageとcredit balanceを確認します。

まずは使ってみる

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

• 

  Lovable

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

Freeでどこまで試せるか

2026年9月時点のFree planは、

• build credits：5 / day、最大30 / month

• Cloud：20 credits / month

• app内AI feature用：4 credits / month

のgrantがあります。

まずFreeでlanding pageやsmall appを作り、private projectやcredit量が必要になった時点で有料planへ進めます。

初回のおすすめ手順

1. 3画面程度のMVPを定義

2. 最初のpromptを送る

3. preview確認

4. UI修正

5. Plan Modeでbackend設計

6. auth / database追加

7. test dataで動作確認

8. GitHub sync

9. security review

10. publish

11. usage / error確認

この順なら「見た目だけできたapp」で止まりにくくなります。

よくあるつまずき

指示するたびに別の場所が崩れる

変更範囲を明示し、一度に一目的で依頼します。

creditが減る

Default Modeはcomplexity-basedです。大きなtaskほどcostが上がります。Plan Modeで先にscopeを固めます。

backendが分からない

まず「必要なdataとuser role」を文章で整理してからCloudへ依頼します。

AIだけでproductionへ出してよいか不安

GitHubへsyncし、code / security / database permissionをreviewできる状態にします。

変更を安全に積み上げる依頼テンプレート

Lovableへ最初の依頼を送る前に、目的、利用者、画面、保存する情報、成功条件を一枚にまとめます。

目的：小規模な料理教室の予約状況を管理するWeb app。利用者：運営者1名。最初に作る画面：ログイン、今日の予約一覧、予約詳細。最初の段階では決済と外部メール送信は入れない。予約一覧で必要な項目：日時、参加者名、人数、状態。成功条件：スマートフォン幅でも予約一覧を確認でき、状態を「確認済み」に変更して再読み込み後も保持できる。個人情報はテスト用の架空データだけを使う。

これは仕様の書き方の例であり、生成結果を確認した体験談ではありません。Lovableには一度に全ての機能を作らせず、まず画面と状態だけ、次に保存、次に認証、という順で依頼します。各依頼に「変更する画面」「変更しない画面」「完了条件」を含め、作業後にpreviewで該当条件を確認します。

Previewから公開までの確認順

• 画面：空状態、通常状態、長い文字、失敗状態を表示する。

• データ：読み込み中、保存成功、保存失敗、再読み込み後の値を確かめる。

• 権限：ログイン前後で誰が何を読めるかを確認する。生成された画面だけでDB権限が安全とは判断しない。

• 秘密情報：API keyやservice credentialをclient側へ置かない。secretはserver-side環境で管理する契約を確認する。

• 変更履歴：GitHub連携を使う場合は、同期先のbranchと差分を確認してから公開工程へ進む。

• 公開：test dataで操作し、認証、権限、error、mobile表示を通してからlive dataを扱う。

料金と作業量の見積もり

Lovableの公式PricingではFreeに日次build creditがあり、月上限、Cloud credit、アプリ内AI用creditも別途示されています。2026年9月の公式告知では、Free / Pro / Businessで毎日使えるchat枠が追加され、2026年10月31日までの現行条件が説明されています。通常のchatで相談することと、Plan / Buildへ作業を渡すことではcreditの扱いが異なるため、会話開始時に残高と操作別条件を確認します。Cloud hosting、database、authentication、storage、server functions等の利用も同じ残高・usage画面で確認し、traffic増加時の継続費用を公開前に見積もります。金額やcredit単価はplan・地域・機能で変わるため、過去記事の数値をそのまま予算に使わないでください。

最初のリリースに含めないもの

課金、顧客データ、メール送信、外部API、管理者権限は、画面ができたことだけでproduction readyとは言えません。まず小さなtest datasetで、成功と失敗の両方を確認します。重要な個人情報や本番secretを入力せず、データベースのrow-level permission、公開URLからのアクセス、ログに残る情報を確認できない場合は公開を止めます。コード所有権の説明があっても、third-party modelや依存packageの権利、運用責任まで自動で保証されるわけではありません。

AIものさしの判断

Lovableは、「要件を小さく切り、AIに実装させながらWeb appを育てる」使い方が基本です。

最初から巨大なpromptで完成品を狙うより、MVP → UI → backend → integration → security → publishと段階を分ける方がcreditと修正回数を管理しやすくなります。

non-engineerでも始められますが、productionではGitHub、security、database設計まで確認できる体制を作ると安心です。