chatGPT先生とBubble×Render開発、はじめました

きっかけは「スケジュール確認がめんどくさい」から

もともと、通っているフィットネススタジオの予約ページを毎回開いて確認するのが手間で、
「自分の希望のレッスンだけをいい感じに一覧表示してくれる何かが欲しい」と思ったのがスタートでした。

最初はローカルで動くPythonスクリプトを書いて、手動で動かして整形するだけ。
でも思った以上に便利で、「これ、もう少しちゃんと動かしたい」と思うようになりました。

なぜ“ちゃんとシステムを作ろう”と思ったのか

以前から趣味でWeb制作や小さなスクリプトを書いていましたが、「もっと本格的に作りたい」と思い、IT業界に転職もしました。

ただ、配属先はIT業務サポート寄りのポジション。
実装や構築はベンダに任せるのが当然の体制で、「自分で触れば早いのに」「触ってみたいのに触れない」というもどかしさがずっとありました。

社内では「やりたいことがあるなら提案していいよ」と言ってもらえるけど、
人を巻き込んで進める情熱なんて全くありません。

そこで「せめてプライベートでは、作りたいものがあるなら自分の手で形にしたい」と思い、個人開発を本格的に再開しました。

今、作っているもの

生活に寄り添うスケジューラーを作っています。
ざっくり言うと、以下のような機能を持つ構成です：

• Bubbleで表示用のUIを構築
• バックエンドはRender
• Pythonで整形・保存処理を行う
• 外部サービスページからスケジュールを取得（GUI操作が必要なのでPlaywright使用）
• 月2回だけcronで自動実行（毎日動かすほどじゃない）

UIにはなぜBubbleを使っているのか

Bubbleは「ノーコードでWebサービスが作れるツール」です。

Bubble: The full-stack no-code app builder. Start for free!

選んだ理由はシンプルで、「UIをサクッと作るなら、Bubbleが一番早かったそうだったから」です。
ネイティブアプリにも対応してるらしいですし、個人で何でもやりたい人にはちょうど良さそうでした。

今触ってみて利点を挙げるとすれば

• 学習コストはそこまで高くない
• 入力フォームとDBの接続が一瞬
• RepeatingGroupでリスト表示も簡単
• ワークフローとロジックをまとめて設計できる

とにかく「手を動かせばすぐ動く」というのが魅力ですね。
仮実装のつもりが、そのまま本番でも十分に使えると感じています。
BubbleのビジュアルUIで仮実装して、そのまま本番にも耐える構成になるというのはかなり大きな利点でした。

でも、Bubbleだけでは完結しなかった

なんかよくBubbleだけで爆速開発したっていう記事もチラホラありますが、私には無理でした。
自分でスクリプト組める人はバックエンド準備して、BubbleはUIだけってした方が気が楽だと思います。

というのも、実際に作ってみると、Bubbleのデータの扱い方には制限がありました。
DBのDataTypeに制限がありますし、複雑なデータ処理はワークフロー設定では無理でした。

やっぱりちょっと凝ったデータ処理には向いていなさそうなので（頑張ればできるかもですが）
そこで外部にちゃんとしたバックエンド（サーバ・DB）を用意して、そこに書き込む構成が必要になりました。

この時点で「Bubble + 外部バックエンド」という分離構成に切り替わっています。

なぜバックエンドにRenderを選んだのか

Bubbleから外部処理を叩きたい
＋
定期的にスクリプトを動かしたい
＋
ローカル実行・VPS構築は面倒

…という条件を満たすサービスを探していたところ、Renderがちょうど良かったです。

• GitHub連携で簡単にデプロイ
• Playwrightを含むDocker環境がそのまま動く
• Web API / cron job / 内部専用処理（Private Service）などがGUIで分けられる
• 無料枠がまだ残っている（Herokuは無料プラン終了）

特に、BubbleからPOSTするWeb APIとして使えて、cron jobも1画面で設定できるのは大きな魅力でした。

今の構成（進行中）

[Bubble] → [Render Web Service] → [Render Private Service] → [Render PostgreSQL]
                                             ↑
                                     [Render Cron Job]

• Bubbleから予約リスト取得・保存のAPIを叩く
• cron jobでも同じスクリプトを定期実行（月2回）
• PostgreSQLに保存された内容をBubbleで表示

ちなみに環境変数などもRender上で管理できます。
整理整頓が得意でない自分にとっては、無くしてはいけないデータを管理できるのはとてもありがたいですね。

進め方は「調べすぎず、まず動かす」

私は仕事でコードを書いているわけではありません。
「ちゃんと調べてからやる」よりも、「まず動かしてみて試す」方が圧倒的に性に合っています。

• ドキュメントを読むよりログを見る
• GUIでエラーを試す方がわかりやすい
• 何度も失敗して構成を踏み直す方が記憶に残る

chatGPT先生に何百回も相談しながら、行き止まりに突っ込んでから構成を直すという手戻りだらけの開発をしています。
でもそうやって組んだ構成やハマりポイントが、今後誰かのヒントになればと思っています。

このシリーズで何を書くのか

この記事は導入編です。

次回以降の記事では、以下のようなテーマで構成・エラー・試行錯誤の記録を書いていく予定です：

• Playwright入りDocker構成をRenderで動かすまでの全記録
• chatGPT先生に何度聞いても構成が通らなかった話
• 月2回だけ定期実行したいときのcron構成とRender設定
• BubbleとPostgreSQLの責務分離とSQL Connector / APIの役割分担

想定読者

• ノーコードだけでは限界を感じているBubbleユーザー
• chatGPTに聞きながら開発をしている個人開発者
• PlaywrightやRenderに興味はあるけど一歩踏み出せていない人
• クラウド構成やDockerがなんとなく不安な人
• 生活の中の「めんどくさい」を自作で解決したい人

これからゆるゆると頑張っていきます！