GAS + Supabaseの料金目安と顧客別Project運用：無料プラン・Proプラン・見積時の考え方
GAS（Google Apps Script）とSupabaseを組み合わせると、スプレッドシートだけでは扱いにくくなった業務データを、外部DBとして管理しやすくなります。
発注管理、請求書送信、進捗管理、日報、顧客管理、作業履歴管理などで、データ量が増える、検索条件が増える、権限管理が必要になる場合は、Supabaseを使う構成が選択肢になります。
ただし、顧客向けにGAS + Supabaseの業務アプリを提案する場合は、機能面だけでなく料金の説明も必要です。
Supabaseには無料プランがありますが、本番運用や顧客別運用では、無料プランだけを前提にしない方がよいケースがあります。
また、Supabaseの料金は「月額プラン料金」だけでなく、Project数、Compute、ストレージ、帯域、バックアップ、ログ、保守対応なども含めて考える必要があります。
この記事では、GAS + Supabaseで業務アプリを作る場合の料金目安と、顧客別Project運用の考え方を実務目線で整理します。
料金や制限は変更される可能性があるため、この記事では2026年5月14日時点で確認した公式情報をもとに、見積や顧客説明で使いやすい考え方として解説します。
1. この記事で伝えたいこと
GAS + Supabaseの料金を考えるときに大切なのは、Supabaseの月額だけを見ないことです。
Supabaseの公式料金ページを見ると、Free、Pro、Team、Enterpriseといったプランがあります。
2026年5月14日時点で確認した範囲では、Freeは無料で小規模・試作用、Proは月額25ドルから、Teamは月額599ドルから、Enterpriseは個別見積の位置づけです。
ただし、顧客向けの業務アプリでは、単に「Supabaseは月25ドルです」と説明すると不足します。
実際には、次のような要素を含めて考える必要があります。
- Supabaseのプラン料金
- ProjectごとのCompute費用
- 顧客ごとにProjectを分けるかどうか
- データベース設計費
- 初期設定費
- 権限設計費
- バックアップやログ確認
- 障害時の一次確認
- 仕様変更や追加改修への対応
- GAS側の開発・保守費
特に、複数顧客向けに同じGAS + Supabase構成を提供する場合は、顧客ごとにProjectを分けるか、同じProject内で顧客データを分けるかを先に考える必要があります。
顧客別Projectにすると、データ分離は説明しやすくなります。
一方で、Project数が増えるほど、Compute費用、設定作業、保守確認、バックアップ確認、権限管理の手間も増えます。
この記事では、料金を細かく計算するための表ではなく、見積前に整理しておきたい判断軸を中心に説明します。
2. Supabase料金を見るときの基本
Supabaseの料金を見るときは、まずOrganizationとProjectの関係を理解しておく必要があります。
Supabaseでは、Organizationの中にProjectを作ります。
公式ドキュメントでは、Organizationごとに1つのサブスクリプションプランを持ち、Free、Pro、Team、Enterpriseのいずれかを選ぶ形になっています。
また、Projectごとに専用のPostgresインスタンスが用意されます。
つまり、Projectを増やすと、単にフォルダが増えるだけではなく、ProjectごとのCompute費用や管理対象が増えると考える必要があります。
公式情報では、Free Planでは無料Project数に上限があります。
Paid planでは、Organization全体に対してプランの機能が適用され、ProjectごとのComputeや一部の利用量に応じた費用が発生します。
Pro Planでは、月額25ドルのプラン料金に加えて、Compute Creditsがあり、標準的な小さなProject 1つをまかなえる説明になっています。
ただし、複数Projectを動かす場合は、追加ProjectのCompute費用が増える前提で見ておく必要があります。
料金を見るときは、次の順番で考えると整理しやすいです。
- Organizationを誰の名義で作るか
- Free、Pro、Teamのどのプランを使うか
- Projectを顧客ごとに分けるか
- ProjectごとのComputeをどのサイズにするか
- データ量やStorageがどの程度増えるか
- バックアップやログ保持が必要か
- 本番運用としてサポートが必要か
GAS + Supabaseの提案では、Supabase料金だけでなく、GAS側の実行制限、保守、障害対応も合わせて説明する方が安全です。
料金ページを見るときは、表示されている月額だけで判断しないことが大切です。Supabaseはプラン、Project、Compute、ストレージ、帯域、ログ、バックアップなど複数の要素で費用が変わります。小さな試作ではFreeで足りても、本番運用でProjectを分けたり、データ量が増えたりすると、見積の前提が変わります。
また、顧客向けの見積では、外部サービス費と作業費を分けます。Supabaseへ支払う費用は公式利用料であり、テーブル設計、GAS連携、RLS設定、バックアップ確認、エラー時の一次対応は開発者側の作業です。この区別を最初に説明しておくと、「月額プラン料金を払えば保守も含まれる」という誤解を避けられます。
料金や制限は変わるため、提案書には確認日を入れます。
3. 無料プランで試せる範囲
Supabaseの無料プランは、試作や小規模な検証に向いています。
GASからSupabaseへデータを登録する、一覧を取得する、簡単な検索を試す、RLSやAPI連携の考え方を確認する、といった用途であれば、無料プランから始められます。
たとえば、次のような段階です。
- GASからSupabaseへ接続できるか試す
- スプレッドシート管理からDB管理へ移せるか検証する
- 小さな業務アプリの試作を作る
- 顧客説明用のデモを作る
- テーブル設計や画面構成を確認する
- 少人数でMVPとして使ってみる
無料プランは、初期検証には便利です。
ただし、本番運用や顧客向け運用では注意が必要です。
公式情報では、Free Planには無料Project数やデータベースサイズなどの制限があります。
また、無料Projectは一定期間利用がないとpauseされる場合があります。
業務アプリとして顧客に提供する場合、使っていない期間にProjectが停止する、制限に近づいてサービス制限がかかる、バックアップやサポートが不十分になる、といった状態は避けたいところです。
そのため、無料プランは「検証」「デモ」「小規模な試作」として使い、本番運用ではPro以上を検討する、という説明が現実的です。
顧客に提案するときも、「無料でずっと本番運用できます」とは言わない方が安全です。
無料プランは入口として便利ですが、顧客の業務データを預かる場合は、バックアップ、ログ、サポート、継続運用まで含めて考える必要があります。
無料プランを使う場合でも、何を検証するのかを決めておくことが重要です。単に「無料で使えるから始める」のではなく、GASから登録できるか、検索速度は十分か、RLSの考え方を説明できるか、既存スプレッドシートから移行できそうか、という検証項目を決めます。
顧客デモで使う場合は、デモ用データと本番データを混ぜないようにします。無料Projectで作った試作をそのまま本番化すると、権限、バックアップ、料金、所有者、データ移行の整理が後回しになりやすいです。試作の時点から、本番では別Projectや別Organizationに移す可能性を説明しておくと安全です。
また、無料プランで動いたからといって、本番でも同じ構成で十分とは限りません。試作では利用者が1〜2人でも、本番では複数人が毎日入力し、履歴が増え、問い合わせ対応も必要になります。無料プランは機能確認の場として使い、本番判断は業務影響と運用体制で決める方が現実的です。
4. Proプランを検討するタイミング
Proプランを検討するタイミングは、単にデータ量が増えたときだけではありません。
本番運用として使う、顧客の業務データを扱う、継続的に稼働させる、保守対象にする、という段階になったらProプランを検討しやすくなります。
たとえば、次のようなケースです。
- 顧客向けに納品する
- 業務停止すると困る
- 毎日または毎週使う
- 顧客データや取引データを保存する
- バックアップを重視したい
- ログを確認したい
- 無料Projectのpauseを避けたい
- 複数人で管理する
- 利用量が増える見込みがある
- Supabaseのサポートも考慮したい
Proプランにすると、無料プランより本番運用向けの機能や枠が増えます。
ただし、Proプランにしたからといって、すべての費用が月額25ドルに収まるとは限りません。
Project数、Computeサイズ、ストレージ、帯域、追加機能、利用量によって費用が増える可能性があります。
Supabase公式のBilling FAQでは、Paid Organization内で複数Projectを動かす場合、追加ProjectのCompute費用が増える例が説明されています。
そのため、顧客へ見積を出すときは、次のように説明すると認識違いを減らせます。
- Supabase公式利用料は別途発生する
- 公式料金は変更される可能性がある
- Project数や利用量に応じて追加費用が出る可能性がある
- 開発費や保守費はSupabase利用料とは別に考える
- 本番運用では無料プラン前提にしない方が安全
Proプランは、GAS + Supabaseを顧客向け業務アプリとして運用する場合の現実的な出発点になりやすいです。
ただし、顧客数が増える、Projectを分ける、データ量が増える、サポート要件が強くなる場合は、TeamやEnterprise、または別の構成も含めて検討する必要があります。
Proプランを検討する段階では、料金だけでなく責任分界も整理します。Supabaseの契約名義を顧客にするのか、開発者側が管理するのかで、請求、権限、解約、データ引き渡しの扱いが変わります。顧客名義であれば支払いと所有権は分かりやすい一方、設定変更の支援が必要になることがあります。
開発者側のOrganizationで顧客Projectを管理する場合は、初期導入は進めやすい反面、顧客が解約したときのデータ返却、管理者権限の引き渡し、請求の按分を決めておく必要があります。小規模案件では曖昧にしがちですが、顧客データを扱うなら重要な項目です。
本番運用に入る前には、利用量の見込みも確認します。登録件数、添付ファイルの有無、画像保存、ログ保持期間、月間利用者数、API呼び出し頻度などです。正確な予測は難しくても、費用が増える要因を顧客と共有しておくことで、後から追加費用が出たときに説明しやすくなります。
5. 顧客ごとにProjectを分ける考え方
複数顧客向けにGAS + Supabaseの業務アプリを提供する場合、顧客ごとにProjectを分けるかどうかが重要です。
顧客別Project運用とは、顧客A用のSupabase Project、顧客B用のSupabase Project、顧客C用のSupabase Projectというように、顧客ごとに環境を分ける考え方です。
この方法には、分かりやすいメリットがあります。
- 顧客ごとにデータを分離しやすい
- 障害や設定変更の影響範囲を分けやすい
- バックアップや復旧を顧客単位で考えやすい
- 顧客別に契約や請求を説明しやすい
- 顧客別のカスタマイズに対応しやすい
- 解約時にデータ削除や引き渡しを整理しやすい
一方で、Projectを分けると管理対象も増えます。
- Projectごとの初期設定が必要
- APIキーや環境設定の管理が増える
- RLSや権限設定の確認が増える
- バックアップやログ確認の対象が増える
- ProjectごとのCompute費用が増える
- 顧客ごとの更新作業が必要になる
同じProject内で複数顧客のデータを分ける方法もあります。
この場合、Project数を抑えられる一方で、テーブル設計、RLS、顧客IDによる分離、管理画面の権限制御を慎重に設計する必要があります。
データ分離の説明しやすさを優先するなら、顧客別Projectが分かりやすいです。
費用や管理効率を優先するなら、1つのProject内で顧客データを分ける選択肢もあります。
ただし、顧客情報や取引情報を扱う場合は、誤表示やデータ混在のリスクを軽く見ない方がよいです。
顧客別Projectにするかどうかは、費用だけでなくデータ分離の説明しやすさで判断します。顧客ごとに契約、データ、バックアップ、解約手続きを分けたい場合は、Projectを分けた方が説明しやすくなります。特に、顧客が自社データの保管場所や削除方法を気にする場合は、分離単位を明確にする価値があります。
同一Project内で顧客データを分ける場合は、顧客IDによる分離、RLS、管理画面の権限、バックアップからの復旧単位を慎重に考えます。設計が甘いと、ある顧客のデータが別顧客の画面に出るリスクがあります。料金は抑えられても、設計とテストの負担は増えると考えるべきです。
見積時には、顧客別Project案と同一Project案の違いを簡単に示すと判断しやすくなります。前者は分離が明確だがProject管理と費用が増える。後者は費用を抑えやすいが権限設計と検証が重要になる。このように説明すると、顧客も価格だけでなくリスクを含めて選びやすくなります。
6. 見積・保守費に入れておきたい項目
GAS + Supabaseの見積では、Supabaseの月額利用料だけを記載しても不十分です。
実際には、初期構築と継続運用の両方で作業が発生します。
初期構築では、次のような作業があります。
- Supabase Organization作成
- Project作成
- テーブル設計
- RLSや権限設計
- APIキーや環境設定の管理
- GASからSupabaseへの接続実装
- エラー処理
- ログ設計
- バックアップ方針の整理
- 顧客別設定
- 動作確認
- 操作説明
保守では、次のような作業があります。
- エラー発生時の一次確認
- Supabase利用量の確認
- ProjectやAPIキー設定の確認
- RLSや権限設定の確認
- バックアップ状況の確認
- Google側とSupabase側の仕様変更確認
- 軽微な設定変更
- 顧客からの問い合わせ対応
- 追加改修の見積
顧客へ説明するときは、公式利用料と開発・保守費を分けて見せると分かりやすくなります。
たとえば、次のような分け方です。
- Supabase公式利用料
- GAS + Supabase初期開発費
- DB設計・権限設計費
- 顧客別Project初期設定費
- 月額保守費
- 追加改修費
- 緊急対応費
Supabaseの利用料は、公式料金ページに基づく外部サービス費です。
一方で、DB設計、GAS連携、保守、障害対応は開発者側の作業費です。
この2つを分けておかないと、顧客が「Supabaseは月25ドルなのに、なぜ保守費が必要なのか」と感じやすくなります。
実際には、Supabaseを契約するだけで業務アプリが保守されるわけではありません。
顧客の業務データを安全に扱うためには、設計、設定、監視、確認、問い合わせ対応が必要です。
保守費には、月次で必ず大きな改修をするという意味ではなく、運用中の確認と一次対応の費用という意味があります。たとえば、エラー通知の確認、APIキーや権限設定の確認、利用量の簡単な確認、顧客からの問い合わせ対応、軽微な設定変更などです。
追加改修費とは分けておく必要があります。新しい画面、帳票、テーブル、集計条件、顧客別カスタマイズ、外部サービス連携は、既存運用の保守ではなく機能追加です。保守費の中に含めすぎると、顧客は安く感じるかもしれませんが、作り手側の負担が大きくなり、長期的に続けにくくなります。
見積書には、公式利用料、初期構築費、月額保守費、追加改修費の考え方を分けて書くとよいです。外部サービス費はSupabaseの料金改定や利用量で変わる可能性があり、開発・保守費は作業範囲で変わる、という違いを明確にできます。
7. 無料プラン前提で本番運用しない方がよいケース
無料プランを本番運用に使うかどうかは、業務の重要度で判断します。
次のようなケースでは、無料プラン前提にしない方が安全です。
- 顧客に納品する業務アプリ
- 毎日使う業務アプリ
- 業務停止すると売上や対応に影響する
- 顧客情報や取引情報を保存する
- 複数人が継続的に使う
- バックアップが重要
- 障害時にすぐ確認したい
- データ量や利用量が増える見込みがある
- 長期保守を前提にしている
- 顧客へ継続利用を約束する
無料プランは、試すには便利です。
しかし、業務アプリとして顧客に提供する場合は、無料プランの制限、pause、サポート、バックアップ、利用量超過時の扱いを説明しておく必要があります。
特に顧客向けツールでは、「無料で運用できる」という言い方をすると、後で有料化が必要になったときに説明しにくくなります。
最初から「試作は無料プラン、本番運用はPro以上を想定」と伝えておく方が安全です。
また、無料プランからProプランへ移行する場合も、誰のOrganizationで運用するか、支払い方法を誰が持つか、請求書や税金をどう扱うかを決めておく必要があります。
顧客自身のOrganizationで運用するのか、開発者側のOrganizationで顧客別Projectを管理するのかによって、請求、保守、権限、解約時の対応が変わります。
無料プラン前提で本番運用しない方がよい理由は、単に制限があるからだけではありません。顧客に提供する業務アプリでは、止まったときに誰が確認するのか、データが増えたときにどう対応するのか、バックアップをどう扱うのか、という運用責任が発生します。無料プランでは、その責任を説明しにくくなることがあります。
特に、請求、発注、顧客情報、作業履歴のようなデータは、試作用の扱いにしない方が安全です。もし無料枠の制限やProject停止の影響で業務が止まると、月額費用を抑えた以上の損失が出る可能性があります。顧客にとって重要な業務ほど、本番運用の費用を最初から見込むべきです。
ただし、すべての案件で最初から高いプランを選ぶ必要はありません。試作、検証、PoCでは無料プランを使い、本番化の判断時にPro以上を検討する、という段階分けが現実的です。重要なのは、無料プランを「永続的な本番前提」として説明しないことです。
8. 顧客説明で使いやすい整理
顧客へ説明するときは、細かい料金表をいきなり見せるより、運用パターンで整理すると伝わりやすくなります。
たとえば、次の3パターンです。
- 試作: Free Planで小さく検証する
- 小規模本番: Pro Planで1顧客または少数Projectを運用する
- 複数顧客運用: 顧客別Projectまたは顧客別Organizationを検討する
試作では、まずGASとSupabaseの連携が業務に合うか確認します。
小規模本番では、Pro Planを前提に、バックアップ、ログ、保守、問い合わせ対応も含めて考えます。
複数顧客運用では、顧客ごとにProjectを分けるか、同じProject内でデータを分けるかを決めます。
このとき、料金だけでなく、運用リスクも一緒に説明します。
- データ分離を優先するなら顧客別Project
- 費用を抑えるなら同一Project内で顧客ID分離
- 権限設計が複雑ならProject分離を検討
- 顧客ごとに契約や請求を分けるならProjectやOrganizationも分ける
- 将来の解約やデータ引き渡しを考えるなら分離単位を明確にする
GAS + Supabaseの提案では、初期費用だけでなく、月額の外部サービス費と保守費を最初から分けて説明することが大切です。
また、料金の説明では、公式利用料が変わる可能性を明記します。Supabaseの料金や制限は公式ページが正であり、記事や提案資料の金額は確認日時点の目安です。顧客に提示するときは、契約前に公式ページを再確認する前提にします。
9. 見積前に確認するチェックポイント
見積前には、顧客の業務規模と運用方法を確認します。
まず、誰のOrganizationでSupabaseを契約するのかを決めます。顧客名義にするのか、開発者側で管理するのかによって、支払い、権限、解約、保守の扱いが変わります。
次に、Projectを顧客ごとに分けるかを決めます。顧客別Projectにするならデータ分離は説明しやすくなりますが、Projectごとの設定、Compute、バックアップ確認、ログ確認が増えます。同一Projectで分けるなら、RLSと顧客ID分離の設計が重要になります。
さらに、無料プランを試作だけに使うのか、本番前提にするのかを決めます。顧客向け本番運用では、無料プラン前提にせず、Pro以上を想定した説明にしておく方が安全です。
最後に、公式利用料と開発・保守費を分けます。Supabaseへ支払う費用、GAS + Supabaseの初期構築費、月額保守費、追加改修費を分けて提示すると、顧客が費用構造を理解しやすくなります。
10. まとめ
GAS + Supabaseは、スプレッドシートだけでは扱いにくくなった業務データを、外部DBとして管理する現実的な構成です。
ただし、顧客向けに提案する場合は、Supabaseの料金目安と運用方法を先に整理しておく必要があります。
2026年5月14日時点の公式情報では、SupabaseにはFree、Pro、Team、Enterpriseのプランがあり、Freeは試作や小規模利用向け、Proは本番運用の出発点になりやすいプランです。
ただし、料金や制限は変更される可能性があります。
また、Proプランの月額だけでなく、Project数、Compute、ストレージ、帯域、バックアップ、ログ、追加機能、保守対応まで含めて考えることが大切です。
顧客ごとにProjectを分けると、データ分離や解約時の整理はしやすくなります。
一方で、Project数が増えるほど、Compute費用や管理作業も増えます。
そのため、見積時には、Supabase公式利用料、初期開発費、DB設計費、顧客別Project設定費、月額保守費、追加改修費を分けて説明すると分かりやすくなります。
GAS + Supabaseは、無料プランだけで本番運用するものではなく、試作から本番へ移る段階で料金と保守を整理する構成として考えると、安全に提案しやすくなります。
次の記事では、Supabase無料プランとProプランの制限、またはスプレッドシート管理からDB管理へ移行する手順を、より具体的に整理します。
Your Message