GAS Webアプリで社内システムを作る方法と運用の注意点

GAS（Google Apps Script）を使えば、追加のライセンス費用をかけずに社内システムを内製できます。Google Workspaceを契約している企業であれば、稟議申請や備品管理といった業務をWebアプリ化する土台がすでに手元にあるということです。しかし「作れるかどうか」と「実用に耐えるシステムとして運用できるかどうか」は別の問題です。本記事では、GASでWebアプリの社内システムを作る具体的な手順と、運用段階でつまずきやすいポイント、そして専用ツールとの使い分けの考え方まで整理して解説します。

GAS（Google Apps Script）で社内システムのWebアプリは作れるのか

結論として、GASでWebアプリ形式の社内システムを構築することは十分可能です。理由は、GAS自体がスプレッドシート・フォーム・Gmailといった既存のGoogleサービスとサーバーサイド処理を橋渡しするスクリプト実行環境であり、Webアプリとして公開する機能が標準で備わっているためです。

GASとは？Google Workspaceに標準搭載された自動化・開発ツール

GASはGoogleが提供するJavaScriptベースのスクリプト言語兼実行環境で、Google Workspaceの各種サービスをAPI経由で操作できます。スプレッドシートのデータ読み書き、Gmailの自動送信、カレンダー連携などをコードで自動化でき、開発環境もブラウザ上のスクリプトエディタで完結するため、新たなサーバーやIDEを用意する必要がありません。

GASでWebアプリ化できる社内業務の具体例

代表的な活用例は、稟議・経費精算などの承認申請フォーム、備品の貸出・在庫管理、簡易的な勤怠打刻システム、複数部署にまたがるデータの一元入力・検索画面などです。いずれもスプレッドシートを簡易データベースとして扱い、GASがその読み書きとロジック処理を担う構成が基本パターンになります。

GASで社内システムを作るメリット

最大のメリットは追加費用がかからない点です。Google Workspaceの契約範囲内でスクリプト実行・Webアプリ公開・データ保存までが完結するため、専用サーバーやSaaSライセンスを新規契約せずに済みます。既存のGoogleアカウント基盤をそのまま認証に使える点も、社内向けシステムとの相性の良さにつながっています。

GASでWebアプリの社内システムを作る基本的な流れ

GASでの社内システム構築は、データ設計・画面作成・公開設定という3ステップで進めるのが基本です。この順序を踏むことで、後からの機能追加や権限変更にも対応しやすい構成になります。

STEP1：スプレッドシートをデータベース代わりに設計する

申請データや履歴を格納するシートを用意し、列ごとに申請日・申請者・金額・承認ステータスといった項目を定義します。正規のデータベースではないため、行の追加・検索速度・同時書き込みの整合性については、あらかじめ想定件数を踏まえた設計が必要です。

STEP2：doGet/doPostでフロント画面（HTML）を作成する

GASではdoGet関数がブラウザからのアクセス時に呼ばれ、doPost関数がフォーム送信などのデータ受信時に呼ばれます。HTMLServiceを使ってHTML・CSS・JavaScriptで画面を組み、doGetからそのHTMLを返すことで、ブラウザ上で動く申請フォームや一覧画面を実装します。

STEP3：Webアプリとしてデプロイし、アクセス権限を設定する

コードが完成したら「デプロイ」メニューからWebアプリとして公開します。この際、「アプリケーションを実行するユーザー」と「アクセスできるユーザー」を個別に設定でき、社内システムとしては後者を「同一組織（ドメイン）内のユーザーのみ」に限定するのが基本です。

社内システムとして運用する際に必ず押さえるべき設計ポイント

GASを一度きりのツールではなく継続運用する社内システムにするには、認証設計・通信制限・承認ロジックの3点を最初に固めておく必要があります。これらを後回しにすると、公開後の仕様変更が困難になります。

認証・権限設計（実行ユーザーとアクセスユーザーの違い）

「実行ユーザー」を作成者本人に固定すると、スプレッドシートへの書き込み権限を利用者ごとに設定する手間が省ける一方、作成者のアカウントが常に処理の実行主体になるため、退職・異動時の引き継ぎリスクが生じます。運用開始前にどちらの方式を採るか明確にしておくことが重要です。

CORS制限とサーバー経由構成の考え方

GASのWebアプリを、別ドメインの社内サイトやSPAからfetchで直接呼び出す構成にすると、クロスオリジンの制約で詰まることがあります。GASのWebアプリはリクエストがリダイレクトを経由して処理されるため、ブラウザからのfetchではレスポンスを読めずにエラーになる、というパターンが典型です。

回避策は大きく2つです。ひとつは、画面もGAS側のHTMLServiceで持ち、google.script.run で同一オリジン内から呼ぶ構成にすること。もうひとつは、外部から呼ぶ必要がある場合に、GASを直接叩かずサーバーサイドを1枚挟むことです。ブラウザのfetchで mode: 'no-cors' を指定する方法は、リクエストは飛んでもレスポンスを読めないため、結果を受け取る必要がある処理には使えません。最初にどちらの構成で作るかを決めておかないと、画面を作り直すことになります。

承認フロー・多段階承認・通知機能など応用の実装ポイント

課長承認後に部長承認へ進むといった多段階承認は、ステータス列の値によって次の承認者への通知メールをGASから送信するロジックを組むことで実現できます。ただし承認者が複数条件で分岐する場合、スプレッドシートの列設計とスクリプトの条件分岐が複雑化しやすく、仕様変更のたびにコード修正が必要になります。

GASで社内システムを内製する際に直面しやすい課題・限界

GASでの内製化は、規模が拡大するほど保守負荷とリスクが比例して増大するという構造的な限界を抱えています。導入初期は問題なく運用できていても、利用部署が増えるにつれて課題が顕在化しやすくなります。

作成者しか触れなくなる「属人化」のリスク

コードのコメントやドキュメントが整備されていない場合、作成した担当者以外がロジックを理解できず、修正依頼が特定の1人に集中します。担当者が異動・退職すると、システムそのものが「触れない資産」として放置されるリスクがあります。

実行時間制限・同時アクセス数などGAS特有の制約

GASにはスクリプトの実行時間に上限（目安として6分程度）があり、大量データの一括処理や複雑な集計を行うと処理がタイムアウトすることがあります。また同時に多数のユーザーがアクセスした場合の挙動も、専用のワークフローシステムほど安定した設計にはなっていません。

セキュリティ・監査ログ・承認履歴管理の限界

誰がいつ承認したかという履歴はスプレッドシートの更新ログである程度追えますが、改ざん防止や証跡としての監査ログ機能は標準では備わっていません。内部統制や監査対応が求められる経費精算・稟議業務では、この点が導入のボトルネックになりやすい部分です。

GAS内製と専用承認ワークフローツール、どちらを選ぶべきか

判断基準は「フローの複雑さ」と「利用範囲の広さ」の2軸です。単純な申請フローを小規模に試すならGAS内製、全社展開や多段階承認が前提ならば専用ツールという住み分けが実務上は現実的です。

GAS内製が向いているケース

対象部署が少数で、承認者も1〜2階層に収まる単純なフローであれば、GASでの内製は十分に機能します。まずは特定部署でスモールスタートし、運用イメージを検証する用途にも適しています。

なお、承認フローそのものをGASで自動化する場合に、どこまで作り込めてどこで詰まるのかはGASで承認フローを自動化する方法と限界で実装レベルまで整理しています。本記事はWebアプリとして社内システムを作る側の話に絞っているため、承認フロー単体の実装を検討している場合はそちらを参照してください。

専用ツールへ移る判断は「承認の先」で決まる

複数部署・複数階層の承認、金額に応じた承認ルートの分岐、監査ログの保持が必要な場合は、専用ツールの導入が現実的です。ただし移行を判断する本当の分かれ目は、承認フローの複雑さよりも承認が終わったあとに何が続くかにあります。

GASで申請〜承認まで組めても、そのあとの発注・支払い実務は自動化しきれません。承認は取れたものの、結局は従業員が自分のお金で立て替えて後日精算する、という運用に落ちやすい。1Approvalのように法人決済を前提にした仕組みであれば、立替精算自体をなくし、複数サービス・複数取引先の利用料も月1回の法人一括請求にまとめられます。支払手段の選び方そのものは立替精算をなくす方法｜法人カード・一括請求の違いで整理しています。

購買や出張の申請が実行された時点でその内容が経費データとして生成される点も、内製との差が出るところです。GASの内製では承認履歴と経費処理が別々のシートに分かれがちですが、ここが一体化されていれば、情シス・総務・経理が個別に突き合わせる手間を減らせます。Google Workspace側の標準機能でどこまで電子化できるかはGoogle Workspaceで稟議・ワークフローを電子化する方法にまとめています。

GASでの内製をどこまで広げるか検討する際の比較材料として、1Approval for Google Workspaceの詳細を見るのも一つの方法です。

よくある質問（GAS Webアプリ・社内システム作りに関するQ&A）

Q. GASでWebアプリを作るのに料金はかかりますか？

いいえ、Google Workspaceを契約済みであれば、GAS自体の利用に追加料金はかかりません。ただし、大量データ処理のために外部APIや有料の拡張サービスを組み合わせる場合は、その分の費用が別途発生します。

Q. GASで作った社内システムは社外の人がアクセスできないようにできますか？

はい、可能です。Webアプリのデプロイ設定でアクセスできるユーザーを「組織内のユーザーのみ」に限定することで、同一のGoogle Workspaceドメインに所属するアカウントのみがアクセスできる状態にできます。

Q. GASのWebアプリで複数人の承認フロー（多段階承認）は作れますか？

はい、作成できます。ステータス列と承認者列をスプレッドシートに用意し、承認完了のたびに次の承認者へ通知メールを送るロジックを組むことで実現可能です。ただし条件分岐が増えるほどコードが複雑化しやすい点には注意が必要です。

Q. GASで作った社内システムが動かなくなった・エラーが出た場合の対処法は？

まずApps Scriptエディタの実行ログでエラー内容を確認するのが基本の対処法です。原因の多くは、GASの実行時間制限超過、スプレッドシートの権限変更、あるいはGoogle側の仕様アップデートによる互換性の問題です。作成者以外が対応できるよう、コードとエラー対処手順のドキュメント化をあらかじめ進めておくことが重要です。

まとめ｜GASでの内製化と専用ツール活用を使い分けて社内システムを効率化しよう

GASは、Google Workspaceの契約範囲内で社内システムを内製できる強力な選択肢ですが、属人化・実行制限・監査対応といった限界も同時に抱えています。小規模な検証段階ではGASでスモールスタートし、全社展開や監査要件が絡む段階では専用ツールへ移行するという使い分けが、多くの企業にとって現実的な進め方です。

スモールスタートはGAS、全社運用は専用ツールという使い分けの考え方

特定部署の申請フローをまずGASで試作し、運用課題を洗い出したうえで、対象範囲を広げる段階で専用ツールへの切り替えを検討するという二段階のアプローチが、コストとリスクのバランスを取りやすい方法です。

Google Workspaceを最大限活用するなら1Approvalの検討もおすすめ

GASで感じた「属人化を避けたい」「承認履歴を残したい」「承認の先の発注・精算まで自動化したい」というニーズには、Google Workspaceとの親和性を保ったまま運用できる1Approval for Google Workspaceが選択肢になります。自社の申請フローの複雑さと将来的な展開範囲を踏まえて、内製と専用ツールのどちらが適しているか検討してみてください。具体的な機能や導入イメージは、1Approval for Google Workspaceの詳細を見るから確認できます。