---
title: "Supabaseの商用利用：OSSライセンスと有料プラン・SLA・契約の確認点"
url: "https://www.issoh.co.jp/column/details/19508/"
published: 2026-11-08
updated: 2026-11-08
categories: ["Webシステム"]
publisher: "株式会社一創"
---

# Supabaseの商用利用：OSSライセンスと有料プラン・SLA・契約の確認点

Supabaseは商用で使えます。ただし「使ってよいか」を決める文書は2種類あり、ソースコードはApache-2.0ライセンス、supabase.comのクラウド版は利用規約と料金プランで条件が決まる仕組みです。この記事では、Freeプランで商用サービスを動かしたときに止まる仕様、Pro・Team・Enterpriseで保証される範囲と保証されない範囲、東京リージョンやDPAなどのデータ要件、受託開発で採用するときの契約主体までを、2026年11月8日時点の公式ドキュメントで確認します。料金の比較やFirebaseとの違いを知りたい場合は、[SupabaseとFirebaseの違い｜DB・認証・料金の比較とどっちを選ぶか](https://www.issoh.co.jp/column/details/3002/)を先に読むと全体像がつかめます。

## まとめ：Supabaseを商用で使う前に決める契約主体とプラン

ライセンス上の制約で商用利用が禁じられることはありません。判断を分けるのは、どのプランで、誰の名義で契約し、どこまでの保証を求めるかです。

実務で先に決める順番は次のとおりです。第一に、本番はFreeではなくPro以上にします。Freeは1週間の無操作で一時停止し、自動バックアップもありません。第二に、稼働率の保証が契約上必要かを確認します。99.9%の稼働率SLAが付くのはEnterpriseだけで、ProとTeamには付きません。第三に、個人情報を扱うなら東京リージョンを作成時に選び、DPAとサブプロセッサー一覧で委託先を説明できるようにします。第四に、受託開発では発注者名義の組織で契約し、開発会社はメンバーとして参加する形を基本にします。

稼働率の保証が要るのにEnterpriseの予算が取れない案件、医療情報を扱うのにBAAを結べない案件では、Supabaseクラウドの採用を見送ります。

## Supabaseの商用利用を分ける2つの層：OSSライセンスとクラウド規約

「Supabaseは商用利用できるか」という問いには、ソースコードを使う場合とクラウドサービスを使う場合で別の答えがあります。混同すると、ライセンスを読んで安心したのにクラウドの規約上の制約を見落とす、という事故が起きます。

### Apache-2.0で公開されたソースコードを商用製品に組み込む条件

[GitHubのsupabase/supabaseリポジトリ](https://github.com/supabase/supabase)はApache-2.0ライセンスで公開されています。Apache-2.0は商用利用・改変・再配布を認めるライセンスで、利用料もかかりません。義務は、配布するときにライセンス文の写しを同梱すること、NOTICEファイルがあればその表示を残すこと、改変したファイルに変更した旨を示すことの3点が中心です。

注意したいのは、Supabaseが単一のプログラムではない点です。データベースのPostgreSQL、APIを自動生成するPostgREST、認証、Realtime、Storageなど、別々のプロジェクトを組み合わせて構成されています。READMEは各構成要素へのリンクを示すだけで、個別のライセンスまでは書いていません。製品に組み込んで配布する場合は、使うコンポーネントごとにLICENSEファイルを確認します。主要なOSSライセンスの義務の違いは[オープンソースライセンスとは？主要9種の商用利用可否と義務を条項番号で解説](https://www.issoh.co.jp/column/details/3932/)で整理しています。

### supabase.comのクラウドはOSSライセンスでなく利用規約で決まる理由

supabase.comで作ったプロジェクトは、ソースコードを受け取って動かすのではなく、Supabase社が運用するサービスを契約して使う形です。このため条件を決めるのはApache-2.0ではなく[Supabaseの利用規約（Terms of Service）](https://supabase.com/terms)です。

規約の準拠法は米国カリフォルニア州法で、紛争はICC規則の仲裁により、アジアの顧客はシンガポールが仲裁地になります。支払いが10日以上遅れたときのサービス停止、規約の変更を事前通知のうえで行える条項もあります。Freeプランだけを対象に商用利用を禁じる条項は見当たりません。商用で使えるかどうかより、契約条件を自社の取引に合わせられるかが論点になります。

## Freeプランで商用サービスを動かすときに止まる仕様と本番の入口

Freeプランでも規約上は商用サービスを動かせます。ただし本番の運用に耐えない仕様がいくつかあり、実務上の入口はProです。

### 1週間の無操作で一時停止するFreeプランの本番リスクと再開手順

[Supabaseの料金ページ](https://supabase.com/pricing)によると、Freeプランのプロジェクトは1週間アクセスがないと一時停止します。同時にアクティブにできるのは2プロジェクトまでです。停止したプロジェクトはダッシュボードから再開できますが、その間アプリはデータベースに接続できません。

社内の月末だけ使う申請システムや、季節キャンペーンのサイトは、利用がない週が続くと止まります。利用者から「つながらない」と連絡が来てから再開するのでは業務システムとして成立しません。有料プランのプロジェクトは無操作でも停止しないと明記されているので、利用頻度にむらがあるシステムほど有料プランが前提です。

### バックアップなし・ログ保持1日がFreeで障害調査を難しくする点

Freeプランには自動バックアップが含まれません。誤ったマイグレーションや削除クエリでデータを壊したとき、Supabase側から戻す手段がない状態です。API・データベースのログ保持期間も1日で、週明けに前週の不具合を調べようとしても記録が残っていません。

容量の上限はデータベース500MB、月間アクティブユーザー5万、転送量5GBです。業務アプリの初期運用なら収まる規模ですが、容量より先にバックアップとログの不足が問題になります。商用で顧客のデータを預かるなら、この2点だけでFreeを外す理由になります。

### 本番の入口はPro月25ドルから：コンピュート課金とSpend Capの扱い

Proは月25ドルからで、データベース8GB、月間アクティブユーザー10万、転送量250GBを含み、自動バックアップは7日分です。月10ドル分のコンピュートクレジットが付き、Microインスタンス1台分をまかないます。2つ目以降のプロジェクトはコンピュート費用が全額かかるため、本番・検証の2環境を常設すると月25ドルでは収まりません。

ProではSpend Cap（利用上限）が初期状態でオンになっています。オンのままなら超過分は課金されず制限がかかり、オフにすると超過分が従量で請求されます。予算を固定したい案件ではオンのまま、アクセス急増でも止めたくないサービスではオフにして監視を組む、という使い分けが基本です。課金単位ごとの月額試算は3002の料金比較の章にまとめています。

## 有料プランごとのSLAとサポート範囲：ProとTeamで保証されない領域

商用利用で見落とされやすいのが、稼働率の保証がどのプランに付くかです。料金ページの比較表と[SupabaseのSLA（Service Level Agreement）](https://supabase.com/sla)を突き合わせると、次のように分かれます。

| 項目        | Pro    | Team    | Enterprise |
| --------- | ------ | ------- | ---------- |
| 月額        | 25ドルから | 599ドルから | 個別見積り      |
| サポート      | メール    | 優先メール   | 24時間365日   |
| 応答時間のSLA  | なし     | あり      | あり         |
| 稼働率のSLA   | なし     | なし      | 99.9%      |
| SOC 2レポート | なし     | あり      | あり         |
| 自動バックアップ  | 7日     | 14日     | 個別設定       |
| ログ保持      | 7日     | 28日     | 90日        |

表のとおり、Teamに付くのはサポートの応答時間のSLAで、サービスが止まったときの補償ではありません。発注者から「稼働率99.9%を契約に書いてほしい」と求められたら、Enterprise以外ではSupabaseとの契約で裏付けられない点を最初に伝える必要があります。

### 稼働率99.9%の保証はEnterpriseだけ：返還クレジット率と上限

SLAの本文では、Enterpriseの顧客に対し製品ごとに月間99.9%の稼働率を約束しています。下回ったときの返還は、99.0%以上なら月額の10%、98.0%以上なら15%、96.0%以上なら20%、96.0%未満なら30%のクレジットです。

クレジットは現金での返金ではなく、将来の請求に充てる形です。上限は直近12か月に支払った対象料金の20%で、請求は月末から30日以内にメールで、影響を受けたプロジェクトと停止時刻を5分単位で示して行います。AWSやCloudflareなど外部事業者に起因する障害、非公式の拡張機能を使った場合などは除外されます。停止による売上の損失を埋める仕組みではないと理解しておくべきです。

### Teamの応答時間SLAとProのメールサポートで足りる運用の線

Proのサポートはメールのみで、応答時間の約束はありません。Teamになると優先メールサポートと応答時間のSLAが付き、Enterpriseは24時間365日のサポートになります。

Proで足りるのは、障害時に自社や開発会社がログとダッシュボードで一次切り分けをでき、Supabase側の回答を数日待っても業務が回る場合です。夜間や休日の停止がそのまま売上や受付停止に直結するなら、Proのまま本番に出すのは避けます。サポートの差は月額で約24倍の開きがあるので、要件を聞いてからプランを決める順番を守ります。

## データ所在とセキュリティ要件：東京リージョン・DPA・SOC 2の確認順

顧客情報や従業員情報を載せる業務システムでは、情報システム部門や法務から保存場所と委託先の説明を求められます。Supabaseでは次の3つの資料で答えられます。

### 東京リージョンap-northeast-1を作成時に選ぶ理由と移管の制約

[Supabaseのリージョン一覧](https://supabase.com/docs/guides/platform/regions)には、日本国内の選択肢としてNortheast Asia（Tokyo）、コードap-northeast-1があります。各プロジェクトの配置先は1つのプライマリリージョンです。「APAC」のような広域指定ではAWSリージョンが自動で選ばれるため、保存場所の要件があるなら特定リージョンを選ぶよう公式も案内しています。

組織間でプロジェクトを移管しても、リージョンを移すことはできません。シンガポールで作った検証用プロジェクトをそのまま本番に昇格させると、日本国内保存を求められたときにデータを移し替える作業が発生します。本番用は最初から東京で作るのが安全です。

### DPAとサブプロセッサー一覧で個人情報の委託先を説明する手順

[SupabaseのData Processing Addendum（DPA）](https://supabase.com/legal/customer-resources/data-processing-addendum)は利用規約の一部として効力を持ち、契約の発効日から適用されます。別途署名しなくても、規約に同意した時点でEUの標準契約条項（SCC）に署名したのと同じ扱いになると定めています。

委託先の確認には[Subprocessor List](https://supabase.com/legal/customer-resources/subprocessor-list)を使います。変更通知を購読できるので、社内の委託先台帳と連動させておけば、監査時の説明資料にそのまま転用できる点も利点です。契約終了時の削除は、終了後30日以内に申し出る必要がある点も社内手順に書いておきます。

### SOC 2 Type 2レポートの入手はTeam以上：医療情報はBAAが前提

[SupabaseのSOC 2に関するドキュメント](https://supabase.com/docs/guides/security/soc-2-compliance)によると、同社はSOC 2 Type 2の認証を取得しており、監査期間は毎年3月1日から翌年2月末までです。レポートはTeamとEnterpriseの顧客が組織ダッシュボードのLegal Documentsから入手できます。Proでは取り寄せられません。

SOC 2の対象はSupabaseが管理する範囲だけで、アプリ側のアクセス制御は利用者の責任です。行レベルセキュリティの設定漏れは監査報告書では防げないので、[Supabase RLSの設定手順とAuth連携ポリシー設計](https://www.issoh.co.jp/tech/details/17056/)で示した有効化漏れの検知を運用に組み込みます。医療情報（PHI）を扱う場合は、BAAの締結とHIPAAアドオンの有効化が前提で、SOC 2はその代わりになりません。

## 受託開発でSupabaseを採用するときの契約主体と組織設計

開発会社にSupabaseでの構築を依頼する場合、技術より先に「誰の名義で契約するか」を決めます。ここを曖昧にすると、納品後の請求先や障害時の窓口が宙に浮きます。

### Authorized Usersの定義から見た発注者名義の組織と受託側の役割

利用規約は、サービスを使える者（Authorized Users）を契約者の従業員、コンサルタント、請負業者、代理人と定義しています。サービスを第三者に提供・再販することは禁じられています。開発会社が自社名義で契約し、その環境を発注者に使わせる形は、この定義と相性がよくありません。

素直なのは、発注者が自社名義でSupabaseの組織を作って支払い方法を登録し、開発会社の担当者を請負業者としてメンバーに招く形です。[Supabaseの課金](https://supabase.com/docs/guides/platform/billing-on-supabase)は組織単位で、1つの組織に有料プランと無料プランを混在させられません。発注者ごとに組織を分ければ、請求書もプランも案件ごとに独立します。

### 受託会社名義で始めたプロジェクトを発注者へ移すときの移管条件

検証段階だけ開発会社の組織で進め、本番前に発注者へ渡すこともできます。[プロジェクト移管の手順](https://supabase.com/docs/guides/platform/project-transfer)では、移管元組織のOwnerで、かつ移管先組織のメンバー以上であることが必要です。GitHub連携とログドレインは事前に外し、TeamやEnterpriseでプロジェクト単位のロールを設定していればそれも外します。

有料プランからFreeプランの組織へ移すと1〜2分の停止が起こりえます。移管先がFreeなら無料プロジェクト2件の上限も適用対象です。移管月の利用料は移管前の分が移管元、移管後の分が移管先に請求されるので、どの月から発注者負担にするかは見積書への記載が必要です。移管後はAPIキーの持ち主も変わるため、[Supabase APIキーの管理](https://www.issoh.co.jp/tech/details/17068/)で整理した鍵の切り替えを納品手順に含めます。

### 責任上限は直近12か月の支払額：障害時の損害を発注者契約で手当て

利用規約の責任条項では、損害賠償の総額は請求の直前12か月に支払った、または支払うべき金額が上限です。逸失利益やデータの損失といった間接損害は原則として対象外です。Proで月25ドルなら、Supabaseが負う責任は年間でもその範囲にとどまります。

この差は、発注者と開発会社の契約で埋めるしかありません。障害時の復旧手順、バックアップの取得先、データ損失時の責任分担を保守契約に書き、Supabase自体の停止は免責事由に入れるのが現実的な線です。データベースのダンプを自社のストレージにも定期保存しておくと、Supabase側のバックアップ期限に縛られずに済みます。

## Supabaseの商用採用を決める契約・運用条件と見送る場面の判定

ここまでの条件を、採用してよい場面と見送る場面に分けて言い切ります。

### Supabaseクラウドを商用採用してよい条件：Pro以上と自社運用体制

採用してよいのは、次の条件をすべて満たす場合です。

- 本番をPro以上で契約し、発注者名義の組織で支払いを管理できる
- 稼働率の保証を契約上求められていない、または求める場合にEnterpriseの予算がある
- 東京リージョンで作成し、DPAとサブプロセッサー一覧で委託先を説明できる
- 障害時に一次切り分けをする担当が自社か保守契約のある開発会社にいる
- データベースのダンプを外部にも定期保存する手順がある

社内向けの業務アプリや、利用者数が数千〜数万規模の会員サービスは、この条件に収まることが多い領域です。CLIで管理したマイグレーションをCIから適用する運用まで整えると、Supabase側の変更にも追従しやすくなります。その手順は[Supabase CLIとローカル開発環境](https://www.issoh.co.jp/tech/details/17063/)にまとめています。

### 見送るべき場面：稼働率保証が要るのにTeam以下の予算しかない案件

次の場面ではSupabaseクラウドを採用しません。稼働率99.9%を発注者との契約に明記する必要があるのに、Enterpriseの予算が取れない場合。医療情報を扱うのにBAAの締結とHIPAAアドオンの費用を見込めない場合。国内のデータセンター事業者との直接契約や、日本法を準拠法とする契約が社内規程で必須の場合も同じです。

これらの制約があるときは、ソースコードがApache-2.0であることを生かしてセルフホストに切り替えるか、別の基盤を選びます。セルフホストは保証も自社持ちになるため、運用人員を確保できるかが採用の判断材料です。構成と運用負荷は[Supabaseセルフホストの構成と運用](https://www.issoh.co.jp/tech/details/17074/)で確認可能です。プランの選定から契約名義、納品時の移管手順まで含めて相談したい場合は、一創の[業務用・Webアプリ開発](https://www.issoh.co.jp/service/apps/business/)で要件整理から対応します。

## よくある質問

Supabaseの商用利用について、検討段階でよく出る質問に答えます。

### Supabaseは無料プランのまま商用利用できますか？

規約上はFreeプランだけを商用で禁じる条項はなく、使うこと自体はできます。ただし1週間アクセスがないとプロジェクトが一時停止し、自動バックアップはなく、ログの保持は1日です。利用者がいる本番サービスでこの条件を受け入れられる場面は限られます。試作や社内の検証はFree、顧客のデータを預かる本番はPro以上と分けるのが実務的な線です。Freeの組織とProの組織は分ける必要があるので、本番用の組織を最初から有料で作ると移管の手間も省けます。

### Supabaseをセルフホストすれば商用利用の制限はなくなりますか？

セルフホストではsupabase.comの利用規約は関係せず、各コンポーネントのOSSライセンスに従います。リポジトリ全体はApache-2.0で、商用利用・改変は認められています。配布する場合はライセンス文の同梱などの義務が残り、構成要素ごとのLICENSEも確認が必要です。一方で、稼働率の保証、バックアップ、セキュリティ更新の適用はすべて自社の責任になります。制約が減る代わりに運用の負担が増える、と考えてください。

### Supabaseのデータを日本国内のリージョンに保存できますか？

できます。プロジェクト作成時にNortheast Asia（Tokyo）、コードap-northeast-1を選ぶと、配置先は東京のAWSリージョンです。「APAC」のような広域指定ではAWSリージョンが自動で選ばれるので、保存場所に要件がある場合は特定リージョンで東京を指定します。組織間の移管ではリージョンを変えられないため、本番用は最初から東京で作成してください。委託先の説明にはDPAとサブプロセッサー一覧を併せて使います。

### Supabaseが値上げやサービス変更をしたら別の基盤へ移せますか？

移せます。データベースは標準のPostgreSQLなので、ダンプを取れば他のPostgreSQL環境へ戻すことが可能です。利用規約にも顧客データはいつでもエクスポートできると書かれています。移行で手間がかかるのは、認証、Storage、Realtimeなどデータベース以外の機能を多用している部分です。Firebaseとの比較を含むロックインの度合いは3002のセルフホストとロックインの章で整理しているので、採用前に依存する機能の範囲を決めておくと移行の見積りが立てやすくなります。

### Supabaseで作ったアプリの利用者数に上限はありますか？

月間アクティブユーザー（MAU）は、プランごとに料金に含まれる数が決まっています。Freeは5万、ProとTeamは10万までが月額に含まれ、ProとTeamでは超えた分が1MAUあたり0.00325ドルで加算されます。ProでSpend Capがオンのままなら、超えた分は課金されず利用が制限される仕組みです。利用者の増加が見込めるサービスでは、Spend Capを外す時期と月額の上限を発注時に決めておくと、急な請求や停止を避けられます。

## 関連記事

- [SupabaseとFirebaseの違い｜DB・認証・料金の比較とどっちを選ぶか](https://www.issoh.co.jp/column/details/3002/)：料金の課金単位と月額試算、ロックインの度合いを比較
- [Supabaseセルフホストの構成と運用](https://www.issoh.co.jp/tech/details/17074/)：クラウドの規約を避けてApache-2.0の範囲で運用する場合の構成
- [オープンソースライセンスとは？主要9種の商用利用可否と義務](https://www.issoh.co.jp/column/details/3932/)：Apache-2.0を含む主要ライセンスの義務の違い
- [Supabase RLSの設定手順とAuth連携ポリシー設計](https://www.issoh.co.jp/tech/details/17056/)：SOC 2の範囲外になるアプリ側のアクセス制御
- [Supabase CLIとローカル開発環境](https://www.issoh.co.jp/tech/details/17063/)：本番運用に入る前に整えるマイグレーションとCI

---

出典: [Supabaseの商用利用：OSSライセンスと有料プラン・SLA・契約の確認点](<https://www.issoh.co.jp/column/details/19508/>)（株式会社一創）
