ノーコード ラボ

NoCode 関連のツールの紹介、使い方などをやさしく説明しています。

トップ > Bubble > BubbleアプリをClaude CodeやCodexから扱える？Buildprint.aiで変わるBubble開発の未来

BubbleアプリをClaude CodeやCodexから扱える？Buildprint.aiで変わるBubble開発の未来

Bubble Buildprint Claude Code AI MCP

1. はじめに

最近、Claude Code や Codex のようなAI開発ツールが一気に身近になってきました。

コードを書く開発者の間では、AIにプロジェクト全体を読ませて、調査してもらったり、修正案を出してもらったり、実際にコードを書いてもらったりする使い方がかなり広がっています。

一方で、Bubble のようなノーコード開発をしている方にとっては、

「Claude Code や Codex は便利そうだけど、Bubble には関係ないのでは？」

と感じる方も多いかもしれません。

ただ、最近はその状況が少し変わってきています。

Bubbleアプリの構造や設定情報をAIが扱いやすい形にして、Claude Code、Codex、Cursor、ChatGPT などのAIツールから参照できるようにするサービスが登場しています。

その代表例のひとつが、今回ご紹介する Buildprint.ai です。

Buildprint.aiを使うと、Bubbleアプリの情報をAIに読ませて、アプリの理解、Workflowの調査、エラー原因の分析、ドキュメント作成、改修方針の検討などに活用できる可能性があります。

この記事では、Buildprint.aiとは何か、Bubble利用者にとって何が嬉しいのか、そしてClaude CodeやCodexと組み合わせるとどのような使い方ができそうかを整理してみます。

2. Buildprint.aiとは？

Buildprint.ai は、Bubbleアプリの情報をAIツールから扱いやすくするためのサービスです。

ざっくり言うと、Bubbleアプリの構造やログ、Workflow、データベース情報などを、AIが理解しやすい形で参照できるようにする仕組みです。

Bubbleアプリには、たとえば次のような情報があります。

  • Data types
  • Fields
  • Option sets
  • Pages
  • Elements
  • Workflows
  • Backend workflows
  • Privacy rules
  • API連携
  • Plugin設定
  • Logs

Bubbleのエディタ上では、これらの情報はそれぞれ別々の画面や設定の中に存在しています。

小さなアプリであれば人間が見ても十分追えますが、アプリが大きくなってくると、

  • どのページにどんな処理があるのか
  • どのWorkflowがどのData typeを更新しているのか
  • あるフィールドがどこで使われているのか
  • Privacy rules がどの処理に影響しているのか
  • エラーの原因になっていそうなWorkflowはどれか
  • 既存機能を修正すると、どこに影響が出そうか

といったことを把握するだけでも、かなり時間がかかります。

Buildprint.aiは、こうしたBubbleアプリの情報をAIツールから参照しやすくすることで、AIに対して次のような相談をしやすくしてくれます。

このBubbleアプリの主要なData typeを整理してください。

このWorkflowが何をしているか説明してください。

このエラーが発生した原因として考えられる箇所を調査してください。

この機能を改修する場合、影響がありそうな箇所を洗い出してください。

このアプリの仕様書を作るために、ページ構成と主要機能をまとめてください。

つまり、Buildprint.aiは「Bubbleで作ったアプリを、AIに理解させるための橋渡し役」と考えるとわかりやすいと思います。

Buildprint.aiを使うルートは、大きく2つあります。1つはClaude CodeやCodex、CursorなどからMCP経由で接続する方法、もう1つはBuildprint.aiのサイト上で動くチャットUIを使う方法です。どちらからでも、Bubbleアプリの調査・参照、そしてアプリ構成（Data type / Workflow / UI など）の編集まで行えます。違いは作業する場所とUIだけなので、普段の開発環境に合わせて選べば大丈夫です。

3. はじめてみる：セットアップの流れ

実際にBuildprint.aiを使ってみるには、Bubbleアプリと接続する必要があります。手順はざっくり次のとおりです。

3.1 Bubble アプリを登録する

Buildprint.aiのダッシュボードで、対象のBubbleアプリ名と App ID を入力します。

Step 1: Bubble アプリの接続

3.2 Buildprint をコラボレーターとして招待する

connect@getbuildprints.com を Bubble エディタの Settings → Collaboration に招待し、必要な権限を付与します。

Step 2: Buildprint をコラボレーターとして招待

Buildprint 側に、Bubble の Settings → Collaboration に追加してほしいメールアドレスとその手順が表示される。

Bubble 側で招待されたコラボレーターを確認

Bubble エディタの Settings → Collaboration を開くと、招待した Buildprint と自分のアカウントがコラボレーターとして並んでいる。

招待が完了すると、Buildprint 側で接続成功の表示が出ます。

接続成功

Buildprint 側に「Buildprint is connected」と表示されれば、コラボレーター招待は成功。

3.3 所有権を検証する

第三者がアプリを勝手に登録できないよう、所有権の検証ステップがあります。Buildprint が表示する meta タグを Bubble の Settings → SEO に貼り付け、Verify ownership を押します。

Step 3: 所有権検証用の meta タグを取得

Buildprint が <meta name="buildprint-verification" ...> の形で検証用タグを発行する。

Bubble 側の SEO 設定に meta タグを貼り付け

貼り付け先は Bubble の Settings → SEO and metatags → Script/meta tags in header。test version 側で OK。

3.4 ログの観測（任意）

詳細ログの観測機能は今のところウェイトリスト制になっています。最初は Skip で問題ありません。

Step 4: Observability 設定（任意）

詳細ログのウェイトリスト案内。今は Skip で先に進める。

3.5 Claude Code などから MCP 経由でつなぐ

最後に、Claude Code や Codex 側に MCP server として Buildprint を登録します。Buildprint のダッシュボードに接続用の URL が表示されているので、それを Claude Code の MCP 設定に追加するだけです。

Buildprint の MCP server 接続設定画面

Buildprint 側で MCP server 接続用の URL（トークン込み）が表示されるので、これを Claude Code 側の MCP 設定に貼り付ける。

これで、Claude Code から Bubble アプリの構造やデータを参照できるようになります。

4. なぜBubbleとAIツールの連携が重要なのか

Bubbleは、非常に強力なノーコード開発ツールです。

画面、データベース、Workflow、API連携、ユーザー管理などを組み合わせて、コードを書かずにWebアプリを作ることができます。

一方で、Bubbleアプリが大きくなるほど、次のような課題も出てきます。

4.1 アプリの全体像が見えにくくなる

Bubbleは画面上で直感的に作れる反面、アプリ全体の構造を一覧で把握するのが得意とは言えません。

Data type、Workflow、Reusable element、Backend workflow、Privacy rules などが増えてくると、どこで何をしているのかを追うだけでも大変です。

特に、他の人が作ったアプリを引き継いだ場合は、最初の調査だけで多くの時間がかかります。

4.2 Workflowが複雑化しやすい

Bubbleでは、ボタンを押したとき、ページを読み込んだとき、条件を満たしたときなど、さまざまなタイミングでWorkflowを実行できます。

これは便利ですが、アプリが成長すると、似たようなWorkflowが増えたり、条件分岐が複雑になったりしがちです。

「この処理、どこで実行されているんだっけ？」

「このData typeは、どのWorkflowで更新されているんだっけ？」

という調査に時間がかかることは、Bubble開発者なら一度は経験があるのではないでしょうか。

4.3 仕様書が後追いになりやすい

Bubbleは開発スピードが速いぶん、仕様書や設計書が開発に追いつかないことがあります。

とくに、スタートアップ的に素早く作ったアプリや、保守フェーズに入った古いアプリでは、

  • 最新の仕様書がない
  • 画面仕様が古い
  • Workflowの意図がわからない
  • データ構造の説明が残っていない

ということも珍しくありません。

このような状況でAIがアプリ構造を読み取り、仕様書のたたき台を作ってくれるなら、かなり大きな助けになります。

5. Buildprint.aiでできそうなこと

ここからは、Buildprint.aiを使うことで、Bubble開発の現場でどのようなことができそうかを見ていきます。

5.1 Bubbleアプリの構造をAIに説明してもらう

一番わかりやすい使い方は、Bubbleアプリの全体像をAIに説明してもらうことです。

たとえば、Claude Code や Codex に対して、次のように質問できます。

このBubbleアプリの構造をざっくり説明してください。

主要なData typeと、それぞれの役割を整理してください。

このアプリにはどのようなページがありますか？

ユーザー登録からログイン後の主要な流れを説明してください。

これだけでも、既存アプリの調査ではかなり便利です。

特に、他の人が作ったアプリを引き継ぐときには、最初にAIへ全体像を説明してもらうことで、調査の取っかかりを作ることができます。

実際にClaude Codeで質問してみると、AIが Bubble MCP 経由でデータ型やデータを取得し、要約してくれます。下のスクリーンショットは、この記事内で作る検証用アプリ kensho に対して「kenshoアプリの構造とデータを教えて」と質問したときの様子です。

質問プロンプト

Claude Code に「kenshoアプリの構造とデータを教えて」と尋ねるシンプルな質問。

AIの回答（Data type 一覧と Project / Task のレコード）

AI が Bubble MCP 経由で Data type を取得し、Project / Task の構造とレコードを表形式で要約してくれる。

AIの回答（index ページの UI 構造と Workflow）

続けて index ページの要素ツリーを ASCII 図で描き、ボタンクリック時の Workflow 動作も解説してくれる。

5.2 Workflowの内容を読み解く

Bubble開発で特に時間がかかるのが、Workflowの読解です。

Buildprint.aiによってWorkflow情報をAIが参照できるようになると、たとえば次のような質問ができます。

このボタンを押したときに実行されるWorkflowを説明してください。

このWorkflowでは、どのData typeが作成・更新されていますか？

このWorkflowでエラーが起きそうなポイントはありますか？

このWorkflowをもっとシンプルにするなら、どのような整理が考えられますか？

もちろん、AIの回答をそのまま鵜呑みにするのは危険です。

しかし、複雑なWorkflowを読むときに、最初の要約をAIに出してもらえるだけでも、人間の調査スピードはかなり上がります。

5.3 影響範囲を調査する

既存アプリを改修するときに怖いのが、思わぬところに影響が出ることです。

たとえば、あるData typeのフィールドを変更したい場合、次のようなことを確認する必要があります。

  • そのフィールドはどのページで表示されているか
  • どのWorkflowで作成・更新されているか
  • 検索条件に使われていないか
  • Privacy rules に関係していないか
  • API連携で使われていないか

人間がすべて手作業で確認するのは大変です。

そこでAIに、

User type の company フィールドを変更する場合、影響がありそうな箇所を洗い出してください。

このData typeを削除する前に確認すべきWorkflowを一覧にしてください。

このOption setが使われている画面や処理を整理してください。

のように依頼できると、改修前の調査がかなり楽になります。

5.4 仕様書やドキュメントのたたき台を作る

Buildprint.aiの活用で個人的にかなり期待しているのが、ドキュメント作成です。

Bubbleアプリの情報をAIに読ませることで、たとえば次のような資料のたたき台を作れる可能性があります。

  • アプリ概要
  • 画面一覧
  • 主要機能一覧
  • Data type一覧
  • Workflow一覧
  • API連携一覧
  • 管理者向け操作マニュアル
  • 保守担当者向けの技術メモ

特に保守案件では、「仕様書がない」「過去の経緯がわからない」という状況がよくあります。

そのような場合に、AIでまずドキュメントの初稿を作り、人間が確認・修正していく流れはかなり実用的だと思います。

5.5 Bubble学習にも使える

Buildprint.aiは、初心者や中級者の学習にも使えそうです。

たとえば、自分で作ったBubbleアプリをAIに見てもらい、

このWorkflowの作り方で気になる点はありますか？

このData type設計は適切ですか？

Privacy rulesで注意すべき点はありますか？

パフォーマンス面で改善できそうなところはありますか？

と質問することで、自分のアプリを教材にして学ぶことができます。

Bubbleは実際に作りながら学ぶツールなので、自分の実装に対してAIからフィードバックをもらえるのは、とても相性が良いと思います。

5.6 アプリ構成の編集まで任せる

Buildprint.aiは、調査・説明だけではなく、Bubbleアプリの構成変更そのものもAIに任せられます。

たとえば、Claude CodeやCodexからMCP経由で deploy_agent というツールを呼び出すと、Buildprint側のリモートエージェントが起動し、Bubbleアプリの編集と反映を自動で進めてくれます。

実際に検証用のkenshoアプリで、次のような指示を出してみました。

kenshoアプリにシンプルなToDoの構造を作ってください。Project と Task の Data type、Create Task の Workflow、index ページの UI を含めてください。

10〜20分ほどで、Data type 2つ（ProjectとTask）、Workflow 1つ、indexページのUI（入力欄・ボタン・RepeatingGroup）が作成され、Bubbleへ反映されました。Claude Code側はステータスを監視しているだけで、実作業はBuildprint側のエージェントが行います。

反映後、Bubbleエディタの Data タブを見ると、Project と Task が追加されているのが確認できます。

Bubble エディタの Data タブ。Buildprint エージェントが作成した Project と Task が並んでいる。

Buildprint.ai上のチャットでも同じことが可能で、Plan modeで方針を相談しBuild modeに切り替えることで反映できます。検証用のBubbleアプリで試したところ、BP_Test_Item というData typeの新規作成、title / memo fieldの追加・削除、Data type自体の削除まで、すべてチャットからの指示でBubbleに反映できました。

ただし、いずれの方法でも、AIが意図と違う変更を入れる可能性は当然あります。反映後は必ずBubbleエディタで確認し、必要に応じてバージョンを戻せるようにしておくのが安全です。

6. Claude CodeやCodexとつなぐと何が嬉しいのか

ここで改めて、なぜClaude CodeやCodexのようなAI開発ツールとBubbleをつなぐ意味があるのかを考えてみます。

ポイントは、AI開発ツールが単に「コードを書くためのもの」ではなくなってきていることです。

最近のAI開発ツールは、コードを書く以外にも、

  • プロジェクト全体を読む
  • ファイルを横断して調査する
  • 仕様を整理する
  • バグの原因を推測する
  • 修正方針を提案する
  • テスト観点を作る
  • ドキュメントを作る

といった作業が得意になっています。

Bubbleはコードではありませんが、アプリの構造情報さえAIに渡せれば、これらに近いことができる可能性があります。

つまり、Buildprint.aiのようなサービスによって、BubbleアプリもAIエージェント的な開発支援の対象になりつつあります。

これは、Bubble開発にとってかなり大きな変化だと思います。

7. 「データも作ってほしい」と思ったときの注意点

Buildprint.aiについて調べていて、少し混乱しやすいのが「データベースを扱える」という表現です。

ここでいうデータベースには、少なくとも2つの意味があります。

ひとつは、Data typeやfieldのような、アプリの設計・構造としてのデータベースです。

もうひとつは、実際に保存されているレコード、つまりBubbleでいうThingsです。

Buildprint.ai（MCP経由でもチャットUIでも）では、Workflowの作成、fieldの更新、設定変更など、Bubbleアプリの構成に関わる変更が可能です。今回の検証では、Data typeの新規作成、fieldの追加・削除、Data type自体の削除も実行できることを確認できました。

一方で、Bubbleデータベース内の実データ、つまりThingsの作成・更新・削除については、Buildprint.ai単体ではできません。

これは不便に見えるかもしれませんが、AIが誤って本番データを書き換えてしまうリスクを考えると、安全側に倒した設計とも言えます。

ただし、実務では「AIからテストデータを作りたい」「マスターデータを登録したい」「問い合わせデータを作成したい」というケースもあると思います。

その場合は、Bubble側で別途、データ作成・更新の入口を用意することはできます。

たとえば、次のような方法です。

  • Data API を有効にする
  • Backend Workflow を作成する
  • API Connector 経由で安全な中継APIを用意する
  • Cloudflare Workers / Hono / Next.js API Routes などでプロキシを作る

実際に検証してみたところ、Bubble側でData APIを有効にし、API tokenを発行したうえで、Claude Codeに curl を叩かせることで、ProjectとTaskのレコードを5件以上、テストデータとして一括作成できました。具体的には次のような流れです。

Settings → API → Enable Data API のチェックと、対象 Data type の公開設定

Bubble の Settings → API。「Enable Data API」を ON にし、公開したい Data type だけ個別にチェックを入れる。User は通常チェックしないでおく。

  1. Bubbleエディタの Settings → API で「Enable Data API」をオンにし、対象のData type（ProjectとTask）をAPIに公開
  2. 「Generate a new API token」で一時的なトークンを発行
  3. Claude Codeから https://<app-id>.bubbleapps.io/version-test/api/1.1/obj/<type-name> に対して POST してもらい、レコードを作成
  4. 作業完了後、不要になったAPI tokenはBubbleエディタからrevoke

このように「読むのはBuildprint MCP、書き込みはBubble側のData API」という組み合わせで使うと、検証用アプリにテストデータを一括投入するような場面では十分実用的です。重要なのは、書き込み用の入口（今回はData API）をBubble側で明示的に開ける／閉める形にしておく点です。

ただし、ここはかなり慎重に設計した方がよいです。

特にData APIを有効にする場合は、対象のData type、公開範囲、Privacy rules、API tokenの管理、誤更新・誤削除時の復旧方法を事前に確認しておく必要があります。

個人的には、AIツールに強い権限をそのまま渡すより、Backend Workflowなどで「AIが実行してよい操作」を限定する方が安全だと思います。

たとえば、AIにBubbleのData APIを自由に触らせるのではなく、

  • 問い合わせレコードを1件作成する
  • 開発環境にテストデータだけを作成する
  • 指定されたステータスだけを更新する
  • 管理者が確認したデータだけを登録する

のように、用途を限定したAPIを用意するイメージです。

つまり、Buildprint.aiはBubbleアプリの構造理解やアプリ側の変更には便利ですが、実データの操作については、Bubble側で別途安全な入口を設計する必要があります。

最初は、読み取り・調査・説明・ドキュメント化から使い始め、データ作成や更新まで任せる場合は、開発環境やテストデータに限定して小さく試すのがよいと思います。

AIにデータ操作を任せる場合は、「AIに何でもできる権限を渡す」のではなく、「AIが実行してよい操作だけをAPIとして用意する」くらいの考え方が安全です。

8. 実務での活用イメージ

ここでは、実際のBubble開発現場でどのように使えそうか、いくつかのシーンを考えてみます。

8.1 既存アプリの引き継ぎ

他社や前任者が作ったBubbleアプリを引き継ぐ場合、最初に大変なのは全体像の把握です。

Buildprint.aiを使ってAIにアプリ構造を読ませ、

  • アプリの概要
  • 主要ページ
  • Data type一覧
  • 重要なWorkflow
  • 外部API連携
  • 注意が必要そうな設定

を整理してもらうことで、初期調査の時間を短縮できる可能性があります。

8.2 保守・改修前の調査

小さな改修に見えても、既存アプリでは影響範囲が広いことがあります。

たとえば、管理画面の項目を1つ追加するだけでも、Data type、画面表示、検索条件、Backend workflow、CSV出力、API連携などに影響することがあります。

そのようなときに、AIへ影響範囲の洗い出しを依頼できると、調査漏れを減らせる可能性があります。

8.3 ドキュメント作成

保守案件では、ドキュメント作成が後回しになりがちです。

Buildprint.aiを使ってAIに情報を渡し、仕様書や保守メモのたたき台を作ることで、ドキュメント整備のハードルを下げられます。

特に、クライアント向けに「現在のアプリ構成を整理した資料」を作るような場面では、かなり役に立ちそうです。

8.4 コード移行・リプレイス前の棚卸し

Bubbleアプリを将来的にNext.jsなどのコードベースに移行したい場合、まず必要なのは現状把握です。

どの機能があるのか、どのData typeが使われているのか、どのWorkflowが重要なのかを整理しないまま移行を始めると、抜け漏れが発生しやすくなります。

Buildprint.aiを使ってアプリ構造を整理しておくことで、移行計画や見積もりの精度を上げられる可能性があります。

9. 注意点：AIに任せきりにはしない

ここまでBuildprint.aiの可能性について書いてきましたが、注意点もあります。

9.1 AIの回答は必ず確認する

AIは非常に便利ですが、常に正しいとは限りません。

Bubbleの仕様を誤解したり、実際には存在しない影響範囲を推測したり、逆に重要な箇所を見落としたりする可能性があります。

そのため、AIの回答はあくまで「調査の補助」や「たたき台」として扱い、最終判断は人間が行うべきです。

9.2 本番環境での利用は慎重に

AIツールを使って調査や提案を行う場合でも、本番環境に直接変更を加えるような運用は避けた方が安全です。

まずは開発環境やコピーした環境で試し、影響範囲を確認したうえで本番反映するのが基本です。

9.3 機密情報・個人情報の扱いに注意する

Bubbleアプリには、顧客情報、ユーザー情報、業務データ、APIキー、外部サービスの設定など、機密性の高い情報が含まれている場合があります。

Buildprint.aiやAIツールを利用する際には、どの情報が外部サービスに渡るのか、社内ルールや顧客との契約上問題がないかを確認しておく必要があります。

特に受託開発や保守案件では、事前にクライアントへAI利用方針を説明しておくと安心です。

9.4 最終反映は人間が管理する

Buildprint.ai（MCP経由でもチャットUIでも）でアプリ構成の変更ができるとしても、その結果をどう確認し、いつ本番環境へ反映するかは人間が管理すべきです。

AIに変更してもらった内容は、必ずBubbleエディタ上で確認し、必要に応じてテストしてから反映するのが安全です。

10. どんな人に向いているか

Buildprint.aiは、特に次のような方に向いていそうです。

  • Bubbleアプリの保守をしている方
  • 他の人が作ったBubbleアプリを引き継ぐ方
  • Bubbleアプリの仕様書を作りたい方
  • Workflowが複雑になって困っている方
  • Claude CodeやCodexをBubble開発にも活用したい方
  • 将来的にBubbleアプリのリプレイスやコード移行を考えている方
  • 受託開発で調査・改修の効率を上げたい方

逆に、まだとても小さなBubbleアプリを作っている段階であれば、最初から必須というわけではないかもしれません。

ただし、アプリが大きくなるほど、構造の整理やドキュメント化の価値は高まります。

その意味では、Buildprint.aiは「Bubbleアプリが複雑になってきたタイミング」で特に力を発揮しそうです。

11. まとめ

Claude CodeやCodexのようなAI開発ツールは、これまで主にコードを書く開発者向けのものと思われてきました。

しかし、Buildprint.aiのようなサービスが登場したことで、BubbleのようなノーコードアプリもAIツールから扱いやすくなりつつあります。

特に重要なのは、

AIでBubbleアプリを作る

というよりも、

すでにあるBubbleアプリをAIに理解させる

という考え方です。

Bubbleアプリは、作り始めはとても速く開発できます。

一方で、アプリが大きくなるほど、Workflow、Data type、Privacy rules、API連携などが複雑になり、全体像の把握が難しくなります。

Buildprint.aiを使って、Bubbleアプリの情報をClaude CodeやCodexから参照できるようになれば、次のような作業を効率化できる可能性があります。

  • 既存アプリの理解
  • Workflowの読解
  • 影響範囲調査
  • 仕様書作成
  • 保守メモ作成
  • 改修方針の検討
  • コード移行前の棚卸し
  • アプリ構成の編集（Data type・Workflow・UI）

さらに、Buildprint.ai上のチャットの Build mode だけでなく、Claude CodeやCodexからのMCP経由でも、deploy_agent というツールを使うことで、Data typeの作成・削除、Workflowの新規作成、ページUIの構築まで任せられることが確認できました。

MCP経由とBuildprint.ai上のチャットでは、UIや使い勝手は違いますが、できる範囲はかなり近づいてきました。普段の作業環境に合わせて、コード開発と一緒にBubbleも触りたければMCP経由、ブラウザで完結させたければチャット、という選び方でよさそうです。

また、実データの作成・更新までAIに任せたい場合は、Data APIやBackend Workflowなどを使って別途安全な入口を設計する必要があります。

AIに何でもできる権限を渡すのではなく、AIが実行してよい操作だけを限定して用意する、という考え方が大切です。

BubbleはノーコードだからAI開発ツールとは関係ない、という時代ではなくなってきました。

むしろ、アプリ構造が画面の中に分散しやすいBubbleだからこそ、AIに構造を読ませる価値は大きいのではないでしょうか。

Buildprint.aiは、Bubble開発をAIエージェント時代につなぐサービスとして、今後注目していきたいツールのひとつです。