GAS + Supabaseで業務アプリを作る考え方：スプレッドシート管理から外部DBへ広げる構成例

GAS（Google Apps Script）は、GoogleスプレッドシートやGmail、Googleドライブと組み合わせて、小さな業務ツールを作るときに便利です。

発注フォーム、請求書送信、進捗管理、日報入力、メール通知など、スプレッドシートを中心にした業務であれば、低コストで始めやすく、現場にも説明しやすい構成になります。

一方で、データ量が増える、複数人が同時に使う、履歴を長期間残す、権限を細かく分ける、といった要件が出てくると、スプレッドシートだけでは扱いづらくなることがあります。

そのようなときに選択肢になるのが、GASとSupabaseを組み合わせる構成です。

GASを画面や業務処理に使い、Supabaseをデータベースとして使うことで、スプレッドシート中心の管理から一歩進んだ業務アプリを作りやすくなります。

この記事では、GAS + Supabaseで業務アプリを作る考え方を、実務目線で整理します。細かいコードや料金比較ではなく、役割分担、構成例、導入時の注意点を中心に解説します。

1. この記事で伝えたいこと

GAS + Supabaseの構成で大切なのは、「GASをやめてSupabaseに置き換える」という考え方ではありません。

GASが得意な部分はそのまま活かし、スプレッドシートでは扱いにくくなってきたデータ管理の部分をSupabaseに任せる、という考え方です。

たとえば、GASは次のような処理に向いています。

• GoogleアカウントやGoogle Workspaceとの連携
• Gmail送信
• GoogleドライブへのPDF保存
• スプレッドシートからの一括処理
• HTML Serviceを使った簡易画面
• 定期実行や通知処理

一方で、Supabaseは次のような役割に向いています。

• 業務データの保存
• 検索や絞り込み
• 履歴データの管理
• 複数テーブルの関連付け
• 権限ルールの整理
• 外部アプリや将来のWebアプリとの連携

つまり、GAS + Supabaseは、GASの手軽さとGoogle連携を残しながら、データ管理をDBへ広げる構成です。

最初から大規模なシステムを作るのではなく、スプレッドシートで始めた業務を、必要に応じて外部DBへ移していくための現実的な選択肢として考えると分かりやすいです。

2. GASとSupabaseの役割分担

GASとSupabaseを組み合わせる場合、まず決めるべきなのは役割分担です。

すべてをGASで処理しようとすると、スプレッドシートの読み書き、画面表示、メール送信、履歴管理、検索、権限管理までGAS側に集まりすぎます。

逆に、すべてをSupabase側に寄せようとすると、Googleサービスとの連携や既存のスプレッドシート運用を活かしにくくなることがあります。

実務では、次のように分けると整理しやすいです。

• GAS: 画面、入力受付、メール送信、PDF作成、Googleサービス連携
• Supabase: データ保存、検索、履歴、マスタ管理、複数テーブル管理
• スプレッドシート: 設定表、簡易出力、確認用一覧、運用担当者向けの補助画面

たとえば、発注管理アプリであれば、発注データや明細データはSupabaseに保存し、GASは入力画面、PDF発注書の作成、メール通知を担当します。

進捗管理アプリであれば、案件、工程、作業履歴、写真情報などはSupabaseに保存し、GASは現場入力画面や管理者向け一覧、遅延通知を担当します。

このように役割を分けると、GAS側の処理が肥大化しにくくなり、データ量が増えたときにも見直しやすくなります。

3. スプレッドシートだけで限界が出やすい業務

スプレッドシートは、業務改善の入口としてとても使いやすいツールです。

表形式でデータを見られるため、利用者にも説明しやすく、管理者が直接修正しやすいというメリットがあります。

ただし、次のような状態になると、スプレッドシートだけで運用し続けるのが難しくなることがあります。

• 行数が増えて検索や表示が遅くなる
• 複数人が同時に編集して競合する
• 入力画面と管理画面を分けたい
• 履歴データを長期間残したい
• 顧客別、拠点別、担当者別に権限を分けたい
• 明細データや関連テーブルが増えてきた
• 外部サービスや別アプリから同じデータを使いたい
• バックアップや復旧手順を整理したい

特に、業務データが「一覧表」ではなく「複数の関連データ」になってくると、スプレッドシート管理は複雑になりやすいです。

たとえば、発注管理では、発注ヘッダー、発注明細、取引先マスタ、商品マスタ、送信履歴が必要になることがあります。

進捗管理では、案件、工程、作業者、作業履歴、写真、コメント、通知履歴を分けて管理したくなることがあります。

このような場合、スプレッドシートのシートを増やして対応することもできますが、検索、整合性、権限、履歴管理がだんだん難しくなります。

Supabaseのような外部DBを使うと、業務データをテーブルとして整理し、必要な条件で取得しやすくなります。

4. GAS + Supabaseの基本構成

GAS + Supabaseの基本構成は、シンプルに考えると次の流れです。

利用者がGASのWebアプリ画面や入力フォームを開き、入力したデータをGASが受け取ります。GASは必要なチェックや加工を行い、SupabaseのAPIへ登録します。

一覧表示や検索を行う場合は、GASがSupabaseからデータを取得し、HTML画面やスプレッドシートに表示します。

メール送信やPDF作成が必要な場合は、GASがGoogleサービスを使って処理します。

この構成では、次のような流れになります。

• 利用者がGASの画面に入力する
• GASが入力内容を検証する
• GASがSupabaseへデータを登録する
• GASが必要に応じてGmailやGoogleドライブを操作する
• Supabaseに履歴やマスタデータが蓄積される
• 管理者画面や集計画面でSupabaseのデータを参照する

ポイントは、スプレッドシートを完全に捨てる必要はないことです。

たとえば、管理者向けの簡易一覧、設定値、帳票出力用の一時データなどは、スプレッドシートを使い続けても構いません。

ただし、正のデータをどこに置くかは明確にしておく必要があります。

発注データの本体はSupabase、設定値はスプレッドシート、帳票PDFはGoogleドライブ、というように役割を決めておくと、後から保守しやすくなります。

ここで特に重要なのが、「正のデータ」をどこに置くかです。

正のデータとは、業務上の判断や後続処理で基準になる正式なデータのことです。発注管理であれば発注内容、請求管理であれば請求先や請求履歴、進捗管理であれば案件や作業履歴が該当します。

同じ情報をSupabaseとスプレッドシートの両方で編集できる状態にすると、どちらが最新なのか分からなくなります。そのため、Supabaseに移すデータは「正式な保存先」として扱い、スプレッドシートは確認用、出力用、設定用に役割を絞る方が安全です。

たとえば、取引先マスタをSupabaseに置くなら、GASの画面やPDF作成もSupabaseの取引先情報を参照します。スプレッドシートに取引先一覧を出す場合でも、それは編集元ではなく確認用のエクスポートとして扱います。

逆に、メール件名のテンプレート、通知先の固定リスト、表示順のように、運用担当者が少し直すだけの設定値はスプレッドシートに残しても構いません。DB化する対象と、シートに残す対象を分けることが、導入後の混乱を減らします。

5. 具体的な業務アプリ例

GAS + Supabaseは、スプレッドシートだけでは少し重くなってきた業務アプリに向いています。

たとえば、発注管理では、GASで発注入力画面を作り、Supabaseに発注データと明細データを保存します。GASはPDF発注書を作成し、取引先や社内担当者へメール送信します。送信履歴もSupabaseに残しておけば、後から検索しやすくなります。

請求書送信では、請求先、請求履歴、送信履歴、添付ファイル情報をSupabaseに保存できます。GASはPDF作成、メール送信、送信前確認画面を担当します。

進捗管理では、案件、工程、担当者、作業履歴、写真情報をSupabaseで管理し、GASの画面から現場担当者が入力します。管理者は条件を指定して進捗を確認し、遅延案件だけを抽出できます。

日報や作業報告では、作業者ごとの報告、作業内容、写真、承認状況をSupabaseに保存できます。GASは入力画面、通知、日次集計、PDF化を担当します。

在庫や備品管理でも、入出庫履歴、拠点別在庫、担当者、棚卸結果などをDB化すると、スプレッドシートだけで管理するより整理しやすくなります。

これらの業務に共通しているのは、データが増え続けること、履歴が重要であること、一覧表示だけでなく検索や絞り込みが必要になることです。

発注管理では、誰が発注したのか、明細を変更したのか、送信済みなのかを後から確認したくなります。請求書送信でも、送信日時、送信先、エラー有無、再送履歴を残したくなります。履歴が複数行になったり、明細ごとに状態が分かれたりすると、一覧表だけでは管理しづらくなります。

Supabaseを使う場合は、業務の本体データと履歴データを分けて考えられます。発注データ、発注明細、メール送信履歴、ステータス変更履歴を別テーブルにしておけば、画面では必要な情報だけを組み合わせて表示できます。

最初から完璧なデータ設計を目指しすぎず、「増え続ける履歴」「検索したいデータ」「複数人で使うデータ」を優先してDB化し、設定値や一時的な確認表はスプレッドシートに残す進め方が現実的です。

6. 導入時の注意点

GAS + Supabaseは便利な構成ですが、導入時には注意点もあります。

まず、APIキーや接続情報をどこに置くかを決める必要があります。

ブラウザ側に秘密情報を出してはいけません。GAS側でAPI連携を行う場合も、スクリプトプロパティなどを使って管理し、ソースコードに直接書かないようにします。

SupabaseのAPIキーには、用途によって権限の強さが異なるものがあります。公開可能なキーでも、テーブル権限やRLSポリシーが甘ければ、意図しないデータ参照につながります。一方で、service roleやsecret系の強いキーはRLSを迂回できるため、ブラウザや公開リポジトリへ出してはいけません。

GASからSupabaseへ接続する場合も、「GASで実行するから安全」と考えすぎない方がよいです。誰がWebアプリを実行できるのか、HTML側にどこまで値を渡すのかを確認する必要があります。

次に、Supabase側の権限設計が必要です。

Supabaseでは、公開されるテーブルにはRow Level Security（RLS）などのアクセス制御を適切に設定する必要があります。管理者だけが見られるデータ、利用者本人だけが見られるデータ、全員が参照できるマスタなどを分けて考えます。

RLSを有効にしただけでは、業務に合った権限設計が完成するわけではありません。どのロールが、どのテーブルに対して、どの条件で読み取りや更新をできるのかを決める必要があります。Data APIを使う場合は、Postgres側の権限付与とRLSポリシーの両方でアクセス範囲を考えます。

実務では、最初に「誰が何を見てよいか」を表にしておくと整理しやすいです。管理者、一般担当者、承認者、外部取引先などの立場ごとに可否を決め、GAS側の画面制御だけに頼らず、Supabase側でも守る設計にします。

GAS側にも実行時間やURL Fetchの割り当てがあります。

Supabaseを使えばスプレッドシートの読み書きは減らせますが、GASの制限がなくなるわけではありません。大量データを一度に取得する、外部APIを短時間に何度も呼ぶ、といった設計は避ける必要があります。

エラー対応も重要です。

Supabaseへの登録に失敗した場合、どのデータが未登録なのか、再実行してよいのか、利用者にどう通知するのかを決めておきます。メール送信やPDF作成と組み合わせる場合は、DB登録と送信処理の順番も考える必要があります。

特に注意したいのは、二重登録と二重送信です。

たとえば、請求書データをSupabaseへ登録した後にメール送信で失敗した場合、再実行時に同じ請求書をもう一度登録してよいのか、登録済みデータを使ってメールだけ再送するのかを決めておく必要があります。

逆に、メール送信後に履歴登録で失敗した場合、利用者から見ると送信済みなのにシステム上は未送信に見える可能性があります。この状態で単純に再実行すると、同じ相手へ二重送信してしまうかもしれません。

そのため、登録、PDF作成、メール送信、履歴更新の各ステップを分け、処理状態を残す設計が大切です。「受付済み」「PDF作成済み」「送信済み」「送信失敗」のように状態を持たせると、障害時にどこから再開すべきか判断しやすくなります。

導入時には、次の点を確認しておくと安心です。

• 正のデータをどこに置くか
• GAS、Supabase、スプレッドシートの役割
• APIキーや接続情報の管理方法
• Supabase側の権限
• エラー時の記録と通知
• 再実行してよい処理と避けるべき処理
• バックアップやエクスポートの方法
• 保守担当者と変更手順

運用開始後は、通知先、権限、マスタ項目、帳票文言を誰が変更するのかも決めておきます。スプレッドシートに残す設定、Supabaseで管理するマスタ、コード変更が必要な処理を分けておくと、保守費や対応範囲も説明しやすくなります。

7. どんな会社・業務に向いているか

GAS + Supabaseは、最初から大規模な基幹システムを作るための万能構成ではありません。

向いているのは、Google Workspaceを使っていて、スプレッドシート中心の業務改善から少しずつ業務アプリ化したい会社です。

たとえば、次のような場合に検討しやすいです。

• 現在はスプレッドシートで管理している
• 入力者や閲覧者が増えてきた
• 履歴をきちんと残したい
• 検索や絞り込みを速くしたい
• 明細やマスタが増えてきた
• 将来的にWebアプリ化も考えている
• Googleドライブ、Gmail、PDF作成は引き続き使いたい
• 小さく始めて段階的に改善したい

一方で、すでに大規模な業務システムが必要な場合や、厳密な監査要件、複雑な認可、常時高負荷の処理が必要な場合は、GAS中心の構成ではなく、専用のWebアプリや業務システムとして設計した方がよいこともあります。

GAS + Supabaseは、「スプレッドシートだけでは限界があるが、いきなり大規模開発にするほどではない」という場面で使いやすい構成です。

導入判断では、現在の不満がどこにあるのかを分けて考えるとよいです。単に入力フォームを作りたいだけなら、GASとスプレッドシートで十分な場合があります。帳票PDFを作ってメール送信したいだけの場合も、データ量が少なければスプレッドシート中心で問題ないことがあります。

一方で、検索が遅い、過去履歴を残したい、担当者ごとに見える範囲を変えたい、同じデータを複数の画面や別アプリから使いたい、という課題が出ているなら、Supabaseを組み合わせる価値が出てきます。

つまり、GAS + Supabaseは「便利そうだから使う」ものではなく、データ管理がスプレッドシートだけでは重くなってきたときに検討する構成です。

小さく始めるなら、履歴が増え続ける部分だけをSupabaseへ移す方法があります。既存のスプレッドシート運用をすべて置き換えず、検索や履歴管理で困っている部分から切り出す方が、説明しやすくなります。

8. まとめ

GASは、Googleサービスと連携した業務ツールを作るうえで便利な仕組みです。

ただし、データ量、履歴管理、検索、権限、同時利用の要件が増えてくると、スプレッドシートだけで管理するのが難しくなることがあります。

そのような場合、GASを画面や業務処理に使い、Supabaseを外部DBとして使うことで、業務アプリとしての構成を広げやすくなります。

大切なのは、GAS、Supabase、スプレッドシートの役割を分けることです。

GASはGoogle連携、メール送信、PDF作成、簡易画面に強みがあります。Supabaseはデータ保存、検索、履歴管理、複数テーブル管理に向いています。スプレッドシートは設定表や確認用一覧として残すこともできます。

GAS + Supabaseは、スプレッドシート管理から外部DB管理へ段階的に広げたいときの現実的な選択肢です。

最初から複雑に作りすぎず、どのデータをDB化するのか、どの処理をGASに残すのか、どこまで保守するのかを決めながら導入することが大切です。