GASが向く作業と向かない作業を実際の移行経験から整理する

GASとは何か、何ができるか

GAS(Google Apps Script)は、GmailやGoogleスプレッドシート、Googleフォームといった複数のGoogleサービスを無料でつなげる、JavaScriptベースのスクリプト環境です。

サーバーを自分で用意する必要がなく、ブラウザ上のスクリプトエディタだけでコードを書いて、Googleのクラウド上でそのまま実行できます。構文はJavaScriptに近いため、プログラミング未経験者でもネット上のサンプルコードを少し書き換えるところから始めやすいのが特徴です。トリガーという仕組みを使えば「毎朝9時に実行する」「フォームが送信されたら実行する」といった自動起動も設定できます。

AIと組み合わせた活用事例については、Google Apps Script(GAS)×AIで非エンジニアでも簡単に業務を自動化する方法を徹底解説やGAS × AIで何ができる？業務を自動化する活用事例5選【初心者向け】でも具体的な例が紹介されています。この記事では、そうした一般的な説明の先にある「実際にどこまで使えて、どこで止まるのか」という境界線を、自社の運用実績から書きます。

gpirot.comがGASを選び、今は主力から外した理由

結論から言うと、案件管理の自動化のためにGASで着手しましたが、外部APIとの連携が増えるにつれて実行時間6分の上限に当たり、現在はPython(手元のPCの定時実行)を主力に据えています。

最初に作ろうとしたのは、CrowdWorksなどの案件情報をGoogleスプレッドシートに自動で書き出して管理する仕組みでした。GASはスプレッドシートの読み書きが得意なので、この段階までは順調に進みました。

問題が出たのは、案件情報をスプレッドシートに書くだけでなく、外部のAPIを呼び出してAIに分類させたり、LINEに通知したり、別のサービスにデータを渡したりという処理を一つのスクリプトに積み重ねていったときです。GASには1回の実行につき6分という上限があり、呼び出す外部APIの数が増えるほど、途中でタイムアウトする確率が上がっていきました。エラー処理を足すたびにコードが複雑になり、どこで止まったのか追いにくくなったのが、移行を決めた直接のきっかけです。

現在のgpirot.comは、サイト自体はCloudflare Pagesで動いており、訪問者が使う機能はPages Functionsで実装しています。具体的には、訪問者の業務を入力・処理・出力・確認の4段階に切り分けて返す仕組み、PDFと写真を表データに変換する処理、登録内容から答える問い合わせ受付の3つです。これに対して、定時で動く裏側の処理はWindowsのタスクスケジューラとPythonで組み、データの保存先はSupabaseに統一しています。GASで組んでいた「1本のスクリプトに全部詰め込む」構成から、「役割ごとに別の仕組みに分ける」構成に変わったのが、今の実態です。

今もGASが現役で動いている場所

主力をn8nとPythonに移した後も、Googleサービスの中だけで完結する処理については、今もGASをそのまま使い続けています。

現在は複数の定時タスクを運用していて、Webの収集・AIでの分類と下書き・LINE webhook・Cloudflare Worker・Supabaseを組み合わせ、ローカルPCの定時タスクで回しています。公開や送信は必ず人が確認してから実行する運用です。この複数のうち、外部APIを複数またぐ処理や分類・判断が絡む処理はPython側に寄せていますが、フォームの回答を整形してスプレッドシートの別シートに転記するような、Googleサービスの中だけで完結する処理は、今でもGASのトリガーで動かしています。

実際のコードはこの程度のシンプルさで足りることが多く、これがGASを使い続けている理由でもあります。

function onFormSubmit(e) {
  var values = e.values; // フォームの回答が配列で入ってくる
  var sheet = SpreadsheetApp.getActiveSpreadsheet()
    .getSheetByName("転記先");
  sheet.appendRow([
    new Date(),
    values[1], // 氏名
    values[2], // 問い合わせ内容
    "未対応"
  ]);
}

このように、外部API呼び出しを含まず、受け取ったデータをそのままスプレッドシートに書き込むだけの処理であれば、6分の制限に当たることはまずありません。役割分担として、Google内で完結する軽い処理はGAS、複数のサービスをまたぐ重い処理はPython、という線引きが今の運用です。

GASが向く作業・向かない作業の境界線

実際に移行を迫られた経験から言えるのは、処理が「Googleサービスの中だけで閉じているか」「外部との連携が何段階あるか」で向き不向きが決まるということです。

向かない作業の具体例として、私が実際に詰まったのは「スプレッドシートの1行ごとに外部APIを呼んで結果を書き戻す」処理です。行数が数十件程度ならGASのままでも動きますが、件数が増えてAPI呼び出しの待ち時間が積み重なると、6分の上限にすぐ届いてしまいます。GASにはUrlFetchAppというHTTPリクエスト用の機能があり、見た目には外部連携もできそうに見えるのですが、1回の実行時間という制約は変わらないため、件数が増える前提の処理には向きません。また、API呼び出しが失敗したときに「何秒待ってから、何回まで再試行するか」といった制御を書こうとすると、GAS単体ではコードが煩雑になりやすく、ここもPythonやn8nに任せた方が見通しが良くなります。

自分の業務に当てはめるなら何から試すか

これからGASを試すなら、フォームからの入力をスプレッドシートに転記するところから始めるのが、詰まりにくく効果も実感しやすい一歩です。

1. Googleフォームを1つ作り、受け取りたい項目(氏名・内容など)を設定する。ここで項目の順番を変えると、後述のスクリプトのvaluesの添字もずれるので、先に項目を確定させる。
2. フォームの回答先として新しいGoogleスプレッドシートを紐付ける。既存のシートに追加しようとすると、シート名の指定を間違えて書き込み先が見つからないエラーが出やすいので、最初は新規シートで試す。
3. スプレッドシートのメニューから拡張機能のApps Scriptを開き、先ほどのonFormSubmitのようなコードを貼り付ける。
4. スクリプトエディタの左側でトリガーを開き、実行する関数と「フォーム送信時」のイベントを設定する。この手順を飛ばすと、コードを保存しただけでは一切動かない状態になるので注意する。
5. 初回実行時にGoogleアカウントへの権限許可が求められるので、内容を確認して許可する。許可を拒否するとトリガーが無効化され、気づかないまま転記が止まる原因になる。
6. テストでフォームを1件送信し、スプレッドシートに行が追加されるか確認する。追加されない場合は、トリガーの設定か項目の添字のずれを順に疑う。

ここまでで詰まった場合、近い処理のイメージを掴むために公開中の自社ツールを見てみるのも一つの方法です。PDFや写真をExcelに貼れるデータに変換するAI転記ツールや、登録内容をもとに答える問い合わせの自動返答(管理画面つき)は、入力から出力までの流れを実際に動かして確認できます。自分が作りたい処理の「入力は何で、出力は何になるのか」を整理する材料になります。

GASで限界を感じたら次に何を見るか

外部API連携が増えてきた、あるいは処理時間が6分に近づいてきたと感じたら、無理にGASの中で解決しようとせず、n8nやPythonへの移行、または外注という選択肢を検討する段階です。

判断の目安は、今の処理に「あと1つ連携先を増やせるか」を自問することです。増やせそうにないと感じた時点で、既に境界線を越えています。Googleフォームの回答をスプレッドシートに自動集計する方法を扱った記事では転記そのものの手順を、GAS外注の切り分けと依頼文を扱った記事では依頼先の選び方と発注手順を、それぞれ詳しく書いています。自分で組むか外に頼むかを決める前に、まずは今の処理がどちらの境界線上にあるのかを、本記事の表に当てはめて確認してみてください。