[Organizational AI Utilization #194] Using GAS to Internally Publish Web Apps Created with Gemini is Recommended

Hello! This is Terada.

Currently, I serve as the Representative Director of 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!

By utilizing features like Gemini's canvas, Claude Cowork, and Claude Code, general staff members have become able to easily create web apps. However, I often see cases where people get stuck on where and how to publish them so that they can be used across the entire company.

In this article, I would like to write about the specific procedures and points to keep in mind when publishing web tools or web apps created with tools like Gemini's Canvas for internal company use only.

4 steps to safely publish an app

In short, the diagram above represents an "overview for deploying code created by AI into safe internal apps that can be used in actual business." It is not just about the program running; it clearly shows the procedures and rules to follow until publication. Based on that, the entire process is divided into four steps, organizing the flow from design to operation.

The first step is to create a simple original code and distinguish whether it is something "just for viewing" or a "working mechanism." From there, the flow involves implementation in GAS and embedding in Google Sites, and finally, safety management such as permission settings and code review. In other words, I believe it is required to advance both technical implementation and operational governance in tandem.

Decide the role of what you want to create first

A particularly important part of the procedure is the "differentiation of publication methods" in the second step. You need to clarify whether the prototype you created is a static page just for displaying information or an app-type one that involves input or data storage. This is because this judgment significantly changes the features to be used and the complexity of the implementation.

If the focus is on information posting, Google Sites alone is easy enough to handle, but if integration with Google services is required, that is where GAS comes in. The image is that if you are creating a collection of links for internal regulations, you can complete it with Google Sites, and if you are creating an internal equipment lending tool, you use GAS to record it in a spreadsheet. As a result, I think that by deciding this division of roles at the beginning, the subsequent implementation work will proceed smoothly.

*Please also see this article for specific examples of familiar business efficiency improvements using GAS.

Actual integration and the concept of data storage

Once the roles are decided, the next step is to implement the screen display processing on the GAS side and embed it into Google Sites. At this time, I think using a spreadsheet as a data storage destination is very practical for small to medium-sized internal tools. For example, for purposes such as daily business reports or simple survey aggregation, a familiar spreadsheet can sufficiently meet the requirements.

However, when the number of items increases or complex processing becomes necessary, it is necessary to keep future database migration in mind. Conversely, it is wise to start small with an easy-to-use tool like a spreadsheet and grow the system while watching the usage status. I have the impression that by taking these steps, you can suppress initial construction costs while quickly responding to the needs of the field.

Operational rules to protect business data

Finally, several points to keep in mind for safe operation within the company are listed. It is essential to set strict access restrictions on both Google Sites and GAS, and to keep the permissions of the linked Google Drive and Gmail to the minimum necessary. Also, code generated by AI should not be put into the production environment as is; it is necessary for a human to review it and check for error handling, etc.

In particular, as an operational boundary, it is essential to explicitly state the rule that business data should never be put into environments that may be used for learning, such as personal Google accounts or free AI tools. In other words, completing data processing within a secure environment for companies is the greatest defense against information leakage. I think that by firmly establishing such a foundation, internal development utilizing AI will become safer and more effective.

*Please also see this article regarding the creation of approval rules before internal publication.

Internal deployment using GAS is easy and tends to be secure

So far, we have organized the procedures for publishing internal apps and the points to note during operation.
I believe the most direct path is to stick to the basic model where Google Sites handles the display and navigation, while GAS handles processing such as input and saving. By standardizing this configuration, the hurdles for internal publication are lowered, and the benefits of AI can be delivered to the field while ensuring security.

In the early stages of development, it is important to organize the configuration into a simple, single-screen layout and first create a small, functional prototype. From there, I think it is best to proceed with internal deployment little by little, following the steps introduced here. I hope this serves as a reference for growing AI-based business improvements into tools rooted in actual practice, rather than letting them end as mere experiments.

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

By the way, I have also published a book summarizing AI promotion within organizations. Please take a look if you are interested.