Google Apps Script（GAS）が6分で止まるたびに、処理を少し削り、待ち時間を足してしのぐ。この対策は、締め切りに追われるたびに睡眠を削るのと同じ構造で、扱う量が増えれば必ずまた足りなくなります。この記事では、GASの時間と回数の制限を、避ける障害ではなく設計の仕様書として読み、止まっても続きから再開できる形に作る方法を整理します。仕様は2025年時点の情報をもとにしています。
回数の上限は、思っているより具体的に決まっています
GASには、1回の実行は6分以内、という分かりやすい壁があります。それに加えて、Googleが公開しているクォータの一覧には、1日あたりのメール送信数、URLFetch の呼び出し回数、トリガーの合計実行時間、同時に動かせる実行の数などが、アカウントの種類ごとに示されています。
実行回数には明確な上限がない、という説明を見かけることがありますが、正確ではありません。この説明を信じて作った自動化は、上限に当たった日に初めて仕様書を読むことになります。多くの上限は1日単位で決まっており、短い時間に呼び出しが集中したときの制限も別にあるからです。作る前に、自分の処理がどの上限に近づきそうかを一覧で確かめます。数字はGoogleの判断で変わることがあるので、使う時点の一覧を見てください。
エラーは、短時間の集中か1日の上限かで処方が変わります
制限にかかると、次のようなメッセージが出ることがあります。
- Service invoked too many times for minute: URLFetch.
- Service invoked too many times: Gmail.
前者のように短い時間あたりの回数を超えた場合は、間隔を空ければ続けられます。Utilities.sleep() で呼び出しの間を置く、トリガーの頻度を下げる、キャッシュを使い、SpreadsheetApp.flush() などで書き込みをまとめて外部へのアクセスを減らす、といった調整が効く場面です。
一方、1日あたりの上限に達した場合は、sleep をいくら足しても、その日のうちは回復しません。待てば直るのは分単位の制限だけだからです。必要なのは、1日に使う量そのものを減らすか、翌日に残りの処理を回す仕組みです。メッセージにどの単位の上限かが書かれていないときは、クォータの一覧と自分の処理量を照らし合わせて見分けます。
止まらない工夫より、続きから再開できる設計にします
トリガーの連続実行、大量データ、外部へのアクセス集中、同じアカウントでの同時実行、長すぎる1回の実行。制限にかかりやすい場面はいくつもありますが、データが増え続ける処理は、どの対策を重ねても、いつか6分か1日の上限に届きます。そこで、止まることを前提に作ります。
- 処理を小さな単位に分ける。名簿なら1行ずつ、ファイルなら1件ずつ
- どこまで終わったかを、PropertiesService などに記録する
- 実行の始まりから時間を測り、6分より手前（たとえば5分）で自分から区切る
- 残りの処理を時間主導型トリガーで次の実行に回し、記録した位置から再開する
- 失敗した単位は記録して、エラー処理とリトライの対象にする
この形なら、制限に当たることは事故ではなく予定どおりの区切りになります。Googleが利用状況を見て制限を調整することがあるため、今日動いた量が明日も動くとは限りません。その意味でも、再開できる設計は保険になります。Googleがどの利用状況でどう制限を調整するのかは公開されておらず、外からは正確に分かりません。分からないものに対しては、当たらない工夫より、当たっても壊れない形のほうが筋がよいのです。
ただし、扱う量が毎回数十行で、今後も増える見込みがない処理なら、ここまでの仕組みは手間のほうが大きくなります。再開の設計が効くのは、データが増える、外部サービスに依存する、止まったときに途中の状態が分からないと困る、という前提がある場合です。
GPTsから呼ぶ処理は、受け付けと本体を分けます
GASをウェブアプリとして公開すると、ChatGPTを自分用にカスタマイズするGPTsから、アクションで呼び出せます。会話の途中で呼ばれる処理は、短く終わらなければ使い心地が悪くなります。重い集計や大量の書き込みは、アクションでは依頼を受け付けて記録するだけにし、本体はトリガーで上の再開できる形のまま動かします。GPTsのプロンプトでは、1回で渡すデータの量と、呼び出す場面を絞っておきます。
手元の自動化が今日途中で止まったら、どこまで終わったかを知っているのは誰でしょうか。スクリプトでしょうか、作った人の記憶でしょうか。そして、その処理が扱う量は、1年後にどれだけ増えている前提で作られているでしょうか。
この記事の背景にある考え方は、拙著『ChatGPT 誰でも1時間でできる！ はじめてのGPTsのつくり方』の1章5節「GPT利用の前提条件と技術的限界」に書きました。利用回数やPythonの実行時間などの制約を一覧にした節で、「これらを理解した上で、計画的にGPTsの開発を進めましょう。」と書いています。並べた数字は2024年時点のもので今は変わっていますが、制約を先に読んでから作るという順序は、GASの6分の壁にもそのまま当てはまります。この節を読むと、使っている道具の上限を、避ける壁ではなく設計の前提として、自分の仕組みのどこに書き込むかを考えられるようになります。
自分の仕事に効くAIは、誰が作るべきか。
『ChatGPT 誰でも1時間でできる！ はじめてのGPTsのつくり方』
要件を日本語で書き出せば、それがそのままAIを動かす。現場の知識を持つ人が自分で作り、育てる、内製化のための本です。
読み終えたとき、手元に残るもの
- 目的、役割、入力、出力をそろえる要件定義の型
- 評価基準と判断基準を持たせる考えるGPTの作り方
- テスト用のダミーデータで直していく手順
- 複数のGPTを分業と協業でつなぐ設計
画面や機能の記述は2024年時点のものです。仕事を分解し、基準を言葉にする考え方は今も変わりません。