「作りたい画面を日本語で説明したら、動くWebアプリが返ってくる」。Lovableを初めて触ったときの体験は、たしかにその一言に尽きます。ただ、実務で使い込むと分かるのは、最初の一画面を出すことよりも、「どこを設定してから本格運用に入るか」「どこから先はLovableに任せないか」の見極めのほうがずっと重要だということです。
Respectifyでは自社のマーケティング管理アプリをLovableで立ち上げ、その後の作り込みをClaude Codeに引き継ぐ形で実運用しています。本記事では、公式ドキュメントで裏取りできる範囲の基本手順に加えて、この実運用から得た「クレジットを無駄にしない使い方」と「任せる範囲の線引き」までを解説します。いわゆるバイブコーディングを実務に持ち込む際の、現実的な運用ガイドとして読んでいただければと思います。
なお、本記事の仕様・画面名称はすべて2026年8月15日時点の公式ドキュメントに基づきます。Lovableは機能更新が非常に速いため、実際の操作時は最新のドキュメントもあわせて確認してください。
最短の使い方：プロンプトから公開まで
公式ドキュメントは、Lovableでの開発を「作りたいものを説明する。生成されたアプリを確認して繰り返し改善する。GitHubにコードを同期する。自社の基準に沿ってデプロイ・運用する」という流れで説明しています（参照：Lovable公式ドキュメント「Introduction」(2026)）。最初の3ステップだけ押さえれば、その日のうちに公開まで到達できます。
最初のプロンプトは「1画面ぶん」に絞る
プロジェクトを作成したら、最初のメッセージで作りたいものを説明します。ここで全機能を一気に書きたくなりますが、おすすめしません。理由は後述するクレジットの問題と、生成結果の手戻りです。まずは「誰が使う何のアプリか」「最初に見えるべき画面」「主要なデータ項目」程度に絞り、動くものを見てから次の指示を重ねるほうが、結果的に速く安く仕上がります。
プレビューで確認しながら追加指示
生成のたびに右側のプレビューが更新されるので、実際に触りながら「この一覧に検索を付けて」「この色をコーポレートカラーに」と日本語で指示を重ねます。仕様の相談だけしたいときは、コードを書かせずに対話するモードを使うとクレジット消費を抑えられます（モード名称や消費量の詳細はLovableの料金の記事で解説しています）。
公開は数クリック、独自ドメインは有料プラン
公開操作をすると、そのままアプリを共有できる状態になります。公開URLの形式や独自ドメインの条件などの詳細はLovableの料金の記事で解説していますので、社外公開を前提とする場合は事前にご確認ください。
ここまでが最短の使い方です。ただし、このまま業務アプリとして運用に入るのは推奨しません。次の3つの設定を先に済ませてください。
実務で差がつく3つの設定
Supabase連携：認証・データベースと「承認制SQL」
ログイン機能やデータ保存が必要なアプリでは、バックエンドとして、「オープンソースのFirebase代替」として紹介されることが多いSupabase（PostgreSQLベースのBaaS）を接続できます。メール・パスワード認証やソーシャルログイン、ファイルストレージ、サーバーレス関数までが自然言語の指示で構成できます。
実務上ありがたいのは、データベース変更が承認制になっている点です。公式ドキュメントには、LovableがSQLを書いてユーザーに提示し、チャット上で承認を得てから実行すると明記されています（参照：Lovable公式ドキュメント「Supabase integration」(2026)）。AIに全権を渡すのではなく、データ構造の変更だけは人間が目を通す設計です。これは、非エンジニアの内製化でも安心材料になります。同ドキュメントは、公開前にすべてのテーブルへRLS（行単位のアクセス制御）ポリシーを設定するよう警告しており、この点は本記事の後半で改めて取り上げます。
GitHub連携：双方向同期が「外の世界」への出口になる
GitHub連携を有効にすると、Lovable上の変更がGitHubリポジトリへ自動同期され、逆にGitHubへプッシュした変更もLovableに反映される双方向同期になります。公式ドキュメントは、リポジトリをローカルにクローンして「好みのIDEで作業を継続できる」ことを明記しています（参照：Lovable公式ドキュメント「GitHub integration」(2026)）。
つまりLovableは、自分の外で作り込まれることを公式に想定した設計になっています。この出口があるおかげで、「立ち上げはLovable、その後はエンジニアやAIコーディングツールで開発」という分業が成立します。プロジェクト開始時に必ず設定しておきたい項目です。
Knowledge：毎回同じ指示を繰り返さないための土台
Knowledgeは、Lovableに常時読み込ませる永続的な指示書です。全プロジェクト共通のワークスペース階層と、プロジェクト固有の階層の2段階があり、それぞれ最大10,000字まで書けます。デザインルール、用語、データ構造、してはいけないことをここに書いておけば、毎回のプロンプトで繰り返す必要がなくなります。GitHubリポジトリ直下のAGENTS.mdなどの指示ファイルも参照される仕様のため、外部ツールと指示書を共通化することも可能です（参照：Lovable公式ドキュメント「Knowledge」(2026)）。
Lovableはクレジット制のため、「指示が曖昧で生成をやり直す」ことがそのままコストになります。Knowledgeを最初に整えることは、品質対策であると同時に、もっとも効果の大きいクレジット節約策です。
どこからはLovableでやらないか
ここからが、Respectifyの実運用でもっとも重要だと考えている論点です。
公式設計が示す役割分担
前述のとおり、公式ドキュメント自身が「GitHubに同期し、クローンして好みの環境で開発を続ける」道筋を用意しています。Lovableをすべての工程で使い続けることは、公式設計上も前提とされていません。私たちはこれを「立ち上げの装置」と捉えています。
Respectifyの実運用：立ち上げはLovable、作り込みはClaude Code
自社アプリの開発では、画面の骨格とデータ構造ができた時点でGitHub連携に切り替え、以降の機能追加・修正はClaude Codeでローカル開発しています。理由は2つあります。第一に、細かい修正の反復はクレジット消費がかさむこと。第二に、複数ファイルにまたがる複雑な変更は、コードベース全体を読めるツールのほうが精度が高いことです。
この運用に落ち着く過程で、高い授業料も払いました。初期に、最初のメッセージへ全仕様を詰め込んで生成させたところ、大量の手戻りと修正の反復でクレジットを急速に消費してしまったのです。以来、Lovableへの依頼は「動く最小限の骨格まで」と社内ルールを決めています。
公開前のセキュリティチェックだけは省略しない
もう1つ、非エンジニアの方にこそ強調したいのが公開前の確認です。2025年5月には、Lovableで生成されたアプリにRLS設定の不備があり、認証なしでデータベースが読み書きできる状態だったとする脆弱性報告CVE-2025-48757がNVD（米国の脆弱性データベース）に登録されました（参照：NVD「CVE-2025-48757」(2025)）。一方でLovable社はこの報告に異議を唱えており、生成されたアプリのデータ保護は各利用者の責任範囲だと主張しています。どちらの立場を取るにせよ、利用者側の実務的な結論は同じです。公開前にアクセス制御を自分で確認する工程を必ず挟んでください。
Lovableの公式ドキュメント自身が、公開前にすべてのテーブルへRLS（行単位のアクセス制御）を設定するよう警告しています（前述のSupabase連携の項で触れた出典の再掲です）。対策機能の有無にかかわらず、公開前の確認は利用者側の工程として組み込んでください。実際、私たちも自社アプリの公開前チェックで「ログインさえすれば他人のデータまで見える」状態の初期設定を検知し、許可リスト方式に組み直した経験があります。警告を読み流さず、「ログインしていない状態」「別ユーザーの状態」で実際にデータへアクセスできないかを、公開前に必ず自分の手で試すことをおすすめします。
まとめ
Lovableの使い方は、「プロンプト、プレビュー、公開」の3ステップだけなら1日で覚えられます。実務で差がつくのはその先で、Supabase連携・GitHub連携・Knowledgeの3つを最初に整えること、そして「立ち上げはLovable、作り込みは外部」という線引きを持つことが、コストと品質の両面で効いてきます。公開前のアクセス制御チェックだけは、どんなに急いでいても省略しないでください。
Respectifyでは、LovableとClaude Codeを組み合わせた業務アプリの内製化支援をRespectify STUDIOとして提供しています。「試作はできたが、業務で使える品質への引き上げ方が分からない」という段階のご相談もお受けしています。
Lovableでの立ち上げから本番運用に耐える品質への引き上げまでを、着手から本番化までの工程として確認したい方には、「AI業務実装ロードマップ。PoCで終わらせない工程表」もあわせてご活用ください。個別の進め方についてのご相談は無料相談へお気軽にどうぞ。
