ホーム > ラクダデザイン
Lovableとは?使い方・料金と、公開前に確かめること|フォーム・セキュリティ・引き継ぎ

Lovableは、チャットで作りたい内容を指示し、WebサイトやWebアプリを作るサービスです。 料金は無料プランとクレジット制の有料プランがあり、以下は2026年10月の調査時点の情報です。 問い合わせフォームを付けて公開する前に、データの保存先の権限・鍵の扱い・引き継ぎ先を確かめます。
Lovableとは|lovable aiの意味と読み方
Lovableとは、文章による指示からコードを生成し、WebサイトやWebアプリの修正・公開まで支援するサービスです。
英単語のlovableは「愛らしい」という意味で、サービス名の読み方は「ラバブル」と表記します。
公式は、自然言語で開発するフルスタックAI開発プラットフォームと説明しています。
当社はLovableを自社の制作では使っておらず、本記事の機能・料金・条件は公式記載に基づきます。Lovable公式のサービス説明
Lovableでできること
Lovableでは、企業サイトや商品紹介LPから、認証やデータベースを備える業務アプリまで作成できます。
| 作れるもの | 使う技術・仕組み | 主な連携・確認事項 |
|---|---|---|
| 企業・店舗のホームページ | AIが生成する編集可能な画面のコード | GitHub同期、独自ドメインでの公開 |
| 商品・キャンペーンのLP | 商品説明、画像、購入先への導線 | 既存の販売先へ送るか、受付も作るかを決める |
| 問い合わせフォーム付きLP | データベース、サーバー側の処理 | 内蔵バックエンドまたはSupabase、メール通知 |
| 顧客ポータル・管理画面 | 認証、データ保存、利用者別の権限 | 誰が何を見られるかを設計する |
バックエンドは、画面の裏側でデータ保存や認証を担う仕組みで、内蔵型と自社Supabaseでは管理・請求先が異なります。
Supabase連携は全プランで利用できますが、両方式の切り替えは自動ではありません。問い合わせ情報を扱うなら、作り始める前に、どの契約で保管するかを決めておきます。
新規アプリは2026年5月13日からTanStack Startのサーバー側描画を採用し、Enterpriseは同年6月22日からです。古い構成とは区別して、移転先の対応環境を確認します。公式の描画方式の説明
Lovableの使い方の流れ

Lovableの使い方は、登録して目的を指示し、プレビューで修正した後に公開と独自ドメインの設定を行う流れです。
- アカウントを登録します。 無料プランから始められます。
- 作りたい内容を指示します。 対象読者、ページの目的、掲載する事実、デザインの希望を具体的に伝えます。公式入門例は、ログインやデータベースを後から追加する進め方です。
- プレビューを見ながら修正します。 チャット、Preview toolbar、コード編集を、変更内容に応じて使い分けます。
- Publishから公開します。 標準ではlovable.app形式のURLが発行され、HTTPSも含まれます。公開後の編集を反映するときは、Publish changesの操作が必要です。
- 必要なら独自ドメインを接続します。 新規接続は有料プランの機能で、指定されたDNS設定と接続確認を行います。SSL証明書は自動で設定されます。
次は本記事の指示例で、掲載事実とAIが補ってよい部分を分けて伝えます。
法人向けギフトの商品紹介LPを作ってください。
目的は、既存ショップの商品ページへの誘導です。
価格、実績、口コミは作らず、未提供の内容は仮置きと明示してください。
本文とボタンを日本語にし、スマートフォンで読みやすくしてください。
今回はログイン、決済、データベースを追加しないでください。
チャット・見た目の編集・コードの使い分け
| 公式の機能名 | 主な用途 | 利用時の注意 |
|---|---|---|
| Chat | コードを変えず、疑問や変更案を相談する | 日次無料枠と現行のチャット料金を確認 |
| Plan | 実装前に調査し、計画を確認する | 基本は1メッセージ1クレジット、追加調査は加算の場合あり |
| Build | 画面やフォームなどを実装・修正する | 作業の複雑さに応じて消費量が変わる |
| Preview toolbar | 要素を選択し、変更箇所を示す | 要素選択・図示による依頼は通常のBuild利用 |
| Edit text inline | 誤字や見出しを画面上で直接直す | 無料枠を超えると通常のBuild利用 |
| コード編集 | 開発担当者がコードを直接直す | Lovable内の編集は有料、手動編集・保存自体は消費なし |
旧Visual Editsは、現在のPreview toolbarに置き換わっています。直接文字修正はアカウント全体で100回の無料枠があり、使った枠は24時間後に復活します。
別途、ワークスペース全体にも24時間あたり2,000回の共有上限が設定されています。いずれかに達するとクレジットを消費します。公式のプレビュー編集条件
Lovableの料金

Lovableの料金は、契約プランに加え、制作・修正と公開後のCloud・AI利用によるクレジット消費で考えます。
以下は2026年10月27日の調査時点の米ドル表示で、有料は最小構成の料金です。金額や条件は、契約時に最新の公式料金で確認してください。
| プラン | 月払いの月額 | 年払い | 月間契約クレジット | 主な違い |
|---|---|---|---|---|
| Free | $0 | ― | 有料契約分なし | 試作、Git同期など |
| Pro | $25から | $250/年から、公式月額換算$21 | 100から | 独自ドメイン、バッジ削除、コード編集 |
| Business | $50から | $500/年から、公式月額換算$42 | 100から | Proに加えSSO、権限・セキュリティ管理 |
| Enterprise | 個別見積もり | 個別契約 | 利用規模・契約による | 大規模組織向けの管理・契約機能 |
年払いの月額換算は公式の丸め表示であり、月払い契約の請求額としては扱いません。基本は人数課金ではなく、ワークスペースの参加者でクレジットを共有する仕組みです。公式料金ページ
無料クレジットと有料プランの付与枠
| 用途 | Freeの付与枠 | 確認すべき条件 |
|---|---|---|
| 制作 | 毎日5、月間上限30クレジット | 毎日5を月の日数分使えるという意味ではない |
| Cloud | 月間20クレジット | ホスティングや内蔵バックエンド向け |
| 公開アプリ内のAI | 月間4クレジット | サイト利用者が使うAI機能向け |
用途別の無料枠を先に使い、不足した分を利用可能な共通クレジットから消費します。CloudやAIの無料枠を、ページを作るための制作枠へ自由に振り替える仕組みではありません。
有料プランの無料枠は、公式ページ間で記載の詳しさや対象条件に差があります。公開ヘルプはPro・Businessに毎日5の制作、月間20のCloud、月間4のAI枠を案内しています。
一方、料金ページは有料の制作枠に一部地域の月間上限を注記し、AIの4はFreeについて明記しています。一方だけで適用条件を断定せず、契約する地域・プランの付与枠を確認してください。
クレジットの減り方と有効期限
Buildの消費量は作業内容で変わるため、100クレジットを修正100回と読み替えることはできません。Planも追加調査で加算される場合があり、計画の承認後に行うBuildは別途消費します。
エラー・セキュリティ修正の無料枠はアカウント全体で10回で、使った枠は24時間後に復活します。超過後は消費対象なので、修正費も予算に含めます。
| クレジットの種類 | 有効期限 |
|---|---|
| 日次の制作無料枠 | 当日中、繰り越しなし |
| 月払い契約の月間分 | 発行から2か月 |
| 年払い契約の月間分 | 年間契約期間の終了後1か月 |
| 追加購入分 | 購入から12か月 |
現在のチャット料金体系と日次無料枠は、2026年10月31日までの暫定提供とされています。期限後の条件は、利用時に再確認してください。
制作と稼働の残高は2026年6月に共通化され、公開後の費用も管理対象です。消費は返信のメニューやPlans & credit usageで確認し、外部サービスとドメイン費用は別に見積もります。公式のクレジット説明
問い合わせフォームを付けるときに確かめること

問い合わせフォームは、保存先と通知先を決め、閲覧権限・秘密の鍵・実際の送信結果まで確認して公開します。
経営者やWeb担当者は、コードの細部より、次の3つの証拠がそろっているかで公開や発注を判断すると迷いません。
| 確かめること | 出してもらう証拠 |
|---|---|
| 届く | フォームから実際に送った記録、保存された内容、通知メール、失敗したときの確認方法 |
| 守れる | 誰がどのデータを見られるかの説明、権限のない人が見られないことを試した結果、セキュリティチェックの結果 |
| 引き継げる | 自社で管理できる契約とアカウント、コード、設定の一覧、運用の手順 |
次の節の専門用語(RLS・鍵など)は「守れる」の中身です。細部は制作会社や開発者に確かめます。
データベースのテーブルとメール通知の送信先
受付記録を保存することと、担当者へメールを送ることは、別々の処理として設計します。通知に失敗しても受付を見失わないよう、両方の結果を確認します。
| 決める項目 | 具体的に確認すること |
|---|---|
| 入力項目 | 会社名、氏名、メールアドレスなど、対応に必要な情報と必須・任意 |
| 保存先 | 内蔵バックエンドか自社Supabaseか、どのテーブルに保存するか |
| 記録内容 | 受付ID、受付日時、問い合わせ内容、対応状況など |
| 通知先 | 担当者の共有メール、不在時の確認者、通知失敗の調べ方 |
| 保管方針 | 利用目的、閲覧者、削除の判断基準と担当者 |
自社Supabaseの組織連携は、LovableのワークスペースのOwnerまたはAdminが行います。接続後のテーブル変更はSQLの変更履歴を確認・承認し、保存結果はTable Editorでも確かめられます。
通知はResend接続、Supabase Edge Functionsからの送信、Lovable Emailsなどを選べます。
| 通知方法 | 料金・設定の確認点 |
|---|---|
| Resend | 自社の契約・送信利用料を確認。送信だけならSending access権限のキーで接続 |
| Supabase Edge Functions+Resend | サーバー側にキーを保管。公式サンプルは認証済み呼び出しが前提 |
| Lovable Emails | 有料プランが必要。月50,000通を含み、超過は1,000通あたり4クレジット、ワークスペース合算 |
Resendのテスト送信元onboarding@resend.devは、アカウント所有者へのテストに限られます。実運用では送信ドメインを認証し、認証済み呼び出し用のサンプルを公開フォームへそのまま流用しません。Lovable公式のResend接続
公開前に確かめるセキュリティの設定
公開前には、行単位の権限設定・鍵の置き場所・公式のチェック機能の3つを確かめ、公開後に実際に送って届くかを見ます。
行単位の権限設定であるRLS
RLSは、データベースの行ごとに、誰が閲覧・追加・更新・削除できるかを制限する仕組みです。問い合わせを受け付ける許可と、保存された個人情報を閲覧する許可は、分けて設定します。
サーバー経由の受付では入力と権限を検証し、テーブルへの直接操作を許可しない設計が考えられます。ブラウザーから直接追加する設計でも、必要な追加だけを許可し、閲覧・更新・削除は制限します。
管理画面へのリンクを隠すだけでは、データのアクセス制限にはなりません。制作担当には、未ログイン者や一般利用者の閲覧などが拒否されるテスト結果を確認します。
RLSだけで大量送信対策が完成するわけではなく、サーバー側の入力検証や不正送信対策も必要です。操作権限とRLSを合わせて見直してください。Supabase公式のRLS説明
公開して使う鍵と隠す鍵
| 鍵の種類 | 扱い | 確認すること |
|---|---|---|
| Supabaseのpublishable key/旧anon key | ブラウザーで使うことを想定 | 公開利用を前提に、操作権限とRLSで保護する |
| Supabaseのsecret key/旧service_role key | サーバー側だけで使う | RLSを迂回するため、ブラウザーやソース管理に置かない |
| Resend APIキー | 秘密情報として保管 | 公開コードに含めず、秘密情報の設定機能へ登録する |
秘密の鍵は用途と登録先を記録し、漏えいした場合は削除・更新する運用まで決めておきます。Supabase公式のAPIキー説明
公式のセキュリティチェック機能
| 機能 | 主な確認対象 | 実行時期 |
|---|---|---|
| Quick scan | データベースのアクセス設定、依存パッケージの既知の脆弱性など | 公開時に自動実行 |
| Deep scan | アプリ固有の権限、受付処理、入力処理、秘密情報の露出など | Security viewなどから実行 |
Deep scanは通常作業中に自動実行されないため、公開前に実行・確認します。公式も完全な安全を保証していないため、スキャン結果と権限テストを合わせて判断します。Lovable公式のセキュリティ説明
公開後は「送れる・届く・完了表示」を実際に確認
- 送れることを確認します。 公開ページからテスト送信し、実際の保存先に内容が記録されたかを確かめます。必須項目の不足や保存失敗時に、受付完了を表示しない動作も確認します。
- 届くことを確認します。 本番の通知先へ届いたメールと保存記録を照合し、迷惑メール扱いも調べます。保存済みで通知だけ失敗した場合に、担当者が発見・再確認できる方法を用意します。
- 完了表示を確認します。 受付成功時の案内が実際に表示され、訪問者が次の行動を判断できるかを確かめます。
当社の別方式の制作では、新しいページの迷惑メール対策設定が合わず、送信がすべて迷惑扱いになりました。Lovableでの体験ではありませんが、本番確認が必要な理由です。
個人情報をフォームで直接取得するときは、原則として、本人への利用目的の明示が必要です。フォーム付近の案内、管理担当、保管と削除の方針を決め、入力項目を必要な範囲に絞ります。個人情報保護委員会の説明
コードの持ち出しと引き継ぎ

LovableはGitHubへのコード同期や共同編集に対応しますが、契約・データ・秘密情報の引き継ぎは別途必要です。
GitHubへの同期とワークスペースの共有
GitHub連携は全プランで使え、Lovableと対象ブランチのコード変更を双方向に同期できます。連携時には標準で非公開の新しいリポジトリが作られ、コードと変更履歴の保管先になります。
コード一式のZIPダウンロードは有料機能であり、無料で使えるGit同期とは条件が異なります。また、コードを取得しても、問い合わせデータ、保存ファイル、認証設定や鍵まで一緒には移りません。
| 共有・移管方法 | 確認する条件 |
|---|---|
| Shareからプロジェクトへ招待 | 特定のLPだけを共有し、メールアドレスと役割を指定 |
| ワークスペースへ招待 | 複数案件を扱える一方、他案件へのアクセス範囲を確認 |
| プロジェクトの役割設定 | Editorは全プランの標準役割、Admin・Viewerは有料 |
| GitHubリポジトリの所有者変更 | 移管先のGitHub接続がLovable側にもあれば同期を継続 |
| 別ワークスペースへの移動 | GitHub接続が切れ、再接続すると新しいリポジトリを作成 |
| GitHubの切断・再接続 | 元へ戻るのではなく、新しいリポジトリを作成 |
共同編集では所有元ワークスペースのクレジットを使うため、外注前に費用負担を決めます。編集プロジェクトへのアクセスと公開サイトの閲覧設定は独立しており、別々に確認します。公式の共同作業説明
制作会社に渡すときに決めること
| 対象 | 納品・引き継ぎ時に決めること |
|---|---|
| 所有者と課金 | 自社の管理者、課金担当、外注先の役割と契約終了時の解除 |
| コード | GitHubの管理組織、同期対象、変更の確認方法 |
| データ | 保存先、テーブル、RLS、バックアップと復元担当 |
| メール | 契約者、送信ドメイン、通知先、失敗ログの確認方法 |
| 秘密情報 | 登録先、用途、更新担当。値を平文の手順書に載せない |
| ドメイン・DNS | 契約者、更新担当、DNS変更を行う担当者 |
| 公開と保守 | 更新手順、以前の状態へ戻す方法、障害時の連絡先 |
| 問い合わせ業務 | 主担当、不在時の担当、通知失敗時の受付確認 |
GitHub側の移管後も元所有者は共同作業者として残るため、終了時には権限を点検します。Lovable公式のGitHub連携
会社のサイトで使うか決めるときの見方
会社のサイトで使うかは、作りたい画面に加え、社内で更新・受付・権限管理を続けられるかで判断します。
次は、自社の体制に照らした編集部の判断軸です。
| 向いている場面 | 向いていない場面 | 確かめること |
|---|---|---|
| 商品紹介LPを試作し、社内で画面を確認したい | 生成内容を確認する担当を置けない | 価格、販売条件、画像の権利を誰が確認するか |
| 文章で修正を依頼し、自社で更新したい | 公開後の更新費や稼働費を管理できない | 共有クレジットと外部契約の管理担当 |
| フォームや簡単な業務アプリを検討したい | 個人情報の保存先・権限を把握せず公開したい | 保存、通知、RLS、鍵の確認結果 |
| コードを残し、制作会社とも分担したい | コードの取得だけで移転が完了すると考えている | データ移行と接続サービスの再設定 |
当社の場合は、Claude CodeやCodexなどのコーディングエージェントにHTMLとCSSを書かせています。文章・部品データと組み立てるプログラムを「生成元」、公開するHTMLを「生成物」に分けています。修正は生成元へ戻し、再生成で修正が消えないようにして、旧版も復元できる形で保存します。Lovableの優劣を示す比較ではなく、生成元・公開環境・更新責任をどこで管理するかという違いです。
よくある質問(FAQ)
Lovableの無料枠・日本語・権利・他サービスとの比較は、対象機能と公式記載の範囲を分けて確認します。
Lovableは無料でどこまで使えますか
Freeは制作が毎日5クレジット、月間上限30で、Cloudは月間20、アプリ内AIは月間4です。GitHub同期も利用できますが、独自ドメインの新規接続やLovable内のコード編集は有料です。
Lovableに日本語で指示できますか
公式入門ガイドは任意の言語での指示を案内しており、日本語も含むと読める説明になっています。公式FAQは日本語UIへの対応を明記していますが、未翻訳部分もあり、生成後の原稿や表示は確認が必要です。Lovable公式FAQ
Lovableで作ったものの権利は誰にありますか
公式は利用者がアプリ・コード・コンテンツを所有し、商用利用や別環境での公開もできると説明しています。ただし、第三者の権利やライセンスに従う必要があり、生成物の独自性や非侵害は保証されません。
一般利用規約は最終更新2026年8月28日、発効2026年8月15日で、生成結果の検証責任も定めます。公式利用規約
非公開設定と学習利用は別項目で、Free・Proは拒否設定、Business・Enterpriseは標準除外です。公式プラン比較
Lovableとv0との違いは何ですか
今回参照した公式資料にはv0との機能比較がなく、両者の優劣は公開情報では確認できません。比較する際は、データ保存、公開先、コードの持ち出し、保守担当を同じ条件で確かめてください。
lovable.devとlovable.appは何が違いますか
lovable.appは、作ったサイトを公開するときの標準の公開先として使われます。規約上、特定のlovable.appサブドメインを永久に利用できる権利は与えられていません。
店舗の「次の一手」を一緒に進めるなら
AI社員アプリ・運営代行・ECコンサルまで、現場を知るチームがワンストップで伴走します。
西尾 勝太株式会社ラクダ 代表
楽天SOY 2年連続受賞 / 楽天NATIONSリーダー店舗 / 楽天NATIONS AIエバンジェリスト
楽天市場の月商を5年で200万円→2億円に伸ばした現場の実践者。売れるECの方程式にAIを重ね、EC事業者の「次の一手」に伴走しています。
西尾勝太のブログを読む




