Google Apps Script（GAS）を使うと、Googleスプレッドシート、Gmail、Googleドライブ、Googleカレンダー、Googleフォームといった、Google Workspaceの中で行っている定型業務を、追加のツールを契約せずに自動化できます。フォームの回答の整理、定期的なメールの送信、ファイルの作成と整理、スプレッドシートの集計と通知などは、GASが特に得意とする業務です。少しのプログラムで大きく手間を減らせるため、多くの会社で現場の担当者が便利な仕組みを作っています。
その一方で、GASで作った仕組みは「作った人がいなくなった後」に問題が表面化しやすいという弱点を抱えています。誰が作ったのか、どこで動いているのか、何をしているのかが分からないまま業務が依存し、ある日突然動かなくなって初めて存在に気づく、ということが起こります。GASで自動化を進めるなら、作り方と同じくらい、保守の仕組みを最初から考えておくことが大切です。
この記事は、Google Workspaceを使っている会社で業務の自動化を進めたい管理者や担当者、すでにGASで作った仕組みの扱いに困っている情報システム担当者に向けて書いています。GASでできること、向いている業務の具体例、作るときの手順、保守の注意点、限界が来たときの判断までを整理します。読み終えるころには、GASで作ってよい業務と、作るなら最初に決めておくべきことが分かるはずです。
Google Apps Scriptでできること
Google Apps Scriptは、Googleが提供するプログラムの実行環境で、JavaScriptに近い書き方でGoogle Workspaceの各サービスを操作できます。プログラムはGoogleのサーバー上で動くため、自分のパソコンを起動しておく必要がありません。
GASでできることを大きく分けると、次のようになります。
| できること | 具体例 |
|---|---|
| スプレッドシートの操作 | データの集計、並べ替え、別シートへの転記、条件に合う行の抽出 |
| メールの送受信 | 一覧をもとにした個別メールの送信、特定のメールの内容の取り出し |
| ファイルの操作 | テンプレートからの文書作成、PDFへの変換、フォルダへの振り分け |
| カレンダーの操作 | 予定の一括登録、予定の一覧の取り出し |
| フォームとの連携 | 回答があったときの自動処理、回答者への自動返信 |
| 定期実行 | 毎朝・毎週など決まった時刻に処理を動かす |
| 外部サービスとの連携 | 外部のAPIを呼び出してデータを取得・送信する、チャットに通知する |
| 簡単な画面の作成 | スプレッドシートにメニューを追加する、簡易な入力画面を作る |
処理を動かすきっかけ（トリガー）には、決まった時刻に動かす時間主導のトリガー、フォームの送信やスプレッドシートの編集をきっかけにするトリガーなどがあります。これを組み合わせることで、人が操作しなくても業務が進む仕組みを作れます。
なお、GASには1回の処理にかけられる時間、1日に送れるメールの数などの利用制限があります。制限の内容は契約しているGoogle Workspaceの種類によって異なり、見直されることもあるため、作る前に公式の情報で最新の内容を確認してください。
GASに向いている業務の具体例
GASが向いているのは、Google Workspaceの中でデータが完結し、処理の手順とルールが明確で、データの量がそれほど多くない業務です。代表的な例を挙げます。
フォームの回答を整理して担当者に知らせる
Googleフォームで受け付けた申し込みや問い合わせを、種類に応じて別のシートに振り分け、担当者にメールやチャットで通知する仕組みです。回答者への受付確認メールも同時に送れます。手作業で回答を確認し、転記し、連絡していた作業がなくなります。
一覧から個別の書類やメールを作る
スプレッドシートの取引先一覧をもとに、Googleドキュメントのテンプレートから案内状や見積書を作成し、PDFにしてフォルダに保存する、あるいは一覧の宛先に個別の内容でメールを送る、といった仕組みです。差し込み印刷のような作業を、ボタン一つで実行できるようにします。
定期的な集計とレポートの配信
毎週月曜の朝に、売上や問い合わせ件数のシートを集計し、要点をまとめてチャットやメールで共有する仕組みです。定例会議の前に誰かが数字を集める作業がなくなります。定期レポートの作り方全般は定例レポート作成を自動化するでも扱っています。
ファイルやフォルダの整理
決まったフォルダに保存されたファイルの名前を規則に沿って付け替える、古いファイルを保管用のフォルダに移す、共有の設定を確認して一覧にする、といった整理作業です。目立たない作業ですが、積み重なると大きな手間になっています。
予定の登録や日程の連絡
社内の研修や面談の予定を一覧から一括でカレンダーに登録する、翌週の予定を担当者ごとにまとめて送る、といった仕組みもGASで作れます。予定の作成と案内のメールを組み合わせれば、日程の連絡にかかる手間を大きく減らせます。
GASで自動化を進める手順
GASは手軽に作り始められるため、思いついたまま書き始めてしまいがちです。後から困らないためには、次の手順で進めることをおすすめします。
- 自動化したい業務の流れを書き出す。きっかけ、処理の手順、判断の条件、例外、結果を誰に届けるかを文章にする。
- 処理するデータの量と、実行の頻度を確認する。利用制限に近づきそうなら、この時点で別の手段も検討する。
- 作る場所を決める。個人のマイドライブではなく、チームの共有ドライブにあるスプレッドシートやプロジェクトに作る。
- 処理を小さな関数に分けて書く。「データを読む」「加工する」「書き出す」「通知する」を分けておくと、修正や確認がしやすい。
- 設定値（シート名、送信先、フォルダの場所など）は、プログラムの中に直接書かず、設定用のシートなどにまとめる。
- エラーが起きたときに通知する処理と、実行結果を記録する処理を入れる。
- 少量のデータで試し、例外のデータでも試してから本番に移す。
- 目的、使い方、トリガーの設定、担当者を記録した説明書を、スクリプトと同じ場所に置く。
手順5の設定値の分離は、保守のしやすさを大きく左右します。送信先が変わるたびにプログラムを書き換える必要があると、プログラムを読めない人は対応できません。設定用のシートを見て書き換えるだけで済むようにしておけば、現場の担当者でも変更に対応できます。
本番のデータで試す前に確認すること
GASはメールの送信やファイルの削除など、取り消しの難しい操作も簡単に実行できます。試すときは、本番の一覧をコピーした試験用のシートを使い、送信先を自分やチームのアドレスに置き換えて動かします。特にメールを一斉に送る処理は、宛先と本文の差し込みが正しいかを少数の件数で確かめてから、本番の宛先に切り替えます。
例外のデータでの確認も欠かせません。必須の欄が空の行、想定外の文字が入った行、同じ人が二度申し込んだ行などを意図的に用意し、処理が止まるのか、飛ばすのか、通知するのかを確かめます。例外のときの動きを決めておかないと、本番で一件の不備が残りの処理すべてを止めてしまうことがあります。
作った人がいなくなった後の保守対策
GASの最大の課題は保守です。特に注意すべき点を整理します。
トリガーとファイルの所有者が個人に紐づく
GASのトリガーは、設定した人の権限で動きます。スクリプトが置かれたファイルの所有者も、通常は作った人です。作った人が退職してアカウントが削除されると、トリガーが動かなくなったり、ファイル自体にアクセスできなくなったりします。業務上重要なスクリプトは、共有ドライブに置き、組織として管理できる状態にしておくことが欠かせません。トリガーを設定するアカウントの扱いも、情報システム担当と相談して決めておきます。
どこで何が動いているか分からなくなる
GASはスプレッドシートやドキュメントに付属する形でも作れるため、外から見ても、そのファイルにスクリプトがあるかどうか分かりにくいという性質があります。部署ごとに作られたスクリプトが増えると、全体像を把握できなくなります。スクリプトの一覧を作り、目的、置き場所、トリガー、担当者を記録しておきます。こうした管理されない仕組みの問題は自動化の仕組みを誰が保守するかで詳しく扱っています。
止まっても気づかない
時間主導のトリガーで動くスクリプトは、エラーで止まっても、作った人にしか通知が届かない場合があります。作った人が異動していれば、誰も気づきません。エラー時の通知を、チームで共有するアドレスやチャットに送るようにし、定期的に実行の記録を確認する担当を決めておきます。
引き継ぎの資料を残す
引き継ぎに必要な情報は、多くありません。何のためのスクリプトか、どのファイルやフォルダを使っているか、いつ動くか、止まったら何が起きるか、止まったときに手作業でどう代替するか。この5点が書かれていれば、プログラムの細部が分からなくても、後任者は対応の見当を付けられます。
あわせて、プログラムの変更の履歴を残す習慣も付けておきます。いつ、誰が、何のために変更したかを説明書の末尾に一行ずつ書き足すだけでも、不具合が起きたときに直前の変更を疑うといった切り分けがしやすくなります。大きな変更の前には、元のスクリプトの写しを残しておくと、問題が起きたときに元に戻せます。
具体例：受付業務をGASで自動化し、保守の仕組みも整えた場合
架空の一般例として、セミナーを定期的に開催している会社で、申し込みの受付をGASで自動化した場面を考えます。以前は、フォームの回答を担当者が毎日確認し、参加者の一覧に転記し、受付確認のメールと前日のリマインドメールを手作業で送っていました。
GASで次のように自動化しました。フォームに回答があると、回答の内容を開催回ごとのシートに振り分け、受付確認のメールを自動で送ります。毎朝決まった時刻には翌日開催のセミナーを確認し、参加者にリマインドメールを送ります。定員に達した回は、フォームの選択肢から自動で外します。
あわせて、保守の仕組みも整えました。スクリプトとスプレッドシートはマーケティングチームの共有ドライブに置きました。メールの文面、送信元の表示名、定員は設定用のシートで管理し、担当者が自分で変更できるようにしました。エラーが起きるとチームのチャットに通知が届き、毎朝のリマインド送信が終わると件数が通知されます。スクリプトの目的、トリガーの設定、止まったときの手作業での代替手順を書いた説明書を、同じフォルダに置きました。
その後、作成した担当者が別の部署に異動しましたが、後任者は説明書と設定用のシートを見て運用を引き継ぐことができました。この例のポイントは、自動化そのものより、作った人がいなくても回る状態を最初から作ったことにあります。
GASの限界と、移行を考えるタイミング
GASは便利ですが、すべての業務に向いているわけではありません。次のような兆候が出てきたら、別の手段への移行を考える時期です。
| 兆候 | 背景 | 検討する手段 |
|---|---|---|
| 処理が時間内に終わらない | データ量が増え、実行時間の制限に近づいている | データベースを備えた業務システム、個別開発 |
| スプレッドシートが重く、同時編集で不具合が出る | スプレッドシートをデータベース代わりにしている | 業務システム、データベースへの移行 |
| スクリプトが長く複雑で、作った人しか直せない | 機能の追加を重ねて構造が崩れている | 要件を整理し直して作り直す |
| 権限管理や操作の記録が必要になった | 利用者が増え、誰が何を変えたか追う必要がある | 権限と操作記録を備えた社内システム |
| Google Workspace以外との連携が中心になった | 外部サービスとの連携が増えている | API連携の個別開発、iPaaS |
移行の判断と進め方はGASで作る社内ツールの限界と移行の目安で詳しく解説しています。移行する場合も、GASで運用していた間に明確になった業務のルールや例外の扱いは、新しい仕組みの要件としてそのまま生かせます。GASで小さく始めたことは無駄にはなりません。
移行を決めたら、いきなりGASを止めるのではなく、新しい仕組みと一定期間並行して動かし、結果が一致することを確かめてから切り替えます。GASが行っていた処理の中には、説明書に書かれていない細かな動きが含まれていることがあり、並行稼働の間にそうした差分を見つけられます。
導入前のチェックリストとよくある失敗
導入前のチェックリスト
- 自動化したい業務の流れ、判断の条件、例外を書き出したか
- データの量と実行の頻度が、利用制限の範囲に収まるか確認したか
- スクリプトを共有ドライブなど、組織で管理できる場所に置いたか
- 設定値をプログラムから分離し、担当者が変更できるようにしたか
- エラー時の通知先を、個人ではなくチームにしたか
- 実行結果の記録を残すようにしたか
- 目的、トリガー、担当者、代替手順を書いた説明書を置いたか
- スクリプトの一覧に登録したか
よくある失敗と避け方
個人のマイドライブで作る。 作った人の退職とともにアクセスできなくなります。最初から共有ドライブで作ります。
設定値をプログラムに直接書き込む。 宛先や文面の変更のたびにプログラムを書き換える必要があり、作った人しか対応できなくなります。設定用のシートに分離します。
エラーの通知を設定しない。 止まっても気づかず、業務の抜け漏れが後から発覚します。エラーの通知と、正常終了の記録の両方を用意します。
機能を継ぎ足し続ける。 便利になるほど要望が増え、スクリプトが長く複雑になります。機能を追加する前に、GASで続けるべきか、別の手段に移るべきかを見直します。
個人情報の扱いを確認しない。 顧客の連絡先などを扱う場合は、共有範囲やメールの送信先の誤りが情報漏えいにつながります。共有の設定と、送信前の確認の手順を決めておきます。
よくある質問
Q. プログラムの経験がなくてもGASを使えますか？
簡単な処理であれば、公式の資料や解説を参考にしながら作ることは可能です。最近は生成AIにやりたいことを伝えてプログラムの下書きを作ってもらう方法もあります。ただし、内容を理解しないまま業務に使うと、問題が起きたときに対応できません。少なくとも、処理の流れと設定値の場所は説明できる状態にしておくことをおすすめします。
Q. Power Automateとどちらを使うべきですか？
社内で主に使っているサービスに合わせて選ぶのが基本です。Google Workspaceが中心ならGAS、Microsoft 365が中心ならPower Automateが自然です。Power AutomateについてはPower Automateで社内業務を自動化するで解説しています。
Q. 社内に誰が作ったか分からないGASがたくさんあります。どう整理すればよいですか？
まず、業務で使っているスプレッドシートやフォームを洗い出し、スクリプトやトリガーが設定されているものを一覧にします。そのうえで、今も必要か、止まったら業務に影響があるかを確認し、必要なものは共有ドライブへの移動、説明書の作成、通知の設定を行います。不要なものは停止します。
Q. GASで作ったものを外部の会社に保守してもらうことはできますか？
可能です。ただし、引き継ぎの際に、目的、使っているファイル、トリガー、業務上の例外などの情報が必要になります。外部に保守を任せる場合も、どの業務にどのスクリプトが使われているかは社内で把握しておくことが大切です。
Otsumuに相談できること
自動化したい業務がGoogle Workspaceの中で完結し、データの量も多くなければ、社内の担当者がGASで作り、この記事のチェックリストに沿って保守の仕組みを整えるだけで十分な効果が出ます。フォームの整理や定期的な通知など、小さな業務から始めてみてください。
一方で、社内に作った人が分からないスクリプトが増えている、処理が重くなって業務に支障が出ている、利用者が増えて権限や記録の管理が必要になった、といった状況では、GASで続けるか、業務システムに移すかの判断が必要になります。判断を先送りにすると、止まったときの影響が大きくなっていきます。
Otsumuは、既存のスクリプトの棚卸しと整理から、GASで続ける範囲と業務システムに移す範囲の切り分け、移行の開発と運用の改善までを一気通貫で支援しています。業務全体の自動化の進め方は自社サービス運用の自動化コンサルティングで、GASやスプレッドシートからの移行は社内ツール開発やExcel業務のシステム化でご相談いただけます。費用は範囲に応じて個別にお見積もりします。
今動いているスクリプトの扱いに迷っている段階でも構いません。まずは30分の無料相談で、状況をお聞かせください。
この記事について
Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。
執筆：Otsumu株式会社 ／ 編集日 2026.10.01