「Lovableを触ってみたが、途中で作りたいものと違う方向に進んでしまった」——これは、Lovableを初めて使った方から最もよく聞く感想です。

原因はツールの性能ではありません。Lovableは「指示されたとおりに作る」ツールであり、指示が曖昧なら曖昧なものが出てくるだけです。そして厄介なことに、Lovableは指示が曖昧なほどコードベースを広く探索するため、失敗した指示ほどクレジットを消費します。つまり使い方の巧拙が、そのまま完成度とランニングコストの両方に跳ね返る構造になっています。

本記事では、Lovable公式ドキュメント（Getting started）および公式プロンプティングガイドの記載に基づき、初回プロンプトから公開・運用までの手順と、実務で結果を安定させるための考え方を整理します。操作手順の羅列ではなく、「なぜその順番なのか」まで踏み込みます。

Lovableそのものの概要は「Lovableとは？AIでアプリ開発できる仕組み・料金・活用法」を、費用構造は「Lovableの料金はいくら？全プラン・クレジット単価・企業導入コスト」をあわせてご覧ください。

Lovableを開く前に、何を決めておくべきか？

なぜ「いきなりプロンプト」は失敗するのか？

公式プロンプティングガイドが最初に挙げている失敗要因は、「事前計画をスキップすること」です。明確な思考なしにプロンプトを書けば、ぼやけた結果が返ってくる——ガイドはこれを最初の落とし穴として明示しています。

これはAIツール特有の問題ではなく、システム開発の一般則がそのまま現れているだけです。要件が固まっていない状態で実装に入れば手戻りが発生する。違いは、手戻りのコストが人月ではなくクレジットで計上されることだけです。

最初に答えておくべき4つの問いとは何か？

公式ガイドは、プロンプトを書く前に次の4点を整理することを推奨しています。

1. 何を作るのか（アプリの正体）
2. 誰向けか（想定ユーザー）
3. なぜ使うのか（解決する課題）
4. 主要アクションは何か（ユーザーに取ってほしい行動）

加えて、ユーザーの動線（着地→信頼獲得→行動→完了）と視覚言語の方向性（「落ち着いた」「大胆」「プレミアム」など）を先に決めておくべきだとされています。とくに後者は重要で、デザインの方向転換は後からになるほど難しくなるためです。

ここで気づくべきは、この4問が従来の要件定義の最小セットとまったく同じだという点です。Lovableは要件定義を不要にするツールではありません。要件定義から実装までのリードタイムを圧縮するツールです。この認識の差が、PoCが成功する企業とそうでない企業を分けます。

最初のバージョンに認証とデータベースを入れないほうがよいのはなぜか？

公式のGetting startedは、最初のバージョンはログインとデータベースなしで構成することを推奨しています。

理由は、認証とDBが入った瞬間に「見た目の問題」と「データの問題」が同時に発生し、切り分けが困難になるからです。まず静的な画面で構造と見た目を固め、それが正しいと確認できてからバックエンドを足す。問題を一度に一つだけ扱うという、デバッグの基本原則がそのまま適用されます。

初回プロンプトから公開まで、手順はどうなるのか？

STEP1〜2：アカウント作成と最初のプロンプト

lovable.devにアクセスし、メール・Google・GitHub・Appleのいずれかでサインアップします。無料プランで個人ワークスペースが付与され、ダッシュボードに到達します。

ダッシュボードのプロンプトボックス（「Ask Lovable to create…」）に、作りたいものを説明します。公式ドキュメントが例示しているのは、カフェのWebサイトを作る場合の次のような記述です。

ヒーローセクション、カテゴリ別にフィルターできるメニュー、営業時間、所在地セクションを含むカフェのWebサイト

この例が示しているのは、「カフェのサイトを作って」では足りず、含まれるセクションを列挙する粒度が必要だということです。日本語のプロンプトでも指示できます。

STEP3〜4：エディタの見方と反復修正

生成が完了するとエディタ画面が開きます。構成はシンプルで、左半分がチャット（Lovableとの対話）、右半分がプレビュー（アプリの実動作）です。すべての変更は復元可能なバージョンとして自動保存されるため、失敗を恐れて手を止める必要はありません。

ここからは1回に1つずつ変更を依頼し、そのつどプレビューで確認するのが公式の推奨する進め方です。加えて、AIを介さずに直接編集できる手段が2つ用意されています。

• テキストのインライン編集：文言はプレビュー上で直接書き換えられる
• プレビューツールバーからの要素選択：変えたい要素を指定してから指示できる

この2つは実務上きわめて重要です。「見出しの文言を直す」程度の作業にAIへの指示（＝クレジット）を使うのは無駄だからです。公式ガイドも「小さな変更を大きなプロンプトで依頼する」ことを典型的な誤りとして挙げています。

STEP5〜6：公開前テストと公開

公開前に、公式ドキュメントは次の3点の確認を挙げています。

1. すべてのボタン・リンクをクリックして動作を確認する
2. フィルターなどのインタラクティブ機能を、全カテゴリ・全条件で検証する
3. デバイストグルを使い、モバイル表示を確認する

確認できたら、エディタ右上のPublishをクリックし、ダイアログでWebサイトのURL（`〇〇.lovable.app`）を編集して、もう一度Publishを押します。これでセキュリティスキャンが実行され、デプロイされます。公開操作自体にクレジットは消費されません（チャット経由で公開を依頼した場合は、通常のチャットメッセージとして消費されます）。

ここで最も間違えやすいのが、公開後の変更はPublishを押し直すまでライブに反映されないという仕様です。Publishボタンに小さな点が表示されていれば、それは「ライブ版より新しい変更がある」というサインです。公式のPublishドキュメントにも明記されているとおり、各Publishはプロジェクトのスナップショットをデプロイする方式です。

PlanモードとBuildモードはどう使い分けるのか？

2つのモードはそれぞれ何をするのか？

公式用語集では、2つのモードは次のように定義されています。

なお、以前「Agentモード」と呼ばれていた機能は、現在Buildモードに名称変更されています。古い解説記事では旧称のまま説明されていることがあるため注意してください。

なぜ設計はPlanモードで固めてからBuildに渡すべきなのか？

理由は2つあります。

第一にコストです。Planモードは何を相談しても1メッセージ1クレジット固定ですが、Buildモードは作業量に応じて変動し、公式ドキュメントの例では画像生成を伴うランディングページ作成で2.00クレジットに達します。迷いながらBuildで試行錯誤するより、Planで方針を固めてからBuildを1回叩くほうが安い。

第二に手戻りです。Planモードはコードを一切変更しないため、方針が違えば捨てるだけで済みます。Buildで作ってしまうと、バージョンを戻す操作が必要になります。

公式ガイドが紹介している実践的なテクニックとして、プロンプトの末尾に「Ask me any questions you need in order to fully understand what I want（私の意図を完全に理解するために必要な質問をしてください）」と添える方法があります。AIに先に質問させることで、認識のズレを実装前に潰せます。

良いプロンプトと悪いプロンプトは何が違うのか？

悪いプロンプトの典型はどんなものか？

公式ガイドが挙げる代表的な誤りは次のとおりです。

もう一つ、見落とされがちな誤りがプレースホルダーテキストの使用です。「Feature 1／Feature 2／Feature 3」で作ると、実際の文言を入れた瞬間にレイアウトが破綻します。公式ガイドは実際のコンテンツで設計することを一貫して推奨しています。日本語サイトを作る場合、この点はさらに重要です。英語のダミーテキストで組んだレイアウトは、日本語を入れると行長と改行位置が変わり、ほぼ確実に崩れます。

再利用できるプロンプトの「型」とは何か？

公式ガイドが示す構造は、おおむね次のように定式化できます。

【何を】＋【どんな構造で】＋【どんな要素を含んで】＋【どんな見た目・挙動で】＋【何を変えないか】

そして、ページ全体を一度に依頼するのではなくコンポーネント単位（ヒーロー、カード、フォームなど）で刻む。これは制御しやすさだけでなく、再利用性の観点からも推奨されています。

「変えない範囲」を指定するとなぜ結果が安定するのか？

Lovableは指示を受けると、関連しそうなコードを探索して変更します。範囲を指定しなければ、意図しないファイルまで修正対象になり得ます。「このページだけ変更、既存スタイルは維持」と境界線を引くことは、品質を守るだけでなく、探索範囲を絞ることで消費クレジットを抑える効果もあります。

これは、外部の開発会社に修正依頼を出すときの作法とまったく同じです。「ここだけ直してください、他は触らないでください」と書くのは、相手が人間でもAIでも変わりません。

Knowledge（ナレッジ）を設定すると何が変わるのか？

Knowledgeは、公式用語集で「会話をまたいでLovableが記憶し続ける永続的な指示」と定義されています。適用範囲は2階層あります。

• ワークスペースKnowledge：そのワークスペースの全プロジェクトに適用
• プロジェクトKnowledge：個別プロジェクトの文脈・規約に適用

ここにデザインの方向性・ブランド要素（フォント、カラー、トーン）・頻出UIパターンを書いておくと、以降のすべてのプロンプトに自動適用されます。公式ガイドは「スタイルは粘着性がある（sticky）」と表現しており、一度設定すれば新しいセクションを作っても一貫性が保たれます。

企業利用では、これがブランドガバナンスの実装手段になります。ワークスペースKnowledgeにコーポレートカラー・タイポグラフィ・文体ルールを記述しておけば、どの部門の誰が作っても、出てくるアウトプットのトーンが揃う。デザインガイドラインをPDFで配って形骸化させるより、はるかに実効性があります。Lovable導入時に情報システム部門や広報部門が最初にやるべき設定は、実はここです。

副次効果としてコストも下がります。毎回スタイル指定を書き直す必要がなくなるため、プロンプトが短くなり、認識のズレによる作り直しも減ります。

バックエンド（Cloud）はどう追加するのか？

LovableのCloudは、公式用語集で「アプリのホスティングに加え、データベース・ストレージ・認証・リアルタイム・関数を備えた組み込みバックエンドを、外部設定なしで提供する」と定義されています。つまり、Supabaseなどのアカウントを別途用意しなくても、そのままバックエンド付きのアプリが作れます（外部のSupabaseプロジェクトを接続する選択肢もあります）。

追加の手順は、静的な画面が固まった段階で「ログイン機能を追加して」「この一覧をデータベースから取得するようにして」とチャットで依頼するだけです。ただし、ここからは設計上の注意点が一気に増えます。

• 認証状態の分岐：ログイン前後で何を見せるかを明示的に指示する
• ローディング状態：データ取得中の表示を指定しないと、空白画面になる
• アクセス制御：誰がどのデータを読み書きできるかを定義する

最後の点が最重要です。Lovableで作ったアプリの情報漏えい事故は、ほぼすべてが行レベルセキュリティ（Row Level Security）の設定漏れに起因します。「動いているように見える」ことと「他人のデータが見えない」ことは別問題です。公開前に必ず、別アカウントでログインして他人のデータが見えないことを実地で確認してください。

なお、Cloudの利用はクラウドクレジットを消費します。全プラン共通で月20クレジットが付与されますが、それを超える分は月次プランクレジットから引かれます。開発を止めても稼働中のアプリは消費し続けるため、「作って終わり」ではなく運用費として予算化が必要です。

外部サービスとの連携はどう設定するのか？

公式のコネクター一覧によれば、Lovableは決済・メッセージング・データ・生産性・CRMなどをカバーする組み込みカタログを提供しており、Slack、Notion、HubSpot、Google Workspaceなどが例示されています。接続方式は3種類あり、この違いを理解しないと権限設計を誤ります。

カタログにないサービスは、カスタムコネクター（任意のREST API）やカスタムMCPサーバー（社内CRM・プライベートAPI）で接続できます。HubSpot APIを使えば、Lovableで作った診断ツールやフォームからCRMへリードを書き戻す、といった構成も可能です。Stripeによる決済やResendによるメール送信も同様に組み込めます。

企業利用で注意すべきは共有アカウント型の接続です。App＋チャットコネクターは共有アカウントで接続されるため、そのアプリを使う全員が同じ権限で外部サービスに触れることになります。基幹システムやCRMと繋ぐ場合、接続に使うアカウントの権限を最小限に絞る設計が必須です。

公開したアプリはどう運用・更新するのか？

カスタムドメインはどう設定するのか？

カスタムドメインの接続は有料プラン（Pro以上）の機能で、公開後に設定できます。DNSの反映には時間がかかる場合があるため、接続直後ではなく反映後にSEOレビューを再実行することが推奨されています。なお、すでに接続済みのドメインはプランをダウングレードしても機能し続けます。

社内限定で公開するにはどうするのか？

BusinessおよびEnterpriseプランでは、公開時のアクセス制御ダイアログでWorkspace（ワークスペースメンバーのみ閲覧可）またはCustom（特定メンバー・メールアドレスを招待）を選べます。社内ツールを作る場合、この機能の有無がプラン選定の実質的な決定要因になります。Proには社内限定公開がないため、社内データを扱うアプリをProで運用するのは推奨できません。

公開を取り消したい場合は、Project settings → Unpublish project、公開ダイアログのメニュー、またはダッシュボードでの一括選択の3通りがあります。解除するとライブURLにアクセスできなくなりますが、プロジェクト自体はエディタに残ります。

SEOの設定はどこで行うのか？

Lovableはサイト作成時にサイトタイトル・メタディスクリプション・ファビコンを自動生成します。ページごとに異なるメタデータを設定でき、チャットで「Change my site title to…」のように指示して変更できます。ページセレクタのSocialカードとSearchカードで、SNSシェア時と検索結果での見え方をそれぞれ確認できます。

公開後は、インデックス状況・パフォーマンス・アクセシビリティをチェックするSEOレビューの実行が推奨されています。ただし、自動生成されたメタディスクリプションをそのまま使うのは避けるべきです。検索意図に合わせた書き換えは、AIではなく人が判断すべき領域です。

公開前のセキュリティチェックはどうするのか？

前述のとおり、Publish時にはセキュリティスキャンが自動実行されます。加えてBusiness・Enterpriseプランでは、セキュリティセンターでワークスペース全体のリスクを一元管理できます。監視対象は4領域です。

1. コード分析（Basic／Deepの2種のスキャン）
2. サプライチェーンセキュリティ（依存パッケージの脆弱性追跡）
3. シークレット管理（APIキーなど秘密情報の可視化）
4. セキュリティインサイト（プロジェクト横断の優先度付け。EnterpriseではPII検出も含む）

検出結果はエラー（公開前に解決すべき重大問題）／警告／情報の3段階に分類されます。注意点として、スキャンは自動実行されません。ユーザーが手動でトリガーするか、Enterpriseプランで週次・月次のスケジュール実行を設定する必要があります（スケジュール実行はクレジットを消費します）。「セキュリティセンターがあるから安心」ではなく、誰がいつスキャンを回すかを運用ルールとして決めておくことが前提になります。

また、セキュリティセンターから直接修正することはできず、個別プロジェクトのセキュリティビューを開いて対応する仕組みです。OWASP Top 10の観点を持つ担当者によるレビューを、公開フローに組み込むことを推奨します。

生成したコードをエンジニアに引き継ぐには？

Lovableは実際のコードを生成しており、Git Syncを使ってGitHubまたはGitLabと双方向に同期できます。公式用語集でも「バージョン管理、コードレビュー、開発者との協業のための双方向同期」と定義されています。

この双方向性が実務上の要点です。エンジニアがIDEで書いた変更がLovable側に反映され、Lovableでの変更がリポジトリに反映される。つまり「非エンジニアが作った試作を、エンジニアが引き取って本番化する」という受け渡しが、作り直しなしで成立します。

企業でのPoCにおいて、これは無視できない価値です。従来、事業部門が作ったプロトタイプは「動くけれど捨てるもの」でした。Lovableの場合、プロトタイプがそのまま本番のコードベースの出発点になり得ます。ベンダーロックインの懸念が比較的小さいのも同じ理由です。

クレジットを無駄にしない使い方は？

ここまでの内容を、コスト観点で再整理します。

もっとも効果が大きいのは1番目です。クレジット消費は「指示の質」の関数である——この一点を組織で共有できるかどうかが、Lovableの費用対効果を決めます。詳細な単価と試算は料金解説記事と公式ドキュメントをご参照ください。

企業でLovableを使う場合、個人利用と何が違うのか？

ここまでの手順は個人でも企業でも同じです。違うのは「作った後」に必要な設計です。

最後の行が、中長期で最も効いてきます。市民開発（Citizen Developer）を全社に広げると、数年後には「誰が作ったか分からない、誰も保守していないアプリ」が積み上がります。経済産業省「DXレポート」が指摘した既存システムのブラックボックス化と、構造はまったく同じです。作りやすさは、統制なしでは負債の生産速度でもある——ここを最初に設計できるかどうかが、AI内製化の成否を分けます。

株式会社100は、HubSpotのエリートパートナーとして100社以上のCRM導入・活用を支援してきた知見をもとに、Lovableによる内製化の上流設計、CRM連携、ガバナンス設計、社内定着までを一貫してご支援しています。「作れる人を増やす」だけでなく「作ったものが資産として残る」仕組みづくりをご一緒します。

よくある質問（FAQ）

Q1. Lovableの使い方は難しいですか？プログラミング知識は必要ですか？

操作自体はチャットに指示を書くだけで、プログラミング知識は不要です。LPや簡単な社内ツールなら非エンジニアでも作れます。ただし本番運用を前提とする場合、アクセス制御やデータ設計の判断が必要になるため、開発の基礎知識を持つ人のレビューが品質を左右します。

Q2. 日本語で指示できますか？

できます。生成されるUIの文言も日本語で指定可能です。ただしレイアウトを作る段階では、ダミーの英文ではなく実際の日本語の文言を入れて設計してください。文字数と改行位置が変わり、後からレイアウトが崩れる原因になります。

Q3. 最初のプロンプトはどれくらい詳しく書けばいいですか？

「何のサイトか」だけでは不十分で、含めるセクションを列挙する粒度が目安です。公式例では「ヒーローセクション、カテゴリ別フィルター付きメニュー、営業時間、所在地」と構成要素を並べています。一方で最初から全機能を書き切る必要はなく、認証やデータベースは後から追加するのが推奨手順です。

Q4. PlanモードとBuildモードはどう使い分けますか？

Planモードは相談・設計用でコードを変更せず、1メッセージ1クレジット固定。Buildモードは実装用で、作業量に応じて消費が変動します。迷っている段階はPlan、方針が決まったらBuildが原則です。

Q5. 思ったとおりに作ってくれないときはどうすればいいですか？

指示を細かく分割し、変更範囲を明示してください。「注文ページのみ変更、既存スタイルは維持」のように境界を引くと安定します。また、プロンプト末尾に「意図を理解するために必要な質問をしてください」と加え、実装前にAIに質問させる方法も公式ガイドで推奨されています。

Q6. 間違えて壊してしまったら戻せますか？

戻せます。すべての変更は復元可能なバージョンとして自動保存されます。大きな変更の前に節目でブックマークしておくと、リカバリがさらに容易になります。

Q7. 公開したのに変更が反映されません。なぜですか？

各Publishはスナップショットをデプロイする方式のため、公開後の変更はPublishを押し直すまでライブに反映されません。Publishボタンに小さな点が表示されていれば未反映の変更がある証拠なので、「Publish changes」を実行してください。

Q8. 公開にクレジットは消費されますか？

公開操作自体は消費しません。ただしチャット経由で公開を依頼した場合は、通常のチャットメッセージとして1回分が消費されます。

Q9. 独自ドメインは使えますか？

使えます。カスタムドメインの接続はPro以上の有料プラン機能で、公開後に設定します。DNSの反映に時間がかかることがあるため、反映後にSEOレビューを再実行してください。

Q10. 社内の人だけに公開することはできますか？

できます。Business・Enterpriseプランでは、公開時に「Workspace（メンバーのみ）」または「Custom（特定メンバー・メールアドレスを招待）」を選択できます。社内データを扱うツールを作る場合、この機能があるBusiness以上が実質的な前提になります。

Q11. 作ったアプリのセキュリティはどう確認しますか？

Publish時にセキュリティスキャンが自動実行されます。Business以上ではセキュリティセンターでコード分析・依存パッケージ・シークレット管理を一元確認できますが、スキャンは自動では回らないため、手動実行かEnterpriseのスケジュール実行が必要です。加えて、別アカウントでログインして他人のデータが見えないことを実地で確認してください。

Q12. 生成されたコードは自分で編集できますか？エンジニアに渡せますか？

できます。コードエディタで直接編集できるほか、Git SyncでGitHub／GitLabと双方向同期が可能です。エンジニア側の変更がLovableに戻る双方向同期のため、試作から本番化への引き継ぎが作り直しなしで行えます。

Q13. 無料プランだけで使い方を習得できますか？

基本操作の習得は可能ですが、Freeは1日5クレジット・月30クレジット上限で、カスタムドメインも使えません。通しで1本作り切る練習には不足するため、実務検証に入る段階でProへの移行を想定してください。

Q14. 社内で複数人が使う場合、何から設定すべきですか？

優先順位は、①ワークスペースKnowledgeにブランド・デザイン規約を登録、②メンバー別のクレジット上限を設定、③公開権限とセキュリティスキャンの運用ルールを決定、④Git同期先を統一——の順です。配布してから統制しようとすると必ず遅れます。

本記事の操作手順・仕様は、2026年8月31日時点のLovable公式ドキュメントの記載に基づきます。Lovableは機能改訂の頻度が高く、UI名称も変更される場合があります（例：旧「Agentモード」→現「Buildモード」）。実際の操作時は公式ドキュメントで最新をご確認ください。