BubbleのWU（ワークロードユニット）削減ガイド【2026年】重い原因と最適化の実務

執筆：Swooo編集部／監修：北浦 聡大（Bubble公式認定デベロッパー・国内初合格／Swooo共同創業者・元CTO）

Bubbleで作ったアプリの動作が重い、月の途中でWU（ワークロードユニット）の枠を使い切ってしまう、超過課金の請求額が読めない。
Bubbleを運用フェーズまで進めた方から、こうした相談を数多くいただきます。

WUはBubbleの従量課金の単位であり、同じ機能のアプリでも「作り方」次第で消費量が数倍変わります。つまりWUは、開発時の設計品質がそのまま毎月の運用コストに跳ね返る指標です。

この記事では、Bubble公式Goldパートナー（日本1位）として累計50件以上の開発を支援してきたSwoooが、社内研修で実際に使っているWU最適化の知見をもとに、WUの仕組み・消費が増える原因・削減テクニック・監視方法までを体系的に解説します。
まずは、WU消費の主な原因と対策を早見表で押さえておきましょう。

BubbleのWU（ワークロードユニット）とは

WU（Workload Unit）とは、Bubbleのサーバー上で発生した活動量を定量化した指標です。データベースの検索、ワークフローの実行、ページの読み込みなど、サーバーが仕事をするたびにWUが加算され、プランごとに定められた月間の枠を消費していきます。

ここで最初に押さえるべき大原則が1つあります。
WUを消費するのはサーバー側の処理だけで、クライアント側（ブラウザ内）の処理は消費しないという点です。

たとえばCustom stateに値をセットする操作そのものは0WUです。要素の表示・非表示の切り替えや、すでにブラウザに読み込まれたデータの並べ替えもWUを消費しません。
ただし注意が必要なのは、Custom stateにセットする値の「中身」です。セットする式の中に「Search for」が含まれていれば、その検索はサーバーで実行されるため課金対象になります。

WUの計測対象になる主なサーバー活動は次のとおりです。

• ワークフローの実行（Actionの処理）
• ページロード（Page Load）
• データベース検索（検索の実行自体に0.3WU＋取得した1件ごとに0.015WU）
• API呼び出し（1回あたり0.1WU＋データ転送量に応じた加算）
• Scheduled API Workflow・Database Trigger・Recurring Workflowの実行
• ファイルのアップロード、CSVの入出力、Bulk操作

1回あたりの単価は小さく見えますが、検索は「取得した件数×0.015WU」で膨らみ、さらに「ユーザー数×操作回数」で積み上がります。同じ検索でも、返す件数を絞れるかどうかで消費が変わるということです。ユーザーが増えるほど設計の差が金額の差になって表れるのがWUの特徴です。
なお、Bubbleそのものの特徴や得意分野については「Bubbleとは何か」で詳しく解説しています。

WUの料金の仕組み｜プラン別の枠と超過課金

各プランには月間のWU枠が含まれています。公式情報で確認できる枠は、Freeプランが月5万WU、Starterプランが月17.5万WUです。
GrowthプランとTeamプランについては、それぞれ月25万WU・月50万WUとする情報が広く知られていますが、公式ドキュメントの記載が変わる可能性もあるため、契約前に最新の公式情報を確認することをおすすめします。

枠を超過した場合の課金は、1,000WUあたり0.30ドルです。
また本番アプリとは別に、開発環境用として月10万WUの枠が用意されているため、開発中のテストが本番の枠を圧迫することはありません。

超過時の挙動は「Overages」の設定で選べます。超過した時点でアプリを止めるか、超過分を課金して稼働を続けるかをあらかじめ指定でき、消費が枠の75%と100%に達したタイミングでメール通知が届きます。
運用中のサービスであれば「課金して続行」を選ぶことになるはずで、だからこそ消費量のコントロールが重要になります。

毎月恒常的に超過が見込まれる場合は、超過課金を払い続けるのと、追加のWU枠（Workload Tiers）を購入するのとでどちらが安いかを事前に計算しておきましょう。超過量が読めるなら、枠の購入が有利になるケースが多くあります。

「最終コスト」で考える習慣を持つ

WUを見積もるうえで見落としやすいのが、1つのアクションの裏で発生する検索の存在です。

たとえば「Make changes to a thing」を1回実行するとき、変更後の値を決める式の中に「Search for X: first item」や「Search for Y: count」が含まれていれば、それらの検索はすべて個別に課金されます。アクション1つのWUだけを見ていると、実際の消費量を大きく過小評価してしまうのです。

件数のカウントや合計などの集計処理も同様に、「データの取得＋集計＋表示」の合算でコストが決まります。同一の集計は30秒間キャッシュされる仕組み（cached aggregation）があるため、短時間に同じ集計を繰り返す設計かどうかで消費が変わります。

ページ遷移の課金も整理しておきましょう。同一ページ内のアンカー移動は0WUですが、検索パラメータを変更した遷移やタブでの再読み込みは課金対象です。別ページへの遷移は、ページロード分に加えて遷移先の「Page is loaded」ワークフローの実行分も消費します。

WU消費が増える典型的な原因

数多くのBubbleアプリを見てきた経験から言うと、WU消費が想定を超えるアプリには共通パターンがあります。代表的な5つを紹介します。

1. ページロード時に大量のSearch forが走る

最も多い原因です。ダッシュボードを開いた瞬間に集計用の検索が何本も走る、初期表示に不要なタブのデータまで読み込んでいる、といった設計では、ユーザーがページを開くたびにWUが消費されます。
「Page is loaded」イベントはURLの検索パラメータが変わるだけでも再実行されるため、気づかないうちに実行回数が膨らみがちです。

2. ネスト検索（検索の中の検索）

「MessageからThreadを検索し、そのThreadからProjectを検索する」のような多段の検索は、1回の表示で検索が連鎖して消費が跳ね上がります。データが増えるほど遅くなり、動作の重さの原因にもなります。

3. Repeating Groupのセル内検索

Repeating Groupの各セルの中にSearch forを置くと、100行の一覧なら検索が100回実行されます。一覧系の画面で消費と表示速度の両方を悪化させる、典型的なアンチパターンです。

4. 認証なしで公開されたAPIワークフロー

認証なしのAPIワークフローを公開していると、外部から誰でも実行できる状態になります。セキュリティ上の問題であると同時に、想定外の呼び出しがWUを消費し続けるリスクでもあります。内部用のワークフローは公開設定を外すのが原則です。

5. Bulk処理・リストへの一括操作

大量レコードへの一括作成・一括変更や、リストに対するスケジュール実行は、1件あたりの消費×件数がそのまま積み上がります。処理自体が必要な場面はもちろんありますが、対象件数と実行頻度を見積もらずに回すと、月の枠を一気に削ることになります。

WU削減の具体的なテクニック

ここからは削減の実践編です。Swoooの社内研修資料で扱っているテクニックを、効果の大きい順に整理して紹介します。

ページロード時の処理を絞る（最優先）

まず手を付けるべきは「Page is loaded」の見直しです。ロード時のワークフローにConditionalを設定し、本当に必要な条件のときだけ実行されるようにします。前述のとおり、パラメータ変更でも再実行される点を踏まえた条件設計が必要です。

集計系のダッシュボードは、デフォルトで全集計を表示するのをやめて、ボタンでの手動取得や、定期的にバックエンドで計算して保存した値の再利用に切り替えるだけで消費が大きく変わります。
「人気商品リスト」のような更新頻度の低いデータは、Option setなどの静的データに持たせてしまう選択肢もあります。静的データの参照はサーバー検索を伴わないためです。

検索は「制約」で絞り、後処理のFilterに頼らない

Search forの後ろに付ける「:filtered」やAdvanced Filterは、検索結果を全件取得したあとに絞り込む後処理です。絞り込み条件をSearch forの制約（Constraints）に入れれば、サーバー側で絞った結果だけが返ります。検索は取得1件ごとに0.015WUが積み上がる仕組みなので、返す件数を絞ること自体がそのままWU削減になります。
制約で表現できる条件は必ず制約で書く。これだけで大きな差が出ます。参考までに、クライアント側での絞り込みに頼った設計では、900ユーザー規模のアプリで約300件・4MBのデータがページに読み込まれ、表示が20秒以上遅くなった実測例が知られています。

DB設計とPrivacy Rulesで「送るデータ量」を減らす

1つのデータタイプにフィールドを詰め込み、Privacy Rulesが全開のままだと、検索のたびに不要なデータまでまとめてブラウザに送られます。テーブルを役割ごとに分割し、画面で使わないデータはPrivacy Rulesで読み取り不可にしておくと、転送されるデータ量そのものが減ります。
Privacy Rulesはセキュリティ設定であると同時に、WUと表示速度の安全網でもあるのです。

ネスト検索の解消もDB設計の仕事です。多段の参照が必要な構造なら、多少冗長でも参照先を直接リンクするフィールドを持たせたほうが、検索は1回で済み、Privacy Rulesの設定も簡潔になります。

リストの持ち方にも目安があります。30件以下の小さなリストは親レコードのList Fieldで直接参照したほうが検索より速く、WUも少なく済みます。逆に30件を超える可能性があるリストはList Fieldに詰め込まず、接続されたデータタイプを検索で参照する構造にします。
また、平均評価のような集計値を表示のたびに計算するのではなく、あらかじめ計算結果をフィールドに保存しておくと、オブジェクトの取得回数と集計コストの両方を削減できます。

同じ検索を繰り返さない

同一画面内で同じ検索を複数の場所に書いていないかを確認しましょう。メールアドレスの重複チェックのように複数回参照する検索結果は、hidden variables（非表示の変数要素）に一度だけ保持して使い回すのが定石です。

ワークフロー内では「Result of Step X」の活用が効きます。前のステップの結果をResult of Step Xで参照すれば、検索の再実行が起きないことが保証されます。逆に、同じパラメータの検索を別の式として書き直した場合、再検索されないことは保証されません。確実に1回で済ませたいなら、Result of Step Xで受け渡すのが安全です。

Repeating Groupのセル内検索は、ページに非表示のRepeating Groupを1つ置いて検索を1回だけ実行し、各セルはその結果を絞り込んで参照する形に書き換えます。100回の検索が1回になります。

Current Userに頻用データを持たせる

Current Userのデータは各ページで常にダウンロードされています。この性質を利用して、「承認待ち件数」のような頻繁に参照する値をUserのフィールドに保存しておけば、表示のたびに走っていた検索を丸ごとなくせます。値の更新はデータ変更時にバックエンドで行えば整合性も保てます。

条件式とアクションの細かいチューニング

単体の効果は小さくても、アプリ全体に効く積み上げ型のテクニックです。

• 条件は軽い順に左から書く：and連結の条件は左から評価され、途中で結果が確定すると残りは評価されません（短絡評価）。画面上の値の判定を左に、Search forを含むサーバー条件を右に置けば、無駄な検索を減らせます
• 0件チェックは「first item is empty」：件数を数える「count is 0」より軽く済みます
• Auto bindingを濫用しない：社内の実測では、1フィールドのAuto bindingが1.05WUに対し、複数フィールドをまとめたMake changesが1.12WUでした。1フィールドだけならAuto bindingが有利ですが、2フィールド以上を編集するフォームなら、保存ボタンでまとめてMake changesするほうが安く済みます

バックエンド処理と外部APIの節約

バックエンドのワークフロー設計では、同じ条件チェックを複数のアクションに重複して書かず、ワークフローの分割やTerminateで後続の判定を止める構成にします。リスト処理と再帰的ワークフローを比べると、WU消費は再帰のほうが大きくなるため、消費の観点ではリスト実行が有利です（再帰は直列、リスト実行は並列という性質の違いもあります）。

外部API連携では、次の4点で消費を抑えられます。

• 都度呼び出しをやめてバッチ処理にまとめる（毎回ではなく1日1回など）
• 認証トークンは保存しておき、期限切れのときだけ再取得する
• レスポンスは必要なフィールドだけ取得する（response_group等の指定）
• ページネーションを使い、必要な件数だけ取得する

API呼び出しは1回0.1WUに加えて転送量分が加算されるため、「呼ぶ回数」と「受け取る量」の両方を絞るのがポイントです。
なお「X秒ごとに実行する」タイプの定期処理は消費が積み上がりやすく、最終手段と位置づけています。

実際にあった高額請求の話｜社内で共有されている教訓

WUの怖さは、ミスが「エラー」ではなく「請求」になって現れることです。
実際に、設定ミスによって大量のWUを消費し、高額な請求につながった実例を身近に見てきました。Swoooではその教訓を社内の研修資料に載せて、共有し続けています。

コードのバグなら動かなくなって気づけますが、WUの浪費はアプリが正常に動いたまま、裏で枠だけが削られていきます。Overagesを「課金して続行」にしていれば、気づいたときには超過分が請求に積まれている。この構造を理解しておくことが、何よりの防御になります。

この経験から、社内では次の2つを鉄則にしています。

• 一括修正はまず少件数で試す：Bulk操作やリストへの一括変更は、いきなり全件に実行せず、数件で動作とWU消費を確認してから全件に広げる
• 再帰的ワークフローは無限ループ対策を先に作る：終了条件が正しく機能することを検証してから本実行する。終了条件が抜けた再帰は、止まるまで消費し続ける

地味な運用ルールですが、WUの事故は「たった1つのワークフローの設定ミス」から起きます。個人の注意力に頼らず、手順として仕組み化しておくことをおすすめします。

WU使用量の確認・監視方法

削減の前に、まず現状把握です。WUの使用状況はBubbleエディタの「Logs」タブ内にある「App Metrics」で確認できます。

App Metricsではドーナツグラフでアクティビティ別の内訳が表示され、どの種類の処理（ワークフロー実行、検索、ページロードなど）がWUを消費しているかを掘り下げて特定できます。「なんとなく消費が多い」ではなく、「このページのこの検索が支配的」というレベルまで絞り込んでから対策するのが鉄則です。

あわせて、ブラウザ側からの調査も有効です。Chromeの開発者ツールでネットワークタブを開き、「search」「msearch」のリクエストを観察すると、ページ表示時にどんな検索が何回飛んでいるかを実際に確認できます。想定していない検索が飛んでいたら、それが削減候補です。

運用面では、枠の75%・100%で届くメール通知を関係者が受け取れる状態にしておくこと、そして月次でApp Metricsを定点観測し、消費傾向の変化をリリース内容と突き合わせることを習慣にしましょう。機能追加のたびに消費構造は変わります。

より踏み込んだ監視には、Bubble公式が買収した監査・監視ツールのFluskも選択肢になります。WU消費の多いユーザーや実行の遅いワークフローをアナリティクスで可視化できるため、消費の偏りを人単位・処理単位で特定したい運用フェーズで役立ちます。Swoooでも標準工程に組み込んで運用しています。

発注者向け｜WU設計ができる開発会社かを見極める

ここまで読んでいただくと分かるとおり、WUの消費量は開発会社の設計力でほぼ決まります。同じ要件でも、ページロードの設計・検索の書き方・DB構造の巧拙によって、運用後の月額費用が変わるのです。

開発費の見積もりは各社比較されるのに、運用後のWUコストは契約時にほとんど話題に上りません。しかし実際にオーナーが毎月払い続けるのは後者です。発注前に、次の質問を投げてみてください。

• 想定ユーザー数と利用頻度から、月間WUの試算を見積もり時に提示できますか
• WU消費を抑えるための設計ルール（検索・ページロード・DB設計）を社内標準として持っていますか
• 納品後、App Metricsを使ったWU消費のモニタリングと改善提案はしてもらえますか

これらに具体的に答えられる会社は、運用フェーズまで見据えた設計をしている会社です。逆に、WUの話題に答えが曖昧なまま契約すると、リリース後に想定外の月額コストを背負う可能性があります。
開発会社選び全般の評価軸は「Bubble開発会社の選び方」で詳しく解説しています。

Swoooは、東証グロース上場企業の株式会社アイビスが運営するBubble開発サービスです。Bubble公式Goldパートナー（日本1位）として累計50件以上の開発を支援しており、WU最適化を社内研修のテーマとして扱い、実案件の教訓を全開発メンバーで共有する文化があります。
WU消費の診断や、運用コストを見据えた開発のご相談はお問い合わせフォームからお気軽にどうぞ。

よくある質問

WUの枠を使い切るとアプリは止まりますか？

Overagesの設定次第です。「止める」を選んでいれば枠の到達時点でアプリが停止し、「課金して続行」を選んでいれば1,000WUあたり0.30ドルの超過課金で稼働が続きます。運用中のサービスは後者を選んだうえで、75%・100%のメール通知を必ず受け取れるようにしておきましょう。

Custom stateや要素の表示切り替えはWUを消費しますか？

消費しません。クライアント側（ブラウザ内）で完結する処理は0WUです。ただし、Custom stateにセットする式の中にSearch forが含まれる場合、その検索部分はサーバーで実行されるため課金されます。「操作は無料でも、中身の検索は有料」と覚えておくと判断しやすくなります。

どのプランを選べばWUが足りますか？

アプリの作り方と利用量に依存するため、一概には言えません。判断の手順としては、まず主要な画面と処理ごとのWU消費を「最終コスト」で概算し、想定ユーザー数と操作頻度を掛け合わせて月間消費を試算します。そのうえで、公式情報で確認できる枠（Free月5万・Starter月17.5万）と照らして選定し、恒常的な超過が見込まれるなら上位プランや追加枠の購入と比較検討してください。

スマホアプリ（ネイティブアプリ）を作る場合もWUはかかりますか？

かかります。Bubbleは2025年6月からReact Nativeベースのネイティブモバイル対応を提供していますが、アプリの形態が変わっても、データベース検索やワークフロー実行といったサーバー側の活動がWUの計測対象である点は同じです。詳しくは「Bubbleでのネイティブアプリ開発」をご覧ください。

すでに運用中のアプリでも、あとからWUを削減できますか？

できます。App Metricsで消費の内訳を特定し、支配的な処理から順に手を入れるのが基本です。Page is loadedのConditional化、Filterから制約への書き換え、hidden variablesでの検索の使い回しなどは、既存アプリにも後から適用できます。一方、ネスト検索の解消などDB構造に踏み込む改善は影響範囲が広いため、テスト計画とセットで進めることをおすすめします。

まとめ｜WU最適化は設計品質そのもの

最後に、この記事の要点を振り返ります。

• WUはサーバー活動の定量化指標。クライアント側の処理は消費しないという大原則を押さえる
• プラン枠は公式情報でFree月5万・Starter月17.5万。超過は1,000WUあたり0.30ドルで、Overages設定と75%・100%通知で制御する
• アクション単体でなく、式の中の検索まで含めた「最終コスト」で見積もる
• 消費が増える典型原因は、ページロード時の検索・ネスト検索・Repeating Groupのセル内検索・認証なしAPI・一括処理
• 削減は効果の大きい順に、ページロードの見直し→制約での絞り込み→DB設計とPrivacy Rules→検索の使い回し→条件式などの細部チューニング
• 一括修正は少件数で試す、再帰は無限ループ対策を先に。ミスが「請求」として現れるのがWUの怖さ
• 使用量はLogs>App Metricsのドーナツグラフでアクティビティ別に特定してから対策する
• 月間WUの試算を見積もり時に提示できる会社かどうかで、開発会社を見極める

WUの最適化は小手先の節約術ではなく、DB設計・検索設計・ワークフロー設計という開発品質の積み重ねです。運用コストに悩んでいる方も、これから開発を始める方も、この記事のチェックポイントを設計と会社選びの物差しとして活用してください。