Google Apps Script（GAS）は、スプレッドシートやGmail、カレンダーなどのGoogleのサービスを手軽に自動化でき、追加の費用もほとんどかからない便利な仕組みです。社内の小さな業務を効率化する道具としては、非常に優れています。ただし、GASで作ったツールが業務の中核を担うようになると、実行時間の制限、権限やアカウントの扱い、作った人以外が保守できない問題が次第に表面化します。GASの限界は、技術的な制約よりも「業務の重要度と、仕組みの堅さが釣り合わなくなったとき」に訪れます。
結論として、GASで作ったツールを本格的なシステムへ移すべきなのは、次のいずれかに当てはまる場合です。処理の量が増えて制限に引っかかり、分割や再実行の工夫が複雑になっている。ツールが止まると売上や顧客対応に影響が出る。作った人以外にスクリプトの中身を説明できる人がいない。社外の利用者や細かい権限の制御が必要になっている。逆に、これらに当てはまらないなら、GASで続けるほうが合理的です。
この記事は、GASで社内ツールを作って運用している担当者や、部下が作ったGASのツールに業務が依存していることに気づいた管理者、情報システム担当者に向けています。GASが得意なこと、限界の種類とサイン、続けるか移すかの判断基準、移行の選択肢と手順、よくある失敗を整理します。なお、GASの実行時間や回数の制限値は、アカウントの種類や時期によって異なり、変更されることもあるため、具体的な値はGoogleの公式情報で確認してください。
GASが得意なこと
まず、GASが向いている業務を確認しておきます。この範囲で使っている限り、GASは費用対効果の高い選択肢です。
- スプレッドシートのデータを整形・集計し、別のシートやファイルに書き出す
- フォームの回答をもとに、メールやチャットに通知する
- 定期的にデータを集めてレポートを作り、関係者に送る
- カレンダーの予定やドライブのファイルを一括で作成・整理する
- スプレッドシートに簡単な入力補助やボタンを追加する
GASで業務を自動化する基本的な考え方はGoogle Apps Scriptで業務を自動化するで解説しています。GASそのものの仕組みはGoogle Apps Script（GAS）の用語解説も参考にしてください。
これらに共通するのは、利用者が社内の少人数で、処理が短時間で終わり、止まっても手作業で代替できる、という特徴です。この条件から外れるほど、GASの限界が見えてきます。
GASの限界の種類
GASの限界は、大きく四つに分けられます。
1. 実行時間と回数の制限
GASには、一回の実行時間の上限や、一日あたりのメール送信数、外部へのリクエスト数などの制限があります。データ量が少ないうちは問題になりませんが、処理対象の行数が増えたり、連携先が増えたりすると、処理が途中で止まるようになります。処理を分割して続きから再開する仕組みを作れば回避できますが、仕組みが複雑になり、途中で止まった場合のデータの整合性を保つのが難しくなります。
2. データの置き場所としてのスプレッドシートの限界
GASで作ったツールの多くは、スプレッドシートをデータベース代わりに使っています。行数が増えると読み書きが遅くなり、複数人が同時に操作すると上書きや競合が起きます。スプレッドシートそのものの限界についてはスプレッドシート管理からWebシステムへ移る判断基準で詳しく扱っています。
3. 権限とアカウントの問題
GASのスクリプトは、多くの場合、作った人のアカウントの権限で動きます。その人が退職してアカウントが停止されると、トリガーで動いていた処理が止まります。また、スクリプトがアクセスできる範囲が、作った人のアクセスできる範囲と同じになるため、必要以上に広い権限で動いていることがあります。細かい権限の制御や、社外の利用者への公開も、GASだけで実現するのは難しい領域です。
4. 保守と属人化の問題
GASは手軽に書ける分、設計書やテストがないまま作られることがほとんどです。スクリプトがスプレッドシートやドキュメントに紐づいて散らばり、どこにどのスクリプトがあるか、誰も全体を把握していない状態になりがちです。作った人が異動・退職すると、エラーが出ても誰も直せません。
GASの限界を示すサイン
次のようなサインが出ていないか確認してください。
- 処理が時間切れで止まることがあり、手動で再実行している
- 処理を分割して続きから再開する仕組みを作ったが、途中で止まったときのデータの状態が分からない
- エラーの通知が作った人にしか届かず、その人が不在だと誰も気づかない
- スクリプトを作った人が退職・異動したが、トリガーやスクリプトの持ち主が移されていない
- 複数のスプレッドシートとスクリプトが複雑に参照し合い、どこを変えると何に影響するか分からない
- ツールが止まると、見積もりや請求、顧客への連絡が遅れる
- 取引先や顧客など社外の人に、データの一部を見せたり入力してもらったりしたい
- 利用者ごとに見られるデータを分けたいが、シートの共有設定で無理に実現している
続けるか移すかの判断基準
サインを判断の軸ごとに整理すると、次のようになります。
| 判断軸 | GASで継続 | GASのまま改善 | 本格的なシステムへの移行を検討 |
|---|---|---|---|
| 処理量と実行時間 | 制限に余裕がある | 分割で対応できている | 分割や再実行の仕組みが複雑で不安定 |
| データの量と同時利用 | 少人数・少量 | 古いデータの退避で対応できる | 多人数が同時に更新する |
| 業務上の重要度 | 止まっても手作業で代替できる | 止まると不便だが当日中に回復できる | 止まると売上や顧客対応に直結 |
| 権限の要件 | 社内の少人数で全員同じ権限 | 共有設定の工夫で足りる | 社外利用者、行単位の制御が必要 |
| 保守体制 | 作った人と別にもう一人分かる人がいる | 作った人が文書を残している | 作った人しか分からない、またはもういない |
| 外部連携 | 不要、またはGoogleのサービス内で完結 | 一部の外部サービスとつないでいる | 複数の外部システムと双方向でつなぐ |
右の列が二つ以上あるなら、移行の検討を始める価値があります。特に、業務上の重要度が高く、保守体制が右の列にある場合は、優先して対応すべき状態です。ツールが止まったときに誰も直せず、業務が止まるリスクを抱えているからです。
中央の列が多い場合は、GASのまま改善する余地があります。スクリプトの持ち主を個人から共有の管理用アカウントに移す、エラーの通知先をチームのチャットにする、スクリプトの内容と動かし方を文書にまとめる、古いデータを別のファイルに退避する、といった対策で、当面のリスクは大きく下げられます。
移行の選択肢
GASから移る先は、ひとつではありません。限界の原因に合わせて選びます。
| 移行先 | 向いている状況 | 注意点 |
|---|---|---|
| 業務特化のSaaS | 業務の型が一般的で、製品に合わせられる | 独自のルールは製品の範囲内でしか実現できない |
| ノーコード・業務アプリ作成ツール | 入力・一覧・権限が中心で、現場で改善を続けたい | 複雑な処理や大量データには向かない |
| 自動化ツール（iPaaS） | 複数のSaaS間のデータ連携が中心 | 処理の数や実行回数に応じて費用が増える |
| Webシステムとして開発 | 業務の中核で、権限・連携・データ量の要件が大きい | 初期の開発費と保守体制が必要 |
| GASを残し一部を切り出す | 大半はGASで足りるが、一部の処理だけが重い | 二つの仕組みの境界とエラー時の扱いを決める |
すべてを一度に移す必要はありません。たとえば、重いデータ処理だけをクラウド上の小さなプログラムに移し、通知やレポートの送信はGASに残す、という段階的な移行も可能です。社内ツール全般の作り方の選び方は社内ツールを開発する前に：内製・ノーコード・外注の選び方で整理しています。
GASから本格的なシステムへ移行する手順
- スクリプトの棚卸し：社内にあるGASのスクリプトを洗い出し、スクリプトごとに、目的、紐づくファイル、トリガー、持ち主、利用者、連携先を一覧にします。持ち主が退職者になっていないかも確認します。
- 業務上の重要度で優先順位をつける：止まったときの影響が大きいものから順に、判断基準の表に当てはめ、継続・改善・移行のどれにするかを決めます。
- 処理の中身を言葉にする：移行するスクリプトについて、どのデータを読み、どんなルールで処理し、どこに何を書き出すのかを文書にします。スクリプトの中に埋め込まれた業務ルール（条件分岐や例外処理）を見落とさないことが重要です。
- 要件を整理し直す：GASの制約のために回り道していた処理は、移行先では素直な形に戻します。画面、権限、データの持ち方、エラー時の扱いを決めます。
- 移行先を選び、作る：前述の選択肢から移行先を決め、設定または開発します。
- 並行稼働で検証する：一定期間、GASと新しい仕組みを並行して動かし、結果が一致するかを確認します。
- 切り替えとGASの停止：切り替え日を決め、GASのトリガーを停止します。スクリプトはすぐに削除せず、一定期間は参照できるように残しておきます。
移行後の運用で決めておくこと
移行は、新しい仕組みが動き始めたら終わりではありません。GASで起きていた問題を移行先で繰り返さないために、次の点を決めておきます。
- エラーの検知と通知：処理が失敗したときに、誰に、どの手段で知らせるかを決めます。個人ではなくチームの窓口に届くようにし、対応の手順も簡単に文書にしておきます。
- 保守の担当と依頼の方法：不具合の修正や小さな変更を、社内の誰が判断し、誰に依頼するかを決めます。外部に開発を依頼した場合は、保守の範囲と対応時間を契約で取り決めます。
- 変更しやすい部分の切り出し：締め日、通知先、メールの文面など、業務の都合で頻繁に変わる設定は、プログラムを直さずに管理画面や設定ファイルで変えられるようにしておきます。
- アカウントと権限の管理：処理を動かすアカウントを個人ではなく管理用のものにし、入退社や異動のときに見直す手順を決めます。
GASで起きていた属人化は、移行先がどんな仕組みでも、運用のルールを決めなければ再び起こります。仕組みを変えることと、運用を変えることをセットで考えましょう。
具体的な場面で考える：受注集計と請求書作成の例
架空の例として、小売業向けの卸を行う会社で、営業事務の担当者がGASで受注集計と請求書作成のツールを作った場面を考えます。受注はスプレッドシートに入力され、月末にGASが取引先ごとに集計し、請求書をPDFで作成して、取引先にメールで送ります。
最初は取引先の数が少なく、問題なく動いていました。しかし取引先が増えると、請求書の作成が実行時間の制限で途中で止まるようになり、担当者が処理を分割して続きから再開する仕組みを追加しました。それでも、途中で止まったときにどの取引先まで送ったのかを確認するのに時間がかかり、一度は同じ取引先に請求書を二重に送ってしまいました。さらに、その担当者が産休に入ることになり、誰もスクリプトの中身を理解していないことが分かりました。
判断基準に当てはめると、処理量、業務上の重要度、保守体制のすべてが右の列です。請求書の誤送信は取引先との信頼に関わるため、優先して対応すべき状態です。この場合、まず担当者が不在になる前にスクリプトの処理内容を文書にし、スクリプトとトリガーの持ち主を共有の管理用アカウントに移します。そのうえで、受注の入力と請求書の作成を、送信済みかどうかを記録できるWebシステムに移し、請求書の送信状況を誰でも確認できるようにする、という進め方が考えられます。会計ソフトとの連携も視野に入れれば、請求データの転記の手間も減らせます。
よくある失敗と避け方
作った人が辞めてから問題に気づく
GASのツールの問題が表面化するのは、たいてい作った人がいなくなった後です。避けるには、トリガーやスクリプトの持ち主を個人ではなく共有の管理用アカウントにしておく、作った人と別にもう一人内容が分かる人を置く、という対策を、問題が起きる前に行うことです。
制限を回避する工夫を重ねすぎる
実行時間の制限を回避するために、処理の分割、状態の保存、再実行のトリガーを重ねていくと、仕組みは複雑になり、作った人以外には理解できなくなります。回避の工夫が二重三重になってきたら、それ自体が移行を検討するサインだと考えましょう。
スクリプトの中の業務ルールを見落とす
移行の際に画面や出力だけを見て要件を決めると、スクリプトの中に書かれた例外処理（特定の取引先だけ締め日が違う、特定の商品は別の計算をする、など）が抜け落ちます。移行前にスクリプトを一行ずつ読み、業務ルールを言葉にして確認する作業を省かないでください。
すべてを一度に移そうとする
社内に多数のGASのスクリプトがある場合、すべてを一度に移そうとすると、計画が大きくなりすぎて進みません。業務上の重要度の高いものから順に、継続・改善・移行を判断し、段階的に進めます。
GASのツールを点検するチェックリスト
- 社内にあるGASのスクリプトを一覧にしたか
- スクリプトとトリガーの持ち主が退職者や異動者になっていないか
- エラーの通知が、作った人以外にも届くようになっているか
- スクリプトの目的と処理内容を文書にしているか
- 作った人以外に、内容を理解している人がいるか
- 実行時間や回数の制限に近づいている処理はないか
- ツールが止まったときの影響と、代替手段を確認したか
- 必要以上に広い権限で動いているスクリプトはないか
- 社外の利用者や細かい権限の要件が出てきていないか
- 移行する場合の優先順位を、業務上の重要度で決めたか
よくある質問
Q. GASはやめたほうがよいのですか？
やめる必要はありません。少人数で使う、短時間で終わる、止まっても手作業で代替できる、という範囲の業務では、GASは費用対効果の高い優れた選択肢です。問題になるのは、GASで作ったツールが業務の中核を担うようになり、仕組みの堅さが業務の重要度に見合わなくなったときです。
Q. GASのスクリプトを生成AIで書いてもらうのは問題ありますか？
生成AIを使えば、プログラミングの経験が浅くてもGASのスクリプトを書けるようになっています。ただし、書いた本人が中身を理解していないスクリプトは、エラーが起きたときに直せません。また、権限や個人情報の扱いに問題がないかは、別に確認が必要です。AIで書いた場合も、処理内容を文書に残し、内容が分かる人を置くことをおすすめします。
Q. 移行にはどのくらいの費用がかかりますか？
移行先と範囲によって大きく変わります。業務特化のSaaSで置き換えられるなら、主にかかるのは利用料と設定の手間です。Webシステムとして開発する場合は、画面の数、権限、連携の数、データ移行の量で作業量が決まり、その作業量と作業する人の単価で費用が決まります。まずは移行対象を業務上の重要度で絞ることが、費用を抑える最も確実な方法です。
Q. GASのまま安全に使い続けるには何をすればよいですか？
スクリプトとトリガーの持ち主を共有の管理用アカウントに移す、エラーの通知先をチームにする、処理内容を文書にする、内容が分かる人を二人以上にする、の四つが基本です。これだけでも、作った人の不在で業務が止まるリスクは大きく下がります。
Otsumuに相談できること
GASで作ったツールが少人数で使われ、止まっても手作業で代替できる範囲にあるなら、GASのまま使い続けるのが合理的です。スクリプトの持ち主を共有アカウントに移し、処理内容を文書にし、エラーの通知先をチームにする。この記事のチェックリストに沿って点検すれば、外部に頼らなくても当面のリスクは十分に下げられます。
一方で、GASのツールが請求や受発注、顧客への連絡など業務の中核を担っており、実行時間の制限を回避する工夫が複雑になっている場合や、作った人が不在になって中身を説明できる人がいない場合は、早めに外部の力を借りることをおすすめします。スクリプトの中に埋め込まれた業務ルールを読み解き、移行先を選び、止めずに切り替えるには、ある程度の専門性が必要です。
Otsumuでは、社内ツール開発として、社内のGASスクリプトの棚卸しと処理内容の文書化から、継続・改善・移行の判断、移行先の選定と開発、並行稼働での検証と切り替えまでを一貫して支援しています。目的から逆算して必要な機能に絞り、AIを活用した開発で少人数・短期間で進めるため、最も重要な一つのツールから移すといった小さな始め方にも対応できます。GASのままで十分と判断した場合は、そのようにお伝えします。
GASのツールがどの段階にあるのかを確認したいという段階でもかまいません。30分の無料相談で、現在のスクリプトの使われ方と困りごとをお聞きし、続けるか移すかを一緒に整理します。
この記事のテーマに近い開発メニューは、Google Workspace・GAS開発です。
- GASで足りる範囲を見極めて設計
- 作った人以外も保守できる構成とドキュメント
- 限界が来たらWebシステムへ段階移行
この記事について
Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。
執筆：Otsumu株式会社 ／ 編集日 2026.10.01