FramerとLovableを比較｜Webサイト制作とアプリ開発の違い

FramerとLovableはどちらもWeb上の画面を作れます。選ぶ分岐は「サイトかアプリか」という名前ではなく、公開ページを見せるだけで足りるか、利用者ごとのデータ・ログイン・権限・処理状態まで管理するかです。前者はFramerを起点にしやすく、後者はLovableでWebアプリを組み立てる候補になります。Framerでもcustom codeや外部連携は使え、LovableでもWebサイトを作れるため、製品名だけで用途を固定しないでください。

最初に「訪問者が何をした後、何が残るか」を書く

作りたいものがLP、会員画面、予約フォームなどのどれかだけでは判断できません。利用者が操作した後に何が保存され、次回訪問で誰がそれを見られるのかを考えます。ページ数や色を決めるより、最初の利用者の行動を一つ書き出す方が、必要な仕組みを見分けやすくなります。

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

利用者の行動	操作の後に必要な状態	先に検討するもの
サービス内容を読み、相談ボタンを押す	問い合わせを担当者が受け取る	Site、form送信、通知、返信運用
メールアドレスで登録し、次回ログインする	ユーザー別の登録情報が残る	認証、DB、権限、アカウント復旧
申請し、担当者の承認後に状態が変わる	操作履歴と状態遷移が残る	role、backend処理、承認、監査
記事や事例を追加して公開する	編集者が同じ型で更新する	CMS、公開権限、preview、移行

「相談フォーム」でも、送信内容をメールで受け取るだけならSite側のformで十分な場合があります。一方、利用者が後からログインし、過去の問い合わせや進捗を見るなら、アプリ側の状態管理が必要です。画面が一つでも後者に当たることがあります。

Site制作とApp制作の違いは必要な状態で見る

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

要件	Framerを起点に確認	Lovableを起点に確認
会社案内、LP、portfolio	Canvasでlayout、responsive、見せ方を組む	Website Builderでページを生成し、表示と運用を確かめる
CMSで記事・事例を更新	CMS collection、item数、編集担当を契約と照合	データをどこに保存し、誰が公開更新するかを決める
ユーザーごとのログイン後画面	外部サービスやcustom codeで足りるかを検証。認証・権限が主機能なら追加設計が必要	Cloudまたは接続するbackendの認証・DBを含むflowを設計
個別データの保存・検索	どこで保存し、誰が権限を管理するか別途設計	schema、アクセス制御、server-side処理、backupを確認
承認・決済・状態遷移	integrationや外部backendを含めて設計	actionの認可、失敗時の状態、paymentや通知の処理をテスト
公開後の編集とpreview	CMS、custom code、branching / stagingなど現行planを確認	promptでの変更とcode / data変更をreviewし、公開前にtest

Framerの公式PricingとHelpは、CMS、custom code、staging、branching等の機能をプラン別に案内しています。これはFramerに動きや連携がないという意味ではありません。小さな動きや第三者scriptで足りるのか、ユーザーごとの認証やデータ制御がサイトの中心機能なのかを分けてください。

Lovableは、公式案内でWebsitesとAppsの両方を扱い、Lovable Cloudではdatabase、user authentication、file storage、serverless functionsを提供すると説明しています。これらを使うとサイトの画面だけでは完了しないデータ処理へ進めます。ただしAIが機能を生成しただけで、データ設計、権限、障害対応、運用責任が自動的に決まるわけではありません。

Framerを選ぶ場合は編集・公開の運用まで確かめる

ブランドサイト、LP、portfolioなど、訪問者へ同じ内容を見せ、主に情報や事例を更新するならFramerのSite workflowから確認します。最初に必要ページとCMS項目を決め、編集者が文章・画像を差し替えたときに表示が崩れないか試します。CMSを使うなら、記事の公開状態、一覧と詳細の表示、画像alt、URL、更新担当をテストします。

契約前には必要なページ数、CMS collectionsとitems、bandwidth、独自domain、チームeditor、staging、redirectを、現在のPricing画面で照合します。機能の有無だけでなく、無料試用から本番公開へ移る条件、使用中のplanで追加できる量、超過時の扱いを記録します。価格や上限は改定されるため、古い記事中の固定額を見積りとして使わず、購入するworkspace/siteのcheckout条件を確認してください。

公開前previewでは、デスクトップとスマートフォンのbreakpoint、リンク、フォーム送信先、ページtitleとdescription、実サイトでのみ動くcustom codeを確認します。Framer公式の案内では、Settingsへ入れたcustom codeがPreviewに現れず、公開後に確認が必要な場合があります。Previewで見た目がよかっただけで、analytics、外部script、フォームまで動作確認済みとは扱わないでください。

Lovableを選ぶ場合は画面より先にData Contractを作る

ログイン、利用者ごとの記録、検索、権限、承認などが必要なら、最初に「誰がどのデータを作り、誰が読み、誰が変更できるか」を表にします。Lovableへ依頼する前に、実データではなく架空のsample userとsample recordを用意し、最小の一連の利用を定義します。

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

Data / action	作成できる人	閲覧できる人	更新・削除条件	失敗時に残す状態
利用者プロフィール	本人、必要なら管理者	本人、明示した担当者	本人の変更可能項目を限定	認証失敗と保存失敗を分ける
問い合わせ・申請	ログイン利用者または公開form	本人と担当者	承認後の変更権限を制限	二重送信を防ぎ再試行方法を示す
運営者メモ	認可された運営者	運営者のみ	roleと操作履歴を確認	権限エラー時にデータを返さない

Lovable Cloudを使うか、自分のbackendを接続するかは、data location、既存account、運用担当、export・移行、契約上の条件で決めます。実装では、schema、認証方式、user間の境界、server側に置くsecret、ログ、削除・backup方法をreviewします。API keyやsecretをbrowser codeへ置かず、未ログイン利用者や別ユーザーから他人のrecordを読めないかをテストします。

Lovableはpublish時のbasic security scanを案内していますが、scanは人による脅威分析や権限テストの代わりではありません。実際に扱うdataの機密度に応じて、認可条件、row-level access、serverless function、公開範囲、backup、incident時の連絡先を別途確認してください。testで見つけた問題を直す前に、production dataを入れないようにします。

ひとつのUser Flowを両方で試す

比較を公平にするには、同じ架空の事業やプロダクトBriefを使い、完成速度を競うのではなく必要条件が満たせるかを記録します。たとえば「小規模事業のサイトに問い合わせフォームを置く」だけなら、フォームが誰へ届けば完了かを定義します。「会員が自分の申請履歴を見て、運営者の承認状態を確認する」なら、user別dataとrole権限が必要です。

1. 利用者と完了条件：誰が何を終えれば成功かを一文で書く。

2. 画面とdata：必要画面、入力、保存する項目、公開可能なsampleを決める。

3. 権限：未ログイン、本人、別ユーザー、運営者の4種類で見える情報を表にする。

4. 失敗経路：入力不備、通信失敗、重複送信、権限なしの表示と再試行を決める。

5. 試作と確認：架空データで作り、mobile表示、form、ログイン、保存、再表示を一つずつテストする。

6. 運用：公開者、更新者、data削除、障害時に止める担当を決める。

記録するのは「見栄えがよい」「AIができたと言った」だけではありません。必須要件の未達、追加サービス、手作業の残り、データを見られる範囲、code reviewの担当を残します。実際に両サービスを同じ条件で試していない場合は、公式仕様と要件からの選定であり、性能比較の実測ではないと区別してください。

公開前の受け入れテスト

SiteでもAppでも、初回出力をそのまま公開しないでください。下の項目をテストし、「誰が合格を確認したか」を残します。

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

テスト	Site中心	App中心
主要画面	Home、サービス、問い合わせ、FAQ	登録、ログイン、主要action、結果画面
Mobile	横幅、長い文字、画像、CTA、navigation	上記に加え、keyboard、error、loading
Form / action	実際の受信先、成功・失敗表示	認証、DBへの保存、重複・再試行
権限	編集者だけが公開できるか	未ログイン、本人、他ユーザー、管理者で比較
Data	CMS入力・公開・修正の引継ぎ	読み書き、削除、backup、secretの配置
公開	domain、redirect、metadata、custom code	environment、test/live key、権限、monitoring

Appで「ログイン画面が出る」ことだけでは、認証済みの人が他ユーザーの情報へアクセスできない証拠になりません。各roleで実際にアクセスを試し、許可されない操作がserver側でも拒否されることを確認します。決済や個人情報を使う場合は、テスト環境と本番環境を分け、法務・プライバシー要件を担当者が確認するまで実データへ移行しません。

判断できない場合は「最小の未確認要件」を選ぶ

サイトとアプリの境界で迷ったら、必要機能を全部実装しようとせず、不確実な要件を一つ選びます。CMS更新、ログイン、user別保存、承認、決済、外部連携のどれが決定を変えるかを特定し、テスト用dataで小さな試作品を作ります。成立条件が確認できないなら、導入や公開を保留します。

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

未確定事項	小さな確認	候補を進める条件
ログインが必要か	user別に保存する画面と共有ページを区別する	個別dataを安全に扱える設計がある
Framerで足りるか	そのcustom codeや外部serviceを誰が保守するか決める	必要なdataと権限を責任者が説明できる
Lovable Appの公開可否	権限、保存、失敗経路をsample dataで確認する	別ユーザーからのアクセス拒否まで確認済み
CMS運用	編集者が記事を追加し、previewから公開する	更新担当と承認担当が明確
将来移行	code、data、domain、契約の持ち出し条件を確認	移行できる範囲と費用を記録済み

AIものさしの判断

会社案内、LP、portfolio、記事や事例を更新するsiteが主目的なら、Framerのページ・CMS・公開運用から検討します。ログイン、user別data、role、backend処理が読者向け機能の中心なら、Lovableを含むApp builderを候補にし、databaseと認可を実装・検証する責任を見積もります。

Framerにcustom codeやintegrationがあること、Lovableでwebsiteを作れることだけで勝者は決まりません。作りたい画面を描く前に、利用者の操作、保存data、権限、失敗時の扱いを一枚に書きます。その要件を満たす候補だけを、同じUser Flowと受け入れ条件で比べてください。dataの保護や公開責任が未確定なら、契約や本番公開は保留します。