GAS業務システムの限界—Webアプリへ移す判断基準と段階移行

動いているGASを、古いという理由だけで捨てない

朝9時、350店舗が同じ申請ボタンを押し、担当者には「処理中」のまま問い合わせが届く。開発者の個人アカウントで動くため、異動後の権限も不安。このように業務影響が観測できたときが検討の入口です。コードの新旧や利用者数だけで結論を出しません。

2026年7月27日のCrowdWorksには、GAS製5システムをNext.js等へ移す案件が掲載され、約2,400ユーザー・約350店舗、認証・権限と移行設計が要件に挙げられました。7月23日にはGAS・AppSheet・Google Workspace連携の保守引継ぎ案件も掲載されています。どちらも需要の具体例であり、規模、予算、応募状況を一般的な移行相場や成果としては扱いません。

移行判断は5面で実測する

観点	GASで測る事実	Web化で要件にすること
同時実行	実行中・待機・失敗のピーク	競合制御、キュー、再実行
権限	誰の権限で何を読めるか	役割別認可、操作記録
UI	スマホ操作、入力ミス、待ち時間	入力制御、状態表示
監視	失敗を誰がいつ知るか	ログ、通知、担当、復旧
保守	所有者、版、依存API、手順	リポジトリ、仕様、当番

Googleの公式ドキュメントでは、Apps Scriptは1実行6分、ユーザーあたり同時30実行、スクリプトあたり同時1,000実行などの制限が示され、値は予告なく変更され得るとされています。またWebアプリは、デプロイしたユーザーとして動くか、アクセス中のユーザーとして動くかで権限が変わります。上限の数字だけでなく、ピーク時の失敗と実行主体を確認します。

止めない段階移行は「入口→処理→データ」の順で切る

棚卸し：入口、トリガー、シート、外部API、通知、所有者を図にする
観測：実行時間、失敗、同時実行、手修正、問い合わせを2週間取る
境界：Webへ移す機能とGASに残す処理をAPI単位で分ける
並走：少数部署で新旧結果を比較し、データの正を一つ決める
切替：停止条件、旧系へ戻す手順、担当者を決めて対象を広げる

Googleは公開利用にバージョン付きデプロイを使うよう案内し、所有権移転後も既存デプロイの所有者は変わらず、所有者アカウント削除でエラーになり得ると説明しています。移行前の引継ぎではコードだけでなくデプロイ所有者とCloudプロジェクトも確認します。全社ツールの棚卸しは社内ツール棚卸しの記事も役立ちます。

来週の一歩：最も混む30分を再現する

重要度が高いGASを1本選び、所有者と利用部署を確認する
実行履歴から2週間の失敗、所要時間、同時実行のピークを見る
権限を「閲覧・登録・承認・管理」に分けて現状を書く
テスト用データでピークの操作を再現し、失敗時の復旧を試す
残す・改修する・段階移行するの判断と根拠を1枚にする

before / afterで測る

処理時間の中央値と95パーセンタイル
失敗率、重複登録、手動再実行の件数
権限に関する問い合わせと誤操作件数
障害発生から検知、担当着手、復旧までの時間

よくある質問

GASは利用者が何人になったら移行すべきですか？

人数だけでは決まりません。同時実行、1回の処理時間、失敗率、権限の分け方、画面操作、監視と引継ぎの難しさを実測し、業務影響と合わせて判断します。

GASを一度にすべてWebアプリへ置き換えるべきですか？

通常は受付、データ、処理、通知を分け、影響の小さい機能から二重運用します。旧系へ戻す条件とデータ同期の正を先に決めます。

スプレッドシートのデータも最初に移しますか？

先に項目、重複、更新者、更新時刻を棚卸しします。Web画面だけ先にしてシートを一時的な正とする方法もありますが、同時更新の競合ルールが必要です。