Lovableでクレジットの使用上限・アラートを設定可能に｜Usage limits & alertsを解説

AIでWebサイトやアプリを作成できるLovableに、クレジットの使いすぎを防ぐための新しい管理機能が追加されました。

2026年10月7日のアップデートにより、有料プランのワークスペースでは 「Usage limits & alerts」 を利用して、

• ワークスペース全体
• プロジェクト
• メンバー
• グループ
• Access Token

などにクレジットの使用上限を設定できるようになっています。

単純に「100クレジットを使ったら知らせる」といった通知だけでなく、設定した上限に到達した時点でそれ以上の利用をブロックすることも可能です。

さらに、Lovable Cloud、AI機能、従量課金型Connectorなど、本番環境で発生するクレジット消費についても制限できます。

Lovableを一人で試すだけでなく、チーム開発や本番アプリの運営に利用している場合には、かなり重要なアップデートです。

Lovableの「Usage limits & alerts」とは？

Usage limits & alertsは、Lovableのクレジット消費量を監視し、一定量に到達したときに通知したり、それ以上の利用を停止したりできる機能です。

設定場所は、

Workspace settings → Usage limits & alerts

です。

利用できるのは有料プランで、設定を作成・変更・削除できるのはWorkspace OwnerまたはAdminです。

Editorも設定内容を確認できますが、変更することはできません。

Lovableでは、基本的にワークスペース内のメンバーやプロジェクトが共通のクレジット残高を利用します。

そのためチームで利用している場合、

「一人のメンバーが大量にクレジットを使用してしまった」

「一つのプロジェクトだけで予想以上にAIを利用していた」

といったことが起こる可能性があります。

今回のアップデートでは、それぞれに上限を設定できるため、Lovableのコスト管理がしやすくなりました。

「通知だけ」と「利用停止」の2種類を選べる

Usage limits & alertsで特に重要なのが、上限に到達したときの動作を選択できる点です。

大きく分けると、

という使い分けができます。

通知方法についても、

• Email
• In-app

を選択できます。

例えば月100クレジットを目安にしたいプロジェクトであれば、

80クレジット程度で通知
↓
100クレジットで停止

といった予算管理を考えることができます。

なおLovableのBlocking Limitでは、上限の80％に達すると「Approaching」状態になります。

アラートも有効にしている場合は、この段階で早期警告を受け取ることができます。

日次・月次の上限を設定できる

クレジット上限は、

• Daily
• Monthly

の2種類から設定できます。

Dailyは毎日UTC 00:00にリセットされ、Monthlyは毎月1日のUTC 00:00にリセットされます。

Lovableの請求サイクルとは独立している点には注意が必要です。

例えば、

1プロジェクト

1日：20クレジット
1ヶ月：300クレジット

のように、同じプロジェクトへ日次と月次のルールをそれぞれ設定することもできます。

短時間に大量消費するのを防ぐDaily Limitと、月全体の予算を管理するMonthly Limitを組み合わせる使い方も可能です。

どこまで細かく上限を設定できる？

今回のアップデートでは、かなり細かい単位でクレジットを管理できます。

ワークスペース全体

最も大きな単位です。

例えば、

Workspace
月間1,000クレジットまで

という上限を設定できます。

ワークスペースのGeneral LimitをBlockにすると、設定範囲内のすべてのクレジット利用に影響します。

複数のプロジェクトやメンバーが存在する企業では、「会社全体としてLovableに使うクレジット量」を管理するために利用できます。

プロジェクトごと

個人的にかなり使いやすいと思うのが、Project単位の上限設定です。

例えば、

社内管理ツール：200 credits / month

顧客向けAIアプリ：500 credits / month

テストプロジェクト：50 credits / month

のように、プロジェクトごとに予算を分けられます。

さらに「Project Default」を設定することも可能です。

例えば、

すべてのプロジェクト
月100 credits

というデフォルトルールを設定しておき、重要なプロジェクトだけ500クレジットへ変更するといった運用もできます。

ここでの100クレジットは全プロジェクトで共有する100クレジットではなく、各プロジェクトにそれぞれ100クレジットの上限が適用される仕組みです。

メンバーごと

チームでLovableを使う場合は、メンバーごとの利用制限も設定できます。

例えば、

メンバー共通
50 credits / month

を設定して、

開発責任者
200 credits / month

のように個別の上限を設定することも可能です。

これまでPeople画面から個別の月間クレジット上限を設定することもできましたが、Usage limits & alertsではさらに、

• 日次制限
• 通知だけの設定
• プロジェクト単位
• ワークスペース単位

などもまとめて管理できます。

メンバー単位の制限では、主にアプリ制作やチャット、画像・動画生成などのBuild Creditsが対象となります。

グループごと

Business・EnterpriseプランではGroup単位でも設定できます。

例えば、

Marketing Team
50 credits / member

Development Team
200 credits / member

といった管理ができます。

注意したいのは、「マーケティングチーム全員で50クレジット」ではない点です。

グループの上限は、所属する各メンバーに個別のAllowanceとして適用されます。

部署単位でAI開発環境を提供している企業では便利でしょう。

Access Tokenごと

Business・EnterpriseではAccess Token単位の制限にも対応しています。

LovableをAPIや外部の自動化処理と組み合わせている場合、

このAccess Tokenは1日20 creditsまで

といった制御ができます。

人間がLovableを操作していないバックグラウンド処理では、誤ったループなどで使用量が増える可能性があります。

Access Token単位で上限を設定できるのは、こうした自動処理の予算管理にも役立ちます。

Build・Run・Cloud・AIなど個別に制限できる

Lovableでは現在、アプリの「制作」だけでなく、公開後のCloudやAI機能などにもクレジットが利用されます。

今回のUsage Limitsでは、対象となるクレジットの種類も選べます。

LovableではBuildとRunが別々の財布になっているわけではありません。

現在は、アプリ制作から公開後のCloud・AI機能まで基本的に一つの共通クレジット残高から消費される仕組みになっています。

そのため今回のように「どの用途でクレジットを使うか」を細かく制御できる機能は重要です。

本番アプリでは「Block」の設定に注意

ここは今回のアップデートで特に注意したいポイントです。

Build Creditsの上限であれば、上限到達後にアプリの編集ができなくなるだけです。

しかし、

• Cloud
• AI
• Connectors
• Run
• General

などにBlocking Limitを設定すると、公開中のアプリにも影響する可能性があります。

例えばCloudに「100 credits / month」の上限を設定してBlockを有効にした場合、100クレジットに達するとCloudがPauseされます。

その場合でもWebページ自体は表示されますが、

• データベース
• ログイン
• Storage
• Backend
• Realtime機能

などが動作しなくなる可能性があります。

つまり、

予算を超えたのでLovableで開発できなくなる

だけではなく、

予算を超えたので公開中のサービスのBackendが停止する

可能性があるということです。

本番サービスでは、いきなりBlockするよりもまずAlertを利用する方が安全なケースも多いでしょう。

「残高が少なくなったら通知」も設定可能

Usage Limitとは別に、Low-balance Alertも追加されています。

こちらは「いくら使ったか」ではなく、残りクレジットがどれくらいあるかを監視する機能です。

例えば、

残り50 creditsになったら通知

と設定できます。

さらに固定クレジット数だけでなく、

残高50％
残高25％
残高10％

といった割合でも設定できます。

複数のアラートを設定することも可能です。

例えば、

50% → 早めの警告

25 credits → 緊急警告

といった使い方もできます。

Low-balance Alertでは利用を停止することはなく、あくまでも通知のみです。

公開中のアプリがある場合には、非常に使いやすい機能でしょう。

メンバーが上限引き上げを申請できる

チーム利用では、上限に達したユーザーが管理者へLimit Increase Requestを送れるようになっています。

例えば開発者が月50クレジットの上限に達した場合、

現在：50 credits

希望：80 credits

理由：
リリース前のため追加作業が必要

といった形で申請できます。

Workspace OwnerまたはAdminは、

• Approve
• Deny

を選択できます。

さらに承認時には、

Indefinitely

または、

Until end of usage period

を選べます。

例えば通常は月50クレジットのメンバーに対して、

「今月だけ100クレジットまで許可する」

といった一時的な引き上げも可能です。

月末を過ぎれば通常の設定へ戻るため、企業の予算管理としてよく考えられた仕組みです。

なおGroupとAccess Tokenの上限では、この引き上げ申請機能は利用できません。

クレジットを追加してもUsage Limitは解除されない

ここも少し注意が必要です。

例えば、

Project A
月100 credits

というBlocking Limitを設定し、100クレジットを使い切ったとします。

このとき追加でクレジットを購入しても、Project AのBlockは解除されません。

Usage Limitは、

「現在何クレジット持っているか」

ではなく、

「その期間中に何クレジット使用したか」

を見ているからです。

解除するには、

• 上限を引き上げる
• Blockingを無効にする
• Limitを削除する
• Daily / Monthly期間のリセットを待つ

必要があります。

これは「残高不足」と「Usage Limit」が別の仕組みであることを理解しておくと分かりやすいでしょう。

実際にはどのように設定するとよい？

利用状況によって設定方法は変わりますが、いくつか例を考えてみます。

個人でLovableを利用する場合

一人で利用している場合は、細かいUser Limitまで設定する必要はないでしょう。

例えば、

Workspace Balance

50% → Alert
25 credits → Alert

程度でも十分です。

予想以上の消費を防ぎたい場合には、

Build
300 credits / month
→ Alert + Block

といった月間上限を追加してもよいでしょう。

チームでLovableを使う場合

5〜10人程度のチームなら、

Default Member Limit
50 credits / month

を設定して、

Lead Developer
200 credits / month

のように必要な人だけ上限を増やす方法が考えられます。

さらに、

Experimental Projects
100 credits / month

など、重要度の低いプロジェクトにも上限を設けておけば、一つのテストプロジェクトで大量にクレジットを使うのを防げます。

本番アプリを運営している場合

公開中のSaaSやWebサービスでは少し考え方を変えた方がよいでしょう。

例えば、

Cloud
100 credits
→ Alert only

AI
100 credits
→ Alert only

のように、まずは通知だけにしておく方法があります。

CloudやAIにBlockを設定すると、本番アプリの機能まで停止する可能性があるからです。

どうしても予算を超えたくないサービスであればHard Limitも有効ですが、可用性とのトレードオフになります。

制作会社・受託開発の場合

クライアントごとにプロジェクトを分けている場合にも相性が良いでしょう。

例えば、

Client A
300 credits / month

Client B
100 credits / month

Internal Demo
50 credits / month

というように、案件ごとの予算をそのままLovable上のLimitとして設定できます。

実際の使用量とクライアントごとの制作コストを把握しやすくなります。

Lovableのクレジット管理は以前より重要になっている

今回のアップデートが重要なのは、2026年にLovableのクレジット体系そのものが変化していることも関係しています。

Lovableは2026年6月にBillingを刷新し、アプリをBuildするためのクレジットと、公開後にRunするためのCloud・AIなどの利用を共通のクレジット体系へ統合しました。

さらにPlans & credit usage画面では、

• どのメンバーが使ったか
• どのプロジェクトが使ったか
• BuildかRunか
• CloudかAIか

といった使用状況を細かく確認できるようになっています。

今回追加されたUsage limits & alertsは、その次のステップと考えると分かりやすいでしょう。

以前は、

「どこでクレジットを使ったか確認する」

ことが中心でした。

今回からは、

「どこまで使ってよいか事前に制御する」

ことができるようになりました。

注意：上限は完全なハードキャップではない

Lovable公式ドキュメントでは、Usage Limitについてもう一つ注意点が説明されています。

使用量は、

クレジット消費を記録
↓
Limitを評価
↓
必要ならBlock

という順番で処理されます。

そのため、100クレジットの上限を設定したからといって、必ず100.000クレジットで完全停止するとは限りません。

タイミングによっては、設定した上限をわずかに超えてからBlockされる可能性があります。

LovableもHard Limitを「正確な切断点」というより、強力なGuardrailとして扱うよう説明しています。

厳密な予算を組む場合には、実際の最大予算より少し低い値でLimitを設定しておくのも一つの方法です。

まとめ

2026年10月7日のアップデートにより、Lovableでは新しいUsage limits & alertsが利用できるようになりました。

今回追加された主な機能は、

• ワークスペース全体のクレジット上限
• プロジェクトごとの上限
• メンバーごとの上限
• 日次・月次の上限
• Email / In-appアラート
• Low-balance Alert
• Build / Run / Cloud / AI / Connector別の制限
• Business・EnterpriseでのGroup制限
• Business・EnterpriseでのAccess Token制限
• 上限到達時の利用Block
• メンバーからの上限引き上げ申請

などです。

Lovableは、単にAIへ指示してWebサイトを作るツールから、データベース、認証、AI、Connectorなどを含めて実際のWebアプリを構築・運用するプラットフォームへ広がっています。

その分、クレジットも「開発時だけ消費するもの」ではなくなっています。

公開したアプリのCloudやAI利用でもクレジットが発生するため、今回のUsage limits & alertsは、特にチーム利用や本番サービス運営では重要な機能です。

ただし、本番アプリのCloudやAIへBlocking Limitを設定すると、上限到達時にユーザーが利用する機能まで停止する可能性があります。

そのため、

開発用のBuild Creditsには上限を設定する
↓
本番環境のRun / Cloud / AIはまずAlertで監視する
↓
必要に応じてHard Limitを設定する

といった使い分けが現実的でしょう。

Lovableを本格的なアプリ開発・運営に利用している方は、一度Workspace settings → Usage limits & alertsを確認しておくことをおすすめします。