GASのスプレッドシート管理をDB化する手順：Supabase移行で考えるデータ設計・移行・運用
GAS（Google Apps Script）とスプレッドシートで作った業務アプリは、最初の業務改善にはとても便利です。
入力フォーム、一覧画面、メール通知、PDF作成、進捗管理、日報入力、請求書送信など、小規模な業務であれば、スプレッドシートをデータ置き場にするだけでも十分に役立ちます。
一方で、データ量が増える、複数人が同時に使う、検索条件が増える、履歴管理や権限管理が必要になると、スプレッドシートだけでは運用が苦しくなることがあります。
そのような段階で選択肢になるのが、Supabaseなどの外部DBへ移行する方法です。
ただし、スプレッドシート管理をDB化するときは、いきなり全部を作り直す必要はありません。
業務データの本体はDBへ移し、スプレッドシートは設定表、確認用一覧、移行前のバックアップとして残す方法もあります。
この記事では、GAS + スプレッドシートで始めた業務アプリを、Supabaseなど外部DBへ移すときの考え方、手順、注意点を実務目線で整理します。
コードの細かい実装ではなく、顧客説明、要件整理、移行計画に使いやすい内容を中心に解説します。
1. この記事で伝えたいこと
スプレッドシート管理からDB管理へ移行するときに大切なのは、「スプレッドシートをやめること」ではありません。
大切なのは、業務データの役割を整理することです。
スプレッドシートは、一覧で見やすく、担当者が直接確認しやすい便利なツールです。
しかし、業務アプリのデータベースとして使い続けると、次のような問題が出やすくなります。
- 行数が増えて処理が遅くなる
- 検索や集計が複雑になる
- 複数人の同時更新で競合が起きる
- 変更履歴を正確に残しにくい
- 顧客別や部署別の権限管理が難しい
- 誤って列やシートを変更するとGASが壊れる
- データの整合性を保ちにくい
一方で、DBへ移行すると、テーブル、主キー、リレーション、検索、履歴、権限管理を考えやすくなります。
SupabaseはPostgresをベースにしたサービスで、DBスキーマからAPIを扱いやすく、Row Level Security（RLS）で行単位のアクセス制御も検討できます。
ただし、DB化すれば自動的に安全になるわけではありません。
テーブル設計、ID設計、権限設計、バックアップ、移行テスト、本番切替、保守体制を決める必要があります。
この記事で伝えたいことは、次の3つです。
- スプレッドシートは便利だが、業務データの本体としては限界が出ることがある
- DB移行では、データ棚卸し、ID設計、テーブル分割、テスト移行が重要
- 移行後もスプレッドシートを設定表や確認用一覧として残す選択肢がある
2. DB移行を検討するタイミング
DB移行を検討するタイミングは、単に行数が増えたときだけではありません。
実務では、次のような状態になったら検討しやすいです。
- スプレッドシートの表示や検索が重い
- GASの処理時間が長くなっている
- 同じデータを複数画面から更新している
- 過去履歴を消せず、ファイルが肥大化している
- 顧客別・部署別にデータを分けたい
- 管理者と一般利用者で見える範囲を分けたい
- 承認履歴や変更履歴を残したい
- データの重複や表記ゆれが増えている
- 顧客向けに本格運用したい
- 将来的に別システムやスマホアプリとも連携したい
Google Sheetsには保存可能なセル数などの制限があります。
ただし、実務では公式上限に達する前に、体感速度、検索、集計、権限管理、保守の面で限界を感じることが多いです。
また、Apps Scriptにも実行時間、トリガー、URL Fetch、メール送信などの割り当てや制限があります。
スプレッドシートの読み書きを毎回大量に行う設計では、データが増えるほど処理が遅くなりやすいです。
DB移行を検討する目安は、「スプレッドシートに入らないか」ではなく、「業務アプリとして安全に運用できるか」です。
顧客データ、契約情報、請求情報、承認履歴、作業履歴などを長期的に扱う場合は、早めにDB化を検討しておくと後から移行しやすくなります。
DB移行を検討する段階では、現在の不満を具体的に書き出します。「シートが重い」だけではなく、どの画面が遅いのか、どの検索が使いにくいのか、どの履歴が追えないのか、どの権限が分けられないのかを整理します。これにより、移行する範囲を決めやすくなります。
たとえば、入力件数は少ないが過去履歴の検索が大変なら、履歴テーブルからDB化する価値があります。逆に、検索や履歴は困っておらず、単に入力画面を整えたいだけなら、スプレッドシートのままGAS画面を改善するだけで十分な場合もあります。
移行判断では、停止時の影響も確認します。請求、発注、顧客対応、現場進捗のように止まると業務に影響するものは、DB化とあわせてバックアップ、エラー通知、復旧手順も考える必要があります。単なる保存先変更ではなく、本番運用の見直しとして扱う方が安全です。
3. いきなり全部移行しない考え方
スプレッドシート管理からDB管理へ移行するとき、いきなり全部を置き換えようとすると失敗しやすくなります。
業務アプリでは、データ保存、画面表示、通知、帳票作成、設定管理、バックアップ、集計など、複数の役割があります。
そのすべてを一度に変えると、影響範囲が大きくなります。
最初は、役割ごとに分けて考えるのが現実的です。
- 業務データの本体はDBへ移す
- 設定値はスプレッドシートに残す
- 管理者向け確認一覧だけスプレッドシートに出力する
- PDF作成やメール送信はGASに残す
- バックアップ用に移行前シートを保管する
- 集計だけDBから取得して表示する
たとえば、発注管理なら、発注データと明細データはSupabaseに移し、メール文面や保存先フォルダIDなどの設定値はスプレッドシートに残すことができます。
請求書送信なら、請求先、請求履歴、送信履歴はDBに移し、PDFテンプレートや送信文面はGASとスプレッドシートで管理する形もあります。
進捗管理なら、案件、工程、作業履歴、写真情報をDBに移し、管理者向けの簡易レポートだけスプレッドシートに出力することもできます。
このように、DB化は「スプレッドシートを捨てる作業」ではありません。
スプレッドシートが得意な部分は残し、DBが得意な部分へ業務データの本体を移す、と考えると進めやすくなります。
段階移行では、まず「正のデータ」を1つ決めます。DBへ移したデータはDBを正式な保存先にし、スプレッドシートは確認用や出力用にします。同じデータをDBとスプレッドシートの両方で編集できる状態にすると、どちらが最新なのか分からなくなります。
また、すべての利用者を一度に切り替えない方法もあります。管理者だけ先にDB版の画面を使う、特定部署だけで試す、過去データ参照だけDB化する、といった段階を作ると、現場の混乱を抑えられます。DB移行は、技術作業だけでなく利用者の慣れも含めて計画する必要があります。
4. スプレッドシートの列をDBテーブルに整理する
DB移行で最初に行うべきことは、スプレッドシートの列をそのままテーブルに移すことではありません。
まず、今のシートにどんな意味のデータが混ざっているかを整理します。
スプレッドシートでは、1つのシートにいろいろな情報が並びがちです。
たとえば、発注管理シートに次のような列があるとします。
- 発注番号
- 発注日
- 顧客名
- 顧客メールアドレス
- 商品名
- 数量
- 単価
- 金額
- 担当者
- ステータス
- 送信日時
- メモ
このまま1つのDBテーブルにすることもできますが、運用が進むと重複や更新漏れが起きやすくなります。
顧客情報、商品情報、発注情報、発注明細、送信履歴は、本来は別の意味を持つデータです。
DB化するときは、次のように分けることを検討します。
- 顧客テーブル
- 商品テーブル
- 発注テーブル
- 発注明細テーブル
- 送信履歴テーブル
- ステータス履歴テーブル
もちろん、最初から細かく分けすぎる必要はありません。
小規模な業務では、まず発注テーブルと発注明細テーブルだけに分けるなど、運用に必要な範囲から始めるのが現実的です。
重要なのは、同じ情報を何度も入力しないことです。
顧客名やメールアドレスが複数行に重複している場合、どれが正しい情報なのか分からなくなります。
DB移行前には、重複、表記ゆれ、空欄、不要列、古いステータスを整理しておく必要があります。
テーブル設計では、シートの列をそのまま移すより、業務上の意味で分けることを優先します。顧客、案件、明細、履歴、添付ファイル、通知履歴は、それぞれ更新頻度や使い方が異なります。1つの大きなテーブルにまとめると、最初は簡単でも、後から検索や更新が難しくなります。
ただし、細かく分けすぎると、GAS側の実装や画面表示が複雑になります。小規模な移行では、まず本体テーブルと履歴テーブルを分ける程度から始めても構いません。重要なのは、将来分けたいデータを意識して、IDや列名を整理しておくことです。
移行前には、データの型も確認します。日付が文字列として入っている、金額にカンマや円マークが混ざっている、担当者名の表記が揺れている、ステータスが自由入力になっている、といった状態はよくあります。DBへ移す前に、日付、数値、選択肢、メールアドレス、空欄の扱いを決めます。
特にステータスや区分は、自由入力のままだと移行後の検索や集計が難しくなります。「完了」「済」「対応済み」が混在している場合は、移行前に正式な選択肢へ寄せます。DB化は、データを入れ替えるだけでなく、業務データの表記ルールを整える機会でもあります。
5. 移行前に決めること
DB移行の前には、技術的な作業より先に決めることがあります。
ここを曖昧にしたまま移行すると、DB化した後に設計をやり直すことになります。
移行前に決めたいのは、次のような項目です。
- どのデータをDBへ移すか
- どのデータをスプレッドシートに残すか
- 主キーやIDをどう設計するか
- 顧客、案件、明細、履歴をどう分けるか
- 既存データの重複をどう扱うか
- 過去データをすべて移すか、一部だけ移すか
- 移行前のバックアップをどこに残すか
- テスト移行を何回行うか
- 本番切替の日時をいつにするか
- 切替後に旧シートへ入力できないようにするか
- 権限管理をどこまで行うか
- 障害時にどこから復旧するか
特に重要なのはID設計です。
スプレッドシートでは、行番号や発注番号をそのまま識別子として使っていることがあります。
しかし、行番号は並び替えや削除で変わるため、DBの主キーには向きません。
DB移行では、顧客ID、案件ID、発注ID、明細IDのように、変わらない識別子を設計する必要があります。
また、過去データをどこまで移すかも重要です。
すべての過去データを移すと安心ですが、古いデータに表記ゆれや欠損が多い場合、移行作業が重くなります。
実務では、「過去1年分だけDBへ移す」「過去データは参照用シートとして残す」「集計に必要なデータだけ移す」といった判断もあります。
移行前には、バックアップの形式も決めます。元のスプレッドシートをコピーして残すだけでよいのか、CSVとして保存するのか、Drive上に日付付きで保管するのかを決めます。移行後にデータ不整合が見つかったとき、どの時点のデータに戻れるかが重要になります。
権限設計も事前に整理します。管理者、一般利用者、承認者、外部ユーザーがそれぞれ何を見てよいのか、どの操作をしてよいのかを表にします。Supabaseを使う場合は、RLSやAPIキーの扱いも関係するため、画面側だけでなくDB側で守る範囲を考えます。
6. GASからSupabaseへ移す基本手順
GASからSupabaseへ移行する基本手順は、次のように考えると整理しやすいです。
1. 現在のスプレッドシートを棚卸しする
2. 必要なテーブルを決める
3. IDとリレーションを決める
4. 不要データや重複を整理する
5. Supabaseにテーブルを作る
6. RLSや権限方針を決める
7. テストデータを移行する
8. GASからSupabaseへ登録・取得する処理を作る
9. 一覧画面や検索画面を確認する
10. 本番データを移行する
11. 切替後の動作を確認する
12. 旧スプレッドシートをバックアップとして保管する
この流れで大切なのは、いきなり本番データを移さないことです。
まず少量のテストデータで、テーブル設計、登録処理、取得処理、検索処理、権限設定を確認します。
その後、本番データのコピーでテスト移行を行い、件数、金額、ステータス、履歴が合っているかを確認します。
本番切替では、旧スプレッドシートへの入力を止める時間を決めておく必要があります。
切替中に旧シートとDBの両方へ入力されると、どちらが正しいデータなのか分からなくなります。
そのため、切替作業では次の点を決めておくと安全です。
- 入力停止時間
- 移行対象データの範囲
- 移行後の件数確認
- 移行後の動作確認
- 問題があった場合の戻し方
- 顧客や利用者への案内
テスト移行では、件数だけでなく中身も確認します。移行前後の総件数、ステータス別件数、金額合計、顧客別件数、未完了件数などを比較します。件数が合っていても、日付や金額の形式が変わっている場合があるため、重要項目はサンプルで目視確認します。
GAS側の処理も、登録、更新、検索、PDF作成、メール送信、履歴登録を分けて確認します。DB登録は成功したがメール送信で失敗した場合、再実行すると二重登録にならないか。メール送信後に履歴更新で失敗した場合、送信済みと判断できるか。こうした障害時の流れをテストしておくと、本番切替後に落ち着いて対応できます。
本番移行では、旧シートへの入力停止を明確にします。利用者が移行中に旧シートへ入力すると、移行済みデータとの差分が発生します。切替前に「この時間以降は旧シートへ入力しない」と案内し、必要であれば旧シートを閲覧専用にします。
切替後は、しばらく旧スプレッドシートを削除せず、参照用として残します。ただし、利用者が誤って旧シートを更新しないよう、名前や権限を変更します。「旧データ参照用」「更新禁止」などの表記を入れると、運用上の誤解を減らせます。
7. 移行後もスプレッドシートを残す使い方
DBへ移行した後も、スプレッドシートを完全に使わなくする必要はありません。
むしろ、スプレッドシートは補助的に残すと便利なことがあります。
たとえば、次のような使い方です。
- 設定値の管理
- メール文面の管理
- PDFテンプレートの管理
- 管理者向け確認一覧
- 月次集計の出力先
- 顧客への提出用CSVの作成
- 移行前データのバックアップ
- 一時的なチェックリスト
業務データの本体はDBに置き、スプレッドシートは見やすい画面や設定表として使う形です。
この構成にすると、スプレッドシートの便利さを残しながら、データ管理の中心をDBへ移せます。
ただし、スプレッドシートに残す範囲は明確にする必要があります。
利用者がスプレッドシートを編集してもDBに反映されない場合、認識違いが起きます。
そのため、次のように役割を分けて説明するとよいです。
- DB: 正式な業務データ
- スプレッドシート: 設定表、確認用、出力用
- GAS: 画面、通知、PDF作成、DB連携
この役割分担を決めておくと、顧客にも説明しやすくなります。
移行後にスプレッドシートを残す場合は、更新方向を決めます。DBからスプレッドシートへ出力するだけなのか、スプレッドシートの設定値をGASが読むのか、スプレッドシートで編集した内容をDBへ反映するのかで、設計の難易度が変わります。
確認用一覧として残すなら、DBから定期的に出力し、シート側は編集禁止にするのが分かりやすいです。設定表として残すなら、通知先、メール文面、保存先フォルダID、表示順など、運用担当者が変更してよい項目に絞ります。
スプレッドシートからDBへ反映する双方向運用は、慎重に扱います。一見便利ですが、どちらが正のデータなのか分かりにくくなり、競合や上書きの原因になります。どうしても必要な場合は、反映ボタン、確認画面、更新履歴を用意し、無意識に同期されないようにします。
8. 移行時の注意点
DB移行では、データを移すことだけに注目しすぎない方がよいです。
実務では、移行前後の運用ルールが重要です。
注意したいのは、次の点です。
- 移行前のバックアップを必ず残す
- 移行前後で件数を確認する
- 金額やステータスなど重要項目を照合する
- 旧シートへの入力停止タイミングを決める
- 本番切替後の問い合わせ先を決める
- 権限設定をテストする
- RLSを有効にするテーブルを確認する
- APIキーやService Roleキーを安全に扱う
- エラー時の再実行方法を決める
- 顧客へ切替日時と影響範囲を説明する
Supabaseでは、DBスキーマに応じてAPIを扱いやすくできます。
一方で、公開されるテーブルやAPIアクセスでは、RLSや権限設定を確認する必要があります。
特に、ブラウザやGASからAPIを呼び出す構成では、キーの扱い、ユーザー権限、顧客別データの分離を慎重に考える必要があります。
また、移行作業中は、旧データと新データが一時的に並行して存在します。
この期間に入力や更新が重なると、差分確認が難しくなります。
移行計画では、入力停止、テスト移行、本番移行、切替後確認、戻し方をセットで決めておくことが大切です。
APIキーの扱いも注意点です。GASからSupabaseへ接続する場合、キーをソースコードへ直接書かず、スクリプトプロパティなどで管理します。HTML画面へ秘密情報を渡さないことも重要です。公開可能なキーを使う場合でも、RLSや権限設定が甘ければ不要なデータ参照につながる可能性があります。
移行後のエラー通知も決めておきます。DB登録失敗、検索失敗、メール送信失敗、PDF作成失敗、権限エラーなどを、誰にどのように通知するかを整理します。利用者には分かりやすいメッセージを出し、管理者にはログを確認できるようにします。
戻し方も事前に決めます。切替直後に重大な問題が出た場合、旧スプレッドシートへ戻すのか、DB側を修正して続行するのか、入力停止を延長するのかを決めておきます。戻し方がない移行は、現場にとって不安が大きくなります。
9. 顧客説明で使いやすい整理
顧客へDB移行を説明するときは、技術用語だけで話すと伝わりにくくなります。
次のように、業務上のメリットと注意点に分けて説明すると分かりやすいです。
DB化で期待できることは、次のような点です。
- データが増えても管理しやすくなる
- 検索や絞り込みを設計しやすくなる
- 履歴管理を作りやすくなる
- 顧客別や担当者別の権限管理を考えやすくなる
- 複数画面から同じデータを扱いやすくなる
- 将来の拡張に備えやすくなる
一方で、注意点もあります。
- 初期設計が必要になる
- 移行作業が必要になる
- テスト移行と本番切替が必要になる
- Supabaseなど外部サービスの料金が発生する場合がある
- 保守や障害対応の範囲を決める必要がある
- スプレッドシートのように自由編集できる運用とは変わる
顧客説明では、「DB化すると便利になります」だけでなく、「移行前にデータ整理と運用ルール決めが必要です」と伝えることが重要です。
また、移行後もスプレッドシートを確認用や設定用として残せると説明すると、顧客の不安を減らせます。
顧客説明では、移行の段階を見せると理解されやすくなります。まず現状のスプレッドシートを整理し、次にテーブル設計を行い、テスト移行で件数や中身を確認し、本番切替で入力先をDBへ変える、という流れです。段階が見えると、顧客側も何を準備すべきか分かります。
また、移行後に現場の操作がどう変わるのかを説明します。これまでシートに直接入力していたのか、GASの画面から入力するのか、確認用の一覧はどこで見るのか、過去データはどこに残るのかを具体的に伝えます。DB化のメリットだけでなく、日々の操作が変わる点を説明することが大切です。
費用面では、DB設計、移行作業、テスト、本番切替、保守を分けます。単なるデータコピーではなく、業務データの整理、権限設計、移行検証、障害時対応まで含む作業であることを伝えます。これにより、顧客も移行費用の意味を理解しやすくなります。
10. 小さく始める移行ステップ
スプレッドシートからDBへ移行するときは、小さく始めるステップを決めておくと進めやすくなります。
最初に、現在のシートを棚卸しします。どの列が正式なデータなのか、どの列が集計用なのか、どの列がGAS内部で使われているのかを整理します。不要列、古いステータス、表記ゆれ、重複データもこの段階で確認します。
次に、移行対象を絞ります。すべてを一気に移すのではなく、履歴が増え続けるデータ、検索に時間がかかるデータ、権限管理が必要なデータから選びます。設定値や確認用一覧はスプレッドシートに残しても構いません。
その後、少量のデータでテスト移行を行います。テーブル設計、ID、登録処理、検索処理、権限設定、エラー時の挙動を確認します。テスト移行で問題が見つかったら、シートのデータ整理やテーブル設計へ戻ります。
本番切替前には、利用者への案内、入力停止時間、バックアップ、戻し方を決めます。切替後は、件数確認、重要項目の照合、画面操作、メール送信、PDF作成、権限確認を行います。
最後に、移行後の運用を整えます。旧シートを参照用として残すのか、設定表として使うのか、DBから確認用一覧を出力するのかを決めます。エラー通知、バックアップ、保守担当も明確にしておくと、DB化後の運用が安定します。
11. まとめ
GASとスプレッドシートで始めた業務アプリは、小規模な業務改善にはとても有効です。
しかし、データ量が増える、利用者が増える、検索や履歴管理が複雑になる、顧客別や部署別の権限管理が必要になると、スプレッドシートだけでは限界が見えてきます。
その段階では、Supabaseなどの外部DBへ業務データの本体を移すことを検討できます。
DB移行で大切なのは、いきなり全部を作り直さないことです。
まずデータを棚卸しし、ID設計、テーブル分割、重複整理、テスト移行、本番切替、バックアップ確認、権限設計を順番に進めます。
移行後も、スプレッドシートは設定表、確認用一覧、出力先、バックアップとして残せます。
GASは画面、通知、PDF作成、Googleサービス連携を担当し、Supabaseはデータ保存、検索、履歴、権限管理を担当する形にすると、役割が分かりやすくなります。
DB化は単なる技術変更ではなく、業務データの扱い方を整理する作業です。
顧客へ提案する場合は、移行のメリットだけでなく、移行手順、テスト、本番切替、保守範囲、外部サービス費まで説明しておくと安全です。
次の記事では、GAS案件の見積・保守契約の作り方を、より具体的に整理します。
Your Message