はじめに
前回の記事でBubbleの概要紹介をした。
今回はPC用デモサイトを作成して得られたナレッジを共有する。
AIプロトタイプの夢と現実
Bubbleでアプリを作ろうとすると、AIで要件を投げて、自動生成させることができる。
要件を適当に投げるとスカスカのサイトしか作られないが、ある程度要件を練ってから投げるとそれなりのものが出来上がる。
注意点は日本語プロンプトを投げること。最初気を使って英語に変換してプロンプトを投げたら、全部英語の表記のサイトになってしまった。
日本語で投げると日本語のサイトを作ってくれる。
日本語プロンプトの精度
AI機能に日本語を投げても、しっかり解釈してそれっぽいUIと画面遷移を作ってくれる（プロトタイプとして優秀）。
文字数制限の壁
プロンプトは2,500文字制限があるため、長文要件はカットが必要。
「皮」だけの罠
画面遷移や見た目は作られるが、各画面のアクションはバグっていたり、ボタンの配置が崩れているため、手動修正が必須（Fixed枠指定でチェックボックスがズレているので、Fit指定に変更等）。
ナレッジ
- アプリを作ろうとしたらpremiumプランを無料体験させようとしてくるが、課金したくない場合はstart with basic featuresを選ぶ。
コストの地雷
デフォルト設定のまま運用すると、Workload Unit（WU=課金単位）を無駄食いする仕様になっている。
便利さとコストはトレードオフで、デモサイトでは自動検索のままにしたが、本番運用では客先が払うコストに直結するため修正が必要。
また、画面内に配置しているオブジェクトは基本使いまわせる。例えばGridに表示している情報は、内部ではDB構造そのまま保持してたりするので、そこからデータを引っ張りだすことで再検索のコストを減らせる。
むしろ、集計のために複雑なクエリを投げるよりも、基本オブジェクトを使いまわすようにするべき。
自動検索の罠
一覧系画面はデフォルトで画面表示時に自動検索が走る仕様になっている。放置すると無駄な課金が発生するため、Repeating GroupのData Sourceは初期状態では空にしておくのが鉄則。
Auto-bindingの挙動
更新画面等でAuto-bindingは便利だが、React等のメモリバインドと異なり「変更の都度、リアルタイムでDB更新処理が走る」仕様なので乱用に注意。
画面内キャッシュの活用
顧客詳細内の契約一覧など、すでに画面上にある要素を判定に使う場合は、DBを再検索せずRepeating Group's List: filtered: count > 0等で画面内処理すればWUを節約できる。
※filteredは個別にダイアログが出てきて、ここに条件を入れる。ここでは右辺にCurrentDate/Timeを書いても加減算できる。
ナレッジ
- 詳細画面とかはわざわざ再検索させなくていい。各項目を選んで、Initial Contentを設定する。情報は遷移前の一覧画面のオブジェクトを指定するとよい（例:Parent group's Customers's name)。
画面・ロジック構築の沼と攻略法
コードを書かないだけで、プログラミング思考（ロジック・状態管理）はフル要求される。
数式はプロパティエディタのようなところで都度候補を出して選択していかないといけない。
どこかで作った数式をコピーして、貼り付ければOKではないので、ここが面倒なポイント。
たまにバグのような挙動があり、同じ数式が入力できるところとできないところがある。
AIに作らせた画面はそれっぽくなってはいるが、動的に取得するプルダウンは100%バグっていた。
アクションも文字列は表示するのに実際は何も生成しないとかおかしい部分があるので、しっかり動作確認することが大事。
また、アクションの名前から期待される処理結果と実際の挙動が違うものが多々ある。
例えば、Emailを送るアクションは定義されているが、これにリストを渡すと全部のデータを1通のメールに混ぜ込んでセキュリティ事故になりかけるとか。
演算式の「左右」による謎バグ
日付加減算（例：現在日付＋1ヶ月＞満期日）を行う際、左辺にCurrent date/timeを持ってこないと加減算の選択肢すら出ない場所がある（※計算場所によって挙動差あり）
〇：Current date/time + months: 1 > Parent group's Contract's expiry_date
×：Parent group's Contract's expiry_date < Current date/time この書き方だと、加減算の候補自体が表示されない。
リセット処理の罠
Reset relevant inputsは直前にDB書き込みされたinputしか消さない微妙仕様。検索条件クリア等はグループ化してReset a group/popupを使うのが正解。
検索条件のスマートな実装
ワークフローのOnly whenではなく、Search forの中のConstraints（検索条件）に設定し、Ignore empty constraintsをチェックすると、未入力項目を自動でWHERE句から除外してくれる。
Only whenでWFを分岐しまくる必要がないため、便利。
State管理とリスト操作
チェックボックスの選択状態管理はCustomState（List指定）を定義し、エレメントイベントからplus item / minus itemで明示的に追加・削除のワークフローを組む必要がある。
大量処理（Backend Workflow）の地雷
リストに対するAPI Workflow呼出時、パラメータ側を「List」ではなく「単体（Single）」として受ける設定にしないと、1通のメールに全員のデータが混ざるなどの大事故になる。
プルダウン初期バグと型ズレ
自動生成されたプルダウンは初期状態でバグっていることが多い（Dynamic choicesで再設定が必要）。Repeating Groupで型が合わない時はType of Contentがずれている。
日付・言語・アイコンなどのUI仕様
デザイナ上の日付プレースホルダーは日本風に設定されているが、実装はすべてアメリカ式のフォーマットで設定されているので注意。
Custom format（yyyy-mm-dd）の指定が必要。
標準エレメントのアイコンはFontAwesome v4ベース。
ナレッジ
- プルダウンは初期だと全部バグってるので修正が必要。基本はもともと設定されている内容を消して、必要なオブジェクトだけが返ってくるようにすればいい。
Choices->DynamicのChoices sourceにDo search for...で目当てのオブジェクトを選ぶ。
そのあとConstraintsで検索条件を指定する。
Sortingは見たまま設定すればよい（ただし5万件がMAXとのこと、仮にそんな候補数になるならそもそもプルダウンにしてはいけないが）。
- DB設計を見ながらデザイン調整する際は、編集ページをブラウザのタブで別途開いて並べるとある程度追従する。
- デバッグは右ペインのInspectを選択すると、項目に紐づいているWFが表示される。
- 分からないことやトラブルシューティングはスクショを撮ってGeminiに聞くのが最速。
ただし、2026/7/25時点ではBubbleのUIがBeta版になっており、生成AIの学習情報とずれているのでうまく読み替える必要がある。 - freeプランだとCSVは出せない。
- Gridを指定しても、候補に出てくる型が違う（contractsが欲しいのに、List of customersしか出ない）とき…これはgridの型設定が間違っている。
RepeatingGroup contract-gridを選んで、ここのVisualのContentを見る。
Type of Contentがたぶん違う型になってるはず。
ここがCustomerになっていると、当然ながらCustomerの項目しか候補に表示されないので、Contractに変更する。 - AIが組んだチェックボックスは位置がずれてる。これは枠に対してFixedでチェックボックスを置いてるから。これはチェックボックス側をFitにすることで修正できる。
- Emailはなんとfreeでも動かせるが、send emailはlistを渡すと1通のメールに全員分のデータが混ざって送られてしまうか、宛先に全員が入ったメールが1通飛ぶ挙動になるので危険。
例えば任意の契約情報を選択し、それぞれ別の顧客にメールしたい場合は、CustomState（ReactのuseStateと思えばOK）と、Backend Workflow（バッチ処理と思えばOK）を別途組んで設定する必要がある。 - チェックボックスはなぜかデザイナから直接WFを紐づけられないが、WF画面側からはElementに指定することでWFを紐づけられる。
- チェックボックスで何を選ばれているかは、別途CustomStateを設定して、追加・削除のWFが必要。（CustomStateはBetaボタン横のボタンから開ける、Listにチェックを入れるのが必須）
WF側ではさっきの通り、チェックボックスから直接作成はできないのでElement Eventから直接対象エレメントを選んで生成する。
追加はOnlyWhenでrow-select-checkbox is checked、削除はisn't checkedを選ぶ。
そして次のアクションでSet statesをして、elementにcheckboxを指定。するとCustomStatesにさっき追加したものがでてくる。
例えばselect_contracts = This Checkbox's select_contracts:plus item Parent Group's Contractと設定する（削除はminus)
左辺と＝は編集できない。 - Backend Workflows側はBackend Workflows>Schedule API Workflow on a listを選ぶ
パラメータはListではなく単体として設定すること（これが大事、最初に選んだon a listがlistを受け取ってfor eachするから）。
ここをListにすると、emailで話したことと同じ事件が起こる。 - 残念ながらBackend workflowsの呼び出しはfreeプランでは動作検証できない。
- 日付のフォーマットは以下の方法で修正する。
入力項目はVisualのConfigureでDate formatをCustomにし、Custom formatにyyyy-mm-ddを入れる。
DBの検索結果などは、数式に入れる。たとえばCustomer's birth_date :formatted as yyyy-mm-ddのようにする。 - 設定画面のLanguageでApplication primary languageをJapaneseに設定しても、日付フォーマットは変わらない（ただし住所の見た目は変わる）。
- 電話番号の型はUS Phoneしかなく、見慣れないフォーマットになる。素直にtextを選ぶ。さらに入力フォーマットを制御したい場合は、別途プラグイン導入が必要な模様。
- 作ったページの名称（Web Pagesの名前）を変えると、ほかのページからのリンクは自動更新されないので手動で修正が必要。
セキュリティ＆権限：Privacy Rulesの威力
アプリレベルではなく、DB層で事故を防ぐ強力なガード機能。
通常のDBではwhere句で対象データを絞り込むが、BubbleではTBL設計に権限設定が深く結びついている。
データの公開範囲を厳密に決められるし、どの項目を表示させるかどうかまで制御できる。
設定さえ間違えなければ、表示してはいけない情報を出すリスクをかなり減らすことができる。
また、ログイン・ログアウトといった認証機能は作る必要がない。
パスワードにいたってはそもそもDB項目としても表示されない（開発者すら触れない）。
全部内部的に隔離した状態で作りこんでくれるので、ここに気を遣う必要がない。
開発者目線としては安心して開発することができる。
「名前すら出ない」強力な保護
プルダウンに自分以外の候補が出ない原因の多くはPrivacy Rules。
DataのPrivacyを見る。EveryoneElseのFind this in searchesをオフにすると、DB検索結果としてデータが存在自体しない扱いになり、強力に保護される。
認証機能
ActionからLog the user inとかLog the user outを選ぶだけ。簡単すぎる。
AIの初期生成データ
それっぽいデータをDBに生成してくれるが、テスト的ではなく限りなく本物のような人物名やメールアドレスなどが設定される。デモ公開時や納品時は必ず消しておいたほうがいい。
ローコードに本当に必要なスキル
Bubbleによるプロトタイプ作成を通して見えてきたのは、ローコード開発は開発業務を大幅に効率化してくれるものの、「誰でも使える魔法の杖」ではないという現実。
クセのある挙動や仕様上の限界に直面した際、それを打破するのはエンジニアとしての地力（トラブルシューティング力やDB構造の理解）だった。
Gemini等のAIをフル活用するにしても、適切な前提知識がなければAIの回答の正誤すら判断できない。
非エンジニアや未経験者が「コードを書かなくていいから」と安易に導入すると、トラブルシューティングで手詰まりになったり、一見動いているように見えて裏で甚大なWU（コスト）を垂れ流すシステムになりかねない。
結論:ノーコード／ローコードの本質
ローコードはプログラミングを不要にするものではなく、基礎ロジック・DB設計・状態管理を理解したエンジニアが「非本質的な作業をショートカットして素早く価値を出すための拡張機能」。
システムの全体像を描けるエンジニアが扱って初めて、その圧倒的な開発スピードという真価を発揮する。
エンジニア経験の有無で分かれる暗黙知
ロジック思考やDB構造を理解していない未経験者を「ローコード要員」として育てるのは相応のリスクがある。
実務経験がある現場リーダークラスによる監督が必要かと思われる。