「GASなら無料」は半分だけ正しい｜6分制限・トリガー・上限で止まる前に知っておきたいこと

「GASなら無料で自動化できるから、全部それで作ればいいですよね」

これ、半分は正しいです。

Googleスプレッドシート、Gmail、Googleドライブとの相性はかなりいいですし、小さな業務改善なら僕もGASを選ぶことがあります。

ただし、「無料で作れる」と「長く安定して運用できる」は別の話なんですよね。

2026年8月時点のGoogle公式ドキュメントを見ると、Apps Scriptには1回の実行時間、トリガー、メール送信、URL Fetch、同時実行などに明確な上限があります。

なお、Google公式でもクォータや制限は変更される可能性があるため、運用前には最新値の確認が必要です。

ここを知らないまま作り始めると、

「テストでは動いたのに本番で止まった」

「少量なら平気だったのに件数を増やしたら終わらない」

「朝の自動実行だけ失敗している」

みたいなことが起きます。

はい。

GAS、便利なんですけど万能ではありません。

この記事では「GASをやめましょう」という話ではなく、どこまでGASでやると気持ちよく使えて、どこから別の構成を考えたほうがいいのかを整理します。

■ 無料の裏にある「上限」

まず一番分かりやすいのが実行時間です。

Google公式では、通常のApps Scriptは1回の実行につき6分が上限です。

6分。

短い処理なら十分です。

スプレッドシートを読んで、数十行を加工して、Gmailの下書きを作る。

このくらいなら設計次第でかなり使えます。

問題は、処理量が増えたときです。

数千行を1行ずつ読み書きする。

外部APIを何百回も呼ぶ。

複数ファイルを順番に処理する。

画像を大量に扱う。

こうなると、急に6分が近づいてきます。

しかも厄介なのは、開発中の少ないデータでは普通に終わることです。

本番データを入れた瞬間だけ遅い。

これ、クッッッソ分かりづらいです。

だから僕は「今動くか」だけではなく、「データが増えたときに同じ作りで耐えられるか」を見ます。

■ トリガーという見えない実行者

GASの便利さを一気に上げるのがトリガーです。

毎朝8時に実行。

1時間ごとに確認。

スプレッドシート編集時に処理。

こういうことができます。

人がボタンを押さなくても動くので、業務改善との相性はかなりいいです。

ただ、トリガーにも上限があります。

2026年8月時点のGoogle公式では、1ユーザー・1スクリプトあたりのトリガー数は20個です。

さらに、トリガー経由の合計実行時間にも日次上限があります。

ここで大事なのは数字を暗記することではありません。

「自動実行を増やせば増やすほど、別の制限も見ないといけない」

ということです。

自動実行が失敗しているのに、利用者は気づかない。

翌朝になって初めて「昨日のデータがない」と分かる。

このパターンは避けたいです。

そのため、定期実行を組むなら、

・失敗したら記録する

・最後に成功した時刻を残す

・必要なら通知する

・途中から再開できるようにする

このあたりまでセットで考えます。

自動化って、動かすことより「止まったときに気づけること」のほうが大事だったりします。

■ メール送信にも上限

GASからGmailやMailAppを使ってメールを送ることもできます。

これも便利です。

請求案内。

定型連絡。

担当者への通知。

エラー通知。

かなり使い道があります。

ただし、メール送信にも日次上限があります。

2026年8月時点では、Google公式のApps Scriptクォータ上、メール受信者数は個人向けアカウントとGoogle Workspaceで上限が異なります。

つまり、

「今日は10件だから大丈夫」

「将来は1000件送りたい」

では設計が変わる可能性があります。

ここを無視して「GASで一斉配信ツールを作りました！」まで突っ走ると、後で困ります。

しかも送信系は、止まるだけならまだいいです。

途中まで送って止まった場合、

どこまで送った？

誰に送れていない？

再実行すると二重送信しない？

という問題が出ます。

処理を再開できる設計、送信済み管理、エラー記録。

この地味な部分が実務では重要です。

派手なボタンよりこっちです。

■ 外部APIを呼ぶなら「相手側の上限」もある

GASから外部APIを呼び出すこともできます。

ChatGPT APIや各種クラウドサービス、業務サービスとの連携も構成としては可能です。

ただし、この場合はGAS側だけ見ていればいいわけではありません。

GASのURL Fetchにはクォータがあります。

さらに接続先APIにもレート制限や日次上限があることがあります。

つまり、

GASはまだ余裕。

でもAPI側が止める。

ということもあります。

逆もあります。

ここまで来ると「GASが書けるか」ではなく、システム全体の制限を見ないと判断できません。

ChatGPTに「このGASを書いて」と頼めばコード自体はかなり速く作れます。

でも、

1日何件処理するのか。

失敗時にどう戻すのか。

何分以内に終わる必要があるのか。

外部APIの上限はいくつなのか。

この部分は、コードを生成しただけでは決まりません。

■ GASに向いている仕事

ここまで制限の話ばかりすると、

「じゃあGASって微妙なの？」

と思われそうですが、違います。

むしろ条件が合えばかなり強いです。

僕なら、こんな仕事はGASを候補にします。

・Googleスプレッドシート中心の業務

・GmailやGoogleドライブとの連携

・データ量がそこまで多くない

・数分以内で終わる定型処理

・担当者数が少ない

・小さく始めたい業務改善

・Googleアカウント内で完結しやすい処理

サーバーを別に用意しなくても始めやすい。

利用者も普段のスプレッドシートから触れる。

この手軽さは強いです。

だから僕も「まずGASで十分」と判断することがあります。

何でも大規模なWebアプリにすればいいわけではありません。

そのほうが高くなるし、管理するものも増えます。

■ GASから離れる判断

逆に、最初から別の構成を検討したほうがいいケースもあります。

・大量データを長時間処理する

・重い画像処理やファイル処理がある

・高頻度で外部APIを呼ぶ

・複数ユーザーが同時に大量操作する

・処理を確実にキュー管理したい

・複雑な権限管理が必要

・データベースを中心に設計したい

こういう場合です。

PythonやWebアプリ、クラウドサービスを使ったほうが素直なことがあります。

もちろん、GASとPythonを組み合わせる方法もあります。

画面やスプレッドシート側はGAS。

重い処理は別環境。

みたいな分け方です。

大事なのは、技術名から決めないことです。

「GASで作りたい」

ではなく、

「この業務を安定して回したい」

から考えます。

■ 「作れる」より「運用できる」

GASは無料で始めやすいです。

だからこそ、最初の選択肢として優秀です。

でも、

無料だから。

Googleだから。

ChatGPTがコードを書いてくれたから。

この3つだけで長期運用まで決めるのは危ないです。

6分制限。

トリガー。

メール送信。

同時実行。

外部API。

このあたりを見ながら、

GASで十分なのか。

設計を少し工夫すればいけるのか。

PythonやWebアプリへ分けるべきなのか。

そこを先に決めたほうが、後から作り直す可能性を減らせます。

「GASで自動化したいけど、この規模で大丈夫か分からない」

そんな段階でも大丈夫です。

今の作業内容と、だいたいの件数・実行頻度が分かれば、GAS向きかどうかから整理できます。

作れるかではなく、運用できるか。

僕はそこまで見て決めます。