GASとスプレッドシートだけで作る業務アプリの限界：外部DBを検討すべきタイミング

公開日：2026/05/21

GAS（Google Apps Script）とGoogleスプレッドシートを組み合わせると、比較的低コストで業務アプリを作れます。

入力フォーム、一覧画面、メール通知、PDF作成、進捗管理、日報入力、請求書送信など、小規模な業務改善であれば、スプレッドシートをデータ置き場にする構成はとても使いやすいです。

一方で、スプレッドシートは本格的なデータベースではありません。

最初は問題なく動いていたツールでも、データ量が増える、利用者が増える、検索や集計が複雑になる、顧客別に権限を分けたくなる、といった段階になると、スプレッドシートだけでは運用が苦しくなることがあります。

この記事では、GASとスプレッドシートだけで業務アプリを作る場合の限界について、実務目線で整理します。

「スプレッドシートは使わない方がよい」という話ではありません。

スプレッドシートで十分なケースと、Supabaseなどの外部DBを検討した方がよいケースを分けて考えるための記事です。

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

GASとスプレッドシートの組み合わせは、業務改善の入口として非常に便利です。

Google Workspaceを使っている会社であれば、追加のサーバーを用意せずに始められます。

スプレッドシートを見ればデータを直接確認でき、担当者も内容を理解しやすいです。

そのため、次のような業務には向いています。

少人数で使う管理表
1日あたりの登録件数が少ない業務
入力項目があまり変わらない業務
一覧確認と簡単な集計が中心の業務
社内だけで使う補助ツール
顧客説明用の小さな試作アプリ
Excelや紙の管理から移行する初期段階の業務

ただし、業務アプリとして長く使う場合は、最初から限界も知っておく必要があります。

スプレッドシートは、表計算と共有編集には強いですが、大量データの高速検索、細かな権限管理、監査ログ、複雑な履歴管理、複数人の同時更新には限界があります。

また、GAS側にも実行時間、トリガー、URL Fetch、メール送信などの割り当てや制限があります。

公式の制限値は変更される可能性があるため、公開前や提案前にはGoogle公式ドキュメントを確認する前提で考える必要があります。

この記事で伝えたいことは、次の3つです。

小規模な業務なら、GASとスプレッドシートだけでも十分に役立つ
業務システム化すると、データ量、同時利用、検索、履歴、権限で限界が出やすい
本格運用や顧客別運用では、外部DBやSupabaseを早めに検討した方が安全な場合がある

2. スプレッドシートだけで作れる範囲

GASとスプレッドシートだけでも、かなり多くの業務ツールを作れます。

たとえば、次のような構成です。

HTMLフォームで入力する
入力内容をスプレッドシートに保存する
一覧画面でデータを表示する
ステータスを更新する
条件に応じてメールを送る
PDFを作成してGoogleドライブに保存する
管理者に通知する
日次や週次で集計する

この構成は、発注フォーム、請求書送信、進捗管理、日報、問い合わせ管理、備品申請、簡易CRMなどに使えます。

スプレッドシートをデータ置き場にすると、開発者以外でも中身を確認しやすいというメリットがあります。

顧客や社内担当者に説明するときも、「このシートにデータがたまります」と伝えればイメージしてもらいやすいです。

また、初期開発の段階では、データ構造を変更しやすいことも利点です。

列を追加する、シートを分ける、ステータス列を増やす、といった変更を素早く試せます。

そのため、業務要件がまだ固まりきっていない段階では、スプレッドシートを使うことで試作と改善を進めやすくなります。

ただし、この「変更しやすさ」は、運用が進むとリスクにもなります。

列名やシート名が変わるとGASが動かなくなることがあります。

担当者が誤って列を削除したり、数式を壊したり、非表示シートを編集したりすると、ツール全体に影響することもあります。

スプレッドシートは便利ですが、業務アプリの裏側として使う場合は、自由に編集できること自体が弱点にもなると考えておく必要があります。

スプレッドシートが向いているのは、利用者が少なく、データ量が大きくなく、一覧表として見ながら修正できる業務です。たとえば、社内向けの簡単な受付一覧、数百件から数千件程度の管理表、担当者が限定されたチェックリスト、月次の集計補助などです。この範囲であれば、GASで入力フォーム、メール通知、PDF作成を組み合わせるだけでも十分に便利になります。

また、運用担当者が直接シートを見て確認できることは大きなメリットです。DB管理画面を別途用意しなくても、担当者が行を見て状況を把握できます。小さな業務改善では、こうした分かりやすさが導入のしやすさにつながります。

ただし、スプレッドシートを「簡易DB」として使う場合でも、列名、シート名、入力ルール、保護範囲、バックアップ方法は決めておく必要があります。利用者が自由に列を追加したり、関数を壊したり、並び替えでデータの対応関係を崩したりすると、GAS側の処理も影響を受けます。

3. 限界が出やすいポイント

スプレッドシートを使ったGASアプリで限界が出やすいのは、主に次のような場面です。

行数が増えて表示や検索が遅くなる
複数人が同時に編集して更新がぶつかる
条件検索や集計が複雑になる
変更履歴を業務要件として管理したくなる
ユーザーごとに見せるデータを分けたくなる
顧客ごとにデータを分離したくなる
誤操作を防ぐ権限設計が必要になる
監査ログや承認履歴が必要になる
GASの実行時間やトリガー制限に近づく

最初は、1つのシートにデータをためるだけで問題ありません。

しかし、運用が続くと、過去データが増えます。

データが増えると、読み込み、検索、集計、並び替え、フィルタ、数式の再計算に時間がかかるようになります。

GASでシート全体を読み込んで処理している場合、行数が増えるほど処理時間も伸びます。

また、複数人が同じデータを更新する場合、誰がいつ何を変更したのかを正確に追いにくくなります。

スプレッドシートにも変更履歴はありますが、業務アプリとして「この申請は誰が承認した」「この金額はいつ変更された」「このステータスはどの処理で変わった」といった履歴を扱うには、専用の設計が必要です。

さらに、顧客向けアプリや部署別アプリでは、権限管理が問題になります。

「A部署にはA部署のデータだけ見せる」「顧客ごとにデータを完全に分ける」「管理者だけが全件見られる」といった要件が出てくると、スプレッドシートだけで安全に管理するのは難しくなります。

この段階になると、スプレッドシートを業務データベースとして使い続けるより、外部DBを検討した方が設計しやすくなることがあります。

限界が出やすいのは、スプレッドシートが「入力画面」「管理画面」「データベース」「集計表」「履歴表」を同時に兼ね始めたときです。最初は1つの一覧表で十分でも、利用者が増えると、入力者には見せたくない列、管理者だけが使う列、集計用の列、GASが内部的に使う列が混在しやすくなります。

この状態になると、どの列を触ってよいのか分かりにくくなります。担当者が列を非表示にしたり、フィルタを変えたり、コピーした表で作業したりすると、GASが想定している構造と実際のシートがずれてしまいます。結果として、エラーの原因がコードなのか、利用者操作なのかを切り分けるのに時間がかかります。

もう一つの限界は、業務ルールの増加です。承認者によって表示内容を変える、担当拠点ごとに閲覧範囲を分ける、ステータス変更履歴を残す、削除ではなく無効化として扱う、といった要件が増えると、スプレッドシートだけでは管理しづらくなります。

4. データ量・同時利用・検索の課題

スプレッドシート管理で最初に問題になりやすいのは、データ量です。

Google Sheetsには保存可能なセル数などの制限があります。

ただし、実務では公式上の上限に達する前に、体感速度や運用のしづらさが問題になることが多いです。

たとえば、次のような状態です。

シートを開くのに時間がかかる
フィルタや並び替えが重い
数式の再計算が遅い
GASの検索処理に時間がかかる
一覧画面の表示が遅い
過去データを消せず、ファイルが大きくなり続ける
関係ない空行や不要列まで処理対象になる

GASでは、スプレッドシートから値を読み込む処理を何度も繰り返すと遅くなります。

そのため、開発時にはまとめて読み込み、メモリ上で処理し、まとめて書き込む設計にすることが重要です。

しかし、どれだけ丁寧に作っても、データが増え続ける業務では限界があります。

検索条件が増えたり、複数のシートを横断したり、月別・顧客別・担当者別の集計が必要になったりすると、スプレッドシートだけでは処理が複雑になります。

同時利用も注意が必要です。

少人数であれば問題になりにくいですが、複数人が同時に同じレコードを更新する業務では、更新の競合や上書きが起きやすくなります。

GAS側でロック処理を入れることはできますが、業務要件が複雑になるほど、スプレッドシートを安全なデータベースとして扱う難易度は上がります。

データ量の問題は、単純な行数だけで判断しない方がよいです。1万行でも軽く使えるシートもあれば、数千行でも関数、条件付き書式、参照範囲、画像、複数シート連携が多いと重く感じることがあります。GASから読み書きする場合も、毎回全行を取得して検索する作りだと、行数が増えるほど処理時間が伸びます。

検索条件が増えてきた場合も注意が必要です。担当者、拠点、期間、ステータス、取引先、商品区分などを組み合わせて探すようになると、スプレッドシート上のフィルタだけでは利用者ごとの画面を作りにくくなります。GASで検索画面を作ることはできますが、裏側で毎回シート全体を読む設計だと、やがて遅くなります。

同時利用も、実務では問題になりやすいです。複数人が同じシートを見ながら作業するだけなら問題なくても、同じ行を更新する、ステータスを変更する、連番を採番する、履歴を追記する、といった処理が重なると、競合や重複が起きる可能性があります。特に発注Noや受付Noの採番は、慎重に設計しないと重複の原因になります。

外部DBを使うと、検索条件を指定して必要なデータだけを取得しやすくなります。すべてのデータをシートに読み込むのではなく、画面で必要な範囲だけを取り出せるため、利用者が増えたときにも構成を見直しやすくなります。

5. 履歴管理・権限管理・監査ログの課題

業務アプリとして使う場合、単にデータを保存できればよいわけではありません。

運用が進むと、次のような要件が出てきます。

誰が登録したかを残したい
誰が更新したかを残したい
更新前の値も残したい
承認履歴を残したい
削除したデータを復元したい
ユーザーごとに見える範囲を分けたい
管理者と一般利用者で操作権限を分けたい
顧客ごとにデータを分離したい
操作ログを監査用に残したい

これらは、スプレッドシートでも工夫すれば一部は実現できます。

たとえば、更新日時、更新者、ステータス変更履歴用のシートを用意する方法があります。

しかし、要件が増えるほど、シート構成とGASコードが複雑になります。

また、スプレッドシートを直接編集できる利用者がいる場合、アプリ側で用意したルールを迂回できてしまうことがあります。

業務アプリでは、入力画面や管理画面だけを通して操作してもらいたい場面があります。

しかし、スプレッドシート自体に編集権限があると、直接データを書き換えられます。

これが社内の小さなツールなら許容できることもあります。

一方で、顧客データ、売上データ、承認データ、契約情報などを扱う場合は、直接編集できる構成がリスクになります。

権限管理や監査ログが重要な業務では、データベース側でユーザー、権限、履歴、制約を管理できる構成を検討した方が安全です。

履歴管理では、「現在の状態」と「過去の変更」を分けて持つことが重要です。スプレッドシートでは、現在の一覧に変更履歴を列として追加したり、別シートに履歴を追記したりできます。しかし、変更回数が増えると履歴シートが大きくなり、どの履歴がどのデータに対応するのかを追うのが難しくなります。

権限管理も同じです。スプレッドシートの共有設定では、ファイル全体の閲覧や編集を制御できますが、行単位や担当者単位で細かく分けるには工夫が必要です。GASの画面側で表示を制御する方法もありますが、元のシートにアクセスできる人がいれば、画面制御だけでは十分とは言えない場合があります。

監査ログが必要な業務では、誰が、いつ、何を変更したのかを後から説明できる必要があります。顧客対応、請求、発注、承認、在庫、契約管理などでは、過去の判断や変更理由を追えることが大切です。このレベルになると、スプレッドシートを単なる一覧表として使うより、DBに履歴テーブルを作る方が整理しやすくなります。

6. GAS側の制限も考える

スプレッドシートだけでなく、GAS側の制限も考える必要があります。

Apps Scriptには、実行時間、トリガーの合計実行時間、URL Fetch、メール送信、同時実行などに関する割り当てや制限があります。

これらの制限は、個人向けアカウントとGoogle Workspaceアカウントで異なる場合があります。

また、Google公式ドキュメントにも、割り当てや制限は変更される可能性があると説明されています。

そのため、顧客へ提案するときは、細かい数値だけを前提にしすぎない方が安全です。

たとえば、次のような業務では注意が必要です。

大量のメールを送る
多数のPDFを一括作成する
外部APIを大量に呼び出す
毎分・毎時のように頻繁に自動実行する
長時間かかる集計処理を行う
多数の利用者が同時に処理する
大量データを毎回スプレッドシートから読み込む

GASは小規模から中規模の業務改善に向いています。

ただし、常時高負荷で動くシステム、大量データを高速に処理するシステム、多数ユーザーが同時に使うシステムには向いていない場合があります。

業務アプリとして本格運用するなら、処理を分割する、キャッシュを使う、不要な読み書きを減らす、外部DBにデータを移す、といった設計が必要になります。

GASの制限は、スプレッドシートを外部DBに置き換えればすべて解決するわけではありません。GASを画面やバッチ処理として使う限り、実行時間、URL Fetch、トリガー、メール送信数などの制限は残ります。そのため、外部DB化するときも、GASに大量処理を集中させない設計が必要です。

たとえば、一覧画面で全件取得してからGAS側で絞り込むのではなく、検索条件をDB側へ渡して必要な件数だけ取得します。過去データを一括で処理する場合は、期間や件数で分割し、途中で止まっても再開できるようにします。これにより、GASの実行時間に引っかかりにくくなります。

また、外部DB連携では、通信失敗も考える必要があります。登録に失敗した場合、再実行してよいのか、二重登録にならないのか、利用者へどう通知するのかを決めます。スプレッドシートだけの処理より構成要素が増えるため、エラー時の設計はむしろ重要になります。

7. それでもスプレッドシートで十分なケース

ここまで限界を説明しましたが、すべての業務で外部DBが必要なわけではありません。

むしろ、最初から大げさな構成にすると、開発費や保守費が上がりすぎることがあります。

スプレッドシートで十分なケースは多くあります。

たとえば、次のような場合です。

利用者が少ない
1日の登録件数が少ない
データ量が急激に増えない
社内だけで使う
厳密な権限分離が不要
監査ログが必須ではない
一覧確認と簡単な集計が中心
手作業の置き換えが目的
試作やMVPとして早く形にしたい
将来のDB化を前提に、まず業務フローを確認したい

このような場合は、GASとスプレッドシートだけで始める価値があります。

特に、紙、Excel、メール、手入力で回している業務を改善する初期段階では、スプレッドシート管理でも十分に効果が出ます。

重要なのは、最初から完璧なシステムを作ることではありません。

今の業務規模に合った構成で始め、運用しながら限界が見えてきたら、外部DB化を検討することです。

ただし、顧客向けに納品する場合は、「将来的にデータ量や利用者が増えるとDB化が必要になる可能性がある」と事前に説明しておくと安心です。

スプレッドシートで十分な場合は、無理に外部DBへ移行しない方がよいこともあります。利用者が数人で、データ量も少なく、権限を細かく分ける必要がなく、管理者がシートを直接見て確認したい業務であれば、スプレッドシート中心の方が運用しやすいです。

外部DBを入れると、テーブル設計、API連携、認証情報、バックアップ、権限、保守担当といった考えることが増えます。小さな業務に対して構成を大きくしすぎると、現場にとっては分かりにくい仕組みになります。技術的にできることと、運用に合っていることは別です。

判断に迷う場合は、まずスプレッドシートで作り、限界が見えてきた部分だけを外部DBへ移す方が現実的です。最初から完全なシステム化を目指すより、利用者の使い方、データ量の増え方、問い合わせ内容を見ながら段階的に判断できます。

8. 外部DBやSupabaseを検討する目安

外部DBやSupabaseを検討する目安は、データ量だけではありません。

次のような要件が出てきたら、スプレッドシート管理から一歩進めるタイミングです。

顧客ごとにデータを分けたい
部署ごとに閲覧範囲を分けたい
ユーザーごとの権限を細かく管理したい
大量データを検索したい
複数条件で高速に絞り込みたい
変更履歴や監査ログをきちんと残したい
データの整合性を保ちたい
複数の画面や機能から同じデータを使いたい
将来的にスマホアプリや別システムとも連携したい
顧客別にプロジェクトや環境を分けたい

Supabaseのような外部DBを使うと、データをテーブルとして管理できます。

スプレッドシートよりも、検索、集計、権限、履歴、複数アプリからの利用を考えやすくなります。

GASは画面やGoogleサービス連携を担当し、データはSupabaseに保存する、という構成も選べます。

この構成にすると、スプレッドシートを管理表として使い続けるより、業務アプリとして拡張しやすくなります。

ただし、外部DBを使えばすべて解決するわけではありません。

設計、認証、権限、バックアップ、料金、保守の考え方が必要になります。

そのため、最初から外部DBにするか、まずスプレッドシートで始めるかは、業務規模、予算、運用体制、将来の拡張予定を見て判断するのが現実的です。

外部DBを検討する目安は、「スプレッドシートが重い」という感覚だけではなく、何が業務上の問題になっているかで判断します。検索に時間がかかって顧客対応が遅れる、履歴が追えずに説明できない、担当者ごとに見せる情報を分けられない、同じデータを複数の画面や別アプリから使いたい、といった具体的な課題があるかを確認します。

Supabaseのような外部DBを使う場合は、正のデータをどこに置くかを決めます。発注データ、請求履歴、案件情報、作業履歴など、正式な業務データをDBに置き、スプレッドシートは設定表、確認用一覧、エクスポート先として残す構成が分かりやすいです。

移行は一度に全部行う必要はありません。まず、増え続ける履歴や検索に時間がかかるデータだけをDB化し、既存のシート運用は一部残す方法があります。段階的に進めることで、現場の負担を抑えながら外部DBの効果を確認できます。