目次
GAS（Google Apps Script）は、スプレッチシートやGmailの自動化だけでなく、社内向けのWebアプリも作れます。HTMLService という仕組みを使えば、入力画面や一覧画面をブラウザで開ける形にでき、サーバーの契約も追加の月額費用も要りません。
「スプレッドシートを直接触らせたくない」「入力ミスを画面側で防ぎたい」という中小企業のニーズに、実はよく合います。
ただ、実案件（匿名）でGASのWebAppを作ってみると、**手軽さの裏にある「基盤としての癖」**に当たります。しかもこの癖は、開発中には見えにくく、本番直前や現場に配ったタイミングで顔を出すものが多いのです。
この記事では、私たちが実際に踏んだ3つの壁と、その対処を整理します。GASでのアプリ化を検討している方が、同じところで止まらないための予防策としてお読みください。
壁1：データサイズ — 一覧を一気に返そうとすると詰まる
WebAppでは、画面（クライアント）からサーバー側の関数を呼ぶために google.script.run を使います。ボタンを押したらデータを取ってきて画面に並べる、という一般的な作りです。
ここで最初の壁が来ます。google.script.run の返却データにはサイズの制限があるため、初期表示で大きな一覧をまとめて返そうとすると、うまく届きません。データが増えてきた本番データで初めて発覚する、というのが厄介な点です。
対処はシンプルで、初期データはアプリを開く時点（doGet）でHTMLテンプレートに埋め込む方式に変えました。画面を開いた瞬間にデータが入っている状態を作り、google.script.run は「追加の検索」「更新の送信」といった軽いやり取りに絞ります。
設計の勘所は、「最初に見せるデータ」と「あとから取るデータ」を分けることです。この線引きを最初に決めておけば、データが増えても作り直しになりません。
壁2：シリアライズ — 成功しているのに null が返る
3つの中で、原因の特定に最も時間がかかったのがこれです。
症状はこうでした。サーバー側のログを見ると処理は成功している。値も正しく取れている。ところがクライアントには null が届く。しかも、withFailureHandler（失敗時の処理）すら発火しない。エラーが出ないので、どこが悪いのか分からない状態になります。
原因は、戻り値に Date オブジェクトが混ざっていたことでした。サーバーとクライアントの間でデータを受け渡すとき、値は変換（シリアライズ）されて運ばれます。この変換で扱えない型が混ざると、静かに壊れます。
やりがちなのは、スプレッドシートから素直にデータを取るケースです。getValues() は日時セルを必ず Date で返すため、日付列がある表を扱うアプリでは、ほぼ必ずこの地雷を踏みます。
対処として、返す直前に必ず「素のデータ」に変換する防御を入れました。
| やり方 | 結果 | |
|---|---|---|
| 対処前 | 取得した値をそのまま返す | Date混入で null。エラーも出ない |
| 対処後 | JSON.parse(JSON.stringify(result)) を通して返す | 常に plain object になり安定 |
この一行を返却の共通処理として必ず通すと決めておけば、以降は同じ罠を踏みません。個別の関数ごとに気をつけるのではなく、出口を1本にまとめて防御するのが再発防止のコツです。
なお「エラーが出ないのに動かない」という症状は、原因の見当がつかないと調査が長引きます。null が返るときはまず型を疑う——これは覚えておくだけで時間を節約できる知識です。
壁3：複数アカウント — 現場で「権限がありません」
開発中は問題なく動いたのに、現場に配った途端に「開けません」と言われる。その典型がこれです。
ブラウザに複数のGoogleアカウントでログインしていると、GASのWebAppは意図しないアカウント（デフォルトアカウント）で実行され、権限エラーになります。しかも、OAuthの同意画面すら出ないため、利用者側には「なぜ開けないのか」が分かりません。「アカウントを切り替えてください」という案内もされないので、現場は詰まります。
中小企業では、個人のGmailと会社のGoogle Workspaceを同じブラウザで併用している方が珍しくありません。つまり、これは例外ケースではなく、普通に起きると考えたほうがいいです。
切り分け方法は決まっています。
- シークレットウィンドウで開いてもらう（ログイン状態の影響を排除できる）
- そこで正常に動けば、原因はアプリではなくアカウントの切り替え
- 案内としては「業務用アカウントのみでログインしたウィンドウで開く」を配布手順に含める
技術的な不具合ではないため、配布時の説明書に一行入れておくだけで問い合わせが減ります。作る側は「動くか」を見ますが、現場は「開けるか」で判断します。ここを設計に含めるのが実務です。
本番前に確認しておくこと
3つの壁は、いずれも本番データ・本番の使われ方でしか出ません。だからこそ、順番を決めて確認します。
- 本番相当のデータ量で試す：ダミー数件では通っても、実データでは返らないことがあります。初期表示のデータ量を先に見積もり、埋め込み方式か分割取得かを決めます。
- 返却値の型をplainに統一する：Dateなどが混ざらないよう、サーバーからの返却を1箇所で変換します。「エラーが出ないのに null」を根本から防げます。
- 別アカウント環境で開けるか確認する：開発者自身の環境は最も条件が良い環境です。シークレットウィンドウや別の担当者の端末で、開く手順まで含めて確認します。
なお、GASやGoogle Workspaceの仕様は変わるため、制限値や挙動の最新の条件は必ず公式ドキュメントで確認してください。
それでもGASでアプリを作る価値はあるか
あります。追加のサーバー費用がかからず、権限もGoogle Workspaceの中で完結し、小さく作って直せるという利点は変わりません。「スプレッドシートを現場に直接触らせず、入口だけ画面にしたい」といった用途では、費用対効果が非常に高い選択です。
大事なのは、手軽さと基盤としての癖は別の話だと理解しておくことです。3つの壁は、知っていれば設計段階で回避できるものばかりで、知らずに進むと本番直前で止まります。この差が、そのまま導入の成否になります。
逆に、扱うデータ量が大きい、画面の作りが複雑、リアルタイム性が厳密に必要——といった要件なら、GAS以外の基盤を検討したほうが早いこともあります。**「GASで作れるか」ではなく「GASで無理なく運用が続くか」**で判断します。
まとめ
- GASのWebApp（HTMLService）は、追加費用なしで社内業務アプリを作れる現実的な選択
- ただしデータサイズ・戻り値の型・複数アカウントという3つの癖がある
- 大きな初期データはdoGetでHTMLに埋め込む、返却値はplainに統一する、配布時はアカウント切り替えの案内を入れる
- いずれも本番データ・本番環境でしか出ないため、本番前の確認手順を決めておく（仕様は変わるため最新は公式で確認）
RENOYでは、GASを使った業務自動化やWebアプリ化を、設計から運用が回るまで伴走しています。「スプレッドシートの入力を画面にしたい」「作ってみたが本番でうまく動かない」といった段階のご相談も歓迎です。まずはお気軽に無料個別相談（オンライン・60分）をご利用ください。サービス内容をまとめた資料は資料請求からご覧いただけます。