Supabaseとは何か。オープンソースのBaaSという立ち位置を整理する
BaaSはバックエンドの何を肩代わりしてくれるのか
室谷代表取締役Supabaseの話をすると必ず「で、何なの？」となるんですけど、ひと言でいうとサーバー側のコードを書かずにバックエンドを用意できるサービスなんですよ。BaaSと呼ばれてるやつで。
テキトー教師DotAI 認定講師たしかに。初めて触る人は「データベースだけのサービス？」って受け取る人が多いんですよね。
実際は認証もストレージもリアルタイムも、まとめて付いてくるイメージです。
実際は認証もストレージもリアルタイムも、まとめて付いてくるイメージです。
室谷代表取締役そう、そこで毎回ゼロからAPIを書く工数が消える。MYUUU の現場だと、その手の配管コードにエンジニアが張り付いてる時間って正直もったいないんですよね。
テキトー教師DotAI 認定講師現場感覚で言うと、最初の一週間で「動くもの」まで行けるかどうかがその後を左右するので、そこが軽くなるのは大きいです。
中身はPostgresを中心にしたOSSの集合体
室谷代表取締役で、中身を見ると面白くて。各プロジェクトに専用のPostgresが割り当たってて、AuthもStorageもRealtimeも、全部そのPostgresの上に乗ってる構造なんですよ。
テキトー教師DotAI 認定講師ここ、最初に戸惑うのが「機能ごとに別のサービスを使ってるわけじゃない」って点なんですよね。管理画面のStudio、AuthのGoTrue、PostgREST、Realtime、Storage、Edge FunctionsのDeno。
それぞれOSSで、土台がPostgresで共通してる。
それぞれOSSで、土台がPostgresで共通してる。
室谷代表取締役だから自前でホストすることもできる。ベンダーに全部預けるか、CLIとDockerで自分たちの環境に置くかを選べるわけで、事業の規模によって判断が変わる部分なんですよね。
テキトー教師DotAI 認定講師なるほど。ロックインが気になる人にも説明しやすい構造ですね。
Firebaseの代替というより、Postgresを土台にした別物
室谷代表取締役よくFirebaseの代替って紹介されるんですけど、公式はそこは違うと言っていて。最大の違いはNoSQLじゃなくてPostgres、つまりリレーショナルDBだってことなんですよね。
テキトー教師DotAI 認定講師たしかに。Firestoreはドキュメント指向でスキーマレス、JOINができない。
Supabaseは外部キーもJOINも普通に書ける。ここを知らずに「同じもの」として入ると、データ設計の段階で手が止まる人が多いんですよ。
Supabaseは外部キーもJOINも普通に書ける。ここを知らずに「同じもの」として入ると、データ設計の段階で手が止まる人が多いんですよ。
室谷代表取締役業界的にも、最初のデータモデルをどっちで切るかで後の開発速度が変わるので、そこは軽く見ないほうがいい。プロダクトの伸び方によっては、JOINが書けるかどうかが効いてきますから。
テキトー教師DotAI 認定講師そうですね。「Firebaseの代わり」ではなく「Postgresを土台にした別物」として捉えたほうが、選ぶときも判断しやすいです。
Supabaseで何ができる？主要な機能をひとつずつ見ていく
Database：プロジェクトごとに専用のPostgresが割り当たる
室谷代表取締役まず土台の話からなんですけど、Supabaseってプロジェクトを作ると専用のPostgresが1個そのまま割り当たるんですよね。抽象化レイヤー越しじゃなくて、フル権限で触れる。
テキトー教師DotAI 認定講師そこが最初に戸惑うところで。「マネージドなのに生のSQLを書いていいんですか」って身構える人が多いんですよ。
Table Editorで画面から、SQL Editorで直接SQLから、同じテーブルを触れます。
Table Editorで画面から、SQL Editorで直接SQLから、同じテーブルを触れます。
室谷代表取締役なるほど。ORMの作法を覚え直さなくていいのは、Postgresの知識がそのまま資産になるってことですからね。
テキトー教師DotAI 認定講師そうなんです。逆に言うと、設計をさぼると普通にDB設計のツケが返ってくるので、そこは昔ながらのDBと一緒です。
Auth・Storage・RealtimeはPostgresとどうつながっているのか
室谷代表取締役Auth、Storage、Realtimeって別サービスっぽく見えるじゃないですか。ここが全部Postgresの上に乗ってる、というのがSupabaseの面白さで。
テキトー教師DotAI 認定講師AuthはJWTを発行して、それがそのままPostgresのRow Level Securityと連動します。ログイン方式はメール/パスワード、パスワードレス、OAuth、SMS、カスタムプロバイダと一通り揃ってます。
室谷代表取締役StorageもS3互換のオブジェクトストレージなんだけど、ファイルのメタデータはPostgresのテーブルに入る。だから他のデータと同じRLSポリシーで縛れるわけですよね。
テキトー教師DotAI 認定講師Realtimeも同じで、Postgresの変更をWebSocketで流すPostgres Changes、オンライン状態を同期するPresence、任意メッセージのBroadcast。DBの変更がそのまま画面に届く感覚です。
Edge FunctionsとAI&Vectorsで広がる使い道
室谷代表取締役サーバーレス関数はDeno上でTypeScript。エッジ側で動いて低レイテンシで、しかもPostgresに直接アクセスできる。
テキトー教師DotAI 認定講師ここ最近で相談が増えたのがAI系で。pgvectorで埋め込みを扱えるので、類似検索をDBの中だけで完結させられるんですよ。
室谷代表取締役別のベクトルDBを立てて同期の面倒を見る、みたいな構成を考えなくて済むのは、運用コストの話として素直に効きますね。
テキトー教師DotAI 認定講師現場感覚で言うと、ベクトル検索の結果と普通のテーブルを同じクエリでまとめて扱えるのが楽なんです。繋ぎ込みのコードを書かなくていいので。
pgvectorやpg_cronなど拡張を足して機能を増やせる
室谷代表取締役拡張が50以上入るって話、地味だけど効くんですよ。pgvectorしかりPostGISしかりpg_cronしかり。
テキトー教師DotAI 認定講師初めて触る人は「拡張を足す」って聞くと身構えるんですけど、Postgresの作法そのままなので、有効化すれば使えるという感覚です。
室谷代表取締役定期ジョブをpg_cron、メッセージキューをpgmqで、とDBに寄せていくと、別サービスを契約して繋ぐ手間が減る。MYUUUくらいの規模だと、その繋ぎ込みの保守の方が高くつくんですよね。
テキトー教師DotAI 認定講師ただ何でもDBに寄せると重くなるので、そこは規模を見て、というのは現場でもよく言います。
SupabaseとFirebaseは何が違う？選び方と乗り換えの判断基準
データモデルの違いはNoSQLかリレーショナルか
室谷代表取締役FirebaseとSupabaseって、よく「どっちが上か」みたいに語られるんですけど、比べてる軸がそもそも違うんですよね。Firestoreはドキュメント指向のNoSQL、SupabaseはPostgresのリレーショナル。
まずそこなんですよ。
まずそこなんですよ。
テキトー教師DotAI 認定講師たしかに。初めて触る人が最初に戸惑うのがまさにそこで、FirestoreはデータをJSONの塊で放り込む感覚、Postgresは表と外部キーで関係を決めてから入れる感覚なんですよね。
室谷代表取締役で、これが効くのが後から「この条件で絞って、あっちのテーブルと突き合わせて」みたいな要件が出てきたときで。FirestoreはJOINができない、Postgresは外部キーもインデックスもJOINも書ける。
設計の自由度がまるで違うんですよ。
設計の自由度がまるで違うんですよ。
テキトー教師DotAI 認定講師現場感覚で言うと、最初はNoSQLの方がラクなんです。スキーマを決めなくていいので。
ただ、業務要件が複雑になってきたあたりで「あ、これ集計できない」ってなる。そこが分かれ目ですね。
ただ、業務要件が複雑になってきたあたりで「あ、これ集計できない」ってなる。そこが分かれ目ですね。
料金体系・認証・ストレージ・セルフホスト可否を並べて比べる
室谷代表取締役じゃあ周辺機能を並べていきましょうか。認証・ストレージ・セルフホストの可否で、けっこう景色が変わります。
| 観点 | Firebase | Supabase |
|---|---|---|
| 料金モデル | ドキュメント読み書き単位の従量課金 | 階層型の固定プラン＋使用量上乗せ（APIリクエスト自体は非課金） |
| 認証 | 基本のログイン方式は無料、SAML/OIDCはIdentity Platformへのアップグレードが必要 | Pro/EnterpriseでSDKを変えずにSSO・SAML・OIDC |
| ストレージ | Cloud Storage基盤、Sparkプランは一部リージョンで5GB | S3互換、無料はファイル50MB・合計1GB、Pro/Teamはファイル500GBまで＋CDN・画像変換 |
| セルフホスト | 不可（Googleのマネージド） | コアがOSSでCLI/Dockerによる構築が可能 |
テキトー教師DotAI 認定講師この表で地味に刺さるのがセルフホストの行で。現場でよく聞くのは「社内ルール的にクラウドに置けないデータがある」というケースで、そこでFirebaseだと詰むんですよね。
室谷代表取締役あと従量課金か固定かに寄ってるかは経営判断に効きます。Firebaseは読み書きの回数で青天井に動くので、アクセスが跳ねたときに請求が読めない。
Supabaseは固定プラン＋上乗せで、APIリクエスト自体には課金されない。予算を立てる側からすると、この違いはかなりデカいんですよ。
Supabaseは固定プラン＋上乗せで、APIリクエスト自体には課金されない。予算を立てる側からすると、この違いはかなりデカいんですよ。
テキトー教師DotAI 認定講師そこは作ってる側だけだと見えにくいんですよね。動けばいい、で進んで、支払う側が毎月ヒヤヒヤする、と。
Firebaseから乗り換えるべきか、判断の基準はここ
室谷代表取締役乗り換えるかどうかの判断軸は、僕の中では2つなんですよ。JOINや複雑な検索が要件に入るか。
そしてGoogle基盤に寄せたいかどうか。
そしてGoogle基盤に寄せたいかどうか。
テキトー教師DotAI 認定講師前者は技術、後者は会社の都合ですね。
室谷代表取締役そう。BigQueryやCloud Functionsまで含めてGoogleで固めたいなら、Firebaseのままでいいんですよ。
逆に「データ同士の関係性が本質」で、集計や権限を細かくやりたいならPostgres側に寄せた方が後で楽になる。
逆に「データ同士の関係性が本質」で、集計や権限を細かくやりたいならPostgres側に寄せた方が後で楽になる。
テキトー教師DotAI 認定講師あと相談として多いのが、Firestoreのセキュリティルールが複雑になって「誰が何を見られるのか説明できない」という状態です。Postgres側はRLSで行単位まで制御を書けるので整理しやすい。
ただ書かないと逆に丸見えになるので、そこはセットで考える必要があります。
ただ書かないと逆に丸見えになるので、そこはセットで考える必要があります。
並行稼働でコピーしてから正規化する2段階の移行プロセス
室谷代表取締役移行の進め方も、公式がわりと現実的な手順を出してるんですよ。いきなり全部置き換えるんじゃなくて、2段階。
- 移行ツールで Firebase Auth → Supabase Auth、Firestore → Postgres テーブル、Cloud Storage → Supabase Storage のデータをコピーする
- 旧環境と新環境を並行稼働させ、書き込み先を確認しながら両方に反映する
- コピーしたJSONをPostgresのテーブルに正規化する（型を決めて外部キーを張る）
- テーブルを公開する前にRLSポリシーを書く
テキトー教師DotAI 認定講師この3番目が一番ハマる人多いんですよ。JSONをそのまま1カラムに放り込んで終わりにしちゃうと、せっかく移行したのにJOINができない。
正規化までやって初めて乗り換えた意味が出るんですよね。
正規化までやって初めて乗り換えた意味が出るんですよね。
室谷代表取締役そこは工数との勝負です。並行稼働の期間は二重でコストがかかるので、先に「いつまでに正規化まで終えるか」を決めておく。
ダラダラ並行にすると、たぶん永遠に終わらないんですよ。
ダラダラ並行にすると、たぶん永遠に終わらないんですよ。
テキトー教師DotAI 認定講師そうなんですよね。移行って技術の問題に見えて、実は段取りの問題ですから。
料金プランはどうなっている？無料プランでどこまで使えるのか
料金プラン別の提供内容
| 項目 | Free | Pro | Team |
|---|---|---|---|
| 月額 | $0 | $25〜 | $599〜 |
| 月間アクティブユーザー | 5万人 | 10万人 | Pro同等 |
| データベース | 500MB | 8GB | Pro同等 |
| エグレス | 5GB | 250GB | Pro同等 |
| プロジェクト数 | 2つまで | 1プロジェクト込み | Pro同等 |
| バックアップ | × | 7日 | 14日 |
| 1週間で一時停止 | ○ | × | × |
| SOC2/ISO27001準拠 | × | × | ○ |
| プロジェクト単位・読み取り専用の権限 | × | × | ○ |
無料プランで試作はどこまで行けるか
室谷代表取締役まず無料枠の話からいくと、APIリクエストは無制限なんですよ。月間アクティブユーザーが5万人まで、データベースが500MB、ファイルストレージが1GB、エグレスが5GB。
CPUは共有でRAMが500MBです。個人の試作なら素直に足ります。
CPUは共有でRAMが500MBです。個人の試作なら素直に足ります。
テキトー教師DotAI 認定講師初めて触る人がまず驚くのがそこなんですよね。「API無制限で本当に0円なんですか」と。
ただ共有リソースなので、重い処理を回すと体感は落ちます。期待値の調整は要ります。
ただ共有リソースなので、重い処理を回すと体感は落ちます。期待値の調整は要ります。
室谷代表取締役あとアクティブなプロジェクトが2つまで。検証用にいくつも立てる使い方だと、ここが先に詰まるんですよね。
テキトー教師DotAI 認定講師たしかに。1本作るだけなら2つで足りますけど、比べるために3つ目を立てたくなったタイミングで最初の壁に当たります。
1週間触らないと止まる、という現実
室谷代表取締役無料枠で見落とされやすいのが、1週間操作がないとプロジェクトが自動で一時停止する点なんですよ。週末に作って、しばらく触らずに戻ってきたら繋がらない、と。
テキトー教師DotAI 認定講師現場でよく聞くのは「放置してたら止まってました」という声です。データが消えるわけではないんですけど、止まってる間は繋がらないので初めての人はかなり慌てます。
室谷代表取締役逆に言えば、止まっても困らないうちは無料でいい。止まると困るなら、それはもう本番なんですよ。
月25ドルで止まらない状態が買えるなら、判断は一瞬なんですよね。
月25ドルで止まらない状態が買えるなら、判断は一瞬なんですよね。
ProとTeamの違い、コンピュートの広げ方
室谷代表取締役有料の線引きはこうなってます。
| プラン | 月額 | 主な内容 |
|---|---|---|
| Free | $0 | MAU 5万人、DB 500MB、エグレス5GB、1週間で一時停止 |
| Pro | $25〜 | 1プロジェクト込み、MAU 10万人、ディスク8GB、エグレス250GB、バックアップ7日 |
| Team | $599〜 | Pro＋SOC2/ISO27001準拠、プロジェクト単位・読み取り専用の権限、バックアップ14日 |
テキトー教師DotAI 認定講師ここで詰まりやすいのが、Proに入ってもコンピュートが自動で大きくなるわけじゃない点です。$10/月分の無料クレジットが付いて、Microが1つ分カバーされる形なんですよ。
室谷代表取締役そう。Microは$10で、そこから16XLの$3,730まで段階的に上げられる。
つまり固定費じゃなくて、負荷に応じて自分でダイヤルを回す設計なんですよ。ROIで見るなら、遅いせいで離脱が出てるなら上げる、出てないなら上げない。
それだけの話なんですよね。
つまり固定費じゃなくて、負荷に応じて自分でダイヤルを回す設計なんですよ。ROIで見るなら、遅いせいで離脱が出てるなら上げる、出てないなら上げない。
それだけの話なんですよね。
テキトー教師DotAI 認定講師Teamの$599は個人には縁がない数字ですけど、SOC2やISO27001の準拠が必要になる場面では、その数字の意味が変わってきます。
Enterpriseと独自ドメインの位置づけ
室谷代表取締役Enterpriseはカスタム価格で、専任のテクニカルアカウントマネージャー、アップタイムSLA、AWS PrivateLink、24時間365日のサポート、専用Slackチャンネルあたりが中身です。要は「人が付く」ことへの対価なんですよね。
テキトー教師DotAI 認定講師現場感覚で言うと、そこは技術の話というより社内稟議の話になりがちです。セキュリティ質問への回答が欲しい、障害時の連絡先が欲しい、という要件で選ばれる印象です。
室谷代表取締役あと独自ドメインはProとTeamでプロジェクトごとに月10ドルのアドオン。地味ですけど、本番でURLを自社ドメインにしたいなら避けて通れないので、最初から見込んでおいたほうがいいですよ。
Supabaseの使い始め方。アカウント作成からバックエンド構築までの流れ
Supabaseの使い始め方(アカウント作成からバックエンド構築まで)
- 01アカウント作成Supabaseの公式サイトでアカウントを作成する
- 02プロジェクト作成ダッシュボードから新規プロジェクトを作成。プロジェクトごとに専用のPostgresデータベースが割り当たる
- 03APIキーと接続情報を控える発行されたAPIキーと接続情報を控えておく
- 04フレームワークを接続するそのまま「フレームワークを接続する」へ進む
- 05バックエンドを組むデータベース、Auth、Storage、Realtime、Edge Functionsでバックエンドを構成する
- 06クライアントライブラリを接続JavaScriptのほかFlutter、Python、C#、Swift、Kotlinも用意されている
アカウントを作ってプロジェクトを立ち上げるまで
公式ドキュメントの導線はシンプルなので、この順番で追えば迷いません。
- Supabaseの公式サイトでアカウントを作成する
- ダッシュボードから新しいプロジェクトを作成する（プロジェクトごとに専用のPostgresデータベースが割り当たります）
- 発行されたAPIキーと接続情報を控えておく
- そのまま「フレームワークを接続する」へ進む
※画面名・ボタン名は更新されることがあるので、実際の操作は公式ドキュメントの表示に従ってください。
室谷代表取締役立ち上げ自体は本当に短いんですよ。プロジェクトを作った時点でPostgresが1つ丸ごと付いてくる感覚で、DB設計を後回しにしても試作が止まらない。
この初速が事業判断に効くんですよね。
この初速が事業判断に効くんですよね。
テキトー教師DotAI 認定講師初めて触る人が最初に戸惑うのが、プロジェクト名とリージョンとパスワードを同時に決めるところで。ここで一回手が止まるんですよ。
パスワードはDBに直結するものなので、忘れると後で面倒になります。
パスワードはDBに直結するものなので、忘れると後で面倒になります。
室谷代表取締役なるほど、そこは地味な落とし穴ですね。
テキトー教師DotAI 認定講師あと無料プランは1週間触らないとプロジェクトが一時停止するので、試しに作ったまま放置すると「消えた？」となりがちです。作りっぱなしには注意で。
テーブルはTable EditorとSQL Editorのどちらで作るのか
室谷代表取締役テーブル作成って、画面で作るのとSQLで書くのと両方あるんですけど、どっちから入るのがいいんですかね。
テキトー教師DotAI 認定講師最初の数個はTable Editorで作るのが分かりやすいです。列を足していく感覚で構造が見えるので。
ただ外部キーや制約が増えてくると、SQL Editorで一気に書いたほうが早いし、あとで差分も残せます。
ただ外部キーや制約が増えてくると、SQL Editorで一気に書いたほうが早いし、あとで差分も残せます。
室谷代表取締役現場だと、AIにスキーマを書かせてSQL Editorに貼る流れが増えてるんですよね。手で作ると同じ作業を2回やる感じになる。
テキトー教師DotAI 認定講師ただそこで終わらせるとRLSを付け忘れるんですよ。テーブルを作った直後に「これは誰が読めるのか」を決める癖をつけておくと事故が減ります。
フレームワークとクライアントライブラリをつなぐ
室谷代表取締役公式の導線は「フレームワークを接続する」から入って、そのあとデータベースやAuth、Storage、Realtime、Edge Functionsでバックエンドを組んで、最後にクライアントライブラリという順なんですよね。
テキトー教師DotAI 認定講師クライアントライブラリはJavaScript以外にFlutter、Python、C#、Swift、Kotlinも用意されているので、アプリ側の言語はほぼ選ばないです。ここで「自分の言語は対応してるのか」を先に確認する人が多いですね。
室谷代表取締役接続でつまずくとしたら、キーの扱いですか。
テキトー教師DotAI 認定講師そうですね。公開前提のキーをサーバー側の秘密情報と混ぜてしまうのが定番のつまずきで。
フロントに置くキーと、絶対に出さないキーを最初に分けておくと後が楽です。違いが曖昧なまま進むと、あとで全部見直すことになりますから。
フロントに置くキーと、絶対に出さないキーを最初に分けておくと後が楽です。違いが曖昧なまま進むと、あとで全部見直すことになりますから。
RLS（行レベルセキュリティ）とは何か。設定しないと何が起きるのか
RLSは「行ごとに見せる範囲を絞る」仕組み
室谷代表取締役Supabaseの公式ドキュメントだと、RLSは「クライアントから直接データベースへ安全にアクセスするための仕組み」と書かれていて、テーブルを公開する前に必ず読む項目として案内されてるんですよね。
テキトー教師DotAI 認定講師最初に戸惑うのが、これが「設定項目のひとつ」に見えてしまうところなんですよ。実際は外からDBを触る前提の設計なので、ここが土台になる感覚です。
室谷代表取締役しかもSupabaseはプロジェクトごとに専用のPostgresが割り当たって、AuthもStorageもRealtimeもそのDBの上に乗ってる。つまり入り口を守るのがRLS、という構造なんですよ。
テキトー教師DotAI 認定講師たしかに。StorageもメタデータはPostgresのテーブルに置くので、同じポリシーで守れる範囲が広いんですよね。
RLSを有効にしないとanonキーで誰でも読み書きできてしまう
RLSを有効にしないと何が起きるか
テーブルを公開する前にRLSを有効化し、ポリシーを設定したか？
YES ／ 設定済み
- JWTとポリシーがDB側で照合される
- ポリシーの条件に合う行だけが返る
- APIを直接叩かれても行が出てこない
- AI生成コードでも最後の防波堤になる
NO ／ 未設定のまま公開
- anonキーを知る誰でもテーブルを読み書きできる
- anonキーは公開前提なので隠しても意味がない
- .envに入れてもフロントから叩くキーは見える前提で守りにならない
- 事故時のコストは障害対応だけでなく信用と説明責任に及ぶ
室谷代表取締役で、ここを飛ばすと何が起きるか。RLSを有効にせずにテーブルを公開すると、anonキーを知ってる人は誰でもそのテーブルを読み書きできる状態になるんですよ。
anonキーは公開前提のキーなので、隠しても意味がない。
anonキーは公開前提のキーなので、隠しても意味がない。
テキトー教師DotAI 認定講師現場でよく聞くのは「キーは.envに入れてます」という安心なんですけど、フロントから叩くキーはそもそも見える前提なので、そこは守りにならないんですよね。
室谷代表取締役経営目線で言うと、事故ったときのコストは障害対応で終わらなくて、信用と説明責任の話になる。MYUUUの現場では、リリース前チェックに「テーブル公開した？ RLSは？」を1行入れてます。
テキトー教師DotAI 認定講師その1行、地味に効くんですよ。「動いたから公開」の順番を止められますから。
ポリシーはJWTとどう連動して行を絞るのか
室谷代表取締役Authが発行するJWTが、そのままPostgresのRLSと直接連動する仕組みになってるんですよね。ログインした人のトークンを見て、ポリシーの条件に合う行だけが返る。
テキトー教師DotAI 認定講師入館証に近いですね。誰かを示すカードと、その人が入れる部屋のルールが別々にあって、DB側で必ず照合されるイメージです。
室谷代表取締役ここが大きいのは、アプリのコード側で絞ってるわけじゃない点で。APIを直接叩かれても行が出てこないので、AIにコードを書かせても最後に残る防波堤になるんですよ。
テキトー教師DotAI 認定講師画面を作るスピードと、DB側で守る強さは別レイヤーなんですね。
AIにコードを書かせる時代にRLSが漏れやすい理由
室谷代表取締役バイブコーディングの話で言うと、AIが認証とDB接続をまとめて生成して、テーブル作成まで一気に進むんですよ。そこでRLSの有効化やポリシー設定が抜けやすい、というのが実務の注意点。
特定ツールの不具合ではなくて、工程が短くなるほど確認が飛ぶという話ですね。
特定ツールの不具合ではなくて、工程が短くなるほど確認が飛ぶという話ですね。
テキトー教師DotAI 認定講師現場でよく聞くのが「画面にデータが出たので大丈夫です」なんですよ。出ることと、出ていいことが一致してない。
室谷代表取締役MCPでエージェントからテーブルを作る流れも同じで、作る作業と守る設定が分かれがちなんですよね。だから最後にRLSを人が見る、を手順として固定するのが現実的です。
テキトー教師DotAI 認定講師ここだけは自動化に任せきらない、と決めておくと事故が減りますね。
Claude CodeやCursorとつなぐと開発はどう変わる？MCP連携の現在地
公式MCPサーバー経由でAIエージェントからDBを操作する
MCP連携でDB操作を自動化するメリットと注意点
PROS ／ メリット
- SQLを一行も書かずに自然言語の指示でテーブル作成やデータの読み書きができる
- プロジェクト作成からテーブル作成、データの読み書きまでコーディングエージェントから触れる
- 実装が速くなり、書く時間を削減できる
CONS ／ デメリット
- 何が起きているか分からないまま進みやすい
- 作られたテーブルにポリシーが付いているか見えにくい
- RLSを有効にしないままテーブルを公開するとanonキーを知る誰でも読み書きできる
- 生成が速いぶんアクセス制御の漏れが抜けやすい
- 実装が速くなるほどレビューと権限設計のコストが相対的に上がる
室谷代表取締役Supabaseって、公式でMCP対応を案内してるんですよね。Claude CodeやCursorみたいなコーディングエージェントから、プロジェクト作成やテーブル作成、データの読み書きまで自然言語の指示で触れる、という話で。
テキトー教師DotAI 認定講師そこは初めて触る人が拍子抜けするポイントで。SQLを一行も書かずに「こういうテーブル作って」で通ってしまうので、逆に「本当にいいのか」と不安になるみたいです。
室谷代表取締役エディタがコードを書く道具から、DBの管理まで飲み込んでいく方向に動いてる。SNSでも公式のMCPサーバーが出たという報告が広がっていましたし、業界の構造としてはもう後戻りしない流れなんですよね。
テキトー教師DotAI 認定講師ただ、便利さの裏で「何が起きてるか分からないまま進む」感じはあります。作られたテーブルにポリシーが付いているのか、そこが見えにくいんですよ。
MCPで自動化してもRLSの確認は省けない
室谷代表取締役前の章のRLSの話と直結するんですけど、MCPでDB操作を自動化しても、最終的なアクセス制御はRLSが担うんですよ。エージェントは速く作るけど、誰が何を読めるかは決めてくれない。
テキトー教師DotAI 認定講師そうなんです。RLSを有効にしないままテーブルを公開すると、anonキーを知っている人は誰でも読み書きできる状態になる。
生成が速いぶん、そこが一番抜けやすいんですよね。
生成が速いぶん、そこが一番抜けやすいんですよね。
室谷代表取締役MYUUUの現場だと、AIに書かせたコードのレビュー観点として「RLSが有効か」「ポリシーが意図通りか」を機械的に確認する項目に入れてます。速く作れるほど、最後の砦を人手の記憶に頼らない仕組みが要るんですよね。
テキトー教師DotAI 認定講師「動いてるから大丈夫」が一番危ないやつで。最初に戸惑うのがまさにそこなんです。
開発スピードと統制をどう両立させるか
室谷代表取締役経営目線で言うと、実装が速くなるほど、レビューと権限設計のコストが相対的に上がるんですよ。時給で換算すると、書く時間を削るより、漏れを潰す時間の配分をどう決めるかのほうが効いてくる。
テキトー教師DotAI 認定講師現場感覚でも同じで、「テーブルを作ったら同じタイミングでRLSを確認する」と最初に決めておくだけで、後から追いかけなくて済みます。順番を先に決めるかどうかが大きいんですよ。
室谷代表取締役スピードと統制って対立しがちに語られるんですけど、順番の問題なんですよね。作る前に決めるか、事故ってから決めるか。
テキトー教師DotAI 認定講師たしかに。エージェント経由でDBを触るのが当たり前になるほど、その順番を最初に握れるかどうかだと思います。
Supabaseのメリット・デメリットと、実際にどんなアプリが作れるのか
Supabaseが向いているケース、向かないケース
室谷代表取締役Supabaseって向き不向きがはっきりしてるんですよね。テーブル設計が先に決まる案件、つまりユーザー・商品・注文みたいに関係性のあるデータを扱うものは素直にハマります。
テキトー教師DotAI 認定講師逆に現場でよく聞くのが「スキーマを決めずにまず動かしたい」というケースです。感覚的に後回しにしたくなって、最初のテーブル設計で手が止まる人が多いんですよ。
室谷代表取締役そこはPostgresなので後からALTERで足せますけど、最初に設計を考えるコストは払うことになる。スキーマレスが欲しいなら、そもそもFirebase側の話なんですよね。
テキトー教師DotAI 認定講師あと「とにかく無料で試したい」人にとっては、1週間操作がないとプロジェクトが一時停止する仕様と、無料プランに自動バックアップが付かない点は地味に効きます。日次バックアップが付くのはPro以上の有料プランで、Proが7日、Teamが14日保持です。
認証付きアプリ、チャット、ECはどう作るのか
室谷代表取締役具体的に何が作れるかというと、AuthとDBが最初から噛み合ってるので、ログイン付きのWebアプリは一番分かりやすいところです。
テキトー教師DotAI 認定講師チャットもRealtimeがありますから、メッセージの変更をWebSocketでそのまま流せます。Presenceでオンライン状態、Broadcastで任意メッセージ。
この辺の構成を自分で考えなくていいのは大きいです。
この辺の構成を自分で考えなくていいのは大きいです。
室谷代表取締役ECなら商品・注文・在庫を外部キーで繋いで、商品画像はStorageに置いて、決済まわりだけEdge Functionsで書く。StorageのメタデータってPostgresのテーブルに入るので、画像のアクセス制御もデータと同じポリシーで書けるんですよ。
テキトー教師DotAI 認定講師そこ、初めて触る人が一番「おお」となる部分かもしれません。画像だけ別管理にならないのは運用が楽ですよね。
OSSでセルフホストできることの意味
室谷代表取締役最後に地味だけど大きいのが、コア部分がOSSでセルフホストできること。Postgres、GoTrue、PostgRESTあたりがOSSで、CLIとDockerで自前構築できます。
テキトー教師DotAI 認定講師「じゃあ自前で立てればタダでは？」となるんですけど、運用は別の仕事として発生します。ここは判断が分かれるところだと思います。
室谷代表取締役経営目線で言うと、これは保険なんですよ。マネージドで速く出す、でもデータとコードは自前で持てる形にしておく。
買収や監査で「クラウドから出せますか」と聞かれたとき、出せる構造かどうかで交渉の土台が変わるので。
買収や監査で「クラウドから出せますか」と聞かれたとき、出せる構造かどうかで交渉の土台が変わるので。
テキトー教師DotAI 認定講師たしかに。ロックインの話に見えて、実は事業の選択肢が残ってるかどうかの話なんですね。
よくある質問
Q1. オープンソースなら、自前のサーバーで動かすこともできますか？
室谷代表取締役オープンソースなので、自前の環境で動かす道は用意されてます。ただ、そこは「運用も自分たちで持つ」ってことなんで、マネージドの楽さを手放す覚悟がいるんですよね。
テキトー教師DotAI 認定講師現場でよく聞くのは、社内ルールでデータを外に出せない、みたいなケースです。そこでは効きますけど、バックアップやアップデートの面倒は全部こっちに来ます。
室谷代表取締役時給換算で考えたら、よほどの制約がない限りマネージドでいいと思います。浮いた時間を機能開発に回した方がペイするので。
Q2. データベースの知識はどのくらい必要ですか？
テキトー教師DotAI 認定講師最初に戸惑うのが、テーブル設計を自分で考える前提になってる点ですね。Firebaseだと書類を放り込む感覚だった人が、ここで一度立ち止まります。
室谷代表取締役とはいえ難しいクエリを書ける必要はなくて、テーブル同士の関係がイメージできれば触れます。SQLもAIが書いてくれる時代ですし。
テキトー教師DotAI 認定講師書けなくても読める、は大きいですね。エラーが出たときに原因を追えるかどうかで速度が変わります。
Q3. データが増えると遅くなったりしませんか？
室谷代表取締役インデックスの設計次第なところが大きいですね。あとフロントから直接データを取りに行く構造なので、取りすぎない形にしておくのが前提になります。
テキトー教師DotAI 認定講師現場感覚で言うと、開発中は全件取れて気持ちいいんですよ。そのまま本番に出て、ある日急に重くなる。
室谷代表取締役AIに書かせると取得範囲が雑になりがちなので、そこは人が見た方がいいんですよね。
Q4. 本番で公開する前に、最低限やっておくべきことは？
室谷代表取締役スキーマの変更履歴を残すこと。画面をポチポチ触って構造を変えてると、本番との差分が追えなくなります。
テキトー教師DotAI 認定講師あと怖いのが、バックアップを一度も戻したことがないまま公開しちゃうパターンです。取ってあるだけでは安心できなくて。
室谷代表取締役鍵の扱いも同じくらい大事で。フロントに置いていい鍵と、サーバー側だけの鍵を混ぜると事故になります。
Q5. 複数人での開発になると、何が変わりますか？
テキトー教師DotAI 認定講師人数が増えた瞬間に、誰がどの行を見られるかの設計が効いてきます。後から剥がすのは本当に大変なんですよ。
室谷代表取締役属人化の話でもありますよね。設計の意図が残ってるかどうか。
MYUUUでも、外注が混じる案件は最初にそこを決めるようにしてます。
MYUUUでも、外注が混じる案件は最初にそこを決めるようにしてます。
テキトー教師DotAI 認定講師たしかに、最初の1時間で決めるかどうかで、後の3日が変わるやつですね。
まとめ
室谷代表取締役Supabaseって、突き詰めると「バックエンドの面倒なところを引き受けてくれる土台」なんですよね。で、AIがコードを書く速度が上がったぶん、ボトルネックは設計と権限の設計に移ってる。
テキトー教師DotAI 認定講師そうですね。コードはすぐ出てくるのに、データの見せ方を決めてないせいで手戻りする。
今の一番の詰まりどころはそこだと思います。
今の一番の詰まりどころはそこだと思います。
室谷代表取締役だから最初の一手は、小さくてもいいので一個アプリを立ててみること。無料の範囲で触れるので、RLSを自分で一本書いてみるのが一番早い。
テキトー教師DotAI 認定講師引っかかりやすいのが設定項目の多さなんですけど、全部理解しなくて大丈夫です。テーブル1個とポリシー1本から始めれば十分。
室谷代表取締役ですね。作りながら覚えるのが結局一番速いし、その過程でFirebaseとの違いも体で分かってくると思います。
