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

Lovable を今読むなら、派手な startup story より先に、どこまでを会話で作り、どこからをコード・GitHub・検証・公開設定で締めるのか を把握する方が実務的です。

現行の公式 docs を見ると、Lovable は単なる「一発生成ツール」ではありません。Plan Mode で方針を固め、Agent Mode で実装し、Visual edits で見た目を調整し、必要なら code editor や GitHub 同期に移る、という複数の surface を持つ build workflow として案内されています。

本記事では、Lovable 公式 docs、公式 pricing、GitHub 上の gpt-engineer リポジトリを起点に、いま一次情報で確認しやすい論点だけを整理します。古い deep-dive に多かった headline number ではなく、mode の役割分担、ownership、backend、publish、verification、security boundary に軸を置きます。

---

この記事でわかること

1. Lovable を Plan Mode -> Agent Mode -> Visual edits -> GitHub -> Publish の workflow として読む読み方
2. Lovable Cloud と Supabase integration をどう切り分けるか
3. GitHub sync、editor access、published URL access を混同しないための考え方
4. browser testing と security view をどこまで信用し、どこから人間が責任を持つべきか

基本情報

---

Lovable を今読む価値は「1回の生成」ではなく build workflow にある

Lovable の docs は、自然言語でアプリを作る体験を前面に出しつつも、実際には次のような段階的 workflow を用意しています。

1. Plan Mode で方向を決める
2. Agent Mode で変更を実装し、必要なら検証する
3. Visual edits や code editor で局所的に詰める
4. GitHub に同期して ownership と collaboration を固める
5. publish / custom domain / security view で公開前チェックを行う

この流れを先に理解しておくと、「非エンジニアでも作れる」という話と、「そのまま本番運用できるのか」という話を混同しにくくなります。

古い記事ほど、Lovable を Vibe Coding ブームの象徴 として説明しがちです。ただ、今の docs で durable に残せる価値はブーム性ではありません。残せるのは、計画、実装、手修正、同期、公開、検証の責任分界 です。

---

まず把握したい 6 つの surface

この整理で大事なのは、Lovable が「コードを書かなくてよい箱」ではなく、コードを書かない段階から GitHub や security review に接続できる段階までを1つの product に寄せた環境 だということです。

---

Plan Mode と Agent Mode は「考える」と「実行する」を分ける

Plan Mode の docs は、Plan Mode を コードが書かれる前に考え、比較し、調べるための mode と定義しています。ここでは質問、デバッグ、アプローチ比較、設計検討が中心で、Plan Mode はコードを変更しません。

また、明確な実装案が見えたときには formal plan が作られ、最新版は .lovable/plan.md に保存されると説明されています。つまり Lovable は、単なるチャットではなく、実装前の reasoning を artifact として残す設計 を持っています。

一方の Agent Mode は、公式 docs で changes directly in your project を implement and verify する execution mode と説明されています。Agent Mode は intent を解釈し、codebase を探索し、ファイルをまたいで修正し、開発中に出た問題へ対処します。

この 2 つをどう使い分けるべきか

• Plan Mode: 要件が曖昧、影響範囲が読めない、DB 設計や UI 方針を先に詰めたい
• Agent Mode: 変更内容が見えた、実装まで一気に進めたい、verification まで任せたい

実務で重要な読み方

Lovable を「とりあえず prompt を打つ場所」として使うより、Plan で方向を固定してから Agent に渡す 方が、不要な差分ややり直しを減らしやすいです。

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

---

Visual edits と code editor を使うと「完全 no-code」ではなくなる

Visual edits の docs では、Lovable は text、colors、layout、images をコードを書かずに直接変更できる visual editor を提供しています。daily limit の範囲では credits を消費せず、design の微修正を高速に進められるのがポイントです。

これは、prompt を投げて UI を作り直す だけが Lovable ではないことを示しています。とくにデザイナー、マーケ担当、PM が copy や spacing を詰める段階では、Visual edits の方が prompt より安全で速い場面があります。

Visual edits でできること

• 任意の UI element を選んで調整する
• margins / padding / alignment を視覚的に詰める
• text、colors、fonts を sidebar から更新する
• 画像を差し替える

それでもコードを見たくなる場面

Lovable の code editor は、full project file structure の閲覧、検索、手編集、format、ZIP ダウンロードを提供しています。paid plan では、生成コードを直接見て、必要なら局所的に修正できます。

この点が重要です。Lovable は no-code 入口を持ちながら、最終的には code ownership に寄せられる product です。したがって、完全にコードを見ない前提で語るより、どこまで visual で済ませ、どこから code / review に切り替えるか を考える方が実務的です。

---

GitHub integration は「所有権」と「移行可能性」の境界になる

GitHub integration docs は、かなり明確です。Lovable で build した code は platform 内にありますが、自分の copy を持ちたい、開発者と共同作業したい、他所へ移したいなら GitHub に export / sync できる と説明されています。

さらに docs は、GitHub 連携によって次が可能になると整理しています。

• code backup
• pull requests、branches、code reviews を使った collaboration
• Lovable と GitHub の自動 sync
• IDE でのローカル作業
• self-hosting や別 platform への deploy

特に重要な 3 つの注意点

1. GitHub 接続後は GitHub が single source of truth になる
2. Lovable と GitHub は two-way sync だが、基本は default branch を中心に同期する
3. 既存の GitHub repo を Lovable に import することはできない

この 3 点から、Lovable は次のように読むのが安全です。

つまり Lovable の境界は「コードを外へ出せるか」ではなく、どの時点で GitHub を source of truth に切り替えるべきか にあります。

---

backend は Lovable Cloud と Supabase integration を切り分けて考える

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

Lovable Cloud をどう読むか

Lovable Cloud docs は、これを database、authentication、storage、edge functions、AI を内蔵した full-stack hosting platform と説明しています。しかも Supabase の open-source foundation を使っており、backend の初期設定なしで production-ready environment を得られるとしています。

要するに Lovable Cloud は、frontend だけ作る場所 ではありません。認証、データ、ファイル、edge logic、AI feature までまとめて扱いたいチーム向けの managed full-stack surface です。

Supabase integration をどう読むか

Supabase docs 側では、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 立ち上げを楽にしますが、運用責任まで消してくれるわけではありません。

---

publish と custom domain は「editor access」と別物

Publish docs で特に重要なのは、project visibility と website access は別 だと明記されていることです。

• project visibility: editor 内で誰が project / source code を見て編集できるか
• website access: published URL に誰がアクセスできるか

この 2 つを混同すると、「公開したらコードも見えるのか」「editor を閉じれば URL も閉じるのか」を誤解しやすくなります。

Publish surface の基本

• publish 時には lovable.app の URL を自動生成できる
• paid plan では custom domain を追加できる
• Free / Pro では published app は web へ external publish される
• Business / Enterprise では workspace 内だけに publish する選択肢がある

Custom domain で確認したいこと

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

したがって公開前には、次を切り分けて考えるべきです。

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

---

verification と security は Lovable の強みだが、人間の責任は残る

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

verification で見ておきたいもの

Test and verify your app docs では、Lovable は次の検証手段を提供しています。

• browser testing: 実ブラウザで user flow をたどる
• frontend tests: UI behavior の回帰確認
• edge function verification: backend logic の確認

browser testing では console logs、network requests、test failures なども観測できるため、動いた気がする ではなく、何を確認できたか を残しやすい設計です。

security で見ておきたいもの

Security overview と Security view の docs は、Lovable が次の scanner を使うと説明しています。

• RLS analysis
• database security check
• code security review
• dependency audit

ただし同じ docs で、これらは thorough security review の代替ではなく、sensitive data や critical function を扱う app の安全性は利用者が責任を持つ とも明記されています。

これはかなり重要です。Lovable は security を無視しているのではなく、むしろ支援 surface を増やしています。しかし、その支援をもって「production ready が保証された」と読むのは過剰です。

---

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 が「使えない」のではなく、どこまでを Lovable に任せ、どこからを GitHub、IDE、Supabase dashboard、security review に切り替えるか を先に決めることです。

---

GPT Engineer との関係は「前史」と「現行 product」を分けて読む

GitHub 上の gpt-engineer repo は、自らを code generation experimentation platform と説明し、Lovable の precursor と位置づけています。README でも、managed service 側とは別物であることが明記されています。

このため、GPT Engineer で見た古い CLI の印象 を、そのまま今の Lovable に持ち込まない方が安全です。

• gpt-engineer: OSS の CLI / experimentation platform
• Lovable: Plan / Agent / Visual / GitHub / Publish / Cloud を持つ managed product

両者は地続きですが、読むべき一次情報は違います。現行の導入判断では、GitHub の star 数や昔の wave よりも、いまの docs に何が書かれているか を優先すべきです。

---

よくある質問

Q1. Lovable は完全な no-code ツールですか？

完全な no-code と言い切るより、no-code 入口と code ownership の出口を両方持つ product と考える方が正確です。Visual edits で見た目を詰められますが、code editor、ZIP download、GitHub sync も用意されています。

Q2. GitHub は必須ですか？

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

Q3. 既存の GitHub repo を Lovable に持ち込めますか？

現行 docs では import はできず、Lovable から GitHub への export / sync が基本 とされています。既存 repo の改修起点として使いたい場合は、この制約を先に確認してください。

Q4. Lovable Cloud と Supabase integration はどう違いますか？

Lovable Cloud は managed な full-stack hosting surface、Supabase integration は Supabase の backend capabilities を Lovable から使う導線と読むと整理しやすいです。どちらでも data access と security review は残ります。

Q5. publish すると editor の project も公開されますか？

いいえ。docs では project visibility と website access は independent と説明されています。公開 URL の可視性と editor access は別に管理されます。

Q6. Lovable の verification だけで本番公開してよいですか？

公式 docs の姿勢はそこまで強くありません。browser testing や security view は有用ですが、sensitive data や critical function を扱う app では、追加の human review が前提です。

---

まとめ

Lovable を今読むなら、中心に置くべきなのは Vibe Coding 市場 や company metric ではありません。中心に置くべきなのは、Plan、execution、visual editing、code ownership、backend、publish、security のつながり方 です。

一次情報から残しやすい結論は次の通りです。

1. Lovable は Plan Mode -> Agent Mode -> Visual edits -> GitHub -> Publish の workflow として読むと理解しやすい
2. GitHub integration は collaboration の便利機能というより、ownership と移行可能性の境界として重要
3. backend と公開は速く進められるが、verification と security responsibility は残る

古くなりやすいのは派手な headline number です。逆に古くなりにくいのは、どこまでを会話で進め、どこからをコード・権限・検証・公開設定で締めるか という運用論点です。

---

参考リソース

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

---

本記事はネクサフローのAI研究シリーズの一部です。