この記事の結論
Supabaseは、プロジェクトごとにPostgreSQLのデータベースを用意し、ログインの仕組み（Auth）、ファイルの置き場所（Storage）、サーバー側の関数などを一緒に使えるクラウドのサービスです。
業務システムに使えるかどうかは、Supabaseそのものより、作る側の設定で決まります。
確かめたいのは5つです。
外から読める場所にある表に、すべてRLS（行ごとの見られる範囲の決まり）がかかっているか。
RLSを通り抜ける秘密の鍵が、ブラウザやソースコードに出ていないか。
契約しているプランで、バックアップが何日分あり、ファイルは別に守っているか。
データを置くリージョンを、最初に決めたか。
プロジェクトの持ち主が、自社の組織になっているか。
Supabaseとは
Supabaseは、プロジェクトごとに完全なPostgreSQLのデータベースを用意し、データの変化をすぐ画面に届ける仕組みやバックアップ、拡張機能と一緒に提供する、と説明しています。
メールとパスワードやGoogleなどでのログインを扱うAuth、大きなファイルを置いてRLSで見られる範囲を決められるStorage、利用者に近い場所で動くサーバー側の関数（Edge Functions）も、同じプロジェクトの中で使えます（Supabase Docs、2026年10月4日確認）。
データベースと、ログインと、ファイルの置き場所を、サーバーを持たずに一度にそろえられるので、小さな会社の業務システムには合いやすい道具です。
そのかわり、誰に何を見せるかを決めるのは、作る側の仕事として残ります。
Supabaseも、アクセスの範囲を正しく管理すること、データベースの秘密の値やAPIの鍵を安全に保管することは利用者の責任だと書き、RLSを常にかけることを勧めています（Supabase Docs：責任共有モデル、2026年10月4日確認）。
Supabaseが受け持つのは、バックアップや監視、OSの保守、土台となる設備とその守りです。
業務システムで使うときに、設計で先に決めること
業務システムでは、複数の店舗や取引先、部署のデータを1つのデータベースに入れ、表ごとのRLSで見られる範囲を分ける作り方ができます。
この作り方にするなら、RLSの決まり、鍵の扱い、データを置くリージョンの3つは、作り始める前に決めておきたいところです。
どれも、後から直そうとすると手間が大きくなります。
問い合わせのように個人情報が入る表は、画面から直接は読めないようにして、サーバー側の処理だけが扱う形にする方法もあります。
ただし、そのサーバー側の処理でRLSを通り抜ける秘密の鍵を使うなら、RLSは守りになりません。
ログインしている人がそのデータを扱えるかを処理の中で確かめ、データを取り出すときも対象の範囲で必ず絞る、という確認を、コードの側に持たせる必要があります。
外から読める表には、すべてRLSをかける
RLSは、表の行ごとに、誰が読めて誰が書けるかを決める仕組みです。
Supabaseは、外から呼び出せるスキーマにあるすべての表で、RLSを有効にするよう書いています。
RLSを有効にすると、ポリシー（決まり）を作るまでは、公開用の鍵を使ったAPIからはデータを読めなくなります（Supabase Docs：Row Level Security、2026年10月4日確認）。
かけ忘れがどれくらい危ないかは、Supabaseの点検機能の説明がいちばん分かりやすいかもしれません。
publicスキーマの表でRLSが無効になっていると、点検はいちばん重い「エラー」として知らせ、その理由を「プロジェクトのURLを知っている人なら誰でも、この表のデータを読み、書き換え、消せる」と書いています。
点検は管理画面のSecurity Advisorから見られます（Supabase Docs：データベースの点検、2026年10月4日確認）。
外注先に作ってもらったシステムなら、ここに何も出ていないかを見せてもらうだけでも、確かめる手がかりになります。
RLSを通り抜ける鍵を、外に出さない
SupabaseのAPIの鍵には、ブラウザやアプリに置いてよい公開用の鍵（publishable key）と、サーバー側だけで使う秘密の鍵（secret key）があります。
以前から使われている anon と service_role も、それぞれ同じ役割の従来の鍵です（Supabase Docs：APIキー、2026年10月4日確認）。
秘密の鍵は、RLSのポリシーをすべて通り抜けます。
Supabaseは、ブラウザにも、配るアプリにも、ソースコードにも入れないように書いています。
秘密の鍵はブラウザから使うと拒まれる作りにもなっていますが、それに頼らず、置き場所で守ります。
業務システムを作ってもらうときは、「秘密の鍵はどこに置いていますか」と聞いてみてください。
答えがサーバー側の環境変数のような場所なら、置き場所の考え方は合っています。
バックアップは、プランで変わる
Supabaseのバックアップは、契約しているプランによって中身が変わります（Supabase Docs：バックアップ、Supabaseの料金、どちらも2026年10月4日確認）。
| プラン | 毎日のバックアップ |
|---|---|
| Free | 料金の表では、毎日のバックアップはProからの機能。Freeには、CLIの db dump で定期的に書き出し、別の場所に保管するよう勧めている |
| Pro | 直近7日分 |
| Team | 直近14日分 |
| Enterprise | 最大30日分 |
Pro以上のプランでは、追加の機能として、時刻を指定して戻せるPoint-in-Time Recoveryを有効にできます。
見落としやすいのは、Storageに置いたファイルが、データベースのバックアップに含まれないことです。
データベースに入っているのはファイルの情報だけなので、契約書や写真をStorageに置くシステムなら、ファイルの守り方は別に決めます。
業務で使うデータを無料のプランに置いたままにしないこと、何日前まで戻せれば業務が困らないかを先に決めること。
この2つは、作り始める前に発注する側と決めておくべきだと私は考えています。
データを置くリージョンは、最初に決める
プロジェクトは、作るときにリージョンを選びます。
アジアには、東京（ap-northeast-1）のほか、ソウル、シンガポール、ムンバイ、シドニーがあります（Supabase Docs：リージョン、2026年10月4日確認）。
気をつけたいのは、同じページで多くのプロジェクトに勧められている、APACのような広い地域の選び方です。
こちらは、その地域の中の空いているリージョンに置かれるので、国までは決まりません。
データを特定の国に置く必要があるなら、東京のようにリージョンを名指しで選ぶよう書かれています。
後からリージョンを変えるのは、設定を一つ切り替える話ではありません。
組織の間でプロジェクトを移す機能ではリージョンは変えられず、別のプロジェクトへデータを移す手順を使うよう案内されています（Supabase Docs：プロジェクトの移管、Supabase内での移行、どちらも2026年10月4日確認）。
個人情報を国内に置きたい、取引先から置き場所を聞かれる、といった事情があるなら、プロジェクトを作る前に決めておきます。
プロジェクトの持ち主を、自社の組織にする
Supabaseのプロジェクトは組織（Organization）の中に作られ、組織の人にはOwner、Administrator、Developer、Read-Onlyのいずれかの役割を付けます。
プロジェクトを組織の外へ移せるのはOwnerだけで、Administratorにはできません。
見られるプロジェクトを人ごとに絞る設定は、TeamとEnterpriseのプランで使えます（Supabase Docs：アクセス制御、2026年10月4日確認）。
外注先の組織の中にプロジェクトがあると、データの持ち主が誰なのかが曖昧になります。
プロジェクトはほかの組織へ移すこともできますが、移すには元の組織のOwnerである必要があります（Supabase Docs：プロジェクトの移管、2026年10月4日確認）。
最初から自社の組織に作ってもらい、外注先の担当者にはDeveloperのような役割を付ける形にしておけば、後で頼む先を変えるときも自社で決められます。
ソースコードの置き場所についても同じ考え方で、外注先が書くコードも、GitHubの自社の組織に置くに書きました。
Supabaseが合わない場合
決まったサーバーの上でしか動かないソフトと組み合わせる、社内のネットワークの中だけで動かしたい、データを置く国や事業者に契約上の決まりがある。
こうした場合は、Supabaseより別の構成のほうが合うことがあります。
どちらを選ぶかは、扱うデータと、使う人の範囲から決めます。
サーバーを持たずに管理画面を作る構成の全体は、小さな会社の管理画面を、サーバーを持たずに作る構成にまとめています。
bundlyzeは、大阪市北区のグラングリーン大阪を拠点に、大阪・兵庫を中心とした関西の会社からのご相談に対応していて、打ち合わせはWeb会議でも対面でもできます。
全国からオンラインでもご相談いただけます。
書いたのは技術責任者の津嘉山です。
AWS認定資格を持つ業務システム開発とAWSの専門のエンジニアで、業務システムの設計を担当しています。
よくある質問
Supabaseに顧客の個人情報を置いても大丈夫ですか？
無料のプランのまま業務に使ってもよいですか？
外注先が作ったSupabaseのプロジェクトを、自社に移せますか？
RLSがかかっているかは、どこで確かめられますか？
作ってもらったシステムがSupabaseなら、まずは管理画面のSecurity Advisorを開いて、エラーが出ていないかを見てください。
ご相談
サーバーやクラウドの運用について、いまの状況をお聞かせください。
「何から手をつければいいか分からない」という段階からで構いません。返信は担当者が直接お送りします。
