GASの利用制限まとめ：無料アカウントとGoogle Workspaceの違いを実務目線で比較

公開日：2026/05/15 最終更新日：2026/05/26

GAS（Google Apps Script）を使う前に確認したいのが、GASの利用制限です。

GASは、個人の無料アカウントでもGoogle Workspaceアカウントでも使えます。ただし、GAS 無料アカウント制限とGoogle Workspace GAS 制限では、メール送信数、URL Fetch、トリガー総実行時間などに違いがあります。

そのため、小さな自動化や社内ツールであれば、無料のGoogleアカウントから試すこともできます。ただし、実務で使う場合は、アカウントの種類によって使える量や運用しやすさが変わる点に注意が必要です。

特に、メール送信、外部API連携、時間主導トリガー、Propertiesの読み書き、ファイル作成などは、アカウント種別によって1日あたりの割り当てが違います。

この記事では、GASを無料アカウントで使う場合とGoogle Workspaceアカウントで使う場合の違いを、実務目線で整理します。細かい制限値はGoogle側で変更される可能性があるため、この記事では業務設計で意識したいポイントを中心に解説します。

1. GASの利用制限で最初に確認すべきポイント

GASの利用制限を確認するときは、最初からすべての項目を細かく覚える必要はありません。

実務で影響しやすいのは、メール送信数、URL Fetch、実行時間、トリガー総実行時間、Propertiesの読み書きです。まずは次の表を見て、自分の作りたいツールがどの制限を消費しやすいかを確認すると整理しやすくなります。

確認項目	無料アカウントの目安	Google Workspaceの目安	実務で見るポイント
メール受信者数	100人 / 日	1,500人 / 日	請求書送信、通知、一括メールで消費しやすい
URL Fetch	20,000回 / 日	100,000回 / 日	外部API、Supabase、チャット通知などで使う
トリガー総実行時間	90分 / 日	6時間 / 日	定期集計、夜間処理、毎時実行で効きやすい
Properties読み書き	50,000回 / 日	500,000回 / 日	設定値、状態管理、処理済み位置の保存で使う
1回あたりの実行時間	6分 / 回	6分 / 回	Workspaceでも長時間処理が無制限になるわけではない

この表はGoogle公式ドキュメントのApps Script quotasをもとにした目安です。割り当てや制限は変更される可能性があるため、公開前、納品前、提案前には必ず公式情報を確認してください。

重要なのは、無料アカウントかGoogle Workspaceかだけではありません。どの処理がどの制限を使うのか、制限に近づく前にログや分割処理で気づけるか、担当者が変わっても運用できるかまで含めて考える必要があります。

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

GASは無料アカウントでも便利に使えます。

スプレッドシートの集計、簡単なメール通知、少人数向けのフォーム処理、社内の小さな作業自動化であれば、まず無料アカウントで試してみる価値があります。

ただし、顧客向けツールや会社の業務で継続的に使う場合は、無料アカウントのままでよいかを慎重に考える必要があります。

GASには、1日あたりの処理量や1回あたりの実行時間などの制限があります。制限を超えると、スクリプトが途中で止まったり、メール送信や外部API連携ができなくなったりします。

Google Workspaceアカウントにすると、すべての制限がなくなるわけではありません。しかし、メール送信数、URL Fetch、トリガー総実行時間、Properties読み書きなど、一部の割り当てが無料アカウントより大きくなります。

そのため、GASを実務で使うときは、次のように考えると整理しやすくなります。

試作や少人数利用なら無料アカウントでも始めやすい
メール送信や外部API連携が多いならWorkspaceを検討する
顧客業務や会社業務なら所有者と管理者を明確にする
制限値ぎりぎりで動かす設計にしない
最新の割り当ては公式ドキュメントで確認する

GASは低コストで始めやすい反面、業務で使うならアカウント選びも設計の一部になります。

無料アカウントかWorkspaceかを比べるときは、単純に「無料で足りるか」だけで判断しない方が安全です。実務では、処理件数が少なくても、誰のアカウントで動かすのか、エラー時に誰が気づくのか、担当者が変わったときに引き継げるのかが問題になります。

たとえば、月に数十件しか動かない請求書送信ツールでも、送信元が担当者個人のGmailで、トリガーもその担当者のアカウントに紐づいている場合、退職や異動のタイミングで運用が止まる可能性があります。処理件数だけ見れば無料アカウントで足りていても、業務の継続性としては不安が残ります。

一方で、個人の学習用、社内での試作、少人数のチーム内だけで使う補助ツールであれば、最初から大きな構成にする必要はありません。小さく作って、実際に使われるかを確認し、必要になった段階でWorkspace環境や共有ドライブ、管理者アカウントに移す進め方が現実的です。

この記事で重視するのは、制限値の暗記ではありません。どの制限が業務に影響しやすいか、どの段階で無料アカウントからWorkspaceへ移すべきか、そしてWorkspaceを使っても残る設計上の注意点を理解することです。

3. 無料アカウントでもできること

無料のGoogleアカウントでも、GASの基本的な機能は使えます。

たとえば、Googleスプレッドシートのメニューからスクリプトを作り、表の内容を加工したり、条件に合う行を抽出したり、簡単なメール通知を送ったりできます。

小さな業務改善であれば、無料アカウントでも十分に役立ちます。

スプレッドシートの定期集計
少人数へのメール通知
Googleフォームの回答整理
Googleドライブ内のファイル整理
簡単なPDF作成
小規模なWebアプリ
自分用の作業自動化

無料アカウントの良いところは、すぐに試せることです。

Googleアカウントがあれば追加費用なしで始められるため、「この業務はGASで効率化できそうか」を検証しやすくなります。試作品を作り、業務の流れに合うかを確認する段階では、無料アカウントは便利です。

たとえば、毎朝スプレッドシートの内容を確認して、条件に合う行があれば自分宛てに通知する程度であれば、無料アカウントでも始めやすいです。フォーム回答を別シートへ整形する、チェック欄が付いた行だけPDF化する、月末に対象データをまとめるといった用途も、処理量が小さければ無料アカウントで十分な場合があります。

無料アカウントは、業務設計を試すための環境としても有効です。いきなり完成版を作るのではなく、まず担当者が実際に使ってみて、入力項目、通知タイミング、エラーの出方、処理にかかる時間を確認できます。この段階では、制限値よりも「業務の流れに合っているか」を見ることが重要です。

ただし、無料アカウントは個人利用に近い前提で考えるべきです。

会社の重要な業務や顧客向けツールを、担当者個人の無料アカウントで運用すると、退職や異動、パスワード管理、権限引き継ぎで困ることがあります。

また、無料アカウントではメール送信数やトリガー総実行時間などの割り当てが小さめです。最初は問題なく動いていても、利用者や処理件数が増えると制限に近づくことがあります。

無料アカウントで作ったツールをそのまま長く使う場合は、少なくとも次の点を確認しておきたいところです。

誰のGoogleアカウントでスクリプトを所有しているか
トリガーを設定しているユーザーは誰か
スプレッドシートやDriveフォルダの権限はどうなっているか
エラー通知は誰に届くか
メール送信元として見えても問題ないアドレスか
将来Workspace環境へ移す場合に、設定を再現できるか

無料アカウントは「使えない」のではなく、「試しやすいが、運用責任を置きにくい」と捉えると判断しやすくなります。

4. Google Workspaceで増える主な割り当て

Google Workspaceアカウントでは、無料アカウントより大きい割り当てが用意されている項目があります。

検索で「google workspace gas 制限」や「gas 無料制限」を調べている場合、まず見たいのは無料アカウントとWorkspaceで何が違うかです。代表的な違いを整理すると、次のようになります。

項目	無料アカウント	Google Workspace	注意点
メール受信者数	1日100人	1日1,500人	1通に複数宛先を入れると受信者数として増える
URL Fetch	1日20,000回	1日100,000回	連携先API側のレート制限も別に確認する
トリガー総実行時間	1日90分	1日6時間	定期実行全体の合計時間として見る
Properties読み書き	1日50,000回	1日500,000回	ループ内で毎回読み書きすると消費しやすい
1回あたりの実行時間	6分	6分	Workspaceでも同じため、長時間処理は分割が必要

代表的な違いは、メール送信数です。

Googleの公式ドキュメントでは、Apps Scriptのメール受信者数は、個人アカウントでは1日100人、Google Workspaceアカウントでは1日1,500人とされています。社内通知や請求書送信などでメールを多く送る場合、この差は大きくなります。

URL Fetchの呼び出し回数にも違いがあります。

外部APIへアクセスする UrlFetchApp は、個人アカウントでは1日20,000回、Google Workspaceアカウントでは1日100,000回とされています。GASから外部サービスやSupabaseなどへ連携する場合は、確認しておきたい項目です。

時間主導トリガーの総実行時間も異なります。

個人アカウントでは1日90分、Google Workspaceアカウントでは1日6時間とされています。定期実行で集計、通知、PDF作成、データ同期を行う場合、トリガーの総実行時間は重要です。

Propertiesの読み書き回数にも差があります。

個人アカウントでは1日50,000回、Google Workspaceアカウントでは1日500,000回とされています。設定値や状態管理をPropertiesに保存するツールでは、読み書きが多くなりすぎないように設計する必要があります。

一方で、すべてが大きく変わるわけではありません。

たとえば、1回あたりのスクリプト実行時間は、公式表では個人アカウントもGoogle Workspaceアカウントも6分です。Workspaceにすれば長時間処理が何でも解決する、という理解は危険です。

Workspaceで増える割り当ては、主に「1日にどれだけ処理できるか」に関わるものです。メール送信、外部APIアクセス、トリガー総実行時間、Properties読み書きのように、業務が広がるほど増えやすい処理で差が出ます。

ただし、割り当てが大きくなることと、設計が不要になることは別です。たとえばURL Fetchが1日100,000回まで使えるとしても、1件の処理で外部APIを何度も呼ぶ設計にしていると、利用者が増えたときにすぐ上限へ近づきます。Propertiesも同じで、ループの中で毎回読み書きする設計にすると、思った以上に回数を消費します。

実務では、次のように「どの割り当てを消費しているか」を分けて考える必要があります。

メール通知が中心なら、受信者数と1通あたりの宛先数を見る
外部サービス連携が中心なら、URL Fetch回数と相手側APIの制限を見る
定期処理が中心なら、トリガー総実行時間と1回あたり6分制限を見る
状態管理が多いなら、Propertiesの読み書き回数と保存容量を見る
ファイル作成が多いなら、DriveやDocs側の制限も見る

制限値は「どのアカウントなら多いか」だけでなく、「どの処理がその制限を消費するか」まで見ないと、実際のリスクが見えません。

5. メール送信が多い業務で注意すること

GASの実務利用で特に注意したいのが、メール送信数です。

発注通知、請求書送信、進捗通知、日報通知、エラー通知など、GASではメール送信を使う場面が多くあります。最初は数件でも、業務が広がると送信数が増えます。

無料アカウントでは、メール受信者数の割り当てが小さいため、少人数向けの通知には向いていますが、多数の取引先や社員へ送る用途では不足することがあります。

Google Workspaceアカウントでは割り当てが大きくなりますが、それでも無制限ではありません。

たとえば、1通のメールに複数の宛先を入れる場合、受信者数としてカウントされます。CCやBCCを使う場合も、送信先の数を意識する必要があります。

請求書送信や一括通知では、次のような設計が重要です。

送信前に対象件数を確認する
テスト送信と本番送信を分ける
送信済み履歴を残す
二重送信を防ぐ
失敗した送信だけ再送できるようにする
1日に送る件数を分散する

GASはメール送信を簡単に自動化できますが、業務メールを大量に送る場合は、割り当てと運用ルールをセットで考える必要があります。

特に注意したいのは、メール送信数を「処理件数」と同じものとして見てしまうことです。1件の請求書を1社に送るだけなら処理件数と受信者数は近くなりますが、社内担当者、上長、経理、取引先の複数宛先へ送る場合、1件の処理で複数人分の受信者数を消費します。

たとえば、50件の請求書を送る処理で、各メールに取引先1名、社内担当者1名、経理共有1件を入れると、受信者数は単純な50ではなく150に近づきます。無料アカウントの上限を意識する場合、この差は無視できません。

また、エラー通知も積み重なると送信数を消費します。処理失敗のたびに管理者へメールを送る設計にしていると、同じエラーが連続したときに大量の通知が発生します。実務では、エラー通知を1件ずつ送るのではなく、一定時間でまとめる、同じエラーは重複通知しない、ログに残して管理画面で確認できるようにする、といった工夫が必要です。

メール送信を含むGASツールでは、送る前の確認画面や送信対象のプレビューも重要です。スプレッドシート上で対象行を抽出し、件数、宛先、件名、添付ファイルの有無を確認してから送信するだけでも、誤送信や上限超過のリスクを下げられます。

顧客向けに納品するツールでは、メール送信元も説明しておくべきです。担当者個人のアドレスから送るのか、会社の共有アドレスから送るのか、送信失敗時の通知は誰に届くのかによって、運用の責任範囲が変わります。

6. 実行時間とトリガー総実行時間の考え方

GASには、1回あたりの実行時間と、トリガーの総実行時間があります。

1回あたりのスクリプト実行時間は、公式表では個人アカウントもGoogle Workspaceアカウントも6分です。つまり、Workspaceを使っていても、1回の処理を長時間動かし続ける設計には向きません。

大量データの処理、PDFの大量作成、外部APIとの大量同期などは、6分以内に終わらない可能性があります。

その場合は、処理を分割する設計が必要です。

対象件数を少しずつ処理する
処理済みの行を記録する
次回トリガーで続きから実行する
重い処理を夜間に回す
不要なSpreadsheet読み書きを減らす

一方で、トリガーの総実行時間はアカウント種別で差があります。

個人アカウントでは1日90分、Google Workspaceアカウントでは1日6時間とされています。定期処理が多い業務では、Workspaceの方が余裕を持ちやすくなります。

ただし、トリガー総実行時間が大きくても、1回の処理が6分を超えれば止まります。

実務では「1回を短く」「全体を分割」「失敗しても再開できる」形にしておくことが大切です。

たとえば、10,000行のデータを毎朝集計する処理を考えます。1回の実行で全行を読み、外部APIへ問い合わせ、結果を書き戻す設計にすると、6分以内に終わらない可能性があります。この場合、500行ずつ処理し、最後に処理した行番号を保存して、次回のトリガーで続きから実行する方が安定します。

PDF作成も時間がかかりやすい処理です。請求書や見積書を1件ずつテンプレートから生成し、Driveへ保存し、メールに添付する場合、件数が増えるほど実行時間が伸びます。全件を一括処理するのではなく、作成、確認、送信を分けるだけでも、処理の失敗範囲を小さくできます。

トリガー処理では、二重起動にも注意が必要です。前回の処理が終わる前に次のトリガーが動くと、同じ行を重複処理したり、送信済みメールを再送したりすることがあります。LockServiceを使って同時実行を防ぐ、処理中フラグを記録する、送信済み日時を必ず残す、といった対策が必要です。

また、GASはSpreadsheetの読み書きが多いと遅くなります。セルを1つずつ読み書きするのではなく、必要な範囲をまとめて取得し、配列上で処理してからまとめて書き戻す設計にすると、実行時間を大きく削減できます。これは無料アカウントかWorkspaceかに関係なく重要です。

Workspaceは総実行時間の余裕を増やしてくれますが、遅い処理をそのまま許容してよいという意味ではありません。実行時間の問題は、アカウント選びだけでなく、データの持ち方、処理単位、再開設計、ログ設計で解決するものです。

7. Workspaceを使うべきケース

Google Workspaceを使うべきかどうかは、単に制限値だけで決めるものではありません。

実務では、管理しやすさ、所有者、権限、継続運用も大きな判断材料になります。

Workspaceを検討した方がよいのは、次のようなケースです。

会社の業務として継続利用する
複数人で同じGASツールを使う
取引先や顧客にメールを送る
毎日トリガー処理を動かす
外部API連携が多い
退職や異動に備えて所有者を管理したい
顧客へGASツールを納品する
共有ドライブや管理者権限を使いたい

無料アカウントでも技術的には動く場合があります。

しかし、会社業務で使うなら、担当者個人のアカウントに依存しないことが大切です。GASプロジェクト、スプレッドシート、保存先フォルダ、トリガー、送信元メールアドレスを会社として管理できる形にする方が安全です。

特に顧客向けツールでは、無料アカウントで作ってそのまま納品するよりも、顧客のWorkspace環境に設置する、または運用責任を明確にした構成にする方が説明しやすくなります。

Workspaceを使うメリットは、割り当ての大きさだけではありません。会社のドメインでユーザーを管理できること、共有ドライブを使えること、管理者がアカウントを制御できること、退職者のデータや権限を扱いやすいことも重要です。

GASツールでは、スクリプトそのものだけでなく、連携するスプレッドシート、フォーム、Driveフォルダ、テンプレートファイル、トリガー、メール送信元が運用に関わります。これらが個人アカウントに散らばっていると、後から全体像を把握しにくくなります。

顧客に納品する場合は、最初に次の点を決めておくとトラブルを減らせます。

スクリプトの所有者を誰にするか
トリガーを誰の権限で動かすか
送信元メールアドレスを何にするか
Drive上の保存先をどこにするか
エラー通知を誰が受けるか
保守時に開発者がどの権限で確認するか

これらはコードの品質とは別の話に見えますが、実務ではツールの信頼性そのものに関わります。処理は正しく書かれていても、所有者が不明、権限が不足、通知先が退職者のままでは、業務ツールとしては不安定です。

無料アカウントで試作し、Workspaceで本番運用する場合は、移行時にトリガーや認可を再設定する必要があります。GASのコードをコピーするだけでは、トリガー、権限、Drive上のファイルID、外部APIの認証情報まで自動的に整うわけではありません。移行手順をメモしておくことも、保守性の一部です。

8. 制限に近づけない設計が大切

GASの割り当ては、上限ぎりぎりまで使う前提で設計しない方が安全です。

Googleの公式ドキュメントでも、割り当ては変更される可能性があると案内されています。今日の上限で動いていても、将来も同じとは限りません。

また、割り当てはGASだけで完結しない場合があります。

Gmail、Googleドライブ、スプレッドシート、外部APIなど、関連するサービス側の制限にも影響されます。たとえば、GAS側では実行できても、Gmail側の送信制限や外部API側のレート制限に当たることがあります。

実務では、次のような対策を入れておくと安心です。

処理件数を事前に確認する
送信数や実行回数を記録する
エラー内容をログに残す
途中で止まっても再開できるようにする
毎回すべてを処理せず差分処理にする
大量処理は分割する
必要に応じて外部DBや専用サービスを検討する

GASは便利ですが、制限を意識しないまま業務の中心に置くと、ある日突然止まるリスクがあります。

制限に近づけない設計では、まず「どれくらい使っているか」を見えるようにすることが大切です。メール送信数、処理件数、外部API呼び出し回数、実行時間、失敗件数をログに残しておくと、上限に近づく前に気づきやすくなります。

ログは複雑な仕組みでなくても構いません。スプレッドシートに処理日時、処理対象件数、成功件数、失敗件数、エラーメッセージを残すだけでも、運用時の確認には役立ちます。顧客向けツールであれば、管理者が見られるログシートを用意しておくと説明しやすくなります。

再開設計も重要です。GASは制限や一時的なエラーで途中停止する可能性があります。途中で止まったときに最初からやり直す設計だと、同じメールを再送したり、同じデータを二重登録したりする危険があります。処理済みフラグ、送信済み日時、外部API登録済みIDなどを残し、再実行しても安全な形にしておく必要があります。

外部APIを使う場合は、相手側の制限も見ます。GAS側のURL Fetch回数に余裕があっても、接続先のAPIに1分あたりの上限がある場合、短時間に連続で呼び出すと失敗します。この場合は、処理間隔を空ける、リトライする、失敗した分だけ後で再処理する、という設計が必要です。

Propertiesは便利ですが、何でも保存する場所ではありません。設定値や少量の状態管理には向いていますが、大量の行データや履歴を保存する用途には向きません。件数が増えるデータはスプレッドシート、外部DB、または専用の保存先を検討した方が安全です。

制限に強いGASツールを作るには、次のような考え方が役立ちます。

1回の処理対象を小さくする
すでに処理したものを判定できるようにする
失敗したものだけ再実行できるようにする
処理前に件数を確認する
処理後に結果を記録する
管理者がログを見られるようにする
上限値を固定の前提にしない

これらを最初からすべて作り込む必要はありません。ただし、業務で使い続けるツールでは、後から入れるより最初に設計しておく方が楽です。

9. 導入判断チェック

無料アカウントで始めるか、Workspaceで運用するかを判断するときは、次の観点で確認すると整理しやすくなります。

利用者は自分だけか、複数人か
処理対象は数十件か、数百件以上に増える可能性があるか
メールを社外や顧客に送るか
毎日または毎時のトリガー処理があるか
外部APIやデータベースと連携するか
担当者が変わっても運用を続ける必要があるか
エラー時に誰が気づき、誰が対応するか
顧客へ納品するツールか、社内の補助ツールか

自分用の小さな自動化であれば、無料アカウントから始めて問題ないことが多いです。失敗しても影響範囲が小さく、処理件数も少なく、送信先も自分や少人数に限られるなら、まず試してみる価値があります。

一方で、会社の業務に組み込む、顧客にメールを送る、毎日自動実行する、複数人が使う、担当者変更後も動き続ける必要がある場合は、Workspaceを前提に考えた方が安全です。割り当てだけでなく、所有者、権限、監査、保守の面で管理しやすくなります。

判断に迷う場合は、最初から大きな仕組みにせず、試作段階と本番段階を分けるのがおすすめです。無料アカウントで業務フローを検証し、本番利用が決まった段階でWorkspace環境に設置する。これにより、開発初期のスピードと運用時の安全性を両立しやすくなります。

ただし、試作から本番へ移す前提なら、ファイルID、シート名、送信元、通知先、トリガー設定をコードやドキュメントで整理しておく必要があります。個人環境でしか動かない前提のまま作ると、移行時に手戻りが増えます。

GASのアカウント選びは、料金だけの話ではありません。どの業務を、誰の責任で、どれくらいの量まで、どのように保守するかを決める話です。

10. まとめ

GASは無料アカウントでも使えますが、実務で継続利用する場合はGoogle Workspaceアカウントとの違いを理解しておく必要があります。

無料アカウントは、試作、自分用の自動化、少人数向けの小さな通知に向いています。一方で、メール送信数、URL Fetch、トリガー総実行時間、Properties読み書きなどは、Google Workspaceの方が大きな割り当てを持っています。

ただし、Workspaceにすればすべての問題が解決するわけではありません。

1回あたりのスクリプト実行時間は、公式表ではどちらも6分です。大量データ処理や長時間処理では、処理分割、再開設計、ログ記録が必要になります。

会社の業務や顧客向けツールでGASを使うなら、制限値だけでなく、所有者、権限、トリガー、送信元、保守体制も含めて考えることが大切です。

まずは無料アカウントで小さく試し、業務利用が見えてきた段階でGoogle Workspaceや運用設計を検討する。この進め方が、GASを安全に使い始めるうえで現実的です。

GASは、低コストで業務改善を始められる強力な選択肢です。しかし、便利さだけを見て業務の中心に置くと、制限、権限、所有者、エラー対応の問題が後から表面化します。

大切なのは、無料アカウントとWorkspaceのどちらが優れているかを決めることではありません。試作には試作に合った使い方を、本番運用には本番運用に合った設計を選ぶことです。

制限値を確認し、処理を分割し、ログを残し、所有者を明確にする。こうした基本を押さえておけば、GASは小さな自動化から顧客向けの業務ツールまで、現実的に活用しやすくなります。

FAQ

GASは無料アカウントでも使えますか？

はい、無料のGoogleアカウントでもGASは使えます。スプレッドシートの集計、少人数へのメール通知、フォーム回答の整理、自分用の自動化であれば無料アカウントから試しやすいです。ただし、会社業務や顧客向けツールでは、所有者、権限、送信元、保守体制も含めて確認する必要があります。

GASの無料アカウントでメール送信はいくつまでできますか？

Google公式ドキュメントでは、Apps Scriptのメール受信者数は無料アカウントで1日100人、Google Workspaceアカウントで1日1,500人とされています。1通に複数の宛先、CC、BCCを入れる場合は受信者数として増えるため、処理件数だけで判断しない方が安全です。

Google WorkspaceにするとGASの制限はなくなりますか？

いいえ。Google Workspaceにすると一部の割り当ては大きくなりますが、GASの制限がなくなるわけではありません。たとえば、メール受信者数、URL Fetch、トリガー総実行時間、Properties読み書きは増えますが、1回あたりのスクリプト実行時間は公式表ではどちらも6分です。

GASの実行時間制限はWorkspaceで伸びますか？

通常のスクリプト実行時間は、公式表では無料アカウントもGoogle Workspaceアカウントも1回6分です。Workspaceにするとトリガー総実行時間には余裕が出ますが、1回の処理を長く動かせるようになるわけではありません。大量処理は分割し、途中で止まっても再開できる設計にする必要があります。