[Organizational AI Utilization #224] General staff and non-engineers should make full use of "GAS" to build tools! Organizing the distinction from Python and the relationship with Canvas apps

Hello! This is Terada.

Currently, I serve as the Representative Director of the AI Digital Community (ADC), a community for AI practitioners such as AI promoters at digital-related companies, as well as the Representative Director of FURIKAKE Partners Inc., which supports the "xAI" transformation of client businesses, and AI Portalize Inc., which provides products that support organizational AI utilization. I support organizational AI utilization from various perspectives!

The movement of having AI write code to build tools is spreading rapidly. It has become an era where even general staff and non-engineers can become "creators."

Many people are confused about "which technology to use" when doing so, but my recommendation is clear: make GAS (Google Apps Script) your main battlefield.

I personally build and operate many work-related mechanisms using GAS, such as tools to save Chatwork logs to spreadsheets and news notification bots.

This time, I will summarize what can be done with GAS, how to distinguish it from Python, and its relationship with apps built using Gemini's Canvas.

※ Click here for other articles related to GAS

GAS is not just for Google, it is a "gateway to the cloud"

Many people think of GAS as a "macro for connecting Google services to each other," but its actual scope is much wider.

In short, GAS is a "JavaScript-based execution environment where Google lends you a server for free."

And, it comes standard with the ability to send requests to external websites and APIs. Thanks to this, as long as a service has a public API, you can connect it with tools other than Google.

For example, in my environment, integrations such as fetching Chatwork message logs via API and saving them to a spreadsheet are running solely on GAS. It is also possible to integrate with the Microsoft side, such as fetching data related to Teams.

"An adhesive that connects cloud services to each other." I believe this is the true position of GAS today.

What can be done with GAS

GAS demonstrates its true value in the following types of "connecting the dots" automation:

• Two-way integration with external services: Copying Chatwork messages to a spreadsheet, periodically backing up external files to Google Drive, etc.

• Periodic execution (triggers): Scheduled batch processing such as "fetching data and updating the sheet at 9:00 every morning" can be set up with a single button without setting up a server

• Webhook endpoint: You can receive "send a notification if something happens" requests from external services

• Simple Web apps: Combined with HTML, you can build internal input forms, application tools, and even simple dashboards

Internal application tools, equipment management, shift entry, data visualization. I feel that 90% of the "minor inconveniences" around general staff can be solved within this scope.

Also understand the limitations of GAS

On the other hand, since GAS runs by borrowing Google's servers, there are clear limitations. It is important to be aware of these.

• Execution time barrier: A single execution is limited to a maximum of 6 minutes (up to 30 minutes even for paid Workspace accounts). Heavy processes that exceed this will stop midway.

• Capacity barrier: It is not good at processing GB-class videos or large amounts of images in memory.

• Load barrier: It cannot withstand general-purpose web services accessed simultaneously by an unspecified number of people. Since the URL cannot be a custom domain, you cannot create a professional look for external use either.

• Local barrier: Because it is executed from the cloud, it cannot directly access internal on-premise servers or files on your own PC.

Conversely, if it is a "tool used within a company or team where the data volume fits in a spreadsheet," it is GAS's exclusive domain.

So, when should you use Python?

The question "Can't you do the same thing with Python?" will likely arise. That is correct, and operating spreadsheets and Google Drive from Python is done routinely even in professional development.

If I were to express the difference in one phrase, it is "GAS for ease of use" versus "Python for power and scalability."

• Environment setup: GAS just requires opening a browser. Python requires installation and preparation of an execution environment (servers, etc.).

• Integration with Google: GAS runs directly with the permissions of the logged-in account. Python requires separate authentication settings (service accounts, etc.).

• Execution time: GAS has a 6-minute barrier. Python is unlimited as long as the environment is running.

• Data processing: Python, with its rich libraries, is the overwhelming winner for aggregation/analysis of tens of thousands of rows and video processing.

The biggest mission for general staff is not to write clean code, but to "solve business issues quickly and cheaply." From that perspective, the time performance of GAS, which requires zero environment setup and runs within the same day, is overwhelming.

My recommended ratio is "GAS 8: Python 2." Only borrow the power of Python when you actually hit those walls: heavy processes exceeding 6 minutes, GB-class data, or full-scale analysis of tens of thousands of rows. If you follow this order, you won't get discouraged.

Distinguishing between Gemini Canvas apps and GAS

In a Google Workspace environment, there is also the option to create web apps with Gemini's Canvas feature. I often use it myself because you can create tools with a UI at lightning speed just by giving instructions in chat.

However, there is one major criterion for judgment. That is "whether or not you want to store data."

Apps created with Canvas are excellent as tools that run on the spot, but they are not good at having a 'database' where entered data can be stored, reviewed later, or shared among multiple people.

If you want to store history, update the same data as a team, or use stored data for other processes, I recommend building it with GAS from the start and using a spreadsheet as the database.

With GAS, you can write code to read from and write to spreadsheets in just a few lines, and you can also publish it as a web app limited to internal company use. The configuration of 'screen as a web app, data as a spreadsheet' is the easiest form for non-engineers to handle.

The concept of using a spreadsheet as a database is explained in detail in this previous article.

Furthermore, even if the amount of data increases and the spreadsheet becomes sluggish, you don't need to switch to Python immediately. Since GAS can also connect to full-scale databases like Firestore or BigQuery, you can expand by 'keeping GAS but upgrading only the backend database'.

When in doubt, follow this order

I will summarize the discussion so far as an order of progression.

• Step 1: First, build with GAS + Spreadsheet DB (90% of tools for general staff are completed here)

• Step 2: When the data volume increases, switch to an external database (Firestore or BigQuery) while keeping GAS

• Step 3: If you hit the 6-minute limit, GB-level data, or full-scale analysis, consider Python only for that part

The point is not to try to make the perfect technical selection from the start. Try building with GAS first, and consider switching only after you actually hit a wall. This is the most efficient way to proceed.

Toward the position of 'If you ask that person, they will automate it in an instant'

In an era where AI writes code, what is required of general staff is not implementation ability, but the ability to judge 'which tasks to automate, with which tools, and how to structure them'.

As the main battlefield for that judgment, I believe GAS, which can be started today with zero environment setup, is the strongest option for non-engineers.

'If you tell that person about troublesome internal tasks, they will automate them in an instant with GAS.' This position will undoubtedly become a value within the company.

I hope you will choose one 'minor inconvenience' around you and try building it with GAS together with AI!

Thank you for reading!
Click here for past AI-related articles!

By the way, I have also published a book summarizing the promotion of AI in organizations. Please take a look if you like.