Google Apps Script（GAS）が途中で止まる場合は、1回の実行時間、1日の利用上限、短時間の呼び出し集中を分けて調べます。どれも「処理しすぎ」に見えますが、対処は同じではありません。
この記事では、スプレッドシートの読み書きや定期処理を例に、時間制限の確認、遅い箇所の測定、処理を分割するときの設計を説明します。上限を回避するためのアカウント増設ではなく、必要な処理を無駄なく実行する方法です。
GASの実行時間は原則として1回6分
2026年10月13日に確認した公式の制限表では、通常のスクリプト実行は一般アカウント・Google Workspaceともに1回6分、スプレッドシートのカスタム関数は1回30秒です。トリガーによる実行には、1日の合計実行時間の割り当てもあります。制限は変更されるため、使用中のアカウントと実行方式をGoogle公式の割り当て一覧で確認してください。
| 停止の種類 | 調べる内容 | 主な対応 |
|---|---|---|
| 1回の実行時間を超過 | どの工程が長いか | 呼び出し回数の削減、処理範囲の縮小、分割 |
| 1日の利用上限を超過 | 実行回数とサービス別の使用量 | スケジュールや処理量の見直し |
| 短時間の呼び出しが多い | ループや同時実行の有無 | まとめ処理、間隔の調整、重複起動の抑制 |
| 外部サービスが応答しない | 相手側の応答・制限・障害 | 対象を絞った再試行と、失敗記録 |
時間制限のエラーをtry...catchで囲めば、処理を無制限に続けられるわけではありません。実行時間に余裕を残して終わり、次回へ引き継ぐ設計が必要です。
まず「実行数」と処理時間を確認する
Apps Scriptエディターの「実行数」で、失敗した関数、開始時刻、所要時間、エラーを確認します。手動実行では完了するのに時間主導型トリガーで失敗する場合は、実行時刻の重なりや対象データ量も見比べてください。
処理全体の時間だけでなく、読み込み・計算・書き込み・外部通信に分けて記録すると、改善する場所が分かります。次は「データ」というシートのA1:E100を読み込み、読み込みと配列処理を分けて計測する例です。スプレッドシートから開いたスクリプトで使います。
function measureRead() {
const book = SpreadsheetApp.getActiveSpreadsheet();
if (!book) throw new Error('スプレッドシートから実行してください');
const sheet = book.getSheetByName('データ');
if (!sheet) throw new Error('データシートがありません');
console.time('read');
const values = sheet.getRange('A1:E100').getValues();
console.timeEnd('read');
console.time('count');
const count = values.filter(row => row[0] !== '').length;
console.timeEnd('count');
console.log('A列に値がある行数: ' + count);
}この例はセルを更新しません。実データの本文をログへ出さず、時間と件数だけを記録しています。実行環境によって時間は変わるので、1回の数値だけで速い・遅いと断定せず、同じ範囲と条件で比較します。ログの扱いはGoogle公式のロギングガイドも参照してください。
高速化は、セルへのアクセス回数を減らすところから
1行ずつgetValue()で読み、1行ずつsetValue()で書く処理は、サービスへの呼び出しが増えます。範囲をまとめてgetValues()で読み、JavaScriptの配列で処理し、必要な範囲をまとめて書き戻す構成を検討します。Googleも読み書きの一括処理をベストプラクティスとして案内しています。Google公式：Apps Scriptのベストプラクティス
ただし、一括取得なら全列・全行を読んでよいわけではありません。必要な列と処理対象の行を決め、使わないデータは読み込まないようにします。数式が入っている列へ値を書き戻すと数式を失うので、入力範囲と出力範囲も分けてください。
読み書きの形はgetValues・setValuesでまとめて処理する方法で確認できます。最適化の前後で、結果の件数や合計が変わっていないかも照合します。
6分で終わらない仕事は、小さな単位に分ける
高速化しても1回に収まらない場合は、処理を複数回へ分けます。最初に決めるのは「何件ずつにするか」だけではありません。
- 1件を識別できるIDと、処理対象の一覧を決める。
- 処理済み・未処理・失敗を区別できる状態を保存する。
- 1回の処理量や停止する時刻を、上限より手前に設定する。
- 再実行時に、保存した状態から対象を選び直す。
- 最後の対象が終わったら、定期実行を終了できるようにする。
たとえば「次は101行目」という行番号だけを保存すると、実行の間に並べ替えや行追加が起きたときに、別のデータを処理してしまいます。途中で元データが変わる運用では、固定IDや処理対象のスナップショットを使う方が判断しやすくなります。
進捗を保存する方法としてPropertiesサービスが使えますが、大量データそのものを詰め込む保存先ではありません。件数や容量の制限を確認し、進捗情報と本体データを分けます。Google公式：Propertiesサービス
途中から再開するときに起きやすい問題
メールの二重送信や、同じデータの二重登録
外部への送信が終わった直後に停止し、処理済みの記録が残らなかった場合、再実行で同じ処理を繰り返すおそれがあります。外部サービスが受け付ける重複防止キーや、記録済みIDの照合など、再実行しても結果が増えない設計を検討します。
時間主導型トリガーが重複する
続行のたびにトリガーを作り、古いものを管理しないと、同じ関数が何度も起動する構成になります。実行を予約する担当を1つに決め、不要な予約を残さないようにします。作成者のアカウントで動く点も、インストール可能なトリガーの仕様で確認してください。
前の実行が終わる前に次が始まる
同じ進捗情報を複数の実行が同時に更新すると、取りこぼしや重複が起きます。必要に応じてLockServiceによる排他制御を使い、ロックを取れない場合の終了方法も決めます。ロックは実行時間そのものを延長する機能ではありません。
変更後に確認すること
- 対象件数と、完了・失敗・未処理の件数が一致する。
- 途中で止めても、再実行で重複や欠落が発生しない。
- 0件、少量、大量のそれぞれで終了条件が成立する。
- トリガーが不要に増えていない。
- 1回の処理時間だけでなく、1日の実行量も制限内に収まる。
小さな処理へ分ければ何でもGASに向くとは限りません。大量の外部通信や長時間の計算が中心なら、Apps Scriptは起動や結果の受け渡しを担当し、処理本体を別の実行基盤へ移す選択肢もあります。まず計測し、どこに時間がかかっているかを明らかにすることが出発点です。
