LASSIC Media らしくメディア
Supabase入門｜社内アプリのバックエンド内製
LASSIC IT事業部｜元請（プライムベンダー）としてシステム開発・検証を受託
社内の申請フローや案件管理台帳、簡易な顧客管理など、小規模な業務アプリを内製したい――。情報システム部門やDX推進部門から、こうした相談が増えています。フロントエンド画面は作れても、認証・データベース・ファイル保存といったバックエンド一式をゼロから構築するにはインフラ設計やAPI実装の知識が必要になり、着手をためらう企業が少なくありません。
こうした場面で選択肢に挙がるのが、Supabaseというオープンソースのバックエンド基盤です。PostgreSQLというリレーショナルデータベースを土台に、認証・自動生成API・ファイルストレージ・リアルタイム通信・サーバーレス関数までを一つのプラットフォームでまとめて扱えるのが特徴です*1。本記事では、Supabaseの主な機能と、社内アプリのバックエンドを内製で始める手順、権限設計の勘所、内製と委託の判断軸を整理します。
なお本記事は、PostgreSQLを土台にしたOSSバックエンド基盤としてのSupabaseに主題を絞ります。GoogleのFirebase（NoSQLのFirestoreを中心とするBaaS）の使い方や、BaaS全般の一般論とは狙いが異なるため、両者の違いを整理する節を設けたうえで、Supabase固有の機能や設計に焦点を当てる方針で解説します。
この記事のポイント
- Supabaseは、PostgreSQLを土台に認証・自動生成API・ストレージ・リアルタイム通信・サーバーレス関数をまとめて扱えるオープンソースのバックエンド基盤です。
- NoSQLのFirestoreを使うFirebaseとは異なり、リレーショナルなテーブル設計とRow Level Security（RLS）によるSQLベースの権限設計が中心になるため、SQL知識を持つ担当者が内製に着手しやすい構成です。
- 内製と委託は二者択一ではなく、データの機密度や社内のSQL知見の有無に応じて使い分ける判断軸を持つことが実務上のポイントです。
目次
Supabaseとは何か：PostgreSQLベースのオープンソースバックエンド基盤
Supabaseは、PostgreSQLというオープンソースのリレーショナルデータベースを中核に据えたバックエンド基盤です*1。「オープンソースのFirebase代替」と紹介されることが多く、認証・データベース・ストレージ・リアルタイム通信・サーバーレス関数といった、アプリ開発に必要なバックエンド機能一式を提供している点が特徴です*2。
提供形態は大きく二つに分かれます。一つはSupabase社が運営するクラウド版で、プロジェクトを作成するだけで各機能がすぐに使える状態になります。もう一つは、コードベース自体がオープンソースとして公開されているため、Dockerなどの環境にセルフホストする形態です*3。データの機密度や社内のインフラ運用体制に応じて、どちらの提供形態を選ぶかを検討することになります。
データベースそのものを直接扱える設計
Supabaseの特徴は、内部で使われているのが独自の抽象化レイヤーではなく、素のPostgreSQLだという点にあります。テーブル設計にはSQLの知識がそのまま活き、既存のPostgreSQL用ツールやドライバとの親和性も高い設計です。テーブルを作成すると、PostgRESTという仕組みによってAPIが自動生成される点も、内製の着手を後押しします*2。なお機能や料金プランの詳細は執筆時点の情報であり、最新の仕様は公式ドキュメントで確認することをおすすめします。
主な機能：Auth・データベース・Storage・Realtime・Edge Functions
Supabaseが提供する主な機能を整理すると、次のとおりです*2。
| 機能 | できること |
|---|---|
| Auth | メール／パスワード、OAuth、マジックリンクなどの認証機能をまとめて提供する |
| Database | フルスペックのPostgreSQL。テーブルを作成するだけでAPIが自動生成される |
| Storage | 画像やファイルを保存し、RLSと同様の考え方でアクセス範囲を制御する |
| Realtime | テーブルの変更をリアルタイムに検知し、クライアントへ配信する |
| Edge Functions | Denoベースのサーバーレス関数。DB操作以外の処理を実装できる |
| Studio | ブラウザ上でテーブル・認証・ポリシーを操作できる管理画面 |
これらは同じプロジェクト内で連携して動作するため、認証で得たユーザーIDをそのままRLSポリシーの条件に使う、といった組み合わせを作りやすい設計です。ローカル開発用のCLIも用意されており、Docker環境を使えば本番に近い構成を手元で再現しながら開発を進められます*2。
Studio・CLIによる開発体験
管理画面のStudioでは、テーブル定義やポリシー設定、認証ユーザーの一覧確認などをGUIで扱えます。SQLエディタも備わっているため、複雑なクエリやマイグレーションはSQLを直接書いて実行することも可能です。CLIを使えば、ローカル環境で組んだスキーマをクラウド版のプロジェクトへ反映する運用もでき、個人開発だけでなくチームでの内製にも対応しやすい構成といえるでしょう。
FirebaseとSupabaseの違い：リレーショナルかNoSQLか
「オープンソースのFirebase代替」と紹介されることの多いSupabaseですが、両者は提供する機能の建て付けが似ている一方、データモデルや権限設計の考え方は大きく異なります。内製の判断を誤らないために、主な違いを整理しておきます。
| 観点 | Firebase | Supabase |
|---|---|---|
| データモデル | Firestore中心のNoSQL（ドキュメント指向） | PostgreSQL（リレーショナル／SQL） |
| ホスティング | Googleのフルマネージドが前提 | クラウド版に加えOSSでセルフホストも選べる |
| 権限設計 | 独自DSLのセキュリティルール | RLS（Postgresネイティブなポリシー） |
| API | クライアントSDK経由の呼び出しが中心 | テーブルからAPIが自動生成される |
| ロックイン | Google基盤への依存度が高い | OSSであるためポータビリティを確保しやすい |
設計スキルの前提が異なる
Firestoreはドキュメント同士の関連をアプリ側のロジックで扱う設計が中心で、正規化やJOINといったリレーショナルDBの発想とは異なるモデリングが求められます。一方Supabaseは、複数テーブルをJOINで結合する、外部キー制約でデータの整合性を担保するといった、一般的なSQLの知識がそのまま活きる設計です。社内にSQLでのテーブル設計経験を持つ担当者がいるかどうかは、どちらを選ぶかの判断材料の一つになります。
権限設計についても、Firebaseのセキュリティルールが専用の記法を新たに学ぶ必要があるのに対し、SupabaseのRLSはPostgres標準のポリシー機能をそのまま使うため、SQLに慣れた担当者であれば導入のハードルは相対的に低くなります*3。ロックインの観点では、SupabaseはOSSであるためセルフホストへ移行する余地がある一方、Firebaseはフルマネージドが前提であり、長期的な運用方針を検討するうえで押さえておきたい違いです。
内製を始める6つのステップ
社内アプリのバックエンドをSupabaseで内製する際の大まかな流れを整理すると、次の6ステップになります。
ステップ1〜3：要件整理からテーブル・RLS設定まで
最初に取り組むのは、どの業務課題を解決するのか、どのようなデータを扱うのかを整理する工程です。ここでテーブル同士の関連やアクセス権限の大枠まで検討しておくと、後工程がスムーズになります。要件が固まったら、Supabaseのクラウド版でプロジェクトを作成するか、セルフホストする場合はDocker環境の準備が必要です。次に、SQLエディタやStudioの画面からテーブルを作成し、あわせて各テーブルにRow Level Securityを有効化してポリシーを設定する段階に進みます。
ステップ4〜6：認証・ストレージ設定からクライアント連携、社内公開まで
テーブル設計ができたら、Authでログイン方式を設定し、ファイルを扱う場合はStorageのバケットとポリシーを整えます。続いて、公式のクライアントライブラリを使ってフロントエンドから認証・データ取得・更新の処理を組み込み、動作を確認していく流れです。最後に、社内の利用者に展開できる状態まで整えたうえで、アクセス範囲や運用担当を決めて公開します。
権限設計（RLS）とセキュリティの勘所
Supabaseを内製で扱ううえで、最も注意したいのがRow Level Security（RLS）の設計です。RLSはテーブルの行単位でアクセス可否を制御するPostgresの機能で、Supabaseではクライアントから直接テーブルへアクセスできる設計であるがゆえに、その重要度が高くなります*3。
- RLSを有効化しないままテーブルを公開すると、想定外の第三者がデータを読み書きできる状態になりかねません。テーブル作成時にRLSを有効化し、ポリシーを設定するまでは公開しない運用を基本にします。
- ポリシーは「誰が」「どの操作を」「どの条件で」扱えるかをSQLの条件式で記述します。auth.uid関数でログイン中のユーザーIDを参照し、自分のデータだけ読み書きできるよう条件を絞り込む設計が典型的です。
- anonキーとservice_roleキーは役割が異なります。クライアント側にはRLSが適用されるanonキーを使い、RLSを迂回できるservice_roleキーはサーバー側の管理処理に限定して扱う必要があります。
- ポリシーの動作は、公開前にテスト用アカウントを複数用意し、意図した範囲だけアクセスできるかを実際に確認しておくことが欠かせません。
よくある設計ミスと対策
実務でありがちなのは、開発中はRLSを無効にしたまま進め、公開直前に慌てて設定するという進め方です。テーブルを追加するたびにRLSとポリシーをセットで設計する習慣をつけておくと、こうした抜け漏れを防ぎやすくなります。権限設計に自信が持てない場合は、公開前に第三者のレビューを挟む、あるいは専門家に確認してもらう体制を検討する価値があるでしょう。
内製と委託の判断軸
Supabaseによって、社内アプリのバックエンドを内製できる範囲は広がりました。ただし、すべてを内製すべきとは限らないのが実情です。内製と外部委託のどちらが適するかは、次のような観点で整理できます。
| 観点 | 内製が向くケース | 委託を検討したいケース |
|---|---|---|
| データ設計の複雑さ | テーブル数が少なく関連もシンプルな用途 | 多数のテーブルが絡む複雑な業務ロジックを扱う用途 |
| 社内のSQL知見 | テーブル設計やRLSポリシーを書ける担当者がいる | SQLでの設計・権限設計の経験者を確保しにくい |
| セキュリティ要件 | 自社基準でRLS設計・レビュー体制を整えられる | 監査対応や契約上の要件が厳格で専門的な設計が必要 |
| スピード感 | 小さく試してから範囲を広げたい | 多数利用者を前提に早期の安定稼働が必要 |
内製から着手し、利用範囲が広がった段階でテーブル設計やRLSポリシーのレビューだけを外部パートナーに依頼するといった、部分的な組み合わせも現実的な進め方です。LASSICのような元請会社は、こうした組み合わせについても中立的な立場でご相談に応じられます。
内製でつまずきやすい点と対策
Supabaseは着手のハードルを下げてくれる一方、内製ならではのつまずきも存在します。実務でよく見られるパターンを挙げます。
- RLSを設定しないままテーブルを公開してしまい、意図しない範囲からデータにアクセスされる――テーブル作成とポリシー設定をセットの工程として運用ルールに組み込むことが有効です。
- service_roleキーをクライアント側のコードに誤って含めてしまう――サーバー側の処理と役割を明確に分け、鍵の管理場所をチーム内で周知しておく必要があります。
- PostgreSQLの正規化やJOINに不慣れなまま設計を進め、後からテーブル構造の見直しが発生する――事前に主要なデータの関連を整理し、必要であればSQL経験者にレビューを依頼するとよいでしょう。
- 公開後の利用状況やエラーログを誰も確認せず、不具合の発見が遅れる――定期的な確認担当と頻度をあらかじめ決めておくことが望ましいです。
いずれもSupabase自体の機能不足というより、体制側の準備不足が原因になりやすい点です。RLSを含む権限設計を最初にきちんと固めておくことが、失敗を避ける近道になります。
まとめ：Supabaseは内製の選択肢を広げるバックエンド基盤
本記事では、Supabaseを使った社内アプリのバックエンド内製について、主な機能からFirebaseとの違い、始め方の手順、RLSによる権限設計の勘所、内製と委託の判断軸までを整理しました。PostgreSQLを土台にしたリレーショナルなデータモデルと、SQLベースのRLSによる権限設計が中心にある点が、NoSQL中心のFirebaseとの大きな違いです。
一方で、内製がすべての場面に適するわけではありません。データ設計の複雑さやセキュリティ要件、社内のSQL知見を踏まえて、内製と外部委託を使い分ける判断軸を持つことが、社内アプリのバックエンドを継続的に運用していくための土台になります。
よくある質問
Supabaseは無料で使えますか。
クラウド版には無料プランが用意されており、小規模な検証や内製の立ち上げには着手しやすい水準です*1。プロジェクト規模が大きくなると有料プランへの移行が必要になる場合があり、プランや条件は変更される可能性もあるため、詳細は公式サイトの最新情報を確認することをおすすめします。
FirebaseとSupabaseはどちらを選ぶべきですか。
扱うデータがドキュメント指向で構わずスピード重視ならFirebase、テーブル同士の関連が多くSQLでの設計・分析がしやすいほうがよいならSupabaseが検討しやすい選択肢です。社内にSQLの設計経験を持つ担当者がいるか、将来的にセルフホストへ移行する可能性があるかも、判断材料になります。
Supabaseの利用にSQLの知識は必須ですか。
必須とまでは言えませんが、テーブル設計やRLSポリシーの記述にはSQLの知識が実質的に前提になります。GUI操作だけである程度は進められるものの、複雑な条件のポリシーやクエリを組む場面ではSQLを直接扱う場面が出てきます。
RLSを設定しないとどうなりますか。
RLSを有効化しないままテーブルを公開すると、想定していない第三者がデータを読み書きできる状態になる可能性があります。テーブル作成後は速やかにRLSを有効化し、必要なポリシーを設定してから公開する運用を徹底することが重要です。
セルフホストとクラウド版は、どちらを選ぶべきですか。
公開までの手軽さを優先するならクラウド版が検討しやすい一方、扱うデータの機密度が高い場合や社内ネットワーク内に閉じた運用が必要な場合は、セルフホストが選択肢になります*3。どちらも一長一短があるため、データの機密度と運用体制の両面から検討することが望ましいです。
著者：テレリモ総研編集部 鈴木 亮佑
システム開発・内製化のご相談はLASSICへ
元請（プライムベンダー）として、Supabaseを使った社内アプリのバックエンド内製支援から、複雑な要件のシステム開発までご提案します。まずはお気軽にご相談ください。
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：Supabase公式サイト（https://supabase.com/）
- *2 出典：Supabase Documentation（https://supabase.com/docs）
- *3 出典：Supabase GitHubリポジトリ（https://github.com/supabase/supabase）
