GASで作った自動化について、最近こういう相談が続いています。
毎朝動いていたスプレッドシートの集計が、件数が増えてから「最大実行時間を超えました」で止まるようになった。
作った担当者が異動してしまって、動いているのに誰も中身を触れない。止まったときに直せる人がいない。
個人のGmailアカウントで試したときは普通に回っていたのに、会社のアカウントに移したあと止まる日が出てきた。
3つとも、聞かれているのは「どう書けば直るか」ではありません。この自動化をこのまま育てていいのか、どこかで業務システムに作り替えるべきなのか、という線引きの話です。この記事ではその線引きを、公式に書かれている数字と仕様から整理します。
結論を先に言います
GASの限界とは、Google Apps Scriptに公式で定められた実行時間や回数の上限のことです。公式ドキュメントでは、1回のスクリプト実行が6分、トリガーの1日の合計実行時間が個人アカウント（gmail.comなど）で90分、Google Workspaceアカウントで6時間と示されています。
ただ、実際に現場で先に壊れるのは技術的な上限ではありません。この記事で持ち帰っていただきたいのは、次の5つです。
- 1回の実行時間の上限は公式ページ間で記述が割れている。確実に差がつくのは1日の合計枠のほう
- 無料トライアルから有料に移った直後は、上限が上がるまでに公式が明記した条件がある
- インストール型トリガーは作った人のアカウントで動く。属人化はGASの仕様の側にある
- エラーメッセージを見れば、どの上限に当たったのかを引ける
- 全部を業務システムに移す必要はない。移すものと、GASのままでよいものを分ける
GASをやめる線引きは、コードの複雑さではなく3つの実測値で決まる
「コードが複雑になってきたから、そろそろ限界かもしれない」という判断の仕方は、正直あまり当てになりません。複雑さは感覚で、人によって基準が違うからです。見るべきなのは次の3つで、どれも数えられます。
1つ目：1回の実行時間が6分に近づいたか
公式のクォータ表では、スクリプトの実行時間は個人アカウントでもGoogle Workspaceアカウントでも6 min / executionと記載されています（Quotas for Google Services）。
ただ、ここは同じGoogle公式でも記述が一致していません。Best practicesのページには「Apps Script has execution time limits (typically 6 minutes per execution, or 30 minutes for some Google Workspace accounts)」と書かれていて、一部のGoogle Workspaceアカウントでは30分という記述になっています。クォータ表の6分と、この30分のどちらが自社に当てはまるのかは、公式ページを読み比べただけでは確定できません。
なので「6分が絶対の上限」と決め打ちして設計するのは、正直やめたほうがいいかなと思います。自社の環境で実際に走らせて、何分で落ちるかを測ってから設計するほうが確実です。いずれにせよ、処理件数が増えていく業務で1回の処理時間が上限に近づいてきたら、件数が伸びればいずれ当たります。
2つ目：1日の合計実行時間が枠に近づいたか
見落とされやすいのがこちらです。1回6分に収まっていても、トリガーで何度も走らせていれば合計が積み上がります。同じ公式ページで、トリガーの1日の合計実行時間は個人アカウントが90分／日、Google Workspaceアカウントが6時間／日と分かれています。
そして公式は、上限に当たったときに出る「Service using too much computer time for one day.」というメッセージについて、トリガーで動くスクリプトは手動で実行するスクリプトより1日の上限が低いため、このエラーはトリガー実行で最も多く起きると説明しています。定期実行に寄せるほど枠は厳しくなる、という順番です。
3つ目：作った人以外が直せるか
これは公式の数字ではなく、現場を見ていて一番事故になるところです。数え方は単純で、「今この自動化が止まったとき、原因を調べて直せる人は社内に何人いますか」と聞いて、答えが1人なら、技術的な上限とは別にもう限界が来ていると考えています。この点はGASの仕様とも関係していて、後半で扱います。
公式の上限を数字で見る｜個人アカウントとWorkspaceで1日の枠が4倍違う
公式のクォータ表から、業務自動化の見積もりに効く項目だけを抜き出しました。数字は公式の表記のまま載せています。
| 項目 | 個人アカウント（gmail.comなど） | Google Workspaceアカウント |
|---|---|---|
| スクリプトの実行時間 | 6 min / execution | 6 min / execution |
| カスタム関数の実行時間 | 30 sec / execution | 30 sec / execution |
| トリガーの1日の合計実行時間 | 90 min / day | 6 hr / day |
| トリガー数 | 20 / user / script | 20 / user / script |
| 同時実行数（ユーザーあたり） | 30 / user | 30 / user |
| URL Fetchの呼び出し | 20,000 / day | 100,000 / day |
| 1日の送信先数（MailAppなど） | 100 / day | 1,500 / day |
ここで押さえておきたいのは、このクォータ表の範囲では実行時間の行（スクリプト6分、カスタム関数30秒）が両方とも同じ値で並んでいて、差がついているのはトリガーの1日の合計枠のほうだという点です。個人アカウントで作った試作が「1回3分で動いた」としても、それは本番の見積もりにはなりません。1日に何回走らせるかを掛けたところで初めて、90分／日と6時間／日の差が効いてきます。
有料に切り替えた直後は、上限がすぐには上がらない
同じページに、見落とすと計画がずれる但し書きがあります。公式には「Additional limits apply for trial accounts.」とあり、無料トライアルから有料のサブスクリプションに切り替えたあと、アカウントの上限が自動的に上がるのは次の2つがどちらも真のときだと明記されています。
- ドメインの累計支払額がUSD $100以上（またはそれに相当する額）に達していること
- その支払額に達してから60日以上が経過していること
つまり、トライアルから契約に切り替えた直後の会社が「Workspaceにしたから6時間／日まで使えるはず」という前提で設計すると、その前提が立つのは先の話になります。導入の時期と自動化の設計が重なっている会社ほど、ここは確認しておいたほうがいいかなと思います。
AIを足すと、使える時間はむしろ短くなる
同じクォータのページに、Workspace Studioを拡張するアドオンの実行タイムアウトは2分と書かれています。GAS本体の6分より短い枠です。あわせて、Workspace StudioはGemini Alpha programの一部として提供されていることも同ページに明記されています。一般提供として扱うのは早いので、検証する場合はその前提で見たほうがいいと思います。Workspace Studioで自動化を始める前の判断はWorkspace Studioの記事で別途整理しています。
なお、公式の上限表には前置きとして「All limits are subject to elimination, reduction, or change at any time, without notice.」という一文が添えられています（「Current limitations」節の冒頭。「Current quotas」節の冒頭にも同じ趣旨の一文があります）。予告なく削除・縮小・変更されうる、ということなので、この記事でも「この数字なら安全です」という書き方はしません。設計するなら、上限に当たったことを検知して知らせる側を先に作るほうが現実的です。
技術的な上限より先に壊れるのは運用｜トリガーは作成者のアカウントで動く
ここがこの記事でいちばんお伝えしたいところです。公式の「Installable triggers」には、「Installable triggers always run under the account of the person who created them.」と書かれています。インストール型トリガーは、常に作成した人のアカウントで実行される、ということです。
公式はそのまま例も挙げていて、ドキュメントが開かれたらメールを送るトリガーを作った場合、そのメールは常に自分のアカウントから送られ、開いた人のアカウントからではないとしています。アカウントごとにトリガーを作れば、それぞれのアカウントから1通ずつ送られるとも書かれています。
さらに運用上やっかいなのが次の記載です。あるアカウントからは、別のアカウントがインストールしたトリガーを見ることができません。それでいて、前者のアカウントがそのトリガーを発火させることはできると公式に明記されています。「一覧に出てこないのに動いている」という状態が、仕様として成立します。
つまり属人化は運用の怠慢ではなく、GASの仕様に埋め込まれているということです。作った人が異動・退職したときに「引き継ぎ資料が無かったから」で片づけると、たぶん同じことがまた起きます。
同じページに書かれている、他の落とし方
Restrictionsの節には、事故の原因になりやすい仕様がまとめて書かれています。
- ファイルが読み取り専用（閲覧またはコメント）モードで開かれた場合、トリガーは動かない。スタンドアロンスクリプトでは、トリガーが正しく動くために利用者に最低でも閲覧権限が必要
- スクリプトの実行やAPIリクエストでは、トリガーは発火しない。例として、
FormResponse.submit()で新しい回答を送信しても、フォームの送信トリガーは動かないと明記されている - 例外は
Form.submitGrades()で、onFormSubmitトリガーを使っているコードから呼ぶと無限ループになる。公式は、呼ぶ前に成績がすでに存在するかを確認するコードを足して防ぐよう書いている - インストール型トリガーは、Apps Scriptのトリガーのクォータ制限の対象になる
対策として公式のBest practicesが挙げているのが共有ドライブでの共同作業です。共有ドライブ上のファイルは個人ではなくグループが所有するため、プロジェクトの開発と保守がしやすくなる、と書かれています。持ち主を個人から組織に移す、という考え方は、業務システムへ移す判断とも地続きです。何を人に任せ、何を任せないかの整理はAIに任せない業務の分類でも書いています。
エラーメッセージから、当たった上限を引く
止まったときに、まず読むべきは例外のメッセージです。公式が列挙している文言と、その意味を表にしました。
| 出るメッセージ | 公式の説明 |
|---|---|
Limit exceeded: Email Attachments Per Message. | Current quotas / Current limitations に挙げられているクォータや制限のいずれかを超えた |
Service invoked too many times: Calendar. | そのサービスを1日のうちに呼びすぎた |
Service invoked too many times in a short time: Calendar. Try Utilities.sleep(1000) between calls. | そのサービスを短時間に呼びすぎた |
Service using too much computer time for one day. | 1日に許される合計実行時間を超えた。トリガーで動くスクリプトは手動実行より1日の上限が低いため、最も多く起きる |
スプレッドシートのセルに #ERROR! が出る場合は別の上限です。公式の「Custom functions in Google Sheets」には、カスタム関数の呼び出しは30秒以内に返す必要があり、返らなければセルに #ERROR! が表示され、セルのメモに Exceeded maximum execution time (line 0). と表示されると書かれています。6分の話と混ざりやすいので、ここは切り分けてください。
ついでに言うと、同じページにはカスタム関数は値を返すセルとその隣接セル以外を変更できないことも明記されています。任意のセルを書き換えたい場合はカスタムメニューから関数を実行する、という案内です。「関数で全部やろうとして詰まる」パターンはここが原因のことがあります。
上限に当たる前に打てる手として、公式のBest practicesは他サービスの呼び出しを最小限にすること（Apps Script内のJavaScript処理のほうが、SheetsやUrlFetchなどへのリクエストより速い）、読み書きをまとめてバッチ化すること（読み書きを交互に行うのは遅く、一度の命令で配列に読み込み、処理し、一度で書き出す）、Cache Serviceで実行間のデータを保持して取得時間を減らすことを挙げています。フォームとスプレッドシートの組み合わせで詰まっている場合はフォーム＋スプレッドシートの業務改善もあわせてどうぞ。
部署別の使いどころ｜GASのままでよいものと、業務システムへ移すもの
ここまでの数字と仕様を、部署ごとの実務に当てはめます。全部を業務システムに作り替える必要はありません。むしろ大半はGASのままでよい、というのが正直なところです。
| 部署 | よくある自動化 | GASのままでよい目安 | 業務システムへ移す目安 |
|---|---|---|---|
| 経理・財務 | 請求データの集計、経費の転記 | 月次で担当者が自分で回す範囲 | 締め日に全社が待つ。止まると請求が出せない |
| 営業 | リストの整形、定型メールの送信 | 1日の宛先数が個人100・Workspace1,500の枠に収まる | 送信が売上の本線。履歴と権限を残す必要がある |
| 総務・人事 | 勤怠の突合、申請フォームの集計 | 月1回、担当者1人で完結する | 毎日動く。給与や労務に直結する |
| 製造・現場 | 日報フォームの集計、在庫の更新 | 1拠点・1チームで使っている | 複数拠点で使う。拠点ごとに見せる範囲を分けたい |
| 情シス・管理部門 | アカウント棚卸し、ログの収集 | 担当者本人が確認のために使う | 他部署が結果に依存し始めた |
右の列に共通しているのは「毎日」「全社」「止まると業務が止まる」の3つです。この3つが揃ったものだけを業務システムへ移す、という順番にすると、移行の対象はかなり絞れます。逆に言うと、月1回・1人・止まっても翌日やり直せるものは、GASのままで十分に元が取れます。業務システム開発・DX支援でご相談いただく案件も、最初にこの仕分けから入ることが多いです。
CodeClimbの見解
ここからは、公式の記載ではなく弊社の解釈と自社運用での経験です。事実と分けて読んでください。
正直に言うと、私たちは「GASはやめたほうがいい」とは考えていません。ツールを売る側ではなく作る側の立場で見ると、GASは業務自動化の入口として今でもいちばん安い選択肢です。上限に当たること自体は失敗ではなく、その業務が育った証拠だと捉えています。
そのうえで、移す判断を分けるのは処理の重さではなく可用性だと考えています。弊社自身、2026年9月21日から24日にかけて、夜間に回していた自動ジョブ6本が4日間まるごと止まりました。原因は個々のスクリプトの不具合ではなく、認証の期限切れという共通の足元でした。再試行を2回行う設計は入っていましたが、この種の失敗は再試行では回復しませんでした。処理の中身がどれだけ正しくても、実行基盤が落ちれば全部止まる、というのを自社で踏んだ形です。
もう一つ、自社の定期実行で学んだことがあります。自動化は書いた時点ではなく、実行環境に入った時点で完成します。設定の正本を書き換えただけでは適用されず、反映されるまでは古い設定のほうが動き続けます。GASのトリガーが作成者のアカウントで動く話と、根は同じかなと思っています。どちらも「コードの外側」で決まる部分です。
効果の実感としては、弊社では見積書・請求書づくりが1件15分かかっていたのが1分もかからなくなり、システム不具合の調査は半日かかっていたのが10分程度で原因を特定できるようになりました。クライアント側の例では、あるkintone運用案件で外部サービスに月9万円かかっていたものを自社開発のシステムに置き換えて廃止し、年間で約108万円の削減になっています。効いたのはどれも「毎日・全社・止まると困る」側の業務でした。この順番は、上の表の右列とそのまま重なります。
AIを足す話についても一言だけ。作業の中にAIを挟むと処理は増えるので、使える時間はむしろ短くなる方向に働くと見ています。最初にAIを入れるより、どの業務が上限に当たっているかを数えるほうが先かなと思います。
よくある質問
Q1. 処理を分割して何回かに分ければ、上限は回避できますか？
公式のクォータ表では、トリガーの1日の合計実行時間は個人アカウントで90分／日、Google Workspaceアカウントで6時間／日と定められています。これは1日あたりの合計に対する枠なので、処理を何回に分けても総量そのものは変わらないと考えています。むしろ実行回数を増やすほど、こちらの枠を使い切りやすくなるはずです。分割は延命であって、線引きの答えにはならないというのが私たちの見方です。
Q2. トリガー数の上限（20）は、スクリプトを分ければ回避できますか？
公式の表記は「20 / user / script」で、ユーザーとスクリプトの組み合わせごとの数です。ただし、スクリプトを分けても1日の合計実行時間はアカウント単位の枠として効いてきますし、インストール型トリガーはトリガーのクォータ制限の対象だと公式に明記されています。管理対象のスクリプトが増えるぶん、誰が何を持っているか分からなくなる副作用のほうが大きいかなと思います。
Q3. 作った担当者が退職したあと、トリガーはそのまま引き継げますか？
そのままでは引き継げないと考えたほうが安全です。公式には、インストール型トリガーは常に作成した人のアカウントで実行されること、そしてあるアカウントからは別のアカウントがインストールしたトリガーが見えないことが明記されています。実務としては、後任のアカウントで作り直すのが確実です。あわせて、公式のBest practicesが勧めるとおり共有ドライブに置いてファイルの所有をグループに移しておくと、次に同じことが起きにくくなります。
まとめ
GASの限界は、公式に数字で書かれています。ただし1回の実行時間については、クォータ表が6分と記載する一方、Best practicesには一部のGoogle Workspaceアカウントで30分という記述もあり、公式内で一致していません。確実に差がついているのはトリガーの1日の合計枠で、個人アカウント90分／日とGoogle Workspaceアカウント6時間／日です。トライアルから有料に移った直後は、累計USD $100以上の支払いと、その到達から60日以上の経過という条件が揃うまで上限は自動では上がりません。
ただ、多くの現場で先に壊れるのは数字のほうではなく運用です。インストール型トリガーは作成者のアカウントで動き、別アカウントからは見えないまま発火します。「1回6分に近いか」「1日の合計枠に近いか」「直せる人が1人しかいないか」の3つを数えて、当てはまるものだけを業務システムへ移す。この順番で仕分けると、無駄な作り替えをせずに済むはずです。
業務システムへの移行を検討されている方へ
CodeClimbは、売る側ではなく作る側として業務システムの開発とDX支援を行っています。「どこまでGASで粘って、どこから作り替えるか」の仕分けからご相談いただけます。まずは業務システム開発・DX支援のサービスページをご覧ください。具体的に止まっている自動化がある場合は、お問い合わせフォームから状況をお知らせいただければ、移すべきかどうかの判断からお手伝いします。
出典
- https://developers.google.com/apps-script/guides/services/quotas?hl=en ｜ Google for Developers（Apps Script 公式ドキュメント「Quotas for Google Services」） ｜ 参照 2026-09-27
- https://developers.google.com/apps-script/guides/triggers/installable?hl=en ｜ Google for Developers（Apps Script 公式ドキュメント「Installable triggers」） ｜ 参照 2026-09-27
- https://developers.google.com/apps-script/guides/support/best-practices?hl=en ｜ Google for Developers（Apps Script 公式ドキュメント「Best practices」） ｜ 参照 2026-09-27
- https://developers.google.com/apps-script/guides/sheets/functions?hl=en ｜ Google for Developers（Apps Script 公式ドキュメント「Custom functions in Google Sheets」） ｜ 参照 2026-09-27
- https://developers.google.com/apps-script/guides/services/authorization?hl=en ｜ Google for Developers（Apps Script 公式ドキュメント「Authorization for Google Services」） ｜ 参照 2026-09-27
