GASの自動化が「ある日突然止まる」理由：6分の壁とトリガーの上限

この記事が答える問い

Googleスプレッドシートの集計やメール送信をGoogle Apps Script（GAS）で自動化した。最初の数か月は問題なく動いていたのに、ある日からエラーで止まるようになった。こうした相談は、GASで自動化した業務によく起きます。

コードを変えていないのに止まる場合、原因は処理するデータが増えて、GASの上限に届いたことが多いです。この記事では、公式ドキュメントに示されている上限と、止まらない設計の考え方を整理します。

結論

• GASには、1回の実行時間や1日あたりの回数などの上限がある
• 無料の個人アカウントでは、1回の実行時間は6分、トリガーで動く処理の合計は1日90分など
• データが増えても止まらないようにするには、処理を小さく分けて、途中から再開できる設計にする

公式ドキュメントに示されている主な上限

Googleの公式ドキュメント「Quotas for Google Services」では、アカウントの種類ごとに上限が示されています。無料の個人アカウント（gmail.com）の場合、たとえば次のとおりです。

Google Workspaceのアカウントでは、一部の上限が大きくなります。また、ドキュメントには、これらの数値は予告なく変わる可能性があると書かれています。設計するときは、必ず最新の公式ドキュメントを確認してください。

「ある日突然止まる」典型的なパターン

1. 全件をループで処理している

スプレッドシートの全行を1行ずつ読み、1行ずつ書き込む処理は、データが少ないうちは数秒で終わります。ところが行数が増えるにつれて実行時間も伸び、ある日6分を超えたところでエラーになります。コードは何も変わっていないので、原因に気づきにくいパターンです。

2. トリガーの合計時間を使い切っている

1回あたりは6分以内でも、5分おきに動くトリガーが毎回数分かかっていれば、1日の合計時間の上限に近づきます。複数の自動化を同じアカウントで動かしていると、合計で上限に届くこともあります。

3. メール送信の上限に届いている

通知メールを1件ずつ送る仕組みでは、送り先が増えたときに1日の送信上限に届くことがあります。上限を超えた分は送られないため、「一部の人にだけ通知が届かない」という形で問題が表れます。

止まらない設計のしかた

読み書きをまとめる

スプレッドシートの読み書きは、1セルずつ行うと時間がかかります。公式のベストプラクティスでも、読み書きをまとめることで処理速度が大きく改善するとされています。範囲をまとめて読み込み、メモリ上で処理してから、まとめて書き込む形にするだけで、実行時間が大きく短くなることがあります。

処理を分けて、途中から再開できるようにする

公式ドキュメントのベストプラクティスでも、長い処理は状態を保存しておき、時間指定のトリガーで続きから再開する方法が紹介されています。

たとえば「何行目まで処理したか」を記録しておき、次の実行ではその続きから処理します。1回の実行で全件を終わらせようとせず、決まった件数ずつ処理する設計にしておけば、データが増えても止まりにくくなります。

失敗したら気づける仕組みにする

上限に届いて止まったとき、誰も気づかないのがいちばんの問題です。処理の最後に結果（何件処理したか、エラーはなかったか）を記録し、失敗したときは担当者に分かるようにしておきます。

GASで続けるか、別の方法にするか

処理を分けても追いつかないほどデータが増えた場合は、GASにこだわらず、別の仕組みに移すことも検討します。

• 毎回の処理件数が非常に多い
• 処理に時間のかかる外部システムとの連携が多い
• 処理の失敗が業務に大きく影響する

こうした場合は、クラウドのサーバーやPythonなど、上限の考え方が異なる方法のほうが向いていることがあります。

チェックリスト

1. 今の処理は、1回あたり何分かかっているか（実行ログで確認）
2. データがいまの数倍に増えても、6分以内に終わるか
3. トリガーの合計時間は、1日の上限に対して余裕があるか
4. スプレッドシートの読み書きを、まとめて行っているか
5. 途中で止まっても、続きから再開できるか
6. 失敗したときに、担当者が気づけるか

まとめ

GASは、Googleのサービスを使っている業務を手軽に自動化できる便利な仕組みです。そのぶん、上限を意識しないまま作ると、データが増えたころに突然止まります。今のデータ量ではなく、1年後のデータ量で動くかを考えて設計しておくと、「ある日突然止まる」を防げます。