Bubble開発会社11社の比較と選び方【2026年】公式Goldパートナー（日本1位）が解説

執筆：Swooo編集部／監修：諸藤 哲耀（株式会社アイビス Swooo事業責任者）

Bubble開発会社を探すと、「おすすめN選」の比較記事が数多く見つかります。ただ、その多くは開発会社自身が執筆したもので、掲載基準も自社寄りになりがちです。この記事も例外ではなく、Bubble公式Goldパートナーである当社Swoooが執筆しています。

だからこそ本記事では、「どの会社がおすすめか」ではなく、発注者が自分の目で確認できる判断軸を中心に解説します。Bubble公式のパートナー認定制度（Gold／Silver／Bronze）の公式要件、公式ディレクトリで各社の認定状況を自分で裏取りする手順、見積もりに表れないランニングコスト（WU）の見方、運営会社の事業継続性まで、他の比較記事があまり扱っていない一次情報ベースの判断材料をまとめました。

読み終えたときに、候補の開発会社を自分の基準で評価できる状態になることがこの記事のゴールです。

Bubble開発を外注するかどうかの判断

会社選びの前に、そもそも外注すべきかどうかを整理します。Bubbleはノーコードプラットフォームなので「自分で作れるのでは」と考える方も多く、実際に小規模なツールであれば内製も現実的な選択肢です。外注と内製の分かれ目がどこにあるかを先に押さえておくと、開発会社との商談でも「どこまでを依頼し、どこからを自社でやるか」の線引きがしやすくなります。

独学での習得には3〜6ヶ月かかる

Bubbleは「ノーコード」とはいえ、本番運用に耐えるアプリを作るにはデータベース設計、ワークフロー設計、プライバシールール（アクセス権限）設計など、相応の学習が必要です。一人前のBubble開発者になるには、一般的に3〜6ヶ月の学習期間がかかるとされています。

Bubbleの使い方を独学で習得することは可能です。ただし、新規事業の検証スピードが重要な局面では、この学習期間そのものが機会損失になります。

本番品質には見えない専門知識が必要

決済機能、外部API連携、複雑なデータベース構造、パフォーマンス最適化、セキュリティ設計。画面上は同じように見えるアプリでも、これらの作り込みの差はリリース後に表面化します。

実際にSwoooへご相談いただく案件の中には、他で開発されたアプリの改修依頼も含まれます。よくあるのは、データベース設計に無理があってユーザー数の増加とともに動作が極端に遅くなったケースや、外部APIとの連携が実装できずに機能が完成しなかったケースです。こうした状態からの立て直しは、最初から設計して作るより高くつくことが少なくありません。

外注が向くケース・内製が向くケース

• 外注が向くケース：決済・API連携・権限管理など要件が複合的／リリース時期が決まっている／本番運用後の保守まで見据えたい
• 内製が向くケース：社内限定の小規模ツール／要件が単純で個人情報をほぼ扱わない／担当者が学習時間を確保できる

外注する判断をした場合、次の課題が「どの会社に頼むか」です。ここからが本記事の本題です。

結論：Bubble開発会社を選ぶ7つの判断軸

先に結論をまとめます。Bubble開発会社は、次の7つの軸で評価すると失敗しにくくなります。

1. Bubble公式パートナー認定：ティア（Gold／Silver／Bronze）と公式ディレクトリでの裏取り
2. 開発実績：件数だけでなく、リリース後にどうなったかまで確認
3. 要件定義と開発標準：進め方の丁寧さと、開発規約・チェックリストの有無
4. セキュリティ体制：プライバシールール設計と監査プロセス
5. 費用の透明性：内訳が分解された見積もりと、相場との整合
6. WU（ランニングコスト）の設計：月々の運用費まで見積もりに含めているか
7. 運営会社の信用力：事業継続性と保守契約の持続可能性

1〜5は多くの比較記事でも触れられる観点ですが、本記事では「発注者が自分で検証する方法」まで踏み込みます。6と7は、リリース後に効いてくるにもかかわらず、選定段階で見落とされやすい軸です。Bubbleアプリはリリース後も保守・改善で年単位の付き合いになるため、後半の軸ほど契約後の満足度を左右します。順に解説します。

判断軸1：Bubble公式パートナー認定を一次情報で確認する

最初に確認したいのが、Bubble社が公式に運営するエージェンシーパートナー制度の認定状況です。「Bubble公認」「正規パートナー」といった表記は各社のサイトでよく見かけますが、認定には明確なティア（等級）があり、公式サイトで誰でも現況を確認できます。

ティア制度の全体像：Gold／Silver／Bronzeの3段階

Bubbleのエージェンシーパートナー制度は、2023年6月からGold／Silver／Bronzeの3ティア制になりました。登録すれば名乗れる制度ではなく、実績・売上貢献・チームの認定資格保有率などの定量基準で審査され、しかも四半期ごとに再審査されます。一度取った認定が永続するわけではなく、直近の実績が伴わなければティアは下がります。

Bubble公式の「Agency Tiers & Benefits」（2025年7月1日更新版）によると、各ティアの主な要件は次の通りです。

Goldは「年間5万ドル以上の価値創出」と「引き渡し実績15本以上」という、継続的に一定規模の開発を回していないと満たせない基準です。また、どのティアでも顧客満足度（CSAT）が審査項目に含まれます。認定開発者比率が小規模ティアほど高いのは、少人数チームほど全員が公式認定を持つことを求める設計になっているためです。

ティアごとの特典：発注者にも意味がある

ティアは開発会社側の勲章というだけでなく、発注者にも実質的な意味があります。公式資料に記載されている特典のうち、発注者に関係するのは次の2つです。

• 公式ディレクトリでの表示優先順位：Goldが最上位に表示される
• Bubble社との連携：Goldのみ四半期ビジネスレビューとパートナーシップ専任窓口が付く

特に「Bubble社との専任窓口」は、プラットフォーム固有の不具合や仕様変更に直面したときの解決スピードに直結します。Bubbleは頻繁にアップデートされるプラットフォームなので、運営元との距離の近さは保守フェーズで効いてきます。

なお、公式資料にはEnterprise案件紹介のレベニューシェア（Gold 20%／Silver 15%／Bronze 10%）も記載されています。これは発注者に直接関係する特典ではありませんが、Bubble社が各ティアをどの程度の格付けとして扱っているかを示す傍証にはなります。

発注者が自分で裏取りする手順

認定状況は、Bubble公式の「Experts Directory」で誰でも確認できます。英語のページですが、確認するのはバッジ表示と数字だけなので、英語が読めなくても数分で終わります。候補の会社が決まったら、契約前に次の手順で現況を確認することをおすすめします。

1. Bubble公式ディレクトリ（bubble.io/experts-directory）にアクセスする
2. 絞り込み条件のLocationで「Japan」を指定する
3. 候補企業の名前を探し、社名の横のティアバッジ（Gold partner／Silver partner／Bronze partner）を確認する
4. 個別ページを開き、実績数（apps built）と活動年数（Active）を確認する
5. 商談時に「現在のティアと、直近の再審査状況」を質問する

ポイントは3つあります。第一に、ディレクトリに掲載されていてもティアバッジが付いていない会社があります。掲載と認定は別物です。第二に、ティアは四半期ごとに再審査されるため、過去の認定と現在の認定が異なる場合があります。各社サイトの表記ではなく、ディレクトリの現在の表示を確認してください。第三に、apps builtの数字はBubble側に登録された引き渡し実績なので、自己申告の「開発実績N件」より客観性の高い比較材料になります。ただし、ディレクトリの表示順とapps builtの数は一致しません。表示順は実績本数ではなく、エコシステム内の売上規模を反映しているためです。

5分あれば終わる作業ですが、これをやるだけで、各社が掲げる認定表記と公式の現況とのズレを自分の目で確認できます。相見積もりの候補を絞り込む最初のフィルタとして、費用対効果の高い確認手順です。

日本のGold認定の現況（2026年7月時点）

2026年7月時点で、公式ディレクトリをLocation=Japanで検索すると、Goldパートナーのバッジが表示されるのはSwoooを含む2社のみです。SilverとBronzeを合わせても、ティアバッジを持つ日本のエージェンシーは片手で数えられる程度で、大半の掲載企業はバッジなしの登録にとどまります。

Swoooは、Gold認定2社の中でもBubbleエコシステム内の創出価値で上回り、公式ディレクトリのティア順ソートで先頭に表示されるBubble公式Goldパートナー（日本1位）です。年間5万ドル以上の価値創出・引き渡し15本以上・四半期再審査という基準を継続的にクリアしています。もっとも、この情報自体も上の手順でご自身の目で確認できます。当社を候補に入れる場合も、他社と同じ基準で裏取りしてください。

なお、認定がない会社に依頼してはいけないという意味ではありません。優れた開発チームがティア申請をしていないケースもあります。ただし認定がない場合は、次章以降の「実績の質」「開発標準」「セキュリティ体制」を、より丁寧に確認する必要があります。

会社の認定とあわせて見る個人資格：Bubble公式開発者認定試験

ティア要件に含まれる「Bubble認定開発者の比率」の元になっているのが、Bubble公式の開発者認定試験（Bubble Developer Certification）です。2023年に始まった試験で、90問を3時間半以内に解き、正答率75%以上で合格となります。認定は取得すれば永続するものではなく、有効期限付きで更新が必要です。

会社のティアが組織としての実績を示すのに対し、この資格は個々の開発者のスキル証明です。商談では「認定保有者は何名いますか。担当予定のメンバーは保有していますか」まで質問すると、実際に自分の案件を担当するチームの水準が見えてきます。参考までに、Swoooの共同創業者エンジニアは2023年10月、この試験に国内で初めて合格し、その後も資格を更新しています。

判断軸2：開発実績は「リリース後」まで確認する

実績確認というと「何件開発したか」に目が行きがちですが、件数は判断材料の入口にすぎません。確認したいのは、作られたプロダクトがリリース後にどうなったかです。

受託開発の事例紹介は「こんな機能を実装しました」という機能一覧の説明で終わることが多く、それだけでは開発品質を判断できません。事例を見るときは、次の観点を加えてください。

• サービスが現在も稼働しているか：事例のURLにアクセスして、実際に動いているかを確認する
• リリース後の継続改善に関わっているか：初期開発だけでなく、その後の機能追加・改善まで担当した事例があるか
• 事業の変化に言及しているか：ユーザー数の推移、事業フェーズの進展など、開発後の話が書かれているか
• 自社と近い要件の実績があるか：業界そのものより、決済・マッチング・予約・API連携など「機能構成の近さ」で見る
• クライアントの声が実名で載っているか：匿名の「お客様の声」より検証可能性が高い

Swoooは累計50件以上のプロダクト開発を支援しており、開発実績の一覧では、稼働中のサービスを開発の経緯とあわせて公開しています。他社を検討する場合も、同じ深さで事例を読み込めるかを比較基準にしてください。

なお、判断軸1で触れた公式ディレクトリの「apps built」も、実績確認の補助線になります。各社サイトの実績表記と、Bubble側に登録された引き渡し数を突き合わせると、実績の数え方（提案段階の案件を含むのか、引き渡しまで完了した案件か）が見えてきます。数字が一致しないこと自体は珍しくありませんが、その差を質問したときに明快な説明が返ってくるかどうかは、その会社の誠実さを測る材料になります。

判断軸3：要件定義の進め方と開発標準

要件定義フェーズの確認ポイント

Bubble開発のトラブルの多くは、開発前の要件定義が不十分だったことに起因します。依頼を受けてすぐ画面を作り始めるのではなく、「何を作るのか・なぜ作るのか・誰が使うのか」を言語化するプロセスを持っているかが分かれ目です。提案段階で次の点を確認してください。

• 要件定義フェーズに専用の期間と成果物（要件定義書・画面遷移図など）を設けているか
• 機能要件だけでなく非機能要件（パフォーマンス・セキュリティ・運用コスト）も議論するか
• ワイヤーフレームやプロトタイプを作成してから実装に入るか
• 仕様や決定事項をドキュメントとして残す運用があるか

開発標準（規約・チェックリスト)の有無を聞く

要件定義よりさらに見落とされやすいのが、開発標準の有無です。Bubbleはコードを書かない分、命名やワークフローの整理方法が開発者ごとにバラつきやすく、標準がないまま作られたアプリは、担当者が変わった瞬間に誰も触れなくなるリスクを抱えます。

商談では、次の質問をそのまま投げてみてください。答えの具体性で、組織としての開発成熟度がわかります。

• 「コーディング規約や命名規則はありますか」
• 「複数人開発のバージョン管理（ブランチ運用）はどうしていますか」
• 「リリース前のチェックリストはありますか。何項目ありますか」
• 「担当者が交代した場合、引き継ぎはどう担保されますか」

参考までに、Swoooの場合は命名規則・ワークフロー管理・ブランチ運用・パフォーマンス上の禁止事項を定めた社内開発規約と、リリース前チェックリスト37項目（プライバシールールの設定漏れ、デバッグ用設定の戻し忘れ、不要データの削除など）を全案件で運用しています。納品時の手戻りゼロという実績は、この標準化に支えられています。同水準の仕組みを持つ会社は他にもあるはずなので、有無と中身を比較材料にしてください。

判断軸4：セキュリティ体制

Bubbleで作られたアプリのセキュリティ品質は、プラットフォームではなく開発者の設計で決まります。特に重要なのがプライバシールール（データへのアクセス権限）の設計で、ここが甘いアプリは、画面上は問題なく見えても、ブラウザの開発者ツールから他人のデータが読み取れてしまうことがあります。

発注者がソースを読めなくても、体制は質問で確認できます。

• 「プライバシールールはどういう方針で設計しますか」→ 「全拒否から始めて必要な分だけ開ける」という趣旨の回答が返ってくるか
• 「権限チェックはクライアント側とサーバー側のどちらで行いますか」→ 重要なチェックはサーバー側、という原則を説明できるか
• 「セキュリティ監査のツールやプロセスはありますか」→ 具体的なツール名や工程が出てくるか

一例を挙げると、Bubbleでは仕様上、データタイプ名・フィールド名やOption set（選択肢データ）の中身が外部から参照可能です。この仕様を理解していれば「そこに機密情報を置かない」という設計判断が最初からできますが、知らずに作られたアプリでは意図しない情報公開につながります。個人情報や決済を扱う案件ほど、こうした仕様レベルの理解がある会社かどうかが重要になります。

Swoooでは、プライバシールールをdeny-by-default（全拒否から開始）で設計し、Bubble公式が買収したセキュリティ監査ツールFluskによるチェックを標準工程に組み込んでいます。発注者側で確認すべき具体的なポイントは、Bubbleのセキュリティ解説（発注者向けチェックリスト）で詳しく解説しています。

判断軸5：費用の透明性と相場観

初期開発費の考え方

Bubble開発の費用は、機能の数よりも「要件の複雑さ」「連携する外部システムの数」「品質担保の水準」で大きく変わります。同じ「予約システム」でも、検証用の最小構成と、決済・通知・管理画面まで備えた本番運用構成では金額のレンジが数倍変わるため、種類別の一律相場だけで判断するのは危険です。
Swoooで実際にお受けしている規模感や、開発タイプ別の費用レンジ・見積もりの内訳はBubble開発の費用相場で詳しく解説しています。

実務上のコツとして、予算の上限は最初の相談時に率直に伝えることをおすすめします。予算を伏せて「いくらでできますか」と聞くより、「この予算内で何がどこまで作れるか」を聞いた方が、開発会社側は機能の優先順位を踏まえた現実的な構成を提案できます。予算に収まらない要件があるなら、初回リリースから外して段階的に追加する計画に組み直せるかどうかも、この時点で議論できます。予算を伝えたときに、金額に合わせて範囲を設計し直す提案が返ってくる会社は、プロジェクト全体の設計力も高い傾向があります。

見積もりを比較するときは、金額の高低より内訳の分解度を見てください。「一式◯◯円」ではなく、要件定義・デザイン・実装・テスト・リリース支援がフェーズ別に分かれた見積もりを出す会社は、プロジェクト管理も同じ精度で行う傾向があります。極端に安い見積もりは、要件定義やテストの工程が含まれていないことがあるので、「この金額に含まれない作業は何か」を必ず確認してください。

開発費とは別にかかるBubble本体の利用料

見落とされがちですが、開発費とは別に、Bubble本体の利用料が毎月かかります。本番運用に使う有料プランは、年払いの場合でStarter月額29ドルから、上位プランは119ドル、349ドルと段階的に上がります（2026年7月時点・Web向けプラン）。エンタープライズ要件では別途Enterpriseプランの見積もりになります。

加えて2025年からはネイティブモバイルアプリ向けの料金体系が追加され、モバイル対応の有無でも月額が変わります。開発会社に「本番運用ではどのプランが必要になる想定か」を初回見積もりの段階で確認しておくと、リリース後に想定外の固定費が発覚する事態を防げます。

保守・運用費用の確認ポイント

初期開発費・Bubble利用料に加えて、3つ目の費用が月額の保守費です。ノーコード開発の保守は月3万〜20万円程度が目安で、契約内容によって幅があります。契約前に次の点を確認してください。

• 保守プランの対応範囲：不具合対応のみか、Bubbleアップデートへの追従、軽微な文言・画面修正、機能追加の相談まで含むか
• 不具合発生時のレスポンスタイム：一次回答までの目安時間が定義されているか
• 機能追加・変更の扱い：保守枠内で対応できる範囲と、別途見積もりになる範囲の線引き
• 担当者の固定：開発を担当したメンバーが保守も見るのか、別チームに引き継がれるのか

3つの費用（初期開発費・Bubble利用料・保守費）を、想定する運用年数で合計したものが本当の総コストです。相見積もりを取る場合は、初期費用の比較だけでなく、この総コストの土俵で並べると判断を誤りにくくなります。相見積もりは3社程度が現実的で、それ以上増やすと各社との対話が浅くなり、かえって見極めの精度が下がります。

判断軸6：WU（ランニングコスト）を見積もりに含めているか

これは他の比較記事でほとんど触れられていませんが、Bubble開発の総コストを左右する重要な軸です。

Bubbleは2023年の料金改定で、サーバー側の処理量をWU（Workload Unit）という単位で計測する従量課金の仕組みになりました。各プランには月間のWU枠があり（無料プランで月5万WU、Starterプランで月17.5万WU）、超過すると1,000WUあたり0.30ドルの追加課金が発生します。

重要なのは、同じ機能でも実装の仕方によってWU消費が大きく変わるという点です。たとえばデータベース検索は、実行1回で0.3WUに加えて取得1件ごとに0.015WUが課金されます。1回の画面表示で必要以上のデータを取得する実装や、全件取得してから絞り込む非効率なフィルタ処理を重ねると、ユーザー数の増加とともにWU消費が膨らみ、月々の超過課金として跳ね返ってきます。初期開発費が安くても、WUを考慮しない実装のせいでランニングコストが高くつくのでは本末転倒です。

単純化した例で規模感を示します。一覧画面が表示のたびに1,000件のデータを取得する実装だと、1回あたり約15.3WUを消費します。この画面が月10万回表示されると約153万WUとなり、Starterプランの月間枠17.5万WUを大きく超え、超過分だけで月400ドル前後の課金になる計算です。同じ画面でも、取得を必要な件数に絞り、検索条件をサーバー側で適切に設計すれば、消費は桁単位で変わります。
実際のWU消費は機能構成によって異なりますが、「実装次第でランニングコストが桁で変わる」という構造は押さえておいてください。

選定段階では、次の2つを質問してください。

• 「想定ユーザー数での月間WU消費の目安を、見積もり時に試算してもらえますか」
• 「WU消費を抑える実装ルール（高コストな検索・フィルタ処理の回避など）はありますか」

この質問に具体的に答えられる会社は、リリース後の運用まで含めて設計しています。WUの仕組みと削減方法の詳細はBubbleのWU削減ガイド（運用費の見極め）にまとめているので、月額コストが気になる方は先に目を通しておくと、商談での質問精度が上がります。

判断軸7：運営会社の信用力と事業継続性

最後の軸は、開発技術とは別の話です。Bubbleアプリは、リリース後もプラットフォームのアップデート対応や機能改善で、開発会社との付き合いが年単位で続きます。つまり開発会社選びは、数年間の保守パートナー選びでもあります。

その観点で確認したいのが、運営会社そのものの継続性です。

• 運営会社の事業年数と規模：会社としてどれくらい継続しているか、開発チームは何名体制か
• 財務情報の開示レベル：上場企業であれば、業績・財務が四半期ごとに公開されており、発注前に確認できる
• 保守契約の実績：長期の保守契約が実際に継続している事例があるか
• 個人か組織か：担当者ひとりに依存する体制か、チームで引き継げる体制か

数年単位の保守を任せる相手として、「その会社は3年後も同じ体制でサービスを提供しているか」という問いは、技術力の比較と同じくらい重要です。倒産や事業撤退まで行かなくても、事業の主軸が変わって保守の優先度が下がる、キーパーソンの退職で対応品質が落ちる、といった変化は受託業界に限らず起こり得ます。財務情報や組織体制が公開されている会社ほど、この不確実性を発注前に評価できます。

Swoooの運営会社は、東証グロース上場の株式会社アイビス（証券コード9343）です。世界累計5億ダウンロード超のペイントアプリibisPaintを開発・運営する会社で、業績・財務情報は証券取引所の開示ルールに基づいて公開されています。発注先の与信確認が必要な場合も、公開情報だけで審査できます。

日本の主なBubble開発会社

7つの判断軸を当てはめる相手として、Bubble開発の受託を公表している国内の主な会社を挙げます（順不同・網羅ではありません）。掲載は当社による推奨を意味しません。特徴は各社の公表情報に基づく2026年7月時点の要約なので、認定状況や実績は、判断軸1の手順で公式ディレクトリの現況を必ず裏取りしてください。

候補を2〜3社に絞ったら、社名の知名度ではなく、本記事の判断軸に沿った質問への回答の具体性で比較することをおすすめします。同じ質問を各社に投げると、体制の差は回答の解像度にはっきり表れます。

Bubbleが向く案件・別の手法を検討すべき案件

ここまでBubble開発会社の選び方を解説してきましたが、Goldパートナーの立場であえて付け加えると、すべての案件にBubbleが最適なわけではありません。会社選びの前提として、手法選びの現在地を共有しておきます。

Bubbleが向く案件

• 小〜中規模のMVP・事業検証：インフラ構築が不要で、企画から数週間で動くものを出せる。Swoooの実績では最短2週間でMVP納品
• 業務システム・社内ツール：ユーザー数が読みやすく、WUコストが安定する
• ビジネス側で運用を引き継ぎたい案件：エンジニアでなくても画面や文言の修正ができる

AI駆動開発との使い分け

一方で、開発の技術環境はこの1〜2年で大きく変わりました。Claude Codeなどのコーディングエージェントを使ったAI駆動開発は、コードを書く速度の問題を解消しつつあり、開発スピードの面でBubbleと同等以上になる領域が出てきています。Bubbleの優位はインフラ整備が不要な点に残るため、当社では現在、目安として100万円未満の小規模案件はBubble、それ以上の規模ではAI駆動開発も並べて比較するという使い分けをおすすめしています。

これは「Bubbleは小規模専用」という意味ではありません。中規模以上でも、運用の引き継ぎやすさや改修サイクルの速さでBubbleが合理的なケースはありますし、管理画面はBubble・コア処理はコードというハイブリッド構成も選択肢です。大事なのは、候補の開発会社がBubble以外の選択肢も含めて比較提案できるかです。1つの手法しか持たない会社は、どんな要件にもその手法を勧めることになりがちです。手法の比較検討から相談したい場合は、AI駆動開発の解説記事もあわせてご覧ください。

他のノーコードツールとの使い分け

ノーコードの中でも、Bubbleがすべての領域で最適なわけではありません。Bubbleが得意なのはデータベースを持つWebアプリで、要件によっては別のツールの方が速く安く仕上がります。

• スマホのネイティブアプリが主戦場：iOS/Android向けにはFlutterFlowが有力な選択肢です。両者の違いはFlutterFlowとBubbleの比較記事で解説しています。Bubble自体も2025年からネイティブモバイル対応を開始しましたが、実運用には確認すべき点があるため、Bubbleでのネイティブアプリ開発の注意点もあわせてご覧ください
• コーポレートサイトやLPだけを作りたい：STUDIOなどのサイト制作特化ツールの方が、デザイン自由度と制作スピードで有利です
• 社内の定型業務アプリ：案件管理や日報のような定型業務は、kintoneのような業務アプリ基盤で十分なことがあります

商談の初期に「この要件はBubbleに向いていますか。別のツールなら何が候補になりますか」と聞いてみてください。ツールの得意・不得意を要件に沿って説明できるかどうかも、その会社の提案力を測る材料になります。

依頼から納品までの流れ

Bubble開発を外注する場合の一般的な流れです。会社によって細部は異なりますが、大枠は次の5ステップで進みます。

ステップ1：初回相談・ヒアリング

開発したいアプリのアイデアや目的、ターゲットユーザー、予算・スケジュールの大枠を伝えます。この段階で詳細な仕様が固まっていなくても問題ありません。ヒアリングを通じてアイデアを要件に落とし込む作業を一緒に行うのが、開発会社の仕事の一部です。

ステップ2：要件定義・見積もり

ヒアリング内容をもとに、開発する機能の一覧と仕様を定義します。ワイヤーフレームや画面遷移図をこの段階で作る会社もあります。要件が固まったら詳細見積もりが提示されるので、内訳と「含まれない作業」を確認してください。あわせて、本番運用時のBubbleプランと月間WUの想定もこの段階で聞いておくと、総コストの全体像がつかめます。

ステップ3：デザイン・開発

契約後、UIデザインと開発が進みます。Bubbleは開発途中でもデモ環境を共有できるため、動く画面を見ながら週次で進捗確認するのが一般的です。認識ズレは早い段階で見つかるほど修正コストが小さいので、定例での確認頻度は契約前にすり合わせておきましょう。

ステップ4：テスト・レビュー

開発が一段落したら、テスト環境での動作確認と修正を行います。発注者側でも実際に操作して、不具合や使い勝手の改善点をフィードバックします。このフェーズを丁寧に行う会社ほど、リリース後の問題が少ない傾向があります。開発会社側のリリース前チェック（権限設定・デバッグ設定・不要データの確認など）が体系化されているかも、このタイミングで見えてきます。

ステップ5：リリース・保守

テスト完了後、本番環境へリリースし、保守・運用フェーズへ移行します。Bubbleはプラットフォーム自体が定期的にアップデートされるため、不具合対応・機能改善は月額の保守契約で継続対応してもらうのが一般的です。保守費用の目安と契約前の確認ポイントは、判断軸5で解説した通りです。

よくある失敗パターンと対策

Bubble開発の外注でよく見られる失敗パターンと対策です。実際にSwoooへ寄せられる相談から、匿名化して典型例を挙げます。

失敗1：要件が曖昧なまま開発が始まり、費用が膨らんだ

よくある状況：「まず作ってみてから考える」姿勢で依頼し、開発途中で追加要望が続出。当初見積もりの倍近い費用になった。

対策：開発前に「誰が・何を・なぜするか」のユーザーストーリーを一覧化し、必須機能と後回しにできる機能を分ける。要件定義を独立したフェーズとして持つ会社を選ぶ。MVPの思想で言えば、初回リリースの機能は「削りすぎたかな」と感じるくらいで適量です。

失敗2：データベース設計に無理があり、後から動かなくなった

よくある状況：リリース直後は問題なかったが、データ件数とユーザーが増えるにつれて画面表示が数十秒かかるようになった。改修を依頼したら「作り直しに近い」と言われた。

対策：これはSwoooに実際に持ち込まれるレスキュー相談の典型パターンです。データベース設計とデータ取得方法の巧拙は、データが少ない検収時点では見えません。契約前に「データが10倍になったときのパフォーマンスをどう担保するか」を質問し、設計面の回答が返ってくるかを確認してください。判断軸3で挙げた開発標準の有無が、ここで効いてきます。

失敗3：外部連携が「できるはず」のまま完成しなかった

よくある状況：決済や外部サービスとのAPI連携を含む要件で契約したが、開発会社側に連携の実装経験がなく、その機能だけ未完成のまま停滞した。

対策：API連携は、Bubbleの画面作成とは別の技術領域です。連携が要件に含まれる場合は、「同じサービスとの連携実績があるか」「エラー時の処理（通知・再実行）まで実装するか」を具体的に確認してください。連携先のサービス名を出して質問すれば、経験の有無は回答の解像度でわかります。

失敗4：担当者の交代で保守が止まった

よくある状況：個人の開発者に依頼していたが、体調不良や別案件の都合で連絡が取りにくくなり、改修が数ヶ月止まった。別の依頼先を探したが、ドキュメントがなく引き継ぎに時間がかかった。

対策：年単位の運用を前提とする案件では、チームで引き継げる体制と、命名規則・ドキュメントの標準化がある組織を選ぶ。判断軸7で挙げた事業継続性の確認は、この失敗の予防でもあります。すでにこの状況にある場合も、引き継ぎ・立て直しに対応できる会社はあるので、あきらめる前に相談してみてください。

よくある質問

Q. 公式パートナー認定がない会社に依頼しても大丈夫ですか？

問題ないケースもあります。認定は「一定の実績と体制がBubble社の審査で確認されている」ことの客観的なサインであって、認定がない=技術力がない、ではありません。ただし認定がない場合は第三者による検証材料が減るので、実績の稼働確認・開発標準・セキュリティ体制の質問を、より丁寧に行うことをおすすめします。

Q. フリーランスと開発会社、どちらに頼むべきですか？

小規模で短期の案件なら、腕の良いフリーランスは費用面で有力な選択肢です。一方、年単位の保守・改修が見込まれる案件や、決済・個人情報を扱う案件では、引き継ぎ体制とレビュー体制のある組織に分があります。判断軸2〜4（実績・開発標準・セキュリティ）は、どちらに頼む場合でも同じように確認してください。

Q. 開発期間はどれくらいかかりますか？

機能を絞ったMVPであれば数週間〜、標準的な規模で1〜3ヶ月程度が目安です。Swoooでは最短2週間でのMVP納品実績があります。期間を左右する最大の変数は要件の確定度なので、早くリリースしたい場合ほど、初回相談前に「必須機能の絞り込み」を進めておくと効果的です。

Q. 他社で作ったBubbleアプリの改修だけ頼めますか？

対応している会社は多く、Swoooでも他社開発アプリの改修・立て直しのご相談を受けています。その場合、まず現状のアプリの設計状態（データベース構造・権限設定・パフォーマンス）を診断してから、改修と再構築のどちらが合理的かを判断する流れになります。

Q. Bubbleで作ったアプリは、後からスクラッチ開発に移行できますか？

Bubbleにはソースコードを書き出す機能がないため、移行する場合は同じ仕様を別の技術で再実装する形になります。ただしこれは必ずしもマイナスではありません。事業検証を終えた段階では要件が固まっており、検証前に作るより大幅に効率よく再構築できるためです。最初のMVPをBubbleで素早く検証し、事業の成立が見えてから本格構築に投資するという二段構えは、初期投資を抑える現実的な戦略です。移行の可能性がある場合は、その計画も含めて相談できる会社を選んでください。

Q. 見積もりの前に費用感だけ知る方法はありますか？

本記事で紹介した費用の考え方と費用相場の解説記事で大枠はつかめます。Swoooの場合は、要件を入力すると概算費用を確認できる即時見積もりツールも提供しています。

Q. Bubbleで作られたアプリには、どんな事例がありますか？

Bubble公式の発表では、2025年の1年間だけで720万件のアプリが作成されています。国内で一般公開されているサービスにも、Xを活用した人材マッチングサービス「kitene」、個性的な本屋やブックカフェを検索できる「LIBRIS」、結婚式準備アプリ「ブラリノ」などの事例があります。Swoooが開発を支援した事例は開発実績の一覧で、より幅広い事例はBubbleのノーコード開発事例の記事で紹介しています。

Q. Bubbleの弱点はありますか？

あります。エディタと公式ドキュメントが英語であること、本番品質の開発には相応の学習期間（一般に3〜6ヶ月）が必要なこと、実装品質によっては表示速度やWU消費が悪化することです。ただし表示速度とランニングコストは、判断軸6で解説したとおり実装の巧拙で桁が変わる領域なので、ツール固有の限界と捉えるより、候補の開発会社に対策を質問して確認する方が実務的です。英語が不安な場合も、日本語で対応する開発会社に依頼すれば発注者側に英語力は必要ありません。

まとめ：7つの判断軸チェックリスト

最後に、この記事の判断軸を商談で使えるチェックリストの形でまとめます。7つすべてを完璧に満たす必要はありませんが、複数の項目で回答が曖昧な会社は、契約後に同じ曖昧さがプロジェクト管理にも表れる可能性が高いと考えてください。

• 認定：公式ディレクトリ（bubble.io/experts-directory）でティアバッジと実績数を自分で確認したか
• 実績：事例のサービスが現在も稼働しているか、リリース後の改善まで関わっているか
• 開発標準：規約・ブランチ運用・リリース前チェックリストの有無と項目数を質問したか
• セキュリティ：プライバシールールの設計方針と監査プロセスを質問したか
• 費用：フェーズ別に分解された見積もりか、「含まれない作業」を確認したか
• WU：想定ユーザー数での月間ランニングコストの試算を求めたか
• 継続性：運営会社の事業年数・体制・財務の開示レベルを確認したか

Swoooは、東証グロース上場の株式会社アイビス（証券コード9343）が運営するBubble公式Goldパートナー（日本1位）です。日本で2社のみのGold認定として、年間5万ドル以上の価値創出・引き渡し15本以上・四半期再審査という公式基準を継続的にクリアし、累計50件以上のプロダクト開発を支援してきました。要件定義から開発、リリース後の保守・改善まで、開発標準に基づくチーム体制で担当します。

「何を作るかまだ固まっていない」「BubbleとAI駆動開発のどちらが合うか判断したい」という段階のご相談も歓迎しています。初回相談では、要件の整理と手法の選択肢、概算の費用感まで持ち帰れる状態を目指します。上の7つの判断軸で、当社自身を評価しながらお話しください。

関連ガイド：
Bubble開発の費用相場（機能別の内訳）
BubbleのWU削減ガイド（運用費の見極め）
Bubbleのセキュリティ解説（発注者向けチェックリスト）
AI駆動開発とは（Bubbleとの使い分け）