はじめに
社内のDX関連の開発は、ほとんどGAS（Google Apps Script）で済ませています。
LINEやLINE WORKSのBot、Appsheetとの連携処理、スプレッドシートをデータベースにした外部向けフォームのバックエンド。規模もジャンルもバラバラですが、「まずGASで作れないか？」を最初に考える癖がついています。
この記事では、実際にGASで何をどこまで作れたのか、そしてどこで限界を感じたのかを、体験ベースで書いてみます。
GASで実際に作ってきたもの
代表的なものを挙げると、こんな感じです。
- LINEbot / LINE WORKS Bot: スプレッドシートのデータを参照して自動応答するチャットBot
- Appsheet連携: Appsheetで入力されたデータをトリガーにして、通知やデータ加工を自動実行
- 外部向けフォームのバックエンド: Webフォームから送信されたデータをスプレッドシートに書き込み、メール通知や後続処理を行う構成
- 自動リマインド: スプレッドシートの期日データをもとに、チャットツールへ自動通知
これらに共通するのは、すべて無料で動いているということです。依頼者に「費用はかかりません」と伝えると、毎回驚かれます。
GASはGoogle Workspaceに標準搭載されている機能なので、追加の契約やサーバーの用意は不要。スプレッドシートをデータベース代わりにすれば、インフラの管理もほぼゼロで済みます。
GASの基本的な強みや社内DXとの相性については、以前の記事で詳しく書いています。
それでもGASが「足りない」と感じるとき
万能に見えるGASですが、使い込んでいくと限界にぶつかる場面もあります。主に感じるのは以下の2点です。
- 実行時間の制限: GASには1回の実行あたり6分という上限がある。大量データの処理やAPI連携が多い処理では、この制限に引っかかることがある
- 応答速度の遅さ: GASを経由したWebアプリやAPIは、コールドスタートの影響もあり、レスポンスが数秒かかることがある
社内ツールとして使う分には、多少の遅さは許容範囲です。問題は社外のユーザーが触るサービスに使ったときでした。
以前、顧客向けのWebフォームをGAS + スプレッドシートの構成でバックエンドを構築したことがあります。社内検証では問題なく動いていましたが、実際に顧客が使い始めると、画面の表示速度や処理のレスポンスに不満の声が上がりました。
結果として、このフォームのバックエンドはCloud Run + Cloud SQLの構成に置き換えることになりました。GASの手軽さは魅力的でしたが、顧客体験に直結する部分では、応答速度の安定性を優先すべきだったという学びです。
私の使い分けの原則
こうした経験を経て、今はシンプルな原則で技術選定をしています。
「小規模なものは基本GAS。GASで無理なら他の技術を使う。」
これだけです。
最初から「GASでは足りないかもしれない」と構えて、オーバースペックな構成を選んでしまうより、まずGASで作ってみる方が圧倒的に早い。実際に限界が見えたら、そのときに乗り換えを検討すればいい。
この判断基準で社内DXの開発を続けてきましたが、困ったことはありません。
まとめ
GASは万能ではありません。実行時間の制限や応答速度など、用途によっては明確に「足りない」場面があります。
ただ、社内の業務改善やちょっとした自動化であれば、GASで十分すぎるほどカバーできます。無料で、サーバー管理も不要で、Google Workspaceとの連携も簡単。この手軽さに勝る選択肢は、なかなかありません。
まずはGASで作ってみる。足りなくなったら、そのとき考える。それくらいの気軽さで始めるのが、結局いちばん上手くいく方法だと思っています。