Lovableで生成したコードを編集するときの考え方

Lovableで生成したコードを直すときは、まず変更の大きさと影響範囲で手段を選びます。文言や小さな見た目調整ならProject chatへ具体的な条件を伝える方法が扱いやすく、既存の処理を一行単位で確かめたいときはCode editorで該当ファイルを読みます。複数画面やdata structureに広がる変更は、いきなり手編集せず、先に計画・差分・戻し方を確認してください。

LovableのCode editorは、sourceを参照したり手で編集したりするための場所です。公式docsでは、Free planではread-only、保存を伴う編集はpaid planが必要とされています。権限や画面表示は更新され得るため、編集できない場合に操作ミスと決めつけず、project accessと現在のplan表示を先に確認しましょう。手で変更できることと、変更が安全であることは別です。

変更内容から編集方法を選ぶ

変更したいことをファイル名ではなく結果で説明できるかが分かれ目です。既存の設計を知らないまま「このコードを直して」と頼むと、見えない前提を崩す可能性があります。

表は横にスクロールできます

変更例	まず使う方法	保存前に見るもの
ボタン文言や余白の微調整	Project chatかCode editor	他の画面へ同じstyleが広がらないか
入力validationの追加	対象componentと処理を調査し、小さい変更	成功・失敗の両方の動作
複数画面の状態管理変更	先にPlanで影響範囲を整理	共有state、既存flow、migration
API keyや認証まわり	変更前に停止条件と権限を確認	client bundle、server側認可、logs
生成コードの原因調査	Code editorで検索し、該当箇所を特定	呼び出し元、関連component、test

「簡単そうだから直接編集」だけで決めないでください。CSS変数一つの変更でも、全画面に適用されるなら影響範囲は大きくなります。反対に、画面固有の説明文だけなら、code構造を触らずchatへ完成条件を伝える方が安全なことがあります。

直接編集の前に現状を一つ残す

変更前にVersion historyの現在地点を確認し、必要なら変更目的が分かるcheckpointやGit commitを残します。LovableのCode editorで保存した手動変更もprojectのVersion historyに記録され、戻せると公式説明されています。ただし、履歴があるから検証なしでよいわけではありません。

さらにGit syncを使う場合は、接続中のrepositoryとbranchを確認します。現行のGit syncはLovableとGit provider間の双方向同期を行い、Lovableは一度に一つのbranchを同期します。別branchにあるcommitは、同期branchへmergeするか同期先を切り替えるまでprojectに反映されません。保存した場所とGitHubへ反映される場所を同一視しないでください。

変更前に記録する項目：

• 対象projectとbranch

• 変更するファイル、画面、処理

• 現在の挙動と、変更後に期待する挙動

• 変更しない範囲

• dataや認証への影響

• 戻すときに使うversionまたはcommit

Code editorで読む順番

コードを開いたら、該当行だけをすぐ変更せず、呼び出し元と結果を確認します。LovableのCode editorではファイルの閲覧・検索やchatへのfile / line referenceができます。検索結果を使い、同じ関数・componentがどこで使われるか調べます。

例えば保存ボタンの動作を変えるなら、次を追います。

1. ボタンを描画するcomponentを見つける。

2. click handlerが呼ぶ関数を確認する。

3. request先、入力validation、loading状態を確認する。

4. 成功時に画面が更新される場所を確認する。

5. 失敗時のmessageと再試行方法を確認する。

6. 呼び出し元が他の画面にも使われていないか検索する。

表示だけ変えたつもりでも、共通componentを編集すると複数画面へ反映されます。複数箇所で同じ関数を使っているなら、対象を絞るか、意図した全箇所をtestへ含めます。知らない生成コードを丸ごと置換せず、既存のstate管理や命名を読んでから最小の差分にします。

Project chatへコードの文脈を渡す

AIへ修正を依頼する場合、「きれいにして」ではなく、対象ファイル・期待結果・制約を渡します。Code editorから該当fileやlineをchatに参照させると、対象を探すための説明が減ります。

依頼文の例：

対象：支出入力画面の保存ボタン

現状：金額が空でもrequestが送信される

期待：空欄と0以下は送信せず、金額欄の近くに理由を表示する

保持：成功時の一覧追加と月合計更新は変えない

先に確認：handler、API、既存validation、他画面での共用有無

変更後：正常入力、空欄、負数、保存失敗をPreviewで確認する

このように成功条件と壊してはいけない動作を分けます。依頼前に既存APIやschemaをAIが変更する権限が必要かも判断してください。原因が分からないのに大規模refactorを依頼すると、問題箇所を越えて差分が膨らみます。

まずは使ってみる

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

• 

  Lovable

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

変更後はdiffと操作結果を両方見る

Lovableが変更を終えたら、要約だけで承認せず、変更されたfilesと差分を確認します。期待していないfile、dependency、設定、database schemaが変わっていたら、publishやGit同期を止めます。保存されたコードが正しく見えても、画面の操作が通るとは限りません。

表は横にスクロールできます

QAケース	確認すること
正常入力	requestが一度だけ送られ、成功状態が出る
空欄・不正値	不正なrequestを送らず、修正箇所が分かる
通信失敗	成功表示を出さず、再試行可能か分かる
別画面	共通component変更の影響がない
画面幅	主要操作が狭い画面でも隠れない
reload後	保存状態と表示が矛盾しない

Browser test機能が使える場合も、人が期待する仕様を決める必要があります。自動testが通ったことは、セキュリティ要件やユーザー間data分離まで満たした証明とは限りません。Authや権限を触った変更は、一般利用者と管理者を分けて確認してください。

失敗したときは範囲を広げずに戻す

修正後にbuild errorが出た場合、直前の差分を小さくして原因を切り分けます。一つの変更を戻すと直るなら、その変更が原因候補です。複数の無関係な修正を重ねてから戻すと、どれが効いたか分からなくなります。

画面の崩れならCSSとcomponent、request失敗ならvalidation・network・server response、保存後に古い値が残るならcacheや再取得処理をまず見ます。原因を特定できないときは、Version historyで安定した状態へ戻し、再現手順とerrorを記録します。Git syncが有効でも、project側とrepository側の両方で戻す必要があるかを確認してください。

差分に応じて回帰テストの範囲を決める

すべての編集に同じtestを当てる必要はありませんが、変えた境界に合わせて確認範囲を広げます。ラベルだけなら、該当画面の表示と狭い幅での折り返しを見ます。共通componentなら、そのcomponentを使う代表画面をすべて開きます。API requestを変えたなら、成功・入力エラー・認証切れ・server errorを試し、画面表示だけでなく送信内容と返却後の状態を確認します。

data schemaを変える場合は既存recordとの互換性、初期データ、更新処理、rollback後の状態も対象です。認証やRLSを触る場合、未ログイン・ユーザーA・ユーザーBの組み合わせで読み書きを確認します。確認できない環境があるなら、それを「問題なし」に置き換えず、その範囲をrelease判断から外します。こうして差分とテストケースを対応させると、過剰な全面QAを避けながら、影響した場所を取りこぼしにくくなります。

AIものさしの判断

小さな文言・局所style変更は、完成状態を明示したchat依頼かCode editorで進められます。入力処理、共通component、data構造、認証、secretに触れる場合は、最初に影響範囲とテストを決め、最小差分で変更してください。手編集がread-onlyならplan表示とproject権限を確認し、権限を回避する方法を探さないでください。

最終的な完了条件は、コードが保存されたことではなく、期待する操作が通り、失敗時にも安全で、変更差分を説明できることです。Git syncを使うなら、同期branchに正しい差分が反映されたかも確認します。変更方法を選べない場合は、編集せずに対象箇所を特定し、現状の挙動と再現手順を整理するところまでを先に完了させます。