ノーコードツールbubbleのワークロードユニットについて日本一詳細な解説！
ノーコード開発ツールBubbleは、その強力な機能と柔軟性で世界中の開発者に支持されています。しかし、アプリを本格運用していく中で必ず直面するのが「Workload Unit（WU：ワークロードユニット）」という指標です。
WUは、Bubbleの新しいパフォーマンスと課金の中心となる概念です。アプリの処理量を数値化し、直接コストに結びつきます。そのため、WUのしくみを理解し、適切に管理・最適化することは、アプリの安定運用とコスト効率を最大化するうえで不可欠です。
本記事では、BubbleのWU（ワークロードユニット）とは何かという基本から、具体的な消費目安、プラン別の料金体系、そしてWU消費を抑えるための設計・最適化原則までを徹底解説します。
この記事からわかること
BubbleのWU（ワークロードユニット）について徹底的に理解できます。
・WUの基本概念と3つの原則
・WUとCapacityの違い
・処理別・アプリ規模別のWU消費目安
・プラン別の料金体系と超過時の課金ルール
・WU消費を抑える具体的な最適化方法
▼そもそもBubbleとは何か？から詳しく知りたい方はこちら
目次
- 【まず知っておきたい】BubbleのWU（ワークロードユニット）に関する3つの原則
- BubbleのWU（ワークロードユニット）とCapacity（キャパシティ）の違い｜混同しがちな2つの指標を解説
- BubbleのWU（ワークロードユニット）消費量の目安とは？処理内容やアプリ規模別の目安を紹介
- BubbleのWU（ワークロードユニット）料金体系について｜プラン別の基本量や従量形態を全解説
- 自社BubbleアプリにおけるWU消費量の確認方法｜Settingタブやサーバーログで随時モニタリング
- BubbleのWU上限に達した場合の影響と対処法｜アプリ停止を防ぐために知っておくべきこと
- BubbleアプリのWU（ワークロードユニット）消費を最適化する方法
- BubbleのWU（ワークロードユニット）を最適化した開発・運用ならSwoooにご相談を
- BubbleのWU（ワークロードユニット）に関するよくある質問
【まず知っておきたい】BubbleのWU（ワークロードユニット）に関する3つの原則
BubbleのWU（ワークロードユニット）を効果的に管理するためには、まず基本となる3つの原則を理解することが重要です。
原則① WUは、Bubbleアプリのサーバー負荷を数値化する独自の指標
WU（Workload Unit）とは、Bubbleアプリが実行するすべてのサーバーサイド処理にかかる負荷を数値化した、Bubble独自の測定単位です。
従来の「時間ベース」や「サーバーのスペック」といったあいまいな指標ではありません。アプリが実際にどれだけの計算リソースを消費したかを示します。
ユーザーがページを読み込んだり、ボタンをクリックしてデータベースを操作したり、外部APIと連携したりする際に、Bubbleのサーバーが行う作業量を定量的に計測するしくみです。
原則② WUはサーバーサイド処理ごとに消費される従量課金型の指標
WUは、アプリ内の具体的な「サーバーサイド処理」が発生するたびに消費されます。主な消費タイミングは以下のとおりです。
- データベース操作：データ検索（Do a Search for）、データの新規作成、変更、削除
- ワークフロー実行：サーバーサイドワークフロー、スケジュールされたワークフローの実行
- 外部API連携：API Connectorを利用した外部サービスとのデータ送受信
- ページロード：ページの初期ロード、動的な要素をレンダリングするためのサーバーからのデータ取得
WUは消費量に応じてコストが発生する従量課金型の指標です。アプリの利用が増え、処理が増えるほど、消費されるWUも増加し、それにともないコストも上がります。
▼ 【Bubble】Backend Workflow完全ガイド
▼ 【Bubble】API Connectorの使い方
原則③ WUは料金プランごとに一定量が割り当てられ、超過分は従量課金される
Bubbleの有料プラン（Starter、Growth、Teamなど）には、それぞれ月間の基本割り当て量として一定のWUが含まれています。
この割り当て量を超えてWUを消費した場合、以下の2つの方法で追加コストが発生します。
- 従量課金（Flexible Overages）：自動的に追加のWUが提供され、超過した分だけ規定の単価で課金されるしくみ
- Workload Tier（追加購入）：事前にWUを追加パッケージとして購入することで、従量課金よりも低単価で大量のWUを確保できる
開発環境（Development）とライブ環境（Live）の合計が計算対象です。ただし、有料プランではDevelopment環境に毎月100,000WUが含まれています。また、エディタ操作自体は原則としてWUを消費しませんが、Dataタブでのbulk操作やimport/exportなどは例外的にWUを消費するため注意が必要です。プランごとの具体的な料金は、Bubble社のポリシーにより変更される可能性があります。最新情報はBubble公式サイトで確認してください。
▼Bubbleの料金プランについて詳しく知りたい方はこちら
BubbleのWU（ワークロードユニット）とCapacity（キャパシティ）の違い｜混同しがちな2つの指標を解説
WUとCapacityって何が違うの？昔の記事だとCapacityの話が出てくるけど…
Bubbleの料金体系が大きく変わった際、最も混乱を招いたのがWUと従来のCapacityの違いです。この2つの指標の役割を明確に区別して理解しましょう。
WUは「月間の処理総量」、Capacityは「同時処理能力」
WUとCapacityは、それぞれ異なる側面を測定する指標です。
| 指標 | 何を測定するか | 影響するもの |
|---|---|---|
| WU（ワークロードユニット） | 月間のサーバー処理総量（量） | 月額コスト、アプリの持続的な稼働 |
| Capacity（キャパシティ） | 同時処理能力（速さ） | 高トラフィック時のレスポンス速度 |
Capacityは、アプリが高トラフィックにさらされた際に、サーバーが処理を絞ることで遅延やタイムアウトを引き起こす可能性を示す指標でした。
一方、WUはアプリの利用が活発であるかどうかの「総量」を示す、より包括的な指標です。現在はWUが課金の中心となっています。
それぞれの指標が影響するBubbleアプリ動作の違い
WU（Workload）は「1ヶ月あたりにBubbleのサーバーが行う作業量（燃料）」を表す指標で、速度（レスポンス）と直接的に連動するものではありません。一方、旧Capacityは「上限を超えるとスロットリング（速度制限）がかかる」性質がありました。現在のプランではCapacityによるスロットリングを避け、月間Workloadの使用量として管理するのが基本方針です。
WUが不足/消費過多の場合
月間のWU割り当て量を超過すると、設定によってはアプリの処理が制限されます。機能がエラーを起こしたり停止したりすることも。これは「アプリの稼働停止」や「高額請求」という形で現れます。
Capacity（旧指標）が不足した場合
これは主に一時的なパフォーマンスの問題として現れていました。同時に多くのユーザーがアクセスした際に処理待ちが発生し、アプリが重くなる現象です。
現在はWUを適切に最適化し、必要な量を確保することが、アプリのパフォーマンス維持とコスト管理の両方を担います。まずはWUを優先的に管理しましょう。
BubbleのWU（ワークロードユニット）消費量の目安とは？処理内容やアプリ規模別の目安を紹介
WUの消費量は、アプリの機能や設計によって大きく変動します。ここでは、どのような処理がWUを多く消費するのか、またアプリの規模別の目安を紹介します。
Bubbleの処理別WU消費量の目安｜同じ処理結果でも過程によって消費量は大きく変わる
WU消費の度合いは、処理の「複雑性」と「データ量」に比例します。以下はBubble公式ドキュメントに記載のある消費量の目安です。
| 処理内容 | 消費WU（目安） |
|---|---|
| HTMLを読み込む | 0.15 |
| サーバーサイドでのプラグイン呼び出し | 0.2 |
| データベースでの検索 | 0.3 |
| データベースから返却されたレコードごと | 0.015 |
| データトリガーのワークフロー処理実行 | 0.05 |
| 1レコードのデータ削除 | 0.1 |
| 1レコードの作成または編集 | 0.5 |
| 外部APIの呼び出し | 0.1 |
| サーバーサイドのワークフロー処理実行 | 0.6 |
同じ10件のデータを取得する場合でも、検索方法によってWU消費量は大きく異なります。Advanced Filterは「検索後にクライアント側で絞り込む」ため、制約（Constraints）で絞れる場合に比べて”検索で取得する件数”が増えやすく、その結果として返却レコード数などが増えてWUが膨らむ原因になります。まずはConstraintsでサーバー側検索を完結させ、取得件数自体を減らすのが基本です。
この表から超概算で考えると、以下のような消費量のイメージになります。
- 簡易的なページの場合：1PVあたり0.2〜1WU
- 複雑な処理を行っているページの場合：1PVあたり30WU以上
※円換算は為替レートや適用される超過単価（標準$0.30/1K WU、Tier契約時は$0.10〜0.15/1K WU）によって変動します。正確なコストはApp Metricsで自社アプリの実測値を確認してください。
Bubbleアプリの形態や規模別の月間WU消費量の目安｜参考事例を紹介
アプリの規模別のWU消費量は設計に大きく依存しますが、以下は参考となる目安です。
| アプリ/事業概要 | WU消費量/月（参考） | Bubbleコスト/月（参考） |
|---|---|---|
| 社内スケジュール管理 | 30K | $29〜 |
| BtoBtoC 採用プラットフォーム（小規模） | 30K | $29〜 |
| SaaS AIライティングツール | 100K〜150K | $119〜 |
| BtoBtoC プラットフォーム（中規模） | 500K | $134〜 |
| toC レンタル事業 | 4,000K | $450〜 |
| toC ノーコード教育事業 | 20,000K | $1,600〜 |
※上記は推定値であり、実際のWU消費量はアプリの設計（検索頻度、DB書き込み量、API連携数など）やユーザー行動によって大きく異なります。プラン料金や為替レートによってもコストは変動するため、あくまで目安としてご参照ください。
実際に弊社Swooo運営のAI WriterもPVあたりに換算すると、10WUを利用している計算でした。
多くのアプリは、プランに付属する基本割り当て量で十分対応できます。ただし、ユーザー数の急増や非効率な処理が判明した場合は、数百万WU単位で消費量が跳ね上がる可能性があるため注意が必要です。
大量データの分析などにはかなり不向きなため、ログ分析はGoogle AnalyticsやBigQueryなどを併用することをおすすめします。
ただし、実際には複数の行動が複雑に絡んだ計算となるため注意してください。
BubbleのWU（ワークロードユニット）料金体系について｜プラン別の基本量や従量形態を全解説
Bubbleの料金体系は「プラン機能」と「WU割り当て量」の組み合わせで構成されます。ここでは各プランの詳細と、超過時の課金ルールを解説します。
Bubbleの各料金プランにおけるWU割り当て量｜Free・Starter・Growth・Teamの詳細
Bubbleの料金プランは、利用可能な機能やカスタムドメインの有無、エディター数に加えて、月間に利用できるWUの基本割り当て量が設定されています。
| プラン名 | 月額料金 | WU割り当て量 |
|---|---|---|
| Free | 0ドル | 50K |
| Starter | $29（年契約）/ $32（月契約） | 175K |
| Growth | $119（年契約）/ $134（月契約） | 250K |
| Team | $349（年契約）/ $399（月契約） | 500K |
FreeプランおよびAgencyプランでは、overages（超過課金）やWorkload Tierの購入ができません。また、プランごとの具体的な料金は、Bubble社のポリシーにより変更される可能性があります。最新情報はBubble公式サイトで確認してください。
BubbleのWU超過分の課金ルール｜月間上限と従量課金のしくみを解説
基本割り当て量を超過した場合、アプリの稼働を維持するために追加のWU費用が発生します。超過時の対応方法は3つあります。
① 従量課金（Flexible Overages）
超過したWUに対して、1,000WUあたり0.3ドルで自動的に課金されます。アプリを止めずに稼働させ続けられるメリットがありますが、消費量によっては予想外に高額になるリスクも。
② Workload Tier（追加購入）
予め「追加のWUパッケージ」を定額で購入するオプションです。従量課金よりも単価が割安になることが多く、消費量が安定して多いアプリや、計画的に予算を組みたい場合に適しています。
| Tier | 月額料金 | 追加WU量 | 超過分の従量課金 |
|---|---|---|---|
| Tier1 | $26（年契約）/ $29（月契約） | 200K | $0.15 / 1K WU |
| Tier2 | $89（年契約）/ $99（月契約） | 750K | $0.14 / 1K WU |
| Tier3 | $269（年契約）/ $299（月契約） | 2.5M | $0.12 / 1K WU |
| Tier4 | $539（年契約）/ $599（月契約） | 6M | $0.10 / 1K WU |
※Workload Tierの内容は今後変更される可能性があります。最新情報はBubble公式サイトで確認してください。
③ WU上限（Workload Cap）の設定
予算オーバーを防ぐために、アプリの月間WU消費量に上限（Cap）を設定できます。overages（超過課金）を無効にしている状態で上限に達すると、Bubbleはアプリをオフラインにし、管理者へ通知します。復帰させるには、overagesを有効化するかWorkload tier（追加分）を購入します。高額請求は防げますが、アプリの機能が利用できなくなる点に注意が必要です。
オートスケールの設定をオフにしたい場合は、Setting → App Plan → Overages are disabledで、アプリを止めるか超過料金を発生させるかを選択できます。事業規模や予算に応じて適切な設定を行いましょう。
▼Bubbleの料金プランについてさらに詳しく知りたい方はこちら
自社BubbleアプリにおけるWU消費量の確認方法｜Settingタブやサーバーログで随時モニタリング
WUの管理は「見えないコスト」にしないことが鉄則です。Bubbleは詳細なモニタリングツールを提供しており、これを利用して常に使用状況を監視しましょう。
Bubbleの管理画面でWU使用状況を確認する手順
BubbleアプリのWU消費状況は、主に2つの方法で確認できます。
（A）Logsタブから見る（推奨）
- Bubbleエディターでアプリを開き、左側のタブから「Logs」を選択
- 「Server Logs」セクションでWorkloadチャートを確認
- 日ごと、時間ごとのWU消費推移やワークフロー単位の消費量を把握
（B）App Metrics Dashboardから見る
- Bubbleエディターでアプリを開き、左側のタブから「Settings」を選択
- 上部メニューの「Billing」（または「Usage」）タブに移動
- 「App Metrics Dashboard」にアクセス
また、そのApp Metricsを下にスクロールをすると、アクティビティごとの割合が円グラフで確認可能です。
こちらも同様にドリルダウンが可能で、具体的にどの行動でWU消費が多いのかが検索できます。
（下記では、Overall → Feching Data → Search とドリルダウンをしていきました）
※画面名称やメニュー構成はBubbleのアップデートにより変更されることがあります。見つからない場合は「workload」「app metrics」などのキーワードで検索して辿ってください。
App Metrics Dashboardでは、以下の情報を確認できます。
- 今月のWU合計消費量
- プランに割り当てられたWUと残りの量
- 開発（Development）環境とライブ（Live）環境それぞれの消費量
- 日ごと、時間ごとのWU消費推移を示すグラフ
BubbleアプリでWU消費が多い処理やワークフローを特定する方法
App Metrics Dashboardには、WU消費を掘り下げて確認できるドリルダウン機能があります。
① Logsタブ（サーバーログ）の活用
「Logs」タブの「Server Logs」には、実行されたワークフローの詳細、かかった時間、そして消費されたWUの量が記録されています。
ログをフィルタリングして、特定の期間や処理タイプ（DB検索、APIコールなど）に絞り込むことで、WUを大量消費している「ボトルネック」となっているワークフローを特定できます。
▼ 【Bubble】サーバーログの取得方法
② Activity Typeごとの分析
App Metrics内で、DB操作、ワークフロー実行、APIリクエストなど、WUを構成する活動タイプ（Activity Type）ごとに消費量の割合を確認できます。これにより、最適化すべき機能の方向性を判断できます。
BubbleのWU使用量の定期的なモニタリングと予測管理のベストプラクティス
WUを適切に管理するためのベストプラクティスを紹介します。
- 定期的なチェックをルーティン化：少なくとも週に一度、WU消費グラフに予期せぬスパイク（急増）がないかを確認
- 月末の予測を立てる：現在のペースから月末の総消費量を予測し、割り当て量を超過しそうであれば月の前半のうちにプランのアップグレードやWorkload Tierの購入を検討
- アラート設定の有効化：Bubbleは通常、割り当てWUの75%に達するとメール通知を送信。この通知が届いた場合は、緊急対策の必要性を示す警告サインと捉える
BubbleのWU上限に達した場合の影響と対処法｜アプリ停止を防ぐために知っておくべきこと
WUの上限に達したらどうなるの？アプリが止まってしまう？
WUの割り当て上限に達した場合、アプリの継続的な稼働に深刻な影響が出ます。事前に対処法を把握しておきましょう。
BubbleのWU不足時にアプリに起こる具体的な影響｜処理遅延、エラー、機能停止について
WU上限到達時の影響は、設定によって異なります。
WU上限を設定している場合（Workload Cap有効・Overages無効）
- 上限に到達した時点で、Bubbleはアプリをオフラインにし、管理者へ通知
- ユーザーはデータベースへの書き込みや複雑な検索ができなくなる
- 復帰させるには、overagesを有効化するかWorkload Tierを購入する必要がある
WU上限を設定していない場合（Overages有効）
- アプリの処理は継続する
- ただし従量課金が発生し、高額な請求書が届くリスクがある
Bubbleのワークロードユニット上限到達前のアラート通知と警告サインの見方
Bubbleは75%ルールでアラートを発します。割り当てWUの75%（または100%）を超えた場合に、管理者へメール通知が届くしくみです。
警告サインとして注意すべきポイント
- アラートメールを受け取った
- 日々のモニタリングでグラフが急激に右肩上がりになっている
- 週末や祝日前にWU消費が急増している
これらのサインを見逃さず、すぐにアクションを起こすことが重要です。
緊急時の対処法｜Bubbleプランの一時的なアップグレードや機能制限の実施
アラートを受け取った際の緊急対応は以下のとおりです。
① 即座のプランアップグレード
迅速により上位のプランにアップグレードし、基本割り当てWUを増やします。
② 追加WUの購入
必要に応じてWorkload Tier（追加WUパッケージ）を購入し、一時的にバッファを確保します。
③ WU消費の激しい機能の無効化
ログで特定した最もWUを消費している機能を、一時的に無効化または実行間隔を延長します。たとえば、頻繁に動くバックエンドワークフローや、特定ページの重い検索処理などが対象になります。
緊急対応はあくまで応急処置です。根本的な解決には、次のセクションで解説するWU最適化が不可欠になります。
BubbleアプリのWU（ワークロードユニット）消費を最適化する方法
Bubbleアプリの費用対効果とパフォーマンスを最大化するためには、設計段階からWUの最適化を意識することが重要です。ここでは具体的な最適化方法を解説します。
Bubbleのデータベース構造の見直し｜不要なフィールド・検索負荷を減らす設計へ
① Advanced Filterの回避
Do a Search forで取得したリストに対して、さらにAdvanced Filterを使用すると、大量のデータをクライアント側にダウンロードして処理することになります。これによりWU消費が高騰します。
可能なかぎりConstraints（制約）を利用して、サーバーサイドで検索を完結させましょう。
② DBの正規化
1つのデータ型（Thing）に情報を詰め込みすぎないことが大切です。関連データ型を分けて（正規化）、必要な情報だけを効率的に検索できるように設計しましょう。
③ カスタムステートの積極的な活用
一時的なデータやユーザーの画面状態（タブの切り替えなど）をデータベースに保存する必要はありません。WUを消費しないCustom Stateを活用することで、無駄な消費を防げます。
Bubbleワークフローの効率化｜サーバーサイド処理を最小限に抑える工夫
① クライアントサイドで完結させる
UIの表示切り替えや単純な計算など、サーバーを経由しなくても良い処理は、すべてクライアントサイドのワークフローで実行します。
▼ 【Bubble】Workflowの実行順序の仕様
② バルク操作の活用
50件以上のレコードを更新する場合、Schedule API Workflow on a listで一つずつ実行する代わりに、Data APIを利用した一括変更や、適切なMake changes to a listアクションを使用しましょう。サーバーへのリクエスト回数を削減できます。
▼ 【Bubble】再帰ワークフローの仕組みと活用法
BubbleのAPIコールやプラグイン利用の最適化｜外部連携のWUコストを抑える
① APIコールのキャッシング
頻繁に変わらない外部データは、APIコールをするたびにWUを消費するのではなく、一度取得したらBubbleのデータベースに保存（キャッシュ）します。一定期間はDBからデータを参照するようにしましょう。
② 取得データ量の制限
外部APIを呼び出す際、必要最低限のフィールドやレコードのみを取得するようにリクエストを調整します。
③ 信頼性の高いプラグインの選定
内部処理が非効率なプラグインはWUを大量消費する原因になります。評価の高いプラグインを選ぶか、自作のAPIワークフローに置き換えられないかを検討しましょう。
Bubbleのページ設計と表示ロジックの改善｜重いリピーティンググループや条件分岐を整理
① リピーティンググループ（RG）内の検索を避ける
RGのセル内で、さらにDo a Search forを実行すると、「セルの数×検索回数」のWUが消費されます。親RGのデータソースから派生したデータを参照するなど、親データソースを効率よく再利用する設計が必須です。
② Single Page Application（SPA）設計の検討
ページ遷移は毎回ページロードのWUを消費します。タブやCustom Stateを使ってURLはそのままに画面を切り替えるSPA的な設計を採用することで、ページロード回数を減らせます。
▼ 【徹底解説】BubbleでSPAを実装する方法！
BubbleアプリのWU最適化による実際の削減効果｜具体的な改善事例と削減率
最適化は、アプリのパフォーマンス向上とコスト削減に直結します。以下は改善事例の参考例です。
| 改善内容 | 削減効果（参考） |
|---|---|
| 非効率なAdvanced Filterを最適化された制約検索に置き換え | 該当ワークフローのWU消費を30%〜50%削減 |
| 高頻度タイマー付きサーバーサイドワークフローを必要な時だけ実行されるトリガーに変更 | 月間WU消費を大幅に削減 |
※削減効果はアプリの設計や利用状況によって大きく異なります。上記はあくまで参考値であり、実際の効果はApp Metricsで計測して確認してください。
BubbleのWU（ワークロードユニット）を最適化した開発・運用ならSwoooにご相談を
BubbleのWU（ワークロードユニット）の最適化は、ノウハウと実績が大きく関わる専門的な分野です。
当社Swoooは、国内初のBubble公式開発試験に合格したBubble開発会社です。Bubbleの新料金体系導入当初からWUのしくみを徹底的に研究し、多数のBubbleアプリのパフォーマンス改善、コスト削減を実現してきました。
Swoooが提供するWU最適化サポート
- 現状分析：App Metrics Dashboardやサーバーログを徹底的に分析し、高WU消費の原因となっている具体的なワークフローやDB設計を特定
- 効率的な設計：WU消費を最小限に抑えるデータベース構造の正規化、バックエンドワークフローの最適化など、根本的な設計改善を提案・実行
- 運用体制構築：WUのモニタリング体制の構築や、WUを意識した機能開発のガイドライン策定をサポート
「アプリの動作が重くなってきた」「WUの超過コストに悩んでいる」といったお悩みをお持ちでしたら、BubbleのWU最適化に特化したSwoooにぜひ一度ご相談ください。
BubbleのWU（ワークロードユニット）に関するよくある質問
Q. BubbleのWU（ワークロードユニット）とは何ですか？
A. Bubbleアプリが実行するサーバーサイドの処理にかかる負荷を数値化した独自の指標です。主にデータベース操作、外部APIコール、サーバーサイドワークフローなど、アプリの「活動量」に応じて消費されます。
Q. WUの大小は、アプリの動作や処理能力にどう影響しますか？
A. WUの割り当て量は、アプリが1ヶ月間に利用できる処理の総量を規定します。割り当て量を使い切ると、設定によってはアプリのサーバー処理が制限され、機能が停止したり著しく遅延したりします。WUの大小は、アプリの持続的な稼働と月額コストに直接影響します。
Q. WU消費が多くなりやすいアプリや処理はありますか？
A. データ量が非常に多いアプリ、Advanced Filterなどの複雑な条件を多用したデータベース検索、多数のレコードを一括処理するサーバーサイドワークフロー、頻繁な外部API連携などがWU消費の主要因となりやすいです。
Q. 外部APIとの連携もWU消費に影響しますか？
A. はい。Bubbleアプリ内でAPI Connectorなどを利用して外部サービスを呼び出す場合、そのAPIコール自体がBubbleのサーバー処理としてWUを消費します。特に大量のデータ取得や頻繁な呼び出しは消費量に直結します。
Q. WU使用量を月ごとに予測・管理するコツはありますか？
A. 以下の3つがコツです。
- Logs（サーバーログ）でWU消費の多い処理を特定し、早めに最適化する
- 日々の消費ペースを管理画面でモニタリングし、月末の総量を予測する
- 月間のWU上限を設定し、予算オーバーを防ぐ
Q. WUとCapacityの違いは何ですか？どちらを優先的に管理すべきですか？
A. WUは「月間のサーバー処理総量（量）」を示す現在の主要な課金指標です。Capacityは「同時処理能力（速さ）」を示す過去の指標でした。現在はWUを優先的に管理すべきです。WUが直接的に月額料金とアプリの持続的な稼働に影響します。
▼Bubbleでできること/できないことを詳しく知りたい方はこちら
▼Bubbleの開発事例について詳しく知りたい方はこちら
