GASが実行時間の制限で止まる場合は、処理を短くする工夫に加え、途中まで終わった仕事を再開できる設計にします。開始時からすべてをやり直すと、API呼出しやファイル作成が重複する可能性があります。
まず、1件の単位、対象一覧、完了の根拠、保留の条件を決めます。制限値はGASの公式資料で、利用するアカウントと実行方法に合わせて確認します。
処理時間の内訳を分ける
読み取り、計算、外部API、書込、通知を分けて記録します。シートを1セルずつ何度も読み書きしているなら、Rangeの一括取得・書込を使えるか検討します。
外部サービスを待つ時間や、大きなファイルの変換が長い場合は、件数を減らすだけで1件が収まるかも確認します。実測していない時間を見積もりの確定値にしないようにします。
再開する対象を固定する
再開位置を「100行目」のような行番号だけで持つと、並べ替えや行追加で対象が変わります。固定のIDを使い、処理開始時の対象と入力の版を記録します。
| 項目 | 内容 |
|---|---|
| job_id | 一連の処理を識別 |
| target_snapshot | 対象IDと入力の版の一覧 |
| state | 未処理、処理中、完了、保留 |
| result_ref | 作成物や更新結果の参照 |
| last_error | 最後に確認した失敗区分 |
以下は架空の状態例です。実際の処理履歴ではありません。
{
"job_id": "DEMO-JOB-01",
"snapshot_version": "v1",
"items": [
{"id": "A01", "state": "done", "result_ref": "demo-result"},
{"id": "A02", "state": "pending", "result_ref": null}
]
}
完了を記録するタイミング
結果を確認してから完了へ進めます。APIへ送る前や、ファイルを作る前に完了と記録しないようにします。
一方、外部処理が終わった後に状態の保存で失敗すると、次の実行は結果を知らない状態になります。処理中のまま残った対象を、未実行と決めつけないことが重要です。結果のIDや相手側の記録を照合し、曖昧なものは保留にします。
状態の保存と同時実行を管理する
小さな設定や再開情報にはProperties Serviceを使う方法があります。対象が多い場合は、状態を確認しやすい台帳なども検討します。プロパティの保存容量や操作回数を、公式の割当に合わせて確認します。
複数の実行が同じ対象を取得しないよう、Lock Serviceで対象の取得と状態変更の区間を管理します。ロックが人の手動編集まで保護するわけではないため、入力の版も照合します。
次の起動と停止を決める
1回の最大件数と、実行時間に余裕を残して止める条件を設けます。定期起動を使うなら、同じ用途のトリガーを増やし続けず、管理する起動元を決めます。
未処理がなくなったときの停止、失敗が続く場合の保留、担当者が再開する条件も残します。再開後は完了件数だけでなく、保留と重複の有無を確認します。
