GASで業務システム開発時の注意点：実行時間・権限・エラー対応まで実務目線で解説

GAS（Google Apps Script）は、GoogleスプレッドシートやGmail、Googleドライブと連携しやすく、小さな業務システムを作るときに便利です。

発注フォーム、請求書送信、進捗管理、日報集計、メール通知など、スプレッドシートを中心にした業務であれば、低コストで始めやすい選択肢になります。

ただし、GASは何でも自由に動かせるサーバーではありません。実行時間、メール送信、トリガー、権限承認、Googleサービス側の割り当てなど、実務運用で意識すべき制限があります。

試作では問題なく動いていても、利用者やデータ量が増えると、処理が途中で止まる、メールが送れない、トリガーが動かない、権限変更でエラーになる、といった問題が出ることがあります。

この記事では、GASで業務システムを作るときの注意点を、実務目線で整理します。コードの細かい話ではなく、顧客説明、提案、保守設計で押さえておきたいポイントを中心に解説します。

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

GASで業務システムを作るときに大切なのは、「動くかどうか」だけで判断しないことです。

小さな処理ならすぐに動かせますが、業務で使い続ける場合は、止まったときに気付けるか、原因を追えるか、誰が直すのかまで考えておく必要があります。

特に、次のようなポイントは最初に確認しておきたいところです。

• 1回の処理が実行時間内に終わるか
• メール送信や外部API連携の割り当てを超えないか
• トリガーが誰のアカウントで動くか
• スプレッドシートやドライブの権限が適切か
• エラー時に通知されるか
• ログや履歴が残るか
• データ量が増えても運用できるか
• 担当者変更時に引き継げるか

GASは、現場の小さな業務改善にとても向いています。

一方で、基幹システムのような厳密な可用性や大量処理を求める用途では、GASだけで完結させるより、外部DBや専用サービスとの組み合わせを検討した方がよい場合があります。

そのため、GASで業務システムを作るときは、「どこまでGASで作るか」「どこから別の仕組みに任せるか」を見極めることが重要です。提案時には、GASでできることだけでなく、GASで抱えすぎると危ない部分も一緒に説明しておくと、後からの認識違いを減らせます。

2. 実行時間と割り当ての注意点

GASには、1回あたりの実行時間や1日あたりの割り当てがあります。

Googleの公式ドキュメントでは、通常のスクリプト実行時間は1回あたり6分とされています。処理が長くなり、この時間を超えると途中で停止します。

たとえば、次のような処理は時間がかかりやすいです。

• スプレッドシートの全行を毎回読み書きする
• 大量のPDFを一括作成する
• 多数のメールを一度に送る
• 外部APIへ大量にアクセスする
• Googleドライブ内のファイルを大量に検索する
• 複数シートを何度も往復して処理する

実務では、処理を一度に全部終わらせようとしない設計が大切です。

対象件数を分割する、処理済みの行を記録する、次回トリガーで続きから処理する、重い処理を夜間に回す、といった工夫が必要になります。

たとえば請求書PDFを100件作る処理なら、100件を一度に処理するのではなく、20件ずつ処理して、どこまで終わったかをシートに残す方法があります。途中で止まっても、次回は未処理の行から再開できます。

処理済みフラグを使う場合は、単に「済」と書くだけでなく、処理日時、作成したファイルURL、送信結果、エラー内容も一緒に残すと、後から確認しやすくなります。再実行時に成功済みの行を飛ばせるため、二重作成や二重送信の防止にもつながります。

また、GASの割り当てはユーザー単位で管理されるものがあります。

メール送信数、URL Fetch、Properties読み書き、トリガー総実行時間などは、アカウント種別や利用状況によって上限があります。無料アカウントとGoogle Workspaceアカウントで差がある項目もあります。

制限値は変更される可能性があるため、公開前や納品前には公式ドキュメントを確認する前提にしておくべきです。特に顧客向けに納品する場合は、「この件数なら毎日動かせるか」「月末だけ処理件数が増えないか」「将来データが増えても同じ構成でよいか」を確認しておくと安全です。

3. メール送信・外部API連携の注意点

GASでは、Gmail送信や外部API連携を簡単に組み込めます。

発注通知、請求書送信、進捗通知、日報メール、エラー通知など、業務システムではメールを使う場面が多くあります。外部API連携では、Supabase、会計ソフト、在庫管理サービス、チャットツールなどとつなぐこともあります。

ただし、メール送信も外部API連携も無制限ではありません。

メールには1日あたりの受信者数や1通あたりの宛先数、本文サイズ、添付ファイルサイズなどの制限があります。外部API連携では、GAS側のURL Fetchの割り当てだけでなく、連携先サービス側のレート制限にも注意が必要です。

一括処理でよくある問題は、途中まで送信して止まることです。

たとえば、100件の請求書メールを送る処理で60件目にエラーが起きた場合、どこまで送れたのか、どこから再送すべきかが分からないと、二重送信や送信漏れにつながります。

そのため、メール送信や外部API連携では、次のような設計が重要です。

• 送信前に対象件数を確認する
• 送信結果を1件ずつ記録する
• 失敗した理由を記録する
• 成功済みの処理を再実行しない
• テスト送信と本番送信を分ける
• リトライ回数を決める
• 連携先APIの制限も確認する

テスト送信と本番送信を分けることも大切です。開発中に実在の顧客へメールが送られると、内容が正しくても信用を損ねることがあります。テスト時は管理者だけに送る、件名にテストと入れる、送信先を固定する、といった仕組みを入れておくと安心です。

外部API連携では、失敗時のレスポンスも記録します。HTTPステータス、レスポンス本文、送信したデータのIDを残しておくと、連携先の障害なのか、認証切れなのか、データ形式の問題なのかを切り分けやすくなります。

GASで外部連携を作る場合は、成功時だけでなく、失敗時の記録と再実行まで含めて考える必要があります。

4. 権限承認と所有者の注意点

GASは、Googleアカウントの権限と強く結びついています。

スプレッドシートを読む、Gmailを送る、Googleドライブにファイルを保存する、外部APIへアクセスする、といった処理には権限承認が必要になります。

開発中は自分のアカウントで承認して動かせますが、業務システムとして使う場合は、誰のアカウントで承認し、誰の権限で動かすのかを明確にする必要があります。

特に注意したいのは、個人アカウントに依存した運用です。

担当者個人のアカウントでGASプロジェクト、スプレッドシート、ドライブフォルダ、トリガーを作っていると、異動や退職時に引き継ぎで困ることがあります。顧客向けツールの場合も、開発者個人のアカウント所有のまま運用すると、契約終了後や保守変更時に問題になりやすいです。

また、権限を広くしすぎることにも注意が必要です。

「リンクを知っている全員が編集可」のような設定は便利ですが、業務データを扱う場合は危険です。スプレッドシート、保存先フォルダ、テンプレート、WebアプリURLの共有範囲を整理し、必要な人だけがアクセスできる状態にします。

GASで業務システムを作るときは、次の点を決めておくと安心です。

• ツールの所有者
• 実行アカウント
• トリガー作成者
• 管理者
• 利用者
• 保守担当者
• 共有範囲
• 権限変更時の手順

所有者は、できるだけ組織で管理できるアカウントに寄せます。個人アカウントを使う場合でも、スプレッドシート、Driveフォルダ、GASプロジェクト、トリガー、テンプレートの所有者が誰かを一覧にしておきます。

実行アカウントも重要です。メール送信の差出人、Driveファイルの作成者、外部APIの認証情報は、実行アカウントに依存します。担当者変更時にトリガーを作り直す必要があるか、再承認が必要かを事前に確認しておきます。

管理者と保守担当も分けて考えます。管理者は業務上の判断をする人、保守担当は不具合や仕様変更に対応する人です。同じ人が兼ねても構いませんが、役割が曖昧なままだと、止まったときに誰も判断できない状態になりやすいです。

権限設計は後回しにしがちですが、運用開始後に直す方が手間がかかります。納品時には、所有者、実行アカウント、トリガー、共有範囲、保守連絡先をセットで確認するのが現実的です。

5. トリガー管理と自動実行の注意点

GASの業務システムでは、トリガーを使って自動実行することがよくあります。

時間主導トリガーで毎朝集計する、フォーム送信時に通知する、スプレッドシート編集時に処理を走らせる、といった使い方です。

トリガーには、単純トリガーとインストール型トリガーがあります。

単純トリガーは手軽ですが、認可が必要なサービスにアクセスできない、実行時間が30秒を超えられないなどの制限があります。たとえば、単純な onEdit(e) でGmail送信や他ファイルへのアクセスを行う設計は向きません。

インストール型トリガーは、より多くの処理に対応できます。

ただし、公式ドキュメントでは、インストール型トリガーは作成したユーザーのアカウントで実行されると説明されています。つまり、誰がトリガーを作ったかによって、送信元やアクセス権限が変わります。

また、別のアカウントが作成したトリガーは見えにくいことがあります。

顧客環境や複数担当者で運用する場合、誰のトリガーが動いているのか、どの関数を実行しているのか、エラー通知が誰に届くのかを記録しておく必要があります。

トリガー管理では、次のような点を整理します。

• トリガーの種類
• 実行する関数
• 実行頻度
• 作成者アカウント
• エラー通知の受信者
• 停止・再作成の手順
• 不要になったトリガーの削除

トリガーは作った本人以外が把握しにくいため、運用資料や管理シートに残しておくと保守が楽になります。特に「毎朝8時に集計」「毎月末に請求書作成」「フォーム送信時に通知」のような処理は、止まると業務影響が出ます。

一時停止や再作成の手順も決めておきます。たとえば、月末処理だけ止めたい場合に、どのトリガーを止めればよいか分からないと、関係ない通知まで止めてしまうことがあります。トリガー名、関数名、実行頻度、目的が分かる形にしておくことが大切です。

自動実行は便利ですが、見えないところで動く処理だからこそ、管理表や納品資料に記録しておくことが大切です。

6. ログ・エラー通知・復旧の考え方

GASで業務システムを作る場合、エラーが起きたときに気付ける仕組みが必要です。

手動で実行している処理なら、画面上のエラーで気付ける場合があります。しかし、時間主導トリガーやフォーム送信時の処理では、利用者がエラーに気付かないことがあります。

そのため、エラー内容を記録し、必要に応じて管理者へ通知する設計にします。

ログとして残したい項目は、たとえば次のようなものです。

• 実行日時
• 処理名
• 対象データ
• 実行アカウント
• 成功または失敗
• エラー内容
• 再実行の要否
• 処理済み件数

スプレッドシートに処理ログシートを作るだけでも、後から原因を追いやすくなります。

重要な処理では、エラー時に管理者へメール通知する、チャットへ通知する、エラー一覧に残すなどの方法を検討します。

復旧方法も大切です。

途中で止まった処理を最初からやり直すと、二重送信や二重登録が起きることがあります。処理済みフラグ、送信日時、外部APIのレスポンスIDなどを残して、途中から再開できる形にしておくと安全です。

ログは細かすぎても運用されません。最低限、いつ、どの処理が、何件中何件まで進み、どこで失敗したかが分かる状態を目指します。利用者向けには短いメッセージ、保守担当向けには詳細なエラー内容を残すように分けると扱いやすくなります。

復旧手順は、記事や仕様書に書くだけでなく、実際に1回試しておくと安心です。エラーを再現できない場合でも、処理済みフラグを見て未処理だけ再実行できるか、通知先が正しいか、管理者がログを見つけられるかを確認しておきます。

エラーを完全になくすことはできません。

だからこそ、エラーが起きても気付き、原因を確認し、必要な範囲だけ再実行できる状態を作ることが重要です。

7. 大量データ処理やスプレッドシート運用の限界

GASとスプレッドシートの組み合わせは、始めやすく、現場にも説明しやすい構成です。

しかし、データ量や利用者数が増えると、スプレッドシート中心の運用には限界が出ます。

たとえば、次のような状態になると注意が必要です。

• 行数が増えて検索や集計が遅い
• 複数人が同時に編集して競合する
• 履歴データが増えすぎて重い
• 権限を細かく分けられない
• 画面表示に時間がかかる
• 全件読み込みが前提になっている
• バックアップや復旧が難しい

スプレッドシートは便利ですが、本格的なデータベースとは役割が違います。

小規模な管理表や社内ツールであれば十分使えますが、検索、集計、履歴管理、権限管理、同時利用が重要になる場合は、外部DBや専用システムを検討した方がよいことがあります。

GASを使い続ける場合でも、設計を工夫できます。

不要な列やシートを減らす、読み書きをまとめる、対象行だけ処理する、古い履歴を別ファイルへ移す、集計結果をキャッシュする、といった改善で運用できる範囲が広がります。

ただし、無理にGASとスプレッドシートだけで抱え込まない判断も大切です。

業務の重要度やデータ量が大きくなってきたら、Supabaseなどの外部DB、専用Webアプリ、既存の業務システムとの連携も選択肢になります。

判断の目安としては、データ量だけでなく、止まったときの影響も見ます。多少遅くても手作業で補える業務ならGASとスプレッドシートで十分な場合があります。一方、売上、請求、在庫、顧客対応など、止まるとすぐに業務影響が出るものは、早めに別構成を検討した方が安全です。

GASを使うこと自体が悪いわけではありません。大切なのは、GASで始める範囲、外部DBに移すタイミング、保守体制を分けて考えることです。

最初はスプレッドシートで素早く始め、件数や利用者が増えた段階でDB化する進め方も現実的です。その場合も、後で移行しやすいように、ID、作成日時、更新日時、ステータス、担当者などの基本項目は早い段階から整えておくとよいです。

8. まとめ

GASは、スプレッドシートやGmail、Googleドライブと連携した業務システムを低コストで作れる便利な仕組みです。

一方で、実行時間、メール送信、URL Fetch、トリガー、権限承認、所有者、ログ、エラー通知、データ量など、実務運用で注意すべき点があります。

試作や小規模な自動化では問題なくても、会社業務や顧客向けツールとして使う場合は、止まったときに気付けるか、誰が直すのか、どこまで保守するのかを決めておく必要があります。

特に重要なのは、制限ぎりぎりで動かさないこと、個人アカウントに依存しすぎないこと、エラー時の記録と通知を用意することです。

GASは業務改善の入り口として使いやすい一方、すべての業務システムに向いているわけではありません。用途、規模、データ量、保守体制を見ながら、GASで作る範囲を決めることが大切です。

最初から完璧なシステムを作る必要はありません。ただし、業務で使うなら、制限、権限、トリガー、ログ、復旧、引き継ぎを最初から意識しておくことが、後からの手戻りを減らします。