記事一覧

Lovableとは?AIでWebアプリを作る機能・料金・使い方を解説

Lovableの会話によるWebアプリ制作、プレビュー、公開、クレジットの仕組みを整理。小さな試作品から確認する使い方を紹介します。

Lovable公式トップページ。「Build something Lovable」の見出しと入力欄がある
情報確認日:2026年11月5日。公式ページ本文を確認した原稿です。アプリ作成、外部サービス接続、契約、公開は実行していません。料金は米ドルです。

リード

作りたいWebサービスの案はあるけれど、最初の画面を用意するところで止まってしまう。Lovableは、自然な言葉で希望を伝え、WebサイトやWebアプリを作っていくサービスです。生成した画面をプレビューし、会話で直し、公開へ進める流れを公式が案内しています。Lovable公式

ただし、画面が表示されたことだけでは、利用者が迷わず使えるか、必要な処理が動くかは分かりません。この記事では、架空の商品一覧を例に、小さな試作品を作って確認する考え方を紹介します。機能の多さより、まず一つの目的を達成できるかに注目しましょう。

Lovableとは

Lovableは、作りたいものの説明から画面や機能を組み立て、チャットとプレビューを行き来しながら調整する制作サービスです。公式の入門ガイドでは、空の状態から始める方法と、テンプレートをRemixして独立したコピーから始める方法を紹介しています。入門ガイド

編集部としては、最初の題材を「誰が、何を見て、どんな操作をするか」で説明することを勧めます。たとえば備品一覧なら、名前を探す人、カテゴリーで絞る人、詳細を読む人という使い方が考えられます。

ここで紹介する例は、架空の名前と説明を画面に出す試作品です。在庫管理や予約受付まで実装したことを示すものではありません。画面上の状態が変わることと、情報が保存されて他の人にも共有されることは、別の確認項目として扱います。

完成形を一度に伝えようとすると、必要な機能と後から足せる機能が混ざります。最初に最低限の操作を決め、動きを見てから範囲を広げるほうが、修正の理由も説明しやすくなります。

できること(主な機能)

会話から試作品を組み立てる

公式ガイドは、自然な言葉でページや動きを説明し、生成されたものを確認する進め方を案内しています。初回の生成後に一つずつ変更を頼む方法や、過去のバージョンへ戻す操作も説明されています。制作の始め方

編集部の指示例は「架空の貸出備品を一覧で見られるページ。名前、カテゴリー、説明を表示し、名前で検索できるようにする」です。最初はサンプルの内容を使い、実際の個人情報や顧客情報を必要としない形で考えます。

色や角丸だけでなく、検索したときに何が起こるかまで言葉にすると、確認する対象がはっきりします。「検索結果がない場合は、そのことが分かる文章を出す」といった条件も、使い勝手の検討に役立ちます。

計画の相談と実装を分ける

Lovableには、コードを変更せずに相談するPlan modeがあります。クレジットの説明では、Plan modeはメッセージの基本消費に加え、調査用のサブエージェントの処理が追加消費になり得るとされています。クレジットと利用量

編集部としては、機能の追加前に「今の仕組みで対応できるか」「どの画面に影響するか」を整理する用途を勧めます。相談した内容を読み、必要な範囲を確認してから変更へ進むと、後で直す理由を追いやすくなります。

計画が表示されたからといって、機能が完成したとは扱いません。案として説明されたこと、画面へ反映されたこと、実際の操作で確認したことを分けて記録すると、共同作業でも状態を共有しやすくなります。

プレビューで画面と動きを確かめる

プレビューは最新の作業内容を表示し、デスクトップ、タブレット、モバイルの表示を切り替えられます。公開済みのサイトは公開時点の内容で、編集後の内容は再公開するまで自動で同じにはなりません。プレビュー

ここで注意したいのは、プレビューと公開サイトが同じバックエンドやデータを使うという公式の説明です。画面の公開タイミングが分かれていても、データ側の変更まで必ず隔離されるわけではありません。

編集部が勧める確認は、表示と操作を分けることです。文字が読めるか、ボタンが押せるかに加え、検索を解除したら元に戻るか、詳細を閉じて続けて探せるかなど、一連の行動を試します。

公開とコードの扱いを選ぶ

公式のプラン比較にはGitHubなどとの同期があり、有料プランではコードの編集・ダウンロード、独自ドメイン、Lovableバッジの削除などが案内されています。プラン比較

コードを取り出せることは、その後の運用や修正が不要になることを意味しません。編集部としては、誰が保守するか、困ったときにどこを調べるか、どのサービスへ依存するかも合わせて考えることを勧めます。

実際に公開する前には、公開範囲、表示内容、接続先を確認します。作成中の試作品を見せることと、一般の利用者に使ってもらうことでは、必要な確認の深さが変わります。

料金プラン

公式のプラン文書では、Free、Pro、Business、Enterpriseが案内されています。下表は月払いの入口となる構成です。有料プランには、月間クレジットを増やす選択肢もあります。公式プラン文書

プラン

月払いの料金

確認した主な枠・機能

Free

0ドル

日次5クレジット、月合計30まで

Pro

月25ドルから

月間100クレジットから、独自ドメインなど

Business

月50ドルから

月間100クレジットから、組織の管理機能など

Enterprise

個別条件

組織向けの追加管理・契約条件

年払いは100クレジット構成でProが年250ドル、Businessが年500ドルと記載されています。年払いでも月間クレジットは月ごとに付与されるため、年間分を最初からまとめて使えるとは考えないようにします。

クレジットは、制作のための処理だけでなく、Cloudやアプリ内AIなどの稼働にも関係します。公式は用途別の付与分を先に使い、必要に応じて共通の残高を消費する仕組みを説明しています。利用量の説明

CloudやAIの月間付与には、一時的で変更され得る枠もあります。無料の付与分だけを前提に長期の運用費を決めず、制作中の消費と、利用者が使う際の消費を確認してください。

編集部としては、一回のメッセージ数だけで費用を見積もらないことを勧めます。処理の内容によって消費が変わるため、小さな変更を数回行ったときの実際の使用量を記録すると比較しやすくなります。

また、料金ページには地域やプランによる日次枠の例外もあります。契約時は公式ページと自分の利用画面の条件を照合し、更新日、付与日、有効期限を確認しましょう。公式料金

Lovable料金ページ。Free、Pro、Business、Enterpriseのプランが並んでいる
Lovable料金ページ(https://lovable.dev/pricing)(出典: lovable.dev、撮影日 2026-11-05(木))

使い方の手順:小さな一覧アプリを考える

以下は公式ガイドをもとにした進め方と、編集部の確認例です。この記事のためにアプリを作成・公開した実測結果ではありません。

1. 利用者と最初の操作を決める

まず「備品を探す人が、名前や種類から候補を見つけられる」と目的を書きます。一覧、検索、詳細の三つに絞れば、何を確認すればよいかを説明しやすくなります。

予約、承認、通知、請求などを同時に盛り込むと、どの機能で問題が起きているか切り分けにくくなります。最初の目的を達成するために不可欠なものだけを選びましょう。

2. サンプルの内容と画面を伝える

公式ガイドに沿って、必要な画面と動きを文章で説明します。編集部の例では、架空の備品名と短い説明を数件用意し、写真がなくても内容を区別できる一覧を考えます。

一件だけでは、長い名前、説明のない項目、同じカテゴリーの複数項目などを確認できません。表示が崩れそうな内容も少し混ぜ、最初から複数の状況を見られるようにします。

3. 生成された画面を操作する

プレビューで表示を確認し、検索に一致する文字、一致しない文字、空の入力を順に試します。見た目が整っていても、操作の結果が利用者に伝わらなければ改善の余地があります。

モバイル表示では、一覧の順番、ボタンの位置、詳細の読みやすさも確認します。横に並んでいた情報が縦に積まれたときに、名前と説明の対応が分かるかを見ましょう。

4. 変更を一つずつ依頼する

修正するときは「もっと使いやすく」だけで終わらず、どの場面で困るかを書きます。たとえば「結果がないと一覧が消えるだけなので、条件を変える案内を表示する」という伝え方です。

変更後は、その箇所と周辺の操作をもう一度確認します。検索欄を直した結果、一覧へ戻れなくなっていないかなど、関連する行動まで見ます。気になる点をまとめて残しておくと、同じ修正を繰り返しにくくなります。

5. 公開の準備と公開後の確認を分ける

公式ガイドでは、PublishからURLや公開範囲を確認し、公開を実行する流れが説明されています。以後の変更も、公開操作を通じて配信内容へ反映します。公開の手順

実際に公開する際は、タイトルや説明文、不要なサンプル表示、リンク先を先に確認します。公開後は配信されたURLを開き、編集画面のプレビューと同じつもりで判断せず、利用者の入口から操作を確かめましょう。

確認結果は「できた」「できない」だけでなく、入力した内容と期待した結果を残すと役立ちます。たとえば「備品名の一部で検索し、該当する二件だけが表示される」と書けば、次の修正後にも同じ条件で見直せます。

関係者に見てもらう場合も、自由に感想を求めるだけでなく、一つの作業を頼む方法があります。「この用途に合う備品を一つ選ぶ」といった課題なら、どこで迷ったかを具体的に聞けます。これはLovableの機能ではなく、編集部が勧める試作品の評価方法です。作る側が説明を補わなくても目的にたどり着けるかを見ると、次の修正を決めやすくなります。

向いている人・向かない人

向いている人

編集部の見立てでは、企画を画面にして、関係者と使い方を話したい人に向いています。文章だけでは想像しにくい検索や一覧の動きを、小さく確認する題材として検討できます。

また、実際の画面を見ながら要件を直せる人にも候補になります。最初の指示で完成させるより、確認と修正を繰り返す前提で考えるほうが、使い方と合っています。

向かない人

表示できた時点で、権限や保存、運用まで確認済みと扱いたい人には勧めにくいでしょう。入力や閲覧の範囲が重要なサービスでは、画面以外の確認も必要になります。

生成後の変更内容や使用量を確認する時間が取れない場合も、導入を急がないほうがよいと考えます。最初は限定した題材で、確認作業を含む制作の流れを試しましょう。

似たツールとの違い

FramerもAIを使ったサイト制作を案内しています。公式の入門レッスンは、キャンバスでの編集やCMSを含むサイト制作を説明しています。Framerの入門レッスン

編集部としては、どちらにも同じ小さな課題を与えると比較しやすいと考えます。見せる内容と更新のしやすさを重視するのか、検索などの操作を持つ試作品を重視するのかで、確認する点を変えます。

比較する点

確認したいこと

制作中の修正

意図した箇所を変更できるか

利用者の操作

一連の行動を迷わず終えられるか

更新と運用

誰が内容や機能を直すのか

費用

制作と公開後の利用を含めて把握できるか

用途だけで優劣を決めず、自分の題材で必要な操作と確認方法をそろえて判断しましょう。

注意点

AIが生成した文章や数値は、掲載してよい事実かを確認します。架空の実績、利用者の声、価格などを、そのまま実サービスの情報として使わないようにします。

プレビューと公開サイトのデータが共有される場合は、画面の修正とデータ側の変更の影響を分けて考えます。公開中のサービスを扱うときは、どの範囲に変更が及ぶかを理解したうえで進めてください。

外部サービスを追加するなら、その接続先の料金や権限も確認が必要です。Lovableの基本料金だけで、すべての外部利用費が含まれるとは判断しないようにします。

まとめ

Lovableは、言葉で説明し、生成された画面を見て、操作しながら直すWeb制作の候補です。最初は小さな一覧や検索を題材にすると、必要な機能と確認すべき動きを整理しやすくなります。

料金はクレジットの付与と消費、制作と稼働の両方を確認しましょう。試作品の見た目だけで判断せず、公開範囲や実際の操作まで確かめることが、利用目的に合うかを見極める出発点です。

出典

すべて2026年11月5日に公式本文を確認。