Lovableの料金とクレジット｜共有残高・上限・解約を確認

有料額より先に契約単位を確認する

現在の公式料金案内では、プランはワークスペースへ紐付き、招待したメンバーが共有するクレジットを使います。人数を増やすことと、同額の席を人数分追加することは同じ説明ではありません。ワークスペースごとの契約と残高を確認してください。有料の入口金額はこの調査では確定していないため、購入画面の期間と金額を使います。個人の試用と会社の管理対象が別ワークスペースなら、同じ残高が使えると仮定せず、どこにプロジェクトを置くかも予算の前提にします。

一つの残高を三つの用途で見る

公式資料では、開発、Cloudの稼働、公開アプリのAI機能に使える残高を説明しています。費用を用途別に集計することと、独立した三つの有料財布があることは異なります。開発が終わっても利用者のアクセスやAI操作は続く場合があるので、公開後の消費も記録してください。同じクレジットでもプランと機能によって価値や消費率が異なると案内されています。他社のトークン数や別プランの表示と数だけで比較せず、同じ作業を終えるまでの消費を使います。

• Lovableの選び方｜Web試作から公開・保守へ進む条件

開発モードと消費の関係

料金ページの例は一般的な作業の参考であり、自分の修正が必ず同じ消費になる保証ではありません。計画と実装のモード、課題の複雑さを分け、メッセージ履歴で実際の消費を確認します。仕様を決めずに同じ画面を作り直す作業は、利用量と確認時間の両方を増やします。まず入力、保存、権限と変えない条件を整理し、その後で容量を増やす必要を判断してください。残量が不足した理由を、必要な作業が多いことと不明な要件の反復へ分けると、購入の根拠が残ります。

架空の予算：制作と利用者の操作

架空の予約なしの問い合わせアプリで、月に小修正四件と利用者の送信があるとします。固定契約をF、開発の消費をB、CloudをC、アプリ内AIをAとして、金額換算は実際のプラン条件に合わせます。四件という数字は予定の例で、公式の利用保証ではありません。AI機能を使わないならAをゼロにできるかを構成から確認します。含まれる付与分を二重に差し引かず、少人数の月とアクセスが増えた月を別に作ると、開発を止めても残る運営費が見えます。

• Lovableの代替候補｜コードを引き継いで育てるアプリ開発

期限と上限は残高とは別に管理する

クレジットには発行や購入の種類に応じた期限があり、日次の付与分も同じように繰り越せるとは限りません。残量だけでなく期限と、どの用途へ使えるかを確認します。ワークスペースで複数人が使うなら、利用者、プロジェクト、全体の上限や通知を必要に応じて設定します。通知を受ける人と、その後に消費を調べる人を決めておくと、誰かが使い切ってから原因を探す運用を避けられます。長期契約は、必要な資源を期限内に使う見込みがあるかも含めて検討してください。 複数のプロジェクトがある時は、消費の大きい一つを独立して点検し、全体の残量だけで原因を決めません。

Web契約を取り消す時の違い

公式のWeb契約手順ではFreeへの変更で有料の更新を止めます。請求期間後は、未失効の月次や繰越クレジットが凍結される一方、購入した追加分等には異なる扱いがあると説明されています。全残高がそのまま使えるとも、直ちに全額消えるともまとめません。契約画面で種類と期限を確認してください。公開アプリ、コード同期、DBの運営は別に点検し、停止するか維持するかを決めます。別担当者がコードと必要な設定から修正を続けられる状態を作ってから契約を整理します。

• Boltの料金｜月払い25ドルとトークン・公開容量の予算