はじめに

過去の経験上、ノーコード（ローコード含む）に対して強い懐疑心を抱いているエンジニアが、現代のノーコード開発ツール『Bubble』のポテンシャルを調査・検証した記事です。

本記事では、100名規模のWEBシステムを架空の題材に設定し、Bubble・クラウド（AWS等）・オンプレミスの3手法で「5年間のTCO（総所有コスト）」や「エンジニアの必要体制（FTE）」を定量的に比較検証しました。単なる「開発の手軽さ」に留まらない、AI時代の脆弱性対応やセキュリティパッチといった「インフラ保守工数・人件費」の観点から、現代のノーコードが持つ導入価値をエンジニア視点で客観的に紐解きます。

まずBubbleって何？

ノーコード開発ツールです。

導入会社の例としては、以下のものがあります。
１：HDDで有名なSEAGATE
デバイスのプロビジョニングや顧客のサブスクリプション管理まで、社内向けおよび顧客向けのアプリ開発。

２：ゲーム開発のUnity
ゲームクリエイター向けの知識ハブの開発。

３：HQ（日本の会社）
リモートワーク支援のプラットフォームサービスの開発。

えっ、ノーコードって微妙なのでは？

私もそう思います。
過去の経験上、ノーコード（ローコード含む）はすごい懐疑的に見てます。
ぶっちゃけ覚える操作多いわりにできることはやたら制限されてるし、自分でコード書いた方がよっぽど楽で早いやんって。

今回はBubbleってどうなんだ？学習コストを割いた上で導入することにどれくらいの価値があるのか？というのを調査しました。

想定の請負案件

仮の保険代理店システムを構築することを前提に、Bubble、クラウド、ローカル開発のコスト比較を行います。

ペルソナ

新しくできた保険代理店。
法人営業を基本とする。
保険会社は生損保を両方扱う１社だけで、乗り合いではない。
社内システムは存在しないため、請負開発として新規開発することにした。
実現方法にはこだわっておらず、開発会社に委ねられている。
ただし、個人情報を扱うため万全のセキュリティとランニングコストは気にしている。

会社の規模想定

ユーザ数：100名
顧客データ数：1000名以上（1ユーザ当たり担当顧客10名の前提）
契約データ数：25000件以上（1顧客当たり3～5件保有の前提）

システムの前提

ブラウザで操作する、WEBアプリとする。

開発のジレンマ

まず、上記の案件を受けたとして、考えることがいっぱいあります。
・保険業界ということは、個人情報を扱う。
・セキュリティは通常以上に気を遣わないといけない。
・インフラはセキュリティをがちがちにしないといけない。

クラウドにする？オンプレミスにする？

上記想定だと、少なくともAPサーバとDBサーバとWAFなどを乗せるネットワーク機器が必要になりますよね。
オンプレだとOSはWindows？Linux？、DBはMySQL？PostgreSQL？ネットワーク機器はどこの製品を使う？WAFはなに乗せる？
クラウドならAWS AmplifyかAppRunnerかECSに、Amazon RDSかAuroraか…。
さらに負荷分散やスケーリング構成とか、バックアップ設計とかアプリの仕様以外で考えることがいっぱいあります！

もしBubbleなら？

サーバー、負荷分散、ネットワーク設計など全部丸投げできる。
その結果、アプリの仕様だけに集中できるようになります。
※もちろんBubble以外にもノーコード開発サービスはあるんですが、今回は無視してます。

検討・作業項目	Bubble	クラウド (AWS等)	ローカル/オンプレ
ハードウェア保守	不要	不要	必要 (5年でリプレース)
OS/ミドルウェアのパッチ	不要	必要 (定期的)	必要 (脆弱性が出るたび)
NW/VPN設計	不要	必要 (VPC設計)	必要 (物理配線含)
スケーリング対応	自動	設定が必要	機材追加が必要
バックアップ運用	標準装備	設定が必要	仕組みを自作

5年先を見据えた持たないIT経営

ということで、Bubble、クラウド、オンプレについて5年のTCO（トータスコストオブオーナーシップ）にまとめました。

TCO(概算）

項目	Bubble (ノーコード）	クラウド開発 (AWS等)	ローカル/オンプレ
初期開発・環境構築	300	800	1,000
インフラ/ライセンス料 (年額)	60 (Teamプラン)	30	50 (電気/部品)
セキュリティ・保守人件費 (年額)	10	120	200
【1年目合計】	370	950	1,250
【5年累計（TCO）】	650	1,550	2,250

※100ユーザー、25,000件の契約データを扱う「保険代理店システム」を想定（単位：万円、概算）

この表はあくまで一例ですが、重要な観点としてAIによるセキュリティ攻撃のリスクへの対応コストもざっくり盛り込んでいます。

セキュリティ保守コスト

AIによる攻撃（自動化された脆弱性スキャンやインジェクション）に対し、
クラウドやオンプレなら以下の作業が「毎月・永久に」発生します。

OS/ミドルウェアのパッチ適用: OSのカーネル更新やDBのマイナーアップデート。
依存ライブラリの更新: Node.jsやPython等のライブラリに脆弱性（CVE）が出るたびに対応。
WAF/IPSの調整: 攻撃トレンドに合わせたファイアウォールルールの更新。

Bubbleなら以下の作業で済みます。

「プラットフォーム・インフラ層」のセキュリティは、Bubble社が数百万のアプリを守るために一括で実施している。
業務ロジックの脆弱性（例：データの閲覧権限設定）をチェックする工数だけが残る。

クラウドやローカル開発では月額のサーバー代は安く見えますが、そこにエンジニアの保守工数という人件費が上乗せされます。
上記の対応のため、エンジニアには重い責任と月１０～２０時間ほどの工数がかかることが想定されます。
Bubbleだと、この辺の工数を丸投げできるのが強みですね。

Bubbleは、単なる安さではなく、将来の不確実なセキュリティリスクと人件費を固定費化できる、もっとも経営的に予見性が高い選択肢かと推測しました。

開発工数のメリット

先ほどの費用感に対して、実際に稼働するエンジニアの想定がこちら。

エンジニア数の想定比較（FTE：フルタイム相当）

開発手法	開発時 (初期)	運用保守 (1名あたり月間工数)	主な役割分担
Bubble	1名	0.1名	業務ロジック構築、UIデザイン、API連携
クラウド (AWS等)	2名	0.5名	アプリ開発(1)、インフラ/セキュリティ(1)
ローカル/オンプレ	3名	1.0名	アプリ(1)、サーバ管理(1)、NW/物理保守(1)

人数の根拠

なぜ人数に差が出るのか？というと
エンジニアが「何に時間を使っているか」という責任範囲（レイヤー）の違いがポイントです。

Bubble：1名（ビジネスロジックに集中）

Bubbleは、インフラ・DB・認証・暗号化といった「土台」が最初から完成しています。

開発時: エンジニアは「保険契約の重複チェック」や「満期フォローの自動化」といった、設計した業務ロジックの実装だけに集中できます。そのため、1名で十分に完結します。
運用時: セキュリティパッチはBubbleが勝手に当てるため、エンジニアは「現場からの要望（メモ欄の追加など）」に応える時だけ動けばOKです。

クラウド：2名（アプリとインフラの分業）

クラウド開発では、どんなに小さくても「アプリを作る人」と「インフラ（土台）を守る人」の役割が必要です。

開発時: AWSなどの設定（VPC、IAM、WAF、DBの冗長化）に1名、コードを書くのに1名必要です。
運用時: AIによる攻撃が激化する昨今、WAFのログ監視や、脆弱性が見つかった際のライブラリ更新に、定期的な工数が削られます。

ローカル/オンプレ：3名以上（物理とOSの守護者）

物理的な機材を抱えるため、役割がさらに細分化されます。

開発時: サーバの選定・調達、OSのキッティング、ネットワークの敷設など、実装に入る前の「準備」に人手が必要です。
運用時: 「ディスクがいっぱいになった」「停電対策」「ハードウェアの故障」「OSの脆弱性対応」など、システムの価値（業務）とは関係ない「守り」の作業に、常に1人分程度の工数が張り付きます。

Bubbleの強み

ここまでの説明で、コスト面でBubbleに優位性があるという事が見えてきたと思います。
開発者の視点で見た時も、次のような便利な標準機能があります。

アプリを作る時って、どのシステムでも作らないといけない共通処理ってありますよね。
たとえばログインなどの認証処理、検索結果のページング、CSV出力やファイルアップロード、入力フォームのサニタイズやインジェクション対策など。
これらはBubbleでは標準実装なので、わざわざ外からライブラリを持ってきたり、実装する必要はありません。
もちろん、外部プラグインとして展開もされているものがあるので、それを組み合わせることも可能です。

他にも以下のような機能があります。

Privacy Rules: DB層でデータの閲覧権限をガチガチに固める仕組み（「論理削除」の実装も一瞬！）。
API Connector: AIや外部SaaSと無限に繋がれる拡張性。外部DBにも接続できる。
Backend Workflows: バッチが必要な重い処理（PDF一括作成など）も非同期でスマートに実行。

つまるところ、開発者は業務仕様と業務ロジックに集中できるということがメリットになります。

もちろん…

Bubbleは強力な武器ですが、魔法の杖ではありません。
気を付けるべきポイントはあります。

権限設定ミス。
Bubble固有のDB設計(普通のRMDBSとは感覚が違う）。
WU単位に課金する特殊な請求体系なので、設計をミスれば、コストとメンテナンスの地雷原になる。
コードを書き出せないため、プラットフォームと運命を共にする経営判断が必要（客先との契約時に注意）。

などなど。
AIによるバイブコーディングも流行していますが、結局サーバー選定やセキュリティの管理工数からは逃れられないんですよね。
こういうところを丸投げできるのも、ノーコードツールの魅力と言えるかもしれません。
もちろん、世の中に100%完璧なシステムなんて存在しませんし、Bubbleも例外ではありません。

今回のコスト検討で使ったTeamsプランではSLAの明文化はありませんが、実績ベースでの高稼働率は担保されています。実際に運用を初めてみて、大規模化する場合には、99.9%のSLA保証があるエンタープライズプランへアップグレードする道筋も確保しています。
少なくとも、自前でサーバ管理して脆弱性パッチするよりは、開発者のメンタル的にも安心して利用できると言えます。

まとめ

Bubbleでの開発は「楽をするため」もあるけど「より価値の高い仕事に集中するため」の選択肢として有用と言えます。
実際に細かく見積もりだして調べてみるまでは、ノーコードツールの価値がまったく感じられなかったけども、管理層や開発体制としてのメリットに目をむけると、意味があるように感じています。
ローコードツールで吐き出したものを別途用意したサーバに乗せるんじゃなくて、全部お任せできるのが強みですね。
もちろん、ロックインなどのデメリットもありますが。

Bubbleは無課金であっても、ほぼフル機能を使ってアプリを作る事が出来ます。
Live環境へのデプロイやカスタムドメイン適用などは有料プランが必要ですが、検証・開発環境としては十分すぎるほど触れます。
まずは触ってみて、感触をつかんでみるのはいかがでしょうか。

注意点として、公式のチュートリアル動画とはUIが変わっているのでそこの差分は手探りで見つけていくしかありません。
動画のチュートリアルも更新してくれないかなぁ。