BoltでSupabaseを使うときの基本

BoltからSupabaseを使うときは、先に「Supabaseを使う理由」と「どのデータを誰に見せるか」を決めます。既存のSupabase projectを引き継ぐ、database設定を自分で管理する、既存資産と同じbackendへつなぐなどの理由があるなら候補になります。新しい小規模試作でその理由がなければ、Bolt Cloudのdatabase機能だけで足りる場合もあります。接続が成功しても、安全なdatabase設計が完成したとは限りません。

この作業で完了したいのは、画面からデータが読み書きできることだけではなく、認証・権限・失敗時の扱いを通じて、意図した利用者だけが必要な行へアクセスできる状態です。特に既存Supabaseをつなぐ場合、AIの指示でprojectやschemaを変える前に、対象環境・データ・復旧手段を確認します。

Supabaseを選ぶ理由を短く言えるか

Boltは独自のBolt Cloudを通じてdatabase、hosting、domainなどを扱え、新しいprojectは通常Bolt databaseから始まります。公式案内ではSupabase連携はPro・Teams planで利用でき、後から切り替える場合は追加の手順が必要とされています。したがって、「AIアプリならSupabaseが必要」とは言えません。現在の契約と画面に表示される条件は接続前に確認してください。利用するbackendを選ぶ前に、必要な運用条件を整理します。

表は横にスクロールできます

要件	Bolt Cloudから始める選択が合いやすい	Supabaseを選ぶ理由になりやすい
既存資産	新しく短い試作品を始める	すでにSupabaseのprojectやtableがある
database運用	Bolt内の機能で足りる	Supabase側でschema・policy・運用を管理したい
周辺システム	特定の接続先がない	別サービスや既存アプリが同じdatabaseを使う
権限設計	小さく検証してから要件を決める	現行のrole・policy設計を引き継ぐ必要がある
移行負担	新規データで始める	既存データを保ったまま接続条件を設計できる

これは製品の優劣表ではありません。現在の設定・契約・project状態で提供範囲が変わり得るため、接続前に公式画面とアカウントの表示を確認します。特に本番projectを接続する場合、試作用projectと同じ感覚でschemaを変更しないでください。

接続前の確認票

接続操作を始める前に、次を埋めます。分からない項目が残る場合は、最初から本番データを使わず、検証用environmentへ戻します。

表は横にスクロールできます

確認項目	記録する値・判断	未確認なら起き得ること
Project identity	project名・識別子・検証/本番の区別	別環境へ接続・変更する
Data owner	databaseを管理する人・team	policy変更の承認者が曖昧になる
Existing schema	table、既存app、migrationの有無	agentが既存構造を置き換える
Data sensitivity	個人情報・機密情報・公開情報	不要なdataをAIやbrowserへ渡す
Access roles	anonymous、signed-in、adminの区分	認証を認可と取り違える
Recovery	backup、migration、restore手段	変更失敗後に戻せない
Test account	権限が異なる2つ以上の利用者	他ユーザーへの漏れを試せない

「接続ボタンを押してよいか」だけではなく、接続後に何を変えてよいかも境界を作ります。たとえば「新しい試作用tableの追加は可、既存tableの削除・renameは不可」「本番の既存rowを変更せず、test userのデータのみで確認する」と明記します。これは操作を止めるための文言ではなく、AIが仕様の空白を勝手な判断で埋める範囲を狭めるためです。

画面より先にデータと所有者を定義する

画面を作ってからdatabaseを合わせると、後でfieldや権限を大きく直すことがあります。先に、保存するもの、作成する人、読める人、更新できる人、消せる人を一つずつ書きます。

たとえばユーザー別のメモ機能では、notes tableにid、owner_id、title、body、created_atを持たせる案が考えられます。ただしこれは記事内の設計例であり、現在のProjectにこのschemaをそのまま作る指示ではありません。既存のBolt CloudやSupabase projectに適用するときは、実際のSDK、migration、既存table、法務要件に合わせて調整します。

最低限、権限をデータ操作別に分けてください。

表は横にスクロールできます

操作	利用者Aの自分の行	利用者Aの他人の行	未ログイン
SELECT	必要なら許可	原則拒否	公開情報だけ許可
INSERT	ownerがAになる条件で許可	owner偽装を拒否	private dataは拒否
UPDATE	A所有の行だけ	拒否	拒否
DELETE	A所有の行だけ	拒否	拒否

「原則拒否」とした箇所は、製品の用途で公開データが必要なら明示的なルールに置き換えます。SupabaseのRow Level Securityは、table単位のpolicyだけでなく、公開APIで操作可能にするgrantとの組み合わせで評価します。UI上でボタンを隠すだけでは、直接APIへアクセスした場合の保護になりません。ルールを作った後に、roleごとのtestで読み書きできる範囲を確かめます。

まずは使ってみる

記事の文脈に合うToolへ進めます。報酬の有無で見た目は変えていません。

• 

  Bolt.new

  公式サイトを見るTool詳細を見る

認証と認可は別の確認

ログイン画面が表示され、userが認証できることは「誰かを識別できた」という確認です。そのuserがどのrecordへアクセスできるかは認可です。両者を混ぜると、画面で他人の行を隠しているだけの設計を「安全」と判断してしまいます。

実際の確認は、最低でもuser A・user B・未ログインの三者を用意し、同じdatasetに対して試します。Aで作成した行をAから読み書きできる、Bからは読めない、URLやidを差し替えてもBから変更・削除できない、未ログインではprivate rowを取得できない、という各条件を個別に確認します。もしアプリ全体が公開データを扱うなら、公開SELECTをどのtableに許すかを決め、書き込み権限と分けます。

テスト結果は「ログインできた」の一行で済ませず、role、操作、期待、実際の結果を記録します。失敗した場合は、まず対象table、requestの認証状態、実際に使われたrole、policy、grantを分けて調べます。画面の例外だけでは、権限拒否と通信障害は見分けられません。

keyとsecretは配置場所で役割が変わる

公開frontendに含まれてもよいpublishable keyと、管理権限を持つsecret keyは同じ扱いにできません。Supabaseの現在の案内では、publishable keyは公開clientで使う前提のkeyですが、それだけでdatabaseへのアクセスが安全になるわけではなく、tableのRLSや権限設定が必要です。一方、secret keyはserver-sideで扱い、公開clientへ置かないでください。古い形式のanonやservice_roleを使う既存projectでは、権限の意味を現在のproject設定と公式説明で確認します。

表は横にスクロールできます

値の種類	置く場所の考え方	チェック
Project URL	公開コードで使う構成がある	接続先projectが検証用か本番か
Publishable key	client側で使う場合がある	RLS・grant・table公開条件
Secret key	server-sideの機密設定	bundleやbrowser responseへ含まれない
外部API credential	server-side function等	request/responseやlogへ露出しない

Boltのsecrets機能やserver functionsを使う場合も、保存しただけで実行経路が自動的に安全になるわけではありません。secretをどのfunctionが読み、どの操作を許し、browserへ何を返すのかを確認します。keyをprompt本文、ソースファイル、公開環境変数、console logへ置かないこと。生成されたdiffやbuild outputに値が含まれていないかも見直します。

接続後の確認は読み書きと失敗経路を分ける

接続後は、代表データを一件だけ使い、画面からのread/writeを確認します。そのあと異常条件を試します。以下の表は実データを壊さないようにtest環境で使うための例です。

表は横にスクロールできます

テスト	操作	合格条件
正常作成	user Aで新規rowを作成	ownerが認証user Aと一致
自分の読取	Aで一覧・詳細を表示	Aのrowが必要な範囲で表示
他人の読取	BでAのrowを指定	許可されない、内容は返らない
owner偽装	Aがowner_idをBへ変えて送信	DB側の条件が拒否・補正する
更新境界	A/Bで同じIDをupdate	Aだけ許可され、Bは変更不可
未ログイン	protected endpointを直接呼ぶ	private dataが返らない
通信失敗	存在しない接続・停止時を想定	retry案内とdata重複の扱いが分かる

認証後に画面上でデータが見えたという一つの成功だけで、他の操作をPASSにしません。各CRUD操作とroleを分離します。失敗経路では、二重送信で重複rowができないか、途中でtimeoutしたときに再試行が安全か、エラー本文にsecretや生のdatabase情報が出ないかも確認します。

変更を戻せる状態で試す

Boltの既存databaseをSupabaseへ接続したり、schemaを変えたりする場合は、接続先と影響を確認し、変更前の復旧手段を用意します。AIからの提案をそのまま受け入れず、SQL、migration、drop・replaceの記述、対象projectを読んでから適用します。すでに本番利用中のデータなら、バックアップを取るだけでなく、復元テストや切り戻し手順も必要です。

設定変更の順序は、検証用project → 少数の架空データ → role別test → schema差分のreview → 本番へ適用する判断、とします。production databaseを開いた状態でAIへ「つないで全部直して」と依頼しないこと。対象が分からない、既存データを消す可能性がある、rollback方法が説明できない場合は、そこで作業を止めて確認します。

AIものさしの判断

BoltとSupabaseを組み合わせる判断は、database名や人気ではなく、既存資産、アクセス境界、運用の責任者から行います。新規試作ならBolt Cloudだけで足りる可能性を先に確認し、Supabaseを選ぶなら、接続先と既存schemaを守る条件を決めます。認証、RLS、grant、keyの配置を別々に確認し、各roleで直接requestを試すまで、データ機能を完成と扱いません。

次に行うことは、接続前確認票を埋め、試作用environmentとA/Bのtest accountを用意することです。既存Supabaseを使う理由が説明できない場合、先にBolt Cloudの現在の機能とproject条件を確認します。逆に既存資産を使う理由がある場合も、初回の接続範囲を限定し、データを保持できるかを公式手順と現行画面で確認してください。