お疲れ様です、田村です。以前、Googleスプレッドシートを扱うApps Scriptで、エラーが出ないまま処理がなかなか戻らないことがありました。原因は実行時間の長さにあったようで、処理の組み方を変えたところ解決しました。
やったことを大まかに言うと、1件ずつ繰り返していた処理を、二つのまとまりに分け、それぞれをまとめて処理する形に見直したというものです。「全部を一度に処理する」でも「細かく1件ずつ処理する」でもなく、一括処理を2回に分けるイメージです。分割前後の実行時間や、実際にGASの時間制限に達していたかは記録がないので、ここでは数字を挙げません。
遅さの原因を「データ量」だけで決めない
元の相談と今回の回答だけでは、どの工程が何秒かかったかまでは分かりません。GoogleのApps Scriptベストプラクティスでは、スプレッドシートなど外部サービスへの呼び出しを減らし、読み書きをまとめることが推奨されています。特に、読み取りと書き込みを何度も交互に行う形は遅くなりやすいと説明されています。
私のケースでは、1件ずつ処理していた部分を見直し、処理を二つに分けて、それぞれがまとめて処理できるよう高速化しました。変更後は、戻ってこないと感じていた処理を終えられるようになりました。ただし、どの操作を何回減らしたか、何秒短くなったかまでは示せません。この変更がすべてのGASに効くという話でもありません。
まず実行状態を確認し、まとめられる単位を探す
似た症状が出たら、最初にApps Scriptの実行数で対象の実行が「実行中」「完了」「失敗」のどこにあるかを確認します。画面が戻らないように見えたことだけで、時間制限に達したとは判断できません。Googleの割り当てと制限には1回の実行時間の上限が掲載されていますが、制限値は公開時点の公式ページで確認してください。
次に、処理を「読み取り」「加工」「書き込み」などに分け、どこで時間がかかるかを見ます。Googleのログ案内にある実行ログやconsoleを使えば、工程の開始と終了を記録できます。業務データの中身そのものはログに出さず、工程名、件数、経過時間だけに絞ります。
遅い工程が分かったら、1件ごとの読み書きをまとめられないか検討します。大きな一括処理が扱いにくい場合は、私のように二つのまとまりへ分ける選択もあります。ただし、途中の結果に依存する処理や、再実行すると重複する書き込みは、単純にまとめたり分割したりできません。元のスクリプトとシートを複製した検証環境で、出力件数と内容が以前と一致するかを確かめてから本番へ反映します。
今回分かったこと
今回の解決は、処理を二つに分け、各部分を一括処理に寄せて高速化した結果です。一方、時間制限エラーの表示や短縮時間を記録していないため、「6分制限が原因だった」「何倍速くなった」とは言えません。
私が以前書いたExcelからGAS Webアプリへデータを送る構成は、データの流れが中心です。処理が戻らないときは、まず実行状態と遅い工程を確かめ、1件ずつの呼び出しを減らせるかを見る。そこから一括処理の大きさや分け方を決めると、原因を見失わずに改善を進められます。