Lovableとは？Plan Mode・Agent Mode・GitHub連携で読むVibe Codingガイド

会話だけで作ったアプリは、どの時点でGitHub、コードレビュー、セキュリティ検証という「人間側の責任」に接続すべきなのか。この記事は、その切り替わる瞬間がLovableのどの機能に埋め込まれているかを、公式docsの記述から特定する試みです。

この記事を単体で書く動機は、前作の整理そのものにあります。AIコーディング主要プレイヤー整理では、Cursor・Devin・Lovable・Replit・LangChainの5社を「どの仕事を任せる道具か」で整理しましたが、「導入前に確認したいこと」欄で具体的な二択がそのまま3つ並んだのはLovableだけでした。GitHubを主系にするかLovableを主系にするか、公開範囲をexternalにするかworkspace内に閉じるか、backendをLovable CloudとSupabaseのどちらで持つか。他の4社ではここまで粒度の揃った分岐が出てこなかったことから、Lovableだけは単体で深掘りする価値があると判断しています。

今回はその1枠だったLovableだけを深掘りし、単体でどこまで任せてよいかを機能単位で確認します。素材は主にLovable公式docs、pricing page、GitHub上のgpt-engineerリポジトリです。2026-04時点のdocsをもとに整理しているため、planや権限まわりの仕様は今後変わりえます。導入前には現行のdocsを必ず確認してください。もう一つ先に断っておくと、この記事はdocsの読解であって、私自身がLovableで本番規模の運用を検証したわけではありません。その境界は最後にもう一度書きます。

---

前提:「切り替え点」と2つの「可視性」

この記事は2つの言葉を軸にします。

切り替え点とは、Lovableが握っていた判断や検証の主導権を、人間側の作業に明示的に渡す瞬間のことです。具体的には次の3か所に現れます。

1. GitHubへ同期し、source of truthがLovableからGitHubへ移る瞬間
2. Supabase dashboardでRLS policyをreviewする瞬間
3. publish前にeditor access と published URL の公開範囲を確認する瞬間

編集の可視性と公開の可視性は、Publish docsが独立していると明記する2つの軸です。編集の可視性はeditor内で誰がproject / source codeを見て編集できるかを指し、公開の可視性はpublished URLに誰が到達できるかを指します。この2つを混同すると、「公開したらコードも見えるのか」「editorを閉じればURLも閉じるのか」を誤解しやすくなります。

全体像は次の6つの機能面に集約できます。

---

Plan ModeとAgent Mode

Plan Modeのdocsは、Plan Modeをコードが書かれる前に考え、比較し、調べるためのmodeと定義しています。ここでは質問、デバッグ、アプローチ比較、設計検討が中心で、Plan Modeはコードを変更しません。明確な実装案が見えたときにはformal planが作られ、最新版は.lovable/plan.mdに保存されると説明されています。実装前のreasoningをartifactとして残す設計です。

一方のAgent Modeは、公式docsでproject内の変更を直接implementし、verifyするmodeと説明されています。実装と検証を実行する側の役割です。Agent Modeはintentを解釈し、codebaseを探索し、ファイルをまたいで修正し、開発中に出た問題へ対処します。

使い分けはシンプルです。要件が曖昧で影響範囲が読めないうちはPlan Modeで方向を固定し、変更内容が見えたらAgent Modeに渡して実装からverificationまで一気に進める。Lovableを「とりあえずpromptを打つ場所」として使うより、Planで固めてからAgentに渡す方が、不要な差分ややり直しを減らしやすいはずです。

この考え方は、Claude Code創設者インタビューを読み直した記事で整理した内容と重ねると理解しやすいと考えています。その記事では、変更対象と非対象を先に明示し、計画を短く出させ、人間が危険な範囲を削ってから実装させるという順番で切ると事故が減ると整理しました。Lovableのplan mode/agent modeの分離も、同じ「考える工程」と「実行する工程」を切り分ける設計をLovable向けに実装したものとして読むのが妥当だとみています。ただしこれはClaude Codeの運用整理から導いた類推であり、Lovable自体でこの分離の効果を検証したわけではありません。

この構造がある分、Lovableは単純なone-shot app generatorよりも、計画と実行を往復できるIDE的なproductとして読む方が正確です。

---

Visual editsとcode editor

Visual editsのdocsでは、Lovableはtext、colors、layout、imagesをコードを書かずに直接変更できるvisual editorを提供しています。daily limitの範囲ではcreditsを消費せず、デザインの微修正を高速に進められます。任意のUI要素を選んで調整する、marginやpaddingを視覚的に詰める、textやcolorsやfontsをsidebarから更新する、画像を差し替える。この4つが主な用途です。デザイナーやマーケ担当やPMがcopyやspacingを詰める段階では、promptよりVisual editsの方が安全で速い場面があります。

それでもコードを見たくなる場面は残ります。Lovableのcode editorは、full project file structureの閲覧、検索、手編集、format、ZIPダウンロードを提供しています。paid planでは、生成コードを直接見て、必要なら局所的に修正できます。Lovableはno-codeの入口を持ちながら、最終的にはコードの所有権を人間側が握る設計に寄っています。したがって、完全にコードを見ない前提で語るより、どこまでvisualで済ませ、どこからcode / reviewに切り替えるかを先に決めておく方が実務的です。

---

GitHub連携

GitHub integration docsは明確です。Lovableでbuildしたcodeはplatform内にありますが、自分のcopyを持ちたい、開発者と共同作業したい、他所へ移したいならGitHubにexport / syncできます。同期によって、code backup、pull requestsやbranchesやcode reviewsを使った共同作業、LovableとGitHubの自動sync、IDEでのローカル作業、self-hostingや別platformへのdeployが可能になります。

GitHubは必須ではありません。公式docsでも、Lovableだけでbuild / launchする利用者がいると説明されています。ただしbackup、ローカル作業、branch、PR、外部deployを考えるなら、同期の価値は大きくなります。

ここで導入判断に直結する制約が3つあります。GitHub接続後はGitHubがsingle source of truthになること、LovableとGitHubはtwo-way syncだが基本はdefault branchを中心に同期すること、そして既存のGitHub repoをLovableにimportすることはできないことです。3つ目は特に見落とされやすく、既存repoの改修起点として使いたい場合は、この制約を先に確認する必要があります。

この3点から、相性は次のように整理できます。

Lovableの境界は、どの時点でGitHubをsource of truthに切り替えるべきかで決まります。「コードを外へ出せるかどうか」という発想ではこの境界を捉えられません。これが1つ目の切り替え点です。

---

backendの選択

Quick startでは、backendを足したいときの選択肢としてLovable CloudとSupabase integrationが案内されています。

Lovable Cloud docsは、これをdatabase、authentication、storage、edge functions、AIを内蔵したfull-stack hosting platformと説明しています。Supabaseのopen-source foundationを使っており、backendの初期設定なしでproduction-ready environmentを得られるとしています。認証、データ、ファイル、edge logic、AI featureまでまとめて扱いたいチーム向けのmanaged full-stack機能面です。

Supabase integration側では、Supabaseはhosted PostgreSQL、real-time、user auth、file storage、serverless functionsを持つbackendとして説明されています。Lovableとつなぐと、boilerplateやserver設定を自前で積まずにbackendを使い始められます。ただし公式docsでも、RLS policyは必ずSupabase dashboardでreview / testしてからreal usersを招待するよう促しています。backend生成が速いことと、security reviewが不要であることは別だという線です。

どれを選んでも、permissions、secrets、data access、verificationは残ります。Lovableはbackend立ち上げを楽にしますが、運用責任まで消してくれるわけではありません。RLS reviewがSupabase dashboard側の作業として残る、これが2つ目の切り替え点です。

---

publishとcustom domain

Publish docsで特に重要なのは、前提で定義した編集の可視性と公開の可視性が独立だという点です。publish時にはlovable.appのURLを自動生成でき、paid planではcustom domainを追加できます。Free / Proでは公開したアプリはwebへexternal publishされ、Business / Enterpriseではworkspace内だけにpublishする選択肢があります。

Custom domain docsでは、外部providerのdomainをつなぐ場合、ドメインの所有権を確認するためにDNSのA / TXT recordsを追加する必要があります。subdomainも接続できますが、wwwを自動で含むかどうかは取得元によって挙動が違います。

公開前には次の4点を切り分けて考えるべきです。

1. editor accessを誰に渡すか
2. published URLを誰に見せるか
3. custom domainをrootで張るか、subdomainで張るか
4. internal toolとpublic siteのどちらとして運用するか

この4点を先に決めておくことが、3つ目の切り替え点です。

---

verificationとsecurity

「代替ではない」という線

Lovableのdocsで好印象なのは、verificationとsecurityを別ページで明示していることです。

Test and verify your appdocsでは、Lovableは次の検証手段を提供しています。実ブラウザでuser flowをたどるbrowser testing、UI behaviorの回帰確認を行うfrontend tests、backend logicを確認するedge function verificationです。browser testingではconsole logs、network requests、test failuresなども観測できるため、何を確認できたかを具体的な形で残しやすい設計です。

Security overviewとSecurity viewのdocsは、LovableがRLS analysis、database security check、code security review、dependency auditというscannerを使うと説明しています。ただし同じdocsで、これらはthorough security reviewの代替ではなく、sensitive dataやcritical functionを扱うappの安全性は利用者が責任を持つとも明記されています。

私はここが本記事で一番重要な一文だと考えています。Lovableはむしろsecurity支援機能を増やしている側です。しかしその支援をもって「production readyが保証された」と読むのは過剰です。だから私は、Lovableを新規の小規模アプリを最速で立ち上げる道具としては使う価値があると考えていますが、既存リポジトリの改修や、認証・決済・RLSなど失敗コストの高い機能が主戦場になるプロジェクトの中心には推しません。理由はここまで見た2本の線、既存repoのimportができずGitHub接続後はGitHubがsource of truthになること、そしてsecurity toolsを公式docs自身が「代替ではない」と位置づけていることです。ただし私自身がLovableで本番規模の運用を検証したわけではありません。ここまでの判断はdocsの読解に基づくもので、その境界は残しておきます。

公開されているSecurity overviewとProject security viewのscanner一覧を突き合わせると、この4つは検出できる欠陥の性質が異なると考えられます。RLS analysisとdatabase security checkは、policyの設定漏れや構造的な不備という「決まった形の欠落」を機械的に検出できる領域です。一方でcode security reviewとdependency auditは、既知の脆弱性パターンや既知の脆弱な依存関係を拾う設計であり、いずれも「この業務でどのロールにどこまで見せてよいか」という要件そのものの妥当性までは判定しません。たとえばあるテーブルへの読み取りをどの権限レベルまで許すべきかは、業務要件を知る人間にしか決められない判断であり、scannerが構造的な不備を検出できても、その要件設計が正しいかどうかは別問題です。docsが繰り返し「thorough security reviewの代替ではない」と明記しているのは、この機械的に拾える欠陥と要件依存の欠陥の境界を指していると考えています。

---

gpt-engineerとの関係

GitHub上のgpt-engineerrepoは、自らをcode generation experimentation platformと説明し、Lovableのprecursorと位置づけています。READMEでも、managed service側とは別物であることが明記されています。gpt-engineerはOSSのCLI / experimentation platformで、Lovableは Plan / Agent / Visual / GitHub / Publish / Cloudを持つmanaged productです。両者は地続きですが、読むべき一次情報は違います。GPT Engineerで見た古いCLIの印象を、そのまま今のLovableに持ち込まない方が安全です。現行の導入判断では、GitHubのstar数や昔のwaveよりも、いまのdocsに何が書かれているかを優先すべきです。

---

導入前に決める3つの切り替え点

ここまでの機能面を、導入前に決める順番として並べ替えると次のようになります。

1. GitHubへ切り替えるか: 新規プロトタイプや小規模アプリならLovable起点で進め、成熟した既存repoの改修が目的ならこの時点でLovableは外す
2. backendをどこに置くか: Lovable Cloudで完結させるか、Supabase integrationで明示的に持つか、どちらでもRLS reviewは自分たちの作業として残ると決めておく
3. publish範囲をどう切るか: editor accessとpublished URLを別々に管理し、internal toolかpublic siteかを公開前に決める

Replitの使いどころで使った「潰すコスト/潰さないコスト」という読み方をここに当てはめると、Lovableが潰すのは「非エンジニアが会話からUIとflowを立ち上げるコスト」です。潰さないのは、GitHub接続後のコードレビューコスト、RLSやpermissionsのreviewコスト、publish前の公開範囲確認コストの3つで、これは上の3つの切り替え点とそのまま重なります。

Lovableが向くのは、仕様を文章で叩き台にしたい初期プロトタイプ、ランディングページや小規模なweb app、internal toolやCRUD中心のworkflow、PM / designer / marketerが自分でUIとflowを叩きたい場面、そしてGitHubへ同期してから開発者レビューにつなげたい場面です。逆に、既存の大きなrepoをそのまま持ち込みたい、publish前に厳格なgovernanceやcompliance reviewが必要、secretsやRLSやpaymentやauthなどfailure costの高い機能が中心、public launch前にinfra / observability / security reviewを自前で握りたい、というプロジェクトでは、早めに別の体制を意識した方がいいと私は見ています。Lovableが使えないのではなく、GitHubへsource of truthを切り替える時点を導入前に決められるかどうかが分かれ目です。

古くなりやすいのは派手な数字です。逆に古くなりにくいのは、どこまでを会話で進め、どこからをコード・権限・検証・公開設定で締めるかという、この3つの切り替え点そのものだと思います。

---

参考リソース

Lovable公式docs

• Plan Mode
• Agent Mode
• Visual edits
• Code editor
• GitHub integration
• Publish your project
• Custom domains
• Lovable Cloud
• Supabase integration
• Test and verify your app
• Security overview
• Project security view

公式pricing / repo

• Lovable Pricing
• gpt-engineer GitHub